Thanks, I’ll try to understand all this.
LOWER ZSCII CHARACTER SET:
92 \
94 ^
96 ‘
123 {
125 }
126 ~
124 and 125 seem to be the same characters.
Thank you!
None of these characters exist in PETSCII, so we can’t show them unless we embed a custom character set. What we can do though, is map them for output to similar-looking characters.
We have already done this for two characters, character 95 (underscore) and character 124 (pipe). The pipe-like graphic character is in fact located at code 125 in PETSCII, so yes, 124 and 125 are currently the same character when printed.
EDIT: Added mappings for these characters. I suggest you PM me if you have further problems getting French characters to work. Hopefully I can update the docs to make it easier for the next person giving it a go.
I noticed this guy was porting zeugma to the bbc micro and I was wondering if you guys were thinking of porting ozmoo to the beeb as well.
github.com/hexwab/zeugma (it’s 3 years since it has seen dev)
There are of course several possible future ports.
We have listed a number of alternate versions we might want to make, but haven’t discussed priorities.
There is a guy who has shown interest in porting it to the PET. The code is there, for anyone who wants to have a go at creating a Beeb version too.
I created a page to package Z-code games with Ozmoo for playing on a C64 (real or emulated):
2 Likes
This is neat. I played around with this tonight, cutting ATS in half and then creating an image that spans two disks. I could only get it to work as a .z8. I guess it was too tight for .z5 even though it was under 256k.
The game does run a little slow, but it’s emulated and outputs a lot of text. The site works like a charm, and after watching the page do its stuff I don’t think that I could do it on my own.
Thanks for setting this up, I’d like to run my next game through this after it’s published.
- D
2 Likes
Looking good!
I would be interested to see your z5 file and your z8 file. As far as I know, there is no way to create a game that can compile to z5 but won’t wotk unless you compile it to z8.
Do both files work in other interpreters?
What language are you using?
I’m using Inform 6, but the .z5 came out at 255kb. It’s right on the cusp. When I compile to a .z8 it came out at 259kb. So they’re true to their size. Both work fine in Gargoyle. But I think it has something to do with the headroom of the .z5, I got it down to 253kb and it works fine now. Before it was corrupting something, so when I typed RUN it was gibberish.
Some news on Ozmoo:
We’ve added support for REU (Ram Expansion Unit), meaning that when you start a game, if you have an REU installed, you can choose to cache the entire game to the REU. It will take a bit longer to start, but you’ll never have to wait for disk access once the game has started.
Also, it means you can play games built for dual disk drive systems with just a single drive. I played Jigsaw.z8 (298 KB) yesterday, and it ran just fine.
There were a few different REU:s made by Commodore. However, there are better REU:s built into various carts, including the popular 1541 Ultimate II+.
In Vice, you can enable a virtual REU either through the Settings menu -> Cartridge/IO settings or using the commandline: “x64 -reu -reusize 512”
There is no new release of Ozmoo available yet, but you can get the latest code by downloading it as a zip file at https://github.com/johanberntsson/ozmoo , or you can use Ozmoo Online at http://microheaven.com/ozmooonline/
Also, Ozmoo Online just got support for using the two custom fonts which are included with the Ozmoo distribution.
Ozmoo can now produce .d81 disk images. This allows a Z-code game of arbirtary size on one disk. Note: Large Z-code games can still have too much dynamic memory to work, or they may be really slow.
Also, Ozmoo has new ways of handling the upper window (used for statusline, menus, printing quote boxes, some Z-machine abuses such as Robot finds kitten etc):
-
Ozmoo will auto-expand upper window if the program tries to print outside the current boundaries. They shouldn’t be doing this, but most terps auto-expand anyway to make the program work as well as possible.
-
Lines that are too long are automatically cropped at the right border. Sometimes ugly, but probably better than the alternative.
-
If a game tries to place the cursor in a negative column, Ozmoo will now keep track of the cursor position and just not print until the cursor is within the visible screen.
All in all, these changes make Ozmoo react as gracefully as possible to games that weren’t meant to run on a 40-column screen.
And for the lower window (where the normal game text is printed):
- Printing a paragraph that ends in the last column will no longer cause an extra linebreak.
This means we’re now using the full 40 columns without (as far as we know) any problems. Infocom’s interpreters for the C64 never used more than 39 columns, to avoid problems. Together with more flexible word-wrapping and a MORE-prompt that steals less screen space, this means we can often fit quite a bit more text in a screen than Infocom’s terps. See screenshots from Borderzone below.
Ozmoo Online has been updated with the new version: http://microheaven.com/ozmooonline
3 Likes
Congrats on getting Ozmoo to work with .d81 disk images. I was able to take Across The Stars, which is a 512kb .z8, and play it on Cloanto’s C64 Forever, using the REU in Ozmoo. I was even able to save the game and restore it. I haven’t played that far into it, but should Ozmoo save games that are stored in the REU. It great seeing it work, I even took my WIP and ran it through Ozmoo. It’s holding up well, even the hint system. 
Great Job - D
Thanks, glad you like it!
Ozmoo will only use the REU to cache static data. Using a REU doesn’t affect load/save in any way, except that if you have the game data cached to an REU you don’t need to insert the game disk again after saving or restoring.
This also means you can save a game when you play with REU and later restore it when you’re not using an REU and vice versa.
Release 2 of Ozmoo (Z-code interpreter for the C64) is out!
Details: https://github.com/johanberntsson/ozmoo/releases
Ozmoo is a lot more mature and stable compared to release 1 five months ago. There are currently no known bugs.
(Image: Jigsaw played on Ozmoo, using font PXLfont-rf)
1 Like
I hope reviving this thread is okay! I bumped into mention of Ozmoo when I was looking to see if there was a way to put a Z-File game on the C64, and from what I’ve read it sounds pretty slick. However, I’m concerned by the mention that Inform 6 games, at least using the standard library, are slow.
I read in the Lemon 64 forum thread, that you’ve been working on PunyInform as a faster alternative to said standard library. I know a release on that is some distance away, but will I be able to just use it instead of the standard library so long as I don’t use any features it doesn’t have? That is to say, can I start developing now, using the standard library, and eventually just swap your library in with possible minor changes? Or is it going to do things its own way?
I think it’s great if all things Ozmoo are collected in this thread. Okay, maybe this isn’t strictly Ozmoo, but until PunyInform is a bit more complete, there won’t be much discussion about it.
PunyInform will work like the standard library for most features that it supports. The basic stuff will, for the most part, work exactly the same.
The biggest exception to this that we see this far, is that all directions will be collected into one object. This is mainly done to keep the object count down. We’re aiming for PunyInform to be usable for z3 games, where there is a hard limit of 255 objects. Additionally, we think we can make parsing faster using a single object for all directions.
A simple game like Cloak of Darkness may not need any modification at all when switching from the standard library to PunyInform, except for including a different set of files.
On a somewhat related note - and if there’s a better thread for it, let me know - the mInform library recommends Inform 6.15 as the last version to support v3 files. I can’t find a Windows executable for that; I can find source, but I’ve never compiled anything on Windows. For now I can just use the latest Inform 6, but anyone have advice in this regard?
Sorry, can’t help you with Inform 6.15.
PunyInform uses Inform 6.33 to compile to z3 as well. It does require some hacking of veneer routines (Routines supporting the Inform language written in Inform and added by the compiler, but which can be replaced by the library), and the hacked routines make for a few limitations to what you can do, but it works. Off the top of my head, the limitations are that you can’t work with dynamic object creation/destruction and messages to an object can’t take more than one parameter.
Of course, you will also need to adhere to the hard limitations of z3, like that a property array can only hold four values.
Ozmoo Online now has support for building games written in German, Italian and Swedish: http://microheaven.com/ozmooonline/
Of course, the C64 doesn’t actually have accented characters, so we had to replace some of the characters it does have.
For Italian, the accented characters can be found by holding the CBM key and pressing various letters.
For Swedish and German, the accented characters have replaced various non-letter characters, such as [ ] £ @.
Ozmoo expects games to use the default Unicode translation table. Games that don’t will probably not work very well.
Filing a bug report: playing a game on a single D64 in drive 8 and attempting to save to a disk in drive 9, I accidentally mounted the blank image on drive 8 instead of drive 9. Ozmoo attempted to access the (empty) drive 9, failed, and locked up.