Switching GROM banks from within GPL itself

[Gary from OPA]

Now that there is out there the UberGROM boards and more people seem to be taking a look into the wonders of GPL coding, I thought I would post up a old demo of code I wrote a while ago, that shows you can switch running code of GROM banks if your device follows the multiple banks system that TI setup in advance, that is >9800 (first normal 8 groms), >9804 (second group of 8 groms).

 

Two GPL opcodes were designed by TI to handle switching of banks. They are called: DSWGR and RTGR and not much is know of them since TI never publicly produced a device with multiple banks of GROMs.

 

But now with large cartridges out there it can be handy to code up game or menu or some cool utility that needs more room to grow and to switch and call code in another bank and come back all from within GPL without messing around with assembly.

 

Here is technical background on how these two opcodes work:

 

The DSWGR and RTGR mechanism

 

As you know, GROMs are accessed via a set of four addresses in cpu memory:

>9800 to read data (this is known as the GROM base)

>9802 to read the current address

>9C00 to write data (GRAM only)

>9C02 to set the address.

 

However, provision is made to use upto 16 sets of such addresses, >0004 bytes apart, which give access to as much as one megabyte of GROM/GRAM. This never became a reality at Texas Intruments (in fact the console GROMs answer to each and every base), but most GRAM cards make use of this trick to implement more than 64K of GRAM.

 

Interestingly, TI provided GPL opcodes to call routines located in another base. Unfortunately, one of them is buggy!

 

The DSWGR opcode has the following syntax:

 

       DSWGR base,address

Where base can be either a variable or a constant, whereas address has to be a variable. So, in practice you could type:

 

       DST   >604A,@>8300        Address where to branch
       DSWRG >9804,@>8300        Branch at >604A using GROM port >9804 

DSWGR pushes both the current base and the return address on the subroutine stack, then changes the base value at >83FA and takes the branch.

 

Routines called in this way simply return with:

 

       RTGR   

which recovers the base and the return address from the stack.

 

Unfortunately, RTGR also performs a dummy write to GROM/GRAM memory, at the address corresponding to the current base. That is, it erases GRAM byte >9800 when returning to base >9800, GRAM byte >9804 when returning to >9804, etc. Why TI did that is beyond my understanding. Maybe they thought it didn't matter since GROMs cannot be written to? Or because GROMs were limited to >1800 bytes, GROM 8 would cover >8000-97FF so the >98xx addresses would not be a problem? Well, it may be a problem with GRAM cards, so be aware of it.

 

Anyhow, there is no DSWGR-callable routine in the console GROMs, and I'm not aware of any cartridge that contains one. Which does not mean that you cannot write your own!

 

The above was taken from http://www.unige.ch/medecine/nouspikel/ti99/gplcall.htm he explains it there the best, then I could, and you can find below my attached demo of usage.

 

SWGROM-S.txt

 

Hope this helps someday, someone, somewhere is producing a multiple-bank GPL program. -- Good Luck, and any questions please ask me.

 

The above code is released FREE to all, do what ever you want with it, burn it, trash it, mod it, assemble it, tear it up into pieces, poke thousands of holes into it, etc.

Edited April 27, 2015 by Gary from OPA

[+Lee Stewart]

Do any of the extant GPL assemblers assemble SWGR and RTGR besides Thierry's? His is the only one as near as I can tell.

 

...lee

[ralphb]

My xga99 cross-assembler does, to my surprise.

tiger ~/tmp > xga99.py -c swgrom.gpl -s rag
tiger ~/tmp > ll swgrom.rpk 
-rw-rw---- 1 ralph ralph 1295 Apr 27 21:43 swgrom.rpk

If you're using the cart generation you'll need to AORG to >0030 so that the automatically generated header has enough room. And there's a silly bug in xga99 with HOME so the sample program provided by Gary needs a line break between SWRUN and HOME, but other than that the result seems to run fine in MESS.

Edited April 27, 2015 by ralphb

[Gazoo]

You can switch banks simply by writing to the byte in scratchpad at >83FB. The word at >83FA contains the current Grom page address. The XB v2.7 Suite cart makes extensive use of this.

 

For instance, if the code below is at g>8000 on both pages 1 & 2:

 

>3100 >0180 >FB80 >0A05, >7810,>0400 (move the byte at g>800A to c>83FB, then branch to g>7810),

 

you will start the execution of the code at g>8000 on page 1 and end up executing the code at g>7810 on page 2.

 

