Adventure Cartridge and GPL

[+InsaneMultitasker]

I have been taking a small detour to learn more about GPL. There are some programs like the 80 column menu that make use of snippets of GPL code, and I've always wanted to better understand the language.

 

To do this, I disassembled the adventure cartridge so that I could learn more about the language and also apply it to updating an old 'friend'.

 

Best I can tell, all of the interpreter changes are in place and working. However, I do not understand how to read/write VDP addresses beyond 0x1fff. Source like this:

 

736B * 86 CLR [email protected]>03C1
736E * BF DST @>8356,>03C9

Is assembled/disassembled as this:

86 A3 C1

BF 56 03 C9

 

Notice how the [email protected]>03c1 address is turned into "A3C1"? Whereas the CPU address is >03C9 in both listings.

 

I have to move ~15 bytes of buffered text and a few PABs to VDP>3600 or higher. The screenshot contains the bits of visible information I need to move.

 

Is GPL limited to directly accessing only the first 4K of VDP without using indirect access?

 

[mizapf]

Tim, have a look at TI Intern. It nicely explains the details of addressing and address representation in commands. For instance, all addresses within 8300 to 837F are represented by a single byte (00-7F), while other addresses are encoded.

 

[Just a side comment: "Intern" is a false friend, it means "internal(ly)" in German, and does not refer to a person.]

Edited May 6, 2018 by mizapf

[+Lee Stewart]

It is the leading >A of the address that informs the GPL interpreter that the address is in VDP RAM. >A000 – >AEFF will encode VRAM addresses >000 – >EFF in two bytes, whereas, >AF announces a VRAM address coming in the next two bytes, i.e., VRAM addresses higher than >EFF take three bytes. VRAM >3600 is encoded as >AF >36 >00.

 

...lee

[+InsaneMultitasker]

Tim, have a look at TI Intern. It nicely explains the details of addressing and address representation in commands. For instance, all addresses within 8300 to 837F are represented by a single byte (00-7F), while other addresses are encoded.

 

[Just a side comment: "Intern" is a false friend, it means "internal(ly)" in German, and does not refer to a person.]

I will take a look. I looked at the GPL manual only, and could not find any obvious explanation. I knew about the CPU pad ram encoding from debugging and an explanation long ago from Tony. It is good to know there is more!

 

It is the leading >A of the address that informs the GPL interpreter that the address is in VDP RAM. >A000 – >AEFF will encode VRAM addresses >000 – >EFF in two bytes, whereas, >AF announces a VRAM address coming in the next two bytes, i.e., VRAM addresses higher than >EFF take three bytes. VRAM >3600 is encoded as >AF >36 >00.

 

...lee

Is this also documented in The Intern, Lee? I will try this today and if it works it will solve the remaining problems in short order!

 

The only thing left will be to figure out how to perform a call files(1) in GPL. The adventure cartridge allows for loading files of 15,000 bytes starting at V0x0400. This works great for the cassette-based files but apparently no one took the disk devices and VDP buffers into account. The largest adventure files I've come across are just over 13k, so this may be a non issue.

[+Lee Stewart]

Is this also documented in The Intern, Lee? I will try this today and if it works it will solve the remaining problems in short order!

 

Yes. See page 97. Also, see “Appendix F” of R. A. Green’s The Graphics Programming Language.

 

...lee

[+InsaneMultitasker]

 

Yes. See page 97. Also, see “Appendix F” of R. A. Green’s The Graphics Programming Language.

 

...lee

Thank you, sir. I will look up both references! I tested the encoding and it is working. I was able to access 0x3700 just fine. Now that I know what to do, I will try to wrap up the changes to the file IO code.

[Casey]

 

The only thing left will be to figure out how to perform a call files(1) in GPL. The adventure cartridge allows for loading files of 15,000 bytes starting at V0x0400. This works great for the cassette-based files but apparently no one took the disk devices and VDP buffers into account. The largest adventure files I've come across are just over 13k, so this may be a non issue.

Have a look here: http://www.unige.ch/medecine/nouspikel/ti99/wr1.txt

 

This is a commented listing of the GPL source code for the TI Writer cartridge that Thierry has posted, but it does a CALL FILES(1) near the beginning.

       CALL  [email protected]>6663              |call files(1)
       BYTE  >01                  |

[+RXB]

This is what I sent to Insane Multitasker privately:

 

From GPL Programming manual page 3-15

Commad Reg.

bits turn on/off

4K or 16K, screen

on/off, interrupt

text mode, M: mode

Sprite size & mag

SAME PAGE:

>60-sets VDP for

