Date   : Tue, 18 Jul 2006 23:05:57 +0000
From   : Jules Richardson <julesrichardsonuk@...>
Subject: Re: Getting .SSD disk images onto a beeb...

Steve O'Leary wrote:
> Ahh, it is that simple and it isn't ! Sorry coming late to this thread 
> or I would have chipped in earlier. Yes an .ssd disk file is a straight 
> forward sector by sector copy, however if no files are stored beyond a 
> certain sector then it does not store empty data. Look at the file sizes 
> of a few ..ssd files and you'll see they vary widley. So you need to 
> ensure that you don't try and read past the end of the input stream and 
> generate an error. In this case you could just exit the proc leaving the 
> previous buffer contents to be written again (which won't do you any 
> harm) or more elegantly perhaps write out null  bytes.

Hmmm. I suppose to be flexible, the remote (e.g. PC) host needs to initially 
send the following:

   require surface 0 flag
   require surface 1 flag
   number of tracks of target disk, surface 0
   number of tracks of target disk, surface 1
   sectors/track of target disk, surface 0
   sectors/track of target disk, surface 1
     ... the beeb side could go away and format a disk at this point, or for
         an initial release it could just prompt the user to insert a
         formatted disk of the right geometry.

with that out that way, it sends the total number of sectors (blocks) on each 
surface in the selected disk image:

   total sector count in disk image, surface 0
   total sector count in disk image, surface 1


then it can send the data for surface 0 (if any), followed by the data for 
surface 1 (if any).


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 - 
but I can't imagine why you'd ever find a disk image like that anyway (SSD/DSD 
formats won't cope with that anyway - Imagedisk and probably various others 
will).

It'll cope with single or double sided disks OK, plus it'll handle the odd 
occurrence of a disk with data on the second surface but not on the first.

As a performance improvement, I'd recommend allowing sending of an initial 
'type' byte before each sector transfer - 0x00 (say) indicates that a full 
sector's worth of data follows, whilst 0x01 (say) indicates that a single byte 
follows and the entire sector at the beeb end should be padded with that byte. 
It may even be beneficial to have an '0x02' tag type, which just means 'same 
as previous' - the beeb can just write out the previous contents of its buffer 
at the current sector address.


I could write the PC side of that easily enough - but I wouldn't have a clue 
how to do any of that in BASIC on the beeb!

cheers

Jules