Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

20 Excellent

About fredrik

  • Rank
    Combat Commando
  1. We have started working on PunyInform again. A new volunteer showed up, and now everyone seems to have found some new energy and time to work on the project.
  2. If you're talking about the library, there hasn't been much acitivity during summer. Things should start happening during fall though. You can follow the project at https://github.com/johanberntsson/PunyInform As for the Ozmoo interpreter, it has received some bugfixes and has gained support for some new languages. It now has support for games in English, Swedish, German, Italian and Spanish. You can follow the project at https://github.com/johanberntsson/ozmoo If you wanna try out Ozmoo, you can build disk images of any Z-code games you like at http://microheaven.com/ozmooonline/
  3. Our goal with Ozmoo was to create a terp that can be used with a vanilla Commodore 64 + 1541 disk drive, because that's how some people want to enjoy their text adventures. Also, it will run fine (and faster!) if you replace the 1541 drive with an SD2IEC, a 1541 Ultimate or a Pi1541. And it will benefit from a RAM expansion cart if you have one. And of course, it will run fine in an emulator. If you want to write a Z-code terp that benefits from modern large capacity drives, it's essential that these drives support either raw block access (read sector 5 on track 3) or fast file seeks (start reading from byte 65536 in file story.z5). We opted for the lowest common denominator - using raw block access on a 1541 disk (or disk image). This works on all hardware, and gets really fast on the modern devices. There are some other terps for the C64 which one may want to consider, if one would be looking for something to port to Atari: There is an interpreter which requires a RAM expansion, called Zeugma. It's a lot faster than Ozmoo, it has no limit on dynamic memory size like Ozmoo, it can fit 53 characters per line through the use of a highres screen and a 6 pixel wide font. Zeugma doesn't support z3 stories, it can't save or restore the game state, and the code is heavily based on the assumption that there's a RAM expansion holding the story data. Also, there is Infocom64, a revised version of Infocom's z3, z4 and z5 interpreters which skips the raw block access and loads story data from a regular file instead. To do this, the story data has to be on an uIEC (SD2IEC) drive or the C64 must have a RAM expansion cart installed. Also, since this terp is based on Infocom's code, the legal situation is messy.
  4. Games like Trinity and AMFV need a disk drive with about 240 KB accessible without switching or flipping disks. The C64 had the C1541, which only had about 170 KB per side, and could only access one side at a time. The C128 had the C1571 which could access both sides and thus had about 340 KB accessible. Ozmoo has build modes for dual C1541 disk drives (340 KB) or a C1581 disk drive (3.5", 800 KB), to play these bigger games. Adding fastload code is on our todo-list. Currently, Ozmoo is faster than Infocom's interpreters for z3-games, but about 30% slower for z5 games, when using a real disk drive and no memory expansion. You're welcome!
  5. Also note that there's a related discussion going on at
  6. I believe Infocom tried their best to get information out in a format that could be easily understood. This sometimes meant simplifying information to a point where it wasn't enitrely true. I.e. they may have said that these titles required 128 KB or RAM, even if it was theoretically possible to play them on a machine with 64 KB of RAM and a large capacity disk drive. When considering which games to sell for which platforms, they may have decided that the games would be too slow on platforms with less than 128 KB, or that they would require disk drives that were so rare that it didn't make sense to market the games for these platforms. Perhaps that magazine got some early information that the game would be released for some Atari 8-bit, but then Infocom changed their minds. All of these games can be played on a Commodore 64 now. If the Commodore 64 had been blessed with a fast, cheap, large capacity disk drive, I'm sure more of these games would have been released for the C64 (Nord and Bert was indeed released for the C64).
  7. Hey there, Glad to see some interest in Ozmoo, which I co-wrote. Ozmoo is open source and may be ported freely. We will be happy to answer any questions that may arise too. I admit Ozmoo and its build system are a bit complex. When considering tools to write your own Z-code games to be run on an 8-bit computer, performance is an issue. Any non-trivial game created in Inform 7 will be painfully slow on a typical 8-bit machine. A real-world game, if it can even run on an 8-bit machine, may take several minutes to process each command. This is due to the way Inform 7 was designed and developed, where performance on machines slower than say 1 GHz wasn't really considered. Inform 6 is fast enough, as a language. However, it comes with a quite powerful standard library, which has become more and more complex over the years. A game compiled with library 6/2 may be quite fast, but a game compiled with library 6/12 will most likely feel sluggish. However, so many bugs have been fixed in later versions, that it would be painful to use the oldest versions. Also, z3 games require a smaller interpreter and may therefore be a better fit for 8-bit machines than z5, but the Inform 6 library can't be used to build z3 games. ZIL is probably the best option right now. It's fast and powerful. As for the syntax, it may take some time to get used to. There's an active and friendly group on Facebook called ZIL - Zork Implementation Language, where you can get all the help you need to get started. Also, the ZIL source code for all Infocom games was published a while ago, so there's lots of code to learn from. We are currently working on a replacement library for Inform 6, which has performance on 8-bit machines as its main design goal. We're aiming for a parser which feels on par with Zork I, while keeping the code small and fast. Also, we're planning to allow authors to build z3 games using this library. //Fredrik
  • Create New...