After the latest fix to the ET4000 DAC(16 vs 15-bit color detection, although I've made a typo in the commit saying 15-bit vs 16-color instead), this is the result of the WHATVGA application running the 16-bit DAC test:

Normal mode:

Other(Color) mode, toggable by pressing +:

Dosbox capture of the same screen(+ has no effect):

I've tried improving the DAC processing, but it still doesn't seem fully correct:

1OPTINLINE void VGA_ActiveDisplay_noblanking_VGA(VGA_Type *VGA, SEQ_DATA *Sequencer, VGA_AttributeInfo *attributeinfo)
2{
3	uint_32 DACcolor; //The latched color!
4	INLINEREGISTER byte doublepixels=0;
5	if (hretrace) return; //Don't handle during horizontal retraces!
6	//Active display!
7	if (VGA->precalcs.DACmode&2) //Hi-color mode?
8	{
9		//Latch a part?
10		if (VGA->precalcs.DACmode&4) //To use split latching?
11		{
12			//Special 4-bit(nibble) latching!
13			Sequencer->lastDACcolor >>= 4; //Latching 4 bits, whether used or not!
14			Sequencer->lastDACcolor |= ((attributeinfo->attribute & 0xF)<<12); //Latching this attribute! Low byte is latched first!
15
16			if ((++Sequencer->DACcounter)&3) //To latch and not process yet? This is the least significant byte/bits of the counter!
17			{
18				return; //Skip this data: we only latch every two pixels!
19			}
20		}
21		else //Normal 8-bit(byte) latching?
22		{
23			Sequencer->lastDACcolor >>= 8; //Latching 8 bits, whether used or not!
24			Sequencer->lastDACcolor |= ((attributeinfo->attribute & 0xFF)<<8); //Latching this attribute! Low byte is latched first!
25
26			if ((++Sequencer->DACcounter)&1) //To latch and not process yet? This is the least significant byte/bits of the counter!
27			{
28				return; //Skip this data: we only latch every two pixels!
29			}
30		}
31	}
32	else //Latch every pixel!
33	{
34		Sequencer->lastDACcolor = attributeinfo->attribute; //Latching this attribute!
35	}
36
37	doublepixels = ((1<<VGA->precalcs.ClockingModeRegister_DCR)<<attributeinfo->attributesize)-1; //Double the pixels(half horizontal clock) and multiply for each extra pixel clock taken?
38	if (VGA->precalcs.DACmode&4) //Double the pixels drawn?
39	{
40		doublepixels = ((doublepixels+1)<<1)-1; //Double the pixels to draw if requested!
41	}
42
43	drawdoublepixel:
44	//Draw the pixel that is latched!
45	if (VGA->precalcs.DACmode&2) //16-bit color?
46	{
47		DACcolor = (Sequencer->lastDACcolor&0xFFFF); //Always use 16-bits!
48				
49		//Now draw in the selected color depth!
50		if (VGA->precalcs.DACmode&1) //16-bit color?
51		{
52			drawPixel(VGA, CLUT16bit[DACcolor]); //Draw the 16-bit color pixel!
53		}
54		else //15-bit color?
55		{
56			drawPixel(VGA, CLUT15bit[DACcolor]); //Draw the 15-bit color pixel!
57		}
58	}
59	else //VGA compatibility mode? 8-bit color!
60	{

61		DACcolor = (Sequencer->lastDACcolor&0xFF); //Only use 8-bits!
62		drawPixel(VGA, VGA_DAC(VGA, DACcolor)); //Render through the 8-bit DAC!
63	}
64	++VGA->CRTC.x; //Next x!
65	if (doublepixels) //More than 1 clock generated?
66	{
67		--doublepixels; //Duplicate the pixel!
68		goto drawdoublepixel;
69	}
70}

As well as the CLUT:

1	for (i = 0;i < 0x10000;++i) //Create the 16&15-bit CLUT!
2	{
3		CLUT16bit[i] = RGB((byte)(((((float)(i & 0x1F)) / (float)0x1F)*255.0f)), (byte)(((float)((i >> 5) & 0x3F) / (float)0x3F)*255.0f), (byte)((((float)((i >> 11) & 0x1F) / (float)0x1F)*255.0f))); //16-bit color lookup table (5:6:5 format)!
4		CLUT15bit[i] = RGB((byte)(((((float)(i & 0x1F)) / (float)0x1F)*255.0f)), (byte)(((float)((i >> 5) & 0x1F) / (float)0x1F)*255.0f), (byte)((((float)((i >> 10) & 0x1F) / (float)0x1F)*255.0f))); //15-bit color lookup table (5:5:5 format)!
5	}

The rendering mode is still set the normal way by the ET4000 emulation:

1	if ((whereupdated==WHEREUPDATED_ALL) || (whereupdated==WHEREUPDATED_DACMASKREGISTER)) //DAC Mask register has been updated?
2	{
3		et4k_tempreg = et34k(VGA)->hicolorDACcommand; //Load the command to process! (Process like a SC11487)
4		DACmode = VGA->precalcs.DACmode; //Load the current DAC mode!
5		if ((et4k_tempreg&0xC0)==0x80) //15-bit hicolor mode?
6		{
7			DACmode &= ~1; //Clear bit 0: we're one bit less!
8			DACmode |= 2; //Set bit 1: we're a 16-bit mode!
9		}
10		else if ((et4k_tempreg&0xC0)==0xC0) //16-bit hicolor mode?
11		{
12			DACmode |= 3; //Set bit 0: we're full range, Set bit 1: we're a 16-bit mode!
13		}
14		else //Normal 8-bit DAC?
15		{
16			DACmode &= ~3; //Set bit 0: we're full range, Set bit 1: we're a 16-bit mode!
17		}
18		if (et4k_tempreg&0x20) //Two pixel clocks are used to latch the two bytes?
19		{
20			DACmode |= 4; //Use two pixel clocks to latch the two bytes?
21		}
22		else
23		{
24			DACmode &= ~4; //Use one pixel clock to latch the two bytes?
25		}
26		VGA->precalcs.DACmode = DACmode; //Apply the new DAC mode!
27	}

Anyone can see if there's something wrong there? The RGB(r,g,b) is a normal RGB to 32-bit integer value(uint_32) conversion(Depending on the system(SDL flags), usually (R<<16)|(G<<8)|(B) on Windows with it's BGR format).

