Atari 8-bit Software Preservation Initiative

[Pheonix]

I've been doing it successfully for quite a while now with the Kryoflux. Just hang onto the RAW Stream files for now, at least. It can write the RAW files, IPF files, ADF, & G64 (the last has minor issues.) It can't write the "flippy" side, but I just put that on another disk anyways (usually.) It can reverse the data and write it to the front side without any reall issues

[GlowingGhoul]

I've been doing it successfully for quite a while now with the Kryoflux. Just hang onto the RAW Stream files for now, at least. It can write the RAW files, IPF files, ADF, & G64 (the last has minor issues.) It can't write the "flippy" side, but I just put that on another disk anyways (usually.) It can reverse the data and write it to the front side without any reall issues

 

Thanks! Which drive are you using? And no problems running the resulting disk on a real 1050?

[+Nezgar]

Is there any tools/documentation on how to use a programmable 1050 like Speedy or Happy connected to a PC with 10502PC for ATX imaging? or is that pretty much dead.

 

I did see a reference to a VAPI imager for happy drives in this old thread: http://atariage.com/forums/topic/251335-help-using-original-vapi-files/?p=3488266

[Farb]

I've been doing it successfully for quite a while now with the Kryoflux.

It would be interesting to know what settings you used. I had tried it once or twice and could never get stream files to write back properly. The only way I've been able to create working disks is via SuperCard Pro and a8rawconv using ATX files.

 

Is there any tools/documentation on how to use a programmable 1050 like Speedy or Happy connected to a PC with 10502PC for ATX imaging?

As far as I know, that tool is not actively supported anymore. I don't think anyone has picked it up.

[Pheonix]

Well, no trouble running the disks on a real TI-99/4a, PC, or Commodore 128, or Amiga. Those are the only systems I have right now.

 

As for the drive, the 5.25" is a Panasonic JU-475-3

[Farb]

Well, no trouble running the disks on a real TI-99/4a, PC, or Commodore 128, or Amiga. Those are the only systems I have right now.

 

As for the drive, the 5.25" is a Panasonic JU-475-3

Are you writing back stream files or IPFs using DTC? I would expect the latter to work perfectly and I have not had success with the former.

 

Sent from my Pixel XL using Tapatalk

[Pheonix]

Writing back stream files. Of the systems I have right now, the Amiga is the only one you can get IPF files for. IIRC IPF only supports Amiga, Atari ST, & Amstraad systems.

[ijor]

Well, no trouble running the disks on a real TI-99/4a, PC, or Commodore 128, or Amiga. Those are the only systems I have right now.

 

The problem writing back RAW files (either Kryoflux RAW, or SCP images) is locating the right write splice. For many other platforms is not a big problem because most titles use the index hole as the write splice. So just writing index to index works most of the time.

 

In the case of Atari 8-bit, most original titles were not duplicated with any alignment to the index hole. If you then attempt to write back with a simple index to index method, chances is that on some track you will corrupt a sector.

 

When having a high level image, it is easy to locate a suitable write splice. That's why a8rawconv writing back ATX images through the SCP works fine, at least in this regard. On low level, raw images, this is much harder. It is still possible to locate a write splice, but it is not simple and not as reliable.

[ijor]

Is there any tools/documentation on how to use a programmable 1050 like Speedy or Happy connected to a PC with 10502PC for ATX imaging? or is that pretty much dead.

 

I abandoned the project long ago because of several reasons.

 

It was a PITA to develop and to debug. It didn't help that it run in multiple enhancements (SuperSpeedy would have been nice, but wasn't available then).

 

It couldn't cope with the most advanced protections with many sectors per track. That could have been developed eventually.

 

The Kryoflux and the SCP became widely available, and images made with an Atari drive can never be as precise and detailed as flux level images.

 

I was a bit obstinate and insisted in using very high transfer speed, that worked fine on my own setup. But custom serial bit rates was always a problem under Windows, so several users could never get it to run at all.

 

I believe I made the tool public some years ago. Don't remember if I posted it here ... hmm, seems not. But anyway if you still want it just let me know.

 

[_The Doctor__]

I tried to help out with this years ago.. I ran into this over and over...

1. make sure the sio caps are out.

2. make sure your sio cords are clean and in GREAT shape.

3. remove everything except the drive your trying to use, and if still a problem try another drive, tune up the drive if it's your only one.

4. clean the drive head!

5. try to make sure your not running anything that interferes with pc timing interrupting your work.

