chrispville / rl02 Goto Github PK

USB Mass storage does not support passing the types of error information various OSes like RT-11 and RSX-11 need in order to work fully with the RL02.

The RL02 disk packs pretty much all had bad sectors somewhere. These can be identified and stored in a factory provided table on the last track of the disk, but it was up to each OS to decide how to handle them. Some skip sectors while others remap them.

Implement an advanced mode over bulk transport which exposes the underlying error bits and drive state to SIMH. (SIMH will require a driver, which is a separate repo).

Hi Chris,
I saw the video about this project on Hackaday and it didn't look like you had a terminator attached. Is one actually needed? I've been trying to get an RL02 drive to work with my 11/73 but not having much luck. Thanks and great job with this project.

Modern OSes get unhappy when they have to deal with IO errors from disks. The RL02 disk packs pretty much all had bad sectors somewhere. These can be identified and stored in a factory provided table on the last track of the disk, but it was up to each OS to decide how to handle them. Some skip sectors while others remap them.

In USB Mass Storage mode, save a track of the RL02 for sector remapping and use the DEC written bad sector table. With these, modern filesystems can be written to the disk around the inevitable bad sectors, although this will break SIMH and block level disk backup support for vintage disks.

The uC will need to be aware of the drive's reported status for proper SIMH support. Likewise, the uC will need to send some drive commands directly through to the drive.

When the FPGA receives a command that will invalidate the data in the FPGA->uC FIFO (such as seek), it doesn't assert the WAIT line until the command gets to the execution step of the pipeline.

Use one of the bits of the command field to represent instructions that will invalidate the FIFOs and immediately assert WAIT on seeing it.

Every once in a while the drive asserts a non-resettable fault after sitting idle, post-spindown, for a while. It seems to spontaneously disappear before I go to probe it. It might be an electrical margin issue.

Write some code and modify the FPGA to interrupt the microcontroller so it can capture the error condition the instant it happens, before it goes away. This type of error handing will be required for robustness anyway.

The BOM has the wrong 3.3V regulator specified for the physical footprint.

Either find a pin compatible replacement or pick a new part.