| Author: | Markus Benko (registered user: 16 posts ) |
|---|---|---|
| Date: | Tue, Jul 31st, 2012 @ 19:00 ( . ) |
Today I've dumped Quiwi with KryoFlux and track 1 sector 20 is clearly partially written at 4.0us instead of 3.25us (speed zone 0 instead of 3 if I remember correctly), which is obviously not a mastering error. And it actually *is* a copy protection: The game is a Trivial Pursuit clone, so everybody not speaking German now has an idea what's the game about. As in Trivial Pursuit, questions have to be answered. The game is controlled with joystick in port 1. Just enter anything as player's name and press F1. When "KNOPF" appears in the upper left corner, press fire button in port 1 to see the first question. When copy protection check failed, all questions (including the first) will be "Ist dies eine Raubkopie?" -> fire -> correct answer is "Ja!!!". Translation: Q "Is this an illegal copy?" A "Yes!!!" - great sense of humour. :) I remembered that older versions of VICE passed bytes from G64 files regardless of selected read density, so I tried to decode that sector properly (from flux timings to GCR, many manual corrections due to weak data in that 4.0us area) and succeeded. After that I modified the DTC-generated G64 file to hold my decoded track 1 and gave it a try in WinVICE 2.2 - and it works! Tried it in CCS64 3.8 and it worked, too. So does CCS64 3.8 also ignore selected read density? Maybe. The more advanced the disk emulation of an emulator is, the smaller is the chance the protection will pass, i.e. soon there will be no emulator left actually letting the protection pass. So in the end Quiwi is another disk which will need working density / speed zone map support in emulators to work properly and work on purpose from a G64 image. Unluckily the G64 format only supports four different cell widths in that map which is sufficient for Quiwi but will probably fail for some other case. It's time for G64v2. Btw: Pete, you've got an email. |
 | Author: | JimDrew (registered user: 23 posts ) |
|---|---|---|
| Date: | Fri, Aug 17th, 2012 @ 17:01 ( . ) |
I agree, a new format (G64v2 or whatever you want to call it) needs to be developed. Something flexible enough to maintain small images for generic data, but also can be expanded to provide detailed data for the density information (every byte). Weak bits can be handled by writing a 00 in place of the changing data. I think all images should be dumped starting from the index, as 99.99% of everything ever duplicated on commercial machines used the index mark for the start of the track, and later protections used the alignment for protection too. |
 | Author: | Nate (guest: search) |
|---|---|---|
| Date: | Sun, Aug 19th, 2012 @ 18:12 ( . ) |
On the subject of track alignment, that can be supported in G64 by reserving a new header bit. The bit can mean that "tracks are aligned in the image, keep this arrangement". If the bit was not set, the emulator would be free to align on sector 0 or some other arbitrary scheme. |