[coco] For Boisy or Mark ref Super Driver

Boisy G. Pitre boisy at boisypitre.com
Fri Sep 17 15:02:09 EDT 2004


On Sep 17, 2004, at 10:33 AM, <alsplace at pobox.com> wrote:

> Refresh my memory -- "rbsuper" does what?  I understand it handles 
> splitting up physical 512+ byte sectors into logical sectors for OS-9. 
>  But what else?

rbsuper does the following:
	1. It manages sector deblocking for handles devices with sector sizes 
from 256 to 2048 bytes/sector.  This gives RBF the impression that the 
underlying storage device is a 256 byte sector device when it really 
isn't.
	2. Hand in hand with #1, it uses caching as a way of keeping around 
sectors that are adjacent to the ones that it reads/writes.  This 
caching saves extra reads from the device, thus improving read 
performance (writing is another matter, though the compromises made 
were acceptable in my opinion, but that's another topic for another 
time).
	3. It handles verification if the IT.VFY byte in the descriptor is set 
to 0.  This means when writing a sector, rbsuper will turn around and 
read the sector back in and compare it to what it just wrote.
	4. It allows HDB-DOS partitions on a device to be read, assuming you 
have a descriptor set up in a certain way.
	5. Of course, it communicates to a low level driver that is simply a 
sector fetcher/recorder.  Rbsuper also handles potential conflicts 
between multiple accesses to the same low level driver via a semaphore.

The main reason for rbsuper's existence is #1, and by extension, #2.

> And, if llram, ll1773, etc. were done, would we save more system RAM, 
> or are those drivers not really doing any of the stuff that rbsuper 
> takes care of to matter?

There's no reason to have a 512 byte sector RAM disk, and by extension, 
no need for caching, so I don't feel it's a good candidate for rbsuper 
(though merely as an exercise, it would be very educational).  ll1773 
could support disks with 512 byte sectors, so that *could* be a 
possible candidate.  But it would only make sense if rbsuper is already 
being used in the system for something else like SCSI or IDE.  If 
ll1773's size results in a smaller number than rb1773, then it may be 
worth looking into.  Again, as an exercise, it would certainly be very 
educational.

> I was able to copy my entire EZ135 drive to the 256MB CF card, and no 
> lockups.  I'm going to make another backup, and once I'm satisifed I 
> have everything copied, I will burn the CF image to a CD for safe 
> keeping.

This is great.  I'm glad to hear llktlr is working for you.

Boisy




More information about the Coco mailing list