PureBasic Forums - English

It is curious. And i like the idea.
http://www.caps-project.org/

See also www.lemonamiga.com for good Amiga info.

PB, but CAPS try to maintain the original physical data storage as it was.
This means that, if you own the original Turrican 2.5''FD, CAPS try to preserve it intact: with the protection.
So then, they have tools to copy it as is.
AMIGA computers haven't a FDD controller. PCs have it. This implicates that with amiga there are no limitation for strange formats for FD. With an AMIGA you can control the heads movements, motor speed, etc, at any moment using all by software. With PCs, you can not do this; all is restricted to the FDD controller specifications.

> CAPS try to maintain the original physical data storage as it was

I still don't understand -- the ADF file format (used in Amiga emulators) is an
an Amiga disk floppy image, no matter which format the floppy used, so what's
the difference? ADFs preserve the storage perfectly...

AMIGA computers haven't a FDD controller. PCs have it. This implicates that with amiga there are no limitation for strange formats for FD. With an AMIGA you can control the heads movements, motor speed, etc, at any moment using all by software. With PCs, you can not do this; all is restricted to the FDD controller specifications.

You could not control the drive speed. The only way you could change the bit size on an Amiga disk was with changing the system clock speed, this was easily done via the video connector.
Most commerial games had restrictions with the disk formats because of the duplication equipment not being sophisticated enough. I personally liked creating my protected disks with smaller bit sizes and random patches. The random patches were made by making both clock and data zero for a while. Both of these protection methods were also easy to program for the Trace duplicator script language - we had to use Trace duplicators because they were in all the cheap duplication places.

DoubleDutch wrote:You could not control the drive speed.

I did it using only software.
Lots of amiga original floppy disks had their protection using this technic.
You can change the caps-lock led light intensity too, like if it was an analogic light. I did it using software only too.

I read this: http://www.bluemsx.com/blueforum/viewtopic.php?t=427

How did you control the drive speed in software, there was no register to control drive speed. ???

The only thing you could do would be to turn the drive motor on or off (bit 7 of $BFDx00). If you toggled this then from drive to drive this would give different results. On my drive at least the write would not be enabled until the drive was ready and up to speed.

The other thing is that even if this did work, you could only write longer bits to the disk, not shorter.

If you need to know some more about restrictions of the Amiga disk formats look at: http://www.caps-project.org/articles.php?id=g_bitcell

actually, caps is doing it wrong (in my humble opinion etc. etc. etc.)

what use is preserving the original format if it isn't playable? one day we will be running out of hardware, and on that day whatever is preserved has to work on an emulator

All the emulator need do is emulate the functions of the floppy drive. If the protection information is kept as it should then the original programs protection routines should be fooled. This way you can run the original bin dump of the disk, rather than a cracked copy. The problem with running a cracked copy is that some of the time they are not cracked properly and so they do not (for example) work at the second or third protection check.

PB wrote:I still don't understand -- the ADF file format (used in Amiga emulators) is an an Amiga disk floppy image, no matter which format the floppy used, so what's the difference? ADFs preserve the storage perfectly...

If ADF could store any disk format, you could use it to store (for example) PC disks, Atari disks, and copy protected disks. As it is, you can't.

ADF only stores track data stored by one format - the AmigaDOS format, whereas IPF's store disk data at their signal level (the "lowest" physical level). Disk images are generally one of the following:

3) Track level (e.g. ADF, and almost all other disk formats)
2) Encoding level (e.g. MFM-warped images)
1) Signal level (e.g. IPF)

Where each higher level (going up numerically above) is built upon assumptions of the structure of the disk in the lower level.

