I think a good way to go would be to desolder the bios chip and use an external programer to reflash the factory bios. But instead of just reinstalling the chip use a socket that way you can easily pull the chip and try different bioses untill you get one that works to your satisfaction.

Have you tried tapping CTRL+A while system boots during the AIC-6370 and into the AIC7880 ? it should get you into the 7880 bios part hopefully so you can disable it.

I have tried CTRL-A and a lot of other CTRL- combinations, at both the AIC-6370 and at the AIC-7880 BIOSes. I am letting it sit for up to 2 hours as recommended while turned on. It has just a terminated cable attached now.

Deunan, yes I have PCI and ISA cards which normally use a W27E257 flashable 32 Kbyte ROM chips. I have two external programmers with a dozen or more solder mount adapters as well.

chrismeyer6 wrote on 2020-01-22, 14:32:

I think a good way to go would be to desolder the bios chip and use an external programer to reflash the factory bios. But instead of just reinstalling the chip use a socket that way you can easily pull the chip and try different bioses untill you get one that works to your satisfaction.

But part of the BIOS is compressed according to SSTV2. Will this method still work? I can do this, but it has its own risk. I could break traces or EEPROM pins. To get it back on, I'd probably have to remove some EISA or PCI slots due to its location. It could look messy when I'm finished. I've done this on a Pentium Pro board, but the EEPROM was in a wide open area. I damaged one trace that needed a wire route to fix. Basically, I'd like to leave this as a last resort. Depending on cost, I'd probably rather buy another bare motherboard and see if I can disable the SCSI via the EISA config, then move the RTC over to the afflicted board and hope the SCSI is still disabled.

chrismeyer6 wrote on 2020-01-22, 14:32:

But instead of just reinstalling the chip use a socket that way you can easily pull the chip and try different bioses.

Usually for a removable chip in this package, there needs to be a housing and a type of clamp to put pressure on the pins to make contact. This takes up considerable space and probably will not fit in its present location. But if you have a link to such a socket, send me the specs and I can take some measurements.

Am back in town till tomorrow. Let me mess with my spare boards parts, I might be able to air-mail you it's RTC after disabling the SCSI controllers on my working machine with it installed. Would probably take a few days for mail from Oregon (am right near the main airport here) it would not be like shipping a motherboard standard mail.

WOW well thanks for messing your board up (not really but it created a discovery!), discovered my spare boards RTC battery is dead and why the spare acted up then wouldn't POST. Same happened when I swapped spare RTC into working board. Swapped good RTC from working board into spare and it booted right up. I have a IBM NetVista that does same thing: if coin battery is dead it does not boot at all, no low bat warning or anything, just acts dead. Will do a battery mod in a few minutes to the dead DS1587 and see if it can be revivied. If so can mail you the working one free for helping me figure out the spare board. Will need it back though as you cannot buy 1587 anymore and no direct replacements I could find anywhere yet.

I was going to mention that the issue with your problematic board might be due to the RTC's failing battery, but figured you knew this already. It is pretty common for boards to not work or boot up properly when the RTC battery is dead or dying.

Looking forward to your test results with the RTC swap. I'm not sure if it is too far gone for my board though, as I've already enabled "reset configuration data". But since the board doesn't pass POST, the option never changes from "Yes" to "No". I've put it back to "No" but hopefully there isn't a lingering "Yes" in que which will clear out your RTC's NVRAM.

Yeah, I can ship the RTC back no problem. Should be a relatively quick process.

EDIT: Its been 2 hours and the computer is still hung at the Asus BIOS

Thanks, just haven't had time to diagnose it, one of those things when you have a good board, a quirky spare and not much free time. Yes got the RTC working, did a frankenstein quick fix on it. Will put a proper coin cell holder on it when I have time. Maybe your RTC batt is also failing, had some very odd quirks happening over the days just before total non-boot, could be coincidence with also doing the rom flash.

