Speedlock protection not original disc ?

[Johnny Olsen]

Speedlock protection Donkey Kong.
Version D7 - 1986 - AAAA

Versus "Oddjob old version" disc utility.


I don't think the original disc version found on the internet is original,
Because the protection system "first time you run it" will write to the disc.


My guess is that the original disc will look like this

Track 1 sector 79,81,82,83,84,85,86,87,88

all sector's 512 X A6 byte.


Oddjob's Disclone can make a backup of this disc.


After running the game for the first time we will see

Track 1 sector 79,81,82,83,84,85,86,87,88

Track 1 Sector's 81 to 88 format byte has change from A6 to A7 and the

sector 79 will only be 128 x A7 byte long.


Oddjob's Disclone can't make a backup of this disc.



To show this Insert My Donkey Kong version in Winape then

press shift+CTRL+F1 - Fane Sector - Track 1 79,81,82,83,84,85,86,87,88

Sector 79 = 512 X A6 byte

Now run "kong"

While Donkey Kong is running go back to the Sector Editor and look at Sector 79

Now it had format sector 79 to a 128 byte sector and change format byte from A6 to A7

and all Sector's 81,82,83,84,85,86,87,88 has changed to format byte A7.



If  you will save the change to the disc you have to use WinApe version 2-0 Alpha 15

or WinCPC.

For some reason winape can't save directly to the disc since version 2.0 Alpha 15 - Richard !!!

Both Sugarbox and JavaCPC_Desktop_2.9 fail to save to dsk.



Normally I use to have write protect tab on but

this protection force me to slide it off.


If the wríte protect tab on a message will show up.

"This disc will not run if WRITE-PROTECT
TAB is ON: Please slide tab to cover the
write-protect hole, then press any key
to re-try load:"

With the write protect tab off the program will run normaly.


If we now make a copy using Oddjob's Disclone. 

and run it with the write protect tab off you will see this message


"**** THIS DISC IS AN ILLEGAL COPY!! ****"

And the disc will be destroyed.




Loader:
------

To have a look at the loader use WinApe.

Open debugger

press F7 - CTRL G - &a598 - F5

close debugger

run"kong


The speedlock loader gaining access directly to the disc rom.


    DISC ROM CALL

0 (1) Set Message     &C033    &CA72
1 (2) Setup Disc    &C036    &C60D
2 (3) Select Format    &C039    &C581
3 (4) Read Sector    &C03C    &c666
4 (5) Write Sector     &C03F    &C64E
5 (6) Format Track    &C042    &C652
6 (7) Move Track    &c045    &C763
7 (8 ) Get Dr Status    &C048    &C630
8 (9) Set retry Count    &C04B    &C603


See SOft 158A dd1 firmware

[Lone]

Hello,


Really interesting analysis. This offer me the opportunity to fix a bug in DSK saving process of Sugarbox.
I confess I never use it - I prefer saving to HFE or IPF when I need to, as it's a lot more reliable.




Anyway, all this make sense - I think that people at CPC-Power or CPCrulez would enjoy this kind of information.

[Johnny Olsen]

@Lone :

How do you make IPF ?
Do you have the original Amstrad disk and use Kryoflux to dump the disk?

And how do you make HFE ?

What do you mean with "more reliable" ?

I think it is only emulations.

I am aware that DSK can not keep all the information as an original disk, but if you can play a game from start to finish, then what is the problem ?

[Ast]

He just tries to do the best fdc emulation... When you know how it works, fdc can't keep all his secret.

[robcfg]

Hej @Johnny Olsen ,


You can dump amstrad disks with HxC floppy emulator software or with KryoFlux, and the with the HXC Floppy Emulator software export the raw dump to HFE files.

[Kris]

Today, the most reliable tool is sugarconvdsk from Lone; it allows you to transfer from a format to another one


http://www.cpcwiki.eu/forum/applications/sugarconvdsk/

[robcfg]

So does the HxC Floppy Emulator software.


Just out of curiosity, why would be sugarconvdsk the most reliable tool out there?

[Johnny Olsen]

Today, the most reliable tool is sugarconvdsk from Lone; it allows you to transfer from a format to another one

Yes maybe, but it makes no sense to transfer from dsk to IPF.

[Lone]

Hello,


I'll try to give you some answers :


- I say that IPF and HFE are more reliable, from the point of view of Sugarbox. It's paradigm is to recreate a complete MFM track when reading any dump (from dsk, hfe and IPF). Saving the track to IPF or HFE is almost straightforward (as they give a MFM track description). Saving to dsk is far more difficult, as you should describe it from a sector point of view. As Samdisk does it perfectly, I didn't tried to make it perfect.


- IPF format is described (sources are also available), so it's no longe a secret. The advantage of IPF is that it can describe a complete track, with any size (HFE is limited to multiple of 16 sizes) and with weak bits. Another advantage is that it can be used to rebuild a disk, with kryoflux.


-  IPF and HFE can be used when saving a disk with Sugarbox (or directly converted with SugarConvDsk).


To the next question, "why would be sugarconvdsk the most reliable tool out there", I'll answer this : It's not the case, always.


