Do you know of any test software to test such an implementation? I'm looking for something to test my own ET4000/W32 emulation I created in UnIPCemu (only in source code on the git repository atm, not released yet) and iron out the remaining bugs that occur with Windows 9x/3.1 so far (3.1 has foreground rendering problems(big blob of random data at the top during setup instead of the foreground window, background is fine), while 95 still has text rendering issues somehow(putting in a test 0xAA pattern instead of the mix data inputs causes a straight uniform horizontal on/off pattern, while letting the OS input it's own data causes what looks like a random foreground/background pixels in both the title bar and contents of the windows and start menu)).

The code for the accelerator and ET3000/ET4000AX and ET4000/W32 chips: https://bitbucket.org/superfury/unipcemu/src/ … ga/svga/tseng.c

Also, any idea how memory is detected on a ET4000/W32 controller? The BIOS I'm using (the W32ISA ROM from 86box) keeps detecting 4MB installed, even if only 512K/1MB/2MB is installed.

Nice card !

Unfortunately I don't know of any consacrated way of testing the ET4000/W32i controller.
I have empirically tested the graphics card using software that I know the behavior of. I have encountered some issues but they were all hardware related and I fixed them during the development of the schematic and PCB layouts.

For MS-DOS, I have used this tool from Tseng Labs, called VDIAG.EXE. I attached it to this thread.

I studied the datasheets and all documentation I could find on-line, but I was mainly interested in hardware design, not the actual programming of the chip. There are some very detailed memory addressing and register mapping descriptions in the datasheet. Unfortunately it is all scanned images. And it's very verbose. The variant that I have is 294 pages and you cannot use the search function. I read it entirely but I scanned the parts that I wasn't interested in. Fact is that memory related information is a bit scattered around the datasheet. Too bad it's not grouped altogether. It gave me some headaches when designing the connections to the DRAM. In fact dealing with the datasheet was like 40% of the time I invested in this project.
From a hardware perspective, the only case in which you can use the entire 4 Mb RAM in a linear fashion, is to use all address lines from both BANK A and BANK B. To use 4 Mb in interleave mode (2 Mb usable but with a very fast interface) you need to let AA9 and AB9 floating. Don't know if it helps but maybe the ROM BIOS checks this when it reports 4 Mb in your case.

Thank you for the direct link to the source code of the ET4000/W32i emulation. I will take a look on it. Also if it helps you with the emulation, I can provide you with the ROM BIOS image that I am using.

Here are some images taken with my mobile phone on the CRT (beware of the moire effect) while displaying some tests from VDIAG.EXE.

Cheers,

Seriously cool project. You, sir, are an enthusiast!
That goes for your other projects as well...I can't imagine the amount of perspiration that went in to making that stuff.

