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
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
 
Relationships
There are no relationship linked to this issue.
Notes
5
User avatar
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.
User avatar
No.00806
Tafoid
Administrator
Apr 25, 2008, 12:23
Acknowledged. Left open for discussion
User avatar
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.
User avatar
No.00900
Robbbert
Senior Tester
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?
User avatar
No.01050
Robbbert
Senior Tester
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.