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.

Well that is nice to hear. I should note though, that copy protection is not the only reason for doing low-level images. For example, at the Software Preservation Society, we require that information see if a disk has been commercially duplicated (important when seeing if a game is authentic), and has not been written by more than one different drive (to ensure it has not changed since mastering). Another reason is that sampling a disk in this way, you can often retrieve data that the original machine could not. Not if the data is really bad of course, but in our experience many errors tend to be reading problems rather than actual bad data. Coming from the Amiga world, we have actually managed to preserve quite a few titles that no longer worked because of the protection. Dungeon Master being a famous example. It used an invalid encoding, which no longer worked on the original machine, but we were able to recover and preserve it using a low level technique. Not always appropriate, but something to consider for commercially mastered disks.

We refer to them as "sector formats", i.e. normal sector-by-sector images. I only used the term "emulator formats" because the other guy did

Sign up at the website at kryoflux.com. That will put you in the queue, so to speak. When boards are available, we first mail those people to give them first opportunity. I expect the price will be the same as it is now. As to drives, we recommend your normal HD PC drive for 3.5". It should work with any Shugart compatible drive, but we have the best results, and the device has been tested the most, with your usual HD drive. Also, I don't know if your dual drive is the same (it may not be), but in general we have found that dual drives are not the best quality.

You can do, but the usual emulator formats of course won't be able to hold any copy protection. We are developing a standard format for that (the one we have is more of a hardware protocol), but it will need to be supported by other tools (e.g. emulators), or, if they are games, you can send the raw files to the Software Preservation Society who can create IPF files that are more suitable for emulators.

The next run should be complete in April hopefully. Our manufacturers are very busy at the moment though, so that might slip into May. You don't need to change the drive speed with a KryoFlux btw.

Might also be worth mentioning that KryoFlux allows you to read disks written on a 300 RPM drive in a more commonly available 360 RPM drive...

KryoFlux does indeed support the TI format. It even can do "hard to read" sectors. See this thread: http://forum.kryoflux.com/viewtopic.php?f=3&t=112 Your right it doesn't support all floppy drives though. We made the decision to focus getting the most commonly available drives working really well, that being Shugart-compatible PC drives. If the TI drives is Shugart compatible (?), it would hopefully work. There are some TI people in our forums (same link as above), so might be worth asking in there.

Well, our primary interest is preservation, so we are very interested in making IPF files for all systems, but obviously we would like help with this! If emulator authors provide support for DRAFT, you could load them directly, my only point is that your success in that is likely to be mixed. It should work for most disks, but there are lots more technical problems than the IPF route. As for writing, that is something that still need to be done, but yes, it is planned.

An IPF file is a description of the disk data, and what that data means. It is similar to how the disks were originally represented for mastering, since you need to know what you are writing in order to make that writing reliable for reading. For IPF, this helps for emulation, and will always work (assuming the emulator is up to it). KryoFlux does not provide IPF files, it provides a raw stream of flux transition timing. Eventually, this will be a standard open file format called DRAFT, which can be supported in emulators, my only point was that it won't have reliability guarantees like an IPF would. We can use DRAFT files, which will give us the information we need to verify they are good (both integrity-wise and authenticity-wise), and generate the IPF file. Also, a DRAFT file is complicated to process. You don't even know what bitcells are yet! So as I said, emulator use is possible, it's just more complicated. We provide a library for IPF files that provide the emulator with the data they need. Single-sided 5.25 disks - great. That will definitely make things simpler. IPF files for Apple II would be in the region of 200 KB - 500 KB I guess, depends on how much of the disk is used. DRAFT files for Apple II might be around 12-15 Mb I would think. Your collection sounds wonderful! No need to worry about save games -we specifically check for that. Because of the differences between systems, we can see if there are any modifications to the data. It's excellent you used copies of the disks to play - I wish I had been as disciplined! As to building KryoFlux, that is exactly what we had been hearing. In fact, I personally didn't want to build one either. We didn't actually want to go to the trouble to get the manufactured, but to get them out there, it seems the only way. Anyway, if anyone is interested they can help us predict the numbers to make here: http://www.kryoflux.com

Yes, you can indeed read Apple II copy protected disks. However, if you want to be able to read the second side of "flippy" disks, you will need a modified drive. This is something we are working on. We at the Software Preservation Society (http://softpres.org) are very interested in preserving Apple II software, and if you are interested in getting a KryoFlux device, it would be wonderful if you could help us with that. As to implementing support in Applewin, that would be superb! Having said that, it would probably be easier to help us with the preservation so we can represent the games in IPF format, and have Applewin support that. The raw flux transition timing files are very big, and we do lots of checking to ensure that the disk does not have errors, and has not been modified after the original mastering.