The FinalGROM 99

[+arcadeshopper]

Or you can send it to me as well if that doesn't work out..

Greg

Sent from my LM-V600 using Tapatalk

[wierd_w]

Makes me wonder if a sideport "enabler" would be doable...  It could contain an ACTUAL GROM, and no ROM, that satisfies the check routines in the QI, and or-- intercepts startup before getting disabled with a CRU write. (since its on the sideport.) It could then chainload the FG99, by jumping execution after the cru write.

 

Just a crazy far-fetched idea. No idea if it would even work.

[ralphb]

4 minutes ago, wierd_w said:

Makes me wonder if a sideport "enabler" would be doable...  It could contain an ACTUAL GROM, and no ROM, that satisfies the check routines in the QI, and or-- intercepts startup before getting disabled with a CRU write. (since its on the sideport.) It could then chainload the FG99, by jumping execution after the cru write.

 

Just a crazy far-fetched idea. No idea if it would even work.

The FinalGROM already has a GROM menu.  But this is only a requirement for v2.2 consoles.  As I wrote above, v2.2 is independent of QI consoles.  It is only QI consoles that the FinalGROM doesn't work on, and the reason is currently unknown.

 

But speaking of "sideport enablers", the SDD 99 is a sidecar that -- among other things -- also runs ROM and GROM carts.

[+OLD CS1]

On 8/13/2020 at 8:39 AM, ralphb said:

QI and v2.2 are actually two different things: You can have QI with version 1.x and v2.2 without QI.

Re-iterating this point.  QI consoles do not necessarily have the GROM-only checks against the GROM port.  Consoles, whether QI or not, can have the v2.2 operating system which ignore ROM-only cartridges.

[+helocast]

1 hour ago, ralphb said:

Yes, we can do that, or sell your FG99 to OLD CS1.

Appreciate the offer. PM'd OLD CS1.

I'll keep my reply short since I'm in Dev. I really wanted it to work ... if nothing else to have a piece of every tech offered here.

I can't keep up, but retired pension/money permitting I try.

 

Doug

P.S. Brewing Academy on Ebay still swears up and down this combo "works" and I've sent them a message to alter their listing in that regard. ¯\_(ツ)_/¯

[+arcadeshopper]

Appreciate the offer. PM'd OLD CS1.
I'll keep my reply short since I'm in Dev. I really wanted it to work ... if nothing else to have a piece of every tech offered here.
I can't keep up, but retired pension/money permitting I try.
 
Doug
P.S. Brewing Academy on Ebay still swears up and down this combo "works" and I've sent them a message to alter their listing in that regard. ¯\_(ツ)_/¯

I'll message him too

Sent from my LM-V600 using Tapatalk

[+MacRorie]

3 hours ago, helocast said:

Appreciate the offer. PM'd OLD CS1.

I'll keep my reply short since I'm in Dev. I really wanted it to work ... if nothing else to have a piece of every tech offered here.

I can't keep up, but retired pension/money permitting I try.

 

Doug

P.S. Brewing Academy on Ebay still swears up and down this combo "works" and I've sent them a message to alter their listing in that regard. ¯\_(ツ)_/¯

 

3 hours ago, arcadeshopper said:

I'll message him too

Sent from my LM-V600 using Tapatalk
 

I have added a notation about QI boards.  BTW, direct email address: macrorie@thebrewingacademy.com  Always open to changes, just need the information.

Edited August 14, 2020 by MacRorie
Put up a picture. "Every day's a school day"

[majestyx]

For the Dumping feature that I see on the FG99 homepage, I am confused about how this is done, or maybe I'm expecting it to do something that it does not do.

 

I read the description of this feature, but am just not getting how this works. Is there some way to take a snapshot of the game state of existing cartridges which is then overwritten to the .bin files on the SD card? Since the description mentions "To save the progress or high scores of games..." I take that to mean that one can "save" the progress of a game such as Parsec, where you may be having a great run & want to save the game state to come back to later. Or is this feature for future ROM images created specifically to use this feature? I don't understand how to trigger the dump while playing a game, if that is indeed what is being referenced.

