Date : Thu, 23 Aug 2001 22:06:17 +0200
From : Isabel Cisternas & Robert Schmidt <rschmidt@...>
Subject: Re: ANNOUNCE : UEF Specification 0.9
Thomas Harte wrote:
> 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.
With an interleaved, raw sector dump of a double sided disk, where both
sides are half full, you get this:
sector 0, side 0
sector 0, side 1
sector 1, side 0
sector 1, side 1, and so on, until both sides run out of empty sectors.
Only very rarely does this go on until sector n-1, where n is the total
number of sectors.
In a non-interleaved image, you'd see this:
sector 0, side 0
sector 1, side 0
...
sector n-1, side 0
sector 0, side 1
sector 1, side 1
...
sector x, side 1
Where x is the last used sector on side 1. On average, you'll have
wasted about half a side worth of sectors. That is, if you've actually
*used* both sides.
Also note a second advantage of interleaving: The interleaved format
puts *no* requirement on the emulator's knowledge of how many sectors
are present, while the non-interleaved format requires you to know that
the disk that the image was made from had n sectors per side. My guess
is that this was the single most important reason for BeebEm introducing
this strategy - it simplified implementation and reduced user confusion.
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.
> 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.
I noticed! I've been looking for those for a long time! :-)
> [heated debate]
OK, guys, let's not get carried away. Wouter and Thomas, you have both
contributed immensely to the 8-bit Acorn emulation/preservation "scene",
and I'd hate to see things sour up because of your differences. You
have both made pretty strong statements, some clearly emotional.
INF and UEF are both very useful in overlapping domains. INF has the
advantage of being ASCII editable, plus that the accompanying data file
is an exact replica of the BBC file. Thus, it is *extremely* easy to
convert to/from INF (which was most of the intent).
UEF is clearly trying to cover a much wider ground - I've uttered a
couple of warnings that the ground was maybe *too* wide. I do however,
welcome any format that provides extremely true preservation
capabilities.
INF is simple, easy and "hackable", UEF is deep and thorough, but
practically only accessible through tools.
Thomas, you've made pretty rough statements about the people whipping up
the formats that existed before UEF. Take into consideration that
progress happens a step at a time - ElectrEm seems to be the emulator
with the highest faithfulness to the original hardware, with BeebEm
catching up (supporting different hardware, mind you). Without the
emulator support, why would somebody cook up a do-it-all format? All the
first emulator authors wanted was to 1) get a kick out of it, 2) play a
few (cracked) games and 3) let the community play some (cracked) games
as well. I doubt "preservation" was as much in their minds as it is in
yours.
You (amongst others) are taking the "scene" to the next logical level,
therefore I welcome your work and more sophisticated formats. 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.
I'll reiterate my hopes for the usage of standard and proven formats,
instead of reimplementing the infamous wheels.
I'm still in favour of using XML for most user-oriented game
information. As you say, this could safely be presented in HTML, but
then we're imposing a certain formatting on the data, and the content
only makes sense to a human reader. With XML, the file is used as a
database (not freak word processor output), and it is up to the emulator
(or emulator front-end, or even a *browser*), to present it to the user
in an appropriate manner. The emulator (or front-end) can easily skip
tags it doesn't understand. All binary data related to the game is
available through appropriately tagged links, be it docs, scans, disk or
tape image. I think Mark de Weger's work on BeebEF should be a good
source of inspiration.
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.
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?
That's enough ranting for today. Remember, we're mostly in this for the
fun of it! ;-)
Cheers,
Robert