• Please review our updated Terms and Rules here

Gigabyte GA-486VS diagnosis

Valerio

Experienced Member
Joined
Aug 20, 2017
Messages
131
Location
New York, Rome, London
Hello! This is my first post.

I recently acquired a 486 motherboard from eBay, a Gigabyte GA-486VS, but it won't POST - no outwards signs of life. I've tried a number of things to diagnose it, but I've now reached the limit of my knowledge/experience/imagination so I'd be grateful for any suggestions as to what to check next! Apologies in advance for the long post.

So here goes -

Background:
I was looking for a late-486-era, good-known-brand motherboard with VLB, support for 72pin SIMMs, and no PCI - this seemed to fit the bill perfectly. The goal was to build an era-appropriate 486 PC, which I have now done with another motherboard. However this is, at least on paper, still a very good motherboard and I'd hate to throw it away... not to mention that it bothers me that I don't know what exactly is wrong with it.

Summary of MB features:
  • GigaByte GA-486VS Rev. 8B
  • Socket3 with 3.3v/3.45v support for DX4s, etc.
  • SiS 85C471/85C407 chipset
  • 256KB 15ns L2 cache (32k8 x 8)
  • 3 VLB slots, no PCI slots
  • 4x 72pin SIMM slots, no 30pin slots
  • no onboard peripherals (HDD/FDD/etc)
  • Award bios version 4.50G dated 21 Nov 1994

Manual is here: http://www.motherboards.org/files/manuals/47/486vs8a.pdf
Chipset datasheet (85C471 only) is here: ftp://retronn.de/docs/chipset/SiS 471.pdf
I could not find the datasheet for the 85C407 (the "southbridge", I guess) - does anyone have it?

Test config:
Currently configured with an AMD DX4-100 (33 MHz FSB), but I also have an Intel DX2-66 for tests (makes no difference to symptoms). I also have a few options for
RAM to test with (4 MB to 32 MB modules, EDO and non-EDO) but as we'll see later it's not relevant so most of the steps below are carried out with a bare-bones
config as follows:
  • no RAM (I did leave the L2 cache installed though)
  • no ISA or VLB cards
  • no keyboard
  • a heatsink and fan on the CPU as it does heat up
  • a PC speaker

Symptoms:
  • bank screen (when tried with a Cirrus Logic VLB video card)
  • no beeps
  • num lock & caps lock leds on the keyboard are on but they are not responsive to key presses

Visual checks:
  • no visible scratches, dents, bent/broken pins at all (I checked both sides)
  • the three electrolytic capacitors appear to be in good condition, and so do the several tantalum ones
  • the CMOS memory battery is not leaking and there is no corrosion damage anywhere
  • I have checked for any debris that may be wedged in any of the ISA/VLB/Socket3/keyboard connectors or between pins but there was nothing. For good measure I thoroughly blasted it with compressed air from a can.
  • I resisted the temptation to put it through the dishwasher (https://www.youtube.com/watch?v=De8BV-2mxec)

Basic DC tests (with a voltmeter):

POST codes:
I have recently bought this https://www.amazon.com/dp/B008BZBKXC ISA/PCI POST diagnostic board. When used with this MB the relevant voltage LEDs light up and the reset LED responds to the reset contact on the MB being operated. The segment-display self-test works. No other information comes up - no POST codes appear. However, I think there's something weird with this board (I've tried it on my other 486 and it does not respond to OUTs on 0x80 when used in an ISA slot) so this is not entirely reliable. It's also supposed to display the bus frequency but it shows F-----, but it fails to do so on my other 486 as well (PCI or ISA slots). I have ordered another one of a different model but it will take a while to arrive.

BIOS:
  • This is stored on a ST M27C512-15 28pin-DIP EPROM. This is a 64Kbyte (64k8) 150ns chip, and I have checked it receives the correct DC power supply from the MB.
  • I have read its contents with an EPROM reader and compared it with the BIOS image from this website: http://th2chips.freeservers.com/ga486vs/index.html and they match except for one byte (and hence the checksum byte) in a probably-unimportant location. Both my BIOS and the downloaded BIOS have the correct 0x00 checksum.
  • Just to be safe, I flashed the content of the dowloaded BIOS to a new Winbond W27C512-45 EEPROM chip and tried it on the MB, with no change in results.
  • Following Pinczakko's excellent guide (https://sites.google.com/site/pinczakko/pinczakko-s-guide-to-award-bios-reverse-engineering) and using IDA Pro I disassembled the first few hundred lines of the BIOS code (it's a bit tedious) and found nothing unusual. I did confirm that the code:
    - starts with the usual far jump at 0xFFF0 ROM location (mapped to F000:FFF0)
    - outputs diagnostic codes on 0x80 from time to time
    - eventually instructs the PC speaker to beep using the onboard timer (at port 0x61)

