Date   : Wed, 22 Aug 2001 12:32:38 -0700 (PDT)
From   : Thomas Harte <t.harte@...>
Subject: Re: ANNOUNCE : UEF Specification 0.9

>  No, because unix is a (are) proper OS, whereas DOS isn't and more ore
>  less obsolete with almost everyone using windoze.

That would be my reaction if I were to select for myself (in actual fact I'm
increasing target support for ElectrEm hopefully soon to MacOS and dropping
none so the issue is moot), but I'm just saying that the idea that DOS
support is no longer wanted isn't true yet, and from watching the ElectrEm
slide won't be for at least a year. Which I consider to be a very surprising
result, but is statistically proven.

>  No, it isn't badly documented, it's extremly explicitly documented. More
>  so than your uef specs & functions to access them (I had to guess which
>  functions did what as you did not describe them anywhere, and they were
>  not named in a standard way either. Also had to guess when to use a
>  certain function, see the uef decode loop).

Oh, the functions are horrid, aren't they? I dumped them about five betas
ago, but the super-nice replacements are more tightly welded to the
emulator's file system abstraction (which saves me too much messing around
between Microsoft OS and UNIX path varieties), so I've yet to quite remove
them.

As for the documentation, I do invite comments regarding which parts don't
make sense or need better explanation. Of course, it all makes sense to me,
but that is hardly the point!

Now, some parts of INF that aren't well defined judging by
http://www.nvg.ntnu.no/bbc/std-format.php3 :

- is the general form meant to be read like an EBNF grammar production, i.e.
are those of the optional fields that are present always present in the
shown order?
- is the next field in the form "name.inf" or just "name" where .inf is
implied?
- why are half those 'specialisations' so called when they just restate what
have so far been presented as rules for all files?

>  Confusing for end users. Hmm. Uef isn't then?

Okay, I have a tape. It is one solid entity. I have a UEF of that tape, it
is one virtual entity. I have about 30 files + INF files describing them and
I have 60 virtual entities.

I want to load my tape and maybe alter some files. Luckily for me, I have a
real Electron and I remember how the tape FS works, so I use whatever *OPT's
I want, and I save any files I alter. Except of course I only have INF files
and the half-thought INF filing system which seems to vary from emulator to
emulator doesn't act anything like the filing system I already know and have
documented in a book. Chances are (with respect to common emulator support)
with INF I can't save.

Or, maybe I want to download a game. So I download the zip file and extract
it somewhere. I load the emulator, and with a UEF-Tape I simply select the
file, and the tape is already cued to the correct place (with ElectrEm it
will even automatically load, but that isn't a UEF feature, so is beside the
point). With an INF I have to either use my recollective memory, consult
documentation or if the non-specialised format is used check the INF files
until I find the only one that isn't linked to as next to figure out which
the first program is.

I don't think I need to comment on the difference between using makeuef to
generate a UEF-Tape when compared to using BBCTape once per file to get a
whole load of INF files. And the argument for INF files over disc images,
even just the vanilla sector dumps used currently, is even less tenable.

>  cheat filing systems? What's that?
>  Many little files: who cares :)

I mean with respect to the fact that supporting files coming from a UEF-Tape
requires just the effort to emulate the tape hardware. I don't know anything
about a BBC, but on an Electron this effort is minimal, and the code
produced is short.

However, to make an emulator load from INF files, the emulator author must
write a filing system which secretly (from the emulated machine's point of
view) reads the native filing system and throws the files into memory, or
else repackages them as they would be seen on a disc or tape and passes them
to the genuine hardware emulation. I consider those activities to be
cheating!

>  The disk naming scheme is not good as you need way too many names (hence
>  I use .dsk), but I've yet too see any really good arguments against INF.
>  So your arguments aren't really valid, INF does what it's supposed to
>  do, it can easily be handled/changed with a text editor if you haven't
>  got tools for a given OS etc, and certainly 'stop coming up' is not
>  going on either. What has been introduced anywhere in weird formats for
>  the BBC? (I'd say UEF :-))

Track interleaved formats cause a lot of wasted space on non-full floppies.
Every other disc image format I have seen (I've been shopping around for a
decent one to support with my emulator) at least has a header saying 'number
of tracks, number of sectors per track' which would instantly negate the
SSD/ADF or DSD/ADL distinction even without a 'number of sides' field that
would merge them all into one.

The better formats even have tables of offsets to tracks or sectors so the
lost space when not all the sectors or tracks are stored in sector dumps is
regained.

Further, the sector dumps don't even support as much as the DFS does - it
supports directly in ROM with no software trickery, writing file table
sectors with a deleted data mark which doesn't allow you to catalogue or
perform any activity other than *exec on files or shift+break boot.

Looking at all these facts, someone has sat down and said 'I can't be
bothered to parse a header in my code, I'd rather instead do comparisons on
the suffix and use lookup tables limiting myself to the common
possibilities' and 'hardly anyone used the deleted data mark, I can't be
bothered to store even a table of which sectors had normal and which had
deleted data marks'. Which I consider to be weird given the aim. The
inability to store non-standard track layouts seems to be fairly common
amongst similar file types which is at least something of a defense, but it
still seems odd to me.

Absolutely no other emulation communities have chosen to deconstruct their
media into the raw contained files and then additionally reference a second
set of files to get the file properties. So I can also claim that is 'weird'
as in 'unusual'.

>  Also remember that that at that time (conception of Robert's & my ideas
>  was late 1995 early 1996 (Robert wanted a BBC identifier at the start
>  IIRC)) all other emulator systems seemed to use image formats only. This
>  is exactly what the INF format was about: breaking up disc images so you
>  can combine them yourself, transfer them to whatever other format etc.
>  Tape was almost a non-issue, if there were more people actually
>  discussing such things on the ML then, things might have been different.

I have had until now no idea who's ideas these were or when they came from,
but of course I understand the tape issue. As I've said before, the first
proper Electron emulator having to come up with the first proper tape format
is not a great surprise.

I suppose another part of the problem is that the users I have are the ones
who bought the machine intended for the budget market and compared to the
technically minded BBC elite are more likely to have made the decision not
to invest as much effort into their purchase. So now they don't want to be
told 'well, you remember how on your Electron you had file attributes which
aren't stored with modern systems so you need an extra file for each one',
they want to be told 'you run your tape into this piece of software and from
then on use the produced file with the emulator exactly as you would the
tape with the original machine'.

I've had a few emails from people who are now just connecting tape players
to the PC and using the original tapes (no file format inbetween - a new
feature in the last ElectrEm), so I'd argue that whatever delivery medium is
closest to the original is preferred.

Anyway, this is a side debate of only minor interest seeming to rest on how
good established (disc images) and dying (INF) file formats are for their
task when the issue is no longer open for debate. The fact is that many
discs and tapes cannot be directly converted to SSD/DSD/ADF/ADM/IMG/ADL/ADS
or INF, but that the UEF and FDI formats, are flexible enough to store them
all.

-Thomas





_______________________________________________________
 Get 100% private, FREE email for life from Excite UK
 Visit http://inbox.excite.co.uk/