The marvellous Bubble Universe graphical animation

From a thread over on Stardot, news of another implementation of a lovely short program, originally seen in 16 lines of Basic, and here seen in hand-coded ARM, running on a retrotastic 200MHz StrongARM RiscPC - one of the fastest machines Acorn produced.

It’s pretty enough as a static image but very much worth watching as a video.

Much more at the stardot thread
Bubble Universe - incredible 16 line demo - needs porting!

Wikipedia on RiscPC:

At launch [in 1994], the original RiscPC 600 model was fitted as standard with an ARM 610, a 32-bit RISC CPU with 4KB of cache and clocked at 30MHz… within only two years a DEC StrongARM could be installed at 233Mhz which was around 8 times faster.

(First seen as Spectrum Basic code by Paul Dunn, but he says he’s not sure where he got the algorithm from.)


Somewhat OT, but for a very simple timeline of Acorn’s ARM-based computers, their specifications and performance, see the table in the head post of this Benchmarks thread on stardot.

Just to state the obvious, this is a beautiful demo.
Also, just 16 lines of BASIC is quite impressive (while I do like the ARM version even a bit better.)


This is the best display hack I have seen, in terms of beauty per amount of code ratio. And we don’t know where it came from?!? Frustrating.

I’ll have this running on a PDP-6.

1 Like

Yes, exactly, it’s a classic display hack.
Not knowing who did it (compare Snowflake) or when it was done (compare the Minskytron) is some of a tradition. :slight_smile:

A PDP-1 version may need a sine/cosine lookup table, though. Unless we can somehow translate this to Minsky’s fast circles,

Regarding fast circles, here’s Minsky’s version, assuming an origin at the center (0/0)
(“times epsilon” is actually a division by shifts):

NEW X = OLD X – epsilon * OLD Y
NEW Y = OLD Y + epsilon * NEW X

This is an accidental variation of

NEW X = OLD X – epsilon * OLD Y
NEW Y = OLD Y + epsilon * OLD X

where we substitute epsilon for sin(θ) and 1 for cos(θ) in the full formula

NEW X = X * cos(θ) - Y * sin(θ)
NEW Y = X * sin(θ) + Y * cos(θ)

Notably, this sped up version results not in a circle, but in a spiral. To see, why this is, consider the determinant of the generating matrix, which must be 1 for any conic to meet, where it started, but is off by ε². Meaning, it’s spiraling out. The accidental variant evens this out, resulting in a determinant of 1.0, but it’s a actually a fat ellipse rotated by 45°, which is very close to a circle.

(Visualization from a blog post on the Minskytron, I’ve in writing for what is now ages. Ideal circle in blue. Both approximations improve with deminishing epsilon.)

We could manipulate this by either changing epsilon (meaning, it’s not symmetrical for x and y), or adding to the either coordinate in the process.

So, maybe there could be something done, based on

x = x - (y >> sy)
x = y + (x >> sx)

by manipulating either part inside of one of the parenthetical expressions…
If this works out, we should get a significant speed improvement for any older systems.

First some JavaScript experiments, then a PDP-10 version that runs on ITS or out of timesharing.


That’s amazing! I fully support any efforts to find out more about the history of this. It would be interesting to see how it fares with lookup tables - it might even be feasible on old systems when done that way - but note that the ARM port uses lookup tables, and that’s a 200MHz system. One would need to dial down the resolution and suffer a lower frame rate - but still, it might be very impressive.

I remember Paul posting that to Facebook some time back - so I did a version in my own RTB Basic (written in C, runs under Linux).

It’s not quite as short as RTB doesn’t allow multiple statements per line, but it’s still quite nice…



Somethings made that one look rather more spread out - and as such, I feel it gives more hints about structure, because things aren’t happening on top of each other. It’s still baffling (to me) as to how this works - how those iterations give rise to these pixels.

Regarding the PDP-10 version, is the sine routine (“COPIED FROM SPACEWAR”) still much the same as the Adam Associates routine from Nov 1960 (for the PDP-1)?
(There are updated and more advanced instruction, but, structurally… the constants look about the same, as well,…)

For a closer look, see Inside Spacewar! — Part 6: Fatal Attraction – Gravity

Try running it without the screen clear for a few seconds … It still produces a nice pattern…



I copied this from the mid-70s PDP-6/10 Spacewar, but checking the mid-60s version, it’s quite similar. It’s here:

I could well believe this is a more-or-less straight translation from PDP-1 to PDP-6, but I don’t know.

As far as I know, the PDP-6 port was done by Steve Russell himself. So, if this is based on this one, there’s some plausibility to this.

Or letting the older generations slowly fade into an alpha channel can look nice, too.

The lack of information on where the algorithm came from is the most frustrating thing. In particular, it’s the arbitrariness of the 0.025 increment in the frame parameter.

I’m also unsure how well (in terms of accuracy and speed) older transcendental mathematics routines handle larger and larger arguments. Maybe that adds interest to the output.

Can you post the source, please?

See EdS’ initial post and the link to stardot. The Sinclair BASIC version can be also seen running on a PC in the link to Paul Dunn’s post at the very end of that post (“says”).

Here is the SpecBAS source, modified only to run on the last version of the SpecBAS interpreter I can get to run on a Raspberry Pi:

10 CONST n=200
20 CONST r=2*PI/235
30 LET x=0
40 LET u=0
50 LET v=0
60 LET t=0
70 LET sz=200
80 LET sw=SCRw/sz
90 LET sh=SCRh/sz
110 ORIGIN -sw,-sh TO sw,sh
130 DO 
140 CLS 0
150 FOR i=0 TO n
160 FOR j=0 TO n
170 LET u=SIN(i+v)+SIN(r*i+x)
180 LET v=COS(i+v)+COS(r*i+x)
190 LET x=u+t
200 PLOT INK RGBtoINT(i,j,99);u,v
210 NEXT j
220 NEXT i
230 LET t=t+.025
250 LOOP 

This version didn’t seem to support the multiline code as originally posted. It also didn’t understand the TAU constant, much like myself. I’ve removed the unused variable y for clarity

It’s worth looking at The SpecBAS Reference Manual because the language has some idiosyncrasies.


I pleaded with Paul Dunn to find the original, and he obliged. The source of the algorithm is this:
Someone might want to approach the author and ask how it came about.


It looks like you’ve replaced it with 2π, while Gordon replaced it with the golden ratio, which could explain Ed’s observation that the activity is noticeably different. Gordon’s version is fiercely quick by any measure. :saluting_face:

1 Like

Ah. I’m not sure why I picked that - I suspect I just searched for a page of numbers and copy/pasted the wrong one. Putting

tau = 6.2831853072

in does make a more “denser” pattern but it’s essentially the same.

The maths in these demos is somewhat abstract- and I wonder how many iterations the original author went through before they stumbled on a nice pattern…

I wrote RTB to be fast - my aim was faster than PHP which wasn’t hard. I did a few lightweight tests with Pauls SpecBas though and I suspect he has the edge on similar hardware, but hindsight has taught me a few tricks I might apply to it when I get the time + energy. However running on a new-ish Intel i7 vs. a 200Mhz ARM does have many advantages…