Old Screensavers

I've been interested in screensavers ever since I got my got my first PC running DOS and Windows 3.1 in my senior year of high school. Soon after getting it, I had a copy of After Dark installed, and I spent a long time watching the Satori screensaver as it rendered and animated.

But before that, I was fortunate enough to be able to play with my dad's Apple computer when I visited him on weekends, and later I got a C64 at my house. I spent a lot of time on both machines making the screen do random stuff. The Applesoft Programming manual (one of the books where I started to learn about programming) had a series of BASIC programs to make a bouncing ball, and I spent many hours tweaking the code in it. We only had a monochrome display so the output wasn't too vibrant, but it was definitely fun. The C64 manuals had similar BASIC code, and it had colors too so it was a lot of fun.

Recently I've spent a bunch of time researching old screensavers. I wanted to learn more about After Dark and the other famous examples of screensavers, but I also wanted to learn about what came before them. I decided I would do a bunch of digging and then maybe try and implement modern versions of old screensavers.

I wondered: what was the first screensaver?

Atari Attract Mode

I spent awhile researching screensavers in early computers. There's a certain amount of anecdotal data about old mainframes that had some sort of screensaver mode, but I wasn't able to verify any of them. Eventually I learned about the 'Attract Mode' in the Atari 400/800 series of computers. I'm not sure if it was the first screensaver, but it's definitely one of the earliest, and maybe the first that did something other than just simply blanking the screen. Here's a description from the first issue of Page 6 Magazine, an 80s era newsletter/magazine devoted to the Atari:

One of the many excellent features included in the ATARI Computers is the automatic screen protection systems called the "ATTRACT MODE". This system initiates a continuous rotation of colours on the screen as protection against "burn through" which may occur when a colour is displayed for too long without change. The computer monitors the use of the keyboard and will automatically enter the "ATTRACT MODE" if no keys have been depressed in the previous 9 minutes (9.01 to be precise). As soon as the keyboard is used, the "ATTRACT MODE" is disabled and the original screen colours return.

The term 'attract mode' dates back to arcade machines, and probably originated with pinball machines. Here's Wikipedia's definition in the Glossary of Video Game Terms

Also known as display mode or show mode, attract mode is a pre-recorded demonstration of a video game that is displayed when the game is not being played.[3] Originally built into arcade games, the main purpose of the attract mode is to entice passers-by to play the game.[3] It usually displays the game's title screen, the game's story (if it has one), its high score list, sweepstakes (on some games) and the message "Game Over" or "Insert Coin" over or in addition to a computer-controlled demonstration of gameplay. In Atari home video games of the 1970s and 1980s, the term attract mode was sometimes used to denote a simple screensaver that slowly cycled the display colors to prevent phosphor burn-in while the game was not being played. Attract modes demonstrating gameplay are common in current home video games.

Attract mode is not only found in arcade games, but in most coin-operated games like pinball machines, stacker machines and lots of other games. Cocktail arcade machines on which the screen flips its orientation for each player's turn in two-player games traditionally have the screen's orientation in player 1's favour for the attract mode.

Some pinball machines even had attract modes that would actually run balls through the game. The Pinball Game Centaur II had an attract mode that caused 'all five balls to automatically shoot onto the playfield every 15 minutes to interact with the pop bumpers and slingshots until they drain' although apparently this would wear out the surface of the machine over time.

The Wikipedia article on screensavers seems to think that attract mode doesn't count, although I can't comprehend how this could be the case:

The Atari 400 and 800's screens would also go through random screensaver-like color changes if they were left inactive for too long. The user had no control over this. These computers, released in 1979, are technically earlier "screen savers." And prior to these computers, the 1977 Atari VCS/2600 gaming console included color cycling in games like Combat or Breakout, in order to prevent burn-in of game images to 1970's-era televisions. In addition, the first model of the TI-30 calculator from 1976 featured a screensaver, which consisted of a decimal point running across the display after 30 seconds of inactivity. This was chiefly used to save battery power, as the LED display was more power intensive than later LCD display models. These are examples of screensavers in ROM or the firmware of a computer.

(I love the bit about the TI-30 screensaver as well)

