Jump to content
senior_falcon

Extended BASIC G.E.M.

Recommended Posts

Progress report. This is coming along nicely. I have a short demo that starts in XB and prints a message. Then it loads XB256 with 2 files and prints some stuff. Then it loads T40XB with 3 disk files and prints a message. Then it loads T80XB with 1 disk file and prints a message. All from one program and everything seems to work properly.

Next is to get The Missing Link to load this way. This will require some finesse. All the other programs start in graphics mode by default, but when TML runs it starts in bit mapped mode. This should be fairly straightforward, but of course one never knows...

 

Also, while testing I found a bug in T40XB and T80XB.  If you CALL LINK("PRINT"...) or CALL LINK("CLS") the program crashes unless you have already done CALL LINK("T40") or CALL LINK("T80"). This normally would not be a big deal unless (like me) you forget to do the CALL LINK("T40"). This is now fixed and works as expected.

  • Like 4

Share this post


Link to post
Share on other sites

Here is the same program running in XB mode, XB256, T40XB, T80XB and The Missing Link. The program listing is below the GIF. This is looking very promising, but it needs a very thorough testing and debugging. For one thing, saving to disk in TML failed so I need to see what is different there.

(Edit) - This was a minor oversight. Fixed by adding one line of code.

SUNDAY.GIF.c23dbad72418c4bbdf29a4479f123cbe.GIF

 


10 PRINT "IN TI EXTENDED BASIC"
20 FOR I=1 TO 1000 :: NEXT I
30 CALL XB256(1)
31 CALL LINK("SCRN2"):: PRINT "Running in XB256" :: FOR I=0 TO 255 :: PRINT CHR$(I);:: NEXT I
40 FOR I=1 TO 1000 :: NEXT I
50 CALL T40XB(2)
60 CALL LINK("T40"):: FOR I=1 TO 24 :: CALL LINK("PRINT",I,I,"In T40XB mode"):: NEXT I
70 FOR I=1 TO 1000 :: NEXT I
80 CALL T80XB
90 CALL LINK("T80"):: FOR I=1 TO 24 :: CALL LINK("PRINT",I,I,"This is running in T80XB mode"):: NEXT I
100 FOR I=1 TO 1000 :: NEXT I
105 CALL TML
110 CALL LINK("PRINT",83,111,"THE"):: CALL LINK("PRINT",93,99,"MISSING"):: CALL LINK("PRINT",103,108,"LINK")
115 CALL LINK("PR"):: FOR I=1 TO 2 :: CALL LINK("PUTPEN",96,120,0):: FOR J=1 TO 80 :: CALL LINK("FWD",J,123):: NEXT J :: NEXT I
120 GOTO 120

 

 

Edited by senior_falcon
  • Like 10

Share this post


Link to post
Share on other sites

Honestly I've not checked yet, as it's still on my list of things to do, but I'm going to have to move GEM out of my FG99's root menu and pop it into another directory as it really clutters up the opening screen.  With any luck things will still work as expected.

Share this post


Link to post
Share on other sites

I have made the cartridge with the revisions described above. This was not without snags. I forgot that when you do XMLLNK (for garbage collection) the ROM bank has to be set for XB. This led to some wailing and gnashing of teeth until I realized what was going on.

 

All seems to work properly but more testing is in order. Also, the docs have to be brought up to date. Should be done soon.

  • Like 7
  • Thanks 1

Share this post


Link to post
Share on other sites

Should be ready this weekend. I am going through the manual to be sure everything is correct. I found at least one "hanging chad" where I said "See page ? for more information", and never went back to put in the actual page number.

  • Like 3

Share this post


Link to post
Share on other sites
10 hours ago, senior_falcon said:

Should be ready this weekend. I am going through the manual to be sure everything is correct. I found at least one "hanging chad" where I said "See page ? for more information", and never went back to put in the actual page number.

I wouldn't worry about that so much...  MS has messages like this!

image.png.f3dd5e0fdbafd68e89fbda2330058038.png

  • Like 1

Share this post


Link to post
Share on other sites

Here is the latest and hopefully final version of XB2.8 G.E.M. It has been modified so you can change graphics modes from Extended BASIC. (Previously you could only select the graphics mode from the menu.) CALL XB256 will load and start up XB256 with 3 disk files which is default. If you want to have a different number of disk files open you can CALL XB256(1) to have one disk file open. This loads XB256 and does the equivalent of CALL FILES(1). Likewise with XB, XXB, XB256, T40XB, T80XB, TML and TMLGA.

