• Please review our updated Terms and Rules here

Weird EISA issues setting HDD Type

S

Shadow Lord

Veteran Member
Joined
Jun 15, 2010
Messages
3,318
Location
California
So not very hopeful on this one but I am having a weird issue with the EISA CFG on the Compaq Portable 486c. Everything seems to be working fine. I can boot, change config, have memory automatically recognized, etc. The only thing that does not work is if I try to set a custom HDD type (i.e. using one of the programmed in HDD type seems to work fine). However, an auto detected or user specified HDD type leads to an error: A failure was detected while writing to your computers nonvolatile memory". It then refuses to save the EISA CFG info into NVRAM.

Anyone seen anything like this before?
 
Unknown_K said:
Are all the other settings saved in NVRAM when you disconnect power and power back on later?

Is there just that 1 Dallas RTC chip in there?

https://i.imgur.com/8Wk3SOl.jpg
Click to expand...

Yes. Everything else works fine. Even putting in a "known" HDD type doesn't cause the issue. It only occurs with auto detected HDD or manual specified type. It does this whether I am using a DOM or a HDD.

There is only one DS1397 chip. I have replacement DS1497 chips which are pin compatible (they just have twice the memory) which I can try in case the issue is the actual NVRAM but it may fail just because it is not DS1397 and would muddy the diagnostic process.
 
I had read that article but didn't see the part where he couldn't save the custom geometry either. His issue seems to be with the actual ECU program - which is quite daunting if you have never used one.

Because of my rebuild of the Systempro XL I have most versions of the ECUs on hand. In that article he looks like he is using Compaq ECU v. 2.26B which is interesting because that particular version does not support the Portable 486c (missing the CFG files). Someone on the forums had said they used 2.30G to get things going but that version is also lacking the CFG files. Interestingly ECU 2.40 (which is the last version to work without issues with my Systempro XL) has built in support for the Portable 486c and version 2.58A (last version of the disk based ECU) is missing it again. So somewhere between 2.30 and 2.40 support was introduced and somewhere between 2.40 and 2.58A it was removed (at least for the original 486c - the 66MHz version uses a different config file). Of course this doesn't mean you can't use those versions - you just have to supply the CFG files for the motherboard.

I was going to go down the list of ECUs (well do a binary search) and see what was the last version of the ECU that included the CFG files for the system (and I may still do it). However, I was able to resolve the problem rather easily. I installed the DOM and let the system auto-configure everything (including the HDD) but before saving the config I changed the HDD type to one that was very close to my DOM in size. Without using a user defined type I was able to save and update the NVRAM and get the system up and running.

In case anyone is curious I am using a pqi industrial DOM model DJ0020G22RP0. I have set the ECU to HDD Type 74. When compared to the auto configured value this is what it looks like:


[table="width: 500"]
[tr]
[td][/td]
[td]Size[/td]
[td]Cylinder[/td]
[td]Head[/td]
[td]Sector[/td]
[/tr]
[tr]
[td]Type 74:[/td]
[td]2037.5MB[/td]
[td]987[/td]
[td]64[/td]
[td]63[/td]
[/tr]
[tr]
[td]Actual:[/td]
[td]2048MB[/td]
[td]4063[/td]
[td]16[/td]
[td]63[/td]
[/tr]
[/table]

The sizes are very similar and all the read/write/seek tests I have run have not produced any issues. I think the failure detected in writing has nothing to do with the actual SRAM chip but field sizes. The auto detected cylinder count requires a four digit field and my guess is the NVRAM DB is hard coded for maximum three digit size field. So when an attempt is made to write a four digit value the write fails and hence the error.

This work around created two issues (one of which I resolved):

1. Initially my DOM had been partitioned and formatted on another system (I had done quick testing on it in Win 7 to make sure the HW was good in case a return was needed). When I first rebooted the ECU threw up an error indicating the partition on the drive did not match the one in the ECU as such it would not let me install the ECU and diagnostic utilities on the HDD in a hidden partition (to avoid data corruption). A quick FDISK to get rid of the existing partition and the ECU had no issues with installing the hidden partition. I was then able to partition the rest of the drive and install MS-DOS 6.22.

2. In case you are wondering even with the DOM partitioned as a Type 74 drive the ECU continues to detect the built in geometry as listed above. Therefore, every time a HW change is made the ECU tried to create a custom type entry which then leads to NVRAM write errors. As such you have to manually change the drive type, with each HW config change, back to type 74 before saving your changes.

Now if I could only find that pesky pot for the screen brightness and this system would be all set...
 
Last edited:
You must log in or register to reply here.
Back
Top