senior_falcon Posted September 2, 2020 Author Share Posted September 2, 2020 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? Quote Link to comment Share on other sites More sharing options...
DavidC Posted September 2, 2020 Share Posted September 2, 2020 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? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 3, 2020 Author Share Posted September 3, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
majestyx Posted September 3, 2020 Share Posted September 3, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted September 3, 2020 Share Posted September 3, 2020 (edited) 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 September 3, 2020 by retroclouds Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 3, 2020 Author Share Posted September 3, 2020 There have been discussions about inverted roms. Could that be it? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 3, 2020 Author Share Posted September 3, 2020 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....... 1 Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted September 3, 2020 Share Posted September 3, 2020 I could certainly see the advantage of having the GEM package available as a cartridge. Quote Link to comment Share on other sites More sharing options...
majestyx Posted September 3, 2020 Share Posted September 3, 2020 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. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted September 3, 2020 Share Posted September 3, 2020 I'm going to say a c file can't be that many banks in a fg99..Sent from my LM-V600 using Tapatalk Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 3, 2020 Author Share Posted September 3, 2020 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... Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted September 3, 2020 Share Posted September 3, 2020 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 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 3, 2020 Author Share Posted September 3, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
majestyx Posted September 3, 2020 Share Posted September 3, 2020 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 3, 2020 Author Share Posted September 3, 2020 (edited) 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 September 3, 2020 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
majestyx Posted September 3, 2020 Share Posted September 3, 2020 That works! 1 Quote Link to comment Share on other sites More sharing options...
DavidC Posted September 3, 2020 Share Posted September 3, 2020 Everything works here...Thank You! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 3, 2020 Author Share Posted September 3, 2020 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. 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 4, 2020 Author Share Posted September 4, 2020 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 7 Quote Link to comment Share on other sites More sharing options...
majestyx Posted September 4, 2020 Share Posted September 4, 2020 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? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 4, 2020 Author Share Posted September 4, 2020 (edited) 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 September 4, 2020 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted September 4, 2020 Share Posted September 4, 2020 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 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 4, 2020 Author Share Posted September 4, 2020 So far only Classic99 and FinalGrom. The hope was to have a physical cartridge, and I think that can be done. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted September 4, 2020 Author Share Posted September 4, 2020 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? Quote Link to comment Share on other sites More sharing options...
Casey Posted September 5, 2020 Share Posted September 5, 2020 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. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.