TI-GROMmy, the system GROM replacement

[RXB]

On 12/10/2023 at 6:05 AM, speccery said:

Thanks, I took a look at the files. There is no documentation how to use GPL@LOADER here, it seems to be an executable program. I assume it is part of the GRAM Kracker software. It does not appear there is source code, that's really what I was looking for. How is GPL@LOADER used? Do you load it with E/A or how does one launch it?

If you look at RXB my GPL RXB code for CALL PLOAD and CALL PSAVE (The P stands for PROGRAM) as it saves and loads a Program Image file

but the file has no location as all of them just assume they are 8K in size. Thus they can be moved to any location but I use a MOVE command

to do that as it is very small and compact way to do it. You could just take my RXB GPL code for CALL PSAVE and add a MOVE command in that 

subroutine and make your own loader and saver. I use this to load the SAMS and you can see it IN THE DARK game I put out. If the GPL MOVE 

routine was in the GPL routine it was be much faster then the RXB version. You could use this for GRAMMY

[Gary from OPA]

i opened up my ti99 and installed the grommy2 board today, and it works nice, i was able to use my univ. memory loader to load sob into the gram, and then using the config program copy it over into user bank 1 and when i restarted it was there.

 

only issue is after i power off the grommy2 defaults back to original system groms in bank 0, i asked in a private message about the ext. physical mode switch, as its not detailed here in the thread, once @speccery updates me on that, i will open back up my console again and install the switch, since i am running the dijit/avpc board with v9938, i want the sob on as default on power-up, as then the DSR detects it, and stops doing stupid patching, and overall the system works better.

 

i am looking forward now that this is working nicely, and the gram feature is nice, and there is two user banks, i can now start to work on v2 of the new ti99 os and upgrade sob with more features, and support newer devices, and be able to test it out in user bank 2, with still have original ti99 os in bank 0 and the v1 sob in bank 1 and the gram there for development uploading and patching and quick testing.

 

going to be cool to start really digging in and developing things, and also using the added adv. features of grommy2 once i learn some more about how it all works and what it can do, as it has extra space, and also the arm core as well to do more tricks.

 

i am really impressed with the board and the design, no need with this to recreate my SOB anymore, or worry about erasing and burning eproms on the original sob to test things out, and the fact my MG Gram-kracker is still in DR, so this fits the bill and offers more as well.

 

stay tuned for more cool things coming from me once i get cracking coding everyday.

 

 

[speccery]

Thanks @Gary from OPA for the writeup and your testing! I am glad to hear it is working for you. I have now a new version of firmware which reads a pin (PA3) and if that's low the system starts with user bank 1. 

 

I was working today for quite a while on the firmware update front, to be able to upgrade the firmware with just software running on the TI, while the grommy2 is inside the computer.

 

For background, when initially designing the firmware I was thinking that the way to do the upgrade would be by means of a serial port dongle or with a ST Micro ST-Link device. While those firmware update methods work and also make it possible to enable a bricked device (especially with the ST Link), it is inconvenient to have to wire things up to be able to update the firmware.

 

