There's an interesting trick in the code Daryl added to Microchess:

If the branch is not taken, the 6502 will execute
so this is a compact way to skip over the branch-taken code without a second branch.

It might be a bit of a challenge to a disassembler, or some types of emulator.

That method has been around for a while. I first discovered it in the Laser 128 (Apple ][c clone) system monitor code. If you search way back - possibly back into the Delphi Forum - you might find a discussion on it. (My user ID on that board was "65c02nut")

By confusing the disassembler intentionally, it made reverse engineering a little harder - a crude form of copy guard!

Daryl

[Edit: Besides using BIT to skip 2 bytes, variations on this trick allow you to skip either 1 byte or 2, and to use instructions other than BIT. We land on this topic in a later thread. The variations can -- unlike BIT -- preserve the state of the flags in the cpu P register. Also, the subtle but serious problem of destructive reads, and some corrective measures, are explained.]


I guess nowadays maybe there's not much justification for these insane, byte-saving tricks, but I find them fascinating just the same. It seems like there's always another byte you can shave somewhere.

Speaking of which, Daryl's sequence might better begin:
I assume it's OK to bomb Carry. (And yes, even the NMOS '02 has a ROR A instruction.)


True enough. But it's the people I feel sorry for!

-- Jeff

Where there's an EPROM there's always need for some space saving tricks.

When I was writing language ROMs for the BBC Microcomputer I frequently ran out of space in 16K available and spent days going over listings looking for common code sequences to eliminate or text to compress.

The ROM for my BBC database package was a tight fit in 16K before Acorn asked us if we could create a multi-user version for ECONET (an RS-422 serial based network like AppleTalk).

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

You can even use the short form of BIT, i.e. BIT ZP, to skip over a single byte opcode like SEC or the like

This trick's been around for a while indeed :-)

André

Absolutely. CMP and BIT are both handy for this trick. (They consume bytes but don't alter X Y or A.)

One suggestion, though: Use BIT Immediate, not BIT ZPG. The latter will read from an address that might map to an IO device; with some IO devices a superfluous read can erroneously update their internal status flags. This is the so-called "destructive read" phenomenon. BIT Immediate is just as effective, and avoids the danger. It also happens to be 1 cycle faster. (The original code also risks a destructive read. In that case no Immediate alternative exists -- two bytes needed to be skipped over, but 6502 Immediate operands are single byte only.) (A 65c816, however... )


My latest version is two bytes shorter than the original!! Do I need to get a life?

-- Jeff

The BIT technique was used in Applesoft BASIC (1978), so it's practically as old as the 6502 itself.

...and I see now that you mention it in your opcode reference pages

You're absolutely right. Only the NMOS 6502 only has BIT ZP and BIT ABS, but no BIT IMM. You'd have to check whether you hit an I/O address that's endangered by a destructive read, although that is something very often overlooked.

On a side note: that's why I like the 6522 over the 6526 - the 6526 has a destructive read interrupt register, while with the 6522 you have to explicitly write to acknowledge an interrupt (if memory serves me right)

André

Better check that. [Doubletake... OK:] Bits in the Interrupt Flag Register can be explicitly cleared. But they also clear in response to reads of other reg's such as ORA, ORB, the shift reg and the timers. So the 6522 is vulnerable to superfluous reads. In any case, it's best to avoid superfluous reads if you can. Problems may be rare, but they can be time bombs, and I'm guessing they can be pure hell to identify when they do occur.
So CMP has more utility than BIT (when using these tricks on the NMOS '02)? I didn't realize that; it was an idle remark when I mentioned CMP. Thanks for the comment.

-- Jeff

If you look at the IFR (interrupt flag register) figure in the 6522 data sheets, you see that every one of the interrupt flags can be cleared by reading something related. For example, T1 counter roll-over interrupt flag can be cleared merely by reading T1CL (the low byte of the Timer-1 counter). This shortens the ISR code partly because it's often something you'll have to read anyway to service the interrupt, so why not have it clear the flag. It does present a problem however with reading that byte for a random-number generator if you're keeping time with T1 interrupts.

Just as the 6502 automatically sets flags whenever you change the accumulator, so too do I prefer destructive reads of interrupt pending flags. Manually clearing those bits are nothing but a nuisance.

The reason my Kestrel-2 emulator's chipset doesn't automatically clear interrupt pending bits is because I asked myself how things would be different if they didn't auto-clear. Also, the CPU could write into the register to artificially create an interrupt condition (why would you want to do this? I dunno -- but the Agnus' interrupt pending bits work the same way. I figured I could learn something by emulating how the Agnus worked). It turns out I never used the feature, and manually clearing the bits only made the ISR that much more inconvenient to write.

This is an ancient programming technique that has been around as long as the 6502. A similar method for a single byte jump would be:



If executed from the CLC instruction, the MPU will see:



You should consider that using the BIT opcode as illustrated in Daryl's code opens the door to a potential booby-trap. Depending on the value being loaded into the accumulator at POUT25, the BIT operation could inadvertently touch a chip register, with undefined results. For example, suppose the code is:



What the MPU would see immediately before POUT25 would be BIT $D0A9. A lot of 6502 systems have their I/O in the $D000 block and often do not fully decode the address space. Depending on the I/O space address decoding, that BIT $D0A9 could be seen by hardware as BIT $D009. On my POC unit:



which means a BIT on that address causes a read operation on the DUART's channel B status register. No telling what might happen in such a case.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Now and again I use this chart as a nice visual reference for which CPUs have which instructions. (The chart doesn't cover the Rockwell and WDC versions of the 65C02, but there's a section near the end of the page discussing that.)

Ref: Neil Parker's "The 6502/65C02/65C816 Instruction Set Decoded" explains the instruction set encoding.

I did a bit more digging: looks like it's used something over a dozen times in the Microsoft BASIC of the day (see this table of 8 versions from 1977 on) - so that includes Applesoft BASIC 1.1 (commented disassembly) - but as far as I can see Woz didn't use it in his unrelated 4k 1.0 version.