RL02-USB Controller Status/Problem

Christopher Parish christopher.parish at parishcomputers.com
Tue Apr 7 07:13:47 CDT 2015

> [...]
> Now, a total imaging of one RL disk to another is not something you
> should do. That would replace the pack serial number, in addition to the
> issues with the bad block lists. Not to mention that different packs
> have bad blocks in different places.

I agree.  You're right that the best way to copy a pack is to load up the appropriate OS in the simulator and instruct it to do the work.  Because it has knowledge of the filesystem, it will copy around bad blocks, identify new ones, etc. without stomping on the serial number and factory recorded bad block data. 

> Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped
> away, or faked. The drive and controller can detect bad blocks, and when
> you try to read one, you'll get an error back. Drivers try a few times,
> and then give up, giving an error back to the user program.
> You should not try anything different.
> [...]
>        Johnny

I will have to patch SIMH to support this paradigm because right now it expects the backing store for its virtual RL02s to be readable at all times.  IO errors trying to access the underlying "file" halt the simulator.  Additionally, there is no way to report what type of error occurred via USB mass storage, only that fewer blocks were returned than expected.

I think I'll need to have two completely different modes of operation.  

A USB Mass storage mode would use the pack like a modern hard disk. The controller would hide and internally use the last track for bad block identification and not expose it to the PC.  Also, the controller would hold some number of sectors in reserve, presenting a flat, error free ~9.8MB disk to the PC.  This would work for modern filesystems but be completely useless for SIMH and physical computer compatibility.

The other mode will need to be a non mass storage interface like bulk or CDC mode specifically for use with SIMH and any custom diagnostics.  SIMH (after modification) would then be able to access all the raw data on the pack and have access to any errors that occur, handling them however it wants.  Copying packs would need to be done just like it is now, except in the simulator.  You either mount or image and mount the first disk, load your favorite OS in SIMH attached to the physical drive, and instruct it to copy disk 1 to disk 2, letting it copy around bad blocks in the manner it always has (preserving compatibility).


More information about the cctalk mailing list