I tried the SciTech Display Doctor 6.53 universal video driver for windows 95. It detects that the video adapter is a UMC 85c418F-GP, but says that the device is unsupported. It can’t confirm memory >1MB either. It says -1KB.

I tried SNOOP.EXE too. That’s a clever utility. I got some cool info on some of the other VLB-SVGA cards that I have. But it fails when I have the UMC card in the computer. I'm following up in the SNOOP.EXE thread.

The VGA BIOS string on my card reads:

1BIOS VERSION 1.05, BOARD VERSION VL-1AV Date: DRAM: 256K DRAM: 512K DRAM: 1M  11/22/93

The INT 13 portion of the driver reads:

1º   VESA SUPER I/O Card Installed   º
2º   ROM BIOS FOR  UM82C418          º
3º   VERSION 1.02                    º
4...
5 Press  F5  if you want to run SETUP

Sometimes I think I've seen part of that text flicker across the screen at boot screen when the monitor is synchronizing, but if it is there, it is gone before the image stabilizes.

Anyone have a different BIOS I can try?

SNOOP has handwritten case-by-case code to detect different ISA and ISA VLB (S)VGA adapters. This resulted in code like this based on information from the different data sheets and articles on the web.

For PCI adapters it uses a lookup from the PCI-SIG device ID database which is fortunately a generic method for all adapters.

For VESA compatible adapters it reports whatever the VESA driver outputs.

In my lab I've got a couple of dozen graphics cards that I've developed SNOOP on, though I don't have any UMC cards, so the only hope of SNOOP identifying this card is probably if it supports VESA directly from the firmware (in which case SDD and other tools will also give the same information)

If there is a data sheet for UMC cards VGA register extensions somewhere, then it would be possible to add manual detection for that UMC card there. (SNOOP has a custom mode to dump VGA registers if one wants to reverse engineer what the extended registers would mean, although that is not particularly easy task to do.. would require many example card variants/versions to make robust)

I'll take a look at the VGA registers and BIOS calls tomorrow after I dig myself out from under work.

Would SNOOP work if I get SciTech UniVBE 6.7 running?

Seems like it should work with my board but so far no luck.

1List of supported SuperVGA families, and chipsets within each family:
2 23: UMC SuperVGA:
3      2: UM85c418
4
5List of supported Ramdac values:
6 51: UMC UM70c188 24 bit DAC

I figured out how to do the override. I needed to tell it that it didn't have -1KB of ram and that it had a UM70c188 ramdac.

Doesn't seem to make a difference if I say 1024KB or 1536KB. I get the same screen.

I don't know if it works or not yet because messing with the drivers back and forth hosed up my win98se install
The 512MB CF I was using was kind of tiny for a Win98SE install so I tried a larger drive. What should have been a simple matter was complicated because this loads after the MR BIOS but before whatever option rom or overlay that I add and it causes some curious failures. Been a while since I've had a set up where EZ Drive 9.09 couldn't boot.

1º   VESA SUPER I/O Card Installed   º
2º   ROM BIOS FOR  UM82C418          º
3º   VERSION 1.02                    º

I'm going to go back to the 512MB device and do a win95 osr2 install

I got things sort of working with this configuration:

I hooked up my old Sony Multisync and then changed the refresh to something the LCD liked and I could do 800x600x256. Seems like the clock is not right. Also Screen would glitch every time I opened a command prompt window in a way that makes me think that it doesn't have the memory configuration right. It would go back to normal if I hit alt-enter twice.

Ideally, I think you might be able to use a 2MB card if you had something like this:

How can I tell what the clock chip is on the board?

But I expect that the UM70c188 ramdac might hold you back. Maybe it's possible to replace the ramdac with a better one?

Here's some info I found about the UMC UM70c188:

https://pdos.csail.mit.edu/6.828/2008/reading … adoc/RAMDAC.TXT

1UMC UM70c188 TrueColor DACs:
2
3REG06 (R/W):  Command Register
4bit 0-3  (R) Always 0
5      4  Set in 24bit mode, clear in all other modes
6    5-7  Mode: 5: 15bit, 7: 16bit. Don't care for 24bit
7Note:  This register can also be accessed at REG02 by reading REG02 four
8       times. Then the command register can be read or written at REG02.
9       This access will be terminated by any access to REG00, REG01 or REG03
10       or after a read or write of the command register.  (DAC type 4-1r1w).

