At a first sight, it looks good. If I were to manually optimize tracks, there could be a few points where the layout could be improved. For instance, I would align vertically the raster of RN1 and RN2. But these are all optical matters, which don't affect the functionality.
Just out of curiosity, the tracks are auto-routed? Or they are manually laid out.

From an electrical point of view, I think you'll have to rely only on the DRC and ERC functions of KiCad as it would take me a lot of time to analyze the schematic and circuit layout visually.
But it should be good if the schematic closely matches my design (except the updates).

Indeed, the capacitors can be trimmed down considerably, efficiently reducing the production costs. Normally, three to five 10 uF capacitors placed in key points on the PCB will do the trick.
I just went crazy with the initial design, especially placing 40 uF in the lower right section of the card. Of course, I could've used any single garden variety 47 uF electrolytic capacitor in that point. But I wanted something that had a retro look and feel.

If you want to make the card look more modern, you can ditch the tantalum parts in favor of modern polymer capacitors. They will have the same footprint, while being cheaper, and almost as good (if not better).

@superfury, unfortunately, I don't know the answer to the ATC reg 16h question.

Cheers,

iyatemu wrote on 2024-09-18, 05:16:

1 from OSHpark or 10 from PCBWAY makes no difference if they don't work, $150 is $150 no matter how you slice it.

- Drop the gold bullcrap when ordering prototypes. Its not real hard gold coating anyway, you are overpaying for aesthetics.
- I would get rid of tantalums and switch to modern 1uF SMDs. In fact I would switch as much as possible to SMD parts.
- Did you really crosshatch power/ground layers 😳 or is that just visual representation? Its an obsolete practice https://resources.altium.com/p/history-and-us … -hatched-planes
- Stitching caps to ground/power layers 1-2 cm away from chips stitched directly to ground/power planes is not how you do proper bypassing 🙁 Drag tracks from VCC pins to caps, with only caps connecting to power plane. Lowest impedance possible between VCC pin and capacitor.
- Stitching busses (ADx, AAx) across looks neat when done in a single line, but it cuts ground layer. Stretch Vias apart to have as little ground interruption as possible under/near signal traces.

ALEKS wrote on 2024-09-18, 10:13:

At a first sight, it looks good. If I were to manually optimize tracks, there could be a few points where the layout could be improved. For instance, I would align vertically the raster of RN1 and RN2. But these are all optical matters, which don't affect the functionality.
Just out of curiosity, the tracks are auto-routed? Or they are manually laid out.

The positions of RN1 and RN2 are left over from when I realized that orienting the chips horizontally instead of vertically would result in neater routing. I had positioned them to be on the same vertical line but shifted in height, when I rotated the pairs of chips, that meant that RN1 was shifted further to the left of RN2.

Everything was manually routed. I don't know how to use KiCAD's auto-router, and I wouldn't want to. Manually routing is extremely frustrating but the most fun part of making a PCB, especially one as complex as this. Trying to puzzle together the Output and Feature sections was the most fun part.

rasz_pl wrote on 2024-09-18, 13:41:

- I would get rid of tantalums and switch to modern 1uF SMDs. In fact I would switch as much as possible to SMD parts.

The choice to remain THT is as much about looks as it is about convenience. Aleks has already published a parts list and Mouser shopping cart on his site. Mine makes a few modifications to the parts, mainly (and importantly) switching from 74244s to 74541s to keep the bus neat and in order. Beyond that, you can use every part in his parts list besides the main memory, which you would need to switch out anyway because the speed is wrong.

Aesthetically, the W32i is something from 1994-1995, right when everything was moving from THT to SMD at large scales. The original Micro-Labs Intl. card the Excelgraph is based on was entirely THT, even down to the memory chips, whereas other cards like the Hercules Dynamite or the ET4W32-5 move to SMD, with the Hercules having EVERY passive component being SMD. I suspect this is because these were mass-produced cards manufactured at great scale, where the MLI card was made by a much smaller company making them in quantities of hundreds to thousands. Aleks wanted his card to resemble high-end industrial/laboratory equipment, I want my version to resemble a piece of boutique consumer/enthusiast gear. As a DIY project and as an aesthetic, this card fits that nicely I think.

