Rare Gamer Interviews Paul Machacek on Stop ’N’ Swop

by Lerako on Apr 10th, 2020

Early last month we had the incredible opportunity to speak with software engineer, Paul Machacek, about his involvement with the enigmatic Stop ’N’ Swop feature found in Banjo-Kazooie and referenced in many of Rare’s titles since. If you’re unfamiliar with the secret feature, our Stop ’N’ Swop Explanation and Retrospective article will catch you up on the necessary details. If you’re like us, however, and you’re well-versed in both Stopping and Swopping, you should find the following insight a rare and exciting glimpse into the development process of one of Rare’s largest mysteries.
Without further ado, we present Paul Machacek’s recollection on the invention, application and unrealized potential of Stop ’N’ Swop!

---

Rare Gamer: Can you tell us how the idea for Stop ’N’ Swop first came about? At what stage in Banjo-Kazooie’s development did the team first start experimenting with the tech?

Paul Machacek: So, Tim [Stamper] and Gregg [Mayles] worked closely together and discussed design for the game throughout. One afternoon, Tim came to me and asked if there might be a way to send a code from one game to another. The idea was to allow something in one game to be able to unlock something else in another so that two games could affect each other.
Also, he asked that it didn’t involve anything that could be printed on the screen and simply copied and shared by people in magazines etc. (no internet back then in the way we know it today), so he didn’t want some text code however convoluted.
He wanted a method that required someone to physically have both cartridges (it was to encourage sales of our games).
There and then, while he was talking to me (it lasted barely 5 minutes, I think) an idea popped into my head and I said to him, “Leave it with me, there’s something I want to try, and I’ll get back to you”.

Back in the 1980’s we all worked on home computers (ZX Spectrums, C64’s etc) and one of the features they usually had was that if you switch them off and then quickly switched them on again, the video memory was not cleared for a short moment and there would be a brief, but degraded, residual image of whatever had been on the screen before you cut the power. There are various reasons for this, but the fact that sufficient data could survive the power-loss journey to be recognizable was what occurred to me.
People think RAM loses it’s data instantly on a power cut, but that’s not true. The data held over a block of RAM degrades over time until nothing useful is left.
On top of that, the electrical characteristics of different systems could play a part too. If there was a capacitor on the board (there always is, and usually in the power supply) then these hold charge and as soon as the main power is cut, they simply discharge into other components until they’re depleted, but this means those other components still have power on them (to a degree) until the caps have discharged.
The PSU itself often has a relatively large electrolytic capacitor in it which can hold quite a lot of charge, and lower power IC’s on a small circuit board could take a few seconds to deplete it fully.
The best demonstration of this is have you ever had a power supply with a little light on it that, when you disconnect it from mains electricity, the light stays on for a few seconds? Well, that’s what I’m talking about.
But in the case of a small computer device, it’s not just a little PSU light that stays lit, but also the chips on the board stay powered to a degree for a short time.

So the N64 was likely to have such brief “memory effects” and I thought I’d investigate.
When I asked Tim what exactly he wanted to transfer between two games he said, “triggers”, basically flags that indicate whether an event in one game had occurred or not in order to activate a feature in another.
Well that’s just binary; an on or an off; a 1 or a 0.
We agreed that a collection of 8 such triggers would be a nice “packet of info”, as it’s simply 1 byte of data that could carry the states of 8 events from one game to another.
So the idea I had was to create a packet of data that contained the byte of information that we wanted to transfer, along with a load of other bytes that did exceptionally heavy error checking so that we could confirm whether the data was valid or not.

The next thing is to say, ‘Where do we put this packet in the memory?’
Well, here’s the thing – if we put just one packet somewhere, then it has to survive, and if it doesn’t then nothing is transferred. There’s no way this could be guaranteed (actually, it was pretty much guaranteed not to work).
However, I was also responsible for writing the entire memory handling system from scratch, so I knew how it worked and I had a better plan.
Going back to the 80’s home computers thing for a moment, it’s not that 1 byte of data in video RAM was surviving the journey; it’s that many bytes, enough bytes over an area of the video RAM was surviving “sufficiently enough” that a recognizable (though degraded) image was appearing.
In a dynamic memory handling system (such as the one we pioneered in Banjo-Kazooie), you start with an empty block of RAM (all of it) and as the game boots and runs, different systems make requests to the memory handler for blocks of RAM of different sizes.

