List of difficult to copy disks

Moderators: DrCoolZic, Moderator Team

User avatar
npomarede
Atari God
Atari God
Posts: 1310
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: List of difficult to copy disks

Postby npomarede » Thu Apr 03, 2014 9:42 am

DrCoolZic wrote:I am also curious to learn that the STX file works with Hatari because from what I remember this protection tests that the track is less than 6300 bytes???

I can test this ; what STX file should I use and which track is it supposed to be ?

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: List of difficult to copy disks

Postby AtariZoll » Thu Apr 03, 2014 11:10 am

DrCoolZic wrote:I have also found a strange behavior of Pasti DLL.
In the STX file the length of the track is 6303 bytes and when reading the file under Steem with Panzer the track length is only reported as 6288 bytes ?
So it seems that Pasti DLL does not use the track lenght as the length of the track read command???
I am also curious to learn that the STX file works with Hatari because from what I remember this protection tests that the track is less than 6300 bytes???


DMA will transfer to RAM only when there is min 16 bytes in it's FIFO buffer. So, it is OK with 6303 . If track is 6304 then should transfer it complete. As I remember Jupiter Masterdrive fails if track is longer than some value ..
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 828
Joined: Mon Nov 04, 2013 5:23 pm

Re: List of difficult to copy disks

Postby JimDrew » Thu Apr 03, 2014 2:32 pm

The protection check fails with a track length greater than 6300 bytes. Tracks 2/3/4 are 6272/6272/6288 bytes on the original disk, according to Panzer.
I am the flux ninja

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2190
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: List of difficult to copy disks

Postby DrCoolZic » Sat May 10, 2014 4:47 pm

This post is for IFW if he is still looking at this tread.

I have tried to use your FdcShiftBit() routine in my program. I never had problem with my previous decoder routine for many years until I found the specific case used in the Jupiter master drive game: a 0x5224 MFM pattern followed by a 0x4489 pattern that should be decoded as a 0xC2 address mark byte followed by a 0x0B byte. So I have tried to use an adapted version of your routine in Aufit.

The result is that now I can read the “Jupiter master drive” "special" sequence correctly but now the normal A1 sync sequence at the head of every records is not read correctly.
The reason is the following: a normal sync sequence is composed of a set of several 0x00 (encoded as 0xAAAA) bytes followed by 3 A1 sync mark (encoded as 0x4489).

So we have a sequence of bit like this:

Code: Select all

0xAAAA 0x4489 = 1010 1010 1010 1010 0100 0100 1000 1001
0x5224                       0 1010 0100 0100 100

As shown this can be interpreted as a 0x5224 sequence followed few bits later by a 0x4489 sequence. In your program the first 0x5224 sync (returned as 0x14) is detected but the second A1 sync is rejected because placed at less than 16 bits apart.

The good news is that despite the fact that the A1 sync is not returned as a sync mark the synchronization is done correctly and therefore all subsequent bytes are decoded correctly.
So my question is: does your routine needs a “post-processing” action from the calling routine to put back an A1 to replace the first returned sync or am I missing something else?

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Sun May 11, 2014 9:14 am

Very busy recently so there was a high chance of missing out on your question - using email would have been safer ;)

There are multiple state machines operate in the FDC at the same time which can make it a bit difficult to understand what's going on.
What you get is how the FDC mark detector sees and transform the data from the disk.
Having found 3xa1 is state based in the FDC and has nothing much to do with how the values are transformed or not.
Check out any state machine dealing with sector header or data read to get the right idea.
Basically how the FDC sees and transform the data during read and how you may want to display or process the "real" data are two different things and you should not mix them, since it's not possible - they are two different views.

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Sun May 11, 2014 9:28 am

In other words: there is no 1:1 relationship, the FDC data read is a lossy transformation that may rob several data bitcells from the data stream, so retrospectively replacing the transformed value with A1 is incorrect, because that's not what happens.
You may want to check the signals and highlight what was considered an address mark and have a different view for the real data instead.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2190
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: List of difficult to copy disks

Postby DrCoolZic » Sun May 11, 2014 1:24 pm

I have also been busy lately and I am just restarting to look at Atari stuff :)

Of course I am not using the read data to update the FDC state machine.

