Software-based floppy disc data separator
classiccmp at philpem.me.uk
Thu Jun 17 20:42:25 CDT 2010
On 17/06/10 21:27, Kieron Wilkinson wrote:
> 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,
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).
> 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
Hmm. I haven't seen (m)any emulators with IPF support -- AIUI, it's just
> 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
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 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 :)
> 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.
classiccmp at philpem.me.uk
More information about the cctalk