You could do. What i would do is go for the absolute simplest system i could possibly imagine. Something like either, choices + a few flags, or a 2 word parser + a state table (a bit like Scott Adams).
Then I’d try to get it working.
Having done some development on retro computers i can highly recommend keeping things super simple. I have a rule: No CPU, no memory and no performance. That’s what you’ve got to work with
The flipside, is that it’s quite a lot of fun getting anything at all working on these old machines.
Also, how do you know those frozen corpses aren’t actually on the way down?
Regarding the Z-machine and tape, Infocom did it for a couple demos for C64 tape. The Ozmoo team was experimenting with that too, but I’m not clear on how far that effort went. It’s doable as long as the game can be made to fit in RAM.
@jkj_yuio : Creating an unusual coding language for an unusual system would put a lot of potential users off even trying it.
I used to code in BASIC on several retro machines when they were new, and I found that half the fun with creating text adventures was trying to squeeze as much text into memory as possible.
I even played around with storing text in video memory on one machine. It was slow, but it worked.
@dfabulich : 8Kb is taking things a little too far. I had imagined a minimum of 32Kb with a preference for 64 (or more).
If I were to try creating a virtual machine or interpreter, I’d be more likely to use Level 9’s a-machine as inspiration, as despite info on it being harder to find, it was made for tape-based systems with 16Kb memory.
The language I’m still not sure about. It would definitely have to be similar to one or more existing languages.
Of all the authoring languages I’ve looked at so far, ALAN seems to be the best balance between natural English and traditional programming code.
Out of the general purpose programming languages I’ve tried, I prefer structured BASIC and Pascal.
There’s, as many other have stated, nothing in the z-machine that stops it from being run from tape. You obviously have to limit the game size so all of the game + the interpreter fits inside the available memory.
I made a single PRG z5 file of the ZIL version of “Craverly Heights” for C64 with Ozmoo yesterday without problem. This file loads completely into memory and easily could be saved to tape.
Personally I would try to write a minimal z-machine, maybe only support z3. Then strip down a existing library (Puny or Zilf) to remove unused functions. I think I read somewhere that 70% of a game is text so text compression is important. One modification to the z-machine, that would break the games compatibilty to other z-machines, would be to improve the text compression algorithm. Here one could experiment with lzw or try Level 9’s compressing scheme.
It would be interesting to make a proper comparison between Z-code and Level 9 A-code text compression. When compiling Craverly Heights for PunyInform, using Hugo Labrande’s abbreviation finding algorithm and the latest compiler patch to apply abbreviations in the best way, the game text (41688 characters) is compressed to 56% of its original size (not sure if the size of the abbreviations used is accounted for though). I don’t think that’s alarmingly bad, considering we’re dealing with short string compression, and unpacking must be doable by a small and fast routine.
I made some calculations over here and if I made them correctly the text is compressed to 17.687 bytes (42.4%) of the original text size on the ZIL version of Craverly Heights. The z5 version are 47.464 bytes and if I compress it with LZW (zip) the file is compressed to 32.371 bytes. That would be some kind of theoretical lower limit. My guess would be that you could cram out maybe 4-5 kB more with a optimal compression but the real time decompression on a 8-bit computer is a challenge.
The main objections I have to creating a z-machine instead of an a-machine are:-
It would only teach me something new
The end result would not be very unique or useful
However, I would probably research how a z-machine is put together to compare it with other systems.
Is there much information available on Level 9’s compression system? I thought that reverse engineering had only gained insight into how to decompress their data?
Also, does anyone know if a-code was a high level programming language, some sort of low level assembly language or a specialised database/spreadsheet system?
I think a low footprint z-machine with highly optimized compression that leave an additional 4-5 kB for game-data would be greatly appreciated by the 8-bit guys and gals.
There’s actually two different compression algorithms used in L9, one in v1-2 and another in v3-4. I and @fredrik are working on a document and have quite a bit of understanding of them. If you have insight on how to decompress you’ll also know how to compress. For version 1 and 2 you only need an algorithm to find 162 abbreviations and this would be practically the same as finding abbreviations for z-machine games. For version 3 and 4 you’ll need an algorithm to find an optimal set of words for the dictionary. You could probably use the one existing in current L9 games otherwise a script that count word frequency could work.
I would say that with the information known to me now that it’s pretty low-level. The opcodes for a-code are a minimal set. The L9 compiler tools could have been more complex and supported a higher level, though. It would be reatively easy to write an a-machine interpreter. It would be much harder/more work to design a language and a compiler.
You’re certainly welcome to join the effort of documenting the L9 format.
I thought the text compression was done during the code and build processes? If that is the case, then wouldn’t any improvements need to be made to the z-code compiler rather than the z-machine?
For the a-machine, it was the routines for choosing the best phrases to optimise I was wondering about. I wouldn’t have thought that knowing which phrases were actually chosen would give that much insight.
I was hoping to be able to transpile to a-code, once the Level 9 code archive is released, and have always wondered if it resembles ZIL in any way.
How would I go about doing that? Is there a Google Group or some sort of central repository for information gained so far?
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 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.
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
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.
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.
