Date : Sat, 25 Aug 2001 00:48:23 +0200
From : Isabel Cisternas & Robert Schmidt <rschmidt@...>
Subject: Re: ANNOUNCE : UEF Specification 0.9
Thomas Harte wrote:
> 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.
OK. Whether ADFS or DFS disks are most common, I'm not qualified to
discuss.
> 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.
I don't understand your point here. Of course, BeebEm makes lots of
assumptions about SSD/DSD files. For DSDs, it's convenient to not have
to know the total number of sectors per side.
> And I still maintain it leads to plenty of wasted space for ADFS floppies,
> and usually at least some for DFS.
Yep, I didn't have ADFS in mind. Whether David did, I can't say.
> 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.
See my reply in another thread. I don't think any previous discussion
is affecting this. Personally, I'm affected by your choice of the words
"[ill/badly/half] [thought out/designed]", all 6 combinations of which
seem rude considering the rather narrow scope of what people have been
trying to do.
> 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.
I disagree with your attitude and choice of words - further strengthened
by the above paragraph.
For my own part, I'm impressed with what a relatively small 8-bit Acorn
community has managed to whip up during the nineties, practically all
efforts unpaid.
> 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".
No, you're saying somebody didn't do the job properly because they were
lazy and/or disinterested. Do you think that's too much of an extra
meaning to read from your statements? Can you understand that people
get emotional?
Is it so hard to just accept that these are shortcuts often taken in
order to reach an immediate and more interesting/fun goal quicker? I
can perfectly understand that an emulator author is happy with playing a
cracked game off of a plain sector dump image. Most of the community is
also happy with it - I can't remember having seen a single request for
more faithful hardware emulation to cope with real copy protections and
such. (But then I'm not an emulator author... :-)
You do seem to posess a rare and very commendable drive for perfection,
but it is not nice to criticize others' lack of this drive, when their
own drive has already done so much.
> > 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?
What's your point? You've done one good thing, so therefore people
should think you don't do bad things?
> 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 : [impressive list]
You're missing my point. Now that we have and are getting software that
can handle truly preserving formats, I welcome these formats. I don't
really care what happens to INF/SSD/DSD, as long as what replaces them
works better. What I resent is the ridiculing (extra meaning?) of the
people who did more or less great contributions to BBC emulation before
you.
> 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.
See my reply to another thread. pcBBC didn't exist, Horizon used a
"multi-files-with-headers" format, and as Richard points out, BeebInC
supports INF natively.
> 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.
Don't forget that thousands of discs have already been turned into
SSD/DSD - since that happened, the discs may be rotten and not FDIable.
> 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.
I feel that we have *four* pretty distinct discussions (in no particular
order):
* How to best represent product metadata (connecting copyright info and
trivia with URLs or inline text for docs, scans, maps, cheats, binaries)
- XML is my choice numero uno.
* How to best represent product auxiliary[sp?] data (documents, images,
documentation) - I suggest at least accepting web browser standards:
HTML, GIF, JPG, PNG, plus PDF. This also touches on the magazine
scanning thread (TIFF? DjVu?).
* How to best represent product binary data (tape, disc and ROM
images) - UEF can do it all (combined with FDI), there are, however,
legacy formats that should be taken into consideration. There should
also be room for future, better formats.
* How to distribute all of the above information on the web, allowing
users to search, upload, download, synchronize and share.
> haven't looked extensively, but
> http://www.oasis-open.org/cover/publicSW.html seems to be a good start for
> considering the options.
Thanks! I'll have a peek.
Cheers,
Robert