If you grew up playing videogames in the 1980s like me, there are a few things you probably remember quite clearly. The sound of loading a game from a 5.25″ floppy disk, the distinctive smell of electronics warming up, the strange feeling of being part of a technological revolution without really knowing where it would take us.
And, of course, dying.
A lot.
Especially if you were playing Ghosts ’n Goblins.
Released by Capcom in 1985, Ghosts ’n Goblins introduced Sir Arthur, a brave knight whose heroic mission was to rescue a princess from an army of undead creatures, demons and other unpleasant inhabitants of the underworld. Unfortunately, Arthur’s shining armour was apparently manufactured by the same company that produces disposable kitchen foil: one hit, and our hero was running around in his underwear. Another hit, and it was game over.
And don’t get me started on having to finish the game twice.
The original arcade game celebrated its 40th anniversary in 2025. Its famously difficult Nintendo Entertainment System (NES) version arrived in 1986, making 2026 its own fortieth anniversary. But 1986 was also a rather significant year for another machine.
On September 15, Apple introduced the Apple IIgs, the most advanced member of the Apple II family.
Forty years later, I thought it would be a nice idea to bring these two anniversaries together.
What better way to celebrate than making Ghosts ’n Goblins run on a computer that never officially received it?
Happy birthday, Apple IIgs. You’re not dead yet.
There’s something rather poetic about the Apple IIgs turning forty in 2026.
Introduced in September 1986, it was supposed to represent the future of the Apple II family. A 16-bit processor, improved graphics, an impressive Ensoniq sound chip, support for a graphical user interface and back-compatibility with the huge existing Apple II software library developed in the previous 10 years.
It was a remarkable machine, technically ambitious and, in several respects, ahead of its time.
It was also a computer caught in the middle of Apple’s changing priorities.
The Macintosh was becoming the company’s future, while the IIgs increasingly looked like an inconvenient reminder of its past. Meanwhile, the Commodore Amiga and Atari ST were establishing themselves as attractive alternatives for gamers and creative users, with their 32bit CPUs, dedicated graphics systems and no ties with the past to be kept alive, at computing-performance and speed costs.
The IIgs survived until 1992, but the gaming library it could have had never fully materialised.
And yet, forty years later, something rather unexpected is happening.
The Apple IIgs is experiencing a small renaissance.
New software projects, ports of classic games, hardware improvements, bug fixes, emulators and modern development tools are making this old machine considerably more interesting than its age would suggest.
What makes the current moment particularly fascinating is the arrival of generative artificial intelligence as a development tool. Over the last few months, AI-assisted programming has begun to dramatically accelerate reverse engineering, code conversion and software porting across the retrocomputing world.
Projects that once required enormous amounts of specialised knowledge and spare time can now be approached by smaller teams, sometimes even by a single enthusiast working with an AI assistant. This doesn’t make the technical challenges disappear. It does, however, change who can attempt to solve them.
And the IIgs, with its peculiar architecture, underexplored potential and relatively small development community, seems an especially interesting candidate for this new wave of experimentation.
There is even renewed discussion around the possibility of another community-driven release of its operating system, GS/OS.
Apple’s last official System Software release was 6.0.1, back in 1993. Enthusiasts subsequently maintained and improved the system through unofficial releases, including System 6.0.2, 6.0.3 and 6.0.4. The possibility of a further community-maintained update is an exciting one, although it should still be treated as a prospect rather than an announced release.
Think about it for a moment.
A computer introduced in 1986, discontinued in 1992, potentially receiving renewed operating-system development in 2026.
Not because Apple decided to resurrect it. Because a community of enthusiasts simply refuses to let it go.
And perhaps because AI is beginning to make some previously impractical projects more achievable.
I find this far more interesting than another annual smartphone upgrade.
Enter silky-gs: not quite emulation, not quite a traditional port
My adventure began with an impressive open-source project by Lucas Scharenbroich, called silky-gs.
The idea behind it is rather fascinating.
Instead of emulating an entire NES on the Apple IIgs, which would be extremely demanding for a 2.8 MHz machine, silky-gs takes the original game’s 6502 machine code and adapts it to execute natively on the IIgs’s 65816 processor.
A compatibility runtime handles the differences between the NES graphics and sound hardware and the facilities provided by the IIgs.
In other words, the Apple IIgs isn’t simply pretending to be a Nintendo console. It is running an adapted version of the original game code, while another layer translates the hardware operations. This approach makes things possible that would otherwise be extremely difficult on an unaccelerated machine.
Looking at the project, I started wondering whether Ghosts ’n Goblins could join the growing collection of NES titles adapted for the platform. After all, what could possibly go wrong?
Well, quite a few things, actually.
Me, Claude and a forty-year-old game
Here comes the part that would have sounded like science fiction to anyone writing videogames in 1986.
Much of the technical work on this port was carried out in collaboration with Claude, Anthropic’s AI assistant.
My role was to initiate and guide the project, select the game, establish priorities, evaluate results and coordinate the testing and optimisation process. Claude worked on analysing the original code, adapting it to the silky-gs framework, identifying bugs, preparing Git patches and running tests.
In practice, it became an unusual exercise in collaborative programming.
Not traditional software development, but not quite the simplistic idea of vibe coding either. We were dealing with actual 6502 and 65816 assembly, memory addresses, CPU cycles, graphical buffers, hardware registers and the very real limitations of a machine designed four decades ago.
And, rather importantly, we were building on the work of an existing open-source community.
Without silky-gs and the knowledge accumulated by its developers, this experiment would have been a very different proposition.
The result was GhostsGS, an Apple IIgs adaptation of the original NES version of Ghosts ’n Goblins.
The game could run. Arthur could move, jump, fight enemies and, naturally, die rather frequently.
But making it run was only the beginning.
Making it run efficiently was another matter entirely.
When 2.8 MHz really means 2.8 MHz
Modern computing has spoiled us. We have processors running at several gigahertz, graphics cards capable of processing millions of polygons and operating systems that cheerfully consume gigabytes of memory before we’ve even opened an application.
On the Apple IIgs, every CPU cycle counts.
And Ghosts ’n Goblins, with its moving enemies, projectiles, scrolling backgrounds and constant activity, is hardly the simplest game to reproduce.
Our first optimisation efforts focused on the sprite engine and memory operations.
One routine was filling sprite buffers by writing the same value one byte at a time, with a separate subroutine call for each byte. Replacing it with native 65816 code capable of processing two bytes at once reduced the overhead considerably.
Another improvement involved pointer-based memory operations, replacing expensive helper routines with shorter instructions while retaining the necessary safety checks.
Individually, these changes might sound insignificant. Together, however, they produced measurable results.
Across equivalent sequences of 6,000 NES frames, the optimised game executed 31% fewer instructions during gameplay and 22% fewer during the title-screen demonstration. On a stock-speed IIgs, the CPU time devoted to the game logic during scrolling dropped from approximately 26% to 19%.
Unfortunately, this didn’t make the entire game 31% faster.
Most of the time saved by the game logic was absorbed by the graphics system, with the visible update rate improving only modestly, from approximately six to six and a half screen updates per second.
Still, the optimisations gave the game logic more breathing room. And they helped us discover where the real performance problem was hiding.
Sometimes the best thing to draw is nothing
During the investigation of silky-gs’s rendering engine, Claude identified a rather curious bottleneck. When an NES game disabled its background, the IIgs runtime would clear the entire screen to black.
Every frame.
Even if the screen was already black.
Imagine painting a wall black, waiting a few milliseconds, and then painting it black again. And again. And again.
Not exactly an efficient use of computing resources.
Interestingly, the original code already contained a comment suggesting that unnecessary blank-line updates should be avoided.
The optimisation simply hadn’t been implemented yet.
The solution was to keep track of which screen lines were already blank and redraw only those that had actually changed.
This was particularly interesting because the improvement wasn’t specific to Ghosts ’n Goblins. It could potentially benefit other games using the same runtime.
Using an Apple IIgs emulator, we tested a reproducible sequence of 1,800 NES frames covering the title screen, introduction, map and beginning of the first level.
Before the optimisation, the sequence took 62.97 seconds. Afterwards, 49.13 seconds.
A 22% reduction in execution time for that benchmark.
Not bad for deciding that sometimes the computer should simply do nothing.
There was, of course, a catch.
The improvement mainly affects transitions, maps, introductions and other sequences with disabled backgrounds. It doesn’t solve the much more difficult problem of scrolling gameplay, where large portions of the screen really do need to be updated.
And writing an entire 32 KB Super Hi-Res screen buffer on a 2.8 MHz Apple IIgs isn’t exactly cheap.
Nevertheless, the optimisation was isolated into a patch suitable for submission to the original silky-gs project. Which brings us to another important aspect of this experiment: contributing improvements back to the tools that made it possible.
The case of the missing joystick buttons
Then came the inevitable real-world bug report.
Someone testing GhostsGS with a classic Mach III joystick reported that buttons 0 and 1 weren’t working.
Arthur could move around, but couldn’t jump or throw his weapons.
A rather serious problem when dealing with an army of zombies.
The cause was buried in the peculiarities of Apple hardware. The original implementation relied on the keyboard modifier register at $C025, which could detect the Command and Option keys. Unfortunately, physical Apple joystick buttons are exposed through different hardware addresses: $C061 and $C062.
The two mechanisms had been assumed to be equivalent.
They weren’t.
The solution was to read the joystick button inputs directly from the appropriate registers. Button 0 now fires, while button 1 jumps. Keyboard controls continue to work as before. The correction passed the automated tests, including combinations of directional inputs and both buttons.
And that is a useful reminder of something fundamental: even an AI capable of producing thousands of lines of assembly code can misunderstand a hardware interface.
A successful build doesn’t necessarily mean a successful program. And an emulator doesn’t necessarily reproduce everything a real computer does.
Seven games, 42,000 frames, and a lot of patience
One aspect of the project that I particularly appreciated was the effort spent verifying that the port remained faithful to the original game.
Rather than simply checking whether Arthur appeared on the screen and moved around, we compared the port’s behaviour against the NES reference. Seven gameplay sequences, each lasting 6,000 frames, were checked. That’s 42,000 frames of comparisons covering game memory, graphics, colour palettes and sound.
The tests passed.
This doesn’t mean that every possible situation has been tested, or that the IIgs reproduces the original NES rendering speed. But it does mean that the underlying game behaviour was preserved across those reference sequences. And that’s important.
The objective wasn’t to create something that merely looked like Ghosts ’n Goblins.
It was to bring the original game to another architecture, preserving as much as possible of its logic and behaviour.
Including its unreasonable difficulty.
Especially that, perhaps.
AI and the unexpected second life of old computers
There is something larger happening here, and I think it’s worth discussing.
For decades, retrocomputing has depended on a relatively small community of dedicated programmers, hardware enthusiasts, collectors and preservationists. Their work has been extraordinary. But it has also been constrained by time.
Reverse engineering an undocumented program, porting an entire game engine or fixing a forty-year-old operating system can require months or years of highly specialised effort.
Generative AI is changing this equation. In recent months, the wider retro-gaming scene has seen a remarkable acceleration in experimental ports, decompilation projects, compatibility fixes and previously improbable software adaptations.
Old games are suddenly appearing on platforms where nobody expected to see them. Obscure hardware bugs are being investigated. Forgotten codebases are being revisited.
For a computer like the Apple IIgs, this is potentially transformative.
Not because AI has suddenly made its processor faster, or its graphics hardware more capable.
But because the most limited resource in retrocomputing has often been human development time, rather than computing power.
AI-assisted tools can help read unfamiliar assembly code, trace dependencies, translate programming languages, identify optimisation opportunities and build repeatable testing environments. They can also make it easier for enthusiasts with different backgrounds to participate.
People who understand the history, the hardware or the experience they want to recreate may now be able to initiate projects that previously required a dedicated assembly programmer from day one.
That doesn’t mean expertise has become unnecessary. Far from it.
AI-generated code can be incorrect, inefficient or dangerously convincing. It can overlook hardware details, introduce subtle bugs and make changes whose consequences are difficult to understand.
And there is a serious risk that a flood of AI-generated projects could obscure the work of the people who spent years documenting, reverse engineering and maintaining these platforms.
This is already generating difficult conversations in the wider videogame preservation community.
Who deserves credit? How should AI-assisted contributions be reviewed? What happens when someone creates a quick derivative project without understanding or acknowledging the foundations on which it depends?
These aren’t trivial questions.
In my view, the most interesting use of AI isn’t replacing the retrocomputing community.
It’s expanding what that community can accomplish, while preserving the knowledge, credit and collaborative practices that made these projects possible.
Which is also why I would rather see our rendering optimisation merged into silky-gs than keep it as an isolated improvement to GhostsGS. And why the idea of a renewed, community-driven GS/OS is so compelling.
It would mean that the current wave of activity isn’t limited to individual games or technical demonstrations. It could also strengthen the foundations of the platform itself.
Forty years after its introduction, the Apple IIgs has entered one of its most interesting periods of community-driven development. Nobody would have predicted that in 1986.
A new kind of digital preservation
There is also an educational dimension to all this.
I often write about digital literacy, creativity and the importance of understanding technology rather than merely consuming it. Retrocomputing offers a particularly interesting example. These machines expose the relationship between software and hardware in a way that modern computers often conceal.
You can see the consequences of a memory access. You can measure the impact of a single instruction. You can understand why a certain graphical effect is expensive, or why a controller button doesn’t respond.
And now, AI adds another layer.
It can help people explore systems they might otherwise find inaccessible, but only if they remain willing to question its answers.
A forty-year-old computer, a forty-year-old videogame and a contemporary AI assistant become an unlikely learning environment.
One where the objective isn’t merely to make something work, but to understand why it works.
Or, quite often, why it doesn’t.
Perhaps this is one of the more interesting possibilities of generative AI: not automating creativity out of existence, but lowering some of the barriers that prevent people from exploring complex technical ideas. And rediscovering the pleasure of building things simply because they are interesting.
Forty years later, sir Arthur is still fighting
So, where does GhostsGS stand today?
Ghosts ’n Goblins has been adapted to run on the Apple IIgs using silky-gs, with working builds, optimisations to the game code, reproducible benchmarks, automated reference tests and improvements to rendering and input.
The resulting disk image, GhostsGS.2mg, can be launched in an appropriate Apple IIgs environment.
The technical changes will end up into Git patches, including sprite-engine optimisations, the rendering improvement, benchmarking tools and the joystick-button fix.
There is still work to do.
Scrolling performance remains limited on a stock-speed IIgs. Real-hardware compatibility deserves further testing. And improvements to the shared silky-gs runtime are worth discussing and reviewing with its original developer.
But perhaps the most interesting part of the story is the timing.
2026 marks forty years since Apple introduced the IIgs and Nintendo players first experienced Sir Arthur’s adventures on the NES.
It also marks a moment when advances in artificial intelligence are giving retrocomputing enthusiasts new opportunities to experiment with machines that commercial software developers abandoned decades ago.
And, somewhere in the community, people are even discussing the possibility of updating the IIgs operating system again.
Not bad for a supposedly obsolete computer.
There are certainly easier ways to play Ghosts ’n Goblins today.
You could use an NES emulator, a modern console, or any number of vastly more powerful computers.
But where would be the fun in that?
Retrocomputing has never been about finding the easiest solution.
It’s about exploring what could have been, discovering what is still possible and refusing to accept that a machine’s story necessarily ends when its manufacturer stops supporting it.
Sometimes it also means spending an unreasonable amount of time saving a few CPU cycles just to make a tiny knight in his underwear fight a few more zombies.
Forty years after their respective debuts, Arthur and the Apple IIgs have finally met.
One is still fighting monsters.
The other is still fighting obsolescence.
And, surprisingly enough, both are doing rather well.
GhostsGS is an independent, non-commercial retrocomputing experiment based on the remarkable silky-gs project by Lucas Scharenbroich. Credit goes to Lucas and the Apple II community for the tools, documentation and knowledge that make this kind of experimentation possible.
Ghosts ’n Goblins is © Capcom. This is not an official Capcom release.