Yes, it was the first video game I ever played and I still enjoy it sometimes...but you should really move this over to the video game thread...unless you mean this to be about all things old school.

If you do, we can exchange stories about programming under constraints where we had to be very resourceful. In 1970 I programmed a Monrobot printing calculator to generate pseudorandom numbers for CWABL, the Citrablammatic Wizamadingy (or Computerized Winner) Automatic Baseball League, which was my classmates Marc Blank's & Alex Citron's simulation of the MLB season. Marc Blank went on to become the macher of game company Infocom.

The Monrobot (the Math Dept.'s calculator in the basement) could be programmed with up to 64 steps, looping but not branching. It had 2 "memory" registers, one of which was also an alternate accumulator that could be added to or subtracted from. The regular accumulator could accept results of addition, subtraction, multiplication, and division. While "diamond" (common symbol on calculators at the time) would sum and retain the sum, "*" would sum and clear (to 0). No, a numeric value could not be used instead of an operation step, but before starting the program, the calculator could have values manually loaded into the pair of memory registers and implicitly in the accumulator.

We (though maybe not Alex) had in the previous year taken a trimester of Computer Math (which was actually Fortran programming), and I'd taken a liking to the subject. We had a keypunch machine in the Arts Dept. bldg., and sent the cards to Manhattan College to run the programs. On my own, I read of a simple algorithm to generate pseudorandom numbers, which was to square a large integer, then truncate equally the high- and low-order digits to generate the next number. If you wind up generating 0000, you're screwed, but otherwise it's not bad. I used that algorithm as the basis of my Monrobot program. I had to use some tricks to do the truncation, since it treated data as 8 sig-dig floating-point exponential. To produce a "1", I divided the contents of a register by itself; to produce a "0", I subtracted a value from itself. To generate a halt, I divided by the 0 so generated; I don't think I used that trick in this program, though. It wound up taking up 63 of the spaces for the 64 programming steps. Memory was volatile, so the program and its starting data had to be manually loaded every time. It would accept a seed for the random number routine, and an integer for the upper limit to the random numbers, because whatever the routine generated would be printed out modulo that limit (i.e. 0 to n).