[ralphb]

13 hours ago, majestyx said:

For the Dumping feature that I see on the FG99 homepage, I am confused about how this is done, or maybe I'm expecting it to do something that it does not do.

 

I read the description of this feature, but am just not getting how this works. Is there some way to take a snapshot of the game state of existing cartridges which is then overwritten to the .bin files on the SD card? Since the description mentions "To save the progress or high scores of games..." I take that to mean that one can "save" the progress of a game such as Parsec, where you may be having a great run & want to save the game state to come back to later. Or is this feature for future ROM images created specifically to use this feature? I don't understand how to trigger the dump while playing a game, if that is indeed what is being referenced.

Alas, it doesn't work for Parser or other legacy programs.  What dumping does is save the image in memory back to SD card.  Now, for ROM and GROM carts, this doesn't do anything, because you cannot modify the image in memory, as ROM and GROM are read-only.

 

But if you active RAM and/or GRAM mode, you can modify the image (i.e., allocate variables inside the image, and then update them) and save this back to SD card.

 

For example,

   AORG >6000

   DATA >AA01, 0, 0, ...   ; header

SCORE:
   DATA 0
HIGHSCORE:
   DATA 0

START:
   CLR  @SCORE
   ...
HIT:
   INC  @SCORE
   ...

As a ROM cart, this "game" doesn't work, since SCORE and HIGHSCORE are in ROM and cannot be modified.  If you activate RAM mode, however, you can modify SCORE and HIGHSCORE, and the dump function would write the changed SCORE and HIGHSCORE along with the rest of the image back to SD card.  Hence, the progress is saved.

 

Parsec, on the other hand, allocated variable in scratchpad RAM, which is not contained in the image, so you cannot save that by dumping Parsec.

[ngtwolf]

On 8/10/2020 at 7:49 AM, helocast said:

A little slower, 55ns vs 45ns and wider voltage supply range. Other than that it is also in the 44-pin TSOP II package.

$6.92 AS6C8008-55ZIN https://www.mouser.com/datasheet/2/12/AS6C8008-1288432.pdf

 

I haven't checked compatibility any closer than that.

Doug

 

On 8/12/2020 at 7:21 AM, ralphb said:

Basically any SRAM IC from this page should work:

https://www.digikey.com/products/en/integrated-circuits-ics/memory/774?k=sram&k=&pkeyword=sram&sv=0&pv276=127091&pv276=130284&pv276=202821&pv276=171276&sf=1&FV=-8|774%2C69|409393%2C142|227886%2C961|407300%2C1291|220518%2C1291|220519%2C1989|0%2C2043|383917&quantity=&ColumnSort=0&page=1&pageSize=25

 

Note that some parts are listed multiple times in different minimum quantities, and some are not in stock.

 

EDIT:  To be safe, download the datasheet before you buy and check that the pins match the original (attached).

cy62158ev30ll.pdf 335.33 kB · 2 downloads

Cool, thanks for the responses guys, i'll check these out.

[+InsaneMultitasker]

Is it possible to 'activate' or change to an advanced mode once the cartridge is loaded?  Let's say the current cartridge operates in ROM mode but I wanted to run a program that needs RAM at 0x7000.  Can I load & start my program, then somehow instruct the FG99 to switch to RAM mode? 

[HOME AUTOMATION]

The mode will be controlled by the 3rd byte in the new image you load.

[+InsaneMultitasker]

1 hour ago, HOME AUTOMATION said:

The mode will be controlled by the 3rd byte in the new image you load.

Thanks, that makes sense, but I also want to know if I can select a cartridge and then make the change myself from within a program. 

[HOME AUTOMATION]

Oh boy... this is too long an explanation!

 

Spoiler

