ET4000 would be my suggestion.

Realtek RTG3105IEH? ISA, slow. has an 8-bit DAC (IIRC, somebody please verify), works with the standard SVGA driver for Windows 3.11 (IIRC), and can do 800x600x8 and 1024x768x4, very small in physical size, and pretty cookie-cutter overall for a basic, late-ISA SVGA card, the FX5200 of '94 😀 The actual vga output is slightly blurry with a sepia-ish tint to the grays.

I dumped the bios for this one somewhere... I recall loading it in DOSBox, seeing a BIOS startup message I never saw before, and properly getting only 800x600x8 and 1024x768x4 VESA BIOS modes in Compushow 2000, however text modes were incorrectly grayscale

Do all VGA modes (modes 0-13h) work on the Realtek RTG3105IEH when programmed as a VGA (monochrome graphics, MDA, 4 color CGA, 16 color CGA/EGA and 256 color VGA modes)? I'm still searching for a datasheet on the chip to take a look at it's SVGA registers. Does it have only additional VGA registers like the Paradise PVGA1A? I already have the VGA implemented, is it difficult to add Realtek RTG3105IEH registers support (No Plug-And-Play implemented (yet))?

The CGA (non-Composite), EGA and VGA modes should work.

It doesn't do any special proprietary SVGA implementations IIRC, but it does VESA 1. I don't have this card anymore, maybe I threw an obscure curveball and I doubt there's datasheets for it 🙁

leileilol wrote:

It doesn't do any special proprietary SVGA implementations IIRC, but it does VESA 1. I don't have this card anymore, maybe I threw an obscure curveball and I doubt there's datasheets for it 🙁

Just spent a few minutes amongst the datasheet sites, nothing leapt out at me.
http://web.archive.org/web/19970627102422/htt … cp/3105ieh.html
Looks like they were available... in 1997. I suppose support in an emulator would have to be reverse-engineered, unless current Realtek still has the datasheets somewhere. 😀

The video card also involved Quadtel, which Phoenix acquired then

Have you looked at http://www.nongnu.org/vgabios/ already?

I think I'm going for the ET4000. Anyone knows some good info on the registers and locations of the registers of the ET4000? Also, how is 16-bit (64k colors) enabled? Is it an extension of the normal 8-bit color mode of the VGA? (simply processing 2 8-bit colors into 1 64k pixel?) I can't find any info on how the 64k mode is archieved.

Edit: after some more searching I found the full documentation on the ET4000. The version I kept finding was only the first few chapters. I notice that the attribute miscellaneous register has a bit to enable WORD mode (64k colors). Does this work the same way the 8-bit color (attribute mode control) works, but combining 2 8-bit colors into 1 16-bit color and double pixels?

16-bit colour is a function of the RAMDAC, not the chip. Most boards with the original ET4000 would have just had an 8-bit RAMDAC.

So they won't be able to show more than 256 colors? Then why does the Attribute Miscellaneous register exist?

1ATC Indexed Register 16: Miscellaneous
2This is a read/write register (protected by KEY).
3R : Port address = 3C 1
4W : Port address = 3CO (index/data flip-flop in DATA mode)
5Bit Description
60-3 Reserved.
74-5 Select High Resolutionlcolor mode.
86 2-byte character code (ET4000 Rev. E).
97 Bypass the internal palette.
10Bits 4-5., in combination, select high-resolution or high-color modes. When bit 4
11is set to a logicall, the MCLK/2 bit in TS Index 7 should also be set. The available
12selections are:
13See Addendum 6_1 for the description of bit 6 and programming instructions.
14Bit
154 5
160 0 Normal power-up default.
170 1 Reserved.
181 0 High-resolution mode (up to 256 colors).
191 1 High-color 16-bit/pixel.
20NOTE: Normally, high-resolution mode never needs to be set.
21Bit 7, when set to I, causes the internal palette to be bypassed (effectively the
22output equals the input value). 

So when bits 4-5 are set to 11b, what happens with an 8-bit DAC (you might need to set bit 7 too)?

That just doubles the pixel data rate. It's up to the RAMDAC to glue two pixels together to generate 16-bit colour. If the RAMDAC doesn't support this then 8-bit colour is all you will get.

What are you trying to do here, incidentally? You're asking questions about all kinds of obscure edge cases that no software is actually going to use, if this is for your emulator then I would have thought getting it to boot DOS would be a better use of your time.

I'm trying to get DOS working, but since I don't have any way to reference to (results vs correct results and disassembly), I can't fix the bugs, since I can't tell the location of the bug. So in the meantime, while I'm waiting for an answer, I'm focusing on other aspects of the emulator and improve them or fix bugs, until there is nothing to do anymore.

superfury wrote:

I'm trying to get DOS working, but since I don't have any way to reference to (results vs correct results and disassembly), I can't fix the bugs, since I can't tell the location of the bug. So in the meantime, while I'm waiting for an answer, I'm focusing on other aspects of the emulator and improve them or fix bugs, until there is nothing to do anymore.

then maybe you should throw up the source so people can take a look.

Already posted an attachment with the source code of the 80(1)86 instruction emulation (without all helper functions, which work fine and have no errors afaik). I've posted a file with the code for the 8086 instructions, 80186 instructions and 8086 instructions ported from fake86 (GRP opcodes).

Have you tried comparing against a working emulator? In the very early days of PCem I used pcemu (http://pcemu.sourceforge.net/) as a reference; from memory it was very easy to integrate into another emulator, and it can then be used to generate a reference trace to compare against your own emulator.

Tried implementing the PCEmu CPU into my emulator. Eventually it became one big mess when I started on the logical operations (##xx precompiler directives). Is there any other emulator that's easier to convert?