The quest for the GPL gate

[+retroclouds]

GPL Gate

 

ok, I've been trying to find a reliable way to call GPL routines from my spectra² library.

 

I'm starting an own thread for this, because I have a lot of questions and I'm hoping that someone with

GPL interpreter knowledge can jump in and give some hints

 

At this stage I'd rather not discuss how useful it is to call GPL from your assembly language program in cartridge ROM,

knowing that you only have 256 bytes of scratch-pad memory to your disposal.

 

Then again, the GPL interpreter stuff is very fascinating.

 

Here are some of the resources I've been using along the way:

 

1) Thierry Nouspikels website. Probably the best TI-99/4A hardcore website around if you ask me. A lot of interesting stuff.

2) The TI-Intern book by Heiner Martin. I have the paper book version. An electronic version is available here.

This manual is very, very important because it contains a GPL interpreter disassembly, as well as all ROMS and GROMS disassembled.

3) The GPL Programmers' Guide; again very important, as it's probably the best introduction to GPL. I have the printed version. The electronic version is available here.

4) classic99, my favourite emulator, sports a very good debugger.

 

After reading a lot, and a mean a lot. I've been able to hack an own GPLLNK routine **which** probably still is buggy.

It's important to know that I want this routine to work without having 32K memory expansion.

This is rather tricky as returning from GPL is kinda hard to do.

 

Before we get into the details. This is the scratch-pad memory setup I'm using.

 

 

As you can see the GPL interpreter stuff reduces available scratch-pad memory a lot.

I can still fiddle with the default location of the GPL subroutine and data stack. That would allow me to free up a few bytes of extra memory,

with the risk that I can't use GPL routines that are heavily nested. Are there any ?

 

After doing a lot of reading, I came up with the below code which is heavily inspired by Thierry's GPLLNK versions.

 

The idea is that you do a BL @GPLLNK with a following DATA statement containing the address of the GROM routine to call.

 

*//////////////////////////////////////////////////////////////
*                            GPLLNK
*//////////////////////////////////////////////////////////////
                             
***************************************************************
* GPLLNK - Gate into the GPL interpreter
***************************************************************
* BL   @GPLLNK
* DATA P0
*
* P0 = GROM address of GPL routine to call
*--------------------------------------------------------------
* Remarks
* This routine is based on a GPLLNK subroutine as published by
* Thierry Nouspikel on the website http://www.nouspikel.com/ti99
*
* It's important to know, that R0 in the main workspace (>8300)
* must contain the CPU RAM address to jump to when returning 
* from GPL. Reason is that we push the GROM address of a memory 
* location having byte sequence ">0F,>F0" on the GPL 
* subroutine stack. 
*
* For returning from GPL, the GPL interpreter will branch to that 
* address and execute GPL opcode >0F (aka the XML instruction)
* The high nibble "F" of operand ">F0" means XML table 16 which 
* is located in scratch-pad memory. 
* The low nibble "0" indicates the first entry in the XML table
* which is a vector to memory location >8300.
*
* Execution flow
* 1) GPL interpreter is started and executes the opcode fetched
*    from the high nibble of GPL workspace register R9.
*    In our case this is >00 which is handled as a RTN opcode.
* 2) GPL interpreter executes "return" statement, pops address
*    of subroutine stack and branches to that GROM address; this 
*    is the address of the routine we want to execute.
* 3) After returning from (2) the GPL interpreter branches to
*    the GROM address containing the byte sequence ">F0,>0F".
* 4) As a result an XML with vector at >8300 (our R0 in the main workspace)
*    is used and the GPL interpreter branches to our XMLRTN
*    routine and we're back in our assembly language program.
*
* BE AWARE!
* Due to multiple GROM revisions the byte sequence >0FF0 may
* be located at another GROM address.
********@*****@*********************@************************** 
GPLLNK  LI    R0,XMLRTN             ; Return address for GPL
       MOV   @WSTFLG,TMP0          ; Get SPECTRA config flags
       COC   @WBIT13,TMP0          ; GPL memory setup required ?
       JNE   GPLLN1                ; No, skip 
*--------------------------------------------------------------
* Prepare memory for GPL interpreter
*--------------------------------------------------------------
       MOV   @GPLDAT,@>8370        ; Set highest available VDP address
       MOV   @GPLDAT+2,@>8372      ; Set pointers for data- and subroutine stack      
*--------------------------------------------------------------
* Push GROM address with opcode for XML on GPL suprogram stack
*--------------------------------------------------------------        
GPLLN1  LI    TMP0,>8373            ; GPL subroutine stack pointer
       MOVB  *TMP0,@TMP0LB         ; Replace byte ">73" with top of stack
       MOV   @DUMXML,*TMP0+        ; Push "dummy XML" on stack
       MOV   *R11+,*TMP0           ; Push address of GPL routine to call
       MOVB  @TMP0LB,@>8373        ; Update stack pointer
*--------------------------------------------------------------
* Execute GPL routine and prepare for return
*--------------------------------------------------------------            
GPLLN2  MOVB  @BDIG0,@>837C         ; Clear GPL status-byte
       MOV   R11,TMP1        
       BL    @PUTVR
       DATA  >01C2                 ; VDP#1 - Turn of VDP interrupt
       MOV   TMP1,R11
       LWPI  GPLWS                 ; Load GPL workspace
       LI    R13,>9800             ; GROM base (GROM0 in console)
       LI    R15,VDPW              ; Set VDP write address   
       S     R9,R9                 ; R9MSB contains GPL opcode >00 (RTN)
       B     @GPLVEC               ; Run GPL interpreter (vector is at ROM @>0016)
XMLRTN  LWPI  WS1                   ; Load our workspace again
       B     *R11                  ; All done - return to caller