I personally have only done this from a program image already running in the FG99.

 

There's an example on Github, but some of the instructions therein, are a bit beyond my immediate understanding, as are their comments! Without an FG99 emulation, or a really good debugger running on real hardware, I would need to experiment with these instructions until they become clear to me.

 

Being unfamiliar with the assembler's conventions used in the example, hasn't helped either.

 

So I cribbed some code from jedimatt42's FORCE COMMAND. But it only loads the new image.bin, then resets to the master title screen, requiring the user to select the module from the TI's menu screen. I'm fairly certain, you can branch to a specific entry-address, after reloading though, if you already know the correct address.

 

I instead took a more complex route, replacing the FG99's menu, with a power-up header and some initialization code that will auto-run the newly loaded module, which also requires a power-up header. Unfortunately, this method requires loading a modified upgrade.avr file into the FG99. A task that if not performed correctly, can brick the FG99. Plus I haven't come close to understanding the FG99's internal code, which apparently populates the menus, on-the-fly. Without a power-up header in the desired image, I would need to program in, all the images desired, manually first.

 

Not too sure the FG99's designer would appreciate this idea whole-heartedly either.

 

Here's a link to Ralph's examples:

 

https://github.com/endlos99/finalgrom99/tree/master/lib

 

If you try to load, rather than re-load, you will need to exclude the ">99, 'OKFG99', >99". Not positive this will work if the FG99 hasn't been started from a power-up header though.

 

I found jedimatt42's code, by searching "OKFG99" in FORCE COMMAND's ROM image. The two examples are nearly identical.

 

Edited September 1, 2020 by HOME AUTOMATION

[+InsaneMultitasker]

18 minutes ago, HOME AUTOMATION said:

Oh boy... this is too long an explanation!

 

  Hide contents

I personally have only done this from a program image already running in the FG99.

 

There's an example on Github, but some of the instructions therein, are a bit beyond my immediate understanding, as are their comments! Without an FG99 emulation, or a really good debugger running on real hardware, I would need to experiment with these instructions until they become clear to me.

 

Being unfamiliar with the assembler's conventions used in the example, hasn't helped either.

 

So I cribbed some code from jedimatt42's FORCE COMMAND. But it only loads the new image.bin, then resets to the master title screen, requiring the user to select the module from the TI's menu screen. I'm fairly certain, you can branch to a specific entry-address, after reloading though, if you already know the correct address.

 

I instead took a more complex route, replacing the FG99's menu, with a power-up header and some initialization code that will auto-run the newly loaded module, which also requires a power-up header. Unfortunately, this method requires loading a modified upgrade.avr file to the FG99. A task that if not performed correctly, can brick the FG99. Plus I haven't come close to understanding the FG99's internal code, which apparently populates the menus, on-the-fly. I need to program in, all the images desired, manually first.

 

Not to sure the FG99's designer would appreciate this idea whole-heartedly either.

 

Here's a link to Ralph's examples:

 

https://github.com/endlos99/finalgrom99/tree/master/lib

 

If you try to load rather than re-load, you will need to exclude the ">99, 'OKFG99', >99". Not positive this will work if the FG99 hasn't been started from a power-up header though.

 

I found jedimatt42's code, by searching "OKFG99" in FORCE COMMAND's ROM image. The two examples are nearly identical.

 

Hah!  No problem,   I probably am not providing enough information, so we are even. 

 

Let's say that my selected cartridge is Extended BASIC.  I would like the XB cart to start up like usual, run the DSK1.LOAD program, which in turn would load an assembly file (program image) into memory.  The program image file would execute.  XB has ROM in the 6000-7fff space, however, I would like RAM in the 7000-7fff space for the program I just loaded.

 

Re-reading the documentation, it seems that I would need to somehow include a bank to set up RAM with an image based on the following:

"To enable one of these [advanced] modes for a specific image, put character R, G or X at image offset 3, also known as "reserved" byte. For legacy images, you may use a Hex Editor to modify the fourth byte."