Actually what happened is that I have been confuse by using CTA. Being lazy (I did not want to perform the test on real Atari) I have used CTA to look at resulting data from a CTRaw file. I was assuming that dump->sample (after setting sync to DOS) would display data as a read track would do. But I guess this is not true as the inter gap data are always displayed as 4E followed by set of 00 and the 3 A1 are also always displayed correctly. Therefore I assume CTA is probably doing pre-processing before displaying the data.

So I went back to a real Atari and did many read tracks … The first bytes takes a lot of different values but almost never 4E. The 00 are displayed either as 00 or as FF and the first sync is never displayed as A1 but most of the time as C2 or 14 (sometimes other values) and is of course always followed by two A1.
So having C2 or 14 for the first sync in the DSR is indeed the right result from the FDC.

Still unclear about the code that test possible overlapping 0x4489 AM? I do not think that there is any MFM bits combination that would result in two overlapping 4489????

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 828
Joined: Mon Nov 04, 2013 5:23 pm

Re: List of difficult to copy disks

Postby JimDrew » Sun May 11, 2014 3:10 pm

Use your Panzer program to read Jupiter Masterdrive and look at the results... you will find that one of the A1's is missing (changed to a different value). The FDC processes the bits on the fly, and certain combinations will flip bits. This results in the first expected A1 to be different, and that is perfectly normal. You can look at the decoded bit patterns and determine what bit orders cause the abnormality in the expected decoding.

Using SCP's editor I made a sequence of just about every combination of words and then read the track in Panzer to see the results.
I am the flux ninja

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Mon May 12, 2014 10:00 am

CTA does not display anything like FDC transformed data at all - it's just the pure bitcells and decoded data (but not in any way transformed).
All the rules in the AM detector come from hundreds of tests, so rest assured there is some weird stuff where some part was necessary to pass the tests for emulation vs. real hardware :)

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2190
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: List of difficult to copy disks

Postby DrCoolZic » Mon May 12, 2014 1:40 pm

Here is a typical output from CTA
This pictures shows the *perfect* 04E and 00 sequence in the GAP and the 3 A1 in the sync :)
CTA_Sync_seq.PNG

Does that mean that CTA does not use CAPS Lib to display perfect information?

Unfortunately I do not have an KF image for "Jupiter Master Drive"

Actually I really like the display from CTA. In Aufit I have experimented something similar where I do a sort of presynchronization at begining of the read track to display the 4E correctly rather than a "shifted version"
You do not have the required permissions to view the files attached to this post.

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Mon May 12, 2014 2:13 pm

The only perfect information you'll ever have is decoding the data as is, anything else is platform dependent, and does not represent the real bitcells recorded.
You'd have a very different processing for CBM drives, WD177x controllers like ST, Nec765 controllers like PCs, Intel 827x PC controllers, Amiga with various sync modes active, Apple drives and so on... pointless and inaccurate for any other platform.

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Mon May 12, 2014 2:17 pm

So, no of course CTA would never use data transformation coming from an AM detector simulation as accurate data - since it is not accurate at all, it just serves a very specific purpose and does not apply to any other platform at all.
That's why I said that you should really distinguish between the real data recorded and how a specific platform (be it Atari ST or something else) sees that data - it is never ever the same thing, except for one case: Amiga with all syncing modes inactive. That's the main reason why you could use an Amiga to sample anything as long as the base bitcells bands are the same, ie 2us or 4us.

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Mon May 12, 2014 2:22 pm

btw: the CTA output is not really synced. You selected the display start explicitly by filtering to possible sync values and that moves the cursor (the yellow line) to the selected sync value - which results in the output being synced naturally.
You can easily shift the decoding by various bitcell amounts using CTRL (1), SHIFT (4), CTRL-SHIFT (8).

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2190
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: List of difficult to copy disks

Postby DrCoolZic » Mon May 12, 2014 4:58 pm

IFW wrote:btw: the CTA output is not really synced. You selected the display start explicitly by filtering to possible sync values and that moves the cursor (the yellow line) to the selected sync value - which results in the output being synced naturally.
You can easily shift the decoding by various bitcell amounts using CTRL (1), SHIFT (4), CTRL-SHIFT (8).

Not sure I understand?
What I did, after analysis, was to select the sync to be DOS and select the sample from first revolution.

