Extended BASIC G.E.M.

[senior_falcon]

On 2/10/2022 at 5:43 PM, senior_falcon said:

On 1/29/2022 at 10:24 PM, Victor said:

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.

Still no feedback on whether this problem is unique to Victor. Be sure to use the files in post #480.

I am reluctant to release XB 2.9 G.E.M. until i know whether this problem lies with Victor's setup or if it is a problem with GEM. As far as I know, GEM works with the Finalgrom, but I would like someone to verify that.

[twoodland]

On 2/10/2022 at 5:43 PM, senior_falcon said:

Still no feedback on whether this problem is unique to Victor. Be sure to use the files in post #480.

 

FYI - TI-99/4A Beige Console (Not QI), F-18a, TIPI, Sidecar SAMS, FG99 - I had a problem loading using the filenames TESTXB28GEM_G.BIN, TESTXB28GEM_8.BIN (blank cyan screen). I renamed them XB28GEMG.BIN, XB28GEMC.BIN, it loaded and the demo ran successfully.

[senior_falcon]

Thank you! That information is in the "Readme" file in the XB 2.8 G.E.M. docs, but I forgot to include it in post #480.

Anyone else have success/problems with this?

[HOME AUTOMATION]

Having failed to read post #502, I did the same thing, and had similar results.

I didn't run the demo, but all 8, selections seemed to work.

[senior_falcon]

On 2/22/2022 at 1:35 PM, twoodland said:

FYI - TI-99/4A Beige Console (Not QI), F-18a, TIPI, Sidecar SAMS, FG99 - I had a problem loading using the filenames TESTXB28GEM_G.BIN, TESTXB28GEM_8.BIN (blank cyan screen). I renamed them XB28GEMG.BIN, XB28GEMC.BIN, it loaded and the demo ran successfully.

Was the demo the one that gave Victor trouble? The XB program can be found on page 14, post #327.

Thanks!

Edited February 23, 2022 by senior_falcon

[twoodland]

4 hours ago, senior_falcon said:

Was the demo the one that gave Victor trouble? The XB program can be found on page 14, post #327.

Thanks!

Correct.  Page14, post #327.  It ran successfully.

[senior_falcon]

Good enough for me. I don't know what Victor's problem was, and he seems to have gone AWOL.

 

Here is XB 2.9 G.E.M. version 2.920220202

Here is XB 2.9 G.E.M. version 2.920220311

XB29GEM20220311.zip

 

 

From the manual:

TEXT MODE PROGRAMMING EDITOR

XB 2.9 G.E.M. now has the ability to edit an Extended BASIC program using the 40 column and the 80 column text mode. (80 columns requires the Classic99 emulator or an 80 column card for the TI expansion box.) The new text mode editor lets you edit a line anywhere on the screen, not just on the botom row.

CALL EDIT32     selects the standard 32 column editing mode. (default)
CALL EDIT40     lets you edit in the 40 column text mode.
CALL EDIT80     lets you edit in the 80 column text mode.
The edit mode you choose is retained after a “quit”

 

Keys usable in EDIT32, EDIT40, and EDIT80:
Fctn S and Ctrl S     cursor left one column
Fctn D and Ctrl D     cursor right one column
Fctn E         edit previous line in program
Fctn X         edit next line in programming
Ctrl E          cursor up one row. If on the first row then to the beginning of the line
Ctrl X          cursor down one row. If on the last row then to the end of the line.
Fctn 1 (and Ctrl 1 text mode)     delete character at the cursor (same as normal XB)
Fctn 2 (and Ctrl 2 text mode)     set insert mode (same as normal XB)
The other editing keys such as Enter, Up, Down, Fctn 4 etc. work the same in all 3 modes.

 

Full screen editing in EDIT40 and EDIT80
When editing in the text mode you are no longer restricted to editing text on the bottom line of the screen. Any line marked with a > can be edited.

Keys used for full screen editing
Ctrl I        cursor up the screen to the beginning of the previous line marked by >.
Ctrl M       cursor down the screen to the beginning of the next line marked by >.
Ctrl J        cursor right to the next program statement after double colon, or the end of the line.
Ctrl K       cursor left to the previous program statement after double colon, or the start of the line.

Normally in XB, Fctn 8 is used to paste previously entered text on the screen. Because you can edit anywhere on the screen, this is not needed in the text mode editor, so the functions of Ctrl 3, Fctn 3, Ctrl 8, and Fctn 8 have been modified.