Ok got the rtc on the board with same x014 bios to disable the 7880 w/o issue using the x014 SCU and saved to cmos. Do not know how good the batt in this one is, tried to check using the VBaux pin to GND and got no volts (probably has a diode to protect or maybe internal BAT gnd does not go to real GND) , only way to truly check would to be a bit of grinding to expose internals. PM me your address and will mail it (the non-franken one 🤣).

On board A, you have the AIC-7880 enabled. On board B, you have disabled the AIC-7880 with the EISA config util. Then you put the RTC from board B into board A and the AIC-7880 was still disabled on board A?

My RTC was working just fine for the 2.5 weeks I've been testing it. I don't think its battery level is due to the recent failures.

feipoa wrote on 2020-01-22, 11:03:

I've waited several minutes, but it doesn't find a hard drive. I've tried disconnecting the hard drive, but it still hangs here. The problem now is that I cannot boot from a floppy disk to get the original v14 BIOS back on because the system must pass up the AIC-7880 firmware before it will boot from a floppy diskette. And the only way to disable the AIC-7880 is by using the EISA Configuration Utility, which must be access via floppy disk.

Sorry to hear about the bad news. I wonder what causes the freeze, could it be some sort of controller/BIOS incompatibility or wrong settings in EISA config. util. for the new option ROM?

If EISA util. actually alters CMOS memory, you can try resetting CMOS settings by shorting RTC's battery for a few moments, it should clear all of the config. bytes responsible for SCSI controller's initialization.

You can also try rewriting CMOS data with the CMOS dump, in which 7880 would be disabled. For that you'd need an external programmer, compatible with your RTC or a motherboard.

On other motherboards, which have a BIOS recovery jumper, do you know what the jumper is triggering? Perhaps I should try to trace this out on the Pentium Pro board? Does the jumper disconnect address A0 as you alluded to in PM? It would be pretty difficult to disconnect just one of the EEPROM pins.

SSTV2 wrote on 2020-01-23, 14:35:

Sorry to hear about the bad news. I wonder what causes the freeze, could it be some sort of controller/BIOS incompatibility or wrong settings in EISA config. util. for the new option ROM?

Could be. I've set the onboard SCSI AIC-7880 to IRQ 15. Perhaps the Asus BIOS doesn't get along with this because it has IDE's on IRQ 15? This board only has a primary IDE port, so IRQ 15 is free.

SSTV2 wrote on 2020-01-23, 14:35:

If EISA util. actually alters CMOS memory, you can try resetting CMOS settings by shorting RTC's battery for a few moments, it should clear all of the config. bytes responsible for SCSI controller's initialization.

I have tried setting the CMOS clear jumper on the motherboard, but didn't help. Normally the battery terminal on RTC module's isn't accessible, but this DS1587 unit appears to have a Vbat pin which is identified as "Battery + supply". Should I short Vbat and GND while the RTC is in board or out of board? I assume out of board might be safer. Any chance this will kill the RTC module?

SSTV2 wrote on 2020-01-23, 14:35:

You can also try rewriting CMOS data with the CMOS dump, in which 7880 would be disabled. For that you'd need an external programmer, compatible with your RTC or a motherboard.

I will check the software of my two IC programmers to see if they support the DS1587. EDIT: Neither of my programmers support the DS1587 or DS1585.

EDIT: "The Vbat pin is not present on the DS1587 as the battery supply is contained within the package" OK, so I would have to grind away some plastic to access the battery pins. Horun, per SSTV2's suggestion, are you able to try shorting the battery to GND pin for a few seconds to see if the SCSI ports are disabled upon reboot?

feipoa wrote on 2020-01-23, 21:44:

On other motherboards, which have a BIOS recovery jumper, do you know what the jumper is triggering? Perhaps I should try to trace this out on the Pentium Pro board? Does the jumper disconnect address A0 as you alluded to in PM? It would be pretty difficult to disconnect just one of the EEPROM pins.

