Extended BASIC G.E.M.

[1980gamer]

I got around to installing XB 2.8 just in the past few days, previous version.

I haven't done much with it yet, including reading the new docs.   But I will.

 

However, I grabbed a project I was working on 18 months ago and just tried to compile it.

I did not work.   I selected option 4 and then XB256 as it is an XB256 app. I can load, save, merge, assemble with 0 errors but it exits without the loader step.

I tried different assemblers and loading in to low memory etc.

 

I am certain it is a config issue on my end!  Oh, I also upgraded CLASSIC99.  Wasn't thinking.  Should have done one at a time and tested.

I did Classic first and just played around, no real stress testing.  Then saw you just put up a new version, so I grabbed it.

 

I also tried option 2 XB and it actually gets to the loader, but the OBJ is blank.

 

I will comb over the classic config.  Disks see fine, but I remember some memory flag from way back when...

 

 

DSK2.zip

[1980gamer]

I can get to the loader using just XB ( option 2 ) but I get a syntax error in line 385

[senior_falcon]

I don't know what could cause that. I just ran another test on this and it works like it should.

The syntax error in 385 is saying there is no call init. To do CALL INIT there has to be >AA55 at >2006. CALL INIT happens at line 70 of LOAD.

[wolhess]

9 hours ago, senior_falcon said:

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 1.66 MB · 5 downloads

 

 

Hi @senior_falcon,

 

thank you for working on my issue.

 

Today I tried the new version XB28GEM1208 and I got nearly the same result as before.

But if I now reload XB2.8 the colors are correct even if I run without autoload.

 

Only if I break (FCTN+4) my Mega Menu program, then the colores are changed like in this picture.
 

 

 

[senior_falcon]

10 hours ago, 1980gamer said:

I also tried option 2 XB and it actually gets to the loader, but the OBJ is blank.

I think you should choose option 2 for XB. The game developers package runs on standard XB, loading XB256 from disk if necessary.

I don't know why OBJ should be blank.

[senior_falcon]

Hi @senior_falcon,

thank you for working on my issue.

Today I tried the new version XB28GEM1208 and I got nearly the same result as before.

But if I now reload XB2.8 the colors are correct even if I run without autoload.

Only if I break (FCTN+4) my Mega Menu program, then the colores are changed like in this picture.

 

Can you send me a copy of this program. Does this autoload from XB?

[wolhess]

1 hour ago, senior_falcon said:

Hi @senior_falcon,

thank you for working on my issue.

Today I tried the new version XB28GEM1208 and I got nearly the same result as before.

But if I now reload XB2.8 the colors are correct even if I run without autoload.

Only if I break (FCTN+4) my Mega Menu program, then the colores are changed like in this picture.

 

Can you send me a copy of this program. Does this autoload from XB?

Yes it autoloads direct from any XB.

 

Right now I tested it in classic99 so I'm sure the same result is with classic99 and it is!

 

MM252C99.zip

You must map the folder in the zip file as a FIAD folder for DSK1. in classic99

and deselect "Write DV80 as Windows Text". Then run your XB.

 

The program will autoload and show the main menu screen.

If you then make a break (FCTN+4) you will see the magenta font.

 

The menu selections doesn't work at all because I'm using a TIPI configuration.

For a small test you can try selection "7" KALENDER or Selection "E" - EDIT40.
After Quit the program "Remind me" or the "Editor" you come to the TI Title screen
and can run the XB 2.8 again. 
This works on my site. 

 

This is a small manual for the complete program: 

 

MegaMenu_252.pdf

 

Thank you for your time an effort.

[senior_falcon]

Yes it autoloads direct from any XB.

Right now I tested it in classic99 so I'm sure the same result is with classic99 and it is!

 

Excellent! Since this misbehaves in regular XB and Classic99 that shows it is not a quirk of the final grom. So it should be relatively easy to work out what is happening.

[1980gamer]

So this is strange, I tried a small test program and it compiled and ran the Loader, then created the XB output.

It was not XB256.  I guess that is the next test.

But the larger program compiles and shows no errors.  It just will not let me create the XB complied version.

I tried the mini-memory and that seems to have failed as well, but I have never tried that prior to today.  So, I have no baseline knowledge.

