Extended BASIC G.E.M.

[jedimatt42]

4 hours ago, Omega-TI said:

 

Anything is possible.  I'll have search the house though, the only SD cards I can find at the moment are all high speed high capacity cards used for photography.  If I remember correctly, the FinalGROM works best with smaller and slower cards, or was that just the FlashROM?  

 

Arcadeshopper did some testing, and he gets the flashing light problem if FCMDG and XB28GEMG are together in a subdir. But not if they are together at the ROOT of the SD card. 

I haven't verified this. But They do 'work' ( no flashing light ) in my setup, which has both in the ROOT of the SD card. 

That might be a issue with the FinalGROM firmware, except, that Arcadeshopper verified he can go from XB28GEMG back to FCMDG... so that points to an subtle issue in Force Command's XB command.

 

We can do more testing on our end before you need to spend your hobby time on this.

[mizapf]

3 hours ago, DavidC said:

Can someone put together a .rpk of this for MAME...please?   I tried, and failed miserably..lol.  

 

I did it some time ago:

To update to the most recent release, use that RPK, unzip it, check the entries in layout.xml concerning the files gromimage and romimage (could be another file name), and pack the (G)ROM dumps together with that layout.xml into a new extended_basic_28_gem.rpk. If your packing program does not allow using the rpk suffix, use zip and rename to rpk after that.

 

Edit: Here is the RPK. Mind that I don't always watch this thread so that I may miss one or another new release.

extended_basic_28_gem.rpk

Edited December 30, 2020 by mizapf

[atrax27407]

Waiting. . .

[Omega-TI]

2 hours ago, jedimatt42 said:

Arcadeshopper did some testing, and he gets the flashing light problem if FCMDG and XB28GEMG are together in a subdir. But not if they are together at the ROOT of the SD card. 

I haven't verified this. But They do 'work' ( no flashing light ) in my setup, which has both in the ROOT of the SD card. 

That might be a issue with the FinalGROM firmware, except, that Arcadeshopper verified he can go from XB28GEMG back to FCMDG... so that points to an subtle issue in Force Command's XB command.

 

We can do more testing on our end before you need to spend your hobby time on this.

 

Yes, I put Force Command back in the ROOT directory along with XB28GEMG and the WEATHER80 program.  I can load XB28GEMG from the cartridge, select T80XB then manually load TIPI.WEATHER80 and run it, it'll even load up and go to Force Command afterwards.  I can even type FG99 XB28GEMG inside Force Command, manually select T80XB, hold down the space key and then type in OLD TIPI.WEATHER80 to run the program.  However typing XB TIPI.WEATHER80 results in the blinking LED.

 

Thanks, I'll wait to see what develops.  

[DavidC]

3 hours ago, mizapf said:

 

I did it some time ago:

To update to the most recent release, use that RPK, unzip it, check the entries in layout.xml concerning the files gromimage and romimage (could be another file name), and pack the (G)ROM dumps together with that layout.xml into a new extended_basic_28_gem.rpk. If your packing program does not allow using the rpk suffix, use zip and rename to rpk after that.

 

Edit: Here is the RPK. Mind that I don't always watch this thread so that I may miss one or another new release.

extended_basic_28_gem.rpk 84.52 kB · 1 download

Thank you sir!   I tried to do all that other stuff....got confused and decided to have a beer and ask y'all for help..Thanks @mizapf, you are awesome!

 

[senior_falcon]

On 12/29/2020 at 9:41 AM, senior_falcon said:

Those address are for the original XB G.E.M.  These addresses should work for XB 2.8 G.E.M.

 

XB GEM 2.8                                    XB 2.8                                      31435

XB GEM 2.8                                    XB 2.8 + XXB                            32336

XB GEM 2.8                                    XB256                                      32296

XB GEM 2.8                                    T40XB                                      32314

XB GEM 2.8                                    T80XB                                      32325

XB GEM 2.8                                    THE MISSING LINK                    32212

XB GEM 2.8                                    TML GRAPHIC ADVENTURE          32280

XB GEM 2.8                                    DM1000                                   31928

 

A different approach may solve the problem. Remember that if you can get into XB 2.8 you can change the graphics mode to 80 column text mode with CALL T80XB or CALL T80XB(n) if you want to change the number of disk files.