douglar wrote on 2024-01-23, 00:47:

I hooked up my old Sony Multisync and then changed the refresh to something the LCD liked and I could do 800x600x256. Seems like the clock is not right. Also Screen would glitch every time I opened a command prompt window in a way that makes me think that it doesn't have the memory configuration right. It would go back to normal if I hit alt-enter twice.

I take it you couldn't do 1024x768@8bpp?

Just got a 418, 800x600@8bpp at 56 Hz and 70 Hz both work. I don't think it has the appropriate dot clock for 60 Hz.
At 1024x768@8bpp at 60 Hz using my code, it generates a display that is horizontally distorted, about 2/3 across the screen it starts repeating an earlier section of that line.
Display Doctor for DOS will attempt 1024x768@8bpp but has a different problem: it's as if it is a split-screen vertical view with the same content in each half.
I haven't tried on a CRT, maybe 1024x768 87i Hz works

jakethompson1 wrote on Yesterday, 00:51:

I take it you couldn't do 1024x768@8bpp?

Just got a 418, 800x600@8bpp at 56 Hz and 70 Hz both work. I don't think it has the appropriate dot clock for 60 Hz.

Can you share a picture of your card? Perhaps there are jumpers or switches that control the refresh rates.

I'm going to get out that card tomorrow and see if I can get 1024x768@8bpp working with an LCD or a multisync.

Pictures of this 418 card
Edit: I wonder if JP5/JP6 are setting which memory clock to use.

jakethompson1 wrote on Yesterday, 00:51:

At 1024x768@8bpp at 60 Hz using my code, it generates a display that is horizontally distorted, about 2/3 across the screen it starts repeating an earlier section of that line.

That's a strange symptom for a DRAM-based card. For VRAM-based cards, symptoms like this might be caused by missing a reload of the VRAM shift register (although at 1024 pixels per line, VRAM shift register reload issues are more likely to occur at exactly the center of the screen, not 2/3 across). Possibly something is messed up with page mode access? The RAM on that card is built from 256k x 4 chips, which typically have a page/row length of sqrt(256k) = 512 entries. At 1024 pixels with 8bpp, a RAM page would still be 2 full scan lines. So I don't think the artifact can be explained by overly tight RAM timing on page misses, as you don't have a page miss 2/3 acress the screen.

Another theory could be some register in the horizontal timing being way off and disturbing the horizontal scan-out at that position. On the other hand, I don't recognize how you should get to that position of some high bit of e.g. the horizontal total register is flipped. But 2/3 of the screen might be half the total scan line length, i.e. 1344 pixels. Interlaced 1024x768 modes require every other VSYNC to be half a scanline off. If the interlace timing generation logic somehow kicks into you mode timing, it might do "stuff" at 2/3 of the width.

jakethompson1 wrote on Yesterday, 00:51:

Display Doctor for DOS will attempt 1024x768@8bpp but has a different problem: it's as if it is a split-screen vertical view with the same content in each half.
I haven't tried on a CRT, maybe 1024x768 87i Hz works

If it were repeated after 512 scanlines, it would look like a memory addressing issue, wrapping at 512K - but that wouldn't make sense for "same content in each half". On the other hand, if that actually is interlaced output, you might get the even lines in the upper half and the odd lines in the lower half. I think your best bet to get a working 1024x768 mode is trying to convince the Video BIOS to set it. You might need to find out how to configure the video BIOS for a 48kHz monitor.

mkarcher wrote on Yesterday, 16:54:

jakethompson1 wrote on Yesterday, 00:51:

At 1024x768@8bpp at 60 Hz using my code, it generates a display that is horizontally distorted, about 2/3 across the screen it starts repeating an earlier section of that line.

That's a strange symptom for a DRAM-based card. For VRAM-based cards, symptoms like this might be caused by missing a reload of the VRAM shift register (although at 1024 pixels per line, VRAM shift register reload issues are more likely to occur at exactly the center of the screen, not 2/3 across). Possibly something is messed up with page mode access? The RAM on that card is built from 256k x 4 chips, which typically have a page/row length of sqrt(256k) = 512 entries. At 1024 pixels with 8bpp, a RAM page would still be 2 full scan lines. So I don't think the artifact can be explained by overly tight RAM timing on page misses, as you don't have a page miss 2/3 acress the screen.

