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)


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?

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)

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.

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).

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)

Is this code from one of the old CBM drives? 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.

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).

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

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.