Over time, these blocks are allocated, reallocated (in different sizes) and de-allocated and the overall RAM ends up filled with lots of regions of different sizes, some filled with current data and some relinquished and empty.
This actually fragments the amount of available RAM, and one of the innovations that allowed Banjo-Kazooie to run that I implemented was a memory defragmenter system that ran in “spare time” at the end of each 30hz (desired) game frame as it waited for the next vertical-blank period.

Also, because of the architecture of the N64 (it’s in the title) we aligned all memory regions with 64-byte boundaries in RAM because the DMA system was optimized to work from such boundaries. So all I did was to add an extra function into the spare time at the end of a game frame that, sequentially, over multiple game frames cycled it’s way through the free regions of RAM, from 64-byte boundary to 64 byte boundary and write out this heavily error checked 64-byte packet everywhere.
It was constantly, every game frame, writing this packet all over free areas of RAM. The packet had 1 byte of trigger data, and 63 bytes of various different types of error checking. I don’t recall exactly what the formats were but it would have been something like this:

In a packet, the 1st byte was the actual data byte with the 8 flags. The 2nd byte would simply be the same data byte with all the flags flipped, which could be easily checked against the 1st byte on reception. The 3rd byte may have been the 1st data byte with the bits in reverse order. The 4th byte may simply be the sum of the first three bytes. The 5th & 6th bytes may have been a 16-bit word, which was the sum of all the previous bytes. The 7th byte may have been the first, third and fifth bytes added together. The 8th byte may have been the second, forth and sixth bytes summed. etc. etc. etc. until we had 64 bytes of data.

The chances of a random block of data passing all the error checking tests was minuscule, and because the flag data was only sending 8 flags that indicated, “yes something is triggered” or, “no something is not triggered”, then if a rubbish pack had been mis-identified as ‘GOOD’ then the receiving game would simply get an activation for a feature that did not happen, really.
But it wouldn’t break the game – it wouldn’t crash or anything.
Also, when the receiving game received a good packet, it would store the 1/enabled triggers in its save game memory so that they would persist as “enabled” forever after in that game.
So, as Banjo-Kazooie would be running, it would (in free time) be constantly dumping these heavily error checked packets all over free RAM, and it only took one single packet to survive the power-cut journey unscathed for the data to get through.

What the receiving game would have to do was as soon as it boots, the very first thing it did (apart from possibly disable the interrupts on the processor which is a standard thing you did on boot) was to scan the RAM at all the 64 byte boundaries and look to see if a packet was there.
Off the top of my head right now, there would have been a short text string in the packet – no idea what now – but it would have been consistent, maybe something like ‘PINK FLOYD’. This boot-searching code would initially look for ‘PINK FLOYD’ to see if a packet was in any of the boundary positions in RAM it could find.
If this initial indication of a packet was found, then it would go through all the error checking steps to see if it was a full and valid packet. If not, it would abort and move on to the next possible boundary position and keep going, looking for packets until all of RAM had been scanned.
It would only have to find one single packet that passed all of the checks and then it would take the trigger byte of data and save it.

So I spent a couple of hours writing some test code and put it on two development carts. Each cart had a hard-coded trigger byte, and they were different for the two carts so that one cart wouldn’t accidentally send data to itself and they would only look for packets with the different trigger code from the other cart.
The test code would boot up, scan the whole of RAM for packets, do all the error checking required on any possible packet candidates it came across and then count the number that fully passed the test.
I wasn’t interested in seeing if one packet survived at this point, I was interested in understanding how many could and how that would be affected by the amount of time the power had been cut.
So each test cart would boot up, immediately scan the whole of RAM for packets that contained the trigger code for the other cart, count the number that fully error checked ok, print the results on the screen and then sit there writing out it’s own packets with it’s own trigger code to RAM ad-infinitum until we cut the power and swapped the carts again.

