ALEKS wrote on 2022-01-24, 13:08:

...I am glad to see activity on the project! I haven't read the previous pages but I get that you want to try lower speed DRAM chips. That might actually be a solution and they might work without hassles. The original TSENG datasheet requests for 45-50 ns DRAM ICs, as far as I remember.

Looking at the few grainy pictures of w32i cards that exist any more, you can see a spread of chips anywhere from 45-70ns. There are two (extremely expensive) cards on ebay right now with memory at 60 and 70 ns, and one of them doesn't even have any resistors between the W32i and the memory chips.

I found some 60ns FPM chips similar to the ones on those cards that I'm probably going to use on the card I plan to build. I'll probably socket the resistor packs like you did on your card and try different resistor values as well as zero resistance to see how the card performs.

It's slow going, I gathered some hard-to-find parts, remade the schematic in KiCad, but haven't begun laying out a PCB at all yet, just brainstorming parts placements.

I'd like feedback on the competency of the schematic, to make sure that everything is okay, particularly with the very big modifications I've made like switching buffer chips out for in-line ones and adding a feature connector, before actually making a PCB.

A screenshot of the schematic and the PDF are attached below.

Any suggestions are welcome (but I do like to argue!).

Hi,

Nice work on redrawing the schematic diagram. Well done. At a first glance, the diagram looks OK.
However, if you're going to use only 4 memory chips, I'd ditch the buffers as they just add complexity to the layout.
Also, if you'd like to streamline the design even more, then IRQ9 line can be ditched as well.

In my initial article, I have made some wrong assumptions and ended up designing some interposers, but the reality was that the memory timing was wrong; I just used faster memories than the ET4000/W32i chip could interface.
I'm not sure whether I presented these or not to the community as a lot has happened in the meantime.

and

Subsequent tests revealed that my add-on buffers (in reality, a sort of delay line constructed around some damping resistors and decoupling capacitors) did nothing to the card memory speed issue (as expected). I was just going to change the RAM chip packages on my design to something more easy to find, but life matters ate all my spare time. The required RAM speed should be 45 ns to 50 ns.

Cheers,
A.

Can the IRQ9 even be dropped? Isn't it required by various software to perform ACL operations? Doesn't the original card have a jumper for that?

Yes, I wired the IRQ9 signal in my initial design. But, in MS-DOS, IRQ9 isn't triggered, as far as I tested.
I think it was initially intended for vertical retrace purposes.

Good point about the ACL. The Windows driver might indeed use it.
Well, in this case, please disregard my remark about IRQ9 in the previous post.

Cheers,
A.

ALEKS wrote on 2024-09-04, 12:53:

Yes, I wired the IRQ9 signal in my initial design. But, in MS-DOS, IRQ9 isn't triggered, as far as I tested. I think it was init […]
Show full quote

Yes, I wired the IRQ9 signal in my initial design. But, in MS-DOS, IRQ9 isn't triggered, as far as I tested.
I think it was initially intended for vertical retrace purposes.

Good point about the ACL. The Windows driver might indeed use it.
Well, in this case, please disregard my remark about IRQ9 in the previous post.

Cheers,
A.

