Date : Thu, 29 Feb 1996 23:31:55 +0000 (GMT)
From : John Sullivan <js10039@...>
Subject: Re: Emulation systems
On Thu, 29 Feb 1996, Robert Schmidt wrote:
> >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.
How about using Linux's UMSDOS method? One file in each directory which
stores 'extended' information. In this case, full BBC filename, load/exec
addresses. (UMSDOS uses the file for storing the full UNIX filename,
multiple timespamps and UNIX file permissions under a normal MSDOS FAT
filesystem.)
The file you *actually* store is something like 8 chars of the BBC
filename (with wierdies substituted to '_' or something) with the
extension set to a 'magic value'. The simplest case is a number which you
use to lookup the correct entry in the index file. Eg.
Files:
BBCTAPE_.___ Index file
BBC-FILE.000 file 'BBC-FILE'
Q_FILE00.001 file 'Q.FILE0000'
R_BBC_FI.002 file 'R.BBC/FILE'
and the index file would contain entries like:
Id# Filename Exec Addr Load Addr Next FileId#
=== ========== ========= ========= ===========
000 BBC-FILE FFFF8023 FFFF0E00 002
001 Q.FILE0000 FFFF4000 FFFF4000 001
002 R.BBC/FILE FFFFFFFF FFFFFFFF FFF
Then have 1 DOS directory == 1 BBC tape, and use *='tape-name' to
'change' tapes.
> My header suggestion is thus:
>
> bytes: contents:
> 4 magic cookie, "BBCF" for example
Good.
> 4 offset of data (header length)
Include version number of header here?
> 4 load address
> 4 exec address
> 1 flags (locked flag is the only one I can come up with)
Although the beeb *does* have a whole byte reserved for this, so may as
well keep it rather than fudge it into somewhere else.
> 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
Good.
> n actual data
Sorry - this is a file structured data format, yes? (If so, ditch flags
completely? I don't think they're useful on anything but a block by block
basis.) For a block/block format (basically a mirror of the data stored
on tape, which may help with protection systems that bugger about with
the filename and flags information during load) you should specify what
portion of the header is repeated for each block. The 'next filename' is
only useful on a per file basis, so should come at the start. (What about
load/exec addresses - are they stored in each tape block, or just once
per file).
For really good tape emulation, we need a block by block format, which
will still fail with games that use one monolithic byte stream.
> 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.
Multiple filesystems are probably a problem since conventions on what
information is stored, how the OS can be hooked to alter the loading
procedure, etc, can vary. Perhaps we can try and keep track of which FS
is currently active, and so alter the emulators behaviour accordingly.
> 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.
Which makes it slightly harder to edit BBC files from under the host OS.
> 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)
If you choose a fairly low-level file format which tries to describe the
original data as completely as possible, then we can probably still work
under most protection systems. Eg:
struct BBC_DATA {
char id[4]="BBCF";
enum { TAPE_BYTESTREAM, NORMALFILE
/* ,DFSIMAGE, ADFSIMAGE for 'hard' disk protection systems, where
* for example, some sectors may be missing and we'll want to return
* an error on access attempts. */
} type
union {
struct {
/* bytestream want's to encode the tape data as closely as possible,
* including perhaps indications of inter-byte pauses. */
} bytestream;
struct {
/* normalfile just stores the BBC filename, exec/load addresses,
* length. This is a really normal file with no wierdies at all.
* Have a pointer to another file containing the 'real' data? */
} normalfile;
struct {
long length;
char *imagefilename;
} dfsimage,adfsimage;
} d;
}
Ideally we want to store as much info as we have about the original
file-source, but keep *that* seperate from the real file-data.
> without hacking file names in the Beeb files
> etc, and which can be converted to any format in use out there, even disk
> images.
Perhaps we need a standard library of routines to inter-convert various
formats into a 'standard BBC-file format' and back. If we can get from
any data format to a format containing 'Data, Filename, Load/Exec Addr,
Length' then most things can be made to work from that, even if the real
data-source isn't fully supported.
John (sorry if this is a little incoherent...)
--
O \
== /
O \
<a href="http://callisto.girton.cam.ac.uk/users/js10039/">Me!</a>