Using SuperCard Pro

Moderators: DrCoolZic, Moderator Team

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 2:12 pm

I have just received my SuperCard Pro today !!! it did not make it for Christmas :roll:
I will create a page on my Web on the subject but let me give you my first impressions
The board looks very professional I will put some pictures ...

So I have installed a 3.5" drive in an old computer to get the power (until I do a specific cable) and tried to connect to the board.
First problem: FDrive uses keyed connector but ... unfortunately the SCP board uses a connector where the keyed pin has not been removed :(
I have found many cables but none of them worked! Finally I have found in the attic a very old cable not keyed :)
Not a big deal but very frustrating when you are in hurry to test your new toy!

Installed the SW (be sure to be execute in Superuser mode) ...
and tried to run SCP first it tells you there is a newer version do you want to install - Yes ... installed

Scanning bus for floppy drive ... but got error: Run time error 713 ... you need the following file to be installed on your machine MSSTDFM.DLL ? and program stop :(
Googled internet and found that this problem comes from VB6 application that do not install the required DLL so followed instruction here http://superuser.com/questions/519841/g ... pplication

Now the program works fine :)
EDIT
I removed part of my original post because I tested the board with an old 0.7 SW which explain why I had problems.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 3:20 pm

OK more good news

I have updated to V0.92 (I was at 0.7! downloaded few days earlier) and rebooted my Win 8 and now everything seems much better !!! Note that it still ask me to update each time I start (dtect new version?)
DM master file now has correctly all the tracks and the file size went down from 30MB to 10MB
So looks cool.
If you are using a shortcut to start the program make sure you check the run as administrator.

Someone ask me question about the cable.
You have to find a model like the one presented on the SCP users manual that has connectors for both 3.5 and 5.25 drives. see here http://www.nullmodem.com/Floppy.htm
The more "modern" cables that were still delivered few years ago with Mobo only have one connector for one 3.5 drive and all these cables have a keyed connector
https://support.gateway.com/s/MOTHERBD/ ... vr21.shtml

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 3:57 pm

First simple question for Jim I have not been able to find were you can specify how many revolutions you want to record?

Problems sampling Turrican.

If I record using the "blind mode" the disk is sampled completely
if I record not using blind mode the sampling always stop (tried 3 times) at track 69 head 0. The program needs to be killed using the process manager :(
scp-stuck-at-69.JPG

What is the difference in the SCP file of using the non-blind mode?

Result of sample:
As mentioned here viewtopic.php?f=102&t=25854#p242772 Turrican uses what I call No-output Flux Area (NFA). In this example it means no flux coming out from the drive for 4299µs

It seems that currently SCP is limited to around 1055 µs. see below
So the track is not recorded correctly (you can also see that there about 4 ms missing for the overall track 196600µs)
scp-turrican-flux-limitation.JPG


Also mentioned in the reference above the SCP file has no provision to indicate where the index happen inside a huge flux transition. Therefore the transition that span over the index (starting at the very end and continuing in the next revolution) is incorrectly reported at the end of the track
scp-wrong-nfa-position.JPG


Here is the correct position of the NFA the span over the index with most part being at the beginning of the track
correct-nfa-with-kf.JPG
You do not have the required permissions to view the files attached to this post.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 4:43 pm


User avatar
Brume
Red eyes
Red eyes
Posts: 4053
Joined: Mon Apr 22, 2002 10:16 am
Location: France
Contact:

Re: Using SuperCard Pro

Postby Brume » Mon Dec 30, 2013 4:47 pm

Have you tried to write a disk? Is it available ?

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 4:56 pm

Brume wrote:Have you tried to write a disk? Is it available ?

Not yet, but yes it seems to be possible

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 5:59 pm

Preliminary page on my web http://info-coach.fr/atari/hardware/dev ... ercard.php
will be updated ...

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 548
Joined: Mon Nov 04, 2013 5:23 pm

Re: Using SuperCard Pro

Postby JimDrew » Mon Dec 30, 2013 6:39 pm

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.
Last edited by JimDrew on Mon Dec 30, 2013 8:05 pm, edited 3 times in total.
I am the flux ninja

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 548
Joined: Mon Nov 04, 2013 5:23 pm

Re: Using SuperCard Pro

Postby JimDrew » Mon Dec 30, 2013 6:42 pm

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.
I am the flux ninja

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 9:48 pm

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.

What I have sampled is not related to a drive limitation. This is the same drive I have used with KF and I have read NFA areas with flux transitions on some games larger than 6 ms without problem :?

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 9:56 pm

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.

Sorry I did not look at the support forum I was in hurry to try the board!!!
I will now look at the forum for info :oops:

  • Where can I get 0.93 I just downloaded few seconds ago from http://www.cbmstuff.com/downloads.htm and it is 0.92?
  • Just to make sure I have removed existing version and re-installed but still v0.92 ????
  • The current limitation on bit cell size probably explain why you cant record 5,000,000 ns flux transitions as in Turrican. Hope you can fix this in future?
  • Eagerly waiting for the capability of recording multiple revolutions so fuzzy bits can be detected.
  • Good you have pin 5 removed will be more compatible with new cables.
Overall thanks excellent product :mrgreen:

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 10:07 pm

Haha I found the magic to get latest release:
You download the latest version 0.92 from the download page http://www.cbmstuff.com/downloads.htm but ... this is not the latest version yet so
you run SCP as an administrator, you answer yes when ask to update and boom you get 0.93 :)
PS. would be nice to have a place for 0.93 directly :roll:

