Posts: 17
Threads: 4
Joined: Sep 2015
With all other cases being functional (a system that can successfully read a disk to an .scp file and write a working 'fresh' copy from the .scp file to a blank disk), I've run in to a problem with a 'newly generated' .scp that I'm hoping to have you take a look at, Jim. ;-)
We've been dumping original Atari media for maximum 'preservation' and in turn converting the .scp's in to .atx images for use in emulators. a8rawconv can take a .atx image and output a new .scp file, which seems like an interesting way to 're-master' old copy protected disks. When I create a new .scp file using that method however, Disk Archiver fails to write it with a "USB Timeout Error!" at track 16. I assume it's a problem with the newly generated .scp (the setup works fine with .scp file imaged from original disks and written back out, for example).
Any chance you could take a look at this and see what it might be about a8rawconv's .scp output that breaks Disk Archiver so we might try to fix it?
https://dl.dropboxusercontent.com/u/1305...libaba.scp
Thanks,
-Clay
Posts: 2,784
Threads: 144
Joined: Nov 2013
Sure, I will take a look at it.
Posts: 2,784
Threads: 144
Joined: Nov 2013
OK, the problem is that Alibaba.scp does not have any information for track 16! The table entry is there, and the header has 'TRK' and the proper track, but there is no data for the track after that!
Look at offset $651010 using HxD or some type of similar hex editor. You will see the header for track 16 and the pointer to the table of entries for that track is $0065B9AB, which is the same used in ALL of the tracks (not possible). The index time is $0000000 (not possible), and the length is $00000040. So, there are a LOT of things wrong with this SCP image!
Once the format gets worked out, it still won't produce a working disk because the data is not flux. I use the characteristics of flux to determine the location of the write splice.
The best course of action for making this work to generate a SCP image that can be written out is to generate a single revolution, using INDEX mode type (instead of SPLICE), and start each track with the first sector and place the gap at the end of the track. This means a single revolution required per track to make a working disk, so the file size will be very small. Also, since the flux data is either 0080 or 0100, it will compress with .7zip to under 30K in total size! That 16MB sample image compressed to just 65,126 bytes!
Posts: 17
Threads: 4
Joined: Sep 2015
(01-01-2016, 10:07 AM)admin Wrote: OK, the problem is that Alibaba.scp does not have any information for track 16! The table entry is there, and the header has 'TRK' and the proper track, but there is no data for the track after that!
Look at offset $651010 using HxD or some type of similar hex editor. You will see the header for track 16 and the pointer to the table of entries for that track is $0065B9AB, which is the same used in ALL of the tracks (not possible). The index time is $0000000 (not possible), and the length is $00000040. So, there are a LOT of things wrong with this SCP image!
Once the format gets worked out, it still won't produce a working disk because the data is not flux. I use the characteristics of flux to determine the location of the write splice.
The best course of action for making this work to generate a SCP image that can be written out is to generate a single revolution, using INDEX mode type (instead of SPLICE), and start each track with the first sector and place the gap at the end of the track. This means a single revolution required per track to make a working disk, so the file size will be very small. Also, since the flux data is either 0080 or 0100, it will compress with .7zip to under 30K in total size! That 16MB sample image compressed to just 65,126 bytes!
Soooo, basically it's a train-wreck. ;-) Thanks for the detailed response. The index aligned track dump makes sense to me. Are the SCP commands/API documented anywhere? (a8rawconv has some functions implemented, but I don't know if it's 'complete'-- for example there's no mention of index pulse detection anywhere)
Thanks,
-Clay
Posts: 2,784
Threads: 144
Joined: Nov 2013
Yes, there is complete developer info in the DOWNLOADS area of my website.
Yeah... it's a bit of a mess... not as bad as my first attempts though! 
I am sure that some pointers are not being updated or something so that they point to the correct data for each track. The data appears to be there (except for track 16), so I don't think it would take much work.
Are you working with Phaeron on this? Is there a public thread? I can certainly help out with the format stuff, but I am not C programmer so I won't be much help there. However, there is complete working example C code for controlling the board, encoding/decoding .scp format, etc. already available from Keirf's disk utilities:
https://github.com/keirf/Disk-Utilities/tree/master/scp
Posts: 17
Threads: 4
Joined: Sep 2015
(01-01-2016, 01:50 PM)admin Wrote: Yes, there is complete developer info in the DOWNLOADS area of my website.
Yeah... it's a bit of a mess... not as bad as my first attempts though!
I am sure that some pointers are not being updated or something so that they point to the correct data for each track. The data appears to be there (except for track 16), so I don't think it would take much work.
Are you working with Phaeron on this? Is there a public thread? I can certainly help out with the format stuff, but I am not C programmer so I won't be much help there. However, there is complete working example C code for controlling the board, encoding/decoding .scp format, etc. already available from Keirf's disk utilities:
https://github.com/keirf/Disk-Utilities/tree/master/scp
I haven't talked to Phaeron-- I'm just debating if I should jump in and try to fix it. I'm an embedded systems guy though, so I would need to figure out which machines I have around even still have a Windows C compiler installed. Building with an ARM or MIPS target isn't going to be of much help. ;-)
Thanks for the pointer, even if I don't do anything in a8rawconv I'd like to understand the implementation just for my own edification.
Posts: 2,784
Threads: 144
Joined: Nov 2013
The control of the board is simple. You can do it through the USB port using the FTDI .dll or just through the COM port for the USB device. You can also use one of the two serial ports on the SuperCard Pro board too!
The commands are very simple, sending just a few bytes to make functions happen.
|
