| Infocom Z5 games: Improving my "InterL" project? [message #363063] |
Sat, 10 February 2018 02:39  |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #363161 is a reply to message #363063] |
Sat, 10 February 2018 23:48  |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
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).
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #363165 is a reply to message #363161] |
Sun, 11 February 2018 00:21 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #363174 is a reply to message #363165] |
Sun, 11 February 2018 04:33 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 10 Feb 2018, qkumba wrote:
> 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.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #363208 is a reply to message #363174] |
Sun, 11 February 2018 13:24 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> (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.
> 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.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #363209 is a reply to message #363208] |
Sun, 11 February 2018 13:53 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 11 Feb 2018, qkumba wrote:
>> (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.
>
>> 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.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #363227 is a reply to message #363209] |
Sun, 11 February 2018 18:39 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> There's 4 "fgetc"s, followed by the 2 that become max1.
Excuse me. I missed that first one.
> 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.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #363234 is a reply to message #363227] |
Sun, 11 February 2018 20:37 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 11 Feb 2018, qkumba wrote:
>> 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".)
>
>> 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.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #363374 is a reply to message #363063] |
Tue, 13 February 2018 13:09 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, February 10, 2018 at 1:39:06 AM UTC-6, Steve Nickolas wrote:
> 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.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #363455 is a reply to message #363374] |
Wed, 14 February 2018 13:34 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
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!
|
|
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364278 is a reply to message #363456] |
Sun, 25 February 2018 02:36 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Wednesday, February 14, 2018 at 12:37:42 PM UTC-6, qkumba wrote:
> The ProDOS version didn't need this change because it never prompts, thus the count remains always valid.
Has the Sherlock Interpreter already been converted to Prodos?
And have there been any z5 games converted to a file yet to be used with the Prodos version?
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364286 is a reply to message #364278] |
Sun, 25 February 2018 06:42 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sat, 24 Feb 2018, I am Rob wrote:
> On Wednesday, February 14, 2018 at 12:37:42 PM UTC-6, qkumba wrote:
>> The ProDOS version didn't need this change because it never prompts, thus the count remains always valid.
>
>
> Has the Sherlock Interpreter already been converted to Prodos?
From what I understand, it has (by qkumba), but it hasn't been released
yet (except to 4am).
> And have there been any z5 games converted to a file yet to be used with
> the Prodos version?
See above - there's some screenshots on 4am's Twitter.
-uso.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364329 is a reply to message #364286] |
Sun, 25 February 2018 15:05 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, February 25, 2018 at 5:42:49 AM UTC-6, Steve Nickolas wrote:
> On Sat, 24 Feb 2018, I am Rob wrote:
>
>> On Wednesday, February 14, 2018 at 12:37:42 PM UTC-6, qkumba wrote:
>>> The ProDOS version didn't need this change because it never prompts, thus the count remains always valid.
>>
>>
>> Has the Sherlock Interpreter already been converted to Prodos?
>
> From what I understand, it has (by qkumba), but it hasn't been released
> yet (except to 4am).
>
>> And have there been any z5 games converted to a file yet to be used with
>> the Prodos version?
>
> See above - there's some screenshots on 4am's Twitter.
>
> -uso.
I was hoping for something a little more simplified like, the interpreter having a loader running under Prodos that can then load any z5 game in and start running it.
I will keep plugging away at it. I am just about there.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364332 is a reply to message #364329] |
Sun, 25 February 2018 16:13 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 25 Feb 2018, I am Rob wrote:
> On Sunday, February 25, 2018 at 5:42:49 AM UTC-6, Steve Nickolas wrote:
>> On Sat, 24 Feb 2018, I am Rob wrote:
>>
>>> On Wednesday, February 14, 2018 at 12:37:42 PM UTC-6, qkumba wrote:
>>>> The ProDOS version didn't need this change because it never prompts, thus the count remains always valid.
>>>
>>>
>>> Has the Sherlock Interpreter already been converted to Prodos?
>>
>> From what I understand, it has (by qkumba), but it hasn't been released
>> yet (except to 4am).
>>
>>> And have there been any z5 games converted to a file yet to be used with
>>> the Prodos version?
>>
>> See above - there's some screenshots on 4am's Twitter.
>>
>> -uso.
>
>
> I was hoping for something a little more simplified like, the interpreter having a loader running under Prodos that can then load any z5 game in and start running it.
>
> I will keep plugging away at it. I am just about there.
>
>
I understand it uses ProDOS startup protocol, so such a loader could be
made (the videos I've seen show Bitsy Bye being used as the menu).
-uso.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364339 is a reply to message #364332] |
Sun, 25 February 2018 17:21 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, February 25, 2018 at 3:13:20 PM UTC-6, Steve Nickolas wrote:
> On Sun, 25 Feb 2018, I am Rob wrote:
>
>> On Sunday, February 25, 2018 at 5:42:49 AM UTC-6, Steve Nickolas wrote:
>>> On Sat, 24 Feb 2018, I am Rob wrote:
>>>
>>>> On Wednesday, February 14, 2018 at 12:37:42 PM UTC-6, qkumba wrote:
>>>> > The ProDOS version didn't need this change because it never prompts, thus the count remains always valid.
>>>>
>>>>
>>>> Has the Sherlock Interpreter already been converted to Prodos?
>>>
>>> From what I understand, it has (by qkumba), but it hasn't been released
>>> yet (except to 4am).
>>>
>>>> And have there been any z5 games converted to a file yet to be used with
>>>> the Prodos version?
>>>
>>> See above - there's some screenshots on 4am's Twitter.
>>>
>>> -uso.
>>
>>
>> I was hoping for something a little more simplified like, the interpreter having a loader running under Prodos that can then load any z5 game in and start running it.
>>
>> I will keep plugging away at it. I am just about there.
>>
>>
>
> I understand it uses ProDOS startup protocol, so such a loader could be
> made (the videos I've seen show Bitsy Bye being used as the menu).
>
> -uso.
I guess I am making assumptions here. The interpreter that came on the Dos3.3 disk resides in the language card where Prodos resides.
On 4AM's twitter he mentioned Qkumba's support program for loading from Prodos hard drives. I am assuming then that the interpreter is still loaded into the language card over top of Prodos.
If this is so, I have a better way keeping Prodos alive.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364345 is a reply to message #364339] |
Sun, 25 February 2018 19:43 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
What we have created is a file-based interpreter that can be launched via Basic.system or BitsyBye, etc. It can run arbitrary z3/z4/z5 files (e.g. straight from ifarchive.org) directly from a ProDOS-based hard disk. It uses ProDOS only as far as loading the interpreter file (in the case of Z4 and Z5 because the games use 127.25kb for themselves, leaving me with only 0.75kb for both read and write support). The Z3 interpreter retains ProDOS in memory, and can even exit back to ProDOS.
The aim is to complete the project in time for KFest 2018.
Rob, what is your better way of keeping ProDOS alive? Moving it to aux isn't an option because it will be overwritten by game data. You'd need more than 128kb of RAM to keep it resident in memory.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364355 is a reply to message #364345] |
Sun, 25 February 2018 22:56 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, February 25, 2018 at 6:44:02 PM UTC-6, qkumba wrote:
> What we have created is a file-based interpreter that can be launched via Basic.system or BitsyBye, etc. It can run arbitrary z3/z4/z5 files (e.g. straight from ifarchive.org) directly from a ProDOS-based hard disk. It uses ProDOS only as far as loading the interpreter file (in the case of Z4 and Z5 because the games use 127.25kb for themselves, leaving me with only 0.75kb for both read and write support). The Z3 interpreter retains ProDOS in memory, and can even exit back to ProDOS.
>
> The aim is to complete the project in time for KFest 2018.
>
> Rob, what is your better way of keeping ProDOS alive? Moving it to aux isn't an option because it will be overwritten by game data. You'd need more than 128kb of RAM to keep it resident in memory.
That is exactly what I had in mind. The AuxLC is being used basically just as a ramdisk for data that gets moved to the lower Main or Aux. There is only one call to that move routine that moves data in and out of the language card.
It probably was a better solution due to the slowness of a floppy drive. But with the use of a hard drive, it is no longer necessary to load every inch of Ram with data.
The data that is stored in AuxLC can be stored on disk until needed, and when it is loaded, there won't be a huge wait during load. 4 kb is the same size as a dbl hi-res graphics file, so maybe 1-1/2 to 2 seconds to load.
Basically then, Prodos will still be in MainLC, the interpreter in AuxLC, and data in lower mem.
I am not seeing the huge loss of memory that you are encountering. The pages of memory that are required for the conversion of disk nybbles to full bytes are no longer needed, saving 3 pages. The floppy disk routines could be all removed as they are already a part of Prodos. The calls for loading and saving the position points as well as the data, could easily be done in a smaller memory area than required for the floppy driver.
There has to be a trigger byte that tells when to load chunks of new data in, as even 127.5 kb of data cannot fit into memory all at once along with the interpreter and other reserved areas.
I found the 5 tables that decipher the data for the interpreter, and I am confident that the data can also be broken down to so called "levels". I am quite surprised how small the interpreter really is, and I see even a lot more space savings once I start re-arranging the source code.
I believe the interpreter can quite easily be reduced to work on a 64 kb machine with an 80-col card (and no need for a 128 kb card). It would still need to have Basic.system removed from memory, and my estimates for memory use would look something like this.
$800.37FF - interpreter and Load/Save routines, game flags
$3800.B7FF - $8000 bytes for data is more than enough to load each level in chunks. 4x 32kb chunks is a 128 kb game and even larger games can be played.
spare room $B800.BAFF
$BB00.BEFF - Prodos disk buffer
$BF00.BFFF - Prodos global page
I would like to see this fully working as well, with the ability to load z5 games. If I can be of some assistance, don't hesitate to ask.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364356 is a reply to message #364355] |
Sun, 25 February 2018 22:59 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
> The data that is stored in AuxLC can be stored on disk until needed, and when it is loaded, there won't be a huge wait during load. 4 kb is the same size as a dbl hi-res graphics file, so maybe 1-1/2 to 2 seconds to load.
I was thinking of 4x 16-page chunks but meant 16 kb in total for the language card
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364359 is a reply to message #364355] |
Mon, 26 February 2018 00:31 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 25 Feb 2018, I am Rob wrote:
> I believe the interpreter can quite easily be reduced to work on a 64 kb
> machine with an 80-col card (and no need for a 128 kb card). It would
> still need to have Basic.system removed from memory, and my estimates
> for memory use would look something like this.
There is a Z5 interpreter for the Commodore 64, so it might be possible.
IIRC, the program that converts Z5 games into disk sets for the 64 does
have to make tweaks to the game code so that the games are able to fit in
64K.
-uso.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364410 is a reply to message #364355] |
Mon, 26 February 2018 13:58 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> That is exactly what I had in mind. The AuxLC is being used basically just as a ramdisk for data that gets moved to the lower Main or Aux. There is only one call to that move routine that moves data in and out of the language card.
I believe that the initial load is of the static data for which there are no direct pointers, unlike the dynamic data that it reads it from time to time.
It might be difficult to determine when to load exactly what.
> Basically then, Prodos will still be in MainLC, the interpreter in AuxLC, and data in lower mem.
The support routines in $800-09FF would then need to be updated in order to swap between AuxLC and monitor ROM in order to call the monitor routines. I think that there isn't enough space in them right now to do that without rewriting something.
> I am not seeing the huge loss of memory that you are encountering.
The original loader on the floppy reads 127.25kb of data into memory (i.e. interpreter and static data), and then transfers control to the interpreter.. The original floppy RWTS was $500 or so bytes. My replacement code uses $400 bytes for buffers, so I had around $100 bytes for the read routine which includes parsing the ProDOS file system. I crammed the write routine into a spare $F0 bytes elsewhere, which supports converting sparse files into allocated blocks.
That allowed me to use the original interpreter more or less unchanged.
> There has to be a trigger byte that tells when to load chunks of new data in, as even 127.5 kb of data cannot fit into memory all at once along with the interpreter and other reserved areas.
There is, but only for the dynamic data. The game is separated into static data and dynamic data. The static data are left in memory forever, as the name implies. The dynamic data are read from disk on-demand and then interpreted.
The trigger to read from disk is whenever the end of a page is reached and the following page is not present in memory. There's one routine that deals with that. The appropriate sector number is known to the game only for the dynamic data.
> I believe the interpreter can quite easily be reduced to work on a 64 kb machine with an 80-col card (and no need for a 128 kb card). It would still need to have Basic.system removed from memory, and my estimates for memory use would look something like this.
>
> $800.37FF - interpreter and Load/Save routines, game flags
> $3800.B7FF - $8000 bytes for data is more than enough to load each level in chunks. 4x 32kb chunks is a 128 kb game and even larger games can be played.
The game has non-linear accesses, though. It's not clear to me that reading such large chunks would be of benefit. The game loads sector-by-sector on-demand.
> spare room $B800.BAFF
>
> $BB00.BEFF - Prodos disk buffer
> $BF00.BFFF - Prodos global page
>
> I would like to see this fully working as well, with the ability to load z5 games. If I can be of some assistance, don't hesitate to ask.
Well yes, if you think that it's really possible, I would like very much to see that.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364433 is a reply to message #364410] |
Mon, 26 February 2018 18:02 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Monday, February 26, 2018 at 12:58:44 PM UTC-6, qkumba wrote:
>> That is exactly what I had in mind. The AuxLC is being used basically just as a ramdisk for data that gets moved to the lower Main or Aux. There is only one call to that move routine that moves data in and out of the language card.
>
> I believe that the initial load is of the static data for which there are no direct pointers, unlike the dynamic data that it reads it from time to time.
> It might be difficult to determine when to load exactly what.
This is why I don't think the data in the LC memory is dynamic. It is just one or more big chunks. Another thing is where the data gets moved to. If the destination part of the memory is replaced by the data from the LC memory, then that same memory will have to be reloaded, either from disk for from some other part of memory. This constant loading and reloading of that destination area can be done from disk as well as from LC memory or any other part of memory. This is why I don't believe it is the end of memory that signifies a move, but rather a flag or signal byte from the interpreter code.
>> Basically then, Prodos will still be in MainLC, the interpreter in AuxLC, and data in lower mem.
>
> The support routines in $800-09FF would then need to be updated in order to swap between AuxLC and monitor ROM in order to call the monitor routines.. I think that there isn't enough space in them right now to do that without rewriting something.
The support routines would no longer be needed since the interpreter would not be running from the LC memory. This will free up another 2 pages of memory.
>> I am not seeing the huge loss of memory that you are encountering.
>
> The original loader on the floppy reads 127.25kb of data into memory (i.e.. interpreter and static data), and then transfers control to the interpreter. The original floppy RWTS was $500 or so bytes. My replacement code uses $400 bytes for buffers, so I had around $100 bytes for the read routine which includes parsing the ProDOS file system. I crammed the write routine into a spare $F0 bytes elsewhere, which supports converting sparse files into allocated blocks.
> That allowed me to use the original interpreter more or less unchanged.
Right. But if Prodos stays in MainLC, then smaller MLI code could be programmed for the Reads and Writes. Your replacement code is doing what Prodos itself would be doing.
>> There has to be a trigger byte that tells when to load chunks of new data in, as even 127.5 kb of data cannot fit into memory all at once along with the interpreter and other reserved areas.
>
> There is, but only for the dynamic data. The game is separated into static data and dynamic data. The static data are left in memory forever, as the name implies. The dynamic data are read from disk on-demand and then interpreted.
> The trigger to read from disk is whenever the end of a page is reached and the following page is not present in memory. There's one routine that deals with that. The appropriate sector number is known to the game only for the dynamic data.
I have thought of this too. The track and sectors for the dynamic data will have to be identified and mapped. But this is no different than using Prodos blocks. You will still have to map a block to a track/sector pair. Otherwise this still only allows this game with your Prodos replacement code to be run from a floppy disk. To run the game from a hard drive, the data will have to be stored contiguously in a file so it can be loaded a block at a time and be contiguous in memory. Another otherwise, even Prodos will have to keep track of the dynamic loads and converted to the correct track/sector pair.
>> I believe the interpreter can quite easily be reduced to work on a 64 kb machine with an 80-col card (and no need for a 128 kb card). It would still need to have Basic.system removed from memory, and my estimates for memory use would look something like this.
>>
>> $800.37FF - interpreter and Load/Save routines, game flags
>> $3800.B7FF - $8000 bytes for data is more than enough to load each level in chunks. 4x 32kb chunks is a 128 kb game and even larger games can be played.
>
> The game has non-linear accesses, though. It's not clear to me that reading such large chunks would be of benefit. The game loads sector-by-sector on-demand.
that is ok. It is not about where the data is loaded from, but where the data is stored to. All you need then is to store the data in memory to a file which will have all its data stored contiguously.
>> spare room $B800.BAFF
>>
>> $BB00.BEFF - Prodos disk buffer
>> $BF00.BFFF - Prodos global page
>>
>> I would like to see this fully working as well, with the ability to load z5 games. If I can be of some assistance, don't hesitate to ask.
>
> Well yes, if you think that it's really possible, I would like very much to see that.
Yes. The more I wrap my head around it, the more I believe it is quite possible.
The biggest challenge is to map out the order of the track/sectors of a floppy and make them contiguous in a file on the hard drive.
I used DSK2FILE version 5.8 to read the first disk and it has the ability to save as a file in Prodos order. This should put the data itself in contiguous order in a Prodos file. I hope to confirm this and am studying the file on my hard drive to see if this is the case.
I don't know how many times I have used the word "contiguous" here, but I believe it is the key to making this work.
Is there a disk image of the the second disk for Sherlock that is in 143 kb format and not the 286 kb .nib format, or is there a program to convert .nib's to .dsk?
Removing the floppy disk code and converting to Prodos should also remove the check for a volume number. And it won't matter if the floppy is 18 sector or 16 sector once the data is on the hard drive.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364796 is a reply to message #364286] |
Sun, 04 March 2018 04:54 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, February 25, 2018 at 5:42:49 AM UTC-6, Steve Nickolas wrote:
> On Sat, 24 Feb 2018, I am Rob wrote:
>
>> On Wednesday, February 14, 2018 at 12:37:42 PM UTC-6, qkumba wrote:
>>> The ProDOS version didn't need this change because it never prompts, thus the count remains always valid.
>>
>>
>> Has the Sherlock Interpreter already been converted to Prodos?
>
> From what I understand, it has (by qkumba), but it hasn't been released
> yet (except to 4am).
>
>> And have there been any z5 games converted to a file yet to be used with
>> the Prodos version?
>
> See above - there's some screenshots on 4am's Twitter.
>
> -uso.
There are way too many interpreters.
Z3 - has up to an M interpreter
Z5 - up to version H
Z6 - unknown version, but handles dbl hi-res graphics and is Prodos compliant.
Although someone stated that a Z5-vH interpreter will play most if not all Z3 files, this Z6 interpreter look like the holy grail.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364799 is a reply to message #364796] |
Sun, 04 March 2018 06:24 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 4 Mar 2018, I am Rob wrote:
> There are way too many interpreters.
>
> Z3 - has up to an M interpreter
> Z5 - up to version H
> Z6 - unknown version, but handles dbl hi-res graphics and is Prodos compliant.
Z4 goes up to H too, and there's one or two versions of the Z3 interpreter
that predate A.
> Although someone stated that a Z5-vH interpreter will play most if not
> all Z3 files, this Z6 interpreter look like the holy grail.
I don't think so? Far as I know, none of these are backward-compatible.
However, a few (at least Zork 1, H2G2, Leather Goddesses) of the Z3 games
were *upgraded* to Z5.
-uso.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364858 is a reply to message #364799] |
Mon, 05 March 2018 13:28 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
The interpreters are tied to the formats that they support. i.e. Z3 only does Z3, Z4 does Z4, Z5 does Z5, ...
However, within Z5 at least, there is apparently no universal interpreter.
For Z3 and Z4, we found one of each that handles all games in that format. For Z5, we found games that wouldn't run properly in one version but did in another, and vice versa, and none that play certain games properly at all.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364862 is a reply to message #364796] |
Mon, 05 March 2018 14:36 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Ouch! Would that also mean then that there are that many encoders (parsers?) to create the z-code? Or can one parser create the code that many different ways?
Looks like under Asimov IIGS adventures someone went to a lot of trouble to make a single compatible interpreter for all the Lost Treasures of Infocom.
Of the Z6 interpreters I see there are versions 9, 14, 16 and 17. That should mean there are at least 17 games for the Z6-interpreter, so far only 4 have been uploaded.
Another note is that the Z6 interpreters say they are Apple IIGS interpreters, but they have no IIGS or even 65c02 instructions in them and it uses Dbl Hi-res graphics. I hope this means it can be used and run on a 128kb IIe or IIc/IIc+.
So much to play with here. Curse you Steve for bringing this to my attention.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364878 is a reply to message #364862] |
Mon, 05 March 2018 20:22 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Mon, 5 Mar 2018, I am Rob wrote:
> Ouch! Would that also mean then that there are that many encoders
> (parsers?) to create the z-code? Or can one parser create the code that
> many different ways?
They probably had separate compilers for each version.
More recent compilers like Inform can generate multiple versions of
Z-code.
> Looks like under Asimov IIGS adventures someone went to a lot of trouble
> to make a single compatible interpreter for all the Lost Treasures of
> Infocom.
>
>
> Of the Z6 interpreters I see there are versions 9, 14, 16 and 17. That
> should mean there are at least 17 games for the Z6-interpreter, so far
> only 4 have been uploaded.
I think there's only 4, but there may have been multiple versions of each.
>
> Another note is that the Z6 interpreters say they are Apple IIGS
> interpreters, but they have no IIGS or even 65c02 instructions in them
> and it uses Dbl Hi-res graphics. I hope this means it can be used and
> run on a 128kb IIe or IIc/IIc+.
>
> So much to play with here. Curse you Steve for bringing this to my
> attention.
>
XD
-uso.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364887 is a reply to message #364878] |
Tue, 06 March 2018 06:48 |
|
|
Originally posted by: Delfs
So it sounds like the Eamon adventures, every one was customized for each story. That sort of makes sense.
If the one IIgs interpreter handles more than one then it most likely is the one to study and compare back to the original interpreters for those stories to find the common code.
Maybe you can find the core code and then the extra routines that are unique and just add those in - like MAME adds in support for new games. :)
Or not.
|
|
|
|
| Re: Infocom Z5 games: Improving my "InterL" project? [message #364888 is a reply to message #364887] |
Tue, 06 March 2018 07:04 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Tue, 6 Mar 2018, Delfs wrote:
> So it sounds like the Eamon adventures, every one was customized for
> each story. That sort of makes sense.
Especially true of version 6; not so much so of 3 (and the same
interpreter is used for multiple games, and multiple interpreters for the
same game, with the version 3 stuff).
> If the one IIgs interpreter handles more than one then it most likely is
> the one to study and compare back to the original interpreters for those
> stories to find the common code.
Well, there's the rewritten ones (like jzip and frotz) too.
-uso.
|
|
|
|
Members
Search
Help
Register
Login
Home
