Extended BASIC G.E.M.

[senior_falcon]

Making good progress. Here is the experimental 80 column editor for GEM listing a program. It hangs up at the last line, so that will need some work with the debugger  to find out why. Listing in 80 columns is about 80% as fast as lising in standard XB. XB GEM  first lists to the XB 32 column screen, then copies the program lines to the 80 column screen. There are a few tweaks that can be made to speed it up, but it can never be quite as fast as in normal XB

[senior_falcon]

The crash at the last line has been fixed.

You may have noticed that each line number is preceded by the "greater than" symbol. This way the editor can know where a line begins and ends. The intention is to let you list a program, then you can go up on the screen to edit any line that appears on the screen.

[+OLD CS1]

4 minutes ago, senior_falcon said:

You may have noticed that each line number is preceded by the "greater than" symbol. This way the editor can know where a line begins and ends. The intention is to let you list a program, then you can go up on the screen to edit any line that appears on the screen.

Interesting.  Does the normal editor use the ">" symbol for the same purpose?  How does it employ the edge character (char 31?)

[senior_falcon]

46 minutes ago, OLD CS1 said:

Interesting.  Does the normal editor use the ">" symbol for the same purpose?  How does it employ the edge character (char 31?)

I believe the ">" symbol is used by XB as a pointer to tell you to "enter something here". When you list a program it is expected that you will not be entering anything until you are done with the list. So there is no symbol at the beginning of each line. This makes it tough to know where a line begins and ends. You could make inferences based on the length of the line, whether the first characters are numbers, etc. But you could imagine a line that splits a number like this:

100 some code::GOTO 12

345

The editor would have to know that the instruction was GOTO 12345, not GOTO 12. Doing this would take a lot of code and would probably be buggy. My way should be bulletproof.

 

When the BASIC or XB editor comes to an edge character it knows that it must add 4 or subtract 4 to get to the next line. There are other ways to do that. For example, if you are going right, you could AND the screen position with >1F and see if the result is >1E. If it is you have to add 4 to the screen position.

[+OLD CS1]

I like the idea of turning the XB editor to work more like the CBM BASIC editor, in which you can cursor up to any previous line or command on the screen to edit or re-execute it.  This is bad-ass.

[senior_falcon]

The experiments with the 80 column editor are coming along nicely. At present I can:

     Enter program lines

     List a program

     Edit a program line  (line number and up or down arrow)

     Use Fctn 8 for the Edit/Recall buffer

     Save and load programs.

 

Yet do do:

   Transfer information from XB to the 80 column editor such as:

     Error messages

     printing a variable (PRINT X)

 

I have some ideas on how to do this that I think will work.

 

Once the editor can interface well with XB it will be time to add features to the editor., which is quite rudimentary at present.

 

 

[senior_falcon]

It looks like this will work out. In the video below, I:

Enter a program

LIST the program

RUN the program

Modify the program

RUN the modified program

Type SIZE

Type PRINT I

 

[+retroclouds]

That is very impressive. Looks like listing the program is faster too, compared to the previous version.

Is the edit80 mode completely driven by the interrupt service routine?

Could the same be possible for TI Basic as well, or is it custom tailored for Extended Basic G.E.M. ?

[senior_falcon]

4 hours ago, retroclouds said:

That is very impressive. Looks like listing the program is faster too, compared to the previous version.

Is the edit80 mode completely driven by the interrupt service routine?

Could the same be possible for TI Basic as well, or is it custom tailored for Extended Basic G.E.M. ?

The program listing hasn't changed. The lines are shorter so they show up faster.

No interrupts are used in this. There are a couple of patches out of XB to the editor, so I have much better control over what is going on.

This would be pretty tough for TI Basic. One possibility is using a 40 column editor. There is room for development in MiniMemory. There are about 1300 or so bytes of unused memory in the ROM.

[senior_falcon]

I have been plugging away at the 40 and 80 column editors. At present:

CALL EDIT40   changes to the 40 column editor

CALL EDIT80   changes to the 80 column editor

CALL EDIT32   returns to the normal 32 column editor

In the 40 and 80 column editors you can:

go up/down on the screen to edit any line, not just the one at the bottom of the screen

go right/left on the screen

