Parallax

Disc Protection by Simon Cooke included some hidden demos unknown to the publisher.

There was a bug that caused a crash when some of the later levels were loaded, this was fixed with a patch issued on Fred 25 which also had the effect of disabling the hidden demos.

However, even with the patch applied the following message exists in the code : “HERE, USED TO BE SOME ENTROPY DEMOS - AND YOU CAN STILL GET TO THEM IF YOU POKE THE JUMP JUST ABOVE WITH 16607… COOKIE!”

FRED Magazine reported that this game was originally going to span over three whole disks, but Cookie’s clever algorithms managed to squeeze it onto only one.

From Simon Cooke 12th June 2023

The Lemmings/Parallax Copy Protection

(Christopher John White - this was all a while back, so please jump in and correct me if I get any of the details wrong - memory is fuzzy). (I'm also borrowing Anton's disk track map )

Just in case anyone's interested, the Lemmings/Parallax Copy protection scheme came about because of two things - one, trying to cram more data onto a floppy, and two, trying to come up with a mechanism that wasn't easy to crack.

But ultimately it was a lot of messing around and experimentation.

The Parallax copy-protection scheme was a neat one (Maciej J. Wołoszyk sent me an email at one point telling me that it had taken him longer to crack than pretty much any other one he'd come across - a marathon 24 hours hacking stint). It relied on a few tricks - 1KB sectors (aside from the mandatory 512-byte boot sector/directory entry), loading and overwriting the DOS over the top of itself (obliterating many hacks - and the code to load the rest of the game after loading the DOS only came in while it was being overwritten). But the coolest parts were the sector addressing scheme that made it pretty hard to figure out what the hell it was doing, and difficult to copy, as well as adding extra tracks.

Source code for the copier, and the DOS, and the boot sector can be found here:

The Copier:
http://simoncooke.com/.../source/parallax/e-copyv1.0.txt

Boot loader, that loads the DOS over the top of itself:
http://simoncooke.com/.../infobase/source/parallax/pboot.txt

The DOS:
http://simoncooke.com/.../infobase/source/parallax/pdos.txt

First the extra tracks... I can't remember if it was common knowledge or just from experimentation but you could get about 84 tracks per disk on a SAM disk. This was about the limit of the Citizen drives, and it was quite possible that some drives might not be able to read the highest numbered tracks, but hey, who doesn't like to live dangerously? The innermost tracks are also spinning much faster (meaning that you'd need to use write precompensation to write data to them correctly), and there's a good chance that you'd run out of space for the entire track if you weren't careful. But luckily, it seemed to work fine.

The next part was realizing that the address data for the sectors on the disk was arbitrary. When you step to a track, the track register is an optional counter to keep track of what the stepper motor is doing, but only if you set the right bit in the STEP commands on the disk controller. Otherwise it doesn't update. Similarly, verifying the track after a step is an optional step controlled by a bit on the controller.

In other words, checking that you're on the track you claim to be is all entirely optional. So the track part of an address doesn't need to be the same as the physical location that the read head is over.

Sectors don't need to be numbered from 1-10 either. You can number them anything you like. So let's number them entirely differently.

Once you've done that, all you need to do to read back a sector is to set the TRACK and SECTOR registers to match whatever you want to read from under the head as it spins past (the numbers can be anything), and then do a read sector command.

I hacked together another copy protection scheme based on this at one point but never put it out into production. The idea was that you'd have multiple sectors on a track with the same address, but one would be full of garbage. You'd have to get the timing just right to read the uncorrupted sector in as it went under the head (probably by reading the index pulse to get the timing right), otherwise you'd have a 50:50 chance of reading garbage data. Hard if you're duplicating a disk the normal way. (Also tempting to do if you could fit 11 512-byte sectors to a track, because then a simple disk copier - even one written in BASIC - would see valid files, which would copy correctly, but they'd come out as garbage... spoooooky...).

The Lemmings copy-protection scheme was designed to cram more than 800KB on a disk, and be mostly uncopyable. I'd figured out from a few experiments that you could probably fit 5KB per track using 1KB sectors, plus some room for a single smaller sector if you reduced the inter-sector gap size when formatting the disk. You can't write out a track in a single pass with the VL-1772-02 due to a weird bug in how it handles data (MFM/FM PLL/encoder issues for some bit patterns), so you need to leave enough gap that you don't trash the sectors to either side with bad writes when writing out the disk in the second pass. This limits how much you can cram on, but it ends up that if you use multiple sector sizes per track you can cram an extra one in.

Using the largest sector size for the majority of the sectors also reduces the amount of space needed for track headers, gaps, synchronization marks, and so on - increasing the space. Which is why you can't fit 11 512-byte sectors on a track, but you can fit 5 1KB sectors and 1 512 byte sectors.

I didn't implement this for Lemmings (IIRC), but told Chris, and Chris took some of the Parallax DOS code for reference and the E-Copy copier source and went ahead and hacked it in. Chris went a bit more conservative for Lemmings and reduced it to 82 tracks per side to make it more compatible with more drives in the wild. (Although we had no hard data on compatibility issues, AFAIK).