Date   : Fri, 01 Mar 1996 09:41:02 +0000 (GMT)
From   : James Fidell <james@...>
Subject: Re: Emulation systems

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

The Xbeeb filing system is much improved in v0.3.  It's also intended to
be an emulation of the DFS, not the tape system.  I chose to keep one
UNIX file exactly the same as one file on a BBC disk because that
maintains portability of files between the two systems.  I personally
don't like the idea of transferring a file from BBC disk and changing
it to get it to work under the emulator.  I think that your criticism
about not keeping all the data in one place is dubious because all my
__CATALOG__ file does is duplicate the information that is in the
catalog of the DFS disk, which is, after all, a different place from the
actual program data.  I agree that it's not perfect, though.

For copying a file under Xbeeb in v0.3 you can do this :

    > *NEWDISK <source disk directory name>
    > LOAD "file"
    > *NEWDISK <target disk directory name>
    > SAVE "file"

There's no emulation of the *COPY command, but I'm sure that will
be along in the fullness of time.

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

I think this is a good point -- there needs to be some mapping of
Beeb filenames to host filesystem filenames.

> >Include version number of header here?
>
> Well... shouldn't the data offset, together with the flag byte be
> enough? This isn't AutoCAD! :-)

Let's choose to err on the side of caution and put in a version
number.  It won't hurt, it generates little extra code and it has all
sorts of potential benefits.  Just because we're not getting paid for
this doesn't mean that we shouldn't make a good job of it.

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

I was thinking about this the other day in relation to disk images.
With the 8271 you can actually read the sync. bytes from the disk
surface.  That could lead to very complex disk emulation if you choose
to go that way.

I'm not saying that you shouldn't, though.

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

The EFS/XDFS emulation in Xbeeb will probably never support CH."" -- I
really want to keep it as a disk emulation.  If I go through the pain
of supporting tape stuff, then I think I'll probably do it at the ACIA
level.

James.

-- 
 "Yield to temptation --             | Work: james@...               
  it may not pass your way again"    | Play: james@...                 
                                     | http://www.OiT.co.uk/~james/
        - Lazarus Long               |              James Fidell