Extended BASIC G.E.M.

[DavidC]

.

Edited March 11, 2023 by DavidC

[fabrice montupet]

I discovered a strange thing with the last version of G.E.M/XB256:

In a program, I redefined the characters from 31 to 159. If I display all of them:

130 FOR I=31 TO 159 :: PRINT CHR$(I); :: NEXT I

All have their new pattern.  Now, I add a subprogram:

2900 CALL DELSPRITE(ALL) :: RETURN

And modify the line 130 like this:

130 FOR I=31 TO 159 :: PRINT CHR$(I); :: NEXT I :: GOSUB 2900

and add :

135 FOR I=31 TO 159 :: PRINT CHR$(I); :: NEXT I

The character patterns between 144 and 159 are deleted/damaged. Tested with Classic99 and ti994w.

 

 

 

Edited February 5, 2023 by fabrice montupet

[senior_falcon]

Once you understand what is going on, there is nothing strange about this.

Normally XB lets you redefine characters from 32 to 143. The sprite motion table is located where the patterns for characters 144 to 157 are normally kept. Most XB's  keep you from redefining those characters, but in XB 2.9 G.E.M. and RXB, the limit checks have been modified so that you can redefine characters 30 to 159. Using sprite motion will modify those characters, and breaking the program or using DELSPRITE(ALL) will reset all those characters to zeros. Some cleverness will be necessary if you want to use sprites and redefine those characters. 

Of course, you can get around this by using XB256 and screen 2.

In the program below you will see that one of the patterns is not fixed, and when you break the program they all get reset:

10 FOR I=144 TO 157 :: CALL CHAR(I,"FFFFFFFFFFFFFFFF"):: PRINT CHR$(I);:: NEXT I
20 CALL SPRITE(#1,65,16,100,100,20,25)
30 GOTO 30

 

Edited February 5, 2023 by senior_falcon

[fabrice montupet]

Thank you for the explanations. The program in progress should have to be deeply modified to integrate the management of the extra characters patterns and sprites motions so I keep this in mind for a future XB256 project. 

[Retrospect]

from what I've read here, my sprite issues with Anubis have been caused by my redefining chars 144 to 157.   

After an alien had been shot dead, and delsprited, it's alive status turned to nill, it's sprite was still roaming around on the screen like a "ghost".   Now I think I know why!    

[Artoj]

I would like to use one of the updated XB versions I see in these forums, what I need to know is all its Commands, the Syntax and anything unique that they have. A general list of all the new Basic commands would be a great help. A PDF file of these would be great, I would appreciate any help, thanks , regards Arto. 

[+OLD CS1]

5 hours ago, Artoj said:

I would like to use one of the updated XB versions I see in these forums, what I need to know is all its Commands, the Syntax and anything unique that they have. A general list of all the new Basic commands would be a great help. A PDF file of these would be great, I would appreciate any help, thanks , regards Arto. 

Every single currently-supported XB extension comes with detailed documentation.

[senior_falcon]

XB 2.9 G.E.M.lets you choose screen colors and a font for use when editing. If you NEW or quit and restart XB the colors and font are retained. This is unlike the "My way or the Highway" approach used by other versions of XB.

One of the things I found in testing SteveB's Multicolor utilities is that, when you select a different graphics mode, the colors and font revert to the default ones instead of retaining the user specified colors and font.

Now that I know about it, this is a simple fix that can easily be done with a hex editor.

[mrvan]

I've been experimenting with chaining programs together, complex enough that I need to use string variables and not constants. XB 2.9 supports this as CALL RUN(p$). Sometimes the call succeeds and the next program runs, but sometimes not reporting a syntax error on the line with CALL RUN. I've checked that the string has the right value, including confirming no spaces. I have no doubt I could have some bug in my program but it's not yet clear. I had the CALL RUN in a subprogram, and then moved it to the main part of the program, thinking there might be funniness with subprograms but no help.

 

I'm hoping someone else knows certain conditions that cause CALL RUN to fail with a syntax error.

 

Anyone? 

[senior_falcon]

Examples?

[mrvan]

1 hour ago, senior_falcon said:

Examples?

Hi senior_falcon, I have a fair amount of work to do to cull down my program into a reasonable example. I was hoping that others might have run into such a problem, such as doesn't work using subprograms, use with on error/resume particularly after an error was trapped, use with files still open, etc.

 

I've added a fair amount of defensive programming techniques such as automatic file number allocation (like unix) when opening files, calling out closing already closed files, and general error checking, all to make sure I've not somehow destabilized things. Sadly these also cause bloat to the code. I've already bumped into the edge of edit/assembler limits and now max size of a PROGRAM file. Looking at CALL DV2XB, it says DV80 or .TXT format. Is that .TXT format different than DV80 or is it indicating that DV80 is the text format? I'm using it now.

 

CALL DV2XB(filename)

Merges a program that was saved in DV80 or .TXT format. If a program is already in memory, the lines of code are merged into the existing program. Lines are replaced if they have the same line number as an existing line. Embedded code cannot be saved or loaded. (immediate mode)

 

I'm working on a script to generate dependencies for a main procedure and to then pull only the code needed for the particular program into the final set. You're probably wondering what I'm doing. I'm using xbas99 to write XB without most line numbering. I've kept all the subprograms in separate files so I can use my file explorer (Finder) to keep the projects organized. Up to this point, though, my program generation script has simply pulled in all the "library" code and the main method. Thankfully, you've included this CALL DV2XB method so my larger programs can load, even if the loading takes a lot longer.

[senior_falcon]

.TXT format is windows format as used by Classic99, and to my knowledge will only work in Classic99.

 

CALL DV2XB(filename) I don't think you are trying to load additional lines of code to a running program, but if you are that will not work. This works in immediate mode only, essentially by typing in the text file. I believe that MERGE format would be faster if it would work for you. But I assume you have tried it and found that it did not do what you want.

 

I don't know for sure if this is your problem, but CALL RUN looks for memory expansion and doesn't work if sees that CALL INIT hasn't been done. (CALL INIT should happen automatically when XB 2.9 G.E.M. starts XB, so I don't know if this is it.)

 

 

