Bios int handling

Page 1/2
| 2

By PingPong

Prophet (3413)

PingPong's picture

21-08-2019, 12:32

Hi
I would need a clarification in how int 38h works in msx.
On a regular msx we know the only source of interrupts in the vdp
We also know that the bios first check if the source of int is the vdp.

Let's imagine this scenario.:
There is a new device, say a AVDP connected to msx that can issue also a 38h int. The interrupts are issued most in different time slots.
But what happens if both arrive at the same time?
Ideally they could be handled both in any sequence but I suspect that there is a chance that the built in vdp could be lost because of the stupid autoreset feature of status reg 0
Do you know a sw way to overcome this problem using bios hooks.?
The scenario I m afraid of is described below:
1) an external device issue interrupt
2) z80 jump to 38h
3) z80 perform in on port 99 to see if vdp is the source
4) vdp was not the source but while z80 is doing step (3) the vdp signal int. Because of the stupid bug the vblank bit readed in by z80 is cleared even if vdp raised the interrupt
5) the original vdp interrupt is missed
6) the external device interrupt is handled by external device sw logic

As there are already examples (like mounsound) that issue ints how a similar scenario is handled?
And what about v9990 cards that can also issue interrupts? Is there a chance that when v9990 raise int the original vdp interrupt could be missed?

Login or register to post comments

By gdx

Prophet (2911)

gdx's picture

21-08-2019, 13:25

INT routine calls the Hook H.KEYI (0FD9AH) then reads the current status VDP register (must be 0 when an interruption occurs) and calls H.TIMI (0FD9FH) if the bit 7 is set.

https://www.msx.org/wiki/System_hooks

By NYYRIKKI

Enlighted (5321)

NYYRIKKI's picture

21-08-2019, 14:25

Indeed... If both VDP and external device both generate interrupts ie. on 60Hz there is this ~0.0017% possibility that VDP interrupt status gets read wrong in this process... Does the interrupt it self also get lost in this process? I'm not that sure about it, but I believe if you say so.

The most natural way to get around this problem is to poll the other interrupting device before checking if the interrupt was caused by VDP and only read VDP status when there was no other interrupting device found... This problem may still happen if RST #38 or similar software method is used to trigger the interrupt handler.

With BIOS this method becomes a bit nasty... You can use #FD9A to catch the interrupt handler before VDP interrupt is read, but then to prevent the read completely, you need to manually remove the return address from stack and jump to #D02... Although this works it does not strictly follow any standard anymore.

By Grauw

Ascended (8309)

Grauw's picture

21-08-2019, 15:06

Didn’t you already ask about this before? Better to keep the topic in one place imo.

Anyway you can look at the BIOS source code yourself, it is not very difficult to understand:

https://sourceforge.net/p/msxsyssrc/git/ci/master/tree/base1...

There are no mitigations for the case you mentioned, it is simply so unlikely that it rarely occurs. Quoting myself from your previous thread:

Grauw wrote:

I never heard anyone complain about this so I don’t think it’s an issue in practice. I’ve only ever heard about this in the context of people polling the interrupt flags.

I really don’t think you need to worry about it. It is a theoretical problem yes, but not a practical one.

By gdx

Prophet (2911)

gdx's picture

21-08-2019, 15:27

NYYRIKKI wrote:

With BIOS this method becomes a bit nasty... You can use #FD9A to catch the interrupt handler before VDP interrupt is read, but then to prevent the read completely, you need to manually remove the return address from stack and jump to #D02...

Do not jump to #D02! Otherwise your program will not work on all MSXs. Better to jump to 0fd9fh, or restore all CPU registers in order plus a POP to back to your program if it runs on cartridge and you need speed.

By PingPong

Prophet (3413)

PingPong's picture

21-08-2019, 17:18

yes, you are right. It's very sad that YOU remember a thing that I DONE little time ago. I'm sorry.

So the only solution is to completely replace BIOS and read the "Other Device" before VDP.

By hit9918

Prophet (2864)

hit9918's picture

21-08-2019, 17:19

I found a trick, the interrupt handler must first sync to the horizontal blank, then the problem cant happen Big smile

you can even make a horizontal sync to the critial point where the interrupt is made, the left border, the start of display area.
and then you can read the interrupt status register. it will RELIABLY happen multiple cycles too late Big smile
the IN of the horizontal sync loop may hit the critical point, but that's another status register, nothing bad happens.

By Grauw

Ascended (8309)

Grauw's picture

21-08-2019, 17:36

PingPong wrote:

So the only solution is to completely replace BIOS and read the "Other Device" before VDP.

That is assuming there is an actual practical problem in the first place Smile.

I install a custom ISR before the BIOS in several of my programs (hooking 38h in DOS or using IM2 in ROM), but I only do so for the reason to improve the interrupt response time of screen splits & MIDI data transfer. I wouldn’t prematurely do it just for the theoretical risk of missing a VDP interrupt. I don’t think it’s needed for that.

I also wouldn’t completely replace the BIOS, I would just test the device I’m handling if it’s the interrupt source, and if it’s not then I would defer to 38h. This avoids compatibility issues (like disk drives not stopping spinning).

By PingPong

Prophet (3413)

PingPong's picture

21-08-2019, 18:55

This is due mainly to the stupid autoreset "feature" of the VDP.
Another shitty design by Karl Guttag (R) surely motivated by the need of minimizing transistor count and costs.
Would be so terribly complex to link the ack function to a specific out on some port? (like on V9990)?

I completely understand all the difficulties the Yamaha engineers had incurred in trying to to a decent V9938 while keeping all that TMS rubbish on line.

By Grauw

Ascended (8309)

Grauw's picture

21-08-2019, 20:13

For sure it must've been a challenge! Smile

It almost looks like an oversight, I mean on paper it sees a nice trick that allows the ISR to be faster too. However he did not consider this practical issue of the timing difference between when the CPU signals the read and when it samples the data bus.

By NYYRIKKI

Enlighted (5321)

NYYRIKKI's picture

21-08-2019, 20:34

gdx wrote:

Do not jump to #D02! Otherwise your program will not work on all MSXs.

Please give me examples. I would like to investigate the issue a bit more closely.

Page 1/2
| 2