Date : Fri, 24 Aug 2001 06:13:16 -0700 (PDT)
From : Thomas Harte <t.harte@...>
Subject: Re: ANNOUNCE : UEF Specification 0.9
Me again!
> With an interleaved, raw sector dump of a double sided disk, where both
> sides are half full, you get this:
I should have been more explicit - I was thinking of ADFS discs. The ADFS
treats one physical drive as one logical drive, with the effect that when
*COMPACT'd, an exactly half full disc uses exactly none of the second side.
> In a non-interleaved image, you'd see this:
[all of side 1 included so that it is obvious where side 2 starts]
That isn't true. The assumption has already been made that not only the disc
parameters (sides, sectors per track, tracks, MFM or FM) but also the
logical disc format (the DFS catalogue or ADFS free space map) are known by
the decoding software, or else not a single non-full image would exist. So I
know how many tracks of the first side are stored if the image is not full
length.
> If you don't agree that this makes sense, that's fine with me. I still
> think it was a pretty good choice, when all David needed for BeebEm was
> raw sectors.
And I still maintain it leads to plenty of wasted space for ADFS floppies,
and usually at least some for DFS.
> Thomas, you've made pretty rough statements about the people whipping up
> the formats that existed before UEF.
I think the recent and very long thread on netiquette and top posting has
made people far too sensitive. I have said that for the purposes of
emulation the formats are [ill/badly/half] [thought out/designed]. To which
people have disagreed by claiming either that the format wasn't designed for
that purpose or that it wasn't necessary to spend a lot of time designing
it. Which are the same thing, but with the added justification that those
who either did design the format or who were there at the time can have
above those of us that didn't or weren't.
I've also said the authors of those formats "couldn't be bothered" to design
something fully accurate. Which is slang for "didn't want to expend the
effort". The author of INF didn't want to expend the effort because, by his
own admission, he has no interest in emulation. The author of sector dump
images didn't want to expend the effort because he considered it a waste of
his time when all the games he wants to play were both crackable and already
cracked. So again, nobody has expressly disagreed with me.
All that is happened is that extra meaning has been read into my comments -
e.g. "badly designed" becoming the much more personal "designed by someone
who couldn't design a decent format if they spent their whole life
considering it".
> ElectrEm seems to be the emulator
> with the highest faithfulness to the original hardware,
Thats only because an Electron emulator that wasn't accurate to the timing
of the original would be near worthless and the implications spread. For
those who have never read about the Electron, the CPU is on a variable clock
rate, where the length of any one cycle is a function of the length of the
previous cycle, the memory address the cycle accesses (the 6502 accesses RAM
every cycle as a design simplification), the current display mode and the
current state of the video circuits.
> However,
> at times you do come across as arrogant and condescending towards the
> people who spent their free time on this before you. My guess is that
> this display heated up more people than Wouter.
Even within only this thread, how does that fit with my recent acceptance
that I was wrong on the topic of inlay scans in UEFs and my purposeful post
to the effect that a good agreed standard for storing extra information is
only going to come from group planning?
If I believe in trying to kill off 'old' data formats so quickly, why does
my emulator support more than any BBC emulator? ElectrEm supports these file
formats in the current public beta :
aiff, au, ssd/dsd/adf/adl/etc, wav, raw, uef
And will support both .tape and fdi in the next release.
> I admit that storing emulation related metadata (like ROM hints and
> target machine) in the XML is maybe not so smart in an UEF world, since
> that decouples those hints from the UEF. They would, however, be useful
> if the XML could equally well link to good old SSD/DSDs, or (say) ZIPs
> (or directories) of INFs.
Except of course that not only are INFs not intended as an emulation format,
but a quick check of the 'big 3' (Horizon, pcBBC and BeebEm) shows that they
simply aren't used by emulators.
Also, SSD/DSDs are less convenient for all PC people than FDIs now. If I buy
a new PC and additionally have a 5.25" drive added then I can download
working FDI conversion software already, but no working SSD/DSD conversion
software.
All I mean is that just considering INF, UEF and SSD/DSD (what happened to
ADF/ADL anyway?) probably isn't good enough unless you limit all 'better
than sector dump' images to UEFs which will work in the long term but in the
short term will mean people converting discs having to use other formats
such as FDI as an intermediate step in a tool chain.
To make clear for people who enjoy adding extra meaning to anything they
read : its a consideration I think should enter into the XML discussions and
no more.
> As XML can be lex/yacc'ed, that sounds like a good way to go. I've had
> a look at MSXML myself, and was horrified. I simply couldn't get
> anywhere before I ran out of patience. There must be simple, ready to
> use XML parsers for C++ out there, though. Anyone?
The W3C recommendation lists as objective 4 "It shall be easy to write
programs which process XML documents", so I'm sure something must exist. I
haven't looked extensively, but
http://www.oasis-open.org/cover/publicSW.html seems to be a good start for
considering the options.
-Thomas
_______________________________________________________
Get 100% private, FREE email for life from Excite UK
Visit http://inbox.excite.co.uk/