search

SilverlineDev / bizhawk

Automatically exported from code.google.com/p/bizhawk
0 stars 0 forks source link

When executing code in SNES Open Bus, tracelog will display all instructions as "brk #$00" #402

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Open Super Mario World
2. Pause
3. Load the attached savestate
5. Open tracelogger, set to log to file
4. Frame advance a single frame
5. Open the generated log file, and CTRL-F "014a13"

What is the expected output? What do you see instead?

The following two lines should appear in the trace file. They are the ones that 
the emulator (correctly) executes.
014a13 ora ($01,x)
014a15 jsr ($FCFC,x)

However the following appears instead:
014a13 brk #$00
014a15 brk #$00

What version of the product are you using? On what operating system?
Version 1.9.1 on windows

Please provide any additional information below.

The cause seems to be that the emulator is capable of *executing* instructions 
in open bus, but not *logging* them after the fact - it thinks it just executed 
the instruction 00 00. Registers and so on still update properly in the log, 
only the instruction itself does not.

Original issue reported on code.google.com by matthew....@gmail.com on 28 Feb 2015 at 4:27

Attachments:

GoogleCodeExporter commented 9 years ago 
Sorry, this can't be solved. Lsnes isn't/won't be supporting it either for 
similar reasons.

The address being read from is in the MMIO range. Bsnes has a design 
shortcoming which renders it incapable of distinguishing real (destructive) 
reads from debugger reads. Therefore the entire MMIO range is crudely blocked 
off from debugger access to prevent debugging tools from changing the emulation 
state. The effect of this is 0x00 getting read.

To make matters worse, there is another problem. Even without the above 
problem, handling fetches from open bus requires simulation of the MDR register 
since it will change after each fetch. The pattern of fetches is interleaved 
oddly with the pattern of data accesses, depending on the vagaries of 
particular instructions. In effect, the instruction needs to be executed 
completely in order to know what happens to MDR.

Fixing this, if it's even possible, requires major renovations to bsnes 
internals which are not likely ever to happen.

Original comment by zero...@zeromus.org on 6 Mar 2015 at 12:57

GoogleCodeExporter commented 9 years ago

Original comment by zero...@zeromus.org on 6 Mar 2015 at 12:58

GoogleCodeExporter commented 9 years ago 
Fair enough. I guess I was thinking of the tracelogger as working in an 
altogether simpler manner, with the emulator core somehow remembering and 
reporting its most recent instruction.

Original comment by matthew....@gmail.com on 6 Mar 2015 at 4:03