wbahnassi wrote on 2025-07-25, 08:13:

Yes, the POST card shows a sequence. The sequence changes between BIOS vendors (Ami, Award, Phoenix). I think I'm currently on an Ami one.

The current startup sequence I get is a few codes that run very fast, then it pauses on 1A 19 and gives the VGA error beep pattern. . After that, it continues to roll again against a few codes until it lands on either 30 24 or 30 25... it's random between these two (24 and 25).

Odd, these codes don't make much sense for graphics card error. Maybe there is a problem with stuck address bit on the BIOS ROM after all?
Since you are getting codes on the card, assuming those are not glitched, the lower 8 bits of data and addresses up to A9 seem to work fine. Could be higher address lines or upper data byte has issues. You did mention a short on D15 line to GND in one of the slots, could be that caused some issues - the problem is this is driven directly from one of the big chips. Did you check the voltage on that line afterwards, is it a valid logic level? Does it ever toggle during boot sequence?

Deunan wrote on 2025-07-25, 20:40:

Odd, these codes don't make much sense for graphics card error. Maybe there is a problem with stuck address bit on the BIOS ROM after all?
Since you are getting codes on the card, assuming those are not glitched, the lower 8 bits of data and addresses up to A9 seem to work fine. Could be higher address lines or upper data byte has issues. You did mention a short on D15 line to GND in one of the slots, could be that caused some issues - the problem is this is driven directly from one of the big chips. Did you check the voltage on that line afterwards, is it a valid logic level? Does it ever toggle during boot sequence?

I have replaced the tranceiver with another chip of the exact model as the original one, so that should be off the checklist now.
I have probed the ISA pins again.. I confirm that all data and address lines are showing activity all the way including the 16-bit part of the slot. I took a photo of the Data 15 pin probe, it doesn't seem stuck to me (nor any other address nor data line for that matter).
I also wanted to see the tranceiver's behavior after replacement, and noticed that the signal from one side is quite square, but from the other side (the side connected to the ISA busses) has a slow ramp for each high signal on each of the data lines. Is this normal? I see also this ramp up on the Data15 photo also.

wbahnassi wrote on 2025-07-26, 19:54:

I have probed the ISA pins again.. I confirm that all data and address lines are showing activity all the way including the 16-bit part of the slot. I took a photo of the Data 15 pin probe, it doesn't seem stuck to me (nor any other address nor data line for that matter).
I also wanted to see the tranceiver's behavior after replacement, and noticed that the signal from one side is quite square, but from the other side (the side connected to the ISA busses) has a slow ramp for each high signal on each of the data lines. Is this normal? I see also this ramp up on the Data15 photo also.

Yes, to some extent. TTL drivers (and NMOS too) run out of current so to speak at about 4V, and after that the edge rise gets slower and slower, so it bends. But the switching treshold is at 2V so that's good enough. On ISA you'll see it more because of the capacitance of the board and slots, and load of the cards. Also some really slow edges that start bending well below 4V are most likely tristated (high impedance) signals, the voltage rise is entirely due to small current from the pull-ups on the TTL inputs. You should be able to see some proper looking pulses there as well, but to know exactly what is going on requires a scope with more than 1 input and some extra trigger logic to capture only the states you want to examine. That way you'd know if that is a read or write and which device is driving the bus.

I've attached a simple test for the ISA bus. There's two "BIOS" files for you to put in the EPROMs. It doesn't do much, you'll need a POST card and it should show you some codes. Eventually it'll loop. See what it does, maybe make a short video. Nothing else other than POST card is needed, in fact try just with that and then maybe add a VGA and see if it does something else.

Deunan wrote on 2025-07-26, 23:02:

Yes, to some extent. TTL drivers (and NMOS too) run out of current so to speak at about 4V, and after that the edge rise gets slower and slower, so it bends. But the switching treshold is at 2V so that's good enough. On ISA you'll see it more because of the capacitance of the board and slots, and load of the cards. Also some really slow edges that start bending well below 4V are most likely tristated (high impedance) signals, the voltage rise is entirely due to small current from the pull-ups on the TTL inputs. You should be able to see some proper looking pulses there as well, but to know exactly what is going on requires a scope with more than 1 input and some extra trigger logic to capture only the states you want to examine. That way you'd know if that is a read or write and which device is driving the bus.

