attachments of the photos of front/back of the card and the OAK VLSI pinout which I was probing with the scope. thanks!

randi wrote on 2025-08-01, 04:11:

Hello there, I just acquired this exact same board as in Oak Technology VGA-16 (OTI-037C based mda/cga/ega/vga) video card schematics? ,and it too is not recognized by any MB (5160/XT Turbo/286/386/486) I have. It just gives the standard AMI 1 long, 8 short beeps.

This basically means: The AMI BIOS checked whether a video BIOS is present. If yes, it has called the video BIOS to initialize card. After the video BIOS returned (in case there is a video BIOS), the AMI BIOS could detect neither a CGA compatible (this includes EGA and VGA) or MDA compatible display card.

randi wrote on 2025-08-01, 04:11:

With some tips from kind folks to use DEBUG.EXE , I managed to download the OAK OTI 037C BIOS on a XT setup with 2 displays (using its integrated MDA) , and run this BIOS inside 86box, confirming BIOS is good.

What's interesting about the design of the OTI-037C card is that the BIOS access is a completely separate function. The OTI-037C chip is not involved in decoding ROM addresses. Address bits 17-19 are only decoded by logic chips, likely one of the PALs on your card. So working BIOS access is a good start, but doesn't tell us a lot about the functionality of the OTI-037C chip or its ISA interface. We do know that the decoding of the ROM address space works, so we can infer that the decoding of the VGA memory address space (A0000-BFFFF) most likely works as well. By the way: The 16-bit part of the ISA bus is only used for BIOS access, the OTI-037C VGA implementation is a pure 8-bit implementation.

U16 is the high data buffer that amplifies the data from the "ODD" BIOS chip before it goes to the high part of the ISA bus in case of 16-bit BIOS reads. I think we can directly skip thinking about that chip, as well as U14 and U15, the BIOS ROMs. Just like in the EGA thread in which you linked this thread, the OTI-037C has multiplexed input for the low 8 address bits and the 8 ISA data bits. The function of chip that was broken on the EGA card is performed by U6 on this card, but this obviously does not mean this is your issue as well. That chip can send the low 8 address bits to the OTI chip if it is required. On the other hand, U9 can send the (low) 8 ISA data bit to the OTI chip or send data from the OTI chip back to the ISA bus. The ISA bus is connected to the "A" side of that chip, while the OTI chip is connected to the "B" side of that chip. THe chip next to it, U10, is an unidirectional buffer, with its output connected to the ISA bus. I suppose that one is used to forward the contents of the "EVEN" BIOS chip to the low 8 bits. Another 244 is right next to it, called U11, is used to forward the contents of the "ODD" BIOS chip to the low 8 bits in case the card is working in an 8-bit system, and those bits are not transferred using the high 8 data lines. To be frank, I was lazy and didn't trace the inputs of U10 and U11, maybe I have them assigned the wrong way around. It doesn't matter for troubleshooting the card, though.

So, to summarize: BIOS access is implemented using U10 to U16. Maybe the PAL U12 also decodes video memory access and not only BIOS access.

The P0-P7 buffer from the data sheet between the OTI chip and the DAC likely is U3, while U5, a quadruple tristate driver is the four buffers shown on PCLK, BLANK, HSYNC and VSYNC. U1 is the inverter for the feature signals EVIDEO, EDCLK and ESYNC. U8 is the driver for the CGA/EGA/MDA output connector. I have no idea what U4 is good for. It is somehow close to the monitor interface, possibly to read the classic monitor ID pins.

So, for the VGA part of that card to work, we need a working address passthrough (U6), a working data connection (U9), likely the PAL U7 and definitely a working VGA chip (U17). It is OK that U17 doesn't output anything until it is properly initialized.

