Search the Community
Showing results for tags 'gpl'.
-
** This question is about the crunch buffer in TI Basic, not the crunch buffer in Extended Basic ** ok, so I have been doing some experiments with TI Basic lately. For one of the tests I'm doing I am using the F18a with 30 rows mode. What I would like to do is add some information on the rows 25-30. The thing is that the VDP memory for that area is "blocked" by the TI Basic crunch buffer that starts at VDP >320 So here are my questions: Is it possible to move the TI Basic crunch buffer to another location in VDP memory? I presume it's hardcoded in the TI Basic interpreter in GPL. Was thinking about using a ISR routine in assembly routine that "kicks-in" and changes addresses (GPL registers, addresses) in a transparent way. Considering that TI Basic is so slow I might actually get away with it Any ideas on this one? Is the TI Basic disassembly available somewhere? I'm aware of TI XB disassembly, but not TI Basic itself. Actually I start liking TI Basic much. Yes it's slow, but I'd like to learn a lot more about its internals before addressing TI Extended Basic.
-
As discussed a little yesterday in the Pandemic club 4A zoom call (thanks for the interesting discussion!) I started to look a bit how the GPL interpreter could be optimised. My original idea was to add some instructions to my FPGA processor core to speed up the interpretation with special purpose instructions, but as I started to look at the code it's quite clear that a lot can be achieved with normal code optimisation. @RXB mentioned that there has been a discussion with @Tursi about this topic. I somehow recall seeing that thread myself, but couldn't easily find it (which is probably my fault). As an obvious optimisation, instead of the multiple levels of tables, the GPL instruction decoding could be improved at the cost of using some more memory simply by having a 256 entry lookup table (occupying 512 bytes). For that part I could create a new instruction which could combine a few TMS9900 instructions, in pseudo code: // Address 0x78 MOVB *R13,R9 JGPL @TABLE,R9 // Here JGPL would be a new instuction, something like below. // The instruction would only perform 2 memory fetches: Read R9, and fetch the jump vector from TABLE. BANK 1 // Switch bottom 8K to a new bank, which has the jump table MOV R9,TEMP // Temp internal register SRL TEMP,7 // TEMP >> 7, shift to a word index MOV @TABLE(TEMP),TEMP // Fetch from table BANK 0 // Switch bottom 8K to normal bank B *TEMP In the arrangement above since the opcode would be passed to the new instruction JGPL, that instruction could also be developed further to understand some GPL instructions directly, executing them directly by the CPU instead of TMS9900. Many GPL instructions are quite involved, so it would best to be able to incrementally improve things, for example starting with branch instructions which seem to be rather simple. I also realised that I am jumping the gun - I should try to look at some GPL code before going to optimization phase to understand how things work. To that end I started using xga99.py to assemble the GPL code for Minimemory cartridge, as a test. Also since I think this a very cool cartridge which could be integrated and expanded in interesting ways in both my icy99 and StrangeCart projects. So I got the GPL source code for Minimemory from Thierry's excellent TI-99/4A tech pages. I guess that code is for his GPL assembler. But I wanted to use the xdt99 package. So I started to assemble the source with xga99.py, like so: xga99.py --aorg 6000 mmg.gpl -L mmg.lst I quite quickly ran into a few problems, due to differences in syntax, for example: The AORG directive in xdt99 does not accept addresses higher than 8K. This causes a number of problems, because there is a hole in the code, i.e. it AORGs to >70AC skipping a bunch of bytes. I guess I have to manually fill that range with some bytes. The multiplication instruction in the source is MPY, but xga99 uses MUL. Not a biggie. Many lines in the code contain comments (which is great) after the code. I have never understood why the comments don't start with a special character like semicolon or something, that would make parsing easier for the assembler and it could probably also prevent some mistakes. Anyway, xga99 could not assemble a number of lines because the comments were separated by just a space. I just removed those comments after the code (by moving them to a separate comment line). The HTEX instruction (in a FMT block) escapes hex bytes differently, simple change: from HTEX '[>0A]' to HTEX >0A Some other opcodes also are different: CAR -> CARRY, PARS -> PARSE, DCGTE -> DCGT The source code uses the BIAS command also outside a FMT - FEND block, it appears to specify a constant to be added to strings specified with the STRI directive. The source I used has first BIAS >60 to set the TI Basic character code offset. I did not find a way to replicate this functionality in xda99. The advice goes: "use the source, Luke". And so I did, and created a new directive STRI60 for xda99, as follows. It's hack for sure, but I didn't want to enter the text as BYTE statements. * Original source (disassembled and commented by Thierry) BIAS >60 G6E1A STRI "ILLEGAL TAG" G6E26 STRI "CHECKSUM ERROR" ---------------------------------- * Modified source for xda99: *EPEP BIAS >60 G6E1A STRI60 "ILLEGAL TAG" G6E26 STRI60 "CHECKSUM ERROR ---------------------------------- * xda99.py has been modified to support the new STRI60 as follows: # EP 2020-12-13 added new STRI60 operation to add the screen offset to each byte. # Used for Mini Memory porting @staticmethod def STRI60(asm, label, ops): asm.process_label(label) text = ''.join(asm.parser.text(op) for op in ops) asm.emit(len(text), *[ord(c)+0x60 for c in text]) And this is roughly where I am at the moment. I am comparing the generated GPL binary image to the original, and now the first >770 bytes match (except for the pointer to >70AC due the AORG stuff, need to come up with a solution for that - probably I'll just fill in the empty range with some bytes) to get to 70AC.
-
I posted a scan of a photocopy of the SDS Programmers Guide in the Development Resources sticky, but it was suggested I start a new thread, so here it is. I have some other stuff, SDSMAC source listings, additional documentation, etc. to put here, too. Coming soon. Anyone else have anything relevant, please post away. The SDS consists of a GPL assembler, linker, simulator, and debugger running under DX10 on a TI 990 mini, typically a /10. TI BASIC programs can be converted to GROM format to run on the simulator. [edit] Anyone has a copy of the SDS software or even a running system, or knows where such might be, please post here, message me, or email jbdigriz@dragonsweb.org. Thanks! jbdigriz HCM_SDS.pdf
-
The batari Basic programming language now has a new home at github. I discussed this change with @batari prior to making this move. We both felt it was important to give bB an official home again. At github batari basic gets backed up, changes are tracked, bugs are tracked, other programmers can easily contribute, it can be forked easily, etc. batari even suggested we go a step further and license the bB source code under the GPL, so we did! (your games are still your games, and the GPL doesn't attach to them) For the latest batari Basic (v1.2 at the time of this writing) you can visit the batari Basic release page. The page where I hosted the now-defunct "reveng" fork now points to that release page. A special thanks goes out to @Karl G who helped with OS X testing, and to @Nathan Strum who provided a monochrome version of his "built with bB" logo, which was used for the project logo. Feel free to comment or ask questions about this change. If you have bug reports, I'd ask that they be submitted to either github or the AA bB bug report thread, and not brought up in this thread. I'd prefer github issues be used (since everything is tracked, conversations about bugs are threaded, etc) but I completely understand that not everybody wants to have a github account. Lastly, 7800basic will be getting the same treatment. I just need a break, as the cleanup and prep for the bB move took more effort than expected.
- 80 replies
-
- 15
-
- batari basic
- github
-
(and 1 more)
Tagged with:
-
Our intention is to collect as much historical background to the Why, When, Who and How GPL came to be. Please contribute by commenting to this topic. Things like : 1. When did it all start ? 2. Why ? 3. Who worked on it's development and interpreter ? 4. What was the real purpose ? 5. How does it compare to other languages ? 6. What can we do with it today ? 7. Coding in GPL in the 1980's compared to 2020 the stark difference. 8. What commercial software was written in GPL ? 9. Who were the important people around this language ? 10. Links to important material. If we can collect snippets of information from as many people as possible we can then compile it into a solid web page that will serve as a historical snapshot of this quirky yet beautiful language that time almost forgot. Thanks for your contributions. We will share a link to the webpage that will contain all you need to know about GPL as soon as we set it up.
-
Hi Guys, yesterday I have run into a nasty Syntax Error in Extended Basic, which also occurs in RXB. I don't understand it and wonder if the line really contains a Syntax Error or this is a Interpreter Bug. Version 1: 1 IF A=1 THEN 2 ELSE FOR I=1 TO 2 :: PRINT I :: NEXT I 2 END Version 2: 1 IF A=1 THEN 2 :: FOR I=1 TO 2 :: PRINT I :: NEXT I 2 END Both versions complain about a Syntax Error in Line 1. I would like to analyze it with the help of you and maybe RXB can be even fixed.
- 2 replies
-
- extended basic
- rxb
-
(and 4 more)
Tagged with:
-
Maybe I'm still dizzy, but I'm trying to write a small GPL program and for my life cannot figure out how to do relative jumps in GPL, like so: . B G@2(>8300) B G*>8300 B *>8300 . These are invalid syntax, though. So, what else? CASE is a bit unwieldy if the value is in the >1000s. I'm surprised I never noticed before ...
-
Is the addressing mode G*>xxxx a valid GS argument in a MOVE statement? AFAIK, the official GPL documentation doesn't mention it, but it can be inferred from combining MOVE bits I and C. In fact, assembling this program . GROM >6000 DATA >AA01 DATA >0000 DATA >0000 DATA MENU DATA 0,0,0,0 MENU DATA 0 DATA START BYTE 7 TEXT 'G* TEST' VAL TEXT 'HI' START DST VAL,@>8300 MOVE 2,G@VAL,V@170 MOVE 2,G*>8300,V@180 B $ . with the Ryte Data GPL assembler yields this byte code for the second MOVE statement: . (MOVE) 37 (Count) 00 02 (GD) a0 b4 (GS) 90 00 . The GS byte code stands for 2 byte address indirect 0 or >8300. But when I execute above program in MESS, only one "HI" is shown. I've tried changing "9000" to "00", "8000", "FF0000", "FF8300", but none of them work. So, is G* for real?
-
I'm trying to create an auto-starting cartridge, or more precisely, a cart with a menu translator that is used to start the cart without a menu selection. MBX and SF titles do this. But when I run this program . * GROM auto start sample grom >6000 data >aaff data >0100 data 0 data 0 ;menu data 0, 0, 0, 0 byte 0, 0, 0 ;menu: ; data 0 ; data autostart ; byte 9 ; text 'AUTOSTART' autostart: all 42 ; >6013 fmt row 10 col 10 htext 'AUTOSTART' fend back 14 stop: b stop end . the TI crashes with a white screen (in MESS). When I add a proper menu, everything works. Is there anything special that programs have to do when running as a menu translator? Note that my program does not return, but keeps on running.
-
This Topic is intended for those who are willing to learn, assist in learning, develop and publish code using GPL, the Graphic Programming Language proprietary to TI 99/4A also known as the GROM Language. To ensure that one can start from scratch and try to dabble a few lines of code in GPL I will list the most basic things that are needed and then show you a very small GPL language program which fills the screen with the letter A. 1. Install python 2.7.11 (Do not install 3.5 as it will not work with the GPL emulator I will propose) https://www.python.org/downloads/ 2. You need an assembler for windows and good documentation according to the assembler chosen. Assembler: https://endlos99.github.io/xdt99/ Documentation : http://www.unige.ch/medecine/nouspikel/ti99/gpl.htm I will assume you install it in C:\XDT99 3. You need a great emulator to run your well crafted virtual cartridges which we shall be creating. Classic 99 is my favourite : http://www.harmlesslion.com/cgi-bin/showprog.cgi?search=Classic99 I will assume you install it in C:\CLASSIC99 4. You need some kind of Editor I prefer Notepad++ : https://notepad-plus-plus.org/ 5. Setting up your assembler > There are clear notes on how to have XGA99 up and running to compile your .GPL code but I will cover this step by step for those who hate reading a lot of material scattered all over the place. Install XDT99, I selected c:\XDT99 folder. Unzip the attached file (xdt99.zip) into C:\XDT99, you can choose a different folder but there are some batch files you would need to change later. This will add a new folder to the standard XDT99 called "myfiles" and also the python program files are in C:\XDT99 (.py files) Point the PATH windows environment variable to point to C:\XDT99 where the.py reside. Please edit C:\XDT99\MYFILES\G.BAT and MG.BAT to point to myfiles and classic99 according to the paths you chose. Please note that all the files you create should be named <filename>G.gpl Example c:\xdt99\myfiles\testG.gpl To compile just go into DOS c:\xdt99\myfiles cd c:\xdt99\myfiles and type G test Note that I did not type G TESTG.GPL as the G.GPL will be auto appended by the G batch file. if no errors just type mg test. This will move TESTG.BIN to CLASSIC99\MODS 6. The last step is to execute the newly created cartridge. Fire Up classic 99 and select Cartridge->User->Open .... navigate to c:\classic99\mods and select the bin file. The TI Program menu will contain the program called TEST in position 2. Have fun... In this post I will place code snippets and BIN files for all to try and enjoy. xdt99.zip
- 101 replies
-
- 3
-
- GPL
- Development
-
(and 3 more)
Tagged with:
-
Ran accross the source code of the GPL Assembler in my files. GPLASSEMBLER SOURCE CODE.zip