Jump to content
IGNORED

Bricks (demo)


Recommended Posts

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.

Link to comment
Share on other sites

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 by sometimes99er
Link to comment
Share on other sites

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 by Ksarul
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

  • Like 1
Link to comment
Share on other sites

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 by Willsy
Link to comment
Share on other sites

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)!

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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?" ;)

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

 

:)

Link to comment
Share on other sites

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. :D

 

Sorry! But you expected me to say that, didn't you! :P

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by sometimes99er
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...