Ctrl 3         deletes the program statement the cursor is flashing on. AND copies to the edit/recall buffer. If necessary, the cursor goes left to the first character after a double colon or the first character after the line number. The deletion goes to the second colon in a double colon or the end of the line.
Fctn 3        deletes characters from cursor to end of program line. AND copies to the edit/recall buffer.
Ctrl 8         inserts contents of edit recall buffer after the double colon. If necessary, the cursor goes left to the first character after a double colon or the first character after the line number.
Fctn 8        inserts contents of the edit/recall buffer at the cursor.
When you paste using Ctrl 8 and Fctn 8, the characters are inserted at the cursor. They do not overwrite any text on the screen.

To copy/paste

Press Ctrl 3 or Fctn 3 to copy characters into the edit/recall buffer. This also erases those characters from the screen. Immediately press Ctrl 8 or Fctn 8 to restore the characters to the screen. The characters are still in the edit/recall buffer.
Navigate to the desired location on the screen using the arrow keys. Then Ctrl 8 or Fctn 8 will paste the contents of the edit/recall buffer onto the screen.  Repeat as desired.

After you have entered or changed a line, it will only be saved if you press Enter or the up/down arrow keys. If you make a mistake and want to “bail out”, Fctn 4 will do the trick.

The text mode editor uses a screen located in VDP ram at >1000. It communicates with XB by copying characters between the usual 28 column editing screen and the text mode screen.     When it detects a cursor on the 28 column screen, XB goes to the text mode editor  Any characters you type are copied to the normal XB editor when you press Enter/up/down. Once there, the characters are processed as if you had entered them using the 28 column editor. When the cursor reappears, control is again passed to the text mode editor. When you LIST a program, XB puts the lines on the normal 28 column screen. Once each line has been printed, XB copies it to the text mode screen. Naturally, transferring characters between the two screens incurs a speed penalty, but it is only about 20%.

Almost everything will work properly from the text mode editor. But, it is important to know that the text mode screen is located in the middle of the VDP stack, and XB knows nothing about it. This can lead to some unexpected behavior. When you load a program of any significant length, garbage may appear on the text mode screen. It remains there until XB copies the program to the 32K memory, then the screen is cleared. You can RUN a program from the text mode editor, but CON has been blocked to avoid a possible memory clash between the VDP stack and the text mode editor screen. After a program breaks, you should be able to print numeric variables (which are kept in CPU ram), but printing a string variable may be incorrect.

After you press enter/up/down, control does not return to the text mode editor until the cursor reappears on the 28 column screen. This can lead to some pauses, sometimes lengthy. A line like this will work fine, but you cannot see the results until it has finished: FOR I=1 TO 20::PRINT I;SQR(I)::NEXT I

These limitations should not be a problem when entering and editing a program. But debugging may be easier if done using EDIT32. You can switch between the editors as desired at any time.

 

SAVE A PROGRAM IN DV80 FORMAT
LIST “DSKn.FILE” saves a program in DV80 format or .TXT format.
Unlike normal XB, you do not have to save the entire program.
LIST “DSK1.TEST”:100-150    Saves lines 100 to 150 to disk 1 as the file “TEST”
LIST “DSK1.TEST1”:200-        Saves lines 200 and above to disk 1 as the file “TEST1”
With Classic99 you can configure the disk to “Write DV80 as Windows Text.” There will be an extra carriage return at the end of each line, but this should cause no problems.

 

LOAD A PROGRAM IN DV80 FORMAT
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 program. Lines are replaced if they have the same line number as an existing line.
With Classic99 you can configure the disk to “Read Windows Text as DV files.”

 

 

Edited March 11, 2022 by senior_falcon

[+retroclouds]

Thank you so much for releasing XB GEM 2.9

Looking forward playing around with the new editors and as important, trying the DV2XB routine. 

 

[senior_falcon]

If your system does not have 80 column support then CALL EDIT80 will probably crash it. (At least it does in Classic99) I had hoped you could type CALL EDIT32 to reset the editing mode but that doesn't seem to work. You can quit to the master title screen, but XB 2.9 remembers the editing mode you were in and uses that on startup, which of course will crash the computer again. A cold reset, or turning off the computer, will reset to the default 32 column editor.

 

Is there a foolproof way for software to know whether a system has 80 column capabilities? With that information I could block CALL EDIT80 and avoid this

[senior_falcon]

I should add that, if you are like me, you have trouble remembering what the keys do when editing. CALL HELP brings up the help menu and the third page has that information.