rasz_pl wrote on 2024-09-18, 13:41:

- Did you really crosshatch power/ground layers 😳 or is that just visual representation? Its an obsolete practice https://resources.altium.com/p/history-and-us … -hatched-planes

Again, I just did that because I think it looks nice and fits the "1994" theming. It also annoys me on actual cards when I'm trying to follow traces for troubleshooting and the inner layers obscure what I'm trying to see. Hatching the planes lets the light through, changing it is as simple as a setting in a drop-down.

rasz_pl wrote on 2024-09-18, 13:41:

- Stitching caps to ground/power layers 1-2 cm away from chips stitched directly to ground/power planes is not how you do proper bypassing 🙁 Drag tracks from VCC pins to caps, with only caps connecting to power plane. Lowest impedance possible between VCC pin and capacitor.

Noted, this is a simple fix.

rasz_pl wrote on 2024-09-18, 13:41:

- Stitching busses (ADx, AAx) across looks neat when done in a single line, but it cuts ground layer. Stretch Vias apart to have as little ground interruption as possible under/near signal traces.

Noted again, I'll try to shuffle those via lines a little bit and space apart the ones I already staggered.

I keep getting advice from outside sources and refining the layout and I've reached a point where everyone seems satisfied.

I'm giving the schematic one last look before ordering PCBs and noticed a few massive glaring flaws that would have rendered the card useless if I had built it. Feel free to compare schematics using these notes so you can spot the errors.

1. I swapped BOTH pairs of /IOW and /IOR -- AND -- /MEMW and /MEMR on the W32i.
2. I connected the capacitor in the voltage reference section to REFSET on the RAMDAC instead of to VREF with the diode reference.
3. I swapped the resistor/cap connections on the clock generator for VCLK and MCLK. The clock chip was connected to the W32i correctly, but the resistors were connected to the opposite pins.
4. Connected the pull-up resistor for the IRQ jumper/DIP Switch to the wrong side.

This, I think, should be the final iteration of the board.

And the amended schematic.

iyatemu wrote on 2024-09-23, 09:30:

3. I swapped the resistor/cap connections on the clock generator for VCLK and MCLK. The clock chip was connected to the W32i correctly, but the resistors were connected to the opposite pins.

Naming doesnt help here, SCLK of one chip is MCLK of the other 😀
Im not sure it would matter much, those resistors/cap are there to eliminate reflections/clean up the high frequency clock between two chips _on particular PCB they were designed for_. R16 R17 R18 C19 were carefully selected manually during EMC tuning for the particular PCB design they were used on that Alex Groza copied. For example first card from https://dosdays.co.uk/topics/retro_review_et4000_pt1.php has some inductors on clock lines and no cap, same purpose totally different mechanism. Edit: Those resistors/cap might explain problems with ram timings.
TLDR dont blindly copy EMC components, they only work in exact environment they were designed for.

The best to do for clock routing is for example listed in https://resources.pcb.cadence.com/routing/202 … ting-techniques
- least amount of via traversal. SCLK-MCLK could be routed without the VIA. Move CS0/CS1 to make room.
- as far away from other signals as possible "maintain a spacing of 3 times the trace width between clock lines and other routing"
- definite NO routing VCLK between crystal pins "want to place your components so that different clock routing doesn’t cross over each other"
- no aesthetically pleasing crosshatch ground under Clock signals "Make sure that your clock traces have good clean return paths on the planes, and don’t route them over any plane splits which would ruin the integrity of the return path"
- bonus point for ground shrouds "Using power and ground layers adjacent to your routing layers to shield your clock lines is also important"

rasz_pl wrote on 2024-09-23, 16:55:

Im not sure it would matter much, those resistors/cap are there to eliminate reflections/clean up the high frequency clock between two chips on particular PCB they were designed for. R16 R17 R18 C19 were carefully selected manually during EMC tuning for the particular PCB design they were used on that Alex Groza copied.

