Fweep 0.8 (a Z-machine interpreter)

I wrote a Z-machine interpreter called Fweep meant to be very portable using only plain C codes. See http://ifwiki.org/index.php/Fweep for some information. The current version is 0.8. (For the other interpreter with similar codes, using SDL and supporting more features of Z-machine, see Aimfiz.)

How’s it compare to bocfel, which I understand is also meant to be a very portable plain C terp?

Don’t forget to check Praxix and Czech too: curiousdannii.github.com/if/tests/czech.z5

I don’t know Bocfel, but this one is support version 9 and 10, and has some debugging (I will add some more), and support Tandy mode even for other than version 3.

Thanks, that “praxix” and “czech” helps.

If you ever have any other bug report/feature suggestion you can post it in here and/or in the wiki, please.

Where are versions 9 and 10 specified?

http://zzo38computer.org/zmachine/z9.txt The rest of the document can be ignored, except for “flags 3” which is also supported in Fweep (despite clearing many of these flags, it tries to approximate the features it cannot implement). Those files helped (although I needed to look at the source-codes, luckily I found it); now I fixed most of it (copy_table still seems slightly broken, for some reason).

I’m not too thrilled about naming the specs Z-machine 9 and 10. It’s bound to cause confusion, especially as there have already been attempts at creating a Z-machine v9 spec in the past. It would be better to call any non-standard changes to the spec something else, like Z-machine ZZO or whatever. Actual incrementations to the version number should happen through community consensus.

But as there is no authority to enforce what should be done with the Z-machine, I’ll have to settle for head shaking and loud tutting.

And v10, for that matter. Multiple attempts at each, I believe.

Version 0.3 is now released, which fixes various bugs (the copy_table bug wasn’t the only one) and adds a debugger built-in.

As it turns out, a few things are still broken, though.

Version 0.4 is now released, and that fixes the remaining bugs (which had to do with the parse buffer).

How’s it compare to bocfel, which I understand is also meant to be a very portable plain C terp?

it doesn’t seem to be able to read a zblorb game, it doesn’t support accented characters but at least it replace them with the non diacritic version of the letter (‘é’ or ‘è’ will become ‘e’). It doesn’t have a status line.(edit: it seems to have, but I can’t find the escape character to display it and I’m not sure it works for v5 and v8)

On the other hand, it doesn’t require glk or ncursesw so it’s somehow easier to compile on exotic plateforms.

I hope it will improve over time, at least for unicode support, and being able to extract the game data from zblorb.

Bocfel can be built with a standard C99 implementation only (i.e. nothing but the standard library):

make GLK= PLATFORM=

However, there are a few caveats that might make it a bit less portable than fweep, depending on how fweep is implemented:

  • Bocfel uses C99; this is an ISO standard, so it is standard C, but it is not as widely implemented as C89/C90 (notably, Microsoft does not appear interested in upgrading its compilers to C99)
    [list]
    [] Obvious C99 features I can think of off the top of my head: snprintf(), fixed-width integers, variable length arrays, compound literals
    [/
    :m]
    [] Bocfel assumes a character set that is compatible with ZSCII in the range 32-126 (which means ASCII/Latin-1/Unicode all are compatible)[/:m]
    [*] Bocfel uses C99’s fixed-width integer types int16_t and uint16_t; these types are required to be 16 bit two’s complement integers, so if the platform does not support such types, Bocfel will fail to build

  • Moreover, Bocfel assumes that converting an out-of-range value to int16_t results in the “correct” value, but C99 does not mandate this; on the other hand, an implementation would have to go out of its way for this conversion to cause a problem
    [/*:m][/list:u]

I’m slowly trying to remove these limitations (apart from “implemented in C99”), but for the time being, Bocfel is not quite as portable as it theoretically could be, although in practice these limitations aren’t a problem.

Edit:
I should also point out that in its standard C (that is, non-GLK) mode, Bocfel does not go out of its way to be user-friendly. For example, there’s currently no way to see the status bar.

I have no intentions to add this. A program to extract the Z-code from a zblorb can be used.

Correct. It uses the ASCII equivalents mentioned in the Z-machine standards document. The actual ZSCII codes will be written to the transcript, however.

The escape character is defined by the command-line parameter; for example, “fweep -e _” makes it an underscore. Enter the escape code and “y” to show the status line (or use the escape code and “?” for help; the command “?” in the debugger can also be used for help). It only works in versions 1 to 3 games; the status line won’t display for newer games since it uses the upper window.

This is the point.

I have no intentions to add either feature. You may fork it if you wish, but I happen to think Unicode and Blorb were bad ideas to add to the Z-machine in the first place. (The standard specifies that the game shouldn’t try to use Unicode unless the standard number is 1 or higher, and Fweep doesn’t set the standard number, so a game that tries to use Unicode anyways violating the standard.)

My interpreter compiles in GNU89 mode; I haven’t actually checked precisely what features of C it uses, though, but it expects that an array of a negative size is a compiler error.

Fweep also makes this assumption.

Fweep defines fixed-width types using the “types.h” header, so it can be changed if needed to work on other platforms.

I am not sure whether or not Fweep requires this (although I think it does at least for version 9 and 10 story files).

Does Bocfel have an escape code feature? I think ZLR in dumb mode doesn’t even support save files and so on.

I will apply bugfixes if there are any, and possibly other changes too, but I don’t want to overcomplicate it. (There is one feature I might add: auxiliary files.)

Thank you for your feedback anyways; it is appreciated. I am working on another interpreter this time using SDL, and using most of the same codes to implement; it is independent of this one, although some bugfixes will apply to both.

It has a feature similar to what fweep’s escape code appears to do: there are special commands (prefixed with /, as in /save and /restore) which are handled by the interpreter rather than the game.

All standard features that are supported by Bocfel’s Glk mode are also supported in its dumb mode, apart from those dealing with screen handling. That means save files are supported, too.

However, I keep the dumb mode around more or less because I like the idea of a plain C interpreter. The primary use of Bocfel is certainly with Gargoyle; secondarily would be motivated tinkerers who might be using it with other Glk implementations. I’m probably the only person who makes any real use of the dumb version—it’s a good way to do benchmarking of the interpreter.

Re the unicode and blorb stuff… I would like to point out that any interpreter that ignores the huge non-english communities as well as an established and widely-used method for storing metadata is asking for trouble.

Well, you are free to fork it if you really want to.

Who do you anticipate will use this interpreter, and your versions 9 and 10?

People generally only fork software if they’ve got a reason to. Like when they’re actually using it. The opinions and suggestions given thus far in this thread don’t seem to be of the “I really need this software, could you implement this and that” type.

Version 0.5 is now released. It fixes the debugger and save game.

You might be correct. I am just saying that you can if you want to.

Version 0.6 is now released. It adds support for auxiliary files (if -a command-line switch is specified), and a few other things.

Version 0.8 is now released, which adds a score notification option (which might be useful since it cannot display the status bar), support for margins, support for shift-locks in versions 3 to 5 (Infocom’s documentation mentions it; Graham Nelson’s documentation forgot), and makes the FONT opcode return the previously selected font (in this interpreter, always 4, unless the game tries to select an unavailable font in which case it returns 0).

Here is another thing I will tell you: The latest version of fweep.zip is 48295 bytes long, and it includes not only the source-codes but also a Windows executable and a program for deal with auxiliary files! Even the oldest version of Bocfel listed in Google Code is 75.3 KB. (However, Bocfel does at least have partial support for version 6, and a few things Fweep lacks, but Fweep also has some things that Bocfel lacks! I will continue to update Fweep and Aimfiz as I add and change things, though.)