SuperCard Pro

[Jeff_HxC2001]

Well, apparently I uploaded the corrected file spec to the wrong folder on our website. DrCoolZic pointed that out this morning and so I fixed it.

DrCoolZic send me some SCP to tests this morning. Thanks to this, i managed to finish the loader & writer

Here is these SCP files running on the real hardware :

SAM_1741.jpg

SAM_1737.jpg

[JimDrew]

Maybe could we start to work with the Union Demo as an example, instead of games?
This demo has his own format: it can't be copied with regular program, so it includes his own copy-program. And of course, it can be freely spread.
See this thread for more copy-protected demos:
http://www.atari-forum.com/viewtopic.php?f=1&t=25586

Who holds the copyright to this demo? The information linked to for the Union Demo goes to a POV demo, not the Union Demo. I would need to see a disclaimer for the copyright in order to make this available on my website.

[JimDrew]

Nice, Jeff! Congrats!

Now, if Hatari or Steem supported .scp image files then you could also use the SCP board to read/write real ST disks too.... even boot real game disks.

[Jeff_HxC2001]

Did you test the .scp created disk? What drive was used to create the original image? I have never seen a drive speed vary so much before!

The file format looks perfect to me! Nice job.

The scp was tested, but not with a real disk. And no floppy disk drive was used to generate it : This is a conversion from a STX file.
Did you really found that the drive speed change so much ? Under SCP i see track lenght between 199.971 ms and 201.646ms. This is < to 1% of variation.

[JimDrew]

Real floppy drives typically vary +/-10us, and that is a lot to me. I have several 3.5" drives that I use that vary only 2-3us on every read. I deal with things on a 25ns interval, so perhaps I am picky.

[Jeff_HxC2001]

Real floppy drives typically vary +/-10us, and that is a lot to me. I have several 3.5" drives that I use that vary only 2-3us on every read. I deal with things on a 25ns interval, so perhaps I am picky.

This may depend of the drive and probably on the floppy disk inserted too. Generally manufacturer specify something around 1.5%/3%.
http://www.millennium.ab.ca/products/fl ... _Drive.pdf

Anyway the speed variation of this SCP is not due to the drive, but more to the STX format itself. This format is clearly not designed to regenerate a flux stream or a floppy disk…
I got some difficulties some years ago when i have done the first reverse engineering of this format. Some tracks in these file contains only the sector data (all the track must be create), while others contains the data coming from a READTRACK command to the WD1772 (data NOT at the MFM level of course…). Unfortunately all information (data, timing…) in these files are related to the WD1772. And half of the disk data are missing : the clock stream. This make the disk recreation somewhat tricky. And i think that some STX with track-based disks are almost impossible to recreate properly : the missing clocks information to resync the track in the real world are … missing from the file . So lot’s of thing are done by guessing from this format… And the timings may vary depending of the tracks…

Another SCP example generated from ST files :
http://hxc2001.free.fr/vrac/Odd_Stuff_2 ... One_st.zip
This time the timings are a lot better

[npomarede]

Did you test the .scp created disk? What drive was used to create the original image? I have never seen a drive speed vary so much before!

The file format looks perfect to me! Nice job.

The scp was tested, but not with a real disk. And no floppy disk drive was used to generate it : This is a conversion from a STX file.
Did you really found that the drive speed change so much ? Under SCP i see track lenght between 199.971 ms and 201.646ms. This is < to 1% of variation.

Hello
Here's the link of the KF dump made by Mug UK from a working Union Demo disk.
http://www.atari-forum.com/viewtopic.ph ... 17#p243517
If you use this to create a SCP file, you should get much better clock data than from starting with the STX version.

Nicolas

[DrCoolZic]

Excellent work Jeff.
I still hope to be able to do the same with my program. I have some good ideas on how to generate details flux info from STX file ...
I will look tomorow at the files you have generated and publish some pictures of the analysis here
Again congrat

[Jeff_HxC2001]

Excellent work Jeff.
I still hope to be able to do the same with my program. I have some good ideas on how to generate details flux info from STX file ...
I will look tomorow at the files you have generated and publish some pictures of the analysis here
Again congrat

Nothing spectacular here. This is the job of this software to convert the various disk format availables.

[Brume]

Who holds the copyright to this demo? The information linked to for the Union Demo goes to a POV demo, not the Union Demo. I would need to see a disclaimer for the copyright in order to make this available on my website.