6. make sure nothing is getting in the way of or polling your serial port.

 

That's the of list fixes for why wont it work complaints I remember most, in almost all cases this solved it. They must have driven you to distraction with all this stuff!

 

please do post your work, it's a shame if others can't see it and learn something, who knows maybe you or they will build on it in some meaningful way!

Edited February 9, 2018 by _The Doctor__

[phaeron]

 

When having a high level image, it is easy to locate a suitable write splice. That's why a8rawconv writing back ATX images through the SCP works fine, at least in this regard. On low level, raw images, this is much harder. It is still possible to locate a write splice, but it is not simple and not as reliable.

 

a8rawconv uses an analysis pass when writing raw flux images -- it does a sector extraction pass as usual and picks the largest inter-sector gap to use as the splice point when writing the raw flux. It doesn't try to find an existing write splice point in the flux. It's more aggressive when writing back ATX images as it will shift sectors if there isn't enough room for them, as there were too many cases otherwise where it couldn't create a track image with the sector timings given in the image.

[Farb]

 

The problem writing back RAW files (either Kryoflux RAW, or SCP images) is locating the right write splice. For many other platforms is not a big problem because most titles use the index hole as the write splice. So just writing index to index works most of the time...

Thanks ijor, this is great info. It also jibes with an exchange I had with Jim Drew when trying to write back an SCP file to a real disk (I think it was Frogger). He had made suggestions that involved manually writing back individual parts of the disk that were problematic using settings in the SCP tool.

 

I will add have added this info to the "writing back to disk" section of the website so we capture it.

Edited February 9, 2018 by Farb

[GlowingGhoul]

OK, so obviously some of you have had success writing back images, one way or another.

Which model floppy was used for writing? I don't want to experiment, please, just tell me which one worked for you.

[Farb]

OK, so obviously some of you have had success writing back images, one way or another.

Which model floppy was used for writing? I don't want to experiment, please, just tell me which one worked for you.

I have had success using both the Panasonic and Epson drives mentioned on the site for writing as well.

 

Sent from my Pixel XL using Tapatalk

[Pheonix]

I think I said before that my 5.25" Kryoflux drive is a Panasonic JU-475-3 modified for 1 pass flippy reading.

 

I have to admit I'm not up on Atari copy protections. It seems to me, as long as the raw stream files are good and the writing drive is good, that writing back should pose no issue. The only issue would be the thinner data stream on the disk caused by the smaller write head of an HD drive. If you're really concerned, or are having difficulties, get a 40 track drive. That should resolve the only issue. Kryoflux (and the SuperCard, if I understand it correctly,) both do extremely low level analog reads of the disk. As long as the read is blind (Kryoflux raw stream is a blind read,) it doesn't matter if it syncs the reads up with the index or with the other tracks (index is easier.) If the write produces the same sync, then the result would have the same track to track sync as the original as well. The problem comes during the conversion from a higher level format (ATX, D64, .DSK, etc...) back down to the raw stream format. That is when sync positioning can cause a problem. If you don't know how the tracks are supposed to be aligned with each other, getting it aligned correctly is pretty close to impossible. It was rather common "not" to have the tracks aligned with each other, which is the default when down converting.

 

I've also discovered another issue with down converting to raw stream format. HxC Tools is the only way I have to convert to raw stream format at this time. The raw stream files it creates are not exactly the same as the ones DTC produces. They seem to be weaker or some such. For example, a test I actually performed:

 

Read a floppy to raw stream with conversion to D64 format (1st stream set)

Used HxC to convert the D64 to raw stream (2nd stream set.)

 

SS1 & SS2 - Converts to D64 fine in both DTC & HxC

SS1 - Write to disk, no errors everything good

SS2 - Write to disk, nothing but errors. Maybe an occasional good sector or two.

 

