At 320x200 resolution? Never seen that before. But if you can make it support SVGA or VESA there are well documented ways to do that.
VGA won't do 256 colors at a resolution sufficient for a GUI such as Windows, if I'm not mistaken.

keenmaster486 wrote:

At 320x200 resolution? Never seen that before. But if you can make it support SVGA or VESA there are well documented ways to do that.
VGA won't do 256 colors at a resolution sufficient for a GUI such as Windows, if I'm not mistaken.

Does 360x480 at standard VGA refresh rates count? Sure it is enough for some game UI and graphics, but for Windows, maybe not.

superfury wrote:

My emulator, x86EMU, properly supports full VGA emulation. Windows 3.0, however, seems to only use the 16-color planar video mode (mode 12h) or it's monochrome variant (mode 11h). Mode 13h isn't used with the VGA and VGA Monochrome modes. Anyone knows how to make Windows 3.0 use the 256-color mode?

Um, maybe I misunderstand what you're trying to do, but Windows 3.0 MME shipped with a 320x200, 256col. driver.
I think it used an MCGA graphics mode, but I'm not completely sure.
It also had several other interesting VGA drivers included, like palettized ones.
The only downside is, that Windows 3.0 MME required an AT compatible enironment (+286).
At least under normal circumstances. Maybe you're able to patch its driver (mcga256.drv) for your purposes.
There was also a special edition for the Intel Inboard 386, which ran in 386 enhanced mode on a XT class machine.

If you need somthing more real-mode friendly, you can also use a Windows 2.x device driver together with a
normal edition of Win 3.0. I had success doing this with Windows 3.0a, for example.
After you installed the driver of your choice, you have to execute Win 3.0 with the /r parameter.
It looks a bit funny, though! And you're then using the older palette scheme.. ^^
If you like to try this yourself, be sure to not use Windows/386 drivers, but normal Windows 2.0 real-mode drivers.

Oh and speaking of Windows 2.x, it also shipped with a VGA driver, you know..
It didn't use the common 640x480 mode (12h), but a 640x400 mode.
Maybe you can modifiy this one more easily than the VGA 3.0 driver from Windows 3.0.

keenmaster486 wrote:

At 320x200 resolution? Never seen that before. But if you can make it support SVGA or VESA there are well documented ways to do that.
VGA won't do 256 colors at a resolution sufficient for a GUI such as Windows, if I'm not mistaken.

Now, that I'm thinking about this, there were indeed a lot of strange video modes available in the late 80s!
For example, those Paradise drivers had a 640x400, 256 colour mode.
Maybe to save video memory (it fits in 256 KibiByte) or to match the old standard resolution ?

Besides, some of these drivers used weird resolutions like 720 x 540 or 640 x 450 to support
fixed-frequency monitors or otherwise limited cards. Wonderful, isn't it ? 😀

I implemented the Tseng Labs ET4000 in my emulator, with the VGA BIOS(The ET4000 BIOS crashes the poor 80186 CPU emulation(probably 80286+ instructions)).

When I try to boot it in it's 640x480x16 mode, it runs without problems. Anything higher than 640x480 makes Windows 3.0 crash with a divide by zero error when starting the GUI(After the initial logo).

So the 16-color mode works fine. But when I use the 640x480x256 mode, I end up with a strange planar graphics mode, 4-bit pixels(Essentially 640x480x16 with messed up graphics interleaved on the screen). Why doesn't it set the 8-bit color mode(either by the VGA Graphics registers standard or the extended ET4000 VGA Attribute register that specifies VGA Mode/8-bit color/16-bit color?

BTW, I'm using the ET3000 Windows 3.0 drivers on the 80186 CPU with VGA BIOS(Couldn't find ET3000 BIOS).

I've improved the ET4000 with better memory support and graphics decoding/conversion:
https://bitbucket.org/superfury/x86emu/src/6e … mmu.c?at=master
https://bitbucket.org/superfury/x86emu/src/6e … 000.c?at=master
https://bitbucket.org/superfury/x86emu/src/6e … cer.c?at=master
https://bitbucket.org/superfury/x86emu/src/6e … ode.c?at=master

