O.K. I was able to get a DOM installed and working on my Compaq Portable 486c:
Because of my rebuild of the Systempro XL I have most versions of the ECUs on hand. Someone on the forums had said they used 2.30G to get things going but that version is lacks the CFG files for the Portable. 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 of the ECU - you just have to supply the CFG files for the motherboard.I am running 2.58A myself on the Portable. 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 HDD problem rather easily.
I believe the issue with the CF vs. HDD has to do with consumer CF cards reporting themselves as "removable" and using an industrial CF card should resolve that issue. To get around this I installed an industrial DOM in the system let the system auto-configure everything (including the DOM which it auto detected/configuered). However, this caused the same issue as the HDD (i.e. a failure to write to NVRAM when I tried to save the EISA config). To get around this 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. If I get the chance I will verify that the same issue existed with the 4GB IDE HDD I tried installing initially as well.
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...
