Grammar sizes in ZIL

Authoring ZIL
, ,
1

I asked Drew Cook (which led to this post) but I’m still wondering how to calculate grammar (and other) sizes for z-machine games.

I attempted to use the INFODUMP.exe file from the z-machine decompiler on my game, which led to a bunch of statistics that I don’t think I’m after, also they were in (I think) hexadecimal form.

Then I tried using the TXD.exe file, but apparently the grammar table is “illegal size” and caused no output, which is weird because the last 3 Infocom parser games probably had a bigger grammar size.

I wonder what’s going on here. How would I fix it? I already used the zil abbreviations, but I’m not even sure if it’s to do with ZIL or z-machine in general.

Thanks

2 Likes
2

By “grammar size” are you referring to the total amount of text able to be viewed by the player?

1 Like
3

I think the problem here is that the grammar table format isn’t part of the Z-Machine specification. Rather, it’s a mutual agreement between the parser and the compiler. So TXD has to figure out which format to assume.

The short answer is probably that to make TXD work on a game compiled with ZILF, you have to give it a serial number saying that the game was built in the 1980s. That should make TXD pick one of the Infocom grammar table formats. Otherwise, it will assume that it’s an Inform game and pick one of the Inform grammar table formats.

Or you could try using the -g option to TXD to “turn off grammar for action routines”.

At least, that’s the conclusion I came to when I was trying it time time ago. If I remember correctly.

2 Likes
4

Thanks, how do I change the serial number? There appears to be no constant or lowcore variable I can change.

EDIT: did it, it gives me a list of stuff. But nowhere do I find the variables about the grammar or other variables. Sorry.

1 Like
5

TXD can identify a couple of parser-formats. Looking at the source code.

From tx.h:.

enum parser_types {
	infocom_fixed,
	infocom_variable,
	infocom6_grammar,
	inform5_grammar,
	inform_gv1,
	inform_gv2,
	inform_gv2a

If you look at showverbs.c (tip: this file also contains a lot of useful information about the different formats in the comments.) you see that it uses the serial-number and the version-number to identify infocom6_grammar. The serial-number (date) must be from the 80s (8xxxxx) and the z-version must be 6. The z-version is stored in byte 0 of the game file and the serial-number in bytes 18-23, you can change these with an hex-editor if you don’t have the source code. If you are compiling with Zilf you can either set the serial-numer with LOWCORE or force a serial-number with the -s directive during the Zapf-stage.

I’m not sure what variables you are after but aside from the pointers to areas defined in the header the rest is much up to how the compiler chooses to structure the data. Tis is done differently between different versions of the Zilch-compiler (Infocoms), versions of Inform, Zilf and Dialog. You need knowledge of the compiler or you need to search for patterns in the data to identify were, for example, grammar is stored, where the z-code area are and where the higt string area starts.

EDIT: There are also a couple of new opcodes added in version 1.1 of the z-machine specifications (three I think, mostly around printing and testing for Unicode-characters) that TXD can’t decode.The dissassembly gets scrambled or TXD simply crash when one is encountered.

5 Likes
6

It’s a bit unclear what you’re trying to do.

ZILF has a debug -d switch. Does that produce the info you need?

2 Likes
7

I set that on, but nowhere does it show the information. Where do you mean to find them?

8

so, in theory the best solution is adding to TXD the format used by ZILF ?

After all, the source is of 1998 vintage, a new version, whose take into account the last quarter of a century or so of Z-code development is perhaps sorely needed…

Best regards from Italy,
dott. Piergiorgio.

2 Likes
9

Not necessary. Zilf have no unique format. But maybe a new way to recognize a v6 game as Zork0 in Nother way than through the compilation date (the serial number).

4 Likes
10

The best solution is to update ZILF to display the statistics you want, if it doesn’t already.

EDIT-ADD: I don’t know if it does! Nor do I know where the -d debug data is written. I haven’t used ZILF, and a quick test only revealed that I don’t have the right version of Mono installed.

2 Likes
11

If you have workspace on the file set up, I think it appears as a .dbg file (readable with a hex editor). I still don’t know where the info is.

2 Likes
12

Exactly! That could be really good.

2 Likes
13

FWIW, ZILF 0.9 has binary packages for Windows, Linux, and Mac that include the necessary .NET runtimes.

2 Likes
14

I’ve noticed that the Linux version can bit a bit finicky. At least on my system (unstable Debian) it won’t run out of the box:

$ zilf
FailFast:
Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.

   at System.Environment.FailFast(System.String)
   at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
   at System.Globalization.GlobalizationMode..cctor()
   at System.Globalization.CultureData.CreateCultureWithInvariantData()
   at System.Globalization.CultureData.get_Invariant()
   at System.Globalization.CultureInfo..cctor()
   at System.StringComparer..cctor()
   at System.AppDomain.InitializeCompatibilityFlags()
   at System.AppDomain.Setup(System.Object)
Aborted (core dumped)

Apparently it needs libicu67, which is no longer available. If I install that package from an older version, everything seems to be just fine. (I’m only mentioning this in case someone else has this problem.)

4 Likes