Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|07647||Debugger||Minor||Always||May 8, 2020, 11:21||May 13, 2020, 07:54|
|Tester||d18c7db||View Status||Public||Platform||MAME (Official Binary)|
|Assigned To||Resolution||Open||OS||Windows 10 (64-bit)|
|Version||0.220||Fixed in Version||Build||64-bit|
|Summary||07647: indytemp: Debugger load command loads incorrect saved data in indytemp|
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.|
|Affected Sets / Systems||indytemp|
|There are no relationship linked to this issue.|
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).
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.|
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?