It looks as if ZXZVM is for the Spectrum +3, which had a built-in 3" disk drive.
This system would create a single file for each game, with no need to load in extra data during play, much like Level 9 and Scott Adams games. That’s the advantage it would have over z-machine games.
So, would the author distribute the source code for players to compile on their own? Because the number one issue of releasing IF in, say, Python is that the author can only compile for their own system. I have Windows, so that means I can’t release for Mac.
So now I have to hope that my players know how to install and run gmake and it’s toolchain to play my text game?
Edit: Just to be clear, I’m not trashing your idea. I feel kind of bad that it seems like we’re attacking it. I just want to point out potential weaknesses before you get too far into it since you were asking for thoughts on the matter.
Do you think that Z-code is fundamentally incompatible with tape-based I/O, such that a ground-up redesign would be needed to be compatible (or just “fast enough”) with those systems?
Could you “just” implement a Z-code interpreter for tape-based systems?
If not, would it be feasible to transpile Z-code to another format that would work on those systems?
I ask because getting folks to adopt a new language is a very difficult task, and if the only advantage for authors is “it’s compatible with tape-based machines that nobody owns anymore,” well, it’s going to be very difficult to get IF authors to adopt it.
@tayruh : It would be up to the author to decide whether to distribute the source code. I intend for there to be a choice of programming languages to transpile to, so they can distribute whichever makes sense to them.
The Mac is problematic in that Apple require you to use one of their machines to compile code for it. You can get cross compilers that will compile to Linux, Android etc. from Windows though.
Java, JavaScript or WebAssembly might be options though.
@dfabulich : It isn’t the speed that is the problem. Some machines loaded programs quicker from tape than a Commodore 64 did from disk.
The problem with the z-machine is that it does not load an entire game into memory at once. Instead, it loads some parts as they are needed and removes others when they aren’t.
This is not practical with a tape based system as they are not random access. It’s like the difference between listening to a tape (which has to be played in order) and a record or CD (where you can jump to any track as needed).
Exporting to tape-based systems wouldn’t be the only advantage. It could also potentially export to JavaScript, C++, C#, Java, JVM, Python, Lua and PHP via the Haxe transpiler, or WebAssembly, JavaScript and Android via FreePascal, or C, C++ and JavaScript via Nim.
Even transpiling to just 3 languages would open up a lot of possibilities.
Interesting idea, but it would definitely be worth really assessing if their is an audience for the framework before you go ahead and do a lot of work on it. Particularly as there is so much overlap with existing tools that have quite considerably established user-bases.
There are already several, extremely portable lightweight adventure writing systems, such as AWS2C and Lantern that can easily target a ton of machines. I think Davide Bucci’s current supported list of platforms currently runs to something like seventeen different machines for his AWS2C games.
DAAD and PunyInform target the majority of the most popular 8-bit platforms and have the benefit of using two well-established adventure languages, which most interested authors are already familiar with. PunyInform is particularly impressive on the BBC machines; as that community have developed their own version of the excellent Ozmoo interpreter, customised to all the various flavours of BBC micro.
As we’ve discussed in your previous threads, there’s also the possibility of a system being produced that might use the Level 9 technology.
As an 8-bit adventure author and exclusively 8-bit text adventure player on old platforms, I would probably be your target audience for this sort of framework… But I’d be extremely reluctant to learn any new language when I already have tools that I can target a huge number of different platforms with.
That’s the main issue, I think, with your proposal… Getting people to adopt a brand new adventure writing language. The task of coming up with a flexible, easy-to-use, powerful and attractive adventure writing language shouldn’t be underestimated. So many have tried to produce adventure systems, but very few catch on.
I can’t help feeling that your time, and programming talent, might be better served expanding the reach of some of the current frameworks rather than creating a new one. But then, as an 8-bit text adventure author, I fully appreciate the joy of producing something just for your own amusement. 
This is an interpreter problem, not a game format problem.
What you are describing is the virtual memory system, which was incorporated as an optional part of the Z-machine to allow for bigger games to run on computers with limited memory. The Z-code game is totally oblivious to this system - it can’t know if the current Z-code interpreter implements it or not, or if a certain part of the program is currently in memory etc. Modern interpreters typically don’t implement the virtual memory system, since there’s no need on a modern machine. In Ozmoo it’s optional. In build mode “P” (single program file), the virtual memory system is omitted, and the entire game has to fit in memory all at once. The maximum game size in this mode is roughly 53 KB on a Commodore 64.
That said, there may not be very many Z-code interpreters for 8-bit platforms that are designed to run without a virtual memory system.
Have you looked at GitHub - Fabrizio-Caruso/CROSS-LIB: CROSS LIB - A universal 8-bit library and some games built with it ? It should allow you to write a C library for a text adventure system, and make the games playable on pretty much any 8-bit computer.
Davide Bucci’s already done something similar with his AWS2C tool and the underlying AWS seems fairly decent; certainly Davide has produced some very popular adventures with it.
You are in a twisty maze of little BASIC dialects, all different.
@8bitAG : If I could find a suitable existing open source IF language, I could potentially work with that instead of starting from scratch.
However, it would also need to reasonably simple and screen reader friendly.
I hadn’t heard of AWS2C before this thread, so I’ll take a closer look at that at some point to see if I can find more info in English.
I had seen Lantern before, but thought the GUI system would cause problems in my use case.
DAAD doesn’t have the source code available for its interpreters, so adding new machines would be made more difficult.
PunyInform is another z-machine variant, so would not be suitable, plus there is already a large selection of those.
I would love to be able to leverage Level 9’s system somehow, but AFAIK there is not even a rough estimate of a release date for the original tools, let alone any updated ones. I have only been able to find vague information on how their tools worked, so it would be difficult to start working towards something compatible before they’re released.
@fredrik : I had previously bookmarked that site and quite a few others in the hope of leveraging existing tools like that.
On the surface it looks as if reusing tools that are already available would allow for compiling to a wide range of machines. The tricky part would be getting everything to work together.
@rockwalrus : That’s another problem this tool could potentially help with.
I’m hoping to allow others to add new transpiler options, so eventually most of the popular BASIC dialects could be covered.
I’d mentioned Davide’s games in your previous thread but I probably didn’t flag up AWS explicitly. Definitely get in touch for a chat with Davide. He’s an amazing polymath who I’m sure could give you some pointers if you do plan on going on, what is actually a very similar journey to what he’s been on.
His three main games are well worth checking out, anyway, as an example of what even such a relatively simple cross-platform tool can produce. Silk Dust - Davide Bucci
Uto has developed a clean room implementation of DAAD, and there is also an MSX version too which is a reimplementation. Not sure of the license.
AWS2C is also an excellent open source option which could be adapted to transpire to lots of other targets, and is fairly light on resources, whilst not being quite as light as PAWS.
Asventuron Pico is also on the horizon too - a version of Adventuron explicitly for transpilation to source code. IAn evolution of the fixed transpiration from Adventuron to DAAD and PAWS.
Is Adventuron Pico going to be open source and for desktop?
I’ve avoided the standard version as I dislike online tools.
Sounds interesting. 
That’s a shame, as once you’ve loaded up the page it basically functions as an offline tool. And, if you really want, you can actually just code in a text editor.
This echoes my understanding of Z-machine as well. I think it’s just not correct to say, as you do here, that Z-machine is simply “not suitable” for tape-based systems. As I understand it, there’s nothing stopping you (or anyone) from porting an Ozmoo-style Z-machine to tape-based systems.
I don’t even think there’s anything stopping you from implementing virtual memory for tape-based systems, but I suppose that it might not have good performance on games that don’t fit entirely into RAM. (I’m not sure any of this would be doable on the 8KB MSX, but I’m pretty sure it’s all doable on the 32KB MSX and/or the 48KB Spectrum.)
But, hey, they’d all still work anyway, and I rather doubt that you’d get a lot of complaints that Zork ran too slowly on 32KB MSX, as long as you could at least open the mailbox and break into the house without paging.
And I can’t emphasize strongly enough how much easier porting Z-machine to older machines would be (for Spectrum, you’d even have ZXZVM to start with!!) compared to re-developing your own code format and language from scratch and trying to convince anybody to write a game (worth playing) in a new language.
But how would that be a useful advantage over Z-machine, when we already have good Z-machine interpreters in JavaScript and C (and Java, and C#, and Python…), interpreters that already work great on Windows, Mac, Linux, iPhone, Android, the web, and even most popular retro devices?
I dunno. If you’re going to have fun with this, I’m not gonna stop you. In this meme template, I’m not trying to tell you “we have food at home,” but I strongly recommend aiming more toward the “just buy a coffee” corner rather than cheering along.
@8bitAG : I have 3 issues with online tools:-
In this case, only #1 is an issue. You don’t need a constant connection (or even a connection) for Adventuron; once you’ve loaded it. And backing-up/saving files is no different than using a desktop program. It is really a desktop program that you just load up using the browser, in many ways.
I don’t like online tools either, in general, but using Adventuron is only like firing up a program. I think that if you’re going to be developing a framework of your own then you should at least check out Adventuron as there would be plenty you could learn from its approach that might be useful.
Chris has worked tirelessly on the system and looking at aspects, such as how it can export its code to DAAD and the PAW would definitely be informative when you think about the basics of your own new adventure language.
I’d say that about all these tools, to be honest. Give them all a go. I certainly wouldn’t want to dampen your enthusiasm for your project (you’ll need endless amounts of enthusiasm to make any progress, that’s for sure) but I do like it when people build on the existing work that others have done. It’s really paying off for systems like DAAD and PunyInform, where lots of experience and expertise is taking those tools in interesting directions.
I hate to be obtuse, but how would this work?
I’m admittedly not familiar with the details of the virtual memory implementation for the Z-machine, but my basic understanding of virtual memory in general is that some other form of storage is used to offload not-currently-used chunks of memory from RAM and onto, say, a hard disk, or some other random-access storage medium. But the medium being random-access is kind of crucial here (and so is the need for it to be entirely software-controllable without user intervention), and that doesn’t describe a system that only has cassette-based storage. Cassette-based systems read (or write) from the beginning of the tape to the end of stored data and require substantial user micromanagement of the physical drive itself, usually requiring manual rewinding and setting whether the drive is currently playing or recording.
Presumably, the cassette drive is already taken up by the tape holding the program being run. It doesn’t even seem that it would be possible to use a second tape drive as a VM backing store, because cassette tapes aren’t a random-access storage medium: they’re read (or written) once and then the user has to (usually manually) use the drive’s rewind button (and wait for that process to complete) to return to the beginning of a tape, then press PLAY or RECORD again. It also seems like the user would also have to be extremely careful whether they’re hitting PLAY or RECORD; getting it wrong would probably mean overwriting the paged-out VM data. (There’s also the issue that many old tape-based systems only supported a single cassette tape drive.)
Again, maybe there’s something I’m missing here, but needing to have a second tape drive and constantly dealing with onscreen messages that say things like “Now rewind tape drive #2 to the beginning of the tape and press PLAY,” waiting a minute while the drive reads data back into memory, responding to a message saying “Now rewind tape drive #2 to the beginning of the tape and press RECORD,” and waiting another minute while data is paged out, seems like a deal-breaker for a lot of people.
Yeah! presumably this would be a bit like when i once worked with ancient mainframes. They had so little memory that your code was often dumped onto tape while out to lunch!
On return, i had to phone the operator (!) to ask for the tape to be reloaded then wait for my code to re-appear
The Z-machine standards document explains Z-machine’s architecture in a fairly readable style. See especially the overview https://www.inform-fiction.org/zmachine/standards/z1point1/overview.html
and the memory map https://www.inform-fiction.org/zmachine/standards/z1point1/sect01.html
Z-machine virtual memory is different from general-purpose virtual memory systems of the kind that you’d use in a modern-ish operating system. What’s getting paged in and out is “high” memory, which contains read-only executable Z-code opcodes and static strings.
All of the writable game data is stored in “dynamic” memory, as well as a high-performance cache of static data (grammar, actions, dictionary). That, and only that, is kept in RAM.
