A project that changed course

One of the joys of retro projects is that they very rarely go in a straight line.

This Blake’s 7 to NABU project has certainly not gone in a straight line.

The original plan was simple enough on paper, at least over a year ago. Take the excellent Oric Blake’s 7 game by Chema Enguita, study the engine, understand the data, and work toward a proper NABU version. In practice, the graphics side became the first real wall.

I could get some mock-up work going, but once it came to properly converting and mapping the Oric graphics to the NABU display hardware, progress slowed badly. I have never claimed to be strong on graphics work, and this project proved it. That part of the port did not really fail so much as grind to a halt while I tried to work out how to translate what the Oric was doing into something the NABU could display cleanly.

That quickly raised a much bigger question:

How do you keep proving the game logic, room flow, puzzle chain, and scene timing when the graphics conversion is the part holding everything up?

That question is what led to the text adventure path.

And, as it turns out, it became one of the most practical parts of the whole project.

First – the problem

The Blake’s 7 Oric game is not a simple text database with a few graphics hung off the side. It is a full adventure built on OASIS, with scripts, room data, puzzle logic, presentation timing, and a lot of machine-specific behaviour tied up in the original engine.

At the same time, the NABU target is not an Oric.

That sounds obvious, but it matters. A direct port is not really a port in the simple sense. It means understanding:

what the original game is doing
what part of that belongs to game data
what part belongs to the original engine
what must be recreated in a new engine

If you get that wrong, you can end up building something that looks plausible, but is no longer really the same game.

Second – the unexpected helper: Beatle Quest

The project really changed pace when I started working with Beatle Quest.

Beatle Quest is a C64 & Spectrum Quill adventure, which made it a very useful research subject. Unlike the Blake’s 7 Oric game, it gave me a classic database-driven adventure format that could be extracted, inspected, replayed, tested, and gradually understood. I have wanted to finish this game for years, which gave the exercise a bit more personal interest as well.

That was the real breakthrough.

Instead of guessing how a future text layer might behave, I could build and test one properly against a real game.

The Python work around Beatle Quest became a kind of live laboratory:

extract the Quill database
build a runner for it
test vocabulary and rule handling
recover replay paths
expand the automated test coverage
find out what the original engine features actually matter

That alone turned into a sizeable project, but it paid off.

What came out of the Beatle Quest work

The Beatle Quest side is now much more than a proof-of-concept.

The Python Quill runner can now:

load the extracted game database
run the imported rule tables
save and load state
handle presentation actions such as PAUSE and CLS
support wider late-Quill actions like BEEP and DROPALL
run a large automated test suite

At the time of writing, the Beatle Quest automated test suite sits at:

207 test cases
289/289 imported response rules covered
20/21 imported process rules covered

That is not just “it seems to work”. That is the kind of coverage that starts to make the engine trustworthy.

Just as importantly, the audit work has shown that the current Beatle Quest import is not missing some secret pile of unhandled text-rule instructions. The biggest remaining general Quill questions are now more about broader engine completeness and graphics playback than hidden logic gaps in this specific game.

That is a very good place to be.

Third – back to Blake’s 7

Once the text engine work on Beatle Quest became solid, it made sense to use the same approach on Blake’s 7, which was my original hope.

The catch – Blake’s 7 is not Quill.

So the Blake’s 7 text prototype had to be treated differently. It was not an import in the same sense. It became a careful authored adaptation built from the Oric scripts, room flow, object logic, and puzzle chain, with one hard rule:

The Oric game is the authority.

The Blake’s 7 correction

The Blake’s 7 Python version is being built directly against the Oric path.

That has meant checking the actual source route and then building the text flow around the right sequence of events:

Blake’s room
the early prison block
key character encounters
access and inventory puzzles
the escape route
the closing Episode 1 scene

The late Episode 1 path now follows the Oric structure much more faithfully, including the transition into the final Sentence scene.

On top of that, the text-only format has gained a lot of practical support:

explicit LOOK coverage
hidden-but-lookable room details shown as notable items
stronger room and object text for testing without graphics
source-attribution in the banner
support for presentation pacing in the final scenes

At the time of writing, the Blake’s 7 text side is covered by:

24 authored test cases
a dedicated LOOK audit covering 158 targets

That has made it possible to test not just the main route, but also a lot of the small details that would otherwise be easy to miss in a text-only adaptation.

Why the text route matters so much

It might sound odd to spend this much time on Python text adventures when the real long-term target is a NABU build.

For me, the answer was always very clear.

The text route gives a way to lock down:

the puzzle logic
the room progression
the inventory behaviour
the edge cases
the scene pacing

before the final hardware layer muddies the waters.

Without that, every future bug becomes a guessing game:

is it the room logic?
the imported data?
the new engine?
the display layer?
the storage layer?

With the text layer in place, those things can be separated.

That makes the final NABU work far less risky.

A bonus outcome – a reusable path

Another pleasant surprise is that this is no longer just about one game.

The Beatle Quest work has pushed the Quill side toward a genuinely reusable imported adventure runner. The Blake’s 7 work has done the same for a more authored source-driven adaptation path.

That means the project is slowly producing not just one end result, but a family of useful tools and methods:

a Quill extraction and testing path
a Python validation layer
a test-first workflow for retro adventure logic
a clearer route toward binary-packed data for smaller 8-bit targets later

That is exactly the sort of thing that makes future ports more realistic rather than less.

What is still left to do

Plenty.

On the Quill side, there are still broader engine questions around:

text colour controls such as PAPER, INK, and BORDER
graphics playback and rendering
how much of the original presentation behaviour should be preserved in a reusable engine

On the Blake’s 7 side, the real remaining challenge is not “can it be made to work as text?” because that answer is now clearly yes.

The bigger challenge is:

How far can the Python text version be pushed as a reliable design and verification layer before the real NABU conversion begins?

My feeling at the moment is that it can be pushed quite a long way.

Final thoughts

If I am honest, I did not expect the text adventure branch of this project to become so central.

I thought it would be a side experiment.

Instead, it has become one of the best things to happen to the Blake’s 7 port effort so far.

Beatle Quest gave me a real imported database to test against. Blake’s 7 gave me a far better way to validate the original game’s flow, structure, and presentation before the hardware work is finished. Together, they have turned a vague “we will sort that out later” problem into something much more practical.

That feels like real progress.

And, perhaps most importantly, it feels like the sort of progress that will still matter when the final NABU build begins.

Part 1 of a series. Part 2: Beatle Quest, Real Hardware, and What “Finished” Actually Means

253