No, POV is the team who put the demo on a compilation disk, but it didn't create the Union Demo. I don't think this demo has a copyright, it's a free stuff that was freely spread & copied (one of the most famous on the ST scene). Also The Union Demo was coded by various teams such as The CareBears, The EXceptions, Replicants, Level 16... (all members of The Union).

The Union Demo is the only stuff that Ijor spread on his website to test Pasti: http://pasti.fxatari.com/

[Jeff_HxC2001]

Did you test the .scp created disk? What drive was used to create the original image? I have never seen a drive speed vary so much before!

The file format looks perfect to me! Nice job.

The scp was tested, but not with a real disk. And no floppy disk drive was used to generate it : This is a conversion from a STX file.
Did you really found that the drive speed change so much ? Under SCP i see track lenght between 199.971 ms and 201.646ms. This is < to 1% of variation.

Hello
Here's the link of the KF dump made by Mug UK from a working Union Demo disk.
http://www.atari-forum.com/viewtopic.ph ... 17#p243517
If you use this to create a SCP file, you should get much better clock data than from starting with the STX version.

Nicolas

Here it is ! (KF Stream -> SCP Stream)
http://hxc2001.free.fr/vrac/The_Union_Demo.zip
And yes the timings looks better . The scp is working on the ST, but it seems that there is something wrong with one sector...

[JimDrew]

Jeff, at the suggestion of DrCoolZic I am making a change to the .scp file format. As long as you are using the offsets already specified it won't affect your HxC support.

Instead of having 5 entries of 3 long words for each of the revolutions, I am using BYTE 0x05 (Number of revolutions) to build the entry table. So, it is possible to have one entry (one set) of 3 long words when only a single revolution is being stored.. or 20 sets if you had 20 revolutions per track being stored. Each entry is still: duration/length/offset. I got rid of the flux space size being stored for read/write cable images. That really is not something that programs need to know. The program creating a read/write capable image should be padding the space to the maximum necessary for storing the worst case scenario of flux transitions for every track.

Another thing to keep in mind for accuracy - the duration is there for a reason. That is the true drive speed in time. To convert the flux to a 100% accurate real time value, you would need to multiply each flux transition time by the duration difference. I use this floating point formula:

S = 1000000 / duration / 5 ; S = multiplier based on drive speed
Z = RawBuffer(X) * 256 + RawBuffer(X + 1) ; Z = bit cell time
V = Int(Z * 25 * S) ; V = corrected bit cell time

For example, if the duration was 199667us then the multiplier would be 1.0016677768484526737017133527323, so each bit cell time would be multiplied by this value to give you the true exact time. This is probably not so important for reading, but it is required for writing to accommodate for different drive speeds.

[JimDrew]

Jeff, someone has reported that he is using the HxC with .scp images and that you are generating two revolutions per track, which is not necessary. Did you know this?

[Jeff_HxC2001]

Jeff, someone has reported that he is using the HxC with .scp images and that you are generating two revolutions per track, which is not necessary. Did you know this?

Yes i am aware of this. in fact still need to implement the "flakey/weak bits" support into the exporter : at each revolution, each flakey/weak may change.
This is the only purpose to make multi-revolutions.
Later versions will automatically choose between 1 or more revolutions.

[DrCoolZic]

union-demo-layout.JPG

union-demo-flux.JPG

[JimDrew]

Jeff, someone has reported that he is using the HxC with .scp images and that you are generating two revolutions per track, which is not necessary. Did you know this?

Yes i am aware of this. in fact still need to implement the "flakey/weak bits" support into the exporter : at each revolution, each flakey/weak may change.
This is the only purpose to make multi-revolutions.
Later versions will automatically choose between 1 or more revolutions.

You don't need multiple revolutions to determine weakbits.

[DrCoolZic]

Jeff, someone has reported that he is using the HxC with .scp images and that you are generating two revolutions per track, which is not necessary. Did you know this?

Yes i am aware of this. in fact still need to implement the "flakey/weak bits" support into the exporter : at each revolution, each flakey/weak may change.
This is the only purpose to make multi-revolutions.
Later versions will automatically choose between 1 or more revolutions.

You don't need multiple revolutions to determine weakbits.

As already discussed we have a different definition for fuzzy bits: Our definition is a fuzzy bits reads differently on different revolution
With this definition you neeed at least two rev to find fuzzy bits.
But of course in some cases you can guess that you will get fuzzy bits just by their "configurations"

