<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Sat, 23 Jan 1999 01:08:46 +0000
From   : jgh@... (Jonathan Graham Harston)
Subject: Backup BBC Hard Disk to PC ??

"Andrew Benham" <adsb@...> wrote:
> It struck me the other day that the BBC Master with its 20M hard
> disk is sitting next to a PC with a 6.4G disk, which could hold a
> 20M backup image and not notice it!
> Has anyone come up with a clever scheme to backup a BBC hard disk
> to a PC ??
 
Mark Usher <marku@...> wrote:
> Right. I have been thinking about this myself recently. There is a
> program to connect a BBC / Master to an archimedes and use it's hard
> drive but that's not quite what we need.
 
Running HADFS Filer 1.10 on an Arc will let you share a disk image over a
serial link to a BBC/Master.  The disk image may contain any filesystem
structure.  HADFS Utils 1.00 running on a BBC/Master provides a 'link'
drive for HADFS over the serial link.  So, you could dump the entirety of
your Master's hard drive over to an Arc file by file using:
 
              *TreeCopy ADFS::0.$ HADFS::L.$
 
Doing it file-by-file is slower than sector-by-sector.  The HADFS System
Suite also includes a program that would copy sector-by-sector which would
be faster, by doing:
 
              *Backup ADFS::0 HADFS::L.$.ImageFile
 
Once on the Arc's hard drive as an HADFS image, all the files are
accessible locally with HADFS Filer, or they can all be dragged out and
dumped straight into a native directory structure.
 
I did just this last November when working with JJR's machines and
updating the HADFS system software.  We managed to get it working at a
full 19.2k baud, but even at that speed, it would probably be an overnight
job to do the whole hard drive.  We started investigating using the
printer ports to join the machines.
 
Toying with the numbers, a 19.2k link would transfer 20Mb of raw data in
approximately 10240 seconds (170.6 minutes or 2 hours 50 minutes).  Adding
overheads would increase this.  I haven't got any experimental data to
quantify this exactly.
 
I know this doesn't solve the problem of transfering the Master's HD to a
PC, but I've been toying with a server program to run on a PC to allow
that.  I suppose I should go back to finishing it off.
 
Mark Usher wrote:
> I'm not sure how this would cope with a file server drive as they are
> not ADFS. It all depends on how the Beeb handles the sectors that are
> retrieved, it could be ok though.
 
It doesn't matter filestructure is containing in the sectors, as long as
you just transfer the sectors as whole sectors, that'll do the trick.
 
Mark Usher wrote:
> 3) The above 2) could be used, but using a parallel Xfer from the User
> Port to the PC's printer port "laplink" style. I've just started playing
> around with this and it looks quite feasable. Much better data transfer
> could be acheived.
 
I made a link to do this sometime in the mid-80s to go from an Amstrad CPC
to a Beeb and it worked quite well.  A couple of years ago Chris
Richardson showed me a cable somebody had made him that connected a PC
printer port to the BBC's user port, primarily for PC to BBC transfers. 
I've been meaning to get around to doing something like this myself for
some time.
 
Mark Usher wrote:
> So, as a quick answer, I've emailed Stuart to ask him if it is possible
> to adapt his pcXfer program to do this. I'd like to write a program to
> then manipulate the resulting image, or maybe Laurie Whiffen might like
> to implement this in his BBC Explorer program. You could then transfer
> the new image back :-)
 
It's fairly simple to read data from a file and display the resulting
file-list as though reading a directory from disk sectors.  I've been
meaning to incorporate this into Filer for some time now.
 
There is a defined format for disk image files if anybody is planning on
writing programs to create or manipulate them:
----8<----
:JGH.Allocation.DskImage
 
Disk Image File Format
=====================
 
Description
Just a complete image of a disk, purely the contents of the sectors of the
disk. For example, with a disk with 256-byte sectors, the first 256 bytes
would be the contents of the first sector of the disk, the second 256 bytes
the second sector, etc. So, an image of a 800k D format disk would be
exactly 800k long, the free space map would be in bytes 0 to &1FF, the root
directory would be in bytes &200 to &6FF and the rest of the disk contents
would be in byte &700 onwards.
 
Identifying Image Contents
A disk image contains purely the contents of a disk.  To identify what
filestructure is stored within an image you examine the contents just as
you would examine the contents of a physical disk to determine the
filestructure on it.  File systems usually store information about the
structure of the physical disk within the data itself.
 
Examples
An image of a 200k DFS disk image might look like:
*WDump DFS_Img
000000 44 49 53 4B 5F 4E 41 4D 46 69 6C 64 30 31 20 24 DISK_NAMFile01 $
000010 46 69 6C 65 30 31 20 24 46 69 6C 65 30 31 20 24 File02 $File03 $
000020 46 69 6C 65 30 31 20 24 46 69 6C 65 30 31 20 24 File04 $File05 $
..etc...
000100 45 20 20 20 99 30 33 20 00 19 2B 80 45 04 CC 02 E   .03 ..;.E.L.
..etc...
031F00 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 eeeeeeeeeeeeeeee
*
----8<----
 
Mark Usher wrote:
> After getting fed up with the snail pace of the serial port for
> transferring data across to the PC, I thought I'd look in to wiring up a
> parallel 4bit or "laplink" cable to do the transfers via the user port.
[snip]
 
So, effectively:
 
USER  CB2  -> ~ERROR   PRINTER
PORT  CB1 <-  D4        PORT
       D7 <-  SELECT                  So this needs a loop polling D7
       D6  -> PaperOut                on the user port to see if there
       D5  -> ~BUSY                   is data to collect on D0-D3
       D4  -> ~ACK
       D3 <-  D3                      Or is this a 'standard' laplink
       D2 <-  D2                      wiring method?
       D1 <-  D1
       D0 <-  D0
 
I made up my lead as follows:
USER  CB2              PRINTER        So this way, when writing a byte
PORT  CB1 <-  SELECT    PORT          to the printer port, when the data
       D7  -> ~ACK                    is present, SELECT is raised, and
       D6  -> ~BUSY                   the user port can be programmed to
       D5  -> ~ERROR                  interupt on CB1 and so automatically
       D4  -> PaperOut                collect the data in D0-D3
       D3 <-  D3
       D2 <-  D2                      ~BUSY and ~ERROR may have been the
       D1 <-  D1                      other way around, but I remember
       D0 <-  D0                      that ~ACK was D7, and the ~signals
                                      were collected together
Mark Usher wrote:
> Now for some software......
 
I'll have to dig out what I've got...  It's in some unfinished HADFS
Support routines somewhere...
 
-- 
J.G.Harston (JGH BBC PD Library) 70 Camm Street, Walkley, SHEFFIELD S6 3TR
jgh@...                --- BBC+Master / Z80+6502 / CoPro+Tubes / Econet+SJ
Devolution / Transport / Planning - - - - - - - - - - - - - http//mdfs.net
Walkley Focus Editor:  http://homepages.nildram.co.uk/~amilton/walkley.htm
-- 
    ___  ___  ___  ___  ___  ___   |  Free Internet E-mail and Usenet News  | 
|  /   \/   \/   \/   \/   \/   \  | +44 181 654 2212 also +44 181 655 4412 |
|    A    R    C    A    D    E    |   Croydon  UK  -  Fidonet#2:254/27.0   |
|     The Definitive Acorn BBS     | http://arcade.demon.co.uk  at weekends |
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>