[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