I suggest the first thing to test is whether we can interface the chip at all. It might well boot up in "disabled" mode, in which it only responds to port 3C3. This is used to be able to switch between onboard video, like the MCGA provided on the PS/2 model 30 and the OAK VGA card. So, please run the following test in DEBUG: Output 0 to port 3C3 (o3c3 0), then read it back (i3c3). Output FF to port 3C3 (o3c3 FF), then read it back again. I don't know whether bits 1 to 7 of that port can be modified, but bit 0 is supposed to be toggleable. If you get issues with debug displaying correctly after "o3c3 ff", blindly type "o3c2 23" to put the OAK card into a state that doesn't conflict with your MDA/Hercules card.

Assuming you can read back bit 0 of port 3C3, and you wrote an odd value to 3c3 last, you should then be able to access I/O ports of the card. Write 8 into port 3CE (graphics controller index port), and try to read it back. If this works OK, write 55 into port 3CF (graphics controller data port), and try to read it back, then write AA into port 3CF and try to read it back.

Please report the results, and depending on whether stuff worked or failed, I will suggest next steps.

Thanks for your detailed reply, much appreciated, especially the commentary on the functions of the various ICs. I have tabulated the results, and repeated the tests also with an Acumos VGA and an EGA card as a control, on multiple MBs as I wanted to make sure I was using debug.exe correctly.

BTW in all these cases, the tests were run with a call in autoexec.bat to run debug.exe < input.txt >output.txt . When I have the OAK 037 inserted, the screen is blank, so I would be typing blind : )

To answer the questions butjer1010 & Deunan asked me, yes that is the same manual I am using for the DIP switch settings (but I tried all 2^4 combinations anyways), I tried both 8 bit & 16 bit slots (it has a jumper to set this, but as mkarcher explained , 16 bit is only used to speed up reading the video bios), and yes I checked the 3 crystals on the scope , regards frequency they match exactly whats stamped on the can. regards voltage levels, I read 2.1v, 2.0v and 2.56v for the 3rd one. Thanks

The results in you table show that the physical Acumos card is unable to read back 3C3, possibly it doesn't even implement 3C3. The CL-GD542x series of chips (which your Acumos is likely a predecessor to) can be configured by strapping resistors to use 46E8 instead of 3C3. All VGA cards you tested behaved the same (and as expected) on the 3CE/3CF test. That test confirms that the 8-bit I/O data and address path is working. It is expected that the EGA card does just return FF, because the original EGA did not implement read-back of I/O data, although some later clones do.

So what this means is that we did not yet identify what causes the mainboard BIOS to reject the card. In a computer with 16-bit bus and without an MDA card, please perform the following test next (again as a debug script)

• Dump the first 128 bytes of video ROM using "dC000:0"
• Check whether the OTI chip is enabled after boot using "i3C3" (1 means enabled. If you get a 0 here, the mainboard BIOS most likely did not like the video BIOS and did not execute it)
• Force the card being enabled by issuing "o3C3 1"
• Set the card to use the "color" I/O port range for the CRTC using "o3C2 23"
• Set the color CRTC index to 0E (o3D4 0E)
• Read back the color CRTC index register (i3D4), expected is "0E"
• Set the mono CRTC index to 0E (o3B4 0E)
• Read back the mono CRTC index register (i3B4). expected is "FF", because no MDA is present and the VGA is set to use the color address
• Output 55 to the color CRTC data register (o3D5 55) and read it back (i3D5). Expected result: 55
• Output 55 to the color CRTC data register (o3D5 AA) and read it back (i3D5). Expected result: AA (this is a test the mainboard BIOS performs to detect tbe presence of a CGA-like card)
• Enable Memory at A000 using o3CE 6; o3CF 4. Confirm the setting worked using i3CF
• Set read mode and write mode to 0, but enable 256-color mode: o3CE 5; o3CF 40
• Enable writes to all pixel positions: o3CE 8; o3CF FF
• Set timing sequencer to use chain-4 mode: o3C4 4; o3C5 A. Confirm the setting worked using i3C5
• Enable writes to all planes: o3C4 2; o3C5 F
• write a test pattern into video memory: eA000:0 5A A5 FF 00 3C C3 96 69
• dump video memory: dA000:0L8