and

"You can preset the RAM by putting the desired values in the upper half banks of your image. Only occupied banks contain RAM, so if you load a 4 bank image, you'll have 4 * 4 KB = 16 KB of RAM available."

 

Maybe by adding an image to the XB cartridge load sequence? I'll do some more reading as I seem to be missing information or misunderstanding the FG99 operation. 

[HOME AUTOMATION]

4 hours ago, InsaneMultitasker said:

Hah!  No problem,   I probably am not providing enough information, so we are even. 

 

Let's say that my selected cartridge is Extended BASIC.  I would like the XB cart to start up like usual, run the DSK1.LOAD program, which in turn would load an assembly file (program image) into memory.  The program image file would execute.  XB has ROM in the 6000-7fff space, however, I would like RAM in the 7000-7fff space for the program I just loaded.

 

Re-reading the documentation, it seems that I would need to somehow include a bank to set up RAM with an image based on the following:

"To enable one of these [advanced] modes for a specific image, put character R, G or X at image offset 3, also known as "reserved" byte. For legacy images, you may use a Hex Editor to modify the fourth byte."

and

"You can preset the RAM by putting the desired values in the upper half banks of your image. Only occupied banks contain RAM, so if you load a 4 bank image, you'll have 4 * 4 KB = 16 KB of RAM available."

 

Maybe by adding an image to the XB cartridge load sequence? I'll do some more reading as I seem to be missing information or misunderstanding the FG99 operation. 

o.k. I think I'm beginning to get an inkling of what your up to...

 

You don't want to load a different cartridge, you just want to change the upper(D.bin) to RAM.

I'm afraid the truth is... you are forced to reload all parts of an image(G,C,D) at once. Can't be done individually.

 

So as an alternative you would like to set up the initial image(s) to allow for some ram in the >7000->7FFF bank, or add another bank or more.

 

I think I ran into a dead end here before, and someone else solved the issue, but i'm not sure who or where.

 

The problem is when a cartridge is set-up to use G, C, and D, there's no way to have more than 8k each, in C and D.

 

The obvious solution is to copy the data from D into C, which can than be expanded to more banks ...by increasing C,s size beyond 16k.

 

I have tried this before and XB always crashes... I think this is because the C, D, images use a different banking method, perhaps inverted. So, I instead tried, transposing C and D's data within the single C image. But this also fails!

 

So being unfamiliar with the different "banking formats" and not having a clear example on hand, I am perplexed.

 

I imagine either the data needs to be rearranged or perhaps the banking addresses to write to are different, or used differently, dunno!

 

I'm getting tired too ...big day tomorrow. Possibly one more joke left in me tonight, sorry!

Edited September 1, 2020 by HOME AUTOMATION

[ralphb]

15 hours ago, InsaneMultitasker said:

Is it possible to 'activate' or change to an advanced mode once the cartridge is loaded?  Let's say the current cartridge operates in ROM mode but I wanted to run a program that needs RAM at 0x7000.  Can I load & start my program, then somehow instruct the FG99 to switch to RAM mode? 

What HOME AUTOMATION said was basically correct.  You cannot switch to RAM mode while you're running.   What you could do is reloading the same image with RAM mode enabled (induces a small delay, also state might be lost).

 

What is the problem of having RAM right from the start?

[Tursi]

No, C/D images are standard "inverted" 16k images, it should work.

[+InsaneMultitasker]

2 hours ago, ralphb said:

What HOME AUTOMATION said was basically correct.  You cannot switch to RAM mode while you're running.   What you could do is reloading the same image with RAM mode enabled (induces a small delay, also state might be lost).

 

What is the problem of having RAM right from the start?

It is more of a convenience issue and trying to limit the user needing to type the program path.file each time.

 

1. If the program is loaded from within Extended BASIC, there is no RAM available at 0x7000.

