Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
07647 Debugger Minor Always May 8, 2020, 11:21 27 days ago
Tester d18c7db View Status Public Platform MAME (Official Binary)
Assigned To Resolution Open OS Windows 10 (64-bit)
Status [?] Acknowledged Driver atarisy1.cpp
Version 0.220 Fixed in Version Build 64-bit
Fixed in Git Commit Github Pull Request #
Summary 07647: indytemp: Debugger load command loads incorrect saved data in indytemp
Description This seems to be specific to indytemp, as I use the save/load commands often in other games and it works fine.
The data loaded doesn't match the data saved resulting in corrupt memory region.
Steps To Reproduce 1) run mame -debug indytemp
2) open a memory window at address A02000
3) let game run for 24 seconds (until lots of data appears in memory window)
4) pause game with F8
5) save testmem,A00000,4000
6) load testmem,A00000

Watch the memory window when data is loaded, the memory window contents change, the data loaded doesn't match the data saved.
Continuing stepping the game with F8, all the sprites are now bunched up in lower feft corner of screen as they have lost their position info due to corrupt memory data.
Additional Information On further inspection, this is limited to sprite memory region A02000-A02FFF. As a test case, if you have a large binary file say 64KB filled with FF, and execute "load file,A00000", then region A00000-A01FFF is loaded with "FFFF" words as expected, region A02000-A02FFF is loaded with "00FF" words (wrong!) and region A03000-A03FFF is loaded with "FFFF" as expected. The save command appears to behave correctly, it's only during load that the data goes missing.
Github Commit
Regression Version
Affected Sets / Systems indytemp
Attached Files
There are no relationship linked to this issue.
User avatar
May 8, 2020, 17:13
I have not attempted to reproduce this bug yet, but it looks as if it would affect all machines in atarisy1.cpp.

The debug load command works by writing back the saved data byte by byte through write handlers, so those on buses wider than 8 bits may need to implement data masking to prevent one byte from canceling out another. The sprite RAM write handler in this driver actually does mask the data written in the ordinary way, but then stores the unmasked data instead for some reason (which may or may not be a good one).
User avatar
May 12, 2020, 20:36
Further examination of the schematics suggests that the standard write masking is NOT performed here. On both the TTL and LSI versions of the System 1 mainboard, the video RAM decode circuit actually ignores UDS, using LDS only, and the chip select and write enable signals are tied together for all four nibbles of each video RAM bank.
User avatar
May 13, 2020, 07:54
edited on: May 13, 2020, 07:54
I don't see how /CS and /WE are tied together, on both SP-277 and SP-286 sheet 8/8A, the /WE is just inverted VRAMWR whereas the /CS comes from control signals VRAC1, VRAC0. If you treat those two signals combined as a 2 bit counter, then in phase 0, memory region A00000-A01FFF is selected, in phase 1 and 2 memory region A02000-A03FFF is selected and in phase 3 (CPU access phase) the memory region selected depends on CPU address line A13.

The video RAM is written when VRAMWR and control signal VRAC2 are both high, the resulting signal is inverted to generate /WR for the RAMs. VRAMWR is generated from /VRDTACK and /WL only. /WL is just a logical OR of R/W and /LDS so you're correct that video RAMs get written only when /LDS is asserted.

This implies that a byte write with only /UDS asserted can NOT write to video RAM, therefore video RAMs can only be written _correctly_ in word mode. Writing in byte mode will overwrite the high byte of the RAMs. This applies to the whole video RAM range A00000-A03FFF so as per my additional notes, from the debugger I can correctly load memory regions A00000-A01FFF and A03000-A03FFF, but region A02000-A02FFF is loaded incorrectly. I'm guessing the debugger accesses A02000-A02FFF in byte mode and the others in word mode? Perhaps the debugger should access all video RAM in word mode?
User avatar
27 days ago
Can someone pretty please take a look-see at this, seems like it would be an easy fix knowing all we know now about byte vs word write access to the memory region. Even if there is debate about the schematic, the debugger itself should be abstracted from the game function and should be able to *correctly* load the data it just saved a second ago back to the same memory region :)