Wrong error message and possibly wrong error checking

[cbeust]

I am seeing the following report:

In text:

GOT $02 AT $00FF OF MAIN MEM (WANT $06)
AFTER SEQUENCE
- LDA #$06
- STA $C005
- STA $C001

Here is the test data:

    ;; Test 6: write to aux
    lda #6
    sta SET_RAMWRT
    sta SET_80STORE
    jsr .check
    !byte .C_skip, 2, 1, 2, 1, 3, 2, 3, 2

Here are the two issues:

1: The error message is wrong

There is no wanted value "6", the actual wanted value is "2". Maybe the error reporting routine is using the test number here instead of the desired value?

2: The test checking might be wrong

Since we're looking at main memory location $00FF, the very first value of the array is what we are expecting: 2.

Which is what my emulator seems to be returning (and my Rust tests, which are a direct port of yours confirm that I am returning 2).

It looks like the test is not just displaying that it wants value 6, but it might actually be testing against 6...

[zellyn]

Quoting from the slack thread (link) for posterity:

Here’s the relevant section of code: https://github.com/zellyn/a2audit/blob/36212fb8df75c08e184b1cc12f82e8ed436d379a/audit/audit.lst#L1085-L1111

I don’t really see any chance for the actual and desired bytes to get mixed up. Is it possible that RESETALL isn’t working properly, and the routine is reading wanted data from somewhere weird? The actual value ($02) is actually correct for that test…

Thread continues…

[cbeust]

Ok I finally figured it out, and of course, the bug was in my emulator.

The bug: I was not honoring turning off WRITE_AUX_MEM if STORE80 was on.

The consequences of that bug were dire and really hard to track.

The short of the story is that it messed up how RESETALL works. That function starts by disabling READ_AUX_MEM and WRITE_AUX_MEM, and then it saves A and X in $300 and $301. Because my routine was buggy and RESETALL is sometimes called with STORE80 ON, I ignored the reset of WRITE_AUX_MEM, which means that when the routine starts and saves A and X in $300 and $301, it does so in... AUX MEM! And obviously, when it tries to restore these, it reads them from MAIN MEM, which contains garbage values.

I cannot overstate how tricky that was to track because this bug only manifested itself way, way later.

Closing this now, and I think I'm going to have a Bourbon.

Thank you @zellyn for the incredible test suite!