New CX16 support for Ozmoo 14
New CX16 support for Ozmoo 14
We have released Ozmoo 14 with support for the X16. It's a Z-Machine interpreter allowing you to play classic Infocom text adventure games, as well as modern games written in the same format. Give it a try at https://ozmoo.online/, or check the source code at https://github.com/johanberntsson/ozmoo
Re: New CX16 support for Ozmoo 14
New version 14.17 released today, fixing a bug that would make games freeze when played on the latest ROM version.
Re: New CX16 support for Ozmoo 14
Neat! And very cool that the "game engine" is needed to drive the mechanic of scrolling the screen itself, and maintaining that room status bar. SAVE/RESTORE works. On exit (QUIT) you have to Y, and then press a key again - but it does clean exit back to the system.
I was comparing it with the original PDP-10 Dungeon and the PDP-11 FORTRAN port of that. Looks like a very good reproduction here.
The ZORK1 build for X16 comes out to 83KB and 13KB. I assume the larger file is the compressed game room-description content, and the smaller 13KB is the ZCODE runtime engine?
Small nit, might export the ZORK1 file as ZORK1.PRG (just to encourage a sort of system-standard that .PRG files can be LOADed and RUN, but that's just a user convention). Also on game exit, it doesn't return to the same screen/text mode as prior to when game was started (again, just nit stuff).
F1 to toggle dark mode is great!
Would it be possible to support a 40-col mode? That might go better for those wanting to use Composite output. It seems the engine supports word wrapping of the uncompressed text.
On the startup - is it uncompressing the entire ~83KB content into banks all upfront at once? Then how does it handle the banking from there? e.g. is it loading current and adjacent rooms in the 8KB bank? The game has to remember state (I think?) of rooms that might not actively be in RAM (plus the player inventory)? I see some of the text is abbreviated from the original (is that ultimately just prudent accommodation for microcomputers in general? since IIRC the original ver did use nearly 1MB RAM? Maybe that's not accurate, just I thought the rough estimate was it had ~1MB of text content when uncompressed). Anyway was just curious on some of the technical details there, on how this >64KB data file is being handled.
I was comparing it with the original PDP-10 Dungeon and the PDP-11 FORTRAN port of that. Looks like a very good reproduction here.
The ZORK1 build for X16 comes out to 83KB and 13KB. I assume the larger file is the compressed game room-description content, and the smaller 13KB is the ZCODE runtime engine?
Small nit, might export the ZORK1 file as ZORK1.PRG (just to encourage a sort of system-standard that .PRG files can be LOADed and RUN, but that's just a user convention). Also on game exit, it doesn't return to the same screen/text mode as prior to when game was started (again, just nit stuff).
F1 to toggle dark mode is great!
Would it be possible to support a 40-col mode? That might go better for those wanting to use Composite output. It seems the engine supports word wrapping of the uncompressed text.
On the startup - is it uncompressing the entire ~83KB content into banks all upfront at once? Then how does it handle the banking from there? e.g. is it loading current and adjacent rooms in the 8KB bank? The game has to remember state (I think?) of rooms that might not actively be in RAM (plus the player inventory)? I see some of the text is abbreviated from the original (is that ultimately just prudent accommodation for microcomputers in general? since IIRC the original ver did use nearly 1MB RAM? Maybe that's not accurate, just I thought the rough estimate was it had ~1MB of text content when uncompressed). Anyway was just curious on some of the technical details there, on how this >64KB data file is being handled.
Re: New CX16 support for Ozmoo 14
Sorry for the late reply, I didn't get a notification and didn't see your post until now.
The smaller file is indeed the Z-code runtime, AKA Z-code interpreter.
The larger file is the Z-code program, i.e. the actual game. It's not actually compressed, but it uses the Z-code format which is quite compact in itself. Z-code does have built-in text compression, so storing a 100 character text typically takes up about 65 bytes. This compression happens at the individual string level though.
Z-code interpreters for typical 8-bit computers use a virtual memory system. The person programming the game can write a game of say 128 KB, and doesn't have to care about what data goes where in the file, or whether it will run on a computer with 32 KB or 256 KB of RAM - the Z-code interpreter handles the virtual memory and loads whatever parts of the game file that are currently needed into RAM. A small part at the beginning of the game file is "dynamic memory", i.e. its contents can change during game play. This part is typically held in RAM at all times, or game play would become crazy slow. Ozmoo uses virtual memory on C64, Plus/4 and C128. On C64 and Plus/4, you can also build a small game without virtual memory handling, so it can even be loaded from tape.
On the Commander X16, we load the first 16 KB of the story file into regular RAM, at $5f00-$9eff. The rest of the story file is loaded into banked RAM, starting at bank 1. This way, we can load even the largest Z-code files (512 KB) in one go. The code to find the correct bank and switch to it whenever accessing the game file is costly. I ran a benchmark Z-code program which sorts a large array, and it ran about five times faster on the X16 than on the C64, despite the X16 having an eight times higher clock speed. Five times faster than on a C64 is still quite fast, so not a big problem.
Ozmoo should run in any screen mode. It uses the screen mode you're in when launching the program, and it stays in this mode even after Quit. It briefly switches to mode 3 to show the splash screen, but then it goes back to the mode you were using. Word wrapping adapts to the current screen dimensions.
If you see the screen mode not working as stated above, maybe you're using a really old version of the interpreter? Try building a game on Ozmoo Online, and you should get Ozmoo 14.17 or above, which works as described.
We'll consider adding .prg to the executable file, if that's a convention on the Commander X16.
To get down from the 1 MB behemoth on a mainframe computer to something that could run on home computers of the day, Infocom:
* devised the Z-code format (which means code for the Z-machine, i.e. the Zork Machine), which is compact and allows for virtual memory (this marks the first time virtual memory was ever used on micro computers)
* reworked some texts and puzzles
* split the game in three parts
They made this work in 1979, and I think they needed to get each part of the game down to about 90 KB to make it fit on disks for some popular computer at the time. They only released Zork 1 first, in 1980. As that was a massive hit, becoming the most sold computer game in the US in 1980 (and 1981!), they release Zork 2 in 1981. They then released Deadline, and then Zork 3.
The smaller file is indeed the Z-code runtime, AKA Z-code interpreter.
The larger file is the Z-code program, i.e. the actual game. It's not actually compressed, but it uses the Z-code format which is quite compact in itself. Z-code does have built-in text compression, so storing a 100 character text typically takes up about 65 bytes. This compression happens at the individual string level though.
Z-code interpreters for typical 8-bit computers use a virtual memory system. The person programming the game can write a game of say 128 KB, and doesn't have to care about what data goes where in the file, or whether it will run on a computer with 32 KB or 256 KB of RAM - the Z-code interpreter handles the virtual memory and loads whatever parts of the game file that are currently needed into RAM. A small part at the beginning of the game file is "dynamic memory", i.e. its contents can change during game play. This part is typically held in RAM at all times, or game play would become crazy slow. Ozmoo uses virtual memory on C64, Plus/4 and C128. On C64 and Plus/4, you can also build a small game without virtual memory handling, so it can even be loaded from tape.
On the Commander X16, we load the first 16 KB of the story file into regular RAM, at $5f00-$9eff. The rest of the story file is loaded into banked RAM, starting at bank 1. This way, we can load even the largest Z-code files (512 KB) in one go. The code to find the correct bank and switch to it whenever accessing the game file is costly. I ran a benchmark Z-code program which sorts a large array, and it ran about five times faster on the X16 than on the C64, despite the X16 having an eight times higher clock speed. Five times faster than on a C64 is still quite fast, so not a big problem.
Ozmoo should run in any screen mode. It uses the screen mode you're in when launching the program, and it stays in this mode even after Quit. It briefly switches to mode 3 to show the splash screen, but then it goes back to the mode you were using. Word wrapping adapts to the current screen dimensions.
If you see the screen mode not working as stated above, maybe you're using a really old version of the interpreter? Try building a game on Ozmoo Online, and you should get Ozmoo 14.17 or above, which works as described.
We'll consider adding .prg to the executable file, if that's a convention on the Commander X16.
To get down from the 1 MB behemoth on a mainframe computer to something that could run on home computers of the day, Infocom:
* devised the Z-code format (which means code for the Z-machine, i.e. the Zork Machine), which is compact and allows for virtual memory (this marks the first time virtual memory was ever used on micro computers)
* reworked some texts and puzzles
* split the game in three parts
They made this work in 1979, and I think they needed to get each part of the game down to about 90 KB to make it fit on disks for some popular computer at the time. They only released Zork 1 first, in 1980. As that was a massive hit, becoming the most sold computer game in the US in 1980 (and 1981!), they release Zork 2 in 1981. They then released Deadline, and then Zork 3.
Re: New CX16 support for Ozmoo 14
It has arisen somewhat organically; to the X16, all files residing on the SD card are of type PRG (unless they're directories), so you can't tell which files are intended to be executable and which files are just data the way you can on Commodore floppies by looking for PRG vs SEQ (or REL or USR). So we've fallen into the habit of giving executables the PRG extension in the filename itself. This goes for both tokenized BASIC programs and machine language binaries, whether with or without a stub loader.We'll consider adding .prg to the executable file, if that's a convention on the Commander X16.
Re: New CX16 support for Ozmoo 14
We just released Ozmoo 14.36.
Ozmoo now supports Undo on Commander X16, i.e. Ozmoo copies the entire state of the virtual machine to Video RAM every turn, and if you perform an Undo, it restores the last saved state. This lets you take back a move that didn't turn out so well.
To perform Undo, type UNDO in the game. If this isn't recognized, it's probably a game written for Z-machine version 1-4, in which case the game code can't perform an Undo, but Ozmoo can - press Ctrl-U to make Ozmoo Undo! (If Ctrl-U can be used for Undo, the splash screen will mention this fact as well).
Ozmoo now supports Undo on Commander X16, i.e. Ozmoo copies the entire state of the virtual machine to Video RAM every turn, and if you perform an Undo, it restores the last saved state. This lets you take back a move that didn't turn out so well.
To perform Undo, type UNDO in the game. If this isn't recognized, it's probably a game written for Z-machine version 1-4, in which case the game code can't perform an Undo, but Ozmoo can - press Ctrl-U to make Ozmoo Undo! (If Ctrl-U can be used for Undo, the splash screen will mention this fact as well).