XB Infocom Conversion Tool

[+Torrax]

Fixed padding and alignment issues with GAME1 (ZDAT1).

This fixes splitting of smaller Z3 DAT files.

 

 

100 ! INFOCOM Z3 CONVERTOR
105 ! ZT=88 Normal, ZT=96 SuperCart
110 I=0 :: A$,B$,C$="" :: ZT=88
120 OPEN #1:"DSK1.Z3",INPUT ,FIXED 128
130 OPEN #2:"DSK1.ZDAT1",OUTPUT,FIXED 255
140 OPEN #3:"DSK1.ZDAT2",OUTPUT,FIXED 255
145 PRINT :"Creating ... GAME1"
150 FOR I=1 TO ZT
160 LINPUT #1:A$ :: LINPUT #1:B$
170 C$=A$&SEG$(B$,1,127):: E$=E$&SEG$(B$,128,1)
180 PRINT #2:C$
190 NEXT I
195 PRINT "Creating ... GAME2"
200 A$,B$=""
210 LINPUT #1:A$ :: C$=A$ :: IF EOF(1)THEN 230
220 LINPUT #1:B$
230 IF LEN(B$)<128 THEN C$=C$&B$ ELSE C$=C$&SEG$(B$,1,127)
240 IF LEN(E$)<=254 THEN E$=E$&SEG$(B$,128,1)ELSE PRINT #2:E$ :: E$=SEG$(B$,128,1)
250 PRINT #3:C$
260 IF EOF(1)THEN 280
270 GOTO 200
280 PRINT #2:E$&RPT$(CHR$(0),255-LEN(E$))
282 IF (LEN(E$)*256/512)<82 THEN PRINT #2:RPT$(CHR$(0),255)
285 PRINT "Finished!!!"
290 CLOSE #3 :: CLOSE #2 :: CLOSE #1
999 END

 

[+InsaneMultitasker]

1 hour ago, Torrax said:

Fixed padding and alignment issues with GAME1 (ZDAT1).

This fixes splitting of smaller Z3 DAT files.

The program is quite helpful and illuminating.  The interpreter file IO code and routines makes sense to me.

 

I wonder... did whoever wrote the original TI version of the Infocom interpreter not fully understand the TI file system?  My approach would have been to use two DF128 files, so that each original 512 byte record could have been split into four 128 byte records.  No need to store the final byte of each DF255 record within an array in memory, simplifying the conversion, load, and recall. 

 

(Current storage options would allow us to easily use the original Z3 file directly in a DF128 format.  Back then, 90k was the common maximum capacity for the TI disk drive)

 

Is the size of the GAME1 file representative of the amount of available memory on the host system after the interpreter is loaded?   Thus for a Supercart interpreter, all of high memory (A000-FFFF) is free allowing for a 96 record GAME1 file and without supercart?

 

Thanks for sharing your insight. 

[+Torrax]

Don't forget that TI didn't share much of their internal documentation back then.  Which crippled software development from outside sources.

They only released more info near the end of the TI-99/4A's life cycle.  I'm surprised that Infocom was able to develop an interpreter for the TI with so little/sparse documentation.  Limited info on the TI's file system could also explain why the original Z3-DAT file is split into GAME1 and GAME2.

 

The 8K SuperCart interpreter increased the dynamic memory available for the larger Z3 games.  The regular interpreter is pushing the RAM limits for some of the larger games.  As I have had an occasional <internal error> on extended plays of the later games (40col non-SC).  So consider the SuperCart a pre-req. for 96 record GAME1 files.

 

I think we need a full decompilation of the interpreters or Barry Boone's source code to understand how he handled the memory management.

His programming style was heavily optimized and used self modifying code at times.  You can easily get lost trying to follow his code -- very headache inducing.  A brilliant and talented TI programmer back then!!  I'm surprised that he didn't rewrite an new Interpreter to handle the native Z3-DAT format as a I/F128 file as most TI users did have 180K double sided drives.

 

You can also check out Informs Z-Machine Standards Documentation.

 

Edited August 29, 2020 by Torrax

[Shift838]

On 8/28/2020 at 8:07 PM, Torrax said:

Fixed padding and alignment issues with GAME1 (ZDAT1).

This fixes splitting of smaller Z3 DAT files.

 

 

 

Tried to use this updated code on a couple of smaller .z3 files and I get:

 

I/O Error 25 in 210

 

Attached is a z3 file called DEJAVU i tried it with.

 

 

DEJAVU

[hlabrand]

23 hours ago, Torrax said:

