List of difficult to copy disks

[JimDrew]

Jim have you been looking at the problem of the SCP flux generated. It seems from dump of floppy copied that the first bytes of the stream on copied disk are totally out of sync.

I have analyzed "by hand" and with a specially designed program the bitstream provided and even with very "creative shift" I am not able to find C2 0B.

You are NEVER going to "find" C2 0B. You WILL find C2 A1, which is the correct flux data when decoded straight from MFM. However, as IFW has pointed out - and proven by Stefan's Panzer dump of the original disk, the WD1772 converts C2 A1 into C2 0B.

[IFW]

Just as Jim said.

[JimDrew]

For the sake of completeness, I checked every byte of your window against mine, in the image as well as the copy and it all matches.

Try this:

Load the Jupiter's Masterdrive image file into the SCP's analyzer. Select track 2, side 0. You should see the single 4489 followed by the normal sets of two 4489's for header and data blocks. You might have to bitshift the data to be able to see it clearly. Now, move the cursor a few hundred bytes past the 2nd set of 4489's and click "set flux end". Now, put in a blank disk and click "Write Image". That TRACK (not the image) will be written to the disk - this is an undocumented feature. You can then go read that track in Panzer and see that C2 A1 has magically turned into C2 0B. I am sure there are quite a few other combinations that will generate different (and most likely consistent) results. So, why did we set the track end to be so short? Because the image was created on a drive that is a lot slower than what most of us are using, if you are writing more than 1 revolution during the copy, you will end up with the track shifted and the start will appear at the end or over-write the first 4489. This makes sure we are dealing only with the data we want to check out in Panzer. The rest of the track will be blank (weak bits).

[IFW]

Jean,

See the attached pictures: it's the very same trick from Chambers of Shaolin.
Notice the 00 29 a1 sequence under the yellow line designed to confuse the AM detector on picture t1.
On t1-1 you see the same sequence from 1 bitcell earlier. Now you can that the same area shifted reads as 5224, one of the wdc recognized syncs.
You can create quite a few combinations of these sequences, which can yield different patters (including different patterns depending on which bitcell you start reading them, as discussed before); all you have to make sure is that one of the normal MFM values encoded would yield 5224 if shifted to some position...

[DrCoolZic]

still cant figure how to get the C2 0B
If you look at the picture provided (without any sync shift) here http://www.atari-forum.com/viewtopic.ph ... 25#p248484
you can see at position 20 on the data and on the clock line
... 4E 29 A1 CD ...
... 90 C2 0A 10 ...

So C2 0A is close to C2 0B but not the same + plus if synchronize on this pattern all char after the C2 0A are incorrectly decoded

[IFW]

Er... I said it a few times already... and not just me:

This is the pattern that fundamentally causes the state machine to change bits.
What you get as a RESULT when read through the WDC is a *different* sequence...
You get the "random" values like based on the current state of AM detector and shifter and comparator state machine.
You get various amounts of bitcells delayed.
If you want to know more details, what happens is well documented by the source code of the IPF library, as I said before.
Just run whatever bitcell pattern you like to see via the WDC emulator in the IPF library, to see the exact results.
C2 OB is one of the "popular" results you'd get

[JimDrew]

C2 0B comes from how the state machine handles the two consecutive sets of 000's. There is one before that issue that becomes C2 00.

Look at the MFM code.. the data we are concerned with is:

Code: Select all

A44A, A449, 1111, 12A4, 9249, 1254, 9254, A449, 4489, 5251, 4512, 5515, 2AAA  <--- MFM data converted from flux
 28    C2    00    1C    92    10    90    C2    0B    C2    B4    F7    00   <--- WD1772 interpretation of MFM data

A44A (1010010001001010) - invalid, contains 3 zero bits
A449 (1010010001001001) - invalid, contains 3 zero bits
1111 (0001000100010001) - invalid, contains 3 zero bits - 3 times too!
12A4 (0001001010100100) - invalid, contains 3 zero bits

