… a loosely disorganised gathering of RetroComputing enthusiasts who collectively do stuff with old computers for a month.
The event is very much open to interpretation… individuals set their own challenges, which can range from programming to multimedia work, hardware restoration to exploring legacy networking, or just plain fooling around. It really doesn’t matter what you do, just so long as you do it.
The deal is that you say what you’re going to try to do, try to do it, and post your progress somewhere visible.
I see systems as late as 2002 are accepted this time around:
Rather than turning up our noses at these systems’ garish GUIs and baroque data bus widths, we are showcasing them! So, pull that 1st Gen iPod out of your desk drawer, fire up your trusty Zaurus SL-5500, drag that iMac G3 out of mothballs, or go find your old ThinkPad 570, and get computing like it’s 1999!
There’s something for the PDP-1, I want to try. (In principle this game. Someone, who should know better, asked, if this could be done on the PDP-1, which is of course a ridiculous idea. Meanwhile, I’m starting to think, it may actually be done with a few compromises. It’s really about finding out.)
But I may not have the time to do it and blog about it. Let’s see…
Spacewar runs at about 16 frames per second.
(So much for why implementing this game on the PDP-1 is a ridiculous idea to begin with.)
However, we showed that we can run a Computer Space simulation at 60 frames per second on the PDP-1. (This is a much simpler game with simpler graphics, though.)
The most obvious bottleneck is that putting a single dot on the display takes 45 microseconds. (This is good for about two solid lines across the display at a decent frame rate. How many dots can we manage and execute a game?)
While Spacewar computes sine and cosine by a complex Taylor series in real time, we may use a lookup table and precomputed values.
(This was good for the PDP-8 version of Spacewar, so we should be allowed to do it on the PDP-1 without calling the wrath of the computer gods upon us.)
We can use lookup tables for the asteroids, as well. (Limiting their shapes to just a limited set.)
Spacewar does gravity calculations for two ships with respect to the sun. Here, we must add gravity from multiple attractors for a single ship. How many calculations can we shove into a frame?
We can’t precompute gravity. However, the timing of Spacewar is derived from a version for a machine without hardware multiply/divide. The version for the upgraded PDP-1 essentially maintains that timing and reinvests some of the runtime gained into more accurate calculations by converting fixed point values to floating point and back gain. (We may produce a version for the hardware/multiply divide based on the original algorithm, which would be faster.)
We must include some scores, this requires compiled procedural sprites for the figures, quite like the outline of the spaceship. With memory already dedicated to lookup tables, this may become rather tight, given that we have only 4K. This will become quite a battle over time versus space constraints.
On the plus side, as compared to Spacewar, we don’t have to render a background starfield (the “Expensive Planetarium” by Peter Samson, which uses lookup tables, as well).
There are obviously some things, we can’t do, like the gravity map (which is in JavaScript even challenging for a 10 years old PC). The near miss asteroid scratch effect is nice to have, but requires figuring out from which side we approached the asteroid. (This will probably be too much.) Quite the same, the vector based Asteroids-style explosions are probably out of budget. And we’ll have to put a limit to the complexity of the scene in higher levels. (For obvious reasons, we won’t be able to do 20 asteroids and 4 saucers at once at 200 KHz.)
There is quite a number of opportunities to tune this. (E.g., what is the granularity of the lookup table? Are we going to have values as ready to use as possible, or will we only have values for a single quadrant and derive sine from cosine, which will be easier on memory, but more expensive in terms of run time? etc…)
I’ve many parts of the actual game logic ready to be reused from the Computer Space port (it’s more a question whether I manage to understand my assembler code from 6 years ago in a decent amount of time or not), also there is quite some to be reused from Spacewar. Entirely new code is required just for drawing the asteroids and the saucers. The challenge is really in juggling the various parameters for fitting the game into the limited amount of memory and tuning run time.
Welcome Eric, and thanks for bringing us the Retrochallenge!
individuals set their own challenges, which can range from programming to multimedia work, hardware restoration to exploring legacy networking, or just plain fooling around. It really doesn’t matter what you do, just so long as you do it
