Emulation for develping SW that works on real HW: FEATURE REQUEST

Page 1/5
| 2 | 3 | 4 | 5

By ARTRAG

Enlighted (6935)

ARTRAG's picture

06-06-2009, 11:28

Hi,
I would greatly appreciate if bluemsx or openmsx teams would consider the possibility to add a tool/feature able to spot the possible loss of I/O data to from the VRAM

It would be sufficent to spot the sections of code where the successive outs are spaced < that 26cycles!!

Please!!!
:-)

Login or register to post comments

By hap

Paragon (2042)

hap's picture

06-06-2009, 11:49

It should be possible with an openMSX TCL script. Mayhaps somebody with a bit of knowledge there can make you one. Smile

By ARTRAG

Enlighted (6935)

ARTRAG's picture

06-06-2009, 14:42

well
in the emulator you should only add a function that counts the cycles btween successive outs
it would be a great help in teh debugger to have a way to enlight these cases

By Manuel

Ascended (19468)

Manuel's picture

06-06-2009, 18:01

I think I would be able to make a script that checks if the time between two writes on I/O port 0x98 is smaller than a certain value and put the result in the console or a file. Would that help?
If so, I'll make an attempt to write such a script. You can help by precalculating the time Smile

By ARTRAG

Enlighted (6935)

ARTRAG's picture

06-06-2009, 18:11

Great! The time should be 26 cycles!

Hem... how do you return where the suspicious outs are?

The best would be to have automatic breakpoints in the debugger that trigger at the location of the out that incurs in the condition.
It should also be possible to disable these breakpoints individually in case of valid I/O (e.g. when in Vblank)
Tongue

By Manuel

Ascended (19468)

Manuel's picture

06-06-2009, 18:21

I'm going to make a small script, not going to change the debugger GUI. Consider it a proof of concept. 26 cycles is nice, but I need it in (micro)seconds Smile

When such an out occurs, I could simply print the current PC.

If you give me a sample program with some known 'bad outs', I can use it to test the implementation.
Please join #openMSX to continue this discussion more easily (e.g. via http://openmsx.sf.net/mibbit.php )

By ARTRAG

Enlighted (6935)

ARTRAG's picture

06-06-2009, 19:16

well, 26 cycles is 26/3579545 sec = 7.2635e-006sec = 7.2635e us (microsec)

By wouter_

Hero (525)

wouter_'s picture

06-06-2009, 22:37

This very simple script should get you started, you can tweak it till it matches exactly your needs. To use it, save it to some file e.g. vdp-timing.tcl and then in the openMSX console type

source vdp-timing.tcl
set last_vdp_time 0

proc vdp_io_write {} {
        global last_vdp_time
        set now [machine_info time]
        set min_diff [expr 26.0 / 3579545]
        if {($now - $last_vdp_time) < $min_diff} {
                # tweak this line to generate the logging you like
                puts stderr "Too fast VDP access detected (pc = [reg pc])"
                # uncomment this line if you want to break at this point
                # debug break
        }
        set last_vdp_time $now
}

debug set_watchpoint write_io 0x98 true vdp_io_write

Manuel is still working on a more extended script. For example to ignore timing problems when screen is disabled, or to only log an error once for the same instruction.

By Manuel

Ascended (19468)

Manuel's picture

06-06-2009, 22:44

I've already finished it in the mean time. It has the code wouter pasted as core, but some more luxury around it Smile

Let me know if you want it, or if you want it posted here. (I already sent it by mail to ARTRAG.)

By ARTRAG

Enlighted (6935)

ARTRAG's picture

07-06-2009, 00:09

manuel, your script ROCKS!!!
I haven't jet tested the new DDA code after the patches, but without your script it would have been a pain find all the criticalities !
THANKS!!

By ARTRAG

Enlighted (6935)

ARTRAG's picture

07-06-2009, 10:38

PS
manuel, you should pubblish this script, it helps a lot the msx1 developers

Page 1/5
| 2 | 3 | 4 | 5