That's with the exact same source material. As well as the same set of destination disks. I was performing a "test" so I didn't depend on just one write each. I actually wrote 10 disks each, and wrote each disk multiple times if failures occurred. Only if a write failed 10 times on a single disk did I consider that a failed disk. SS1 resulted in a total of 4 failed writes on 10 disks (14 writes resulted in 10 good disks.) SS2 resulted in 100 failed writes (that 10 failed writes on 10 different disks.) I keep intending to message them about that, but since I'm just using the software and don't actually own (and don't have current plans to get,) the HW, I keep putting it off.

 

So, if you are having problems with disks created by writing the raw stream to disk, I'd suggest: Check the method you are using to produce the raw stream files. Check the drive is aligned & cleaned (both the vintage drive used on your real HW as well as the drive used to write the stream to disk.) Check to see if the vintage drive is capable of reading tracks created by the writing drive (narrow HD tracks in a DD drive, is actually a rather old issue.) Since you can't write flippy back (you have to convert the flip side to a second top side,) then you don't have to worry about a drive dedicated to writing DD disks being flippy modded. DD 5.25" drives aren't really all that rare, just make sure you get a 40 track drive and not one of the rare 80 track DD drives (like I ended up with.) It will have a similar problem.

[ijor]

a8rawconv uses an analysis pass when writing raw flux images -- it does a sector extraction pass as usual and picks the largest inter-sector gap to use as the splice point when writing the raw flux. It doesn't try to find an existing write splice point in the flux.

 

Right, usually there is no need to locate the original write splice. And in many cases there are multiple write splices on every track. But there are a few cases that this method doesn't work. Some tracks don't have any suitable inter sector gap. Some tracks have all the sectors "overlapped" or "short".

[ijor]

I think I said before that my 5.25" Kryoflux drive is a Panasonic JU-475-3 modified for 1 pass flippy reading.

 

I have to admit I'm not up on Atari copy protections. It seems to me, as long as the raw stream files are good and the writing drive is good, that writing back should pose no issue. The only issue would be the thinner data stream on the disk caused by the smaller write head of an HD drive. If you're really concerned, or are having difficulties, get a 40 track drive. That should resolve the only issue. Kryoflux (and the SuperCard, if I understand it correctly,) both do extremely low level analog reads of the disk. As long as the read is blind (Kryoflux raw stream is a blind read,) it doesn't matter if it syncs the reads up with the index or with the other tracks (index is easier.) If the write produces the same sync, then the result would have the same track to track sync as the original as well. The problem comes during the conversion from a higher level format (ATX, D64, .DSK, etc...) back down to the raw stream format. That is when sync positioning can cause a problem.

 

No, I'm afraid you don't understand what the problem is. Alignment between tracks (what we call skew align) is not the problem. And btw, ATX images, at least when converted properly from flux level images, preserve this alignment. And most Atari 8-bit disks don't care about the inter track alignment anyway.

 

The problem is the location of a suitable write splice. This has nothing to do with the quality of the image, the width of the write head, or the condition of the drive. Write splice is the location where the track recording ends and overlaps with the start as a consequence of the media being circular. Due to both magnetic and mechanical imprecision, you don't have much control about what would be exactly recorded at the write splice point. So you need to locate a right position on the track where the magnetic result doesn't matter.

 

If you have a high level description of the track, then it is easier to locate a suitable write splice. That is what Phaeron just commented he is performing with his software. But when writing low level images blindly, then it is more difficult and sometimes not very reliably.

 

For completeness let me say that writing back low level images blindly have additional drawbacks. For instance, if the disk was slightly damaged you might reproduce, or even make the problem worse.

Edited February 10, 2018 by ijor

[_The Doctor__]

Sent from my Pixel XL using Tapatalk

 

If you've got all of this sorted out and tucked into the repository, it might be time for another torrent / dropbox installment

Edited February 10, 2018 by _The Doctor__

[Pheonix]

 

The problem is the location of a suitable write splice. This has nothing to do with the quality of the image, the width of the write head, or the condition of the drive. Write splice is the location where the track recording ends and overlaps with the start as a consequence of the media being circular. Due to both magnetic and mechanical imprecision, you don't have much control about what would be exactly recorded at the write splice point. So you need to locate a right position on the track where the magnetic result doesn't matter.

 

If you have a high level description of the track, then it is easier to locate a suitable write splice. That is what Phaeron just commented he is performing with his software. But when writing low level images blindly, then it is more difficult and sometimes not very reliably.

 

For completeness let me say that writing back low level images blindly have additional drawbacks. For instance, if the disk was slightly damaged you might reproduce, or even make the problem worse.

 

Yes, I had misunderstood you a bit, but that doesn't make that big of a difference here. The Kryoflux, at least, when reading blindly, reads the pure analog flux levels. So, when the track splices (as you explained it,) and overlaps the ending over the beginning, it reads that section "exactly" as it appears on the disk. And by blindly, I'm saying it's not trying to interpret it, it's just reading the flux pattern in its raw form. When the raw stream is written back, it produces the exact same pattern at the overlap point. The Kryoflux doesn't see an overlap, it just sees a flux pattern that is slightly different than anywhere else on the track, (and since it's blind, it doesn't treat that as the error that an interpretive reader would.) To describe it a little clearer. Imagine a circle that is grey. Only at one point it's almost black for a short piece. That black line is the "splice" point where the end overlaps the beginning a bit. The Kryflux would save this denser location in the raw stream. When it writes it back it would produce the grey circle with the black section in the exact same location relative to the data on the track, the index marker, & the black lines on all other tracks. The blind read doesn't care about alignment, beginning or ending of track, sector locations, gaps, headers, or anything of that nature. All it reads is the flux density at every point of the track. I don't remember, off hand, the resolution it reads it at, but it is much higher than the Atari would be capable of.

 

The main danger with blind reads, as you mentioned, is if there is damage in the data (physical damage, or just age degradation.) The blind read, since it isn't interpreting the flux data, won't realize that the pattern it read doesn't translate, and just saves the incorrect flux pattern. This is why I, and I believe most others, combine the raw read with an interpretive read. The raw stream is still a blind read, but DTC then tries to interpret the raw stream into a higher level format. If it cannot, it reads the track again. It does this until it gets a good read of the track, or so many attempts have failed (this can be adjusted to more or less than the default.) It then keeps the best read of the raw stream & moves on.

[ijor]

The Kryoflux doesn't see an overlap, it just sees a flux pattern that is slightly different than anywhere else on the track, (and since it's blind, it doesn't treat that as the error that an interpretive reader would.)

Seems that you still don't understand the problem. Reading (or interpreting) the data at the original splice point is not the problem. Actually it usually doesn't matter at all what you read at the splice point because it is garbage anyway.

 

When the raw stream is written back, it produces the exact same pattern at the overlap point.

 

No, it doesn't, it can't. As I said, you don't have full control of what is exactly recorded at the splice point you create. The main reasons are the variations of the rotational speed and the index pulse jitter.

 

As long as you write using the same original splice point, then there is no problem because as I said above, it is garbage anyway. But if you can't detect the original splice point or find an alternate suitable one, then chances that you will write corrupted data.

 

I won't argue with you anymore on the theory. Try writing back some Atari 8-bit raw stream images (not high level ones) that are not aligned to the index hole, and test them. Then come back and we'll talk.

 

Edited February 10, 2018 by ijor

[Pheonix]

Since I don't have and am unlikely in the foreseeable future to get an Atari with floppy, that is not likely. But it seems you are operating under the assumption that the drive the Kryoflux is using has the same issues as the old belt driven drives of the era. For example, my 5.25" Kryoflux drive's RPM varies from 360.758 & 360.769 RPM in a 5 minute test run. Compared to my C128's 1571 which ranges from 299.98 to 302.76 RPM (and that is better than my 1541.) Also, the Kryoflux (even though it doesn't write verify a raw stream write,) does make several passes to get the replaced flux pattern to match what it has in the file. The index pulse is also a lot more stable than the few drives that used them back then as well. Sure, if I was using an Atari drive to write the flux data back (and that can be done,) I would face that issue. I do know that at least one C64 copy protection utilizes data overlapping from the end of a track to the beginning. Which is why it was one of the strongest protections of the time. A speed control box, and a drive with a more stable than average drive speed was needed to copy those. And even then, it usually took several tries. The kryoflux does it in one try.

 