As a "standard MFM" format have been detected CTA knows the track structure and therefore it knows about the position and counts of the 4E 00 A1 etc.
When I select the first record does the display reflect the format information or the KF image information?
In other words are the 4E in front of the AM sync on the same position as the A1 selected ("backward propagation of the sync") or does this information comes from the format?
The fact that the C2 located in front of the A1 is displayed as A1 does this come from the format information ? or does CTA in this case just sync on the first A1 ignoring the C2 to follow the format information

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Tue May 13, 2014 12:02 am

Everything appears as it is recorded.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2190
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: List of difficult to copy disks

Postby DrCoolZic » Tue May 13, 2014 8:06 am

IFW wrote:Everything appears as it is recorded.

Exactly as *recorded* not as *decoded/read* by WD1772.
This makes sense as it is the purpose of CTA to construct the bits to send to a machine like Trace. Brilliant

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Tue May 13, 2014 8:38 am

Correct :)

wheeel
Atariator
Atariator
Posts: 28
Joined: Thu Aug 30, 2007 12:11 pm

Re: List of difficult to copy disks

Postby wheeel » Sat May 17, 2014 6:17 am

DrCoolZic wrote:I have tried to use your FdcShiftBit() routine in my program. I never had problem with my previous decoder routine for many years until I found the specific case used in the Jupiter master drive game: a 0x5224 MFM pattern followed by a 0x4489 pattern that should be decoded as a 0xC2 address mark byte followed by a 0x0B byte. So I have tried to use an adapted version of your routine in Aufit.


Hi DrCoolZic, it would be great to see another release of your ever-so-useful tool. I've noticed two minor glitches in the version I'm using (0.4c). Firstly, it never reads track 82 on side 2 (I almost said side 1, but realised that was quite ambiguous really!). The scp file has the track (I've checked in the SCP software). The other thing is that I quite often get a crash due to some .NET exception or other -- could the program trap these and give the user a chance to continue anyway at their own risk!?

The other thing I've found, and this may also be more of interest to JimDrew, is that I have a number of disks that are HD but used in the Atari ST so that they are really DD formatted. Of course, the ST didn't have the switch for HD so by-and-large this worked. I remember reading in a magazine at the time that using an HD disk in this manner wasn't at all recommended, but I only ever had a problem once that I can recall. But... these disks really confuse Aufit which can't seem to sync to the data at all:

screenshot.gif


At this point, I wonder how the SCP software works since if I put some paper over the HD hole and reread the disk, sometimes I can have a marked improvement (but not always). I had thought that the SCP software simply does a raw dump of the disk so that it didn't matter what was on it. Or, does SCP modify its behaviour if it reads from an HD disk? I have noted that Aufit totally fails to read a true HD disk, so I imagine Aufit simply doesn't support the higher data rate.

Cheers!
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2190
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: List of difficult to copy disks

Postby DrCoolZic » Sat May 17, 2014 9:06 am

Yes you are right the current release version stops at track 82.0. Next release will correctly read 82.1. Thanks for feedback on this bug.

Aufit crash. The program is still in beta and needs lot of more work but unfortunately you will have to be patient because I currently do not have too much time to spend on Atari stuff. There are two main reason to the crashes.
  • One is pretty bad and I need to fix it: there is a huge memory leak in the program as soon as you use the “Disk Layout” or “Disk Data” commands. The “layout window” uses a lot of memory and currently this memory is not released (seems easy but it is not :( ) therefore most probably the program will crash if you open another disk image … The solution is to close the program after using this command.
  • The other one is when reading very bad images. There still cases of improbable conditions that confuse the program. I say very bad images because most bad images (thanks to people that have provided test cases) are now correctly handled.

I am currently working (slowly because lack of time) to a new version that necessitate extensive changes internally in the data structures because I want to be able to read CTR and IPF files (as well as stx files). It will also incorporate a new transitions to bits converter based on the work done by IFW :)

As far as I know yes using HD on DD drive is a bad idea. I believe this is due to the fact that the magnetic particles used in HD FD are well suited to DD drive head. Therefore it works but it gives very marginal results. If this is some FD done years ago it should not give good results. If you are doing FD now *DO NOT* use HD FD.

SCP SW should not care if DD or HD FD is used. Making images should be fine because you are most probably reading on a HD drive. But if you produced the FD on an Atari you are probably in trouble.

The image that you publish shows a very very bad image. There are a lot of invalid transitions (shown in red) resulting in either fuzzy bytes. Look also at the histogram it shows a wide dispersion of the transitions above AND below nominal values. So this image cannot be used.
Seems also that the input file is incorrect as Aufit could not read it entirely?

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: List of difficult to copy disks

Postby IFW » Sat May 17, 2014 11:05 am

HD and DD drives and disks use different coercivity.
3.5 HD drives auto-detect the media type (using the HD "hole" to detect) and switch the circuitry accordingly during writing.
Most drives also switch the filtering circuitry during read using the media type, and this will give different readability characteristics.

In other words: if you have a 3.5 HD disk recorded in DD mode (covered the HD hole with a tape during write) you should do the same during read.
So if your HD disks don't read well and contain DD data, try reading them with the HD hole covered and see if it improves. If they were "properly" recorded (hold covered) then they will read ok. Such disks won't read properly on DD only drives.

It's a very bad idea of using HD disks for DD data unless you know what you are doing.

wheeel
Atariator
Atariator
Posts: 28
Joined: Thu Aug 30, 2007 12:11 pm

Re: List of difficult to copy disks

Postby wheeel » Sat May 17, 2014 8:27 pm

DrCoolZic wrote:I am currently working (slowly because lack of time) to a new version that necessitate extensive changes internally in the data structures because I want to be able to read CTR and IPF files (as well as stx files). It will also incorporate a new transitions to bits converter based on the work done by IFW :)


