Hi Aleks,

no worries. Matt actually already tested with 60ns or so chips and they do indeed work (with 33 Ohm resistor packs). So I think this is one of the ways to go. I expect this to work.

superfury wrote on 2021-05-17, 20:44:

Although the VDIAG test program still doesn't agree with my emulation regarding the VSS state

I still haven't managed to pin down why it fails on said test. Stuff like Windows 9x, 3.x and Windows NT can use it just fine (no visible errors).

It simply says:

Error power up: VSS

Looking at the vdiag.exe in a hex editor also shows that very same string inside the app, so that's indeed what it's trying to display (however fast it's disappearing because of the other tests following it immediately after).
That happens right before the ACL tests (which all pass).

Does anyone have any idea what it means by this issue? It's the only error the program is still reporting when running the diagnostics on the card.

Configuring the vdiag color tests to run backwards makes it start with said message, followed by the accelerator tests.
So it's the start of the accelerator tests that is throwing that error?

Anyone knows anything about what might cause said error to pop up immediately at the start of the tests?

One luckly thing is that I can trigger said test easily when the OS is booted (simply run vdiag, then change the order of the tests to backward, then run the color tests to make it start the test that's failing immediately).

Edit: Just checked what reads/writes it was performing.
All I saw is some writes to the ACL Suspend/Terminate register(0x10 and 0x00), ACL Sync Enable register(only 0x00 I think) and reads from the ACL Accelerator Status Register?

Anyone can shed some light on what it's trying to do? What response of my emulator isn't matching there?

All I see it do to the accelerator is:
(syntax for reads is valueread<=reg XXh)
(syntax for writes is valuewritten=>reg XXh)

10h=>reg 30h
00h<=reg 36h
00h=>reg 30h
00h=>reg 32h

10h=>reg 30h
00h<=reg 36h
00h=>reg 30h
00h=>reg 32h

10h=>reg 30h
00h<=reg 36h
00h=>reg 30h
00h=>reg 32h

10h=>reg 30h
00h<=reg 36h
00h=>reg 30h
00h=>reg 32h
At this point, the "Error power up: VSS" is displayed?

So it keeps setting the terminate bit, read reg 36h, clears the terminate bit and then clears the sync register?
So is it expecting something to appear in reg 36h after setting the terminate bit?

root42 wrote on 2021-06-23, 08:09:

The biggest costs are the ET4000W32i chip (I paid 20€ per piece after customs from questcomp), the RAM and the RAMDAC. PCBs are less than 10€ at JLC. At the moment a full kit is roughly 100€.

If we can get the ET4000 chips for cheaper that would help. But I doubt we get it lower than 80-90€ BOM cost. When assembled it will be more costly if the one who does the assembly isn't doing it for free.

Hello,

May I ask you for help where I can buy ET4000W32i chip ? I have all other material already but I'm unable to get the main chip.
Thanks.

Hi

Now, my ET4000 card runs with full 2 MB video ram without corruption in image.

2x MB814260-70PFTN
1x KM416C256BT-7
1x M5M44260CTP-7

RAS/CAS line resistor are 33/10 ohm. (just putting few 10 ohm array from table 😉 )

all four DRAM came from dead hard disc.. TSSOP-44/40 and DRAM 256k x16 is not common, pleas change footprint to SOJ40 (very common)

It is confirmed, 35ns FPM DRAM is too fast.

regards
matt

Lovely, matt! I need to figure out what I did to break my own card. I also replaced the RAM. But now I only get garbage on screen.

About my last post, anyone knows anything about it? What is supposed to happen on a real ET4000/W32i graphics card when it reads back those values?

superfury wrote on 2022-10-16, 23:19:

So it keeps setting the terminate bit, read reg 36h, clears the terminate bit and then clears the sync register?
So is it expecting something to appear in reg 36h after setting the terminate bit?

My copy of a ET4000/W32i datasheet indicates you need to "wait for RDST (ACL Status Register, bit 0) to be zero". So this implies that setting the terminate bit is supposed to run a reset procedure that takes some time. Completion of the reset procedure will be indicated by either RDST (which is bit 1) or WRST (which is bit 0) going from 1 to zero. From your trace, I'm about to guess that you should make RDST (bit 1) read back as 1 for some time (or counts of reading the status register) on a rising edge of the "terminate" bit.

mkarcher wrote on 2023-08-11, 17:22:

superfury wrote on 2022-10-16, 23:19:

So it keeps setting the terminate bit, read reg 36h, clears the terminate bit and then clears the sync register?
So is it expecting something to appear in reg 36h after setting the terminate bit?

My copy of a ET4000/W32i datasheet indicates you need to "wait for RDST (ACL Status Register, bit 0) to be zero". So this implies that setting the terminate bit is supposed to run a reset procedure that takes some time. Completion of the reset procedure will be indicated by either RDST (which is bit 1) or WRST (which is bit 0) going from 1 to zero. From your trace, I'm about to guess that you should make RDST (bit 1) read back as 1 for some time (or counts of reading the status register) on a rising edge of the "terminate" bit.

So what happens on real hardware? How long is RDST and/or WRST set? Is it 256 cycles long (256 ACL registers being cleared one by one)?
Currently the terminate request is set as a custom ACL MMU write request (like it's MMU ACL aperture writes to VRAM), counted through it's ACL clocks the same way as normal map 0-2 ACL writes.

Currently, there's multiple ACL full writes:
- ACL queue
- ACL memory 0-2
- ACL suspend
- ACL terminate

All terminate in the same location in the code, timed by the rendering clock (the normal SVGA clock crystal that's being used and configurable by software using the misc output register bits and it's Tseng extension bits for higher speeds).

Edit: Implemented it to be 256 clocks for now. The clocks being in terms of rendering clocks in UniPCemu's case (it's ACL rendering is ticked by the same clock as the selected clock for the pixel/CRT generator).
Previously it was at 1 clock speed (so from CPU POV it's instant, since the video card is running way faster thsn the CPU (CPU only at 16 or 32MHz or 3MIPS(essentially ~12MHz) by default).

superfury wrote on 2023-08-13, 04:37:

So what happens on real hardware? How long is RDST and/or WRST set? Is it 256 cycles long (256 ACL registers being cleared one by one)?

I might be able to write/run a test tool the next days.

superfury wrote on 2023-08-13, 04:37:

All terminate in the same location in the code, timed by the rendering clock (the normal SVGA clock crystal that's being used and configurable by software using the misc output register bits and it's Tseng extension bits for higher speeds).

Using the rendering clock is very likely wrong. The ET4000 family chips have two different clocks: The pixel clock (MCLK, pin 19 of the W32i) and the system clock (SCLK, pin 22 of the W32i). Everything related to video memory is performed at the system clock. The accelerator is tied closely to the video memory and will run at the system clock. The pixel clock is used only for ticking the CRTC which generates the display timings. The pixel data is fetched from memory at system clock speed, and transferred through a FIFO to the scan-out logic. The idea of this FIFO is similar to the prefetch queue on the 8088. As the ET4000 can do burst reads and writes in fast page mode, it doesn't make sense to fill the pixel data FIFO with single 32-bit words, but a burst FIFO refill only starts when the fill level dropped to a configuratble value, so a burst refill is effective. The configuration of the FIFO is performed through the bits 7 and 5 of the CRTC register 0x37. Bit 7 controls the amount of data remaining in the FIFO that will start a refill. Bit 5 controls the depth of the FIFO. It seems pixel FIFO refills are non-interruptible, so refilling the pixel FIFO blocks the video memory from other accesses. A deeper FIFO means that the bursts are longer (higher throughput, but more latency if a different party, e.g. the host interface on video memory reads, requests video memory access). The W32i datasheet allows up to 50 MHz system clock. The AX datasheet allows up to 41.6 MHz, and 40.0 MHz is the usual SCLK frequency of the AX chip.

superfury wrote on 2023-08-13, 04:37:

Edit: Implemented it to be 256 clocks for now. The clocks being in terms of rendering clocks in UniPCemu's case (it's ACL rendering is ticked by the same clock as the selected clock for the pixel/CRT generator).

Did it help passing the "VSS" test?

mkarcher wrote on 2023-08-13, 07:32:

I might be able to write/run a test tool the next days. […]
Show full quote

superfury wrote on 2023-08-13, 04:37:

So what happens on real hardware? How long is RDST and/or WRST set? Is it 256 cycles long (256 ACL registers being cleared one by one)?

I might be able to write/run a test tool the next days.

superfury wrote on 2023-08-13, 04:37:

All terminate in the same location in the code, timed by the rendering clock (the normal SVGA clock crystal that's being used and configurable by software using the misc output register bits and it's Tseng extension bits for higher speeds).

Using the rendering clock is very likely wrong. The ET4000 family chips have two different clocks: The pixel clock (MCLK, pin 19 of the W32i) and the system clock (SCLK, pin 22 of the W32i). Everything related to video memory is performed at the system clock. The accelerator is tied closely to the video memory and will run at the system clock. The pixel clock is used only for ticking the CRTC which generates the display timings. The pixel data is fetched from memory at system clock speed, and transferred through a FIFO to the scan-out logic. The idea of this FIFO is similar to the prefetch queue on the 8088. As the ET4000 can do burst reads and writes in fast page mode, it doesn't make sense to fill the pixel data FIFO with single 32-bit words, but a burst FIFO refill only starts when the fill level dropped to a configuratble value, so a burst refill is effective. The configuration of the FIFO is performed through the bits 7 and 5 of the CRTC register 0x37. Bit 7 controls the amount of data remaining in the FIFO that will start a refill. Bit 5 controls the depth of the FIFO. It seems pixel FIFO refills are non-interruptible, so refilling the pixel FIFO blocks the video memory from other accesses. A deeper FIFO means that the bursts are longer (higher throughput, but more latency if a different party, e.g. the host interface on video memory reads, requests video memory access). The W32i datasheet allows up to 50 MHz system clock. The AX datasheet allows up to 41.6 MHz, and 40.0 MHz is the usual SCLK frequency of the AX chip.

superfury wrote on 2023-08-13, 04:37:

Edit: Implemented it to be 256 clocks for now. The clocks being in terms of rendering clocks in UniPCemu's case (it's ACL rendering is ticked by the same clock as the selected clock for the pixel/CRT generator).

Did it help passing the "VSS" test?

Just ran VDIAG. It still gives the error on the "Power up: VSS".
So it still errors out?

I see normal display setup (for 80x25 text mode) when booting:
- Sending 0x10 to the ACL register to terminate operation.
- Reading 0x03 from the ACL status a few times (4 times in total). The SCLK times these clocks (256 clocks in total, at 40MHz).
- Suspend/terminate finishes, clearing all registers in one go. This sets the ACL status register to 0x00 (low 3 bits cleared).
- The result from the status register now reads 0x00.

I'm just thinking... Perhaps some other bits are expected to be set after the reset?
If bit 0 or 1 supposed to clear before the other bit is set?

Bit 4 isn't set, because the queued registers are unmodified by the terminate operation.

Edit: Just modified the accelerator to no longer set bit 1 when terminating the operation. It will leave it if it was already set (due to terminating), but if inactive to begin with, it will only set and clear bit 0 now (set during the counting, cleared when terminated and all registers are reset to power-up defaults (whatever those may be. Currently just all registers becoming cleared)).

Edit: I see the BIOS ROM clearing the terminate bit manually after only 0x55 (85 decimal) cycles? Perhaps it needs to somehow be done within said time?
UniPCemu only sets bit 0 before (and is forced to clear it when 85 cycles elapse)?

During the testing program, the counter ends up at 0x8A before being stopped by the BIOS resetting the bit?

Edit: Still the VSS error pops up?

I see it writing 0x10 to the Suspend/Terminate register, then reading 0x01 from the status register once (due to slow 486 32MHz CPU), then the terminate finishing (which clears the bits in the status register) once it times out, writing 0x00 to ACL register 0x32, writing 0x00 to register 0x30. writing 0x00 to register 0x32, reading register 0x36 (being 0x00), then writing register 0x38 value 0x00 (shouldn't exist?), register 0x39 value 0x00 (same as 0x38), register 0x3a value 0x00, register 0x3b value 0x00, register 0x34 value 0x00, followed by normal defined registers being accessed (memory aperture registers, followed by normal 0x80+ defined registers).

OK. Just checked the ET4000 W32i and W32p documentation again:
- On the status register RDST/WRST, both agree.
- On the suspend/terminate register, they disagree:
- W32p: suspend: RDST set&cleared (bit 1) on Revision A, other revisions use bit 6 instead? Terminate uses it as well.
- W32i: Same for RDST in both suspend and terminate, but both mention it's bit 0 of the status register!

Right now, UniPCemu makes those two fill bit 0, but not bit 1 of the status register? Should it not set bit o and only bit 1? What is the truth?
What happens to WRST during this suspend/terminate?

Edit: Just modified the UniPCemu code to set bit 1 (RDST) as documented on the W32p documentation, but make an exception and not set bit 0 (WRST) in that case (it is set for only the queued register writes or ACL memory writes being in the queue).

Basically, what software sees is just bit 1 setting and clearing (with bit 0 being unmodified, although clearing if terminate flushes the buffer, which in turn causes bit 1 to clear as well once UniPCemu parses the idle action of the ACL).

Edit: The error still persists. So bit 1 setting and clearing doesn't make it go away. Bit 0 (WRST) doesn't either? Both bits setting and clearing doesn't either.

Why would it cause the VSS power-up error? Is it not liking the state of any of the registers read back?

UniPCemu basically clears them all when a terminate is issued (just a simple memset call on the 80h+ register range. The lower registers are only cleared in the 30h+ range (31h,32h,34h and 35h(bits 5-7 only), as well as 30h (except bit 4, which is left set, although ignored afterwards))). Only the Terminate bit is left alone in this case (according to documentation).

Well done, Madao! Good work figuring out the issue. I really haven't had time for my projects (this VGA card included) in the past couple of years -- usual life business, that is.
Back in 2021 or so, I also spotted timing issues on the Hewlett Packard 16500C logic analyzer -- it was a pain to install all those test leads on the DRAM data bus. But I didn't step further into the analysis. As far as I recall, the datasheet states that 45 ns or 50 ns memories are required for interleaved operation.

I'll try slower RAMs as well. But ... when I'll find some spare time to return to my x86 hardware design experiments. For now, they're all frozen 🙁

Cheers,
A.

Hi

I want to build this VGA card. Please help where can I get the BIOS.
Thanks.

I sent it to you as an attachment to a private message on the forum.

Thank you, here is my video card.

I was just able to grab 3 W32I chips for a really good price. About $20 each, shipping inclusive.
I'm looking to put together a modified version of these cards with a marginally lower chip count.

I'd effectively be redoing the layout of most of the card and layout from scratch, and I'm thinking of using two 1MB chips (reducing chip count by two), but 5v 1MB DRAMs seem hard to find. 256 x 16 chips seem much more common and easy to find (leaving the chip count the same).

Any advice?

iyatemu wrote on 2024-04-02, 04:01:

I'd effectively be redoing the layout of most of the card and layout from scratch, and I'm thinking of using two 1MB chips (reducing chip count by two), but 5v 1MB DRAMs seem hard to find. 256 x 16 chips seem much more common and easy to find (leaving the chip count the same).

To make use of one of the key features of the ET4000/W32i for high resolutions, the memory bank interleaving that is reflected in the "i" suffix, it is important to have two banks of 32 bits each, so your 1-megabyte DRAM chips would need to be 256K x 32. Two 512Kx16 chips will not allow interleaving - if they are supported at all. I can find 256K x 16 5V chips a dime a dozen, and if I am really desperate to get some, I will buy a "for parts only" untested very early PCI graphics cards on ebay (be careful to not get EDO, see below), which usually contains 2 to 8 of these chips. On the other hand, I have no idea whether I have a single 5V FPM 256K x 32 at all.

For bank interleaving on the ET4000/W32i, it is of utmost importance to not use EDO, but FPM only, because the bank interleaving requires that the "inactive" bank stops sending data as soon as the /CAS signal gets de-asserted, otherwise, both banks will conflict. The key point of EDO is that it allows to pipeline two stages of RAM reading inside the RAM chip, allowing similar performance with a single bank to what the W32i achieves using two banks. As EDO RAM was not common when the ET4000/W32i was designed, Tseng used bank interleaving an incompatible way to achieve the same result - they pipeline the memory access by interleaving data transfer between two different chips. So this adds another constraint to your search: You would need 256K x 32, 5V, FPM RAM. While there definitely are x32 RAM chips, I tend to see them only at 3.3V, and with an EDO or SDRAM interface. That's technology that is way newer than the ET4000/W32i.

If you just want to get highest DOOM or Quake 360x480 scores, and do not care about SVGA speed / operation, bank interleaving is likely not required at all, and you could just go with just 1MB in two 256k x 16 chips. As you only have a single bank, you will probably get away with using EDO chips as well. But in that case, why even bother with the W32i? "Highest DOOM scores on an ISA bus" is perfectly achievable with the ET4000AX as well, so that use would be a waste of perfectly good W32i chips.

wonder if OE to CAS mod would work with EDO chips on ET4000 Re: What retro activity did you get up to today?

rasz_pl wrote on 2024-04-02, 11:42:

wonder if OE to CAS mod would work with EDO chips on ET4000 Re: What retro activity did you get up to today?

Thanks for reminding me about the OE-to-CAS idea. One needs to check the timing specification of the ET4000/W32i and the RAM chips very carefully to see whether they match. The bank interleave mode is designed to push the FPM chips of that time to the limits, and IIRC the ET4000 chip relies on a positive hold time of the data relative to the trailing edge of /CAS, which might not be provided by fast EDO chips.

mkarcher wrote on 2024-04-02, 07:10:

If you just want to get highest DOOM or Quake 360x480 scores, and do not care about SVGA speed / operation, bank interleaving is likely not required at all, and you could just go with just 1MB in two 256k x 16 chips. As you only have a single bank, you will probably get away with using EDO chips as well. But in that case, why even bother with the W32i? "Highest DOOM scores on an ISA bus" is perfectly achievable with the ET4000AX as well, so that use would be a waste of perfectly good W32i chips.

I already have a 4000AX, but truthfully, I just like absurd old technology. I'm running a 486DLC-40 in a tiny little system. I want to try building one of those interposers to add a 168-pin 486SXL2-33/66 in there. But, there's another version that's been created that can be set for any 486-class processor, which implies Overdrive too. Potentially running Win95 with an Overdrive on a 386 board with a W32i seems absurd enough to me to warrant building a 32i card, and it's much cheaper to build one based on the Excelgraph (or just an EG outright) than buy any preexisting W32i card.

I'll just go with the 4 256x16 chips like the OG design, but I'll still need to change the footprints to something more widely available that the W32I might have a better chance of driving.