GloriousCow wrote on 2024-02-24, 21:01:

superfury wrote on 2024-02-24, 20:55:

What about the 8259 IRR register? UniPCemu has IRR2 raised (it's parallel interrupt lines), so the line is actually raised.
But the IMR register bit 2 is s, so the IRR isn't set somehow? IMR is BCh.

If you turn off vsync interrupts in the CRTC, then I assume CRTINT is not produced. Therefore you have no interrupts, the PIC doesn't get involved, and crucially, bit 7 in the input status register isn't driven by anything, so you can't detect vsync anymore. That's all I was saying.

Behaviour with interrupts is interesting though. IMR keeps toggling between BCh and B8h. While B8h, the vertical retrace interrupt gets through. But somehow, eventually, it keeps stuck at BCh?

Hmmm.. I started some program from Scali (The myth of the vertical retrace interrupt on EGA/VGA VRETIRQ program).

I see it counting for a bit, then it suddenly stops counting? Changing modes doesn't restart counting?

I see the interrupt flipflop is cleared and the vertical retrace end register interrupt bits both cleared permanently?

Hmmm... Perhaps my implementing of bit 4 being required to raise an interrupt is incorrect?

ET4000/W32i documentation says:

bit 5: When set to 0, enables the vertical interrupt to occur. If bit 5 is set to 0 and the vertical retrace interrupt is cleare […]
Show full quote

bit 5: When set to 0, enables the vertical interrupt to occur. If bit 5 is set to 0 and the vertical retrace interrupt is cleared, then IRQ will be asserted when "VS" becomes true.

bit 4: When set to 0, clears the vertical interrupt. If bit 5 is low and the vertical interrupt is cleared, then output pin IRQ will be asserted when output line "VS" becomes true. The vertical interrupt should be cleared whenever a vertical interrupt occurs, before re-enabling interrupts.

Input Status Register 0:
Bit 7: A value of 1 indicates a pending vertical retrace interrupt.
A value of 0 means that the vertical retrace interrupt has been cleared.

So bit 4 of the Vertical Retrace End register doesn't block interrupts from happening? Only bit 5 does that.
UniPCemu so far caused setting of bit 4 to be required for the raising of the flip-flop and IRQ output.

Edit: It fixed the VRETIRQ program at least? It doesn't stop counting now anymore! 😁

Does Fanfasy Land use the PIC in a weird way? Like not using plain AEOI for interrupt termination or setup special PIC modes not like the defaults from the BIOS?

UniPCemu only checks bit 5 of OCW2 being set of bits 5-7 and doesn't implement SMM at all or priorities other than 'higher than ISR MSB' (not implemented) at all.

UniPCemu a bit odd on that one:
- OCW2 always (excluding NOP) terminates any lowest IR it can find on all parallel IR lines (so IR0 parallel 0 and IR7 parallel 1 terminate in one 'EOI').
- IR lines are always checked from IR0 to IR7, ignoring all priorities. So essentially always in SMM.

Edit: Modified it to become properly fully nested mode for now (other modes not yet supported). Thus IR7 blocks IR0 now (blocking itself was already done).

Edit: And modified it further to support all modes with rotation etc.
Thus supporting the PIC properly for the first time.

SMM is also supported now (masking off all IRQs while an IRQ is in-service right now).
Rotation of IRQ priorities is also implemented, so that should be improved as well.

Oh! Having fixed that, EGA Fantasy Land seems to properly use the IRQ. I now see the scrolling effects of the bottom window at when the demo is running! 😁

Edit: The special mask mode isn't set, so the main issue was probably that it didn't mask off the lower priority IRQs when setting the ISR register to a non-zero value due to raising an IRQ.

Edit: Ran throughout the whole demo without much issues. A graphical hiccup once and again, but nothing big (probably because of CPU timing?).

Manually controlling the cursor (leaving the demonstration mode) I actually see the smooth panning and scrolling both working properly 😁

Afaik everything is working perfectly now 😁

Nice work. How does a user specify that the EGA should be in lo-res mode in UniPCemu?

GloriousCow wrote on 2024-03-01, 13:55:

Nice work. How does a user specify that the EGA should be in lo-res mode in UniPCemu?

I simply have a setting to specify the monitor (EGA 5154 enhanced, EGA 5154 normal, CGA 5153). That simply affects the monitor ID bits reported on the switches on the EGA adapter.
The monitor that's connected is still an EGA adapter, as it properly responds according to the different signals and is compatible.
All it does is change the switches: 0x6(off on on off) for enhanced EGA, 0x7(on on on off) for EGA 5154 normal and 0x8(off off off on) for CGA 5153 (remember that bit 0 of the switches is switch #0).
For example, monochrome VGA monitor sets SW2 only (0x2, or 'off on off off'). And monochrome EGA monitor (right now) sets 0x4 (or 'off off on off', so SW3 only on).

Though EGA monochrome (MDA monitor) still seems to have issues with starting on tested BIOSes (Generic Super PC/Turbo XT BIOS latest as well as Compaq Deskpro 386 tested).
Once the XT-IDE BIOS pops up it runs for a bit, but MS-DOS renders incorrectly (wrong memory area for VRAM writes). Cursor seems to still update though?
'C' from 'CLS' command puts the cursor at the position of the 'X' of 'XTIDE Universal BIOS'?
So it looks like cursor position updating still works in monochrome mode. Just nothing is written to the VRAM window correctly (all written to the B800 segment instead of B000 segment when in monochrome mode, except the XT-IDE BIOS itself it seems).
Until I run 'mode mono' that is.
It's almost like it's using the color adapter for output somehow instead of the 'primary' monochrome EGA adapter.

Edit: Also, interesting, running Windows 95 (at least the C version, others probably as well. Though you'd need to emulate a 386 or newer for that) sets the special mask mode on (sets said bit to 1). So that's a good test of that mode. Don't know if older versions of Windows (3.1 etc.) use it as well?

Edit: It makes me wonder though. What actualy DOES special fully nested mode do to a 8259(A) PIC? What really changes in the behaviour of the chip? Normal special mask mode is relatively simple.