I ended up messing with the UVGA utility from the UM408 drivers on the 418. Running UVGA M7 sets the monitor type to a NEC 4D and unlocks non-interlaced 1024x768. Then if I use int 10h to switch to 1024x768 at 4bpp, all is well. If I switch to 1024x768 at 8bpp, I get the same visual artifacts as described above. I get the DOS prompt back, then if I just hold down a key, eventually I get a second of that character further across the screen for a certain portion of the line, then it goes back to normal past that. I should get a picture later

Here are the ram chips on my card:

They are all G44256BP80 DIP 20, but there are 9 with the stripe on the left and 3 shorter ones ( 4, 5 ,7 ) without the stripe.

I'm assuming that this pinout is correct:

https://pcbjunkie.net/index.php/resources/ram … reference-page/

Vxx, Gnd and OE are each connected to the same pin on each chip
I/O1 & I/O2 are not connected to anything. Some look isolated. Some have traces. I followed the I/O1 trace from chip 1 to a via near the notch in chip 12, but that via doesn't seem to go anywhere.
I/O3 & I/O4 are connected to unique pins on the UMC UM85C418F chip
The Ax pins + CAS/RAS seem to be arranged in two banks of 6 chips (1 2 3 4 5 6 / 7 8 9 10 11 12)
WE seem to be arranged in 4 banks of 3 chips (chips 1 2 5 / 3 4 6 / 7 8 11 / 9 10 12)

Does that make sense?

douglar wrote on Today, 01:33:

They are all G44256BP80 DIP 20, but there are 9 with the stripe on the left and 3 shorter ones ( 4, 5 ,7 ) without the stripe.

Different package shapes (yeah, all DIP20) make me suspect those chips come from different factories. Yet they have the same marking including the same production week (30th week of 1993). This does not look like official factory marking, but more like custom markings applied by a reseller of broken chips.

douglar wrote on Today, 01:33:

I'm assuming that this pinout is correct:
https://pcbjunkie.net/index.php/resources/ram … reference-page/

I don't think you have to doubt that. This pinout is industry standard.

douglar wrote on Today, 01:33:

Vxx, Gnd and OE are each connected to the same pin on each chip The Ax pins + CAS/RAS seem to be arranged in two banks of 6 chip […]
Show full quote

Vxx, Gnd and OE are each connected to the same pin on each chip
The Ax pins + CAS/RAS seem to be arranged in two banks of 6 chips (1 2 3 4 5 6 / 7 8 9 10 11 12)
WE seem to be arranged in 4 banks of 3 chips (chips 1 2 5 / 3 4 6 / 7 8 11 / 9 10 12)

Does that make sense?

This makes sense. /OE might be connected to ground permanently. The split between Ax / CAS / RAS lets me think they did that to reduce the load on a single output. Possibly it is two banks, but even if it were two banks, the address would not have to be split - well, except if this is a copy of the IBM EGA design that uses split addresses to load font data from plane 2 (at an address from "address bus B") while loading the next character/attribute combination from planes 0 and 1 (at an address from "address bus A"). So the address lines are either split to allow parallel cycles at different addresses, or just because 12 chips on one address output is too much. I don't know, and it doesn't really matter.

Each "block" of 6 chips is obviously subdivided in two "subblocks" of 3 chips, that can individually be written. This also makes some sense.

douglar wrote on Today, 01:33:

I/O1 & I/O2 are not connected to anything. Some look isolated. Some have traces. I followed the I/O1 trace from chip 1 to a via near the notch in chip 12, but that via doesn't seem to go anywhere.
I/O3 & I/O4 are connected to unique pins on the UMC UM85C418F chip

This is likely incomplete. As you write it, each "subblock" has 6 data lines connected. That makes no sense. The EGA/VGA design requires a 32-bit memory interface based on 4 8-bit bytes, so each "subblock" needs to have 8 data lines connected to the UMC chip, and everything would line up perfectly. This means I suspect you missed some chips that do have I/O1 or I/O2 connected to unique pins on the UMC chip. In each "subblock", only one chip is supposed to have two connected data lines, and the other two chips are supposed to have three connected data lines. A 2+2+4 layout would be possible, too, but I haven't seen it yet.