VAPI Image back to disk

[Bryan]

Obviously, this indicates there's a difference between recording flux transitions and sending a track to the drive or Kryoflux would copy any disk perfectly without intervention.

 

So, I'm guessing that some types of protection require manual identification. This has traditionally been the case with Fuzzy sectors since they return something different each time (that is, you can't just turn around and write what you think you read). The good news is that the A8 uses a WD FM/MFM controller and therefore will always require some sort of coherent sector formatting (unlike software-only GCR controllers which can do almost anything they please).

 

I've read a bit about an advanced analysis tool for Kryoflux. Is this required to progress from here and what is its cost?

 

-Bry

 

EDIT:

This is interesting (these may be ST, but they're for the same type of controller):

 

http://www.atari-for...=21709&p=195487

 

http://forum.kryoflu...c.php?f=7&t=286

[fiath]

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...

[fiath]

Obviously, this indicates there's a difference between recording flux transitions and sending a track to the drive or Kryoflux would copy any disk perfectly without intervention.

 

 

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.

 

So, I'm guessing that some types of protection require manual identification. This has traditionally been the case with Fuzzy sectors since they return something different each time (that is, you can't just turn around and write what you think you read). The good news is that the A8 uses a WD FM/MFM controller and therefore will always require some sort of coherent sector formatting (unlike software-only GCR controllers which can do almost anything they please).

 

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.

[Bryan]

Well, I have a lot of original games and can certainly start making images if it will help.

[Farb]

I've tried twice over the past couple of months to submit my collection of 200+ Kryoflux Atari images to SPS and never got any sort of confirmation they were received.

[kenjennings]

Let us know how it does! My luck with hardware "Bit Copiers" was poor except for specific "extra-long" tracks.

