Not so great news... Having those latest bugfixes (multibyte loading using multibyte buffers, destination address writes to offset A3 having no effect anymore(as documented on the W32i documentation)) caused no effect on Windows 95! So there's a CPU problem somewhere that's causing this?

Although when switching Windows 95 from 16-bit color mode to 8-bit color mode it seems to have made all icons anywhere become black instead of their usual color-filled selves?

Huh? Now, suddenly, the accelerator isn't used in 16-bit color mode, but some articacts (when switching to 8-bit color mode from 16-bit color mode) still appear? Mainly in this case, all icons become filled with black instead of their supposed colors?

Rebooting causes the corrupted fonts to once again be displayed?
Edit: It's somehow not using the accelerator in 16-bit mode anymore? In 8-bit mode (and during setup using the W32 chip) it still doesn and still displays a corrupted font?
Edit: Found the 'issue' with the 16-bit mode: the accelerator was fully disabled in the video accelerator settings (Slider all the way left set to none).

VDIAG runs fine now (except the reset that somehow keeps failing?).

I've changed the mixmap inputs to produce a checkerboard pattern based on the used X&Y position when it starts a new 8-byte block to process.

1			et34k(getActiveVGA())->W32_ACLregs.latchedmixmap = (et34k(getActiveVGA())->W32_ACLregs.Yposition&1) ? 0x33 : 0xFF; //Checkerboard pattern for 16-bit color depth!
2			if (et34k(getActiveVGA())->W32_ACLregs.Xposition & 0x10)
3				et34k(getActiveVGA())->W32_ACLregs.latchedmixmap ^= 0xFF; //Reversed for the even numbers horizontally!

This is what I get:

Seeing the checkerboard pattern in there makes it look like the mixmap is indeed producing correct output, but the font data that's supplied is actually incorrect?
Those rectangles/squares in there are probably single lines rendering somehow (since all lines are in foreground font state)?

So that means that the graphics card is functioning properly and the CPU seems to have problems generating font data for the accelerator to use?

ALEKS wrote on 2021-03-25, 12:00:

The project will be available on my site in the next couple of days. I will also try to record a video with some games played through this card.
Later edit: I did a quick videoclip with the card performing under Windows 98: https://www.youtube.com/watch?v=Q-47q33atbk

Wow, seriously impressive! I would love to have such a card in my 486 system. 😀 So whenever the project goes live on your website keep us posted, please!

Where did you source the W32i chips?

I wouldn't think the CPU doesn't have enough power to generate data for an ISA-class card. Even an accelerated one. But then again, in a simulation, everything might be possible.

The project went live on my site.
I also injected my own ASM routine in the VIDEO ROM BIOS binary image and then burned the BIOS into a 27C256 UV-erasable EEPROM. All good so far.

I sourced the ET4000/W32i chips from China. There are multiple electronics parts stores on-line where you input your RFQ for the part you'd like. However, the chips are not cheap at all. They go from about $40 to $100 each, depending on the seller. Then there's the shipping and import taxes. But then again, how often do I get to build my own early '90s x86 hardware? Once in a lifetime, perhaps?

Cheers,

I do still have one question, tho.

Any idea what the VSS state of the accelerator is? I'm currently assuming most (except interrupt and sync enable registers) registers and queues cleared?
What does your chip give in it's ACL registers after a terminate command completes (with the internal registers filled with 0xFF/0xFFFF/0x3FFFFF values, queue not written to start processing pixels)?

VDIAG keeps complaining about it, but I can't find anything online about it. The only known other emulators that implement the chip are the PCem-based ones, which do a half-ass job at emulating all upper non-MMU window registers(in other words, registers 30h-34h), not implementing their functionality at all(behaving as ROM registers, which they aren't, together with their missing functionality (except reading the status register))! UniPCemu is actually the only one that tries to emulate them at least.

I've just verified the functionality of the mix map handling in UniPCemu, using the 8x8 CGA font used for rendering the text layers (which is shifted out from LSb to MSb for rendering the emulator's own text (it's the Dosbox CGA 8x8 font ROM, but all bits in the bytes are in reversed order (for optimizing rendering of UniPCemu's text surfaces), thus being available for the rendering method used by this algorithm):

1extern byte gpu_font_08_reversed[256 * 8]; //Full font, ascending font! For testing!
2
3byte get_font08_16bit(byte character, byte x, byte y)
4{
5	byte result, i, chardata;
6	x &= 0x7; //16-bit location!
7	y &= 0x7; //Y location!
8	result = 0; //Init!
9	for (i=0; i < 8; ++i)
10	{
11		//2 bits = 1 pixel
12		chardata = gpu_font_08_reversed[(character << 3) | y]; //The row to process!
13		chardata >>= x; //The pixel to process!
14		if (chardata & 1) //Pixel is foreground?
15		{
16			result |= (1 << i); //Set said bit in the result: render foreground!
17		}
18		if (i & 1) //Odd half?
19		{
20			++x; //Next X position!
21			x &= 7; //Wrap around to test!
22		}
23	}
24	return result; //Give the 4 16-bit pixels requested!
25}

