Stumbled across this the other day. Ozmoo is a new open source z-machine interpreter for the Commodore 64. It’s a neat project that has a lot of potential for taking new games to old hardware.
Quoting the site:
I had to hack a bit at the make.rb file to get it to work under Linux. You can grab my fork here if you can’t wait for the main branch to check and merge my changes.
You’ll also need the acme cross-assemler and exomizer.
How I got it running under Linux:
Of course, just as the main README says, you’ll need ruby and vice:
sudo apt-get install ruby
sudo apt-get install vice[spoiler]First, I modified make.rb, so you’ll have to grab my modded fork:
git clone https://github.com/howtophil/ozmoo.git
[/spoiler]
My changes have now been merged with the main source, so grab that instead:
git clone https://github.com/johanberntsson/ozmoo.gitThen change into the ozmoo directory, clone the acme assembler source, and make acme:
cd ozmoo
git clone https://github.com/meonwax/acme.git
cd acme/src
makeI find it easier to leave acme in place as a subdirectory, so mod the make.rb file and set
$ACME = "acme/src/acme"Then download exomizer, extract it into an exomizer subdirectory, and make exomizer:
mkdir exomizer
cd exomizer
wget https://bitbucket.org/magli143/exomizer/wiki/downloads/exomizer-3.0.1.zip
unzip exomizer-3.0.1.zip
cd src
makeAt this point you should be able to turn a z[3,4,5,8] file into a .d64 Commodore 64 diskette image from the top level of your ozmoo directory:
ruby make.rb game.z5You’ll also need build-essential, if you don’t already have it.
sudo apt-get install build-essentialAnd whatever other requirements to build that acme and exomizer list in their documentation.
My changes have been merged with the main source.
tiny question: how to fit the majority of .z5 and virtually all .z8 in a .d64 (664 blocks of 256 bytes, total 169,984 bytes (aside the footprint of the 'terp…) ??
better targeting the 1571 (.d71) disk image… or better, the 1581 (.d81) disk image, IMVHO.
Best regards from Italy,
dott. Piergiorgio.
Curious? Will this run on native c64 hardware?
I know all the old Infocom games fit, though a few still fail to run.
I think there are quite a few smaller games still 
Also, there are plans for it to span 2 disks/disk-images in the future.
I believe it should, though I don’t have a way to transfer the disk images to C64 diskettes.
I have one of the SDHD disk emulator gadgets. I will give that a try.
Thank you
As discussed in another debate, the majority of .dat/.z? fails on C=64 was because of the 40 columns; AFAICT, inform library don’t handle, or don’t handle well, less than ~50 columns.
IIRC, in the z-machine specs was noted that at least in the .z3 format there was support for multi-disk, because Tandy’s disk format has a very low capacity (5.¼ SSSD FM modulated, ~80-90k) so I think that spanning into 2 disk/images is more than feasible.
Best regards from Italy,
dott. Piergiorgio.
Well, I processed all the old Infocom .dat games I had and these are the ones that worked (or at least boot up in x64 the VICE emulator):
Good to see there’s interest in our little project.
Ozmoo can currently build to one or two 1541 disk images. When building to two images, you currently need to mount the “boot disk” in drive 8 and the “story disk” in drive 9. This should soon be changed so you can use drive 8 for both.
The current size limitation is that the non-dynamic memory of the story file must fit on a 40-track disk, minus 2 sectors (a total of 191,5 KB). In practice, this means Inform games up to about 210 KB should be playable. If they have a large amount of dynamic memory, they can be bigger, but games with larger dynamic memory will be prone to constant disk access which will probably make them horribly slow except maybe on emulators or with modern replacements for the 1541, like the SD2IEC.
This project is very much under development, so don’t expect production quality gameplay just yet. Save/restore hasn’t been implemented, there are certainly bugs here and there, and there are some features which we aren’t quite happy with yet. We also hope to find ways to increase the speed a bit more.
On the 40-column issue: Many Inform games work fine with 40 columns. Some fail when they print quotes or menus, but work well during regular gameplay. If you are writing a new game, and intend to target the C64 platform, it’s not hard to make it work perfectly well.
I made a compilation of Inform games for the C64 a while ago, using Infocom’s interpreters from back in the day: microheaven.com/PostInfocom/ . All of the included games work well on the C64.
As for Commodore 64 compatibility: Yes, Ozmoo should certainly run on a real C64, either with a real 1541, or with a modern-day replacement like S2IEC or Ultimate 1541 II+. I have tried it on a C64 with an SD2IEC myself.
Please note that the C64 will never be a suitable platform for playing all Z-code games. I’ve noticed that many Inform 7 games will feel sluggish even on a 700 MHz Raspberry Pi with 256 MB of RAM. Large, complex Inform 6 games may also be too much for the C64.
The C64 has 64 KB of RAM. Ozmoo will leave about 50 KB for game data. The dynamic memory part of the story file stays resident in C64 RAM at all times. If a game has 30 KB of dynamic memory and 10 KB of static memory (like the dictionary) which is accessed every turn, there is 10 KB left for all other parts of the story file. If the game calls code (parser, clever object routines etc) which adds up to more than 10 KB each turn, the game will be swapping constantly and will be a pain to play.
Smaller games should run just fine, unless they do a lot of complicated processing and/or use a lot of dynamic memory. A really large z8 game is a lot less likely to run smoothly. If you were to write a z8 game specifically for use on a C64, making sure not to use up too much dynamic memory or execute large amounts of code every turn, you could probably make it run well.
If you read the todo-file, you can see that we’re hoping to target 1571 and 1581 later on. Our reasons for starting with the 1541 are:
Inform 6 and z5 (or z3 with an older inform 6) are probably your best bets for dev of inform games meant to be played on the c64.
Indeed. Or possibly ZIL. There is a Facebook group where ZIL coders meet, and it seems pretty active.
If you use Inform 6, it would probably we wise to use the Minform library. It sacrifices a few things from the standard library (the most painful one being the parser’s ability to deal with multiple objects as in GET ALL) to make for a much smaller compiled size. Running a Minform game still seems quite a bit heavier than a typical Infocom game though.
Is Minform still around? I haven’t been able to find any live links to it.
I believe I got the copy I’ve used from time to time from here ifarchive.org/indexes/if-archiv … tions.html
Of course, it’s for inform 6, not inform 7.
Also available at these pages:
I just discovered the part of the Z-machine spec that discusses this:
“In the Infocom period, the larger Version 3 story files would not entirely fit on a single Atari 800 disc (though they would fit on a single Apple II, or a single PC disc). Atari versions were therefore made which were identical to the normal ones except for having Flags 1 bit 2 set, and were divided into the resident part on one disc and the rest on another.”
(Source: inform-fiction.org/zmachine/sta … ect11.html )
So, this kind of disk splitting is exactly what Infocom used for larger z5 games like Borderzone on the C64 as well (The story file is larger than a disk). Ozmoo now supports this way of building a game (build mode S2: add -S2 as argument to make.rb), but it also supports splitting the non-resident part over two disks (build modes D2 and D3), allowing for games up to about 400 KB in size. Of course, you need two disk drives to play the game. And if it’s a complex game, with lots of code that needs to run every turn, thousands of objects etc, it may be unplayable due to speed issues or using too much dynamic memory.
Putting that in the flags bit seems like a slight category error. The interpreter should know where to find the game file before loading it in. The disk layout is between the interpreter and whoever packages up the game, not a Z-spec question.