Stay a while, stay forever: a C64 demo for VIPP Malta

Recently I attended the 10th Parallels VIPP Summit in Malta, which also marked 10 years of the VIPP program. VIPP stands for Very Important Parallels Professional: a group of IT professionals and community contributors in end-user computing (EUC) who give Parallels feedback on its products and strategy. Members meet with the product teams during the year, get early access to new releases, and come together once a year at the summit.

I’ve been a member since 2016, so this year I received a certificate for 10 years of membership.

The summit was well organised, and it was refreshing to see again that a vendor is genuinely interested in our feedback and actively engages with us. Christa Quarles, the CEO of Parallels, being there in person underlined that.

Compliments to Christian Aquilina, VP Product and Program Management at Parallels, Chris Marks and the whole team for a well organised meeting. I also want to thank Parallels for including a walking tour of Mdina, the old walled city in the middle of the island. Game of Thrones fans may recognise it: parts of King’s Landing in the first season were filmed there, and its main gate was the city gate of King’s Landing. When you travel somewhere for a meeting, it’s a shame to go home having seen only the hotel and the meeting room.

A breadbox in Malta

Most of the summit was about the future: where Parallels and its products are going next. So there was something nice about the contrast when Freek Berson brought a piece of the past: the newly released Commodore 64 Ultimate. It’s the original C64 hardware, rebuilt exactly, with some modern additions: HDMI output, and loading programs straight from a USB stick instead of a stack of floppies.

And not just to look at. Freek showed a Parallels RAS admin console running on the C64: a client written in BASIC, with a little embedded machine code for the crypto, that talks to a live Parallels RAS environment through a PowerShell gateway. From the C64 you can browse farms and session hosts, see the active sessions and even send a message to a user. The source is on GitHub.

Seeing it took me straight back. I wrote intros back in the day: your logo, shown before a popular game started. I have good memories of the computer meetings, like the monthly one in the Maaspoorthal in ’s-Hertogenbosch, where I live. Let’s be honest, they were copy parties. People brought their own computers and TVs, and in no time you’d see your intro running on screens all over the room.

How intros were made back then

An intro was a few kilobytes of pure 6502 machine code, packed in front of a game. You typed it in a machine code monitor on a cartridge like the Action Replay or the Final Cartridge, or, if you were lucky, in Turbo Assembler on the C64 itself. There was no PC next to it, no emulator, and no debugger beyond the monitor. When it crashed, you reset and started again.

The tricks were all about timing. The C64’s video chip (the VIC-II) draws the screen one line at a time, 50 times per second. If you change a register at exactly the right moment, the screen shows things the hardware was never designed to show:

• Raster bars: change the background colour on every line
• More sprites: reuse the 8 hardware sprites further down the screen
• Into the borders: open the side and top borders and put graphics there
• Illegal opcodes: use undocumented CPU instructions that saved a cycle or two in exactly the loop where it mattered

It’s been such a long time. I’ve forgotten how to make them. I’ve forgotten most of the 6502 instruction set, never mind the undocumented ones. Weirdly, I still remember lots of SYS and POKE commands:

• POKE 53280,0 : POKE 53281,0 turns the border and background black
• SYS 64738 resets the machine
• SYS 49152 starts the machine code you just loaded at $C000

But Freek really opened a rabbit hole. With the AI and agentic AI tools we have today, could we make an intro like that again?

The VIPP demo

I asked Claude Code, the AI coding agent I use daily, for “a fun c64 demo, perhaps in the old style with a bouncing logo and scroll all VIPP members”, with one condition: it had to run on the real hardware, so the real limits apply. I sent along the VIPP logo and a screenshot of an old demo for inspiration.

It set up a complete toolchain itself:

• 64tass, a 6502 assembler
• VICE, a cycle-exact C64 emulator, which it also scripted as a test instrument
• Python, which generated every graphic
• Exomizer, which packs the result into a single file. It had to compile Exomizer from source, because there are no Windows builds any more.

About ten minutes later the first version was running: the VIPP logo as sprites, a scroller and music.

Over the next few hours we built it up to this:

