intfiction.org

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):

• Advent.d64
• ballyhoo.d64
• border_zone.d64
• cutthroats.d64
• deadline.d64
• enchanter.d64
• hitchhikers_guide.d64
• hollywood_hijinx.d64
• infidel.d64
• leather_goddesses_of_phobos.d64
• lurking_horror.d64
• moonmist.d64
• nord_and_bert.d64
• planetfall.d64
• plundered_hearts.d64
• seastalker.d64
• sorcerer.d64
• spellbreaker.d64
• starcross.d64
• stationfall.d64
• suspect.d64
• suspended.d64
• wishbringer.d64
• witness.d64
• zork1.d64
• zork2.d64
• ztuu.d64

Here's a zip of the d64 files I created on the Internet Archive (Super out of date version of Ozmoo though. Look forward to a new version of this pack)

_________________
~~~
My ebooks on Amazon
My ebooks on Smashwords

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: http://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:

* 1541 images can be copied to real disks for the 1541, the most common drive for the C64
* 1541 images can be used on all modern disk drive replacements, like the 1541 Ultimate II+, the Pi1541 and SD2IEC.
* 1541 images can be used with all C64 emulators.

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.

_________________
~~~
My ebooks on Amazon
My ebooks on Smashwords

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.

_________________
Daniel Stelzer

I believe I got the copy I've used from time to time from here https://ifarchive.org/indexes/if-archiv ... tions.html

Of course, it's for inform 6, not inform 7.

_________________
~~~
My ebooks on Amazon
My ebooks on Smashwords

Also available at these pages:

https://inform-fiction.org/extensions/complete.html

https://inform-fiction.org/extensions/replacements.html

_________________
~~~
My ebooks on Amazon
My ebooks on Smashwords

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: https://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.