4K memory, turns

screen on,enables

VDP interrupt,

puts VDP in oormal

pattern mode

with size

THUS for your problem it should be:

>E0-sets VDP for

16K memory, turns

screen on,enables

VDP interrupt,

puts VDP in oormal

pattern mode

with size

Page 3-14:

VDP(l) is the command register. Bit 7 is set if there is a

16K chip in the system. This bit should always be reset by the

programmer. The interpreter will set the bit if there is 16K.

[+InsaneMultitasker]

Thanks Rich and Casey... all of this is and has been very helpful as well!

 

Just a few more DSR-related changes to make and then I'll share the cartridge for testing on real hardware. All of my work so far has been done with Classic99 and Winhex.

[+Ksarul]

Ooooohhhh! Now to make an UberGROM image of this once you're done. . .

[+InsaneMultitasker]

A few things I've learned. The cartridge is programmed in GPL language and uses VDP for the usual things like screen and patterns, but also to store a title screen along with the game database. Many of the game programmers already have experience with having only the scratchpad RAM space available for workstpaces and variables. For me, this is a completely 'new' experience.

 

The scrolling and screen displays are handled with a combination of direct writes (GPL MOVES) and indirect printing. I haven't quite figured out the word-wrap code, but it relies upon a few pointers in CPU RAM that are updated either during printing or after a direct write. The information above the dashed line is printed differently than that underneath.

 

The FMT (format) GPL command really had me scratching my head for a while. The disassembler identified the first few, used for drawing the title screen. But it also incorrectly translated the "0x08" following the DSRLNK as a FMT command, which caused the disassembler to treat much of the following code as jibberish. I was able to disassemble the code following the 0x08 to get a listing eventually

 

I used Ralph's gpl disassembler from the TI Cross Development tools and also this EA3 gpl disassembler for the latter bulk of my work.

 

Oh yea, 10 minutes of frustration later I learned that using MAME and Classic99 can be hazardous to one's mental state. I was trying to reload the disassembler from DSK3 where it was clearly present in the classic99\dsk3 folder. Then I realized I was using MAME and the file it could load was on DSK2, mounted as a disk image. Oh brother.

 

[+acadiel]

Ooooohhhh! Now to make an UberGROM image of this once you're done. . .

Yep, drooool!

 

Package that up with those two disk images I just made and we’re cooking!

[Fritz442]

This may be a bit off subject, but is there any way to run the game file in

high ram in stead of VDP so the game files could be larger?

[+InsaneMultitasker]

Yep, drooool!

 

Package that up with those two disk images I just made and we’re cooking!

Which images are you referring to ?

 

This may be a bit off subject, but is there any way to run the game file in

high ram in stead of VDP so the game files could be larger?

This isn't an impossible task but certainly not an easy one. The game would first need to be properly disassembled then you would need to change all VDP references to CPU RAM throughout the cartridge. It's not something I have the appetite for but certainly anyone else is willing to give it a go; I'll share my work with that theoretical challenge taker, if he/she exists.

[+acadiel]

I think the Scott Adams adventure format is relatively well understood, but we can probably ask the man himself for the format that he used. He's really active on Facebook, and we can probably write a new interpreter. He told me at VCF that the computer has to have at least 16K of RAM to load the database.

 

Sent from my moto x4 using Tapatalk

[Fritz442]

 

This isn't an impossible task but certainly not an easy one. The game would first need to be properly disassembled then you would need to change all VDP references to CPU RAM throughout the cartridge. It's not something I have the appetite for but certainly anyone else is willing to give it a go; I'll share my work with that theoretical challenge taker, if he/she exists.

I wish I had better understanding of this, I have been working on two new Adventure games recently but run out of room.

We could make some really kick ass games with larger game files.

[+InsaneMultitasker]

Tell me some more about the space issue. Is it a result of too many objects, too many text responses, etc. Maybe a portion of the parser could be changed to look in CPU RAM for a larger game. If you share the format of the game file, I'll look at where it is stored in a few of the adventure games to get some context.

[Fritz442]

Yes all objects, text, and APL fill up the VDP space. That's why all games are no larger than about 13k. Just like TOD games

are about that same size. I believe back then not everybody could afford 32k ram so it was written to stay in the console.

If we could move that to 32k ram the games could be much larger and longer.

When using the editor, there is a percentage that increases as you write the game. When it reaches 100% it simply

stops writing data to the game file.

Edited May 8, 2018 by Fritz442

[+InsaneMultitasker]

