+TheBF Posted July 27, 2019 Share Posted July 27, 2019 9 hours ago, GDMike said: <snip> Was it just intended to write to ROMs and package up that way? Interpreters have always been used to save program space. They do this many times, as GPL does, by making all instructions only one byte in size. (byte code interpreter). This method also allows you to assign special bytes as higher level instructions meaning they enable more complicated routines. All this applies to the stock 99 console which only 256 bytes of CPU memory and all the rest living in the video processor! That's a very constricted system. :-) I can't prove this but it is possible that the GPL authors were influenced by Forth as it has a data stack AND a program return stack. Using stacks can conserve program space as well in a byte code interpreter by not requiring arguments in the instruction stream. This is because all arguments are known to be on the data stack. In this respect I don't know enough about GPL to know if they took advantage of this idea. My 2 cents. 2 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 27, 2019 Share Posted July 27, 2019 25 minutes ago, TheBF said: Interpreters have always been used to save program space. They do this many times, as GPL does, by making all instructions only one byte in size. (byte code interpreter). This method also allows you to assign special bytes as higher level instructions meaning they enable more complicated routines. All this applies to the stock 99 console which only 256 bytes of CPU memory and all the rest living in the video processor! That's a very constricted system. :-) I can't prove this but it is possible that the GPL authors were influenced by Forth as it has a data stack AND a program return stack. Using stacks can conserve program space as well in a byte code interpreter by not requiring arguments in the instruction stream. This is because all arguments are known to be on the data stack. In this respect I don't know enough about GPL to know if they took advantage of this idea. My 2 cents. P-code interpreters probably influenced the GPL designers, as well. The idea of p-code predates Forth by several years, though the popular use of p-code interpreters (notably, the UCSD Pascal P-System) brackets Moore’s invention of Forth. ...lee 3 Quote Link to comment Share on other sites More sharing options...
GDMike Posted July 27, 2019 Share Posted July 27, 2019 Thank you! You can find books regarding development, but hard to find personal thoughts regarding. Quote Link to comment Share on other sites More sharing options...
RXB Posted July 27, 2019 Share Posted July 27, 2019 16 hours ago, Tursi said: Sorry Rich.. you know I think GPL is okay and definitely has its place, but you made the challenge. challenge.lst 13.39 kB · 10 downloads No support code needed, 342 bytes. But I don't think the GPL code provided takes anywhere near 1073 bytes... what were you including? The biggest chunk is support for character definitions: 605D: MOVE >03CC BYTES FROM GROM@>61B7 TO VDP@>1002 The rest is just GPL setting up VDP, again Assembly takes up tons of memory in comparison. Example in Assembly you need VMBW to move from ROM or RAM to VDP. The above "MOVE >03CC,G@>6187,V@>1002" takes 7 GROM bytes, I know Assembly is no where that compact. My article from Micropendium "Comparing Languages" explains the differences between XB, GPL and Assembly. With out support routines loaded like VMBR or VMBW or VSBR or VSBW or DSR assembly can not do anything easy, these take up space (Just a fact). Unlike GPL that already has those built into the OS. If the above support routines were built in then things would be different. 2 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted July 27, 2019 Share Posted July 27, 2019 (edited) 18 hours ago, Tursi said: Sorry Rich.. you know I think GPL is okay and definitely has its place, but you made the challenge. challenge.lst 13.39 kB · 11 downloads No support code needed, 342 bytes. But I don't think the GPL code provided takes anywhere near 1073 bytes... what were you including? (Full disclosure I don't know that the original GPL program actually did) But if in some alternate reality ? ... we made a set of ROMS for TI-99 with Forth instead of GPL... and we put the workspace and two Forth stacks in scratchpad (32+64+64 bytes) ... You could add CHARSET to the system and it uses 178 bytes which includes labels and a re-usable routine GVMOVE that reads GROM and writes to VDP. Mea culpa but I hard-coded the PDT and GROM font address here for my own system but they could be variables fed by a two other routines and it would still be small. HEX : GROM ( addr -- ) DUP 9C02 ! 9C02 C! ; \ set the GROM address : GC@+ ( -- c) 9800 C@ ; \ read & auto-increment address : ]PDT ( char# -- 'pdt[n] ) 8* 800 + ; \ VDP pattern Descriptor table : ]GFONT ( ascii -- grom_adr) BL - 7 * 6B4 + ; \ GROM array of TIFont data \ transfer directly from GROM to VDP : GVMOVE ( grom_addr vdp_addr cnt -- ) ROT GROM BOUNDS DO GC@+ I VC! LOOP ; : CHARSET ( -- ) [CHAR] ~ 1+ BL \ all ASCII chars DO I ]GFONT \ get GROM address for char I I ]PDT \ get PDT address for char I 0 OVER VC! \ store 1st zero in VDP 1+ \ inc PDT address 7 GVMOVE \ write 7 bytes GROM->VDP LOOP ; GVMOVE is like Tursi's GPL2VDP routine (albeit slower) and it would be used like this which took another 116 bytes. So 178+116= 294 bytes HEX : MOVESTUFF 6077 0C80 10 GVMOVE 6087 0AE0 32 GVMOVE 60B7 0B40 30 GVMOVE 60E7 0B80 10 GVMOVE 60F7 0BC0 B8 GVMOVE 61AF 0CC0 08 GVMOVE 6077 0384 08 GVMOVE ; All that to say that 1073 bytes does seem a bit weighty so there must be more going on. Edited July 27, 2019 by TheBF Wrong number of bytes for workspace 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted July 27, 2019 Share Posted July 27, 2019 2 hours ago, TheBF said: (Full disclosure I don't know that the original GPL program actually did) But if in some alternate reality ? ... we made a set of ROMS for TI-99 with Forth instead of GPL... and we put the workspace and two Forth stacks in scratchpad (32+64+64 bytes) ... You could add CHARSET to the system and it uses 178 bytes which includes labels and a re-usable routine GVMOVE that reads GROM and writes to VDP. I want this. I want a 4A that has nothing but FORTH on it. Then it would be a 99/4thA. Seriously, I would use this. 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted July 27, 2019 Share Posted July 27, 2019 (edited) I'm reviewing a piece of assy code from R.A.Green which sets up keyboard input and Display architecture. It looks interesting. Not a BLWP Kscan,Vmbw, etc...In it I think. I was hoping I could assemble this but I just found this! I know what he's saying, but my editor assembler doesn't.. Edited July 27, 2019 by GDMike Quote Link to comment Share on other sites More sharing options...
+TheBF Posted July 27, 2019 Share Posted July 27, 2019 2 hours ago, FarmerPotato said: I want this. I want a 4A that has nothing but FORTH on it. Then it would be a 99/4thA. Seriously, I would use this. It would be a big undertaking and keeping it compatible would be impossible I think. Which Forth system are you using now? 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted July 27, 2019 Share Posted July 27, 2019 Just now, TheBF said: It would be a big undertaking and keeping it compatible would be impossible I think. Which Forth system are you using now? Doesn't have to be compatible. Just let it be an instant-on FORTH prompt. Graphics and sound. It would have to be able to call the disk controller DSR (or rewrite it) and have its own RS232 primitives. Having fast internal 32K would be a nice complement. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted July 27, 2019 Share Posted July 27, 2019 14 minutes ago, FarmerPotato said: Doesn't have to be compatible. Just let it be an instant-on FORTH prompt. Graphics and sound. It would have to be able to call the disk controller DSR (or rewrite it) and have its own RS232 primitives. Having fast internal 32K would be a nice complement. I want one too! I will noodle on it. Maybe It could be tested by swapping ROM files on an emulator ???? That would be soooo much better. 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted July 27, 2019 Share Posted July 27, 2019 (edited) I'd love to see it too, booting up to "OK" Edited July 27, 2019 by GDMike Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 28, 2019 Share Posted July 28, 2019 6 hours ago, GDMike said: I'm reviewing a piece of assy code from R.A.Green which sets up keyboard input and Display architecture. It looks interesting. Not a BLWP Kscan,Vmbw, etc...In it I think. I was hoping I could assemble this but I just found this! I know what he's saying, but my editor assembler doesn't.. Perhaps the code was written for Green’s Macro-Assembler, RAGASM, which code would likely not be compatible with the TI E/A Assembler. ...lee 1 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 28, 2019 Share Posted July 28, 2019 On 7/27/2019 at 10:47 AM, TheBF said: All that to say that 1073 bytes does seem a bit weighty so there must be more going on. Rich was including the size of the data tables. 1 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 31, 2019 Share Posted July 31, 2019 On 7/25/2019 at 6:21 PM, arcadeshopper said: wrong. Many grom games were converted to run from ram with a little code to copy the grom image to ram then execute.. runs great..from disk or rom cart.. needs 32k tho if your copy needs 32k, that's what it's doing. Looking at the GPL interpreter in INTERN, it's hard for me to see how this could work. The GPL interpreter is hard coded in the ROM. At >0078 is MOVB *R13,R9 which fetches the GPL byte into R9. Assuming you set up R9 to point to the byte in RAM, to fetch it would have to be MOVB *R13+,R9. There are lots of places in the interpreter with JMP >0070 or B @>0070. So hard wired in the ROM are instructions that send the microprocessor to an instruction that doesn't do the right thing. I believe you could rewrite the GPL interpretor so it can deal with RAM instead of groms - that would be 8K of assembly code, unfortunately on the 8K bus so performance would be slower. Many cartridges used GPL and ROM. The GPL was used to load the screen, character definitions and other set up tasks, then control would be transferred to the assembly portion of the program. The GPL portions could be duplicated in assembly, but then you're not running GPL from RAM; you're running straight assembly. Although I can't see how you could run GPL from RAM, that doesn't mean it can't be done. Some of the cartridges that are pure GPL are BLASTO, CAR WARS, AMAZING, HUNT THE WUMPUS, THE ATTACK, and many others. If they have been converted to run from RAM that shows that it can be done. The real subject was RAGASM and whether it was written in GPL. RAGASM consists of two files: one loads into >2000 to >3FFF; the other loads from >A000 to >BE16. I disassembled this code and found that it is straight assembly code from >2000 to >3FFF. >A000 to >B2C8 is also assembly. >B7C8 to >BE16 is assembly and character definitions. The section of code from about >B2C8 to >B7C8 is not assembly instructions and it doesn't look like GPL code either. It looks like some sort of table. There what seem to be evenly spaced numbers often separated with multiple >0000 and >2000 and others. The bottom line is that RAGASM is either all assembly code or almost all assembly. If any of it is written in GPL is is a small fraction of the total code. 1 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 31, 2019 Share Posted July 31, 2019 2 hours ago, senior_falcon said: Looking at the GPL interpreter in INTERN, it's hard for me to see how this could work. The GPL interpreter is hard coded in the ROM. At >0078 is MOVB *R13,R9 which fetches the GPL byte into R9. Assuming you set up R9 to point to the byte in RAM, to fetch it would have to be MOVB *R13+,R9. There are lots of places in the interpreter with JMP >0070 or B @>0070. So hard wired in the ROM are instructions that send the microprocessor to an instruction that doesn't do the right thing. I believe you could rewrite the GPL interpretor so it can deal with RAM instead of groms - that would be 8K of assembly code, unfortunately on the 8K bus so performance would be slower. Many cartridges used GPL and ROM. The GPL was used to load the screen, character definitions and other set up tasks, then control would be transferred to the assembly portion of the program. The GPL portions could be duplicated in assembly, but then you're not running GPL from RAM; you're running straight assembly. Although I can't see how you could run GPL from RAM, that doesn't mean it can't be done. Some of the cartridges that are pure GPL are BLASTO, CAR WARS, AMAZING, HUNT THE WUMPUS, THE ATTACK, and many others. If they have been converted to run from RAM that shows that it can be done. The real subject was RAGASM and whether it was written in GPL. RAGASM consists of two files: one loads into >2000 to >3FFF; the other loads from >A000 to >BE16. I disassembled this code and found that it is straight assembly code from >2000 to >3FFF. >A000 to >B2C8 is also assembly. >B7C8 to >BE16 is assembly and character definitions. The section of code from about >B2C8 to >B7C8 is not assembly instructions and it doesn't look like GPL code either. It looks like some sort of table. There what seem to be evenly spaced numbers often separated with multiple >0000 and >2000 and others. The bottom line is that RAGASM is either all assembly code or almost all assembly. If any of it is written in GPL is is a small fraction of the total code. Here is a link to post#287 of FlashROM 99 & FinalGROM 99 - Repository in which I posted the linker docs for the RyteData GPL Linker, which can run GPL cartridge code from the 32 KiB expansion RAM by loading a GPL simulator into the lower 8 KiB to interpret the GPL object code loaded with it into the upper 24 KiB. I am not aware of any source code for this GPL simulator, but that would sure be nice. ...lee 2 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted July 31, 2019 Share Posted July 31, 2019 9 hours ago, senior_falcon said: I believe you could rewrite the GPL interpretor so it can deal with RAM instead of groms - that would be 8K of assembly code, unfortunately on the 8K bus so performance would be slower. 6 hours ago, Lee Stewart said: Here is a link to post#287 of FlashROM 99 & FinalGROM 99 - Repository in which I posted the linker docs for the RyteData GPL Linker, which can run GPL cartridge code from the 32 KiB expansion RAM by loading a GPL simulator into the lower 8 KiB to interpret the GPL object code loaded with it into the upper 24 KiB. I am not aware of any source code for this GPL simulator, but that would sure be nice. ...lee So it is as I thought-a new GPL interpreter in RAM. Do you know if it uses all 8K of low memory? Maybe they were clever enough to use some of the GPL interpreter in ROM. Looks like you'd have to adjust address pointers in the GROM code to deal with the new location. For example, GROM at >G0C7E is CALL GROM >11F2 which is >0611F2. 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted July 31, 2019 Share Posted July 31, 2019 1 hour ago, senior_falcon said: So it is as I thought-a new GPL interpreter in RAM. Do you know if it uses all 8K of low memory? Maybe they were clever enough to use some of the GPL interpreter in ROM. Looks like you'd have to adjust address pointers in the GROM code to deal with the new location. For example, GROM at >G0C7E is CALL GROM >11F2 which is >0611F2. Well, the first six bytes of UTIL1 are FFFF 0B96 2A00, which means 2966 (>0B96) bytes are loaded at >2A00. The GPL simulator that the linker generates to run the GPL object code it processes for you is actually a copy of UTIL1 with the name as the first of two E/A5 files produced by the linker and its header modified as necessary. ...lee 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted August 1, 2019 Share Posted August 1, 2019 Here's an old post(the oldest!) that mentions a GPL interpreter simulator. I remember when this subject seemed so amazing! #20 EDIT: This was meant to post as: #947 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted August 1, 2019 Share Posted August 1, 2019 3 hours ago, HOME AUTOMATION said: I remember when this subject seemed so amazing! Me too. That was yesterday when I found out about it! 1 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted August 2, 2019 Share Posted August 2, 2019 16 hours ago, HOME AUTOMATION said: Here's an old post(the oldest!) that mentions a GPL interpreter simulator. I remember when this subject seemed so amazing! #20 EDIT: This was meant to post as: #947 I think it is awesome 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted August 3, 2019 Share Posted August 3, 2019 It's nice to have an idea how it works w/o having to do the research myself. Thanks, Lee. 1 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted October 31, 2019 Share Posted October 31, 2019 (edited) Something for the 9900 experts I saw this cool routine for Intel86 CPUs that determines if a number n is greater than or equal to a low limit and less than a higher limit. The did not use jumps but did use a final SBB instruction (subtract with borrow) It was used in a Windows Forth system and the code is shown below in a Forth RPN format. For clarity: hi is in BX lo is in AX n is in CX Output is returned in BX. I tried doing this in 9900 code and I can't seem to emulate the SBB instruction correctly. I tried jumping on the carry flag to change the output register but no luck? Anybody know how? CODE within ( n lo hi -- flag ) \ clever version is taken from Win32For. No JUMPS! ax pop. cx pop. bx ax sub. cx ax sub. cx bx sub. bx bx sbb. next. end-code Edit: I got it to work this way. Is this as good as it gets? By way of translating Forth Assembler: pop is a macro: *SP+ Rx MOV, NC IF, assembles: JOC ELSE, +2 ELSE, assembles: JMP ENDIF, \ cx ax bx \ R1 R0 tos CODE WITHIN ( n lo hi -- flag ) R0 POP, R1 POP, R0 TOS SUB, R0 R1 SUB, TOS R1 SUB, NC IF, TOS SETO, ELSE, TOS CLR, ENDIF, NEXT, ENDCODE Edited October 31, 2019 by TheBF Quote Link to comment Share on other sites More sharing options...
intvnut Posted October 31, 2019 Share Posted October 31, 2019 You might be slightly faster if you always CLR TOS, and then conditionally SETO, to avoid the extra unconditional JMP. CLR doesn't modify the flags. Something like this (guessing at the syntax): \ cx ax bx \ R1 R0 tos CODE WITHIN ( n lo hi -- flag ) R0 POP, R1 POP, R0 TOS SUB, R0 R1 SUB, TOS R1 SUB, TOS CLR, NC IF, TOS SETO, ENDIF, NEXT, ENDCODE Quote Link to comment Share on other sites More sharing options...
intvnut Posted October 31, 2019 Share Posted October 31, 2019 Also, I'm not an expert in TMS9900 instruction timings. Would there be any advantage to using relative addressing rather than POPs? e.g @2(SP), @4(SP), etc. and then doing a single stack update at the end? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 31, 2019 Share Posted October 31, 2019 2 hours ago, TheBF said: I tried doing this in 9900 code and I can't seem to emulate the SBB instruction correctly. @mizapf said something some time ago about the subtraction instruction and the carry flag. ISTR that it was always(?) set because how the microcode performed the operation. Maybe he will be along shortly to clarify. ...lee 1 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.