go right or left to the next statement in the line

delete and insert as usual.

 

Yet to do:

change Fctn 3 to delete from the cursor to end of line and copy the deleted text to the edit/recall buffer.

add Ctrl 3 to delete just one program statement and copy the deleted statement to the edit/recall buffer

change Fctn 8 to paste contents of the edit recall buffer wherever desired

Edited November 5, 2021 by senior_falcon

[+retroclouds]

On 11/5/2021 at 4:30 PM, senior_falcon said:

I have been plugging away at the 40 and 80 column editors. At present:

CALL EDIT40   changes to the 40 column editor

CALL EDIT80   changes to the 80 column editor

CALL EDIT32   returns to the normal 32 column editor

In the 40 and 80 column editors you can:

go up/down on the screen to edit any line, not just the one at the bottom of the screen

go right/left on the screen

go right or left to the next statement in the line

delete and insert as usual.

 

Yet to do:

change Fctn 3 to delete from the cursor to end of line and copy the deleted text to the edit/recall buffer.

add Ctrl 3 to delete just one program statement and copy the deleted statement to the edit/recall buffer

change Fctn 8 to paste contents of the edit recall buffer wherever desired

 

How are the 32/40/80 column editors going? Really looking forward to the 80 column editor.

[senior_falcon]

11 hours ago, retroclouds said:

 

How are the 32/40/80 column editors going? Really looking forward to the 80 column editor.

I will try to work on this in the near future.

[senior_falcon]

On 11/5/2021 at 11:30 AM, senior_falcon said:

I have been plugging away at the 40 and 80 column editors. At present:

CALL EDIT40   changes to the 40 column editor

CALL EDIT80   changes to the 80 column editor

CALL EDIT32   returns to the normal 32 column editor

In the 40 and 80 column editors you can:

go up/down on the screen to edit any line, not just the one at the bottom of the screen

go right/left on the screen

go right or left to the next statement in the line

delete and insert as usual.

 

Yet to do:

change Fctn 3 to delete from the cursor to end of line and copy the deleted text to the edit/recall buffer.      Done

add Ctrl 3 to delete just one program statement and copy the deleted statement to the edit/recall buffer      Done

change Fctn 8 to paste contents of the edit recall buffer wherever desired

Coming along nicely. There are probably a few nuances on Fctn 3 and Ctrl 3 that are yet to be addressed. I will check that out thoroughly, then change Fctn 8.

Of course, then there must be another screen in CALL HELP to explain the new editing features.

[senior_falcon]

At this point the editor works to my satisfaction.

Fctn 3 deletes from the cursor to the end of the line and copies the deleted text to the edit/recall buffer

Ctrl 3 sends the cursor left to the first character after a double colon, or to the first non space after a line number. It deletes from that position to the 2nd colon in a double colon, or to the last character in the line and copies the deleted text to the edit recall buffer

Fctn 8 inserts the copied characters in a program line starting at the cursor position. (To the end of the line if the cursor is at the end.)

Ctrl 8 is similar, but sends the cursor left to the first character after a double colon, or to the 2nd character after a line number before inserting the text.

You can copy/paste a program statement by navigating to the statement on the screen. Press Ctrl 3 to delete and copy to the edit/recall buffer, then Ctrl 8 to restore the deleted characters. Now that the code is in the edit/recall buffer you can navigate to any position on the screen and use Ctrl 8 to paste the program statement. You can do this multiple times as needed.

 

So far the test code is running in ram. The task now is to integrate this into the G.E.M. roms to make a nice smooth package.

Edited January 26, 2022 by senior_falcon

[+RXB]

On 8/22/2021 at 8:08 PM, senior_falcon said:

I believe the ">" symbol is used by XB as a pointer to tell you to "enter something here". When you list a program it is expected that you will not be entering anything until you are done with the list. So there is no symbol at the beginning of each line. This makes it tough to know where a line begins and ends. 

Sorry just to confirm this is not correct the ">" symbol does not matter at all, it could be replaced with "?" or "@" or "^" 

with no effects on XB working. It is a flag for the user they could have picked any token.

<0275> 641E 0F,83    TOPL35 XML  SCROLL            Scroll the screen
<0276> 6420 BE,A2,E1 G6420  ST   >9E,V@NLNADD-1    Display the prompt character
       6423 9E
