+InsaneMultitasker #1 Posted May 6, 2018 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]>03C1736E * 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? 3 Quote Share this post Link to post Share on other sites
mizapf #2 Posted May 6, 2018 (edited) 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 1 Quote Share this post Link to post Share on other sites
+Lee Stewart #3 Posted May 6, 2018 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 1 Quote Share this post Link to post Share on other sites
+InsaneMultitasker #4 Posted May 6, 2018 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. Quote Share this post Link to post Share on other sites
+Lee Stewart #5 Posted May 6, 2018 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 2 Quote Share this post Link to post Share on other sites
+InsaneMultitasker #6 Posted May 6, 2018 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. 3 Quote Share this post Link to post Share on other sites
Casey #7 Posted May 6, 2018 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 | 2 Quote Share this post Link to post Share on other sites
+RXB #8 Posted May 6, 2018 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. 1 Quote Share this post Link to post Share on other sites
+InsaneMultitasker #9 Posted May 6, 2018 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. 4 Quote Share this post Link to post Share on other sites
+Ksarul #10 Posted May 7, 2018 Ooooohhhh! Now to make an UberGROM image of this once you're done. . . Quote Share this post Link to post Share on other sites
+InsaneMultitasker #11 Posted May 7, 2018 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. 4 Quote Share this post Link to post Share on other sites
+acadiel #12 Posted May 7, 2018 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! Quote Share this post Link to post Share on other sites
Fritz442 #13 Posted May 8, 2018 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? Quote Share this post Link to post Share on other sites
+InsaneMultitasker #14 Posted May 8, 2018 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. 1 Quote Share this post Link to post Share on other sites
+acadiel #15 Posted May 8, 2018 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 1 Quote Share this post Link to post Share on other sites
Fritz442 #16 Posted May 8, 2018 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. Quote Share this post Link to post Share on other sites
+InsaneMultitasker #17 Posted May 8, 2018 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. Quote Share this post Link to post Share on other sites
Fritz442 #18 Posted May 8, 2018 (edited) 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 Quote Share this post Link to post Share on other sites
+InsaneMultitasker #19 Posted May 8, 2018 (edited) 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 Quote Share this post Link to post Share on other sites
+InsaneMultitasker #20 Posted May 8, 2018 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!!! 2 Quote Share this post Link to post Share on other sites
Torrax #21 Posted May 8, 2018 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 4 Quote Share this post Link to post Share on other sites
+TheBF #22 Posted May 8, 2018 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 Quote Share this post Link to post Share on other sites
+InsaneMultitasker #23 Posted May 8, 2018 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. Quote Share this post Link to post Share on other sites
Fritz442 #24 Posted May 9, 2018 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? Quote Share this post Link to post Share on other sites
Fritz442 #25 Posted May 9, 2018 (edited) 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 Quote Share this post Link to post Share on other sites