Date   : Fri, 01 Mar 1996 01:44:06 +0100
From   : Robert Schmidt <robert@...>
Subject: Re: Emulation systems

>> DOS/Win32 have no distinction between upper and lower case - DFS does.

I realised my mistake here right after posting... :-/

>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.)

This is in essence the technique used by Xbeeb.  It is cumbersome because
information about 1 file is not gathered in 1 place.  If you want to join
two sets of BBC files, you need to attach one index file to the other - not
a mean feat, but nevertheless cumbersome.  If you want to move just a few
files, you have to edit the index file manually, and make sure you keep the
correct entries with the files you move.

With my suggested format, the filenames of the host files are really
irrelevant, and limitations in the host OS will be no problem.  The emulator
or utility must, however, go to the extra step of scanning each host file in
the selected host directory to find the real BBC file names.  An emulator
should maintain:

- a table of BBC files in the current host directory, with host file
names, and
  eventually offsets inside the host file (if "meta"-files are supported)
- a current file pointer, to support CH."" operations in tape-based programs

>> 4               offset of data (header length)
>
>Include version number of header here?

Well... shouldn't the data offset, together with the flag byte be enough?
This isn't AutoCAD! :-)

>> 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.

Whenever someone wants to support a block by block format, or even a byte
stream format, these could be reflected in the flag byte.  I don't find it
very probable that any of the emulator developers wants to work on
supporting such exotic formats now, though - given that they are all in
relatively early stages. In fact, I don't consider block or stream formats
as very interesting at all.  Most (all?) good games exist as disk versions,
anyway.

>(What about 
>load/exec addresses - are they stored in each tape block, or just once 
>per file).

The BBC stores the following info in each block: filename, load & exec
address, block number, block length, block flags, header CRC and data CRC.

>For really good tape emulation, we need a block by block format, which 
>will still fail with games that use one monolithic byte stream.

I don't even want to think of the implementation issues involved in
supporting these 2 formats.  I think it is best first to ignore "OS hooks
for funny things" - I am not convinced that the effort would be worth the
amounts of time, sweat, tears and coffee required from the emulator developers.

>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.

Any copy protection schemes can be cracked - and this should be a lot easier
under an emulator than on the real Beeb, so I still think a simple format is
sufficient.  Adding a full-featured, absolutely-in-control debugger to an
emulator should be a breeze, and would pay off a lot quicker than trying to
*support* all possible devillish copy protection schemes.

>> 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.) 

Why not?  DFS has a "locked" flag per file, that should be reason enough.

>Which makes it slightly harder to edit BBC files from under the host OS.

Yeah well... it's just an option.  It's easy enough to make a utility to
split such a "meta-BBC-file" into several single host files, for programs
which refuse to support such meta files.  It's just an option that some
people might find convenient.  It would be natural to gather all files
related to a single game into one such meta file, for example.

>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.

Exactly, I had something like that in mind.  And I am not suggesting this
format and telling all emulator developers that "hey! you should do this!"
(I guess they couldn't care less!  :-)  What I'd like is a nice, convenient
format for distribution of BBC files - those who want to support it directly
should feel free to.  However, if the format they *do* support is relatively
simple, there's no reason why you shouldn't be able to download a game from
my page (say), unzip it, then convert it to that particular emulator.
Converting from my suggested header format to a BeebEm disk image, a Xbeeb
__CATALOG__ file, a set of MacBeebEm files, etc, ... it should be a breeze
both ways.  

Whether the converted files work as intended is a different matter
altogether, though - for example given that DFS (BeebEm) and EFS (Xbeeb)
won't let CH."" work correctly, and that some programs (like Wouter's
double-sided disk menus) assume two sides of disk are available, etc.

Hmm... that's all I could think of for now, hope you didn't fall asleep.  I
should though - it's 1:30 AM here... *yawn*


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