JimDrew wrote:I will go out on a limb and say yes. When I was selling Supercard Ami for the Amiga, we sold a LOT of them to the Atari ST clubs because they used an Amiga 500 with that product to copy everything for the ST. There has never been an Amiga or ST disk I have heard about that did not copy with that device... but there were tens of thousands of disks released, so anything is possible.
Where can I get an original of Crown of Creation 3D? Is this program known to be particularly difficult (or impossible) to copy? Like I said, I know very little about the ST, so please bare with me while I get up to speed. If you guys know of any programs that are "impossible" to copy, please let me know the names and I will try to buy them (usually from eBay). I can also arrange for any disks sent to me to be returned with a backup and SuperCard Pro image file.
DrCoolZic wrote:Yes happy New Year to all
I know that you do not like too much the STX format!
This format is far from being perfect for historical reasons (new protections discovered after initial releases) but it has the advantage of being able to store information for all known protections I can think of. We could redesign a cleaner format but what for? There are thousands and thousands of games already saved using this format. I know that Nicolas is working on providing support in Hatari so this format will be supported by all major Atari emulators.
IPF is a strange “beast”. The format is design to be able to support any kind of protections but in fact the protections are not “defined” per se in the file format but in the accompanying library. So for example you will not find any timing information in the file but this timing information is coded in the library. The idea behind IPF is that there is a limited number of protections used by reproduction machines (like the Trace machine) and you just need to find out and describe all these protections. The problem is that when you want to add a new protection like the Dungeon Master weak bits you have to modify the IPF library to handle this new protection. Creating IPF file is tough because you need to know all the protections supported by the current lib and with this information you have to select the right one based on what you detect in the source… But the advantage is that you should get a “perfect image”.
The IPF format is described in http://info-coach.fr/atari/software/pro ... tation.pdf and information about the IPF/CAPS library can be found in http://info-coach.fr/atari/software/projects/IPF.php
STX has never been designed to be able to write FD but only for emulation. Product like SCP or the old Discovery Cartridge are designed for that. Also it is not clear that in future you want to create Floppy Disks? If SCP provides floppy drive emulation in future (like HxC) it seems a better route?
I am not convinced that adding CRC/Checksum is very useful. This idea come from the past when files where transmitted over modems… in the last decades I have never seen a file to get corrupted? I do not know if the Pasti library would care if extra bytes were added at the end of the file but it is easy to experiment.
Can you summarize the problem with Microprose Golf? What do you mean by STX does not emulate correctly floppy rotation? Is it a problem with the pasti library or with the STX format.
I need to understand why some programs can’t be imaged with Pasti: is it a problem with the imager or a problem with the format?
JimDrew wrote:The problem with .STX, .IPF, etc. is that they interpret the contents of the disk, and so you are limited only to what the libraries 'know', which is actually very little compared to the number of different types of copy protections released. If you want full 100% compatible read/write, the easiest method is certainly flux level. Yes, the files are large, but you can trim most everything to a single revolution per track, and really we don't care about file size anymore - maybe 10 years ago we did, but hard drive space and RAM is not an issue anymore. You could always keep the images compressed and decompress them when the disk is 'mounted'
The FPGA Arcade and a few other emulation projects are implementing .scp flux image files. The data is just clocked in like the real floppy. The WD1772 emulation would just fetch the flux transitions and convert them to clock and data bits. This would let you have 100% compatibility with any type of copy protection. I can't imagine it be that much work to change your existing WD1772 emulations to support flux directly. There is already a bunch of work done to parse through files, build tables, etc. With the .scp file format, you just need a track number to look up the offset to the track data header, which gives you info about the rotation speed, track length, and offset to the flux. From there you either copy the entire track to a circular buffer or fetch the track data from the file directly.
DrCoolZic wrote:Now let say that you discover a new protection like the macrodos protection that uses four segments with different cell timing. You will need to define a new type to store in the file but more importantly you will need to write the code in the library that will return the right timing values for this new protection and this can ONLY be done by SPS.
npomarede wrote:DrCoolZic wrote:Now let say that you discover a new protection like the macrodos protection that uses four segments with different cell timing. You will need to define a new type to store in the file but more importantly you will need to write the code in the library that will return the right timing values for this new protection and this can ONLY be done by SPS.
Macrodos is already supported, I tested Hatari with a partial dump of Damocles that SPS sent me some times ago, and the protection passed succesfully. That's why I had the feeling capslibrary is pretty much complete right now, and could certainly already support a sector split into 16 chunks of bytes at different speeds ? Do you mean the IPF format doesn't allow to define a sector as a variable list of blocks of bytes, each one with its own duration ?
Of course new protection schemes for Atari ST not yet imaged with KF could require to extend the IPF format later it current IPF is limited.
Users browsing this forum: No registered users and 3 guests