Date : Fri, 01 Mar 1996 03:25:18 +0000 (GMT)
From : John Sullivan <js10039@...>
Subject: Re: Emulation systems
On Fri, 1 Mar 1996, Robert Schmidt wrote:
> >How about using Linux's UMSDOS method? One file in each directory which
> >stores 'extended' information.
>
> This is in essence the technique used by Xbeeb. It is cumbersome because
> information about 1 file is not gathered in 1 place.
However file-system control data doesn't really belong within the data
file itself.
> 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.
A simple copy program that understands the index file would be needed
anyway, really.
> 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.
Another way is to just copy the file into that directory, and have a
synchronization utility, and/or arrange for the emulator to silently
update the index file of it detects any changes to the directory.
> With my suggested format, the filenames of the host files are really
> irrelevant, and limitations in the host OS will be no problem.
Likewise.
> 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.
With the index file, this information is already there (although you
should probably to a quick scan to sanity check the file).
> 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! :-)
Future proofing. Mirroring the version number of the archive *writer*
allows the reader to do cunning things in the face of developement and
cock-ups^H^H^H^H^H^H^H^H format-revisions.
>[...]
> >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.
They *ought* to be easier than mucking around with whole files - the code
for picking the raw data apart already exists in the BBC MOS - you just
have to arrange for the next byte of the file to become available on the
ACIA input-port every n cycles.
> 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.
Probably right, but nice for completeness sake.
> >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.
I suppose at the very least you can run the emulator until the game gets
going (tweaking by hand as it runs), then do a complete memory/state dump.
> >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.
Oops - so it does. It means a completely different thing to the CFS
locked flag though, doesn't it (read-only as opposed to execute-only).
Doesn't ADFS have a load of different flag settings aswell?
We need to decide whether to:
i) ditch the flags completely - they cause too many problems and aren't
*really* necessary.
ii) choose a sensible number to use. (DFS semantics *only*, CFS/DFS?)
iii) implement all available flags and make only appropriate ones visible
at any time.
> >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.
True, and it makes a good archive format for file transport.
> 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.
Nightmare. To get them to work the emulator has to have some pretense of
operating under CFS - either by emulating the tape hardware, or by
emulator hooks to catch OSFILE stuff, for example.
Otherwise, hack the files to not to CH.""
> 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*
I'm probably up till 7am again tonight. Eek!
John
--
O \
== /
O \
<a href="http://callisto.girton.cam.ac.uk/users/js10039/">Me!</a>