Hey everyone, it’s Marcus.
One of the fun tasks I’ve been challenging myself with over the years at the ACMS is to try to port Minesweeper onto a large number of machines that don’t already have existing ports of the game. My first port was for the classic Mac, which turned out really nicely polished and fun to play.
My next target was the IBM 5150, which didn’t already have much software available to be demoed at the museum, so I wrote the game to run ‘bare-metal’ and not require DOS to already be running for the game to work. The whole game fit into around 10-ish sectors of a floppy disk.
After the 5150, I wrote a never-finished version of the game that ran on the PDP-11 architecture. Just like the version of the 5150, it was designed to run bare-metal with no operating system required. I don’t have any photos of it running, but we were able to have the game run on a PDP-11 that was connected to a paper teletype machine which was pretty entertaining to watch.
I then learnt about the museum’s PDP-8 and its in-progress restoration, and I knew immediately I had to give porting the game to it a crack! The challenge with programming for the PDP-8 is definitely the absolutely tiny instruction set of only around 8 instructions. I found a compiler that works well enough called ‘Palbart’, a PDP-8 programming manual, and created the following repository: Jaffa / Straight-Sweeper · GitLab
A challenging aspect of the PDP-8 architecture is the fact that the core memory is divided up into ‘pages’ that are each 200 (octal) memory addresses wide. Any code in one page is unable to refer to code in any other page, with the exception of the first page (known as the zero-page). One frustration that this causes is that it is impossible to run a subroutine from a different memory page than where the current instruction is.
In the following pseudo-code example, calling the subroutine ‘FOO’ which resides in page 2 from code that is in page 1 would cause a compiler error.
The solution is to create an absolute pointer to the subroutine in the zero-page (which is accessible from all pages) and then indirectly call the subroutine through the pointer.
This means for every subroutine that should be accessible to the entire game, a pointer to it must exist in the zero-page so that code elsewhere in the game is able to call the subroutine without causing a compiler error. This eats up valuable space in the zero-page (which is only a little over 100 memory locations long), which could otherwise be used for global variables and constants that are equally important to the function of the game. So far I haven’t run out of space in the zero-page, but I haven’t implemented all necessary subroutines yet so I’m not sure if this will actually become a problem yet.
Another roadblock I’m trying to get through is figuring out how to somewhat-reliably generate random numbers. I did this on the PDP-11 by using the middle-square method ( Middle-square method - Wikipedia ), which was easy enough to accomplish because the PDP-11 is a 16-bit machine and creating a big-enough number was no issue on that architecture. Unfortunately the PDP-8’s 12-bit architecture made trying to use this method too unreliable. Quite often, I would end up with a random number that would either stay stuck at 0, or would have an incredibly short period (which means the random number would only cycle through a small number of repeated values). Another method I’m currently attempting is to use the code of the game itself as a large data-set of somewhat random numbers and using those to increment the base random number/seed. Each time a new random number is needed, a pointer to a random address of the game’s code is used to retrieve some random data, and then the pointer is incremented by 1.
The game is only about 50% complete, with many critical functions yet to be developed. I still need to add a routine that adds the numbers into the map, another which checks if the game has been won or lost, and so on. I’ll also make sure the code is both well documented and as efficient on memory as possible. The primary way I can see the game being loaded on the real machine when it is eventually restored would be via paper tape, so having the game be as compact as possible would help in reducing the total paper tape needed and speed up loading time.