Atari 8-bit Software Preservation Initiative

[Pheonix]

 

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.

 

You are calculating the variance wrong here. The variance isn't calculated across the entire range but at a +/-, so it's done with the average. The average RPM of the given range is 360.7635 giving you a variance of +/- 0.0015%. This is adjusted, of course by how big a test sample the Kryoflux takes before calculating its timings. The longer the sample the more accurate the averaging will be. My test ran for approximately 5 minutes (didn't use a stop watch, just looked at the time in the lower right corner of my computer screen.) The Kroflux can only be testing for a few seconds at most, it starts writing to quickly. So, it's probably safe to say that it's variance (on my drive,) will range from 0.0015% to 0.003% more closely approaching the true variance depending on how long the test cycle runs. It is probably fairly close to 0.002% most of the time. So, it might fall within tolerance on a regular basis.

 

From my understanding, floppy drives don't erase then write during a write operation. They just write. The Kryoflux will perform an erase track followed by a write track (under normal circumstances.) This can be turned off, or changed to erase disk write disk instead.

 

As a final note, just attached 2 different drives to the Kryoflux and ran the same test on them. The first had a range from 360.751 to 360.842 & a variance of 0.0126%, and the second had one of 360.748 to 360.823 with a variance of 0.0104%. Both well above tolerable levels. So, the drive I'm using appears to be considerably better than average. I have a 4th drive to test, but it would have to wait until I finished fixing it.

 

As for the C64, I personally know of at least one company that didn't worry about index syncs, because the mastering HW didn't have a sensor either. Historically, there were several that used cheaper mastering systems that didn't include an index sensor. This says nothing about the many floppies that were actually made by the end user (me, in this particular case,) that read & write just fine.

[phaeron]

 

You are calculating the variance wrong here. The variance isn't calculated across the entire range but at a +/-, so it's done with the average. The average RPM of the given range is 360.7635 giving you a variance of +/- 0.0015%. This is adjusted, of course by how big a test sample the Kryoflux takes before calculating its timings. The longer the sample the more accurate the averaging will be. My test ran for approximately 5 minutes (didn't use a stop watch, just looked at the time in the lower right corner of my computer screen.) The Kroflux can only be testing for a few seconds at most, it starts writing to quickly. So, it's probably safe to say that it's variance (on my drive,) will range from 0.0015% to 0.003% more closely approaching the true variance depending on how long the test cycle runs. It is probably fairly close to 0.002% most of the time. So, it might fall within tolerance on a regular basis.

 

That's not the way it works. The only thing that matters is the error between the software/firmware's estimate of how many bits can fit on the track and how many actually fit on the one attempt when it does the write. That the drive might be fairly good on average is of no use if on the actual attempt to write the track the discrepancy exceeds 4us. That 0.00192%, by the way? That's a full bit cell of error, which is too much. You need significantly under that in order to have enough phase margin for the reading drive to successfully decode the data. That's why systems that rewrite flux try to place the splice point in a gap instead of in the middle of data.

[Pheonix]

My apologies. Going back over the discussion, I believe we are operation under a failure of perspective. I was arguing that the Kryoflux is fully capable of reading the splice point and recreating a replica of that splice point on the disk. I allowed myself to start arguing that the Kryoflux doesn't create its own splice point which wasn't my intention in the beginning. The Kryoflux works to reduce it's own splice point, but I shouldn't be saying that it doesn't have one at all. Looking back at the discussion, I believe you were actually saying that the Kryoflux's splice point is what causes the problem, not an inability to copy the Atari's splice point. I got so wrapped up in trying to say that if the Kryoflux read a spliced pattern at a point mid track that it would recreate that same spliced pattern at the same mid-track point on the target, that I found myself trying to say that the Kryoflux doesn't have a splice point itself. I didn't mean to go there, and only recently realized that I had been sorry.

 

If you go back to my first post on this discussion, I think you'll notice my comment about copy protection? For some reason, I had latched onto your comment about the splice as if the Atari had used a strange splice location as a form of copy protection. Why I did that I'm not sure now... I blame my health & medication That being said, I do think the Kryoflux has reduced it's own splice footprint to smaller then you imply. Also, I have a huge C64 collection, and there was a larger collection of C64 titles that were nowhere near index synced than you seem to think. Same thing with Apple II titles. Which also uses GCR, and also seems to be able to get reliable writes from raw stream files on a regular basis (though I don't have direct experience with those, this is based on what I've read in the forums.) Almost every C64 title I have, I have successfully written from the raw stream files to use on my C128. I would say every, but thinking on it, I can't actually guarantee that. I can say I've never faced a total failure to write, only failures from bad media. Using a different disk works and no other title I tried to write worked on that disk either. This is one of the reasons why I thought they had fixed the index mid data issue. Reading & thinking about it further (the lack of updates since that post I referenced,) is why I am wondering if GCR is less sensitive to the issue. I do know, with the C64's smart drive, that GCR formatting supports a degree of error correction. Maybe it's enough to counter the reduced splice point the Kryoflux produces.

 

Back to your original comment that I mis-read (I guess.) The only solution I can see is to write a program that will scan the stream file. Detect the correct splice point. Then adjust the stream file so that it lines up. To do it right, though, it would have to read all tracks. Calculate the true splice points of all tracks. Then set the adjustment so that all streams are adjusted the same, as many splice points as possible match up, and those that can't be matched up are in safe locations. Too many copy protections depend on precise track alignment Though, it probably holds true that any that are so dependent would also be index aligned to begin with. Maybe have the program written to either do "track at a time" or "disk at a time". With warnings & notices in the latter case, when alignment won't be precise. I also believe that DTC has an ability to adjust the splice point +/- from the index (I'll have to sit down & read the manual again t be sure.) That would mean examining the steam data & discerning where the splice point is supposed to be on a track-by-track basis.

[Fred_M]

At the site (a8preservation) is a dump of the UK Ariolasoft cassette of Archon. I was surprised to see this mentioned: "Manually fixed by Kr0tki (had protection that required manual tweaking of the CAS file)".

 

I have dumped the original cassette myself a few months ago (and uploaded it to the Atari Sector forums) and found nothing wrong with it. It can be be loaded in Altirra when you switch the C:patch off. It is the same loadroutine as for example MULE.

 

I have attached my dump to this post. Maybe you can use it

archon_1983_Ariolasoft_UK.zip

Edited February 11, 2018 by Fred_M

[Kr0tki]

At the site (a8preservation) is a dump of the UK Ariolasoft cassette of Archon. I was surprised to see this mentioned: "Manually fixed by Kr0tki (had protection that required manual tweaking of the CAS file)".

That description is somewhat imprecise; I regularly review contributed CAS files in order to remove any non-needed artifacts resulting from glitches and other quality-related issues. The a8cas-convert tool is so "sophisticated" that it cannot detect silence properly, and stores it in the resulting CAS file as a block of random rubbish. The description at A8Preservation means simply that the contributed CAS file was cleaned up to remove superfluous data.

 

I have attached my dump to this post. Maybe you can use it

Your CAS file exhibits the problem I wrote about: it contains a few excessive bytes of data, resulting either from not ignoring a period of silence that was on the original tape, or from glitches in the source signal. The CAS file that's in the A8Preservation torrent, is cleaned up properly and contains only the data that is needed.

 

EDIT: But your CAS file can surely be used for verification. I have just verified that Fred_M's CAS file contains the same data as the earlier dump, therefore we can mark it as verified. Farb, are you listening? :-)

Edited February 11, 2018 by Kr0tki

[Fred_M]

Thanks for the explanation kr0tki!

[_The Doctor__]

can a8cas be fixed up to stop this behavior?

[Kr0tki]

Well, it's all by design. A8CAS cannot be made to ignore any glitches in the signal, because a) those "glitches" are sometimes part of an elaborate copy protection scheme, b) not ignoring anything greatly helps when restoring data from tapes of very poor quality. It could be made to detect silence more reliably, though.

 

But the reality is, each CAS file has to be reviewed manually after conversion anyway, to make sure the tape was decoded correctly and to remove any unwanted glitches. Considering this fact, removal of unwanted data is simply another step within the manual process of review. The cost of this additional step is so low that I simply don't feel any push to fix it.

[ijor]

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

As a final note, just attached 2 different drives to the Kryoflux and ran the same test on them. The first had a range from 360.751 to 360.842 & a variance of 0.0126%, and the second had one of 360.748 to 360.823 with a variance of 0.0104%. Both well above tolerable levels. So, the drive I'm using appears to be considerably better than average.

 

That's more close to the typical figures. Your previous values were too good. Either the Kryoflux software computes some kind of average and not instantaneous variation (which is what matters for this purpose as Phaeron explained), or your first drive is outstanding. Let alone that as you recommended yourself, it's better to use DD (40 tracks) drive for write back, which being older usually have worse performance and even higher mechanical variance.

 

From my understanding, floppy drives don't erase then write during a write operation

Your understanding is wrong. Drives do erase automatically when writing. And as I said already, the magnetic side is is another problem that affects what is exactly recorded at the splice point.

 

Let's assume for a moment that the drive is mechanically perfect. Rotation speed is constant at the nominal value (300 or 360 RPM), index pulse is also perfect without any jitter. It still won't work reliably. You still don't have precise control of the magnetic recording. You don't know exactly when the drive actually starts writing and when it starts erasing, you don't know when it exactly stops. You don't know how much is erased but not written. Furthermore, this is analog logic, not digital. There isn't a precise point where write current starts or ends, there is a slope. Simply drives are not designed to make a precise recording at the write splice point. The splice area is assumed to be noisy and diffuse.

 

But there is even more. Let's assume for a moment that you somehow managed to overlap the start and the end of the recording so perfect. There aren't bits at the disk surface. There isn't a direct translation between bits (or pulses) and the magnetic polarization. There are only flux reversals. You have no control whatsoever if the reversal is in one direction (north to south) or the other (south to north). It doesn't matter at all because when reading it is the same, only relative flux reversals are read. But when you attempt to overlap the end and the start of the recording, the behaviour would depend if the track had an odd or even number of flux transitions. So you might need to drop one pulse to avoid a creating a fake flux reversal. Which bit would you drop?

 

So as you can see, is it not that simple to control precisely what is exactly recorded at the write splice. And btw, this is not just my personal opinion, or our (Phaeron's and mine) opinion. The developers of both the SCP and the Kryoflux agree. Something that you could verify by checking their documentation or their posts at different forums.

 

Reading & thinking about it further (the lack of updates since that post I referenced,) is why I am wondering if GCR is less sensitive to the issue.

GCR is definitely not less sensitive, on the contrary. Regarding the exact situation with C64 disk, I would prefer to not comment because it is not my area of expertise.

 

The only solution I can see is to write a program that will scan the stream file. Detect the correct splice point. Then adjust the stream file so that it lines up. To do it right, though, it would have to read all tracks. Calculate the true splice points of all tracks. Then set the adjustment so that all streams are adjusted the same, as many splice points as possible match up, and those that can't be matched up are in safe locations.

 

Something like that conceivable could work in some cases. But it is a retorted and ugly workaround. The simple and correct fix is to implement the capability of creating the write splice at any point on the track. Not just at the index. The SCP does support this. Phaeron's software does exactly that when writing back with a SCP.

Edited February 11, 2018 by ijor

[_The Doctor__]

and that's the thing the scp does a better job in one way but it's not the same software wise, and the kryoflux better in another because of the software.. if SCP could have better integration or have the software operate at that same level.... might I also add last time I checked neither were selling or in stock at their respective sites. Can someone point us to the appropriate sellers.

[phaeron]

SCP does have a splice mode that can start anywhere in the track, but a8rawconv doesn't use it. Instead, it uses index aligned mode and takes advantage of SCP's ability to end the write anywhere in the track: the flux data is padded with a leader to align the start of the write, and then the write wraps around the track to that point. This is partly to ensure that the entire track is written and also to preserve track skew between tracks and relative to index. I don't know of the details of Kryoflux's write capabilities but I would be surprised if it couldn't also do this.

 

The SCP website is cbmstuff.com -- it looks like they have it currently for sale.

[Pheonix]

Ijor:

 

I guess you missed my last post where I pointed out that I was working toward a different argument originally than where I ended up going. I was originally, and had intended to stay, arguing that the Kryoflux (and I imagine the SuperCard as well,) can reproduce the pattern found at the splice point that isn't at the index, at the same spot on the target disk. This is "not" the Kryoflux's splice point. The example I gave with the grey ring holds true, only now "add" a second point (this time, lets make it a gap,) that is white instead of black. Place the index pulse at the white mark and now we see what is going on. The black mark is the splice point of the original disk (which doesn't have the white mark, it's just solid grey with a black line marking the splice.) The second ring with both the black & white mark, is the destination disk, where the Kryoflux faithfully recreated the pattern it found on the source disk (the black line,) while also generating it's own splice (the white line.) For some reason, I had latched onto the idea that Phaeron and you were claiming that the Kryflux was unable to write back the black line and that this was preventing some copy protections from working. I have been arguing that point this entire time, but adjusting my language to counter what you were stating and thus started sounding like I was claiming the Kryoflux didn't create a splice point. So much so, that I actually started thinking that for a bit. It was researching more facts, and reading what I just "knew" had to be wrong, that made me realize where I was going, and backtracking to re-read the discussion again. I'll state things a little clearer now:

 

1) The Kryoflux "does" create a splice point. The splice point cannot be perfect. The splice point (if it fall in an area that is supposed to contain data,) will read as corrupted. The Kryoflux firmware "is" designed to minimize the splice point as much as possible, but it can "not" eliminate it completely.

 

2) The Kryflux "can" recreate the pattern of a splice point that is located mid track (from it's viewpoint.) This results in a track that actually has 2 splice points. This is the point I thought Phaeron and you were arguing. I thought you were telling me this was impossible and pointing out things like index jitter & RPM variance as the reason this was impossible (which wasn't making a lot of sense to me, but I was still taking it seriously.)

 

3) During this, I started treating everything splice related as the same thing. This is where I went off the rails a bit, and what finally made me look back and figure out what was wrong.

 

So, anything wrong with those 3 points?

 

Now on to other points. Yes, I guess you can say that a drive erases as it writes, in a way. To show it clearly, another example. First, a drive (floppy, hard, tape,) records on an analogue medium. The best way to picture it is to think of the child's toy that is a bunch of metal filings inside a clear plastic case. Take a magnet and those filings bunch together to form shapes & images as you move it around. Now imagine something similar and much much smaller, of course, suspended on the surface of the medium. The write head produces a magnetic field that pulses at given frequencies creating varying density of particles on the surface. The read head then picks up these densities as pulses when the medium is moved past it during a read. These density changes are referred to as flux transitions, and the pattern they form is interpreted into binary data by the controller (and vice versa during a write.) Another way to picture this is to dump a tape that contains computer data into a wav file editor. Now zoom in and view the wave forms as they change frequencies. Now, by itself, the write head will just produce whatever pulse pattern it is told to. The software "can" be designed to first send a neutral pattern to "erase" a section before writing to it, but this is done in software, and from a mechanical vies is a separate action. Unless it's told to do so, the drive will just write the new data, which also has the effect of destroying the old data, It could be said that the destruction of the old data counts as erasing it, but it is not a separate action. Even if software erases the data first, writing the new data "destroys" the erase pattern when it is written.

 

All that being said. A new write to a section will be more accurate if the media is first normalized (the tiny particles spread evenly over the section.) Which is why some mastering devices (or copy programs,) have a function to "erase" a disk. This is usually optional though. Kryoflux has it on by default, but it can be turned off.

 

Finally, all I can say about GCR & the C64 is that I have yet to have had a problem with splice location, and the C64 has plenty of titles that were not mastered with an index capable device. I actually don't know much about the next layer of disk encoding, be it GCR, FM, MFM, or something else. I know of them, and know some of the systems that use each. I just don't know anything specific about how they actually work. I do know, because of my research into copy protections, that the C64 & 1541 are capable of minor error correction of data on the disk. This ability was often used as part of copy protection. Beyond that, for the purpose of this discussion, I cannot say much.

[Pheonix]

SCP does have a splice mode that can start anywhere in the track, but a8rawconv doesn't use it. Instead, it uses index aligned mode and takes advantage of SCP's ability to end the write anywhere in the track: the flux data is padded with a leader to align the start of the write, and then the write wraps around the track to that point. This is partly to ensure that the entire track is written and also to preserve track skew between tracks and relative to index. I don't know of the details of Kryoflux's write capabilities but I would be surprised if it couldn't also do this.

 

The SCP website is cbmstuff.com -- it looks like they have it currently for sale.

 

I thought the Kryoflux did have something like this, but now I'm not sure. The documentation, IMHO, leaves much to be desired I get more information from DTC -help than any doc file I've managed to locate. Even then I''m not sure what some of the commands are capable of. -wp<par> for example. All it says is platform specific parameter (default: 0) without saying anywhere what parameters are available for what platforms or how to reference them. Looking at the -help results, the only thing that looks like it might apply is the write precompensation. Allowing you to set the window up to 10000 nanoseconds, and the time up to 1000 nanoseconds. That means the window can be as much as 0.00001 seconds and the time as much as 0.000001 seconds. Considering your statement that a bit cell is 0.00192 seconds, neither seem large enough to apply. So, it may be something that has to be done to the stream files and not able to be done at write time. I always said I wanted a SuperCard as well.

[ijor]

and that's the thing the scp does a better job in one way but it's not the same software wise, and the kryoflux better in another because of the software.. if SCP could have better integration or have the software operate at that same level....

 

 

Yes, each one has its pros and its cons. The Kryoflux software is better in some points. In others the SCP is better. For instance, the SCP can read flippy disks with an unmodified drive, just by flipping the disk. The Kryoflux software, at least last time I checked, cannot. Note than not every drive can read the flippy side, most DD drives can, most HD ones cannot. That's a limitation of the drive itself beyond the one of the controller.

 

 

SCP does have a splice mode that can start anywhere in the track, but a8rawconv doesn't use it. Instead, it uses index aligned mode and takes advantage of SCP's ability to end the write anywhere in the track: ... I don't know of the details of Kryoflux's write capabilities but I would be surprised if it couldn't also do this.

 

That's what I meant. Letting you end the write anywhere on the track is precisely letting you place the write splice anywhere you want.

 

Of course that the Kryoflux can do that as well. But the software doesn't implement that for RAW files.

[phaeron]

 

Looking at the -help results, the only thing that looks like it might apply is the write precompensation. Allowing you to set the window up to 10000 nanoseconds, and the time up to 1000 nanoseconds. That means the window can be as much as 0.00001 seconds and the time as much as 0.000001 seconds. Considering your statement that a bit cell is 0.00192 seconds, neither seem large enough to apply. So, it may be something that has to be done to the stream files and not able to be done at write time. I always said I wanted a SuperCard as well.

 

Write precompensation is something different. It's a method of pre-distorting data to compensate for peak shift effects that occur on the media, particularly on tighter inner tracks, so the data that's read back is closer to intended.

 

a8rawconv doesn't do write precomp, btw. Haven't analyzed how much of a problem it is at Atari FM/MFM densities and how much correction is needed.

 

Yes, each one has its pros and its cons. The Kryoflux software is better in some points. In others the SCP is better. For instance, the SCP can read flippy disks with an unmodified drive, just by flipping the disk. The Kryoflux software, at least last time I checked, cannot. Note than not every drive can read the flippy side, most DD drives can, most HD ones cannot. That's a limitation of the drive itself beyond the one of the controller.

 

The SCP software itself has some problems -- I couldn't get it to work on Windows 8/10 and had to use Windows XP/7, and the Atari 800 mode at least used to use index mode instead of splice mode. However, the hardware is solid and more importantly is fully documented and dead-simple to use in external programs. All you have to do is open a serial port and send some simple byte stream commands to read and write flux. Additionally, there are no distinctions between commercial/noncommercial or institutional use.

[Pheonix]

Write precompensation is something different. It's a method of pre-distorting data to compensate for peak shift effects that occur on the media, particularly on tighter inner tracks, so the data that's read back is closer to intended.

 

a8rawconv doesn't do write precomp, btw. Haven't analyzed how much of a problem it is at Atari FM/MFM densities and how much correction is needed.

Well, that answers that question I keep intending to ask what certain switches do in more detail on the forum, but keep putting it off unless & until I come across something that just refuses to work.

 

The SCP software itself has some problems -- I couldn't get it to work on Windows 8/10 and had to use Windows XP/7, and the Atari 800 mode at least used to use index mode instead of splice mode. However, the hardware is solid and more importantly is fully documented and dead-simple to use in external programs. All you have to do is open a serial port and send some simple byte stream commands to read and write flux. Additionally, there are no distinctions between commercial/noncommercial or institutional use.

It's on my "to get" list. Working on other things right now, though. One thing slowing me down is a means of safely sharing drives with both the Kryoflux and the SuperCard. The Kryoflux manual is quite explicit in stating "not" to turn on the drives when it isn't powered up, but I also don't know what would happen if both a Supercard and the Kryoflux are powered up at the same time. Thinking on maybe a switch that would switch the ground & power line(s) between the Kryoflux & the SuperCard. Also looking for a smaller enclosure for my 2 drives & Kryoflux than the tower case I currently have them installed in (preferably one that doesn't cost $100+)

 