- Track-level formats store just track data, therefore if you saved a file containing "HELLO" to a disk them imaged it as ADF, you would be able to see that text in the disk file when looking at it with a text-editor.
- At the encoding level, you would not since the binary sequence is "encoded" as a series of 0's and 1's to make storing data on a floppy disk more reliable. Trying to put it simply: For MFM (a "self-clocking" encoding), this means combining the binary sequence with escape codes to make sure the read "knows where it is" when reading back the data.
- At the signal-level, the encoding is irrelevent (you don't care about it, since you are looking at what makes up the encoded data in the first place). You store (very basically) each signal (high/low) along with the time between adjacent signals.

It is all very complicated. Why? Basically because you are storing digital data on an analogue medium.

As well as that, CAPS describes what every little piece of data is for, including checkum information to ensure data integrity, and look to see if the disk have been modified after the original mastering - which becomes possible when you work at the signal level.

blueznl wrote:actually, caps is doing it wrong (in my humble opinion etc. etc. etc.)

what use is preserving the original format if it isn't playable? one day we will be running out of hardware, and on that day whatever is preserved has to work on an emulator

They certainly *are* playable. WinUAE has supported IPF images for about two years, and WinFellow support is apparently in the works. This is what the support library is for on the download page.

WinUAE can actually play every single IPF image preserved so far. If it can't play one, then it gets fixed so it can.

Does that mean they are doing it right?

> If ADF could store any disk format, you could use it to store (for example)
> PC disks, Atari disks, and copy protected disks. As it is, you can't.

I said it's an Amiga disk format, not any disk format. In other words,
you can hand me any bona fide Amiga floppy disk and I can create an
ADF disk image file of it, which can be used with any Amiga emulator.
The different formats I referred to are AmigaDOS, DMS, and so on;
all of which were used by the Amiga.

The ADF format will not cope with the protection I used. As well as long tracks (using a smaller bit size) I made both clock and data zero for a section of the track, the effect of this was a kind of "randomness" to the data in that particular section of the track.
This kind of protection was quite common and the protection check quite easy to do...

If the data is not random, then its a copy.
If it is random then its real!!!

The long tracks could NOT be copied using standard Amiga hardware, it would ether have to be copied using extra hardware (eg Cyclone or modified system clock) or it would have to be cracked.

btw How does ADF cope with GCR encoded tracks rather than MFM?

-Anthony

PB wrote: I said it's an Amiga disk format, not any disk format. In other words,
you can hand me any bona fide Amiga floppy disk and I can create an
ADF disk image file of it, which can be used with any Amiga emulator.
The different formats I referred to are AmigaDOS, DMS, and so on;
all of which were used by the Amiga.

Ah... But there are *hundreds* of disk formats used on bona-fide Amiga floppy disks. That is, floppy disks that were created solely to be used on an Amiga. Even the Atari ST / IBM PC disk format was used on Amiga game disks (as protection), and hence why I mentioned them.

Unfortunately, the only game disks you will be able to make ADF images of are games with no copy protection, as explained above. ADF is fine for cracks, or your own personal data. But it is not much use for original commercial games.

DoubleDutch wrote:The ADF format will not cope with the protection I used. As well as long tracks (using a smaller bit size) I made both clock and data zero for a section of the track, the effect of this was a kind of "randomness" to the data in that particular section of the track.
This kind of protection was quite common and the protection check quite easy to do...

If the data is not random, then its a copy.
If it is random then its real!!!

I notice you mentioned Trace machines, I take it you created some games for the Amiga then and this wasn't a hobby thing? Nice

You might be interested to know that the IPF format also supports this random effect.

The long tracks could NOT be copied using standard Amiga hardware, it would ether have to be copied using extra hardware (eg Cyclone or modified system clock) or it would have to be cracked.

Agreed. At least, not copied as-is. If the long track is done by just adjusting the gap size (rather than actually using the space with real data, like Dragon's Lair for example) and the game doesn't check that the long track is actually present (quite common it seems, probably since it could be done simply at duplication), then you could copy them by simply reducing the gap again. Of course, this is not going to be done by the vast amount of people wanting to copy the game, especially since it is no guarantee anyway (if there is a check for it somewhere in the game). Not sure you could call this cracking or not, since no game code is changed... I guess you probably could.

btw How does ADF cope with GCR encoded tracks rather than MFM?

It doesn't. For a start ADF tools use trackdisk.device and AFAIR that does not support reading GCR tracks. GCR-encoded disks seem to be extreamely rare on the Amiga (but seen on at least one game). Though that is surprising really, I would have thought there would be used more often as protection.... Perhaps there were problems describing them in Freeform...