There is information in the XB2.8GEM docs showing how to change certain defaults such as the color and font in T40XB, T80XB, and XB256.

Disk access should work with CF7 and a real TI99 but it would be nice if someone tested that to verify.

Have fun!

 

 

(Edit: If you CALL VERSION(X)::PRINT X the latest version number is 2.820201202)

(Edit: Post 350 on this page has version 2.820201208 which fixes a minor bug that Wolfgang was having.

Edited by senior_falcon
  • Like 9

Share this post


Link to post
Share on other sites

I apologize for zoning out and having to ask this.  GEM 2.8 seems like an entirely new animal with all the features it offers, and it looks promising for modernizing several of my old game programs.  Programs using it can be compiled, right?

  • Like 1

Share this post


Link to post
Share on other sites
I apologize for zoning out and having to ask this.  GEM 2.8 seems like an entirely new animal with all the features it offers, and it looks promising for modernizing several of my old game programs.  Programs using it can be compiled, right?
Not yet.. this is just basic module stuff

Sent from my LM-V600 using Tapatalk

Share this post


Link to post
Share on other sites
1 hour ago, OLD CS1 said:

I apologize for zoning out and having to ask this.  GEM 2.8 seems like an entirely new animal with all the features it offers, and it looks promising for modernizing several of my old game programs.  Programs using it can be compiled, right?

At the present time only XB and XB256 can be compiled. I am hoping to add assembly support to the compiler. I will not make any new assembly support routines part of the compiler like XB256 is. This will impact the speed a bit because the compiler will have to pretty much duplicate the steps taken when XB CALL LINKs to a subroutine. But there would be a lot of versatility and it should be possible to include almost any assembly support routines.

This is not trivial. At present I have modified the compiler so it produces the desired code when it comes to an unknown CALL LINK. (i.e. a call link that is not part of XB256) The next steps are much more complex.  Now I have to figure out how to to modify the XB support utilities such as NUMASG, NUMREF, etc. so they can interface with compiled code.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
17 hours ago, senior_falcon said:

Here is the latest and hopefully final version of XB2.8 G.E.M. It has been modified so you can change graphics modes from Extended BASIC. (Previously you could only select the graphics mode from the menu.) CALL XB256 will load and start up XB256 with 3 disk files which is default. If you want to have a different number of disk files open you can CALL XB256(1) to have one disk file open. This loads XB256 and does the equivalent of CALL FILES(1). Likewise with XB, XXB, XB256, T40XB, T80XB, TML and TMLGA.

There is information in the XB2.8GEM docs showing how to change certain defaults such as the color and font in T40XB, T80XB, and XB256.

Disk access should work with CF7 and a real TI99 but it would be nice if someone tested that to verify.

Have fun!

XB28GEM1202.zip 1.66 MB · 16 downloads

 

 

Hello Harry,

 

With the XB 2.8 G.E.M you have created an excellent Super Extended Basic!

 

I just started my Mega Menu program (normal XB compiled with Isabella) from a normal disk system and everything works as it should.

Then I did the same with my TIPI system and everything works as it should.

 

Now it's time to look a little more intensively with the new possibilities.

 

I tested on the following two systems:
System 1:
TI EU console
FG99 with XB 2.8 G.E.M.
Speech synthesizer
PEB with TIPI,
SAMS 1Mb (incl.32KB)
HRD4000B, TI Disk Controller with 80 Track mod.
1 x 5.25 "DS80SD, 1 x 3.5" DS80SD, 1x5.25 "SS40SD floppy drives


System 2:
TI EU console
prepaired with a snug REPL99 card
FG99 with XB 2.8 G.E.M.
PEB with snug EVPC2 (V9938) RGB output,
32KB memory expansion
CorComp Floppy Disk Controller DSDD
3 x 3.5 "DS40DD, 1 x 5.25" DS40DD floppy drive
RAVE99 with speech card
P-Code Card

 

Thank you for this new Extended Basic!

 

Wolfgang

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

The real proof of the pudding is to be sure you can save and load after moving the stack.

CALL XB256(1) will move the stack. Then this should save a short file:

     10 OPEN #1:"DSK9.TEST",DISPLAY ,VARIABLE 80,OUTPUT
     20 PRINT #1:"This is a test"
     30 CLOSE #1

CALL TML will move the stack again. Then this should be able to read the file you just saved:

     10 OPEN #1:"DSK9.TEST",DISPLAY ,VARIABLE 80,INPUT
     20 INPUT #1:A$
     25 PRINT A$
     30 CLOSE #1

 

 

  • Like 2

Share this post


Link to post
Share on other sites
26 minutes ago, senior_falcon said:

The real proof of the pudding is to be sure you can save and load after moving the stack.

CALL XB256(1) will move the stack. Then this should save a short file:

     10 OPEN #1:"DSK9.TEST",DISPLAY ,VARIABLE 80,OUTPUT
     20 PRINT #1:"This is a test"
     30 CLOSE #1

CALL TML will move the stack again. Then this should be able to read the file you just saved:

     10 OPEN #1:"DSK9.TEST",DISPLAY ,VARIABLE 80,INPUT
     20 INPUT #1:A$
     25 PRINT A$
     30 CLOSE #1

 

 

It seems it works but I get some flaky screens before the XB 2.8 and TML prompt.

 

I started with XB 2.8 and run the first part (I named it TEST1)

image.thumb.png.ffaa234c31999aabbc7f640d48033503.png

 

Then I did the CALL TML, OLD TEST2 and RUN

The following screens I see every time I run the program:

image.thumb.png.1f8dc52e5ad2422c288af2b9f04425ca.pngimage.thumb.png.a504163c4c5b0366a7752b23fdc01496.png 

 

 

 image.thumb.png.422ccc1353ff5b8e4d856a86868be7cb.png

Share this post


Link to post
Share on other sites

That stuff you see is because The Missing Link starts up in bit mapped mode, but you are printing in standard graphics mode. So there is junk on the screen, then the program ends and XB returns to graphics mode and then you can read THIS IS A TEST.

However.....

You can make line 25 CALL LINK("PRINT",1,1,A$) and then add line 50 GOTO 50

This works almost as expected, but there is a colorful block in the middle of the screen where it should not be. This also happens with standard XB and disk based TML, so clearly the problem lies with TML

I'm quite sure this did not happen with the original TML, so now I have to see what is going on with it. This doesn't happen with TMLDEMO which loads fonts from disk.

Doggone it, I though I was done with this.

 

(Edit) In case you missed it in the post below, there is no problem with The Missing LInk. It works the way it always did. I just forgot how it worked!!!

Edited by senior_falcon
  • Like 2

Share this post


Link to post
Share on other sites

Sometimes even the guy who wrote it has to RTFM! From The Missing Link manual:

  In the 16 color mode, INPUTing from a DISPLAY format disk file will cause spurious blocks of color to
  appear on the screen. You can avoid this by using LINPUT instead. (The use of INTERNAL format files
  will present no problem.)

 

Try this for the program that tests whether you can read from disk:

     10 OPEN #1:"DSK9.TEST",DISPLAY ,VARIABLE 80,INPUT
     20 LINPUT #1:A$
     25 CALL LINK("PRINT",1,1,A$)
     30 CLOSE #1
     40 GOTO 40

 

  • Like 1

Share this post


Link to post
Share on other sites

By the way, it's nice to see that you are using the font you like (Font 2) and not the font that I like and set as default. Lately I have become quite partial to font 3 with dark blue on grey.

Share this post


Link to post
Share on other sites
18 hours ago, senior_falcon said:

Sometimes even the guy who wrote it has to RTFM! From The Missing Link manual:

  In the 16 color mode, INPUTing from a DISPLAY format disk file will cause spurious blocks of color to
  appear on the screen. You can avoid this by using LINPUT instead. (The use of INTERNAL format files
  will present no problem.)

 

Try this for the program that tests whether you can read from disk:

     10 OPEN #1:"DSK9.TEST",DISPLAY ,VARIABLE 80,INPUT
     20 LINPUT #1:A$
     25 CALL LINK("PRINT",1,1,A$)
     30 CLOSE #1
     40 GOTO 40

 

This is working. After RUN I see the strange screens and the message:

image.thumb.png.f0064899d5d2367e5cd0d30e3eee1986.png

 

If I break the program I get the color and font I assume:

image.thumb.png.91e20aae1c0a8fec78a1c81a85a3dae7.png

 

 If I autoload my Mega Menu program in XB 2.8 I see this: It is correct!
 

image.thumb.png.72571744cbfbd357e00f5b9520db7952.png

 

If I break the program the color and the font is changing to this:

 

image.thumb.png.7f57b2a389aee6fc0e984ede4306470e.png

 

If I run XB 2.8 without autoload I get this font from the beginning:

image.thumb.png.0e5372d641d7bb108233ef94cff75df6.png

 

I think this is not the default font, but I will try to patch the bin file with my default color/font.

 

 

Share this post


Link to post
Share on other sites

First of all, the strange screens you mention should only last for a second or so. This is the transition from graphics to bit mapped mode. If it is many seconds (which I doubt) then something is amiss.

I have a feeling that MegaMenu is not playing nice with XB 2.8 G.E.M. Can you do this:

CALL PEEK(8198,A,B)::PRINT A;B   this should be 170,85 (or AA55)

Then:

CALL PEEK(9456,A,B)::PRINT A;B  I think default is 23,1

 

 

Share this post


Link to post
Share on other sites

The first thing XB 2.8 G.E.M. does when you select any of the XB options from 2 to 8 is CALL INIT. There is a little twist to how is does this. First it checks memory at >2006. If it finds >AA55  then it knows that CALL INIT has been done, which means you have already been in XB and so you may be using a custom color and font. It still does CALL INIT, but stops at >24EF, leaving >24F0 and >24F1 untouched. This way if you have set a custom font and color it will not overwrite them. If it doesn't see >AA55 then it also loads the default colors and font at >24F0 (black on cyan and font 1).

Since the color and font are not the default ones, evidently GEM is seeing >AA55 at >2006 and assuming that you are using custom colors and font. Since you haven't done that there are two possibilities:

1 - Megamenu is loading code into low memory but without overwriting the >AA55 at >2006

2 - Megamenu does CALL INIT, but then uses the "unused" word at >24F0 for its own purposes.

This is easy enough to track down.

Do what ever you did to get to the screens with the font (it looks like magenta on cyan) shown in the bottom two pictures above. Then:

CALL PEEK(9436,A,B,C,D,E,F...up to X,Y,Z)  (26 letters A-Z)

PRINT A;B;C;D;E;F..up to X;Y;Z                 (26 letters A-Z)

And post the results. With that information I can see what is happening.

Edited by senior_falcon

Share this post


Link to post
Share on other sites
19 hours ago, senior_falcon said:

First of all, the strange screens you mention should only last for a second or so. This is the transition from graphics to bit mapped mode. If it is many seconds (which I doubt) then something is amiss.

I have a feeling that MegaMenu is not playing nice with XB 2.8 G.E.M. Can you do this:

CALL PEEK(8198,A,B)::PRINT A;B   this should be 170,85 (or AA55)

Then:

CALL PEEK(9456,A,B)::PRINT A;B  I think default is 23,1

 

 

Hello,

the CALL PEEK(8198,A,B) is: 170,85
but
the CALL PEEK(9456,A,B) is: 131,160

The MegaMenu program was compiled with the runtime routines in low memory and loads with 32K loader as a large program.
It shows 6944 Bytes left and low memory 15366 - 16383 free.

The program is fully working and I usually don't break the program. If I run a XB program from the menu it works with the normal color and font. 

 

And here are the result of your second message about call peek(9436,....)

 

image.thumb.png.c9fe465ebce50d4735ee2e304f7cfb5c.png

 

If I run the program from the XB prompt and from the screen above the color changes to Black on Cyan.
So a second run and any further run shows Black on Cyan.

 

I have no custom font configured. I use the default files as provided. 

Only at the magenta screen I use CALL LOAD(9456,23,2) to get a better readable screen:

 

image.thumb.png.66b67ea93fa6bd2abd8a2f066ade1bfe.png

 

 

 

Share this post


Link to post
Share on other sites

Thank you for helping track that down. It is as I suspected; >2006 is >AA55 but the CALL INIT code is overwritten with other code and XB GEM  does the wrong thing.

Fortunately this is easy to fix. Instead of looking at >2006 I will have GEM look at >24E8 which is B *R11. I may decide on a different address. B *R11 is used all the time which could lead to a false positive in certain cases. The instruction before that is MOV @4(R13),R2 which is used less frequently.

I should be able to do this tonight.

 

 

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites

XB 2.8 G.E.M. version 2.820201208. This should fix the problem that Wolfgang was having with his MegaMenu program.

From the MegaMenu program you should get the default colors and font

 

XB28GEM1208.zip

 

(edit) See post 370 on page 15 for the latest version

Edited by senior_falcon
  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...