Page 3 of 3

Re: Cassablanca Classic floppies

Posted: Tue Feb 13, 2018 6:31 pm
by ZrX
SimonV wrote:
Tue Feb 13, 2018 3:23 pm
ZrX wrote:
Mon Feb 12, 2018 8:47 pm
Could you post what's in the casablanca/save/HDSernum file on your HDD?
Is that something I can see from booting the Casablanca or ?
The file likely contains the serial number of the hardware itself, collected from somewhere.

Re: Cassablanca Classic floppies

Posted: Thu Feb 15, 2018 6:23 pm
by SimonV
I'll see what I can find. In the meantime I bought another Casablanca that's on it's way so I have more disks to experiment with. And I also did archive the others I have last week, here's the link. ...

Re: Cassablanca Classic floppies

Posted: Wed Mar 07, 2018 1:56 pm
by IFW
Just checked Spicerack disk 1; looks like old-school PC protection, just on HD disk :)
However, the disk looks copied rather than duplicated...

Re: Cassablanca Classic floppies

Posted: Wed Mar 07, 2018 2:00 pm
by IFW
I'd recommend redumping the disks using -z3 -i4 as guide parameters, so bad tracks would get retried.
If you decode spicerack 2 it has read errors on track 42
The last 512 bytes sector on each track seems to be just protection, but getting the 10x1024 right is required to dump all the data correctly, so just use -z3 -i4.
dtc -f<casdisk> -i -z3 -i4 -l8

Re: Cassablanca Classic floppies

Posted: Mon Mar 12, 2018 7:11 pm
by ZrX
We spent a bit of time during our weekend meet analysing the Casablanca disks (we also had a machine to test with).

Many of the dumps have tracks that DTC simply reports unformatted, but can be decoded by changing the -v rpm value. Tho while one value makes some tracks readable, it renders others unformatted in turn.

Each track is 11 x 1024 bytes, where the last sector is altered to the size of 512 in the sector header.

The protection uses the last sector on track 00.0 to store a serial number, as a 512 byte sector with correct checksum, of the machine it was first booted on and locks it to be used on that machine only. On first boot the sector data must be 1024 bytes long, but with wrong checksum when read as 512 bytes. The sector is originally filled with 1024 x K (0x4B).

The last sector on track 01.0 is also filled with 1024 x K (0x4B), but then the first 512 bytes on that track must always be 0x00 with the correct checksum of the 512 bytes, or the disk gets rejected.

Other than these two tracks, the last sector on all the other tracks of side 0 are filled with 1024 x K (0x4B), and on side 1 filled with 1024 x D (0x44) (the initials of the author of the protection).

Re: Cassablanca Classic floppies

Posted: Sat Apr 07, 2018 5:22 pm
by ZrX
I've been able to study this system for a while and few observations about the copyprotection:

System contains two ROMs, standard Amiga 3.1 kickstart ROM along with another ROM that contains system specific files. Both ROMs are using what's known from many Amiga accelerators a maprom feature, where the ROMs are copied to RAM and then mapped to appear as ROMs at the usual address.

The protection contains three parts, a Microchip PIC that holds the system serial number (along with powersupply control, a clock and some configuration parameters for the hardware included in the machine), a custom disk resource module that reads and writes the custom sectors hiding the protection, and a library module that interacts between the Microchip PIC and the disk resource module.

When powered on the PIC is queried for the version, serial# and configuration data which are then stored in memory, but can also be queried manually by software. The disk resource module then checks the floppy, if booted from one.

Along with the protection in the system ROM, the same resource modules and libraries are also included with possibly every disk available for the system, and are copied to the hard drive during installation and then replace the ones mapped in RAM.

So if one would patch the ROM to skip the protection a disk for another system could be booted and installed on first boot, but the files from that disk would then replace the routines in ROM and the protection would be active again, unless the update file is removed or patched from each disk, or the last version that was released is patched and installed into the ROM itself.