USB compatibility
#1
The SuperCard Pro USB interface uses a FTDI FIFO chip. There are drivers available for Windows, Mac OSX, and Linux.

If you are interested in making an application for SuperCard Pro that works with Mac OS or Linux systems, we would be happy to work with you to make this possible, so please contact us!
Reply
#2
(11-01-2013, 08:18 PM)admin Wrote: The SuperCard Pro USB interface uses a FTDI FIFO chip. There are drivers available for Windows, Mac OSX, and Linux.

If you are interested in making an application for SuperCard Pro that works with Mac OS or Linux systems, we would be happy to work with you to make this possible, so please contact us!

I've been looking at direct card support in SAMdisk, initially just for reading, but ultimately for writing of sector-based images too. I have basic reading working through the USB port under Windows, and it shouldn't be too much trouble to have the Mac and Linux versions do the equivalent.

Do you have any recommendations on identifying an SCP board over other FTDI devices? I'm guessing you probably share a device ID. Is the only option to send it a short query (perhaps firmware version) and see if you get the expected response back? Or is there a better approach?

Also, I'm currently reading 2 revolutions starting from an index. I'm finding that the first sector on the first revolution is offset compared to the same sector in the second revolution. Should the start of each revolution be from the same point relative to the start of the index signal? Reading multi-revolution .scp images created by your utility is fine, so I guess I'm doing something wrong somewhere.
Reply
#3
You can identify the SCP board using the FTDI command for querying the ID. I use the .dll provided by FTDI to control SuperCard Pro. You could also use the COM port, but you don't have all of the neat features offered by the .dll then. I will post some info about this.

When you do a multi-rev read, the index to index time and read length (number of bitcells read) is available by calling Command 0xA1 (DoCMD_GETFLUXINFO). If you add the length of the number of bitcells x 2 (because bitcells are a word wide) to the start of the buffer that holds the 2 revolutions of data, you will be at the beginning of the 2nd revolution.

You might want to take a look at Keirf's code. He has already added SCP hardware support into his disk utility. So, the C source is done and tested. You can find info here:

https://www.cbmstuff.com/forum/showthread.php?tid=115
Reply
#4
(07-29-2014, 11:03 PM)admin Wrote: You can identify the SCP board using the FTDI command for querying the ID. I use the .dll provided by FTDI to control SuperCard Pro. You could also use the COM port, but you don't have all of the neat features offered by the .dll then. I will post some info about this.
I'm currently using the COM port under Windows, and figured that would also be easier on Linux and Mac as I think the board should be picked up by the system USB CDC driver on both. Locating the board might be easier with the FTDI library, but it'd be nice to avoid an extra library dependency.

Quote:You might want to take a look at Keirf's code. He has already added SCP hardware support into his disk utility.
I've just done a quick Windows conversion of it, and I'm seeing the same offset between tracks as I am when talking directly to the device. Hmmm. I'm now suspecting my serial port parameters might be wrong -- perhaps I'm getting XON/XOFF characters in the bulk data or something nasty!
Reply
#5
Switching to the FTDI library has cured my problem. I still suspect something about the port parameters at fault, but they seemed fine to me, and a virtual port shouldn't really be as fussy as real serial hardware. Here's what the problem looked like in the analyzer:

https://dl.dropboxusercontent.com/u/2553...offset.png

Note the zero bytes at the start of the data returned, and the red line at the start of the visualisation. Once real data did start flowing, it was from the start of the buffer rather than the current data offset. That caused the offset on the first revolution that prevented me matching sector positions on subsequent revolutions.

I'm still not so keen on the FTDI driver requirement as it's a bit of a barrier for users. Windows owners of the SCP board will already have them installed for the official software, but getting Linux and Mac users to install it may be a bit of a support headache. I'll double check that recent Linux and Mac OSes install the device as a virtual serial port without any trouble, and then maybe go back to track down the cause of it not working under Windows.
Reply
#6
I think Keirf's disk utility uses the serial port under Linux, and not the FTDI library at all. I will try using the COM port under Windows in place of the library, but I don't think that is an issue. You could try doing a second read of the buffer and see if you see the same result.

I wonder if this is a flow control issue? Have you checked the COM port settings to make sure hardware flow control is enabled? You should be able to read 512K of data from the SCP RAM, starting at offset 0x0 and see both revolutions without a break between the tracks, and then 0's after the 2nd revolution's data.
Reply
#7
I changed my VB app to read data from the SCP board using the COM port and it works the same as the library. So, I am not sure what is happening. Did you try flushing your FIFO prior to reading? You should be able to read a track, read the track info, and then read the track data (over and over) without any nulls.
Reply
#8
After finishing the FTDI side I went back to re-implement the USB COM port, and it's all working fine now! I've even tried both native Win32 API and CRT, and both are working correctly. So I've no idea what the problem was with the old code.

Opening the port through the Win32 API did start in 7-bit mode, so I had to change that. Opening in binary mode for the CRT seemed to do all that's needed.

I've got more work to do on the reading side before I attempt writing. I might be back at that point... Smile
Reply
#9
Good to hear! Writing is the same as reading, except you set a length (number of bitcells). Don't get confused between number of bitcells and length of data. Each bitcell is a word wide!
Reply
#10
I got writing working a few days ago for general MFM and FM formats, but haven't added pre-compensation yet. The documentation wasn't completely clear on how the bulk data for writes should be supplied, though I figured (correctly) it'd probably be the reverse of reading and require a RAM upload in advance.

I've a few extra questions too:

1) If the index is already active when an index-synchronised read/write is started, does the firmware wait for the start of the next index or start immediately?

2) Does the density setting control double-stepping tracks, or something else?

3) What difference does the 300 vs 360rpm make for reads and writes? Is it only for drives that support programmatic control of the motor speed?

4) Do you have any recommendations on when (if ever) the device needs resetting? Does closing and re-opening the device give a fresh session, or is it still possible there may be buffered data from a previous session?

Cheers Smile
Reply




Users browsing this thread: 5 Guest(s)