Date : Thu, 23 Aug 2001 03:46:25 +0000
From : "W.Scholten" <wouter.scholten@...>
Subject: Re: ANNOUNCE : UEF Specification 0.9
Thomas Harte wrote:
> 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?
Yep.
> - is the next field in the form "name.inf" or just "name" where .inf is
> implied?
See the example in the original inf specification. (I sent you one long
ago too).
> - why are half those 'specialisations' so called when they just restate what
> have so far been presented as rules for all files?
These are nothing to do with me, but with Mark De weger's stuff (he uses
it on xfer). As I've sent you my code & info long ago, and it's always
been available with bbcim, this is irrelevant for your argument. I also
said it was my format (with discussion from Robert, so both I guess).
> > 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
Emulator? Hmm. Reread my previous post. Exchanging data is the name of
the game, and that can be to BBC's... Or any other machine on which one
might want to examine BBC data.
> documented in a book. Chances are (with respect to common emulator support)
> with INF I can't save.
So what? It's not actually meant to be an emulator format. If it doesn't
work, too bad. Use an image format. I said this before. Your emulator
could stop with an error message in that case. There's no need an
emulator should limit itself to one format.
> 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.
Nope this is not an argument (because of what the format is about). You
add metadata in your format (implicit too with chunk order), and that
can be added easily with a readme,[ CHAIN"ABCD" to start] . Can be done
with an image too created from individual files (from INF to tape
image). Further to find first files, you can add a utility (or in the
emulator) that checks which ones are first and sorts them or whatever.
Btw, if you've got a disc with many programs on it, you get a similar
problem...
> 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.
In one case you get one file, in another more files. And?
> And the argument for INF files over disc images,
> even just the vanilla sector dumps used currently, is even less tenable.
Teneble? There were *no* arguments for or against inf/diskimages vs
other image formats (unless you think that only one type of format may
survive, and that that should be UEF/FDI whatever). Only that they do
the job. You made comments about bad definition and bad ideas. It's not
actually despite the optional arguments, and they're not bad ideas. Not
perfect but fine for the job intended. I've said this before, and you
again say 'inf can't do this or that'. This has been discussed a while
ago already! (check the ML archive and/or mail archive). Same for disk.
> > 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!
So what? Some (many) emulators use invalid opcodes to break out
emulation for example. Who cares? Cheating? If you want an emulator to
work in a certain way, fine, do so. But most people just want to use
them to run programs (I think you're cheating because you don't emulate
how the 6502, 1770 etc operate internally, transistor states you
know...). It all depends what you want to emulate (atomic level? cool)
'cheating' is a silly argument against inf (distribution!). Btw, did I
mention that I don't really use emulators?
[ disk ]
> 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.
Ok. But I and most people probably don't really care about this (not
then and probably not all know with large HD's). It certainly wasn't an
item when the format was introduced (in beebem?). Improvements are fine,
but you imply with 'ill thought out' and such that your 'reasons' are
obvious and should have been used from the start and some idiots
invented them. It wasn't that way and I frankly resent that you find it
necessary to try to rewrite history with your 'can't be bothered' etc.
Wasn't Dave Gilbert (beebem) the one who 'invented' the interleaved
diskimage format? He might want to explain why.
> 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.
Yes, I believe I was actually the first to bring this up on this list a
few months ago (in response to one of your posts), but thanks for
telling me :)
> 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'.
Are you kidding me? Noone sat down and said 'I can't be bothered....'. I
actually didn't want a header... (not sure what Robert's exact position
was).
Read again my previous post, the 'editor' stuff, tools, interchanging
data etc, and you may understand why the separate text file was chosen.
And yes, binary headers are fantastic. NOT. It could have been done
better (more easily extendable), but Robert explained that. Diskimages
were all anyone cared about at that time. Every game was available
cracked, so copy protection wasn't necessary to consider either.
And what's this 'can't be bothered' talk? Are we going to do a flame war
or something? If you give technical arguments why something is bad or
not, fine, anything else is not fine if done in an unfriendly or
suggestive manner.
There were reasons for everything. You weren't there. I & Robert have
explained (some/all?) the reasons for the INF format before. Disc
images, well not sure where this is described, beebem readme? ML
archive?. I've agreed to the things these formats can't do, I've said to
use real image formats if needed. Rehashing is boring.
> Which I consider to be weird given the aim. The
What aim? In the spec it says: THE ARCHIVE FILE FORMAT: i.e. the
standard format for/of files in the BBC archive. This it is (actually of
*my* archive, later Robert's archive), but there's no explicit aim to
nuke other formats, as in 'no other formats allowed' or everything
will/should be in this format, as it doesn't say so. With interest in
true image formats, one might have to rename it I guess (or not, naming
true image formats 'true_image' format or something).
The only aim was to provide an archive of software in an easily usable
format
that can be transported to any system. Disc images are clunky.
Non-editable by hand (no tools for a given system remember? RISC os
users had to set attributes separately for a while). Eliminating disk
images was not the aim, providing something that's mostly more useful
was.
> 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.
No, this was not necessary nor was anyone interested (due to all games
being availble in unprotected versions I guess). The goal was making all
the software available. Making it 'as original as possible' was not an
issue and for exchanging one's own BBC code/text files for example to a
PC this is
also not an issue. Read up on what went on before making insinuations
about people don't caring or whatever.
> 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'.
Weird does not mean unusual, but eerie/odd (odd gives unsual in the
dict. as a meaning but then you're 2 steps away and slightly different
meaning; or am I wrong here native English speakers?), and of course
used as a response to your 'ill thought out' etc. So you think because
not everyone else is using/making utilities for extracting files in this
way, makes this format weird. Now *that's* weird! If only for
information sifting and not being able to check everything on the entire
world this argument is void. You should know that both good and bad
ideas get lost and reinvented...
If you just meant unusual, then your whole sentence was superfluous.
Yes, it's unusual, so what?
nitpicking: what's this 'emulation communities'? Why no mention of
actual users of the machines? This list is *not* just about emulation!
And neither are the inf/disk formats just for that purpose.
[origin]
> I have had until now no idea who's ideas these were or when they came from,
It should be as we've mailed about it and it's mentioned in various
places, even the document you incorrectly cite for your 'bad def'
argument states:
----
The standard format was first described by Wouter Scholten and is
sometimes known under
the names "archive format" or "image format".
----
That should give a clue (had some discussions with Robert, but yes I
decided on this).
> 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.
Why? Because the BBC emulator makers started with the disk format, and
as all BBC owners were all rich anyway and never touched a tape after
1983?
> 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'.
This is nonsense. There are instructions how to use formats in a
program, change it for emulator use etc, with *any* format. The remember
bit is completely irrelevant. There's no need to know about the output
files. It's irrelevant wether you get 1 or 100 files from a utility. You
get output files from a given utility, put them in a directory. Or you
make an uef. Same thing (first case uses the native filing system for a
container).
May I complain to you that your emulator uses too many files and that
that's confusing? The emulator should place files onto the end of itself
(executable) so there's only one file at all, no? Much less confusing
for users. The emulator's config file should of course also be attached
etc.
> 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.
For preservation and interest yes, but otherwise no. You've not given a
reason for an image format in this section. What should be original is
first and foremost the experience. If with a cracked program, fine for
me and many others.
And why do you have this multiplexing thingy, improving the image of,
what was it, daredevil dennis?
Now that's not original at all. I strongly object to such cheating.
> Anyway, this is a side debate of only minor interest seeming to rest on how
I think anything to with the electron is a side debate and of minority
interest, and people really shouldn't talk about them, but I'll let
people talk about it anyway. Both are on topic as per the charter.
> good established (disc images) and dying (INF) file formats are for their
> task
Dying? Why do you have to be so negative? UEF is the dying format isn't
it? At least as an exchange format, maybe not an emulator format.
I'm not going to get an unprotected disc from an acornsoft game if I
want to examine the game code (instead of the protection code). I'm not
going to use an FDI from say planetoid to put on a disk for my BBC as I
can place say 10 unprotected games on a disk. INF versions are fine for
this. Dying? It has it's uses, probably for a long time yet. A more
general format ok, but not like UEF (is/was) I hope.
> when the issue is no longer open for debate.
Please don't be condescending. I'll do better though: there was no
debate. INF has limitations (and advantages), true image formats don't
have limitations in emulation or restoring originals, and I already said
so long ago. And I didn't say otherwise in my previous post, just giving
some reasons as to the format.
> 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.
Rehashing...
I get the idea you think that I'm defending INF and the currently used
disk image formats as good enough for anything. Why? I've stated in
previous mails to you & posts to this ML that this is not the case. But
they do do what they were intended for, and I think more than one
formats is ok: A standard format and image formats.
And please do something about your writing style (if that's really is
what's going on). I can only see it as ill researched and very
unfriendly; guessing what
happenend and saying people 'couldn't be bothered' and formats are 'ill
thought out', 'half-thought', without knowing anything about how/why/for
what purpose they were made is stupid.
Saying the inf/diskimage formats are not general enough and therefore
need replacing is fine with me, but not the way you say it.
Would you like it if I called UEF an ill thought out format? I can prove
it too, you've made a new version with some altered definitions of tape
blocks, so the old one was ill thought out wasn't it? I wouldn't be
surprised if it happened again.
Last from me on this, bye.
Wouter