17 Jun
2010
17 Jun
'10
6:42 p.m.
On 17/06/10 21:27, Kieron Wilkinson wrote:
Wasn't the original reason "we don't want badly-made IPFs floating
around the internet and ruining our reputation" or something like that?
(If not.. well, it's the impression *I* got).
Hmm. I haven't seen (m)any emulators with IPF support -- AIUI, it's just
UAE.
I guess I'm going more for the sort of person that would buy a
Catweasel, but wants to use it on more modern computer equipment, or
image discs "on the go". Effectively something to solve this situation:
1. Bob has a computer (say, an obscure CP/M box) without a boot disc.
2. Alice has the bootdisc but needs it for her machine.
3. Alice can't duplicate the disc on her machine (say, because the
machine is incapable of copying its own boot media)
4. Alice is, however, happy to allow Bob to visit with a floppy drive
and a laptop to copy the disc himself.
So Bob hops on a train with a laptop bag containing:
A laptop
A DiscFerret
A power supply
A cable kit
A floppy drive.
Bob visits Alice, copies her disc, tests his copy on her machine, then
he can use the XDIF image to figure out:
A) what the disc format is (NEC765, Amiga, H89, ...)
B) the format parameters (sectors/track, tracks/surface, #surfaces)
C) how to remaster it and make a 'better than new' copy
So like the CAPS system, but with the 'analysis' side of things handed
off to the users... If the user in question doesn't know how to create
the image properly, they can pass the dump along to someone else to
convert into, say an ImageDisk image, IMA file or whatever.
The main thing that irks me about the CW is that Jens (Schoenfeld?)
basically said "I'm done with this" and ditched it. The Linux drivers
won't write discs on anything past Kernel 2.4, and IIRC the Windows
drivers won't work on anything newer than Windows 98... that's pretty
pathetic. Which is why I started working on the DiscFerret. Yes, the
name is a subtle jab at the CW :)
We had some very nice conversations with you from what
I can see, so
I am not sure why you now perceive us in a negative light?
OK, a few reasons:
1) A couple of months ago I had a look at the first 'ticket' / thread I
started with you. As I recall that's basically showing "ticket closed,
content not visible." -- Annoying, there was some useful info in there
and I don't have the confirmation emails.
2) The sheer lack of info in the WIPs. For instance, the stuff that
introduces Freeform. How about a couple of example Freeform scripts?
Maybe the text or a PDF of the Amiga DevCon notes mentioned?
Maybe your
comment above "we can't tell you" (I don't think we said that?)
I don't think you said it in as many words, but I got the impression of
SPS having something of a "secret society" aspect to it. A lot of the
more technical information (for instance, I'd like to know a little more
about how Copylock works and how you can read an RNCL track and get the
checksum or take the checksum and remaster the track) seems to be "under
lock and key" so to speak.
is because we have not yet given you the DRAFT image
file specs yet. If
that is the case, we're not being obstructive, the reason for it is
simply because the format doesn't exist yet...
Ah. I got the impression (from the WIPs) that DRAFT had been implemented
in the Kryoflux design already...
Mmm. Not
releasing the IPF file format info is pretty inexcusable.
You are of course absolutely right in this regard. We have known
since the beginning that it was a pretty ridiculous state of affairs
for a image format intended for preservation (we have publically said
this in multiple places elsewhere). Fortunately the reasons behind it
have disappeared over the years, We wanted to do a few
other things first (like being able to show that an image really
comes from us),
Distribute it with a GnuPG signature file and put your GnuPG key on the
keyservers. Problem solved.
I should state here (as we have confused people on
this before), that
IPF is a *mastering* format. It is similar to how Trace prepared disk
data for writing, where they had the disk data but also scripts
describing checksums, data formats, protection, etc. - since you need
to know how to write the data (especially copy protection) for it to
be reliable (or of course work at all, for some types of protection).
I was working on something similar for the "write" side of the
DiscFerret. It's more or less ground to a halt though; I wanted to have
a look at Freeform, but hit a brick wall: the hardware is NLA, and even
the last company that's supporting Trace kit doesn't seem to mention the
Unix-box-and-autoloader duplicators, just the tin-box all-in-one units.
It is designed for writing, and that is basically what
happens when
an IPF tracks are loaded in an emulator (just not to a physical disk
of course). IPF is a very different thing to a dump format, and I
would say that for most non-preservation purposes a dump format is
fine (and also has the advantage of being simple).
XDIF (the DiscFerret storage format) can do either dump-type or
mastering-type depending on what Tags and Blocks are present in the
file. You can have a "TRAK" (track) block which contains a "SCPT"
block
and a bunch of "DATA" blocks -- that's a mastering script and data.
Alternatively you can have TRAK, TINF (Track Info), and RDAT (Raw Data)
blocks which would be a raw dump.
don't seem
overly keen to work with open-source teams outside of
the UAE developers (what few are left).
I am not sure where you heard that, because we are doing that right
now, and have been for some time (off and on for a few years in
fact). Our analyser constitutes several thousand hours of
engineering effort
over the last 10 years, and comes out of many years of research and
development done before that, so to be completely honest with you, I
can't see us making that available for free any time soon.
Fair enough. It would be nice to have some technical papers on the
decoding engine, format-ID, and copy protection analysis engines
though... I've read tons of stuff on Copylock, but it all boils down to
"this is where you put a BPX to sniff the encryption key, and this is
where you grab the decrypted gamecode."
The proof is in the pudding - you can try it yourself
if you have
an ARM7 development board.
Don't have one, don't want one. Not for one project, anyway.
We said from the start that source will be
available when everything is finished and we move out of beta, feel
free to complain then if it's not.
:)
I'm planning on making the DiscFerret API a little more universal across
hardware. Maybe when the Kryoflux hardware is 'stable' I'll look into
buying one of the finished boards and add support to the library.
Also, I would
pay good money to see a Kryoflux board imaging an MFM
hard drive. The DiscFerret has had that feature from the get-go :)
Sounds neat. :) We're coming very much from the preservation of
consumer software angle, and KryoFlux is primarily built to solve
problems in that area (we need it ourselves in this regard). Given
that we're aiming at common use-cases, I guess this is something that
might well stay unique to you - diversity in our solutions is a good
thing. I have to say that I'm a bit surprised to see the
rather negative
sentiment in your post Phil, it's very different from the
conversations we have had with you. I don't really understand the
reasons for it, but perhaps we can all just try to get along? We're
all fighting on the same side after all.
Well, in this instance I'll take a rather large helping of humble pie.
I've got the wrong end of the stick, and for that I apologise.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/