[Coco] Preserving old CoCo diskettes...

[Roger Taylor]

At 02:29 PM 5/19/2010, you wrote:
>On Wednesday 19 May 2010, Roger Taylor wrote:
> >At 08:39 AM 5/19/2010, you wrote:
> >>Roger,
> >>
> >>I can admit that we agree more than you think. You didn't admit that
> >>the number I posted was incorrect, you just indicated that I'll make
> >>it faster tomorrow. I asked for Gene to post his findings and you
> >>indicated that he won't do that, so I then reported the number. Factual
> >> data.
> >
> >No, I clearly remember saying more than once that you witnessed an
> >older build of NitrOS-9 that uses my early driver that did some
> >overkill LSN0 reading.  Enough.
> >



>And I find this a bit confusing Roger, as os9/nitros9 has never had to read
>lsn0 except the first time it accesses anything on that disk.  So I'm
>wondering where this got started?

The card's LSN0, not the disk's LSN0.  Disk BASIC must do this to 
make sure the partition pointer is not corrupt when running BASIC or 
ML programs that do wild stuff to memory.

Gene, my first drivers for NitrOS-9 (and this is not the Drive Pak 
product), used some of the DOS code and so this scheme carried over, 
and is still safer than even reading LSN0 once and storing it in a 
buffer.  I knew somebody would end up taking one of the paks to the 
fest that had the older NitrOS-9 build on it, and I would dearly pay 
the price.  And so I pay.

Still, this isn't space shuttle equipment, but had I written the code 
to be used in a power plant or something like that, you can bet your 
butt the old method will still be in use.  LSN0 has values that must 
not become corrupt under *any* circumstance, and the only way to 
ensure this is to read LSN0 as if it's RAM just prior to transferring 
a card sector.  Slower than it could be?  Yes, twice as slow, and 
those numbers landed here in due time just like a fly landing on a 
pile of crap.

The newer NitrOS-9 build on the distro card image does thing 
differently, and we'll see those numbers in due time as well.



>That might not be true if you're opening the disk in its entirety via the
>/dn@ operator, but I've not seen a normal usage situation that demands the
>file system be bypassed in that manner.

I think wer'e talking about different LSN0's and topics.


-- 
~ Roger Taylor