While it is true that you typically use resistors on clock lines to dampen reflections, as any kind of ringing caused by overshoot is detrimental on clock lines, it looks like this is not the purpose of R16, R17, R18 and C19 in this design. If you have sufficiently strong outputs, it makes sense to flatten the edges to both improve EMC and avoid ringing by series termination using a resistor close to the output pin. This resistor typically has around 22 to 47 ohms and is connected in the signal path. You can further try to take a bit off the edges by using a couple (but not significantly more) pF of capacitance to ground after the resistor. This can further improve EMC.

On this card, though, on VCLK/MCLK (the pixel clock) we find a series capacitor, and a resistor pair to ground/Vcc with a total impedance of 1.6kOhm. This looks not at all like termination and EMC managenent, but a lot like shifting a 2.5V centered (CMOS-like) output of the clock gen to an 1.4V centered signal for the ET4000W32 chip. 1.4V centering makes sense for TTL inputs with a low threshold of 0.8V and a high threshold of 2.0V. And indeed the ET4000/W32i datasheet specifies both clock inputs as TTL, so that side makes sense. On the other hand, the CH9294E datasheet also specifies TTL-level outputs, so I doubt this interface network is required at all for a Chrontel CH9294E clock chip. The purpose of the MCLK/SCLK (memory/engine clock) network seems to be similar, by just pulling down a CMOS output to yield more TTLish levels. My guess for the different networks is that the pixel clock adaption needs to be more elaborate due to the variable and possibly higher frequencies used on that line compared to the fixed 40MHz used for the engine clock.

The current PCB design is not a problem even if the adaption network turns out to be wrong on this card, because one could just not populate all the pull-up/down resistor and replace C19 by a 0 ohm, 22 ohm or 33 ohm resistor without re-spinning the PCB.

On the other hand, the general hints given by rasz_pl about clock routing sound like solid advice. Thanks for them!

I'll ask a question that I don't think has been asked yet:

Is it possible to use the ET4000/w32P variant on this board instead of the I variant? I'd very much like to build this, but I've noticed that finding stock of the P version is a little easier from second-source folks where you're not scavenging from a potientially-working card.

mbalmer wrote on 2024-09-26, 11:11:

Is it possible to use the ET4000/w32P variant on this board instead of the I variant?

Defenitely no. I have datasheets for both the ET4000/W32i and the ET4000/W32p. The W32p datasheet no longer mentions the ISA and MCA host interface types. Furthermore, the W32p is packaged in a 208-pin package, whereas the W32i is packaged in a 160-pin package.

mkarcher wrote on 2024-09-26, 21:09:

The W32p datasheet no longer mentions the ISA and MCA host interface types.

Well, boo. Although it's interesting that the P variant was also used on VLB cards, which, if I understand correctly, is essentially ISA with extra steps; but at the same time, it could also be that even thought the chip itself is VLB-compatible, it might not be ISA-ONLY capable.

Ah, well. I had hoped to be able to build this, but considering the difficulty in finding the part as well as the already steep price on cards featuring it (presumably because the chip is an ET4000 variant, which already carries a premium), I guess I will have to pass for now.

mbalmer wrote on 2024-09-26, 22:27:

Well, boo. Although it's interesting that the P variant was also used on VLB cards, which, if I understand correctly, is essentially ISA with extra steps

Seeing VLB as ISA with extra steps is not a good model, in my oppinion. You may think of EISA (enhanced ISA) this way, as the name already implies. VLB actually provides a totally different bus on the extra connector: The frontside bus of the 486 processor. You can observe this by noticing that the VL slot has 32 "local" data lines and 32 "local" address lines in addition to the 16 "system bus" data lines and the (kind of) 24 "system bus" address lines of the ISA connector. There are some things that are not available on the VLB part, mostly voltages except +5V, IRQs except for IRQ9 and access to ISA DMA. Furthermore, a VL card should plug into the 8-bit ISA connector just for mechanical stability. Most VL VGA cards also use the ISA side to provide access to the BIOS chip, as ISA has been designed in a way to make accessing ROM chips easy. All VL IO controller cards are actually plain old ISA I/O controller cards for everything except the hard disk port. The hard disk port is only accessible on the local bus and the other components are only accessible on the ISA bus and provided by a different chip. Some VL I/O controllers provide one IDE port by a VL IDE interface chip and a second port by the ISA multi I/O chip.

