Machine-exact emulation (primarily of G7000)?

[Sdw]

I ma trying to develop my first game for G7000, and while I have a G7000+flashcart, testing everything on that is way too much wear on the connectors (pulling out cart, reprogramming, inserting etc.) hundreds of times, so I try to develop using o2em120b5win for most of my testing and then a few times per day testing on real hardware.

I use the emulator with the -euro switch to get timing and behavoir to emulate my G7000.

Unfortunately I have noticed that the emulation and real hardware differs quite a lot, to the point where it's almost impossible to predict if something will work on real hardware or not even if it works in the emulator.
For example, one time I had forgot to disable the VDC while putting in new data in registers, worked fine in emulator but of course crashed on real hardware.
I have also noticed that o2em seems to continue drawing sprites in the emulator even if you disable them in the VDC - on real hardware the display stops when you disable them etc.
Right now I have run into some really weird timing bug.
The following piece of code

Code:

mov r0,#vdc_color
mov a,#col_bck_green
movx @r0,a

mov r0,#vdc_control
mov a,#002h
movx @r0,a

mov r0,#vdc_color
mov a,#col_bck_red
movx @r0,a

In o2em I get a green area that is perhaps 15 rasterlines high?!
On real hardware, I get the expected behavior, with a short green (maybe half a rasterline) and then the red starts.

Is there any other emulator I could try with more cycle accurate 8245 emulation?

-edit- Oh, and I'm well aware of that the problem is that I probably make mistakes and program stuff the "wrong" way, but having the emulator actually emulate what happens when you do things wrong is a very nice feature!

[manopac]

Unfortunately I have noticed that the emulation and real hardware differs quite a lot, to the point where it's almost impossible to predict if something will work on real hardware or not even if it works in the emulator.

unfortunately you are right ... I started fixing things in O2EM once I started writing programs, cause I was not happy with some of the features (and some of the bugs)

For example, one time I had forgot to disable the VDC while putting in new data in registers, worked fine in emulator but of course crashed on real hardware.

This should actually be fixed in o2em (in the version you use) - I think I did that years ago ... what registers did you write to? Currently the behaviour is that if you write to 00-7F and VDC is on, it will behave like on real hardware and not write to those registers - other registers can be changed with VDC enabled, e.g. like in your example below the backgroundcolor
(there is actually even a command line option to allow writing to VDC even if its enabled - some homebrews need it ... it's called "allowvdcalways") - you will find it in the config-xml o2emcfg.xml)

I have also noticed that o2em seems to continue drawing sprites in the emulator even if you disable them in the VDC - on real hardware the display stops when you disable them etc.

hm ... not sure I ever changed that, but should be simple to do ...

Right now I have run into some really weird timing bug.
The following piece of code

Code:

mov r0,#vdc_color
mov a,#col_bck_green
movx @r0,a

mov r0,#vdc_control
mov a,#002h
movx @r0,a

mov r0,#vdc_color
mov a,#col_bck_red
movx @r0,a

In o2em I get a green area that is perhaps 15 rasterlines high?!
On real hardware, I get the expected behavior, with a short green (maybe half a rasterline) and then the red starts.

nope - no timing bug ... without analyzing the code that draws the screen, I think the problem is that O2EM refreshes the screen in chunks and starts a refresh if you change the background color (which is something common games do) - usually they don't change it back so quickly, so you never notice how O2EM draws the screen ... (like I said - without looking at the code I think thats how it works ...)

Is there any other emulator I could try with more cycle accurate 8245 emulation?

let me know if you find one ;-) would make developing much easier

[Sdw]

This should actually be fixed in o2em (in the version you use) - I think I did that years ago ... what registers did you write to? Currently the behaviour is that if you write to 00-7F and VDC is on, it will behave like on real hardware and not write to those registers - other registers can be changed with VDC enabled, e.g. like in your example below the backgroundcolor
(there is actually even a command line option to allow writing to VDC even if its enabled - some homebrews need it ... it's called "allowvdcalways") - you will find it in the config-xml o2emcfg.xml)

Yes, you are correct! I just tested again, and it correctly handles this. I think when I ran into this problem, I was still using the 1.18 version of the emulator.

I take it you have a good knowledge of the O2Em source code then, do you know how it handles the 8048 and 8244/8245 emulation steps?
Are they synchronized on a per line basis?
I'm thinking the best way would probably be to step one instruction (1 or 2 cycles) on the 8048 and then update/draw just the amount of pixels that the corresponding amount of color clocks would give on the VDC, and then do the next instruction etc.