<0277> 6424 06,6A,76        CALL G6A76             Read in a line
<0278> 6427 06,D0,AF        CALL SAVLIN            Save input line for recall   
<0279>               *    Crunch the input line
<0280> 642A 86,22           CLR  @ERRCOD           Assume no-error return
<0281> 642C BF,0A,08        DST  CRNBUF,@RAMPTR    Initialize crunch pointer
       642F 20
<0282> 6430 0F,7F           XML  CRUNCH            CRUNCH the input line
<0283> 6432 00              BYTE 0              *  Normal crunch mode

G6A76 does not even care about the ">" and SAVLIN does not either as that is taken from EDIT BUFFER.

The CRUNCH buffer also does not care about the ">" either.

 

Not that it matters as G.E.M. works fine. Just wanted everyone to know you do not need to worry about the ">"

[senior_falcon]

On 8/22/2021 at 11:08 PM, senior_falcon said:

I believe the ">" symbol is used by XB as a pointer to tell you to "enter something here". When you list a program it is expected that you will not be entering anything until you are done with the list. So there is no symbol at the beginning of each line. This makes it tough to know where a line begins and ends. 

Sorry just to confirm this is not correct the ">" symbol does not matter at all, it could be replaced with "?" or "@" or "^" 

with no effects on XB working. It is a flag for the user they could have picked any token.

 

I suppose a better choice of words would have been to use the word "prompt" instead of "pointer."  Regardless of that, in what way was what I wrote wrong? True, the developers of XB could have used "?" or "@" or "^" or any other character as a prompt. But here's the thing. THEY DIDN'T. 

 

G6A76 does not even care about the ">" and SAVLIN does not either as that is taken from EDIT BUFFER.

The CRUNCH buffer also does not care about the ">" either.

Not that it matters as G.E.M. works fine. Just wanted everyone to know you do not need to worry about the ">"

 

I would bet that no one lost a wink of sleep stressing out about the ">".

 

From your comments it is clear that you do not understand the point of posts 453 to 455 above. G.E.M. will allow the user to edit any line, anywhere on the screen. If you have entered the lines they will automatically have the ">" prompt at the beginning of each line. If you LIST the program, with any other XB there is no input prompt at the beginning of each line. G.E.M. changes that by adding the prompt for each line and that way the editor knows where the line begins and ends.

[+RXB]

2 hours ago, senior_falcon said:

Sorry just to confirm this is not correct the ">" symbol does not matter at all, it could be replaced with "?" or "@" or "^" 

with no effects on XB working. It is a flag for the user they could have picked any token.

 

I suppose a better choice of words would have been to use the word "prompt" instead of "pointer."  Regardless of that, in what way was what I wrote wrong? True, the developers of XB could have used "?" or "@" or "^" or any other character as a prompt. But here's the thing. THEY DIDN'T. 

 

G6A76 does not even care about the ">" and SAVLIN does not either as that is taken from EDIT BUFFER.

The CRUNCH buffer also does not care about the ">" either.

Not that it matters as G.E.M. works fine. Just wanted everyone to know you do not need to worry about the ">"

 

I would bet that no one lost a wink of sleep stressing out about the ">".

 

From your comments it is clear that you do not understand the point of posts 453 to 455 above. G.E.M. will allow the user to edit any line, anywhere on the screen. If you have entered the lines they will automatically have the ">" prompt at the beginning of each line. If you LIST the program, with any other XB there is no input prompt at the beginning of each line. G.E.M. changes that by adding the prompt for each line and that way the editor knows where the line begins and ends.

Yea prompt would be kind of spot on. As the cursor is flashing on the screen the need for ">" is superfluous.

[senior_falcon]

The short video below shows how the editor in G.E.M. lets you edit anywhere on the screen.

It starts out in the normal 32 column mode. CALL EDIT40 puts it in the 40 column mode. The LOAD program from XBGDP is already loaded.

You can go up/down a program line using "Ctrl I" and "Ctrl M". I go up to line 160.

You can tab left/right a program statement usint "Ctrl J" and "Ctrl K". I tab through the program statements to the end of line 160, then tab back till I get to CALL CLEAR.