Make that the first line of your program.

[jedimatt42]

18 hours ago, senior_falcon said:

A different approach may solve the problem. Remember that if you can get into XB 2.8 you can change the graphics mode to 80 column text mode with CALL T80XB or CALL T80XB(n) if you want to change the number of disk files.

Make that the first line of your program.

That seems like a preferable approach, so the burden of knowing what extensions are used by a program remain with the programmer, and this knowledge requirement isn't distributed to all of the users of the program.

[senior_falcon]

In my testing I found that when using the compiler, XB 2.8 G.E.M. would crash if you chose to put the runtime routines into low memory. (It works fine when using the normal place for the runtime routines.)

I am polishing up the loader so that:

* If you chose "Y" for the option to put runtime routines in low memory then the proper loader program is loaded automatically.

*If you chose "N" for that option and the program  is too big to fit entirely in high memory, you are sent back to the compiler so you can press "Y" and recompile.

*The option to load using MiniMemory will be removed.

These changes should streamline the process and make it more intuitive.

[1980gamer]

Great News!  I had been struggling.

I thought I was doing something wrong and was going to keep trying different combos.

 

My small test programs worked. But my larger game wasn't.  I was rewriting it to try to save space.  ( should still be optimized! )

 

I may have to split the game up anyway.   I am working on a 5 pack of mini games. Just 1 of them got a little bigger than a mini game!  LOL

[senior_falcon]

Making good progress changing the loader to work as described above. I have some memory limitations that I am still working out:

With the runtime routines in low memory you are using pretty much all 32K of available memory.

Because of this the loader is written in XB and run from VDP ram which frees up all 32K of expansion memory.

There must be an 8K buffer in VDP ram for saving the EA5 files and that limits the size of the XB program.

The existing loader AORG's code to >2008. This works fine in normal XB, but the memory locations >2008 to >20F7 are used by the fast loader in G.E.M. Therefore, code in that memory block must be poked in with CALL LOAD or some other strategy which is compatible with the G.E.M. loader.

I am not sure if the 32K loader program can be shrunk enough to avoid overlapping the buffer used for saving the EA5 files, so it might be necessary to do a CALL FILES(1), or maybe to divide the loader into two segments

[senior_falcon]

I think this is all worked out and the loader is much easier to use now. I am still testing, but it looks good. The buffer and the XB program were colliding, but that was fixed by removing most of the comments.  I should be posting an update to the XB game developer's package in the next couple of days.

 

(Edit) - Finished. See the XB Game Developer's Package thread for the revised version.

Edited February 24 by senior_falcon

[senior_falcon]

There have been a number of unsuccessful attempts at making an endless XB program possible. To my knowledge only XB 2.8 G.E.M. can seamlessly chain multiple XB programs together while retaining the numeric and string variables from one program to the next. From the XB 2.8 G.E.M. manual:

 

CALL RUNL1(A$)

RUNL1 is used to run an XB 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 does not do a prescan or reset any of the variables of the calling program. By chaining programs together with RUNL1 you can create a very long XB 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 exiting one program and retrieve them in the next program.

RUNL1 takes some liberties with the XB interpreter and to use it successfully, there are six rules that must be followed:

 

If interested, you can read more about this technique on pages 12-13 of the manual.

 

Edited February 25 by senior_falcon

[senior_falcon]

Greg now has physical cartridges of XB 2.8 G.E.M. available!

[senior_falcon]

There was some discussion recently about the speed of HCHAR and VCHAR. This prompted me to take a look to see if the sluggish speed could be improved. As it turns out, it could be improved and it was added to XB 2.8 G.E.M. I will post the new files for GEM soon - just checking it out to be sure I haven't missed anything. A video is below. 

Edited May 7 by senior_falcon

[senior_falcon]

Here is the latest version of XB 2.8 G.E.M. with the HCHAR and VCHAR modifications shown in the video above. Because it fills the entire screen, what is shown in the video demonstrates the greatest increase in speed. It actually is a tiny bit slower (1-2%) if only printing one character, but it will always be faster if more than one character is printed.

Also there is a tiny fix to The Missing Link. One of the TML extras did not work-I was switching banks when I shouldn't have been.

XB28GEM20200506.zip