REA CART done

[RXB]

How about a direct compilation of a simple XB program into GPL? I offer because I already have that prepared here.

 

GPL is /much/ faster than both BASICs. It's much SLOWER than assembly. Many early cartridges are written in GPL, like Zero Zap, A-Maze-Ing, and such - so you have seen the speed of GPL. GPL does tend to be more compact than assembly but it does have a limitation, it needs GROM to execute out of. That was why I made the GPL chip a year ago.

 

Here's my example file. I wrote a tool to convert so this is a machine conversion, but as such it gives a nice 1:1 relationship. This is the configuration tool for my MPD project. (One note: I needed to write to GROM, which XB can't do, so I also snuck in the ability to drop MOVE commands in XB comments ).

 

example.zip

 

An excerpt:

 

*470 GOSUB 1450
 1AA7: CALL G@L1450
* 06,00,00,

*480 CALL KEY(0,K,S)
 1AAA: ST @>8374,>00
 1AAD: SCAN
*490 IF S=0 THEN 480
 1AAE: BR G@L480
* Mapping 'k' to >8375
* BE,74,00,03,40,00,

*500 CALL HCHAR(24,1,32,32)
 1AB0: FMT
 1AB1:   COL 1
 1AB3:   ROW 24
 1AB5:   HCHAR 32,32
 1AB7: ENDFMT
* 08,FF,00,FE,17,5F,20,FB,

*510 IF K=48 THEN 1010
 1AB8: CEQ @>8375,>30
 1ABB: BS G@L1010
* D6,75,30,60,00,

 

It's a little messy, as it's the raw output of my converter, but it shows the XB statement, the GPL it was converted to, and after each block, the raw bytecode of the GPL.

 

 

Whoa that is very cool. Very impressive work. I guess I can post some videos of using GPL and how to run the GPL Assembler and even the GPL Linker for those that would like to make GPL programs that run in the

AMS or regular memory.

[RXB]

GPL is one of the 'last great mysteries' of the 4A for me. It's the one thing (now) that I have not touched.

 

Rich, you could be guilty here of starting a GPL renaissance!

 

For the record, I do agree that assembly on the 9900 is indeed a memory hog. It's biggest problem? The minimum instruction size is two bytes.

 

We have 32K of ram, but you only actually have 16K of program space, as fas as I'm concerned. Contrast this with processors such as the Z80 and the 6502, and even modern Intel processors, which have byte oriented instructions. You get more code space with those processors.

 

GPL on the other hand is a byte oriented, virtual machine. You get much more bang for your byte in GPL than you do with assembly. Of course, you are running in a VM, so your performance will suffer, but it should still turn a reasonable speed.

 

I tell you want I would like to see in GPL? A conversion of a simple TI BASIC program. Let's say a program to bounce an asterisk around the screen? Then we will compare TI Basic with GPL and see the difference in speed? My hunch is that a 'raw GPL' (i.e. one that does not go back and forth into the TI BASIC interpreter) will be much faster than the TI BASIC program.

 

Heck, just the fact that GPL is VM is as cool as hell, and makes me want to play with it!

 

This kind of re-asserts what I was saying the other day. The little 4A, launched in 1981 was way way way more sophisticated than ANY of it's contemporaries. By a massive margin.

 

Changing the subject a little: The word is, that GPL was actually going to be executed by a custom GPL processor. Imagine that! How fast would that have been?

 

Anyway, I would like to see the GPL code for this program, and also a video of it compiling and running, with no CPU overdrive.

 

5 CALL CLEAR
10 X=5
20 Y=9
30 XD=1
40 YD=1
50 CALL HCHAR(Y,X,42)
60 X=X+XD
70 Y=Y+YD
80 IF X>32 THEN 130
90 IF X<1 THEN 160
100 IF Y>24 THEN 190
110 IF Y<1 THEN 220
120 GOTO 50
130 X=32
140 XD=-XD
150 GOTO 50
160 X=1
170 XD=-XD
180 GOTO 50
190 Y=24
200 YD=-YD
210 GOTO 50
220 Y=1
230 YD=-YD
240 GOTO 50

 

Mark

 