I can't help you with this, but I could certainly help you with bug squashing (memory leaks, etc.) if you'd be willing to share the source.

DrCoolZic wrote:The image that you publish shows a very very bad image. There are a lot of invalid transitions (shown in red) resulting in either fuzzy bytes. Look also at the histogram it shows a wide dispersion of the transitions above AND below nominal values. So this image cannot be used. Seems also that the input file is incorrect as Aufit could not read it entirely?


This is correct. This was one of a number of part-runs while trying to get best imaging parameters. The final image came out with only one dodgy sector that fortunately was in an unused part of the disk.

IFW wrote:It's a very bad idea of using HD disks for DD data unless you know what you are doing.


:D Yes, herein lies the impetuosity of youth: absolute and certain knowledge in all things!

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 828
Joined: Mon Nov 04, 2013 5:23 pm

Re: List of difficult to copy disks

Postby JimDrew » Sun May 18, 2014 6:12 am

You can change the characteristics of how the drive reads and writes by changing the density selection for reads and writes in the pull-down menu. We almost always used HD disks with the Amiga because the drives were low density only (no pin) and HD disks always worked better.
I am the flux ninja

wheeel
Atariator
Atariator
Posts: 28
Joined: Thu Aug 30, 2007 12:11 pm

Re: List of difficult to copy disks

Postby wheeel » Sat May 24, 2014 2:54 pm

JimDrew,

Looking at the file format description for the .scp files, I cannot find a bit that indicates whether disk imaged was high-density or not. It seems bit 1 of the flags field is set whether the disk is DD or HD and the documentation says this bit is only relevant to 5.25" disks. Could there not be a bit in the flags field that matches the High Density Select signal coming from the floppy drive? It would be great not to lose this information!

Cheers :)

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 828
Joined: Mon Nov 04, 2013 5:23 pm

Re: List of difficult to copy disks

Postby JimDrew » Sun May 25, 2014 2:13 am

Technically, we don't need to know the density. The only reason I have the density selection option is for drives that have their jumpers backwards (typically only 5.25" drives). The flux itself is different between high density and low density disks. I guess I could add a flag for this, but it's something that SCP doesn't need to duplicate disks.
I am the flux ninja

wheeel
Atariator
Atariator
Posts: 28
Joined: Thu Aug 30, 2007 12:11 pm

Re: List of difficult to copy disks

Postby wheeel » Tue May 27, 2014 4:49 pm

JimDrew wrote:I guess I could add a flag for this, but it's something that SCP doesn't need to duplicate disks.


I would say its worthwhile. Let's say this: it is only a single bit in the flags field and is a piece of information provided by the drive that is not currently stored... and it is potentially useful for emulation tools -- e.g. to adjust timings to sync to high-density flux information in a WD1772/Ajax emulator since this chip doubles its clock frequency when it detects an HD disk.

Also, your software could use it -- as a check for a user who tries to duplicate an HD disk onto a DD disk.


Social Media

     

Return to “SuperCard Pro Disk Copier”

Who is online

Users browsing this forum: No registered users and 2 guests