I've attached a simple test for the ISA bus. There's two "BIOS" files for you to put in the EPROMs. It doesn't do much, you'll need a POST card and it should show you some codes. Eventually it'll loop. See what it does, maybe make a short video. Nothing else other than POST card is needed, in fact try just with that and then maybe add a VGA and see if it does something else.

Thanks for the explanation. Ok, I've flashed the two BIOS files. My EEPROMs are W27C512 (64 KB), so for each chip I'm putting its relevant 32KB data at both 0x0000 and 0xC000. Hopefully this is alright.
Here is a video capture of the sequence until I think it repeats: https://youtu.be/I18IjJ9aH38

Is this the pattern you were expecting? I noticed the second number always seems to have an 0x80 added to it (highest bit always on). Not sure if this is what you programmed it to do. But if it's not, then it's probably the culprit.

wbahnassi wrote on 2025-07-27, 01:48:

Is this the pattern you were expecting? I noticed the second number always seems to have an 0x80 added to it (highest bit always on). Not sure if this is what you programmed it to do. But if it's not, then it's probably the culprit.

This is the expected result. C003 is a code I display first as sanity check, then the program goes through some I/O ports - this was written to test address lines A4 to A7 so that's why the sequence is like that. What I do here is assume the mobo has 74612 or emulation of this register for DMA paging purposes. So I write and read the value from there, but it's only 4 lower bits. However outputs to the POST card are 8 bits obviously and that all seems to work. So in general I'd say the ISA 8 lower data bits and adress bits involved in I/O space decoding work OK on your mobo.

So with that we can try checking the higher address and data bits, knowing that POST card should be reliable enough as a debug device. The question is how to do it. These POST cards have some limitations, for example you can't output the same code twice, it won't show it properly. I think the best approach would be to use a 16-bit VGA card. I can write a test that tries to write and read from VRAM in both 8-bit and 16-bit mode. Since the read will happen shortly after the write we don't care if the card has been initialized and is doing refresh properly. I should have some time later today to try and code something like that for you.

Thanks @Deunan. Those test BIOSes are definitely useful for others as well. Hopefully they can find them here with a description of what to expect.
In the meantime, I did another attempt with an 8-bit EGA card since 8-bit ISA seems to be all good, alas.. it still isn't recognised.
I'm starting to suspect something is off with the ST62C008 chip. It is close to the old leaky battery area, and its legs look dull despite my cleaning. But I did confirm that all lines from the tranceiver are reaching that chip. The only line I couldn't yet trace is the OE line, but IIRC it did have some activity when I probed it.

Here's the next test. My own Suntac mobo is starting to give me trouble too, it just doesn't want to boot when taken out of the box after weeks of not being used. Problem with mine is it eventually does start working and after that it's not possible to debug it anymore until it 'breaks" again.

Anyway, I only tested this code as a COM program but seems to work as intended. You'll need to have a VGA in a 16-bit slot. This test only does data bus bit walk because until we can confirm that works there is little point in doing address tests. So I tried to keep it simple - the POST card should start with 5501 code and eventually loop back to that. The video you've made last time was very good, do another one.

EDIT: /OE on the 245 seems to be connected to AEN, which is generated by 002. DIR is controlled by 005 it seems. The schematic I have is from earlier version that uses 006 instead of 007+008 combo, so there are some differences in how ISA is handled. There might be corrosion under your 008 chip, and some broken connections there. Problem is desoldering these chips from corroded pads is major PITA. It usually requires spending some time with soldering iron on each pin, refreshing the solder so it flows properly. Only then can the chip be lifted with hot air.

Alright, tested it and recorded the operation: https://youtu.be/bE29Th8ViHo
I noticed it does indeed start at 5501, but then it gets stuck in a loop of b0 FF, b1 FF, b2 FF, b3 FF, then back again to b0 FF, b1 FF, ...
I tried two different VGA cards. That didn't make a difference. I waited for quite a bit, but I think it was really stuck in the above loop.

Since I was mentioning the 008, I thought I'd post photos of how it looks here. I struggled to find BIOSes for boards with 007 and 008. I wonder if using other BIOSes is not compatible with this specific boards, since they don't use those two chipsets. I'm not quite enthusiastic about desoldering the 008 as my soldering skills aren't quite there yet, and it's surrounded by caps.. 😀

