Go Penguin WIP platformer for MSX 1

That's the way it is on MSX lib example.

All code is public: https://github.com/albs-br/penguin-platformer/blob/master/Ga...

But my guess is that this routine has nothing to do with the matter.
The problem is that code meant for screen should run before the corresponding line is drawn. As the AKG Play routine is fat (20 scanlines is a lot) bad things happens. If I run at 50Hz machines it works perfectly.

Maybe the AKY player be the solution (but this one doesn't run on the game, on the tester code isolatelly runs ok).

Even if I have heard many people say that the ISR pushes/pops all the registers for you, if I do not manually push/pop all the registers the ISR modifies myself, I always get corruption/crashes. From what I see, both your readinput function (and probably the music playback routine) modify registers, so, I suggest just doing push of all the registers your ISR is modifying at the beginning of the ISR, and pop afterwards. If that solves it, then case closed

ok, thanks for the clarification KYYRIKKI! If I read the code correctly, I think albs_br is directly replacing the HTIMI function by his own, so, then I think the problem is the missing push/pops. Without the music handler, this probably was never a problem, since the custom interrupt function finished very quickly, making it almost impossible for the interrupt to trigger anywhere that was not your "halt" instruction, hence you never saw any problem before.

But that is my hypothesis, I might be wrong hahaha

You can read exactly what the ISR does here.

Indeed, in H.TIMI you need to preserve AF, in H.KEYI you don’t need to preserve anything. In both you need to keep interrupts disabled. When you hook these, make sure the handler and the data it accesses is either in page 3 (0C000H and up) or that the hook does an interslot call, or that you’re absolutely sure the slot selection stays constant for as long as the hook is present.

As you mention screen corruption, are you perhaps writing to VRAM faster than 29 cycles per byte, which can only be done during vertical blanking? In that case make sure to call the music player after the VRAM update.

You use halt to determine if you are in vblank to do unrolled otir? Halt simply wait for next interrupt, but if there is added hardware int could be generated from other devices than vdp. Better polling jiffy system variable (learned it here when coding FF, I don't remember if NYYRIKKI or Grauw told me):

jiffy:			equ	0fc9eh	;vblank updated variable

   ld hl,jiffy
   ld a,(hl)
wait_vblank:
   cp (hl)
   jr z,wait_vblank

And, well, if you need to do routines within the vblank put them at the beginning of isr hooked routine, before the music player. Obviously you don't need this piece of code if you put them in isr. And read joy/key input elsewhere. Human reactions are really (a lot) slower than 1/50th of sec, you don't need tonpoll them so often...