SuperCard Pro Flux Image format (.scp)
Personally I prefer the DPLL approach to read flux transitions.
This is what is actually used in the WD1772 and I am trying to have a behavior as close as possible to the WD1772 in my program. But in fact this is not really directly connected to the WD1772 as a PLL is always used as input to any FDC (whether integrated or external to FDC). There are numerous application notes on how to process input data from floppy drive with analog and digital PLL and long time ago I used to know well this subject when providing customer’s support for the Intel 8272 FDC!

I have modestly contributed to the debug of the VHDL model of the WD1772 created by Wolfgang Förster ( and my code implement the same DPLL described in patent 4,780,844 The code was not very difficult to write but it was tricky to set the different parameters to get the good behavior. My code can handle flux for double density and high density but not for single density (this is independent of FM / MFM) but it can be adapted. In a near future I intend to release the source of the tool I am currently writing and as Jim mentioned yes the prototype already works with scp files. It provides nice graphical outputs of the input flux but the code only works for DD MFM floppy disks as used on Atari platform. According to Jim it seems you can do without a DPLL to shift bits in but I am still not fully convinced that you get the exact same result as when using a DPLL. Floppy drives / disk suffer from two types of “flux speed” variations fast and slow (simplified) that must be compensated by different mechanisms. The slow variation (usually due to motor irregularities) are compensated by adapting the clock of the DPLL and the fast variation are used to adjust what is called the inspection window. This is critical in cases of what I call border bits (bit that can be interpreted as 0 or 1) in the range close to 5µs to get accurate results. However this may be “academic concerns” because in most cases it is not so important if one bit gets detected incorrectly because by definition fuzzy bits are fuzzy!

Currently my software allow 9% variation on the input frequency as it seems to be the behavior of the WD1772 for DD/MFM but this can be changed easily for example to read damaged FD. Note that on “good FD” 9% is more than enough as the protections used on Atari only vary the clock by 5%.

Concerning the flux range one quick note: Looking at DD floppies I have never noticed any transitions below 2µs and (apart from No Flux Area where you get artificially several ms) the range can go up to few hundreds microseconds on unformatted diskettes. The histogram of fluxes reparation on unformatted diskettes seems to be influenced by the type of media used (for example DD floppy disks versus HD) …
For information the prototype of my program progress at reasonable speed currently it take either SCP or KF raw flux as input and displays all sort of nice representation of the data for example look at

Very bad input partially recovered

Speedlock protection +5% -5% variation on first sect

Disk with No flux area (in yellow close to the index)
Back to the subject of SCP file.

I wonder why you did not use a slightly more open format so you don’t run into this kind of problem.
To get information from the file you use pointers which is fine but at the same time you define fixed emplacements? What for? You already have first/last track info in the header so why not just put only the required number of track data header (this is actually how my program works so I should not care about changes in your format). On the same vein you specify the number of revolutions sampled so why reserved space for revolution not used? Could just loop to read the number of revolutions specified in the file header?
Not important just some thought
By the way seems like latest version still says 0-163 for track?
ACK! You are right, the latest version was uploaded to the wrong folder! It is now there.

The only "fixed" thing in the file format is that there are 5 entries of 3 long words for each revolution. You can have flux data placed anywhere because it is pointer based, but you were concerned that the revolutions would not be stored sequentially, so I made a note to not break up the flux data (although you could still break them up and have the data correct based on pointers). I have limited the revolutions to 5 because that is what will fit in the on-board RAM of the SCP board, and since I have made this product so you don't need a PC to drive it, I wanted to keep that compatibility. I could have made the entries based on the number of revs, but that would still be limited to 5. It makes it easy to use a hex editor and search for 'TRK' and I can see the info easily when there is a padded space. Storing a few hundred extra long words is not going to make a big impact on file size. Also, there already thouands of .scp files that have been created and support added by several emulations an even HxC, so I won't change the file format now.

My MFM decoder uses anything higher than 5.2us and anything lower than 7.2 us as 6us. So, 5.2us and lower is considered 4us and anything above 7.2us is considered 8us. Of course, any data that is below 2.9us or above 9.2us is considered weakbits. This really for just showing you in the analyzer. You never need to know any type of decoded data to copy disks using flux.
Is that disk GhostBusters II? Your original post stated "Ghostbuster" (no 's' on the end). If it's GhostBusters II (like from the movie), I have seen this disk on eBay and will buy it.
Yes Ghostbusters II

Similar to Turrican NFA but slightly different.
On the first rrack there is a lot of long transitions instead of NFA. I do not know if this is due to age of floppy or if it is by design?
Thanks for the info.
I have been thinking about what you have said about making the .scp format a bit more open... I know YOU want to store more than 5 revolutions, and after looking at my info it appears that I can go ahead and change the specs to allow as many revs as you want without breaking the existing images! Fortunately, everything is offset based. If you are using the offsets and not hard coding what is typical when created by SCP (like 0x00000044 being the first offset to flux) then any program should be able to handle as many revs as are specified in the main header. For every rev you would have 3 long words (time, length, offset). You wouldn't have empty entries like we do now. Also, we really don't need to store the length of the flux space available when a disk is read/write capable. Read/write capable disks only have one revolution. The program that creates the read/write image (SCP, HxC, etc.) should be padding the flux space to the maximum size for the disk type. The flux data is placed in this space (starting at the beginning of course). The program using the image file only cares about the current track length (number of flux transitions) and should have no worry about exceeding the maximum space when expanding/contracting tracks. So, I think I will make these changes to the specification.
Good let us know.
And NO I do not want more than 5 revolutions in fact I think 3 is fine and 4 is perfect!
But I think it might be interesting in some cases to go beyond 83 tracks (although not convince).
I was only doing this proposal because for me it makes more sense but again it is really not that important.
ALL of the 3.5" drives I have here are hitting the metal bracket on track 82, with no possibility to go to track 83. The Chinon drives used in the Amiga could not make it to 82 most of the time.
Latest release supposed to handle strong bits. Is this right?

SPC format need to be updated (by the way do a search for 164 you still heve wrong info in some places).

If I understand correctly with the new version of the sw and strongbits the format is upward compatible but not downward compatible. Trying to red a new file format with old software will read without error but will provide wrong results.

Is the revision number of the file (major or minor) bumped?

It used to be that you could take the "length of the track in bit cells" as the number of entries in a buffer but this is no more true. For example if you have a buffer with 0 0 a in fact this is only one entry in the output buffer. Is this right?

So the actual number of entries in a buffer using 32 bits int will the number flux provided minus the number of 0 entry found.
If you want to read sequentially all flux from all revision you need to take care of this to avoid "holes" between revolutions.

Let me know if the above is correct.
I am modifying my code and I want to make sure I got it right

Users browsing this thread: 1 Guest(s)