Doing some SCP tests

[Stefan jL]

I realized i had windows 8 on my laptop so now i could use DrCoolZics Aufit programs SCP to STX converter for faster testing with emulator (Steem)

I really wanted to know how to identify bad disks, so i did SCP images of disks that did not work on my ST... G-Loc, Star Wars Trilogy Empire Strikes Back and Speedball US version. dowload here: http://www.ym2149.com/scp/non_working_disks_scp.zip
To my surprise so did G-Loc actually work in Steem after i converted it to STX? And i thought G-Loc was the one that looked most weird when checking it with the flux display using Jim's SCP software Anyway the disk don't work on my ST, i havent written it back to disk and i have not tested the original disk on all my ST's... maybe it could be as with Bad Company and only work on some ST's.

Anyone is welcome to point out what to check for identifying bad disks with those "bad disk" images (except G-Loc wich could be a good disk?).

Also for DrCoolZik here is Eco SCP with firmware 0.6: http://www.ym2149.com/scp/eco_atarist_firmware_06.zip

And i decided to make an SCP of "Lethal Weapon" as that is a troublesome disk on my ST, almost half of the time i start it so does it say "illegal copy" on title screen and stops working. AtariZoll said it could be a bad disk, wich could be true. I just must mention that before i had the original so did i have a cracked version also and it did happen with that one also... i first thought it was a joke... i mean saying "illegal copy" on a cracked version

I imaged "Lethal Weapon" 6 times and one of them was working in Steem without saying "illegal copy".
Here are both the bad copy and good copy of Lethal Weapon... can the "illegal copy" be seen with the SCP analyser or Aufit that it is a bad copy?
http://www.ym2149.com/scp/lethalweapon_atarist_scp.zip

[Jeff_HxC2001]

I imaged "Lethal Weapon" 6 times and one of them was working in Steem without saying "illegal copy".
Here are both the bad copy and good copy of Lethal Weapon... can the "illegal copy" be seen with the SCP analyser or Aufit that it is a bad copy?
http://www.ym2149.com/scp/lethalweapon_atarist_scp.zip

From the hxc software :There is some bad sectors on the bad one. But it seems that there is also a bad sector at a different place in the good one...

hxc.jpg

[DrCoolZic]

Hi Jeff. Nice images Something new in your software. I really like layout representation for FD

Stefan: I am aware that there are still a lot of cases that crashes Aufit especially with bad image input.
There is still a problem with SCP on No Flux Area. Currently if the NFA is located on top of the index the first flux is not placed in the file in the first revolution. So if you have a track with an NFA of 10ms located 5ms before and after the index, then the data provided for the first revolution will be shorter by 5ms. Jim is working on the problem. FYI in such case KryoFlux outputs a 10ms flux and indicate that the index is placed at 5 ms inside this flux so you get both the righ flux lenght and the right position.
In many cases where the NFA is over the index Aufit will most probably crash
I have also found that using an image created in blind mode will in most cases also crash Aufit. Remember that you should not even try it because to work Aufit needs at least 3 or 4 revolutions and better 5.

I will be travelling for the coming weeks and I will not have the opportunity to work on Aufit so all these fixes will have to wait ...

[JimDrew]

There is no way to "read ahead" of the index on the first revolution, so to duplicate a NFA that occurs sometime during the index will require you to read two revolutions (non-blind mode). The NFA read/write works very well and I won't be changing it.

[DrCoolZic]

There is no way to "read ahead" of the index on the first revolution, so to duplicate a NFA that occurs sometime during the index will require you to read two revolutions (non-blind mode). The NFA read/write works very well and I won't be changing it.

Just to make sure I understand: The first transition in the first revolution will be missing, the index time of the first revolution will be incorrect, the position of the first transition (the NFA) in the second revolution relative to the index will be unknown.
Therefore the only way to find that there is a NFA over the index is to detect that the index time of the first revolution is incorrect?
On the second revolution if the NFA is over the index will the index time include only partially the NFA or will the index time be longer than normal?
In other word will the NFA be split in end of 1st rev begining of 2nd rev or not?
I have to think about this but it will be difficult to find the original data

[DrCoolZic]

I have been thinking on best solution to fix this problem.
One possible solution is to consider that information from first revolution cannot be used and just always throw it away (this would be somewhat similar to KF where the data before first index cannot be used). This would reduce the number of usable revolutions to 4.
But I cannot figure out how to find the position of the index inside the NFA. I have been thinking about having the transition split but this would obviously gives wrong information! However not having the NFA split would also result in wrong track length.

So I am stuck ?
Any suggestion

[DrCoolZic]

@Stephan
I do not have time to look at your images before my travel but here are some ideas that I want to share ...