The slight bend on one of the legs is alright. There are no shorts there, I double-checked that.

wbahnassi wrote on 2025-07-28, 20:25:

I noticed it does indeed start at 5501, but then it gets stuck in a loop of b0 FF, b1 FF, b2 FF, b3 FF, then back again to b0 FF, b1 FF, ...

It's not stuck. Either I messed up somewhere or your ISA is not doing memory access cycles at all. Check /MEMR i /MEMW, both the system wide (B11 and B12) and ISA local (C9 and C10) on ISA slot for activity. One of these at least I'd expect to be missing.

What you should see here is another bit walk test like what it starts with, but 16 bits and with inversions also tested. The first test is simple I/O output only as a sanity check.

wbahnassi wrote on 2025-07-28, 20:25:

I'm not quite enthusiastic about desoldering the 008 as my soldering skills aren't quite there yet, and it's surrounded by caps.. 😀

Don't do anything with it for now. My Suntac mobo is also 008 based. I will try to figure out how that's connected to ISA and the system bus, but that's a lot of pins to check and I'm short on free time. In the meantime I'll double check my code to see if I made any mistakes. There is RAM on your mobo, right? You could quickly hack the test to use system RAM instead, that would tell is if the code works and also test the data bits, since that is what it does. In the even.bin file, at offset 0x4019, there is byte 0xB8. Change it to 0x01, program again and retry.

EDIT: Or if that is EPROM, change it to 0x08 and that won't require erase cycle, since 1 to 0 can be always written. It will require 1M (or more) of RAM though.

Deunan wrote on 2025-07-28, 21:51:

It's not stuck. Either I messed up somewhere or your ISA is not doing memory access cycles at all. Check /MEMR i /MEMW, both the system wide (B11 and B12) and ISA local (C9 and C10) on ISA slot for activity. One of these at least I'd expect to be missing.

I checked the 4 pins. Those three: B11, C9, C10 are showing good activity. However, B12 /MEMR is indeed stuck high! What could be wrong here?

wbahnassi wrote on 2025-07-31, 17:20:

I checked the 4 pins. Those three: B11, C9, C10 are showing good activity. However, B12 /MEMR is indeed stuck high! What could be wrong here?

Check soldering on 002 chip. These two (/SMEMR i /SMEMW) are pulled up by external resistors so if the solder on the pin is cracked it would make the signal permanently high if the rest of the signal path is OK. It's probably pin 39 you want to check but the schematics were printed as cheaply as possible and the numbers are hard to read. Also keep in mind on some of these chips the numbering starts in the middle of one of the sides. If you can't find anything I'll verify this on my mobo.

I think it's pin 30 on the 002 chip. I traced B11 and it goes into R30 (10K Ohm), and B12 goes into R31 (also 10K Ohm).. and the other ends of both R30 and R31 go directly to pin 30 on the 002 chip.
The 002 chip looks pristine to me.

I also found B12 to connect to another trace. That trace ultimately should go to the 007 chip, but I found that it's severed. The cut location is on one of the vias under the corroded battery. The via is actually not connecting across the board. The surface part is fine and goes to 007. The bottom part connects to B12. But bottom and surface aren't talking to each other.. I'll try to fix this by inserting a thin wire and soaking it with solder from both ends.

wbahnassi wrote on 2025-07-31, 19:42:

I think it's pin 30 on the 002 chip. I traced B11 and it goes into R30 (10K Ohm), and B12 goes into R31 (also 10K Ohm).. and the other ends of both R30 and R31 go directly to pin 30 on the 002 chip.

Pin 30 is probably connected to +5V. R30 and R31 are the pull-ups I mentioned, though I expected those to be part of a resistor network. These are unfortunately the differences between the schematics and newer (?) boards with 007 and 008 chips. It seems 007 has some functions that were originally part of the 002 chip, like the RAS/CAS timing for RAM chips based on the delay line.

wbahnassi wrote on 2025-07-31, 19:42:

The cut location is on one of the vias under the corroded battery. The via is actually not connecting across the board. The surface part is fine and goes to 007. The bottom part connects to B12. But bottom and surface aren't talking to each other.. I'll try to fix this by inserting a thin wire and soaking it with solder from both ends.

