03670: Many sets in toaplan2.c: Graphic corruption when using -autosave/save state

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03670	Save/Restore	Minor	Always	Jan 17, 2010, 15:04	Mar 9, 2011, 17:14

Tester	fallicanet	View Status	Public	Platform	MAMEUI
Assigned To	AWJ	Resolution	Fixed	OS	Windows XP (32-bit)
Status [?]	Resolved			Driver	toaplan/toaplan2.cpp
Version	0.136	Fixed in Version	0.141u4	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	03670: Many sets in toaplan2.c: Graphic corruption when using -autosave/save state
Description	Bad graphics after save state on title screen
Steps To Reproduce
Additional Information	bakraidu, batrid and clones seem effected. Others in the driver might also suffer.
Github Commit

Flags
Regression Version
Affected Sets / Systems	Many sets in toaplan2.c

Attached Files	0001.png (30,139 bytes) Jan 18, 2010, 18:59
Attached Files	batrid - savestate.zip (690,481 bytes) Aug 20, 2010, 08:49

No.06574 Haze Senior Tester Aug 20, 2010, 12:53 edited on: Aug 20, 2010, 12:54	it doesn't restore the dynamic text characters properly, which is odd because I thought the core took care of that. This code has remained relatively untouched by my VDP changes, because it's external to the VDP.
No.07200 AWJ Developer Feb 15, 2011, 13:22	I've figured out what's (probably) going on with Batrider and Bakraid. At power up, the text layer tile RAM is mapped into the 68K address space at 200000-207FFF. After the game copies the tile data to there from ROM, it does a write to 500080. I'm pretty sure what this write does is permanently bankswitch the tile RAM out of the 68K's address space. After this write, 200000-2033FF becomes the palette RAM and the nametables, etc., for the text layer, and 203400-207FFF becomes just normal work RAM. MAME handles the first part of the tile RAM from 20000-2033FF via the function batrider_textdata_decode, which memcpy()s the correct data into the tile RAM, but it wrongly has the tile RAM from 203400-207FFF mapped in all the time and just doesn't mark the tiles dirty when the game writes there (compare toaplan2_tx_gfxram16_w to raizing_tx_gfxram16_w) Normally everything is fine despite the bogus mapping because the tiles are never marked dirty, but when you restore a save state, MAME restores the latter half of the text tiles from the current contents of 203400-207FFF, which of course is the wrong data. Because the current MAME address map is correct 99.99% of the time, and because I have insufficient information for a 100% hardware accurate implementation (is the bankswitching reversible? does the value written to 500080 matter?) I'm going to keep the current approach of memcpy()ing the tile data to where it belongs and just add a comment explaining what's really going on, rather than monkeying around with dynamic address mapping.
No.07203 AWJ Developer Feb 15, 2011, 16:22	On further analysis, I'm starting to wonder if the RAM text layer and palettes in these two games are actually written to via DMA and shouldn't be directly mapped into the 68K address space at all? On the other toaplan2.c games the palette RAM, and the text layer RAM if present, are off on their own in the 68K address map, but in batrider/bbakraid they're right in the middle of main RAM. Additionally, these two games do a write to 500082 every vblank, which doesn't correspond to anything any of the other games does. 500080 = trigger DMA from main RAM to text pattern table RAM? 500082 = trigger DMA from main RAM to palette and text nametable RAM? Also, the POST screen in Battle Garegga lists "main RAM", "text RAM" and "color RAM" as individual test items, but the POST screen in Batrider and Battle Bakraid only lists "main RAM"... further implying that the text RAM and color RAM aren't directly accessible by the CPU in those games. Maybe someone with a PCB can chime in...