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