SuperCard Pro Flux Image format (.scp)

[admin]

All Amiga, Atari ST, etc. use tracks 0-79 (or higher). The C64 always started at track 1 instead of track 0. It is the only one that I know of that is this way.

Any game that uses protections on track 83 and higher would not work on my A500, A1200, A2000 (both of them), A3000, or A4000. I tested the drives on all of these and the max track is 82 (most of the time, sometimes it hits the end). I have gotten several drives "stuck" by trying to move the heads too far. When this happens, you have to take apart the drive and get access to the worm gear and rotate it manually to unstick the head.

[dlfrsilver]

All Amiga, Atari ST, etc. use tracks 0-79 (or higher). The C64 always started at track 1 instead of track 0. It is the only one that I know of that is this way.

Any game that uses protections on track 83 and higher would not work on my A500, A1200, A2000 (both of them), A3000, or A4000. I tested the drives on all of these and the max track is 82 (most of the time, sometimes it hits the end). I have gotten several drives "stuck" by trying to move the heads too far. When this happens, you have to take apart the drive and get access to the worm gear and rotate it manually to unstick the head.

i'm sorry to hear that your computers cannot reach up to track 83

This means that you would not be able to load and use some softwares.

[LordCrass]

What would that be, 1 or 2 games that use that many tracks? I wouldn't worry about that.

[dlfrsilver]

What would that be, 1 or 2 games that use that many tracks? I wouldn't worry about that.

not more than 10 games that i know of.

[DrCoolZic]

MAy I suggest you add a revision number in your specification it is getting tough to know what version we are looking at

[DrCoolZic]

Can you explain

Code:

BYTE 0x03 contains the track number (0-165).  For single sided disks, tracks 0-41 (48TPI)
or 0-83 (96TPI) are used.  For double-sided disks, the actual track number is this value
divided by 2.  The remainder (0 or 1) is the head.  0 represents the bottom head and
1 represents the top head.  For example, 0x0B would be 11/2 = track 5, head 1 (top).
Likewise, 0x50 would be 80/2 = track 40, head 0 (bottom).

Does not make sense to me.
I am now performing more check i thougth it was track /2 but here what i amgetting ?
track 0 => 0
track 1 => 0
Track 2 => 1
Track 3 => 2
Track 4 => 2
track 5 => 2
track 6 => 3
track 7 =>4 ???
So I guess we just have to ignore and use the index number?
Is it suppose to be useful?
Or at least it could be equal to track index so it can be used to check we are on the right track?

[admin]

Hmm... that's not correct! It should be:

track 0, head 0 = 0
track 0, head 1 = 1
track 1, head 0 = 2
track 1, head 1 = 3
track 2, head 0 = 4
track 2, head 1 = 5
...etc. etc. this is for any disk except C64/128, where the head 1 position will be 1/2 tracks.

The number SHOULD match the index, and I thought I was checking it in the file to make sure it matched and reported an error when it didn't. I will have to look at that.

Maybe this is the cause of the issue you saw earlier.

I will mark the version for the SCP image spec ("final")

[admin]

I added some more details to the image file spec today.

[obo]

Can you please clarify how disks with the final sector overhanging into the index position would be handled in blind and non-blind modes, with respect to start position in the .scp track data?

If I understood things correctly, the blind mode would start strictly at the index position and the data field for the final sector should be truncated at the start of the index for the one-and-only stored revolution. Is that correct?

For the non-blind mode, I've seen some mentions of the start position being completely random, and others saying it sniffs the track data to determine a more suitable start position . If it's the latter, is the data from the reading point up to the selected start position discarded, or kept in the image?

I've only done some basic tests with some simple 10-sector MFM disks, which don't currently overhang the index. I'm seeing pretty much the same index-start position in the .scp images in both cases, but I want to make sure I support what might be stored. Almost everything will be index-synchronised, but the overhang is likely to crop up.

Really impressed by the hardware and software so far

[admin]

For blind mode, it's a simple index to index dump of the tracks. Most everything sold commercially was produced on TRACE and similar machines using an index to index copy. So, most everything works with blind mode.

For cases where the index was not used to queue the start of the tracks, the non-blind mode must be used. That simply spools in the number of revolutions you tell it to, with 2 revolutions being the default. All revolutions dumped always start/end with the index. When you go to write the track data back, the write routine knows that there is 2 or more revolutions so it then goes and finds the first write splice that occurs starting after the start of the 2nd revolution. So, the entire 1st revolution is written followed by the 2nd revolution (contiguously) up to where the write splice is located. That places the write splice in the same location as the original image.

So, Simon.... what are you working on? If you have any questions, please let me know and I would be happy to help out.