[Coco] cache sector 0? related question

[L. Curtis Boyle]

Going from faint memory here... but some drivers did use some of the extra byes. I know the B&B controller had the "alternate boot" info at the end of sector 0 (you could hold down a key to switch between two different boots), and the Eliminator driver may have had some use for the extra bytes (can't remember for sure).

L. Curtis Boyle
curtisboyle at sasktel.net



On Jan 25, 2014, at 11:26 AM, Aaron Wolfe <aawolfe at gmail.com> wrote:

> Here's another one for the experts:
> 
> Is the area in LSN0 that actually contains data ever bigger than 64
> bytes? NitrOS9 docs show PD.OPT section is from 0x20 to 0x3F... then..
> nothing?  Of course I ask because 64 bytes is much easier to deal with
> than 256.. but don't want to misunderstand something.
> If I took that shortcut I would definitely add code on the server side
> to abort caching if non zero was found in the area past 0x3f.  Quick
> look with a hex editor shows nothing but 0 on a couple RBF images
> here, but obviously something could write there, and in the coco world
> that often means somebody does..
> 
> -Aaron
> 
> On Sat, Jan 25, 2014 at 11:05 AM, Aaron Wolfe <aawolfe at gmail.com> wrote:
>> Its often been noticed that sector 0 of an RBF filesystem gets
>> read/written an awful lot when doing nearly any disk I/O.  I've been
>> working on the dw server some this morning and am being reminded of
>> just how much.
>> 
>> Would it be practical to cache this sector somewhere?  256 bytes is
>> not tiny, but also not impossible to find in the typical system page.
>> The logic for a simple write-through cache would not be very complex.
>> I guess I'm looking to the experts for reasons this can't work or
>> should never be done before looking at how to do it :)  Any thoughts?
>> 
>> -Aaron
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>