Also, wrt MS-DOS not triggering the IRQ, it's simply because it doesn't enable it in the vertical retrace register?
There's various registers involved afaik:
- The vertical retrace end register bit 5 being cleared should enable the interrupt on vertical retrace start. The flipflop (IRQ line) is cleared by writing bit 4 of said register with a 0. This matches the EGA documentation.
- CRTC Register 25h(ET3000) or 35h(ET4000) bit 6 changes the interrupt source to be on the CRTCB/Sprite controller instead (when the last scanline rendered ends rendering it's last pixel in my implementation).

I don't know how the two interrupt sources (The CRTCB/Sprite or vertical retrace end combined with ACL interrupt line) combine though? UniPCemu lets either of them raise the IRQ line, clearing the outputted line with either method. But if both sources (ACL source and the CRTCB/Sprite/Vertical retrace end source) raised simultaneously before being lowered, the first acnowledge method used lowers the output signal while the second (the other signal that was raised) has no effect on the specific device IRQ pin (it does clear either the latch(vertical retrace/CRTCB/Sprite) if that's used to lower or otherwise the ACL IRQ registration if that's used to lower the IRQ).
So basically the two systems affect the output signal being raised and lowered, but lowering doesn't register on the opposite's registers (the ACL register ACK doesn't affect the latch and the latch doesn't affect the ACL register output registration).
So basically it's like this right now:
1. ACL raises an IRQ. IRQ line output goes high.
2. Vertical/CRTCB/Sprite raises an IRQ. IRQ line output unchanged (still registered on the IRQ output though in any case).
Then either:
3A) ACL gets acknowledged while high. ACL clears the ACL side of the signal registration and lowers the global IRQ line. Vertical/CRTCB/Sprite is left registered high even though the signal is already lowered. Lowering Vertical/CRTCB/Sprite will only affect the internal state (flipflop and register itself) after this (unless raised again for some reason).
3B) Vertical/CRTCB/Sprite gets acknowledged while flipflop set (by resetting the flipflop). Clearing the register bit will clear the flipflop (the way it's acknowledged actually) and lower the global IRQ line. If the ACL is acknowledged after this it will only affect the internal state (ACL registers) after this (unless raised again for some reason).

3A and 3B can trigger after case 1 or 2 respectively. Basically, both have their own internal state that's set on raise (and used for lowering detection). When raised for either reason, they raise the global IRQ flag (in UniPCemu actually on the IRQ controller inputs directly using a function call, but it's essentially a simple 1-bit register). If case 1 or 2 occurs with a previous low output, it will trigger an IRQ in the IRQ controller (8259A and/or IOAPIC (depending on configured IR line in the controller it can be inverted or handled differently though, like edge or level triggered, inversed signal etc.)) by raising the IR line. When either source gets acknlowledged they acknowledge locally (since the controllers have no knowledge about each other afaik, even on the same chip die (never read anything about if they did though)) and only globally if the global flag was set.

It's a good question what really happens on a Tseng ET4000/W32(/i/p) controller though? It should be testable easily by enabling both interrupt sources (both ACL and vertical for instance and ease of testing), then letting them trigger both lines and observing the IRQ inputs on the 8259A chip that's in level triggered mode for the IRQ (to be able to observe the IR line outputs together with the register outputs)?
If it's like UniPCemu implements it, triggering the ACL first (using a simple transaction that's way faster than a video frame) and then waiting for the vertical retrace to start using polling will cause both outputs to be set. Then if you acknowledge either and the IRQ line doesn't lower on the (A)PIC that means that UniPCemu has a faulty implementation and they use a shared input. And of course it can also detect the case (by reading the vertical retrace IRQ status after finishing the ACL operation) where the ACL triggers the IRQ line using the vertical retrace registers instead (which UniPCemu currently doesn't, both are seperated systems). If they share the actual IRQ flipflop (documented in the EGA documentation), you'd see acknowledging either will clear the flipflop that's reported in the status registers. That should be immediately visible after the ACL transaction completes (since it will trigger the IRQ right then and there, way way before the vertical interrupt cause can do that). I wouldn't be surprised if that's the case though.

Anyone brave enough to test with a real ET4000/W32i (ofc with IRQ9 enabled)?

A simple way to make it trigger the IRQ9 signal for testing (using the vertical retrace interrupt) is running the EGA demo 'Fantasy Land'. It programs the IRQ2 to be enabled as in the EGA/VGA documentation (using the registers I mentioned). It should be fairly obvious when the IRQ fails for some reason (I think you'd see the scroll-in and scroll-out of the top window (that scrolls in from below) not happening anymore or some related effect, don't remember exactly what it was used for).
Edit: Yeah, I was right:
https://www.os2museum.com/wp/fantasyland-on-vga/

There is yet another problem with many VGA cards. FantasyLand uses vertical retrace interrupts to achieve smooth animation, with the split screen nicely sliding up and down. On many VGA cards, vertical retrace interrupts do not work.