The cartridge is coded to load a file up to 15k in size. However, this upper limit was most likely set before the disk system was considered, since adding a controller reduces available VDP by ~1.5k. In theory, a game file of 14k is possible if a CALL FILES(1) equivalent is performed for both the cartridge and the game editor.

 

Inspecting a game file shows a basic layout as follows:

1k - title screen, one time display only

1k - character set

5 tables of information consisting of a set of pointers and the data

-objects/things you see in the location

-in-game responses

-item abbreviations

-locations

-action abbreviations

in game logic

 

Moving the tables to the 32k might be simple enough, but you'd still need to be able to create a larger file with the editor.

 

Edit: The adventure editor documentation states the following:

 

"... This percentage is deriven from an 'available VDP memory space' which has been chosen as to enable data storage on diskette medium. (i.e. up to >3780V). The adventure command module however will accept files longer than that (up to >3A98V) which will ONLY be possible on cassette storage medium with no diskette controller connected."

 

The documented limit matches the cartridge's load limit: DST [email protected]>03C6,>3A98. So in reality, removing the disk controller from the equation would only get you a few hundred bytes, as I was not taking into account the reserved space and screen space in my earlier comments.

Edited May 8, 2018 by InsaneMultitasker

[+InsaneMultitasker]

 

Have a look here: http://www.unige.ch/medecine/nouspikel/ti99/wr1.txt

 

This is a commented listing of the GPL source code for the TI Writer cartridge that Thierry has posted, but it does a CALL FILES(1) near the beginning.

This code was quite helpful. Any idea what program was used to disassemble the TI Writer cartridge? The output is much closer to what I'm used to from Diskassembler, and certainly easier to follow!!!

[Torrax]

Reading this jogged my memory about a project I started back in 2009 and forgot about. So here's some old files zipped up. Not sure if I used Theirry's GPL Disassembler or TI-99/Sim's dumpgrom back then.

 

There's not much in my commented source file. Not sure where my printouts are that contained more detailed notes. Hopefully they are stuffed somewhere in my small apartment.

!GPL-ADV-TOD-stuff.zip

[+TheBF]

I wish I had better understanding of this, I have been working on two new Adventure games recently but run out of room.

We could make some really kick ass games with larger game files.

 

 

I have been considering how to create an adventure game language for people like you in Forth.

It would be a set of high level commands that let you make the databases, output text and accept commands from the user that would be interpreted by the system.

Different databases of responses could be kept in VDP RAM and expansion memory so the game space gets much bigger.

 

If it was done using the Forth BLOCK file system in TF or FB Forth, the database can be an entire disk with little difficulty.

 

I know nothing about adventure games. Could you give me a list of commands that would make it easy for you?

 

B

[+InsaneMultitasker]

Reading this jogged my memory about a project I started back in 2009 and forgot about. So here's some old files zipped up. Not sure if I used Theirry's GPL Disassembler or TI-99/Sim's dumpgrom back then.

 

There's not much in my commented source file. Not sure where my printouts are that contained more detailed notes. Hopefully they are stuffed somewhere in my small apartment.

 

Now that's the style of disassembly output I am more used to! Do you recall if the source will re-assemble into the cartridge or what programs I would use to attempt it? If so, I might take my comments and 'merge' them into your files.

[Fritz442]

 

 

I have been considering how to create an adventure game language for people like you in Forth.

It would be a set of high level commands that let you make the databases, output text and accept commands from the user that would be interpreted by the system.

Different databases of responses could be kept in VDP RAM and expansion memory so the game space gets much bigger.

 

If it was done using the Forth BLOCK file system in TF or FB Forth, the database can be an entire disk with little difficulty.

 

I know nothing about adventure games. Could you give me a list of commands that would make it easy for you?

 

B

I'm not really sure how to answer this question, is your program going to create a game file for the Adventure module?

[Fritz442]

Moving the tables to the 32k might be simple enough, but you'd still need to be able to create a larger file with the editor.

 

Edit: The adventure editor documentation states the following:

 

"... This percentage is deriven from an 'available VDP memory space' which has been chosen as to enable data storage on diskette medium. (i.e. up to >3780V). The adventure command module however will accept files longer than that (up to >3A98V) which will ONLY be possible on cassette storage medium with no diskette controller connected."

 

The documented limit matches the cartridge's load limit: DST [email protected]>03C6,>3A98. So in reality, removing the disk controller from the equation would only get you a few hundred bytes, as I was not taking into account the reserved space and screen space in my earlier comments.

I didn't know about the cartridge's load limit. If that can not be changed, then the whole larger file idea would possibly be dead in the water.

Edited May 9, 2018 by Fritz442