CBMSTUFF FORUM
SCP Hardware Questions - Printable Version

+- CBMSTUFF FORUM (https://www.cbmstuff.com/forum)
+-- Forum: CBMSTUFF PRODUCTS (https://www.cbmstuff.com/forum/forumdisplay.php?fid=1)
+--- Forum: SuperCard Pro (https://www.cbmstuff.com/forum/forumdisplay.php?fid=3)
+---- Forum: Hardware (https://www.cbmstuff.com/forum/forumdisplay.php?fid=42)
+---- Thread: SCP Hardware Questions (/showthread.php?tid=607)

Pages: 1 2


SCP Hardware Questions - merlinkv - 02-24-2019

Hello

What's the utility of the "Power Jumper"?

   

Also, the mSD card slot will be useful in the future as storage unit for dumps and write <-> read operations?

Best Regards


RE: SCP Hardware Questions - admin - 02-24-2019

As stated in the manual, the power jumper is used for powering the SCP hardware from the USB port. When using the SCP without a USB port you disable the power jumper and use power through the 3.5" disk drive power port.


RE: SCP Hardware Questions - merlinkv - 02-25-2019

The only reference I have found at the manual for J1 is to be opened when I want to upgrade the firmware ... but in the picture is labeled as "Power Jumper" .... sorry, but I'm a bit confused.

I'm using self powered drives ... J1 must be opened or closed?

Best Regards


RE: SCP Hardware Questions - admin - 02-25-2019

If J1 is closed (the jumper in place), then the USB port powers the SCP board. If you do not use a USB port with the SuperCard Pro (like as a stand alone copy station or something like that), then you must power the SuperCard Pro through the 3.5" disk drive power port (+5v/GND). If you power the SuperCard Pro board this way, you MUST remove J1.

The firmware update requires connecting the SuperCard Pro to your PC's USB port. As stated on page 15 of the manual:

To setup the SuperCard Pro board for a firmware update:
• Attach the SuperCard Pro to a PC system's USB port.
• Remove jumper J1.
• Insert the flash jumper so that GND and Rx/Tx on port RS232-1 is
jumpered (see figure 11 for details).
• Re-insert jumper J1

So, you would remove jumper J1 (which powers off the SuperCard Pro board). Attach the firmware update jumper (provided with your SuperCard Pro when you purchased it). Then place J1 back in place.

You don't need to update the SuperCard Pro firmware. All boards are shipped with the latest firmware. There has not been an update to the firmware in several years, and no update is planned in the immediate future.


RE: SCP Hardware Questions - Duboun - 09-15-2020

Hi,
I'll just use this thread, because I don't want to start a new one...

So, why is the serial port so slow?
I wanted to try reading the flux data with microcontroller and store them on SD card (since the built-in one is not used),
but because the SCP sends only 1byte every 50ms, it takes around 55mins to transfer 64kB over the serial port.
And that was just track0 on side0, it would take probably few days to transfer entire 1.44MB floppy.
Or am I doing something wrong?


RE: SCP Hardware Questions - admin - 09-15-2020

The serial port is whatever speed you set it to. At 300 baud, that is about 33.3ms per byte. I suppose depending on the amount of overhead you had it could be 50ms per byte. The serial port supports up to 1.25 mbps. What baud rate are you trying to use?

I am doing some final testing right now on the SD card support, because I will be implementing the ability to load/save using the SD card and also enable the option to make SuperCard Pro a disk drive emulator.


RE: SCP Hardware Questions - Duboun - 09-15-2020

(09-15-2020, 01:35 PM)admin Wrote: The serial port is whatever speed you set it to.  At 300 baud, that is about 33.3ms per byte.  I suppose depending on the amount of overhead you had it could be 50ms per byte.  The serial port supports up to 1.25 mbps.  What baud rate are you trying to use?

I am doing some final testing right now on the SD card support, because I will be implementing the ability to load/save using the SD card and also have enable the option to make SuperCard Pro a disk drive emulator.

That would be really cool if it could run as drive emulator...

I was using default baudrate (250000), but I also tried others (19200, 500000) and it was the same.
The device communicate on the specified baudrates, but the 50ms delay between every byte received does not change.

Captured data
Captured data closeup


RE: SCP Hardware Questions - admin - 09-15-2020

I know others are using the serial port, but not the same one you are using.  I will take a look at it.  The commands require that you fetch the data within 4 character periods (4 bytes) or you will loose data and generate an error, which does have a timeout period.


RE: SCP Hardware Questions - admin - 09-15-2020

Well, I see a potential problem.  Did you cut the jumper at JB0, and add a jumper at JB1?

By default Rx and Tx are connected together and the routine that sends a byte falls into code that waits on the byte to be received after transmitted (echo'd), and there is a 50ms time out period that can go by if the byte is not received.  With Rx and Tx tied together the code just falls through and exits because the byte is instantly available.  So, if you are trying to use separate Rx and Tx lines then that would result in exactly what you are seeing.  It looks like I need to make another flag bit for handling whether the Rx and Tx are tied together or split.  I guess everyone so far that has been using the serial ports in their default half-duplex setup.

if you did not split the lines, then that would mean that you don't have the proper pull-up on the serial port line.


RE: SCP Hardware Questions - Duboun - 09-16-2020

(09-15-2020, 10:55 PM)admin Wrote: Well, I see a potential problem.  Did you cut the jumper at JB0, and add a jumper at JB1?

By default Rx and Tx are connected together and the routine that sends a byte falls into code that waits on the byte to be received after transmitted (echo'd), and there is a 50ms time out period that can go by if the byte is not received.  With Rx and Tx tied together the code just falls through and exists because the byte is instantly available.  So, if you are trying to use separate Rx and Tx lines then that would result in exactly what you are seeing.  It looks like I need to make another flag bit for handling whether the Rx and Tx are tied together or split.  I guess everyone so far that has been using the serial ports in their default half-duplex setup.

if you did not split the lines, then that would mean that you don't have the proper pull-up on the serial port line.

Yes, I have split Rx and Tx, because I just wanted to test few things (and I never used half duplex uart on stm32).

But it's working now.
I added echo on my serial port and now it takes just few seconds to transfer.
Looks like it does not need to echo the exact same dtata, I tried sending back zeros to see if I get any error, but it was the same.
Maybe I'll use half duplex...

Anyways, thanks for your help.