Extended BASIC G.E.M.

[senior_falcon]

Just want to be sure you did PEEKV and POKEV

CALL POKEV(16111,99,99)

Use the disk for a while and then quit.

CALL PEEKV(16111,A,B)::PRINT A;B

[DavidC]

30 minutes ago, senior_falcon said:

Just want to be sure you did PEEKV and POKEV

CALL POKEV(16111,99,99)

Use the disk for a while and then quit.

CALL PEEKV(16111,A,B)::PRINT A;B

Yes sir.  Call POKEV(16111,99,99) ,  ran the nano, loaded games, mounted different disks to volume 1, loaded programs, saved programs, quit out back to Title Screen.  Loaded XB2.8,       CAll PEEKV(16111,A,B)  values are:  76 and 49.

[senior_falcon]

It's a long shot, but you could try CALL POKEV(16111,99,99,99,99,99,99) and then CALL PEEKV(16111,A,B,C,D,E,F)::PRINT A;B;C;D;E;F in the unlikely event that there are 2 consecutive bytes that are untouched. 

 

[DavidC]

Ok, loading, saving, mounting different disks, ect.   Call PEEKV values are:  76 49 32 32 32 32

[senior_falcon]

Not surprised. Too bad, I had a fix all figured out if that was a usable memory location.

I have a memory location that is under my control that can be used. It will require more changes to the code but should be workable.

And of course I can make another one that zeros out cpu ram from -24 to -1. Not the best because you have to reload your custom font and colors after a quit.

[senior_falcon]

I guess it's best not to assume anything with this pesky problem. For all I know this thing splatters random bytes throughout memory when it starts up. 

 

Using regular XB, press 2 for XB.

CALL INIT::CALL LOAD(9456,99,99)

Do some disk access, etc. (only XB stuff, no EA5 programs)

Quit, then press 2 for XB again.  No CALL INIT this time.

CALL PEEK(8198,A,B)::PRINT A;B    should be 170 and 85

CALL PEEK(9456,A,B)::PRINT A;B    should be 99 and 99

Edited September 7, 2020 by senior_falcon

[DavidC]

20 minutes ago, senior_falcon said:

I guess it's best not to assume anything with this pesky problem. For all I know this thing splatters random bytes throughout memory when it starts up. 

 

Using regular XB, press 2 for XB.

CALL INIT::CALL LOAD(9456,99,99)

Do some disk access, etc. (only XB stuff, no EA5 programs)

Quit, then press 2 for XB again.  No CALL INIT this time.

CALL PEEK(8198,A,B)::PRINT A;B    should be 170 and 85

CALL PEEK(9456,A,B)::PRINT A;B    should be 99 and 99

Using regular XB (from my finalGROM),  Typed CALL INIT:: CALL LOAD(9456,99,99). Then I loaded and ran a few simple XB programs.  Edited and saved them, reran them.  I quit out of XB, reloaded XB did the CALL PEEKS and the results were :  170 and 85  for the first one and 99 and 99 for the second.  The results match what you expected. 

[senior_falcon]

Well how about that. Thank you! Armed with that information, I have a fix in mind that should work well for this.

[DavidC]

AWESOME!

 

[senior_falcon]

Here is XB 2.8 G.E.M. modified to deal with the problems Majestix and David C were having with their NanoPEB systems. Instead of using CALL LOAD(-2,COLORS,FONT) to set the custom colors and font when using the editor, you now have to use CALL LOAD(9456,COLOR,FONT). These 2 bytes persist when you BYE or QUIT. However, if you set the custom colors/font, then use XB for a while, then run an E/A5 program, they may be corrupted when you return to XB. In that case XB 2.8 G.E.M. will put zeros at 9456 which tells GEM to use the default colors/font.

Remember that you can use a 1 line LOAD program to load your preferences. Example:

10 CALL LOAD(9456,78,134) will use the colors dark blue on gray, use font6 and invert the autoload behavior. (no autoload unless you are holding down a key.)

 

(edit) This is not just for nanoPEB systems. It should work on any TI system. (I hope!)

 

(edit 9/22) see post #276 for the latest version that can use defs and subs in chained programs.

 

Edited September 23, 2020 by senior_falcon

[senior_falcon]

A question has arisen on whether XB 2.8 G.E.M. can be loaded to a cartridge. The request is for "Something that can be loaded into an EPROM." What does this mean? How does that differ from the files I have posted that can be used as cartridges in Classic99 and the FinalGrom?

Edited September 12, 2020 by senior_falcon

[DavidC]

Just gave this a quick go and it's looking good! I will mess around with it more when I get some free time to dig in.  Thank You @senior_falconfor all your hard work. This truly is a GEM!! ( sorry, I couldn't resist.. )

[majestyx]

I too am up and running with the expected cyan background and black text.

 

Thanks for all the new features and fonts. This will be a lot of fun to play with!

[senior_falcon]

