Texas Wanted: BIOS EEPROM Flashing

[Pickelhaube808]

I recently picked up a Chaintech 486SOM board that after having a capacitor blow, now needs a new BIOS chip as I am getting this following error:

Award BootBlock Bios v1.0
Copyright (c) 1995, Award Software, Inc.

BIOS ROM checksum error

Detecting floppy drive A media...
INSERT SYSTEM DISK AND PRESS ENTER

(I have tried many system disks and that does not fix the issue )

As such, I am requesting the service of someone who has a compatible EEPROM programmer (and ideally the same 32-pin chip). I am not familiar how flashing works, so I am not sure if you can put both the 486 BIOS and the Award BootBlock on as a fallback like how the original chip has it. Worst case, assuming it still works without bootblock, a chip with only the supplied 486 bios would suffice. Should you have a compatible programmer but lack the correct EEPROM, I have ordered a few that should arrive soon and can mail them to you should you be comfortable with that.

The chip in question:

SST PH29EE010-150-3CF

Here are pictures I took while I was scraping the stickers off:






Here is the BIOS file. I am not sure where I would find the Award BootBlock BIOS, if that is even available in ROM form. Please let me know if there is any other information I need to provide.

 

[GiGaBiTe]

The bootblock is usually included in the ROM image, but isn't flashed unless the user tells the award programming software to do so.

I have a XGECU T48 programmer that has a profile for this chip. If you don't mind driving up to Austin, I can give it a go programming your EEPROM. You'll want to bring your machine so it can be tested after flashing it.

 

[Pickelhaube808]

The bootblock is usually included in the ROM image, but isn't flashed unless the user tells the award programming software to do so.

I have a XGECU T48 programmer that has a profile for this chip. If you don't mind driving up to Austin, I can give it a go programming your EEPROM. You'll want to bring your machine so it can be tested after flashing it.

I appreciate the offer, but for the cost in gas and having to spend half my weekend driving up there and back, it may make more sense for me to just buy that programmer (the T48 TL866-3G?) and flash the chip at home.

 

[modem7]

As such, I am requesting the service of someone who has a compatible EEPROM programmer (and ideally the same 32-pin chip).

Possibilities:
www.eprompro.com (Canada)
www.arcadecomponents.com (Texas)

 

[GiGaBiTe]

I appreciate the offer, but for the cost in gas and having to spend half my weekend driving up there and back, it may make more sense for me to just buy that programmer (the T48 TL866-3G?) and flash the chip at home.

Round trip from here to north SA and back is about 140 miles and 3 or so hours of driving. Even with my huge gas guzzling work van that gets 16 MPG, it only costs about $23.19 in fuel. The T48 programmer is $80-90ish once you put in taxes and shipping lol.

 

[Pickelhaube808]

Round trip from here to north SA and back is about 140 miles and 3 or so hours of driving. Even with my huge gas guzzling work van that gets 16 MPG, it only costs about $23.19 in fuel. The T48 programmer is $80-90ish once you put in taxes and shipping lol.

Not driving on I-35 again if my life depended on it. Felt like the most dangerous road with the dumbest people on it. Made the mistake of taking it to go pick up a 5153 monitor a few months back. 281 would bring it closer to 200mi round trip for me at about 14mpg. Thanks, but I bought the programmer as it can get to me quicker and only cost about $70 total. I also have other chips I will probably need to use this on in the future.

 

[Bruce Tomlin]

Windcrest area, I can do the burn, no problem, just not this weekend. All I need is the image file.

 

[GiGaBiTe]

Not driving on I-35 again if my life depended on it. Felt like the most dangerous road with the dumbest people on it. Made the mistake of taking it to go pick up a 5153 monitor a few months back. 281 would bring it closer to 200mi round trip for me at about 14mpg. Thanks, but I bought the programmer as it can get to me quicker and only cost about $70 total. I also have other chips I will probably need to use this on in the future.

I've driven IH-35 from end to end in Texas, Oklahoma and partly through Kansas. The only places where it is bad (in Texas) is in Dallas, Austin and San Antonio around the core of the city where over 9000 roads somehow manage to all intersect each other in the same place.

Not sure I'd pick 281 with the dumpster fire of construction between 1604 and Bulverde that's been going on for 10+ years. You'll spend more time sitting at stop lights in gridlock than driving from 1604 to New Braunfels on 35. You'd spend less time going out I-90 to Seguin and cutting up 123, or going out I-10 and cutting over on 46 than going up that stretch of 281, if you want to avoid 35 entirely. Or just take I-90 to the 130 toll, which will get you most anywhere up to Georgetown. Just be prepared to pay, because the 130 toll from 90 to Creedmoor is privately owned, and hideously expensive. Each toll scan will cost between $9-15. I made the mistake of taking it once and my boss yelled at me for a $50+ toll bill.