• The logo: VIPP, shaded by hand in pixel-art style, bouncing on a sine and gravity curve
• The “10”: a separate logo for the 10-year anniversary, bouncing on its own path
• The scroller: an Ocean-style gold font greeting all VIPP members, over Rob Hubbard’s Commando
• The attack: when the “10” bumps into VIPP, both freeze, a laser gun slides in and shoots the “10” three times, and it explodes in fire. That one was a request: Leee Jeffries asked for lasers and explosions
• The reflection: the scroller is mirrored in rippling water underneath

The hardware still says no

The fun part was watching the AI run into the same walls we did in the eighties, and get around them the same way.

Eight sprites, and not one more. The VIC-II shows at most 8 sprites on one line. The VIPP logo is 21 sprites (3 rows of 7, reused per row), and the “10” is the eighth. So on every line with the logo there was no sprite left for a gun. The solution became the choreography:

• When the “10” bumps into the logo, it recoils just far enough to be above or below it.
• In that free band, the gun borrows one of the logo’s sprites, and gives it back halfway down the screen, before the logo needs it again.
• The laser beam isn’t a sprite at all. It’s the background colour, switched on and off within the line at exactly the right CPU cycle, so the beam stops exactly at the “10”.

63 cycles per line. A PAL C64 has 63 CPU cycles per screen line. With 8 sprites on that line, about 44 are left. The first version needed 50 now and then, so the logo occasionally broke up. The AI found that by stepping through the emulator frame by frame and measuring on which line and cycle its code ran.

Turn a limit into an effect. Multicolour sprites share two of their colours. While the “10” burns in fire colours, the whole VIPP logo picks them up too, as if the blast lights it. That came out of a hardware limit, not a plan.

How we worked

Some things made this work, and they’d work for any project:

• Previews first. Early on the AI started changing the logo on its own, and I said “show me first before changing it”. From then on every visual change started as an image with a few options: logo A or B, which font, which explosion. I picked and it built.
• It didn’t trust its own screenshots. It noticed that emulator screenshots in fast-forward mode skip frames and catch half-drawn screens. So it wrote its own tool: VICE stops once per frame, at a fixed point after the frame is drawn, and saves an exact image. It then checked 50 consecutive frames automatically, and searched frames pixel by pixel for artefacts. That’s how it found a VIC-II bug I’d long forgotten: on newer C64s, every colour change in the visible area leaves a grey dot.
• It measured instead of eyeballing.
  • It checked the motion with positions dumped from memory, not by looking.
  • It recorded the music as WAV files and compared them with the original player’s: a 98.5% match. That started when its sound effects had made the demo completely silent.
  • It checked the laser’s timing on the CPU cycle, over hundreds of frames.
• It said what it couldn’t check. It can’t listen. “I haven’t heard the result myself” came up more than once, and that’s where I came in.

A real TV and a real CRT

When it ran on the real C64, I noticed how good the graphics look over HDMI: razor sharp. Almost too sharp, because I remember them differently. An old CRT TV showed C64 graphics much smoother and less blocky, and artists designed for that:

• The signal blurred. Most of us connected through the RF or composite input. That smeared each pixel a little into its neighbours, and colours bled into each other horizontally. Pixel edges softened, and the “staircases” on slanted lines largely disappeared.
• Dithering became colours. With only 16 colours, artists placed two colours in a checkerboard. On a CRT those blended into a new, in-between shade. On HDMI you see the checkerboard. Our water reflection does exactly that: on a TV it would melt into a dark purple.
• Wide pixels and scanlines. Multicolour mode uses pixels twice as wide. On a CRT, the glowing phosphor and the dark gaps between scanlines made them look rounder and less like blocks.

So the art was made for the screen of the time. HDMI shows what’s really in memory, pixel for pixel.

Impossible Mission

Then I thought of Impossible Mission by Epyx. I remember it as state of the art when it came out in 1984, and given the graphics and development tools of the time, I honestly still think it is. Your agent runs, jumps and somersaults through an underground base more smoothly than anything else then. Dennis Caswell, its designer, reportedly took those movements from photos in a library book about athletics.

And the sound was very special. A computer that talked: “Another visitor… Stay a while… STAY FOREVER!” That was a real novelty. The speech came from a company called Electronic Speech Systems. Then there’s the scream when the agent falls into a gap.

So I asked: could we add a mode, under the SPACE bar, that pays tribute to it? A self-playing version, with the agent visiting five rooms where the security terminals show Parallels products: RAS, DaaS, Secure Workspace, Browser Isolation and Desktop.