GPLDAT  DATA  >3FFF,>9F7E
*--------------------------------------------------------------
* GROM address of dummy XML opcode. Depends on console version
*--------------------------------------------------------------  
DUMXML  DATA  >0379                 ; Value of GROM @>0379 is >0FF0
* :..

 

 

Current status is that:

a) I'm able to jump into the GPL interpreter

b) First RTN statement is properly executed

c) The GPL interpreter does a LIMI 2 at ROM @>0070 and I'm off to the ISR routine at ROM @>0900.

*GGGRRRHH* I didn't want that

I'm able to safely return to my assembly language program. I had to turn of the VDP interrupt flag in VDP#1.

 

So here to my questions:

 

1) Would there be a reliable way to run multiple "GPL" statements without the ISR bumping in ?

The answer is very likely to be found on Thierry's website, but I'm asking here anyway

 

2) How many different GROM revisions were produced for the TI-99/4A ?

Some of the GPL routines have vectors, but a lot don't.

 

3) Also for returning to my assembly program in scratch-pad memory I had to go find a byte sequence

that resembles the opcode+operand of a GPL "XML" instruction with a table located in scratch-pad memory.

I found such sequence, but that sequence may of ofcourse be located at different GROM memory addresses,

depending on the GROM revision

 

 

The "quest" goes on

[matthew180]

Sorry, can't help with this one my friend, I know nothing of GPL. I would, however, be interested in some explanation as to what GLP calls you are hoping to tap into for your lib?

 

Matthew

[Opry99er]

I think one is the SPRITE collision routine in GPL which is pretty sharp, from what I understand.

[+retroclouds]

Sorry, can't help with this one my friend, I know nothing of GPL. I would, however, be interested in some explanation as to what GLP calls you are hoping to tap into for your lib?

 

Matthew

 

ok, here are the main ones I can think of right now:

 

Likely possible:

• Load title screen font, small-caps font, etc.
  This could be done without GPL, but due to different ROM revisions the exact location of the fonts may be hard to find as they can be displaced with a few bytes.
  

 

Hard to do:

• GPL COINC instruction. Collision check routine. You can use it for checking collision between sprite-sprite, sprite-tile, tile-tile.
  Don't know if this will be possible at all. Normally the mapping table is stored in GROM.
   
  
• GPL FMT instruction. There is pretty much a screen formatter included in the GPL interpreter. It has its own "language" you can use to draw screens in a compact way.
  

[Gary from OPA]

I try to help you out on this later this weekend.

 

I been swamped since a launch of a new product on Aug. 19

and been overloaded, working 20 hours a day, just keeping

my servers up and expanding them like mad, to handle the

2million+ per day they are getting regarding the news.

 

Ugh.

 

Anyhow back to GPL, there is only four versions to worry about:

 

v1.0 - The original 99/4

v1.1 - The most common 99/4a

v2.2 - The ROM blocking 99/4qi

v3.0 - My licensed SOB version

 

The parts that move between those versions is not many, and I got all the notes on that.

Plus notes on all possible free bytes you can safely use in the sad little tiny 256 space.

[Opry99er]

My curiosity is now steeped.... If the GPL COINC routine map was programmed in assembly to begin with, could it be written again? This time without the need for GROMs? Perhaps a straight VDP memory chunk could be set aside for it... I don't know how big it is, but I bet we have room...

 

I may have missed the point on this, as I'm not an expert in either assembly or GPL, but the wheels are turning a bit and I'd like to know more.

[Tursi]

The GPL COINC routine just does a distance compare, Owen, we already taught you how to do that in assembly.

[Opry99er]

I see. Yes, and it was much appreciated. I was just curious because I have heard alot about the GPL routine and was interested in details.

[+retroclouds]

I try to help you out on this later this weekend.

 

I been swamped since a launch of a new product on Aug. 19

and been overloaded, working 20 hours a day, just keeping

my servers up and expanding them like mad, to handle the

2million+ per day they are getting regarding the news.

 

Ugh.

 

Anyhow back to GPL, there is only four versions to worry about:

 

v1.0 - The original 99/4

v1.1 - The most common 99/4a

v2.2 - The ROM blocking 99/4qi

v3.0 - My licensed SOB version

 

The parts that move between those versions is not many, and I got all the notes on that.

Plus notes on all possible free bytes you can safely use in the sad little tiny 256 space.

 

Thanks Gary! My target platform is the unexpanded TI-99/4A console, so if I understand correctly there

are 2 main versions to worry about, being v1.1 and v2.2

[sometimes99er]

My target platform is the unexpanded TI-99/4A console, so if I understand correctly there are 2 main versions to worry about, being v1.1 and v2.2

If your target is ROM cartridges without GROM in the cartridge, then you could forget about v2.2. And then you're down to only one version and should be able to go "nasty" (direct dips) !?

 

[matthew180]

The "no GROM" problem is being worked on...

 

Matthew

[Opry99er]

Could cart GROM be replaced with "flash" theoretically?

[matthew180]

No. A GROM has a "settable" and self-updating internal address counter, so there is logic involved. Tursi is working on a microcontroller version and I'm going to start on a PLD (programmable logic device) version that will probably use a CPLD. Since I got into FPGA's I've become attached to the PLD idea and I like the extreme low level operation (I should have been a chip designer - that's where I'm happiest.) With a CPLD I can make a pin-compatible "programmable" GROM replacement.

 

Matthew

[rocky007]

I try to help you out on this later this weekend.

 

I been swamped since a launch of a new product on Aug. 19

and been overloaded, working 20 hours a day, just keeping

my servers up and expanding them like mad, to handle the

2million+ per day they are getting regarding the news.

 

im' curious, what's your new product ?