9249 (1001001001001001) - valid
1254 (0001001001010100) - invalid, contains 3 zero bits
A449 (1010010001001001) - invalid, contains 3 zero bits
4489 (0100010010001001) - invalid, contains 3 zero bits
5251 (0101001001010001) - valid
4512 (0100010100010010) - invalid, contains 3 zero bits
5515 (0101010100010101) - invalid, contains 3 zero bits
2AAA(0010101010101010) - valid

So, you can see there are a LOT of invalid MFM bytes. The WD1772 has to figure out how to sync on these and output the proper data. I think the C2 00 and C2 0B are just how the state machine ends up for this sequence. It's going to take a bit of work to figure out all of the combinations, unless you made a replica of the state machine with some sort of table look up. .... or you can apparently just look at the source code for the ipf library.

[DrCoolZic]

Thanks guy look like I need to spend more time on this.
I already started to write a program with GUI to analyze these situations ...
Is this documented somewhere or just based on experience?

One last thing and after I shut up. You mention "invalid contains 3 zero".
By itself I think that 3 000 is OK as MFM is (1,3) RLL http://en.wikipedia.org/wiki/Run-length ... 2C3.29_RLL
4 zero is invalid. However in what you show there are invalid sequences of 000

Would be interesting to be able to write these kind of sequences (impossible to write on a real machine) with SCP to analyze the result with real Atari. Any easy way to enter sequences to write?
I have started to look at IPF code and it is interesting. At first glance the differences I see with my code is the delayed things and the overlapping A1 mark inside C2.

[Brume]

I'd definitely use an external PSU for any kind of old drive to be 100% certain of correct operation, including stable RPM for the drive, timely spin-up and head movement etc. 5.25 drives without doubt some 3.5 drives may work correctly, but...
I am not sure if I have seen any dumps made with your setup.

I can confirmed he did quite a lot and of excellent quality. Thanks Brume

Thanks DrCoolZic
I may have found an interesting case for you last week-end. I imaged a lot of games, and of them gives troubles to Aufit. I'm sending you an email atm.

[DrCoolZic]

For the sake of completeness, I checked every byte of your window against mine, in the image as well as the copy and it all matches.

Try this:

Load the Jupiter's Masterdrive image file into the SCP's analyzer. Select track 2, side 0. You should see the single 4489 followed by the normal sets of two 4489's for header and data blocks. You might have to bitshift the data to be able to see it clearly. Now, move the cursor a few hundred bytes past the 2nd set of 4489's and click "set flux end". Now, put in a blank disk and click "Write Image". That TRACK (not the image) will be written to the disk - this is an undocumented feature. You can then go read that track in Panzer and see that C2 A1 has magically turned into C2 0B. I am sure there are quite a few other combinations that will generate different (and most likely consistent) results. So, why did we set the track end to be so short? Because the image was created on a drive that is a lot slower than what most of us are using, if you are writing more than 1 revolution during the copy, you will end up with the track shifted and the start will appear at the end or over-write the first 4489. This makes sure we are dealing only with the data we want to check out in Panzer. The rest of the track will be blank (weak bits).

Excellent. I did not read carefully but this is almost what I was asking
Any possibility to directly modify the MFM bytes displayed ...
seems like it is possible to use insert byte to insert value in B (dont know what is usage of L?)
Actually it seems possible to enter value directly but you have to use number on the "regular KB" but does not seems to work with numeric keypad

[JimDrew]

You can switch to FLUX mode and modify the flux values. When you switch back to MFM mode, the new values are shown. You can not modify the MFM values and have them appear as the new flux data though (not yet at least). You already know the timing for bitcells, so you can easily create any type of MFM stream you want.

[JimDrew]

One last thing and after I shut up. You mention "invalid contains 3 zero".
By itself I think that 3 000 is OK as MFM is (1,3) RLL http://en.wikipedia.org/wiki/Run-length ... 2C3.29_RLL
4 zero is invalid. However in what you show there are invalid sequences of 000