[ijor]

1) The Kryoflux "does" create a splice point. The splice point cannot be perfect. The splice point (if it fall in an area that is supposed to contain data,) will read as corrupted. The Kryoflux firmware "is" designed to minimize the splice point as much as possible, but it can "not" eliminate it completely.

Correct.

 

2) The Kryflux "can" recreate the pattern of a splice point that is located mid track (from it's viewpoint.) This results in a track that actually has 2 splice points. This is the point I thought Phaeron and you were arguing. I thought you were telling me this was impossible and pointing out things like index jitter & RPM variance as the reason this was impossible (which wasn't making a lot of sense to me, but I was still taking it seriously.)

As I said already, in almost every case this doesn't matter. The pattern at the original splice point is usually garbage.

 

Now on to other points. Yes, I guess you can say that a drive erases as it writes, in a way ... The write head produces a magnetic field that pulses at given frequencies ... Unless it's told to do so, the drive will just write the new data, which also has the effect of destroying the old data, It could be said that the destruction of the old data counts as erasing it, but it is not a separate action.

This is mostly non sense. Please stop talking about things you obviously have no idea. No. It's not "in a way". The drive has specific erase heads that are automatically activated when writing. The erase heads might be physically separated from the read/write head, or they might be separate cores in the same physical head. Most drives use a so called tunnel erase mechanism (google the term). Among other things this is required for erasing a band wider than the write one or you will get too much interference from the previous data.

 