Anyone can tell me the correct format used on the Sierra Hi-color DAC's 32k and 64k color modes? My current code uses the low 5 bits for red, middle 5(32k) or 6(64k) bits for green and upper 5 bits for blue. Is that correct?

My renderer spits out nibbles(default during the 32/64k graphics modes, unless the 8-bit color enable is set in the Attribute Mode Control, which will combine every 2 outputted nibbles into a 8-bit value before sending it to the DAC.

Bit 8 of the Sierra DAC control register enables the 64/32k modes instead of the normal 8-bit RGB translation. This will combine four 4-bit values(on 4 clocks) into a single 16-bit pixel when bit 5 is set in the DAC Control Register, which is translated to RGB using a 65k indexed RGB lookup table(32k or 64k format have seperate lookup tables).
When bit 5 is cleared during 32k/64k modes, it will combine the pixels outputted(either two nibbles or two 8-bit values, depending on what the attribute controller supplies(8-bit color enable setting)) into a single 16/15-bit color(with bits 4-7 and 12-15 cleared, while bits 0-3 and 8-11 contain the gotten pixel values).

Is that Sierra Hi-color DAC behaviour correct?

I've just adjusted the DAC processing to be about the same as the Sierra Hi-color DAC (whole range of numbers) datasheet:

1OPTINLINE void VGA_ActiveDisplay_noblanking_VGA(VGA_Type *VGA, SEQ_DATA *Sequencer, VGA_AttributeInfo *attributeinfo)
2{
3	uint_32 DACcolor; //The latched color!
4	INLINEREGISTER byte doublepixels=0;
5	if (hretrace) return; //Don't handle during horizontal retraces!
6	//Active display!
7	if (VGA->precalcs.DACmode&2) //Hi-color mode?
8	{
9		if (VGA->precalcs.DACmode&4) //DAC Hi-color mode 2? Latch in 1 rising clock!
10		{
11			Sequencer->lastDACcolor = attributeinfo->attribute; //Latching this attribute! Latch in one go!
12		}
13		else //DAC Hi-color mode 1? We're latching in 2 half-clocks!
14		{
15			//Latch a 8-bit pixel?
16			Sequencer->lastDACcolor >>= 8; //Latching 8 bits, whether used or not!
17			Sequencer->lastDACcolor |= ((attributeinfo->attribute & 0xFF)<<8); //Latching this attribute! Low byte is latched first!
18
19			if ((++Sequencer->DACcounter)&1) //To latch and not process yet? This is the least significant byte/bits of the counter!
20			{
21				return; //Skip this data: we only latch every two pixels!
22			}
23		}
24	}
25	else //Pseudo-color mode?
26	{
27		Sequencer->lastDACcolor = attributeinfo->attribute; //Latching this attribute!
28	}
29
30	doublepixels = ((1<<VGA->precalcs.ClockingModeRegister_DCR)<<attributeinfo->attributesize)-1; //Double the pixels(half horizontal clock) and multiply for each extra pixel clock taken?
31	if ((VGA->precalcs.DACmode&6)==2) //Multiple inputs are taken?
32	{
33		doublepixels = ((doublepixels+1)<<1)-1; //On top of the attribute doubling the clocks used, we (qua)druple it again! 
34	}
35
36	drawdoublepixel:
37	//Draw the pixel that is latched!
38	if (VGA->precalcs.DACmode&2) //16-bit color?
39	{
40		DACcolor = (Sequencer->lastDACcolor&0xFFFF); //Always use 16-bits!
41				
42		//Now draw in the selected color depth!
43		if (VGA->precalcs.DACmode&1) //16-bit color?
44		{
45			drawPixel(VGA, CLUT16bit[DACcolor]); //Draw the 16-bit color pixel!
46		}
47		else //15-bit color?
48		{
49			drawPixel(VGA, CLUT15bit[DACcolor]); //Draw the 15-bit color pixel!
50		}
51	}
52	else //VGA compatibility mode? 8-bit color!
53	{
54		DACcolor = (Sequencer->lastDACcolor&0xFF); //Only use 8-bits!
55		drawPixel(VGA, VGA_DAC(VGA, DACcolor)); //Render through the 8-bit DAC!
56	}
57	++VGA->CRTC.x; //Next x!
58	if (doublepixels) //More than 1 clock generated?
59	{
60		--doublepixels; //Duplicate the pixel!

61		goto drawdoublepixel;
62	}
63}

Also the 16-bit and 15-bit CLUT have been updated according to documentation:

1	for (i = 0;i < 0x10000;++i) //Create the 16&15-bit CLUT! The format is Red on MSB, Green in the middle and Blue in the LSB.
2	{
3		CLUT16bit[i] = RGB((byte)(((((float)((i >> 11) & 0x1F)) / (float)0x1F)*255.0f)), (byte)(((float)((i >> 5) & 0x3F) / (float)0x3F)*255.0f), (byte)((((float)((i >> 0) & 0x1F) / (float)0x1F)*255.0f))); //16-bit color lookup table (5:6:5 format)!
4		CLUT15bit[i] = RGB((byte)(((((float)((i >> 10) & 0x1F)) / (float)0x1F)*255.0f)), (byte)(((float)((i >> 5) & 0x1F) / (float)0x1F)*255.0f), (byte)((((float)((i >> 0) & 0x1F) / (float)0x1F)*255.0f))); //15-bit color lookup table (5:5:5 format)!
5	}

Now, the normal mode is stil the same (it uses VGA-mode rendering for some strange reason on my 8088 emulation, combined with the DAC set to mode 7h(DAC Command Register set to E0h). Logically speaking, the ET4000 should be set to use mode E0h(DAC) with Hi-resolution 16-bit colors set in Attribute Controller register 16h bits 4-5(set to 11b)? But for some reason, the Attribute Controller register is set to 00h(Indicating VGA mode???)?

Screen capture after pressing + now:

I've just tried the given code on the ET3000 graphics card emulation:

I'm currently rethinking something: what do bits 6-7 on the ET3000 port 3CDh do?

13CDh (R/W): Segment Select
2bit 0-2  64k Write bank number
3    3-5  64k Read bank number
4    6-7  Segment Configuration.
5           0  128K segments
6           1   64K segments
7           2  1M linear memory

I understand that the 1M linear memory changes the VGA to use linear mode(planes 0,1,2,3 chained, just like the normal memory modes, but what do the 64k segments/128k segments do? The bank number always selects a 64k bank? So what does it change? The memory addressed by the CPU? The memory addressed by the ET3000 rendering?

I've looked at what the WHATVGA application does when it tries to test the 64K color mode. It, for some reason, doesn't set the Linear Graphics mode(as documented in the ET4000 documentation), not even on the ET3000? So it starts reading and writing VRAM in planar mode(while it's format suggests(when forcing linear mode)) that it's expecting the Linear Graphics mode, even though the Chain-4 bit isn't set? Anyone can explain this? Or does this mean there's a serious bug in my CPU emulation?

What's set on a real ET3000 w/ Sierra Hi-color DAC?

Edit: I've left the used base mode at the default mode, but it should be a 256-color modes as far as I remember the list of base modes. Since it uses a 256-color base mode(confirmed in the rendering), it should enable the Linear Graphics mode by setting the Chain-4 bit(bit 3) in the Sequencer Memory Mode register? Anyone knows if there's a reason the ET3000 BIOS doesn't set it? Is this a bug in my 8088 CPU emulation? Vladstamate?

superfury wrote:

I understand that the 1M linear memory changes the VGA to use linear mode(planes 0,1,2,3 chained, just like the normal memory modes, but what do the 64k segments/128k segments do? The bank number always selects a 64k bank? So what does it change? The memory addressed by the CPU? The memory addressed by the ET3000 rendering?

I would assume the memory addressed by the CPU. As the programmer would set the memory access mode then go ahead and right bytes. It **could** also impact the GPU pattern of memory accessing as well, but I am not sure about that. I think all that the scheme for different segment sizes is to allow more memory to be accessed on the card itself from the CPU point of view (and therefore programmers').

That would make the most sense to me, but I am not 100% sure.

Well, what's the point in the 64k and 128k modes? The normal VGA registers already supply those:
mode 0. A0000-BFFFF 128k
mode 1. A0000-AFFFF 64k
mode 2. B0000-B8000 32k
mode 3. B8000-BFFFF 32k

Modes 1&2 already provide a 128k and 64k window into VRAM. What does the 64k/128k toggle add to that? 1M above 1M I understand, but what's the purpose of the 64k/128k setting? What does it affect, and how? Also, where above 1M does the 1M toggle place the window? Directly at physical address 100000h?

Edit: What about the bank sizes in 1M mode? Are they 64k, 128k or ignored completely?

No I do not think it means that. The 0x3CD register allows you to access from the CPU video memory up to 1 MB. You either do it as linear memory if bits 6-7 are 2 (which then I think ignores bits 0-5). Or segmented of up to 8 segments of either 64k or 128k (which also gives you 1 Mb of memory). The normal VGA only sees 128k (0xA0000 - 0xBFFFFF) so I assume ET3000 allows to you to see all of its 1Mb of onboard RAM.

As to the question of where the linear 1Mb is mapped I do not know. For the rest (64k and 128k segments) I assume the mapping is the old 0xA0000 - 0xAFFFF/0xBFFFF.

Could it be that bits 0-5 actually are the base address of the 1MB RAM aperture, but starting at 1MB with bits 0-5=0. So linear address X can be found at linear memory access (((port 3CD&3F)+1)<<20)|X. Essentially the low 6 bits of 3CD function as the high VRAM base address? Since there's no seperate register for it?
Edit: Maybe even low 7 bits SHL 20 is it's base? Since value 3 is 'undefined' or undocumented?
Edit: Since the ET4000 says something about mapping the high 4 bits to the 64k segment(instead of the normal bits 0-3/4-7 of port 3CD in linear mode), it seems to use something else to provide the high 12 bits. Maybe it uses the 7 remaining bits on port 3CD on the ET3000 and the full 8 bits on the ET4000? It cannot map below 1MB, so probably 1MB is added to that base address? So effectively the formula becomes:
(((Port3CD&0x7F)+1)<<20)|X for byte #X in VRAM on the ET3000
((((Port3CD&0xFF)+1)<<20)|X for byte #X in VRAM on the ET4000

Anyone can confirm that?

Just speculating here, but maybe the selection between 64k/128k pages mean you can access whole 1MB video memory through 16 pages of 64k at 0xA0000-0xAFFFF, or 8 pages of 128k at 0xA0000-0xBFFFF?

vladstamate wrote:

As to the question of where the linear 1Mb is mapped I do not know.

There's a register for that too, at least in ET4000/W32p model you can select one out of 256 possible 4MB memory areas, so it can be anywhere within the first 512 megabytes of memory. Obviously handy only in a VLB/PCI environment. Don't know about other models, maybe a chip living in a 16-bit ISA bus can select an area within first 16MB.

Dosbox simply maps the base of the memory window to 64k*lower or upper 3(ET3000)/4(ET4000) bits depending on reads/writes. 64k becomes 128k when bits 6-7 are 0 instead. Also Dosbox ignores bit 7 of port 3CD, mapping modes 2/3 to 0/1 instead(that cannot be correct?). So setting the Window to A0000-BFFFF, 3CD to 0x89, writing to address A0001 will(during Chain-4 mode) write a byte to address 0x20001 in VRAM?

I've just implemented the ET3000 and ET4000 CRT and various other registers dumping and added it to the VGA Dump option in the Settings menu. Dumping the registers shows the following, while rendering the WHATVGA default video mode(not configured when starting WHATVGA's 16-bit DAC test mode):
- All CRTC registers of the ET3000 are cleared.
- 3C0 register 16 contains 10h(which is odd: according to the documentation, this means nothing? Bits 4-5 can have the following values: 0=VGA-compatible, 1=???, 2=256-color Hi-res(same as mode 3 when output to the DAC, but using the 8-bit mode of the VGA? Essentially a rising clock with the 8-bit VGA value(Just like the Attribute Controller 8-bit color enable bit does), then a lowering clock containing 00h for the 16-bit DAC?), 3=16-bit mode)
- 3C0 register 17 is cleared.
- 3C4 register 06 is cleared(Extended Sequencer register).
- 3C4 register 07 is set to A8h.
- Hercules Compatiblity mode register contains 01h(Extended memory on Hercules, probably due to enabling the extended SVGA modes, if any?).
- The Segment Select register contains 49h(Read/Write block 1; 64k mode)
- All remaining registers are cleared(Hi-color DAC command register of the Sierra Hi-color DAC; CGA mode&color and MDA compatiblity registers; Extended Feature control bits).

It strikes me as odd that the CRTC registers are all zeroed out. Is this correct for this mode?

http://files.mpoli.fi/unpacked/software/progr … 3.zip/tseng.txt

Can anyone make a ET3000 (S)VGA register dump of all registers to compare with my dump? Then at least I can see what's going wrong. Also, does WHATVGA work properly with an ET3000 8-bit color on a XT? (I'm using mode 2E 640x480x256 mode afaik). I'm testing the 64K mode of the Sierra Hi-color DAC with that mode.

This is the current result of the WhatVGA's 64k color test(using the default display mode settings):

Anyone can see what's going wrong? Is this simply because of some bug in my 8086 emulation? Does WHATVGA's 64k color mode even work on a 8086/8088 CPU?

Edit: Seeing as the results change when I open and close the Settings menu(which completely(WHEREUPDATED_ALL is used as it's parameter to update all VGA registers and CRTC timings) updates the precalcs used in the (S)VGA emulation) during the drawing process and after the drawing has finished changes the output, this leads me to believe that there's actually a problem with calculating the precalcs somewhere? So the precalcs aren't updated in 100% of the cases where it needs to be updated?

VGA precalcs: https://bitbucket.org/superfury/unipcemu/src/ … lcs.c?at=master
ET3k/ET4k precalcs override: https://bitbucket.org/superfury/unipcemu/src/ … eng.c?at=master

The VGA precalcs always execute first, with the ET3k/ET4k precalcs overriding the applied VGA precalculations. This way the tseng emulation overrides the basic VGA functionality with it's extended values. Apparently the Tseng SVGA cards don't apply to all required cases of the VGA or Tseng registers being updated, seeing as manually forcing a full update seems to change it's precalcs compared to leaving it alone?

Anyone can see what's going wrong in the (S)VGA precalcs? Some things seem not updating correctly?

Edit: I've made a little log of all SVGA precalcs handling it doesn't respond to, which includes the booting of course, but also the DAC 16-bit color test(which is at the end):

The numbers given are hexadecimal values containing of an OR value of what's changed (in the (S)VGA register set):

1//ALL update? (for init)
2#define WHEREUPDATED_ALL 0x0000
3//Section update (from section below), flag. This updates all register within the section!
4#define WHEREUPDATED_ALL_SECTION 0x10000
5
6//Section (used when not all). This is OR-ed with the data index!
7#define WHEREUPDATED_GRAPHICSCONTROLLER 0x1000
8#define WHEREUPDATED_SEQUENCER 0x2000
9#define WHEREUPDATED_CRTCONTROLLER 0x3000
10#define WHEREUPDATED_ATTRIBUTECONTROLLER 0x4000
11#define WHEREUPDATED_DAC 0x5000
12
13//Rest registers (used when not all)
14#define WHEREUPDATED_MISCOUTPUTREGISTER 0x6000
15#define WHEREUPDATED_FEATURECONTROLREGISTER 0x7000
16#define WHEREUPDATED_INPUTSTATUS0REGISTER 0x8000
17#define WHEREUPDATED_INPUTSTATUS1REGISTER 0x9000
18#define WHEREUPDATED_DACMASKREGISTER 0xA000
19#define WHEREUPDATED_INDEX 0xB000
20
21//CGA horizontal/vertical timing
22#define WHEREUPDATED_CGACRTCONTROLLER_HORIZONTAL 0xC000
23#define WHEREUPDATED_CGACRTCONTROLLER_VERTICAL 0xD000
24//CGA misc CRT registers!
25#define WHEREUPDATED_CGACRTCONTROLLER 0xE000
26
27//All index registers that can be updated!
28#define INDEX_GRAPHICSCONTROLLER 0x1
29#define INDEX_SEQUENCER 0x2
30#define INDEX_CRTCONTROLLER 0x3
31#define INDEX_ATTRIBUTECONTROLLER 0x4
32#define INDEX_DACWRITE 0x5
33#define INDEX_DACREAD 0x6

The code is simply an OR value(except value 0, which is when all registers are to force update(WHEREUPDATED_ALL)) of the actual register that's been modified according to the VGA register update. It consists of a category(all lines up to WHEREUPDATED_CGACRTCNTROLLER) or-ed with either the INDEX defines(for WHEREUPDATED_INDEX only) or the entry within that category, which is the value of the index register that has been used to update the value in the (S)VGA precalcs. So if the CRTC index 0x15 has been updated, the code is 0x3015.

Anyone can see if any registers have any effect on the SVGA that's not handled enough in the SVGA precalcs overrides?

So it, at least, doesn't seem to handle any accesses to:

1Misc Output register
2Attribute Controller Index
3Sequencer register 00h
4Sequencer register 02h
5Sequencer register 03h
6Sequencer register 04h
7Sequencer register 06h
8CRTC register 03h
9CRTC register 05h
10CRTC register 08h
11CRTC register 0Ah
12CRTC register 0Bh
13CRTC register 11h
14CRTC register 14h
15CRTC register 16h
16CRTC register 17h
17Attribute Controller 00h-0Fh
18Attribute Controller 10h-14h
19Graphics Controller 00-08h

Is it missing any overrides that need to activate on the SVGA within that list(VGA registers that need to be (partly) ignored or combined with SVGA registers to work)?

superfury wrote:

Also, does WHATVGA work properly with an ET3000 8-bit color on a XT? (I'm using mode 2E 640x480x256 mode afaik). I'm testing the 64K mode of the Sierra Hi-color DAC with that mode.

Hi superfury, I tried my ET3000 in my XT machine..
And the good news is: Well, yes, WHATVGA istelf does run on a PC/XT with 8088 processor.
The bad new is, however, my card does only offer 512KiB, a normal DAC and I can't disable the on-board CGA.
So I'm afraid any serious testing is gonna fail. Anyway, I took some pictures for you.

That does at least confirm something goes wrong when setting up the video mode by the BIOS(thus, other than the emulated ET3000/ET4000's precalcs problem), this is probably a problem with my CPU emulation itself(seeing as Prince of Persia also does strange things when using MIDI output, which doesn't happen when the MPU-401 isn't emulated).

I'm going to try and dump the instructions executed by the video interrupt call to set the video mode(INT 10h mode 2Eh) to verify if the CPU is doing something wrong there(it probably is, as it's executing strange things in some cases).

Edit: I've made a little log about WIndows 3.0 entering mode 2E(640x480x256). It might contain information about why the video mode goes so awfully wrong. Windows does boot on the 80186(NEC V30) emulation, but I receive an error message now, which is ridiculously large and only partially on the display.

Anyone can see if there's something wrong there?

Edit: I've checked the log until 00:04:43:58.04448, where it's busy processing the DAC color entries. Everything until that point seems to process the registers (Sequencer, CRT, Graphics controller, Misc registers) correctly.

Edit: A screen capture of current progress:

Does this meean that the memory is wrapping too much? Seeing as the lines break up halfway or earlier consistently, it seems there might be a problem in scanline offsets(offset register incorrect?)?

I've improved the precalcs some. Now it gives me strange stuff after opening the Task manager of Windows 3.0 and closing it:

Anyone can see what's going wrong here?

Edit: One thing I've noticed is that the ET3000 BIOS loads most registers from a ROM table, but the Sequencer Memory Mode register is set up for planar access(instead of linear memory)? The rest of the hardware seems correctly set up for 8-bit linear graphics.

Anyone knows why the chain-4 isn't set on the ET3K?

I've just patched the ET3000/ET4000's new precalcs for memory modes to patch the incorrect Sequencer Memory Mode register value of 6 to apply memory as if it's set to 0xE instead(temporary patch). Now Windows 3.0 shows better content, but WHATVGA shows something really strange:

It looks like memory is being wrapped around a very small address, seeing as it's overwriting memory in an invalid-location way(that's what it looks like to me)?