I guess for ISA this is just about the best thing that still makes sense? Or do you have some other ideas waiting in the wings?
(well "makes sense" is a subjective term - if you want it, you want it 😀

Thank you for the kind words.
I think this is the best I can get out of the ISA bus in terms of video cards. I used the fastest memories that I could find available (and because of this I had some timing issues in the early design stages) but the real bottleneck is the bus itself.
My ambition was to design a full ISA system and it appears that the bus supports real-time video, audio, I/O, and networking. All at an acceptable speed.

I know there is a Cirrus Logic chip that offers at least the performance of the ET4000/W32i chip. Maybe it would be fun if somebody comes up with a design using that specific CL chip.

Here is a videoclip.

https://www.youtube.com/watch?v=Q-47q33atbk

Cheers,

Just a little question: can you run the tool I've made in my other thread (Found at my second post at ET4000 and ET4000/W32/i/p actual KEY behaviour? ) on your ET4000/W32 card?
I'm incredibly curious what it's outputs will be (displaying the actual KEY behaviour for read operations in it's results).
Mainly because that's a piece of exact documentation that's still missing from all found specs (and none of the emulators agree on it's exact behaviour for emulation of the Tseng ET4000 chips).

The program will simply print some numbers on a single row (in hexadecimal format) which display how the card responds to reads with and without the KEY set in the hardware.

Edit: Btw, after fixing some the extended attribute and sequencer registers to be allowed to be read when the KEY isn't set (like it currently does with the CRTC registers too), it now no longer crashes and starts the next phase: some text "Screen filled............." in the bottom right and a yellowish/greenish screen is displayed.
I see in the breakpoints I've set in my emulator it's starting to use the 2D accelerator at that point! 😁

I even see it use the mix map (which seems to be during parts where it fills the entire screen with a solid color)?

Although it eventually crashes with a "Error27 Cannot set reg:Stat.........".
So perhaps the status register bit 3 is indeed writable as the documentation says?
Does that have any effect on the loaded accelerator status of actively processing registers (the internal vs realtime data that's processing)?
Don't know if the sprite is supposed to be T-shaped?
Edit: Btw, it starts with a weird: "Error 7: Write mode 3 error"? Does that mean that the VRAM accessing is faulty somehow in write mode 3?
Also 2 simultaneous fonts seems to fail (all the same font, just bright and dark green interleaved)?
Edit: It was an issue with the precalcs used for the attribute inputs. It was shifting the attribute byte higher and not taking that into account when taking bit 3 of the attribute byte for processing it into the split font display. Whoops!
That's another quite old bug solved now (it's probably been there since the whole attributes are precalculated, so probably since near the first releases of UniPCemu with the current rendering system, so probably all UniPCemu builds!).
Edit: It now shows a small A followed by a large A, repeated over the entire screen in that test! 😁

After the last high-color test, it will display at the top-left: "Error power up VSS"?

I have ran the .COM program but it either does nothing or it does what it was intended to but in a very quick fashion.
The screen goes black for an instant then quickly reverts back to the standard command line.
You can add a BIOS read key routine or something after printing the numbers so that I can check what it displays.

The moving sprite is indeed a T-shaped. I can take pictures of every test screen if it helps you.
I don't encounter any errors while the program loads. However, when I initially did the design, I had some timing errors caused by improper PCB layout design. And the Tseng utility complained about mode 07 (if I remember correctly) as it could not access it. Needless to say that I had garbled pixels in graphics mode and broken pieces of ROM fonts in 80 x 25 text-mode.

2 simultaneous fonts works correctly on my side. I can see both big and small green characters on screen. They are indeed interleaved but displayed very clearly.

Possibly unrelated but just a fun fact about ROM fonts interleaving. If you know the program Fontraption (used to edit ROM fonts) programmed by VileR (he's also a member on the forum), it also had issues with rendering dual fonts on my card. I have discussed with him and he found this weird behaviour in the video ROM BIOS. If I remember correctly it was something about the BL register that specifies the target block in map 2 of VGA RAM (0 to 7). And the Tseng ROM treated that differently than other BIOSes. I'm talking from memories and I might be in an error. If he sees this thread, maybe he can shed some light.

Hmmm... The program that's ran is a very simple one. Although I've coded it entirely in assembly.

If it detects the video card correctly (by setting the KEY according to the ET4000 documentation), it will display the numbers using simple MS-DOS teletype (interrupt 21h function 02h).
It does the byte to hex conversion using a simple shift and add (to create the numbers and hexadecimal letters A-F).

So it should actually just print the results on the line where the program started at (after you press carriage return to start the program from MS-DOS).
If it doesn't, that's very weird? All output is done unconditionally (except the hex conversion taking different bases for letters 0 and A).

The only things it actually affects are the following registers:
- The registers to enable/disable the KEY (registers 3BF and 3B8/3D8).
- CRTC register 34h bit 3.
The results are also printed after it returns all modified registers back to their original state (when it started the program).
Other bits in CRTC register 34h are left untouched (written the same as read).

Btw, it will need to run in pure MS-DOS, without anything that can interrupt it (like virtual I/O ports etc, including memory managers of any kind). That includes Windows.

Also, the issue with the interleaved fonts is already fixed (bright green and some darker green with correct fonts (two sizes of A interleaved)).

I've made a slight bugfix version of the testing app:
Re: ET4000 and ET4000/W32/i/p actual KEY behaviour?

It now restores all other registers as well before trying to display anything for results.

It was kind of an obvious bug: it was still writing the test value (0x01) to the Misc Output Registers, thus making the VRAM unwritable (unmapped) during the result printing (though the cursor would still be updated due to MS-DOS still updating the cursor position registers (not requiring VRAM access).

Can you try again with the updated version?

I ran the updated version and it displays these numbers: 88888088
Hope this helps!

ALEKS wrote on 2021-03-26, 17:24:

I ran the updated version and it displays these numbers: 88888088
Hope this helps!

That sure sounds weird. It means that:
The original value read with KEY disabled was 88h.
Read it with the KEY set reads 88h.
It then overwrites said value with 80h (changing the register, since the KEY should be set).
Then reading it back with the KEY cleared again shows that the value read back is unaffected?

Hmmm...
Some things are wrong with my code, obviously. Currently working on them.

Fixed quite a lot of bugs in the test program (pretty big bugs causing it to work incorrectly and give wrong results). See the post on my thread on the program for an exact list of bugfixes.
It also has a new little extra data being output for checking if the value was written correctly with the KEY enabled.
One of the biggest bugs were the hex display being incorrect and register writes actually not being done at all (reads instead of writes) 😖

Could you please try again once you've got the time? I know it took a bit of work to get the bugs ironed out, but this time it should give proper results.

Also. for reference:
UniPCemu floating the bus on reads without the KEY: FF080000FF
UniPCemu passing through to normal VGA behaviour without the KEY: FF080000FF
UniPCemu allowing all reads with and without KEY: 0808000000

I ran the new program but this time, immediately upon execution, the screen goes blank and then it deactivates (!?) the video card completely. Also killing the output signals. The CRT monitor shuts down (as in no signal received).
Only a hard reset can get the video card reinitialized.

ALEKS wrote on 2021-03-27, 07:21:

I ran the new program but this time, immediately upon execution, the screen goes blank and then it deactivates (!?) the video card completely. Also killing the output signals. The CRT monitor shuts down (as in no signal received).
Only a hard reset can get the video card reinitialized.

I've just released a bugfix. There were some problems with the last build (both wrong registers being used in some cases and the CRTC register that was tested on wasn't being restored properly(writing the address of the variable instead of the actual variable back 😖 ). The function to re-arm the KEY protection was also using entirely random port numbers (instead of loading DX with a proper port number, it was loading ax 😖 ). Thus it was writing to the DMA controller (probably, since it's port 0h) and port D4h (probably nothing responding to that).
The results are also more readable (with newlines between each byte) and 4-bit hex number printing was simplified a bit.

Could you try again? If it's still turning off the display that would be very weird? (since the CRTC register 34h is now properly restored and the Misc Output register does nothing more than switch to color mode(only affecting bit 0 of said register, leaving all other bits intact during the testing).

Btw, what system are you running this on? XT (compatible)? AT (compatible)? Another motherboard? 8088 CPU or 386+ CPU?

The program should be run under MS-DOS without any device drivers loaded (Microsoft HIMEM should still be OK though). But that's mainly to prevent it from modifying or intercepting the port I/O it makes to the video card (to make sure the results are actually from the video card instead of some driver that's emulating stuff (which might be faked, for example with video compatibility or overriding drivers or by Windows itself when running a command prompt)).

Afaik the registers that it actually changes (the Misc Output Register mono/color bit changing to color mode and register 34h switching the 3C3/46E8 video enable setting.
The bits it was actually modifying incorrectly (the other bits of the Misc Output register) might be the cause of the old issues (RAM enable, clock select, (odd/even page select?), and probably (in this case) the horizontal/vertical sync polarity being wrong).

Btw, what kind of video playback accelerator is used with the ET4000/W32 chip? The documentation mentions the Image Port, but I can't find anything about the image processor itself that should be connected to it to use said functionality?

I ran it again and this time it displays the following hex numbers:

188 88 80 80 80

My system is made of hardware entirely designed by me:
- ISA System Backplane
- ISA 80386DX Singleboard Microcomputer
- ISA ET4000/W32i Video Card
- ISA I/O Interface
- ISA Audio Interface
- 32 Mb SIMM Modules

When I need more power, I just remove the 80386DX computer card and insert a Pentium MMX / 233 MHz ISA singleboard computer card instead. The rest of the ISA cards remain in position.
For the Windows 98 videoclip that I did, the Pentium computer card was installed.

PS: I know assembly myself and I like your work. I'm find your writings very interesting. I was always attracted by weird, obscure computer stuff.

Later edit: To my knowledge the Image Processor is something used for hardware movie processing. At least that's what the datasheet says. The 2D acceleration features of the ET4000/W32i are built into the chip itself. In my design, I let the IMx pins floating (e.g. not connected to anything).

Cheers,

Well, I ran the test program you've posted. It for some reason keeps giving me an Error 7, saying that write mode 3 doesn't work properly? That's very strange?

Then, once the accelerator tests run, it eventually gives another error: "Error27 Cannot set reg:Stat", directly after the cursor test.

I somehow also see all kinds of weird writes to start an 2D accelerator (ACL registers triggered) to start an operation at address 0? It keeps overwriting the very same top of the active display with new colors, erasing the previous ones?
The error about the "Stat" reg being unable to set is pretty weird? Any idea what it means with that?

I've made the ACL Accelerator Status register top 4 bits fully writable and the bit 2 starts an accelerated operation (not loading the registers or decoding them).
Just also made the other registers 'undefined' bits actually writable (of the defined unqueued ACL registers).

ALEKS wrote on 2021-03-27, 16:32:

I ran it again and this time it displays the following hex numbers: […]
Show full quote

I ran it again and this time it displays the following hex numbers:

Copy code to clipboard

188 88 80 80 80

My system is made of hardware entirely designed by me:
- ISA System Backplane
- ISA 80386DX Singleboard Microcomputer
- ISA ET4000/W32i Video Card
- ISA I/O Interface
- ISA Audio Interface
- 32 Mb SIMM Modules

When I need more power, I just remove the 80386DX computer card and insert a Pentium MMX / 233 MHz ISA singleboard computer card instead. The rest of the ISA cards remain in position.
For the Windows 98 videoclip that I did, the Pentium computer card was installed.

PS: I know assembly myself and I like your work. I'm find your writings very interesting. I was always attracted by weird, obscure computer stuff.

Later edit: To my knowledge the Image Processor is something used for hardware movie processing. At least that's what the datasheet says. The 2D acceleration features of the ET4000/W32i are built into the chip itself. In my design, I let the APx pins floating (e.g. not connected to anything).

Cheers,

Well, those values mean that the reads of CRTC registers aren't protected by the KEY, since it can read the KEY is both cases just fine. So, as the documentation seems to imply (indirectly), only the writes are actually affected by the KEY (by not writing said registers other than 0x33 and 0x35 when the KEY isn't set. And of course 0x35 is partly protected by the CRTC write protect bit in register 07h(as is documented)).
So in this case, currently UniPCemu's current commits is actually the only ET4000 emulation (afaik) that correctly implemented the KEY of the ET4000 chips! 😁 (Compared to PCem and clones and Dosbox and clones).

Just managed to fix write mode 3.
The main cause was actually the rotate operation done in said mode. It was rotating based on a size of 32-bits instead of a proper 8-bit rotate 😖

VDIAG changes though:
- When starting it, it asks the questions about supported video modes below the MS-DOS command prompt line starting the program instead of on the top of a cleared screen.
- Also when starting it, the top half row of the display displays seemingly garbage characters in various colors?
- A configuration summary displays itself when starting the app this time directly after some vram windows displays half a horzontal window full of bright colors (VRAM tests?).
- The configuration window says the following (atm 1MB VRAM installed):
- BIOS version: garbled text
- Primary display: VGA
- Secondary display: Not present
- Translation ROM: Present (it isn't!)
- Installed memory: 512K bytes (actually 1MB in this case)
After that the tests start normally.
Edit: Whoops. That's the VGA being used instead of ET4000/W32... Need to recheck later when I have time again.
Edit: Hmmm... Restarting with a proper ET4000/W32 emulation seems to fix said erroneous behaviour.
Edit: When running with 1MB (BIOS detects 4MB for some weird reason), it gives me an error with VRAM after those tests (which now gives patterns accross the entire screen instead of half on the VGA).
Then it gives me an A000:0000 VRAM error?
Edit: It gives me this:
"Error 1: Memory test failed in mode 13 bank 10 loc A000:0000" (without quotes).
So there's at least an issue with the memory banking somehow?
Edit: Hmmm... It properly addresses address 100000h in VRAM. But since only 1MB of VRAM is installed, it floats the bus and writes nothing and reads 0xFF back (which the VDIAG app doesn't like).
So the main culprit here is that the BIOS doesn't detect the right amount of VRAM.
Edit: Yup. Adding more VRAM (to 2MB total) causes said number to increase to an error result of mode 13 bank 20 loc A000:0000.
Edit: Increasing it to 4MB (what the BIOS reports) shows the following after those tests:

1CONFIGURATION SUMMARY
2BIOS version 8.00 (10/14/93)
3Primary display: VGA
4Secondary display: Not present
5Translation ROM: Present (note: it isn't present or emulated)
6Installed memory: 4096K bytes
7
8ISA 8-bit or LOCAL 16-bit

So somehow it's thinking it has 4MB because the BIOS always thinks 4MB is installed somehow?