How to detect FinalGROM99?

[+retroclouds]

I'm currently doing some experiments with FG99 usage in Stevie.

 

Basically what I want to do is store my program settings and add the possibility to backup editor text to the FG99.

That way I can take the final grom cartridge, plug it into my other TI-99/4a (which also has SAMS ofcourse) and continue working there.

 

That should be possible by creating an appropriately sized cartridge image and by using the advanced mode as described here: https://endlos99.github.io/finalgrom99/

(Yes, I am aware I can accomplish the same by saving my files to TIPI, but that's not the purpose of this excercise) ?

 

Anyway, the thing is, that as it stands now the final grom isn't supported in any of the popular emulators (js99er, classic99, mame, ...)

So I need a way to detect if I have a final GROM cartridge and enable programs options accordingly.

 

Is there a way to detect if there is a FG99 cartridge present?

 

Obviously it would be cool if any of the emulators would support FG99, but as long as that isn't the case I need to find an alternative.

[HOME AUTOMATION]

Off the top of my head, you could use GRAM vs. GROM, write a change to it ...save to the FG99's image, and then check to see if it took.

[RXB]

1 hour ago, HOME AUTOMATION said:

Off the top of my head, you could use GRAM vs. GROM, write a change to it ...save to the FG99's image, and then check to see if it took.

Well that would work but also it would assume a GRAMKRACKER is a FinalGROM cart.

I think just switch to write at >600E as how many other products would page in a non zero value at >6FFE and >6FFF

[senior_falcon]

9 minutes ago, RXB said:

Well that would work but also it would assume a GRAMKRACKER is a FinalGROM cart.

I think just switch to write at >600E as how many other products would page in a non zero value at >6FFE and >6FFF

XB 2.8 G.E.M. for one.

[HOME AUTOMATION]

1 hour ago, RXB said:

Well that would work but also it would assume a GRAMKRACKER is a FinalGROM cart.

Not unless GRAMKRACKER responds similarly to the FG99's save/reload sequence:

 

  >99,"OKFG99",>99

[+jedimatt42]

4 hours ago, HOME AUTOMATION said:

Not unless GRAMKRACKER responds similarly to the FG99's save/reload sequence:

 

  >99,"OKFG99",>99

I don't think the FinalGROM responds in any tangible way to the command, without committing to instructing it to load or save a memory image. Then you can poll for the image to show signs of existance... 4A -> FinalGROM99 communication appears to be unidirectional. 

 

The easiest way to tell if there is a finalgrom, is to look at the cartridge slot of the 4A before deciding to issue the command that depends on it.

 

That is a serious solution. I'm not trying to be funny. It is retro computing, sometimes the user is required to know what they are doing. 

 

However, if you were to code a routine to save to FG, then couldn't you code a routine to read from FG? And if you did both, and added a validate operation to your write, doing a compare while reading instead of overwriting the data, you could detect if the save was successful or not. This still leaves it in the user's hands to decide to issue the command, but at least you can tell them (yourself?) that it worked or didn't work, at the cost of save taking a performance hit.

[HOME AUTOMATION]

11 hours ago, HOME AUTOMATION said:

...save to the FG99's image, and then check to see if it took.

...Is there an echo in this cave...?

 

                     

 

                      

 

[+retroclouds]

Too bad the FG99 cart has no option to query the device so that you can detect if it’s a FG99.

Don’t know if this is something that could be added by a firmware update. 

But let’s be honest how many folks out there would do a firmware update or would be aware there’s even a firmware update.

 

This got me thinking that for future devices it would be cool if there’s a uniform way to identify the device.

Thinking about a GPL DSR call / device that returns a device, version, capabilities string.

 

Strangecart?

[+jedimatt42]

7 hours ago, HOME AUTOMATION said:

...Is there an echo in this cave...?

 

                     

 

                      

 

I like to call that "agreement"

[+InsaneMultitasker]

10 hours ago, HOME AUTOMATION said:

 

Hah, last week I happened to see the Twilight Zone episode where the townsfolk found and destroyed this cave-dwelling computing monstrosity. 

[HOME AUTOMATION]

3 hours ago, InsaneMultitasker said:

...the townsfolk found and destroyed this cave-dwelling computing monstrosity. 

 

Sure. Kidnap the humans......destroy the machine!

 

[+OLD CS1]

Please, no disassemble me.

[HOME AUTOMATION]

LAWGIVER: It is clear that you simply did not understand. I will re-phrase...

You are ordered to accompany us to the absorption chambers. The Good is all. Landru is gentle. You will come...

 

   

You attacked the Body. You have heard the Word and disobeyed. You will be absorbed.

 

?

 

[Ed in SoDak]

Space - The FinalGromTIer

[Ed in SoDak]

19 hours ago, retroclouds said:

... Thinking about a GPL DSR call / device that returns a device, version, capabities string.

 

Strangecart?

Like EXB's CALL VERSION perhaps? EXB returns 100(early version?) or 110 while SXB returns 120.

[RXB]

2 hours ago, Ed in SoDak said:

Like EXB's CALL VERSION perhaps? EXB returns 100(early version?) or 110 while SXB returns 120.

Currently RXB CALL VERSION(X) :: X will be 2020

 

[+retroclouds]

The FG99 still has some hidden gems barely utilized: 

 

https://endlos99.github.io/finalgrom99/

 

I mean you have 512K of RAM to your disposal in assembly language.

Yes, it is in 4K chunks/banks hidden in the cartridge space but very interesting nonetheless.

Also the possibility to save bank contents to the cartridge image on the SD card.

 

 

 

[jrhodes]

I find the best way to detect the FinalGrom99 is the visual inspection method .

[RickyDean]

2 hours ago, jrhodes said:

I find the best way to detect the FinalGrom99 is the visual inspection method .

Yep, hard to miss, if this is there or a GramKracker. I do have both and never got them confused. ...?

[Asmusr]

8 hours ago, retroclouds said:

The FG99 still has some hidden gems barely utilized: 

 

https://endlos99.github.io/finalgrom99/

 

I mean you have 512K of RAM to your disposal in assembly language.

Yes, it is in 4K chunks/banks hidden in the cartridge space but very interesting nonetheless.

Also the possibility to save bank contents to the cartridge image on the SD card.

Js99er supports RAM mode, but not reloading/dumping.

[+retroclouds]

37 minutes ago, Asmusr said:

Js99er supports RAM mode, but not reloading/dumping.

 

hmm, that is strange. I made a 64K cartridge image of Stevie that runs in FG99 ‘R’ mode (4K rom/4K ram) and it works on the real deal but locks up in Js99er.

 

I’ll do some more testing this weekend and let you know.

[Asmusr]

6 hours ago, retroclouds said:

 

hmm, that is strange. I made a 64K cartridge image of Stevie that runs in FG99 ‘R’ mode (4K rom/4K ram) and it works on the real deal but locks up in Js99er.

 

I’ll do some more testing this weekend and let you know.

It could be broken since I haven't tried it for a long time.

[+retroclouds]

On 5/20/2021 at 1:12 PM, Asmusr said:

It could be broken since I haven't tried it for a long time.

 

This is to confirm that it does work fine in js99er. Sorry for the confusion.

I must have done something wrong while building the cartridge image.

 

Repeated the build step once more and then it worked flawlessly. Will do some more testing.

Now if I could only dump my changes to the cartridge image again.

 

Perhaps I can hack something on a local js99er version. Quick question; with the online version, suppose the dump functionality is in place, couldn’t it just dump to a browser cookie that gets restored and used instead of the cartridge image? Probably not as easy as that, but the basic idea.

For sure you wouldn’t that as persistent storage, but for development purposes I guess it might work.

 

 

 

[Asmusr]

28 minutes ago, retroclouds said:

Perhaps I can hack something on a local js99er version. Quick question; with the online version, suppose the dump functionality is in place, couldn’t it just dump to a browser cookie that gets restored and used instead of the cartridge image? Probably not as easy as that, but the basic idea.

For sure you wouldn’t that as persistent storage, but for development purposes I guess it might work.

You could save it in the browser's database IndexedDB. That's what I do for Save State/Restore State (which appears to be broken BTW). Take a look at database.service. You could also save it in localStorage, which is what Raphael does.

[Asmusr]

If you want to work on the js99er code I suggest you make a fork in github so you can pull new updates and potentially make a pull request for me to merge in.