I added a pretty long while ago two provisions to help upgrading the firmware without adding any wiring: first was a specific command to reprogram the firmware with the contents of the GRAM memory (which I didn't test at the time due to lack of time) and the second was a backup method by being able to execute ARM code from GRAM. Now that I have tested things more it turns out the firmware indeed has some bugs which prevent the firmware reprogramming command from working.

 

However, I have been able to make the backup method work. If the GRAM is loaded with a file which contains both a new version of the firmware and some custom new code as well, the custom code can be executed by a command from the TI using the ability to run ARM code from GRAM - and I have used it to reprogram the firmware properly. Alas, there is a problem in that at least for now the custom code needs to be compiled so that it matches the version of the firmware already running on the device. This was silly of me, but originally I did not lock down the address of the GRAM in the ARM core's memory. Rather the address varies depending on the firmware loaded. Luckily there are not many versions of the firmware out there, so I should be able to compile versions of the upgrade packages for them. There are also techniques I should be able to use (compiling with position independent code or doing a slide of nops) to get around the problem.

 

I will continue to work on this, in addition to the firmware changes the TI config tool also needs some improvements.

[Gary from OPA]

13 minutes ago, speccery said:

Thanks @Gary from OPA for the writeup and your testing! I am glad to hear it is working for you. I have now a new version of firmware which reads a pin (PA3) and if that's low the system starts with user bank 1. 

 

I was working today for quite a while on the firmware update front, to be able to upgrade the firmware with just software running on the TI, while the grommy2 is inside the computer.

 

For background, when initially designing the firmware I was thinking that the way to do the upgrade would be by means of a serial port dongle or with a ST Micro ST-Link device. While those firmware update methods work and also make it possible to enable a bricked device (especially with the ST Link), it is inconvenient to have to wire things up to be able to update the firmware.

 

I added a pretty long while ago two provisions to help upgrading the firmware without adding any wiring: first was a specific command to reprogram the firmware with the contents of the GRAM memory (which I didn't test at the time due to lack of time) and the second was a backup method by being able to execute ARM code from GRAM. Now that I have tested things more it turns out the firmware indeed has some bugs which prevent the firmware reprogramming command from working.

 

However, I have been able to make the backup method work. If the GRAM is loaded with a file which contains both a new version of the firmware and some custom new code as well, the custom code can be executed by a command from the TI using the ability to run ARM code from GRAM - and I have used it to reprogram the firmware properly. Alas, there is a problem in that at least for now the custom code needs to be compiled so that it matches the version of the firmware already running on the device. This was silly of me, but originally I did not lock down the address of the GRAM in the ARM core's memory. Rather the address varies depending on the firmware loaded. Luckily there are not many versions of the firmware out there, so I should be able to compile versions of the upgrade packages for them. There are also techniques I should be able to use (compiling with position independent code or doing a slide of nops) to get around the problem.

 

I will continue to work on this, in addition to the firmware changes the TI config tool also needs some improvements.

sounds good to me... looking forward to trying out the update system via the ti99 only, and testing out the PA3 switch system. -- For me it will be a great help to have upgraded console os running at bootup, as I am using a v9938 on my avpc card, and that will stop the need for DSR on Dijit card to be always patching the vdp registers, which mainly makes TI Basic useless, due to the original problem of TI setting the undefined vdp bits to 1 instead of 0. - reason why originally my TIM had the SOB device with the upgraded os.

 

still have to dig around and see if i can find a toggle switch for PA3, but I guess I could just tied it low now that I have the files already loaded into the flash, but would be good to go back to original groms (bank 0) incase of a problem.

 

One question, with PA3 tied low, that does not prevent software wise, to use the config or command to switch to bank 2 or bank 0 software wise, and do a reset (not a power-off) to switch over to using the other banks right?

 

also If i do go ahead and install a switch, is there any harm in moving the LED off the board and placing it on the outside of console along with switch, so I can see the light, as with the console closed up, I can't see the LED, but is there really any need to look at it? -- All tho I love having blinking lights, the more the better.

Edited July 21 by Gary from OPA
added led question.

[speccery]

17 minutes ago, Gary from OPA said: 

One question, with PA3 tied low, that does not prevent software wise, to use the config or command to switch to bank 2 or bank 0 software wise, and do a reset (not a power-off) to switch over to using the other banks right?

 

also If i do go ahead and install a switch, is there any harm in moving the LED off the board and placing it on the outside of console along with switch, so I can see the light, as with the console closed up, I can't see the LED, but is there really any need to look at it? -- All tho I love having blinking lights, the more the better.

PA3 is only sampled when the MCU starts from reset, so it only has an impact on the initial bank. You can switch banks to your heart’s content programmatically afterwards.

 

no harm in moving the LED. I think the led is lit when a grom access is ongoing, so there is some information value with it. To be honest mine is also inside the console, so not visible to me atm. If you use another led it’s good to use a bright low current led like the one installed on the board. All boards need leds  

[Gary from OPA]

21 minutes ago, speccery said:

PA3 is only sampled when the MCU starts from reset, so it only has an impact on the initial bank. You can switch banks to your heart’s content programmatically afterwards.

 

no harm in moving the LED. I think the led is lit when a grom access is ongoing, so there is some information value with it. To be honest mine is also inside the console, so not visible to me atm. If you use another led it’s good to use a bright low current led like the one installed on the board. All boards need leds  

so PA3 what is the best way to tie it LOW, is there a spot on the board itself I can use, since officially there is no ground, or should i run a wire from pa3 to ground spot on the ti99 motherboard, thru a like 1k resistor as well, or just direct to GND, I don't want to damage any signals on your board, so want to do it safe as possible.

Edited July 21 by Gary from OPA
added picture

[speccery]

10 hours ago, Gary from OPA said:

so PA3 what is the best way to tie it LOW, is there a spot on the board itself I can use, since officially there is no ground, or should i run a wire from pa3 to ground spot on the ti99 motherboard, thru a like 1k resistor as well, or just direct to GND, I don't want to damage any signals on your board, so want to do it safe as possible.

Welcome to the wonderful world of the GROM ground connectivity   (for those who maybe don't know, the picture above is from the grommy2 firmware update doc).

The quick answer is that you can run the signal from your switch to the ground of the motherboard. Alternatively, you can connect the switch to the VSS above (top left, third signal), which is the ground of the grommy2. If you want to be extra safe, you could use a 100 ohm resistor, that will provide some protection if the connection is accidentally made somewhere else than ground. A 1k resistor is likely too high and may not successfully pull PA3 to the ground (it could work too).

 

The signals on the right and left are the same and only signals which all GROM chips on the mother board connect to. There is no ground there, the closest thing is the -0.7V biased "ground". Since the grommy2 only connects to the same signals as regular GROM chips, it has no console ground available. What I did was that there is a diode connected from the ground of the grommy to the -0.7V level. Since the diode voltage drop is about 0.6V, the ground (VSS) of the grommy2 is almost at the same level as the ground of the console, but it is not the same signal physically. I guess the real GROM chips can't really pull signals low enough (especially on a loaded bus), so by making the ground of the GROM chips -0.7V there is some headroom even if a GROM cannot pull its outputs low enough. It is a weird arrangement.

[Gary from OPA]

The ST Link v2 programmer dongle thingy arrived today by Amazon along with some small toggle switches, so later on today if I have time going to open up my console again and flash the new firmware and wired up the switch to the PA3, so I can switch between booting into original console grom bank 0 or sob v1 groms in bank 1 on console power up.

 

This will still leave software selectable bank 2 for testing my new sob v2 operating system.

[speccery]

@Gary from OPA I have been working quite a bit on the grommy2 firmware upgrade tools. I have tested several methods and tried to come up with easy ways to do the in-system upgrade of the firmware.

 

In system programming, software only:

1. Update old grommy2 in system even with bogus firmware. I spent quite a bit of time to work on this. The upgrade is done with the "grommy2 config" tool (a GROM cartidge program) with a specific payload.
2. grommy2 with a fixed firmware properly supporting future firmware updates. Again update is made with grommy2 config, but no specific payload needed, rather just the new firmware stored in GROM. This method is how upgrades will be done in the future.

In system programming, using external hardware:

3. Use of FTDI usb to serial adapter and ST Micro STM32CubeProgrammer. This path I have tested already, but the new component is that I checked that the upgrade can be made using the strangecart as the usb to serial adapter. This required a small update to the firmware of the StrangeCart, namely adding support for even parity.

 

4. In addition, if one has an ST-Link dongle available, that is probably the safest way to update firmware, but requires specific wiring and the use of STM32CubeProgrammer software.

 

I attach a version of the strangecart firmware which includes support for options 1 and 3 above.

Option 1: With the strangecart, switch to cartridge image #4 using call carts(4), grommy update. Issue the following commands once switched to that cartridge.

4 - enable shadow

9 - switch to more...

5 - copy 24k grom 8000 gram (this takes a while, the one I tested was from 0.6.01 to 0.7.21 included here)

7 - ARM execute 4000

Cycle the power of the console, the firmware should now be updated. Switch to Grommy config to check if the firmware was updated. Basically if the system boots it's good news..!  This update method must not be used if the grommy2 is already in 0.7.21 or newer version.

 

Option 3: requires USB connection to the strangecart, wire serial ports of grommy2 to strangecart (wires crossing, RX-TX and TX-RX). SWCLK needs to be connected to the VCC of the grommy2. After this, power on the console. The grommy2 will go to update mode. Login to the strangecart using a terminal program, and issue the command "usb2serial 1" which makes the strangecart a USB-to-serial bridge with 115200,E,1 so this is with even parity. After this exit the terminal program, and use STM32CubeProgrammer in UART mode. For me the StrangeCart in macOS is available both as a tty... and cu... device, the cu... device is the one to choose within STM32CubeProgrammer.

 

There isn't a whole lot of error checking in these processes. Getting method 1 to work was not easy, I will write later separately how I made it working.

 

I attached:

- the strangecart firmware (firmware.bin)

- the newest version of the grommy firmware grommy2.bin (if you use the ST Link or other serial port based setup)

- g2config.bin - this is a GROM cartridge image which contains GPL code, new firmware, and specific firmware updater ARM code for method 1. This file is already included in the strangecart firmware load as GROM cartridge #4.

firmware.bin

grommy2.bin g2config.bin

[Gary from OPA]

54 minutes ago, speccery said:

I attach a version of the strangecart firmware which includes support for options 1 and 3 above.

Option 1: With the strangecart, switch to cartridge image #4 using call carts(4), grommy update. Issue the following commands once switched to that cartridge.

4 - enable shadow

9 - switch to more...

5 - copy 24k grom 8000 gram (this takes a while, the one I tested was from 0.6.01 to 0.7.21 included here)

7 - ARM execute 4000

Cycle the power of the console, the firmware should now be updated. Switch to Grommy config to check if the firmware was updated. Basically if the system boots it's good news..!  This update method must not be used if the grommy2 is already in 0.7.21 or newer version.

i think i will try option 1, using my strangecart to update the grommy2 as a test, worse case if it bricks I got the st link v2 to use.

 

of course, still going to have to open up my console, to add the physical toggle switch to PA3 so i can bootup into bank 1 on power-up of the console.

 

ok, now what is the easy way to upgrade the strangecart firmware again, i haven't tried that yet.

[Gary from OPA]

Well, that was easy, using the strangecart to update the firmware first, funny thing i had to go thru 4 micro-usb cables, i found 3 of mine short little cables, don't pass data, just power, so that was useless at first, i thought for a bit, that my strangecart was not being picked up by my laptop, until i finally tried the 4th cable, i guess those other 3 cables, were leftover ones i had from power banks or other devices that only need charging not data.

 

once that problem was solved, it was simple to drag and drop the new firmware bin onto the strangecart, and i used my tty program afterwards to make sure it was now on the latest build.

 

then i plugged my strangecart into my grommy2 console, and ran call carts(4) and followed the steps, and zippy do, my grommy2 was updated with no problems.

 

of course afterwards i had to reload my bank 1 with my sob v1 groms, as that got wiped out during the firmware upgrade, so that took me a few extra steps to do.

 

now to open up my console, and solder in the physical switch on pa3 so i can select what bank to power-up as. bank 0 (original) or bank 1 (sob v1).

 

i still have st link v2 in guess i need it in the future, as least it is there as backup, and only cost me $7.99 CAD so that was worth it.

 

as you can see from attached screenshots, i am now running on the new grommy2 firmware.

[speccery]

Thats great news! I am happy to hear it worked. To say it was a bit complex to get this working would be an understatement. I was so focused on trying to get this done that i didn’t really test the existing functionality, but it **should** be intact. It’s late for me, i will follow up with some more details later. Anyway the new versions should be easy or easier to update in the future.

[Gary from OPA]

It works great, I installed the toggle switch into the top cover thru one of the slots that are easier to remove as they not fully attached, and then ran the common switch pin to Vss on the grommy2 and one side of the switch to the PA3 pin, I used wires with terminal plugs so not to solder anything on the grommy2 itself, so easy to unplug if need be.

 

And when I power up in original grom mode, everything is messed up as the dijit/avpc dsr I am running is not doing any vdp register patching.

 

And in the other position I power up into my sob v1 which been flashed into bank 1 which of course now displays fine as the ti99 o.s. had the right v9938 registers.

 

I can now get to work on improving my upgraded os and testing it in bank 2.

 

Wonderful device the grommy2 is, many thanks to Erik for the fast work in fixing the firmware upgrade and enabling the physical PA3 bank switch for developers like me.

[speccery]

8 hours ago, Gary from OPA said:

Wonderful device the grommy2 is, many thanks to Erik for the fast work in fixing the firmware upgrade and enabling the physical PA3 bank switch for developers like me.

 

thanks @Gary from OPA I am glad that it is working for you! It's good to hear the board is getting some good use, don't hesitate to let me know if you have improvement ideas. I will try to keep the grommy2 a simple and easy to understand device, unlike the strangecart which has evolved into a pretty big software project. I also want to work on the configuration tool some more, to make it more robust and user friendly.

 

8 hours ago, Gary from OPA said:

I am curious, is that red board your flat screen video adapter? I am asking as it looks a lot like a board I bought to be used with multiple retrocomputers for scan conversion to use modern displays. I haven't put enough time to get to know how to use of it. I was going for the ESP8266 extension (to minimise latency) but I didn't get it to work immediately and ran out of time when I was checking it out, probably a year ago or something like that.

[speccery]

Updated documentation of grommy2 at GitHub here: https://github.com/Speccery/StrangeCart-Doc/blob/main/grommy2/README.md

 

This now reflects version 0.7.21 of the grommy2 firmware.

[Gary from OPA]

45 minutes ago, speccery said:

thanks @Gary from OPA I am glad that it is working for you! It's good to hear the board is getting some good use, don't hesitate to let me know if you have improvement ideas. I will try to keep the grommy2 a simple and easy to understand device, unlike the strangecart which has evolved into a pretty big software project. I also want to work on the configuration tool some more, to make it more robust and user friendly.

 

I am curious, is that red board your flat screen video adapter? I am asking as it looks a lot like a board I bought to be used with multiple retrocomputers for scan conversion to use modern displays. I haven't put enough time to get to know how to use of it. I was going for the ESP8266 extension (to minimise latency) but I didn't get it to work immediately and ran out of time when I was checking it out, probably a year ago or something like that.

Yes, it is what I use to convert the analog 15.75khz RGB output from the v9938/58 chip which is Composite SYNC to VGA.

 

I tried few other devices which are all based on the more common green board and even the open source gsb-control one and even costly 200 boxes, and they all produced horrible pictures or had syncing issues.

 

I have found ntsc 60hz is harder to handle for these devices, most seem to be configured for 50hz scart systems when it comes to syncing.

 

But these cheap Chinese red board worked perfectly, menus are all in Chinese only. But not much adjustment was needed just a couple of button pushs to move the picture up a bit and to the right a bit.

 

https://www.aliexpress.com/item/1005006613991933.html

 

https://www.amazon.ca/Converter-Definition-Conversion-Professional-Processing/dp/B07W7T3FTQ

[speccery]

I worked some more on the grommy2 config tool. I also created a test project which compiles a simple ARM program which can be executed with the tool (provided the test program is loaded into the GRAM). I did this to be able to test that the grommy2 config tool is able to run ARM code and that a suitable ARM program will return gracefully so that the grommy2 can continue to work as before.

 

Pretty much all the visible changes are on the second page (the memory dump page) of the config tool.

 

I attach the GROM image of the config tool (config.bin). This needs to be loaded into GROM address >6000 i.e. as a normal GROM cartridge.

config.bin

I also attach a new version of strangecart firmware (firmware.bin) which includes this version of the tool as cartridge 3.

 

The second screen now looks like below. I spent way too much time in improving the GROM display tool (it now uses a short assembly routine in scratchpad to do convert to hex and display a byte). I also added a hex editor which is currently only used to edit the values of three 16-bit variables called X, Y and Z. If one enters X, Y or Z the current value of the variable is shown and can be edited (by entering hex digits, enter when done). Of these variables X can be used in option 6 to launch an ARM program in the offset X within the GRAM area. Y is used to set the base address of the hex dump, making the tool actually useful to look around GROMs. This hex display thing can be used even without a grommy2, the other functions don't really make sense without one.

firmware.bin

[RickyDean]

On 9/14/2022 at 4:08 PM, speccery said:

I feel that I’m still learning with every new project about software I didn’t know about… what does TIM SOB do? Some kind of driver for 80 column mode?

Well somehow I let this one slip by, you've already found out what the SOB is, so I still want 3?

[Gary from OPA]

25 minutes ago, RickyDean said:

Well somehow I let this one slip by, you've already found out what the SOB is, so I still want 3?

You don't need my original sob device anymore, I going to be releasing a new version that will support the grommy2, from all my tests it is the best console GROM replacement device so far. My sob only replaced grom 0 and 1 and was great at the time for using only two gals and 16k eprom, but it was limited in what I could add to the ti99 os since I only had 4k extra space to work with.

 

With grommy2 I have extra 6k to work with in the original grom area in bank 1 and because you can software switch to bank 2 there is room for at least another 18k of code as you can temporarily use all the ti basic area in bank 2 while still having 2k of grom 0 as well.

 

So that gives you an easy total of 24k of new space for gpl code, and that is still with keeping the original ti groms in bank 0 and ti basic in bank 1.

 

Lots of room to make a really nice ti99 front end operating system for everyone to enjoy.

 

Soon I will need to order another grommy2 from Erik for my other ti99 system once I have polished off some additions for this system using a v9938 so I can also make some cool boot up support for f18a which is in my other system.

 

It is time for a 2025 dream operating system for the ti99. Don't want to say 2024 as I doubt I have v2 sob in 2024, but will have at least a beta one for others to enjoy on their grommy2 before the end of the year and to give me suggestions on what else to add after they get a general idea of what I am cooking up for everyone to enjoy.

[speccery]

@Gary from OPA how much GROM space would you need, ideally? With the current grommy2 hardware, I could enable one more user Flash GROM bank. Then there would be the default system bank of 24K GROM and three user banks of 24K for a grand total of 96k GROM. That would still leave 16K flash for future software extension.

 

On the RAM side, it is good to leave something for future use, but another 4k bytes of RAM could be allocated for GRAM. With larger amounts of GRAM and GROM capacity, it becomes a question on how that should be organised so that it is convenient for GPL software use. For example paging could be used in the GROM space with 2K page size (i.e. have 12 page slots of 2K each in the memory map and for each 2K page select a 2K GROM or GRAM page).

 

When prototyping, I also created the Super Grommy prototype, versions 0.1 and 0.2 pictured below.

This microcontroller has USB, 512K of flash and 144k of RAM. So it could support for example 16 banks of 24K of GROM and 4 banks of 24K GRAM with still memory to spare. The MCU package I used here is a 48 pin TQFP, but the same MCU can be had in the same 32 pin TQFP as in the current grommy2, and it is pin compatible. The 32 pin version does not support USB however, which is a feature I thought would be useful for the super grommy. I think I went perhaps a bit overboard with this one. Also, with a revised PCB, both grommy2 and super grommy could be fitted with a serial flash chip which would be more than fast enough from GROM use. In that case the GROM capacity would be measured in megabytes. 

 

In terms of speed, the grommy2 serves GROM content in around 2 microseconds, or four times faster than a normal GROM (I documented that somewhere earlier in this thread). If there are no legacy GROM chips connected, then GROM traffic is much faster. Sadly this has limited system performance impact, since the GPL interpreter uses at least tens (if not hundreds) of TMS9900 instructions per a GPL instruction, rendering even these major access time improvements pretty much unnoticeable.

[Gary from OPA]

5 hours ago, speccery said:

@Gary from OPA how much GROM space would you need, ideally? With the current grommy2 hardware, I could enable one more user Flash GROM bank. Then there would be the default system bank of 24K GROM and three user banks of 24K for a grand total of 96k GROM. That would still leave 16K flash for future software extension.

 

On the RAM side, it is good to leave something for future use, but another 4k bytes of RAM could be allocated for GRAM. With larger amounts of GRAM and GROM capacity, it becomes a question on how that should be organised so that it is convenient for GPL software use. For example paging could be used in the GROM space with 2K page size (i.e. have 12 page slots of 2K each in the memory map and for each 2K page select a 2K GROM or GRAM page).

 

When prototyping, I also created the Super Grommy prototype, versions 0.1 and 0.2 pictured below.

This microcontroller has USB, 512K of flash and 144k of RAM. So it could support for example 16 banks of 24K of GROM and 4 banks of 24K GRAM with still memory to spare. The MCU package I used here is a 48 pin TQFP, but the same MCU can be had in the same 32 pin TQFP as in the current grommy2, and it is pin compatible. The 32 pin version does not support USB however, which is a feature I thought would be useful for the super grommy. I think I went perhaps a bit overboard with this one. Also, with a revised PCB, both grommy2 and super grommy could be fitted with a serial flash chip which would be more than fast enough from GROM use. In that case the GROM capacity would be measured in megabytes. 

 

In terms of speed, the grommy2 serves GROM content in around 2 microseconds, or four times faster than a normal GROM (I documented that somewhere earlier in this thread). If there are no legacy GROM chips connected, then GROM traffic is much faster. Sadly this has limited system performance impact, since the GPL interpreter uses at least tens (if not hundreds) of TMS9900 instructions per a GPL instruction, rendering even these major access time improvements pretty much unnoticeable.

Yes, i think that would be nice, 3 user banks of 24k, for 96k in total. -- which still leaves the system grom area untouched.

 

Which brings me to question about that "system grom" is there a way to burn in changes to that area bank 0, so it replaces the original console grom, of course it is always great to have untouched version for backup/restore usage, so maybe not wise, but there is wasted 2k/2k/2k in that area officially. -- in fact really for restore/backup usage grom 1/2 is not needed, the bank 0 could be squeezed down to 8k or even 6k.. never mind me, i just thinking out aloud. personally, 96k of user space is good enough for now, we see how it goes.

 

as for super groomy, that is nice design as well, but i think it would only be useful if we ran a couple of extra wires, solder in a13/a12/a11 to allow for official multiple grom banks, if you have free control wires for that, and a way to latch in what grom base is currently being accessed. of course that removes the drop in, replace idea as you need to solder wires.

 

but for future big project i have in mind for a new /4a motherboard design i am slowly working on, the super groomy idea would be perfect, as then it could just be incorporated into the traces the extra address lines needed for the module.

 

in regard to grom bases, i was thinking earlier about that even on the grommy2, the pa3 instead of being on a switch, it could be tied to address line, but then your firmware would have to be polling it to see if it changes, and no point, unless you had two free pins, for a13/a12, then it could automatically switch the selected bank 0/1/2/3 depending on the current grom base, and of course still requires running two wires, maybe that could be done in your firmware, i have studied it yet to see how it all works, and only be useful for my purposes if system groms in bank 0 were replacable, and updateable as well, allowing from copy of gram bank to bank 0 as well. or attachable to firmware update.

 

just some random thoughts to think about, i have some as well for strangecart, but i will lay them out later on this week, its a monday here and too many things to catch up on, after taking sunday off.

[speccery]

@Gary from OPA thanks for sharing those thoughts.

• I have also thought about the writability of the system bank, but so far I've thought the simplicity of having unmodified regular GROMs there has been winning in my mind. It also keeps the idea of being a replacement for GROMs. Currently the top 2k is wasted there, that's true.
• Would there be any merit in having the top 2k areas of system GROMs be writable? If so, how would one branch there, I mean would making them writable also mean that the rest of the system GROM area would need to be writable to be useful?
• Even the grommy2 has currently enough free pins to support the official banking. However, as the grommy2 is designed to serve the system GROM area (although it of course could serve any area), is there merit in supporting multiple system GROM area bases? I suppose there is no existing software which would take advantage of banks in the system area.
• Banking in the system area would require further configuration, and that configuration would need to stored somewhere, in practice the flash memory of the grommy2. Perhaps this could work in a way that if PA3 is low, stored configuration is used. If there is no stored configuration, PA3 low would select user bank 1.

[RXB]

19 hours ago, Gary from OPA said:

Yes, i think that would be nice, 3 user banks of 24k, for 96k in total. -- which still leaves the system grom area untouched.

 

Which brings me to question about that "system grom" is there a way to burn in changes to that area bank 0, so it replaces the original console grom, of course it is always great to have untouched version for backup/restore usage, so maybe not wise, but there is wasted 2k/2k/2k in that area officially. -- in fact really for restore/backup usage grom 1/2 is not needed, the bank 0 could be squeezed down to 8k or even 6k.. never mind me, i just thinking out aloud. personally, 96k of user space is good enough for now, we see how it goes.

 

as for super groomy, that is nice design as well, but i think it would only be useful if we ran a couple of extra wires, solder in a13/a12/a11 to allow for official multiple grom banks, if you have free control wires for that, and a way to latch in what grom base is currently being accessed. of course that removes the drop in, replace idea as you need to solder wires.

 

but for future big project i have in mind for a new /4a motherboard design i am slowly working on, the super groomy idea would be perfect, as then it could just be incorporated into the traces the extra address lines needed for the module.

 

in regard to grom bases, i was thinking earlier about that even on the grommy2, the pa3 instead of being on a switch, it could be tied to address line, but then your firmware would have to be polling it to see if it changes, and no point, unless you had two free pins, for a13/a12, then it could automatically switch the selected bank 0/1/2/3 depending on the current grom base, and of course still requires running two wires, maybe that could be done in your firmware, i have studied it yet to see how it all works, and only be useful for my purposes if system groms in bank 0 were replacable, and updateable as well, allowing from copy of gram bank to bank 0 as well. or attachable to firmware update.

 

just some random thoughts to think about, i have some as well for strangecart, but i will lay them out later on this week, its a monday here and too many things to catch up on, after taking sunday off.

I put out a video and link on Atari Age years ago on using SWGR and RTGR commands built into the TI Console.

I got SWGR and RTGR to work on Classic99 and on a Real TI using a PGRAM or GRAMKRACKER or MESS or GRAMULATOR

In my video I show how to switch from one GROM base to another and back again.

Below is the RYTE DATA GPL Manual for the GPL Assembler.

You could also reference Therry GPL Manaual for more data.

ASSM-DOC (2021_08_22 17_15_51 UTC).txt

[RXB]

10 hours ago, speccery said:

@Gary from OPA thanks for sharing those thoughts.

• I have also thought about the writability of the system bank, but so far I've thought the simplicity of having unmodified regular GROMs there has been winning in my mind. It also keeps the idea of being a replacement for GROMs. Currently the top 2k is wasted there, that's true.
• Would there be any merit in having the top 2k areas of system GROMs be writable? If so, how would one branch there, I mean would making them writable also mean that the rest of the system GROM area would need to be writable to be useful?
• Even the grommy2 has currently enough free pins to support the official banking. However, as the grommy2 is designed to serve the system GROM area (although it of course could serve any area), is there merit in supporting multiple system GROM area bases? I suppose there is no existing software which would take advantage of banks in the system area.
• Banking in the system area would require further configuration, and that configuration would need to stored somewhere, in practice the flash memory of the grommy2. Perhaps this could work in a way that if PA3 is low, stored configuration is used. If there is no stored configuration, PA3 low would select user bank 1.

Please read my previous post above to Gary on SWGR and RTGR these have already been fully researched by me and demoed in a video.

[RXB]

Ok found the videos I made on the above:

 

Now I did get SWGR and RTGR to work in Classic99 after all.

This would work a ton less complicated on REAL IRON as Emulators tend to cheat on GROM/GRAM bases.

Edited July 30 by RXB