Go Penguin WIP platformer for MSX 1

Page 14/16
7 | 8 | 9 | 10 | 11 | 12 | 13 | | 15 | 16

By thegeps

Paladin (881)

thegeps's picture

07-07-2021, 21:56

Why read input during isr? Can you post readinput code? I don't see something that could corrupt the screen, so maybe it's in readinput code. And maybe you can post a video of the issue here

By albs_br

Champion (341)

albs_br's picture

08-07-2021, 05:12

thegeps wrote:

Why read input during isr?

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

thegeps wrote:

Can you post readinput code? I don't see something that could corrupt the screen, so maybe it's in readinput code. And maybe you can post a video of the issue here

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).

By thegeps

Paladin (881)

thegeps's picture

08-07-2021, 12:56

I actually use AKG player on Freedom Fighter, and inside the isr I have really a lot more than you (all sat management and sat sending to vram, reverted sat on alternate frames, check for music speed adjust 50hz/60hz) and the only effect it has on ntsc machines is a little slowdown when all 32 sprites on screen (often, lol) but not affecting playability...
So I think that maybe AKG couldn't be guilty here...
I hadn't (and I haven't in these days) enough time to study your scrolling code (but I will, it deserve to be studied)

By santiontanon

Paragon (1519)

santiontanon's picture

08-07-2021, 20:47

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 Smile

By NYYRIKKI

Enlighted (5889)

NYYRIKKI's picture

08-07-2021, 22:59

santiontanon wrote:

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 Smile

If you use BIOS ISR handler then AF is only you need to push/pop... If you use directly #38 or some other IM-mode then you need to push/pop all registers you plan to use in your ISR routine.

By santiontanon

Paragon (1519)

santiontanon's picture

09-07-2021, 00:02

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

By JMeric

Resident (46)

JMeric's picture

09-07-2021, 00:45

Wahoooo,

Great game, beautiful and smooth Smile
Continue your fabulous work

By Grauw

Ascended (10139)

Grauw's picture

09-07-2021, 01:24

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.

By albs_br

Champion (341)

albs_br's picture

09-07-2021, 05:15

Tried to push and pop all registers as @santi pointed out, it doesn't work. But I'll keep it just to stay on the safe side (unnecessary, maybe?)

Then I perceived that just after the halt there were two routines using unrolled OTIR's that should run on VBLANK. Replaced them by loops with OUTI, JP nz, and worked perfectly. After that I saw here @Grauw pointing out exacly this solution.

If I have to call the music player inside the ISR that's the only solution. Am I right?

Thanks for all help.

By thegeps

Paladin (881)

thegeps's picture

09-07-2021, 08:14

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...

Page 14/16
7 | 8 | 9 | 10 | 11 | 12 | 13 | | 15 | 16