This is the original(top row) and replaced mix map inputs used for the testing:

1			et34k(getActiveVGA())->W32_ACLregs.latchedmixmap = et34k(getActiveVGA())->W32_MMUqueueval; //Latch the written value!
2			et34k(getActiveVGA())->W32_ACLregs.latchedmixmap = get_font08_16bit('A',((et34k(getActiveVGA())->W32_ACLregs.Xposition&0xF)>>1),et34k(getActiveVGA())->W32_ACLregs.Yposition&7); //A-pattern for 16-bit color depth!
3			if (et34k(getActiveVGA())->W32_ACLregs.Xposition & 0x10)
4			{
5				et34k(getActiveVGA())->W32_ACLregs.latchedmixmap ^= 0xFF; //Reversed for the even numbers horizontally!
6			}

So positions 0-7 render the CGA font, positions 8-15 render it flipped(inversed font), 16-23 render the same as the first 7 pixels etc.

This is what happens to Windows 95 once this is done:

Seeing as the A's themselves display without issue, this means that the rendering method used by the ET4000/W32 itself seems to be correct? Even more fun: this means that the CPU part of generating the font data inputted this way is misbehaving somehow (seeing the random data that gets output instead of the proper text)? And since the fonts get displayed without issue when the accelerator is disabled, this means that it's the accelerated routines in Windows 95's drivers are what's causing the problem?

Can you check with Windows 98 instead?
When I installed Windows 98 I tried different drivers and only some worked. In the end I think I used the ones provided by Microsoft. I can check later on today when I'll have time.
I remember that some drivers would not enable the accelerator and would default to a very slow 2D performance; almost unusable. But I haven't encountered any visual artefacts like the ones you posted.

ALEKS wrote on 2021-04-13, 13:04:

Can you check with Windows 98 instead?
When I installed Windows 98 I tried different drivers and only some worked. In the end I think I used the ones provided by Microsoft. I can check later on today when I'll have time.
I remember that some drivers would not enable the accelerator and would default to a very slow 2D performance; almost unusable. But I haven't encountered any visual artefacts like the ones you posted.

Unfortunately my Windows 98 installation I was testing with was corrupted (probably because of CPU issues being fixes), so it'll need to be setup again. That's going to take quite a while (especially using UniPCemu, at 15% CPU speed for 3MIPS CPU speed...).

ALEKS wrote on 2021-04-13, 06:01:

The project went live on my site.

Hm, I found this site: https://alexandrugroza.ro/index.html But can't find the project there. Do you have a direct link?

EDIT: Stupid me... found it here: https://alexandrugroza.ro/microelectronics/sy … ller/index.html

I've just been looking at your schematic of the card.
I see you've connected A16(from the XT part of the ISA bus) and A17-A22 directly to the inputs on the card. But A23 is connected to the SEGE pin, with an inverter on it(if I'm understanding the circle sign before the port correctly?)?
So the card decodes A16-A22 normally, but A23 is ignored and inverted on the SEGE input?
Can you explain what this does to the addresses fed to the chip and how it responds to them?

Edit: I see that UCPC is a direct line to VSS (ground)? So it's always low(ISA bus)?

Edit: Then, reading the documentation of the chip (in ISA mode):
- During VGA-compatible mode, bits 23(=SEGE) and A<22> of the linear address are compared to bits 1:0 of the System Segment Map Comparator. A<21> and A<20> are then normal inputs to the used window or ignored in VGA mode.
So bits 1:0 map to bits 23:22 of the physical address supplied by the CPU? The upper bits are ignored, while bits 4:2 of said register are all set during power-up? So the options here is a map at 4MB(01h), 8MB(02h) and 12MB(03h) when linear mode is enabled?

SEGE is a multi-purpose pin. The most interesting is that for 16-bit ISA operation (linear design), it is tied to system ISA bus A23 signal.
In other system designs it is connected differently. However I was not interested in anything other than ISA thus I don't know the other functions.

Later edit: Yes, UCPC signal is always tied to VSS in ISA mode.

ALEKS wrote on 2021-04-14, 10:25:

SEGE is a multi-purpose pin. The most interesting is that for 16-bit ISA operation (linear design), it is tied to system ISA bus A23 signal.
In other system designs it is connected differently. However I was not interested in anything other than ISA thus I don't know the other functions.

Later edit: Yes, UCPC signal is always tied to VSS in ISA mode.