For info Aufit alpaha release available here http://www.atari-forum.com/viewtopic.php?f=102&t=25906

[JimDrew]

You can determine if you have weakbits by looking at the bit cell times and filtering valid vs. invalid, so only a single revolution is necessary. Multiple revolutions definitely increases the accuracy though. Your fuzzy bits are not the same as weakbits. The data in a fuzzy bit area only changes because of how the WD1772 decodes the data between two valid windows. The actual flux data dumped (like from Dungeon Master) should never change from read to read with SCP because it does not contain any actual weakbits. Proof of this is that you can read a fuzzy bits track and write it back without doing anything. Weakbits require flux times outside of what the drive's controller can handle, which is why it changes every time it is read. Special handling for writing is required for weakbits.

[Hippy Dave]

Thank you Jeff
So does it mean it's easily possible to convert STX to RAW or SCP format?

Yes, and ST,MSA,DIM,STT,ADF,ADZ,DMS files too
Please note that the software is also able to import streams files, analyze them, and generate ST,MSA, ADF,...
Here is the full support list for more details :
(Access : R -> Can import the file W -> Can create the file)
(Ps: Many file format without the "W" can be generated with the generic raw file exporter..)

Code: Select all

libhxcfe version : 2.4.4.1

---------------------------------------------------------------------------
-                   libhxcfe file type support list                       -
---------------------------------------------------------------------------
MODULE ID          ACCESS    DESCRIPTION                         Extension

