6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue Nov 12, 2024 2:08 pm

All times are UTC




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Sun Jun 20, 2021 1:30 am 
Offline

Joined: Sat Jun 05, 2021 6:56 am
Posts: 19
While picking at some of the code I've been working with (looking for places where shortcuts were taken to shave a byte or three or where some likely obfuscation was thrown in), I find a few instructions that seem to accomplish nothing:
(Note: 6800 code follows; I could have rewritten it 6502 style but I wanted to show the setup going into the TST instruction)

Code:
LDX #$0083
STX $00D8
LDA A #$01
STA A $00DE
...
INX
LDA A #$83
ADD A $00DE
STA A $00D9
CLR $00D8
CPX $00D8
TST $00CC
BNE $F6FE

So it loads the index register with $83, bumps it up to $84, then saves the same value to $D8, compares the present value of X to the value in $D8...
then moves to do a test on the flag at $00CC (this other location only ever goes between a 0 and a 1).

So, what does all that rigamarole with X and $D8 accomplish? Does it just force some flags into a predetermined state before moving on to TST?


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 20, 2021 5:44 am 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
CPX affects ^NVZ and TST affects ^NVZC, so I can't see any obvious use for the CPX instruction except to burn four or five cycles.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 20, 2021 7:16 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
It's worth checking for branches into this code. If it's part of a loop, it might make more sense.

But, depending on where it came from, it might also be pointless: a remnant of something needed earlier, or thought to be needed.


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 20, 2021 1:17 pm 
Offline

Joined: Sat Jun 05, 2021 6:56 am
Posts: 19
Long story short, the code pertaining to $D8 can pretty much go at this point, but the TST $CC stays.

I have found a fair number of 'make it work' kludges and programming inconsistencies so far, and $D8 and $DE go into this pile as well. $D8 looks to be an offset that apparently allowed the main table used by the interrupt routine to be relocated by the programmer. There's no reason for it to be moved, so all the relative addresses will be changed to hard-coded addresses (eliminating the need for $D8), and $DE is used in a few loops that get executed only once each.

Whoever was tasked with maintaining the code was apparently told to "just make it work"... the operations using the index register are especially confusing, hence my working to get it cleaned up so I can understand what's going on and ultimately get this rewritten to work on 65xx processors. In some places, the index is used 68xx style where X holds the base address, while in others it is used 65xx style where it is used as an offset for the base address contained in the instruction. In many places, however, it is used merely as a fixed offset (like the designers were unsure where to place one table in RAM before settling on the present location).

An example of programming inconsistencies - there is a flag in other parts of the code that can be set to 1, 2, or 4. When the program checks for the flag being 2 or 4, it does it properly with CMP followed by BEQ or BNE. When it checks for 1, it instead did a LSR followed by BCC or BCS just to save a byte (and they were not hurting for space in the ROM either).


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 21, 2021 10:58 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
Condition code behavior is my biggest gripe about the 68xx family. It doesn't align with my natural train of thought the way the 65xx family does.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 26, 2021 6:35 am 
Offline

Joined: Wed Mar 02, 2016 12:00 pm
Posts: 343
Is this code from one of the old CBM drives? :P The 8050 has a lot of clutter like that.. it has remenants from earlier drive code that is either not used or just doesn't work as intended.


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 22, 2021 8:12 am 
Offline

Joined: Sat Jun 05, 2021 6:56 am
Posts: 19
Still picking at the code to see how it works, particularly the interrupt code, and I wound up making a chart by RAM address to see which locations are read and written and where in the code they are called on.

I just now noticed that the TST $00CC conditional when called, drops down to another seemingly functional section, but then writes to one address, which is the only time in the entire 8K of code that particular location is called on.

So, two possibilities are now rattling around in my mind: One, that code is there just to burn CPU cycles (think I saw this before in some C64 code that was also interrupt driven), or could that bit of code be there to prove copyright?

And Barry, I'll agree that having cut my programming teeth on the 65xx, it's hard to follow the 68xx way sometimes (my gripe is in the way the 68xx's 16-bit index works vs. the X and Y on the 65xx).


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 22, 2021 11:02 am 
Offline
User avatar

Joined: Sat Dec 01, 2018 1:53 pm
Posts: 727
Location: Tokyo, Japan
Meterman58761 wrote:
So it loads the index register with $83, bumps it up to $84, then saves the same value to $D8, compares the present value of X to the value in $D8...

That's not quite how I'm reading it. I get:

  • Load X with $0083 (N.B. a 16-bit value, of course)
  • Store X in $D8:$D9
  • Do other stuff
  • Increment X
  • Store 0 in $D8, leaving $D9 untouched
  • Compare X to $D8:$D9

I assume that something is (or was) jumping up into the area after the STX initialization but before the INX, and so perhaps something is twiddling with the LSB of $D8:$D9 (which the post-INX code doesn't touch) against which X is compared.

That said, yeah, the CPX doesn't seem useful for anything given that the immediately following TST wipes out all the flags that the CPX set. (CPX modifies NZV, TST modifies NZVC.) Unless there's an I/O port at $D8 or $D9, in which case surely there are more clear ways of twiddling it. As others have pointed out, possibly this is old code left over from some previous version of the program?

_________________
Curt J. Sampson - github.com/0cjs


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 24, 2021 1:27 am 
Offline

Joined: Sat Jun 05, 2021 6:56 am
Posts: 19
cjs: $D8 / $D9 is a fixed offset with value $0083 that gets nudged up to $0084, then back.

This is just one of many bits of 'cruft' in the code... given certain aspects of the original unit's hardware design (it has a #$?!?!! hot chassis - even when the power switch is OFF) I'm not entirely surprised. The CPU chip is even a special part - custom 68xx version that was originally developed for car computers and which is now a $50+ part if you can even find any. Hence my interest in cleaning the code to where I have options - further rewrite to 65xx code or something that'll play nice with FPGA.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: