<![CDATA[CBMSTUFF FORUM - Developer Area]]> https://www.cbmstuff.com/forum/ Thu, 16 Apr 2026 23:44:03 +0000 MyBB <![CDATA[Reference of first flux transition]]> https://www.cbmstuff.com/forum/showthread.php?tid=868 Tue, 21 Dec 2021 06:09:55 -0500 AlWe]]> https://www.cbmstuff.com/forum/showthread.php?tid=868
I'm just reading in the flux data, add them all up and then compare the result with the corresponding duration field from the TRK header.
Here what I e.g. get for one of my 1.44 MB IBM disks:




Quote:rev: 0, index2index=7987142, flux transitions=76847
rev: 1, index2index=7988418, flux transitions=76853
rev 0: acc ticks=7987094
rev 1: acc ticks=7988423



index2index and flux transitions are the duration and the bitcells from the TRK header, while acc ticks is the sum over all flux transitions in the revolutions.

For rev 0 there are 48 "free" ticks which should be the ticks from the last flux transition to the index signal,
But in rev 1 there are 5 ticks *more* than the revolution is long...

Noteworthy is also the discrepancy: while the index2index time varies 1276 ticks (31.9ms) the accumulated ticks have a discrepancy of 1329 ticks (33,225ms)
So the second revolution as roughly 2ms longer, and has 6 flux transitions more. Which seems to be too much to be explained away by some rounding errors.

As background why I'm looking at that:
There is at least one floppy formal - XDF - which is writing sectors over the index pulse and therefore I have to stitch revolutions together correctly, too.

My first assumption was, that the scp format is simply using the time from the first index pulse as reference for the first recorded flux transition.
The question therefore was, if I have to account for the time between the last flux in a track when I want to decode the first flux transition when reading over the index mark.
Now since the first flux transitions in my mult-rev images are always identical it looks like the reference may already be the last flux prior to the index signal. (Which would prevent us to figure out how far away the first flux transition is from the index pulse...)
That could explain why the sum of all flux transactions is longer than the track.

But I simply can't match the what I see into either assumption... So any tips what I'm doing wrong here?]]>
I'm just reading in the flux data, add them all up and then compare the result with the corresponding duration field from the TRK header.
Here what I e.g. get for one of my 1.44 MB IBM disks:




Quote:rev: 0, index2index=7987142, flux transitions=76847
rev: 1, index2index=7988418, flux transitions=76853
rev 0: acc ticks=7987094
rev 1: acc ticks=7988423



index2index and flux transitions are the duration and the bitcells from the TRK header, while acc ticks is the sum over all flux transitions in the revolutions.

For rev 0 there are 48 "free" ticks which should be the ticks from the last flux transition to the index signal,
But in rev 1 there are 5 ticks *more* than the revolution is long...

Noteworthy is also the discrepancy: while the index2index time varies 1276 ticks (31.9ms) the accumulated ticks have a discrepancy of 1329 ticks (33,225ms)
So the second revolution as roughly 2ms longer, and has 6 flux transitions more. Which seems to be too much to be explained away by some rounding errors.

As background why I'm looking at that:
There is at least one floppy formal - XDF - which is writing sectors over the index pulse and therefore I have to stitch revolutions together correctly, too.

My first assumption was, that the scp format is simply using the time from the first index pulse as reference for the first recorded flux transition.
The question therefore was, if I have to account for the time between the last flux in a track when I want to decode the first flux transition when reading over the index mark.
Now since the first flux transitions in my mult-rev images are always identical it looks like the reference may already be the last flux prior to the index signal. (Which would prevent us to figure out how far away the first flux transition is from the index pulse...)
That could explain why the sum of all flux transactions is longer than the track.

But I simply can't match the what I see into either assumption... So any tips what I'm doing wrong here?]]> <![CDATA[SCP format - disk type confusion]]> https://www.cbmstuff.com/forum/showthread.php?tid=861 Thu, 11 Nov 2021 16:21:48 -0500 AlWe]]> https://www.cbmstuff.com/forum/showthread.php?tid=861 Looking at the SCP format description this should be possible by checking Byte 4. But when I look at my SCP images the value is not even close to what I expect and I can see no way to match it up to the documentation...

Here some samples I created at different times using the SuperCard Pro Software. The last sample was created just now after double checking that as format IBM 1.44 had been selected:
  1. 53 43 50 20 45
  2. 53 43 50 23 45
  3. 53 43 50 23 45
I don't get why the disk type is 0x45 when I just created an IBM 1.44 image. Shouldn't it be 0x33?
0x45 would map to DISK CLASS TANDY and an undefined SUB.CLASS. Am I missing something or is the documentation really wrong here?!?

Unrelated but also noteworthy, there is a typo in the tapes section:
Code:
tape_MFM = 0x01                    ; xxxx 0010

In context it's more or less obvious that this should be tape_MFM = 0x02]]> Looking at the SCP format description this should be possible by checking Byte 4. But when I look at my SCP images the value is not even close to what I expect and I can see no way to match it up to the documentation...

Here some samples I created at different times using the SuperCard Pro Software. The last sample was created just now after double checking that as format IBM 1.44 had been selected:
  1. 53 43 50 20 45
  2. 53 43 50 23 45
  3. 53 43 50 23 45
I don't get why the disk type is 0x45 when I just created an IBM 1.44 image. Shouldn't it be 0x33?
0x45 would map to DISK CLASS TANDY and an undefined SUB.CLASS. Am I missing something or is the documentation really wrong here?!?

Unrelated but also noteworthy, there is a typo in the tapes section:
Code:
tape_MFM = 0x01                    ; xxxx 0010

In context it's more or less obvious that this should be tape_MFM = 0x02]]> <![CDATA[SCP media test in Linux, verify question?]]> https://www.cbmstuff.com/forum/showthread.php?tid=524 Thu, 31 May 2018 09:34:33 -0400 Pitou]]> https://www.cbmstuff.com/forum/showthread.php?tid=524
I just started working on a media test for Linux re-using the source code from Keir Fraser.

I did a lot and so far it's working pretty well. For now, I'm writing a 4us flux for a total of 200ms.

I'm now reading back the data, but not sure how to do the compare. As we know the values are not always exact from read to read.

What is the margin error we can assume?

Also, the first 2-3 bitcells are often very far from original value. Is that normal?

How should I do the compare and assume that a track is ok?

Thank you.

Pitou!]]>
I just started working on a media test for Linux re-using the source code from Keir Fraser.

I did a lot and so far it's working pretty well. For now, I'm writing a 4us flux for a total of 200ms.

I'm now reading back the data, but not sure how to do the compare. As we know the values are not always exact from read to read.

What is the margin error we can assume?

Also, the first 2-3 bitcells are often very far from original value. Is that normal?

How should I do the compare and assume that a track is ok?

Thank you.

Pitou!]]> <![CDATA[SuperCard Pro iwth IEC interface]]> https://www.cbmstuff.com/forum/showthread.php?tid=399 Mon, 21 Aug 2017 11:02:10 -0400 Jeff_Birt]]> https://www.cbmstuff.com/forum/showthread.php?tid=399
Just a random thought...]]>
Just a random thought...]]> <![CDATA[Settle delay and other timings, three-mode drives]]> https://www.cbmstuff.com/forum/showthread.php?tid=344 Mon, 14 Nov 2016 12:15:58 -0500 mark_k]]> https://www.cbmstuff.com/forum/showthread.php?tid=344 Settle delay

How is the drive settle delay handled? That's the delay needed after moving the heads to the desired track, before reading/writing data. Do programs which access the SCP have to handle that themselves, or does the hardware/firmware guarantee it for the step to track command?

The doc for command 0x91 set parameters says "Word 4 - delay (in milliseconds) after seeking track 0 (default 15)". Which suggests the SCP only uses a settle delay after stepping to track 0 via command 0x88 - seek track 0. Should user programs wait after issuing command 0x89 step to track, before reading data? And similarly wait after issuing commands 0x8A and 0x8B (step inwards and outwards)?

The Citizen Z1DA-78A floppy drive specification at
  http://maben.homeip.net/static/S100/citi...iskete.pdf
mentions 18ms being needed as the settle delay. My drive is a Citizen Z1DE-57Bb (HP OEM model) and I'm having problems getting good dumps using it. I'll post about that in another thread.


Three-mode floppy drives

When using a three-mode floppy drive (i.e. one capable of being told to spin at 360rpm instead of 300rpm), can the SuperCard control the drive mode? I notice the 0xA0 read flux data command has bit 3 related to that. Does that flag just tell the SCP to read at a higher resolution, or does it tell the drive to spin at that speed?

Various drive manuals say the mode (for HD disks at least) is selected by the state of drive connector pin 2.
According to "SAMSUNG-SFD321B-070103.pdf"
  http://www.techtravels.org/wp-content/up...070103.pdf
the mode is set by the density select line (pin 2 of the 34-pin connector):
 - HD disk and DS line HIGH: 2.0MB (normal 300rpm)
 - HD disk and DS line low: 1.6MB (360rpm)
 - DD disk: always 1.0MB regardless of DS line (300rpm)

According to "FDAA-522041_YD-702D-6639D_3.5_Floppy.pdf"
  http://bitsavers.informatik.uni-stuttgar...Floppy.pdf
those Y-E Data drives can be jumpered for both senses of pin 2 (the Y-E Data PDF calls that line MODE SELECT). In other words, either the same as SFD-321B, or the opposite: HD disk and pin 2 low: 2.0MB/300rpm, HD disk and pin 2 high: 1.6MB/360rpm. If I read the PDF correctly, it looks like that particular Y-E Data drive ships with jumpers set to the opposite of the SFD-321B.

Teac also made 3-mode floppy drives (FD-235HG). According to "Teac FD-235HG manual.pdf"
  http://maben.homeip.net/static/S100/teac...manual.pdf
(document page 22, PDF page 25)
MODE SELECT LOW: 1.6MB (360rpm), MODE SELECT HIGH: 2.0MB (300rpm)
So Teac 3-mode selection is same as Samsung.]]> Settle delay

How is the drive settle delay handled? That's the delay needed after moving the heads to the desired track, before reading/writing data. Do programs which access the SCP have to handle that themselves, or does the hardware/firmware guarantee it for the step to track command?

The doc for command 0x91 set parameters says "Word 4 - delay (in milliseconds) after seeking track 0 (default 15)". Which suggests the SCP only uses a settle delay after stepping to track 0 via command 0x88 - seek track 0. Should user programs wait after issuing command 0x89 step to track, before reading data? And similarly wait after issuing commands 0x8A and 0x8B (step inwards and outwards)?

The Citizen Z1DA-78A floppy drive specification at
  http://maben.homeip.net/static/S100/citi...iskete.pdf
mentions 18ms being needed as the settle delay. My drive is a Citizen Z1DE-57Bb (HP OEM model) and I'm having problems getting good dumps using it. I'll post about that in another thread.


Three-mode floppy drives

When using a three-mode floppy drive (i.e. one capable of being told to spin at 360rpm instead of 300rpm), can the SuperCard control the drive mode? I notice the 0xA0 read flux data command has bit 3 related to that. Does that flag just tell the SCP to read at a higher resolution, or does it tell the drive to spin at that speed?

Various drive manuals say the mode (for HD disks at least) is selected by the state of drive connector pin 2.
According to "SAMSUNG-SFD321B-070103.pdf"
  http://www.techtravels.org/wp-content/up...070103.pdf
the mode is set by the density select line (pin 2 of the 34-pin connector):
 - HD disk and DS line HIGH: 2.0MB (normal 300rpm)
 - HD disk and DS line low: 1.6MB (360rpm)
 - DD disk: always 1.0MB regardless of DS line (300rpm)

According to "FDAA-522041_YD-702D-6639D_3.5_Floppy.pdf"
  http://bitsavers.informatik.uni-stuttgar...Floppy.pdf
those Y-E Data drives can be jumpered for both senses of pin 2 (the Y-E Data PDF calls that line MODE SELECT). In other words, either the same as SFD-321B, or the opposite: HD disk and pin 2 low: 2.0MB/300rpm, HD disk and pin 2 high: 1.6MB/360rpm. If I read the PDF correctly, it looks like that particular Y-E Data drive ships with jumpers set to the opposite of the SFD-321B.

Teac also made 3-mode floppy drives (FD-235HG). According to "Teac FD-235HG manual.pdf"
  http://maben.homeip.net/static/S100/teac...manual.pdf
(document page 22, PDF page 25)
MODE SELECT LOW: 1.6MB (360rpm), MODE SELECT HIGH: 2.0MB (300rpm)
So Teac 3-mode selection is same as Samsung.]]> <![CDATA[Decoding Flux Information]]> https://www.cbmstuff.com/forum/showthread.php?tid=299 Mon, 15 Feb 2016 21:12:23 -0500 Relayer]]> https://www.cbmstuff.com/forum/showthread.php?tid=299
I currently contain the flux values in a byte array. One sample track of a disk has alternate low and high decimal values. If I understand the SCP format, I'm looking at 16-bit pair values in HIGH-BYTE/LOW-BYTE sequence. Does each 16-bit value represent a flux intensity in a range from 0 to 65535?

I converted the first 300 bytes to HEX values and got the following:

002E0108010901090109010901090109010901080109010901090109010901090109010901090109010901090109010901090107010A010A01090108010B0107010A0109010B01050086008200880108010A0106008700850083008500870106010B01080109010A01090108010A0107010C0107010A0107010A0109010A010801090108010A01090108010A0109010801090108010A0109

Any guess as to what I'm looking at?]]>
I currently contain the flux values in a byte array. One sample track of a disk has alternate low and high decimal values. If I understand the SCP format, I'm looking at 16-bit pair values in HIGH-BYTE/LOW-BYTE sequence. Does each 16-bit value represent a flux intensity in a range from 0 to 65535?

I converted the first 300 bytes to HEX values and got the following:

002E0108010901090109010901090109010901080109010901090109010901090109010901090109010901090109010901090107010A010A01090108010B0107010A0109010B01050086008200880108010A0106008700850083008500870106010B01080109010A01090108010A0107010C0107010A0107010A0109010A010801090108010A01090108010A0109010801090108010A0109

Any guess as to what I'm looking at?]]> <![CDATA[Device initialisation]]> https://www.cbmstuff.com/forum/showthread.php?tid=295 Sat, 06 Feb 2016 14:02:42 -0500 obo]]> https://www.cbmstuff.com/forum/showthread.php?tid=295
After opening the device I always select drive 0, turn the motor on, then seek to cyl 0.  Instead of seeking to cyl 0 it seems to position the drive head at cyl -4, and using a slower than normal step rate.  If I then sequentially read the content of tracks 0 upwards, the first 4 show as blank and cyl 4 shows the output from physical cyl 0, etc.  If I stop my program and re-run it everything works completely normally, with cyl 0 correctly located and a normal step rate used.

It seems like I should be initialising more of the board when I first open it.  Can you advise on what I need to change from the firmware defaults?  I have hardware version 1.1 and firmware version 1.2 installed.

The cyl -4 issue feels like it might be related to the flippy mode somehow, which I'm not changing.  I've noticed your own software doesn't suffer from the same problem, but it's likely to be applying more to restore the user's configuration settings...]]>
After opening the device I always select drive 0, turn the motor on, then seek to cyl 0.  Instead of seeking to cyl 0 it seems to position the drive head at cyl -4, and using a slower than normal step rate.  If I then sequentially read the content of tracks 0 upwards, the first 4 show as blank and cyl 4 shows the output from physical cyl 0, etc.  If I stop my program and re-run it everything works completely normally, with cyl 0 correctly located and a normal step rate used.

It seems like I should be initialising more of the board when I first open it.  Can you advise on what I need to change from the firmware defaults?  I have hardware version 1.1 and firmware version 1.2 installed.

The cyl -4 issue feels like it might be related to the flippy mode somehow, which I'm not changing.  I've noticed your own software doesn't suffer from the same problem, but it's likely to be applying more to restore the user's configuration settings...]]> <![CDATA[Sending data from RAM to USB]]> https://www.cbmstuff.com/forum/showthread.php?tid=287 Mon, 18 Jan 2016 16:41:49 -0500 dfstudios]]> https://www.cbmstuff.com/forum/showthread.php?tid=287
I've been experimenting with writing some software to control SCP. Everything I've done so far works okay, apart from sending data from the on-board RAM to the USB port as I keep getting a pr_CommandErr return code.

Could someone please explain to me in more detail how to use this function?

Kind regards,

Francis]]>
I've been experimenting with writing some software to control SCP. Everything I've done so far works okay, apart from sending data from the on-board RAM to the USB port as I keep getting a pr_CommandErr return code.

Could someone please explain to me in more detail how to use this function?

Kind regards,

Francis]]> <![CDATA[Weird problem writing 'weak flux' pattern]]> https://www.cbmstuff.com/forum/showthread.php?tid=282 Thu, 07 Jan 2016 07:53:31 -0500 keirf]]> https://www.cbmstuff.com/forum/showthread.php?tid=282
I'm experimenting with reliably writing 'weak flux' areas to disk, as short as 64 MFM bitcells (128us), which will read back randomly. I've settled on the following repeated pattern of 12 flux values: 25us, 0.5us*6, 19us, 0.5us*4

This works well. However for convenience I want to use the same pattern even for much larger weak areas. I have one track which is 44894489 ... a few bytes of header ... 8192 MFM weak bitcells (16ms). Remainder of track is normal null filler.

When I generate above track with my chosen weak pattern, write to disk with Supercard Pro, and then read back, my 44894489 header is missing Sad It seems related to the large number of short (500ns) fluxes I am emitting. If I remove those I get my 44894489 sync back.

I can provide before and after SCP files. Of course these are generated entirely by my own tools, so can't discount I've done something stupid  Wink

 Regards,
 Keir]]>
I'm experimenting with reliably writing 'weak flux' areas to disk, as short as 64 MFM bitcells (128us), which will read back randomly. I've settled on the following repeated pattern of 12 flux values: 25us, 0.5us*6, 19us, 0.5us*4

This works well. However for convenience I want to use the same pattern even for much larger weak areas. I have one track which is 44894489 ... a few bytes of header ... 8192 MFM weak bitcells (16ms). Remainder of track is normal null filler.

When I generate above track with my chosen weak pattern, write to disk with Supercard Pro, and then read back, my 44894489 header is missing Sad It seems related to the large number of short (500ns) fluxes I am emitting. If I remove those I get my 44894489 sync back.

I can provide before and after SCP files. Of course these are generated entirely by my own tools, so can't discount I've done something stupid  Wink

 Regards,
 Keir]]> <![CDATA[Strange...]]> https://www.cbmstuff.com/forum/showthread.php?tid=199 Wed, 10 Dec 2014 05:08:02 -0500 giants]]> https://www.cbmstuff.com/forum/showthread.php?tid=199
I Have the 2 cars (Kryo and scp), why ? because I think this cards is perfect.
I prefere to start to say, This post IS NOT, sorry : 'which has the largest' Wink
I say that because this post was deleted to the kryo forum... maybe here we are more understanding, I hope Smile

SO !
I made DUMPS with 1 floppy reader (Sony MPF920L)
one cable simple (2 connectors)
one Molex External Power (12 and 5V)
And, one Original Amiga Disk Game : BloodMoney
I Made ALL MY test with the SAME Hardware, it's very important

The question is, It is normaln when I use some programs to see 'What the data look like', Program like Aufit or hxcfe, to generate bmp 'diskview'
I don't have the same graphics....

Flux is Flux, don't care is Kryo or Scp
If Data Is present, normaly I must see It.

But...
[Image: aufit_KRYO_BloodMoney_WindowsXP.gif]

and

[Image: aufit_SCP_BloodMoney_WindowsXP.gif]

Look in the circle, left picture...
Maybe is aufit so, let's try with hxcfe

hxcfe_KRYO_BloodMoney_WindowsXP.gif
[Image: hxcfe_KRYO_BloodMoney_WindowsXP.gif]

and

hxcfe_SCP_BloodMoney_WindowsXP.gif
[Image: hxcfe_SCP_BloodMoney_WindowsXP.gif]


How do you explain that?]]>
I Have the 2 cars (Kryo and scp), why ? because I think this cards is perfect.
I prefere to start to say, This post IS NOT, sorry : 'which has the largest' Wink
I say that because this post was deleted to the kryo forum... maybe here we are more understanding, I hope Smile

SO !
I made DUMPS with 1 floppy reader (Sony MPF920L)
one cable simple (2 connectors)
one Molex External Power (12 and 5V)
And, one Original Amiga Disk Game : BloodMoney
I Made ALL MY test with the SAME Hardware, it's very important

The question is, It is normaln when I use some programs to see 'What the data look like', Program like Aufit or hxcfe, to generate bmp 'diskview'
I don't have the same graphics....

Flux is Flux, don't care is Kryo or Scp
If Data Is present, normaly I must see It.

But...
[Image: aufit_KRYO_BloodMoney_WindowsXP.gif]

and

[Image: aufit_SCP_BloodMoney_WindowsXP.gif]

Look in the circle, left picture...
Maybe is aufit so, let's try with hxcfe

hxcfe_KRYO_BloodMoney_WindowsXP.gif
[Image: hxcfe_KRYO_BloodMoney_WindowsXP.gif]

and

hxcfe_SCP_BloodMoney_WindowsXP.gif
[Image: hxcfe_SCP_BloodMoney_WindowsXP.gif]


How do you explain that?]]> <![CDATA[Suggestion for addition to SCP file format]]> https://www.cbmstuff.com/forum/showthread.php?tid=182 Sun, 10 Aug 2014 11:26:33 -0400 mark_k]]> https://www.cbmstuff.com/forum/showthread.php?tid=182
A suggestion for an addition to the .scp file format: Add a field for an arbitrary comment. You could put that directly after the current last field (timestamp).

My use for that would be to record the drive make/model/serial number used for reading the disk. And maybe some notes about that specific disk (e.g. when/where bought from, whether known to be modified, etc.).

Or perhaps have a general extensible extra data system to allow programs to handle extra data even if they don't understand that specific entry. So you could have a field type followed by byte length then the field data (the comment text in this case). Hmm, that sounds a bit like the IFF specification... Smile


Also a little question about the timestamp field. Is the time supposed to be UTC or the user's local time? And what zero-padding is supposed to be used? In scp_image_specs.txt one example given is "1/05/2014 5:15:21 PM"

I assume the date format is the American type, i.e. day/month/year? Is the day supposed to be not-zero-padded (for days 1-9) but the month field is?

(If I were (re)designing the format, I'd probably have the time field contain a string conforming to ISO 9601...)]]>
A suggestion for an addition to the .scp file format: Add a field for an arbitrary comment. You could put that directly after the current last field (timestamp).

My use for that would be to record the drive make/model/serial number used for reading the disk. And maybe some notes about that specific disk (e.g. when/where bought from, whether known to be modified, etc.).

Or perhaps have a general extensible extra data system to allow programs to handle extra data even if they don't understand that specific entry. So you could have a field type followed by byte length then the field data (the comment text in this case). Hmm, that sounds a bit like the IFF specification... Smile


Also a little question about the timestamp field. Is the time supposed to be UTC or the user's local time? And what zero-padding is supposed to be used? In scp_image_specs.txt one example given is "1/05/2014 5:15:21 PM"

I assume the date format is the American type, i.e. day/month/year? Is the day supposed to be not-zero-padded (for days 1-9) but the month field is?

(If I were (re)designing the format, I'd probably have the time field contain a string conforming to ISO 9601...)]]> <![CDATA[C code for accessing the SCP hardware]]> https://www.cbmstuff.com/forum/showthread.php?tid=115 Tue, 08 Apr 2014 11:20:39 -0400 admin]]> https://www.cbmstuff.com/forum/showthread.php?tid=115
https://github.com/keirf/Disk-Utilities

You should be able to drop in the scp.c, scp_dump.c, and scp.h files into any project and modify them as needed.

Thanks Keir for providing this!]]>
https://github.com/keirf/Disk-Utilities

