+InsaneMultitasker Posted May 6, 2018 Share Posted May 6, 2018 12 March 2022: Released nearly complete version: adventure2022Mar12 testG.bin - binary grom cartridge image for use with Classic99, js99er, fg99. For FG99, RENAME to ADV80G.BIN ADVGROM80 - TIFILES format Gram cartridge file, with header. (Loads into Geneve GPL but a modified GPL needs to be released) Thank you to those who participated in this thread and helped me to better understand GPL. This has been a fun project and it only required a few years to release what I hope is a stable version --------------------------------------- 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? 3 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 6, 2018 Share 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 Link to comment Share on other sites More sharing options...
+Lee Stewart Posted May 6, 2018 Share 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 Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 6, 2018 Author Share 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 Link to comment Share on other sites More sharing options...
+Lee Stewart Posted May 6, 2018 Share 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 3 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 6, 2018 Author Share 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 Link to comment Share on other sites More sharing options...
Casey Posted May 6, 2018 Share 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 G@>6663 |call files(1) BYTE >01 | 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted May 6, 2018 Share 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 Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 6, 2018 Author Share 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 Link to comment Share on other sites More sharing options...
+Ksarul Posted May 7, 2018 Share Posted May 7, 2018 Ooooohhhh! Now to make an UberGROM image of this once you're done. . . Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 7, 2018 Author Share 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 Link to comment Share on other sites More sharing options...
+acadiel Posted May 7, 2018 Share 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 Link to comment Share on other sites More sharing options...
Fritz442 Posted May 8, 2018 Share 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 Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 8, 2018 Author Share 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 Link to comment Share on other sites More sharing options...
+acadiel Posted May 8, 2018 Share 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 Link to comment Share on other sites More sharing options...
Fritz442 Posted May 8, 2018 Share 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 Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 8, 2018 Author Share 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 Link to comment Share on other sites More sharing options...
Fritz442 Posted May 8, 2018 Share 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 Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 8, 2018 Author Share 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 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 May 8, 2018 by InsaneMultitasker Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 8, 2018 Author Share 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 Link to comment Share on other sites More sharing options...
+Torrax Posted May 8, 2018 Share 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 Link to comment Share on other sites More sharing options...
+TheBF Posted May 8, 2018 Share 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 Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 8, 2018 Author Share 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 Link to comment Share on other sites More sharing options...
Fritz442 Posted May 9, 2018 Share 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 Link to comment Share on other sites More sharing options...
Fritz442 Posted May 9, 2018 Share 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 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 May 9, 2018 by Fritz442 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.