This program you wrote is specifically special to Basic or XB. I mean the XD=-XD switches a -1 to a +1 and back. The same for the YD=-YD. Also you have Y and X backwards as X is normally row and Y is normally Column. If the purpose was to give me fits it worked. Also as Assembly and GPL both start rows with 0 and not 1 then there is no number under 0 as that is the smallest column or row number possible in Assembly or GPL. So when writing the GPL program there is one number less then 0 as it just goes back to >FF which is 255 in decimal.

 

Really any program you write in BASIC or XB is already using and running under GPL. If you want a speed test I can make one.

[Willsy]

Wow! That was actually quite fast. I don't think TF would be much/any faster than that, which is kind of what I expect, as both TurboForth and GPL are virtual machines, running essentially token-threaded code.

 

 

I just tried this in TurboForth:

 

6 VALUE X  10 VALUE Y  1 VALUE XD  1 VALUE YD
: BOUNCE 
 1 GMODE ( select 32 column mode)
 BEGIN
   Y X 42 1 HCHAR
   XD +TO X
   YD +TO Y
   X 31 = IF XD NEGATE TO XD THEN
   X   0= IF XD NEGATE TO XD THEN
   Y 23 = IF YD NEGATE TO YD THEN
   Y   0= IF YD NEGATE TO YD THEN
 AGAIN ;

 

If you wanted to calculate the screen address as you did in your GPL, you could do it like this: (remove the HCHAR line and replace with)

42 Y 5 << X + V!

 

They look pretty evenly matched. TF possibly just has the edge, but there's not much in it. The main advantage is that you don't need edit, write code, save code, load compiler, compile, load loader, load, test cycle. Just type your code in...

Edited April 14, 2011 by Willsy

[Willsy]

Whoa that is very cool. Very impressive work. I guess I can post some videos of using GPL and how to run the GPL Assembler and even the GPL Linker for those that would like to make GPL programs that run in the

AMS or regular memory.

 

Hell yeah! Bring it on!

[Willsy]

This program you wrote is specifically special to Basic or XB. I mean the XD=-XD switches a -1 to a +1 and back.