[mrvan]

1 hour ago, senior_falcon said:

.TXT format is windows format as used by Classic99, and to my knowledge will only work in Classic99.

 

CALL DV2XB(filename) I don't think you are trying to load additional lines of code to a running program, but if you are that will not work. This works in immediate mode only, essentially by typing in the text file. I believe that MERGE format would be faster if it would work for you. But I assume you have tried it and found that it did not do what you want.

 

I don't know for sure if this is your problem, but CALL RUN looks for memory expansion and doesn't work if sees that CALL INIT hasn't been done. (CALL INIT should happen automatically when XB 2.9 G.E.M. starts XB, so I don't know if this is it.)

 

 

That is very likely the problem! My program doesn't have CALL INIT. If I have programs chained together is it ok that each have CALL INIT? Will CALL INIT be ok in the compiled XB programs? I'm planning for most of my projects to be compiled and used in this program chaining. 

 

I tried the -marge option in xbas99 and it claimed to be unimplemented. I'll look around more for text to merge capabilities. I think another format, the one for large programs, could work if I can find text to that as well. I'm in a mac environment so am preferring tools that can run there.

 

Thank you for your help so far, and for the quick responses!

[senior_falcon]

I don't know anything about xbas99. The merge I was referring to is the "merge" format that you can use in XB, such as SAVE "DSK1.TEST1,MERGE" and then later you can MERGE "DSK1.TEST1"

 

Only the first one really needs CALL INIT. If you intend to compile the program, do not include CALL INIT.  It is either ignored or crashes the compiler. CALL INIT is included in the XB loader that is made in the last step after compiling, assembling, and loading.

 

[mrvan]

11 minutes ago, senior_falcon said:

I don't know anything about xbas99. The merge I was referring to is the "merge" format that you can use in XB, such as SAVE "DSK1.TEST1,MERGE" and then later you can MERGE "DSK1.TEST1"

 

Only the first one really needs CALL INIT. If you intend to compile the program, do not include CALL INIT.  It is either ignored or crashes the compiler. CALL INIT is included in the XB loader that is made in the last step after compiling, assembling, and loading.

 

Thank you, senior_falcon. I look forward to addressing this and will let you know.

[mrvan]

2 hours ago, senior_falcon said:

I don't know anything about xbas99. The merge I was referring to is the "merge" format that you can use in XB, such as SAVE "DSK1.TEST1,MERGE" and then later you can MERGE "DSK1.TEST1"

 

Only the first one really needs CALL INIT. If you intend to compile the program, do not include CALL INIT.  It is either ignored or crashes the compiler. CALL INIT is included in the XB loader that is made in the last step after compiling, assembling, and loading.

 

