Exploring how The Sentinel unravels itself after loading
Revs, the amazing racing game that Geoff Crammond wrote before The Sentinel, has one of the most convoluted loading processes I have ever analysed; see the deep dive on the jigsaw puzzle binary for the gory details. In comparison, the loading process for The Sentinel is simplicity itself.
This is particularly true of the version that I've documented on this site, which comes from the Play It Again Sam 6 compilation. This was released in 1989, some three years after the original, and by that point in the game's life it wasn't worth spending a lot of effort on copy protection or obfuscation, so apart from hiding the game files from the disc catalogue, the game binaries are otherwise unprotected. This is unlike the original 1986 release, which contains plenty of fiendish protection (see Level7's disassembly for an analysis of the original tape protection).
There is still a small process of unfolding that occurs during the loading process, so for completeness I'll document it here, though this isn't exactly a deep dive, more of a shallow surface skim. The game itself still contains a whole load of anti-cracker code, though; see the deep dive on anti-cracker checks for more information.
The loading process
-------------------
The game binary has a load address of &1900 and an execution address of &6D00, which is the address of the Entry routine.
The loading process moves the game binary around in memory in two stages. First, it moves the whole binary down from &1900 to &0400, which is where the game runs; and second, it moves a block of code from &4100 to &5800.
This latter move is necessary because the loading screen uses screen mode 5 but the game itself uses a custom mode 5 with a different start address. Once the game binary has loaded it is moved below address &5800, which is the starting point for screen memory in mode 5, so the mode can now be reset and reprogrammed to the custom screen mode. The custom mode starts at address &6000, so once it has been set up in the ConfigureMachine routine, the second block of game code can be moved just before screen memory at &5800-&5FFF. (The routine actually copies an extra page of memory into the first 256 bytes of the custom screen, so the entire copy is from &4100-&49FF to &5800-&60FF, but the extra bytes have no effect and are overwritten by the screen being cleared.)
Here's a breakdown of the loading process once the binary is loaded and Entry is called:
- Copy the game code from &1900-&6CFF to &0400-&57FF.
- Jump to ConfigureMachine (see below).
- Set up the custom screen mode (see the deep dive on the custom screen mode for details).
- Add a break handler to clear memory on BREAK, even on the older MOS 0.10 (otherwise crackers could load the game on MOS 0.10 and simply press BREAK to access the loaded game code).
- Copy the game code from &4100-&49FF to &5800-&60FF.
- Initialise the 6522 timers.
- Initialise the IRQ handler.
- Jump to MainTitleLoop to run the game (see program flow of the main title loop for details).