Date   : Thu, 29 Feb 1996 22:41:33 +0100
From   : Robert Schmidt <robert@...>
Subject: Re: Emulation systems

>I read your reasons for this but I'm not too sure. My one (MacBeebEm)
>just reads in files off the hard disk as and when they're needed, treating
the
>hard drive as one great big virtual cassette tape. 

I'm currently having a discussion with Wouter Scholten about the pro's and
con's of the various methods.  I agree that having one host file correspond
to one BBC file is very convenient.  I do however see compatibility problems
with weird file names (as I think I've expressed earlier).  The Beeb allows
characters like "?", "*", "\" and "/" in their filenames, thus breaking DOS
and Win32.  I have seen commercial programs using "*" and "/".  Also
DOS/Win32 have no distinction between upper and lower case - DFS does.

These problems appeared often enough while I was decoding my BBC tapes a
couple of weeks ago.

My current suggestion is to provide an optional field in the header,
containing the actual BBC file name.  If this field is not present, the BBC
file name is assumed to be the same as the host file name.  If the field
*is* present, the host file name can be anything, but should be chosen to be
as similar to the BBC file name as possible.

Also, since many tape programs rely on the functionality of CH."", *R."" and
*L."", the header should optionally provide the name of the *next* file on
the "tape".  If this field is not present, *CH."" etc. should return "not
found" or something similar.

My header suggestion is thus:

bytes:          contents:
4               magic cookie, "BBCF" for example
4               offset of data (header length)
4               load address
4               exec address
1               flags (locked flag is the only one I can come up with)
4               BBC data length (n)
4               CRC (of the data block)
10              BBC file name - optional (right-padded with zeroes)
10              BBC file name for *next* file - optional
n               actual data

The "offset of data" entry provides for future expansion of the header.  I
can't really see any more information that could possibly be interesting,
though.  Utilities which do not recognize entries after the BBC file name
should ignore the rest of the header, and simply read the data.  E.g. for an
emulator like BeebEm which supports DFS only, the *next* file name is not
interesting.

Notice that this format easily accomodates several BBC files in a single
host file.  After the data block, simply start over with a new header.

As BBC file names are stored in the headers, emulators and utilities must
scan the files in the current directory for BBC files, and should possibly
be aware that a host file might contain more than one Beeb file.

I realise that this format might seem bloated, but I am concerned with the
distribution issues.  I want to use a format which can be seen as a common
denominator, which can be used for 99% of the Beeb software (funny copy
protection schemes excepted) without hacking file names in the Beeb files
etc, and which can be converted to any format in use out there, even disk
images.


Regards,
robert

--
Robert Schmidt - robert@...         - http://www.idt.unit.no/~robert
	
	Maintainer of "The BBC lives!" page:  
	http://www.idt.unit.no/~robert/bbc/bbc.html