Date : Thu, 23 Aug 2001 07:02:56 -0700 (PDT)
From : Thomas Harte <t.harte@...>
Subject: Re: ANNOUNCE : UEF Specification 0.9
> 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).
That you had to send me your code proves I genuinely found the definition
confusing. I didn't mean the format was ill-defined in your head, I meant it
in the sense of in the public arena - also known as the world of links that
say 'specification for standard archive format' and not the world of people
guessing which packages also contain informative source.
> 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.
Well, okay, then you reread my previous post. I was complaining about INF
and sector dumps being a poor way to make a digital copy of the original
file medium, and the assumption that these formats are good enough for that
task to be a strange one. If your format was never concerned specifically
with that area then it isn't a great surprise.
> 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.
Okay then, INF is a data exchange format. And the data I am concerning the
argument with is that data which is executable on an Acorn micro. Which I
think implies using some form of emulator, wouldn't you say?
> Btw, if you've got a disc with many programs on it, you get a similar
> problem...
Until I press shift+break I do. But of course I understand your point - at
least notice that your offer more than one way of communicating the data
whereas shift+break is exactly one.
> In one case you get one file, in another more files. And?
For the non-technically minded this is confusing.
> 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).
I said the argument for those forms being a better way to store image data
wasn't tenable. Which it isn't.
> 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.
I was defending what seems to be my singular push for the adoption of more
rigourous image formats amongst the Acorn community. Have many (quite
forward sighted) people defended that on the list before?
> So what? Some (many) emulators use invalid opcodes to break out
> emulation for example.
Of course, as you say emulators aren't an intended application for INF files
anyway.
> 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.
Now, I've seen conversation about this one on the ML before (check the
archives!) and as I understand it, discs are read in an interleaved format
for the obvious reason of saving track stepping time and are then
additionally saved in interleaved format because its easier to code in
assembly language - which the intial set of tools were coded in because of
the programming the hardware considerations.
In 1996 the average hard drive size was probably half a gigabyte on new
computers, and I was certainly able to run one of the older emulators on my
early 486 with only a 120mb hard drive. Suppose I have just ten double sided
ADFS discs I want to use, most of which are approximately half full. With an
interleaved format I lose about 1/12th of my hard disc. With a
non-interleaved format I lose only about 1/24th. I cannot believe that this
decision was a result of careful consideration.
> 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 :)
But when posting on a mailing list everybody is listening, so I'm not
telling you, I'm making sure everybody is aware of the justification. I'm
actually very glad you bought it up on the mailing list a few months ago
because otherwise it would have been a lot harder to find the related bug my
emulator had for a short time just recently!
> And what's this 'can't be bothered' talk? Are we going to do a flame war
> or something?
No, its a colloquialism.
> 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.
Both of which are subjective. But it seems that if I start off with a post
about why some formats are not good as media images particularly to emulator
applications, and you tell me how it is not surprising since those formats
are not necessarily all strictly targetted at emulators then very little of
an unfriendly nature has occurred.
> 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?
Perhaps an argument in my favour for poorly defined? How well a format is
defined depends on the documentation available, so if the documentation is
not to be found then the available condition fails.
> 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.
The list may not be, but the thread is about storing executable programs on
non-native machines. Surely not every posts has to map to every one of the
readers?
[origin]
> That should give a clue (had some discussions with Robert, but yes I
> decided on this).
Again I should point out that my post was more about sector dump images than
INF.
> 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?
Without a hint of irony - yes. The sales figures back me up, as everyone
points out Superior software sold more Electron tape games than any other
format/medium, but that BBC disc games were second.
> 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 received such a complaint, which caused me to put all the bitmaps, fonts
and so on associated with the emulator into one data file. It has been made
clear to me by an employee of Pace that contracting the system ROMs into
there also would make legal trouble mildly more likely. It was also
requested that the config file be made a seperate ASCII file by the emulator
of a front end. Which only leaves the keymap configuration files, but I'll
run a quick poll amongst the users if you think it would seriously be an
advantage.
> 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.
Its worse than that - its a state snapshot *gasp*. Because, and you'll love
the way I'm helping your side of the argument with this one, the tools
weren't mature enough to work reasonably with tape images.
> 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.
UEF has never been born as an exchange format! But, if it helps the argument
at all, the most recent two UEFs to be added to The Stairway To Hell were
added on the 13th of this month (ten days ago) and are of 'Time Lords' and
'Islandia', neither of which have previously been available in any form.
However, you maintain INF is a format for BBC style information exchange
between various machines, including the BBC, and not an emulation format.
However as time goes on the original machines die and the emulators grow in
prominence, so would you not agree that such a format is going to face a
natural decline when faced with those tailored for emulation no matter what
the design? We're all dying.
> 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.
If you know about all the games ever written then good for you, but since
creating a protected format which stores more data on a disc than a standard
format it is simply not true to claim that it is impossible to write a
program which cannot be cracked and stored on a normal floppy.
> Please don't be condescending. I'll do better though: there was no
> debate.
I think you misunderstood to what I was referring. The UEF debate has
subsided into the best way to store extra stuff - e.g. Robert's cddb styled
suggestion or the continued XML related talk. I was surprised that the
strictly UEF part of the topic had seemed to stumble on.
> 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.
Indeed it would be. But what about saying that the formats appear as 'ill
thought out' or 'half-thought' to a particular component of their audience?
> Saying the inf/diskimage formats are not general enough and therefore
> need replacing is fine with me, but not the way you say it.
For the rest of the post you've championed the idea that they don't need
replacing, just superceding, so I suppose someone could draw issue with the
way you say things also.
> 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.
Of course it is plain to see how the opinion that UEF is an ill thought out
format can be formed. It is also plain to see how it is being actively
developed to be as friendly to as many people as possible - the changes come
after consultation with others including comments made by yourself. You've
admitted privately (which before you claim is an insult of some sort refers
strictly to the medium rather than the intended audience) that the INF
specification was at one point ambiguous, but you fixed it and it has
stabilised. Should all formats besides your own be perfectly formed from
birth?
Also - if the tape chunks change again it won't be at my behest.
> Last from me on this, bye.
Until in about half a year someone says 'I'm a bit confused about this
element of INF' or 'where would I find an INF archive, all I can find are
SSDs' and you pop up to say 'we've already discussed INF at length, and I
don't intend to again'.
-Thomas
_______________________________________________________
Get 100% private, FREE email for life from Excite UK
Visit http://inbox.excite.co.uk/