A glass fiber pencil is great for removing solder mask (and corrosion from copper). Can be done with fine sandpaper too but that tends to unmask more than you need. If you need a good thin wire then strip a piece of some old power cable and take one strand of copper from that. I had a cracked via on my Suntac even without the corrosion, so that doesn't really surprise me.

And we have progress. VGA came through. On boot, VGA displays its VBIOS text, then the BIOS takes over and shows the error in the photo, with a non-stop stream of beeps.

I tried the original BIOS chips and I couldn't get a VGA signal out of them, so I'm guessing there are more things that need fixing here. Earlier I do remember finding address 20 on ISA having no signal at all. I wonder if this is that issue. I'll try some other BIOSes as well just in case.. but good news so far 👍

wbahnassi wrote on 2025-07-31, 21:20:

Earlier I do remember finding address 20 on ISA having no signal at all. I wonder if this is that issue.

A20 should be inactive until something (BIOS or HIMEM) enables A20 gate. Seems like yours can't, might be wrong BIOS or it's more broken conenctions. On these old mobos this should still be handled by the KBC, but possibly there is already faster emulation in the 008 chip for example. Pin 22 of the KBC is A20GATE output, you should see it change state. But you'll need to set the scope trigger right as it won't be much activity, just a pulse probably. I would set the scope for single trigger, power the mobo, then arm the trigger and use reset button to force BIOS to retry. During power on there is usually too much noise so that's why a delayed arming and reset is better.

On the expense of embarrassing myself, turned out I forgot to plug in the keyboard controller chip. I had it removed while I was tracing lines across the board.. Amazing that I got a boot from the Ami BIOS regardless of that chip 😅

Anyways, the board is back alive now. I also plugged in the original BIOS chips and they also work fine.. so I can confirm the dumps I got from them are good.

I'll toy around with the board a little and report with any particularities I find..

Thanks a lot Deunan for your help and guidance! I learned a lot through the process and also got a happy ending too 🤜🤛

The photo below is with the board only having a VGA card on it. I'll need to plug in an external battery, keyboard and an IO card. Hopefully everything functions fine.

We're all forgetful idiots 😉

In the late 90s, so not even in a time when I shouldn't have expected it as a matter of course, I was swapping an AT power supply and forgot to unplug it.
Came to unscrewing the power switch, and I became shockingly aware of my mistake.

Ok I spent quite a bit of time trying different BIOSes.. there were like over 40 of them! My main goal was to find the oldest BIOS that can support my CF card (256MB). In general I can say:

• Award BIOSes are generally very basic, and only support predetermined HDD types (no custom entry)
• My version of the Award BIOS (DTK) is like the above, but has a funky diagnostics set. Very cool to watch 😀
• Phoenix BIOSes are also very basic. Some of them though allow custom HDD types. However, they were still unable to recognize my CF card despite correct values. It can't boot from the CF card, but if I boot from a DOS disk, I can see drive C and browse its directories, but I can't read any of the files (it hangs)
• Ami BIOSes are a little more advanced, and generally all support custom HDD types. They suffer from the same issue above though. Can't recognize CF card after setting its type.

Finally, I came across one, and only one, Microids BIOS. This was a black sheep among the rest. It has a date of 1994, and a really unique and slick BIOS setup program. This one not only supports custom HDD types, but also my CF card worked with it very smoothly. My only gripe with this one is that it's far too new for this board, but hey... it seems it's either this, or XT-IDE.. and I'd go with this BIOS honestly.

Besides that, the system checks all good. Slow as a 12MHz 286 😀 but otherwise runs fine, and the turbo switch halves the performance down to 6MHz.. really nice for those old 80's games. Memory is also tested all good (1MB).

If you like me to run any specific tests let me know!

Cheers!

wbahnassi wrote on Yesterday, 07:44:

(...) Can't recognize CF card after setting its type.

I found that some HDD controllers work better than others. My first pick is Prime 2C, seems to work best with everything and has external RS232 port driver chips that can be replaced when damaged. A non-C Prime 2 is also very decent.

The worst in my ranking is UMC with UM82C863F+UM82C865F combo. Weird split-chip design, built-in RS232 that is partially shot now, and it only really works properly with one particular CF card from SanDisk. How come I don't know, considering that IDE interface is almost a pass-through between ISA and the device, but it just fails with all other cards.