LIFE - 4 Gosper Glider Guns on PDP-7 Type 340 display

Wow, Tube Elite is quite impressive. I had no idea this could be done at this speed/frame rate.

Worth noting that both the videos I posted are using PiTubeDirect, a project which is able to deliver very much faster 6502 performance than was possible back in the day: in effect, a GHz-class Raspberry Pi emulates a 6502 running at over 250MHz, or at 3MHz or 4MHz, or a variety of other CPUs at various speeds. I’m not sure what speed is being used for the Executive Elite in the video.

Edit: but notably, I think Elite’s game time goes as fast as it can - the world clock is not calibrated. So if you run on a 4MHz second processor everything happens faster than on a 3MHz processor. It’s not (just) a frame rate difference, it’s a physics engine difference.

1 Like

Yeah, the BBC Micro’s decision to use faster RAM was expensive in 1981. But what was expensive in 1981 was not expensive in 1985, when the Commodore 128 came out. The Commodore 128 had an affordable launch price of $300, and it featured 4MHz RAM suitable for its processors (2 MHz 8502 and 4 MHz Z80).

But for various reasons, the C128 did not take full advantage. Most users lacked the 80 column monitor necessary for the CPU to run at full speed, and the modest speed advantage was not compelling seeing as the overwhelming bulk of software available was for the C64. It’s a shame because there were 6502 CPUs twice the speed, and 80 column mode could have taken advantage of that (the RAM was just sitting there doing nothing for half the cycles).

Anyway, in 1985, there was also the very affordable Atari ST and the relatively affordable Amiga. Both had ~8MHz RAM, as did the Mac (which admittedly was pricey, though). Apple ][ accelerators commonly had 3.58MHz 65C02, so an affordable 3.58MHz 65C02 computer with 7.16MHz RAM would have been doable. So basically, we never did get to see what the 6502 could really have accomplished.

I wonder if the Tube interface could have operated more like Amiga accelerator cards. The Amiga approach was for the accelerator CPU to outright replace the original CPU, which would simply be inactive. The RAM on the accelerator card was called “Fast RAM”, and the CPU could access it at full speed without any interference from the video card or anything else. But when accessing “Chip RAM” (a.k.a. “Slow RAM”), the card’s bus was “glued” to the main bus and the CPU had to wait for access. During this time, the accelerator’s CPU would be slowed down to the main bus speed. This was a relatively simple solution compared to a fast on board cache, but with some obvious limitations. The graphics chip and other hardware DMA couldn’t access Fast RAM, and the CPU would inevitably be slowed down during access to Slow RAM.

But the big benefit is - you don’t need special software to take advantage of the extra speed. All that’s needed is a parameter in the memory allocation routine to specify whether it needs to be Slow RAM. If it doesn’t, then the memory can be allocated from Fast RAM on computers that have Fast RAM available.

As I understand it, the idea behind the Tube interface was that the main 8-bit CPU would always serve basic IO (thus abstracting IO for any future main processor), while the actual computations could be transferred to a more advanced processor, as they would become available. (In the case of the BBC machine, this also facilitated future CP/M compatibility.) As Steve Furber recalled in a recent interview, it was felt at Acorn right from the beginning of the design process for the BBC Micro that the days of 8-bit MPUs might be limited.

Edit: To me, this sounds more like the BBC Micro was designed more like a smart terminal (and channel architecture), which could either run on its own or could be connected to an essentially external processor via the fast Tube interface.

Indeed so, Acorn’s Proton project, which was massaged into conformance with the BBC’s desired spec, was to make a machine which acted as a front end to a bigger faster machine. And in effect that’s what happened, once the Tube interface chip was designed and the first Second Processors were shipped. It went from 6502, for speed and memory capacity, through z80 for CP/M and x86 for DosPlus, to 16032 aka 32016 for scientific computing, to ARM for bringup and software development. And these days, all of those can be run using PiTubeDirect, as well as a 6809 and a PDP-11. (There’s a BBC Basic for PDP-11, of course!)

I wrote a couple of articles:
Acorn’s BBC micro - some resources
Acorn’s Second Processors and the Tube - what, and why
and also of relevance to this sub-topic (bit of a thread drift…)
Some interesting Steve Furber observations
“Outline specification for the BBC MICROCOMPUTER system”

Interesting to learn that the C128 also had 4MHz memory and an 80 column mode. It’s not a machine I have any familiarity with.

2 Likes

Note that an 8MHz 68000 takes four clock cycles to make a memory access and so can only make use of a 2MHz memory. That was what the Macintosh had and the video took up 1MHz making the processor run at half speed except during the horizontal and vertical blanking periods.

As I described here, I changed the memory to a 4MHz one so that there was still 2MHz left over for the processor during the active video with 1MHz wasted (and 2MHz wasted during the blanking). This made a RAM-only benchmark 23% faster (with a smaller increase in performance for software with a lot of ROM use). It was only worth it because Apple was already using memory capable of 4.35MHz on the Mac 512K and later anyway (in contrast to the 3.33MHz DRAM of the Mac 128K, which they rounded down to 2MHz) so there was no extra cost.

4 Likes

Wow, that’s awesome! Thanks for the description details - they answer a lot of things I had been wondering about the Mac and 68000.

BTW I cooked up an RLE file for the 4 guns pattern:

x = 72, y = 72, rule = B3/S23
64b2o$24bo39b2o$22bobo$12b2o6b2o$11bo3bo4b2o12b2o$10bo5bo3b2o12b2o$2o
8bo3bob2o4bobo$2o8bo5bo7bo$11bo3bo$12b2o$64b3o$63bo3bo$62bo5bo$62bo5bo
$65bo$63bo3bo$64b3o$65bo3$66b3o$66b3o$65bo3bo2$64b2o3b2o10$66b2o$66b2o
$4b2o$4b2o10$b2o3b2o2$2bo3bo$3b3o$3b3o3$6bo$5b3o$4bo3bo$6bo$3bo5bo$3bo
5bo$4bo3bo$5b3o$58b2o$56bo3bo$47bo7bo5bo8b2o$47bobo4b2obo3bo8b2o$36b2o
12b2o3bo5bo$36b2o12b2o4bo3bo$50b2o6b2o$47bobo$6b2o39bo$6b2o!
3 Likes

Just found a description of programming Life for the PDP-7 on a 72x72 character display - very likely the one we see at the top of the thread, as the shared blog and the video are both from the Living Computers Museum. Pseudocode within. It’s a word-wide approach, described as parallel programming.

Jeff Kaylin:

I wrote this program for a PDP-7, which has a word size of 18 bits. The display I use has a reasonable 44 character mode, and a tiny 88 character mode. So I chose 36 x 36 as my first game board, later expanding to 72 x 72. That would be 2 18-bit words per line or 4 18-bit words per line.

1 Like