Ok so no obvious source of the issue up to this point. For what follows I have used a 100 Mhz, 2-channel digital sampling oscilloscope (a Siglent SDS1102CML).

Clocks:
  • The clock generator is (I think) a UM9515-01 but I could not find any datasheets for it. Similar generators usually have the clock output on pin 8 so I checked
    that and it does have a 33 MHz wave. It's not super clean:
    33MHZ.jpg
  • The ISA bus has good OSC (at 14.318 Mhz) and BCLK (at 7.159 Mhz, ie OSC/2) signals

ISA I/O reads/writes:
  • The BIOS code contains several IN and OUT instructions from the very beginning. Most of these are chipset-configuration related (cf the chipset manual) so it is possible that the chipset traps these and does not broadcast them on the ISA bus. However we should at the very least see the 0x80 diagnostic OUTs (even if my dodgy POST board does not show them).
  • to check this, I simply set the oscilloscope to trigger a single acquisition on the falling edge of IOW\ (B13 on the ISA connector)
  • results: nothing! not a single trigger... not good. Same thing with IOR\ (B14).

Now the hard part... pls shout if I got any of the details wrong.

So we know that upon RESET being deasserted the 486 CPU is supposed to start instruction fecthing and execution in Real mode at physical location 0xFFFFFFF0 with CS:IP set to F000:FFF0. The chipset should map this to the onboard ROM, which contains the BIOS. So the first thing to check is whether the ROM chip is being accessed correctly and with the right address (ie starting at 0xFFF0 as the chip has 16 address lines). To do this I:
  • set the oscilloscope to trigger a single acquisition on the falling edge of RESET (B2 on the ISA connector) on one channel
  • use the other channel to acquire the following signals, one at a time: Chip Enable (CE\) and Output Enable (OE\) on the ROM chip, and SA0 to SA15 on the ISA connector
  • I have checked and the address pins on the ROM chip are directly electrically connected to the ISA connector lines SA0...SA15 - no buffers/transceivers in the middle. The latter are much less fiddly to sample with my probes.
  • I acquire about 80 usec of data at 250 MSamples/sec (on each line), ie the first 70 usec after RESET is deasserted
  • I transfer all the waveforms to a laptop and in Excel I crudely identify the time positions of the falling edge of OE\ and "read" the level on the address line waveforms at those times
  • I check that CE\ is asserted whenever OE\ is asserted (except a tiny part towards the end), so I don't have to worry about it
  • I also make a mental note to buy a logic analyser or a mixed signal oscilloscope as the above is a fairly laborious process...

Anyway the results are mixed... Good news:
  • OE\ and CE\ are cyclically asserted as you would expect
  • the first location being accessed is indeed 0xFFF0 !
  • subsequent locations are accessed in order: 0xFFF1, 0xFFF2, 0xFFF3, etc. all the way to 0xFFFF

Bad news:
The first instruction, at 0xFFF0, is a far jump, specifically JMP F000:E05B, which is a 5-byte instruction (0xEA + ptr16:16). I was not expecting the sequential instruction fetch to stop immediately at after the fifth byte (the 486 has a 32-byte prefetch instruction queue) but I was hoping it would eventually switch to fetching instructions at address 0xE05B or thereabouts, but instead it started accessing 0xE078, no idea why. Here is the list of accessed addresses:
View attachment addresses.txt
Towards the end it looks like it's repeating/skipping addresses but this may well be due to my data acquisitions getting out of sync (remember I acquire the address bits separately on different runs).

Also I don't really know enough about pipelines, prefetching, cache fills, and so on so this could all be absolutely normal. Any insight into this would be highly appreciated.

Next I looked at the actual data being fetched. Unlike the address lines, the data lines of the ROM chip are not electrically connected to the ISA bus so I sampled them directly from the ROM chip pins. More bad news: the waveforms coming out of the ROM chip looked very distorted. Weirder still, if I compared them to those sampled on the ISA bus, the ISA bus waveforms (much cleaner) appear to lead the waveforms on the ROM chip pins by ~120 nanoseconds!! How is that possible if the data originates from the ROM chip?
ISA_vs_ROM_D0.jpg
Also, yet more bad news: even in their distorted form, the data being fetched does not seem to match the data I know is contained in the ROM chip. I tried this with both the original ST EPROM and with the replacement Winbond EEPROM, and I got the same result. Very confusing - and very high probability I did something stupid that I do not realize (yet).

Ok so I was about to give up when I tried something different. I wrote a simple piece of code:

Code:
start:
	CLI
	MOV	AL, 0x26
	OUT	0x80, AL
	NOP
	JMP	start