As for 35 being one of the worst roads, LOL. You should try driving in Houston, Edinburg, Dallas or Arlington. There are far worse places than IH-35. My last trip to Edinburg, people were so crazy that they were driving in emergency lanes and on sidewalks like they were normal road lanes. Traffic lights and stop signs? Those are only suggestions.

Anyway, good luck with your programmer. If you got the TL48, it's fairly easy to get going in Windows. If you need to use any of the special adapters, double and triple check you're using the correct adapter, and that it's in the correct orientation. There are some adapters that look like duplicates, but are for different voltages and have pins moved around. Mine weren't really labeled well and are hard to tell which one you actually need.

The DIP chips obviously don't need adapters, just to be put in the correct orientation and correct pins. If you search for "29010", it should bring up the correct part.

 

[LiqMatrix]

Dallas has some seriously narrow (hair raising) lanes on parts of their interstate sections. Last time I drove through that city I swear my side view mirror was almost scraping up against the car passing me by at 1000MPH.

 

[GiGaBiTe]

Dallas has some seriously narrow (hair raising) lanes on parts of their interstate sections. Last time I drove through that city I swear my side view mirror was almost scraping up against the car passing me by at 1000MPH.

Don't forget the left exits, that aren't marked. You're expected to know where they are.

 

[rlerner]

Nah driving in Dallas is completely safe and sane and not at all dangerous.

Spoiler: Actually...

It's terrifying

BTW I'd drive to Austin for some EEPROM flashing just to get the knowledge, but I don't have anything that needs flashing at the moment 🤷‍♂️

 

[Pickelhaube808]

Got the T48 in and will try flashing the bios tonight... Hopefully it goes smoothly and nothing else is wrong with the board after the flash. Recapped a few mid-late 90s PCI and ISA cards for the build last night (made sense as some caps were dented and some were falling close to the capacitor plague era) so I replaced a few caps on the mobo too, especially the only electrolytic which was inline for the CPU power delivery. Not that I'll be trying to break any overclocking world records with this 486 though.

 

[Pickelhaube808]

Hmm... so here's what I feared -

I read the EEPROM and saved what it spat out. Comparing what I got off the chip and the new BIOS bin shows that there are no differences, and I am still getting the BIOS checksum error with the reflashed chip. Could I have a dead BIOS chip? Could this BIOS just be an incompatible revision for this board?

 

[Pickelhaube808]

I am at least confident that it is actually flashing...

 

[GiGaBiTe]

Hmm... so here's what I feared -

I read the EEPROM and saved what it spat out. Comparing what I got off the chip and the new BIOS bin shows that there are no differences, and I am still getting the BIOS checksum error with the reflashed chip. Could I have a dead BIOS chip? Could this BIOS just be an incompatible revision for this board?

If the image you dumped from the EEPROM matches a known good BIOS image, then the EEPROM is probably fine.

How are you checking the differences between dumped vs. good image? I'd recommend using a hex editor that can compare binary files, rather than the programmer's built in checksum function.

You may also want to put deoxit gold in the EEPROM socket to make sure the pins are making good contact.

Since you have a programmer now, you might try finding another similar 486 motherboard with the same chipset and flashing that to see if anything changes. I've had to do that with some boards where the original BIOS was so broken that the board didn't work with it.

 

[Pickelhaube808]

If the image you dumped from the EEPROM matches a known good BIOS image, then the EEPROM is probably fine.

How are you checking the differences between dumped vs. good image? I'd recommend using a hex editor that can compare binary files, rather than the programmer's built in checksum function.

You may also want to put deoxit gold in the EEPROM socket to make sure the pins are making good contact.

Since you have a programmer now, you might try finding another similar 486 motherboard with the same chipset and flashing that to see if anything changes. I've had to do that with some boards where the original BIOS was so broken that the board didn't work with it.

I was comparing both BINs in Notepad++ using the compare plugin, where both came out identically.

The weird thing in the new and old BIOS roms is that there is this giant empty section in the middle consisting of FFs repeated for like 1/3rd of the entire rom. I feel like it should be populated with the actual BIOS screens but it is just... nothing. I was able to take other data and fill this blank area with it, but it wouldn't do anything on boot.

Since this board is 486SOM, I also flashed bioses from 486SPM and 486SPI, both POSTing to the exact same error screen.

I also noticed that removing the keyboard controller chip (AMIKEY 2) stops the board from POSTing. This chip may also be the problem, but there is no data out there on what it does and replacements could not be found...

Before you sent this, I did manage to find a similar board in terms of features. It was the only decent board that could get to me in a reasonable amount of time and is compatible with all of my stuff, I just hope it actually works- a Gigabyte GA-5486AL.

 