I will try tomorrow (cant do tonite) this new version ;)

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Mon Dec 30, 2013 10:23 pm

FYI: not important at this stage - but in some case when in analyzer mode read image does not display anything (in my case trying to read fire and forget.scp file)
But I like your analyzer a lot of very nice idea :) :) :)
I specially like your data control area. I have in mind something similar in my program: I want to have search capabilities equivalent to some sort of logic analyzer ... so you define some trigger condition and the program search for you

Excellent :D

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 548
Joined: Mon Nov 04, 2013 5:23 pm

Re: Using SuperCard Pro

Postby JimDrew » Mon Dec 30, 2013 11:05 pm

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.
I am the flux ninja

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Tue Dec 31, 2013 10:49 am

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.

Yes this is definitively a nice feature and yes keep it like it is (asking the user). You may also consider to always put the latest version in the download area.
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.

As I already mentioned the protection used in Turrican and some other games is very special because normally such huge time without any transition is not possible. On an unformatted track you still have transitions happening (can be up to several 100 µs) because of the noise in the head and the ACG of the read chain. This protection “fools” the read chain and result in no transitions for several ms (actually could be dome much larger than that if wanted).
I believe I have fixed the checksum issue now that was causing some image files (multiple revolutions) to not show any data.

Excellent. Now waiting for an entry in the GUI toset the number of revolutions.
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 have three modules In my software to decode the data. The first module is a DPLL based on patent 4,780,844 that takes the fluxes and lock an internal clock and detect how many inspection windows to get to the next flux. Look here http://info-coach.fr/atari/hardware/FD-Hard.php#FDC_PLL for more detail. This module is not related to the WD1772. The next module is a Data Shift Register (DSR) and Sync detector. This module takes input from the DPLL and convert the result in a stream of MFM bits. This module is again not directly related to the WD1772. I say not directly because the next module needs to provide the sync characters and when to use them. Therefore the DSR module is tailored to decode DOS/MFM bit stream. The last module is a kind of WD1772 emulator that interprets the stream of bits based on the emulated command. For example when emulating a read track command the sync detector is turned on at all time, where when emulating a read sector command the sync detector is turned off as soon as the data address mark is detected. So the same stream of MFM bits gets decoded differently depending on the emulated command.
For the sync it is true that the first A1 sync often requires a “resync” operation. In some cases it make sense in some other cases it don’t. As you mentioned for “user written” floppy disk it is a two pass operation: the disk is first formatted and in that case all bits should be perfectly positioned. But when a sector is written by the WD1772 the sector ID is detected and when the correct ID is found the write gate signal is turned on at a specific position. Of course this position cannot be guaranteed to be perfect and this is where you find so called sector write splice (one at the beginning and one at the end). So for a user written sector you will most probably always have resync but for “disc copier” written there should not be any write splice as the entire track is written “continuously” (only a write track splice exist).
All this explain why data in GAPS can be shifted by some bits. In MFM/Atari/DOS format the sync are always preceded by a sequence of twelve 0x00 bytes. Although not mandatory and not detected by the WD1772 these bytes are here to help the DPLL in locking correctly to the input stream (00 in MFM results in maximum number of flux transitions). Usually they show either as 0x00 or 0xFF when shifted by one bit….
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.

