Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|01751||Core||Minor||Always||Apr 25, 2008, 04:27||May 22, 2008, 13:57|
|Assigned To||Resolution||Won't fix||OS||Windows XP/Vista 32-bit|
|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|
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.
|Affected Sets / Systems||memory.c|
|There are no relationship linked to this issue.|
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.|
Apr 25, 2008, 12:23
|Acknowledged. Left open for discussion|
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.
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?
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.