Posts: 24
Threads: 2
Joined: Feb 2014
Thanks for the details! That does answer everything I needed to know, and it's useful to know the images are always index-synchronised, even if the content might not be.
I'm adding SCP image support to SAMdisk, which is my disk utility dealing mostly with Amstrad CPC and Spectrum +3 disks. They're not in a challenging format compared to some other systems, but do benefit from the extra detail available in the flux dumps. It already supported KryoFlux and DiscFerret using keirf's flux library, and I've added .scp to that (and will pass my changes back when they're done).
The board API looks quite straight-forward too, so I may look into direct image reading and writing
Posts: 2,853
Threads: 148
Joined: Nov 2013
I did the Amiga copiers the same way, with multi-revs always being index-sync'd. This always gives us a reference. You will find that with the analyzer you can select a flux start and flux end, anywhere inside of the data that was read. If you read 2 revs and just so happens the start of the track is 1/3rd of the way through the first revolution, you could set the start to be there, and then go find the same location in the 2nd revolution and set that as the end. But, it is more accurate if you leave the start as the first byte and just overlap the write to the where you need the end to be. Either method works, but I prefer the later because it guarantees you are writing the data on the exact same index position.
I made the SCP setup as simple as possible so that developers (like yourself) could easily add support for the image file format, as well as the actual hardware.
Let me know if you run into any issues. I can help you with any flux->mfm conversion routines that you might need, but really its pretty simple - bitcell time * 25 = actual number of nanaseconds.
Posts: 2,853
Threads: 148
Joined: Nov 2013
Note, I just changed the .scp image file format to add one extra track (top/bottom), so that tracks 0-83 are now supported. Technically, any number of tracks could be supported. Please make sure that you are following the .scp image file guideline and using offsets for the track data. If you used offsets and did not hard code anything, you won't have to make any changes to your program.
The change made now puts the start of the 1st track data header at 0x000002B0 instead of 0x000002A8, however, you should never rely on this fact. You should be checking the track data header table for the exact offset for each track's data header.
Posts: 24
Threads: 2
Joined: Feb 2014
It looks like I only read up to 83*2 index entries (based on "up to 166 tracks supported"), so I'll need to make a change to use end_track+1.
How soon will you be updating the SCP software with the new limit?
Posts: 2,853
Threads: 148
Joined: Nov 2013
You really should be checking the track data header table for the used tracks. An offset that is null (0x00000000) indicates the track is not used. It is possible to make images with tracks in different locations, as well as skipping tracks. The track data header table (IFF_TDHOFFSET) always starts at offset 0x010 and represents the offset (from the start of the file) to the track data headers for tracks 0-xxx. That is the only thing you should be concerned with. That table of entries could be technically any length, with a minimum guaranteed to be 166 due to the previous format. IFF_THDSTART should not be used as the starting point of the data, since that has moved with the extended track (and will move again in the future).
IFF_END represents the largest track number in the image, but it does not mean that all tracks are present in the image. You could have two tracks (0 and 79) and IFF_START would be 0 and IFF_END would be 158, and all other entries would be null. The track data header and data could be swapped from their expected locations as well, so you need to always rely on the offset to the track data header, and also the track data header's offset to the actual flux data.
I am testing the new limit right now. At some point, I will be adding 200 track support to certain formats, so be aware!
Posts: 2,853
Threads: 148
Joined: Nov 2013
The image file format was just updated to allow including preservation information. This update was suggested by Natalia Portillo. After a few days, we had the details worked out.
Posts: 1
Threads: 0
Joined: Nov 2018
Quote:The updated image file format specification is located here:
https://www.cbmstuff.com/downloads/scp/s..._specs.txt
Hello,
I am trying to get the specification, but is giving me 404/Not Found error.
Please, could you put the file online again ?
Thanks.
Posts: 2,853
Threads: 148
Joined: Nov 2013
I fixed the link in this thread. It's always been available through the DOWNLOADS page the website.
Posts: 6
Threads: 0
Joined: Sep 2019
Hi, everybody!
When I create a .scp file, is there a preferred value to use for the disk type at offset 0x04 when none of the predefined values are appropriate, and I will be using the drive strings in the footer?
When I read a .scp file, should I ignore the disk type byte when drive strings are present?
Posts: 2,853
Threads: 148
Joined: Nov 2013
Yes. You should use:
man_Other | <disk size>
Example:
DiskType = 0x80 | 0x00
This would be "Other" with a disk size of 360K
The disk type is just a reference for displaying something about the disk. The internal structure (tracks/heads) should be used for handling the flux data.