Jump to content
senior_falcon

Extended BASIC G.E.M.

Recommended Posts

I don't have a lot of insight on this. Wolfgang was able to get this to work by changing XBGEM_8.BIN to XBGEM_C.BIN.

The original G.E.M. had only 2 banks of rom (the standard XB setup) This one has 17 banks, so maybe something different has to happen?

 

Share this post


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

I don't have a lot of insight on this. Wolfgang was able to get this to work by changing XBGEM_8.BIN to XBGEM_C.BIN.

The original G.E.M. had only 2 banks of rom (the standard XB setup) This one has 17 banks, so maybe something different has to happen?

 

Yes sir, that is what I did to get the original G.E.M to work.  It does not work ( for me ) with 2.8  Does anyone have it up and running with their FinalGROM?

Share this post


Link to post
Share on other sites

Majestyx wrote: "Regarding the new CALL RUN / RUNL1, it states that these are used to run XB256 programs. Is it safe to say this will also work to T40XB/T80XB/XB 2.8 programs too? Based on the discussion on pages 11 & 12, that would appear to be the case, but as Benny Hill once said - NEVER ASSUME! I am guessing that the XB256 naming may be left over from earlier versions of the documentation."

 

In the process of checking this out, I discovered that there is something strange going on with The Missing Link.

This worked fine in the original XB G.E.M., but there is something not quite right about the new version. The problem has to do with how stack space is reserved. I think the problem is simple.

-Just did some checking and may have found the source of the problem. If I'm right the fix is simple. 

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, DavidC said:

Yes sir, that is what I did to get the original G.E.M to work.  It does not work ( for me ) with 2.8  Does anyone have it up and running with their FinalGROM?

Just tried this myself and while the menu entries do show up, I cannot get any of the choices to load, including DM1000. They all lead to a blank cyan screen which locks up the computer so that FCTN-QUIT doesn't even work. Pressing reset on the FG99 brings me back to the TI title screen. Pressing any key shows the XB 2.8 menu choices, but once again, all choices lead to the blank cyan screen.

  • Like 1

Share this post


Link to post
Share on other sites
9 hours ago, DavidC said:

First of all I would like to thank @senior_falcon for all your hard work.  This is truly incredible. I was able to get this up and running on Classic99 without issue.  Has anyone loaded onto their FinalGROM?  I tried, but all I get when I choose a option is a blank screen.  The original GEM from post #1 works fine on my FG, I simply cannot get 2.8 to work on my FinalGROM.  Any ideas?   

 

I have the same issue with my FinalGROM, although I renamed the binary as suggested in the documentation.

Could this have something to do with the firmware revision on the FinalGROM? Can that be updated (haven’t checked).

Do know that my FinalGROM was in the first batch produced.

Edited by retroclouds

Share this post


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

Majestyx wrote: "Regarding the new CALL RUN / RUNL1, it states that these are used to run XB256 programs. Is it safe to say this will also work to T40XB/T80XB/XB 2.8 programs too? Based on the discussion on pages 11 & 12, that would appear to be the case, but as Benny Hill once said - NEVER ASSUME! I am guessing that the XB256 naming may be left over from earlier versions of the documentation."

 

In the process of checking this out, I discovered that there is something strange going on with The Missing Link.

This worked fine in the original XB G.E.M., but there is something not quite right about the new version. The problem has to do with how stack space is reserved. I think the problem is simple.

-Just did some checking and may have found the source of the problem. If I'm right the fix is simple. 

Found 2 problems:

1 - I must have used XB256 at some point in the testing and it modified the grom that sets the bottom of the stack.(as is recommended for Classic99) Normally this is a temporary change, but then I saved the groms along with that change. So it was setting the bottom of the stack to >1820 instead of >0958. That is fixed.

2 - As part of my performance improvements for TML I goofed and made it so pixels were not printed when in the 2 color mode. The location of the problem is identified and it will be fixed tonight.

How embarrassing.......

  • Like 1

Share this post


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

 

I have the same issue with my FinalGROM, although I renamed the binary as suggested in the documentation.

Could this have something to do with the firmware revision on the FinalGROM? Can that be updated (haven’t checked).

Do know that my FinalGROM was in the first batch produced.

I have the latest firmware on my FinalGROM & it's not working.

 

Also, if the ROMs were inverted, I think we wouldn't see any menu entries at all, but I'm no TI tech wizard. I just know the symptoms of when I tried (unknowingly) using inverted ROMs. All that would show up on the menu was TI BASIC. I don't know if I've ever seen a C file as large as this one, so perhaps that's the issue? Maybe Ralph B can shed some light on it.

Share this post


Link to post
Share on other sites
2 hours ago, arcadeshopper said:

I'm going to say a c file can't be that many banks in a fg99..

Sent from my LM-V600 using Tapatalk
 

"The FinalGROM 99 supports ROM images, GROM images, and mixed images of up to 1 MB in size that use the write-to-ROM bank switching scheme."

This makes me think it should work. Somehow...

Share this post


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

"The FinalGROM 99 supports ROM images, GROM images, and mixed images of up to 1 MB in size that use the write-to-ROM bank switching scheme."