About VIPP Mission: this is not a game, and not a remake. You can’t play it. It is a short tribute to Impossible Mission (designed by Dennis Caswell, published by Epyx in 1984): a self-playing sequence that runs by itself on a loop. We made it for one private event, the Parallels VIPP Summit, as an homage to one of the best-loved C64 games. It uses graphics, sounds and speech from the original game, taken from our own copy. All rights to Impossible Mission remain with its rights holders. The tribute is not distributed: there is no download, and the original game data is not in our repository.

Reverse engineering a 1984 game, live

This is where it got really interesting. The AI loaded the original into the emulator and read its memory and code. Some things it couldn’t get on its own, though: it can’t play with a joystick in real time. So we split the work:

• I played. It mapped the cursor keys to the joystick and gave me a checklist: ride the lift, run, somersault, search furniture, get zapped by a robot, use a terminal.
• It recorded. While I played, its tool logged sprites, positions and the sound chip, and saved snapshots of the whole machine every five seconds.
• It replayed and measured. With those snapshots it went back to any moment and took exact measurements:
  • the agent’s 28 animation frames, each made of three sprite pieces
  • 5 pixels per step, one step every 3 frames, 76 pixels per somersault
  • the lift hum, which doesn’t just stop but spins down: one voice drops by 3 per frame, the other by 4, one frame later
  • the speed of a fall
• The rooms came from the game itself. It let the original game build all 32 rooms and read them out, and I picked five.

Every time I watched, I had small corrections:

• “the elevator humm doesn’t stop when the elevator stops”
• “we’re missing the opening tune”
• “it doesn’t die when hitting robot or beam from the robot?”
• “the node map is not drawn when the elevator moves”
• “is the death scream also in?”

Each one led to a measurement in the original and an exact rebuild.

The talking computer, again

The speech is the original engine with its 6 KB of samples. It plays by switching the C64’s master volume very fast. That trick depends on a quirk of the original 6581 sound chip; on the newer 8580 it’s about six times quieter. The AI measured that with WAV recordings. It then added a check that detects which chip is present, and on an 8580 it uses the “digi boost” trick from the eighties. It also told me straight that this only gets it to about half the level, and that I’d better set the Ultimate to a 6581.

When the agent kept dying

I’d asked for exactly one death per loop. At one point I mentioned, almost in passing: “fyi it’s in the dying loop now”. The agent came back at the door, repeated what had killed him, and died again, forever.

The fix was the cleverest part of the project. The AI wrote a simulator of its own game engine that runs every tick of a loop. It plans the agent’s route against that simulation: when to run, when to somersault over a robot, how long to search. The build now fails if a loop has any death that wasn’t planned. VICE then confirmed the simulation “to the tick”. In the end there are two deaths per loop, both planned: a robot’s zap, and a fall with the original scream.

A bug we only saw while making this blog

For this post we recorded the demo as video: every frame, with sound. The demo was spot on. The mission video came out 2.5 seconds shorter than its audio.

It turns out the mission blocks its frame interrupt for up to 7 frames each time it draws a new scene, 121 frames per loop. Nobody had noticed in two weeks, because those frames are scene changes. Only putting the sound next to the picture showed it: sound is a clock that doesn’t skip.

The fix was in the spirit of the project. The demo already uses one of the C64’s timers, ticking once per screen line, for the laser. The recorder now uses a second, free timer to count those ticks, so every frame knows how much time really passed.

The whole thing

In numbers:

• about a day of work, with a night’s sleep in between
• 8 versions
• about 5,000 lines of 6502 assembly and 4,600 lines of Python tooling
• the full 64 KB used, including the RAM hidden under the I/O chips
• packed into one 25 KB file

Curse you, Freek

What I take away from this: I was the director, the ears and the joystick. The AI wrote the 6502, the tools and the tests, and it was honest about what it couldn’t check. All the tricks I’d forgotten were back within a day, plus a few I never managed back then.

So I curse Freek. I can’t wait to dig up the Commodore 64s I still have, and finally make the stuff I always wanted to make back then but never could.

Music: Commando by Rob Hubbard. Impossible Mission (Epyx, 1984): graphics, sounds, speech and rooms from the original game, for a private event.

A note on how this post was written: I used AI assistance. Claude helped with the project and made the first draft from my notes. It was not written automatically: I steered the work, reviewed the draft, corrected what was wrong and rewrote parts in my own words.