2. If the program is loaded from another rom/cartridge environment, such as Force Command, RAM is not necessarily available at 0x7000.

 

I know that I can instruct the user to load the program from Editor Assembler option 5, with RAM mode enabled at 0x7000. It's just not that efficient.

[HOME AUTOMATION]

Editor... get help!!!

 

Edited September 2, 2020 by HOME AUTOMATION

[HOME AUTOMATION]

21 hours ago, @ralphb said:
What is the problem of having RAM right from the start?

------------------------------------------------------------------------------------------------------

When XB runs, it expects the bank to switch, 8k pages. However, in RAM mode the pages are 4k, So the upper page doesn't switch. Causing XB to crash after the first line is input! 

21 hours ago, @Tursi said:
No, C/D images are standard "inverted" 16k images, it should work.

------------------------------------------------------------------------------------------------------

Apparently, my first attempts failed due to something going wrong with my FG99, the next attempts all resulted in the FG99's LED just flashing, finally I realized, nothing would start... after reloading "version_1_3.avr", I was back in business(Never had this happen before, it appears to be the result of my cartridge port failing, the FG99's LED, kept getting extremely dim at times). After running my last few attempts again(unsuccessfully), I re-ran the first two, one of which succeeded! Unsurprisingly, you were right.
 
18 hours ago, @InsaneMultitasker said:
It is more of a convenience issue and trying to limit the user needing to type the program path.file each time.

1. If the program is loaded from within Extended BASIC, there is no RAM available at 0x7000.
2. If the program is loaded from another rom/cartridge environment, such as Force Command, RAM is not necessarily available at 0x7000.

I know that I can instruct the user to load the program from Editor Assembler option 5, with RAM mode enabled at 0x7000. It's just not that efficient.

------------------------------------------------------------------------------------------------------

So, I did get XB, extended to 32k, this provides for two more 8k ROM pages, but if set up as RAM, XB crashes... best I could do... Maybe you can do something more with it! Set the fourth byte to >52 for RAM mode, but XB will crash.

 

EXBASICG.BIN

 

EXBASICC.BIN

On 8/31/2020 at 2:36 PM, @HOME AUTOMATION said:
The mode will be controlled by the 3rd byte in the new image you load.

------------------------------------------------------------------------------------------------------

Doh! I meant to say, 4th byte... 0,1,2,3.

Edited September 2, 2020 by HOME AUTOMATION
replaced: EXBASICC.BIN w/cleared pages 3,4. I had left some old data there.

[ralphb]

22 hours ago, Tursi said:

No, C/D images are standard "inverted" 16k images, it should work.

That's actual news to me!  But then, I don't know any "original" carts with more than 8K ROM files.

 

For the FlashROM and FinalGROM, all files have to be uninverted.

[ralphb]

1 hour ago, HOME AUTOMATION said:

21 hours ago, @ralphb said:
What is the problem of having RAM right from the start?

------------------------------------------------------------------------------------------------------

When XB runs, it expects the bank to switch, 8k pages. However, in RAM mode the pages are 4k, So the upper page doesn't switch. Causing XB to crash after the first line is input!

I think ExtBASIC was just an example.  But obviously when you add RAM/GRAM to it, you need to adapt the bank switching as well!  I assumed he wrote a cart from scratch, and there I don't see the difference.

[HOME AUTOMATION]

1 hour ago, ralphb said:

For the FlashROM and FinalGROM, all files have to be uninverted.

Yes, I thought it was the image where I had transposed the data which worked.

 

When I re-checked, C and D's data were still in the same order in my new... single C image.

 

So, you win again!

[Asmusr]

Would it be possible to add a new cartridge type to the FG99 where you could page in 4K pages of the ROM at >6000 and >7000 independently? So, for instance, you could page in >0000->0fff of the ROM at >6000 and >2000->2fff of the ROM at >7000? Or even the same 4K at both >6000 and >7000?