KRYOFLUXSTREAM      (RW) :  KryoFlux Stream Loader                (*.raw)
AMIGA_DMS           (R ) :  AMIGA DMS Loader                      (*.dms)
AMIGA_ADZ           (R ) :  AMIGA ADZ Loader                      (*.adz)
AMIGA_EXTADF        (R ) :  AMIGA EXTENDED ADF Loader             (*.adf)
AMIGA_OLDEXTADF     (R ) :  AMIGA OLD EXTENDED ADF Loader         (*.adf)
ZXSPECTRUM_FDI      (R ) :  ZX SPECTRUM FDI Loader                (*.fdi)
AMIGA_ADF           (RW) :  AMIGA ADF Loader                      (*.adf)
ACORN_ADF           (R ) :  ACORN ADF Loader                      (*.adf)
AMSTRADCPC_DSK      (RW) :  Amstrad CPC DSK Loader                (*.dsk)
ATARIST_DIM         (R ) :  ATARI ST DIM Loader                   (*.dim)
ATARIST_STX         (R ) :  Atari ST STX/Pasti Loader             (*.stx)
ATARIST_STT         (R ) :  ATARI ST STT Loader                   (*.stt)
COPYQM              (R ) :  COPYQM IMG Loader                     (*.dsk)
TELEDISK_TD0        (R ) :  TELEDISK TD0 Loader                   (*.td0)
ATARIST_MSA         (RW) :  ATARI ST MSA Loader                   (*.msa)
RAW_IMZ             (R ) :  IBM PC IMZ Loader                     (*.imz)
HXCMFM_IMG          (RW) :  HXC MFM IMG Loader                    (*.mfm)
ORIC_DSK            (R ) :  ORIC DSK Loader                       (*.dsk)
ATARIST_ST          (R ) :  ATARI ST ST Loader                    (*.st)
ROLAND_W30          (R ) :  Roland W30 file Loader                (*.w30)
SPS_IPF             (R ) :  SPS IPF Loader                        (*.ipf)
TI994A_V9T9         (RW) :  TI99 4A V9T9 Loader                   (*.v9t9)
AMIGA_FS            (R ) :  AMIGA FS Loader                       (*.amigados)
PROPHET2000         (R ) :  PROPHET 2000 Loader                   (*.img)
RAW_IMG             (R ) :  IBM PC IMG Loader                     (*.img)
MSX_DSK             (R ) :  MSX DSK Loader                        (*.dsk)
FAT12FLOPPY         (R ) :  FAT12/MS DOS Loader                   (*.fat)
HXC_HFE             (RW) :  SD Card HxCFE HFE file Loader         (*.hfe)
HXC_EXTHFE          ( W) :  SD Card HxCFE EXTENDED HFE file Loader(*.hfe)
HXC_HDDD_A2_HFE     ( W) :  SD Card HxCFE HFE file Loader (HDDD A2 Support)(*.hfe)
VTR_IMG             (RW) :  VTR IMG Loader                        (*.vtr)
IMD_IMG             (RW) :  ImageDisk IMD file Loader             (*.imd)
HXC_AFI             (RW) :  HxC AFI file loader                   (*.afi)
C64_D64             (R ) :  C64 D64 file image loader             (*.d64)
C64_D81             (R ) :  C64 D81 Loader                        (*.d81)
ZXSPECTRUM_TRD      (R ) :  Zx Spectrum TRD Loader                (*.trd)
ZXSPECTRUM_SCL      (R ) :  ZX SPECTRUM SCL Loader                (*.scl)
THOMSONTO8D_SAP     (R ) :  THOMSON TO8D SAP Loader               (*.sap)
TRS80_JV1           (R ) :  TRS80 JV1 Loader                      (*.jv1)
TRS80_JV3           (RW) :  TRS80 JV3 Loader                      (*.jv3)
TRS80_JVC           (R ) :  TRS80 JVC Loader                      (*.jvc)
SVD                 (R ) :  SVD Loader                            (*.svd)
NEC_D88             (RW) :  NEC D88 Loader                        (*.d88)
X68000_HDM          (R ) :  X68000 HDM file Loader                (*.hdm)
RAW_LOADER          (RW) :  RAW Sector loader                     (*.img)
SNES_SMC            (R ) :  Super famicom SMC Loader              (*.smc)
VEGAS6809           (R ) :  VEGAS6809 image Loader                (*.veg)
TRS80_DMK           (RW) :  TRS80 DMK Loader                      (*.dmk)
TI994A_PC99         (R ) :  TI99 4A PC99 Loader                   (*.pc99)
APRIDISK            (R ) :  APRIDISK Loader                       (*.dsk)
ENSONIQ_EDE         (R ) :  ENSONIQ EDE Loader                    (*.ede)
FAT12FLOPPY         (R ) :  FAT12/MS DOS Loader                   (*.fat)
ENSONIQ_GKH         (R ) :  ENSONIQ GKH Loader                    (*.gkh)
THOMSON_FD          (R ) :  THOMSON FD Loader                     (*.fd)
CASIO_FZF           (R ) :  Casio FZF file Loader                 (*.fzf)
DRAGON3264_VDK      (R ) :  DRAGON32 & 64 VDK Loader              (*.vdk)
OBERHEIM_DPX        (R ) :  Oberheim DPX Loader                   (*.dpx)
ENSONIQ_EDM         (R ) :  Ensoniq mirage EDM Loader             (*.edm)
EMAX_EM             (R ) :  EMAX EM1 & EM2 Loader                 (*.em1)
SAMCOUPE_MGT        (R ) :  SAM COUPE MGT Loader                  (*.mgt)
SAMCOUPE_SAD        (R ) :  SAM COUPE SAD Loader                  (*.sad)
EMULATORII          (R ) :  E-mu Emulator II / SP1200 dsk Loader  (*.emuiifd)
EMULATORII_EMUII    (R ) :  E-mu Emulator II *.eii Loader         (*.eii)
EMULATORI           (R ) :  E-mu Emulator I dsk Loader            (*.emufd)
CAMPUTERSLYNX       (R ) :  CAMPUTERSLYNX Loader                  (*.ldf)
BBC_ADL             (R ) :  BBC ADL floppy image loader           (*.adl)
BBC_SSD_DSD         (R ) :  BBC SSD & DSD floppy image loader     (*.dsd)
FEI                 (R ) :  FEI Loader                            (*.fei)
SYSTEM_24           (R ) :  System 24 loader                      (*.s24)
SCP_FLUX_STREAM     (RW) :  SCP Stream Loader                     (*.scp)
APPLE2_NIB          (R ) :  Apple II NIB Loader                   (*.nib)
APPLE2_DO           (R ) :  Apple II DO Loader                    (*.do)
SPECCYDOS_SDD       (RW) :  Speccy DOS SDD File Loader            (*.sdd)
BMP_IMAGE           ( W) :  BMP floppy tracks layout image generator(*.bmp)
ARBURG              (RW) :  ARBURG RAW Loader                     (*.arburgfd)
GENERIC_XML         (RW) :  Generic XML file Loader               (*.xml)

I just compiled HxCFloppyEmulator and I've made a Readme.Linux
Maybe this info could be added to the HxCFloppyEmulator project.

Code: Select all

   Building HxCFloppyEmulator on CentOS 5 Linux

1) Have a copy of the HxCFloppyEmulator sources in a directory.