"Ctrl 3" deletes CALL CLEAR, then "Ctrl 8" restores it. (You have to press Enter or up/down for the change to a line to take effect, so Ctrl 8 is not really needed here)

I use "Ctrl M" to go down to line 190, use "Ctrl K" to tab over one program statement and paste in CALL CLEAR using "Ctrl 8", then press Enter.

I list line 190 to show the line has actually been changed.

Then I change the color and font to white on blue and font 2, then CALL EDIT80 changes to the 80 column editor.

Quit, then select XB and you will see the color/font changes and 80 column mode are still active.

 

 

 

[+retroclouds]

2 hours ago, senior_falcon said:

The short video below shows how the editor in G.E.M. lets you edit anywhere on the screen.

It starts out in the normal 32 column mode. CALL EDIT40 puts it in the 40 column mode. The LOAD program from XBGDP is already loaded.

You can go up/down a program line using "Ctrl I" and "Ctrl M". I go up to line 160.

You can tab left/right a program statement usint "Ctrl J" and "Ctrl K". I tab through the program statements to the end of line 160, then tab back till I get to CALL CLEAR.

"Ctrl 3" deletes CALL CLEAR, then "Ctrl 8" restores it. (You have to press Enter or up/down for the change to a line to take effect, so Ctrl 8 is not really needed here)

I use "Ctrl M" to go down to line 190, use "Ctrl K" to tab over one program statement and paste in CALL CLEAR using "Ctrl 8", then press Enter.

I list line 190 to show the line has actually been changed.

Then I change the color and font to white on blue and font 2, then CALL EDIT80 changes to the 80 column editor.

Quit, then select XB and you will see the color/font changes and 80 column mode are still active.

 

 

That's how Extended Basic on the 99/8 should have looked like. Well done! ?

[+Vorticon]

This is outstanding work. Direct full-screen editing of XB programs in 80 columns is a dream come true. Any limitations to know about?

[senior_falcon]

10 hours ago, Vorticon said:

This is outstanding work. Direct full-screen editing of XB programs in 80 columns is a dream come true. Any limitations to know about?

There are probably a few minor things. TRACE does not work when using EDIT40 and EDIT80. So you'd need to CALL EDIT32, then TRACE and run the program. Undoubtedly there are other minor problems, but if needed, you can always CALL EDIT32 and you are in the normal XB editor.

It shouldn't be a problem when using T40XB or T80XB, but when using standard XB or XB256, there will (rarely) be times when you cannot continue a program after breaking.

Once this is released I'm sure you guys will find more.

Edited January 28, 2022 by senior_falcon

[Victor]

Working with XB28GEM20210815, renamed and loaded onto SD card for Finalgrom99.  TI console, P-box, 32k.  Typed in program from page 14, post #327, by senior falcon, to demonstrate XB256, T40, T80, and TML.  Syntax error in line 31, where FOR, CALL LINK("PRINT"), and NEXT are on one multi-statement line.  Retyped program to put them all on separate lines.  Runs.  If the program crashes from syntax error, if I try to EDIT any lines, XB256 refuses to let me, get garbled statements, etc.

Edited January 30, 2022 by Victor
incorrect statement

[senior_falcon]

I don't have any problems like that using Classic99. I intentionally made a syntax error while in XB256 and it worked as expected. I don't have any good way to test on a real ti99.

[+arcadeshopper]

I don't have any problems like that using Classic99. I intentionally made a syntax error while in XB256 and it worked as expected. I don't have any good way to test on a real ti99.

Do you need me to send you a finalgrom99?

Sent from my Pixel 6 Pro using Tapatalk

[Victor]

My Finalgrom99 runs many .bin files fine, except for RXB version 2021, some instability.  I have run Jedimatt42's 32k Expansion Memory Test ver 1.3, no problems.  GEM works fine if I rewrite the programs to eliminate multi-statement lines with the PRINT in the middle.  Still have scrambled lines when LISTing after a crash.  LISTing again straightens it out.  While EDITing a line, making and change and pressing ENTER gives SYNTAX ERROR (!).  I have to list the line, edit it, and arrow down to next line to get it accepted.  I could make a video . . .

Edited January 30, 2022 by Victor
additonal information