Extended BASIC G.E.M.

[Omega-TI]

11 hours ago, jedimatt42 said:

I would expect, having looked at the parts, it would go nicely on an UberGrom board.

Wow, that would be kind of neat.  The sad thing is, I've not programmed a 1284P in so long I've forgotten how to do it.  The 49F040 is a piece of cake though.  You know the old saying, "Use it or lose it".  Sadly, I've lost it.

[Omega-TI]

Just in case anyone burns one....

 

 

[senior_falcon]

I was trying to LOAD("DSK9.T80XBGEM.OBJ") a few days ago using the fast assembly object code loader. This threw an error in XB, but did not throw an error using MiniMemory. To make a very long story pretty short, here is what I found. Besides the usual addresses that you can REF in the minimemory loader such as VSBW, VWTR, etc., I added others including SCROLL. T80XB has an assembly sub called, you guessed it, SCROLL. When the loader is adding DEF's  to the list of assembly subs it checks to see if it is in the REF table. If so then an error is issued. I will look tonight to see if it is possible to have SCROLL both REF'd and DEF'd. That may be the best way to deal with this.

[Asmusr]

14 hours ago, Omega-TI said:

The sad thing is, I've not programmed a 1284P in so long I've forgotten how to do it.

You could use GROMCFG on the TI.

[senior_falcon]

The fix to the problem described in post 303 was simple. I simply bypass the check for REFs and DEFs being the same. Now you have the best of both worlds. You can:

          REF XMLLNK

          DEF SCROLL

SCROLL LWPI WKSP

             BLWP @XMLLNK

             DATA >0026

             etc.....

 and that works fine. The loader knows to add scroll to the list of assembly subroutines. Or you can:

          REF SCROLL 

          REF XMLLNK

           DEF SCRL

SCRL   LWPI WKSP

             BLWP @XMLLNK

             DATA SCROLL

             etc.....

and that also works fine. The loader knows to look up SCROLL in the table of REFs. Notice that, unlike the normal XB loader, you can use REFs.

If you try to do both REF SCROLL and DEF SCROLL you get an error message when assembling using the TI assembler and Asm994a, and probably all others as well.

       

Edited October 29, 2020 by senior_falcon

[Tursi]

10 hours ago, Asmusr said:

You could use GROMCFG on the TI.

Everyone made it very clear that they hated the tools I provided.

 

[+jedimatt42]

On 10/27/2020 at 7:26 PM, Omega-TI said:

Wow, that would be kind of neat.  The sad thing is, I've not programmed a 1284P in so long I've forgotten how to do it.  The 49F040 is a piece of cake though.  You know the old saying, "Use it or lose it".  Sadly, I've lost it.

You'll give up a feature in post #289

[Omega-TI]

On 10/28/2020 at 10:50 PM, jedimatt42 said:

You'll give up a feature in post #289

Very true, but I was thinking more for my beige unit in one of my new beige shells.

[senior_falcon]

While working on the new CALLs for GEM, I found a bug in Asm994a. As mentioned earlier, the new object code loader can use REFs. Here's the bug:

       REF GPLWS

       LWPI GPLWS

       END

When assembled with the TI assembler, loading this one line of code gives the expected >02E0,>83E0

When assembled with Asm994a, loading this one line gives >83E0,>0000 and if there are lines after this the loader seems to slow to a crawl. I'm guessing it's somehow getting out of sync.

DATA GPLWS gives the expected >83E0 with either assembler.

I will make a note of this bug in the GEM manual.

Edited October 31, 2020 by senior_falcon

[senior_falcon]

Being able to move the vdp stack within a running program is the key to having a CALL TML that works properly. Or, if you are in the TML environment, CALL XB256 or CALL T80XB would also entail moving the stack. I have finally had some success doing this. It was a simple test program that created 2 strings and then printed them. The program started up, did the prescan before startup, then the first line CALL LINK'd to an assembly routine that moved the stack. After the stack was moved the program worked as expected. Now to test with more complex programs that use DEF's and user subs.

[+RXB]

1 hour ago, senior_falcon said:

Being able to move the vdp stack within a running program is the key to having a CALL TML that works properly. Or, if you are in the TML environment, CALL XB256 or CALL T80XB would also entail moving the stack. I have finally had some success doing this. It was a simple test program that created 2 strings and then printed them. The program started up, did the prescan before startup, then the first line CALL LINK'd to an assembly routine that moved the stack. After the stack was moved the program worked as expected. Now to test with more complex programs that use DEF's and user subs.

Moving Stack is a problem as some hard coded routines exist in XB that will assume VDP address >0958 one of them is in XB ROMs other in GPL.

[+Lee Stewart]

2 hours ago, RXB said:

Moving Stack is a problem as some hard coded routines exist in XB that will assume VDP address >0958 one of them is in XB ROMs other in GPL.

 