Every PC-compatible 386/486 mainboard has a kind of bridge that translates 486 FSB cycles into ISA cycles for cycles that can not be handled on the FSB side (access to main memory, interfacing the 387, interfacing a Weitek 3167/4167). A mainboard with VL slots exposes both sides of the bridge to VL cards. A VL card can claim a cycle on the FSB side by activating a signal quite quickly in response to a 486 FSB transaction start, which will prevent the ISA bridge to generate a cycle on the ISA bus. In that case, the VL card takes responsibility to respond to that bus cycle. Otherwise, the ISA bridge will respond to the cycle. A VL card claiming a cycle that is handled by something else than the ISA bridge (like main memory) will result in undefined behaviour.

If you have further questions about the way VLB works, I am happy to explain stuff. In that case, we should split this off into a different thread, though.

mkarcher wrote on 2024-09-27, 19:30:

Seeing VLB as ISA with extra steps is not a good model, in my oppinion. You may think of EISA (enhanced ISA) this way, as the na […]
Show full quote

mbalmer wrote on 2024-09-26, 22:27:

Well, boo. Although it's interesting that the P variant was also used on VLB cards, which, if I understand correctly, is essentially ISA with extra steps

Seeing VLB as ISA with extra steps is not a good model, in my oppinion. You may think of EISA (enhanced ISA) this way, as the name already implies. VLB actually provides a totally different bus on the extra connector: The frontside bus of the 486 processor. You can observe this by noticing that the VL slot has 32 "local" data lines and 32 "local" address lines in addition to the 16 "system bus" data lines and the (kind of) 24 "system bus" address lines of the ISA connector. There are some things that are not available on the VLB part, mostly voltages except +5V, IRQs except for IRQ9 and access to ISA DMA. Furthermore, a VL card should plug into the 8-bit ISA connector just for mechanical stability. Most VL VGA cards also use the ISA side to provide access to the BIOS chip, as ISA has been designed in a way to make accessing ROM chips easy. All VL IO controller cards are actually plain old ISA I/O controller cards for everything except the hard disk port. The hard disk port is only accessible on the local bus and the other components are only accessible on the ISA bus and provided by a different chip. Some VL I/O controllers provide one IDE port by a VL IDE interface chip and a second port by the ISA multi I/O chip.

Every PC-compatible 386/486 mainboard has a kind of bridge that translates 486 FSB cycles into ISA cycles for cycles that can not be handled on the FSB side (access to main memory, interfacing the 387, interfacing a Weitek 3167/4167). A mainboard with VL slots exposes both sides of the bridge to VL cards. A VL card can claim a cycle on the FSB side by activating a signal quite quickly in response to a 486 FSB transaction start, which will prevent the ISA bridge to generate a cycle on the ISA bus. In that case, the VL card takes responsibility to respond to that bus cycle. Otherwise, the ISA bridge will respond to the cycle. A VL card claiming a cycle that is handled by something else than the ISA bridge (like main memory) will result in undefined behaviour.

If you have further questions about the way VLB works, I am happy to explain stuff. In that case, we should split this off into a different thread, though.

It makes me curious about how the SEG2-SEG0 is wired on such a board. And how it's given to the ET4000/W32i chip. Might explain how linear addressing mode works. Re: COLORImage ET4000/W32i VLB card has such a card.

It might give some insight on how linear addressing is really implemented in other cards, assuming they're address-space compatible with ISA cards?

superfury wrote on 2024-09-27, 23:39:

It makes me curious about how the SEG2-SEG0 is wired on such a board. And how it's given to the ET4000/W32i chip. Might explain how linear addressing mode works. Re: COLORImage ET4000/W32i VLB card has such a card.

Answered over there: Re: COLORImage ET4000/W32i VLB card

I've ordered and received the boards. I ordered a small test PCB to test the fitment of the VGA connector and everything is good, mechanically. This should fit in any machine with little issue if I got the tolerances right.

