Text adventure framework with transpiler - crazy idea?

A-code can be thought of as the machine code of Level 9’s A-machine. The A-machine is an 8-bit virtual machine with a 64 KB address space and whose machine code (i.e. the A-code) is specially designed for writing text adventure games.

I would assume that Level 9 used a high-level language when writing their games and compiled this to A-code or used some authoring tool which generated A-code. Hopefully, we will know more about this when @8bit_era’s and Mike Austin’s work with preserving the original Level 9 development tools is done.


I can’t help wondering if they reused some of their work on extending Nascom BASIC when creating their compiler.

I would say A-code is very similar to Z-code. It’s mainly generic low level instructions, with a few high-level instructions tailored to what text adventure authors need.

It looks to me like the designers of A-code have been thinking more like Basic programmers than the designers of Z-code, e.g. there are subroutines and they don’t have local variables. I would think Level 9 used some kind of Basic to program their games, and this code was then compiled to A-code.

PM me if you want to join in on the fun of figuring out the A-code format.


There need to be changes in both ends. The z-code compiler needs to compress with a new algorithm and the z-machine needs to know how to decompress this new algorithm. With these kind of changes it stops being a “z-machine”, though.

1 Like

That’s what I thought, which would mean using a different compiler as well as a different interpreter.

There’s a major obvious issue, and one minor but serious issue, in my krazy idea (actually a wet dream…): using the GCC (GNU compilers collection) concept, a front-end for the languages and a back-end for the binaries, linked with an intermediate pseudocode language. compiling a TADS source into glulx story file or an Inform 6/7 into TADS story file, or even writing with multiple language and releasing in multiple story files (as noted in my debate on strengths of IF language, writing the room descriptions in Inform 7 and his powerful adaptive prose support, and implementing the NPC in TADS 3, eventually with a parser written from scratch in Alan 3, and then successfully compiling all this indifferently in glulx, T3 or even hugo story files, isn’t the perfect ideal IF environment ? is obvious why I call this my major wet dream in IF coding

(being a Naval historian, I often use Fortran together with C in my research coding, so I know personally the vantage of using the specific strenght of languages)

the catches are first, that the coding work is perhaps beyond the coding prowess we have around, and second, that if one don’t start from true scratch, but from the GCC codebase, ALL the languages/sory file formats should be compatible with the GPL or the LGPL, and I don’t think is easy tracking and coaxing every language/story file author into relicensing into a (L)GPL compatible license…

Sorry for the inevitable igniting of the debate, and

Best regards from Italy,
dott. Piergiorgio.


Maybe I’m misunderstanding your description, but it seems to me that it would be easier to create a new language with the features and syntax you need, and transpile that into several output formats.

The licenses for the programs which use the output formats shouldn’t matter, as this system would work independently of the other systems without involving their source code.

Most of these languages are tailor-made for their respective target formats, and the target formats support specialized commands and data structures. They won’t mix well.

1 Like

I recently found a couple of cross compilers that target retro machines, in case anyone else is looking for one:-

SDCC (Small Device C Compiler) is a Standard C compiler suite that targets a wide range of 8-bit computers.

Boriel ZXBASIC is a BASIC cross compiler that targets the ZX Spectrum and several other Z80-based computers.

1 Like

I used SDCC for my Z80 retro projects. It’s pretty good.

TO summarise my discovery, it’s now possible to get better results compiling C->Z80 that writing it by hand.

Actually, this is not true, the code output isn’t actually better. But using the compiler allows you to make high-level changes you just wouldn’t be able to do if hand coded. The net result is a better code.

For IF, a while back i started building a project i called “minif”. This would be a small “C” program designed to compile to Z80 retro machines.

As mentioned above, Davide Bucci’s AWS2C, which he’s used very successfully for several of his adventures, does something very similar. GitHub - DarwinNE/aws2c: Adventure Writing System to C translator

He uses z88dk, rather than SDCC, to pop run the C on his Z80 platforms; but it’s a similar tool.


I recently asked on Reddit, and 4 people there (so far) seem to think it is possible to set up Nim to use SDCC or z88dk as a compiler. One of them has used it with an 8-bit mini board.

@8bitAG : I couldn’t find much info on AWS in English, so I kind of put that to the back of my mind.

Hi there,

For your info, AWS is very pretty much like GACS, and even simpler, in a fashion similar to what Inpaws is like PAWS/DAAD.

I’m pretty sure that the Google translator can help in providing a first approach in english.

Nonetheless, in the spanish community we recurrently discuss about the “should someone undertake the creation of a new engine?” question. And the answer is alway NO.

My humble opinion is that, if you want to have fun with the project, you should go ahead but making your expectations level with the effort it will impose on you and with the real base of users it will be able to attract. Be positive that the impact of your work will be from little to none.

Our beloved Uto has so far created 4 engines in different moments of time, all based on the PAW paradigm: NMP, Superglus, NGpaws and, recently, a catch up on the unearthed DAAD called DAAD-READY that easily compiles to maaaany 8-bit and retro machines. We also have other legacy DOS-only PAW-likes: SINTAC, Caecho and a few more. The Inform side of the spanish community has developed translated libraries for 6 (InformaTE and InfSP). Very few have approached Alan, Hugo, Adrift and others.

But: the availability of tools has never boosted a reasonable production of games. It is really hard to attain an involved interest from authors.

And: in the end, almost no tools are used but for DAAD-READY and Inform.

Also: don’t forget that most authors start working with a certain engine and always try to push the limits. 'd say that 95% of the times authors reach a block point because the engine does not support the features their story require. Limitations bring authors down to earth and pfff they end up going back to inform or daad ready, if any, or just give up.

Tiny tonto, bare bones systems such as Scott Adams are no longer attractive. And once Inform, the Infocom games and the new ZIL system (ZILF) are in the open, why should anyone want to author a game anything less?

My own experience, being a PAW/DAAD sort of expert, is that once you choose a system you’d better invest time in learning it up, down and thru, and endure. I have recently turned my back on DAAD and decided to invest time in ZIL. I’m trying to self learn it all as the parser tech is superb and it can produce real gems with a level of sofistication in 64 kbs that DAAD can never dream of, in spite of the beauty of the language and the easy coding paradigm.

If I were you, I would try e.g. to create a new lang that can compile to DAAD READY code and, then, recompile from DAAD READY to its 8-bit and retro machine’s interpreters. The 95% of the work is already done. Devote your effort to a new DSL to your own specification, macro-translate it and let DAAD do all the hard work.

I’m just a simple author, but I’d never distract a single second from my ZIL learning time to try anoooother engine focused on 8-bitters. I wonder what would a new 8-bitter would do better than the long-tested, used and beloved, in sipte of its shortcomings, DAAD does so well.

Just make sure you’re sure on why you want to do it. It can be very frustrating otherwise!!!

Cheers everyone!

1 Like

Translating the AWS manual using Google’s translator is a slow process, as they seem to be in PDF format. This means the text has to be copied and pasted into the translator and there is a 5000 character limit.

I’m hoping to avoid creating an entirely new system. Instead I want to use a combination of existing tools to target machines that other systems do not support.

I haven’t yet found every link in the tool chain, but I’m closer than when I first had the idea.

It may turn out that the Level 9 tools are made available before I do find everything I need, but even if that happens there are a number of machines they didn’t originally support. The retro tools I have found may then help me to create new Level 9 interpreters.

Creating a new language to compile to DAAD or any other currently available system would still not produce games for the systems I want. I would also have to write new interpreters and/or compilers.

If I did have to create a new language, I would certainly try to make it compatible with at least one existing one, but I’d only attempt that if I couldn’t find anything suitable to reuse.

It seems to me that I have two main options:-

  1. Create a new IF language that translates to existing IF languages and programming languages to support additional platforms.
  2. Make an existing IF language translate to existing programming languages and/or create new interpreters to target additional machines.

Option 1 is likely to be more appealing to new users, as they wouldn’t need to learn as many languages to target the extra platforms.

Option 2 is probably more appealing to existing authors, but mostly those that already use that particular IF language.

Of course, if there was some sort of GUI involved, the language used would matter less to many authors.

What platforms do you actually want to create games for? Let’s have a list. :slight_smile: You mentioned tape-based platforms initially, such as the BBC B, MSX, Spectrum etc. A lot of those are targeted by existing systems. Level 9 didn’t support much of a bigger range than any other system… it just hit a few unusual targets (that they eventually dropped support for anyway)… even Level 9’s system demanded at least 32K (save for the the initial batch of 16K versions of games).

Do you think that there is an actual audience for “tape” players on niche retro systems, given that even a large chunk of fans for those systems will use emulators or disk-replacements such as Goteks?

I still think PunyInform makes the most sense if you’re looking at writing something for the largest range of retro machines… Even if that doesn’t 100% meet your criteria for a “tape-based system”… but low-memory machines will always be difficult to target.

The retro adventure writing community has proven that there is an audience for PunyInform games on a wide range of retro machines. And even a commercial audience, with actual physical tapes & disks produced for standout examples.

(Also apologies… as this thread is over a year old, I realise the conversation is repeating itself slightly as I’m sure several of us have forgotten we’ve already commented similarly earlier… I know I have!)

I would like to support the less common machines, including:-

  • Enterprise 64 & 128
  • Sharp MZ series (MZ-80, MZ-700, MZ-800 etc.)
  • Dragon 32 & 64
  • Sam Coupe
  • Memotech MTX series
  • Tatung Einstein
  • Jupiter Ace

The first 3 are especially important to me, as I owned an Enterprise 128, Sharp MZ-700 and a Dragon 32 in my youth (so very long ago). I did not own a disk drive for any of them as they were relatively rare and expensive in the UK.

Level 9 did produce games for the Enterprise 64 & 128, but not for the other two AFAIK.

I would imagine there is an audience for tape based games in the UK, as many of the remaining physical machines will not have a suitable disk drive. Any machine that could use a standard cassette recorder should be able to use a digital recorder instead, which is generally cheaper than a disk drive.

Those using emulators aren’t my main target audience, as they can use an emulator for a more common system if they want to play a particular text adventure. Text on one machine doesn’t look that different from text on another machine after all.

As you’ve said, there is an audience for physical tapes, even if it is small. It stands to reason that the wider the range of systems that tapes can be produced for, the bigger the potential audience.

(Don’t worry about forgetting what has already been said. I often can’t remember what I ate the day before, without effort.)

1 Like

Lol… you know you’ve got a list of really obscure systems when the Dragon is the one with the most existing text adventures on it. :slight_smile:

Most of those are Z80-based then, with several of them capable of running CP/M and also several of them also capable of running ZX Spectrum games, with the right additions. The Dragon is the really odd one out. So nothing new there. :slight_smile:

I still feel that just adapting an existing system to target those machines would be the most logical choice, although one of the more lightweight systems would be best. I’m sure if you chatted to Davide Bucci, then AWS and AWS2C could easily be adapted so the source code was in English, allowing a C output that could be compiled to those various platforms.

There are various other lightweight adventure systems out there too… such as Lantern which again would seem to be a good place to start.

(As an aside… as a SAM Coupe owner, both now and back in the day, there is zero point producing tape-based games… It really is a disk-based machine, despite the original model not coming with a disk as standard… anyone who can afford a SAM these days can afford a disk-like solution for it!)

1 Like

The Dragon is kind of an oddball, from what I remember of using one. I live in Wales now, so feel at least some obligation to at least try and support it if I can.

I’m still weighing up the pros and cons of adapting one of the exisiting IF tools compared with creating a framework in an existing (non-IF) programming language with transpile options.

I will at least read the manual for AWS, but as I mentioned it is time consuming. From the screenshots it seems to be a simpler version of Quest, ADRIFT or TAB which I’m not sure would be very screen reader friendly (which I would like the system to be if possible).

I’ve looked at Lantern a couple of times, not least of all because it supports the Sharp MZ-80A which is highly compatible with the MZ-700. The toolchain seems a little convoluted, but it could be useful.

The use of C-style syntax and C itself does put me off though. I would prefer BASIC or Pascal style code, given the choice.

There are a few BASIC or Pascal options that could work for an IF framework.

BCX and FreeBASIC both translate to C before compilation, so might work with SDCC.

Turbo Rascal SE compiles to several retro machines, but not the ones I’m interested in (yet). FreePascal has a Z80 compilation option in the dev branch, but no machine-specific configurations yet.

There are also several Pascal to C converter programs about, although those I’ve seen don’t mention SDCC or z88dk specifically.

Decimal BASIC has a tool to translate to FreePascal, and Nim can be translated to C, C++ & JavaScript.

So, there are lots of options if I ignore existing IF tools and go with an existing programming language.

Tim Gilberts has unfinished business with the Dragon… if he ever goes back to his version of Quill for that machine (never finished due to accidental data loss) then it would be tempting to make a Quill game in Welsh for the Welsh Dragon… although my Welsh would need to get a hell of a lot better first. :slight_smile:

I thought The Quill was superceded by Professional Adventure Writer?

From what little I know of Welsh, you’d also need a noun-verb parser in addition to the more usual verb-noun version. (I have a vague dream of supporting Welsh too.)