Garry Kitchen talks about a BIT operation accessing an illegal address?

[Dionoid]

During last year's PRGE in 2017, David Crane and Gerry Kitchen hosted a panel talk.

 

At 27:43 Garry talks about how he was crunching code to get Keystone Kapers within 4K, and that he used a BIT instruction as fall-through to save an extra byte, which I think is a quite common technique to avoid using a branch and win a byte.

However, they found out that the BIT instruction was accessing an 'illegal address', which I assume is some sort of I/O zeropage address that will mess things up.
But I don't understand how reading an 'illegal address' can mess things up. And if it actually does crash your game: how can you detect it in your own code?

 

Is there someone who can explain this?

For those who aren't familiar with the 'Skip 2 bytes using BIT'-hack, it works like this:

     ;set background to white if score is 0. otherwise set background to black
     lda Score
     beq ScoreIsZero
     lda #$00         ; black
     .byte $2c        ; BIT absolute reads next 2 bytes as operand, so skipping the 'lda #$0f' and continues at the 'sta COLUBK'
.ScoreIsZero:
     lda #$0f         ; white
     sta COLUBK       ; set background color

Edited October 12, 2018 by Dionoid

[+SpiceWare]

Hmm, if he was crunching the code to get within 4K, that suggests the code he was working on was larger than 4K. Maybe the bit instruction accidentally accessed a bank switching hotspot.

[tokumaru]

I don't know all Atari 2600 registers off the top of my head, but in other platforms there certainly are memory-mapped registers that can cause problems if read at the wrong time.

 

On the NES for example, if you read the PPU status register at the exact time when vblank starts, you end up inhibiting the NMI that normally fires every frame. Also, reading from the PPU data register (used to read/write from/to VRAM, which's in a separate bus) during rendering will screw up the PPU address register, corrupting the display. I'm sure there are other examples, but these are the ones that just came to mind.

 

As for preventing that kind of problem, I guess there's nothing you can do but see what address the skipped instruction forms, and see if there's anything sensitive mapped to that address, not forgetting to take mirroring into account.

Edited October 12, 2018 by tokumaru

[Omegamatrix]

It is possible that there was unexpected dependency elsewhere in the code that the bit instruction changed the flags for (N V Z). If the register that was being BIT tested was undefined then it could turn into a nasty bug.

[JeremiahK]

Yeah, I'm pretty sure the problem was that the BIT operation effected the flags in a bad way.

 

By the way, ".byte 0c" is the correct way to do this. It's a NOP in absolute addressing mode, so it won't mess with any flags or anything else, except triggering a bankswitch, which it's also quite useful for. It's an illegal opcode, so I understand why they didn't know about it back then.

 

I like to use a macro for this:

    MAC SKIP_WORD
    .byte 0c
    ENDM

    MAC SKIP_BYTE
    .byte 82
    ENDM

Edit: After watching the video, it sounds like there may not have even been a problem. They had a machine that tested the code, and it was found that an "illegal address" was being accessed. Meaning that the bit was accessing an address outside of memory, which really just means it was accessing a "mirror". I don't see how this could actually cause a problem, as long as there is no bankswitching, which there wasn't, since the game being discussed, Keystone Kapers, was 4K. (Unless you somehow accidentally strobe a register in the TIA, which I don't think is possible with a BIT instruction.) I might be completely wrong, but I don't think there was actually a real problem with the code, the machine just gave a warning.

Edited October 13, 2018 by JeremiahK

[DEBRO]

Hi there,

 

It's been a while since I looked at my disassembly of Keystone Kapers. I don't remember anything strange other than knowing he was doing a NOP_W and translating it for distella appropriately.

 

Looking at it again, I can see one instruction would do a BIT instruction on $A9. I hadn't gotten to labeling that ZP location to know what it is.

 

Garry was careful to use LSR or ASL after these instructions as to not affect the value in the accumulator. Also, most times there was a compare instruction after as well.

 

The alert probably triggered on the BIT instruction on $04A9, $05A9, $91E6, $93E6, $A8F6, and $A0D6.

 

This the first time I had seen any tricks like this in an Activision game.