The boards look pretty nice. I wanted to go with PCBway for the manufacturing, but with all the relevant options set, and with actual gold plated fingers, the quote came out to over $475 after the design audit. So I went with JLCPCB. The board material itself is very nice and high quality, but my primary issue with them is their silk screening. They offer a (very expensive) litho/exposure silk screen option now which is EXTREMELY nice. Very, very good quality, however they do NOT over any gold plating options. With everything set, and with the expensive, nice silk screen, the total cost plus shipping came out to $180 for 5 boards.

Added estimates for parts are about $95 for the new, bulk parts, $20 for each W32i, $15 for the DRAM, $13 for the RAMDAC, $5 for the clock generator, and $15 for the BIOS EEPROM. All prices are including shipping and rounded up.

PCB, each - $36
New parts - $95
W32i, each - $20
RAMDAC, each - $13
DRAM, x4 - $15
Clockgen, each - $5
BIOS EEPROM-$15
------------------
Total for one build, $199
But, total I've actually spent buying multiple extra parts is closer to $500.

I really, really hope this works.

PCB looks beautiful. Takes some balls to just pull a trigger without running a quick cheap prototype 😮 :-]

I'm a bit curious now how the ET4000AX actually deals with it's linear mode.

The documentation says:
Bit 4, when set to 1, will define the most significant 4-bits of display memory
address lines as directly from the microprocessor address bus llinear system). Note
also that GDC Indexed Register 6, bits 3 & 2 must be set for 128K bytes 10,0).
Since the linear system responds to a contiguous 1MB address space, the host
addresses IA(23:20») should be used to avoid address conflicts with the host.
When set to 0, defines these address lines as derived from the Segment Select
Register (port 3CD).

