Date   : Wed, 19 Jul 2006 11:50:51 +0000
From   : Jules Richardson <julesrichardsonuk@...>
Subject: Re: Getting .SSD disk images onto a beeb...

Steve O'Leary wrote:
>> From: Jules Richardson <julesrichardsonuk@...>
>> To: bbc-micro@...
>> Subject: Re: [BBC-Micro] Getting .SSD disk images onto a beeb...
>> Date: Tue, 18 Jul 2006 23:05:57 +0000
> 
>> That should get around 'problems' with the image file data being 
>> 'shorter' than the eventual target disk. It doesn't cope with 'holes' 
>> in a disk; for that the PC side would have to be clever and pad out 
>> the data it was sending
> 
> Holes shouldn't be a problem as although logically there can be a hole 
> there is still data in there that will just be sent by the PC as normal, 
> it'll be junk perhaps but unimportant as it doesn't have a catalogue 
> entry. To illustrate;

Ahh, by holes I mean tracks or sectors that are totally missing though, say 
due to original disk damage - the more flexible image formats will just record 
th fact that there's no data at that point and move on (resulting in a more 
compressed image file), whereas SSD/DSD would have to pad out the missing 
sectors with false data and there'd be no way of knowing at transfer time that 
this had been done.

If we're 'compressing' sectors for transfer (i.e. a sector of all the same 
value is just a tag + data byte rather than tag + full sector) then it doesn't 
really matter, I suppose.

Actually, to be totally flexible, I suppose the first thing the PC should send 
is a sector map, describing relationship between logical and physical sectors 
and logical and physical sides - not vital for an initial cut of any software, 
but needed to sort out interleave issues and likely handle a few oddball copy 
protection schemes out there.

<tangent>
SSD/DSD is a reasonable choice for 'transient' data, but as any kind of 
archive format it really doesn't cut it - same's true of a lot of the 'dumb' 
formats out there. For preservation and archive use, any format needs to 
encapsulate enough data to recreate the original media as closely as possible, 
as well as flag errors in the original and allow storing of metadata, so that 
someone unearthing a stray archive file in x years times knows what it is!

I'd prefer any transfer protocol to be able to send/receive as much of the 
anticipated information as possible, even if initial versions of the code 
don't actually do anything with it :)
</tangent>

cheers

Jules

-- 
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.