[senior_falcon]

I now see what is going on in Wolfgang's program. My fix was the right thing to do, but in the wrong place. I see what has to be done - if CALL INIT has not happened I need to load the default colors and fonts, but without changing >24F0, because that could crash the program if you CON. This will probably be a couple of days.

[senior_falcon]

Here's a question about what default behavior would be preferable. XB 2.8 G.E.M. can handle autoload at startup in 2 different ways:

If no key is pressed then it tries to load and run DSK1.LOAD. If a key is held down then autoload is bypassed. Or:

If no key is pressed then autoload is bypassed. If you hold down a key then autoload is attempted.

 

Any preferences?

[+arcadeshopper]

1 hour ago, senior_falcon said:

Here's a question about what default behavior would be preferable. XB 2.8 G.E.M. can handle autoload at startup in 2 different ways:

If no key is pressed then it tries to load and run DSK1.LOAD. If a key is held down then autoload is bypassed. Or:

If no key is pressed then autoload is bypassed. If you hold down a key then autoload is attempted.

 

Any preferences?

option 1

[wolhess]

3 hours ago, senior_falcon said:

If no key is pressed then it tries to load and run DSK1.LOAD. If a key is held down then autoload is bypassed.

This is my preference too.

[HOME AUTOMATION]

By using two filenames, perhaps you could offer both...

 

DSK1.LOADKU

DSK1.LOADKD

 

⚖️

[senior_falcon]

44 minutes ago, HOME AUTOMATION said:

By using two filenames, perhaps you could offer both...

 

DSK1.LOADKU

DSK1.LOADKD

⚖️