The 8K SuperCart interpreter increased the dynamic memory available for the larger Z3 games.  The regular interpreter is pushing the RAM limits for some of the larger games.  As I have had an occasional <internal error> on extended plays of the later games (40col non-SC).  So consider the SuperCart a pre-req. for 96 record GAME1 files.

 

I'm following this discussion with interest, obviously :D One question: I seem to recall that Ballyhoo, although it's a 128kb story file, didn't require SuperCart, when others of a similar size did. What is it due to precisely? (If I'm understanding correctly, the Z-Machine can use up to 64kb of RAM, and the TI-99/4A can't give it that much RAM, unless you use a SuperCart?)

Ideally, my game would avoid requiring a SuperCart, but I am aiming for a final file size close to 128kb... So, do I need to be looking into what makes the Z-Machine RAM get bigger, and try to avoid doing it?

[+InsaneMultitasker]

With the supercart version of the interpreter, the program code that is normally loaded into RAM at addresses >F300-FFFF (approximate) is instead loaded into the supercart space at >6000-6D00.  The remaining available supercart memory is not used by the interpreter.  The one benefit gleaned from moving the code into the supercart is that the maximum contiguous memory space for the z-file increases from 22k to 24k.  I believe this is what Torrax is referring to as the available dynamic memory. 

 

Upon startup, the interpreter checks the z3 file bytes 4-5 for the "begin paged memory" address.  The supercart interpreter allows for 24k, the non-supercart allows for approximately 22k.  If I correctly looked at my copy of Ballyhoo's GAME1 file, its paged memory address is 0x5780, just shy of the 22k limit.

 

All versions of the TI interpreter manage a cache within video memory. The 40 column interpreter (standard and supercart) allocates 24 slots, 9938 allocates 23 slots, and the F18A allocates 19 slots.  Each slot is 512 bytes for information loaded from disk during the game play.  Maybe this limited space contributes to the periodic internal error.

 

 

[+Torrax]

Some of the very small Z3 files will fit entirely into the GAME1 file and error out in trying to read non-existant data needed for the GAME2 file.

You can say the TI interpreters have a minimum Z3-DAT requirement due to the split DAT format.

 

GAME1 -- 88*256-22K, 96*256-24K

GAME2 -- 1 to 2K extra needed

 

So about 24K and 26K (SC) orig Z3-DAT sizes seem to be the bare minimum for our interpreters.

 

[+Torrax]

I think the SuperCart version may also use some of 8K RAM to deal with the parsing of the larger dictionary sizes.

[+Torrax]

New thread created "Infocom Small Systems Development".  Please post Inform programming material there.

 

Going into read-only mode for sometime as my Grandmother of 99 1/2 yrs. passed away this morning.  Need to deal with this and the lack of a funeral due to covid-19. Will be back...

[HOME AUTOMATION]

She's an angel now!

 

...Feel better.

 

 

      -Alex

[+InsaneMultitasker]

confirmed that the SuperCart/8k space at 0x6000-0x7fff is only used to hold the program code and routines that are loaded in high memory 0xf300-ffff with the standard interpreter.  I have also successfully assembled and relocated the supercart portion of the interpreter to run from 0x7000, hence my questions in the FG99 thread.  There is still some work to do to sync the source code to the Lost Treasure of Infocom release, with an end result of commented source code.

 

On 8/29/2020 at 12:35 AM, Torrax said:

I think we need a full decompilation of the interpreters or Barry Boone's source code to understand how he handled the memory management.

[Shift838]

On 9/1/2020 at 11:34 AM, InsaneMultitasker said:

confirmed that the SuperCart/8k space at 0x6000-0x7fff is only used to hold the program code and routines that are loaded in high memory 0xf300-ffff with the standard interpreter.  I have also successfully assembled and relocated the supercart portion of the interpreter to run from 0x7000, hence my questions in the FG99 thread.  There is still some work to do to sync the source code to the Lost Treasure of Infocom release, with an end result of commented source code.

 

 

Will this one also do the 9938 version?

[+InsaneMultitasker]

10 minutes ago, Shift838 said:

Will this one also do the 9938 version?

It works with 9938 and f18a. I intend to sync the 9938 changes and if possible, add a test for the F18A to tailor the buffering mechanism to either device.  I'll create a topic as I get closer to finishing the code review.  The only reason I'm working on this now is that the interpreter code is simple enough that I can pick up where I left off without any hassle, unlike some of my other projects that are too complex to deal with during this busy work period. This is one of my old 'bones' that I like to chew on.