07451: fb01: Test mode is not working due to an unmapped memory region

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
07451	Misc.	Minor	Always	Oct 13, 2019, 10:15	Apr 7, 2020, 22:47

Tester	cmonkey	View Status	Public	Platform	SDLMAME
Assigned To	AJR	Resolution	Fixed	OS	MacOS X
Status [?]	Resolved			Driver	yamaha/fb01.cpp
Version	0.214	Fixed in Version	0.220	Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	07451: fb01: Test mode is not working due to an unmapped memory region
Description	At boot FB-01 checks for the System Setup + Inst. Select + Data Entry -1/No buttons being pressed and jumps to test mode code @ $32df if they are. Test mode code sets the stack to $ffd0 and uses the 48 bytes from $ffd0 to $ffff as scratch ram. Currently the only mapped RAM region in the fb01 driver is $8000-$bfff, which is realised on hardware by the 2x8Kb SRAMs. After a bit of head scratching as to what test mode was using for its RAM I've come to the conclusion that it must be using 64 bytes of the 80 bytes of DDRAM in the HD44780 as stack/scratch ram (16 bytes stack/48 bytes scratch). The other 16 bytes are used for the LCD display. The HD44870 manual clearly states, on p.10 'the area in display data RAM (DDRAM) that is not used for display can be used as general data RAM.' It's possible to get test mode running perfectly in the current driver by editing all instructions that target $FFxx addresses above $32d7 in the rom and changing them to $BFxx (64 addresses in total need changing) to remap them into the currently mapped 16Kb SRAM region. I've attached a bsdiff patch which will do this, so you can see how test mode should look, if you don't have access to a physical FB-01. I'm not sure whether, when the fb01 driver was originally written, test mode was ever planned to be implemented or not, and as such you may decide that this is really a BTNAB, if it wasn't, as a non-functional test mode doesn't affect how the rest of the emulated machine works. Also, I wasn't sure what category to choose for this report so if you feel 'Misc' is incorrect then please feel free to change it to something more appropriate. As ever, many thanks to all the MAME devs for their continued hard work and support on MAME.
Steps To Reproduce	Hold down the keys that are mapped to the 'System Setup', 'Inst. Select' and 'Data Entry -1/No' buttons and reset the machine. This will cause a jump to test mode code at $32df but upon return from the first subroutine call code execution will resume at $0000 due to the fact that the first CALL instruction will attempt to place its return address onto a non-mapped stack so the RET instruction will pop $0000 of the (non-existent) stack into the PC and resume from there.
Additional Information	bsdiff patch to remap all $FFxx address references in test mode to $BFxx, to allow test mode to run successfully in current driver SHA1 of original nec__-011_xb712c0__8709ex700__d27c256c-15.ic11 = 049c482d6c91b7e2846757dd0f5138e0d8b687f0 SHA1 of bsdiff patch = f070db69fbb71955278dfb2eda7d41c264824dca SHA1 of patched nec__-011_xb712c0__8709ex700__d27c256c-15.ic11 = 9e849c04167e53352a9635712d95dcc5ea34ad2f
Github Commit

Flags
Regression Version
Affected Sets / Systems	fb01

Attached Files	fb01_test_mode_patch.bsdiff.zip (404 bytes) Oct 13, 2019, 10:15 Uploaded by cmonkey

