TI-99 Infocom Interpreter Dev

[+InsaneMultitasker]

1 hour ago, Asmusr said:

Yep.

Cool.  I'll look again.  Maybe it is my misunderstanding of how the FG99 is implemented; I was looking for the FG99 cartridge in the Software list and options without any success. Is it just a matter of loading the cartridge files from disk, with the proper advanced mode option set in the 6-byte header, and js99er takes it from there?

 

9 hours ago, PeteE said:

@Asmusr will correct me if I'm wrong, but I do think he implemented FG99 RAM mode in JS99er.

Thanks  

[Asmusr]

4 minutes ago, InsaneMultitasker said:

Is it just a matter of loading the cartridge files from disk, with the proper advanced mode option set in the 6-byte header, and js99er takes it from there?

You need to load a cartridge image with an ASCII R (>52) at offset 3 to enable the RAM mode. See https://endlos99.github.io/finalgrom99/ under Advanced modes.

If your TI software is on disk I guess you can create an empty cartridge with just the header, but maybe you're talking about the host system disk?

[Asmusr]

Note that JS99er doesn't emulate the X or G modes.

 

To actually emulate the FinalGROM there would need to be a way to insert an (emulated) SD card into the cartridge. One reason for adding a full emulation would be to emulate the  reloading feature, but AFAIK nobody has developed any software using that. 

 

[+InsaneMultitasker]

52 minutes ago, Asmusr said:

You need to load a cartridge image with an ASCII R (>52) at offset 3 to enable the RAM mode. See https://endlos99.github.io/finalgrom99/ under Advanced modes.

If your TI software is on disk I guess you can create an empty cartridge with just the header, but maybe you're talking about the host system disk?

Yes, it sounds like the empty cartridge and header is the way to start.  Eventually, I plan to use 128K of ROM for the game information and at least one bank of RAM for buffer/code space.  So the catridge would by of type "R" of the appropriate size.  I suppose I could incorporate the Interpreter in the ROM and copy it into the 32K RAM space with a simple ROM header/code approach.  I don't typically deal with cartridges but I think I understand what is needed to play with emulation now.  Maybe.

 

[Asmusr]

6 minutes ago, InsaneMultitasker said:

I suppose I could incorporate the Interpreter in the ROM and copy it into the 32K RAM space with a simple ROM header/code approach.

Sure, you can use one of the tools to create a cartridge image from TIFLES and then patch the header.

[wierd_w]

Or just pull the really huge one HomeAutomation already made...

 

 

Edited January 15, 2022 by wierd_w

[+InsaneMultitasker]

Getting closer.  I've been trying to incorporate too many new things into the program, so I took a step back today to re-evaluate what I want to complete for the initial release. 

 

This evening, I came across a few more native z3 games that I was able to convert to DF128 using TI99Dir's binary option. The first one was Craverly Heights; the interpreter successfully loaded it (into SAMS) on the first try.  The game tracks time instead of moves/score, and I was pleased to see the new status line code didn't throw a tantrum.  

 

 

GitHub - johanberntsson/Craverly-Heights_PunyInform: A PunyInform port of Ryan Veeder's game Craverly Heights

[+InsaneMultitasker]

I added 80 column VDP detection that seems to be working in Classic99 (with F18A gpu enabled) and on real hardware (Geneve v9938).   The latter might be the first real iron test for this interpreter.  One of the few remaining challenges for this release is how to deal with the path.file for the game and the save/load option.  When I uploaded the below photo, I noticed a problem that doesn't occur in emulation.  My hardware must want in on the debug action.    

 

[+InsaneMultitasker]