OTOH, industrial duplicator drives usually don't erase. But this is because they are supposed to be loaded with virgin or bulk erased disks.

 

And sorry if I am being a bit too harsh. But enough is enough.

 

 

 

 

[Pheonix]

So you're talking about the prep head? I don't see how that applies to how it was used it in the previous post. Where it was implied that the drive had to erase the section, then immediately write that section at extremely high speed, and thus didn't have time to do other things, and maybe even couldn't do that at speed. The prep head produces a fixed field that does a partial prep of the area just ahead of the write head. We never considered it a true erase head as it didn't actually do a full erase. To do that, you had to use the stronger field of the write head. It definitely isn't a write head, as it can't be used to either read or write data. It just cleaned up an area a bit just prior to writing it. It also reduce the remote possibility of current field levels actually corrupting the write. Finally, as it was wider than the write head, it reduced the presence of phantom data on the track edges caused by bleeding of the old field values.

 

 

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.

 

To actually quote what I was referring to. Here he is referring to the write head doing the erase, not the "erase" head which has a fixed effect. For the write head to do an erase, it has to be told to do so. What you are referring to as the "erase" head, is fixed functionality. It activates during a write, and cannot be controlled (usually,) otherwise. It's field strength is generally weaker then the write head. If it is, somehow (by hacking the drive, usually,) activated manually, and then run over the disk, it will generally "not" actually erase everything. Large amounts of data will still be fairly easily recovered. A disk thus treated (in a reasonable amount of time, not talking hours here,) has a chance of actually being readable, though it would be spotty.

 