No.17079 hap Developer Oct 13, 2019, 11:23	Instead of modifying the rom data, does it also work if you change this line? map(0x8000, 0xbfff).ram().share("nvram"); // 2 * 8KB S-RAM to: map(0x8000, 0xbfff).mirror(0x4000).ram().share("nvram"); // 2 * 8KB S-RAM
No.17081 cmonkey Tester Oct 13, 2019, 13:07	I've just done a clean, single driver only build (fb01) of 0.214 using the above alteration to the memory map and can confirm that test mode works fine with an unmodified rom using this approach. This is seemingly not how the original hardware handles ram in test mode but as long as it works, that's the main thing. The OPP TIMER CHECK section of test mode gives a 'TIMER ERROR!!' message when invoked on the emulated machine, whereas on real hardware it gives a 'TIMER OK !!' message. It does this whether using the modified rom or unmodified rom with altered memory map. This test is related to the checking of timers A and B on the YM2164. I'll dig into the test code further to see why it's failing the timer check but it's very likely to be because the real hardware uses a YM2164 and the emulate machine is using a YM2151. The resolution of timer B in the YM2164 is twice that of the YM2151 (this is detailed on the YM2164 Wikipedia page: https://en.wikipedia.org/wiki/Yamaha_YM2164) YM2151 timer B resolution is calculated as :- timer_B_time[i] = clocks_to_attotime(1024 * (256 - i)); YM2164 timer B resolution would be (if there were a YM2164 device in MAME) :- timer_B_time[i] = clocks_to_attotime(2048 * (256 - i)); Many thanks for the quick response to my original report.
No.17082 cmonkey Tester Oct 13, 2019, 13:39	As I suspected, the timer check in test mode is failing due to the differing resolution of timer B in the YM2164 vs the YM2151. The timer check code loads timer A with a value of 899, giving a period of 2ms (64 * (1024-899) / 4000) and timer B with a value of 216, giving a period of 20.48ms (2048 * (256 - 216) / 4000). It then starts both timers and increments a counter each time timer A expires. When timer B expires it expects the counter to hold a value of 10 (for 10 expirations of timer A) but, due to the shorter period of timer B in the emulated YM2151, it only holds a value of 5. This can be corrected by changing the instruction at $3600 from CP 10 to CP 5. Doing so will show the 'TIMER OK !!' message when the test concludes. Would it be possible to fix this purely in the fb01 driver or will it need a new emulated YM2164 device?
No.17083 hap Developer Oct 13, 2019, 14:35	I think the address mirror change is correct. It's not a special hardware trick or anything, it's simply caused by incomplete address decoding. It's impossible that the LCD chip internal RAM is at $FFxx. As for YM2164, MAME would need to add this device to fix the timer problem.
No.17086 cmonkey Tester Oct 14, 2019, 00:15	I'm curious as to what makes you believe that it's impossible for the HD44780 DDRAM to be at $FFxx? I've studied the schematics carefully and, as far as I can see, A14 is only connected to the 32kb rom. It doesn't appear to be connected to either of the rams (or anything else for that matter), unless the schematics are incorrect. I've performed continuity testing on my FB-01 between A14 and every other pin on the board and the only connection I've found is to A14 on the rom. The 2 x 8kb rams are addressed by a combination of A13 and A15 into a couple of inverters and NOR gates. A lack of A14 into the RAMs would make it impossible for the CPU to address them in the $c000-$ffff range. I simply can't find any evidence anywhere on the schematics of A14 being used to address the RAMs, but am happy to be proved wrong if anyone else can find evidence. The LCD controller only has 11 connections to drive it, D0-D7 from the CPU and A0/A4/A5 to address it via I/O ports 30 and 31. From what I can tell it seems to read/write to/from the data bus of the CPU, irrespective of what address is on the address bus, as long as the correct combination of signals are put on I/O ports 30 and 31. What I don't understand is how it's internally mapping the 64 spare bytes of general purpose DDRAM back to $FFxx addresses which the CPU uses to read/write to/from. I'm beginning to think that the only way I'll really prove to myself that test mode is exclusively using the DDRAM of the LCD controller is by desoldering the rom and 2 x 8kb SRAMs and then installing a modified rom which has the IM1 vector hard-coded to $32ce (which is the address of the IM1 interrupt routine used by test mode). That way test mode code will only be accessing either the rom from $0000-$7fff or the RAM at $FFxx and if it runs as normal without the 2 x 8kb SRAMs in place it will prove, without doubt, that the LCD controller DDRAM must be being used.
No.17087 hap Developer Oct 14, 2019, 09:00	Regarding the LCD: "What I don't understand is how it's internally mapping the 64 spare bytes of general purpose DDRAM back to $FFxx addresses which the CPU uses to read/write to/from." That's because it doesn't. It is impossible with this type of LCD chip to map its internal RAM to a CPU address bus. "I've performed continuity testing on my FB-01 between A14 and every other pin on the board and the only connection I've found is to A14 on the rom. The 2 x 8kb rams are addressed by a combination of A13 and A15 into a couple of inverters and NOR gates. A lack of A14 into the RAMs would make it impossible for the CPU to address them in the $c000-$ffff range." It is how I imagined it: A14 unconnected to the RAMs. It means that when A15 is high, it will go to the RAM whether A14 is 0 or 1. like this: cpu writes to 1xy zzzzz zzzzzzzz A15 = high x = don't care y = select one of the two RAM chips z = RAM address pins
No.17538 cmonkey Tester Apr 7, 2020, 18:55	This ticket can be closed now, as far as I'm concerned, as the two issues that I raised it in respect of (unmapped memory region and broken timer check) have been fixed via commits from hap and ajrhacker. Test mode and OPP TIMER CHECK are now both working perfectly in 0.220. Many thanks for the fixes and apologies to hap for doubting your knowledge and experience.
No.17540 Robbbert Senior Tester Apr 7, 2020, 22:47	Resolving as requested by the OP. Fixes provided by hap and AJR.