Too much work. This is a bit of a moot point. If you CALL LOAD(9457,FONT#+128) you can invert the behavior so you have to hold the key down for LOAD. Also, the docs tell how to modify the cartridge  to change the defaults for this.

I prefer the other way, holding down a key for LOAD. So far there is a veto proof majority of 2 to 1 for the other way.

[+retroclouds]

1 hour ago, senior_falcon said:

Too much work. This is a bit of a moot point. If you CALL LOAD(9457,FONT#+128) you can invert the behavior so you have to hold the key down for LOAD. Also, the docs tell how to modify the cartridge  to change the defaults for this.

I prefer the other way, holding down a key for LOAD. So far there is a veto proof majority of 2 to 1 for the other way.

I’m also in for holding down the key for LOAD.

For me, the immediate prompt is more important than automatically loading a file on startup.

[senior_falcon]

I should be posting the updated version of this tomorrow. I just want to check out the docs one more time and give it another testing. There were some vexing problems that were the result of making changes without thinking it through. I think I will leave the autoload behavior unchanged. That way it matches  XB 2.7

If you want to change it the docs describe how to make some changes using a hex editor so that it will behave the way you want.

Edited December 14, 2020 by senior_falcon

[Omega-TI]

Why not have it check for the existence of a configuration file?  If no file exists, load DSK1.LOAD as normal, if it's there, it can have any number of options.

 

EDIT. Never mind, I replied before I got down to the last message in the thread that said you'll keep it as is.

Edited December 14, 2020 by Omega-TI
Read last message in thread.

[senior_falcon]

There are a couple of tweaks I am working on. Normally any of the CALLs to change graphics mode (CALL XB, CALL XXB, CALL XB256, CALL T40XB, CALL T80XB, CALL TML, CALL TMLGA) all work fine, and always work when they are the first instruction in the program. There are certain times when they don't work properly; for example when changing both the graphics mode and the number of disk files from within a FOR/NEXT loop.  I think I understand what is happening, but now have to make changes that don't have bad side effects. 99% of the time this will not be a problem, but hopefully it can be made to work perfectly all the time.

[senior_falcon]

This is the latest version of XB 2.8 G.E.M. The version number is 2.820201212.

This addresses the problems that Wolfgang found. It starts with the default colors and font: Black on Cyan and font 1. (You can change these using a hex editor to whatever you want.) If you temporarily change these with CALL LOAD(9456,color,font) then those will be used unless something changes ram at

 >24e4. After CALL INIT that is >C0AD. If that is changed then GEM assumes the custom colors and font are corrupted as well, so it reloads the default colors. This will take care of the funny red on green colors and strange font that Wolfgang was experiencing.

 

There are two minor issues when compiling programs. (Be sure to select #2, even if you are using XB256)

 

If you use the TI assembler that is part of the game developer's package you are prompted to press Enter when the assembler is done. That works fine in XB because XB always tries to autoload the LOAD program (the main menu for XBGDP). By default XB 2.8 G.E.M. suppresses autoload if you are holding down a key. If you are running at normal speeds and are quick, you can get off the enter key fast enough so that LOAD will run. In CPU overdrive you cannot get off enter fast enough (unless you have superhuman reflexes) and so LOAD will not load. There are a few ways around this:

Take Classic99 out of overdrive and tap enter really fast.

Type RUN "DSK1.LOAD" or OLD DSK1.LOAD and RUN.

Add 128 to the font so you have to hold down a key for autoload. If you do this, when you select XB remember to hold down the 2 for a couple seconds to force the autoload.

 

You can put the compiled program into the 24K high memory as usual. But if you put the runtime routines in low memory, you must must use minimemory to load your program, or use standard XB. This is described in the manual. You cannot load using XB 2.8 GEM because the fast loader uses ram from >2008 to >20F8 and the runtime routines are AORG'd to >2008. There is no way to fix GEM so this works without reverting to the 20x slower standard XB loader. It can (and will) be fixed with a slight revision to the compiler loader. The other thing I noticed is that the compiler loader needs some adjustments to make it more obvious what should be done. For example, if you chose the 24K option in the compiler but try to load with the 32K option, there should be better messages about why it isn't loading and what to do about it

 

.

 

(Edit) See post #376 on page 16 for version 2.820201226

Edited December 27, 2020 by senior_falcon

[senior_falcon]

If you are using CALL LOAD(9456,colors,font) to set custom colors and font, the colors cannot be the same (that would be kind of hard to read) and neither the foreground nor the background color can be transparent. If either is the case, XB 2.8 G.E.M. will load the default colors, except when using CALL HELP which tries to display the incorrect colors. If your custom colors don't take effect or the colors are wrong in CALL HELP, there is a very simple solution: use valid colors.

Edited December 19, 2020 by senior_falcon

[senior_falcon]

On 12/18/2020 at 11:11 AM, senior_falcon said:

You can put the compiled program into the 24K high memory as usual. But if you put the runtime routines in low memory, you must must use minimemory to load your program, or use standard XB. This is described in the manual. You cannot load using XB 2.8 GEM because the fast loader uses ram from >2008 to >20F8 and the runtime routines are AORG'd to >2008.  It can (and will) be fixed with a slight revision to the compiler loader.

I just did a little testing and, as expected, you can AORG >2008 then BSS >00F0 and then start loading code with no problems. Then in XB you can poke values with CALL LOAD to >2008 - >20F7 with no trouble. So fixing the compiler loader so it can load the runtime routines to low memory  using XB 2.8 G.E.M. will be no problem.

 

[wolhess]

On 12/18/2020 at 5:11 PM, senior_falcon said:

This will take care of the funny red on green colors and strange font that Wolfgang was experiencing.

Hi Harry,

 

The font problem after break is solved with your new version. Many Thanks!

 

Wolfgang

[senior_falcon]

A discussion in another thread lead me to make some adjustments to the STRREF routine in the CALL INIT routines. Assembly programs can now fetch strings from XB somewhat faster.

In post #371 above I noted a minor bug in CALL HELP. This has been fixed so that if you have invalid values for the user set colors then the defaults will be loaded when you CALL HELP.

These changes will be noticed by virtually no one when using XB GEM but I wanted to post the new version just to be thorough. Plus I like the version number: 2.820201221

 

(Edit) See post 376 on next page for latest version

 

Edited December 27, 2020 by senior_falcon

[wolhess]

Hi,

 

I checked the new version and tried to use CALL HELP.

 

If I break my Mega Menu program (same compiled version as in post #357) the color and font it is good but if I then CALL HELP I get a wrong color and font!

After HELP finished I get the correct font and color again.

I tested it on real TI and in classic99 with same results.

When I run XB 2.8 from FG99 without autoload and tried then the CALL HELP command the color and font is good.