No idea, but it definitely doesn't disconnect pins that are essential for successful image flashing. I don't have any vintage intel chipset based MBs that would have recovery jumper on them, so I can't even check how that works, I only have intel motherboards based on S478 or LGA775 with recovery jumpers. I'll check them instead.

feipoa wrote on 2020-01-23, 21:44:

I have tried setting the CMOS clear jumper on the motherboard, but didn't help. Normally the battery terminal on RTC module's isn't accessible, but this DS1587 unit appears to have a Vbat pin which is identified as "Battery + supply". Should I short Vbat and GND while the RTC is in board or out of board? I assume out of board might be safer. Any chance this will kill the RTC module?

Unlike typical DS1287, your RTC appears to have /RCLR pin, which clears CMOS memory, you don't need to short anything now, as you had cleared CMOS on MB. If you got the "CMOS checksum error" message after shorting that jumper, you can be sure that CMOS was cleared.

@feipoa, not sure it would help much with your current issues, but did you try their 'Resetting the NVRAM and CMOS' procedures

- Power off the system and disconnect the system from the AC source.

- Set system board jumper CMOS CLEAR to pins 2-3.

- Reconnect AC power and power on the system. The CMOS NVRAM will automatically reset to the default settings.

- When the POST (power-on self-tests) complete, power off the system and disconnect the AC power source.

- Restore system board jumper CMOS CLEAR to its original setting (1-2).

- Run the SCU to configure the system.

Found one S5 intel motherboard with recovery jumper on it. The recovery mode is invoked by connecting address 16 line directly to the Flash ROM (MB used to have i28F001 IC), in normal mode address 16 line is inverted by 74HCT14 hex inverter (pin 9in, pin8 out). Check how 3 highest address lines are wired on your 28F004 Flash ROM, are you sure that there is no other way of initializing recovery on that MB? It would be odd, if a professional motherboard, that has a soldered Flash ROM with protected boot block, would leave users without means of BIOS recovery.

PC Hoarder Patrol: I did not try that exact procedure, but I can. Even if the NVRAM is cleared, I suspect the onboard SCSI will still be enabled. The AIC-7880 SCSI must be disabled or the system will not boot from a floppy drive.

EDIT: Checksum bad - Run Setup - check!
EDIT: EISA Configuration NVRam Bad - Run Configuration Utility - check!
EDIT: As expected, the system still wants to run through the AIC-7880 BIOS, which it cannot, so no booting from floppies. You'd think as a safegaurd, the SCSI's would be disabled by default if NVRam is Bad. But no.

SSTV2: I didn't quite follow. ON the socket 5 board you found, the recovery mode jumper a) disconnects the EEPROM's address line A16 from a HEX inverter and, b) connects EEPROM's address line A16 to what? In your statement "what" from my question equates to "Flash ROM". Meaning EEPROM address line A16 connects to itself in recovery mode? Thus it is disconnected from the rest of the motherboard?

I'll need to pull the motherboard and PSU out of the case to properly properly inspect the board jumpers and traces. There are several "reserved" jumpers. With any luck one of them connects to A18 of the TSOP-40 EEPROM.

I can confirm that if the entire CMOS in the RTC (both regular CMOS and the EISA config part) are cleared that the on-board devices are auto enabled (the Cirrus VGA, the 6370 SCSI and 7880 SCSI) most likely due to they are "Embedded" as the EISA config states (op-roms in main rom).

feipoa wrote on 2020-01-23, 05:43:

On board A, you have the AIC-7880 enabled. On board B, you have disabled the AIC-7880 with the EISA config util. Then you put the RTC from board B into board A and the AIC-7880 was still disabled on board A?

My RTC was working just fine for the 2.5 weeks I've been testing it. I don't think its battery level is due to the recent failures.