The Kryoflux certainly looks interesting! (I'd never heard of it.)

-Larry

 

I got kryoflux set up, and it appears I've been able to image my most important working 360K DSDD floppy (Mac/65 assembly, all my working code, etc.) using kryoflux and a generic PC 1.2M floppy drive.

Oddly, neither Atari-specific format would work properly (FM or MFM). Errors on every track. Imaging it as a generic MFM disk worked fine with all the parameters specifically set for proper number of tracks and sector size. For reference (and so I don't lose it )

 

C:\Users\root\Desktop\kryoflux\kryoflux_2.0b9_windows\dtc>dtc -g2 -z1 -k2 -e78 -fmdml4_2.dsk -i4

 

The problem is it generates separate dumps for each surface, so now I have to find a way to fold them back together and turn it into an ATR file. I think I smell C code in the air.

 

04/10/2012 10:04 PM 184,320 mdml4_2_s0.dsk // 720 sectors * 256

04/10/2012 10:04 PM 184,320 mdml4_2_s1.dsk

[kenjennings]

On further review, having moved the kryoflux disk dumps to a linux box where I can get a good view of a hex dump, it appears all the bytes of the atari floppy have been XOR $FF. All those empty sectors that should be filled with $00 are filled with $FF. Weird. Not sure why that happened.

 

I dissected the first bytes of a known bootable disk created with the APE Prosystem from an Atari drive, with one of these Kryoflux dumps (after un-XOR $FF) and the data matches, so I should be able to reassemble the disk dumps into a working ATR file.

[BillC]

On further review, having moved the kryoflux disk dumps to a linux box where I can get a good view of a hex dump, it appears all the bytes of the atari floppy have been XOR $FF. All those empty sectors that should be filled with $00 are filled with $FF. Weird. Not sure why that happened.

 

I dissected the first bytes of a known bootable disk created with the APE Prosystem from an Atari drive, with one of these Kryoflux dumps (after un-XOR $FF) and the data matches, so I should be able to reassemble the disk dumps into a working ATR file.

IIRC Atari 8-bit disk drives write data inverted and then reverse the process when reading, which the Kyroflux drive wouldn't do.

[malers]

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...

 

What are the exact options for DTC-tool for copy protected Atari 8 bit disks, which create the stream-files SPS needs?

I think most copy-protected disks are SD/SS, 40 Tracks, 128 Bytes per sector, 18 Sectors per track. The protection itself can be of course long tracks, short sectors, fuzzy sectors, bad sectors.....

[Bryan]

IIRC Atari 8-bit disk drives write data inverted and then reverse the process when reading, which the Kyroflux drive wouldn't do.

Yep, it's one of those little idiosyncrasies you wouldn't know about unless you looked into the drive internals.

[fiath]

I've tried twice over the past couple of months to submit my collection of 200+ Kryoflux Atari images to SPS and never got any sort of confirmation they were received.

 

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.

[fiath]

What are the exact options for DTC-tool for copy protected Atari 8 bit disks, which create the stream-files SPS needs?

I think most copy-protected disks are SD/SS, 40 Tracks, 128 Bytes per sector, 18 Sectors per track. The protection itself can be of course long tracks, short sectors, fuzzy sectors, bad sectors.....

 

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).

[fiath]

IIRC Atari 8-bit disk drives write data inverted and then reverse the process when reading, which the Kyroflux drive wouldn't do.

 

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

[Bryan]

Regarding flippies...

 

Can the Kryoflux software reverse track data so a head 2 track read while spinning forward (modified drive) can be written to the front of another disk?

[ijor]

is there any possiblity to transfer a VAPI-ATX back to disk?

 

There is currently no readily available software to write back VAPI images. We have a couple of programs in different development and testing stages. But my main problem is (as many others) lack of time. Currently I can barely find the time to write this message. Hopefully I'll have some more time in a couple of weeks or so.

 

The hardware devices best suited for writing back copy protected 8-bit disks are the ones working at the flux transition level. The three ones that I'm more or less familiar are the Discovery Cartridge, the Catweasel and the Kryoflux. They should be able to write back every single 8-bit disk.

 

It should be possible to write back most, but not all, of the protections using less powerful hardware. This includes Happy and similar enhancements (Duplicator, Speedy, etc), and also The Chip and the Super Archiver.

 

They say Kryoflux is mainly for use with HD drives, but I don't see why it couldn't handle 360K drives equally well.

 

Yes, that's the main drawback of the Kryoflux for the purpose of writing back 8-bit disks. It can handle 360K drives, at least some of them, but the electrical interface is not ideal. Older drives require stronger pullups and higher current buffers.

 

This doesn't mean that the Kryoflux can't work with any 360K drive at all, neither it means that it is completely impossible to write back DD disk on an HD drive. But it is not the ideal hardware for this purpose.

 

OTOH, the ideal hardware is useless without the correct software ...

 

Reading DD disks on an HD drive is less of a problem except for the flippy side, which most HD drives can't without a hardware mod. Most DD drives do can read the flippy side without any hardware mode, by physically flipping the disk (as you would do on a 1050 or 810 drive). Some people believe that this method is useless for preservation purposes, because the index pulse is lost. But in the worst case, you still can, at the very least, read non original flippy disks with most DD drives.

 

Obviously, this indicates there's a difference between recording flux transitions and sending a track to the drive or Kryoflux would copy any disk perfectly without intervention.

So, I'm guessing that some types of protection require manual identification. This has traditionally been the case with Fuzzy sectors since they return something different each time

 

Yes, you don't want to copy flux transitions blindly. This would be using a hardware digital copier like an (so called) analog copier. I think we talked several times (possibly more at the ST subforum) about the drawbacks and limitations of analog copiers. One additional issue that is particularly nasty for many 8-bit disks is the location of the track write splice point.

 

Having said that, is very possible to implement software that would copy most, if not all, protections reliably without any manual identification, and without creating any kind of master images. But this is not trivial, and it is much more work than just copying flux transitions blindly.

 

Can the Kryoflux software reverse track data so a head 2 track read while spinning forward (modified drive) can be written to the front of another disk?

 

Yes.

 

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)...

 

As I said in another thread, please be careful with this. That is a good technique for retry and verifications purposes. But this will provoke in many cases too many retries, which is bad karma to some "fragile" original disks, like many Synapse ones.

 

Well, I have a lot of original games and can certainly start making images if it will help.

 

I insist in an idea I also mentioned in the other thread. Let's post all raw dumps in some public place. This way we won't depend, at least not exclusively, on the scarce time of somebody else (including SPS people, but also including me) to post process the dumps.

Edited April 12, 2012 by ijor

