Help with Supercard Pro

[+Larry]

I did purchase one, and I love the Windows software.  But I'm having trouble getting the settings correct.  Can someone please help that has one and is successfully creating images?

 

I have the settings as 5-1/4" 48 TPI

40 tracks (0-39)

Source Device SuperCard Pro (D0)

Target Device SuperCard Pro (D0)

 

When using just a copy option, it sounds like the drive is trying to go past track 39 -- makes a thumping sound starting at track 20

 

I'm also concerned that both the Read and Write densities are set to "High."  Low is grayed out and I can't select it.  When I make a copy of a regular SD Dos disk and try to boot it, my 1050 acts like it is reading the first track OK, then goes into "Boot Error" and retries until I shut it off.

 

Any help will be greatly appreciated!

 

[cwilbar]

In the Archiver, set:

 

target device: flux image file

disk type: Atari 400/800

copy mode: Splice

# revolutions: 5  (sometimes with random noise tracks ? this will overrun the SCP's buffer and you'll need to drop it, in which case 4 usually works)

 

in drive options:

 

drive type: 48tpi  (if your drive is 360K, 96tpi if it is a 1.2M drive)  (go by the checkbox, I find the gray/black highlighting of the text confusing and unusual (IMHO))

density read: low

density write: low

index sensor reads: required (unless doing a flippy w/o an index hole, then set to ignore (and your drive may yet not work on a floppy anyway (you'll get a blank read))

index sensor writes: required

 

you can also click to increase end track to 41 if you want to image any potential duplication signatures that may be embedded there.

 

The resulting supercard pro image can be written back out using SCP software, a8rawconv, or converetd to .atx for emulators (or for writing back out with a8rawconv).

(some .atx don't like to be written back out, so keep your .scp files if you are archiving for writing back out)

 

It sounds like you may have a 360K drive that is being treated as a 1.2M drive and is double stepping the heads ????

 

 

 

[+Larry]

Thanks!  I'll give those a try. 

 

Yes, that double stepping is what I thought about, too. I also posted in the CBMstuff forum in case that double stepping is a bug. From the forum posts, I have a feeling that not many Atarians use these.  I think the potential ease of use is a real plus for the SCP vs Kryoflux. Thanks again.

[+Larry]

OK, I now understand the "grayed out" settings.  Yes, I think that is confusing, also. 

 

Now the drive is no longer thumping (head banging) during the reading, but still does it during writing.  I also took a look at a copy from SCP using the Archiver/Editor.  It is only writing every other track.  Every other track is blank, and on the sectors which are written, all are bad sectors. Only the first track is good. It certainly looks like double stepping.

[ijor]

11 hours ago, Larry said:

Source Device SuperCard Pro (D0)

Target Device SuperCard Pro (D0)

 

When using just a copy option, it sounds like the drive is trying to go past track 39 -- makes a thumping sound starting at track 20

 

I'm also concerned that both the Read and Write densities are set to "High."  Low is grayed out and I can't select it.  When I make a copy of a regular SD Dos disk and try to boot it, my 1050 acts like it is reading the first track OK, then goes into "Boot Error" and retries until I shut it off.

 

I understand you are trying to copy a disk directly and not dumping an image, and then write back the image, correct? I think this is a rare usage. Most people either create an image, or either write back one. So not sure how much help are you going to get with this procedure.

 

Anyway, the SCP software usually can't locate a correct write splice. You need to use a8rawconv to drive the write back procedure. And for the same reason a copy directly would fail most of the times.

 

So don't copy. Make an SCP image instead, then write it back using a8rawconv.

 

[cwilbar]

Check all the settings carefully, as you can adjust both read and write settings for some parameters.

 

I presume you are writing to the same drive as you are reading from ?

 

I haven't dug into doing C64 disks yet, but I believe I was getting double stepping even though my drive is 48tpi when I had the pull down set to C64 disks.  Though I've upgraded a couple versions since, and I have not gone back to revisit imaging C64 stuff.

 

For those archiving for the Atari 8 bitters.... I think the SuperCard Pro is well represented.  The primary choices have been SCP and Kryoflux.

 

Keep at it, sounds like your getting close.

 

 

[+Larry]

7 hours ago, ijor said:

 

I understand you are trying to copy a disk directly and not dumping an image, and then write back the image, correct? I think this is a rare usage. Most people either create an image, or either write back one. So not sure how much help are you going to get with this procedure.

 

Anyway, the SCP software usually can't locate a correct write splice. You need to use a8rawconv to drive the write back procedure. And for the same reason a copy directly would fail most of the times.

 

So don't copy. Make an SCP image instead, then write it back using a8rawconv.

 

Hi Ijor-

Yes, that likely is true, but the easiest way to see that SCP is actually working correctly is to copy a disk then boot that disk with a regular Atari drive.  I plan to try a8rawconv as a work-around, but the SCP is supposed to copy correctly -- as-is. Hopefully, the software can be updated to copy correctly. In the meantime, I have downloaded a8rawconv 0.94.  I'll read through the a8rawconv thread here and see if I can get this to work. I presume that a8rawconv will find the SCP 48TPI floppy drive through the USB? (Or does it need to be inside my PC to write using Phaeron's software?)

 

Can you please give me an example of the a8rawconv syntax that would be used to write out a saved SCP image? 

 

I think I may know what the issue is -- it is the 288 vs 300 rpm's.  If the SCP software does not compensate (like an XF551), it would fail. Here is a screenshot of a disk copied with SCP then read with a 1050 with the Archiver/Editor.

 

[+Larry]

6 hours ago, cwilbar said:

Check all the settings carefully, as you can adjust both read and write settings for some parameters.

 

I presume you are writing to the same drive as you are reading from ?

 

I haven't dug into doing C64 disks yet, but I believe I was getting double stepping even though my drive is 48tpi when I had the pull down set to C64 disks.  Though I've upgraded a couple versions since, and I have not gone back to revisit imaging C64 stuff.

 

For those archiving for the Atari 8 bitters.... I think the SuperCard Pro is well represented.  The primary choices have been SCP and Kryoflux.

 

Keep at it, sounds like your getting close.

 

 

 

Yes, same drive -- it is a Chinon from an XF551.  Works great in the XF551.  Have you written out some of your .scp images using only the included SCP software?  Did it work, or did you have to use a8rawconv?

 

I made an image of a dos 2.5 disk and it is 6.68 MB.  Later I'll try to write it out.

[ijor]

8 hours ago, Larry said:

I presume that a8rawconv will find the SCP 48TPI floppy drive through the USB? (Or does it need to be inside my PC to write using Phaeron's software?)

It works with the SCP hardware through the USB interface, not with internal old school floppy drives.

 

8 hours ago, Larry said:

I think I may know what the issue is -- it is the 288 vs 300 rpm's.  If the SCP software does not compensate (like an XF551), it would fail. Here is a screenshot of a disk copied with SCP then read with a 1050 with the Archiver/Editor.

 

There is no need to compensate. The software only needs to detect correctly the type of drive you are using (48tpi or 96tpi), and also its RPM (300 or 360 RPM). It seems that your problem is again, the double step issue.

 

[cwilbar]

speed is not a concern here.  You could ( in theory ) sample the disk at 360 RPM... and as long as you write it out with a drive a 360RPM, then the flux transitions will be in the same relative place on the disk as the source disk.

 

And I have written out a number of disks now to load on real hardware.  I've used a8rawconv and the archiver software to write out the disks for the Atari.  No issues.

 

As I can write out scp or atx with a8rawconv and I'm a command line junkie, I've been using that more lately.

 

If you're still having an issue writing a .scp file out, I'd suggest:

 

1. Take your known good disk, rip a .scp image

2. Install Altirra emulator

3. use a8rawconv to make an .atx (a8rawconv mydisk.scp mydisk.atx)

4. Test the .atx with Altirra.  If you can boot it, you know the rip is good (at least good enouogh to boot)

 

If your test in Altirra goes well, do the following:

1. write out 2 disks from your .scp image; one with the bundled archiver software, one with a8rawconv (a8rawconv mydisk.scp scp0:48tpi)

2. attempt to boot each on a real Atari

 

If your a8rawconv disk works and the archiver copy doesn't, you're having a write issue from Archiver

If neither work, maybe you have a drive problem while writing.

 

Maybe this will help you isolate exactly where the failure is.

 

 

 

[ijor]

5 hours ago, cwilbar said:

1. write out 2 disks from your .scp image; one with the bundled archiver software, one with a8rawconv ...

 

Once more again, the SCP software can't write back most 8-bit images. This is because the data on most disks isn't aligned to the index hole and the SCP software can't currently locate a proper write splice point in the middle of the track. That's why using a8rawconv is recommended because it usually is much better at locating a write splice point.

 

Of course, if the data is aligned to the index hole, then the SCP software should be able to write back correctly. Many original disks are aligned to the index hole, MULE is a good example. Disks formatted with a XF551 are aligned as well.

 

Jim (SCP designer) said recently that he will improve the software for this purpose. So this might change in the future.

[cwilbar]

Thanks @ijor, I missed that.  I've only been dealing with archiving and writing out copies of my originals, so I've probably only run into index aligned disks so far (a least for ones I've written).

 

I do usually use a8rawconv myself these days to write disks out as I generally find command line faster than click here, file open dialog there, etc, etc.

 

 

[+Larry]

@JimDrew said he will look into the double-stepping on writing.  If this is also a problem on C64 disks, might be a good time to mention it. (Or it may get fixed by default).

[+Larry]

When using the following command line to write out my SCP test image, I keep getting an error "unable to open input file dosdisk.scp".

 

a8rawconv dosdisk.scp scp0:48tpi

 

Windows originally made my .scp file a text file.  I changed the file association to SCP control software.  But the file could not be opened under either situation.  Both files are on my D drive in the root directory. a8rawconv is "allowed" by my antivirus.

 

Any thoughts?

[phaeron]

5 hours ago, Larry said:

When using the following command line to write out my SCP test image, I keep getting an error "unable to open input file dosdisk.scp".

 

a8rawconv dosdisk.scp scp0:48tpi

 

Windows originally made my .scp file a text file.  I changed the file association to SCP control software.  But the file could not be opened under either situation.  Both files are on my D drive in the root directory. a8rawconv is "allowed" by my antivirus.

 

Any thoughts?

This error means that a8rawconv couldn't find the file at all, never mind the contents of it. Double-check the file with the DIR command -- make sure it doesn't have a double extension, like dosdisk.scp.txt.

 

[+Larry]

1 hour ago, phaeron said:

This error means that a8rawconv couldn't find the file at all, never mind the contents of it. Double-check the file with the DIR command -- make sure it doesn't have a double extension, like dosdisk.scp.txt.

 

 

Thanks, it was dosdisk.scp.scp with Dir

 

Next issue is the com port or VCP.  The device manager says that it is working properly.  I checked the box to load it under the Advanced tab of Properties.  Says it is port 0005 hub 0001  Manufacturer FTDI 

 

a8rawconv dosdisk.scp scp0:48tpi:com5

 

produces "unable to open serial port 5"  Any thoughts about that?  I've tried every com port from 1 to 13.

[phaeron]

18 minutes ago, Larry said:

 

Thanks, it was dosdisk.scp.scp with Dir

 

Next issue is the com port or VCP.  The device manager says that it is working properly.  I checked the box to load it under the Advanced tab of Properties.  Says it is port 0005 hub 0001  Manufacturer FTDI 

 

a8rawconv dosdisk.scp scp0:48tpi:com5

 

produces "unable to open serial port 5"  Any thoughts about that?  I've tried every com port from 1 to 13.

 

You shouldn't actually have needed to reconfigure anything with the driver. I just tested on a new computer and it pulled the FTDI VCP driver from Windows Update, without even the SuperCard Pro software installed. It shows up in Device Manager under Ports (COM & LPT) as USB Serial Port (COMn). The port numbers you're reading off are most likely from the USB connection and not the COM port number. If this isn't working, then you can try to reinstall the driver from C:\Program Files (x86)\SCP\USB if you have the SCP software installed.

 

Once you've got the serial port showing up properly in Device Manager try running a8rawconv without COM port and just let it auto-detect the port. Make sure you are running the latest 0.94 version, as it has some fixes for auto-detecting COM10 and above.

 

[cwilbar]

I've also had the scp not 'come up' on a com port on my Alienware laptop once in a while.  When it does happen (not often), I pull the USP cable, wait a few seconds and plug it back in and it comes up fine.

 

Not saying that is what is going on for you, or if my experience is unique or not.... just relaying something I've observed that you may or may not run into.

 

On a few revisions of software back with the SCP software, reading Atari diskettes worked fine, but when set to C64 I think it might have been double stepping.

 

I'm not currently working on archiving my C64 stuff, so I did not concern myself with it for now.  (I'm still trying to organize all my Atari images into good, think ok (works but might be a multidisk game noto fully tested, or it may read data during a game and not fully tsted), suspect bad, and bad..... and it really sucks when you have duplicate titles, that both seem to work, but they don't compare 100% ?

 

 

 

[+Larry]

in post #88, @JimDrew says:

"In Window's Device Manager, go to "Universal Serial Bus Controllers" and locate the entry called "USB Serial Converter". Right-click that entry and select Properties. Under the advanced tab select "Load VCP". That instructs Windows to load a virtual com port (a COMx port). If that is not selected, you will not have a COM port setup for the SuperCard PRO board! Click OK and exit the Device Manager. You will need to remove and re-insert the USB connection to the SuperCard PRO board in order for Windows to force the loading of the VCP."

 

At the end of the USB listings in the Device Manager is the USB Serial Converter.  Everything seems to be OK. VCP is "checked."

 

It is the FTDI driver 2.12.28.0 dated 8-16-2017

There are no newer drivers that I can find.  I uninstalled the driver and re-installed it.  Is this what a8rawconv (0.94) is looking for?  It can't find it. Win10.

 

Maybe I'm missing something?

 

-Larry

 

[phaeron]

5 hours ago, Larry said:

in post #88, @JimDrew says:

"In Window's Device Manager, go to "Universal Serial Bus Controllers" and locate the entry called "USB Serial Converter". Right-click that entry and select Properties. Under the advanced tab select "Load VCP". That instructs Windows to load a virtual com port (a COMx port). If that is not selected, you will not have a COM port setup for the SuperCard PRO board! Click OK and exit the Device Manager. You will need to remove and re-insert the USB connection to the SuperCard PRO board in order for Windows to force the loading of the VCP."

 

At the end of the USB listings in the Device Manager is the USB Serial Converter.  Everything seems to be OK. VCP is "checked."

 

It is the FTDI driver 2.12.28.0 dated 8-16-2017

There are no newer drivers that I can find.  I uninstalled the driver and re-installed it.  Is this what a8rawconv (0.94) is looking for?  It can't find it. Win10.

 

No, as I said earlier, a8rawconv needs the COM port, not this driver. It should look like this:

 

 

The driver version number and date are the same as the USB Serial Converter driver and do match what you have on your driver. You need to figure out why the USB Serial Port is not showing up, as there's no point in trying a8rawconv until it does.

 

[+Larry]

Success!

 

In order to get a valid com port, I had to plug in my SIO2PC-USB (with the FTDI chip).  It was com3.  When I invoked a8rawconv without a :comx, it failed.  It still could not find the com port.  But looking at the device manager, I found com4 had now been opened.  So I added :com4, and the drive activated and the disk was written out.  The disk was just a regular dos disk, but it booted correctly with all sectors are valid.

 

I disconnected the SIO2PC-USB interface, and com3 disappeared from the Device manager, but com4 remained. Unplugging the SCP interface, the com4 went away.  But when I reconnect SCP, com4 pops up correctly.  So why didn't this work before?  My theory is because this is a desktop, it has a valid com1 sitting there unused. (?) But attaching a USB device that called for a VCP, Windows attached one. So my issues should be over.

 

Thanks for the help. 

[+Larry]

So with my new found success, I decided to move to the deep end of the pool -- I took out my original Bruce Lee from Datasoft.  I readied everything and started to make an image. Immediate failure -- "no index pulse found." 

 

What is the success rate with SCP?  Given that I am still at the very beginning of the learning curve, I'm sure things will get better. (I hope!)  But I've got to admit, that Super Archiver looks mighty good right now!

[cwilbar]

Is your Bruce Lee a combo C64/Atari disk with C64 on the front, and Atari on the back ?????

 

If you are trying to read the backside then you need to not require index pulse on read.  And your floppy drive may still betray you (I tested all of mine, and only 3 or 4 would read the backside.... the remaining ones would act the part.... but I'd end up with an 'blank' ATX file).

 

If you are trying to read the front.... check your disk, make sure that somehow the index hole has not gotten blocked.  The Atari doesn't need it but the SCP uses it (unless your drive will permit you to ignore it).

 

[+Larry]

Yes, my Bruce Lee is the combo disk with the C64 version on the front. So yes, there would be no index hole with the disk flipped.  I would have to add one.  I never thought of that.  I have several combo disks.  Looks like I will not be imaging back sides since I would prefer not to modify my originals.  Interestingly, I haven't been able to make a successful backup yet with Happy, Archiver, or Super Archiver. The original boots fine, so no problem with it.

[cwilbar]

You do not need to punch an index hole.

You can set index for reads to disabled and try imaging it.

It then depends on your floppy drive and its jumper settings (some drives can be set for index/rdy which may or may not affect if they work reading w/o an index hole (I have not tried)).

 

I can confirm that panasonic ju-455 will read w/o an index pulse.  If you search for posts by me, I listed a few others that do this to (TEAC FD-54B and a Toshiba drive).  But my Toshiba drive failed on me, and the TEAC has a speed issue when writing.  That leaves me running the panasonic which has worked wonderfully.