Discussion:
Infocom Z5 games: Improving my "InterL" project?
Add Reply
Steve Nickolas
2018-02-10 07:39:04 UTC
Reply
Permalink
Raw Message
So far, the Z5 version of InterL is able to create usable disks only for
interpreter A. Unfortunately, this interpreter is full of bugs and
doesn't work very well with the majority of games - not only failing hard
with Inform games, but even with some actual Infocom games.

Sherlock uses the F interpreter; H2G2 uses the E interpreter. (There is a
cracked version of Leather Goddesses of Phobos using the H interpreter;
since it can't tell when the wrong disk is inserted, I don't want to use
cracked H even though it would save me having to encode 18-sector tracks
for the second disk.)

The method by which I inject games now is basically the reverse of the
method by which tools for extracting them work. I'm obviously not doing
something right, since the newer interpreters don't like my disks.

(This is http://3.buric.co/interlz5-001.zip from about a year ago.)

The specific need for this is related to 5.25" disks; as Z5 files can be
up to 256K in size the need to span them across 2 disks is still somewhat
necessary. For larger media, well, qkumba's been working on that. ;)

-uso.
qkumba
2018-02-11 04:48:05 UTC
Reply
Permalink
Raw Message
As we noted elsewhere, the Sherlock interpreter runs all Infocom Z5 files, and many modern ones, too.
The Beyond Zork interpreter runs only a subset of Infocom Z5 files, but succeeds on a collection of modern ones where Sherlock fails.

From reading your source code, one thing stands out: the 100864 bytes limit is specific to certain titles. The limit was removed in the later interpreters, allowing them to go up to track 35 for the static data (though I haven't found any that do).
qkumba
2018-02-11 05:21:28 UTC
Reply
Permalink
Raw Message
For the titles where the limit was removed, bytes 4 and 5 in the .z5 are the size in big-endian format.
Divide it by 64 and you'll have your block limit.
Then multiply it by 256 and you'll have the byte limit.
For Sherlock, it's $78EA -> $01E3 -> $1E300 -> 123648 bytes.
Steve Nickolas
2018-02-11 09:33:24 UTC
Reply
Permalink
Raw Message
Post by qkumba
For the titles where the limit was removed, bytes 4 and 5 in the .z5 are the size in big-endian format.
Divide it by 64 and you'll have your block limit.
Then multiply it by 256 and you'll have the byte limit.
For Sherlock, it's $78EA -> $01E3 -> $1E300 -> 123648 bytes.
Hm.

So I'm doing this...

l=fgetc(file);
if (l!=5)
{
fclose(file);
fprintf(stderr, "%s is not a Z5 file\n", argv[2]);
return -1;
}
/* ignore these bytes */
l=fgetc(file);
l=fgetc(file);
l=fgetc(file);

max1=fgetc(file);
max1<<=8;
max1|=fgetc(file);
max1<<=2;

(i.e., I'm reading a big-endian word from offset 4-5, then multiplying it
by 4 (i.e., 256/64) and treating this as the byte size of disk 1... it
looks like I've misunderstood something.)

-uso.
qkumba
2018-02-11 18:24:56 UTC
Reply
Permalink
Raw Message
Post by Steve Nickolas
(i.e., I'm reading a big-endian word from offset 4-5, then multiplying it
by 4 (i.e., 256/64)
That's not exactly what I intended.
If you don't divide by 64 and then multiply by 256, then you'll need to round the result down to a multiple of 256.
Post by Steve Nickolas
and treating this as the byte size of disk 1... it
looks like I've misunderstood something.)
Count from zero not one. You're picking up bytes 3 and 4, not 4 and 5.
Steve Nickolas
2018-02-11 18:53:04 UTC
Reply
Permalink
Raw Message
Post by qkumba
Post by Steve Nickolas
(i.e., I'm reading a big-endian word from offset 4-5, then multiplying it
by 4 (i.e., 256/64)
That's not exactly what I intended.
If you don't divide by 64 and then multiply by 256, then you'll need to round the result down to a multiple of 256.
Post by Steve Nickolas
and treating this as the byte size of disk 1... it
looks like I've misunderstood something.)
Count from zero not one. You're picking up bytes 3 and 4, not 4 and 5.
There's 4 "fgetc"s, followed by the 2 that become max1.

In its current form I get...something that works for Sherlock, but not for
(say) Zork 1...

l=fgetc(file);
if (l!=5)
{
fclose(file);
fprintf(stderr, "%s is not a Z5 file\n", argv[2]);
return -1;
}
/* ignore these bytes */
l=fgetc(file);
l=fgetc(file);
l=fgetc(file);

max1=fgetc(file);
max1<<=8;
max1|=fgetc(file);
printf ("%04X\n", max1);
max1>>=6;
max1<<=8;

printf ("%lu\n", max1);

will display the hex 78EA and the decimal 123648, which seems to be right
- and the diskset appears to work (boots correctly, $VERIFY works).

I try the same method with Zork 1, and I get 2BC0 and 44800, and a broken
diskset.

-uso.
qkumba
2018-02-11 23:39:54 UTC
Reply
Permalink
Raw Message
Post by Steve Nickolas
There's 4 "fgetc"s, followed by the 2 that become max1.
Excuse me. I missed that first one.
Post by Steve Nickolas
In its current form I get...something that works for Sherlock, but not for
(say) Zork 1...
I've never seen the z5 version of Zork I. If you can share it, then I'd be happy to investigate further.
Steve Nickolas
2018-02-12 01:37:36 UTC
Reply
Permalink
Raw Message
Post by qkumba
Post by Steve Nickolas
There's 4 "fgetc"s, followed by the 2 that become max1.
Excuse me. I missed that first one.
Understandable. (Though it was separated off by the check for the magic
number "5".)
Post by qkumba
Post by Steve Nickolas
In its current form I get...something that works for Sherlock, but not for
(say) Zork 1...
I've never seen the z5 version of Zork I. If you can share it, then I'd
be happy to investigate further.
http://3.buric.co/zork1.z5

-uso.
I am Rob
2018-02-13 18:09:40 UTC
Reply
Permalink
Raw Message
Post by Steve Nickolas
So far, the Z5 version of InterL is able to create usable disks only for
interpreter A. Unfortunately, this interpreter is full of bugs and
doesn't work very well with the majority of games - not only failing hard
with Inform games, but even with some actual Infocom games.
Sherlock uses the F interpreter; H2G2 uses the E interpreter. (There is a
cracked version of Leather Goddesses of Phobos using the H interpreter;
since it can't tell when the wrong disk is inserted, I don't want to use
cracked H even though it would save me having to encode 18-sector tracks
for the second disk.)
The method by which I inject games now is basically the reverse of the
method by which tools for extracting them work. I'm obviously not doing
something right, since the newer interpreters don't like my disks.
(This is http://3.buric.co/interlz5-001.zip from about a year ago.)
The specific need for this is related to 5.25" disks; as Z5 files can be
up to 256K in size the need to span them across 2 disks is still somewhat
necessary. For larger media, well, qkumba's been working on that. ;)
-uso.
Got the F-interpreter moved to a Prodos disk, now to match the data on the sectors with the data in memory.
qkumba
2018-02-14 18:34:56 UTC
Reply
Permalink
Raw Message
Okay, the Sherlock interpreter carries an assumption about a minimum size for the side A data, which Zork I isn't achieving.
However, if I change the interpreter code T00 S04 A$62 and A$73 from #$6F to #$71 then it loads (though it prompts twice to turn over the disk in Zork's case because of the hard-coded prompt in the second case).
The #$6F is a zpage location that holds the low number of blocks left on side A ($70 holding the high part).
It was being zeroed by the prompt, causing a failure to resume reading after turning over the disk. Changing it to #$71 (a zpage location that is initialised later, thus safe to use at that point) avoids that problem.

So, Steve - your conversion process works!
qkumba
2018-02-14 18:37:40 UTC
Reply
Permalink
Raw Message
The ProDOS version didn't need this change because it never prompts, thus the count remains always valid.
Loading...