[GiGaBiTe]

BIOS images are usually smaller than the EEPROM they're contained in. Finding large chunks of empty space is normal. You don't want to fill the empty space with random code that you don't know anything about, because the BIOS may use this empty space to store variables. If the BIOS code encounters nonsense when it's looking for nothing may cause erratic behavior, like sending the stack pointer off into lala land and cause the system to crash. BIOS images are also often compressed, so the data you're looking at might just be the compressed image.

Removing the keyboard controller will cause the system to hang because the keyboard controller does more than control the keyboard. It's a full Intel 804x/805x microcontroller with its own ROM. It's other purpose is to control the CPU's A20 address line, which is used for backwards compatibility with the 8088/8086 memory map. The 8088/8086 only had 20 address lines (A0-A19), which allowed them to address a total of 1 MB of RAM. A quirk of the CPU was trying to access memory segments above 1 MB would cause the address to wrap around to the bottom of the memory map. On 286 and higher CPUs that had more than 20 address lines, address line A20 was used as a toggle to keep backwards compatibility with older software in 808x mode that relied on the old method of memory access.

Intel moved the A20 gate functionality into the 486, but motherboards with 804x/805x keyboard controllers may still have this functionality out on the motherboard. Likely because many 486 board designs have direct lineage to 386 motherboard designs, or things that carried over since the architecture wasn't that much different.

If the board still isn't booting with known good ROM images, I'm starting to think there's a bad component on the motherboard. I'd recommend pulling all of the cache chips if present, there should be nine of them next to the CPU socket all lined up in a row. You'll have eight cache chips and one TAG chip, make sure you don't get them mixed up. They should have different part numbers on them.

I'd also pull the RAM and test it on another system using Memtest if possible. Beyond that, I'd recommend a POST code card, either ISA or PCI to read potential codes on the system bus. You may also want to use a multimeter to test those black resistor packs next to the CPU socket, they have a habit of going bad.

If you have another 486, I would try that as well. It's not unheard of for a 486 to have bad L1 cache, or just bad from age. If that CPU has been abused with excessive voltage or heat for any portion of its life, it could be on its way out.

 

[Pickelhaube808]

BIOS images are usually smaller than the EEPROM they're contained in. Finding large chunks of empty space is normal. You don't want to fill the empty space with random code that you don't know anything about, because the BIOS may use this empty space to store variables. If the BIOS code encounters nonsense when it's looking for nothing may cause erratic behavior, like sending the stack pointer off into lala land and cause the system to crash. BIOS images are also often compressed, so the data you're looking at might just be the compressed image.

Good to know. Is there a way to decompress the BIOS file to poke around at the contents? Not that it matters, just something to do while bored. I do however see full ASCII text contained in it, so either part or all of it is not compressed.

Removing the keyboard controller will cause the system to hang because the keyboard controller does more than control the keyboard. It's a full Intel 804x/805x microcontroller with its own ROM. It's other purpose is to control the CPU's A20 address line, which is used for backwards compatibility with the 8088/8086 memory map. The 8088/8086 only had 20 address lines (A0-A19), which allowed them to address a total of 1 MB of RAM. A quirk of the CPU was trying to access memory segments above 1 MB would cause the address to wrap around to the bottom of the memory map. On 286 and higher CPUs that had more than 20 address lines, address line A20 was used as a toggle to keep backwards compatibility with older software in 808x mode that relied on the old method of memory access.

Interesting. I was wondering why a chip responsible for the keyboard was so massive.

If the board still isn't booting with known good ROM images, I'm starting to think there's a bad component on the motherboard. I'd recommend pulling all of the cache chips if present, there should be nine of them next to the CPU socket all lined up in a row. You'll have eight cache chips and one TAG chip, make sure you don't get them mixed up. They should have different part numbers on them.

Uhh... I may have taken them out and mixed them up before reinstalling them while troubleshooting the first time LOL! So the TAG chip is structured differently from the rest of the flash chips and cannot be mixed in?

I'd also pull the RAM and test it on another system using Memtest if possible. Beyond that, I'd recommend a POST code card, either ISA or PCI to read potential codes on the system bus.

I do have a post card, and it kept hanging on a code that implied floppy drive access. This would always happen on it trying to load a system disk and failing.

You may also want to use a multimeter to test those black resistor packs next to the CPU socket, they have a habit of going bad.

I do have a multimeter and can test them, but how would I know what values it is supposed to show? I am guessing they have part codes on the side that I can look up, I have just never taken a look at them up closely before.