When I try to run Windows 3.0 with anything higher than 640x480x16 it'll crash with a divide error (emulated NEC V30).
When I run Windows 3.0 with the supplied 640x480x16 it runs without problems.
When I run Windows 3.0 with the supplied 640x480x256 it keeps filling the screen with junk data (all orange on black). During this time video data is read from the VGA planes as planar graphics(1 bit from each of the four planes), instead of 256-color(2x4 bits per plane). Does this have something to do with using a VGA BIOS instead of a ET3000 BIOS? I don't have a working ET3000 one, only an ET4000, which crashes the BIOS when initializing. Can a VGA BIOS work with the Windows 3.0 ET3000 driver?

Anyone can see what's going wrong?

I've managed to get it working somewhat using the original ET3000 BIOS. For some reason, the mouse is extremely large on the screen(also moving very fast and reappearing on the left side several times when going from top left to the top right of the display(Windows 3.0 desktop).

I notice that the VRAM location (where it reads all four planes at once) gets increased by four every four fetches (the other three fetches fetch the same plane again).

Both the character clock shift (CRTC Mode Control DIV2 and DIV4: Divide memory address clock by 2 and 4) and the CRTC Mode Control Byte/Word/DWord are set to DWORD (DIV4 bit in the Underline register and Double word addressing are enabled. This causes:
1. The DIV4 Divides the increasing address (every 8 pixel drawn) by four, resulting in the Memory Address clock only going to the next item once every four character clocks(8*4=Every 32 displayed pixels).
2. The DWord mode multiplies this number by four, making the plane index retrieved increase 4 plane positions every time the character clock increases.

This results in the following character clocks on a scanline(1 character clock=8 pixels):
1. Set of pixels loads from address 0(first position caused by the DIV4)
2. Set of pixels loads from address 0(")
3. Set of pixels loads from address 0(")
4. Set of pixels loads from address 0(")
5. Set of pixels loads from address 4(second position caused by the DIV4)
6. Set of pixels loads from address 4(")
7. Set of pixels loads from address 4(")
8. Set of pixels loads from address 4(")
9. Set of pixels loads from address 8(third position caused by the DIV4)

Is this even correct? How does the Divide memory address clock by 1/2/4 and Byte/Word/DWord Memory address counter combine? My input is the horizontal position from the character generator (Thus the current horizontal character, where each character width is 8 or 9 pixels wide). It's output should be the VRAM plane address to retrieve data from(from planes 0-3 latched for splitting into pixels according to packed-pixel(used in 256-color modes), single shift(Used in planar modes, like 16-color 640x480 mode) or interleaved shift(used in the CGA 4-color graphics modes)).

The freeVGA only explains the character clock, as used in the monitoring timing (Overscan, Active display, Retrace and Blanking): http://www.osdever.net/FreeVGA/vga/vgacrtc.htm
It doesn't give any information, besides the registers and their meaning, about those two registers (Divide memory address clock by 1, 2 or 4 and Byte/Word/DWord Memory addressing).

Anyone can tell me how exactly those two influence rasterizing of the active display?

I've implemented the Byte/Word/DWord Memory modes according to the documentation, but it seems that the ET3000 won't ever set the 256-color mode bits (both Attribute controller index 16h and the Miscellaneous Graphics register are set to 0). Does this mean there's something wrong with my 80186 CPU emulation, or is this a bug in the BIOS? What happens to those two registers on a real machine? Anyone can dump those modes set on a real machine and tell me the results?

Edit: Looking at the result when starting WIndows 3.0 with the Attribute Mode Control register's 8-bit color latching enabled, the colors of Windows 3.0 end up like they should, indicating that it isn't enabled for some reason, while it's needed for proper rendering?

Further, the screen sort of visible is only a quarter screen (top quarter) with the rest containing junk, the mouse parts being duplicated a few times every few pixels of the cursor horizontally. It's also huge (about 64x64 pixels large)? VGA 16-color modes have no problem.

I managed to fix the colors, but the memory layout is still messes up somehow:

The sequencer, which does the main part of the rendering: https://bitbucket.org/superfury/x86emu/src/1d … cer.c?at=master
The graphics rendering support: https://bitbucket.org/superfury/x86emu/src/1d … ode.c?at=master
The VRAM mapping support: https://bitbucket.org/superfury/x86emu/src/1d … ram.c?at=master
The attribute generation: https://bitbucket.org/superfury/x86emu/src/1d … ler.c?at=master
The CPU host aperture manager: https://bitbucket.org/superfury/x86emu/src/1d … mmu.c?at=master
Basic VGA precalculations: https://bitbucket.org/superfury/x86emu/src/1d … lcs.c?at=master
ET4000 and ET3000 extensions for the VGA: https://bitbucket.org/superfury/x86emu/src/1d … 000.c?at=master

Anyone can see what's going wrong? The colors look right, so that means that the DAC is functioning properly. Maybe it has something to do with the VRAM itself? Are the formulas used when retrieving data from VRAM (VGA_loadcharacterplanes(this loads the four planes and latches them into an 8-pixel buffer for rendering) and VGA_Sequencer_updateRow(Which handles the vertical timing)). I think those two might have an error somewhere? I do notice that the rendering row overflows the memory available (even though it should fit in about 500K VRAM).

The CPU host aperture writes to VRAM(Windows 3.0 driver I think), while it's using the maps specified in register 0x3CD(Which select a multiple of 64K VRAM). The video memory is wrapping around 512KB.
The location of a planar pixel is PLANEINDEX shifted left by 2 OR'ed with the plane(0-3). This results in the direct VRAM memory address it uses to retrieve the bytes(in this case all four planes, or one DWORD of VRAM). Since a scanline is 0x80 PLANEINDEXes long, the whole display should be 480*0x80(the amount the row is increased every row, so the OFFSET REGISTER has a value of 0x40?)=0xF000 PLANEINDEX entries long. So this means that 640x480x256 won't run with 512K VRAM?

superfury wrote:

So this means that 640x480x256 won't run with 512K VRAM?

This depends on the driver, I guess. General speaking, 640x480x256 is possible with 512K VRAM, I'd say.
Several of my old ISA cards (16Bit) are limited to 512K and do display 256 colours just fine.
So *maybe* the driver is using a fast mode whereas 1MB is required.
I remeber, that some drivers included a normal driver for 512K cards and a performace driver for 1MB cards.

Sorry I can't be more technical. My knowledge about VGA internals are too limted in this respect, I'm afraid.

Anyone knows how exactly all those clock interact with each other in the VGA? I'm trying to make sense of the Shift/Load rate/Shift four, Underline location/CRTC mode control's Double Word/Byte/Word setting, DIV2/DIV4 of the CRTC mode control/Underline location, SLDIV vs Scan doubling.

Anyone knows how these affect timing and/or output? And what about those counters? The FreeVGA documentation uses many terms, it looks like, to describe them?

Hmm. I've looked at your sources an I'm quite impressed! You put a lot of effort into it. 😀
The only thing I can do for you is to keep looking fore some device drivers or code snippets.

Speaking of this, I've attached two files for you.
One contains an old patch named "tweak". It allowed a generic VGA card to use an 800x600 resolution in mode 12.
To do so, it altered timing of the CRTC and set an 800x564 resolution if I'm not mistaken.
Even though this not related to your problem, it does contain an asm file with tweaked register values which could be useful for testing purposes.

The second file is an old Win 3.0 device driver for the tseng card. According to the time stamps of each of its files, it was released in 1990.
Unfortunately, I can't guarantee it will work in real-mode: The setup.inf only mentions standard and enhanced mode.

And I've also found a link to a doucment about the ET3000 registers.

According to your documentation on the ET3/4000, CRTC registers 32, 36, 37 and 3F exist on both chips. Dosbox, however, only supports those with the ET4000 chip? Do they exist on the ET3000?

Edit: Looking at the VGADOC documents: http://files.mpoli.fi/unpacked/software/progr … 3.zip/tseng.txt

It says indexes 30h+ are only on the ET4000(except index 34, however it is already mentioned at index 24h, so it is either mirrored on the ET3000 or index 34h doesn't exist on the ET3000?)? Can the configuration register at 24h give any info that has to do with VRAM wrapping, or is this fixed to 17 bits on the ET3000?

Edit: I tried to implement the 17-bit and 18-bit DWord addressing modes used with the ET4000 and ET3000, depending on the memory mask(always 512K for ET3000, 512K, 1M or VGA mode(256K) for ET4000) into my emulation:

https://bitbucket.org/superfury/x86emu/src/11 … 000.c?at=master

It's this function:

1uint_32 Tseng3k_DWordShift(VGA_Type *VGA, uint_32 memoryaddress)
2{
3	uint_32 temp = et34k(VGA)->memwrap; //The memory size, specified as a mask for the et3k&et4k!
4	switch (temp>>18) //What size are we to use, according to the bits set(16-bits value is specified excluding the plane. The memory wrap adds two bits(plane index), so ignore that too)?
5	{
6		case 1: //512K RAM?
7			return ((memoryaddress<<2)&0x1FFFF)|((memoryaddress>>15)&3); //SVGA shift using 17-bit index for double memory!
8			break;
9		case 3: //1M RAM?
10			return ((memoryaddress<<2)&0x3FFFF)|((memoryaddress>>16)&3); //SVGA shift using 18-bit index!
11			break;
12		default: //VGA-compatible?
13		case 0: //VGA-compatible?
14			break;
15	}
16	return (memoryaddress<<2)|((memoryaddress>>14)&3); //VGA-compatible shift using 16-bit index!
17}

The VGA mode matches the results given in the table of the DWord mode of the XGA. Although I'm not entirely sure about the 512K and 1M versions. Is it correct(wrap around 17 or 18 bits instead of 16 bits)? Does anyone know how this is handled in the ET3000 and ET4000? Or does it wrap at all?

Looking at the ET4000 datasheet again I notice that after the CRTC Mode Control Register explanation there's a table with, what seems like, the mapping of the Memory Address bits during byte/word/dword etc. modes? Is this correct?

https://archive.org/details/bitsavers_tsengLa … er1990_11230195

It's table 4.3-4 on page 128. Are these the address lines calculated on the ET3/4000 chips?
https://ia801004.us.archive.org/BookReader/Bo … ale=16&rotate=0

Can you tell anything from this that will improve my ET3K&ET4K emulation using this? Most of it already is implemented in my standard VGA and Dosbox-based SVGA emulation.
What do I do with the parts referring to ET4000 registers? Just process, as the values always are zero(initialization value, never to change on the ET3000, since they don't exist)?

Sorry, this kind of bare metal stuff is not a special subject of mine (I do have a basic understanding of VGA, but this is beyond me).

However, I could perform some tests on real hardware for you, if you wish.

As far as I can tell from the page:
MD is the output lines to memory(Planar 18-bit index?)
PG seems to be the normal single plane mode, as used with Mode X.
OE0 and OE1 seem to be the Odd/Even mode with and without the CRTC Mode Control MAP14 bit.
LG is Linear Graphics? Might be activated with mode 2 addressing(1M Linear graphics in the upper 2 bits of register 0x3CD(ET3000) or System Configuration register #2 register at CRTC register(port 0x3?4) index 0x37)?

Can you confirm this on your card? You should be able to address memory linearly by setting bits 6-7 of port 0x3CD to 10(2) on the ET3000.

On the ET4000 this should be done by setting bit 4 of 3?4 index 36.

superfury wrote:

Can you confirm this on your card? You should be able to address memory linearly by setting bits 6-7 of port 0x3CD to 10(2) on the ET3000.

Sure. But it will take some time, because I haven't done that before. So it's not that easy for me.

Was only using the QB/Turbo Pascal and VGA BIOS so far.. 😅

But maybe the test is no longer necessary, anyway :

According to one of my programming books, $3DC is clearly available on the ET-3000.
It also says that in 256col. mode the total memory of 512KB is divided in 64KB pages (except 800x600 16col. mode).
And each of them can be used in the $A000 area, when selected via the Segment Select Register ($3DC).
In contrast, 128KB pages are addressed directly in $B000.

And it also notes, that depending on the revision of the ET3K chipset, the partitioning of the VRAM can be 128KB or 64KB.
And to find out, someone has to check the Miscellaneous Register ($3C0 ?) :
If the second bit is set, but the third cleared, the partitioning is done in 64KB segments.
Are both cleared, partitioning is done in 128KB segments.
But there's a catch: Before these bits can be read, a graphics mode has to be set.

Btw, I've found out that vgadoc3 is outdated by now. It was replaced by vgadoc4b (in vgadoc4, vgadecl.inc was missing).

I hope this helps.

Good luck! 😀

Apparently the VGADOC4 was what I was looking at all along.

I've implemented the Attribute Controller's Miscellaneous register bit 4(Double all horizontal timings (all normal horizontal timings specifying horizontal character clock numbers, except the end registers(which only contain parts, and thus isn't multiplyable by 2 without screwing up their intention), Display start address and CRTC offset), which all override the default VGA timings with their used values (inclusion of the ET3000/ET4000 extension bits and then multiplied by 2 when the Misc register bit 4 is 1).

I've also added proper Interlace rendering(affecting the row before applying the vertical character clock to it), which shows all odd scanlines first, then the even scanlines.

This seems to affect rendering itself:

The segment size configuration (0=128K, 1=64K, 2=1M) of port 0x3CD seems to be only present in the ET3000. The ET4000 always has 64K segments (not mentioned in the pdf document, nor in the VGADOC documents)? This is already implemented in my emulation (it multiplies bits 0-2 and 3-5 with 64K/128K/1M to obtain the start address to add to the memory addressed by the CPU to access that plane's data.

Can you see what else might be going wrong?

Sequencer: https://bitbucket.org/superfury/x86emu/src/21 … cer.c?at=master
VGA/CGA/MDA precalculations: https://bitbucket.org/superfury/x86emu/src/21 … lcs.c?at=master
ET3000/ET4000 extensions: https://bitbucket.org/superfury/x86emu/src/21 … 000.c?at=master

Headers:
ET4000: https://bitbucket.org/superfury/x86emu/src/21 … 000.h?at=master
Precalculations: https://bitbucket.org/superfury/x86emu/src/21 … lcs.h?at=master
Basic VGA: https://bitbucket.org/superfury/x86emu/src/21 … vga.h?at=master

When moving the cursor, it seems to switch between 64K and 128K bank sizes(512K RAM installed).

It's running in 256 colors mode.

Running it on a NEC V30(only 80186 instructions implemented) with 640x480x16 colors results in the following:

Edit: Fixed the Attributes: The extended Attribute Controller registers of the ET3000 and ET4000 were getting written when the Attribute Controller Index was getting written as well, causing invalid data to be loaded. I've also implemented Palette RAM and Overscan bit 0-3 protection according to the low 2 bits of Attribute Controller register at index 16h.

Just tried installing WIndows 3.0 with the ET3000 1024x768x16 color driver. This is what it gives after starting the first installation graphical interface:

Looking at the size of the screen, it seems that the display timing of 1024x768 is in effect(it's a little bit larger due to overscan etc. being displayed). The Windows text is roughly readable, the individual pixels aren't rendered correct? 640x480 on ET4000 seems to be correct?

Trying with 800x600 results in the setup quitting (running MS-DOS 5.0), complaining that it needs MS-DOS 3.3+, when starting the graphical interface(using NEC V30(actually 80186 CPU) emulation)?

Jo22 wrote:

This depends on the driver, I guess. General speaking, 640x480x256 is possible with 512K VRAM, I'd say.
Several of my old ISA cards (16Bit) are limited to 512K and do display 256 colours just fine.

Yup, the maths are quite simple...
256 colour modes require 1 byte per pixel.
So 640x400 requires 640*400 = 256000 bytes of memory, which fits into 256K. Various SVGA cards with 256K support this mode (stock IBM VGA does not).
Many of these cards also support 640x480 when you extend the memory to 512K, since that requires 640*480 = 307200 bytes of memory.

For better performance, some SVGA cards/drivers will use padding between scanlines to align them. For example, instead of using 640 bytes per scanline, they may choose to use 1024 bytes per scanline (the next power of 2), where the last 384 bytes are not used. This way you need 1024*480 = 491520 bytes of memory, so it still just about fits in 512K. The advantage is that you can address each scanline by just shifting the Y-coordinate by a factor of 2^10, making things more efficient to address.
This is why eg DirectDraw reports both a width and a 'pitch' for a surface: the width is the number of visible pixels, and the pitch is the distance between two scanlines in bytes (in this example 640 and 1024 respectively). Various games suffered from 'pitchbug' on hardware where pitch != (width*sizeof(pixel)).