Valerio
Experienced Member
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:
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:
Symptoms:
Visual checks:
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:
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:
ISA I/O reads/writes:
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:
Anyway the results are mixed... Good news:
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?
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:
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!
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):
- Power supply is a brand new Startech AT 230W PS, https://www.startech.com/Computer-P...t-Replacement-PS2-AT-Power-Supply~PS2POWER230 , which I know works as I tested it with my other 486 build. All voltages (as well as POWER_GOOD) are fine at the AT power connector on the MB.
- DC rails on the ISA bus are also fine
- CMOS battery is charged (reading 4.04v with the power off)
- The CPU voltage regulator is an LT1086CT (http://cds.linear.com/docs/en/datasheet/1086ffs.pdf) in a TO-220 casing and its output is fine (3.43v on pin 2)
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:
- 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?
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!