Whereas when tackling the original Atari ‘Star Wars’ vector game it was a pleasant challenge -create the necessary 6809 toolset, optimizations and Vectrex advancements for a great game I’d like to play- the work for ESB was different from the outset: I knew that even though it was released years later it was an inferior game and would tax the Vectrex to the extreme. Now that I have converted it my estimation has not risen – but my reasons why I dislike the game have deepened. But I should start at the top: Empire Strikes Back is the best Star Wars movie to date, marginally beating the very first one. At least in my estimation which explains my still somewhat fond, albeit hesitant start to this project.
This is the last 8-bit vector game Atari released, using in 1985 the very same hardware used by the first Star Wars game in 1983. Just increasing the ROM sizes a bit. During those two years a lot changed in the business, the golden arcade age has definitely passed and this is a good example of post-boom times. The game feels the same – just one more level and the overall game experience and design is extremely similar. This is enforced by the internal design – it is obviously an adaptation of the first game with the addition of more ROM space to accommodate the extras. But.. but ! Atari at this point was at least equally interested in not being ripped off by its customers than competitors, too, so they made sure that the rom extras could not be copied and played in an original Star Wars cabinet and chose Atari’s (back-then new) ‘Slapstic’ security chip. This one functionally sits on top of a larger rom and handles bank switching for a smaller rom adr. space. The security part being the capability to offer curious ways of affecting these bank switching bits via several other means.
When looking at the code and the game itself it was clear to me that they did not care foremost anymore about having fun for the gamer or maximizing the possibilities the hw offered. It is about squeezing more money out of something existing and getting it out the door. Even the tutorial in the game – which takes a largish amount of rom space – cannot even be viewed in one go: you have to play three times in a row (and insert enough coins) to see it all. That really says it all. And to quote John (of John’s arcade): in the original game’s last level you destroy the **ing Death Star ! Here you dodge asteroids that you cannot even shoot.. I cannot agree more and just add: you cannot shoot them in a shoot’em up !
So, this turned into a technical investigation into how Atari engineers implemented the slapstic security capabilities really fast. On the outset the slapstic chip is pretty simple: upon hitting certain addresses the output bank lines would change deterministically. The devious part is that there are address iterations (in a sea of incoming adr. lines, no less) which will change this, say preload a different bank line or ignore a switch afterwards. Easy to do on the slapstic side, bastardly hard to figure out afterwards. Luckily MAME engineers already figured this out but this is not where I started: I wanted to see what the Atari engineers did in ESB.
The deterministic bank line behavior is spelled out in the esb slapstic rom parts as subroutines, impossible to ignore or miss. There are five small, identical subroutines at the very start of the rom (at 8000/8080/8090/80A0/80B0) consisting just of: BITA $8000, RTS. So to figure out how the normal bank switching works takes just a few minutes with a disasm of the rom. Accessing 80×0 sets a bank, 8000 clears the inner switching mechanism (but does not touch the bank lines). The devious parts are quite rare and in the context of this game at least are used as a way to return back to different routines based on game state via the pc on the stack; returning to different slapstic banks with the same pc. When killing a TIE fighter in space for example if you do hit it the game will do this to explode it. And if the slapstic security malfunctions it just always misses.
Pretty unusual for Atari back then: these rare protection features are easily reproducible, even if it takes a while to play through the earlier levels. Nowadays running this in an emulator makes finding them straightforward – freeze the state shortly before and look for new address accesses afterwards within the slapstic area.
Nice and easy which led me to waste a week of my life: trying to remove the entire bank switching and devious parts of the code. Removal of the devious parts was indeed easy enough: there are two alternate slapstic hw mechanisms used: ignoring or overriding the bank switch when accessing 80×0. E.g. an override is at a subroutine in bank 2 at 9DFE which does a LDA 0,X and is called just from four areas with X of (9B5C/9B5D/9B5E/9B5F) and a JMP 8090 directly afterwards – the lower bits in X previously on the bus are substituted for the jmp adr. bits for the bank switch. So just nop’ing out the call to the subroutine and using the correct bank switch function removes the need for alternate hw behavior there (and similar for the other code spots).
The bank switching itself – to change the entire game into a modified harvard architecture – turned out to be a nightmare. That has not entirely to do with the slapstic per se but more with the very odd and wasteful way the slapstic rom is used: There are not many calls and esp. no switches made from outside the slapstic rom – it is a self contained entity. And the switch internally is made via subroutines – which have to be in all 4 banks. But also the start and end bank have to be in-sync code-wise for this and they used massive amount of lists of jmp and jsr’s to cover this. Most of the time but not always, which does not help either. I am not certain whether this is security-by-obfuscation but am slightly leaning towards the view that several people were working on this game and the one in control of the slapstic rom area chose a way of exposing the rom functionality which is self contained and just not lends itself to static interpretations. And wasted roughly a fifth of the rom space just for these switch codes which do something like a jsr, jmp, jmp, jsr, jmp frequently to switch banks more than once (and jump around in them) before finally ending up in the subroutine wanted.
But the most problematic part were a few callers outside: based just on adr. changes (via slapstic bank switching) and the call pattern behaviour from the non-slapstic rom parts this could not only not be distinguished but I have almost convinced myself that it is deliberately done as caller security: I know of callers to slapstic addresses which end up in different banks and did not find the reason as to why so far. It seems the normal, banked rom parts are not aware of the bank set in the slapstic – there’s no tracking variable or any switch outside except a reset in the reset code. Still, there are callers into the slapstic that end up in different banks. The switch is again rare and takes a while to reproduce. Just the kind of thing Atari engineers liked to do protection-wise. So ESB will have to remain the only example where I could not entirely convert the arcade game into a harvard architecture, at least the smaller slapstic rom area – the entire rest (including the banked parts) are.
Not that this would affect the gameplay nor performance, it just shows what can motivate me: a technical puzzle. There to be solved. Well, at least the entire, higher level slapstic protections are gone so I could create a version now which runs on normal Star Wars pcbs with a tiny bit of hw add-on (for the bank switching). Not that I have access to one nor know someone who owns one…