Part 1: Blake\u2019s 7, Beatle Quest, and a Very Practical Text Adventure Path<\/a><\/strong><\/p>\n Part 2:<\/strong> Beatle Quest, Real Hardware, and What \u201cFinished\u201d Actually Means<\/strong><\/a><\/p>\n Part 2 ended with a promise: Blake’s 7 catches up, and Pyramid 2000 gets built from nothing. That is still coming. It is still Part 3.<\/p>\n This is the chapter that happened first, uninvited.<\/p>\n Beatle Quest had just reached v1.00.22 on real NABU hardware – clean, tested, finished, in every sense that mattered about 2 weeks ago. Then came an obvious question I had been quietly avoiding: if the whole point of this engine is that the game logic lives in a portable .ADV data file and a small C runtime, was that actually true? Or was it just true on paper?<\/p>\n There was only one way to find out. Stop talking about portability and go prove it, on real, different, unrelated 8-bit and 16-bit machines.<\/p>\n The claim, precisely: the same BQFULL.ADV data file – the same rooms, the same puzzles, the same 1000-point scoring, byte-for-byte identical – should be able to run on any machine with a C compiler and basic file I\/O, with only the platform-specific edges of the runtime needing to change. Screen clearing. Delay routines. Not the game.<\/p>\n If that held up, it would mean something real: not just “Beatle Quest runs on NABU,” but “this whole approach to preserving old text adventures travels.”<\/p>\n Six targets went in, one after another: Commodore 64, Commander X16, MSX, Apple II, Amiga, and a TRS-80 Color Computer built by hand in 6809 assembly rather than through a C compiler at all. Six real, different toolchains. Six real, different ways for this idea to have quietly been wrong.<\/p>\n Almost nothing changed. That was the whole result, in miniature.<\/p>\n Every port kept the entire game-logic layer untouched: the room graph, the command parser, the scripted-action engine, the scoring, save\/load. What changed, per platform, was small and mechanical – a screen-clear call here, a delay routine there, a file-open convention somewhere else. On the smoothest of the six (Amiga), that list was two lines: a Delay() wrapper and an ANSI clear-screen escape sequence. Everything else just ran.<\/p>\n That is not nothing. That is the actual thing being tested, working.<\/p>\n Five of the six ports went smoothly at the software level: keep the C runtime, adapt the small platform-specific edges, and the same scripted playthrough runs correctly. That is not quite the same as “done” though – one of those five, Commander X16, still has a real problem on real hardware I have not solved yet. I cover that honestly later rather than skipping past it here. The sixth port, the TRS-80 Color Computer, was a different kind of hard: not a real-hardware wrinkle that showed up later, but three full attempts before the software side even worked at all.<\/p>\n The CoCo is a smallish machine, with less room to work with than some of the other five. My first attempt went in through a modern C compiler – a C compiler is a C compiler, I figured. It was not that simple. Getting the compiled program to even fit took real effort, and once it did, it locked up solid the moment the game actually started running, with nothing on screen to explain why. I paused it there (The compiler is just not mature enough), unsolved.<\/p>\n The second attempt used a different kind of compiler, built specifically for this family of machines, translating a dialect of BASIC into the machine’s own native code. That got much closer. A determined effort to trim it down closed most of the gap. But “most” was not “all” – the last stretch turned out to be blocked by a genuine bug in the compiler’s own official fix for exactly this situation. I confirmed that, not just suspected it, by building the smallest possible program that still showed the same failure (Great Program, BASIC-To-6809).<\/p>\n Two real, careful attempts, two real dead ends – same underlying reason both times. Every layer standing between the game logic and the machine costs something, and this machine simply does not have room to spare.<\/p>\n So the third attempt gave up on someone else’s compiler and wrote the engine directly in the machine’s own language instead, using a real, surviving commercial game from the machine’s first year on the market as a reference for how software like this was actually built at the time. That version worked. Fully data-driven against the same shared file format as every other port, and it cleared the same bar every other platform had: a full, scripted playthrough of the whole game, a perfect score – confirmed on a real, physical CoCo, with a genuine period-correct floppy drive attached.<\/p>\n The lesson is not “assembly is better.” It is narrower and more useful than that: portability holds right up until a specific machine’s limits say otherwise, and when that happens, the fix is not to fight the ceiling – it is to build for the machine that is actually there.<\/p>\n That should have been the end of the CoCo story. It was not.<\/p>\n “Confirmed on real hardware” turned out to mean something narrower than it sounded. Real hardware, yes – but with a genuine, original-style floppy drive attached, the exact setup I had used for every other CoCo test, and by far the easiest one to reach for. Most people running a CoCo today are not doing that, though. Real floppy drives from this era are used less and less. The practical way to get a program onto a real CoCo now is a small modern add-on card that plugs into the disk-controller slot and stands in for a whole shelf of floppies, using an SD card instead. From BASIC’s point of view it behaves exactly like a disk drive. Underneath, it is nothing like one at all.<\/p>\n My disk-reading code talked directly to the original floppy controller’s own hardware. Fast, and it had worked every time on the setup I had tested. On the modern SD-based replacement, it did not work at all. Not a crash – something quieter and more misleading. It reported success and handed back data that looked plausible but was not the right data. That is a much harder kind of wrong to notice than an outright failure.<\/p>\n Two more rewrites of the disk-handling code followed, each a more careful, lower-level attempt to talk to that same original hardware correctly. Each one looked right on the emulator I used for day-to-day testing. Neither held up once actually tried on the real modern hardware people actually use.<\/p>\n The fix, when it finally came, was not a cleverer way to talk to the hardware. It was giving up on talking to the hardware directly, and calling the machine’s own disk operating system instead (DECB) – the same handful of built-in “open a file,” “read the next character,” “close it” commands that Disk BASIC itself is built from. Real commercial software from the machine’s own era used those same commands without a second thought, specifically so it would keep working no matter what disk hardware ended up plugged in underneath.<\/p>\n It is the kind of fix that is obvious in hindsight and easy to miss going in – well, for me anyway, especially when the instinct is to solve a hardware problem with more hardware-level code. It took someone who had actually written software for this exact era of machine, back when it was new, to say the quiet part out loud: don’t fight the disk controller, just ask BASIC to do it, the way everyone building real software for this machine always did. Thirty-plus years on, I had simply forgotten that as the obvious first move – a genuinely old lesson, rediscovered rather than invented.<\/p>\n Confirmation came in stages, the way it usually does. The corrected code proved itself first on two independent emulators, then on a real CoCoSDC card in a real machine – a full playthrough and a save-then-reload, both clean, both correct. For CoCoSDC at least, the modern-storage question was genuinely closed.<\/p>\n FujiNet’s own real hardware took one more step to settle. Reading worked immediately, matching what CoCoSDC had already shown. Writing did not – a real, repeatable error, on the one card I was testing, on both of the ways it can talk to storage. My first instinct was to assume the fix had a second hole in it and go looking for one. What actually settled it was running the exact same disk code through FujiNet’s own PC emulator – the real server software, just hosted differently – and watching it write correctly, log entries and all. That does not prove the physical card is fine. It does prove the fix is: same code, same protocol, and it works. Whatever is wrong with that one card is a question for the card, not the code – worth being precise about, rather than letting one stray hardware error quietly reopen a question that had already been answered.<\/p>\n Every platform reached the same bar: a full, scripted, 378-command playthrough of the entire game, ending in a perfect 1000 out of 1000. Not “should work.” Run, and read the transcript. (The CoCo’s own version of that transcript needed re-running once, on the corrected, BASIC-native disk code above, before it could really count – see the previous section. Old lessons have a way of asking to be proven twice.)<\/p>\n Most needed a person to test them – which, for a project built around “playable, not just plausible,” felt like the right place for a person to be anyway.<\/p>\n That bar – a perfect scripted run – is about the game logic, and every one of the six clears it. It is not the same as “runs on real, physical hardware,” and I do not want to blur those two together. So here is the honest state of that harder bar. The original NABU build and the CoCo build have both actually run on real hardware (CoCo has more to its story than that one sentence suggests – see above). Commander X16 has been tried on real hardware too, and does not currently survive it – it locks up reliably, a real, open problem I have not solved. Commodore 64, Apple II, MSX, and Amiga have not been tried on real hardware at all yet – not “failed,” just genuinely untested outside an emulator so far. Proven-in-software and proven-on-real-metal are two different bars. Pretending otherwise would undo the whole point of being careful about the difference.<\/p>\n The multi-port question is answered, cleanly, in the specific sense I set out to test: the same room graph, the same puzzles, the same 1000-point scoring, running correctly against six genuinely different toolchains with almost nothing but the platform edges changed. That is the actual claim this chapter makes, and it is a real one – “it is portable in theory” is a much weaker sentence than “the identical script produces the identical perfect score on six unrelated machines.”<\/p>\n Whether all six also survive contact with real, physical hardware is a related but separate question, still partly open – and the honest thing is to leave it looking exactly that open, rather than round it up early. That was always the real point of building this engine around a shared, machine-independent data file in the first place: a bet, made a while ago, that doing the hard work once – the room flow, the puzzle chain, the parser, the scoring – would pay for itself every time afterward. Six platforms into proving the logic, it has. The remaining real-hardware questions are next.<\/p>\n The “Ports”<\/strong> release page is under construction: Interactive fiction (IF) – Text Adventure cross platform porting<\/a>.<\/p>\nThis was not the plan<\/h2>\n
The idea being tested<\/h2>\n
What actually needed to change, and what did not<\/h2>\n
The one that did not go smoothly at all<\/h2>\n
The lesson that came after the “working” version, not before it<\/h2>\n
Six for six, with one honest asterisk<\/h2>\n
What this chapter actually settled<\/h2>\n
![\"\"](\"https:\/\/www.amigaretro.com\/projects\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-28-213232-300x234.png\")
<\/p>\n