So indeed the options for this board are the video memory being mapped at 4MB, 8MB and 12MB (since it's set to ISA mode)?

Edit: Also, got an explanation on the duplicate address lines 17-19 on both the XT and ISA part of the card(you've only connected the ISA part of those)? So ISA lines C6-C8(AT) vs A12-A14(XT)?

Just tried Windows 98... Immediate crash on (if I remember correctly) VPICD.VXD?
Edit: Yup: "While initializing device VPICD:
Windows protection error. You need to restart your computer".

So getting some PIC or IRQ errors now?

I never thought about 8-bit card mode thus I decided to use the 16-bit extended signals for addressing.
In addition, my 80386DX project PCB has the LA17-LA19 (16-bit) signals hardwired to the SA17-SA19 (8-bit) signals. But the video card works OK with other PCs, up to Pentium 233 MHz (that's the fastest one that I have).
I haven't checked it out but I think most other 16-bit ISA systems have these address lines hardwired together. But without actually having verified this information, I might be wrong here.

The ISA standard however says that the LAxx address lines are latchable and are valid when BALE is high. The SAxx lines are latched when BALE switches to low. But from my knowledge 17, 18, 19, either LA or SA, perform the same function.

Later edit: I just started the PC and took this screenshot with the Windows 98 drivers that I'm using. It's just the standard Microsoft driver dated 4/23/1999. On the other hand, HWiNFO is displaying garbage for some reason. @Martin, if by chance you are reading this post, maybe you can fix the ET4000/W32i chip detection. And also the available DRAM and RAM mode (interleave/linear).

ALEKS wrote on 2021-04-13, 06:01:

I sourced the ET4000/W32i chips from China. There are multiple electronics parts stores on-line where you input your RFQ for the part you'd like. However, the chips are not cheap at all. They go from about $40 to $100 each, depending on the seller. Then there's the shipping and import taxes. But then again, how often do I get to build my own early '90s x86 hardware? Once in a lifetime, perhaps?

I just checked on eBay, and I'm surprised by how expensive used ET4000/W32 cards are.

Here's a seller of some ET4000/W321 (misspelled?) chips for $18 each, or as low as $11.25 if you buy 42+. None of the other sellers on digipart are willing to list a price.

I know that eBay prices are particularly high for ET4000/W32i cards. I don't think there were that many made (at least not like Trident cards) and they offer great ISA performance. I think only one other card based on a variant of Cirrus Logic GD series chip is on par with the Tseng models.

However if somebody would like to venture into building my card, he/she would quickly realize it is not cheap either. Sure you can do the PCB in China, with a lower quality than OSHPark. But still functional. But then there is the sourcing of the Tseng Labs chip, and a ROM image (that's easy to find on-line) and an EEPROM programmer. The other parts are cheap. Then there is the metal bracket which I took from another card. I would really like to find an on-line service to build ISA card brackets.

ALEKS wrote on 2021-04-14, 18:15:

I know that eBay prices are particularly high for ET4000/W32i cards. I don't think there were that many made (at least not like Trident cards) and they offer great ISA performance. I think only one other card based on a variant of Cirrus Logic GD series chip is on par with the Tseng models.

However if somebody would like to venture into building my card, he/she would quickly realize it is not cheap either. Sure you can do the PCB in China, with a lower quality than OSHPark. But still functional. But then there is the sourcing of the Tseng Labs chip, and a ROM image (that's easy to find on-line) and an EEPROM programmer. The other parts are cheap. Then there is the metal bracket which I took from another card. I would really like to find an on-line service to build ISA card brackets.

If I'm not mistaken, this Keystone bracket is a good fit for your card. If the DB9/HD15 sized hole in that bracket doesn't line up with your PCB, that's obviously not hard to fix.

As for the other ICs - the DRAM chips, the RAMDAC, and the clock generator - are those the same parts that were used on ET4000 cards back in the 90s? Admittedly the FPM DRAM chips have been EOL for a long time. New RAMDACs aren't a thing anymore, so it would probably need to be a video DAC hooked up to some kind of FPGA... this is only getting worse the more I think about it.

Thank you for the Keystone bracket hint. I will look into the Keystone drawings and check the measurements first. If it fits I will take a couple of them.

Regarding the DRAM, the ones I used are a newer than what would've been normally used in the early '90s. But they are still obsolete parts. The PLL clock generator and the RAMDAC chip are, however, period correct.

If superfury manages to correctly emulate the ET4000/W32i chip in software, then there is a good possibility of translating all that implementation into a couple of CPLDs (Verilog most probably) or better an FPGA. That would make for a nice project. I think an FPGA core implementation of the Tseng chip would successfully even run Half-Life 1. Even with my card I get around 7-15 fps in HL1, over ISA, in the lowest resolution possible.

My intention was to build everything with the parts that were available in the '90s. But I would like to see modern ISA card implementations as well.

Just found the Windows 98 problem: it tries to write MSR 1Bh, but the CPU emulation thinks that invalid bits are written somehow, causing the crash? Hmmm...
Edit: Just fixed the MSR 1Bh up a bit, allowing writes to all bits but bits 0-7, 9 and 10, as well as allowing up to 32-bits(Pentium Pro and below) or up to 35-bits(Pentium II with PAE) base address for the Local APIC.
Previously it just allowed writes to bits 4-7 being set, which obviously is incorrect.
Edit: Yup. That fixed the booting of Windows 98 to boot properly again! 😁

@ALEKS I am trying to find the Chrontel CH9194E. Google and eBay give me very few to no results. Is there a compatible IC I can use? Can't even find a datasheet!

EDIT: Would this be a compatible part?
It's a clock generator and also is DIP20:

https://www.jameco.com/z/ICS2494-236-Major-Br … 20_2303175.html

EDIT2: I think the ICS2494-237 and -304 should be compatible, they are programmed for the ET4000 range, including the W32 according to the datasheet.