Trouble with very odd 3.5" format
The USB/FIFO test runs but neither reports success or failure. It just displays send/receive and an incrementing byte value but nothing else. I'm guessing if there was a problem it would be displayed?

I have used this same computer to image a few hundred disks and there has never been an issue.

Is the uC on the SCP just clobbering the FDTI FIFO/USB interface and overwriting the buffer? I'm surprised that there is no data integrity check on the PC side of things (CRC etc.) 

I did use the laptop to image the two disks for the TPPD1/2 and I made duplicates of each so I'm certain the SCP works fine.
If the USB test fails it stops and tells you the exact problem. I am not sure to think. Did you add a new USB device to your computer recently?

The SuperCard Pro just sends/receives data from the USB FIFO chip. There is a checksum of the transfer, so if the data was wrong you would immediately get a USB error during the image/copy.
I am perplexed as well. I have not installed any new USB devices. The FTDI driver installed is the latest one (from 2018 as I recall). I even unplugged all USB devices except the KB and mouse which did not help. I did just notice that if I unselect 'Re-seek track 0' I will get a red line the first time it tries to read that track and if I try it again the red line is gone. If I re-enable the 'Re-seek track 0' of course I get the red line.

As I was writing the above I got to wondering if there was any sort of configuration file somewhere other than C:\Program Files(x86)\SCP. I found C:\Users\**user**\AppData\Local\SCP\scp.ini. Nothing really looked odd but I added a '.x' to the end of the file name and when I started SCP it created a new .ini file. 

After it generated a new .ini file it now works fine! What the heck?? That only thing that is really different, other than file paths and disk type settings, is the 'Past Radix' under the Analyzer section. Maybe there is some garbage character throwing off the parser? I did not look at look at the files with a hex editor. I put both in a ZIP file and attached to this post. 

I'm glad that was it but am really curious what was wrong with the original .ini file.

Attached Files
.zip (Size: 859 bytes / Downloads: 1)
I just ran a diff on the two files: both IHSRed and PasteRadix are different. I'm guessing that IHSRead and IHSWrite should not both be set to TRUE?
That is "Paste Radix", used for the copy/paste function in the editor/analyzer.

The is simple - your IHSRead was set to False.  Look in the pull-down menu under INDEX SENSOR->READ.  This should be set to REQUIRED for 3.5" disk drives.  That option is to allow reading the back side of a 5.25" disk (using a 5.25" disk drive).  I would not expect this to cause a problem when using a 3.5" disk drive though.  The drive must have some sort of really long start-up delay that is masked when waiting on the index pulse.  I guess that is why the drive appears to be outputting nothing for a period of time.  Since there is no way to know what type of device is connected to SuperCard Pro, there is no way to automatically setup various options by the software detecting something.  You always want the INDEX READ and WRITE set to REQUIRED for 3.5" disk drives.
(10-05-2020, 03:39 AM)admin Wrote: The is simple - your IHSRead was set to False. 

I must have set that to false ages ago when I was imaging the back side of some 5-1/4" C64 disks! The issue was not the drive spin up time it was the seek time. It always read track0/head 0 fine as it did not have to seek.

Now I['m wondering if there is a way to 'stupid proof' it. An idea would be to have a setting to denote what type each attached drive is. Even if one were to plug in a different drive it would be an easy matter to select the drive type which would then allow for confirming/double checking settings, greying out settings that only pertain to a given drive type. Another thought is to treat IHSRead and IHSWrite as True if the Copy Mode is set to Index.

Well, it was a learning experience anyhow.
I experimented with this a bit.  My 3.5" drive always has this issue, no matter what I do for seeking.  I get no fewer than 80,000 bit cells of time (nearly a full revolution) of no data coming from the drive if you don't wait on the index pulse.  I am guessing that this must be something to do with how the reading works with the 3.5" drive mechanisms.  I never noticed this before because this option is really only to be used with 5.25" disks, however, I do use with other types of devices (like tape drives).  The Disk Type is sort of an "auto filler" for the tracks and that's it.

I can pop up a message stating that the drive is not spooling data if the very first bitcell ends up being a strong bit (which is what we call this in the protection scheme world).

I would like to re-write the entire copier application in C++ (it's written in Visual Basic 6 right now).  If someone were to make a Visual Studio/C++ template that had a basic interface (like a few buttons and such), I could figure it out from there and write a new copier.  I am just not familiar with Visual Studio enough to create something from scratch.  With a new copier I would make things like selecting the drive type would invoke various settings, and at that point analyzers for different disk formats would be easy to add in as plug-ins.
I could send you a basic form in VS2017 or VS2019. Have you considered C#? Very C++ like syntax but friendlier, like C++ meets VB. Makes a quicker development scenario for the things I do. Given that the program is basically always going to be waiting on the drive the raw speed of C++ would not be as beneficial. It could also be used by folks on Mac/Linux who are using Mono (but more work to test everything.)

I was also thinking that I should save my commonly used configurations and load the correct config after starting the SCP software. This will at least help prevent me from doing silly things for now Smile
Sure, I can look at C#.  I like that C++ can handle memory as stings instead of having to deal with pointers.  I don’t really know the difference between C# and C++.  Remember, I am an assembly programmer, so C in general is a foreign language to me that I sort of stumble through.  My only experience with C is C++ with the Arduino IDE.

There is not much waiting on the drive, and most everything is done inside of the SuperCard Pro board itself.  This is why you can copy and image disks with other computers that have just a serial port.  The USB port is not a requirement.
I'll shoot you an email about this.

Users browsing this thread: 1 Guest(s)