fredrik

My server is back online, and I have updated the collection with the new disk images for TI99/4a. Many thanks to Torrax for the help!

The z3 version of Lucid Night was used for all platforms in this collection. You should find it in the DOS (or MSDOS?) folder, possibly with a generic name like story.dat.it may also be in the Modern folder. My server is unfortunately down at the moment, but I should get it up in a day or two.

BTW, for both Lucid Night and Submarine Sabotage I used z3 files which were exactly 64 KB in size, and Ox said they still didn't work?

I'm the site owner. Thanks for your efforts! If you send me working disk images for games in the collection, I'll update the collection. Note that these are the games in the collection: A1RL0CK, by Marco Innocenti Blorp!, by Shawn Sijnstra A Clean Getaway, by Michael Bub The Fantasy Dimension, by Johan Berntsson Lucid Night, by Dee Cooke Submarine Sabotage, by Garry Francis I.e. Falling to Pieces is not part of the collection, but Lucid Night is.

If you've already managed to build the compiler from source (note that you need v6.36), you should just put it in your path, and to compile say `minimal.inf` you start a shell, go to the PunyInform folder and type: inform +lib minimal.inf -v3es The first part is the name of the compiler executable (typically inform or inform6), `+lib` means "if the program needs library files, expect to find them in directory lib". -v3es is a set of compile options that I often use: v3 means compile to a version 3 story file (*.z3), e means use abbreviations to make the story file shorter, s means show statistics for the story file.

Borogove.app is a great resource, and it was just updated to the latest PunyInform version. To use PunyInform on Linux, you may want to check out Inform6Unix: https://gitlab.com/DavidGriffith/inform6unix . It includes the latest version of PunyInform as well, and instructions on installation and use. You should also join our Discord server for PunyInform - see link at https://github.com/johanberntsson/PunyInform#community . It easy to get help there.

Just a note about game size. Ryan Veeder's game Craverly Heights has now been implemented in several different IF authoring systems, which are all capable of generating Z-code games. This is the size of the game files produced by the different systems: Original Inform 7 version (as z8): 258 kB Dialog version (as z5): 127 kB Inform 6 version (as z5): 86 KB PunyInform version (as z3): 49 kB. ZIL version (as z5): 48 kB All are Z-code. The last two are suitable for 8-bit computers. It's not the size in itself that is the problem with the others, but the fact that a quite small game becomes so big - there is so much game data that is part of the library (parser etc) and that is needed every move, that the interpreter has to swap from disk constantly. Note: The different versions of the game aren't *identical*. They use the library of each system, with each library supporting its own set of verbs, having its own set of standard responses etc. But everything that's in the Inform 7 source code - functions, objects, text strings etc, has been ported to each of these systems. You can use the exact same walkthrough to play any of the versions. Here's Ryan Veeder's page about the game and these ports: https://rcveeder.net/craverly/

Porting Ozmoo should be fairly straightforward. It just seems there's no one who has the interest, skills and time to do it. Frotz is written in C, meaning you'd get a much bigger and slower interpreter. That's typically ot a great fit for an 8-bit target.

Inform 7 can't target v3. Even if it could, the very smallest Inform 7 games are well above 200 KB in size, and the maximum size of a v3 game is 128 KB. Not even standard Inform 6 can target v3, at least not for the last 20-something years. I'm using (and developing) PunyInform, an alternate library for Inform 6, with the specific aim of making games that run well on 8-bit platforms. It supports v3, v5 and v8.

C is enticing in that it's so portable. C code is, however, at least for 8-bit platforms, always slower than even a naïve implementation of the same program in assembler. For 6502-based targets, the difference is typically bigger than for a lot of other targets. Also, C makes for a bigger program, which means you'll have less space for game data, so more swapping from disk. We spent about six months optimizing the assembler code of Ozmoo, and this roughly doubled the speed. Try playing a game in Ozmoo in VICE, with the emulator running at 20-25% speed. I think that's about the fastest you can hope for if you write an interpreter in C. As for portability: Ozmoo can be ported to other 6502-based platforms. It just takes that someone, who knows the platform well, decides to do it. Most of the code is platform independent. I'd be happy to help guide someone who takes on the task of porting to Atari. Steve Flintham ported Ozmoo to Acorn/BBC: https://zornslemma.github.io/ozmoo.html . Here's a game I wrote, playable on a BBC emulator in a browser window: http://www.bbcmicro.co.uk/game.php?id=3592 (Note: As is the norm for BBC programs, you press SHIFT to keep printing once the screen has filled with text)