You should be able to drop in the scp.c, scp_dump.c, and scp.h files into any project and modify them as needed.

Thanks Keir for providing this!]]> <![CDATA[Software Developer's Kit (SDK)]]> https://www.cbmstuff.com/forum/showthread.php?tid=93 Sun, 02 Feb 2014 13:42:32 -0500 admin]]> https://www.cbmstuff.com/forum/showthread.php?tid=93
The SCP PC software is written in Visual Basic 6, so it doesn't take much to use the SCP hardware.

SuperCard Pro Software Developer's Kit]]>
The SCP PC software is written in Visual Basic 6, so it doesn't take much to use the SCP hardware.

SuperCard Pro Software Developer's Kit]]> <![CDATA[Devices/emulators supporting SCP]]> https://www.cbmstuff.com/forum/showthread.php?tid=80 Wed, 08 Jan 2014 10:01:26 -0500 admin]]> https://www.cbmstuff.com/forum/showthread.php?tid=80
Finished support:

HxC - supports read and write of .scp image files. You can use the HxC drive emulator software on a PC or Mac to convert to/from .scp format and a variety of image formats, such as .ipf, .raw, .adf, etc.
E-UAE, FS-UAE, WinUAE - full support for using .scp image files for floppy images.

Work in progress:

FPGA Arcade
Hatari - Atari ST emulation
AII]]>
Finished support:

HxC - supports read and write of .scp image files. You can use the HxC drive emulator software on a PC or Mac to convert to/from .scp format and a variety of image formats, such as .ipf, .raw, .adf, etc.
E-UAE, FS-UAE, WinUAE - full support for using .scp image files for floppy images.

Work in progress:

FPGA Arcade
Hatari - Atari ST emulation
AII]]> <![CDATA[SuperCard Pro Flux Image format (.scp)]]> https://www.cbmstuff.com/forum/showthread.php?tid=16 Fri, 01 Nov 2013 20:54:19 -0400 admin]]> https://www.cbmstuff.com/forum/showthread.php?tid=16
The flux image format consists of a header containing offsets to tracks.  Each track contains a header with the information about the track data, including bit cell count, rotational speed, and offset to the actual flux data.  The image format was made so that corrupted images could be recovered, losing only the track(s) of data where the corruption occurred, not all of the data.  Because offsets are used for the data, it is possible to make very small images where writing is not required (a write-protected disk).  You can also have a large padded space so that the track can change sizes for writing support.

If you have any questions about the data structure, please ask here so that everyone can learn.

We are willing to help emulation authors implement this format.  This format is being implemented into the FPGA Arcade for low-level disk access so it will be possible to use copy protected disk images that will load just like the original!

The updated image file format specification is located here:

https://www.cbmstuff.com/downloads/scp/s..._specs.txt]]>
The flux image format consists of a header containing offsets to tracks.  Each track contains a header with the information about the track data, including bit cell count, rotational speed, and offset to the actual flux data.  The image format was made so that corrupted images could be recovered, losing only the track(s) of data where the corruption occurred, not all of the data.  Because offsets are used for the data, it is possible to make very small images where writing is not required (a write-protected disk).  You can also have a large padded space so that the track can change sizes for writing support.

If you have any questions about the data structure, please ask here so that everyone can learn.

We are willing to help emulation authors implement this format.  This format is being implemented into the FPGA Arcade for low-level disk access so it will be possible to use copy protected disk images that will load just like the original!

The updated image file format specification is located here:

https://www.cbmstuff.com/downloads/scp/s..._specs.txt]]>