When I look at VDPio.asm I see _vdpsetvramwr:
no ints are disabled during outing to #99. Is this on purpose or is it done prior to the call?
EDIT: I see it is done prior to the call by most of the routines I come by. Chance is small this is the cause of the problems.
EDIT2: I see however that there are some routines that call the _vdpsetvramwr: directly without doing di first.
EDIT3: Also a quick overview of the ISR allthough I am not a 100% sure (have to read quickly) status register 0 is not being set back after lineint. I remember having similar issues on real HW.
xor a ; read S#0 out (0x99),a ld a,128+15 out (0x99),a
shouldn't this be after you do all your lineint stuff?
It works only at 50 he due to exact timing of some actions
no point in testing at 60hz
instead of "no point in it" I would say it is serving the synchronization bug on a golden plate in a emu config
@Daemos,
about the status register selection, in p3bios I let the interrupt handler restore the RG15SAV.
then a blitter test goes like this
[code]
waitblt: in a,(0x99) ;I know I set up R15 before and an interrupt wont change this
and xxx
jp nz,waitblt
[code]
no status register setup, removed overhead.
another thing, interrupt handlers that do early EI.
check status register, then check a mutex against being run multiple times, and after that just go EI.
from now on you can code similar to non-interrupt code, e.g. call functions that got a usual DI/EI pair.
an unification in programing model.
The line interrupt is extreme, that can go without the early EI. It doesn't have much code anyways.
But the vblank interrupt tends to be a fatter bar where you call lot more things.
It is a plus to be able to code it more like non-interrupt code.
Also the vblank could get interrupted by "the moonsound on a BPM exactness trip".
Instead being late by a fat vblank handler.
Doing things more like a realtime OS 
But not with ado but coding in common patterns.
The RG15SAV way is nothing new, but the same pattern known from memory mapper mirrors:
ld (mirror),a
out (hardware),a
first the mirror byte, then the hardware.
When I look at VDPio.asm I see _vdpsetvramwr:
no ints are disabled during outing to #99. Is this on purpose or is it done prior to the call?
EDIT: I see it is done prior to the call by most of the routines I come by. Chance is small this is the cause of the problems.
I should always have disabled interrupts always before the call. The idea is that there are cases where I cannot re-enable interrupts between two calls to _vdpsetvramwr.
EDIT2: I see however that there are some routines that call the _vdpsetvramwr: directly without doing di first.
Where ? This could be the problem I cannot spot.
EDIT3: Also a quick overview of the ISR allthough I am not a 100% sure (have to read quickly) status register 0 is not being set back after lineint. I remember having similar issues on real HW.
xor a ; read S#0 out (0x99),a ld a,128+15 out (0x99),a
shouldn't this be after you do all your lineint stuff?
This latter cannot be the problem, as the ISR code is custom (I have ram in page 0) and all the IN's in my code are after setting register #15.
It works only at 50 he due to exact timing of some actions
no point in testing at 60hz
instead of "no point in it" I would say it is serving the synchronization bug on a golden plate in a emu config 
The main loop exceeds the frame time, you get any kind of overflow, and bluemsx is very inaccurate on timings (and more) so you get all a series of problems you will never see on the real thing.
Anyway booting the rom with shift pressed enables 60Hz, so you can try NTSC also on openmsx (an on the real thing). Can you spot the problem there? Bluemsx isn't a valid testbed for this kind of development.
On openmsx I'm trying to test if there are outs while the interrupts are enabled with a debug script by Wouter (thanks!).
On the console command I type:
>debug set_watchpoint write_io 1 "0 255" mytest
>proc mytest {} {
> if {[reg IFF] & 2} {
> message "OUT with EI at PC=[reg PC]"
> }
> }
Sadly I do not get any message in the Status info tab of catapult: not in PAL, neither in NTSC mode (booting with shift).
So, or this debug script has some problems (I've never used debug on command line in openmsx), or the glitch on real HW has to be found elsewhere (!).
Is there someone who has a tested and working debug script for the same purpose on openmsx ?
Where ? This could be the problem I cannot spot.
xor a ld (_kBank1),a inc a ld (_kBank2),a call _cls ld a, :sprtdata ld (_kBank4),a call _hw_sprite_init ld a, :_scorebar setpage_a ld c,0 ld de,256*(mapHeight*16+8) call _vdpsetvramwr ld hl,_scorebar ld bc,0x0098 ld a,24 1: otir dec a jr nz,1b
in main.asm at start
thanks but this cannot be the issue.
This code cannot be interrupted as few lines above I did
call setrampage0 ld a,0xc9 ld (0x38),a
so no interrupt ;-)
After all you see the screen being built and the score bar being loaded in VRAM also on real HW, so this part works at least till line 201 (included).
The problems have to be after line 210 where I do
call _isrinit
and the main loop starts.
If disabling _isrinit will the engine at least run?
What else of your code is located in page 0?
ei halt
Does this work when interrupts are disabled? Enabling interrupt has a 1-instruction delay after all, so they will only be enabled after the halt? Either way, probably not the cause of your problems. Btw, also, no need to disable interrupts at the start of your ISR afaik (the Z80 disables them automatically).