So, forgive me for trying to keep things a little simple. I've also neglected to specify that it is actually a read/write head, not just a write head. I've neglected to bring up pattern bits and such. Nor have I brought up such details as frequency changes, cross-talk, surface bleed, and a whole host of other fine details that don't really apply here.

 

Finally, I say again, I originally thought you were referring to the original splice being needed for some form of copy protection. I did a study of those, but I don't claim to know them all. I've dropped that, since I discovered that isn't what was being said after all. That's why I listed it, no need to denigrate me over that misunderstanding. If it "is" needed for some form of copy protection, it will be there. That's all I was saying.

[+Nezgar]

a8rawconv doesn't do write precomp, btw. Haven't analyzed how much of a problem it is at Atari FM/MFM densities and how much correction is needed.

It was a big enough problem for the original batch Atari 810's that didn't include a data seperator board, which added write precompensation for inner tracks. Lots of stories of how unreliable they were because of that...

[Shannon]

Is this a discussion that belongs in another thread?

[ijor]

a8rawconv doesn't do write precomp, btw. Haven't analyzed how much of a problem it is at Atari FM/MFM densities and how much correction is needed.

It was a big enough problem for the original batch Atari 810's that didn't include a data seperator board, which added write precompensation for inner tracks. Lots of stories of how unreliable they were because of that...

 