On some of the disks that I have imaged I have noticed that on some sectors the data are sometimes read correctly and sometimes incorrectly on different revolutions.
This results in Fuzzy bytes but in fact they are obviously not fuzzy bytes. You can find out by looking at the CRC if in some revolution the data read without CRC error this means that the data are correct.
Note that all this is part of normal reading with a floopy drive

Therefore I have been thinking at adding an auto-recovery capability in Aufit. The simplest form would be to look at several revolutions and if one or two are good then always use this information and forget about the bad one. A more advance auto-recovery would be to use the same mechanism used on real Atari and on KF ==> read all the sectors of a track and if the result are incorrectly decoded performs several retries (on Atari there are 5 retries with eventually a seek in between to clean the head from dust). This should be possible when Jim release the kit that will allow to directly command the floppy drive.
Another area is also to modify the DPLL parameters to recover from disk with bigger speed variation. Currently the parameters are set to 10% variation but would be easy to relax to 50% or more.

Bad disks are sometime a mystery. I had some disks that looked pretty bad with flux varying a lot from normal position and that would decode perfectly and some others that looked almost perfect but did not decode correctly. So result are somewhat unpredictable.

What is interesting with doing thinks in software is that you should be able to perform some smart recovery techniques not feasible with original FDC. So it should be feasible to image successfully disks that dont even work anymore on Atari

[Hippy Dave]

There is no way to "read ahead" of the index on the first revolution, so to duplicate a NFA that occurs sometime during the index will require you to read two revolutions (non-blind mode). The NFA read/write works very well and I won't be changing it.

A circular buffer or similar allows you to capture data before the trigger event.

[JimDrew]

There is no way to "read ahead" of the index on the first revolution, so to duplicate a NFA that occurs sometime during the index will require you to read two revolutions (non-blind mode). The NFA read/write works very well and I won't be changing it.

Just to make sure I understand: The first transition in the first revolution will be missing, the index time of the first revolution will be incorrect, the position of the first transition (the NFA) in the second revolution relative to the index will be unknown.

The index time will always be correct. That is measured index pulse to index pulse.

Therefore the only way to find that there is a NFA over the index is to detect that the index time of the first revolution is incorrect?
On the second revolution if the NFA is over the index will the index time include only partially the NFA or will the index time be longer than normal?
In other word will the NFA be split in end of 1st rev begining of 2nd rev or not?
I have to think about this but it will be difficult to find the original data

For duplicating disks it does not matter if there is no NFA in the 1st revolution. For non-blind copies, 2 revolutions are captured. The first revolution is written out along with some part of the 2nd revolution - ending at the next write splice (which could be immediate or at the end of the 2nd revolution, depending on the disk).

Right now, with KickOff2 (which has the NFA in the middle of the index), the first revolution does not have a NFA at all, but the 2nd revolution (actually starting at the end of the 1st revolution - extending into the 2nd revolution) has the NFA like the original.

[JimDrew]

There is no way to "read ahead" of the index on the first revolution, so to duplicate a NFA that occurs sometime during the index will require you to read two revolutions (non-blind mode). The NFA read/write works very well and I won't be changing it.

A circular buffer or similar allows you to capture data before the trigger event.

True, but then you lose your index reference. We need a reference point. So, in the case of KickOff2 even if the NFA is captured starting at the index the NFA is shorter than when captuing it between the 1st and 2nd revolutions. There is no win here other than throwing out the first revolution if you are trying to convert the data to an image. For making copies, it doesn't matter because the track is wrapped around 1 revolution, past the index, and stopping at a write splice which makes it just like the original.

[Stefan jL]

From the hxc software :There is some bad sectors on the bad one. But it seems that there is also a bad sector at a different place in the good one...

When i used Aufit so did only the protection show as red marked... although i am not sure how to use Aufit properly. Could you check the other images i did of Lethal Weapon? They are all "illegal copy" http://www.ym2149.com/scp/lethalweapon_ ... tarist.zip

DrCoolZic... ok i did not know i must use revlotions, i just used the preset of SCPro software.

Also here is a SCP of "Bad Company":
http://www.ym2149.com/scp/badcompany_sc ... tarist.zip
This is the "16-bit pocket power" release and is very troublesome to get working on Atari ST, it is not just my copy that has problem other people has also maked note of the problem with their Bad Company disks, when i first did an STX of it so did only one of my 5 Atari ST's manage to make it properly.
SCP did not seem to have problem at all to copy it, and at least the "SCP to STX" works fine in Steem

[JimDrew]

Aufit uses multiple revolutions to compare the flux data and generates the .stx image. So, you should make the image with blind mode turned off (no check mark) and the revolutions set to 3 or 4. Of course you don't need to to that if you are making an image just to make a copy.