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, 2021 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, 2021 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, 2021 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

See post 426 on page 18 for the latest version, XB 2.8 G.E.M. version 2.820210712

 

Edited July 13, 2021 by senior_falcon

[senior_falcon]

Naturally I have a good knowledge of the enhancements that were added to XB 2.7 to create XB 2.8 G.E.M. I am not so familiar with the XB 2.7 enhancements that Gazoo (and probably others) added to XB, and I have been exploring some of the CALLs he added.

 

Two super versatile CALLs are CALL MSAVE and CALL MLOAD.

CALL MSAVE("DSK1.TEST",10000,512) will save 512 bytes of memory starting at 10000 in program image format. This is EA5 format, and any EA5 loader can load the file and run it. (edit- assuming what you have saved is actually a runable program)

Here's where the versatility comes in. CALL MLOAD("DSK1.TEST") loads those 512 bytes to address 10000, but does not try to run it! It just loads it and returns back to XB. So with MSAVE you can take pictures of memory anywhere in XB, in any size you want, save to disk, then restore the memory from disk as desired. One good use for this would be to save low memory utilities. 

But, if you CALL MLOAD("DSK1.TEST",1) then the program will be loaded to memory and it will run as an EA5 program. So a game loader menu could use MLOAD to run EA5 games.

 

One problem I discovered with XB 2.8 G.E.M. is that the font is not loaded when running an EA5 program. This works properly in XB 2.7, so I broke this as a side effect of adding the 60 fonts to the XB 2.8 G.E.M. cartridge. Most programs load their own font anyway, so this wouldn't be a problem for them. I noticed this running ARC303G

This has been been fixed so it works properly, and the updated files will be posted tomorrow or Saturday.

Edited July 2, 2021 by senior_falcon

[senior_falcon]

Here is XB 2.8 G.E.M. version 2.820210702. This has been modified so it now loads the font to the proper VDP location when running an EA5 program. I also changed the background color to light green to match the EA5 startup color. In XB 2.7 the background was dark blue, making black letters hard to read.

I have also updated XB 2.8 G.E.M. included in the XB Game Developer's Package to match this one.

(Edit) One thing I should add is that MSAVE and MLOAD only work in standard XB 2.8 G.E.M. or with XXB. Other than T40XB, the graphics packages reduce the VDP stack space enough to keep MLOAD from working. I didn't test extensively, but MLOAD did seem to work in T40XB.

 

See post 426 on Page 18 for the latest version, XB 2.8 G.E.M. version 2.820210712

 

 

Edited July 13, 2021 by senior_falcon

[+Vorticon]

XB GEM seems to hang the computer when loaded from the Finalgrom. I have the GROM files XB28GEM_G and XB28GEM_8 on the SD card, and while I do get a menu item for XB GEM, any selection blanks the screen and hangs the computer.

Am I missing something here?

[senior_falcon]

There is a discussion on page 9 of this thread.

My post 213:

"I was looking at information about the finalgrom, and it looks like the filenames are in an 8.3 schema. Try renaming them:

XB28GEMG.BIN

XB28GEMC.BIN"

 

That was reported to work. Check page 9 if there are any other issues.

 

Also mentioned in the README file:

Final Grom
To be able to use the Final Grom you need to rename the two files:
XB28GEM_G.BIN should be XB28GEMG.BIN
XB28GEM_8.BIN should be XB28GEMC.BIN

 

Edited July 4, 2021 by senior_falcon

[+Vorticon]

I got to verify first hand the speed advantage of loading a large ALC support routine (~3K) with XB GEM versus standard XB. We're talking several orders of magnitude improvement here. Impressive and a very compelling reason to use XB GEM for those mixing assembly and XB.

[senior_falcon]

Try entering CALL HELP.

Also try CALL LOAD(9456,244,2) (or 244,130).

This gives white on dark blue and the XB2.7 font. If 130 you must hold down a key to autoload from dsk1.

[+retroclouds]

Think I stumbled upon a small bug. When doing "CALL HELP" after having run a T80 program the first few screens are garbled (as it displays in 80 columns mode).

Other than that, let me take the opportunity to say what an amazing package this is! I am very impressed! ?

 

 

Edited July 6, 2021 by retroclouds

[senior_falcon]

On vacation. I will look into this next week. It is supposed to be in 40 column mode, but somehow is in 80 column. I am sure it is a simple fix.

[SkyPilot]

21 hours ago, retroclouds said:

Think I stumbled upon a small bug. When doing "CALL HELP" after having run a T80 program the first few screens are garbled (as it displays in 80 columns mode).

Other than that, let me take the opportunity to say what an amazing package this is! I am very impressed! ?

 

 

 

Does this mean it could be possible to program in 80 columns when I get a TI and F18A?

[+retroclouds]

3 hours ago, SkyPilot said:

Does this mean it could be possible to program in 80 columns when I get a TI and F18A?

 

Yes,that is correct. Program editing is still 32 columns, but there are instructions to turn on 80 columns mode while your program is running. For many of the extended basic commands (hchar, vchar, etc.) there are comparable call link instructions. There are also calls for defining a window, scrolling, input, etc.