I'm not very familiar with the 810 data separator board but I doubt it performs write precompensation. Write precompensation is not used in FM. The data separator as implied by its name is for reading, not for writing, and its main function is to perform as a PLL.

[_The Doctor__]

Belong in this thread? Yes it does and no it doesn't as it is about preserving our software but maybe should be in a technical thread...

Edited February 12, 2018 by _The Doctor__

[ijor]

Finally, I say again, I originally thought you were referring to the original splice being needed for some form of copy protection. I did a study of those, but I don't claim to know them all. I've dropped that, since I discovered that isn't what was being said after all. That's why I listed it, no need to denigrate me over that misunderstanding. If it "is" needed for some form of copy protection, it will be there. That's all I was saying.

 

I am certainly not denigrating anybody. You got me tired and as somebody just said, this went too far off topic. I won't reply anymore. If you want to continue with the subject please open another thread.

[Farb]

But your CAS file can surely be used for verification. I have just verified that Fred_M's CAS file contains the same data as the earlier dump, therefore we can mark it as verified. Farb, are you listening? :-)

Yes, we can mark Archon as verified based on this. Thanks Fred_M! Edited February 12, 2018 by Farb

[Farb]

 

 

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

 

I'd be remiss in my duties to this thread if I didn't ask: any chance you can submit Kryoflux dumps of those titles to us? :-) If so, PM me an email address and I'll set up a Google Drive upload folder for you.

 

Sent from my Pixel XL using Tapatalk