But, as you say, unless someone with a kryoflux and an Atari with Floppy (along with software where that would make a difference,) gives it a test, you won't be convinced. The best I can do is write the few Atari disk images I have back to disk, then see if I can again dump them accurately. I do have a few games that I play in emulation. They came on the back sides (or on the front with the C64 on the back,) of games I got for my other systems.

 

The ones I have (just doing a quick flip through my disks...)

Ninja

Dig Dug

Pitfall & Demon Attack

Lode Runner

Lode Runner's Rescue

Ultima II - Revenge of the Enchantress

Temple of Apshai Trilogy

M.U.L.E. (was advertised as the C64 version.)

Bruce Lee

PQ - The Party Quiz Game

 

As a quick test, I wrote back a couple (M.U.L.E. & Load Runner - didn't have to flip the flippy data) to floppy, then read the disk again without issue. That's the closest I can come to testing the write function. Read the disk with my Kryoflux again, to see if it reads OK. If that isn't acceptable, I won't be able to make acceptable tests.

[ijor]

But, as you say, unless someone with a kryoflux and an Atari with Floppy (along with software where that would make a difference,) gives it a test, you won't be convinced.

 

And why you think it wasn't tested already?

 

The best I can do is write the few Atari disk images I have back to disk, then see if I can again dump them accurately. I do have a few games that I play in emulation. They came on the back sides (or on the front with the C64 on the back,) of games I got for my other systems.

 

M.U.L.E. (was advertised as the C64 version.)

 

As a quick test, I wrote back a couple (M.U.L.E. & Load Runner - didn't have to flip the flippy data) to floppy, then read the disk again without issue. That's the closest I can come to testing the write function. Read the disk with my Kryoflux again, to see if it reads OK. If that isn't acceptable, I won't be able to make acceptable tests.

I said disks that were not recorded aligned to the index hole. MULE, as most Electronic Arts releases, it is. So it should write back without problems, at least there shouldn't be an issue of locating the right write splice.

 

Lode Runner might be, some versions are aligned to the index hole, some are not. But how do you know it wrote back ok? Just because "it reads OK" back with the Kryoflux doesn't mean anything. If you want me to check, post both Lode Runner stream images, the original dump and the one of the copy you wrote back.

Edited February 10, 2018 by ijor

[Pheonix]

Lode Runner is probably index aligned then. I don't have big enough of a test batch. Hitting myself now, should have done this to begin with. Went to the Kryoflux forum. There is a problem with tracks that aren't index aligned (or there used to be, in 2015.) The exact quote. "The Kryoflux currently does not know how to successfully write a track where the data crosses the index." I thought they had fixed that, mainly because a large majority of C64 titles also ignored the index (the drives didn't even have an index sensor.) Also, spiral tracks was one of the C64 copy protection methods, and that pretty much guarantees that there will be tracks with data crossing the index. I'll admit, the controller they use has one of the programming languages I don't know, but it seems it shouldn't be that hard a fix. Of course, there also hasn't been a firmware upgrade since before that post either, so even if they have fixed it, they haven't released said fix yet. But, it doesn't matter where in the track the index is, as long as it isn't in the middle of a sector (index straddling - another copy protection method, but only on systems where all drives had index sensors.)

 

In this case, the blind read doesn't do any good, because it's just going to place the index pulse wherever it occurs in the stream timing. It's just that during the write process, the way it is done will cause corruption in the data at the index pulse if it doesn't fall withing a gap. The quick fix is to use software (the post suggests HxC Tools,) to sync the tracks to the index pulse. Though, I imagine this could break copy protection if not done carefully.

 

As for M.U.L.E.; no, the folder (box,) disk, & paperwork all say Atari. The guy I purchased it from had advertised it as a C64 version. I bought it thinking it was a C64 version, and I decided not to argue with the seller when he said "too bad, no returns." So, it is originally an Atari version of the game, the seller just misinformed everyone when he put it up for sale.

 

On careful consideration, and knowing that I don't completely understand the differences between GCR & FM/MFM encoding, it is possible that GCR encoding it more forgiving of the corruption caused by index straddling (when written by the Kryoflux,) than FM/MFM is.

[ijor]

"The Kryoflux currently does not know how to successfully write a track where the data crosses the index." I thought they had fixed that, mainly because a large majority of C64 titles also ignored the index (the drives didn't even have an index sensor.)

...

On careful consideration, and knowing that I don't completely understand the differences between GCR & FM/MFM encoding, it is possible that GCR encoding it more forgiving of the corruption caused by index straddling (when written by the Kryoflux,) than FM/MFM is.

 

I don't think it is more forgiving. The difference is what I said in my first reply to you. On most other platforms, including the C64, most commercial disks were duplicated aligned to the index hole. It doesn't matter for this purpose if the C64 drive doesn't have an index sensor. What matters is how the original disk was recorded at the duplicator.

[phaeron]

For example, my 5.25" Kryoflux drive's RPM varies from 360.758 & 360.769 RPM in a 5 minute test run.

 

While this is much better than the 1571's timings, it's still pretty bad on the scale that we're talking about here.To do a blind write successfully without choosing a safe splice point means that the drive speed variation overall during the track write needs to be under one bit cell. That's four microseconds, or in relative terms, about 0.00192%. A range of 360.758-360.769 RPM is a change of 0.003%, already high enough to excessively stretch or drop a bit. And that's assuming that the read/write head is able to erase and rewrite within a single bit cell of tolerance, which is not necessarily guaranteed.