Date   : Tue, 22 May 2001 04:32:05 +0000
From   : "W.H.Scholten" <wouter.scholten@...>
Subject: Re: Tape reading/writing

[ thomas wrote ]

> It is chunk based and designed to store digital versions of pretty
> much all of the information that would have come when you bought a
> program in just one file. That means not only tape, disc and ROM
> media, but also inlay scans, game instructions, author credits, etc. 

And as I said in an earlier mail this is exactly why I don't like
the uef format: it mixes original data with emulator & other data, which
can be accomplished on a meta level (config files, that are used when a
certain file is loaded). That would also make it easier to replace scans
by other/better ones etc.

> The INF format is even worse since it can't store non-ROM format data.

That's not quite correct. The defined file types are disk/tape files,
that do not modify themselves while loading/saving, i.e. a proper subset
of block files in case of tape.

It would be asy to add tape images: use an identifier "TAPEIMAGE" and
nothing else (all else is in the tape image). old utilities will just
barf on this, newer ones should be able to say: 'can't transfer a tape
image' (for eg. transfer to a bbc disk), or show more information using
a tape decoder.

However, is this useful? In that case it would also be a good idea to
replace the .dsk disk format specifications (years old and noone
noticed), and add a DISKIMAGE identifier with trackno etc.

I think it would be better to keep them (.inf file attributes for a
single BBC file and images containing zero or more files) apart.

All in all, .inf works beautifully, it just can't handle files that do
not abide by the filing system rules. In those cases, you can use
cracked versions or use a 'image' format.

> The UEF format is knocking on a year old, and at least two large
> repositories of UEF files exist online

And noone seemed interested for years before that (e.g. the mail from
Mark Cooke to me the ML from 12 aug 1997 and the suggested 6502em
TAPEIMAGE support in .inf files didn't give any response (at least, I
don't remember anything)).

Btw, the diskimages in the formats used for the BBC are also not good
enough for proper emulation, as they do not store the head number for
example (stored on sector headers), and other information (and what
about format changes after a given track? I don't know what's possible
in BBC disk protection despite being co-author of FDC), which is why
protected disks need unprotecting too. So, for those who want the
original code, here too another format is needed... (making a dump for
that format would be annoying, imagine having to go through all possible
head values etc, trying to read a sector..., it would take ages).

All in all, I do not find unprotecting/modifying a problem w.r.t.
authenticity (prefereably the way it was unprotected should accompany
the files). In case of tapes, it's not too hard to actually implement a
method to use weird files, but for disk... Anyone up for this? It's
probably best do make a BBC side program that handles this (can't stand
DOS, so I'm not going to work on FDC anymore to implement such things).


Regards,

Wouter