fiath

I doubt very much they would ever do something like that (but I don't blame them). If we want a public raw dump repository we would need to arrange for that by ourselves. I support them being public as I said before. It's not our data after all. Anyway, we need to update our server, so having an alternative location for them to reside would be useful for us too.

Yes as ijor said. We have a special option to reverse the bitstream on the second side. To can learn more about this here, as well as the drive mod: http://forum.kryoflux.com/viewtopic.php?f=2&t=253

It shouldn't, but annoyingly we are currently have some technical problems with our FTP, which may take a little to sort out. Maybe somebody knows a convenient alternative we could all use in the interim?

I think the default retry count is 3 or maybe 5. It's surprising how many disks have read errors the first time only to work on the second or third. I'm sure it is something you would want to be careful of on many older disks though, sure. I've heard of various very old audio recordings that have to be baked to secure the magnetic layer, and are destroyed as the read head passes over it. A one-try deal... So sad. Yes, that sounds like a good idea.

That's interesting! Perhaps we need an integrated option flip them back...

KryoFlux reads the disk at the flux transition level, so these things are mostly irrelevant fortunately. The best technique is to dump to stream files as well as the normal Atari 8-bit in parallel. KryoFlux uses the Atari format to verify the sectors that are legally formatted (and so can retry bad tracks), and the raw flux transitions can be saved in the stream file (and inspected, or used in emulation, later). Easiest thing to do is use the user interface. You just select stream files (or better, click on "multiple" and ctrl-select stream files as well as your Atari format).

I'm sorry about that. I will check up on it for you. I am sure they were received, we have just been (well, as always) extremely busy and our communication sometimes suffers.

Well, technically you can copy a disk "blind", but it is not very reliable. Certainly not good enough for preservation, particularly as you should be able to verify if the data is correct, and not modified. If we "describe" the disk in our tools, we can write back basically any software protection (via IPF), and we even do that for weak bits on existing games. This kind of description was what was needed when the disks were originally mastered - so we are basically doing it the same sort of thing. Hence why we call IPF a mastering format. Well, it is a bit more automated than just manual identification. We need to train our tools to understand the formats used, and when that is done our software can automatically detect most stuff. Things like fuzzy areas show up nicely too. But we need to be sure we get a large sample of software so we can be confident that we have covered minor variations. Yes, I know what you mean about software-only controllers... We did the Amiga first for a few reasons, and that was one.

Mainly we need a decent collection (usually a couple of hundred, depending on the platform) of raw disk image samples for our research. We can then research the formats, common protections and such things. Atari 8-bit has an additional difficulty of flippy disks. To dump those at a raw level, you need a modified drive. We're currently trying to buy up lots of the games (with some great help from some people here) to image using the modified drives we have. But it's sadly a very expensive business...

That's kinda the problem actually. SPS can't start producing IPF's for Atari 8-bit until we have enough images to do the appropriate research for the platform. We can't do that alone. We have some help, but we need lots of support for the each community in order to get things rolling. As to whether KryoFlux is useful for Atari 8-bit, it really depends what you want to use it for. For writing images, then yes, clearly it is not appropriate for that at this time. However, if you want bit-for-bit images of what is on the disks for preservation purposes, then I think it is ideal - that is the very reason it was created. For a supported platform, creating IPFs is mostly automatic - mainly it is a process of verification and double-checking - and that requires a lot of technical knowledge and familiarity with our tool chain. Of course, the initial support for the platform needs to be done, and any formats and copy protection not seen before would need more work.

I don't really know much about the XFD format, but given it is a "sector"-based image format, I wouldn't think so. Writing IPF images is easy (using KryoFlux). Producing the IPFs in the first place is hard. The Software Preservation Society currently does that for Amiga, Spectrum, Amstrad and Atari ST. There are no IPF images for 8-bit Atari yet (at least not from Softpres).

XFD - High level "sector image" format for Atari 8-bit. The contents of each block on a legally formatted disk. ADF - Same as XFD, but for the Amiga format. IPF - Mastering format, similar to how the disks were originally mastered. Intended to contains and describe any copy protection on a disk. Yes, as long as the disk doesn't have any physical protection (physical holes, etc.), you can back up to KryoFlux's low level "stream format". This contains any copy protection on the disk. You should know though that there are fundamental problems writing this kind of "raw read" back to disk (no matter what device you use) - kind of similar to the sort of problems you get copying VHS tapes. However, once you have the data in stream format, it is possible to use it in emulators, it is also possible to write it with some technical know-how (you need to know "how" to write it). That's just the problem you get with copy protection, whatever device you use to read it.

KryoFlux can read to XFD images, but can't currently write them. It's write support is currently limited to IPF and ADF, though more are planned.

Nice! I fired that up in the GUI: Are those original disks you've dumped? BTW, if you specify the image type for this (-i3a) you'll get error checking, and it will retry any tracks with errors.

I agree completely. I've had many discussions with developers over the years who felt differently, though. One of my favorite arguments is "documentation lies." I've also seen that argument used to get out of properly commenting code Depends what they meant. When people usually say things like that, they mean that they think you should write code so that comments are less useful. That is, your code is readable without comments. E.g. the usual stuff like composing small methods (your domain "primitives") into a more-meaningful higher level language. Of course, with something like IPF, while code is better than nothing, what it really needs is a spec. Giving you a high level view to guide you though the format - an insight into the code. A spec is definitely something we want to do, it's just a question of getting the time to do it (properly). IPF is not a simple format (it can't be simple, it is a disk-format-generation - mastering - format). However, I think the comments as code idea still has merit. Write your code so that comments become less useful. You probably still need them of course. This is absolutely spot on (and some other related points). However, in the end, we thought that we were hurting ourselves, our preservation goals, and the cause, more than any good it was doing. Actually, we thought that for a long time, but couldn't find a license we liked.