Date : Mon, 13 Aug 2001 12:12:34 -0700 (PDT)
From : Thomas Harte <t.harte@...>
Subject: Re: ANNOUNCE : UEF Specification 0.9
Mark Usher :
> I must admit I shy away from linking to here and there. As you have no
doubt
> observed the net is such a fast moving place. Just a change of service
> providers would mean a new URL for the Documentation project for example.
Well, I was thinking more of URLs of the form 'file://' without removing the
option for an ftp or http or whatever. Also I gather the modern zip handling
programs allow you to open a zip as a virtual directory to run things from
rather than just expanding to a temporary folder the single file you double
click on, so this form combined with those modern programs would be able to
handle 'everything in a zip' with no further work. Certainly I can't see any
other viable way to do 'everything in a zip' while including PDFs and things
like that.
> Wouter did start to use a text file to contain information regarding the
> .ssd/.dsd files, and it is something similar to this that I can imagine
> being most helpful. Something like
>
> <BBC PACKAGE>
>
> <FILES>
>
> <FILE>
> <NAME>$.!BOOT</NAME>
> <LOADADDRESS></LOADADDRESS>
> <EXECADDRESS></EXEXADDRESS>
> <TYPE>ASCII</TYPE>
> </FILE>
>
[etc]
Wouter seems to be the king of ASCII packaging! For my money, if ASCII is
the aim could we stick with something that can be Yacc/Lex'ified? With
something as simple as that shown above development would probably take
longer with something as simple as that shown above, but things tend to grow
in complexity. Look at horrid, horrid INF files.
But then, if 'everything in a zip' is combined with 'ASCII file for defining
what is present' and 'established file formats for established external
programs' I'd rather stick with HTML and hyperlinks than XML and embedded
meta data since the lower limit of the sort of system the prewritten
software capable of 'doing XML' targets compared is higher than that which
any of the emulators target, whereas with HTML that isn't the case.
Richard Gellman :
> I see the UEF as an interesting (yet still young) medium. IMO it handles
> tape images perfectly, which I think is what the UEF file format has
become
> to primarily represent. However I see no reason why it can't contain other
> information.
[cut]
> UEF is probably pretty pointless for inlay scans, rom images, and disc
> images as standard working formats exist for these. Altough it'd be
> interesting to see a ROM image format that can deal with the Interword
logic
> switched double ROM, and non-standard disc formats (protected and such)
are
> still a new concept in terms of emulation (at least in BBC emulation).
Presumably that ROM has a register somewhere in its address space for
internal paging? A general form of that would be trivial to add to the
format.
As for non-standard disc formats - the new 'completely accurate' disc drive
emulation in ElectrEm is now at the level of all type 1 commands (seek,
restore, step, step in, step out) + read sector, and so should be able to do
all protected discs that just mess with the data after the id mark (which
I'm willing to bet is most) or relies on non-standard sector ordering (e.g.
interleaved for greater storage capacity) or an increased number of tracks.
Within a week I reckon I'll have write sector and read/write track running
which means even those really devious programs which hide data in the gaps
or things like that should work. I don't think beta 10 of ElectrEm will
support writing to FDIs, or possibly any beta, but fully accurate writes to
UEFs will be implemented.
Just out of interest, who came up with the plain sector dumps with disc size
implicit from extension idea anyway? I mean it sounds like a 'quick fix' but
if you add the amount of time some people must have spent hacking protected
software to get it to convert it sounds like an idea that has generated
substantially more work, not less.
But on the topic - does anybody have an example of some protected software
that would run on an Electron so I can do some proper testing? And also, am
I right in thinking that the DFS ROM's determing FM or MFM disc types by
simply trying both? At the minute I've not fully implemented FM support so
the emulator happily loads MFM discs with either mode selected causing 1770
DFS *CAT to report FM operation, which is why I ask.
And does anybody know how a disc drive reacts with no disc present? The
WD1770 datasheet doesn't seem to think any alternate action is taken
depending on the state of the ready line so I assume it goes ahead and sets
the motor on anyway, but then not only will no data be found but I'd imaging
no index hole pulses (you know, assuming the motor ignored the motor line
and didn't start) either so according to the datasheet the WD1770 will enter
an infinite loop which can't be right.
> I think the option to have some ascii information embedded in a UEF tape
> image could be useful, if the emulator is willing to decode it on loading.
> But anythng in which a working format already exists for doesn't need to
be
> in the UEF file.
Personally I'd keep at least 'origin information' and maybe switch 'game
instructions' to 'controls summary' (for quick reference - really useful for
flight sims!) with respect to ASCII data. Then the only thing UEF contains
which anyone could possibly object to is the inlay scan chunk, which it
seems is universally agreed should go.
At the minute I oppose any suggestion that the 'target platform' and 'ROM
hint' chunks should go, but if anyone has a convincing argument . . .
> Of course, one thing to bear in mind is that all of this is _optional_ in
a
> UEF file. The creation of a UEF file does not assume that all this info
> _must_ be there, it just can be if the author so wishes.
Although this thread has already seen 'I thought binary chunk based formats
had gone out by now' (a paraphrase from Robert Schmidt) so even the
implementation of that isn't universally popular! Personally I think that
type of thing when the chunk header has complete continuity works very well.
-Thomas
_______________________________________________________
Get 100% private, FREE email for life from Excite UK
Visit http://inbox.excite.co.uk/