This initializes the VGA card well enough to be able to perform video memory access. If everything seems to work fine (the BIOS should start with 55 AA 40), try invoking the POST entry of the BIOS using

1-a100
2xxxx:0100 CALL FAR C000:3
3xxxx:0105 int 3
4-g=100

If the cards springs to life using that operation, it seems the BIOS is slightly corrupted and has a checksum error, which prevents the mainboard BIOS from running it during the power-on self test and initialization procedure.

Thanks mkarcher for the detailed instructions, I rant these on a 286, the majority of values came out to those expected, apart from: i3D4 did not have OE, it had 37 ; i3b4 remained OE, the value I wrote to it; o3d5 had 37 instead of AA and not clear if the write test pattern worked.

-d C000:0

C000:0000 55 AA 40 EB 1C 90 00 00-4F 41 4B 20 56 47 41 20 U.@.....OAK VGA
C000:0010 42 49 4F 53 2C 20 6E 6F-74 20 66 6F 72 20 49 42 BIOS, not for IB
C000:0020 4D 50 51 52 56 57 1E 06-53 55 2E 8E 1E 41 07 BA MPQRVW..SU...A..
C000:0030 C3 03 8B EA B4 FE E8 6F-02 E8 48 01 E8 B2 26 BA .......o..H...&.
C000:0040 DE 03 B0 0E EE 42 EC 24-FE EE E4 61 0C 3C E6 61 .....B.$...a.<.a
C000:0050 24 C3 E6 61 E8 48 26 BA-CC 03 BD C2 03 B4 11 E8 $..a.H&.........
C000:0060 46 02 E8 1F 01 E8 24 01-E8 86 26 F6 06 89 00 01 F.....$...&.....
C000:0070 75 07 F6 06 87 00 02 74-0C BE 25 10 B3 0B B0 00 u......t..%.....
-i 3c3
01
-o 3c3 1
-r
AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=1158 ES=1158 SS=1158 CS=1158 IP=0100 NV UP EI PL NZ NA PO NC
1158:0100 37 AAA
-i 3c3
01
-q
-o 3c2 23
-o 3d4 0e
-i 3d4
37
-o 3b4 0e
-i 3b4
0E
-o 3d5 55
-i 3d5
55
-o 3d5 AA
-i 3d5
37
-q
-o 3CE 6
-o 3cf 4
-i 3cf
04
-q
-o 3ce 5
-o 3cf 40
-q
-o 3CE 8
-o 3CF FF
-o 3C4 4
-o 3C5 A
-i 3C5
0A
-q
-o 3C4 2
-o 3C5 F
-eA000:0 5A A5 FF 00 3C C3 96 69
-dA000:0L8
A000:0000 74 74 74 74 74 74 74 74 s<<<<<<<
-q
-a100
1158:0100 CALL FAR C000:3
1158:0105 int 3
1158:0106
-g=100

AX=0000 BX=0000 CX=0000 DX=0000 SP=FFEE BP=FFFF SI=0000 DI=0000
DS=1158 ES=1158 SS=1158 CS=1158 IP=0105 NV UP EI PL ZR NA PE NC
1158:0105 CC INT 3
-q


there was no screen output from the OAK yet.

Am I correct in the following assumptions?

• There is no MDA/Hercules in that 286 computer you ran the test on
• The output of debug is redirected to a file, so you can read it without having a visible screen

