01751: memory.c: Won't execute code under the control of a read handler

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
01751	Core	Minor	Always	Apr 25, 2008, 04:27	May 22, 2008, 13:57

Tester	Robbbert	View Status	Public	Platform	Other
Assigned To		Resolution	Won't fix	OS	Windows XP/Vista 32-bit
Status [?]	Closed			Driver
Version	0.124u4	Fixed in Version		Build	Other
		Fixed in Git Commit		Github Pull Request #

Summary	01751: memory.c: Won't execute code under the control of a read handler
Description	The problem was noticed while doing development in MESS. Unlike arcade games, where code is relatively ordered, computer users can attempt to execute code in any ram - even if it's "assigned" to the screen or to programmable characters. These areas are normally under the control of read/write handlers. On a real computer, there is no issue - the code runs as you would expect. In MESS, the game will usually freeze instead, or perhaps reboot the computer. Testing with a debug build showed some alarming results. Firstly, a memory view shows all the bytes correctly. But a disassembler view just shows all FF in the read-handler area. The CPU does something completely random, but not what is in either view (I haven't determined what it's doing, yet). Each step of the CPU produces a log message "warning - op-code execute on mapped I/O". What I'd like to know: 1. Is this behaviour a bug, or by design? 2. If it's by design, what would you suggest to get around the problem? 3. If it's a bug, is it something that can (and will) be fixed?
Steps To Reproduce	Although the issue was first noticed on "mbeeic", it's is much easier to test with "super80v", as the super80 is much more suited to bug testing. 1. Get (and install) the latest svn of MESS (or 0.124 should do), and any required files. 2. At the command prompt, enter >mess super80v 3. If you enter H F700, you will see that the last 3 lines are zeroes and can be used for this testing. This is part of the screen memory, normally unused. 4. Enter E F7E0, this bring up a prompt for entering bytes into RAM. 5. Type in 3E 45 C3 10 C0. (make sure the period is entered) 6. Enter G F7E0 (this executes the little program you just wrote) 7. If it works, you should get the letter E printed on the screen, and return to the prompt. 8. But, nothing gets printed, and the computer may hang. To show what the code should do, enter it at location 0000 instead, and enter G 0.
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	memory.c

Attached Files

No.00802 Haze Senior Tester Apr 25, 2008, 06:38	This has always been the case, you can't execute code on read handlers. AFAIK it's to do with the way the system has been designed, and yes, there are cases where it's really quite annoying.
No.00806 Tafoid Administrator Apr 25, 2008, 12:23	Acknowledged. Left open for discussion
No.00809 aaron Developer Apr 25, 2008, 17:50	This is a performance optimization that has been in MAME forever. It is not going to change; however, there are some paths around it: 1. You can install an opbase_handler, which lets you control where MAME accesses memory to directly fetch opcodes. See missile.c for an example. 2. Some of the older CPU cores could be modified to fetch their opcodes by calling the read handlers instead of directly accessing opcodes. However, this does not work for encrypted opcodes, so some mechanism would need to be added to support that.
No.00900 Robbbert Moderator May 7, 2008, 06:14	Finally discovered this precise problem on the Mamedev wiki. Unfortunately the examples of using opbase_handler don't really help. What does the handler return? The code or the address? Or what is the difference between returning ~0 and address? It's good that the wiki has information, but its like talking to those who already know. To give a better question, let's say that a read handler lives at 4000-5FFF, and now we want to replace it with an opbase_handler. What do I do?
No.01050 Robbbert Moderator May 22, 2008, 13:57	Worked out enough to get me by. Tafoid you may as well close this. It's not serving any purpose.