6502.org

I'm working on some A8 (atari 8 bit) related hardware, and in the process of this I'm using an Atarimax multicart, this device if you've never met it is a cartridge that goes in your A8 and gives a menu of games. Unfortunately it's not open source (or at least, if it is, I've not found any source code) so I've had to reverse engineer it.

The loader has a couple of weird things in it that I really don't know why they would be done like that - forgive me because I'm primarily a Z80 person, so I may just be missing some tricks that experienced 6502 developers know about, but even so I can't see much of a reason why some things have been done in a certain way.

For instance, this code snippet:
Why the bne then beq? Surely a jmp would save a byte and do the same thing? I can't see how this branch would never be taken. Note that no code branches or jumps to 0142, the only branch to goto_main: is the one at 013b.

Then there's this code snippet:
Why would you use the 3-byte instruction sta $000c instead of the 2 byte zero page instruction sta $0c (not just at $014b, but all the loads/stores in that snippet are using 3 byte instructions to store in the zero page rather than the 2 byte instruction).
The only reason I can think of is to either to provide padding (unlikely, the whole routine lives in stack space, so you'd think compactness would be important to allow more stack space) and I don't think any of this is timing sensitive. The only plausible reason I can come up with is that when this routine is written out from the first 8k page of the cartridge, the addresses could be modified to be anywhere in address space, but in this instance this still doesn't make sense because DOSINI and BOOT can't be anywhere in memory (because the OS ROM will use these).

A belated welcome!

My first thought is that this is just some inefficiency, rather than something clever. Although the code may be running on a very limited machine, once it fits the space and runs fast enough, there's no reason to optimise it further.

So, the bne+beq looks to me like a tactic which avoids needing an absolute address for the destination. It just so happens this gadget is reached by a beq. It could be that earlier versions of the code did otherwise, or that this is a standard gadget maybe even inserted by macro.

Similarly for the absolute addresses - possibly, or probably, just a case of using a suboptimal addressing mode, perhaps because a macro is in use. Just possibly using an absolute address helps with portability somehow, or code relocation, or even as a remote possibility works with some clever hardware which is responsive to the 6502 bus activity.

So, my guess is that there's nothing that's very clever that's being missed. But I'd be happy to be shown to be wrong!

I was thinking the same as BigEd. Possibly the original source was C and the C optimizations were not very efficient or disabled.

Daryl

My thought for the first (the beq/bne) is that there might be another destination that is sometimes used during development (depending on the state of the Z flag). For the release version they change it so both paths go to the same place.

For the second, many 8 bit assemblers would do that if the operand is a label defined after that line in the source code. On the first pass, the assembler doesn't know where DOSINI is, and makes the safe assumption that it could be anywhere in memory. Changing that decision on the second pass would change the address of every later instruction, breaking JMPs and JSRs and anything else that depends on their locations. So they stick with the less efficient 16 bit address. If the programmer wanted page zero, they had the opportunity to say so before that point.

Yes, I've seen that many times as well.

Daryl