Re: CBM900 hard disk timeout

Hello!

Michał Pleban wrote:

> That condition basically means that the controller did not respond with
> a status code at all. So it would rather mean timeout in communication
> with the controller, not timeout in reading from disk. If the controller
> wasn't able to communicate with the disk, it would show some SASI-like
> error code from the controller.

Bad news: I damaged the controller :-(

Good news: I am pretty sure now that the controller is the source of all
the problems.

Here's what happened. I reverse-engineered the BIOS startup code, which
performs these steps:

1. Suppress some error messages.
2. Read sector from floppy (command 08).
3. Set hard disk geometry (command 0C).
4. Read sector from hard disk (command 08).
5. Enable error messages.
6. Set hard disk geometry (command 0C).
7. Read sector from hard disk (command 08).

Step 1. disables displaying the "Timeout" message, as well as certain
errors on read sector, namely 0x84, 0x92 and 0x94. These are most
probably SASI error codes OR'ed with 0x80 (for exaple, 0x04 "drive not
ready", 0x12 "sector not found"). The BIOS initially does not show them,
so that there is no error displayed if the floppy is not inserted.

Step 3. is important as the BIOS sends some (hardcoded) values to the
controller such as number of heads, cylinders etc. If this step fails
(i.e. the controller does on return code 0x00), the famous
"Controller/drive initialization error" message is showm such as when
the controller is not inserted.

What is very important here that this step always succeeds if the
controller is connected. So the controller is alive at this point, to
the extent that it returns a proper success code via DMA.

Then if hard disk #0 is present, we start getting errors 0xFF (timeout)
as early as in step 4. Whereas if the hard disk is not connected, 0xFF
appears first in step 6., which means that step 4 executes properly too
(possibly returning error 0x84).

So I concluded there must be some problems with the controller, which
make it hang and stop responding to all further commands. So my idea was
to remove the controller, and attach it only after all the above
procedure is performed. There would be no commands issued to it, so
perhaps it would not be hanging.

I tried this once, but no success (0xFF all along). So I removed the
data cable from the disk, leaving only the control cable. I attached the
controller only after the BIOS onitor was displayed, and tried the "park
drive" option. Voila! The controller properly parked the drive, moving
the head visibly. Another park command failed with 0xFF again,
indicating that the controller hung. I tried several times again, with
plugging and unplugging the cables in various combinations, but the park
command never wurked again.

Unfortunately, at some point during this plugging and unplugging,
something broke in the controller and now it responds with error 0x75 in
step 4. It is less than 0x80 so I assume this is some internal
diagnostic error code, probably meaning that some chip is broken. This
happens regardless of whether the disk is atatched or not. Then it
dutifully hangs in step 6 as before.

I suspect that hanging of the controller firmware may be a reason of bad
8749 MCU, eaither because of a bitrot in the EPROM contents or some
other problem. I ordered some 8749's from Ebay and found a good soul
with MCS-48 programmer who will program them for me when they arrive.

As for the 0x75 error I introduced, I will try to replace the WD ASIC
chips on the controller, and hopefully it will be fixed. I suspect that
the WD2010 chip may failed. Hopefully it's not something more serious,
like faulty DMA chip, which would be unsolvable :-( I am expecting the
chip from Ebay to arrive in about 2 weeks and I will be able to perform
more diagnostics then.

Regards,
Michau.





       Message was sent through the cbm-hackers mailing list