[Tursi]

18 hours ago, senior_falcon said:

With Classic99 you can configure the disk to “Write DV80 as Windows Text.” There will be an extra carriage return at the end of each line, but this should cause no problems.

The read should be on by default, but I will again warn caution to setting the write option. Windows text is not binary - so if the program is storing anything /but/ text in a DV80 file, it will be corrupted. For one-off uses like a listing file, use the ?W option rather than changing the emulator configuration.

 

Unless you know what you're doing and take responsibility for the result, I recommend LIST "DSKn.?W.FILE" over changing the write DV80 option.

 

[Asmusr]

On 2/24/2022 at 5:03 AM, senior_falcon said:

Here is XB 2.9 G.E.M. version 2.920220202

I'm so impressed. I added 2.9 to https://js99er.net

Edited February 25, 2022 by Asmusr

[+mizapf]

Here's the RPK.

extended_basic_29_gem.rpk

[senior_falcon]

On 2/24/2022 at 5:43 PM, Tursi said:

The read should be on by default, but I will again warn caution to setting the write option. Windows text is not binary - so if the program is storing anything /but/ text in a DV80 file, it will be corrupted. For one-off uses like a listing file, use the ?W option rather than changing the emulator configuration.

 

Unless you know what you're doing and take responsibility for the result, I recommend LIST "DSKn.?W.FILE" over changing the write DV80 option.

 

I have never had any trouble when changing the configuration. But, it is certainly true that Tursi knows way more about Classic99 than anyone else on the planet. If he says do it a certain way, don't bother asking why, just do it that way! I will revise the docs.

Realistically, when using Classic99, it's probably easier to just LIST "CLIP", then paste into a text editor and save from there. Or edit the program and paste back into Classic99 with "Paste XB"

 

 

That brings up another good point.

LIST “DSKn.FILE”  should only be used to save ascii characters from 32 to 127. i.e. displayable characters.

CALL DV2XB(filename) should only load characters that can be entered into an XB from the keyboard. Ascii 32 to 127 will be safe. Some people have saved characters above 127 in a data statement using control key combinations. That may (or may not) work when LISTing to disk or loading with CALL DV2XB.

Because DV2XB works by making XB think you have typed in the program lines, any embedded assembly code will NOT be saved when LISTing to disk.

 

Edited February 26, 2022 by senior_falcon

[Tursi]

3 hours ago, senior_falcon said:

I have never had any trouble when changing the configuration. But, it is certainly true that Tursi knows way more about Classic99 than anyone else on the planet. If he says do it a certain way, don't bother asking why, just do it that way! I will revise the docs.

Realistically, when using Classic99, it's probably easier to just LIST "CLIP", then paste into a text editor and save from there. Or edit the program and paste back into Classic99 with "Paste XB"

Hehe, we had this discussion a few years ago. Pretty much everything you do is with text, and it's more convenient for you to work this way. But Classic99 can't tell the difference between a DV80 intended to contain text and a DV80 intended to contain binary data. I can't think of an example right now, but the back of my mind tells me someone actually had a problem with this - although they might have checked "write ALL DV as text".

 

Anyway, if binary data is written to a Windows text file, when it's read back in, it will be interpreted as a Windows text file. Control codes may or may not be stripped, and certainly embedded bytes of value 13 or 10 may be interpreted as line endings, whether or not they should be. In short, you won't get back what you wrote out.

 

I'm not afraid to give a user the power to cut off their own foot...

 

I have to admit that even I LIST "CLIP" a lot... but it IS actually faster to LIST "DSK1.?W.FILENAME.TXT", and only takes one step too. More keystrokes, though. Perceived ease versus actual ease, I guess.

 

[+OLD CS1]

8 hours ago, Tursi said:

I have to admit that even I LIST "CLIP" a lot... but it IS actually faster to LIST "DSK1.?W.FILENAME.TXT", and only takes one step too. More keystrokes, though.

At the risk of sounding like a fanboy for Classic99, I would say that the CLIP device deserves a major award for being exceptionally innovative.  LIST "CLIP" then CTRL-V into something.  So easy a caveman can do it.

 

So, here ya go.

[ThePrez]

Gentlemen, I installed every variation of GEM on my FinalGrom99 SD card in separate folders.  The files I used are: 20210506, 20210712, 20210815, 20220202, and TESTSB28.  ALL of them failed to run the "GEMDEMO" on page 14.  The problem is the line with: FOR...PRINT...NEXT.  They run if those commands are on separate lines.  Am I the only one with a physical TI having this problem?  If so, I can only conclude that my FG99 is bad.