There is no hard-coded reference in the console ROM or GROMs. Where are they in XB?

 

...lee

[senior_falcon]

4 hours ago, RXB said:

Moving Stack is a problem as some hard coded routines exist in XB that will assume VDP address >0958 one of them is in XB ROMs other in GPL.

That's not an issue at all. That was figured out with TML in the early 1990's. T40XB and T80XB use the same trick. It's the actual stack that needs to be moved to make room for graphics. Instead of ending at >37D7, my test program moves it so it ends at >2FFF, all done from a running program.

[+RXB]

20 hours ago, Lee Stewart said:

 

There is no hard-coded reference in the console ROM or GROMs. Where are they in XB?

 

...lee

Lee

One in start up of XB GROM and another in XB ROMs usually at start up of XB.

In RXB 2020 I have modified these to be moved to your choice. 

 

[senior_falcon]

On 11/1/2020 at 10:54 AM, senior_falcon said:

Being able to move the vdp stack within a running program is the key to having a CALL TML that works properly. Or, if you are in the TML environment, CALL XB256 or CALL T80XB would also entail moving the stack. I have finally had some success doing this. It was a simple test program that created 2 strings and then printed them. The program started up, did the prescan before startup, then the first line CALL LINK'd to an assembly routine that moved the stack. After the stack was moved the program worked as expected. Now to test with more complex programs that use DEF's and user subs.

I did some re-coding and with the changes it looks like user SUBs and DEFs work fine with the stack moved. (Only one program tested so far.) So it should be possible to CALL TML as described above andthe program will select the proper graphics mode as needed. So far this will only work if that is the first statement in the program. In the next few days I will investigate whether it is possible to change graphics modes at any point within a program.

[senior_falcon]

I made another small change and now it looks like the stack can be moved at any point within a running program. I have a little more testing to do to be sure there are no snags (there usually are!) and assuming all goes as expected should be adding this to GEM soon.

I had a great idea for an addition to XB 2.8 G.E.M. - the ability to run ROM programs on a v2.2 console. And then I realized that would be kind of tough if XB has to be in the slot!

[Omega-TI]

1 hour ago, senior_falcon said:

I had a great idea for an addition to XB 2.8 G.E.M. - the ability to run ROM programs on a v2.2 console. And then I realized that would be kind of tough if XB has to be in the slot!

 

Which brings up a technical question, assuming one wanted GEM or some other cartridge image like Force Command to always to be available, no matter what is plugged into their cartridge port, could a cartridge work with some sort of "P-Box based cartridge adapter"?

[senior_falcon]

That's way beyond my pay grade. I'm pretty ignorant about the TI99. I learned a few tricks and have been making the most of them ever since.

[atrax27407]

8 hours ago, Omega-TI said:

 

Which brings up a technical question, assuming one wanted GEM or some other cartridge image like Force Command to always to be available, no matter what is plugged into their cartridge port, could a cartridge work with some sort of "P-Box based cartridge adapter"?

Check out the SNUG HSGPL Card. That being said, you can still only access one cartridge at a time.

Edited November 6, 2020 by atrax27407

[HOME AUTOMATION]

9 hours ago, Omega-TI said:

 

Which brings up a technical question, assuming one wanted GEM or some other cartridge image like Force Command to always to be available, no matter what is plugged into their cartridge port, could a cartridge work with some sort of "P-Box based cartridge adapter"?

Sounds to me like a good candidate for a TSR type run, perhaps brought up from an interrupt key. The other real issue being where it would reside as a fixture.

[atrax27407]

Why don't we start a separate topic for this? Perhaps Omega could do a poll.

[+acadiel]

On 10/28/2020 at 11:38 PM, Tursi said:

Everyone made it very clear that they hated the tools I provided.

 

GROMCFG is super easy to use.  I don't know why people hate it so much.  I've used it probably 30+ times.

[Tursi]

8 hours ago, acadiel said:

GROMCFG is super easy to use.  I don't know why people hate it so much.  I've used it probably 30+ times.

The original thread provides sufficient enlightenment.

 

But thanks.

 

[senior_falcon]

I can now move both ends of the stack from within a running program, with no hiccups, glitches or other problems that I can detect. It also works from command line in the immediate mode. This means that G.E.M. can have CALL TML, CALL XB256, CALL T40XB, etc. I will see whether these can be more versatile. i.e. CALL XB256 will load and start up XB256 with the default 3 disk files. Or you could have CALL XB256(2) which would do the same as CALL FILES(2) and then load XB256.

[senior_falcon]

The pieces of the puzzle are beginning to fit together. As hoped, CALL XB256 will be able to load and start up XB256 with the default 3 disk files, while CALL XB256(4) would load and start XB256 with 4 disk files open.

I now need to do a check for sufficient stack memory to throw an error if moving the stack will leave the program without enough memory.