Thank you, senior_falcon. The CALL INIT did the trick. This has now enabled the command interpreter, a very basic shell (for now), execute commands that are other programs, passing arguments to them. This is modeled after the initial unix concept, on the PDP-11, that used psuedo-pipes between chained programs. As is probably the case with many of us using these 40+ year old machines, it's to learn and see how much we can do, perhaps applying modern techniques. I was so limited with the tools I had when I was 13, having XB, Editor/Assembler, 32KB, and a floppy drive. Experience now, and being able to sim with the most hardware, and then a modern external dev env, lots more fun.

[SteveB]

8 hours ago, mrvan said:

I'll look around more for text to merge capabilities.

TiCodEd has the option to write MERGE files, also in the Mac version. I write the MERGE format as the input for Harry's compiler.

 

For windows you may also use my LibXBTKN64.dll from another program to write a tokenized MERGE file. In general it should be possible to build the shared library also on Linux and Mac, but I have not received much demand for this yet.

[mrvan]

On 3/18/2023 at 5:53 PM, senior_falcon said:

.TXT format is windows format as used by Classic99, and to my knowledge will only work in Classic99.

 

CALL DV2XB(filename) I don't think you are trying to load additional lines of code to a running program, but if you are that will not work. This works in immediate mode only, essentially by typing in the text file. I believe that MERGE format would be faster if it would work for you. But I assume you have tried it and found that it did not do what you want.

 

I don't know for sure if this is your problem, but CALL RUN looks for memory expansion and doesn't work if sees that CALL INIT hasn't been done. (CALL INIT should happen automatically when XB 2.9 G.E.M. starts XB, so I don't know if this is it.)

 

 

Hi senior_falcon, I was able to get each of my programs chaining properly with CALL RUN using CALL INIT. With them stable, my next step has been to compile them with your XB compiler. Before compiling I removed the CALL INIT that I had at the beginning of each program, as you recommended. Each of the compiled versions of the programs hang on the CALL RUN. I found a work around to it eliminating the CALL RUN in the compiled code, and then by merging in code into the linked program that contained an XB CALL RUN. I've used files to retain state information so collecting which program to chain to wasn't really much of a problem. Aside from this I also wonder if there's by any chance a blackboard type capability that eases passing info between programs. I've seen clever tricks like reading state directly from the screen, but I'm wondering if there's something better than that.

[+Vorticon]

I am unable to run XB2.9GEM on a real TI using the FG99. It just locks up the machine. No such issues with the 2.8 version.

Anyone else has experienced this? I am using the latest posted version on page 22 of this thread.

[senior_falcon]

1 hour ago, Vorticon said:

I am unable to run XB2.9GEM on a real TI using the FG99. It just locks up the machine. No such issues with the 2.8 version.

Anyone else has experienced this? I am using the latest posted version on page 22 of this thread.

Some people say it works and some say it doesn't. Since I don't have a Final Grom I cannot test it.

[+Vorticon]

What changed from the 2.8 version?

[senior_falcon]

26 minutes ago, Vorticon said:

What changed from the 2.8 version?

There are a couple additional pages of bank switched rom.

Take a look at my post August 1, 2022.

[+Vorticon]

Well that's really a shame. I suspect it's got something to do with the FG and not my other hardware which is pretty standard outside of the TIPI and pcode card.

[+retroclouds]

12 minutes ago, Vorticon said:

Well that's really a shame. I suspect it's got something to do with the FG and not my other hardware which is pretty standard outside of the TIPI and pcode card.

 

If you name the files for GEM as seen below, it should work. At least it does for me. Didn't work before, but after renaming the files it did.

 

rom -> XB29GEMC.bin

grom -> XB29GEMG.bin

[senior_falcon]

See if changing the file names works.

I will take a look at the code tonight. Most of the scratchpad is initialized at startup, but not all. I use one of those uninitialized bytes (I think it is >83D5 but will check) as a flag so that if you are in 40 column mode and quit, then when XB 2.9 starts, XB will again be in the 40 column mode. There was some trouble that developed because, when you start up a real TI99, the bits are indeterminate and so the value could be anything. (In Classic99 ithe bytes are always set to zero at startup.) One potential problem is that if at startup the flag happens to get set for the 80 column mode but you don't have any way to display 80 columns, then you get a blank screen with no way out. I think that I now initialize that value at startup to avoid trouble like this but will take a closer look tonight.