Closed BigEd closed 7 years ago
It is actually exposed by the hardware as a 16 bit value: https://github.com/hoglet67/AtomBusMon/blob/master/src/T6502/T65.vhd#L209 and https://github.com/hoglet67/AtomBusMon/blob/master/src/AlanD/R65Cx2.vhd#L1522
I'm not sure why in the T65 core S is 16-bits; possibly because the core also claims some degree of 65C816 compatibility.
I stuck with 16 bits so the value displayed to the user is actually the memory address being pointed at.
Dave
Ah, right, the '816 - support for which in T65 is very slight, AFAICT, but the intention is there.
(In the stardot thread the value displayed is not a normal 6502 stack value, which would always be in page one. That seems odd. Perhaps the T65 masks the high byte when in '02 mode and it is essentially uninitialised.)
Ah, in that case this is a bug.... https://github.com/hoglet67/AtomBusMon/issues/2
I think the best solution is for the C code to force the upper 8 bits to 0x01, i.e. ignore what the hardware is telling it.
Sounds like a plan!
Untested - but it seems wrong to me and a simple fix. Unless I missed something.