JimDrew wrote:The data coming out of the drive is spooled into the file. So, whatever transitions that are occurring on the RDData line for THE DRIVE BEING USED, are what is placed into the file. Some drives do not allow for more than 1ms of flux transitions, while others allow for much longer transitions. It's all drive dependent. I am still waiting for my Turrican to arrive from the U.K.
JimDrew wrote:Ok, many of your questions are already answered in our support forum... but I will address them here too.
Download the manual! Administrator mode is required for installation. Information about every single option is included in the manual.
I am not sure why you are getting asked to update your firmware, but v0.93 is the latest version. So, if you have only v0.92 installed then that would definitely be why! v0.93 corrects the problem with the hanging on non-blind copies that you saw with it hanging on track 69.
The limitation on bit cell size is 65535 (which is multiplied by 25) to get the actual flux transition time in Nano seconds. So, it is possible to have up to 65535 * 25ns (1638375ns) represented in a single cell.
There is currently no way to specify the number of revolutions to dump. Blind mode dumps a single revolution (which is all that should be needed for most Atari ST disks). Blind mode off dumps 2 revolutions (was 3 with v0.92 and that caused some OS issue when files were >32MB in size - I am looking into that). I will be adding a way to specify number of revolutions in the future.
Note: all orders placed from today one will have pin 5 removed from the 34 pin socket to make it work with newer cables. I also have a bunch of floppy drive cables compatible with SuperCard Pro along with 3.5" power cables. I will be putting these online shortly.
Yes, you can write immediately with SuperCard Pro. You can copy disk to disk or you can make a disk image and write the image back to disk.
JimDrew wrote:The auto-update function needs your permission to update, which is why it asks you. It wasn't until recently that I even had v0.92 by itself. Before then we were on v0.70 which would auto-update directly to v0.92 (and now v0.93). The auto-update feature is very convenient. No need to go to our website or forum area to download anything, it happens automatically. I guess I could make an option where it doesn't ask you and just does the update.
When my Turrican arrives, I will look at how to extend the bit cell times from the maximum of 1.638375ms to some higher value. I do have a timer wrap interrupt that should be queuing when the bit cell time exceeds 0xFFFF. That must not be working, and I have never cared before because I have never seen any disks this way.
I believe I have fixed the checksum issue now that was causing some image files (multiple revolutions) to not show any data.
You can see the raw MFM data, which is much more important that the converted data that you are use to seeing because it shows you the real flux data as it is decoded to MFM, which does not necessarily match a straight conversion to WD1772 decoded data. I see many cases (actually most cases) where there is an extra flux transition after the SYNC (4489 = A1) and the header, before the next SYNC. I am not sure if this is a bug in the WD1772 or if this is the result of the writing being turned off and back on. I know that most disk formatting routines wrote entire tracks out and sectors are written individually after finding the header. The write splice that occurs there would be something that I would expect, and apparently the sync detection in the data separator ignores any invalid flux up to where the sync begins.
I don't think you need multiple revolutions for fuzzy bits. I am pretty sure the WD1772 uses a window comparator for each of the 3 specific windows. Any values too far outside of these windows would have to be invalid. Can you get raw MFM out of the WD1772 controller? If so, were there any MFM editing utilities for the ST? For the Amiga, I used my MFM/GCR editor, which is somewhat like my analyzer is now. I could read/write tracks directly on the Amiga, alter data, etc... all at the MFM or GCR level, not decoded. If there is the ability to view MFM on the ST, then perhaps some test tracks can be made to check just how out the data can be and still have the WD1772 read it.
You can fill flux values and write those with the SCP analyzer. By the way, I am finishing up the SDK for the SCP hardware. Since you already have the .scp image file format integrated into your program, you could read/write real disks using the SCP hardware pretty easily. You have to open the driver (I have C examples), and send it packets to turn on the motor, and step the head. The flux read routine gives you the same data that you are using in the file (raw data + the 5 seperate entries). So, it would be simple enough for you to add this support.
Users browsing this forum: No registered users and 1 guest