I'm curious what would happen on a ET4000/W32i card... It should be able to emulate EGA in some way (I've implemented it in UniPCemu at least). I don't know if it's triggered by the BIOS or some special program though (EGA emulation mode). Maybe by the default mode set on a EGA mode with specific EGA values found in the BDA?

I can check that FantasyLand demo on my ET4000/W32i, maybe this evening. Or more certainly during the weekend.
However I might not have enough time to connect the logic analyzer to the IRQ9 line to capture the triggering events (if any). I think I should be able to catch IRQ9 events through a small TSR assembly program; but that would take me far longer than connecting a logic analyzer probe to the interrupt request 9 line.

Or, if the IRQ9 is repetitively triggered fast enough, I might be able to visually catch it with my Signal View interface; LED20 should light up.

But I will at least try to launch the demo. For some reason I missed the EGA days. I have some experience with CGA and more with VGA. Thus, I never thought about EGA emulation through VGA display controllers.
Anyway, that's some good food for though. I'll have to read about it and learn a bit on this EGA emulation.

Thank you for the comment above and the link to FantasyLand -- I didn't knew about it.

A.

Well, I tested FantasyLand with the ET4000/W32i card and it doesn't work.
Here's a small clip with the display flickering around: https://youtu.be/sgUEaU6eliY

I guess there's no need to fire up the Logic Analyzer anymore.

A.

ALEKS wrote on 2024-09-05, 20:02:

Well, I tested FantasyLand with the ET4000/W32i card and it doesn't work. Here's a small clip with the display flickering around […]
Show full quote

Well, I tested FantasyLand with the ET4000/W32i card and it doesn't work.
Here's a small clip with the display flickering around: https://youtu.be/sgUEaU6eliY

I guess there's no need to fire up the Logic Analyzer anymore.

A.

Maybe it needs the translation ROM for some reason? Or is that just for CGA/MDA support?
Does the special Tseng EGA compatibility mode require the LUT translation ROM chip to work?
It's documented in the w32i manual afaik (4000AX as well documents and supports it)?
Does someone have a dump of the translation ROM btw? It'd be nice to implement that one, if possible.
Edit: So far implemented loading the 2 ROMs into UniPCemu. Also implemented the documented translation lookups, although not yet called by the CRTC and misc output register reads/writes.
Right now both ROMs are loaded seperately.

I found some clue about some people posting the ROM(s) on a forum, but it's a dead link?
https://forum.vcfed.org/index.php?threads/orc … tion-rom.57728/
Edit: Yay! Found it on minuszerodegrees!
https://www.minuszerodegrees.net/rom/rom.htm
Search for Orchid on the page for the ROM.