There are a lot of ways to get fuzzy bits in MFM. The WD1772 do not care at all about fuzzy bits. The DSR (also describe in the patent mentioned above) just look for presence of transition inside an inspection window. Normally in DD MFM these transitions should be at 4, 6, and 8 µs resulting in 2, 3, and 4 bit shifted in the DSR but in fact anything can happen inside reasonable limits. My definition of fuzzy bits is based on description given in patent 4,462,078. You have fuzzy bits/bytes if the same bit/byte read in different revolutions are different. This can be achieved with what I call border bits (see http://info-coach.fr/atari/hardware/FD- ... fuzzy_bits), or transitions far above/below normal values, by having unformatted sector, No Flux areas, weak flux transitions, etc…
So yes you can sometimes predict fuzzy bits with only one revolution, and yes you can back up a track with fuzzy bits with one revolution, but this is not exactly what I describe.
Generally speaking there is no way to read the MFM information from the WD1772 and therefore there is no program to do that. With the WD1772 you can only read the decoded data but not the clock and not the MFM. Turrican uses a nice trick that allow to read the clock bits in order to check that the received flux does not contain neither data bits nor any clock bits. For that matter a sector within sector is created with a sync byte shifted by a half cell. So when you read the first sector you read the normal data bits, and when you read the second sector you read the clock bits.
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.

This is definitively something to consider

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Tue Dec 31, 2013 11:03 am

Brume wrote:Have you tried to write a disk? Is it available ?

Just tried with Dungeon Master and works like a charm ;)

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Tue Dec 31, 2013 11:14 am

I confirm that the problem of program hanging when dumping in non blind mode has been fixed with 0.93

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Using SuperCard Pro

Postby DrCoolZic » Tue Dec 31, 2013 1:32 pm

Seems like SCP 0.92 records 3 revolutions in non blind mode (but can't display the data in analyzer, and sometimes freeze) and that SCP 0.93 records 2 revolutions in non blind mode and fixes the problems mentioned.

So using SCP 0.92 I have been able to record 3 revolutions of Fire and Forget. After fixing a bug in my program (first test of multi-revolutions) I can now analyze and display the three revolutions:
fire-forget-scp-79-3-rev.JPG
You do not have the required permissions to view the files attached to this post.

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 548
Joined: Mon Nov 04, 2013 5:23 pm

Re: Using SuperCard Pro

Postby JimDrew » Tue Dec 31, 2013 4:35 pm

Yes, my 'fix' (for now) for the bug in v0.92 hanging was to reduce the number of revolutions to 2. There is an issue with VB when you exceed the signed 32 bit value. I deal with unsigned 32 bit, so I had to switch floating point (doubles) to fix this problem. There is also a problem calculation the checksum of the entire file if the checksum value exceeds 0x7FFFFFFF. I have lots of little things to fix and add, but its getting there. :)

Wow... you guys really were in a box with the WD1772 controller! I remember working with the WD1771 in the CBM 1571 and 1581 drives, and figured that was a fluke... I guess not!
I am the flux ninja


Social Media

     

Return to “SuperCard Pro Disk Copier”

Who is online

Users browsing this forum: No registered users and 1 guest