Is anything known how those top 4 bits of the 24-bit address inputted are mapped by the ET4000AX?
Perhaps the Segment Select Register (3CD) is used for that for both reads and writes (reads/writes using either the top(read) or bottom(write) 4 bits depending on if it's a read or a write?), since it's unused in this mode?

So combined with my new ISA adapter to map the upper address bits into the ISA space (in 16MB chunks), you can position it anywhere in 1MB(ET4000AX) or 4MB(ET4000/W32) locations within that 16MB(ISA) address space. Combining those two, you can put it anywhere inside 4GB memory locations (including the first MB, which you obviously shouldn't).
The ISA space is defined by the PCI-to-ISA adapter, while the location of the ET4000 memory within that is defined by:
- The Segment Select register (3CD) on the ET4000AX (low 4 bits for writes, high 4 bits for reads, usually you'd map them equal).
- Register 30h on the W32i chips, using bits 0-1 for A22-A23 (to specify the address space used, in 4MB chunks) and bits 2-4 to 111b for legacy mode (normal VGA mapping, the power-on default) and 110b for linear memory mode (provided the linear memory map bit in register 36h (bit 4) is set).

In fact, does bits 2-4 of the register 30h registers even need to be modified? Can't it just be kept at 111b and simply bits 0-1 used to map?
Edit: Just checked and cross-referenced with Aleks's card schematics. Since DB11 is low during PORI (grounded), the ISA A23 (AT connector) is like in his card mapped to SEGE. SEGE then is used as bit 1 input to register 30h. Bit 0 is the usual A22 (AT connector). A21-17 are there on the AT connector too. So the bottom bits are forced low on segmented mode, thus mapping to 0-4MB. But in segmented mode, A21-20 are compared to low as well, thus forcing to only respond to the first ISA 1MB. And then the normal A0000-BFFFF mapping applies inside the chip.
When set to linear mode, A23-22 are thus matched to reg 30h bit 0-1 and if matched address the linear memory area.

My emulator now is modified to support it that way too (SEG0-2 are ignored now).
And the personal PCI-to-ISA bridge of my software implementation (A IT8888G PCI-to-ISA bridge) can remap it past the memory present to prevent conflicts. It's as documented, except with a ROM (also documented) to load a subvendor/subdevice ID to identify it as the ET4000AX(W32P with low 8 bits being 00h, so 100C:3200h) or ET4000/W32i rev 2 (W32P with low 8 bits being 03h (100C:3203)).
The card itself also once again identifies as ISA now (no PCI/VLB).

So it can map the space anywhere in 4GB now (low 23 bits using register 30h or 3CD(ET4000AX) and upper bits (24-32) using the IT8888G PCI-to-ISA relocation feature). Although Windows 9x doesn't have drivers for it afaik? Or is that just a 95 issue (95 RTM identifies it as a 'broken' PCI-to-ISA bridge (error 2))? 95 OSR 2.5(C) thinks it's a generic PCI bus?
Neither think that the ET4000/W32i is on that bus it seems?

Hmmm... Just curious about something...

What happens to the controller when on the ISA connector B02 (RESET DRV) is used? How does this affect the ET4000/W32i? Does that clear all registers? Or does it have some specific effect?
Could that be what the vdiag software is complaining about?

I've been working on my own implementation of the ET4000/W32i emulation some more and noticed something.

It seems like when the W32i is reset using RESET DRV(REST pin in the documentation), it latches the monitor ID pins on DB0-3, which then appear on the status register #0 higher 2 bits (feature connector low bits)? But the upper bits (ID2 and ID3) seem to be live pins, read on the input status #0 register (whose switch sense isn't connected it seems) and on the 3CAh register's bits 2-5, which also seems like live pins (but I'm not sure those are actually live like the feature connector pins)?
Edit: Looked at the documentation again, it's indeed latched for the upper bits as well. Perhaps only the switch sense pin isn't latched? But in your implementation, it isn't wired to anything other than VCC, so it's wired to 5V (or whatever voltage the card uses)?

I've checked the function mentioned at 9AFA inside the VDIAG executable. But it seems to depend on CRTC register 22h, which isn't supposed to be a valid register on the ET4000 series. Only on the ET3000AX it's a valid register (maybe, nothing is documented in the one source I have of it's registers)? It seems to perform logic like on CRTC register 34h, selecting port 46E8 or 3C3 for the card enable toggle, erroring out because it's not set, thus resulting in FFh being read and port 46E8 being used? So if it doesn't exist, this same case will happen, as register 22h isn't supposed to exist (thus floating the bus). It for some reason doesn't expect 3C3h/46E8h in an active state at this point? Is it supposed to have disabled the card somehow?
Edit: I don't see it driving a PCI reset or anything else while doing this test. Is it resetting the ISA bus in some unknown way?

superfury wrote on Yesterday, 18:40:

But it seems to depend on CRTC register 22h, which isn't supposed to be a valid register on the ET4000 series.

It seems to perform logic like on CRTC register 34h, selecting port 46E8 or 3C3 for the card enable toggle, erroring out because it's not set, thus resulting in FFh being read and port 46E8 being

Are you aware that 22h is 34 decimal? Possibly there is a bug in VDIAG confusing 0x34 and 34 in C syntax.

mkarcher wrote on Yesterday, 21:27:

superfury wrote on Yesterday, 18:40:

But it seems to depend on CRTC register 22h, which isn't supposed to be a valid register on the ET4000 series.

It seems to perform logic like on CRTC register 34h, selecting port 46E8 or 3C3 for the card enable toggle, erroring out because it's not set, thus resulting in FFh being read and port 46E8 being

Are you aware that 22h is 34 decimal? Possibly there is a bug in VDIAG confusing 0x34 and 34 in C syntax.

The end result is the same, however. At that point it's read as being set (due to floating bus), just like the register's setting (as the BIOS POST just before it left it on, I'm seeing C000:100 being executed), but it seems to want it being reported in the 'off' (zeroed) state. Why would it want that to happen? The BIOS code will turn it on always, due to successfull POSTing.
I do see an invalid write to 3C3 with zero, but it probably doesn't register due to 46e8h being active for the 34h register setting.

Edit: I see some interesting stuff during this test. It seems to perform a ROM POST at that point (or just before it), which tries (but fails) to disable the adapter?
Observed behaviour:

100:00:45:59.06524: No reaction on port (W) 42e8=00 @c000:022c
200:00:45:59.06564: No reaction on port (W) 42e9=90 @c000:022c
300:00:45:59.06600: No reaction on port (W) 42e8=00 @c000:0231
400:00:45:59.06632: No reaction on port (W) 42e9=50 @c000:0231
500:00:45:59.06668: No reaction on port (R) 92e8 @c000:0237
600:00:45:59.06700: No reaction on port (R) 92e9 @c000:0237
700:00:45:59.06736: No reaction on port (W) 92e8=55 @c000:023e
800:00:45:59.06768: No reaction on port (W) 92e9=55 @c000:023e
900:00:45:59.06804: No reaction on port (R) 92e8 @c000:0241
1000:00:45:59.06836: No reaction on port (R) 92e9 @c000:0241
1100:00:45:59.06876: No reaction on port (W) 92e8=ff @c000:0256
1200:00:45:59.06908: No reaction on port (W) 92e9=ff @c000:0256
1300:00:45:59.06956: No reaction on port (W) 03b4=34 @c000:07df
1400:00:45:59.06992: No reaction on port (W) 03b5=ff @c000:07e5
1500:00:45:59.07036: No reaction on port (W) 03c3=00 @c000:0125
1600:00:45:59.07072: No reaction on port (W) 4ae8=00 @c000:012d
1700:00:45:59.07104: No reaction on port (W) 4ae9=00 @c000:012d

Required behaviour code:

1                out     dx, al          ; Enable the video card
2seg000:0109
3seg000:0109 loc_109:                                ; DATA XREF: seg000:0161↓w
4seg000:0109                 call    convolutedTsengExtensionsEnable
5seg000:010C
6seg000:010C loc_10C:                                ; DATA XREF: seg000:0ED7↓r
7seg000:010C                                         ; seg000:0FAB↓r ...
8seg000:010C                 mov     ah, 34h ; '4'
9seg000:010E
10seg000:010E loc_10E:                                ; DATA XREF: seg000:17A6↓w
11seg000:010E                                         ; sub_18D3+7E↓w
12seg000:010E                 call    readIndexedRegisterAHintoAL
13seg000:0111                 and     al, 0F7h
14seg000:0113                 call    detectPort42E8
15seg000:0116                 jz      short loc_11A   ; if detected, skip
16seg000:0118                 or      al, 8           ; Enable ourselves
17seg000:011A
18seg000:011A loc_11A:                                ; CODE XREF: seg000:0116↑j
19seg000:011A                 call    writeIndexedRegisterAH_valueAL_portDX
20seg000:011D                 test    al, 8           ; Were we enabled on card?
21seg000:011F                 jz      short isAdapter
22seg000:0121                 mov     dl, 0C3h        ; We were not enabled.
23seg000:0123                 mov     al, 0           ; Disable the card! THIS ISNT REACHED DURING NORMAL POST,  but is reached during the diagnostic suite for some weird reason. This doesn't reach the card, due to it being configured for 46E8h instead at this point.
24seg000:0125                 out     dx, al
25seg000:0126                 jmp     short $+2
26seg000:0128 ; ---------------------------------------------------------------------------
27seg000:0128
28seg000:0128 isAdapter:        

And the subfunctions called:

1convolutedTsengExtensionsEnable proc near
2seg000:01F0                                         ; CODE XREF: seg000:loc_109↑p
3seg000:01F0                 push    cx
4seg000:01F1                 mov     dx, 3B8h
5seg000:01F4
6seg000:01F4 loc_1F4:                                ; CODE XREF: convolutedTsengExtensionsEnable+20↓j
7seg000:01F4                 mov     cx, 28h ; '('
8seg000:01F7
9seg000:01F7 loc_1F7:                                ; CODE XREF: convolutedTsengExtensionsEnable:loc_21A↓j
10seg000:01F7                 mov     al, 1           ; Write 1
11seg000:01F9                 call    writeALtoHerculesPort
12seg000:01FC                 in      al, dx
13seg000:01FD                 test    al, 40h         ; High bigt set?
14seg000:01FF                 jnz     short loc_20B   ; If so, finished
15seg000:0201                 mov     al, 3           ; Write 3
16seg000:0203                 call    writeALtoHerculesPort
17seg000:0206                 in      al, dx
18seg000:0207                 test    al, 40h
19seg000:0209                 jnz     short loc_21A
20seg000:020B
21seg000:020B loc_20B:                                ; CODE XREF: convolutedTsengExtensionsEnable+F↑j
22seg000:020B                 cmp     dl, 0B8h
23seg000:020E                 mov     dl, 0D8h
24seg000:0210                 jz      short loc_1F4
25seg000:0212                 call    enableSVGAextensions
26seg000:0215                 call    getActiveCRTCaddressInDX
27seg000:0218                 jmp     short loc_222
28seg000:021A ; ---------------------------------------------------------------------------
29seg000:021A
30seg000:021A loc_21A:                                ; CODE XREF: convolutedTsengExtensionsEnable+19↑j
31seg000:021A                 loop    loc_1F7         ; Write 1
32seg000:021C                 mov     al, 0A0h
33seg000:021E                 out     dx, al
34seg000:021F                 sub     dl, 4
35seg000:0222
36seg000:0222 loc_222:                                ; CODE XREF: convolutedTsengExtensionsEnable+28↑j
37seg000:0222                 pop     cx
38seg000:0223                 retn
39seg000:0223 convolutedTsengExtensionsEnable endp

And:

1detectPort42E8  proc near               ; CODE XREF: seg000:0113↑p
2seg000:0224                 push    ax
3seg000:0225                 push    dx
4seg000:0226                 mov     dx, 42E8h
5seg000:0229                 mov     ax, 9000h
6seg000:022C                 out     dx, ax
7seg000:022D                 jmp     short $+2
8seg000:022F ; ---------------------------------------------------------------------------
9seg000:022F
10seg000:022F loc_22F:                                ; CODE XREF: detectPort42E8+9↑j
11seg000:022F                 mov     ah, 50h ; 'P'
12seg000:0231                 out     dx, ax
13seg000:0232                 jmp     short $+2
14seg000:0234 ; ---------------------------------------------------------------------------
15seg000:0234
16seg000:0234 loc_234:                                ; CODE XREF: detectPort42E8+E↑j
17seg000:0234                 mov     dx, 92E8h
18seg000:0237                 in      ax, dx
19seg000:0238                 jmp     short $+2
20seg000:023A ; ---------------------------------------------------------------------------
21seg000:023A
22seg000:023A loc_23A:                                ; CODE XREF: detectPort42E8+14↑j
23seg000:023A                 push    ax
24seg000:023B                 mov     ax, 5555h
25seg000:023E                 out     dx, ax
26seg000:023F                 jmp     short $+2
27seg000:0241 ; ---------------------------------------------------------------------------
28seg000:0241
29seg000:0241 loc_241:                                ; CODE XREF: detectPort42E8+1B↑j
30seg000:0241                 in      ax, dx
31seg000:0242                 jmp     short $+2
32seg000:0244 ; ---------------------------------------------------------------------------
33seg000:0244
34seg000:0244 loc_244:                                ; CODE XREF: detectPort42E8+1E↑j
35seg000:0244                 cmp     ax, 5555h
36seg000:0247                 jnz     short loc_255
37seg000:0249                 mov     ax, 0AAAAh
38seg000:024C                 out     dx, ax
39seg000:024D                 jmp     short $+2
40seg000:024F ; ---------------------------------------------------------------------------
41seg000:024F
42seg000:024F loc_24F:                                ; CODE XREF: detectPort42E8+29↑j
43seg000:024F                 in      ax, dx
44seg000:0250                 jmp     short $+2
45seg000:0252 ; ---------------------------------------------------------------------------
46seg000:0252
47seg000:0252 loc_252:                                ; CODE XREF: detectPort42E8+2C↑j
48seg000:0252                 cmp     ax, 0AAAAh
49seg000:0255
50seg000:0255 loc_255:                                ; CODE XREF: detectPort42E8+23↑j
51seg000:0255                 pop     ax
52seg000:0256                 out     dx, ax
53seg000:0257                 pop     dx
54seg000:0258                 pop     ax
55seg000:0259                 retn
56seg000:0259 detectPort42E8  endp

enableVGAextensions simply forces the VGA into color mode using the misc output register and performs the extension enable writes using fixed ports afterwards.