Some things seem quite off in your dump (but that's likely not your fault, but hopefully helps to diagnose the hardware):

• Something responds to 3B4. Only an MDA card or a VGA set to monochrome emulation should do that. Writing 23 to 3C2 should put the OAK chip to color emulation.
• The readback from 3D4 is strange. If you were running debug interactively, unexpected readbacks from 3D4 may be expected, because moving the cursor requires access to 3D4/3D5. But the value 37 is strange. This index value is too high for CRTC registers. Even worse: It has bit 5 set, while the Oak datasheet indicates that bit 5 is reserved for testing and needs to be cleared all the time.
• The AA readback from 3D5 is strange. Again a 37, which looks nothing at all like the expected AA.
• The video memory contents don't look anything like I expected. You should be able to read back "5A A5 FF 00 3C C3 96 69". But that's not the only thing that's strange. The hex dump is eight times 74, but the ASCII dump contains the characters corresponding to 73 3C 3C 3C 3C 3C 3C 3C. This seems to indicate that video memory reads are not repeatable.

Can you please retry the experiment several times and check whether the results are repeatable? Please add an "i" after every "o" to check wheter the write worked, with one exception: After o3C2 23, use i3CC, not i3C2. Also add "o3B5 55; i3B5; o3B5 AA; i3B5" (4 lines) after "i3B4".

Thanks mkarcher for going over the output. Yes those assumptions are correct. Tests are done without any other video adapters besides the OAK.

Regards the memory test, there is no RAS,CAS coming out of the OAK chip. I was expecting a continuous pulse train of RAS/CAS for the DRAMS , even before your memory test being executed.
I added the lines you mentioned to the script, and repeated the tests multiple times, and also tried it on 86box for comparison, hires results in the links:

Regards the MDA type OE response to 3b4, there is a non zero possibility that the dip switch settings are wrong. There is only 1 manual for the oak oti037c chipset online (that butjer1010 mentioned), and I am going with that for the VGA setting. I had already tried all 2^4 dipswitch possibilities with VGA, then EGA monitors connected, so I dont think the boards non display problems are due to bad dipswitch settings. However I found the below on a forum post from March this year, the settings he mention are not for VGA in the manual, but for a type of NEC monitor. I repeated test with that dipswitch setting too, but got same results as before.

Thanks

The results are very curious, especially if they are reproducible. I noticed that the video memory readback in the current test is FF FF FF FF FF FF FF FF (likely no response at all), while in the previous test (with the shorter script), it was 74 74 74 74 74 74 74 74 or 73 3C 3C 3C 3C 3C 3C 3C depending on what you look at. Also, the 3D4 readback is FF this time, while it was 37 last time. This does again not mean you did anything wrong. In case of broken/borderline TTL driver chips, some differences may also be caused by using a different mainboard this time.

I understand that you are unsure about the DIP switches, but as long as the card is not configured by the BIOS into a legacy emulation mode (we likely should check that, if possible), it should respond to either to 3B0..3BF, or to 3D0..3DF. You again got responses to both 3B5 and 3D5, which is something that just shouldn't happen if everything was working properly. You should be able to configure the range 3Bx vs. 3Dx using the least significant bit of what you write into 3C2. I let you write an odd value into 3C2, so the card is supposed to respond to 3Dx only, and should allow a MDA card 3Bx to respond to 3Bx cycles. This is not supposed to be dependend on the DIP switches.

Actually, the pattern is quite interesting. You already got the bad responses from 3D4 and 3D5 in the 286 mainboard with the shorter script. Interestingly, the response was 37 and not FF, but I would not put too much attention to that - sometimes on older boards ther are no strong pull-ups on the bus, so maybe it's OK to get something other than FF even if no device actively drives the bus. This could also explain the strange video memory readings: If you just get something that was on the bus before, this might be processor instructions from DEBUG. Different instructions while printing the hex values and while printing the characters make a lot of sense. So, don't chase that path, as it might be more a pecularity of the 286 board than an indicator for what's wrong with the VGA card. But something is strange: It seems the response to 3B4/3D4 can be reliably flipped over without accessing 3C2! You get a good response from 3B5 after writing AA, and a good response from 3D5 after writing 55.

Something like this might happen if all writes to 3Bx/3Dx mistakenly also decode to 3C2. After writing an even byte to 3D4/3D5, we get good rplies from 3Bx only. After writing an odd byte to 3D4/3D5, we get good replies from 3Dx only. You missed one detail of my last post, which was not that important at that time, but is very important for the next test. To read the value from the configuration register you write at 3C2, you can't read 3C2 (as you did in your latest reply), but you have to read 3CC instead. This is due to historical reasons, and doesn't have to make sense. To test my hypothesis that 3Dx/3Bx mis-decode to 3C2 as well, please test the following

1o3C2 23
2i3CC
3o3B4 0E
4i3B4
5i3CC
6o3B4 0F
7i3B4
8i3CC
9i3D4
10o3B5 AA
11i3B5
12i3CC
13q

If writing odd value to 3Bx/3Dx ports causes the card to switch over to color ports, we should get a good readback of 0E at 3B4, but a bad readback of 0F at 3B4, while it will magically appear at 3D4. The value at 3CC will show whether card "knows" what ports it is currently responding to.

Apologies for the 3C2-3CC omission yesterday, the value returned as per below in all four places is 00. The 0F did appear after i3D4.
In case it helps, I probed with the scope during yesterdays tests, and did not see any pulse train for CAS throughout, it stayed at a static 2.3V . Thanks

-o 3C2 23
-i 3CC
00
-o 3B4 0E
-i 3B4
0E
-i 3CC
00
-o 3B4 0F
-i 3B4
FF
-i 3CC
00
-i 3D4
0F
-o 3B5 AA
-i 3B5
AA
-i 3CC
00
-a100

OK, thanks for your tests. I see several issues here: The 3CC readback of 3C2 does not work at all. Also, my suspcion that values written to 3B4 or 3B5 influences whether the card responds to color or monochrome addresses is conformed. I think I can confidently conclude that the OAK OTI-037C chip is broken. As reading and writing from and to 3C4, 3C5, 3CE and 3CF works perfectly, the bus interface seems fine. All I/O address decoding is performed inside the OAK chip, so there seems to be no way writing to 3B4, 3B5, 3D4 or 3D5 should change the mono/color bit in 3C2 if there are issues outside of that OAK chip. While obviously some short circuits on the multiplexed data/address bus may affect some ports, but not other ports, the multiplexed nature of the bus, and the seemingly perfect operation of the data bits during 3CF access makes it unlikely that this bus is broken. Also, I fail to see how 3B4 and 3D4 can get mangled into 3C2. That misdecode must happen inside the OAK chip. So, that's likely game over for that card, I am sorry.

Thanks all the same. There is a lot of good info in this thread. Someone else might be able to use this info to diagnose their OAK at some point in the future. Apart from downloading BIOSs I had never used Debug.exe before . Cheers

randi wrote on 2025-08-04, 23:31:

Regards the memory test, there is no RAS,CAS coming out of the OAK chip.

It seems the OAK chip is capable of not generating RAS/CAS: The memory timing is generated by the EGA/VGA component called "timing sequencer". On the original EGA and early clones, it was a dedicated chip, which is programmed using I/O ports 3C4/3C5. It looked as if the sequencer correctly responds to I/O cycles directed to it, so maybe you can successfully program it. If you write 0 to 3C4, the 3C5 register can be used to place the sequencer into a reset mode, in which "the video memory contents may get lost" (quoting the OAK datasheet). Writing the value 3 into that register should put the sequencer into fully operational mode, so "o 3C4 0 ; o 3C5 3" is a way to enable the sequencer and the RAS/CAS output.

Typically, the sequencer reset is disabled at the end of configuring a video mode, so the OAK BIOS should have disabled sequencer reset during the attempted POST. I have no good explanation why the sequencer would be in reset when the system is booted, but as we already discovered unintended state changed when writing to 3D4/3D5/3B4/3B5, maybe the sequencer reset is accidentally activated after setting a video mode. If you are curious, you can try to explicitly enable the sequencer and scope the RAS/CAS signals. It won't help getting the card working, though, it's just for your curiosity (if present).