A more accurate description is missing clock bits, which appear at 3 zeros in a row.

There are only so many MFM values are "valid" and used for encoding data.

This explains the sync mark pretty well:

http://en.wikipedia.org/wiki/Modified_F ... Modulation

[DrCoolZic]

I'd definitely use an external PSU for any kind of old drive to be 100% certain of correct operation, including stable RPM for the drive, timely spin-up and head movement etc. 5.25 drives without doubt some 3.5 drives may work correctly, but...
I am not sure if I have seen any dumps made with your setup.

I can confirmed he did quite a lot and of excellent quality. Thanks Brume

Thanks DrCoolZic
I may have found an interesting case for you last week-end. I imaged a lot of games, and of them gives troubles to Aufit. I'm sending you an email atm.

Got Starglider 2 - Short feedback
Quite interesting indeed Side 1 is using a lot of nice protections but it should be ok
Problem is on side 0 Track 0 and 1 needs more analysis
But track 02 to 78 are quite interesting first the gap are full of invalid char F7 but the interesting part is the ID segment
For example the first sector starts with A1 A1 A1 FE F7 F7 F5 F7 02 72
The first 2 F7 are the track and side number (both invalid cause normal bios read to fail) the F5 is the sector number (245 also invalid), the F7 is the track size (also invalid) followed by valid CRC
What is interesting is the size. normal value are 0 to 3. I was experimenting with invalid size values in Aufit and the release version was incorrectly setting the size to 512 instead of 1024.
I have corrected the problem. Here is the stx generated that seems to work but could not go very far as it is asking for information from a book I do not have

sg2.rar

Although the program seems to work like that the tracks 01.0 and 79.0 are strange strange.
This game packs a lot of interesting protections
Thanks

[Brume]

Got Starglider 2 - Short feedback
Quite interesting indeed Side 1 is using a lot of nice protections but it should be ok
Problem is on side 0 Track 0 and 1 needs more analysis
But track 02 to 78 are quite interesting first the gap are full of invalid char F7 but the interesting part is the ID segment
For example the first sector starts with A1 A1 A1 FE F7 F7 F5 F7 02 72
The first 2 F7 are the track and side number (both invalid cause normal bios read to fail) the F5 is the sector number (245 also invalid), the F7 is the track size (also invalid) followed by valid CRC
What is interesting is the size. normal value are 0 to 3. I was experimenting with invalid size values in Aufit and the release version was incorrectly setting the size to 512 instead of 1024.
I have corrected the problem. Here is the stx generated that seems to work but could not go very far as it is asking for information from a book I do not have

sg2.rar

Although the program seems to work like that the tracks 01.0 and 79.0 are strange strange.
This game packs a lot of interesting protections
Thanks

Wow, that's fast! Thank you!
So a new version of Aufit is expected soon, I guess

[DrCoolZic]

This explains the sync mark pretty well:

http://en.wikipedia.org/wiki/Modified_F ... Modulation

I prefer this one http://info-coach.fr/atari/hardware/FD- ... ress_Marks

[DrCoolZic]

Got Starglider 2 - Short feedback
Quite interesting indeed Side 1 is using a lot of nice protections but it should be ok
Problem is on side 0 Track 0 and 1 needs more analysis
But track 02 to 78 are quite interesting first the gap are full of invalid char F7 but the interesting part is the ID segment
For example the first sector starts with A1 A1 A1 FE F7 F7 F5 F7 02 72
The first 2 F7 are the track and side number (both invalid cause normal bios read to fail) the F5 is the sector number (245 also invalid), the F7 is the track size (also invalid) followed by valid CRC
What is interesting is the size. normal value are 0 to 3. I was experimenting with invalid size values in Aufit and the release version was incorrectly setting the size to 512 instead of 1024.
I have corrected the problem. Here is the stx generated that seems to work but could not go very far as it is asking for information from a book I do not have