which outputs a number (0x26) to port 0x80 over and over again. This code is 8 bytes long so I flashed it to location 0xFFF0 in my Winbond EEPROM and tried it out. (partial) Success! The ISA diagnostic board did not show the code (it never does, even on working systems) but with the scope I manually sampled IOW\, BALE, SA0-SA15, and SD0-SD7 on the ISA bus and indeed 0x26 was being written to 0x80. Bad news though: it was only being written once, while my code was supposed to repeat this I/O write operation over and over again. Not giving up yet, I seemed to remember reading somewhere (but I may be wrong) that the first jump instruction after reset must be a far jump, so maybe my loop with a near relative jump somehow confused the CPU (I'm good at finding excuses as to why my stuff doesn't work).

So I tried another code snippet: a proper far jump, followed by a PC speaker beep using ports 0x61 etc. No luck... maybe the programmable interval timer (which is integrated in the chipset) must be properly initialized/enabled through the chipset somehow before it can be used (also see previous comment about excuses). Anyway I'm now scraping the bottom of my reservoir of testing ideas... I'd be very happy to receive suggestions of things I can test or try with the equipment I have. I still hope it's something fixable or a silly mistake by me, or maybe something totally obvious I missed (like the cache chips are insterted backwards! They are not, I checked...)

Thanks for reading so far!
 
IMO you are wasting your time. Buy a working 486 MOBO. There are so many traces / layers / components that may have died that it is probably mission impossible. Try a regular 8BIT/16BIT ISA VGA as well.

I went through this with an IBM PS/ValuePoint 486 MOBO I bought off eBay as a spare. It would post a few times. Then it died. No visible damage. Even less components / traces than this MOBO. In the end I recycled it. It got extremely aggravating. Same with an Everex Tempo MOBO (very interesting early 486: 386 MOBO re-purposed for a 486). Same with a Magnavox 486SX (very interesting early 486: 286 MOBO re-purposed for a 486).
 
I'd say you're doing pretty well! Getting a working ISA POST card would be a good next step, and it seems you're already on the way. Double-check your CPU jumpers, and if it's possible to run the board with no cache, pull the cache.
 
I agree it's almost certainly a waste of time in terms of getting the mb to work... although at least I've learned quite a few new things!

I will try with the new POST card when it arrives. I have kept testing the current one in another system and it seems that it does intermittently respond to OUTs on 0x80, but not consistently (even in a bare-bone system booted to clean DOS & using a few lines of assembly in DEBUG.COM). It's an extremely simple board so it mystifies me how it could end up being broken (or maybe it was badly designed to begin with!).

On the cache option - I did think about that. The MB jumpers do not support a 0KB cache setting but at this point I have nothing to lose - I may try that as well (and if I can get code to execute reliably, I will disable the cache via the chipset).

Thanks!
 
I'm not sure if this applies to your specific board, but anyway. I had a 486 board with some battery damage, and in the process of fixing it I found out that it would not boot at all if the keyboard BIOS wasn't seated correctly. I think it was AMIKEY. It was a bit puzzling as most boards seem to be fine without the keyboard BIOS until they test the keyboard. My guess is the system BIOS did a very early check for the K/B BIOS and if it didn't find it it just gave up.
 
I'm not sure if this applies to your specific board, but anyway. I had a 486 board with some battery damage, and in the process of fixing it I found out that it would not boot at all if the keyboard BIOS wasn't seated correctly. I think it was AMIKEY. It was a bit puzzling as most boards seem to be fine without the keyboard BIOS until they test the keyboard. My guess is the system BIOS did a very early check for the K/B BIOS and if it didn't find it it just gave up.

I can't see a separate keyboard bios on the MB. There is what I think is a keyboard controller, a Lance LT38C41L, but I have no datasheets and anyway it's soldered in place...
 
A few more tests...

First of all I remembered that I can trigger on the EXT line of the oscilloscope so now I can acquire two bits of data at once! What luxury!

Then I have used two OUTs in a row (coded from F000:FFF0 as usual) to 0x80 to check data lines, first 0xAA (10101010b) and then 0x55 (01010101b). Having previously located the position of the second falling edge of IOWC\ from the trigger event (which is the first falling edge) using the cursor, I then go through ISA SD0 to SD7 to check that the correct bits are being output. And indeed they are (CH1 is an even bit, CH2 is an odd bit):

ISA_AA55check.jpg

Unfortunately that's the last thing that went well. I tried using the same code in a different location and jumping to it (nope), reading a byte from memory (even from the very first 16 bytes) and then doing the OUTs above, etc (nope)...

(although now that I think about it memory read instructions before the first jump are probably messy as I don't know how the hidden base address part of the DS segment at startup)

Anyway so it seems that I have a perfectly functional 486 MB as long as any code is at most 16 bytes long and does not read or write from/to memory or perform jumps!
 
Back
Top