SuperCard Pro PC software

[JimDrew]

OK, so it's a straight 1:1 dump with no sector interleave then. Thanks for the info!

[Hippy Dave]

OK, so it's a straight 1:1 dump with no sector interleave then. Thanks for the info!

Yes.
.ST is above interleave, so don't think interleave. Interleave is done at a lower level.

[JimDrew]

Got it! Thanks again!

[DrCoolZic]

This might help you.
I have not yet really worked on the doc

[JimDrew]

New version of the SCP software has been released. A few fixes in the analyzer and the addition of Amiga ADF file creation. Not too exciting for Atari ST folks, but this is the gateway to making a .ST file (and recovery) from ST disks. I have a great DSP routine that can extract valid data from really poor quality flux. I can convert Amiga disks that have no chance of ever reading in an Amiga. I expect the same for the .ST disk conversion too.

[Brume]

New version of the SCP software has been released. A few fixes in the analyzer and the addition of Amiga ADF file creation. Not too exciting for Atari ST folks, but this is the gateway to making a .ST file (and recovery) from ST disks. I have a great DSP routine that can extract valid data from really poor quality flux. I can convert Amiga disks that have no chance of ever reading in an Amiga. I expect the same for the .ST disk conversion too.

This seems to be fantastic!
If you can do the same for Atari ST disks (non protected disks),please do! Would be a great addition to the imaging process

[JimDrew]

I am working on it. It turns out that this support is actually pretty critical since most popular computers used the WD177x (and compatible) series controllers. So, Atari ST, IBM 360K/720K/1.44MB, Mac 1.44MB, CBM 1581, most midi keyboards, etc. all use the exact same disk format. This would let you generate a .st/.msa/.dsk/.img/ whatever you wanted to call it file that would work with many different types of computer emulations.

[Brume]

I'm still very interested in this feature (imaging disks into .st or .msa formats with SCP).

Any progress, Jim?

Thanks and good luck

[JimDrew]

I have been working on the floppy drive emulator portion of SCP. This feature will let you use the board like the HxC device. I need a break, so I will go look at the imager again.

[JimDrew]

Updated SCP software to handle the new firmware version (beyond 0.99) correctly.

[JimDrew]

New version of the PC software was released. I optimized a few parts of the code dealing with highlighting text, and I added start, end, and length information for a highlighted block (in real time). This lets you use the highlighting to figure out the number of bytes between two points.

[DrCoolZic]

Thanks
Documentation updated?

[JimDrew]

There is no documentation for the analyzer, and I am not really excited about making any because it is very complex and anyone who knows what the analyzer does should be able to easily figure it out. All other documentation is current.

[JimDrew]

Lots of stuff coming for SCP...

Now that FPGA Arcade supports .scp images for the Amiga core, adding that support to the WD1772 emulation for the ST core will be pretty easy. So, I am back working on some new things, including converter routines for converting a ST disk to .dsk or .msa and also for converting the other way - .dsk/.msa to .scp. I am also making .adf to .scp for Amiga disks.

SCP has always had the ability to write disks back, including weakbits and no flux areas. .scp image files are used by several different emulators and now several 3rd party applications use the SCP hardware directly.

I am testing/debugging the floppy drive emulator support. You will be able to replace your ST's floppy drive with a SCP board. I am making the control interface compatible with the HxC software, but using .scp flux images for 100% compatibility.

[TheNameOfTheGame]

Lots of stuff coming for SCP...
You will be able to replace your ST's floppy drive with a SCP board. I am making the control interface compatible with the HxC software, but using .scp flux images for 100% compatibility.

Definitely waiting for this. Sounds good!

[JimDrew]

By popular demand, I am adding an option to test each track to make sure the disk media itself is good prior to writing the track's data.

You can also use the Media Integrity Test that is in the Utilities menu if you wanted to test a batch of new disks. The test is very accurate - a precise bitcell duration is written and then read back, checking for the deviation and the write splice. I allow a +/- 350ns variance from center line. Anything outside of that is deemed bad. With a good disk and good drive, that deviation will always fall well within +/-50ns. So, +/- 350ns is a huge window.

[DrCoolZic]

I believe it would be better to do a verify that the data have been correctly written rather than guess they might be written correctly?

[JimDrew]

Sure, a verify would be best. But if the drive is good and a disk is tested as good, then it is highly likely that a copy will be good as well. A native format (Atari, Amiga, PC, etc.) verify is easy enough to do. A flux level verify is more difficult, but I think I have that working now. The issue has to do with WHEN the index actually appears vs. the first bit cell and the write splice. That first bitcell can be shifted, so I have to shift the data buffers so that they match. I am going to make a definable compare window for the bitcell duration. This way you can specifiy the amount of error margin in the bitcell duration that is allowed. The write splice is something that will always be an issue because even though SCP is very good about overlaying the write splice in the exact location, that particular bit cell can be off by several microseconds - which is enough to cause a decoding error. However, with a verify option and a narrow compare window, the track can be re-written over and over until it matches exactly. Drive speed is the key reason why the bitcell duration is off. 99.9999% of the time, this won't matter. But if some protection is looking for data under the index pulse, and you are copying with the index mode, that write splice has to be perfect.

[DrCoolZic]

I was trying to image a disk today and got the error "Read length RAM capacity!"
I thought this bug has been fixed long time ago?
I am using SW 1.5 HW 1.1 FW 1.0

Edit: As did not go with 5 rev I have tried 4 rev it fails also but instead of first track it fails after 50 something tracks
4 rev is already bare minimum for preservation

for reference Dr.T Tunesmith

[DrCoolZic]

When trying to image disk if no disk present you are getting "no index found"
You are proposer to retry but if you now insert the disk it complains about no disk drive selected?

[DrCoolZic]

On another program I am again getting again the RAM capacity error.
But what is strange is that I have two original disks with the same program on it: One can be imaged without problem the other one fails on track 0

EDIT:
looking at the images generated with Kruoflux the only difference is in the last sector that contains fuzzy bits.
Both uses a partially unformatted region but wit a quite different pattern

for reference Dr.T Tiger (black disk)

[JimDrew]

It could be that the "fuzzy bits" values are extremely large and thus cause the track to be >125K entries in size per revolution. Read two revolutions with the editor/analyzer and go look at the flux display to see how many flux transitions are being reported. 512K of RAM can store 4 revolutions at 125K per revolution, but most tracks average around 65K in size, so 5 revs is not usually an issue. The fix I did before was to remove the protected memory area in the 512K RAM so that it all could be used as a buffer. To fix the issue you are seeing I would probably need to enable the USB streaming. You could then select a million revolutions. I am not a fan of streaming because of potential USB issues with slow computers or background tasks halting the USB operations.

I will look at the no index and then no disk selected issue.

You could upload a two rev version to that retro backup site and I can look at track 0 to see what is going on.

[DrCoolZic]

Yet another Ram capacity error

for reference: Dr.T Level II KeyDisk Update

[DrCoolZic]

Yet another one - same problem

reference : Thunder blade D1

EDIT: Amazing I wanted to test your analyzer stuff ...
Went back to copy mode with 5 revolutions and now it miraculously works ????

[DrCoolZic]

It could be that the "fuzzy bits" values are extremely large and thus cause the track to be >125K entries in size per revolution. Read two revolutions with the editor/analyzer and go look at the flux display to see how many flux transitions are being reported.

Where do I find the number of flux???

I took one FD that cause the problem and I have read the faulty track with 5 revolution without problem
This track uses a partially unformatted sector. Nothing very unusual

ram problem.PNG