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