Find the door control
Move your pointer across the map. Plain-language labels show you the key check, alarm, and door status.
RETRO-MODERN // WORKSHOP FILE 0001
BREACH is a working title and will be replaced.
You hack a door control.
Your code really runs.
You play a netrunner hired to open an electronically secured door. To do it, you inject small programs into its control system – while a guardian program hunts them.
BREACH in 20 seconds
Open the door. Outsmart the guard. Erase your trace.
BREACH is a tactical hacking game. You need no programming skills or C64 knowledge: the game turns the computer into a readable map and your programs into four simple tools.
Inject a tool
Place one of your small programs and run it: read, spoof, distract, or slow the guard down.
Beat the ICE
The digital guard searches for your code. If it finds it, the code is erased and your trace rises.
Your goal: Open the door, erase the code you injected, and disconnect before your trace fills up.
Video / early development build
The computer inside the computer is running.
C64 × Ultimate 64 × target system
BREACH is working against a real 6502.
The video shows the early build in which the emulated target system is actually running inside the game. This is a workshop view—not a finished trailer or a release-date announcement.
Watch the video on YouTube ↗
Planned Target Corridor16 MB REU: C64 + 1541 Ultimate II+, Turbo Chameleon 64, Ultimate 64, C64 Ultimate, C77 or VICEThe compatibility list is still being verified. A standard C64 without expansion should not start: the world exists as a living state in memory.
The game without prior knowledge
Imagine a long corridor.
On its walls hang one hundred and twenty-eight numbered slots. Something lies in each one. Together, they control a door. There are signs on the slots: "checks the key", "triggers the alarm", "indicates if the door is open".
You walk down the corridor, look for the right slot, and place something of your own inside. Then you press start – and the door opens.
But a guard is walking in the same corridor. He opens slot by slot and checks if something is there that doesn't belong. You can see where he is. You can place your thing in a slot he has just checked. Or you can place something that stops him.
And because the guard himself is located in one of these slots, you can reach him – if you are fast enough.
The winner is whoever has the door open and takes their stuff back before the guard comes across it.
Four actions, that's all it takes: look, place, start, remove. No prior knowledge, no programming skills – the game writes the signs on the slots.
Beneath that lies real machine code. You notice this by the fact that things can happen that no one intended – not by the fact that you would have to understand it.
One job / five colors / one clock
What happens on the screen
A fixer writes: Warehouse, Door 4, open at 11 PM. The door is connected to a small computer. The grid – the slots from above – is its memory: a readable hex dump, not a symbolic image.
- 01Green: foreign memory
The untouched program of the door control.
- 02White: your pointer
In the prototype, it is at
$0348– where the door status is located. - 03Cyan: your code
Five bytes, just written into the target system.
- 04Red: the ICE
A guardian program that searches the memory cell by cell.
- 05TRACE 22 %
How far the backtracking has progressed in this visible prototype.
DOOR: OPEN // ICE: 71 CELLS // TRACE: 22 %
The door is open. Now you have to disappear again.
The ICE is just about to reach your code. The planned time pressure is not created by a staged countdown, but by a program that runs over the same memory. On fast hardware this program keeps running in real time while you think; on an ordinary C64 it takes a turn whenever the player takes one.
Status of the image: Grid, pointer, Daemons, injecting, executing, wiping, ICE, trace, as well as winning and losing are playable. Since the end of August the target system really calculates too — the screenshot shows an older state.
Four actions / nothing more
Read. Write. Execute. Gone.
Read
Move the pointer over the grid. Plain text is displayed below it: "checks the key", "triggers alarm" or "door status".
INJECT
Write a Daemon to a place of your choice. The position is the actual decision.
EXECUTE
Let the injected Daemon run and observe what the target system does with it.
WIPE
Delete traces and disconnect the connection before the ICE reaches your code.
MINE · reads outSPOOF · fakesGHOST · places a decoyICEPICK · slows down
No one has to read machine code. The bytes are real – but the depth remains optional. Those who don't zoom in read a labeled map and use tools.
Why this is a game
The ICE shares your memory.
If the guard actually works in the same memory, you don't just have to run away from him. You can place your Daemon behind the ICE, write a decoy in front of it, or risk placing your code directly into its routine.
The most exciting outcome would be one that no author has prepared: whoever overwrites running code can cause the target system to crash. Garbage in the grid. Door jams. Job lost – not as a script, but as a consequence of the wrong bytes.
Exactly this part now exists: the tested 6502 emulator has been inside the game since the end of August. The door control is real program code that really runs — no longer a rule that pretends.
BEHIND THE ICEPLACE DECOYOVERWRITE ICESHORT PATH / HIGH TRACE
Computer within a computer
Is there still a C64 running over there?
Almost – and the two deviations are exactly what's interesting. The target system is not a complete C64. A 6502 runs there with its own memory, but without VIC, SID or its own screen: a controller, such as those that could be in a door, an elevator or a camera.
This makes it small enough to emulate. And its entire memory fits as a visible grid on a C64 screen.
YOUR MACHINEC64 · TC64 · Ultimate 64 · Commodore 77
BREACHthe grid · the pointer · the bar
TARGET SYSTEMa 6502 with its own memory
- door control was already there
- the ICE searches for foreign objects
- you placed your Daemons inside
The ICE and your code are in the same memory.
The whole game depends on this. That's why "Where do I put this?" is a question at all. That's why you can hide behind the ICE, throw a decoy in its way, or write your code into the ICE. If they were two separate machines, none of that would exist.
WHO AGAINST WHOM?
First human against automaton. Then program against program.
At the beginning, it is asymmetrical: a human with a pointer against an automaton. As soon as you press INJECT, that tips. The Daemon is now itself a program on the same machine. From then on, two programs run against each other in the same memory – triggered by your action.
The ICE does not attack you directly. It searches for foreign code in the memory it guards. If it finds any, it deletes it and the trace jumps up: the abstraction for the fact that someone is backtracking to where the netrunner is sitting.
REAL, BUT ADJUSTABLE
The ICE is actually running. We wrote it, though.
That's why it can produce real, not individually prepared outcomes – and the difficulty remains controllable. A slow, blunt ICE for the first job; one that searches backwards, perhaps for the twelfth.
Workshop status: The emulator exists and is byte-verified:
netz.prg calculated 256 out of 256 bytes correctly. Since the end of August it is linked in the game: the ICE is no longer a counter but a program that is really worked through, step by step, inside the rebuilt machine.Same code / four planned tiers
Why additional computing time counts
A computer-within-a-computer costs in the current model approximately 30 host cycles per emulated cycle. At 1 MHz, this would leave only around 33 kHz for the target system. The C77 statement below is an extrapolation – measurements so far were taken on a real C64 and in a 20 MHz environment. TC64 and Ultimate 64 will be tested separately on real hardware.
AreaC64 + REUTC64Ultimate 64Commodore 77
Target Systemturn-based plannedturbo path planned, real test pendingreal test pendingfull C64 speed as extrapolation
Cyberspacewireframefilled surfaces as goal, test pendingfilled surfaces as goalfilled surfaces, fluid – target image
Sound3 SID voices as basisdual-SID emulation available, game path openMultiSID + samples possibleup to 24 SID voices possible
Statusdesign decisioncompatibility and performance test pendinghardware test pendinghardware not available
Calculation path, not promise: 77 MHz ÷ 30 would theoretically yield about 2.57 million emulated cycles per second. For a PAL-C64 cycle of around 0.985 MHz, approximately 29.6 MHz would be required; about 61.6% of the host time would remain. Firmware, memory accesses, video, I/O and real implementation can change this result.
Measurement 02 / SuperCPU 20 MHz
What is actually measured today
POLYGON does not yet prove Cyberspace, NETZ does not yet prove a finished target system. Together, however, they show that filled geometry and a 6502 emulator are verified as separate components.
Same file / different voice
The C77 keys already speak the game.
On official C77 images, RETURN says EXECUTE, INST/DEL says INJECT/WIPE. A classic C64 is intended to receive an overlaid key bar; on the C77, it could disappear because the action is written directly on the key.
This is a design goal, not a second build and not confirmed automatic C77 detection. Which registers the production unit offers will only be checked on real hardware.
RETURNEXECUTEINST/DELINJECT / WIPE
Workshop status / 02.09.2026
Playable is not finished.
Already running
- Grid and pointer
- four Daemons
- Inject, Execute and Wipe
- ICE and trace
- Winning and losing
- the target system really calculates
- approach and break-in as one round
- own font instead of the ROM character set
- runs as a cartridge
- measured on the Ultimate 64
Still missing
- Sound and terminal
- Story and further jobs
- drawn pictures instead of characters
- measurements on the Turbo Chameleon
- a name instead of the working title
No release date. No price. No pre-order.
BREACH is a working title. The screen terms are invented and provisional — „ARASAKA“ has meanwhile been replaced by „MERIDIAN“ so that no foreign trademark appears in the game. Retro-Modern does not collaborate with Commodore or CD PROJEKT RED.
Workshop log
What happened lately.
The target system really calculates
Until now the program code on screen was only scenery — real bytes that never ran. Whether you had won was decided by a rule inside the game. Now the door control actually runs: inside a rebuilt computer within the computer. Whatever you write into it gets executed. For the first time the game makes sense by itself instead of claiming to.
Approach and break-in become one round
Two separate experiments have become one sequence: the camera drives from the building to the door, the break-in starts there — and whether the door opens afterwards depends on how it goes. The floor plan also got a floor, so that it looks like a plan and not like a few strokes in the dark.
Measured on real hardware for the first time
Until then all numbers came from the emulator or from paper. The Ultimate 64 works about sixty times faster than a Commodore 64 — and, this was the real question, it does not slow the graphics down. Older accelerators do exactly that. This makes pictures possible that would be unthinkable on a real C64.
One game, two gaits
On fast hardware everything keeps running in real time while you think. On an ordinary C64 that would be unfair — there the guard program now takes a turn whenever the player takes one. Like chess. Not a stopgap, but a game style of its own.
Our own translator
Both projects now translate their C64 code with a self-written tool. Before that it needed Java and someone else's program. The proof that the swap changed nothing: the finished games are byte for byte the same as before.
Playable for the first time
Grid, pointer, four tools, the guard program and a round you can win or lose. From here on the question was no longer whether the idea carries, but how far.
Next measurement point
The Ultimate 64 is done. Now comes the Turbo Chameleon.
On the Ultimate 64 the measurements are in: the graphics are not slowed down, and the target system runs faster than on a real C64. On the Turbo Chameleon this is still open — its documentation suggests that it slows down on graphics instructions. If that is true, the same game will look plainer there. That, too, has to be measured rather than assumed.
Sources & Context
- Ultimate Documentation: Turbo up to 48 MHz and control registers ↗
- Ultimate Documentation: MultiSID up to 24 voices ↗
- Ultimate Documentation: REU up to 16 MB ↗
- Individual Computers: TC64 with 6510 turbo, 16 MiB REU and dual SID ↗
- Individual Computers: TC64 benchmarks – performance depends on the code path ↗
- Commodore: official C77 announcement ↗
All game mechanics, compatibility lists, and performance values on this page are development status or clearly marked target images. Trademarks and placeholder names belong to their respective rights holders.