2) Enter the
   HxCFloppyEmulator/HxCFloppyEmulator_software/trunk/sources/thirdpartylibs/fltk
   directory.

3) Extract fltk-1.3.2-source.tar.gz from the fltk website into this directory.

4) Delete the fltk-1.3.x directory

5) Rename the extracted fltk-1.3.2 directory to fltk-1.3.x

6) Enter the fltk-1.3.x directory and run configure:
./configure

7) Modify the Makefile:
   HxCFloppyEmulator/HxCFloppyEmulator_software/trunk/build/Makefile

   by changing line 17 from:
LDFLAGS=-lc -lm  -ldl  -lpthread
   to:
LDFLAGS=-lc -lm  -ldl  -lpthread -lXext -lXft -lXinerama

8) Enter the HxCFloppyEmulator/build directory

9) run make
make

10) done

[Jeff_HxC2001]

I just compiled HxCFloppyEmulator and I've made a Readme.Linux
Maybe this info could be added to the HxCFloppyEmulator project.

Code: Select all

   Building HxCFloppyEmulator on CentOS 5 Linux

1) Have a copy of the HxCFloppyEmulator sources in a directory.

2) Enter the
   HxCFloppyEmulator/HxCFloppyEmulator_software/trunk/sources/thirdpartylibs/fltk
   directory.

3) Extract fltk-1.3.2-source.tar.gz from the fltk website into this directory.

4) Delete the fltk-1.3.x directory

5) Rename the extracted fltk-1.3.2 directory to fltk-1.3.x

6) Enter the fltk-1.3.x directory and run configure:
./configure

7) Modify the Makefile:
   HxCFloppyEmulator/HxCFloppyEmulator_software/trunk/build/Makefile

   by changing line 17 from:
LDFLAGS=-lc -lm  -ldl  -lpthread
   to:
LDFLAGS=-lc -lm  -ldl  -lpthread -lXext -lXft -lXinerama

8) Enter the HxCFloppyEmulator/build directory

9) run make
make

10) done

Yes good idea .
But the "-lXext -lXft -lXinerama" modification is specific to the CentOS 5 Linux distribution i think.

[Hippy Dave]

I just compiled HxCFloppyEmulator and I've made a Readme.Linux
Maybe this info could be added to the HxCFloppyEmulator project.

Code: Select all

   Building HxCFloppyEmulator on CentOS 5 Linux

1) Have a copy of the HxCFloppyEmulator sources in a directory.

2) Enter the
   HxCFloppyEmulator/HxCFloppyEmulator_software/trunk/sources/thirdpartylibs/fltk
   directory.

3) Extract fltk-1.3.2-source.tar.gz from the fltk website into this directory.

4) Delete the fltk-1.3.x directory

5) Rename the extracted fltk-1.3.2 directory to fltk-1.3.x

6) Enter the fltk-1.3.x directory and run configure:
./configure

7) Modify the Makefile:
   HxCFloppyEmulator/HxCFloppyEmulator_software/trunk/build/Makefile

   by changing line 17 from:
LDFLAGS=-lc -lm  -ldl  -lpthread
   to:
LDFLAGS=-lc -lm  -ldl  -lpthread -lXext -lXft -lXinerama

8) Enter the HxCFloppyEmulator/build directory

9) run make
make

10) done

Yes good idea .
But the "-lXext -lXft -lXinerama" modification is specific to the CentOS 5 Linux distribution i think.

I wondered why other distros did not have a problem without "-lXext -lXft -lXinerama" so maybe this is something to note anyways.
One other thing; Your whole project must be pulled just to compile two programs. It is good that the whole project can be pulled in one shot, but pulling separate items would be nice... Or maybe a source tarball could be put in with the windows-executable download-files on sourceforge.

[Stefan jL]

Not Atari ST related but i have done a successful copy of Bonanza Bros for Sega System 24 using SuperCard Pro
It uses HD 1.44 disks http://system16.com/hardware.php?id=708

Here is the scp copy:
http://arcade.ym2149.com/files/scpro/wo ... (index).7z

[Jeff_HxC2001]

Not Atari ST related but i have done a successful copy of Bonanza Bros for Sega System 24 using SuperCard Pro
It uses HD 1.44 disks http://system16.com/hardware.php?id=708

Here is the scp copy:
http://arcade.ym2149.com/files/scpro/wo ... (index).7z

http://www.youtube.com/watch?v=2LvD8FbNUFM