This makes me think it should work. Somehow...

"For mixed images, the ROM file must always end in C, but an optional second ROM bank ending in D may be present. The GROM G file may be up to 40 KB in size, whereas the ROM C file may be up to 960 KB in size. If a D file is given, it must be exactly 8 KB in size."

 

Ok so it can be up to 960kb.. yours should fit.. and it must be uninverted

 

Greg 

Share this post


Link to post
Share on other sites

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

  • Thanks 1

Share this post


Link to post
Share on other sites

Now it loads but is really strange - I get an ugly orange screen with somewhat distorted text characters. First is just XB 2.8, second is T40XB which is a bit blurry.

 

 

20200903_143606resize.jpg

20200903_143620resize.jpg

Share this post


Link to post
Share on other sites

When GEM loads any of the XB options (2-8) it uses the value at -2 for the foreground and background colors. It uses the value at -1 for the font. I'm guessing there are some numbers left over in those  memory locations that are causing this.

Zeros will load the default font and colors. Try CALL LOAD(-2,0,0) and see what happens.

Then try CALL LOAD(-2,244,3)  for white characters on dark blue and a bolder font.

Edited by senior_falcon
  • Like 1

Share this post


Link to post
Share on other sites

Excellent! Just goes to show you, when in doubt, RTFM. If I had done that with the finalgrom manual then my readme file would have had accurate information. I should be able to post the updated version tonight. I need to move one line of code so it happens sooner. Plus the revisions to the docs that were suggested.

  • Like 3

Share this post


Link to post
Share on other sites

Here is the revised version of XB 2.8 G.E.M. The two little bugs have been fixed and tested and some of the manuals have been revised.

CALL VERSION(X)::PRINT X   returns the number 2.820200903

 

XB28GEM.zip

  • Like 7

Share this post


Link to post
Share on other sites

I still get the orange screen and the different font when using it in the FG99. Is this something that will be fixed in a future release, or is this just an oddity of using it with the FG99, since it doesn't happen in Classic99?

Share this post


Link to post
Share on other sites

It looks like FinalGrom is using the memory at -2 and -1 for something.

The only fix I can see is to have a LOAD program in DSK1. 10 CALL LOAD(-2,78,5+64+128). or your choice of colors and font. These values set the colors to dark bluw on gray, uses font #5, configures XB 2.8 to run forcecommand when BYE is entered, and turns off the autoload unless you hold a key down.

 

(edit) I don't know if those values are needed by the FinalGrom or not. It may be that if they are altered the FinalGrom does not work I have no way to test this.

 

Sure would have been nice to know about this earlier:

In the thread T80XB/FCMD - Users question, I asked:

@Omega:
Can you try this for me:
Get into Extended BASIC
CALL INIT
CALL LOAD(-1,10)
RUN "TIPI FC.FCMDXB"           Does this reset the computer to Force Command the way you want?
Get into Extended BASIC again
CALL PEEK(-1,X)::PRINT X     Does X=10? (In other words, does the memory persist through the reset?)

No answer

Post #181 in this thread:

JediMatt reminded me that using CALL LOAD(-2,COLOR,FONT) uses the vector for "Load Interrupt", which is at >FFFC to >FFFF.
What will this interfere with that people care about?
I could move these two bytes to -6 but would prefer not to because it means doing some rework of the compiler.

No answer

Post #183 in this thread:
 Let me restate my earlier question in a different form:
Does anyone use hardware along with XB that utilizes  the "Load interrupt" hook at >FFFC?
Speak now or forever hold your peace.

One answer saying it should be OK.

 

 

Edited by senior_falcon
  • Like 1

Share this post


Link to post
Share on other sites

Obviously, no one tried to build a RPK for MAME, so here is my attempt. It is the original XB GEM (with 16K ROM); for the XB 2.8 GEM I had to change the bank handling in the gromemu cartridge type, so I will publish the 2.8 RPK when the new MAME release is out.

 

By the way, is there a real Extended Basic 2.8 GEM, or does it only depend on emulation or FinalGROM? (This is relevant for me whether I extend the current paged378 type or the gromemu type, which is a catch-all for exotic cartridge types.)

extended_basic_gem.rpk

  • Like 2

Share this post


Link to post
Share on other sites

Majestyx reports that when choosing XB2.8 G.E.M. from the FinalGrom, memory at -2 is not zeroed out.

CALL PEEK(-2,A,B)::PRINT A;B gives the values 86 and 223.

Are those values the same for all FinalGroms?

Does anyone know the purpose of those values?

Is there any harm if they are changed?

 

Share this post


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

Majestyx reports that when choosing XB2.8 G.E.M. from the FinalGrom, memory at -2 is not zeroed out.

CALL PEEK(-2,A,B)::PRINT A;B gives the values 86 and 223.

Are those values the same for all FinalGroms?

Does anyone know the purpose of those values?

Is there any harm if they are changed?

 

I just did this with my FinalGrom and I got 0 and 0 right after power up and choosing it from the FG99 menu. 

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...