Jump to content

Photo

Adventure Cartridge and GPL

Adventure GPL F18A

51 replies to this topic

#1 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,015 posts

Posted Sat May 5, 2018 10:03 PM

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   V@>03C1
736E   *   BF   DST   @>8356,>03C9
 

Is assembled/disassembled as this:

86 A3 C1

BF 56 03 C9

 

Notice how the V@>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?

 

Attached Files



#2 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,190 posts
  • Location:Germany

Posted Sun May 6, 2018 7:03 AM

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 by mizapf, Sun May 6, 2018 7:05 AM.


#3 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,671 posts
  • Location:Silver Run, Maryland

Posted Sun May 6, 2018 8:16 AM

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



#4 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,015 posts

Posted Sun May 6, 2018 9:59 AM

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



#5 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,671 posts
  • Location:Silver Run, Maryland

Posted Sun May 6, 2018 11:31 AM

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



#6 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,015 posts

Posted Sun May 6, 2018 12:17 PM

 

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



#7 Casey OFFLINE  

Casey

    Chopper Commander

  • 230 posts

Posted Sun May 6, 2018 2:02 PM

 

The only thing left will be to figure out how to perform a call files(1) in GPL. :-o   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/...el/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  G@>6663              |call files(1)
       BYTE  >01                  |


#8 RXB OFFLINE  

RXB

    River Patroller

  • 3,017 posts
  • Location:Vancouver, Washington, USA

Posted Sun May 6, 2018 3:46 PM

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.


#9 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,015 posts

Posted Sun May 6, 2018 5:32 PM

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

Attached File  adv80-2.JPG   54.12KB   2 downloads



#10 Ksarul OFFLINE  

Ksarul

    River Patroller

  • 4,568 posts

Posted Sun May 6, 2018 6:00 PM

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



#11 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,015 posts

Posted Sun May 6, 2018 6:45 PM

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. 

Attached File  gpldisassm.jpg   13.1KB   3 downloads

 

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.

 



#12 acadiel ONLINE  

acadiel

    Stargunner

  • 1,354 posts
  • www.hexbus.com
  • Location:USA

Posted Mon May 7, 2018 4:44 PM

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!

#13 Fritz442 OFFLINE  

Fritz442

    Chopper Commander

  • 204 posts
  • Location:Florida

Posted Mon May 7, 2018 6:21 PM

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?



#14 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,015 posts

Posted Mon May 7, 2018 6:30 PM

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.



#15 acadiel ONLINE  

acadiel

    Stargunner

  • 1,354 posts
  • www.hexbus.com
  • Location:USA

Posted Mon May 7, 2018 6:39 PM

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

#16 Fritz442 OFFLINE  

Fritz442

    Chopper Commander

  • 204 posts
  • Location:Florida

Posted Mon May 7, 2018 6:41 PM

 

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



#17 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,015 posts

Posted Mon May 7, 2018 6:50 PM

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. 



#18 Fritz442 OFFLINE  

Fritz442

    Chopper Commander

  • 204 posts
  • Location:Florida

Posted Mon May 7, 2018 7:05 PM

 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 by Fritz442, Mon May 7, 2018 7:17 PM.


#19 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,015 posts

Posted Mon May 7, 2018 9:18 PM

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   V@>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 by InsaneMultitasker, Mon May 7, 2018 9:44 PM.


#20 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,015 posts

Posted Mon May 7, 2018 9:53 PM

 

Have a look here:  http://www.unige.ch/...el/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!!!



#21 Torrax OFFLINE  

Torrax

    Chopper Commander

  • 111 posts

Posted Tue May 8, 2018 3:05 AM

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. 

Attached Files



#22 TheBF ONLINE  

TheBF

    Dragonstomper

  • 568 posts
  • Location:The Great White North

Posted Tue May 8, 2018 7:14 AM

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



#23 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • Topic Starter
  • 2,015 posts

Posted Tue May 8, 2018 11:59 AM

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.



#24 Fritz442 OFFLINE  

Fritz442

    Chopper Commander

  • 204 posts
  • Location:Florida

Posted Tue May 8, 2018 6:14 PM

 

 

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?



#25 Fritz442 OFFLINE  

Fritz442

    Chopper Commander

  • 204 posts
  • Location:Florida

Posted Tue May 8, 2018 6:18 PM

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   V@>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 by Fritz442, Tue May 8, 2018 6:50 PM.






Also tagged with one or more of these keywords: Adventure, GPL, F18A

1 user(s) are browsing this forum

0 members, 1 guests, 0 anonymous users