MSX bios interrupthandler

Страница 2/6
1 | | 3 | 4 | 5 | 6

By Grauw

Ascended (10010)

Аватар пользователя Grauw

11-03-2014, 20:33

hit9918 wrote:

"c3c" is not official address, is it.

No, 38H is.

hit9918 wrote:

@grauw, I noticed bios takes much less once one pressed a key into keyboard buffer.
is that related to your poke, is value 255 maybe a different kind of empty keyboard buffer.

Key scanning is rather expensive, it isn’t done every interrupt. This value is counted down and when it reaches 0 the keys are scanned and it is reset to 2 (I believe). By keeping it set to 255 continuously, the key scanning will never happen.

By hit9918

Prophet (2904)

Аватар пользователя hit9918

11-03-2014, 21:24

After bios calls H.TIMI, it does EI.
Then any time down that code, it could get hit by a new vblank interrupt.
and then again same code gets run.
having random interrupted anything of the code that does read modify write variables.

That is the thing I never understood.

Not only with an interrupt server taking longer than a frame this happens.
When after a long DI doine EI short before the vblank, it happens, too.
First immedeately happens interrupt, bios does consume, then it does said EI and then the vblank hits it a second time.

By Grauw

Ascended (10010)

Аватар пользователя Grauw

11-03-2014, 22:52

The reason it re-enables the interrupts is that the vblank handling can be pretty lengthy (up to 9000 cycles or so?), so if it didn’t re-enable them some interrupts would have problems getting handled in time. E.g. MIDI interrupts arrive at a rate of 52 interrupts per frame, if I am to keep up with that the ISR must only keep the interrupts disabled for 320 µs max, that’s ~1100 cycles at 3.58 MHz.

Though, I think it would’ve been safer had they checked and set a flag in memory before enabling the interrupts. Without that, if the ISR gets starved by other interrupts and can never complete before the next vblank, it seems to me this would eventually lead to a stack overflow.

At this point you’re probably in dire straits anyway, but still, memory corruption due to stack overflow can lead to worse results than a simple hang does, and if the flow of interrupts that cause the starvation (say, RS232 input) eventually stops it won’t be able to recover.

By hit9918

Prophet (2904)

Аватар пользователя hit9918

11-03-2014, 22:50

I understand that double interrupt is needed for fast devices.
But in that case the questionable section after EI is not entered.

But with "enable interrupt short before vblank" the problem happens when vblank interrupt request is active.
With disks taking long DI times, it happens all day.
And I wonder why there are no funny crashes.
I feel like the code survives it out of sheer luck.

By hit9918

Prophet (2904)

Аватар пользователя hit9918

11-03-2014, 22:54

The bios code after EI is interrupted at any instruction.
Then the same code ran again from begining.
And then the rest of interrupted code continues running.
I am not telling that I observed the case, but from theory it gotta happen.

By Grauw

Ascended (10010)

Аватар пользователя Grauw

11-03-2014, 23:30

That very likely happens, yeah.

I can see that some things could get odd values, e.g. NEWKEY / OLDKEY may not be updated correctly. But I don’t see why it would crash under normal conditions, as long as there is enough space on the stack to hold a second interrupt handler… This is pretty easy to prove, I’m sure they checked that.

The correct updating of all values without synchronizing using DI/EI is harder to prove. E.g. we can easily see that even if a second vblank interrupt occurs between ld hl,(JIFFY) and ld (JIFFY),hl, it always gets increased, so that’s fine. Similarly, if certain key matrix changes are missed that should be no problem either.

However I don’t think they pass this test, because they don’t disable interrupts between setting the keyboard matrix row and reading the value, and this can cause the last key matrix row to accidentally be read for any of the other rows. (Note that it does briefly disable interrupts when reading the joystick ports, so it’s fine there.)

By hit9918

Prophet (2904)

Аватар пользователя hit9918

12-03-2014, 00:22

it still is remarkable that never happens "a keypress out of nothing" or something.
reading one sector should need longer than one frame, floppy action should trigger the case relatively much.

By Daemos

Paragon (1951)

Аватар пользователя Daemos

12-03-2014, 09:14

Quote:

The reason it re-enables the interrupts is that the vblank handling can be pretty lengthy (up to 9000 cycles or so?), so if it didn’t re-enable them some interrupts would have problems getting handled in time. E.g. MIDI interrupts arrive at a rate of 52 interrupts per frame, if I am to keep up with that the ISR must only keep the interrupts disabled for 320 µs max, that’s ~1100 cycles at 3.58 MHz.

What I suddenly understand here is that MIDI on turbo GT gives off interrupts? Many many many interrupts. Enough to create enough int staking to hang a system if di is kept for a lenghty time, like ldir an entire page?

By Grauw

Ascended (10010)

Аватар пользователя Grauw

17-09-2020, 22:43

MSX-MIDI only gives interrupts when it is enabled / configured and actually receiving bytes (at a rate of 3125 bytes / sec). And when it does, it’s not enough to hang the system. Doubt it is the cause of on turbo R GT woes.

By anonymous

incognito ergo sum (116)

Аватар пользователя anonymous

13-03-2014, 11:48

Daemos wrote:

What I suddenly understand here is that MIDI on turbo GT gives off interrupts? Many many many interrupts. Enough to create enough int staking to hang a system if di is kept for a lenghty time, like ldir an entire page?

This is what happens when you don't receive a proper education. You start thinking you understand things, which are totally not true.

While the replies on this thread SEEM insightful and helpful at first sight, looking at disassembled BIOS is hardly helpful for a beginner programmer like you, Daemos. Anyway, you appear to have made the choice to not learn anything properly... This makes me sad, because I value a high-level MSX development scene... But so be it.

(inb4 the flaming trolls arrive, the above is not meant to be mean)

Страница 2/6
1 | | 3 | 4 | 5 | 6