So? What's special about that? It's just doing an inversion (1's complement). There's nothing special about a NEG instruction!

 

Also you have Y and X backwards as X is normally row and Y is normally Column.

Eh? Y indexes up/down the screen, X indexes across. Always has, always will!

 

(y*32)+x=the screen address to write to.

 

Also as Assembly and GPL both start rows with 0 and not 1 then there is no number under 0 as that is the smallest column or row number possible in Assembly or GPL.

Sure. It doesn't affect the design of the program though. It just means the start values are different

Edited April 14, 2011 by Willsy

[+Vorticon]

Marry the two of them and you get great apps. RXB is Assembly and GPL.

Point taken. Now the dreaded question: how does one mix GPL and assembly into a single program since GPL is interpreted and assembly is compiled?

 

GPL is compiled and interpeted. When I compiled RXB or REA or any other cart it is a compiled program, but when I run it the OS interpetes the complied code and from there GPL can load Assembly and run it.

 

Examples are CALL LOAD, CALL LINK and many other RXB routines. GRAMPACKER was a program that puts Assembly into GROMs and runs them. None of this stuff is hard to do or that complicated.

 

When you do a CALL INIT from XB or BASIC using a EA cart you are loading Assembly from GPL. About 1/5th of all routines you run in XB are actually run from the GPL calling Assembly in the ROMs.

 

Actually the main reason XB is so slow is the total lack of VDP memory and the insane number of times the Garbage collection is needed to clean up the mess.

When you see XB pause for a second while using it, that is the Garbage collection trying to get more VDP memory that is used for Strings, numbers, Files, Variables, and copies of stuff. 16K is dinky really.

OK I get it now. This certainly holds a lot of promise, at least for me. Thanks for the explanations

[+Vorticon]

 

They look pretty evenly matched. TF possibly just has the edge, but there's not much in it. The main advantage is that you don't need edit, write code, save code, load compiler, compile, load loader, load, test cycle. Just type your code in...

Talk about a dilemma here! To be perfectly honest, it seems to me that GPL would be easier to master for someone who already knows AL than TF. However, the involved development cycle you mentioned is certainly a pain, possibly enough to offset the TF learning curve.

 

Sooo, here's what I'm going to do:

Get familiar with GPL while waiting for your TF book to come out, and THEN dive into TF

[lucien2]

From my testing over the years I would rank speed on the TI as Assembly, Forth, C99, and GPL. But on emulators GPL runs just as fast as C, Forth or another other language as the Hardware delays are not needed.

Which hardware delays?

I did this speed test a few weeks ago with workspace registers in scrath PAD or in RAM extension. Both Classic99 and MESS show a significantly difference.

 

 

 

* EA5
       COPY "DSK1.EA5-1"
       B    @START
* EA3
*      DEF  START
*      REF  GPLLNK
 
       COPY "DSK1.LIB"
 
RAMEXT BSS  32
RAMPAD EQU  >8300
S1     BYTE 19
       TEXT 'RAM EXTENSION TICKS'
S2     BYTE 17
       TEXT 'SCRATCH PAD TICKS'
 
 
START  MOV  R11,@SAVRTN
       LWPI RAMEXT
       BL   @INIT
 
       LWPI RAMPAD
       LI   R0,S2
       BL   @PRINT
       BL   @SPEED
       BL   @INTSTR
       LI   R0,INTST0
       BL   @PRINT
 
       LWPI RAMEXT
       LI   R0,S1
       BL   @PRINT
       BL   @SPEED
       BL   @INTSTR
       LI   R0,INTST0
       BL   @PRINT
 
 
L1     BLWP @KSCAN
       MOV  @STATUS,R0
       ANDI R0,>2000
       JEQ  L1
 
       MOV  @SAVRTN,R11
       CLR  @STATUS
       RT
 
 
SPEED  CLR  @TIMER
       LI   R3,>FFFF
L2     MPY  R0,R1
       AI   R0,10
       LIMI 2
       LIMI 0
       DEC  R3
       JNE  L2
       MOV  @TIMER,R0
       RT
 
 
DEPLMT RT
 
* EA5
       COPY "DSK1.EA5-2"
 
       COPY "DSK1.MEMLIB"
 
* EA5
       COPY "DSK1.EA5-3"
       END

 

Edited October 9, 2016 by lucien2

[Tursi]

I've noted before that Classic99 does emulate the hardware delays, and will be getting the GROM holds too, once CPU hold is working right. But reading GROM is a very small part of the GPL interpreter.

 

That said, Mark, TF is clearly faster than GPL, I've worked with it enough to say. GPL is a complex byte code with lots of addressing modes, and requires a lot more parsing than TF does. It also has a number of inefficiencies in the interpreter in the ROM that slow it down slightly (some deliberate, it looks like parts of it was written assuming that GROMs need explicit delays like the VDP was supposed to). It's not bad by any means, and it can approach assembly speed if well written.

 

On the other hand, it's not a high level language, either. It is one half step above assembly. The only thing it makes easier for you is the hardware access is mostly abstracted. You still do most of your work by directly accessing memory addresses (though the FMT command is interesting!) It's primary advantage, as has been said over and over, is it's much more compact than assembly, because it can indicate addressing modes in a couple of bits, and access the different types of memory rather transparently.

 

Working in it the last couple of weeks has been interesting. There are some things I like, some things I don't. The one thing that bugs me is that the regular addressing modes don't recognize GROM, only CPU memory and VDP memory - it almost seems like an afterthought! The only way to read or write GROM is using the MOVE instruction, which has a whole bunch of flags that override the normal addressing modes. (MOVE is also the only way to write to the VDP registers).

 

The other gotcha I've hit in GPL is that you CAN NOT do direct hardware access to the VDP or GROMs to try and get around the limitations or boost performance. This is because the VDP interrupt runs at any time during your execution (though I suppose you could turn that off in the VDP register, then you could hit it directly), and of course GPL executes from the GROM so the GROM address is constantly changing. MOVE is probably going to be faster than anything coded distinctly in GPL anyway.

Edited April 14, 2011 by Tursi

[Willsy]

Tursi,

 

With reference to the little bounce program above in GPL, are you saying that on real hardware it would run slower than Classic99, due to the fact that Classic99 does not currently simulate the memory access delays associated with GROM access?

 

Phew, that was a long sentence wasn't it!

 

Even if the above answer is yes, I'm still very interested in GPL!

 

I wonder if the GPL GROMS have ever been disassembled? I know the ROMS were, in TI Intern...

 

[quick check]

 

Oh, yes! It's all there in TI Intern. Wow!

[RXB]

Anyway, I would like to see the GPL code for this program, and also a video of it compiling and running, with no CPU overdrive.

 

Voilà!

 

I used words for my variables, I don't know if it is better than bytes.

I had to put the variables on CPU RAM, I don't know how to address the RAM extension (I try to locate them at >2000, but got a "gas error" ).

 

http://www.youtube.com/watch?v=fUmZFKGz2FU

 

 

  	GROM >E000
* GROM HEADER
  	BYTE >AA,>01,>01,>00
  	DATA >0000 * POWER UP
  	DATA MENU
  	DATA >0000 * DSRS
  	DATA >0000 * SUBROUTINES
  	DATA >0000,>0000
MENU   BYTE >00,>00
  	DATA START
  	STRI 'BOUNCING *'

* MAIN
X      EQU  >8318
Y      EQU  >831A
XD 	EQU  >831C
YD 	EQU  >831E
POS    EQU  >8320

START  BACK >1C
  	DST  >1C1C,V@>384
  	DST  4,@X
  	DST  8,@Y
  	DST  1,@XD
  	DST  1,@YD

L1 	DST  @Y,@POS
  	DSLL 5,@POS
  	DADD @X,@POS
  	ST   42,V@0(@POS)
  	DADD @XD,@X
  	DADD @YD,@Y
  	DCGT 31,@X
  	BS   L2
  	DCGE 0,@X
  	BR   L3
  	DCGT 23,@Y
  	BS   L4
  	DCGE 0,@Y
  	BR   L5
  	B    L1
L2 	DST  31,@X
  	DNEG @XD
  	B    L1
L3 	DST  0,@X
  	DNEG @XD
  	B    L1
L4 	DST  23,@Y
  	DNEG @YD
  	B    L1
L5 	DST  0,@Y
  	DNEG @YD
  	B    L1

  	END

 

 

I was attempting to duplicat the BASIC program to much why my version was unsuccessful. Also was more concerned about getting the GPLHOW2 files and video out there.

 

Now that GPLHOW2C is out there I will work on making more involved ones that are more useful. Like addtions to Basic or small utilities.

[Tursi]

With reference to the little bounce program above in GPL, are you saying that on real hardware it would run slower than Classic99, due to the fact that Classic99 does not currently simulate the memory access delays associated with GROM access?

 

I doubt you'd see the difference. The actual GROM access is less than 5% of the time spent in the GPL interpreter on average. For most programs I'd say it's probably close to 2%. I did a bunch of measurements on the GPL interpreter a couple of weeks ago (which I posted) about the speed of GROMs, and although a single memory access to GROM is quite slow, even a tight read loop sees far less impact than you'd expect. My simulated GROMs running at better than twice the speed of the real GROMs (and with the console accepting and responding to the faster speed) made no noticable difference in TI BASIC whatsoever. I would expect BASIC to show a greater difference than a small GPL program due to the larger number of GPL instructions being executed.

 

So the short answer is yes, but not measurably.

[+Vorticon]

OK I have a really dumb question, but please bear in mind that my architectural knowledge of the TI hardware is pretty basic:

I figured out how to make REA work under Classic 99. Now, what is needed to get it working on a real TI? I assume a cart will have to be made with an REA Eprom, but are there any other hardware requirements?

[Willsy]

I think you need some GRAM of some sort: A gramkracker, a HSGPL or something like that. I'd like to see a plug-in cart with 512K GRAM and say 32 or 64K of paged flash.

Edited April 21, 2011 by Willsy

[+Vorticon]

I think you need some GRAM of some sort: A gramkracker, a HSGPL or something like that. I'd like to see a plug-in cart with 512K GRAM and say 32 or 64K of paged flash.

So basically any GPL programs I produce in the future will have to be emulator only... Bummer.

[lucien2]

I think you need some GRAM of some sort: A gramkracker, a HSGPL or something like that. I'd like to see a plug-in cart with 512K GRAM and say 32 or 64K of paged flash.

So basically any GPL programs I produce in the future will have to be emulator only... Bummer.

 

The linker generates a standard EA5 program.

[RXB]

I think you need some GRAM of some sort: A gramkracker, a HSGPL or something like that. I'd like to see a plug-in cart with 512K GRAM and say 32 or 64K of paged flash.

So basically any GPL programs I produce in the future will have to be emulator only... Bummer.

 

The linker generates a standard EA5 program.

 

Yea but the the Linker is really lame. You can only make programs with limited abilites.

And as they run from VDP with a extra front end they are slower.

Not to mention you can only use >6000 to >C000 as the linker resides at >E000

So you go from 40K in GROM to 32K and you can not do XB or other large cartridges.

Also the linker will not allow testing of GROM 0,1,2, or 7.

[marc.hull]

I think you need some GRAM of some sort: A gramkracker, a HSGPL or something like that. I'd like to see a plug-in cart with 512K GRAM and say 32 or 64K of paged flash.

So basically any GPL programs I produce in the future will have to be emulator only... Bummer.

 

The linker generates a standard EA5 program.

 

This is starting to resemble a Monty Python sketch.... If the Linker generates an EA5 executable from GPL then what the hell is the GPL code for other than to be translated into object code? It must be obvious ??

[Willsy]

I don't think it produces ea5 code, does it? If you watch Rich's videos he is clearly using a "compressed GPL object code loader" (the one with a cyan screen).

 

If it were an ea5 then one would assume it contained an assembly stub to poke a self-contained GPL payload into GRAM. But I saw no evidence/mention of this.

[lucien2]

I think you need some GRAM of some sort: A gramkracker, a HSGPL or something like that. I'd like to see a plug-in cart with 512K GRAM and say 32 or 64K of paged flash.

So basically any GPL programs I produce in the future will have to be emulator only... Bummer.

 

The linker generates a standard EA5 program.

 

This is starting to resemble a Monty Python sketch.... If the Linker generates an EA5 executable from GPL then what the hell is the GPL code for other than to be translated into object code? It must be obvious ??

 

I like GPL because the source is more compact than assembly and you can use routines from GROMs easily.

 

I was just disappointed that you can't access the RAM extension.

 

Here is the BOUCING* example in EA5 format. BOUNCING EA5.zip

[Tursi]

I think you need some GRAM of some sort: A gramkracker, a HSGPL or something like that. I'd like to see a plug-in cart with 512K GRAM and say 32 or 64K of paged flash.

 

Allow me to link to my GROM simulator that anyone is free to use in their own cartridges: http://www.harmlesslion.com/software/simulator

 

It runs on any Atmel AVR, from the tiny 2k chips up to the big-ass 128k chips. It does require you to build the code to target your application, though that's pretty simple. Also, the GROM sim code itself is very simple and would easily port to any other microcontroller.

 

The cart in the photo on that page, if we get it working, supports up to 128k of GROM and 512k of paged Flash.

 

So if you do produce a GPL program and want to put it on cart, all the pieces are available, you just have to put them together.

[Willsy]

I think you need some GRAM of some sort: A gramkracker, a HSGPL or something like that. I'd like to see a plug-in cart with 512K GRAM and say 32 or 64K of paged flash.

 

Allow me to link to my GROM simulator that anyone is free to use in their own cartridges: http://www.harmlesslion.com/software/simulator

 

It runs on any Atmel AVR, from the tiny 2k chips up to the big-ass 128k chips. It does require you to build the code to target your application, though that's pretty simple. Also, the GROM sim code itself is very simple and would easily port to any other microcontroller.

 

The cart in the photo on that page, if we get it working, supports up to 128k of GROM and 512k of paged Flash.

 

So if you do produce a GPL program and want to put it on cart, all the pieces are available, you just have to put them together.

 

Tursi

 

There's a picture of a cart board on that page. Did you get the board made up?

 

Mark

[Tursi]

There's a picture of a cart board on that page. Did you get the board made up?

 

Jim is responsible for that beauty, he has made a few, but there's a problem with the flash chip that needs to be solved before it can be released.

 

For just the GROM chips, it's trivial to route a board. You don't need any interface components, it's a glueless connection (pin-to-pin, just like an EPROM). Just needs a capacitor on the power lines to smooth the switching.

[RXB]

REA TI BASIC is done. Here is the package and this time has the GRAM files to load already to use. @README@ explains what all the files are for and I also included the failed AMS support that for some reason will not work even though the same exact routines work in the REA Module and RXB.

 

The zip file REABASIC has all source code, object code and listings. Also the GPL Assembler, Loader, and Save GRAM files.

 

REABASIC.zip

[+OLD CS1]

GPL could have been Java before Java was Java. Kinda.

 

But what piques my curiosity is, why could GPL only be run from GROM? Is it simply a limitation set in the GPL interpreter, or is there some real hardware reason?