If you speak about amstrad disk, I have a good algorithm to handle a lot of .dsk file out there. All are converted to MFM Track (with other informations, like weak bits, optionnal bits (as number of bit read are not always the same in a weak area)). Then, it make an exact copy of this track to IPF dump.


So : It's not a good tool to use to create dsk file. Prefer Samdisk !
It's good if you want to create IPF or HFE, especially from dsk files.

[Johnny Olsen]

It's good if you want to create IPF or HFE, especially from dsk files.

As I understand it dsk is bad format and IPF is a good format, why create IPF from dsk ?
Or are you speaking about create IPF from samdisk dsk

If Samdisk can create an exact copy of an Amstrad disc why using IPF ?

[Lone]

As I understand it dsk is bad format and IPF is a good format, why create IPF from dsk ?
Or are you speaking about create IPF from samdisk dsk

If Samdisk can create an exact copy of an Amstrad disc why using IPF ?

Dsk is not a bad format. It's just that it is sometime difficult to describe protected contents with it. And it's not always straightforward to write back a disk.
Anyway, almost all amstrad dumps are in dsk format (and every emulator are using it, often exclusively).


IPF is superior, as it's far more easy to write something in this format (without any restriction based on any protection scheme). In fact, converting any MFM track to IPF can be automated - I have a test that convert any disk format, and check if track is exactly the same, and I have converted and checked with success my whole dump directory (about 4000 dumps in various format)


Not every emulator can read it : Sugarbox, an old caprice32 version, Caprice forever, and another one that is not already public (I don't know if I can speak about it - what a teasing !).
You will notice that the 3 main used emulator (Winape, JavaCPC and Arnold) are not supporting it.


The probleme is that IPF contents are really confidential, and the only public tools available to produce this format for amstrad are from me (as far as i know).


HFE is almost as good as IPF, but its 2 main default (don't support weak sectors, and the size problem) make it often impossible to use for protected content.


I think it's a bit more clear !

[Johnny Olsen]

Yes - thank you Lone

[AMSDOS]

Sorry if I'm off-topic, I was just wondering where Richard Wilson's earlier DSC/HDR files from RWCPC/Winape fits in with these other files. Once I took a DSK image of Silkworm from ADATE which had some sort of protection, but was able to use Xexor to write to DSC/HDR format.

[dlfrsilver]

I guess it's my turn to enlight about the speedlock AAAA.


Basically, you must understand that the Ocean speedlock disk were all duplicated in a plant.


Next, a trace machine has a precision for writing intersector gaps that a CPC computer will never have.


So if Johnny's theory was right, when i make IPFs for the collectors who are sending me their disks or dumps, the CTA analyser would report the protection track as modified.


This for a simple reason : When a CPC writes on a disk, the intersector gap size are variable in size. With a trace machine they are fixed.


example :


Sector 129
gap size 34
Sector 130
gap size 34
[/size]Sector 131
[/size]gap size 34
[/size]Sector 132
[/size]gap size 34
[/size]Sector 133
[/size]gap size 34
[/size]SEctor 134
[/size]gap size 34
[/size]Sector 135
[/size]gap size 34
[/size]Sector 136
[/size]gap size 34
[/size]Sector 121
[/size]gap size 34
[/size]
Here the ID field gap size is 34 bytes on Road Runner (it uses a speedlock AAAA)


Next,


the Data Field, each sector is 512 bytes, with a GAP size of 94 bytes, and the protected sector is 865 bytes in gap size, and it has a
DCE (Data Error Checksum).


The track is 6290 bytes long.


Basically, if a CPC was modifying the track,


You would have instead of 34 bytes of ID field variable gap sizes, like 34,36,35,36,34,35 in gap size. This would then show that the CPC has written on the track.


Same applies to the data field.


In the end the real way this specific Speedlock AAAA protection was made, is to use a protected track that a standard CPC drive and controler cannot replicate.


The write enable is requested on the disk when launching because the protection checks itself in order to see if the disk is a copy or the original.


If it detects the disk is a copy, the protection will then erased the whole disk. That's the purpose of the "Please deprotect the disk to allowing the program to run".


The only failure on this protection, is that if your disk becomes erroneous or is in bad shape, the day the protection fails, it will erase your original disk.


This has happened to me in the past on my CPC, i had an ocean game using this protection which has become faulty with the year, and one day, the protection was no more passing correctly, and the whole content has been wiped out by the protection.


There is a disk formatting routine inside it, made to trash the disk.

[Executioner]

For some reason winape can't save directly to the disc since version 2.0 Alpha 15 - Richard !!!

It should, and I have tested it numerous times with various disc images. You don't have "Enable Temporary Writes" checked by any chance? This causes WinAPE to write only to the in-memory version of the disc image and not write the changes back to the original disc image. If not, perhaps it's not registering a format command as a write for some reason.

HFE and IPF support are planned for a future version, they won't be in the next release.

[Johnny Olsen]

perhaps it's not registering a format command as a write for some reason.

exactly.
Enable -  Prompt to save Changes in WinApe.
Try load my "Donkey kong maybe original.zip" file.
Look at track 1 sector 79 now try run "kong"
look in the same sector again and see the difference
Now remove the disc -
nothing is written to the disk.

If you do it all again, but before you remove the disk changes the Attributes, WinApe will recognize the change and save to the disk.