07647: indytemp: Debugger load command loads incorrect saved data in indytemp

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
07647	Debugger	Minor	Always	May 8, 2020, 11:21	Feb 1, 2021, 17:38

Tester	d18c7db	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows 10 (64-bit)
Status [?]	Acknowledged			Driver	atari/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

Flags
Regression Version
Affected Sets / Systems	indytemp

Attached Files

No.17618 AJR Developer 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).
No.17645 AJR Developer 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.
No.17647 d18c7db Tester 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?
No.18432 d18c7db Tester Feb 1, 2021, 17:38	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 :)