The other cart on power-up would then do the same thing, and we could see the results on the screen every time we cut the power, swapped carts and switched back on again.

Rare Gamer: What was your experience as you tested the first successful ‘cartridge swapping’ and discovered that memory could be transferred between games?

Paul Machacek: The very first time I ran the test, the power was cut for a very short time and the results indicated that hundreds of packets had survived the journey. Then I called Tim. He and Gregg came over and I explained all this to them, and they recalled the “memory effect” from 80’s home computers having been highly familiar with those systems.

For some reason at that point we did something really weird:

We decided that between 3 people with 6 hands we’d try to swap carts like a Formula 1 motor racing pit-stop to change tyres. Gregg would have his hand on the running cart in the machine, Tim would be holding the second cart alongside it, and I’d be on the power switch.
I’d say “3-2-1, Go!”, cut the power, and the other two would rip the cart out and insert the second one as quickly as possible, and then I’d power up again.
Hundreds of packets survived.
We sat there for a while just doing this over and over again.
Hundreds of packets survived every time.
I then realised this was stupid, and pointed out that no-one on their own at home was going to do this.
The real test was to see just how long you could cut the power and still have a packet survive the journey (it only needed to be one).
So, we slowed things down and used a stopwatch. We’d cut the power between carts swaps for longer periods of time, and the surprising thing was that although the number of packets surviving the journey decreased with time, it seemed to be linear and completely repeatable. In the end, we had reliably successful results with cutting the power for 23 seconds. Yes! Stop ’N’ Swop was born!

Now, the thing is – hardware changes. There are reasons why “the same console” may have different electrical characteristics than other versions of itself.
The PAL N64 sold in the UK was not electrically identical to the NTSC one sold in the US, and they were different from the Japanese version. However, we had all of these variants in the office, so grabbed them all and did all the testing again on all of them.
It worked fine and our baseline was 23 seconds would work, but we could tell the world a safe figure of 10 seconds, or maybe even 5, which generally seemed long enough to be safe – and sensible – for customers.

As soon as we finished the testing that evening, Gregg and Tim were looking at what we could do with this. The only thing was, because it meant connecting different games then we’d have to consider what to actually do that made sense in them all.
We had three big N64 dev teams working on platform adventure games at the time, and the other two teams were still trying to work out what their games would be after Banjo-Kazooie finally got traction with what Banjo would be. So, in the end we decided to simply have a generic thing where games would send Easter Eggs to each other, which meant that the stuff we put in Banjo-Kazooie was at a far more advanced stage of development – we didn’t need to know what the other two teams were going to design potentially many months later.

At some point, and down to Gregg or Tim, one of the Eggs became a Key (the Ice Key).