[malers]

 

 

 

 

Yes, that's the main drawback of the Kryoflux for the purpose of writing back 8-bit disks. It can handle 360K drives, at least some of them, but the electrical interface is not ideal. Older drives require stronger pullups and higher current buffers.

 

This doesn't mean that the Kryoflux can't work with any 360K drive at all, neither it means that it is completely impossible to write back DD disk on an HD drive. But it is not the ideal hardware for this purpose.

 

OTOH, the ideal hardware is useless without the correct software ...

 

Reading DD disks on an HD drive is less of a problem except for the flippy side, which most HD drives can't without a hardware mod. Most DD drives do can read the flippy side without any hardware mode, by physically flipping the disk (as you would do on a 1050 or 810 drive). Some people believe that this method is useless for preservation purposes, because the index pulse is lost. But in the worst case, you still can, at the very least, read non original flippy disks with most DD drives.

 

 

Which 360K drive is in your opinion the best one for writing with kryoflux? The C64 people should face the same problem, dont they?

[malers]

I insist in an idea I also mentioned in the other thread. Let's post all raw dumps in some public place. This way we won't depend, at least not exclusively, on the scarce time of somebody else (including SPS people, but also including me) to post process the dumps.

 

Would be a pleasure, to upload dumps in a public place. But I thinks one of SPS people should create the public place and do some communication. That should not take a lot of time.

[fiath]

As I said in another thread, please be careful with this. That is a good technique for retry and verifications purposes. But this will provoke in many cases too many retries, which is bad karma to some "fragile" original disks, like many Synapse ones.

 

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.

 

I insist in an idea I also mentioned in the other thread. Let's post all raw dumps in some public place. This way we won't depend, at least not exclusively, on the scarce time of somebody else (including SPS people, but also including me) to post process the dumps.

 

Yes, that sounds like a good idea.

[fiath]

Would be a pleasure, to upload dumps in a public place. But I thinks one of SPS people should create the public place and do some communication. That should not take a lot of time.

 

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?

[fiath]

Regarding flippies...

 

Can the Kryoflux software reverse track data so a head 2 track read while spinning forward (modified drive) can be written to the front of another disk?

 

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

[deathtrappomegranate]

Would be a pleasure, to upload dumps in a public place. But I thinks one of SPS people should create the public place and do some communication. That should not take a lot of time.

 

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?

 

Perhaps a moderator could consider making a sticky thread here?

[kenjennings]

The Kryoflux dump of a double density disk produced 256 byte sectors for the entire disk, including the first 3 boot sectors. However, the spec for the ATR format says the first 3 sectors are always 128 bytes. I see in the data from kryoflux that the first 128 bytes in the 3 sectors are duplicated in the second half of each sector (disk was originally written on an XF551 by MyDOS ) .

 

Is the 128 byte limit in the first three sectors only enforced by DOS in software when writing the boot sectors in double density to insure boot compatibility with the OS? OR, is it the drive controller itself that is hardwired to do this with the first three sectors? If a floppy is formatted and DOS/bootloader is NOT written then can the entire 256 bytes of the first three sectors be read/written on Atari drives?

[kenjennings]

IIRC Atari 8-bit disk drives write data inverted and then reverse the process when reading, which the Kyroflux drive wouldn't do.

 

Yep, it's one of those little idiosyncrasies you wouldn't know about unless you looked into the drive internals.

 

Would anyone know WHY the original drive designers decided to invert all the bits on the disks? What does it accomplish?

[Bryan]

I remember that it was myutil on the PC that had the first documentation of inverted data that I saw. It's also true that using 1.2M drives causes problems for SD/DD systems because the track is narrower (so more tracks can be written). This means if you re-write old disks on a HD drive, the middle of the old track is erased but the outer edges will contain traces of the old data. This makes the disks unreliable unless they are degaussed first.

[Rybags]

Inverted bits - possible reasons:

 

- possibly the CRC generated is better with all $FF than all $00.

- IBM used initial data of $E5, so maybe non-zero data is more likely to show up a problem when formatting. $FF when inverted on read gives us our nice "00" empty sector.

- $FF usually used in gap data, maybe that value in sector makes it more likely for the controller to find ID marks.