GEM TML works fine, but crashes with the old TMLDEMO program that calls fonts from disk.  If someone could rewrite that program to use the built-in fonts it would be a great tutorial.

[senior_falcon]

Victor, back in post #472 had the same problem.

In post #502, twoodland wrote:

FYI - TI-99/4A Beige Console (Not QI), F-18a, TIPI, Sidecar SAMS, FG99 - I had a problem loading using the filenames TESTXB28GEM_G.BIN, TESTXB28GEM_8.BIN (blank cyan screen). I renamed them XB28GEMG.BIN, XB28GEMC.BIN, it loaded and the demo ran successfully.

Have you done that?

 

[senior_falcon]

On 3/3/2022 at 9:29 PM, ThePrez said:

Gentlemen, I installed every variation of GEM on my FinalGrom99 SD card in separate folders.  The files I used are: 20210506, 20210712, 20210815, 20220202, and TESTSB28.  ALL of them failed to run the "GEMDEMO" on page 14.  The problem is the line with: FOR...PRINT...NEXT.  They run if those commands are on separate lines.  Am I the only one with a physical TI having this problem?  If so, I can only conclude that my FG99 is bad.

Turns out you're not crazy. Victor just sent me his copy of GEMDEMO that was misbehaving. When you list it there is nothing to be seen, all looks as it should. But it turns out that somehow a few extra characters have been appended to two lines.

At the end of line 31 there are three characters that look like colons. At the end of line 100 there is one of these characters.

These are ASCII >6D which is (probably) the carriage return (>0D) and the XB offset of >60. Both will lead to error messages as you discovered.

It should not be possible for that character to be entered from the keyboard.

So naturally the question is: "How the heck are they getting there???????"

Any ideas?

They are invisible in the 32 column editor, but if you CALL EDIT40 they will appear as shown in the picture.

Can you describe in detail the process you used in entering the program. Also a description of your TI99 setup. Even the smallest detail might be the clue needed to solve this mystery. Since you had this problem with earlier versions of G.E.M., it doesn't seem to be caused by the text mode editors.

If you are in the EDIT32 mode you can add this line: 1 CALL COLOR(30,16,16)::GOTO 1 and the characters will turn white.

Edited March 5, 2022 by senior_falcon

[senior_falcon]

Has anyone been able to duplicate this problem? In theory this is not possible, but Victor was able to do it and it looks like ThePrez did it as well. I'd like to know how this happens so I can find a way to block it.

[senior_falcon]

On 1/30/2022 at 1:13 PM, Victor said:

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 . . .

Yes, please make a video.

[senior_falcon]

I have made a couple of minor changes to XB 2.9 G.E.M.

To try to address the issues encountered by Victor and ThePrez I did the following:

1 - I have made it so you cannot enter characters from 0 to 31 directly from the keyboard. This matches standard XB behavior. (I meant to do that earlier, but must have forgot.)

2 - Colors are preloaded into the 15 unused character sets from 160 to 255 and  from 0 to 23.

Now the spurious bytes that were causing trouble in Victor's test program will light up so you can see them and know there is an issue to be corrected. You must use EDIT32 to see these.

I still have no idea how it was possible to enter them.

 

(Edit March 19) The changes mentioned above did not completely fix Victor's problem. Use the latest version posted on page 22, post #528.

Edited March 20, 2022 by senior_falcon

[senior_falcon]

Victor's program. You can clearly see the extra characters now.

 

[senior_falcon]

At last I was able to duplicate Victor's problem. if you enter:

10 FOR I=1 TO 9::PRINT I;::NEXT I

20 REM

RUN             it runs fine

LIST "CLIP"   or any other list to a device or even LIST ""

10            then down arrow to edit. Line 10 is listed with a gray square at the end.

Press F, then ENTER      because a key has been pressed XB thinks a change has been made. Line 10 is saved with the extra character,

RUN           and you get the error message "NEXT WITHOUT FOR IN 10"

 

Please try everything you can think of to see if there are other circumstances that cause this behavior.

 

As a stop gap measure, if you press 10 and down arrow you see the extra gray character. Down arrow, then up arrow and you will be at 10 but without the extra character.

This is happening in the XB rom, but obviously it is my code that is somehow causing the problem.

 

 

 

[Willsy]

My guess would be some sort of off-by-one error on the line length somehow.