Just have been thinking...
UniPCemu latches pixel shift count and byte panning (which are combined) on vertical retrace end (pixel shift count) and vertical retrace start (byte panning).

Are those even latched? Or always live?
Byte panning btw is counted as pixel shift count addition measured in character clock sizes (8 or 9 pixels multiples).

End horizontal retrace (CRTC 05) bit 7 is also weird? I doubt it's directly added on EGA to the start address registers? Is it used instead of VGA's byte panning register value?

Also found https://forum.vcfed.org/index.php?threads/ega … 3/#post-1366687 , might be a test case?
Edit: Also found (for VGA and SVGA cards): Re: Solved(?): Why does Commander Keen 4-6 hardware scrolling glitch on ATI (Mach) PCI video cards
Getting complicated now...

superfury wrote on 2024-02-21, 11:50:

Just have been thinking... UniPCemu latches pixel shift count and byte panning (which are combined) on vertical retrace end (pix […]
Show full quote

Just have been thinking...
UniPCemu latches pixel shift count and byte panning (which are combined) on vertical retrace end (pixel shift count) and vertical retrace start (byte panning).

Are those even latched? Or always live?
Byte panning btw is counted as pixel shift count addition measured in character clock sizes (8 or 9 pixels multiples).

End horizontal retrace (CRTC 05) bit 7 is also weird? I doubt it's directly added on EGA to the start address registers? Is it used instead of VGA's byte panning register value?

Also found https://forum.vcfed.org/index.php?threads/ega … 3/#post-1366687 , might be a test case?
Edit: Also found (for VGA and SVGA cards): Re: Solved(?): Why does Commander Keen 4-6 hardware scrolling glitch on ATI (Mach) PCI video cards
Getting complicated now...

As you can see from that thread on the EGA at least pel panning is not latched, but behavior differs on clones / VGA cards

GloriousCow wrote on 2024-02-21, 14:31:

superfury wrote on 2024-02-21, 11:50:

Just have been thinking... UniPCemu latches pixel shift count and byte panning (which are combined) on vertical retrace end (pix […]
Show full quote

Just have been thinking...
UniPCemu latches pixel shift count and byte panning (which are combined) on vertical retrace end (pixel shift count) and vertical retrace start (byte panning).

Are those even latched? Or always live?
Byte panning btw is counted as pixel shift count addition measured in character clock sizes (8 or 9 pixels multiples).

End horizontal retrace (CRTC 05) bit 7 is also weird? I doubt it's directly added on EGA to the start address registers? Is it used instead of VGA's byte panning register value?

Also found https://forum.vcfed.org/index.php?threads/ega … 3/#post-1366687 , might be a test case?
Edit: Also found (for VGA and SVGA cards): Re: Solved(?): Why does Commander Keen 4-6 hardware scrolling glitch on ATI (Mach) PCI video cards
Getting complicated now...

As you can see from that thread on the EGA at least pel panning is not latched, but behavior differs on clones / VGA cards

OK. Now UniPCemu does the following:
- Latch byte count and pel panning together always (instead of during start of vretrace (byte panning) and end of vretrace(pixel shift count) that was used until now for each respectively).
- Latch them at horizontal total and new video frame(at vertical total's first clock of the new EGA frame) and use them immediately on said clock. This effectively makes it tick at the start of each scanline, where the latches are used to discard pixels read from VRAM.
- Latch them at start of vertical retrace on MDA/CGA(they're always zero pixels and unused) and VGA and SVGA cards (Tseng ET3000/ET4000AX/W32i)).
- EGA CRTC register bit 5 sets byte panning instead of the documented VGA register.

So EGA has the effect of them being unlatched and VGA/SVGA now latch them during vertical retrace start (UniPCemu's Tseng chips). MDA/CGA have them set to not shift always, so it has no effect.

Edit: OK. MELT gives sets of scanlines that move small bars across the screen?

Using the 8088 running at 20MHz there (cycle-accurate mode, with current cycle accuracy of the limited instruction accurate instruction set (above opcode 83h's EU timings is probably inaccurate (still the old timings))).
Edit: Just fixed the PEL shifting of DCR modes (dot clock rate divided by 2) to behave properly (actually shifting 8 double clocks instead of single clocks(which are one half of the dot clock in that case when enabled)).
Edit: And fixing the not-ready state during powerup (when the sequencer is disabled from ticking) fixes the emulator to not hang in such a case anymore.

I see that the EGA is skipping pixels from the start of the buffer depending on the current PEL panning. But the wavey effect from the screen capture on the forums isn't there? Only some scanlines being shifted each X scanlines for n lines the same? It's about an NNNNNNNNNNNNNNNNNNNNNNNNNSSSSSSSSSSSS pattern repeating (N being not shifted, S being shifted)? Although I see the skipping moving left and right in the rendered frames the emulator outputs?

Hmmm.. Just been thinking... What if I put said pixel panning effect (a copy of said table with the assembly code) into my MDA monochrome mode 0Fh demo? If the EGA pixel panning is operating properly, it should give me a sinus pattern on the screen with those straight vertical lines?

melt (game.exe) in MartyPC:

(click for animated version)

I implemented pel panning as a fundamental operator of the Attribute Controller. There's nothing to 'latch' per se; when you write a new value to the attribute controller's pel panning register it takes effect immediately. If you maintain a two-character / 16 pixel FIFO, then you can just shift the fifo left by the amount of pel panning. Each character clock the attribute controller serializes 8 pixels (shifted out of fifo, after shift by pel pan) and is loaded with 8 pixels (or 1 char + 1 attribute, in text mode)

code is here:
https://github.com/dbalsom/martypc/blob/565ff … troller.rs#L397

still uncertain of handling of pel panning values > 7 so i am limiting to 7. I still need to play with MOD 0x07 as you suggested. The bit twiddling is because i pack 8 pixels into u64 values and draw a hchar (64 bits) or lchar (64+64bits) at a time, so you're seeing the pixel doubling logic. The FIFO is implemented as a u128; this should probably be done with SIMD but I wanted to get the basics working first

GloriousCow wrote on 2024-02-22, 18:43:

I implemented pel panning as a fundamental operator of the Attribute Controller. There's nothing to 'latch' per se; when you wr […]
Show full quote

I implemented pel panning as a fundamental operator of the Attribute Controller. There's nothing to 'latch' per se; when you write a new value to the attribute controller's pel panning register it takes effect immediately. If you maintain a two-character / 16 pixel FIFO, then you can just shift the fifo left by the amount of pel panning. Each character clock the attribute controller serializes 8 pixels (shifted out of fifo, after shift by pel pan) and is loaded with 8 pixels (or 1 char + 1 attribute, in text mode)

code is here:
https://github.com/dbalsom/martypc/blob/565ff … troller.rs#L397

still uncertain of handling of pel panning values > 7 so i am limiting to 7. I still need to play with MOD 0x07 as you suggested. The bit twiddling is because i pack 8 pixels into u64 values and draw a hchar (64 bits) or lchar (64+64bits) at a time, so you're seeing the pixel doubling logic. The FIFO is implemented as a u128; this should probably be done with SIMD but I wanted to get the basics working first

What I do is pretty simple right now. Simply perform the first steps until the attribute controller pel panning count times. That pretty much shifts data out of the shift register (which is precalculated when a latch occurs every 8 (or 4 in 8-bit SVGA color modes), 16 or 32 clocks (this is determined as my other thread I made explaining the timings).
It uses MOD 7 in graphics modes (as it's 8 pixels per clock) and above 8 becomes 0 panning in 9 dots modes.
Unknown what happens on SVGA with Tseng's odd character widths (5,6,7,14 and 15 wide text characters). UniPCemu just looks at the one Sequencer register 01 bit to determine PEL panning operation right now.

Edit: First attempt running it failed. Forgot to put the input status 1 register from the demo (which obviously doesn't work yet for some reason) into 3BA instead of 3DA (as it's monochrome mode 😖 ). First try hanged because of that 🤣

One nice thing is that if pixel panning actually works on UniPCemu, I should see the image wobble more easily, as it's simple straight lines vertically accross the screen. It should show a vertical sinus pattern that's used if it works at least. If it doesn't, it's immediately visible that that's not functioning at all. And if the earlier pattern applies again, there's probably something odd going on.

Edit: Ooh! I see it's actually modulating the pixel shift count as it should, every scanline (using the current cycle-accurate 4.77MHz 8088 CPU).

So the modulation itself is working from register pov. I see the precalcs getting updated for rendering.
But the actual rendering, instead of going left to right and back, is caused to become more of a flip-flop toggle it looks like?

Since the modulation of the register is actually working, why does the pixel panning get a flip-flop effect?
It's in graphics mode, so it's mod 7.

Also as a note why the bottom part of the screen isn't continuing the pattern, it's because it's not modifying the pixel panning effect after 200 scanlines (it's rendering 350 scanlines in mode 0F). So the last 150 scanlines are using the panning of the 200th scanline.
One nice thing (a side effect essentially) that this gives is that it clearly displays how the pixel panning is operating in the top and bottom 'window' as it were. The top window that's created uses a normal wave effect on all scanlines that's moving upwards, while the bottom 'window' should instead just wobble parallel lines (the 4 block colors rendered) horizontally from left and right, clearly displaying how the PEL panning (and byte panning on the different register of the EGA) is modifying a scanline if modulated (and not moving a pattern).

The odd thing is that both the vertical pattern and the horizontal pattern are displaying the on/off pattern (either moving right some amount or not moving at all).

That pretty much confirms that the PEL panning isn't operating as it should (like it's being rounded or truncated in some odd way (low bits cleared or something like that)).
Edit: Found a bug in the horizontal rendering timing that was resetting horizontal timing AFTER the pel panning was applied when it shouldn't (thus causing the whole latching to become undone because it resets all horizontal timing related to VRAM, SLR and character counter etc., causing the actual first pixel to restart the horizontal timing like the PEL panning didn't happen!).

Edit: I'm getting the weird pattern on the EGAMELT program too? How is that even possible?

Finally, I see movement! 😁

And the executable used:

Again, beware, as it's written for mode 0F.

UniPCemu running EGAMELT shows the same vertical pattern oddly enough? It's supposed to be a sinusoidal PEL shift pattern according to the lookup table though (it's like it's inversed or overflowing)?

Edit: Also, the entire horizontal logic (VRAM reloading, SLR, character counter and subcharacter(for shifting out one bit at a time from all 4 planes, or the text font pattern (with unchanging attribute)) is simply processed (so all but CRTC (which drives this instead) and attribute controller (as it's supposed to ignore the pixel inputs for rendering)).
I also see the 32 entries from the table being used on every 32 scanlines, cycling ahead on every frame(by 1 ahead to move it upwards) and the bottom half following the 200th scanline accordingly.
So then, why is it looking like it's clipping (binary AND) the waveform in the rendered image? Flipping my own app's output sideways reveals a clipping-like behaviour (Something like: 0,0,0,0,0,6,7,8,3,4,5,6,5,4,3,8,7,6,0,0,0,0,0 -ish pattern)?

Is Mode F supposed to use the 14Mhz clock?

GloriousCow wrote on 2024-02-23, 02:13:

Is Mode F supposed to use the 14Mhz clock?

I didn't intuitively expect it, but it would make sense. The MDA monitor displays 720 active horizontal pixels in Mode 07 at 16.257MHz. If you calculate the number of pixels at 14.318 MHz that take the same time, you get to 634, which is quite close (within 1%) to 640.

mkarcher wrote on 2024-02-23, 02:26:

GloriousCow wrote on 2024-02-23, 02:13:

Is Mode F supposed to use the 14Mhz clock?

I didn't intuitively expect it, but it would make sense. The MDA monitor displays 720 active horizontal pixels in Mode 07 at 16.257MHz. If you calculate the number of pixels at 14.318 MHz that take the same time, you get to 634, which is quite close (within 1%) to 640.

It looks like that is the case?
Mode 7 has Misc Output A6(EGA documentation), so clock #1=16MHz.
Mode F has Misc Output A2(EGA documentation), so clock #0=14MHz.

Well, my Mode F needs some work, but I can see a smooth sinus pattern with the pel panning, just like the melt demo.

GloriousCow wrote on 2024-02-23, 13:48:

Well, my Mode F needs some work, but I can see a smooth sinus pattern with the pel panning, just like the melt demo.

OK. Added some more options to MODE0F.PAS. A 'fastdrawing' option (reduces the screen to one scanline in VRAM by manipulating the offset register, as well as the drawing of course) and a 'specialpattern' option (makes the colors the x coordinate modulo 4 instead). Also made parameters parsed in random order, in order of the parameters supplied overriding each other if that's the case (as well as supporting random order of parameters).

Still would need to test and compile it though.
Edit: Made all effect options configurable as well (a parameter added for the original sine wave effect and even added a second triangle wave effect (which runs at 2 scanlines for each movement for simple table implementation, so 0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7,7,7,6,6,5,5,4,4,3,3,2,2,1,1,0,0)).

Edit: The executable:

The parameter options are now (applied in revers order, if they overwrite one another (for example, the wave pattern to use)):

That pattern seems to begin at, what, the second character clock or something like that? It's not shifting correctly at least somehow?

Edit: Added some more functionality, this time a noanimation switch to disable the frames increasing the start position (generating a static image with only static 0-based PEL panning at scanline #0).

Edit: Hmmm... When comparing the clocks of the rendered image, I see something weird when compating it to the unshifted image (with PEL panning being 0)?
The first 4 rows are actually what happens without PEL panning (correct behaviour). The first 8 pixel clocks are spent reading from VRAM in all cases (skewing the graphics clocks).
Then from scanline 4 and onwards, the PEL panning starts to shift the display. But instead of shifting the display in 8 pixel multiples, it somehow starts with 1 equalling 4, then 2=5, 3=6, 4=7, 5=4, 6=5, 7=6 pixels shifted? So it's having the effect of
"(n&3)+4" pixels shifted somehow?
Also, somehow, with PEL panning, somehow the scanline seems to start 8 pixels earlier?
Edit: Hmmm... Perhaps an issue with pre-display clocks conflicting? That's exactly 4 pixels in graphics modes always.

Btw, one funny thing is on the EGA in monochrome mode as well. It doesn't document anything special about the overscan color register in monochrome graphics modes. So theoretically you can simply set it to 00h, 08h, 10h and 18h to display overscan in various greyscales supported by a MDA monitor (don't know if any software does this though)?

Edit: That fixes the effect! 😁

Btw I also modified the MODE0F program to render the sinus and triangle wave until scanline 175 instead of 200 (as it's a 350 scanline screen).
Edit: EGAMELT is running at last! 😁

UniPCemu's EGAMELT output:

Edit: So does beverly hills cop (CPU changed to 8MHz).

Congrats!

There's odd behaviour with the cursor end register though?

After POST, the Cursor End register is zeroed for some odd reason?

Just looked a bit more into the EGA/VGA blink bit in graphics modes.

Apparently, when plane 3 is 0 in 4-bit graphics modes, the top bit (bit 3) is set for the LUT lookup?
So it forces the foreground and background bit 3 to be 1 instead of the simple masked 0 (according to Lotus 1-2-3 2.3)?

https://github.com/86Box/86Box/pull/3845

UniPCemu still leaves it zero right now though.
Edit: Forced the bit 3 to become 1 when blinking isn't enabled on a graphics pixel that has blinking enabled in the attribute controller mode control register.

So the new logic of EGA attribute controller processing is:

1OPTINLINE byte getattributeback(byte textmodeshift, byte attr,byte filter)
2{
3	//Only during text mode: shift!
4	attr >>= textmodeshift; //Shift high nibble to low nibble with text mode!
5	attr &= filter; //Apply filter!
6	return attr; //Need attribute registers below used!
7}
8	byte pixelon, charinnery, currentblink;
9	word Attribute; //This changes!
10	
11	byte color256;
12	color256 = GETBITS(VGA->registers->AttributeControllerRegisters.REGISTERS.ATTRIBUTEMODECONTROLREGISTER,6,1); //8-bit colors?
13
14	byte enableblink;
15	enableblink = GETBITS(VGA->registers->AttributeControllerRegisters.REGISTERS.ATTRIBUTEMODECONTROLREGISTER,3,1); //Enable blink?	
16	
17	byte enableblink2;
18
19	byte underlinelocation;
20	underlinelocation = GETBITS(VGA->registers->CRTControllerRegisters.REGISTERS.UNDERLINELOCATIONREGISTER,0,0x1F); //Underline location is the value desired minus 1!
21	
22	byte textmode;
23	textmode = (GETBITS(VGA->registers->AttributeControllerRegisters.REGISTERS.ATTRIBUTEMODECONTROLREGISTER, 0, 1) == 0); //Are we in text mode?
24
25	byte textmodeshift;
26	textmodeshift = (GETBITS(VGA->registers->AttributeControllerRegisters.REGISTERS.ATTRIBUTEMODECONTROLREGISTER,0,1)==0)?4:0; //Text mode? Also the number of bits to shift to get the high nibble, if used!
27
28	byte monomode;
29	monomode = GETBITS(VGA->registers->AttributeControllerRegisters.REGISTERS.ATTRIBUTEMODECONTROLREGISTER,1,1); //Monochrome emulation mode(attribute) with b/w emulation(misc output)?
30
31	byte graphicsforced;
32	byte effectiveattr;
33	byte fontstatus;
34	byte paletteenable=0;
35	byte palette54=0; //palette 5-4 used?
36	byte colorselect54=0; //Color select bits 5-4!
37	byte colorselect76=0; //Color select bits 7-6!
38	byte backgroundfilter=0,effectivebackgroundfilter;
39	byte VGADisabled = 0;
40	byte palettecopy[0x10];
41
42	paletteenable = GETBITS(VGA->registers->CRTControllerRegisters.REGISTERS.ATTRIBUTECONTROLLERTOGGLEREGISTER,5,1); //Internal palette enabled?
43	INLINEREGISTER byte CurrentDAC; //Current DAC to use!
44	if (paletteenable) //Precalcs for palette?
45	{
46		for (CurrentDAC = 0;CurrentDAC < 0x10;++CurrentDAC) //Copy the palette internally for fast reference!
47		{
48			palettecopy[CurrentDAC] = GETBITS(VGA->registers->AttributeControllerRegisters.REGISTERS.PALETTEREGISTERS[CurrentDAC],0,0x3F); //Translate base index into DAC Base index!
49		}
50		palette54 = GETBITS(VGA->registers->AttributeControllerRegisters.REGISTERS.ATTRIBUTEMODECONTROLREGISTER,7,1); //Use palette bits 5-4?
51		if (palette54) //Use palette bits 5-4?
52		{
53			colorselect54 = VGA->precalcs.colorselect54; //Retrieve pallete bits 5-4!
54		}
55		colorselect76 = VGA->precalcs.colorselect76; //Retrieve pallete bits 7-6!
56	}
57	paletteenable &= ((VGA->precalcs.BypassPalette)?0:1); //Bypass the palette if needed!
58
59	backgroundfilter = ((~(enableblink<<3))&0xF); //Background filter depends on blink & full background when not in monochrome mode!
60

61	INLINEREGISTER byte colorplanes;
62	colorplanes = VGA->registers->AttributeControllerRegisters.REGISTERS.COLORPLANEENABLEREGISTER; //Read colorplane 256-color!
63	colorplanes &= 0xF; //Only 4 bits can be used!
64
65	INLINEREGISTER word pos;
66	INLINEREGISTER word pos2;
67
68		for (pixelon=0;pixelon<2;++pixelon) //All values of pixelon!
69		{
70			for (currentblink=0;currentblink<2;++currentblink) //All values of currentblink!
71			{
72				for (charinnery=0;charinnery<0x20;++charinnery)
73				{
74					//Take the 
75					pos2 = charinnery; //Set!
76					pos2 <<= 1; //Create room!
77					pos2 |= currentblink; //Add!
78					pos2 <<= 1; //Create room!
79					pos2 |= pixelon; //Add!
80
81					for (Attribute=0;Attribute<0x100;++Attribute)
82					{
83						fontstatus = pixelon; //What font status? By default this is the font/back status!
84
85						enableblink2 = enableblink; //Local copy for processing!
86
87						graphicsforced = 0; //Default behaviour!
88
89						effectiveattr = Attribute; //Default: effective attribute!
90						effectivebackgroundfilter = backgroundfilter; //Default: effective background filter!
91						//Underline(text mode)&Off capability!
92						if (unlikely(monomode)) //Only in mono mode do we have underline capability and other stuff!
93						{
94							if (likely(textmode)) //This is active in text mode only!
95							{
96								if (unlikely(charinnery == underlinelocation)) //Underline (Non-graphics monochrome mode only)? Ignore textmode?
97								{
98									if (unlikely((Attribute & 7) == 1)) //Underline used for this character? Bits 6-4=0(not according to seasip.info/VintagePC/mda.html, so ignore that fact!) and 2-0=1 only according to freeVGA!
99									{
100										fontstatus = 1; //Force font color for underline WHEN FONT ON (either <blink enabled and blink ON> or <blink disabled>)!
101									}
102								}
103								if (unlikely((Attribute & 0x77) == 0)) //Are we always displayed as background (values 0, 8, 0x80 and 0x88)?
104								{
105									fontstatus = 0; //Force background!
106								}
107								if ((Attribute & 0xF0) && ((Attribute & 0x77) != 0x70)) //Background set and not inversed?
108								{
109									effectiveattr &= 0xF; //Mask off any background bits!
110								}
111								if (((Attribute & 0x77) != 0x70)) //Not inversed?
112								{
113									effectivebackgroundfilter &= 7; //Never include the blink bit!
114									if ((Attribute & 0x7) == 0) //Font black?
115									{
116										effectiveattr |= 1; //Use font color 1 for example?
117									}
118								}
119							}
120							else //Monochrome Graphics mode (EGA+ only case)?
121							{
122								//Special behaviour! Planes 1/3 are masked off. Planes 0/2 being 0/1 respectively enables blinking.
123								fontstatus = 1; //Default: always font to mask properly!
124								effectiveattr &= 0x55; //Planes 1/3 are always masked off (undocumented EGA behaviour)!
125								enableblink2 = (enableblink ? (((effectiveattr&5)==4)?2:3) : 3); //Enable blinking or forced behaviour!
126							}
127						}
128						else if (!textmode) //Graphics mode?
129						{
130							fontstatus = 1; //Ignore font input by default!
131						}
132
133						//Blinking capability! Applies to the font/background only!
134						if (likely(enableblink2)) //Blink affects font?
135						{
136							if (unlikely(((getattributeback(textmodeshift,(byte)Attribute,0x8) && ((enableblink2&2)==0))) || (enableblink2==2))) //Blink enabled?
137							{
138								fontstatus &= currentblink; //Need blink on to show foreground!
139							}
140							else if (!(monomode | textmode)) //Non-blink bit behaviour in graphics mode is bit 3 forced set for the lookup?
141							{
142								graphicsforced = 8; //Force the bit plane high!
143							}
144						}
145
146						//Determine pixel font or back color to PAL index!
147						if (unlikely(fontstatus))
148						{
149							CurrentDAC = (byte)effectiveattr; //Load attribute!
150						}
151						else
152						{
153							CurrentDAC = getattributeback(textmodeshift,(byte)effectiveattr,effectivebackgroundfilter); //Back!
154						}
155
156						CurrentDAC &= colorplanes; //Apply color planes(4-bits)!
157						CurrentDAC |= graphicsforced; //Forced bits high?
158
159						if ((enableblink2 == 2) && (fontstatus)) //Blinking forced bit 3 in the lookup on?
160						{
161							CurrentDAC |= 8; //High plane: blink on!
162						}
163
164						if (unlikely(paletteenable==0)) goto skippalette; //Internal palette enable?
165						//Use original 16 color palette!
166						CurrentDAC = palettecopy[CurrentDAC]; //Translate base index into DAC Base index!
167
168						if (unlikely(VGADisabled)) goto skippalette; //Are we not on a CGA? Skip the further lookup!
169						if (unlikely(color256)) //8-bit colors and not monochrome mode?
170						{
171							CurrentDAC &= 0xF; //Take 4 bits only!
172						}
173						else //Process fully to a DAC index!
174						{
175							//First, bit 4&5 processing if needed!
176							if (palette54) //Bit 4&5 map to the C45 field of the Color Select Register, determined by bit 7?
177							{
178								CurrentDAC &= ~0x30; //Clear bits 5-4!
179								CurrentDAC |= colorselect54; //Use them as 4th&5th bit!
180							}
181							//Else: already 6 bits wide fully!
182							CurrentDAC &= 0x3F; //Clear the high 2 bits for inserting the selected base!
183							//Finally, bit 6&7 always processing!
184							CurrentDAC |= colorselect76; //Apply bits 6&7!
185						}
186
187						skippalette:
188						pos = Attribute;
189						pos <<= 7; //Create room for the global data!
190						pos |= pos2; //Apply charinner_y, currentblink and pixelon!
191						//attribute,charinnery,currentblink,pixelon: 8,5,1,1: Less shifting at a time=More speed!
192						attributeprecalcs[pos] = CurrentDAC; //Our result for this combination!
193					}
194				}
195			}
196		}

(code unused for CGA/MDA clipped out), VGA->precalcs.BypassPalette is usually 0 for normal EGA/VGA operation (used in some SVGA chips, like the Tseng chips extensions).

The attributeprecalcs variable is basically a lookup table of all input signals and output signals of the attribute controller for any color lookup (the 8-bit/16-bit accumulation shifts etc. is performed after this step). It's inputs are the Attribute(from text mode or graphics pixel), charinner_y(the scanline within the character), currentblink(the current blinking status of the rendering frame) and pixelon(foreground or background pixel in text modes, always 1 in graphics modes).
The lookup table is 32768 bytes large.

GETBITS(x,shift,mask) shifts x to bit 0 and applies mask using an AND operation (basically ((x>>shift)&mask)).

Edit: Lotus 1-2-3 r2.3 now behaves as expected in WYSIWYG mode 😁
(It uses 16-color graphics with blinking bit)

It matches the video now (https://youtu.be/jHUaneVUkfQ)!

I'm getting (as in the video)
(text mode -> graphics mode)
light gray (difficult to see on the video, but probably the case there as well?) on blue -> cyan on blue
black on cyan -> black on cyan
active: cyan, black cursor
inactive: light gray

Another thing that happens is that text that's in a selected text box becomes red in the video (@9:47). The same happens in UniPCemu now!

Nice test case for other emulators as well btw 😉 !

OK. After checking some documentation on SVGA cards wrt the vertical retrace interrupt, I found that it seems that only bit 5 of the vertical retrace end register blocks IRQs. Bit 4 only seems to exist to detect 0 being written to it to clear the IRQ.
Interrupt Status #0 register bit 7 reads the value of the IRQ line.

So writing 1 to bit 4 doesn't have any effect, other than not counting as a 0 write to clear the IRQ. It doesn't block vertical retrace IRQs from the graphics card.

In fact, setting bit 4 to 1 isn't documented at all by the EGA or W32i documentation at all to have any effect?

Edit: And once again, FLAND leaves the flipflop set for some odd reason?