I thought it would be a fun exercise to try and re-implement the Atari attract mode in Processing. Since I never owned an Atari computer (and in fact, I can't remember ever seeing or using one), the first thing I did was boot up an Atari emulator so I could get a look at the actual output.

8-bit machines allowed you to issue PEEK and POKE commands which would toggle different values in the memory of the machine. You could use this to play sounds, fiddle with video output, and fiddle with the operating system in all sorts of interesting ways. Sometimes the addresses you needed to know were common knowledge, other times you would learn about them from friends or magazine articles. Either way, they were generally a fun way to mess with your computer.

In order to trigger attract mode after a certain period of idle time, the Atari stored a counter value at memory location 77, which was updated every four seconds. If the user hit a key on the keyboard, the value was reset to zero. Once it hit 127, attract mode would be triggered. Here's some simple BASIC code which sets the value to a pretty high number so that attract mode is triggered almost immediately:

5 POKE 77, 125
10 PRINT PEEK (77): GOTO 10

If you run this code on an emulator (or on an actual Atari), you will see something like this:

I tweaked the speed of this GIF to update every second or so, but on the emulator, it updated every nine seconds precisely.

What it Does

Here's a description of attract mode from the book Mapping the Atari, which is readable on the super-awesome atariarchives.org:

Attract mode rotates colors on your screen at low luminance levels when the computer is on but no keyboard input is read for a long time (seven to nine minutes). This helps to save your TV screen from "burn-out" damage suf- fered from being left on and not used. It is set to zero by IRQ whenever a key is pressed, otherwise incremented every four seconds by VBLANK (see locations 18 - 20; $12 - $14). When the value in ATRACT reaches 127 ($7F), it is then set to 254 ($FE) un- til attract mode is terminated. This sets the flag to reduce the luminance and rotate the colors when the Atari is sitting idle. POKE with 128 ($80) to see this effect immediately: it normally takes seven to nine minutes to enable the attract mode.

When I read this for the first time, I realized how little I remembered, or even ever new, about how old 8-bit machines worked. I had no recollection of what VBLANK was, so I had to look it up:

vertical blanking interval (VBI), also known as the vertical interval or VBLANK, is the time between the end of the final line of a frame or field and the beginning of the first line of the next frame.

Basically, it's the short period of time when a computer would do everything that wasn't related specifically to putting an image on the screen.

Here's a bit of the VBLANK routine that handles attract mode.

;
; SYSTEM VBLANK ROUTINE
;
; INC FRAME COUNTER. PROCESS COUNTDOWN TIMERS. EXIT IF I WAS SET. CLEAR
; SET DLISTL, DLISTH, DMACTL FROM RAM CELLS. DO SOFTWARE REPEAT.
;
SYSVBL: INC   RTCLOK+2   ;INC FRAME COUNTER
          BNE     SYSVB1
          INC     ATRACT        ;INCREMENT ATRACT (CAUSES ATRACT WHEN MINUS)
          INC     RTCLOK+1
          BNE     SYSVB1
          INC     RTCLOK
SYSVB1: LDA   #$FE        ;{ATRACT] SET DARK MASK TO NORMAL
          LDX     #0             ;SET COLRSH TO NORMAL
          LDY     ATRACT        ;TEST ATRACT FOR NEGATIVE
          BPL     VBATRA        ;WHILE POSITIVE DONT GO INTO ATRACT
          STA     ATRACT        ;IN ATRACTI SO STAY BY STA $FE
          LDX     RTCLOK+1   ;COLOR SHIFT FOLLOWS RICLOK+1
          LDA     #$F6        ;SET DARK MASK TO DARK
VBATRA: STA   DRKMSK
          STX     COLRSH
          LDX     #0             ;POINT TO TIMER1
          JSR     DCTIMR        ;GO DECREMENT TIMER1
          BNE     SYSVB2        ;BRANCH IF STILL COUNTING
          JSR     JTIMR1        ;GO JUMP TO ROUTINE

Pretty clear, right? I think what this is doing (my assembly code knowledge is weak) is something like this: - reset COLRSH and DARKMSK -- these are variables that dictate the colors used on the screen - increment the ATTRACT counter - ATTRACT is an 8-bit signed integer. That means the maximum value is 128. As the computer adds to the variable, eventually it will roll over and turn into a negative number. - When that happens, the routine sets DRKMSK to a value which will limit any bright colors from displaying on the screen, and cycle COLRSH according to the current time

Separately, the Atari takes the values of COLRSH and DRKMSK and uses them to draw the screen. I'm glossing over a bunch of details here, if you'd like to learn more you should read the Atari Home Computer Technical Reference Notes 1982 section on attract mode.

So now what?

Having tracked down the code, and gotten an idea of how it worked, I tried to dig up the Atari color palette. The first thing I found was this somewhat terrifying article from A.N.A.L.O.G. magazine:

The colors fall into sixteen different classes, or hues, each with sixteen different lightnesses, or luminances, numbered 0 through 15. Some modes on some models may ignore oddnumbered luminances, displaying the next lowest even luminance. To find the value for the color register that corresponds to the color you wish, take the number of the hue, multiply by 16 and add the luminance. The hue values may be found in Table 1, below. For example, the value for a dark red would be 4 (for red) * 16+2 (a low luminance value), or 66.

Here's a chart describing this from one of the Atari technical manuals:

I could understand this more or less, but I couldn't translate it to anything useful. Really all I wanted was to know the RGB values of the color palette of the Atari. In hindsight, this was totally naive of me. RGB wasn't used in computers until the mid 80s at the earliest, and even the notion of 'true color' wasn't really around until CGA monitors emerged. In fact, the Atari forums are full of debates about the color palettes of the different machines Atari produced, comparisons of how they rendered PAL or NTSC, or so on. Eventually if you dig into this enough, you will find yourself looking at weird color wheel images like this:

which is part of the CTIA specification -- the CTIA was one of the chips on the Atari which was responsible for graphics output.

I kept digging and found a couple examples of palettes that artists have produced for their art. They were all nice but it seemed like they had been tweaked to match a personal aesthetic, or had been tweaked to be more applicable to 8-bit art in general, rather than to the specific Atari palette.

I wanted to use the 'real' colors if I could. I thought about reading the source code for the emulator to see if I could find it there, but that seemed like a lot of work, so instead I decided to generate a palette on an Atari emulator, and then write some code to figure out the RGB values of the palette.

Luckily, people have already written this code in BASIC. I found this code, and ran it on the emulator:

10 REM * DISPLAY ALL 256 COLORS
11 GRAPHICS 9:FOR V=0 TO 15:COLOR V
12 FOR N=0 TO 4:PLOT 5*V+N,0
13 DRAWTO 5*V+N,191:NEXT N:NEXT V
14 D=256*PEEK(561)+PEEK(560)
15 FOR N=1 TO 16:READ V:POKE D+V,143
16 NEXT N:FOR N=0 TO 25:READ V
17 POKE 1664+N,V:NEXT N:POKE 512,139
18 POKE 513,6:POKE 546,128:POKE 547,6
19 POKE 53248,40:POKE 53249,208
20 POKE 53261,255:POKE 53262,255
21 POKE 53266,0:POKE 53267,0
22 POKE 54286,192
23 GOTO 23
24 DATA 16,28,40,52,64,76,88,102,114
25 DATA 126,138,150,162,174,186,198
26 DATA 8,72,169,0,133,203,104,40,76
27 DATA 95,228,8,72,165,203,24,105,16
28 DATA 141,26,208,133,203,104,40,64

And got this image:

Then, I wrote a ruby script using ImageMagick to read the output, and find the RGB values of the dominant colors in the output. Hooray!

Having gone through all of this, I decided to write a Processing script that would simulate attact mode. My first script was a very rough simulation of the BASIC code that I ran on the Atari emulator to generate the animated GIF above. It's pretty ugly, and doesn't operate at all like the original script because text functions so differently compared to how it did on old 8-bit machines, but here it is:

Next I decided I wanted to do something that actually looked nice, and had some passing relevance to 8-bit computing. I thought about remaking [@ARealRiverarealriver as an 8-bit screensaver (and I still might), but for now I've made a script with output similar to the 10 GOTO 10 script from 10 PRINT CHR$(205.5+RND(1)); : GOTO 10.

I fiddled for awhile, trying all sorts of variations, and I ended up with a set of scrolling lines, with a background and margin, all of which cycle through the available color palette. Here it is:

If you click 'fullscreen' it's almost like an actual screensaver.