Jump to content
InsaneMultitasker

TI-99 Infocom Interpreter Dev

Recommended Posts

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 :) 

Share this post


Link to post
Share on other sites
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?

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

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. 

 

Share this post


Link to post
Share on other sites
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. :)

 

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites

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

 

 

Edited by wierd_w
  • Like 1

Share this post


Link to post
Share on other sites

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. ;) 

 

image.thumb.png.0c03ab8983e4cd826ceaaa4a15a51ca4.png

 

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

  • Like 10

Share this post


Link to post
Share on other sites

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.  :(  

 

image.thumb.png.8ace911dc0c8439d78c6bb3b68e634f7.png

  • Like 5

Share this post


Link to post
Share on other sites

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

 

  • Like 5

Share this post


Link to post
Share on other sites

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..?

 

image.thumb.png.0d83eb985ab3c0c396a594f228facbac.png

(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)

 

  • Like 3

Share this post


Link to post
Share on other sites

@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. 

 

 

  • Thanks 1

Share this post


Link to post
Share on other sites
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.

  • Like 5

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...