Running the game in MAME yielded the same results as on the real hardware.  On a whim, I reset Classic99 with the "debug reset - scramble ram" option.  The game display failed at the same point, with different characters being printed.  I looked in the debugger at the displayed gibberish in vram and found that it matched bytes immediately after the line composition buffer.  When run from Classic99, the end of the composition buffer contains >00, which for the interpreter is an 'end of line' marker.  On the real hardware, the bytes are either >A5 5A or some other non-zero value.  There isn't an initialization routine for the buffer, so I'll have to compare interpreters to look for the root cause.  Fortunately, the fix seems simple enough: clear the bytes after the composition buffer and review the line composition code for a boundary test error.  I now feel better knowing the issue is in the display routine, not the interpreter proper. 

 

Edit:  I was wrong, there was an end-of-buffer initialization... I had changed the routine to directly load the values into R8 (to eliminate hard-coded values) then I changed it to move the values directly, bypassing the R8 setup.  I didn't recognize the CLR *R8 for its purpose!  This also means that some other memory location was being cleared too. [On the Geneve, it was address >0300, which is ROM on the TI but RAM on the Geneve]  -- Nasty little oversights! 

 

;;       mov  @composestart,r8   ;compose start, line to print
;;       MOV  R8,@AD
;;       mov @composeend,r8    ;compos end 
;;       MOV  R8,@HI

 

    mov    @composestart,@AD
    mov    @composeend,@HI

    CLR  *R8            ok

 

[+InsaneMultitasker]

I am now at the point where I am trying to maximize the available vram buffer space for the 9918, F18A, and 9938 configurations.  The interpreter uses a block of contiguous 512-byte buffers in VRAM to manage the game story, and the more buffers, the better. 

 

The extended character set and 80 column image table chew up more space than the previous interpreters, particularly for the F18A setup.  I could set FILES to 2 or possibly 1, if I disable the transcript option and close/re-open the game file when saving/loading the game state.  The interpreter has been working acceptably (so far) with 19 game buffers in the unoptimized F18A version.

 

The interpreter configures vram at startup, based on VDP detection and (maybe) user over-rides to force 40 columns and/or the standard characters set.  This is the layout I think will work to make best use of memory..?

 

(I purposely selected the value >37C0 to represent the disk buffer vdp boundary, to account for nanopebs and a few devices that consume additional VDP memory at startup)

 

[+FarmerPotato]

@InsaneMultitasker

Hey, this is some really important work, IMO. I look forward to seeing your documented sources! (And playing some Infocom games again.)

 

Especially like that you are doing the extended character set. 

 

 

[+InsaneMultitasker]

On 2/17/2022 at 5:45 PM, FarmerPotato said:

 I look forward to seeing your documented sources! (And playing some Infocom games again.)

Thank you, I intend to release a test version in the near future.

 

Tonight I set up the blocks of data for each of the five vdp configurations.  It's a bunch of EQUates to make future changes simpler, and DATA statements to hold the actual values.  Once determined/selected, the config is copied into general data statements used to control screen location, PABs, and anything else that might 'move' to maximize available memory.  So far there are nearly thirty 2-byte data elements per configuration, which really vexed me until I remembered that all of this extra config data is used once at run-time then the space is reclaimed.  One configurable interpreter is certainly more manageable than five.  Alas, if I cannot streamline the code enough, I'll have to generate a 2nd version for the larger games.   This is where I've been tempted to remove the $verify and/or transcript code.

[Elia Spallanzani fdt]

Maybe it can be useful: https://github.com/jcmf/glulx-strings

[+InsaneMultitasker]

I was playing with the Geneve's interpreter code this weekend, as I wanted to natively run a larger "supercart" game.  I resolved the issue and in the process of reviewing differences with the /4a interpreter, I found myself reading the commented /4a interpreter code posted to Github (thanks @mizapf !).   In the disk IO code, it seems that the author had planned to use a Dis/Fix 256 file which as most of us know, is one byte larger than the maximum record size.  The file PAB specifies a record length of >FF which is 255.  I wonder if there was a hex-to-decimal conversion mistake or a base-0 misunderstanding with respect to the PAB?

 

