Brume wrote:Depending of what you mean with 'copy disks'.
There are tons of original ST disks we can't copy with Acopy (was the best tool for protected disks). Best way is to test with original games such as Maupiti Island, Space Ace, etc. Since they have their own format, Acopy can't deal with them. Hackers included their own copy-program at the start of each release they made. Also Dragonflight is famous to have one of the best protection ever made on Atari.
But there's also disks we can't copy with Pasti. In that case, one title comes to my mind: Au nom de l'hermine [French game by Coktel Vision]. Strangely, Acopy can copy it on another disk, but STX won't work.
JimDrew wrote:I am not sure what you mean by "the index position". The flux data starts at the beginning of the index, and the end of the flux data is the start of the index again. Each of the 5 entries (one per revolution) contains the index to index duration, number of bit cells captured during that duration, and the offset from the TDH (track data header) to the flux data. In multi-rev dumps, the data is continuous and the table entries will give you the information for each revolution as it occurred.
Keep in mind that the SCP bit cells are 25ns, not 41.6666ns like KryoFlux. It's critical to use 16 bits to represent the flux transitions because weakbits can last thousands of microseconds.
Of course this is true. So if we were in "preservation business" like some other people we know it would be bad. But if we can succeed in creating a working copy (not a perfect copy) from a raw stream file this would be niceGoing from stream to .scp images would be reducing the quality of the image because of the difference in capture resolution. My goal was to replace the stream files with a higher resolution version in a format that was open and easy to use for emulators.
DrCoolZic wrote:Do you own the games mentioned above?
Why would flux transition be aligned with index?
JimDrew wrote:I hope someone will dump this with SCP. I have to work backwards in my mind and encode the data as MFM. This reminds me of most Amiga custom tracks (just one sector per track) and a wiped upper track.
JimDrew wrote:My goal was to replace the stream files with a higher resolution version in a format that was open and easy to use for emulators.
Users browsing this forum: No registered users and 13 guests