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:
| Size | Cylinder | Head | Sector |
| Type 74: | 2037.5MB | 987 | 64 | 63 |
| Actual: | 2048MB | 4063 | 16 | 63 |
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...