If you have another 486, I would try that as well. It's not unheard of for a 486 to have bad L1 cache, or just bad from age. If that CPU has been abused with excessive voltage or heat for any portion of its life, it could be on its way out.

This I will do if I can find another cheap chip for testing. If it's just a bad DX4, I'll have to wait and see if I can get one for a good price soon.

 

[GiGaBiTe]

Good to know. Is there a way to decompress the BIOS file to poke around at the contents? Not that it matters, just something to do while bored. I do however see full ASCII text contained in it, so either part or all of it is not compressed.

Each BIOS vendor (Award, AMI, Phoenix, Insyde, etc.) has their own proprietary methods of data compression. There are some tools out there to decompress BIOS images, but it's YMMV if it will work or not. The BIOS image can have both raw and compressed data mixed, depending on the module in the BIOS. There's a website called bios-mods.com which has some tools available, but there's no guarantee they'll work on your specific BIOS version.

Uhh... I may have taken them out and mixed them up before reinstalling them while troubleshooting the first time LOL! So the TAG chip is structured differently from the rest of the flash chips and cannot be mixed in?

TAG SRAM is used to store the cache lookup table. It has extra circuitry inside it for decoding memory addresses for data inside the L2 cache on the motherboard so that the CPU knows where the data it needs to fetch is.

When you look at the nine memory chips, there should be one chip that has a different part number than the rest, which would be the TAG chip. If all nine memory chips are the same, then someone before you didn't install a TAG chip, or the motherboard has the decoding circuitry on the logic board and is using one of the chips to store the lookup table. Though, that chip should still be smaller in capacity because the lookup table takes considerably less room than cached data does. Try seeing if all of the chips have the same part number.

While this isn't the same board, it has a similar layout. You can see the TAG socket closest to the CPU.

486SPM Motherboard Settings and Configuration

486SPM motherboard and socket layout, connections, user configurable settings, DRAM configuration, Jumper configuration, floppy drive configuration

stason.org

I had an older 386 board that someone had put TAG SRAM into a normal SRAM socket and it caused all matters of erratic problems. The board wouldn't boot, or it would randomly hang and otherwise be super unstable.

I do have a post card, and it kept hanging on a code that implied floppy drive access. This would always happen on it trying to load a system disk and failing.

Hanging on floppy drive access would make sense, because the Boot Block recovery tries to read the floppy to recover itself. It's looking for a bootable DOS disk with an autoexec.bat to launch awdflash.exe and whatever BIOS image goes with the board in question.

Flashing AWARD BIOS's

I do have a multimeter and can test them, but how would I know what values it is supposed to show? I am guessing they have part codes on the side that I can look up, I have just never taken a look at them up closely before.

Here's a video on how to measure a resistor pack/network.

This I will do if I can find another cheap chip for testing. If it's just a bad DX4, I'll have to wait and see if I can get one for a good price soon.

I have some 486/586 chips if you want one for testing.

 

[Pickelhaube808]

Each BIOS vendor (Award, AMI, Phoenix, Insyde, etc.) has their own proprietary methods of data compression. There are some tools out there to decompress BIOS images, but it's YMMV if it will work or not. The BIOS image can have both raw and compressed data mixed, depending on the module in the BIOS. There's a website called bios-mods.com which has some tools available, but there's no guarantee they'll work on your specific BIOS version.

Thanks, will have to check the site out.

TAG SRAM is used to store the cache lookup table. It has extra circuitry inside it for decoding memory addresses for data inside the L2 cache on the motherboard so that the CPU knows where the data it needs to fetch is.

When you look at the nine memory chips, there should be one chip that has a different part number than the rest, which would be the TAG chip. If all nine memory chips are the same, then someone before you didn't install a TAG chip, or the motherboard has the decoding circuitry on the logic board and is using one of the chips to store the lookup table. Though, that chip should still be smaller in capacity because the lookup table takes considerably less room than cached data does. Try seeing if all of the chips have the same part number.

Yep! All have the same part number. Person before me didn't install a TAG chip - the retroweb page for it shows the exact board i bought (whoever made the page pulled the photos from the ebay listing). As you can see, they are all the same EtronTech chips with the same part number. The cache SIZES seem to be configured properly (see the 256k section on the image below), but the "TAG chip" is not a TAG chip. Is there a good method for sourcing a TAG chip? I'm looking at pictures of other 486 boards like the 486SPM and seeing if they have different chips, which some do, but the only source of them would probably be fakes from China.

While this isn't the same board, it has a similar layout. You can see the TAG socket closest to the CPU.

Here's my board, and yeah, it has the TAG chip slot too.

I have some 486/586 chips if you want one for testing.

Thanks, I may have to ask should this new board coming in also run into some fun problems too...



At least the new board looks to have a TAG chip and a few socketed resistor packs!