Be sure to try out the different fonts and colors. Some days I'm in the mood for dark blue on gray, other days  black on cyan, and sometimes I like white on dark blue. My most used fonts are 1,3,6 and sometimes 18 just to be different.

[senior_falcon]

A simple little change that was made to XB 2.8 G.E.M. was to modify CALL COLOR to accept numbers from 1 to 32. You cannot define the patterns for ascii 160 to 255 or 0 to 29 but if you set the colors with the same foreground and background, you can use HCHAR or VCHAR to put 8x8 color blocks on the screen. These are completely independent of characters 30 to 159. There are 15 unused character sets, which matches the 15 colors available. In the program below, line 1 puts characters 0 to 255 on the screen. Line 20 loads a font, and uses that to define characters 128 to 159, then loads a different font. Now characters 30 to 159 are defined. Line 30 changes the colors of the "unused" character sets and this is independent of the defined characters.

 

1 CALL CLEAR :: CH=0 :: FOR R=1 TO 8 :: FOR C=1 TO 32 :: CALL HCHAR(R,C,CH):: CH=CH+1 :: NEXT C :: NEXT R
20 CALL FONT(32):: FOR I=64 TO 95 :: CALL CHARPAT(I,A$):: CALL CHAR(I+64,A$):: NEXT I :: CALL FONT(4)
30 FOR I=17 TO 31 :: CALL COLOR(I,I-15,I-15):: NEXT I
100 GOTO 100

 

 

Edited September 13, 2020 by senior_falcon

[+jedimatt42]

Took me a while to understand your point, as I was stuck on "but aren't those pattern definition spots overlapping with memory used for something else..." 

The patterns may be garbage from a character definition point of view, but as you instruct, if the foreground and background are the same, the pattern is invisible, and they can then be used as solid blocks. 

 

That's cool.

[senior_falcon]

15 hours ago, jedimatt42 said:

Took me a while to understand your point, as I was stuck on "but aren't those pattern definition spots overlapping with memory used for something else..." 

The patterns may be garbage from a character definition point of view, but as you instruct, if the foreground and background are the same, the pattern is invisible, and they can then be used as solid blocks. 

 

That's cool.

The cool thing is that it doesn't cost anything other than a couple of bytes of GPL code.

A different approach would be to preload the colors into the color table.  Instead of the usual 15 bytes set to >00 and 17 bytes set to >10 (>F0 in RXB and XB 2.7) you could have >11,>22,>33,>44 up to >EE,>FF and then the 17 bytes set to >10. I can't remember why I didn't do it this way. I think it can leave funny colors on the screen when a program breaks.

[senior_falcon]

One of the new CALLs in XB 2.8 G.E.M. is CALL RUNL1(filename). Using RUNL1 lets you chain XB programs together ad infinitum. (Or at least to the limits of disk capacity.)From the manual:

CALL RUNL1(A$)

RUNL1 is used to run an XB256 program from a running program. It is similar to CALL RUN but with a major difference. After it loads the program it runs the first line, but without doing a prescan or resetting any of the variables of the calling program. By chaining programs together with RUNL1 you can create a very long XB256 program, and the neat thing is that bypassing the prescan means super fast start up time and that all the variables are automatically carried over into the newly loaded program. You don't have to save them before leaving one program and retrieve them in the next program.

RUNL1 plays some tricks on the XB interpreter and to avoid problems, there are a couple of things that are important to know..... etc.

 

One of the limitations is that named subprograms can only be used in the first program segment. Subsequent segments loaded and run using RUNL1 cannot use named subprograms. For some this is a major limitation. The good news is that I have found a way around this limitation and this should be very easy to implement.

 

The second limitation is that DEF can only be used in the first program segment. I am hopeful that I can find a way to remove that limitation as well.

[majestyx]

32 minutes ago, senior_falcon said:

One of the limitations is that named subprograms can only be used in the first program segment. Subsequent segments loaded and run using RUNL1 cannot use named subprograms. For some this is a major limitation. The good news is that I have found a way around this limitation and this should be very easy to implement.

Just so that I am understanding this correctly, does this mean if I define a named subprogram in the first program segment, for example, named RSF(FRN,LRN), then it cannot be used/called in subsequent program segments? Or can it only be defined in the first program segment, but can be called in a later one? I ask because I am using one like this in my current project. I don't currently need to chain programs together for this one, but for future reference, I'd just like to know so that I can plan ahead.

 

The reason I ask is that it's the core subprogram that I use for displaying the text from a "story" file. In fact it's the only subprogram in the entire program at all. It also doubles as a "PRESS ANY KEY TO CONTINUE" subroutine when passing in 2,1, or passing in 1,0 to also include a single-line scroll first.

 

So if in a future program where I may need to chain multiple program segments, if I can't use e.g. CALL RSF(1,91) in later segment, then I'll need to keep the program contained to a single program segment or figure out a different way to approach programming it.

