floooh
ZX Memory writes - Z80 or ZX implementation?
Hey! I've not figured out yet whether it's the implementation or the Z80 "chip" but I noticed an issue on my emulator (that's structurally based on the examples provided) that ALSO replicates on your ZX example too.
When you run certain commands from BASIC (my emulator covers the 48 and 128k models), there is an attempt to write to ROM - specifically to address 0.
When having a look at other emulators (including my own, before I swapped out the Z80), this doesn't seem to be the case.
It also appears that it's things that would ordinarily invoke a ULA port write, too.
As far as replication goes:
- Put some debug/trapping code around the bit that writes to memory in zx.h
- Go into BASIC and try any of these:
BEEP 1,1
BORDER 5
The values don't matter, but the outcome is the same - perhaps 10+ or so attempted writes to address 0.
Hmm yeah, I can see that too in the memory heatmap in my ZX emulator, the 'green' are write accesses to addresses 0..4 (so the first 5 bytes)
The write is coming out of an LD (DE),A instruction at address 0x33E0 in the ZX48K ROM:
33E0 LD (DE),A
33E1 LD A,05H
33E3 SUB C
33E4 INC HL
33E5 INC DE
...which at least looks like regular code, not data or garbage...
...looking at a rom listing it seems to be this code:
https://github.com/reclaimed/prettybasic/blob/master/doc/ZX%20Spectrum%2048K%20ROM%20Original%20Disassembly.asm#L16981-L16986
...so the CPU emulator seems to do the right thing... the question is just why DE is zero at this point...
PS: how did I arrive there:
- set a conditional breakpoint here at the memory write with the condition
addr == 0: https://github.com/floooh/chips/blob/0a879d60d2d4ced9c24863e53a482e6925101428/systems/zx.h#L446, this makes the emulator very slow though..., so only enable the breakpoint right when hitting enter after the BASIC command - when the breakpoint hits, continue stepping until you're back in the CPU emulator, and this is in the
LD (DE),Asomewhere around here: https://github.com/floooh/chips/blob/0a879d60d2d4ced9c24863e53a482e6925101428/chips/z80.h#L1629 - ...at this point check the PC (it's 0x33E1, one beyond the instruction start)...
- then in the disassembler check the instructions at 0x33E0 (which is indeed
LD (DE),A
Yeah I did some crude debugging too, to see WHERE (as far as the PC goes) the value of DE was set to 0 immediately before the memory write.
Whether it's helpful or not, these are the last two places that set DE to 0 right before the attempted write. Both BORDER set, as well as a BEEP give the same two things:
0x33B2 - POP DE (https://skoolkid.github.io/rom/asm/33A9.html)
0x33CD - EXX (https://skoolkid.github.io/rom/asm/33C6.html)
The first one might be entirely unrelated, but included just in case. The latter one has some (maybe) useful info - DE is supposed to be the STKEND pointer.
@floooh Still trying to work this one out :-/
- The address at 0x33FB appears to be where DE is first set to 0x0000
- it calls routine at 0x33c8 but we never actually return from here before the ROM write occurs.
Currently I have a breakpoint set up at 0x33FB and the issue occurs maybe within about 20-30 instructions. My (unfounded) hunch is that it's stack related.
Testing in 48k mode, with BORDER 5 command in basic.
Ref 1: https://skoolkid.github.io/rom/asm/33F7.html Ref 2: https://skoolkid.github.io/rom/asm/33C6.html#33C8
hmmff....Maybe it's a non-issue...I downloaded FUSE and tried the same thing with the same breakpoint. Result: an apparent ROM write attempt, same instruction. I guess now I'd just be curious to know why the other emulators DON'T seem to have this issue :-p