Simple, and no messing with assembly. (or bothering to go through all the nonsense of using a GPL assembler when it's easier to just type the code into a Hex editor and run it right away )

 

Gazoo

Edited April 27, 2015 by Gazoo

[Gary from OPA]

You can switch banks simply by writing to the byte in scratchpad at >83FB. The word at >83FA contains the current Grom page address. The XB v2.7 Suite cart makes extensive use of this.

 

For instance, if the code below is at g>8000 on both pages 1 & 2:

 

>3100 >0180 >FB80 >0A05, >7810,>0400 (move the byte at g>800A to c>83FB, then branch to g>7810),

 

you will start the execution of the code at g>8000 on page 1 and end up executing the code at g>7810 on page 2.

 

Simple, and no messing with assembly. (or bothering to go through all the nonsense of using a GPL assembler when it's easier to just type the code into a Hex editor and run it right away )

Gazoo

Might be easier, but logically more messy.

 

These opcodes are there for those writing actual GPL programs not using hex editor, developing a new GPL program which flows correctly between banks, without the need of messing with code afterwards.

 

Don't you think it would be handy to be able to assemble from source a program larger then one bank of code. -- Yes, sure no one has written one yet, but I hope that someday someone will make proper use of our expanded GROM space now, and infact write a new utility that is more then 5times8K of code, it would be very nice to see!

 

Sometimes being able to write up source file, and have it assemble and run with knowing the hex, or why is much better, also helps if in the future the underlaying hardware changes.

Edited April 27, 2015 by Gary from OPA

[Gazoo]

Messy for you, not for me. And I don't mess with code afterwards, I do it as I go.

 

The XB v2.7 Suite cart is actually 120k of Grom code that flows correctly between banks, and they all have to be there for it to work correctly. Take something out and you break it. I don't think anyone else has ever put together that much GPL code in one place that runs as seamlessly as this cart. Please feel free to correct me if I'm wrong.

 

Sometimes writing GPL source code is better for some people, but not for me. Visualizing what is going on by looking at the Hex code in it's entirety is much better for me.

 

I think the vast number of GPL programs I've released over the past 26 years speak well enough of my approach, haven't had too many complaints.

 

Gazoo

[Gazoo]

Kracker_Facts.pdf

 

While the discussion is about GPL source code, there's an interesting error in the GPL source code in the Kracker Facts file, which I've attached here.

 

In the 'CALL CAT' code, line 109, Grom address g>DC4D, there is code that sends the TI into never-never-land. >3414,>A282,>A8CA throws the Grom execution address somewhere in the g>5000 range, locks up the console, produces an interesting screen display, and produces a not-so-pleasant squealing sound. Fortunately I was able to identify this offending code, break out of it, fix the problem, and return to the catalog code to produce a satisfactory result.

 

That's only one of the reasons I dislike GPL source code. Bleech!!!!!!

 

Gazoo

 

[RXB]

Well I put out some videos on attempts to do this on Classic99:

 

 

 

 

So the idea was to make RXB take up 2 40 pages of GROM and be able to access and switch back and forth.

 

Much like Gazoo does on his 2.7 Suite module does.

 

My approach though would find the 40K page of GROM it came from and could get back where it came from to the other 40K page of GROM.

 

The idea was to make a patch where any module could find another module and jump back and forth in the 16 pages of 640K of GROM on the TI99/4A

Edited April 28, 2015 by RXB

[+Lee Stewart]

Kracker_Facts.pdf

 

While the discussion is about GPL source code, there's an interesting error in the GPL source code in the Kracker Facts file, which I've attached here.

 

In the 'CALL CAT' code, line 109, Grom address g>DC4D, there is code that sends the TI into never-never-land. >3414,>A282,>A8CA throws the Grom execution address somewhere in the g>5000 range, locks up the console, produces an interesting screen display, and produces a not-so-pleasant squealing sound. Fortunately I was able to identify this offending code, break out of it, fix the problem, and return to the catalog code to produce a satisfactory result.

 

That's only one of the reasons I dislike GPL source code. Bleech!!!!!!

 

Gazoo

 

 

What is wrong with that code and what change did you make? It looks like perfectly good GPL to me (from my reading of the TI GPL Programmer's Guide).

 

...lee

[+acadiel]

Switching GROM banks from within GPL itself.... isn't that akin to causing a temporal anomaly in the space time continuum?

[RXB]

 

What is wrong with that code and what change did you make? It looks like perfectly good GPL to me (from my reading of the TI GPL Programmer's Guide).

 

...lee

My GPL code worked fine and switched GROM pages back and forth fine.

 

SWGR and RTGR works great!

[Gazoo]

 

What is wrong with that code and what change did you make? It looks like perfectly good GPL to me (from my reading of the TI GPL Programmer's Guide).

 

...lee

 

What it's supposed to do is to display the device as the first thing on the screen once the catalog begins. It's supposed to do a simple VDP to VDP move, but it doesn't.

Copied from my previous post: '... sends the TI into never-never-land. >3414,>A282,>A8CA throws the Grom execution address somewhere in the g>5000 range, locks up the console, produces an interesting screen display, and produces a not-so-pleasant squealing sound.'

 

My solution was to jump out of the code there, display 'DSK .' on the screen, grab the byte at >8375, put that byte after the 'K', then jump back into the routine.

 

Just was curious as to why the code doesn't work.

 

Gazoo

[+Lee Stewart]

 

What it's supposed to do is to display the device as the first thing on the screen once the catalog begins. It's supposed to do a simple VDP to VDP move, but it doesn't.

Copied from my previous post: '... sends the TI into never-never-land. >3414,>A282,>A8CA throws the Grom execution address somewhere in the g>5000 range, locks up the console, produces an interesting screen display, and produces a not-so-pleasant squealing sound.'

 

My solution was to jump out of the code there, display 'DSK .' on the screen, grab the byte at >8375, put that byte after the 'K', then jump back into the routine.

 

Just was curious as to why the code doesn't work.

 

Gazoo

 

That particular code should work—unless, perhaps , the name length in >8314 (TEMP2) is wrong. Maybe try >3414,>AF02,>82AF,>08CA, which should force the interpreter to read a full 2 bytes for each VRAM address instead of a byte and a half—at least, that is what the >F after the >A is supposed to do.

 

...lee

[Gazoo]

That code sort of worked the first time, at least it didn't produce a lockup. But it didn't write the characters with the >60 offset as required.

 

 

And on the 2nd pass everything goes all to hell:

 

 

But at least there's no lockup. Pressing a key correctly returns you to the menu.

 

I jumped out of the code at g>DC4D with a branch to g>DEC0 (>05DE,>C000) and used the patch below to get it to work.

 

 

Gazoo

 

 

 

[Gazoo]

Switching GROM banks from within GPL itself.... isn't that akin to causing a temporal anomaly in the space time continuum?

 

You'll have to ask 'Q' for the answer on that one. Picard should be able to forward the question to him for you.

[+Lee Stewart]

That code sort of worked the first time, at least it didn't produce a lockup. But it didn't write the characters with the >60 offset as required.

...

But at least there's no lockup. Pressing a key correctly returns you to the menu.

 

I jumped out of the code at g>DC4D with a branch to g>DEC0 (>05DE,>C000) and used the patch below to get it to work.

 

 

Gazoo

 

The need for the >60 offset is because it is XB, right? How do you get a MOVE to do that? Maybe your patch code does it? I will see how long it takes me to hand disassemble it.

 

...lee

[+OLD CS1]

 

You'll have to ask 'Q' for the answer on that one. Picard should be able to forward the question to him for you.

 

"Oh, you'd like me to connect the dots for you, lead you from A to B to C, so that your puny mind could comprehend. How boring."

[RXB]

Do any of the extant GPL assemblers assemble SWGR and RTGR besides Thierry's? His is the only one as near as I can tell.

 

...lee

I did this using SWGR and RTGR for a RXB using 2 carts for Classic99.

 

RXB could be in any PAGE of GROM but REA with built in Editor and built in GPL Assembler and RAM Assembler (normal) had to be in first GROM PAGE >9800 (GROM PAGE 1)

 

No one seemed to understand how freaking cool this was and no one even used it as far as I could see. (I was really heartbroken over this.)

 

The idea was to use the last GROM bank normally used by REA and move it to a whole new page >9800 and have all the built in Disk stuff for EA.

i.e. Editor, Assembler and GPL Assembler

 

Then you can put RXB in any GROM PAGE and the REA would find it and switch to it.

And then RXB could have a routine to switch back, the problem was no place in the TI Memory to save that address.

 

I even used a GROM Powerup to find and locate both carts and save the address.

 

REA2012.zip

[Gazoo]

 

The need for the >60 offset is because it is XB, right? How do you get a MOVE to do that? Maybe your patch code does it? I will see how long it takes me to hand disassemble it.

 

...lee

Move 5 bytes to VDP at >0282 from Grom at >DEE0 (the 5 bytes already have >60 added to them)

Add >6000 to the word at >8375

Move 1 byte to VDP at >0285 from >8375

Branch back into the routine at g>DC53

 

Gazoo

Edited April 29, 2015 by Gazoo

[+Lee Stewart]

Move 5 bytes to VDP at >0282 from Grom at >DEE0 (the 5 bytes already have >60 added to them)

Add >6000 to the word at >8375

Move 1 byte to VDP at >0285 from >8375

Branch back into the routine at g>DC53

 

Gazoo

 

Thanks!—I almost had it. I forgot the leading 0 of the >75 of >A375 and was trying to figure out where address >7560 might be.

However, now I am really confused. @>8375 is an odd address. Won't performing a word add to an odd address actually start in the previous byte? That is, will not a GPL double-add of >6000 to @>8375 actually add >6000 to @>8374, effectively adding 0 to the byte at @>8375?

 

...lee

[+mizapf]

As far as I know, GPL has no word boundaries. A double-operation always takes this and the next byte address.

[+Lee Stewart]

As far as I know, GPL has no word boundaries. A double-operation always takes this and the next byte address.

 

Wow! You are right! Here is the snippet from the GPL interpreter that does it:

0254  D145  MOVB 5,5      Word?
0256  1301  JEQ  >025A
0258  DCC2  MOVB 2,*3+    Write data
025A  06C2  SWPB 2
025C  DCC2  MOVB 2,*3+

...lee

[Willsy]

Yeah. GPL is modeled on a (theoretical) 8-bit processor. Or at least, an 8-bit processor that never saw the light of day. I have a feeling there was supposed to a GPL CPU in the 4A (and quite possibly no 9900 at all) but it all went the way of the pear.