marc.hull Posted July 24, 2011 Share Posted July 24, 2011 Yes and you have another step with CSAVE to create GRAM Module Files. But once that is done you can have a Module always set up and run permanently. That is something that Assembly or Forth could never do. Be instantly up and running from menu screen even if the computer is turned off and on. That more then pays for the trouble. If not for Cartidges and that Slot there would be no TurboForth cart. By the way I need to order one. Hmmmm... every time I turn on my TI I am instantly greeted with "Menu" (assembly program) and can select 24 assembly or XBASIC program to run instantly at the touch of a button. No loading required (on my part anyway.) And where does this reside? Afraid you missed my point. The TI was built to access 640K of GROM from the cartridge slot in 1979. This was just the console and nothing else. Really what can you do with 8K Cartridge RAM and just a console? (Answer: Sell cartriges like hot cakes just like TI did. Hottest item they sold, and attempted to shut down others that created them.) I fully understand things change but give credit to what made this possible. When the TI99 was introduced it was the GROM slot that sold the machine not the DISK programs or TAPE programs. Later DISK and TAPE took off. Everyone started with EA/MM/XB/LOGO/PASCAL or the Basic built in. All of these are GPL. Just please give credit instead of dissing GROM. All of these hacks copy what GPL does right out of the box since it was introduced. Nobody is dissing GROM. Just pointing out a bit of evidence that contradicts your wildly inaccurate statement. All computers of this era had cartridge ports so I don't understand why this attribute "makes the computer." I understand your affinity to GPL and I think it's great. But when you make silly arguments as to why it is the end all and be all of the TI then you really just hurt your own cause. As far as Turbo Forth is concerned. I may be wrong but I don't think it contains much GPL or GROM. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted July 24, 2011 Author Share Posted July 24, 2011 (edited) Nobody is dissing GROM. Just pointing out a bit of evidence that contradicts your wildly inaccurate statement. I understand your affinity to GPL and I think it's great. But when you make silly arguments as to why it is the end all and be all of the TI then you really just hurt your own cause. True. Edited July 24, 2011 by sometimes99er Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted July 24, 2011 Share Posted July 24, 2011 (edited) True, the cartridge port will support up to 16 GROM bases (BTW, this was reduced to four on the 99/8 ). In 1979 it would not have been possible to do so, however, as the console port could not power that many GROMs. An external device would have been necessary, and TI even made them--Jon has a pair of the CEC 9914 devices shown here: CEC 9914 Pic and I own one modified to run the Plato module. These didn't use the GROM port though, they connected to the side. TI made other devices though--the EGROM box did connect to the cart port, but it only simulated one cartridge (I have two different versions of these). The GSIM also used the cart port, and it could do more than one GROM base (I have one of these). The Almelo PEB GRAM card also connected a cable to the cart port, and was also capable of more than one GROM base (I don't have one of these). The Mechatronics GRAM Karte is related to it, though very different in implementation (I have one of these). I also have a GRAMulator, PGRAM+, GRAM Kracker, and both versions of the Wiesbaden Modul. All are good GRAM devices--but the key with these and all such devices is that none of them were sold while TI was still selling computers. They also never sold their EGROM cartridges (though a lot of folks will find one of the boards in various prototype cartridges in their possession--I have several and one sold on E-Bay last year as an unknown cartridge). TI did use the cartridge port extensively--they sold many cartridges that maxed out a single GROM base and also cartridges using up to 4 ROM banks (TI Calc). They tried to force third-party developers into their arms by introducing the V2.2 OS--and failed because too many machines were already in consumer hands without it. GROM was the ultimate hardware dongle of its day. You couldn't duplicate the chips, and not enough information on GPL was in consumer hands to trick the computer into running the program from main memory instead. That changed after TI dropped out of the market--and allowed a lot of people to push GPL and the cartridge port to their limits. I'm really glad for that. It is also why I wanted to include a GROM emulation on the most recent cartridge boards--I wanted to make sure that the fantastic GROM-based software made by TI and now many others could be run by the folks who still live in console-only land, or who prefer to insert the cartridge and go. I'm really glad Tursi thought enough of the idea to write the code for the AVR to do it--and that Matt let me use his 6-input latch for the bank switching to extend the board out to a single 512K space (and even TI had provisions for (and used extensively) bank switching for their ROM side). Jon did a lot of hard work here too--and for that I thank him! Why do I note all of this? The board will allow a LOT of space for additional programming in the TI cartridge port space. Rich might just find a way to expand the GPL space for RXB to fill all three GROM bases (120K)--and fill the 512K of assembly space too. Now that would be an Extended BASIC (maybe with a built-in compiler?)! Edited July 24, 2011 by Ksarul Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted July 24, 2011 Author Share Posted July 24, 2011 The syntax for GPL is very much like XB. I think the syntax looks more like Assembler. Quote Link to comment Share on other sites More sharing options...
matthew180 Posted July 24, 2011 Share Posted July 24, 2011 I would also like to point out that TI crippled (like everything else on the 99/4A) the GROM capacity by making the console GROMs respond to the first three GROM addresses at EVERY GROM port. So that leaves you with only 5 GROM addresses at each port (can't remember how many of those there are.) Actually, I'd go out on a limb and say that, probably, every GROM TI made does not honor or decode the different GROM ports, so if you are using TI's GROM chips, you only have 8 GROMs available. Also, you can't use two at the same time like XB and the E/A. It's just dumb. The primary purpose of GROM was DRM and NOT some clever memory expansion. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 24, 2011 Share Posted July 24, 2011 I would also like to point out that TI crippled (like everything else on the 99/4A) the GROM capacity by making the console GROMs respond to the first three GROM addresses at EVERY GROM port. So that leaves you with only 5 GROM addresses at each port (can't remember how many of those there are.) Actually, I'd go out on a limb and say that, probably, every GROM TI made does not honor or decode the different GROM ports, so if you are using TI's GROM chips, you only have 8 GROMs available. Also, you can't use two at the same time like XB and the E/A. It's just dumb. The primary purpose of GROM was DRM and NOT some clever memory expansion. The GROMs themselves can not decode the GROM base, that is done by sampling the address lines (which are not even routed to the GROM chips). So it doesn't matter whose GROMs you use, it only matters how you wire them up. To use two real GROMs at different bases, you need to introduce a circuit to detect the bases and activate the correct chip. The console GROMs do respond at any base (as do most cartridges), because they don't differentiate the address lines. There are 16 GROM bases sampled by the console, and room for up to 256 bases in the 99/4A memory map. The cart that Jon, Jim and I came up with supports 16 bases. Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 24, 2011 Share Posted July 24, 2011 Interesting stuff.. this is almost starting to read like GPL vs Turboforth trash talk :-) Question is could you write GPL in TurboForth! I believe you could, yes. Though, in fairness to GPL, you could also write a Forth in GPL! 1 Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 24, 2011 Share Posted July 24, 2011 (edited) Yes and you have another step with CSAVE to create GRAM Module Files. But once that is done you can have a Module always set up and run permanently. That is something that Assembly or Forth could never do. Be instantly up and running from menu screen even if the computer is turned off and on. That more then pays for the trouble. If not for Cartidges and that Slot there would be no TurboForth cart. By the way I need to order one. Hmmmm... every time I turn on my TI I am instantly greeted with "Menu" (assembly program) and can select 24 assembly or XBASIC program to run instantly at the touch of a button. No loading required (on my part anyway.) And where does this reside? Afraid you missed my point. The TI was built to access 640K of GROM from the cartridge slot in 1979. This was just the console and nothing else. Really what can you do with 8K Cartridge RAM and just a console? (Answer: Sell cartriges like hot cakes just like TI did. Hottest item they sold, and attempted to shut down others that created them.) I fully understand things change but give credit to what made this possible. When the TI99 was introduced it was the GROM slot that sold the machine not the DISK programs or TAPE programs. Later DISK and TAPE took off. Everyone started with EA/MM/XB/LOGO/PASCAL or the Basic built in. All of these are GPL. Just please give credit instead of dissing GROM. All of these hacks copy what GPL does right out of the box since it was introduced. Nobody is dissing GROM. Just pointing out a bit of evidence that contradicts your wildly inaccurate statement. All computers of this era had cartridge ports so I don't understand why this attribute "makes the computer." I understand your affinity to GPL and I think it's great. But when you make silly arguments as to why it is the end all and be all of the TI then you really just hurt your own cause. As far as Turbo Forth is concerned. I may be wrong but I don't think it contains much GPL or GROM. No. No GROM and it only uses a single GPL call to load the upper case characters at startup! That's it! If I knew how to locate the characters in GROM then I could save some memory, as it is, I had to write a GPLLNK *just* to load the freaking characters! Edited July 24, 2011 by Willsy Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted July 24, 2011 Share Posted July 24, 2011 Thanks Tursi! Matthew, if you look at TI's early marketing flak, they started out describing GROMs as a clever memory expansion trick--unfortunately, that later evolved into the not-so-nice DRM tool as they figured out that the machine was both popular and that their GROMs provided a unique route to DRM. Now we just need to put the GPL version of Blocks into one of our AVR demos (assuming we can get permission to do so)! Quote Link to comment Share on other sites More sharing options...
RXB Posted July 24, 2011 Share Posted July 24, 2011 (edited) Sorry will repost correction. Edited July 24, 2011 by RXB Quote Link to comment Share on other sites More sharing options...
matthew180 Posted July 24, 2011 Share Posted July 24, 2011 @Tursi: Yeah, thanks for the technical details, I forget that stuff 5 minutes after I don't need to know it any more. Basically, you always lose 3 of the 8 GROMs at all the bases, plus any more GROM slots if there is a cartridge installed that has GROM. Not very useful IMO. Now, having one of our new uber-carts actually decode the address and restrict the cart GROMs from any port other than the first, now that would be useful. And, moving the system GROMs to the uber-cart would also allow the system GROM to be limited to the first port as well. Quote Link to comment Share on other sites More sharing options...
John Doe Posted July 24, 2011 Share Posted July 24, 2011 (edited) Edited February 22, 2014 by Tony Knerr Quote Link to comment Share on other sites More sharing options...
jacquesg Posted July 24, 2011 Share Posted July 24, 2011 @Tursi: Yeah, thanks for the technical details, I forget that stuff 5 minutes after I don't need to know it any more. Basically, you always lose 3 of the 8 GROMs at all the bases, plus any more GROM slots if there is a cartridge installed that has GROM. Not very useful IMO. Now, having one of our new uber-carts actually decode the address and restrict the cart GROMs from any port other than the first, now that would be useful. And, moving the system GROMs to the uber-cart would also allow the system GROM to be limited to the first port as well. I have a HSGPL card on my TI-99/4A and I have installed Art Green's Multiplan on bank 4. On this bank I no longer have access to TI-Basic because Art placed MPBASE in Grom 1 and MPDATA in Grom 2. Winfried Winkler's Grom0 is also installed and when I select bank 4 all that shows is 1 - MULTIPLAN. This seems to indicate that perhaps the first 3 GROMs can be used in some circumstance. At least this is the case with a HSGPL card. Of course, any inserted cartridge over-rides the bank selections available with a HSGPL card. Jacques Quote Link to comment Share on other sites More sharing options...
RXB Posted July 24, 2011 Share Posted July 24, 2011 Ok here is the code and video that Lucien2 wrote for GPL. Do not know why I could not copy it so had to type it in. GROM >C000 DATA >AA00,>0100,>0000 DATA MENU DATA >0000,>0000,>0000 MENU DATA >0000 DATA START STRI 'BRICKS' RND EQU >8378 P1 DATA >0000,>C0C0,>3F3F,>FFFF P2 DATA >0000,>0000,>0000 DATA >C0C0,>C0C0,>C0C0 P3 DATA >0000,>0000,>0000,>3F7F DATA >0103,>0303,>0303,>FFFF COL BYTE >10,>23,>45,>68 BYTE >89,>AB,>C2,>EF A EQU >8300 B EQU >8301 IH EQU >8302 IL EQU >8303 VIH EQU >8304 VIL EQU >8305 R EQU >8306 C EQU >8307 GH EQU >8308 GL EQU >8309 START ALL 32 BACK 13 * SHADOW PATTERNS CLR @A * A=0 CLR @B * B=0 CLR @IH * IH=0 CLR @VIH * VIH=0 L1 ST @B,@VIL * VIL=B SLL 2,@VIL * VIL*4 ADD @A,@VIL * VIL=VIL+A SLL 3,@VIL * VIL*8 ST @A,@IL * IL=A SLL 1,@IL * IL*2 MOVE 2,G@P1(@IH),V@>900(@VIH) INCT @VIL * VIL+2 ST @B,@IH * IH=B MUL 6,@IH * IH*6 MOVE 6,G@P2(@IH),V@>900(@VIH) INC @A * A+1 CGE 4,@A * A>=4? BR L1 * NO, GOTO L1 CLR @A * A=0 INC @B * B=B+1 CGE 2,@B * B>=2? BR L1 * NO, GOTO L1 * BRICK PATTERNS DCLR @IH * IH:IL=0 L2 MOVE 16,G@P3,V@>940(@IH) DADD 64,@IH * IH:IL=IH:IL+64 DCGE 7*64,@IH * IH>=448? BR L2 * NO, GOTO L2 * COLORS MOVE 8,G@COL,V@>384 * COLORS * MAIN LOOP L3 * RANDOM POSITION RAND 22 * RND=(0-22) ST @RND,@R * R=RND RAND 29 * RND=(0-29) ST @RND,@C * C=RND ST @R,@VIL * VIL=R CLR @VIH * VIH=0 DSLL 5,@VIH * VIH*32 DADD @C,@VIL * VIL=C * IS IT FREE? DST V*VIH,@GH * GH=VDP AT VIH:VIL ADDRESS CGT 39,@GH * GH>39? BS L3 * YES, GOTO L3 CGT 39,@GL * GL>39? BS L3 * YES, GOTO L3 * DRAW BRICK RAND 6 * RND=(0-6) ST @RND,@IL * IL=RND SLL 3,@IL * IL*8 ADD 40,@IL * IL+40 ST @IL,V*VIH * IL=VDP AT VIH ADDRESS INC @IL * IL+1 DINC @VIH * VIH:VIL+1 ST @IL,V*VIH * IL=VDP AT VIH ADDRESS * DRAW SHADOWS DINC @VIH * VIH:VIL+1 ST 4,@A * A=4 CALL SHADOW * GOSUB SHADOW DADD 30,@VIH * VIH:VIL+30 ST 2,@A * A=2 CALL SHADOW * GOSUB SHADOW DINC @VIH * VIH:VIL+1 ST 3,@A * A=3 CALL SHADOW * GOSUB SHADOW DINC @VIH * VIH:VIL+1 ST 1,@A * A=1 CALL SHADOW * GOSUB SHADOW B L3 * GOTO L3 * END MAIN LOOP * DRAW SHADOW SHADOW ST V*VIH,@GL * GL=VDP AT VIH ADDRESS CGT 38,@GL * GL>32? BS SHAD00 * YES, GOTO SHAD00 OR @A,@GL * OR BITS A INTO GL ST @GL,V*VIH * GL=VDP AT VIH ADDRESS SHAD00 RTN END Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 24, 2011 Share Posted July 24, 2011 No. No GROM and it only uses a single GPL call to load the upper case characters at startup! That's it! If I knew how to locate the characters in GROM then I could save some memory, as it is, I had to write a GPLLNK *just* to load the freaking characters! I actually wrote this code for the first version of the multicart, and you're free to reuse it. It parses the GPL vectors to find the actual character data in GROM and loads it directly, no GPLLNK needed. It does assume that the starting address IS a vector, but works on all three main revisions of the 99/4 and 99/4A GROMs. **************************** * Load lower case charsets * **************************** * Note, if you still need space, you can remove support for the * 99/4 by deleting the code marked between * +++ 99/4 support +++ begin/end blocks * NOTE!! Workspace must be >8300 before entering. GOGO MOV R11,R9 * Save our return spot * +++ 99/4 support begin +++ * load R3 with 6 for 99/4, or 7 for 99/4A * the TI way (XB) to do this is to call SCAN with mode 5 - * the 99/4A will change the mode to 0. * many programs assume the keyboard mode was set up anyway LI R3,7 LI R0,>0500 MOVB R0,@>8374 LWPI >83E0 BL @>000E LWPI >8300 MOVB @>8374,R0 JEQ IS4A DEC R3 * make a copy of the capitals for the 99/4 to 'support' lowercase * this will be partially overwritten by the main set, but it works! LI R0,>0018 * GPL vector address LI R1,>4A00 * dest in VDP - must OR with >4000 for write LI R2,>0040 * how many chars BL @GPLVDP * this function goes somewhere later in your ROM JMP MNSET * +++ 99/4 support end +++ * If you delete the above block, replace with * LI R3,7 * so that the character size counter is still valid IS4A * 'lowercase' letters LI R0,>004A * GPL vector address (not available for 99/4) LI R1,>4B00 * dest in VDP - must OR with >4000 for write LI R2,>001F * how many chars BL @GPLVDP * this function goes somewhere later in your ROM * main set MNSET LI R0,>0018 * GPL vector address LI R1,>4900 * dest in VDP - must OR with >4000 for write LI R2,>0040 * how many chars BL @GPLVDP * this function goes somewhere later in your ROM B *R9 * RETURN TO CALLER ***************** * GROM routines * ***************** * Set GROM address GPLSET MOVB R0,@>9C02 SWPB R0 MOVB R0,@>9C02 B *R11 * Get a word from GPL GETGPL MOVB @>9800,R0 SWPB R0 MOVB @>9800,R0 SWPB R0 B *R11 * Copy R2 characters from a GPL copy function vectored at * R0 to VDP R1. GPL vector must be a B or BR and * the first actual instruction must be a DEST with an * immediate operand. Set R3 to 6 for 99/4 (6 byte characters) * or 7 for a 99/4A (7 byte characters) GPLVDP MOV R11,R10 * save return address BL @GPLSET * set GROM address BL @GETGPL * Get branch instruction (not verified!) ANDI R0,>1FFF * mask out instruction part AI R0,3 * skip instruction and destination BL @GPLSET * set new GROM address BL @GETGPL * get actual address of the table BL @GPLSET * and set that GROM address - GROM is now ready! SWPB R1 * assume VDP is already prepared for write to save space MOVB R1,@>8C02 SWPB R1 MOVB R1,@>8C02 * VDP is now ready! CLR R0 LP8 MOVB R0,@>8C00 * pad the top of the char with a space MOV R3,R0 * then copy 7 (or 6) bytes * +++ 99/4 support begin +++ CI R3,6 * check for 99/4 JNE LP9 MOVB R0,@>8C00 * extra blank line for 99/4 * +++ 99/4 support end +++ * no changes needed if this block removed LP9 MOVB @>9800,@>8C00 * copy a byte (both sides autoincrement) DEC R0 JNE LP9 DEC R2 * next character JNE LP8 B *R10 NEXT END To call it, just BL @GOGO. It uses a lot of registers so it's helpful to do it early in your program, or save off the important ones. It also changes the GROM and VDP addresses (obviously). The character set is loaded at >0800 as per the E/A environment. This is set (with offsets) at lines 32, 45 and 52. On a 99/4 which doesn't have lowercase characters, it will load two copies of the uppercase character set. You can also remove the 99/4 support to save a little code space (since it has to auto-detect the machine and do a little extra padding for the smaller characters). Those areas are marked. Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 24, 2011 Share Posted July 24, 2011 @Tursi: Yeah, thanks for the technical details, I forget that stuff 5 minutes after I don't need to know it any more. Basically, you always lose 3 of the 8 GROMs at all the bases, plus any more GROM slots if there is a cartridge installed that has GROM. Not very useful IMO. Now, having one of our new uber-carts actually decode the address and restrict the cart GROMs from any port other than the first, now that would be useful. And, moving the system GROMs to the uber-cart would also allow the system GROM to be limited to the first port as well. Why would a cartridge be worried about conflicting with other cartridges, though? You can put GROMs on the side port, yes, but for the reasons you list it's not very useful to do so, except in GRAM devices. One problem with having the system GROMs locked down to a particular base is software that expects the system GROMs to be visible at any base will break. For example, it would become impossible to call SCAN without patching the software to first fix the GROM base. It gets a little messier too, because GPL programs are generally written not to care what base they are located at - the console takes care of this. That's the whole magic behind REVIEW MODULE LIBRARY, but if you have to change the base to call console functions or access console data, then you also have to take note of which base you are at so you can restore it on return. That would all need an assembly language trampoline function to work properly (I don't think you can do it in GPL since you need to access specific data from specific GROM bases). It's not a limitation that I think is overly serious for a couple of reasons. First I've already noted - the most useful place for GROMs is in a cartridge, and a cartridge doesn't need to worry about what other cartridges are doing -- they aren't attached by definition. Second is that losing 24k of address space per base isn't a huge deal, really. Even if we say that we are restricted to 6k GROMs, that still leaves 30k of GROM space per base (40k with 8k GROMs). That's nearly as much memory as is in the 32k memory expansion. And you can have up to 256 bases on the 99/4A, giving you 7.5MB of GROM data (10MB with 8k GROMs). Yeah, it could be more, but until someone hits that limit I wouldn't be too concerned. If you /did/ hit that limit, it's trivial with a microcontroller-based emulator like the AVR to add bank-switching to the GROMs. (The multiple bases are not bank switching -- all the data is available at any time). The cartridge that we released only decodes the standard of 16 bases for a couple of reasons. The biggest reason is that I can only allocate 120k or so of the flash memory. So there's already no way to fill all the available space, even adding in the EEPROM, RAM, and I/O. 16 is a "standard" because that's how many bases the console scans... there's no other reference or hardware reason for that value. (Also, the number of I/O pins we had available in a convenient location ). I'm actually kind of glad to see the conversation swinging around from "Why do we need GROM emulation?", which is what someone was saying when I first announced this project, to "Did TI screw us on GROM support?" 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 25, 2011 Share Posted July 25, 2011 Granted, if Groms 1 & 2 were restricted to respond at only >9800, you could make the argument that you only need TI BASIC on one Grom page (page being the long-accepted term for grom port as it seems now to be renamed as). Ah, true, I didn't think about TI BASIC as reasonable to lock down. It certainly is. You could do that in any console, then, by just removing GROM 1 and 2, and dropping them in a cartridge for when you wanted TI BASIC. I wonder, would it be enough to just solder them into an E/A cart? That should work, eh? Quote Link to comment Share on other sites More sharing options...
John Doe Posted July 25, 2011 Share Posted July 25, 2011 (edited) Edited February 22, 2014 by Tony Knerr Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted July 25, 2011 Author Share Posted July 25, 2011 Now Assembly only has 16 Registers and GPL only has 256 bytes of Scratch Pad, ... Okay, so we've got Assembly in the equation/this thread. Assembly = 16 Registers GPL = 256 bytes of Scratch Pad Listing of lemons and apples. GPL has more. GPL wins ! Assembly = 256 bytes of Scratch Pad GPL = 256 bytes of Scratch Pad Could the above be true ? Looks like a draw ... Assembly = 224 bytes of Scratch Pad and 16 Registers GPL = 224 bytes of Scratch Pad Assembly has more. Assembly wins ! Assembly is the fastest language anyway. I tried and develop something in GPL and it took like forever. Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 25, 2011 Share Posted July 25, 2011 I'm really very interested in GPL and plan on having a serious go with it soon. The thing about assembly language on the TI is the TMS9900 instruction set - assembly language on the 99xx is *so easy*, that once you know it well, it really doesn't make sense to 'go backwards' into other languges. Except Forth. Sorry! But you expected me to say that, didn't you! Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 25, 2011 Share Posted July 25, 2011 I actually wrote this code for the first version of the multicart, and you're free to reuse it. It parses the GPL vectors to find the actual character data in GROM and loads it directly, no GPLLNK needed. It does assume that the starting address IS a vector, but works on all three main revisions of the 99/4 and 99/4A GROMs. Crikey mate! I reckon that takes more room than the GPLLNK routine ;[ GPLLNK ; This routine is based on the routine published in the July 1986 edition of ; Smart Programmer. Modified by yours truly to allow it be executed from ROM. gplws equ >83e0 ; GPL workspace gr4 equ gplws+8 ; GPL R4 gr6 equ gplws+12 ; GPL R6 stkpnt equ >8373 ; GPL stack pointer ldgadd equ >60 ; load and execute grom address entry point xtab27 equ >200e ; low mem XML table location 27 getstk equ >166c ; cpu register data - this data is copied into >200e onwards, so that it sits ; in R7 onwards gpllnk data glnkws ; [mapped to R7] set up BLWP vectors data glink1 ; [mapped to R8] rtnad data xmlrtn ; [mapped to R9] gxmlad data >176c ; [mapped to R10] GROM address for GPL XML 0F27 opcode data >50 ; [mapped to R11] Initialised to >50 where PUTSTK ; address resides ; this routine runs in it's own workspace, starting at >2000 glnkws equ >2000 ; GPLLNKs workspace of which only registers R7 thru R15 ; are used glink1 li r0,gpllnk ; we need to copy the cpu register data (above) to li r1,>200e ; RAM. R0=Source, R1=Destination li r2,5 ; R2=Word count gpllop mov *r0+,*r1+ ; copy the data above into r7 onwards... dec r2 ; copied all of it? jne gpllop ; loop if not mov *r11,@gr4 ; put PUTSTK address into R4 of GPL WS mov *r14+,@gr6 ; put GPL routine address in r6 of GPL WS mov r9,@xtab27 ; put XMLRTN address into >200e lwpi gplws ; load GPL workspace bl *r4 ; save current GROM address on stack mov @gxmlad,@>8302(r4) ; push GPL XML address on stack for GPL return inct @stkpnt ; adjsut the stack pointer b @ldgadd ; execute our GPL routine xmlrtn mov @getstk,r4 ; get GETSTK pointer bl *r4 ; restore GROM address off the stack lwpi glnkws ; load our ws rtwp ; all done - return to caller ;] Is there any evidence to suggest that the graphics data in GROM has ever changed location? Can I not just assume a hard-coded address? Mark Quote Link to comment Share on other sites More sharing options...
RXB Posted July 25, 2011 Share Posted July 25, 2011 Now Assembly only has 16 Registers and GPL only has 256 bytes of Scratch Pad, ... Okay, so we've got Assembly in the equation/this thread. Assembly = 16 Registers GPL = 256 bytes of Scratch Pad Listing of lemons and apples. GPL has more. GPL wins ! Assembly = 256 bytes of Scratch Pad GPL = 256 bytes of Scratch Pad Could the above be true ? Looks like a draw ... Assembly = 224 bytes of Scratch Pad and 16 Registers GPL = 224 bytes of Scratch Pad Assembly has more. Assembly wins ! Assembly is the fastest language anyway. I tried and develop something in GPL and it took like forever. What GPL does best is run Embedded Assembly. EA cart, XB cart, Mini Mem cart, and games are just a few examples. Use GPL to set up the enviorment and put stuff in place then use Assembly to do the grunt work. Each is best at a certain task. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted July 25, 2011 Author Share Posted July 25, 2011 (edited) Now Assembly only has 16 Registers and GPL only has 256 bytes of Scratch Pad, ... Okay, so we've got Assembly in the equation/this thread. Assembly = 16 Registers GPL = 256 bytes of Scratch Pad Listing of lemons and apples. GPL has more. GPL wins ! Assembly = 256 bytes of Scratch Pad GPL = 256 bytes of Scratch Pad Could the above be true ? Looks like a draw ... Assembly = 224 bytes of Scratch Pad and 16 Registers GPL = 224 bytes of Scratch Pad Assembly has more. Assembly wins ! Assembly is the fastest language anyway. I tried and develop something in GPL and it took like forever. What GPL does best is run Embedded Assembly. EA cart, XB cart, Mini Mem cart, and games are just a few examples. Use GPL to set up the enviorment and put stuff in place then use Assembly to do the grunt work. Each is best at a certain task. But we had this 18 line XB demo and this "the same program" was rewritten for different languages. You point out some differences in environments, namely 16 Registers and 256 bytes of Scratch Pad, and then continue about differences in storage and use of variables. I question your environments, "Assembly has 16 Registers and GPL has 256 bytes of Scratch Pad", not what is best at a certain task. This, what is best, is again subject to different opinions. I've used XB and Assembly since early on and this without any GPL programming. So I won't start using GPL to set up anything. Edited July 26, 2011 by sometimes99er Quote Link to comment Share on other sites More sharing options...
Willsy Posted July 25, 2011 Share Posted July 25, 2011 Given that GPL is a byte based assembly language, it expect it is possible to write much more compact programs in GPL than in assembly - the tradeoff being speed, of course. Imagine if TI *had* produced a GPL processor chip (as was the rumour?) - man, that would have been something! Mark Quote Link to comment Share on other sites More sharing options...
Tursi Posted July 26, 2011 Share Posted July 26, 2011 Is there any evidence to suggest that the graphics data in GROM has ever changed location? Can I not just assume a hard-coded address? It's in different places in each GROM set. That's why there's a vectored function in GPL to get the data from, and why I wrote this function in the first place. It probably is larger than the GPLLNK, but I never liked the idea of relinquishing control and hoping I get it back. 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.