8000 SUB RSF(FRN,LRN)
8010 ROW=1
8020 IF FRN>LRN THEN GOSUB 8065 :: GOTO 8100
8030 LINPUT #1,REC FRN:A$ :: FRN=FRN+1
8040 CALL LINK("PRINT",24,1,A$):: CALL LINK("SCROLL")
8050 IF ROW=23 THEN GOSUB 8070 :: IF (FRN-LRN)<1 THEN ROW=0 ELSE CALL LINK("PRINT",24,1,"",40):: CALL LINK("SCROLL"):: GOTO 8100
8060 ROW=ROW+1 :: GOTO 8020
8065 IF LRN=0 THEN CALL LINK("SCROLL")
8070 CALL LINK("PRINTI",24,8,"PRESS ANY KEY TO CONTINUE",25)
8080 CALL KEY(0,K,S):: IF S<1 THEN 8080
8090 RETURN
8100 SUBEND

At first I thought you meant that if subprograms are to be used, they must all be defined in the first program segment, but could still be called in later ones. In other words, I took it to mean that if you are going to use subprograms, make certain they are all defined in the first program segment due to prescan being eliminated (my lack of memory management understanding is tripping me up) since they cannot be defined using SUB in later segments. But after re-reading the manual and now your post above, it sounds more like subprograms can be defined & called in the first program segment only, but can no longer be called in later program segments, most likely because line numbers in later program segments may overwrite the subprogram line numbers.

 

If you could please verify which is the case, I'd greatly appreciate it.

[senior_falcon]

Is or will be?

As things stand now you can only use subs in the first program. As you surmised, when you load the second program things have changed in memory and calling a SUB will get the program lost. (Since it is XB at least it doesn't crash)

As things will be, my tests show that it should be possible to use the same sub throughout the chain of programs. The subs will have to be included in each program in the chain. Otherwise there is no code to run when the subs try to execute. 

It looks like DEF will be possible as well, but that fix is a little trickier.

But a story that is good to remember is this: When Joe Hooker was boasting about how he would kick Robert E. Lee's butt, Lincoln responded, "The hen is the wisest of all the barnyard animals. She never cackles until the egg is laid."

And so I will refrain from cackling until this egg is laid.

[senior_falcon]

What might be lost in the noise is that version of The Missing Link included with XB 2.8 G.E.M. is an enhanced version having 8 additional subroutines that are not part of the original TML. Two are shown here: CALL LINK("GRAFIX") and CALL LINK("BITMAP")

TML starts in the bitmapped mode. Line 2 sets it to graphics mode where you input an angle to use in drawing a polyspiral. After you input the angle, line 5 returns XB to the bitmapped mode where the polyspiral is drawn. After a pause the program returns to line 2 to start the process all over. Any graphics on the screen in the bitmapped mode will be preserved when you return. If you are using custom colors and font they will be used when you CALL LINK("GRAFIX")

 

2 CALL LINK("GRAFIX")
3 PRINT "We are now in the standard  graphics mode normally used by XB.": : :"Enter an angle to be used indrawing a polyspiral."
4 INPUT ANG
5 CALL LINK("BITMAP")
10 CALL LINK("PUTPEN",92,120,0):: FOR I=1 TO 120 :: CALL LINK("FWD",I,ANG):: NEXT I
15 CALL WAIT(240):: CALL LINK("CLEAR"):: GOTO 2

 

Edited September 16, 2020 by senior_falcon

[senior_falcon]

On 9/14/2020 at 11:36 PM, senior_falcon said:

 

As things stand now you can only use subs in the first program. As you surmised, when you load the second program things have changed in memory and calling a SUB will get the program lost. (Since it is XB at least it doesn't crash)

As things will be, my tests show that it should be possible to use the same sub throughout the chain of programs. The subs will have to be included in each program in the chain. Otherwise there is no code to run when the subs try to execute. 

Subprograms are now working in chained programs.

I spent some productive time with the debugger and it looks like DEF can be made to work as well. That's a bit trickier. For the first program, prescan finds the DEF's and puts the DEF name and a pointer to the code in the VDP stack. In the chained programs, the code for DEF might be anywhere, so a mini prescan has to happen that finds the DEF's and corrects the pointers in the VDP stack. 

[atrax27407]

Waiting for the latest version . . .?

[senior_falcon]

I was doing a little assembly programming last night. Besides the 20x speed increase in the loader, It is so nice to be able to simply REF VMBW instead of having to get out the book to look up the address.

Edited September 18, 2020 by senior_falcon

[senior_falcon]

Turns out I was overthinking the problem and no additional coding and no mini prescan was necessary. Now SUB, SUBEND, SUBEXIT, and DEF can be used in any of the chained programs. To use these you have to pay close attention to certain details, so I will work on the docs to make sure the necessary steps are 100% clear.

Edited September 19, 2020 by senior_falcon