Extended BASIC G.E.M.

[+InsaneMultitasker]

On 5/7/2021 at 9:34 PM, senior_falcon said:

Here is the latest version of XB 2.8 G.E.M. with the HCHAR and VCHAR modifications shown in the video above. Because it fills the entire screen, what is shown in the video demonstrates the greatest increase in speed. It actually is a tiny bit slower (1-2%) if only printing one character, but it will always be faster if more than one character is printed

Impressive!  What sort of changes needed to be made to improve the speed so dramatically and are there other routines that will benefit? 

[senior_falcon]

On 7/7/2021 at 5:32 PM, InsaneMultitasker said:

Impressive!  What sort of changes needed to be made to improve the speed so dramatically and are there other routines that will benefit? 

HCHAR and VCHAR  use the GPL instruction FMT which makes for super compact code. Sadly, the compact code comes at a price - slow execution.

I set up HCHAR and VCHAR to retrieve all the numbers via GPL instructions (row,column,character,# repeats), then go to assembly routines to actually put the characters on the screen. This is actually a tiny bit slower by a few percent if you are only putting one character on the screen. If there are more than one then there is no comparison.

PRINT and DISPLAY AT could benefit from this treatment, but it would be a nightmare to implement because of all the possible variables such as comma, semi colon, colons, AT, and so on. That was a real ordeal on the compiler and I have no desire to repeat that experience.

With XB256, CALL LINK("DISPLY",row,column,text) is a faster alternative that can be used in place of PRINT and DISPLAY AT

Edited July 12, 2021 by senior_falcon

[senior_falcon]

Retroclouds wrote:

"Think I stumbled upon a small bug. When doing "CALL HELP" after having run a T80 program the first few screens are garbled (as it displays in 80 columns mode)."

 

I finally figured out what is happening. For the T80 mode, VR0 is set to >04. When an XB program breaks I was relying on XB to reset the registers to the proper XB ones. But XB doesn't change VR0 because XB thinks there is no reason for it to ever be changed. Even though the TI is set back to G32 mode, VR0 is still set to >04. CALL HELP uses the 40 column text mode for the first two screens, but because VR0 is not reset to zero, it actually goes into the T80 mode. There are a couple of ways to fix this minor bug and I am working out the best way.

 

Meanwhile, if you type CALL LINK("G32") the video registers are set correctly and CALL HELP will work as expected.

[senior_falcon]

Here is XB 2.8 G.E.M. which corrects the bug Retroclouds encountered when doing CALL HELP after using the T80 mode.

As always, I hope this is the final version.

XB28GEM20210712.zip

[+retroclouds]

Are there any plans for a future XB 2.9 G.E.M ?

 

Things I could think of:

• Support for the f18a 80x30 rows mode
• Program editing in 80 columns mode
• Saving/Loading XB programs in DV80 format (as was planned for the TI-99/8)

 

 

[senior_falcon]

Support for the f18a 80x30 rows mode

I don't have the f18a and don't know anything about the 80x30 mode. I do not think this mode is emulated in Classic99 and so I would have no way to test it. This would reduce the stack space a bit, from 8180 bytes to 7700 bytes, which would probably be tolerable.

 

Program editing in 80 columns mode (or 40 column mode)

There is a tiny chance this could be done. Years ago I experimented with a 40 column text editor for XB. This used an interrupt routine to send characters back and forth between the normal 32 column editor and the 40 column screen located in a different vdp memory area. As I remember this was not very satisfactory from a performance standpoint. I do know a little more now than I did back then, so maybe something like this could be made to work. Or maybe not...

 

Saving/Loading XB programs in DV80 format (as was planned for the TI-99/8)

I'm not sure why this would be desireable. This seems like a huge amount of work for what seems to me to be a trivial improvement in functionality.

 

 

 

[+retroclouds]

10 hours ago, senior_falcon said:

Support for the f18a 80x30 rows mode

I don't have the f18a and don't know anything about the 80x30 mode. I do not think this mode is emulated in Classic99 and so I would have no way to test it. This would reduce the stack space a bit, from 8180 bytes to 7700 bytes, which would probably be tolerable.

Last time I checked it wasn’t supported in classic99. That is why I’m using the js99er emulator for development in 80 columns, 30 rows  mode. js99er has full F18a support. You don’t have the great classic99 debugger, but for a lot of things the js99er debugger is sufficient.

Quote

Program editing in 80 columns mode (or 40 column mode)

There is a tiny chance this could be done. Years ago I experimented with a 40 column text editor for XB. This used an interrupt routine to send characters back and forth between the normal 32 column editor and the 40 column screen located in a different vdp memory area. As I remember this was not very satisfactory from a performance standpoint. I do know a little more now than I did back then, so maybe something like this could be made to work. Or maybe not...

Would it nowadays with the availability of the extended basic source code be easier to implement such feature?

Can you share some details on how your development cycle for GEM looks like? What tools do you use? Do you start from the source code or do you patch the existing module? Sorry for asking such stupid questions but it’s very interesting to know. On a sidenote , actually the last week I spent quite some time going through the product 359 basic interpreter manual. That is so much fun to read and want to learn and get a better understanding of how the Extended Basic interpreter works.

 

Quote

Saving/Loading XB programs in DV80 format (as was planned for the TI-99/8)

I'm not sure why this would be desireable. This seems like a huge amount of work for what seems to me to be a trivial improvement in functionality.

I understand. The reason I’m interested in this, is because it was a feature originally planned for the TI-99/8 and because I have written a programming editor Stevie that works with DV80 files, so I figured it would be the easiest for sharing extended basic programs between the two. Actually what I really would like to do is integrate Extended Basic with the editor.

Build a custom cartridge image for the final grom that has the (modified) extended basic and also has the programming editor and jump from the editor straight into extended basic and run the program or return from extended basic into the editor.

As the editor is using SAMS and has it’s own SAMS pages I think it would be doable, obviously VDP ram would need to be taken care of. 

 

Edited July 15, 2021 by retroclouds

[+Vorticon]

2 hours ago, retroclouds said:

I understand. The reason I’m interested in this, is because it was a feature originally planned for the TI-99/8 and because I have written a programming editor Stevie that works with DV80 files, so I figured it would be the easiest for sharing extended basic programs between the two. Actually what I really would like to do is integrate Extended Basic with the editor.

Build a custom cartridge image for the final grom that has the (modified) extended basic and also has the programming editor and jump from the editor straight into extended basic and run the program or return from extended basic into the editor.

As the editor is using SAMS and has it’s own SAMS pages I think it would be doable, obviously VDP ram would need to be taken care of. 

 

That would be so totally awesome! It would be THE killer feature of Stevie.

[+jedimatt42]

I don't sell TIPIs so I don't know who has them, but if you are a TIPI user and you save a DV80 named GAME/XB full of XB source code, then in XB OLD TIPI.GAME/XB then TIPI will convert it to BASIC dynamically. It is a one way process. GAME/XB remains a DV80. "GAME" is just an example. Ending in "/XB" or "/BAS" is the key bit.

 

Maybe an integration that supports switching easily between XB and Stevie, such as the OKFG99 protocol, for finalGrom... 

 

I forget if Stevie made it to cartridge form... Ah, yes it did... I'll have to play with that today... ( You have to forgive me, my TI is always a victim of tinkering, but it is all in one piece right now! )

[+Vorticon]

1 hour ago, jedimatt42 said:

I don't sell TIPIs so I don't know who has them, but if you are a TIPI user and you save a DV80 named GAME/XB full of XB source code, then in XB OLD TIPI.GAME/XB then TIPI will convert it to BASIC dynamically. It is a one way process. GAME/XB remains a DV80. "GAME" is just an example. Ending in "/XB" or "/BAS" is the key bit.

 

Maybe an integration that supports switching easily between XB and Stevie, such as the OKFG99 protocol, for finalGrom... 

 

I forget if Stevie made it to cartridge form... Ah, yes it did... I'll have to play with that today... ( You have to forgive me, my TI is always a victim of tinkering, but it is all in one piece right now! )

So the file has to have the /XB or /BAS extension? Good to know. So now I can write an XB program in Stevie in full 80 column and with full screen editing capabilities among many other features, save it to a TIPI folder and run it directly from FC. How cool is that?

Any limitations to the conversion process by TIPI or any valid XB source code will work? (this should really be moved to the TIPI usage thread)

Edited July 15, 2021 by Vorticon

[+jedimatt42]

It has been covered in the TIPI support thread, and is detailed on the wiki. 

 

My point was to suggest an integration between XBGEM and Stevie carts like for switching into XBGEM from Stevie and switching from XBGEM to Stevie.

[senior_falcon]

On 7/15/2021 at 7:43 AM, retroclouds said:

 

Support for the f18a 80x30 rows mode

Last time I checked it wasn’t supported in classic99. That is why I’m using the js99er emulator for development in 80 columns, 30 rows  mode. js99er has full F18a support. You don’t have the great classic99 debugger, but for a lot of things the js99er debugger is sufficient. This may sound strange, but I have tools that work for me and I don't want to learn anything new.

 

Program editing in 80 columns mode (or 40 column mode)

Would it nowadays with the availability of the extended basic source code be easier to implement such feature? I don't think the source code would be helpful for me. I believe that my current thinking might make it possible to use a 40 column editor for T40XB and an 80 column editor for T80XB. Of course, remember that both T40XB and T80XB can run in the normal XB graphics mode, so you could load T40XB, do your editing in 40 (or 80) column mode, then test or run in graphics mode. But not XB256.

Can you share some details on how your development cycle for GEM looks like? What tools do you use? Do you start from the source code or do you patch the existing module? No source code. All the additions have been patches to Gazoo's XB 2.7. I use Classic99 for this with GRAM enable on all 5 groms. All the GPL is hand assembled and saved in a custom assembly language program. When this is assembled and run, it takes the bytes of GPL code and pokes them into the GRAMS. Once the program is working as desired, a custom A/L saver is used to dump the contents of the GROMs and RAM banks to disk. These files are put together using a hex editor, then saved. This works for me, but is very tedious and I would suggest that anyone who is serious about GPL should start by learing how to use a GPL assembler.  Sorry for asking such stupid questions but it’s very interesting to know. On a sidenote , actually the last week I spent quite some time going through the product 359 basic interpreter manual. That is so much fun to read and want to learn and get a better understanding of how the Extended Basic interpreter works.

 

Saving/Loading XB programs in DV80 format (as was planned for the TI-99/8)

I understand. The reason I’m interested in this, is because it was a feature originally planned for the TI-99/8 and because I have written a programming editor Stevie that works with DV80 files, so I figured it would be the easiest for sharing extended basic programs between the two.

To go from DV80 to an XB program you have to convert the code into tokenized XB. The 3 ways I can see would be:

1 - write code that converts the DV80 into tokenized XB. This seems like a lot of work, with potential for many bugs that would  need to be ironed out.

2 - Find a way to use the GROMS/ROMS in the XB cartridge to do this.

3 - You might be able to fool XB with a program that reads the lines of DV80 code from disk, prints them on the screen, then presses Enter with an interrupt routine. XB would handle the code the same as if you had typed it in. This doesn't seem impossible.

Since a long XB line can take several DV80 lines, how are you marking the end of the line? Carriage return?

Actually what I really would like to do is integrate Extended Basic with the editor. Build a custom cartridge image for the final grom that has the (modified) extended basic and also has the programming editor and jump from the editor straight into extended basic and run the program or return from extended basic into the editor.

As the editor is using SAMS and has it’s own SAMS pages I think it would be doable, obviously VDP ram would need to be taken care of. 

You would have to be sure SAMS didn't clash with XB256, T40XB, T80XB, The Missing Link, etc. This might not be a problem - when you are in the editor you are not using XB.
 

 

[RXB]

QUOTE:

"

3 - You might be able to fool XB with a program that reads the lines of DV80 code from disk, prints them on the screen, then presses Enter with an interrupt routine. XB would handle the code the same as if you had typed it in. This doesn't seem impossible.

Since a long XB line can take several DV80 lines, how are you marking the end of the line? Carriage return?"

 

Actually RXB has had this feature built in since 2001 to read DV80 files and run XB programs or command lines into Editor same as you type them in.

Also you do need to put a Carriage Return at end of your intended line just like XB, but you can have really long lines.

RXB Demo showed this and is composed of 10 Videos in row for one DV80 file, each video is 15 minutes max.

 

(1) RXBDEMO1.mov - YouTube

(1) RXBDEMO2.mov - YouTube

(1) RXBDEMO3.mov - YouTube

(1) RXBDEMO4.mov - YouTube

(1) RXBDEMO5.mov - YouTube

(1) RXBDEMO6.mov - YouTube

(1) RXBDEMO7.mov - YouTube

(1) RXBDEMO8.mov - YouTube

(1) RXBDEMO9.mov - YouTube

(1) RXBDEMOA.mov - YouTube

 

Again all this from 1 single DV80 file!

 

Would be a great feature to add to XBGEM

[senior_falcon]

Retroclouds post #432

Quote

Saving/Loading XB programs in DV80 format (as was planned for the TI-99/8)

I'm not sure why this would be desireable. This seems like a huge amount of work for what seems to me to be a trivial improvement in functionality.

I understand. The reason I’m interested in this, is because it was a feature originally planned for the TI-99/8 and because I have written a programming editor Stevie that works with DV80 files, so I figured it would be the easiest for sharing extended basic programs between the two. Actually what I really would like to do is integrate Extended Basic with the editor.

Build a custom cartridge image for the final grom that has the (modified) extended basic and also has the programming editor and jump from the editor straight into extended basic and run the program or return from extended basic into the editor.

As the editor is using SAMS and has it’s own SAMS pages I think it would be doable, obviously VDP ram would need to be taken care of. 

 

It should be possible to save and load programs as DV80 by doing what Rich does or what I suggested in one of the posts above. This would not be exactly what you wanted, which was to go directly from the editor to an XB program or sending an XB program back to the editor. Instead, XB would do most of the heavy lifting. Read a DV80 file, print it on the screen and jump to the editor where Enter is pressed. Or list a program, read it from the screen and save it as DV80.

[senior_falcon]

I just discovered a feature of XB that I had forgotten about (or never knew?)

For many years back in the day I would LIST "PIO" to get a program listing.

Turns out you can also do a LIST "DSK2.PROGRAM" and the program will be saved to disk. This appears to be DV80. The file created can be read with Funnelweb. But a look with a hex editor shows that the lines are not terminated with CR.

The first byte in each line is the length of the line. I believe it is possible to create an XB line that lists using more than 255 characters, and I don't know what would happen in that event.

As mentioned, the lines are not terminated with CR, so RXB CALL USER does not work correctly. If Stevie looks for CR then it would probably not work properly either.

Using Classic99, if you choose "Write DV80 as windows text" then it is saved in a format that can be read with a text editor. The problem here is that there are too many CRs. After every 80 characters there is a CR LF even though there is more to the XB line.

Once the rough edges are ironed out, this looks like it would be useful. Since this is built into XB, if I were to implement something like CALL USER in XB 2.8 G.E.M., I would probably make it compatible so that files saved with LIST could be loaded.

[RXB]

3 hours ago, senior_falcon said:

I just discovered a feature of XB that I had forgotten about (or never knew?)

For many years back in the day I would LIST "PIO" to get a program listing.

Turns out you can also do a LIST "DSK2.PROGRAM" and the program will be saved to disk. This appears to be DV80. The file created can be read with Funnelweb. But a look with a hex editor shows that the lines are not terminated with CR.

The first byte in each line is the length of the line. I believe it is possible to create an XB line that lists using more than 255 characters, and I don't know what would happen in that event.

As mentioned, the lines are not terminated with CR, so RXB CALL USER does not work correctly. If Stevie looks for CR then it would probably not work properly either.

Using Classic99, if you choose "Write DV80 as windows text" then it is saved in a format that can be read with a text editor. The problem here is that there are too many CRs. After every 80 characters there is a CR LF even though there is more to the XB line.

Once the rough edges are ironed out, this looks like it would be useful. Since this is built into XB, if I were to implement something like CALL USER in XB 2.8 G.E.M., I would probably make it compatible so that files saved with LIST could be loaded.

The GPL source code for CALL USER is in RXB GPL source so not much trouble to put it into the GPL of XB GEM, at least you could look at how it works.

SRXB3 and SRXB6 have the code for USER in the source file RXB GPL Source Text in RXB 2020 on AtariAge TI Development.

RXB is FREEWARE so using the code I freely release is fine with me. If you have improvements all the better.

 

[senior_falcon]

19 hours ago, RXB said:

RXB is FREEWARE so using the code I freely release is fine with me.

Thank you! That is very generous of you.

[senior_falcon]

As noted in my post #440 above, LIST "DSK1.PROGRAM" will save a program in DV80 format. The problem is that CR is not appended at the end of a program line. I am investigating ways to do this, but I need a way to be sure it will only happen when listing (saving) to disk.

I need to know what devices can be used when listing. For example:

LIST "PIO"           \

LIST "RS232"        should not have the CR appended

LIST "TP"             /

I can look to see if the name starts with PI, RS, or TP and prevent adding the CR in those cases.

Would it be safe to assume that any other device name would involve saving to disk?

[RXB]

I use this program to convert Text DV80 files from text to USER files that need the CR at end of program lines:

100 ON ERROR 170

110 OPEN #1:"DSK1.MANAGER",INPUT

120 OPEN #2:"DSK1.MEMORY",OUTPUT

130 LINPUT #1:Z$

140 IF LEN(Z$)=80 THEN X$=X$&Z$ :: GOTO 130

150 IF LEN(Z$)<80 THEN PRINT #2:X$&Z$&CHR$(13)

160 X$,Z$="" :: GOTO 130

170 CALL CLSALL

180 END

 

Much quicker then any other way to create batch files.

[senior_falcon]

Making good progress on adding the ability to save and load programs as DV80.

Not quite ready for prime time, but in the video below you can see:

1 - the LOAD program from XBGDP is loaded

2 - lines 100-150 are saved in DV80 format using LIST "DSK1.LOAD100":100-150

3 - NEW and LIST to show there is no program

4 - CALL LOADDV("DSK1.LOAD100") which shows the DV80 file LOAD100 being loaded into memory

5 - The program is listed to show that only lines 100-150 are loaded.

Can this be used with Classic99 saving and loading files in windows format? Of course!

The end result of LOADDV is the same as MERGE. It adds lines of code to whatever program lines are already in memory.

 

Edited August 5, 2021 by senior_falcon

[senior_falcon]

On 7/14/2021 at 2:44 AM, retroclouds said:

Are there any plans for a future XB 2.9 G.E.M ?

 

Things I could think of:

• Support for the f18a 80x30 rows mode
• Program editing in 80 columns mode
• Saving/Loading XB programs in DV80 format (as was planned for the TI-99/8)

 

 

Here is XB 2.8 G.E.M. version 2.820210815.

XB28GEM20210815.zip

This addresses Retrocloud's third request.

 

To save a program in DV80 format:

LIST "DSK1.PROGRAM"

To save just lines 100-150 of a program in DV80 format:

LIST "DSK1.PROGRAM100":100-150

To save from the beginning to line 100 in DV80 format:

LIST "DSK1.PROGTO100":-100

You can also use a text editor to create a program and save it as a windows .TXT file. Be sure there is a CR at the end of each program line.

 

To load a program in DV80 or .TXT format:

CALL DV2XB("DSK1.PROGRAM")   or   CALL DV2XB("DSK1.PROGRAM.TXT")

 

If using Classic99, be sure your actions match the disk configuration. 

If you have set up the disk to "Write DV80 as Windows Text"  be sure to append a .TXT to the file name.

If using a real TI the windows .TXT option is not possible.

 

If you have added XB 2.8 G.E.M. to the classic99.ini file note that a change needs to be made

[usercart1]     (I have another cart which is usercart0)
name=XB 2.8 G.E.M
rom0=G|6000|A000|CARTS\XB28GEM_G.BIN   
rom1=8|0000|24000|CARTS\XB28GEM_8.BIN   

 

Except for the README file I have not updated the documents for this yet.

 

Edited August 16, 2021 by senior_falcon

[+retroclouds]

Thank you for your hard work on this. It is much appreciated. Looking forward doing tests and experiments.

We’re currently renovating the house, so TI hobby time is very limited at this time. Might take a bit for me to reply.

 

Anyway do have some plans for this one. Could imagine writing a GPL DSR (think mini memory style) that exposes the Stevie editor buffer in SAMS as DV80 file. Jump from Stevie straight into GEM where you can then load with CALL DV2XB(“STV.1”) 

(1 means Stevie editor buffer #1)

[senior_falcon]

I have been experimenting with the possibility of incorporating an 80 or 40 column editor with XB 2.8 G.E.M.

The short GIF below shows a very preliminary version of this. The editor is quite rudimentary, but it is enough for testing. The main challenge is to interface seamlessly with XB. The video below shows a one line program being entered, and then it is run.

Many challenges remain. For example, you must be able to LIST a program, and commands such as PRINT X must be usable.

It is by no means certain how much of this will be possible, but this is at least one step along the way.

Edited August 20, 2021 by senior_falcon

[+OLD CS1]

Quite an advancement!

[+retroclouds]

3 hours ago, senior_falcon said:

I have been experimenting with the possibility of incorporating an 80 or 40 column editor with XB 2.8 G.E.M.

The short GIF below shows a very preliminary version of this. The editor is quite rudimentary, but it is enough for testing. The main challenge is to interface seamlessly with XB. The video below shows a one line program being entered, and then it is run.

Many challenges remain. For example, you must be able to LIST a program, and commands such as PRINT X must be usable.

It is by no means certain how much of this will be possible, but this is at least one step along the way.

That is simply Amazing!