But that's just one 32KB ROM? Orchid is apparently an early ET4000 adaptor. And the ET4000 chip it uses uses that ROM.
Doesn't the ET4000 require 2 ROMs (as is documented) of 32KB each? Or is the ROM combined in some way?
Edit: https://dosdays.co.uk/topics/retro_review_et3000_pt1.php
OK. So a single 32KB sync ROM is correct. Then how is it wired up to the ET4000 chip (which assumes two ROM chips in it's documentation)?
How would BDB15 and DIR be wired onto this chip? Or did they only read half of the chip's contents?

Edit: Maybe it's figured out from the pins on the back and front of the images?
https://dosdays.co.uk/topics/retro_review_et3000_pt1.php
https://dosdays.co.uk/media/tsenglabs/ET3000/ … 16_et3000_1.jpg
https://dosdays.co.uk/media/tsenglabs/ET3000/ … 16_et3000_2.jpg
That 444.837 chip (rev. V2.62) chip seems to be the translation chip, from what's mentioned down on the page.
So comparing the two board photos, I at least managed to find out their locations on the backboard, I think?

So then it would be possible to check where those traces are going? What pins are the address (BDA) pins and DIR pin from the ET4000 connected to on the ET3000?
The ET3000AX chip faces the right side (so if turned 90 degrees clockwise it's straight?
Btw, https://thandor.net/object/529 seem to have another one on display.
Looking for the chips (https://datasheet.octopart.com/D27256-2-Intel … et-17852618.pdf) I see that the top-left pin (front) or top-right(back) is the VCC pin, followed by A14 and A13. Then A8,A9,A11,(some control line),A10,(another control line),data bus 7 through 3. The bottom row starts with A12 (opposite side of A14), then A7, A6 through A0, data line 0 through 2. The data lines give the output (which is based on the A14-A0 lines) for the reads performed from what I can see.
So now the question is how the A lines are wired to the rest of the system?
Edit: Just took a look at the ET4000 documentation again. It doesn't mention the read ROM in it's schematics?
It just mentions the write ROM in it's schematics, with BDB14-8 to A14-8(expected), DB7-0 to A7-A0(so driving the CPU input pins here), +DIR to CE(chip enable), -XROM to OE(so when a XROM lookup this is always the case, so it's always reading data from the chip! Otherwise it could mess up the data or results), BDB0-7 from Q0-Q7(the outputs of the lookup)?
For the read ROM it's apparently slightly different (seen on the Microchannel schematic, not on the AT schematic):
- BDB0-7 drive the A0-A7 inputs (the documented lookup in this case).
- DB0-7 receive the outputs from the translation.
- -DIR is used instead of +DIR. So it's not driving CE(chip enable), thus floating it's result on the AT. So during reads, the ET4000 drives it itself without translation (see explanation of RDMLL below).

Assuming XROM always properly works, this would mean that read lookups have the lower bits of the address and the output pins swap places?

So basically the write ROM translates the CPU input value in the low bits of the lookup(BDB0-7 receives the results) for CPU writes, while the read ROM translates the Tseng lookup (DB0-7(the CPU) receives the output to use by the Tseng chip(given in BDB0-7)) and gives it to the CPU directly on it's address pins? Do I understand this correctly?
The AT architecute otoh just documents the write chip, but no read chip? So the chip that's on the single-chip boards (the 32KB chips) are always write translation chips, with no read translation chips implemented?

Basically, with only 1 32KB translation chip, the chip is actually the write ROM, never the read ROM! Is that correct?
Edit: RDMLL is an interesting one in this AT configuration case. It's lowered during:
- AT VRAM reads
- AT VRAM writes
- AT BIOS reads
- AT I/O reads without translation
- AT I/O writes without translation
- Microchannel VRAM reads
- Microchannel VRAM writes
- Microchannel BIOS reads
- Microchannel I/O reads without translation
- Microchannel I/O write without translation
Lowering RDMLL causes the ET4000 to drive/receive(connect) DB0-7 itself I think (it's going through a LS245 chip from what I can read. It's inputs are -RDML(connected to OE? The documentation reads E though?) and +DIR(connected to +DIR input))? And raising RDMLL disables the outputs?

So it's not driving DB0-7 at all when it's in AT mode during any AT read/write translation at least? So when it's translating I/O reads using the translation ROM chip in AT mode, the internal DB bus is driven with the original value (which is read by the CPU even in translation mode), but since RDMLL isn't lowered, it doesn't drive the DB bus with it's value? The Microchannel one otoh doesn't use the above circuit, thus always driving DIR low and DB as is expected.

So the AT chip configuration only supports one translation chip (which is the write chip). The reads translation has no effect on the resulting data in AT mode (only in read translation ROM mode it's actually not driving the DB bits so that the result from the translation can respond)!
Edit: Just now adjusted the lookup to perform a AT-style passthough when the read translation ROM isn't loaded, otherwise use the ROM to perform proper translation (although architecturally incorrect, it eases single ROM implementations as documented).
Edit: And implemented the whole translation lookups for Misc Output register and CRTC reads/writes. It's enabled if the ENXL(writes) or ENXR(reads) are enabled, translating the values through the ROMs. And the translation function for looking up in the ROM checks for AT to disable the read translation ROM (which is currently simply based on the read translation ROM not being present).
It also has a mask and extra bits for the CGA CRTC lookup (replacing bit 4), but it's currently a if-false check since I don't know yet how the chip detects it's in 'CGA' mode for translation? The ET4000AX documentation mentions that CGA mode, but I can't find anything about how it detects that case?

ALEKS wrote on 2024-09-04, 07:29:

Hi,

Nice work on redrawing the schematic diagram. Well done. At a first glance, the diagram looks OK.
However, if you're going to use only 4 memory chips, I'd ditch the buffers as they just add complexity to the layout.

I can just remove the 245 ICs?

Reading through I also see that the IRQ9 switch is something there would be no harm in leaving in, good to know. Thanks for taking the time to look at my recreation.

Hi,

No, the octal bus transceivers (*245) are required, so it’s good to be kept.

I had the wrong impression that you used U101 and U102 for video RAM CAS and RAS buffering, but I was wrong. The second time I looked at the schematic, I saw that they are used for the VGA feature connector, something that I don’t have in my design. Thus, disregard my initial remark — sorry about that.

Now regarding IRQ9, keep it as well. If the Windows driver uses it for the ACL then it’s mandatory actually.
Even though I connected it in my initial design, I wasn’t sure whether it would ever be triggered. One day I will try to test with the logic analyzer while in Windows.

A.

ALEKS wrote on 2024-09-07, 20:33:

Hi, […]
Show full quote

Hi,

No, the octal bus transceivers (*245) are required, so it’s good to be kept.

I had the wrong impression that you used U101 and U102 for video RAM CAS and RAS buffering, but I was wrong. The second time I looked at the schematic, I saw that they are used for the VGA feature connector, something that I don’t have in my design. Thus, disregard my initial remark — sorry about that.

Now regarding IRQ9, keep it as well. If the Windows driver uses it for the ACL then it’s mandatory actually.
Even though I connected it in my initial design, I wasn’t sure whether it would ever be triggered. One day I will try to test with the logic analyzer while in Windows.

A.

I can check with Windows 95 I've installed directly on UniPCemu, but right now the CPU is a bit broken (hard disk crashes loading MS-DOS 6.22, floppy fails properly executing FDISK as well it seems), still trying to find the culprit in the CPU. Test386.asm says that the AAM instruction fails, while other testsuites (From Hiren's BootCD 7.8 ) like The Troubleshooter say that the string instructions are broken somehow (used to work fine on the last release?). Looking at them, I see them executing just fine I think, other than weird opcodes being fetched eventually somehow(like MOV /x with rm set, GRP5 /7, weird 0F3x instructions etc.) and most recently fdisk executing an ADD on DS:10000, crashing/hanging itself in a #GP fault to itself.

Just have been wondering... On the ET4000 and related chips, various extended registers are protected by the KEY.
Could it be that the ET3000AX also requires such a key for it's extended registers (or at least some of them)?
The documentation (only 1 document on the internet from what I can find, which is the Programmer's Guide to the EGA, VGA, and Super VGA Cards and the vgadoc documentation) doesn't explain the KEY being required?
Does the ET3000AX need the KEY like the ET4000 and compatible chips (like W32/W32i/W32p)?
Edit: Just added ET3000-only support for 8 simultaneous fonts.
I'm wondering though, would that require disabling bits 3-7 of the attribute byte (masking it off)? Or only clearing bits 3-5, as bit 6 is marked ~bit5 and bit 7 isn't mentioned? What does real hardware do with that? Simply mask bits 3-5/6/7 off for font/background translation on the attribute controller?

Hi all!

I've been following this thread for a while, and also build myself an Excelgraph.
Tseng ET4000 are priceless on Ebay and elsewhere, and building the project was a lot of fun.

I attached some pictures of my card! However, I'm having some trouble finding the right BIOS for the card, it seems. The BIOS I'm using currently only detects 1MB out of the 2MB on the card. I have another BIOS from a Hercules card that detects the 2MB correctly, but fails too load most games and software.

Could someone perhaps share a BIOS image that works well with the Excelgraph? I do have the fast 35ns chips, but I suspect that the BIOSes I've been using are simply not optimal for the card.

PaulV wrote on 2024-09-14, 11:30:

Hi all! […]
Show full quote

Hi all!

I've been following this thread for a while, and also build myself an Excelgraph.
Tseng ET4000 are priceless on Ebay and elsewhere, and building the project was a lot of fun.

I attached some pictures of my card! However, I'm having some trouble finding the right BIOS for the card, it seems. The BIOS I'm using currently only detects 1MB out of the 2MB on the card. I have another BIOS from a Hercules card that detects the 2MB correctly, but fails too load most games and software.

Could someone perhaps share a BIOS image that works well with the Excelgraph? I do have the fast 35ns chips, but I suspect that the BIOSes I've been using are simply not optimal for the card.

The excelgraph uses a BIOS from a Micro-Labs card that's impossible to find. I've gotten BIOSes from an ISA Hercules Dynamite and one of those ET4W32 l-5 cards, but without building the card, I obviously can't test either.

The BIOS for the ET4 is here:
https://theretroweb.com/expansioncards/s/axis … e-et4w32-5#bios

The Micro-Labs card the Excelgraph is based on is also on the site:
https://theretroweb.com/expansioncards/s/micro-labs-mlix2
... but with no BIOS dump.

If Mr. Groza would be kind enough to provide a dump of that card's BIOS, it would be greatly appreciated.

Regarding the ET3000 8 simultaneous fonts, I ran TVDIAG from https://github.com/joncampbell123/dosbox-x/issues/2819 on my emulation.

I now get:

Is that correct behaviour? Are the fonts in the correct order? What about the background color bits? Are they supposed to be zeroed when sent to the attribute controller when in 8 font mode?
Is bit 6 of the attribute supposed to do something? Isn't it just using bits 3,4,5 as a simple 3-bit index (read in normal little-endian bit order)?

Edit: Managed to get the bit mapping working correctly:
Essentially:
1. If 8 fonts mode enabled:
1.1 If bit 6 and 5 of the attribute aren't equal:
1.1.1 map bit 6 to bit 0 of the lookup (MA13)
1.1.2 map bit 3 to bit 1 of the lookup (MA14)
1.1.3 map bit 4 to bit 2 of the lookup (MA15)
bits 0-2 of the lookup then are the replacement of MA13(bit 0), MA14(bit 1) and MA15(bit 2) of the font RAM planar address used (the lower bits are from the character (8 bits below it) and row scan counter (lowest 5 bits)). Those inputs map directly to 0,4,8,c,2,6,a,e memory maps (from the output of the 8 fonts mode translation).

I've moved my conversation to my other thread about this, splitting off on this topic: Real ET3000 8 simultaneous fonts effects on attribute controller?

Hi PaulV and jyatemu,

Indeed, the source of my inspiration for the component layout was that MLI card, as I had it in my spare parts box (I bought it from Micro-Labs directly, one of the last cards that Ted had available). The initial BIOS modifications for the original card were treated in a specific article on my site. The EXCELGRAPH texts and highlights are actually assembly programs compiled and injected in the BIOS binary code, by aid of an additional suite of self-wrote software. I'm unsure what happens if someone edits directly the binary file with a HEX editor.

For the schematics, a combination of the ET4000AX and the ET4000/W32i datasheets was the source. Also, the DAC section was improved by using a voltage reference diode in order to produce stable and predictable colors and RAMDAC behavior between different card assemblies. Of course, a precision metal film resistor divider would've worked perfectly fine, but if we can do it better, why not?

PaulV, that's a very weird BIOS that you have. Where do you have it from?
I've attached my BIOS variant as a ZIP archive. The modifications don't alter the original microcode in any way. Only the fonts and the card name are modified. From my knowledge, these Tseng BIOSes were provided by Tseng, and were card-specific, only in terms of the graphics controller variant (AX, W32i, W32p). The various card branding identifiers were added as per the request of the company that built the cards. Thus, a BIOS tailored for the ET4000/W32i should work for all cards constructed around this chip.

The attached BIOS variant will detect 2.0 Mb of RAM, if used with the EXCELGRAPH card, as the RAM is hardwired for interleave mode.

Let me know if it works!

By the way, you should try to find 45, 50, 60, or even 70 ns RAM chips. Just spare yourself of the hassle with 35 ns chips -- these are too fast for the ET4000/W32i controller. I also updated the article on my site with this information. I have some more pictures and handwritten notes and someday I'll add them to the article, just to document everything I did.

In the meantime, I also ordered a few 70 ns chips for experimenting around. I'm pretty sure they will work. In addition, 33 R resistors should be used with the correct memory chips.

Cheers,
A.

Hi Aleks! Thanks for your reply.

I think I'll also try to source some slower RAM chips and give them a try.
The BIOS is just a generic ET4000/W32i one I found somewhere - I edited the BIOS to show a custom message and give it some color.
These slight modifications did not seem to change the card's behaviour and I found that the text can be changed just by using a HEX editor.

The only caveat is the checksum that needs to be recalculated and updated in the BIOS ROM, or else the card will not work.

Many thanks for sharing the BIOS, and I'll let you know if it works for me.

Regards,

Paul

Any idea how the 2 byte character code setting (ATC reg 16h) work? How does that affect the memory addresses for character base address?

I think I've done it. I really really do want to make sure everything is good before ordering any boards though, they're expensive no matter how many you get. 1 from OSHpark or 10 from PCBWAY makes no difference if they don't work, $150 is $150 no matter how you slice it.

I've attached an adjusted schematic for the card, a few pins are shuffled around on, for example, one of the resistor packs, and one of the 541s used for flow control of the Feature Connector. I've also gotten rid of some of the bulk capacitors and extra bypass caps because the Feature Connector is taking up whatever space they were using on the original design. This was done on the advice of others that the redundant caps were really just unnecessary.

Also, here are some screenshots showing off the routing. If you can make out how it's routed at this scale, I'd really appreciate any feedback on this too.

Even if it is an adaptation of someone else's work, This is the most ambitious project I've undertaken, and I want to make sure everything has the highest chance of working before ordering anything.

ALEKS wrote on 2024-09-17, 10:06:

Hi PaulV and jyatemu, […]
Show full quote

Hi PaulV and jyatemu,

Indeed, the source of my inspiration for the component layout was that MLI card, as I had it in my spare parts box (I bought it from Micro-Labs directly, one of the last cards that Ted had available). The initial BIOS modifications for the original card were treated in a specific article on my site. The EXCELGRAPH texts and highlights are actually assembly programs compiled and injected in the BIOS binary code, by aid of an additional suite of self-wrote software. I'm unsure what happens if someone edits directly the binary file with a HEX editor.

For the schematics, a combination of the ET4000AX and the ET4000/W32i datasheets was the source. Also, the DAC section was improved by using a voltage reference diode in order to produce stable and predictable colors and RAMDAC behavior between different card assemblies. Of course, a precision metal film resistor divider would've worked perfectly fine, but if we can do it better, why not?

PaulV, that's a very weird BIOS that you have. Where do you have it from?
I've attached my BIOS variant as a ZIP archive. The modifications don't alter the original microcode in any way. Only the fonts and the card name are modified. From my knowledge, these Tseng BIOSes were provided by Tseng, and were card-specific, only in terms of the graphics controller variant (AX, W32i, W32p). The various card branding identifiers were added as per the request of the company that built the cards. Thus, a BIOS tailored for the ET4000/W32i should work for all cards constructed around this chip.

The attached BIOS variant will detect 2.0 Mb of RAM, if used with the EXCELGRAPH card, as the RAM is hardwired for interleave mode.

Let me know if it works!

By the way, you should try to find 45, 50, 60, or even 70 nS RAM chips. Just spare yourself of the hassle with 35 nS chips -- these are too fast for the ET4000/W32i controller. I also updated the article on my site with this information. I have some more pictures and handwritten notes and someday I'll add them to the article, just to document everything I did.

In the meantime, I also ordered a few 70 nS chips for experimenting around. I'm pretty sure they will work. In addition, 33 R resistors should be used with the correct memory chips.

Cheers,
A.

Aleks, many big thanks for sharing the BIOS. Of course, my schematic is as close to a direct copy of yours as I could manage, minus its modifications. I used the same documentation as you did, in fact the Feature Connector was lifted directly from the example schematic given in the ET4000 databook. I've also designed my own font to mod into the BIOS like you did. It's a thin font designed sfter Japanese PC fonts of the late 80s and early 90s.

Hopefully everything looks sane. I can't wait to try building one for myself.