TI99/4A Scott Adams games possible to convert to TRS-80 format?

[pdxiv]

Hi,

I heard rumors that the Scott Adams game Buckaroo Banzai in TRS-80 format was actually ported from the TI99/4A. Eventually I started to look at what other the various TI99/4A games out there made using the “Tex-Comp ADVENTURE EDITOR” (which is what Scott Adams seems to have used), and there actually seems to have been quite a few titles made. A quick googling turned up the following 19 exciting-sounding titles, in alphabetical order:

Adult Adventure, Colossal Cave - Masters Game, Colossal Cave v4.0, Computorama, Discovery At June Lake, Escape from Alcatraz, Escape from Cannibal Island, First days In Eden, Gerrys Place, Knight Ironheart, Matilda’s Dilemma, Moon Adventure, Mystery of Captain Kidd, Nessy, On The Loose, The Doors In Eden, The Great Advocado Adventure, Tomb of the Gray Elf, Travelling

So, given that Buckaroo Banzai was converted from the TI99/4A game files, would all other other games also be possible to convert?

I started looking at the structure of the game data files and some of the code of the Bunyon interpreter, and it certainly seems similar enough, although the actions seem to be structured in a more dynamic way (which may, or may not be a problem).

Before I dive in head first and try to hack together a converter script, does anybody have any prior experience with this? Is it even possible?

Thanks.

[jkj_yuio]

Another option would be to compile the interpreter for the TRS-80, it doesn’t look that complicated ( he says )

I ported ScottFree to the trs-80 here. I might be possible to do the same with Bunyon.

[pdxiv]

@jkj_yuio

Another option would be to compile the interpreter for the TRS-80, it doesn’t look that complicated ( he says )

That would be an interesting thing to do. The TI99/4A data files are slightly more efficient too.

Since the TRS-80 text data file format seems to be the most universally supported format for these games though, I thought that if the TI99/4A files could be converted to that format, they would be possible to expose to a wider audience.

I’m still in brain storming mode on this. Started reading the “Tex-Comp ADVENTURE EDITOR” manual just to get a grasp of how the “actions” work. I honestly wonder how people actually put up with this tool and managed to write games with it… And apparently it was nicer than whatever Scott Adams had himself at the time

@jkj_yuio

I ported ScottFree to the trs-80 here.

I honestly didn’t think that would have been be possible. Big kudos there

[Nathan]

I was sure there was already a script to do this on the archive, but now I can’t find it.

[Warrigal (Garry Francis)]

Bjorn Gustavsson’s Scott2Zip can convert both TRS-80 and TI-99/4a formats to an Inform file. This is a Perl script which clearly shows the differences in the two formats. Apart from Bunyon, this might be your best bet.

[Warrigal (Garry Francis)]

I’ve started a new thread here with a much more comprehensive list of these games.

[pdxiv]

Thanks for that suggestion. Scott2Zip seems to be very close to what I want to accomplish. Perhaps I’ll try to make it output in ScottKit format instead of ZIL, to give some extra flexibility with how actions are handled. (TI99/4A action data sees to be variable length, rather than the fixed 8 number chunks of the “SACA” format.)

The data address offsets are wrong in the files I’ve found (in FIAD format?) and scott2zil won’t read them without a little hacking, but that should be a minor thing.

[ahope1]

@pdxiv

TI99/4A action data sees to be variable length, rather than the fixed 8 number chunks of the “SACA” format.

That’s interesting! Please provide details, if and when you can.

[pdxiv]

This is my interpretation of the whole thing right now. Subject to change, as they say

The action part of the TI format seems to be optimized for speed and being able to write more verbose events. The data seems to be smaller than corresponding SACA on average though, by virtue of simply being encoded in binary.

Let’s have a look at the structure of an old SACA action for reference:

+-------------+-------------+
| Verb        | Noun/Chance |
+-------------+-------------+
| Condition 1 | Data 1      |
+-------------+-------------+
| Condition 2 | Data 2      |
+-------------+-------------+
| Condition 3 | Data 3      |
+-------------+-------------+
| Condition 4 | Data 4      |
+-------------+-------------+
| Condition 5 | Data 5      |
+-------------+-------------+
| Command 1   | Command 2   |
+-------------+-------------+
| Command 3   | Command 4   |
+-------------+-------------+

In terms of performance, this means that you’ll potentially need to scan through the whole list of actions to find one that matches every time you evaluate input, because you don’t know if a verb/noun combination you’re looking for is present until you reach the end of the entire list of actions.

In contrast, the TI actions seem to be arranged into “verb blocks”. When an input verb is recognized, the action evaluator looks up the memory address for the actions related to that verb in a table and starts to look for an action that matches the supplied noun. Every action begins with a “noun”, followed by action size in bytes and then the rest of the action consists of “opcodes” with 0-2 arguments.

The opcodes are grouped as follows:

0x00:        Do nothing
0x01 - 0xb6: Print message
0xb7 - 0xc9: Conditions
0xd5 - 0xfe: Commands
0xff:        End of action

Here’s the first action from Ghost Town in ScottKit format:

occur 3% when exists candle
        print "Candle blew out!"
        swap candle candle1
        look2

Here is the same action, in the “verb block” for “automatic actions”, in the TI binary format:

0x03           : "noun" with value 3
0x08           : Number of bytes in action
0xbd 0x09      : Check that item 9 "exists"
0x24           : Print message 36: "The candle blew out!"
0xec 0x09 0x1a : Swap item 9 with item 26
0xff           : Done executing action

In theory, this means that there are almost no limits to how many conditions, commands or print statements an action may have in the TI format since actions aren’t confined to “chunks” with a predefined size. The “pass values to commands on a stack via conditions” mess is also gone.

[Warrigal (Garry Francis)]

For what it’s worth, ‘SACA’ is Scott Adams Classic Adventure and ‘SAGA’ is Scott Adams Graphic Adventure. These refer to the underlying engine. Both TRS-80 and TI-99/4a data file formats use the SACA engine. I think Scott Adams coined the term when he introduced SAGA, just to distinguish between the two. SAGA was used in a marketing campaign, but I don’t think SACA was used as an acronym in advertising, although Scott Adams Classic Adventure was.