INT_IRQ will not write 0xFF to INT_LAST in case of an unknown interrupt

[skiselev]

Although the code sets the "default" value of 0FFh to AH, that will not get written to INT_LAST i

INT_IRQ PROC
ASSUME DS:_BDA
PUSH AX ; save registers
PUSH BX
MOV BX, SEG _BDA ; set up for DS to BDA
MOV AX, DBW <0FFH, OCW3 <,,,,11B>> ; AL = OCW3 (Read ISR reg on next pulse)
; AH = default return 0xFF in INT_LAST <-- default value
OUT INT_P0, AL ; write to PIC port 0 (20h)
PUSH DS ; save DS and delay for PIC at least 1 clock pulse
IN AL, INT_P0 ; get In-Service Register (ISR)
TEST AL, AL ; is there an active hardware interrupt?
JZ INT_IRQ_DONE ; jump and exit if not <-- if there is no active interrupt, it will exit without writing 0FFh to INT_LAST
MOV AH, AL ; Save ISR in AH
IN AL, INT_IMR ; get current Interrupt Mask Register (IMR)
MOV DS, BX ; set DS to BDA
MOV INT_LAST, AH ; save last interrupt to BDA and delay for PIC <-- not reached if there is no active interrupt
OR AL, AH ; apply IMR mask to ISR
OUT INT_IMR, AL ; write AL to PIC port 1 (21h)
MOV AL, INT_EOI ; End of Interrupt OCW
OUT INT_P0, AL ; write EOI to PIC port 0 (20h)
INT_IRQ_DONE:
POP DS
POP BX
POP AX
IRET

INT_IRQ ENDP

[640-KB]

Thx! I'm on it!

[640-KB]

Good catch! Looks like I can just move MOV INT_LAST, AH to after the INT_IRQ_DONE: and that will take care of it.

Interestingly as an aside, I looked into it a little bit further and that byte 40:6Bh is also used by INT 15h BASIC cassette routines during reads as well as the default location in memory (for at least the Vendex PCs) to store the copy of the FE2010A's config register. Which kind of seems like having an active ISR that could write to that location after boot may not be such a great thing actually. What I'm really interested to find out is does that "last interrupt" byte have any actual use outside of POST tests or is it only the typical "have to do exactly what IBM did for compatibility" superstition. :)

BTW, as you may have come across in the code, I have been playing around with it on the micro_8088/NuXT (since I have one now) as it is such a cool piece of hardware you created. GLaBIOS is of course no replacement for 8088_bios, but I'm having fun with it as a new little sub-project. Are you okay if I keep poking around at it and release whatever I come up with?

Thanks again for the bug find -- really appreciate it.

[skiselev]

It appears that the IBM XT BIOS uses INTR_FLAG (INT_LAST in your code, last_irq in mine) for testing that PIT channel 0 indeed generates interrupts. I assume this test both PIT and PIC functionality.
It also seems that in GLaBIOS you use that to test that the PIC doesn't receive any interrupts when interrupts are masked
In my BIOS, I don't do much testing, so it pretty much just updates the byte with the last IRQ for compatibility reasons

I was actually looking at your code because of this issue: skiselev/8088_bios#31
It is quite weird, I was suspecting that 8088 BIOS does something different with PIC initialization (it doesn't appear to) or with UART detection or initialization (INT 14h, AH=00). There are some differences between our implementations there, but they don't seem to affect the issue... So if you're feeling bored you're welcome to poke around 😉

BTW, I am impressed with the quality of your code (use of macros, MASM records, and various optimizations)

[640-KB]

Ah, I was wondering what brought you to such a fairly obscure (and not all that interesting) part of the BIOS. I've committed the fix for the JMP on this, though won't bump to a new release until we do a bit more testing across platforms. That's probably one of the oldest bits of code in there, and since it's always been that way I'd almost be hesitant to change it ("not broke, don't fix" kind of things).

c9dd39d

For the POST testing I pretty much just followed this from minuszerodegrees as the template for what to do. It seems like back then a lot of those tests were probably overkill, but now that some of this vintage hardware is passing 40 years old, it's actually turned out to be useful. But for new hardware, for sure skip it... not worth the bytes or time!

MASM does have some fun goodies, but now the code is pretty well married to it so for better or worse I'm probably stuck with it for a while! I've been asked if I'd consider migrating it to nasm or something, but with all the MASM meta now that doesn't sound like a ton of fun. :)

Thanks again for the code review and bug find!

640KB