I've managed to get the 1024x768x16 mode work by making the Interlaced mode double vertical timings, as well as adjusting the attribute controller to properly fetch 4-bit planar pixels instead of 8-bit (chunky mode) pixels. I also had to disable the odd/even fields that were emulated for this card, since it split the 1024x768 odd and even rows into two fields(although according to what the manual said, this is only for real monitors, not for rendering simple framebuffers, as my emulator uses?).

800x600 mode gets stuck into a little loop checking AX and jumping back to itself. Maybe it requires a 286+ CPU to be used?

Anyone knows anything about the ET3000 640x480x256 mode? Does it do anything that's ET3000-specific to cause this(since 1024x768 now works, it shouldn't be a horizontal/vertical timing problem)? Or am I missing something?

This is my current progress(running ET3000 drivers on x86EMU commit 2016/06/29 18:58 run using the 80186 CPU(shown as NEC V30(16-bit) or V20(8-bit)):

Anyone can see what's going wrong in the 640x480x256 mode? Is there something wrong with the memory? It looks like it's missing data or uses corrupted data in the 1024x768 mode(which, like the 640x480x256 mode, uses more than 256k memory).

I notice that, when moving the Windows 3.0 mouse from left top to left bottom or from left top to right top, it reappears 2 times in the left top corner, before stopping at the part where the "F" of "File Ma" begins. Anyone can say anything about this? Does this say anything about the fault in rendering or mapping VRAM?

Strangely enough, when moving the mouse cursor from the edge of the top-leftmost screen, I notice that the VRAM banks switch between bank 0 and 2? Bank 0 being the left-top bank and plane 2 being the top-right bank screen(2nd part of the 3 parts of the top)? All accesses are set as 64k banks.

Anyone can tell me anything about this?

Is map 0 mapped to 0x00000-0x10000, etc. e.g. the address in VRAM is 0x10000(64k), 0x20000(128k) or 0x100000(1M) times the bank set, then the offset is added for the actual VRAM address(after applying the plane)?

So(in planar mode):
VRAM address = (bank number * 0x10000) + (offset * 4) + plane.

What's the difference between OE mode 0 and 1(as mentioned in the ET4000 manual)?
Why does the planar mapping use PLX and PLY, which map to PL0 or A16 and PL1 or A17? What makes it use PL0/1 vs A16/17? I can't find anything about that in the documentation?

Is this correct?

I've made a little dump, as createn by a little Turbo Pascal program(with a seperate pascal module(Turbo Pascal unit) abstracting the whole softdebugger I/O away).
The program just goes from left to right on the display buffer, and plots vertical lines with all 256 colors. This is done after enabling the x86EMU's new VGA memory logging function using the softdebugger emulated hardware, finally trying to disable it(which it fails at for some reason, according to it's log). Finally to quit and return to the MS-DOS prompt in mode 02h(80x25 text mode).

When looking at what it's doing, I notice that it indeed draws correctly vertically. However, horizontally it goes from the left edge to the right edge of the screen, returns to the left edge 2 times when executing, only to stop about 1/3 screen when having drawn all 640 horizontal pixels.

It looks like either the renderer is messing up, or the VRAM access itself is buggy?

Btw, the code of the program and unit can be found in the x86EMU repository:
Main program: https://bitbucket.org/superfury/x86emu/src/8a … S.PAS?at=master
x86EMU unit(abstracting the communication with x86EMU away): https://bitbucket.org/superfury/x86emu/src/8a … U.PAS?at=master

Anyone can see what's going wrong, based on the log createn by the application(with x86EMU itself logging the information it's requesting)?

Edit: I've made a little revision on the dumping: The program now precalculates the 640 horizontal pixels(Horizontal 256-color pattern) and draws the pixels linearly. Also the log itself has been extended to include the full VRAM address excluding the planes(the planes are simply OR'ed into the lower 2 bits to generate the full index in 512K VRAM). Usually the planes would contain the four linear pixels, would it not? So plane 0 contains the pixels MOD 4, plane 1 contains pixels MOD 4 + 1, plane 2 contains pixels MOD 4 + 2 and plane 3 contains pixels MOD 4 + 3? But the linear pixel coordinates written(0-640) are addressed in planar form instead of chunky 8-bit format? Is this even correct?
Shouldn't it write pixel 0 to index 0 plane 0, pixel 1 to index 0 plane 1, pixel 2 to index 0 plane 2, pixel 3 to index 0 plane 3, pixel 4 to index 0 plane 4 etc.? So it should be using Chain-4 mode instead of planar mode(The VRAM Memory Window addresses are linearly addressed, as are the pixels written using BIOS int10h function C(put pixel)? Why isn't the Chain-4 bit(Sequencer mode control register) set?

Edit: Looking at the dumped Sequencer registers during mode 2Eh, I notice something strange:
The dump contains:
00=03
01=03
02=0F
03=00
04=06

While it should be(accordign to the ET4000 documentation):
00=03
01=01
02=0F
03=00
04=0E

So it, while setting most bits, also sets bit 1(undefined) or register 01h, while not setting the required bit 3(Chain 4 mode) of the Sequencer Memory Mode control register? Anyone knows anything about this?

Just tried the same software with the ET4000 emulation(and ET4000AX BIOS). That one correctly uses chain 4 mapping?

Also, when trying to boot using the ET4000(+ET4000AX BIOS) with ET3000(Windows 3.0) drivers, I get a bit strange output:

Is there any way to validate my emulator's (S)VGA(ET3000/ET4000 vs VGA) memory mapping? By dumping video memory and comparing it to what the actual hardware uses?

I strongly recommend to get a real ET3000/ET4000 if you develop an emulation. From own experience programming just from documentation for such extremely close to hardware projects works only in rare circumstances.
Also be aware that in details ET4000 differ by chip revision as can be seen e.g. in the Copper demo.