My memory gets hazy here, but Banjo-Kazooie was going to release sometime before the next two games (which ended up being Donkey Kong 64 and Conker’s Bad Fur Day. I think Conker was still “Twelve Tales” at this point, so you can see how much things could have changed by the time we had to ship Banjo in the summer of 1998.

Whilst all this was going on, another team was doing Diddy Kong Racing and the GoldenEye team had shipped that game and were in the early stages of Perfect Dark. The Banjo Team also had a notional idea at the point of doing a sequel (which obviously ended up being Tooie) so we had a picture of a group of six games in our minds that could be linked.
I suggested, “Wouldn’t it be great if we could go full-circle and if a player got all six, and we sent triggers sequentially between them, then the last game could send a super-code back to the first?” That may have been why the Ice Key replaced an Egg for Banjo-Kazooie.

So, Banjo-Kazooie needed to accept codes from games that might be released several years later (like Tooie was), so we put two things into the first Banjo game.
First, Banjo would write it’s packets to free RAM all the time it was running, and the trigger flags would be updated in the packets when you completed certain tasks in the game. I do not recall what these were.
The second thing it was doing was on boot-up – it would scan RAM looking for packets from another game, any game, didn’t matter, just finding packets that passed all the error checking would allow it to receive 8 triggers that would enable access to the 7 Easter Eggs and Ice Key.
All the assets and functionality for these was put into Banjo-Kazooie and it worked fine.

It was during the development of Donkey Kong 64 in October of 1999 that Nintendo raised an issue in with how Stop ‘N’ Swop was intended to function. To be honest, I can’t really fault Nintendo for this but they just said “No”.
One thing that I heard back was that they were concerned that as the N64 matured and they redesigned the circuit board to make it cheaper to manufacture during the later part of its life cycle, that the changes may break the feature; that memory would degrade too quickly and customers would find it broken or unreliable.
I wish I’d been part of the conversation, but I have no idea if it would have made a difference.

By the way, we did actually pre-empt problems – we didn’t like the idea that something unforeseen may break it, so in the end we relented and created a bunch of very long comedy text phrases that you could type in using Kazooie’s Beak on the alphabetic floor we’d already put in the game. I believe that these codes were eventually discovered some years later and are free to access online. These codes were never published by us, and were never meant to [be] unless there had been a substantial failure of the system.
So whilst they were ultimately shareable, they were a last resort, rather than a simple passcode that would be printed on-screen and then easily shared between customers.

The system wouldn’t really have done anything unless other games were leaving codes for Banjo to pickup on boot, so we left the system fully intact in Banjo-Kazooie and never implemented it properly in any other title. When Banjo carts boot on N64, the first thing they do is scan RAM for packets.

Rare Gamer: You mentioned before that Stop ’N’ Swop was meant to encompass not only the Banjo-Kazooie series, but potential for titles like Donkey Kong 64, Jet Force Gemini and even Perfect Dark – did the other teams at Rare start to plan out implementation in their games, or was it just Donkey Kong 64 that got that far before you received word that the feature had to be removed?

Paul Machacek: Gregg was involved with the DK franchise, having worked heavily on Donkey Kong Country, so a bit of this filtered across to DK64, which was the next of the three big N64 adventure teams that got traction and released. So, whilst we knew by that point that the feature was politically dead, it didn’t stop jokes and nods to it going in to other titles.

Rare got it’s first internet-connected computer as a single terminal that was free for anyone to access at Rare in 1998. So we could start to see what people were saying on message boards and early forums. We knew that the Easter Eggs and Ice Key were creating discussion and it became an in-joke at Rare for a while after.

References to Stop ’N’ Swop in other titles only really appeared if the very few people involved with it on Banjo were involved. There was no big presentation or anything, it was just ad-hoc chats between people and “what would be funny/cool”
We really didn’t do meetings at Rare back then – everything was informal and teams were mostly locked off from each other in different buildings.

Rare Gamer: Can you remember which of the Mystery Eggs were intended for which games? Would each have gotten one respectively, or were there plans to give two or three to another title?

Paul Machacek: Beyond Banjo, there was no specific plan. It’s not like we said, “The Pink Egg will unlock if you do such-and-such in Tooie or DK64“. The truth is, Banjo-Kazooie‘s Stop ’N’ Swop feature was heavily reliant on other games being delivered with Stop ’N’ Swop enabled, and that never happened as they all shipped after Banjo, and after the feature had been killed. Shame, but, all you wonderful folks still love it 22 years later, so maybe it did ultimately provide some entertainment, which is all we were really after 😉

With that, i’m afraid my recollection now fades. It could have been great, it might have been terrible, it’s an amazing idea. Maybe it is great because it’s mythical, and part of Rare’s Lore.
Who knows? I’m glad it happened, I don’t know how I feel about how it landed. I really wish it had worked and everyone had gone out and bought a collection of six N64 games and had an amazing surprise. Maybe lots of people did buy those six games anyway…

A few months later, and after we’d moved the studio from the old Twycross Farmhouse to our new state-of-the-art facility at Manor Park just south of the village, Tim came to me with a bit of paper with some rules for a puzzle game on. Later that evening I already have V1.0 of it running and playable on a Gameboy, and 5 years later we released it as It’s Mr Pants.
Let’s face it, we were loony-tunes crazy.

Categories: Interviews