03373: looping: Unmapped I/O read/writes result in large error log and major performance drop

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03373	Misc.	Major	Have not tried	Aug 4, 2009, 02:29	Aug 9, 2009, 10:45

Tester	Luigi30	View Status	Public	Platform	MAME (Self-compiled)
Assigned To	robiza	Resolution	Fixed	OS	Windows XP/Vista/7 32-bit
Status [?]	Resolved			Driver	venture/looping.cpp
Version	0.133u1	Fixed in Version	0.133u2	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	03373: looping: Unmapped I/O read/writes result in large error log and major performance drop
Description	looping has a problem with unmapped I/O memory, causing it to generate hundreds of megabytes of errors every minute of operation. It also has major slowdown.
Steps To Reproduce
Additional Information	(no context): unmapped I/O memory byte write to 00000102 = 00 (no context): unmapped I/O memory byte write to 00000101 = 00 (no context): unmapped I/O memory byte write to 00000107 = 00 (no context): unmapped I/O memory byte write to 00000106 = 01 (no context): unmapped I/O memory byte read from 00000107 (no context): unmapped I/O memory byte read from 00000105 etc etc etc.
Github Commit

Flags
Regression Version	0.124u1
Affected Sets / Systems	looping

Attached Files

No.04772 hap Developer Aug 5, 2009, 17:33	fixed
No.04777 Tafoid Administrator Aug 7, 2009, 01:27	There has been some discussion on the list about this and bugs like this.. the method sent to give a landing place for the unmapped writes is a nice stop gap, but not really a fix. If such fixes are done in the future, it would be best to full comment that such NOP'ing of code is a temporary measure. There is some work being done on this particular driver right now to better address unmapped I/O issues. As a result, I'm assigning to Robiza (he was working on it some) and he'll decide where to go with it. In reality, you want all those messages coming out in a -LOG run. There are bound to be a many games or drivers which will have unknown writes and will fill up a log file quickly and slowing down emulation as a result. In the future, we will likely not be accepting bugs of this nature unless they directly result in a noticeable bug in the emulation. Lack of speed, by itself, is not a bug. If you use -LOG, you accept the fact that emulation might be beyond slow.
No.04779 Luigi30 Tester Aug 7, 2009, 03:10 edited on: Aug 7, 2009, 03:10	I had -log on in my mame.ini and didn't notice. It works fine without -log. It's been there so long I thought it was default behavior.
No.04780 robiza Developer Aug 7, 2009, 07:16	for the real solution i think it's necessary a redump info in the driver: To Do: - redump COP420 internal ROM ROM_REGION( 0x1000, "mcu", 0 ) /* COP420 microcontroller code */ ROM_LOAD( "cop.bin", 0x0000, 0x1000, BAD_DUMP CRC(bbfd26d5) SHA1(5f78b32b6e7c003841ef5b635084db2cdfebf0e1) ) // overdumped 4 times, and starting PC is not 0
No.04784 robiza Developer Aug 8, 2009, 08:00	a COP420 have only 0x400 bytes; maybe it's not a bad dump
No.04787 robiza Developer Aug 8, 2009, 22:52 edited on: Aug 8, 2009, 22:56	i think the dump is ok and the start PC is 0 yet the rom is 0xc2 bytes shifted ROM_LOAD( "cop.bin", 0x00c2, 0x033e, CRC(bbfd26d5) SHA1(5f78b32b6e7c003841ef5b635084db2cdfebf0e1) ) // overdumped 4 times, and starting PC is not 0 ROM_CONTINUE( 0x0000, 0x00c2) ROM_CONTINUE( 0x00c2, 0x033e) ROM_CONTINUE( 0x0000, 0x00c2) ROM_CONTINUE( 0x00c2, 0x033e) ROM_CONTINUE( 0x0000, 0x00c2) ROM_CONTINUE( 0x00c2, 0x033e) ROM_CONTINUE( 0x0000, 0x00c2)
No.04788 robiza Developer Aug 9, 2009, 06:51 edited on: Aug 9, 2009, 10:21	i think the bug is in the cop420 core with every opcodes we get a input/ouput access thanks to Curt: serial SIO port which is read/written on every cycle