Greetings:
Some DiskOnChip architectural and installation questions:
I purchased a DoC2000 96MB high-profile DIP from a third party; it is installed in a PC-104 Aaeon SSD-2000 module. The Aaeon board has very little documentation and what there is seems to differ from reality, for example selecting DoC #1's 8k address window as D000 using the DIP switch results in data appearing at D200 and it seems that after power-on-reset, the user must write to the board's I/O base register to select one of 16 64k windows (used with SRAM, but seemingly necessary for DoC also) or invalid data appears in the 8k window. Using msdos 'debug', one can write 'FF' to the I/O base register and a valid '55 AA' signature appears at 'D200:0'. If one reboots the CPU at this point, the BIOS scan finds the 'ROM' code but hangs since it isn't a legitimate boot loader from my inspection of the disassembly.
Inspection of the entire 8k window confirms a working DoC device according to the M-Systems specs; there is a repeating 64 byte (1st half) boot record for the first
2k followed by a repeating 64 byte (2nd half) boot record for the next 2k followed by all zeros for the next 4k assuming the device is in 'reset mode'.Running 'dinfo.exe' against this system (when '55 AA' is readable at the start of the window) shows 'no DiskOnChip devices found'. Note that there are no identification strings of any kind in the boot (IPL) records on this device.
Running 'dformat.exe' against this system produces the same error message.
What conditions are necessary for the utilities to recognize a valid DoC device?
How can one replace the IPL code when the device is not recognized by the utilities? Writing to the IPL area is discussed in the DoC SDK API documentation for low-level services; I don't have the SDK, (would like to find it) and hope that sinking time into custom development isn't necessary just to reprogram a device.
I would appreciate replies from anyone with DoC experience; surely this must have happened to other folks.
TIA,
Michael