Ultimately, the game files were stored as DF255, with special encoding to store the last byte of each record, then later cobble the full 256-byte block back together in memory.  Had the author used Dis/Fix128 files and read two consecutive 128-byte records - or used level 2 IO to read/write 256 byte blocks - most if not all of the /4A file conversion mess would have been eliminated.  Ah well, such is life.  I thought this was interesting regardless  

 

PABT2   DATA >FF00       FIX 256 (READ ONLY)
PABT3   DATA 0               RECORD #

RCSIZE  DATA 256             LENGTH, 1 RECORD (READ ONLY)

* OPEN/FIX-INT-INPUT-REL,VDP BUF,(FIX)256/ ,REC #, /NAM LEN

PGDATA  DATA >000D,0,>FF00,0,>0009
        TEXT 'DSK1.GAME'
        EVEN

 

[+InsaneMultitasker]

Here is the in-process disassembled source to the Geneve Infocom interpreter.  I'm close to the point where I should be able to make changes to the program.

 

INF Geneve Interp listing 4-6.txt

[+InsaneMultitasker]

Tonight marks the Geneve interpreter's first successful load of an unmodified (native) z3 game file. 

The disassembly & rework have given me an idea or two for overcoming the /4a challenges.

@mizapf's MAME debug tips have been most helpful in helping me to find two 35+ year-old bugs. 

  

Edit: added screenshot of extended ZSCII using the character set created by @wierd_w.  

[+InsaneMultitasker]

The updated Geneve Infocom interpreter seems to be working properly with the fixes and updates, so I'm releasing v1.2 into the wild.  I've named it INF3 to distinguish between the older INF and its 2-gamefile format.

 

This program runs from the Geneve OS's command line.  The game file must be a single, "raw" z3 file in DF128 format.  For example, if you wish to play one of the newer PunyInform games, download the raw z3 file then convert it from a "PC" file to a TIFILES format file. TI99Dir does this quickly and easily.

 

Notable items:

• Game file is the single, raw z3 file.  Removed game1/game2 support. (Edit: more accurately, I disabled the 2-file support in case there is a need for it later).
• Disassembled the interpreter program.  Validated the z-machine instructions: they match the V1.3 /4a interpreter.
• The game size limitations have been removed with the change in file format, i.e., larger "Supercart" games now load and run.
• During startup and restore operations, the entire game file is loaded into memory from the device. 
• The interpreter no longer locks up at the exit dialogue when it encounters a "bad" file or bad internal opcode.
• The video mode and screen window are set -after- the game is loaded. 
• The default character set is the Geneve OS pattern table.  However... 
• The new character set with extended ZSCII characters is available. Press F5 at an input prompt to toggle between default and new sets.
• The input buffer size is now limited to 75 characters. This fixes problems with games that allow excessive input buffers.
• The input buffer length was incorrectly being set to one more than the maximum memory space.
• The input routine now detects NULL characters in the input buffer and replaces them with the SPACE character.  NULL buffer initialization was most noticeable in some of the newer releases. 
• The TAB key has been fixed. Pressing it during data entry will reveal the last command/file name.  Right-arrow will also reveal the same, one character at a time. 

Possible, future updates:

• Visible status bar/line. Some people like it, others don't.  The status line uses an MDOS window command so for now, I left it alone.
• Disk catalog option during save/restore.  Who here doesn't dislike needing to exit the game when you forget the restore file's name?
• Some games do not calculate the $verify bytes; others were modified without recalculating the verification, e.g. a few of The Master's releases. Allow the user to disable the game integrity check

I've learned a bit more about the /4a and Geneve interpreters and resolved a few old, outstanding issues.  I hope to spend some time with the /4a code later this year.

INF3

[+arcadeshopper]

On 1/14/2022 at 5:19 PM, Asmusr said:

Note that JS99er doesn't emulate the X or G modes.

 

To actually emulate the FinalGROM there would need to be a way to insert an (emulated) SD card into the cartridge. One reason for adding a full emulation would be to emulate the  reloading feature, but AFAIK nobody has developed any software using that. 

 

Force command uses it