Just a note: Inform 7 games can be compiled to Z-code or Glulx format. When compiled to Z-code, they still can't be run on 8-bit computers because they get waaaaaay too slow and they typically need a lot more stack space than a Z-code interpreter on an 8-bit machine can offer. As for Glulx: There are no Glulx interpreters for 8-bit machines, but games would be even slower in that format because it's bulkier, so more swapping.

I'd start by having a look at some of the modern, high-quality games. If you like the Infocom breed of text adventures, but they're too hard and frustrating, check out https://hlabrande.itch.io/tristam-island and https://8bitgames.itch.io/hibernated1

I'm a bit late to the show here, but you can choose colours and fonts with Ozmoo for Commodore computers. Head over to http://microheaven.com/ozmooonline/ to build disk images of your favourite Infocom games. The story files are already there, and it's the best version of each game (typically the last version that was released). You can also build Bureaucracy and Beyond Zork for any of the targets, even though they were only released for the C128.

Yes and no... Everything that can be learnt from the Z-machine header is read from the header when the game starts. Ozmoo comes with a make script written in Ruby, which builds the interpreter from source every time you package a game with the interpreter. To make the interpreter as small and fast as possible, it only includes code for the Z-machine version needed for this specific game, so you can basically build four different version of the interpreter, for z3, z4, z5 and z8 games. But additionally, you can customize the build further, like setting the default colours, adding text to the splash screen, customizing the cursor, putting in a custom font, changing the stack size, adding a loader showing an image etc. You can also build a game in two principally different build modes - singlefile mode or disk-based mode. If you build using a disk-based mode, the interpreter, the dynamic memory part of the storyfile and as much of the static memory part that will fit are put into one file, 62 KB big, which is then compressed with Exomizer, which also adds code to make it self-extracting. All of static memory is then put on disk as raw sectors, and the first two sectors of the disk contain information about what parts are included in the boot file and where the interpreter can find all parts of static memory on disk. So essentially, if you have built Zork 1 as a game on a disk (it's too large to build as a single-file build anyway), you can change it to play say Planetfall instead (both are z3 games), by decompressing the boot file, replacing the dynamic memory and the first part of static memory from Zork 1 with the dynamic memory and first part of static memory of Planetfall, compressing this as a new file (including the interpreter which was part of the original file), writing the static part of the Planetfall storyfile as raw sectors to the disk, then altering the first two sectors of the disk to reflect the change. While the layout of these sectors is documented, this is not a simple process to get right. So maybe you'll want to run the make script again instead, feeding it the Planetfall story file, and it will build you a disk image for Planetfall. Steve has opted to write his own Python script for the make process for BBC.

Ozmoo has been ported to BBC/Acorn, supporting shadow RAM, a coprocessor, different display modes, several different computer models and pretty much any memory configuration, including beasts with 192 KB of RAM. Steve Flintham has done a terrific job with this. See https://stardot.org.uk/forums/viewtopic.php?f=2&t=19975&start=420 You can play the game Calypso built with this interpreter online at http://bbcmicro.co.uk/game.php?id=2575 BBC Ozmoo is now being further developed as a separate branch, but Steve keeps adding bug fixes and improvements from the trunk. This project is still in alpha, but I think we'll see an official release soon. Meanwhile, Ozmoo (the trunk) has gained support for Commodore Plus/4 and C128. You can now build games for the C64, C128 and Plus/4 at http://microheaven.com/ozmooonline/ If someone in the Atari community wants to put in the effort required, they could adapt Ozmoo to work on Atari as well, no doubt. I'd be happy to help out with advice.