My RTC in spare worked fine for a few weeks too, only when I started messing with it more did the battery give up.
Yes if I move the RTC with 7880 disabled to other board the 7880 is still disabled. See pic attached, note the BIOS is x08 not x14 of spare. Hitting F1 and it boots to floppy (if bootable floppy is in) and from there you can flash EPROM if needed.

I'll need to pull the motherboard and PSU out of the case to properly properly inspect the board jumpers and traces. There are several "reserved" jumpers. With any luck one of them connects to A18 of the TSOP-40 EEPROM.

Already went thru all the reserve jumpers, all it did was move addresses on some onboard stuff and did not disable anything on my spare board. The one related to the 7880 is J7A, though maybe you will have better luck.

I have a Asus P2B-S with onboard SCSI and it has a jumper to disable but is also a 7890 chip not 7880 chip, without proper datasheets am not going to risk messing up the NEC by shorting whatever pin the P2B-S jumper does. Also the 7890 is a Ball Grid IC not a SMC so impossible to compare....

I pulled the MB and PSU from the case and started probing.

Measured from the 28F004 EEPROM:
A18 - goes to a pin on the EISA slot and to a pin on the AIC-6370Q
A17 - don't know. I didn't see a trace leave the solder pad
A16 - goes to pin 2 of the J7A jumper

J7A is a reserved jumper and is "factory set" for pins 2-3. So I set J7A to pins 1-2 and powered up the system. The screen stays blank. That is usually a good sign if it is the recovery mode jumper. But I waited 5 minutes and there never was any floppy activity. To ensure I have the floppy drive connected properly, I have "floppy seek" enabled in the BIOS, and it does seek when J7A is set to its factory default position.

I then decided to run through the reserve jumpers, namely J7A, J7B, J5A, J4B, J3A, and J106. I first tried each jumper position with J7A in its factory default position, hoping that one of these jumpers would disable the AIC-7880, but they did not. Each jumper position set contrary to its factory default position allowed the system to boot as expected, except for J7A, for which the screen stays blank.

I then tried setting J7A to the opposite of its factory default position and ran through the reserved jumpers one by one, hoping that some pairing of J7A and another would commence recovery mode, but they did not. I then set all the reserved jumpers to the contrary of their factory default, all at once, but still recovery mode did not commence.

I don't know what to try now, but I am enclosing a photo of the Proserva motherboard, the highest resolution I can get away with on Vogons (2 MB). Maybe it will give someone some ideas.

Next I discovered that if you repeatedly press Ctrl-A just before and after the Asus AIC-7880 BIOS appears, it will enter the SCSI BIOS. For whatever reason the Adaptec host ID is set to ID 15, which seems odd as this is normally set to ID 7.

Unfortunately, none of the settings I alter in the SCSI BIOS get saved. I attempted to input ID7 and to DISABLE Host Adapter BIOS, but nothing gets saved, even though I exit properly and confirm YES to save settings. I've tried hitting CTRL-ALT-DEL at this point and also fully exiting the SCSI BIOS such that pressing a key reboots, but in both cases the settings are not saved and I'm faced with a hung Asus SCSI BIOS upon reboot.

EDIT: Forgot to mention that I also tried a network card with a working boot ROM, the 3c905C-TX-M. I enabled it on another computer and confirm that the other computers tries to boot from the boot ROM. I then put the 3c905C-TX-M into the Proserva and enabled "Execute User ROMs". Unfortunately the Proserva wants to go through the AIC-7880 BIOS before it will attempt to load the boot ROM on the network card.

Found a source for the RTC but is the DS1585 (same as 1587, except no battery or 32.768kHz XTAL) and can easily be fitted with both. Am ordering a few as a precaution to a future failed internal cmos section.

Sounds like a good idea. What's the source?

https://www.questcomp.com/part/4/ds1585s/177339189 for the sop versions, they are out of the DIP28's. Would require soldering to a socket adapter plus adding the 32.768khz xtal and battery. Minimum order $25 plus shipping. Needed some 12887A too so ordered those and a few 1585s and can solder so not a big issue.