Harald contacted me recently and was kind enough to share these additional notes:
*) Later titles used tracks with super short syncs that are missed by nibblers (which we noticed on later V3 titles)
*) Later titles used a simple form of Huffman-coding to get extra data on the disk.
*) On some titles, they would randomly insert extra syncs on tracks that were checked for position and length (this is probably what the extra checks are on DOTC)
*) They checked for extra drive RAM in the protection by using mirror location tricks. :)
*) They did use bad GCR in early titles not knowing it would cause compatibility issues with later drives. He said they left it in the loader track (20). This is why when we correct or "simulate" bad GCR it ruins this track.
*) They definitely intentionally store more info than will fit on a track at 300rpm.
*) They never checked track sync. This seems to be untrue- Paperboy is checking sync on tracks 31-42 and others have been found.
Version 0
This appeared in the first V-MAX! title released, Star Rank Boxing. It has nasty checksum checks throughout the game and appears to have some byte counting on a couple of long tracks. I haven't been able to make a copy that will pass the very last protection check that it does before the game starts. It is all normal CBM DOS sectors.
Version 1
This is used in some Activision games and is mostly easily copied and works in VICE. A couple titles have an extra byte counting protection check that still fails. It uses normal CBM DOS sectors.
Version 2
There are 2 variations of this used on the Cinemaware games and a few other
titles. What we call 'V2' are usually identified by the lack of any directory entries other than "!".
The first variation has a single EOR'd section of code on track 20 that starts with big run of $5A, then a single EOR'd section of loader code followed by a checksum calculation. These disks use regular CBM DOS sectors. This variation to is difficult to get a proper read of track 20, because while it has no sync, it has a bits of data that is actually ten '1' bits in a row. This foils copiers because the drive circuitry *sometimes* detects this as a sync (a BIT/BVC branch combination has a 5 CPU cycle jitter) and reframes the data. If you are persistent enough, you can get a good read of these and they will remaster and work in the emulators. Defender of the Crown also seems to have a byte counting check like the earlier V-MAX! v0 on the back side, which I cannot get to pass.
The second variation has a track 20 that starts with somewhat less $5A and has 2 sections of EOR'd code. It uses all new custom V-MAX sectors instead of regular CBM DOS.
Version 3
This is the version that appeared later on Taito games, etc. I have found two variations of this, one with later tracks (every other one) that have very short syncs and one that doesn't. Both work in VICE now as of the my newest update of the MNIB reading routines. Both contain V-MAX sectors of variable length and some contain tracks of CBM DOS sectors also.
All V-MAX! titles I have can be remastered if you slow the drive motor down to 297.5 RPM. Y