sg2.rar

Although the program seems to work like that the tracks 01.0 and 79.0 are strange strange.
This game packs a lot of interesting protections
Thanks

Wow, that's fast! Thank you!
So a new version of Aufit is expected soon, I guess

Already sent to you
PS be aware that this is a not stable version with some experiment on sync mark but it shouuld be OK in most cases

[DrCoolZic]

You can switch to FLUX mode and modify the flux values. When you switch back to MFM mode, the new values are shown. You can not modify the MFM values and have them appear as the new flux data though (not yet at least). You already know the timing for bitcells, so you can easily create any type of MFM stream you want.

I love your tool

Please fix usage of numeric keypad much easier

[DrCoolZic]

Got Starglider 2 - Short feedback
Quite interesting indeed Side 1 is using a lot of nice protections but it should be ok
Problem is on side 0 Track 0 and 1 needs more analysis
But track 02 to 78 are quite interesting first the gap are full of invalid char F7 but the interesting part is the ID segment
For example the first sector starts with A1 A1 A1 FE F7 F7 F5 F7 02 72
The first 2 F7 are the track and side number (both invalid cause normal bios read to fail) the F5 is the sector number (245 also invalid), the F7 is the track size (also invalid) followed by valid CRC
What is interesting is the size. normal value are 0 to 3. I was experimenting with invalid size values in Aufit and the release version was incorrectly setting the size to 512 instead of 1024.
I have corrected the problem. Here is the stx generated that seems to work but could not go very far as it is asking for information from a book I do not have

sg2.rar

Although the program seems to work like that the tracks 01.0 and 79.0 are strange strange.
This game packs a lot of interesting protections
Thanks

Wow, that's fast! Thank you!
So a new version of Aufit is expected soon, I guess

Message bounced back for security reason. Your mailer does not like zip executable ... I will send it later but you already have the convertion. So just le me know if it works.
Already sent to you
PS be aware that this is a not stable version with some experiment on sync mark but it shouuld be OK in most cases

[JimDrew]

Please fix usage of numeric keypad much easier

The numeric keypad is not going to help you enter hex values A-F. I will look at adding support for the numbers. I don't ever use a numeric keypad for anything except cursor movements.

Edit: ok, added numeric keypad support. I have released a new version with that change and many others.

[JimDrew]

This explains the sync mark pretty well:

http://en.wikipedia.org/wiki/Modified_F ... Modulation

I prefer this one http://info-coach.fr/atari/hardware/FD- ... ress_Marks

Yes, this is nice but only covers C2 and A1 individually, not their affects when placed together, or with one of the many other MFM word values that are invalid (3 zeros in a row). I think you will have fun creating various MFM strings with the analyzer and reading those values on a real WD1772.

[DrCoolZic]

Please fix usage of numeric keypad much easier

The numeric keypad is not going to help you enter hex values A-F. I will look at adding support for the numbers. I don't ever use a numeric keypad for anything except cursor movements.

Edit: ok, added numeric keypad support. I have released a new version with that change and many others.

You people with American keyboards cant understand this kind of request
But if you are lucky to access the numeric keys directly, on a French KB you have to use the Shift key to access numeric values and this is a pain

[IFW]

SG2 is a dual-format disk; 0.0 contains boot code for both Amiga and ST, that's why it looks strange.

[Stefan jL]

I imaged Jupiters Masterdrive with external power for the diskdrive... i still cant copy the disk and play on my ST so i guess both my drives are bad? Can anybody verify that these two SCP images are bad? http://www.ym2149.com/scp/jupiter_external_power.zip

[JimDrew]

I will take a look at the images. One thing that you can do to see how stable your drive speed is - use the analyzer and read a track over and over again and note the "Time:" value. It should vary really no more than a few microseconds every time you click the READ TRACK button.

[Stefan jL]

ok, then it is not good even with external power... since i get between 199964 - 200005