TI-GROMmy, the system GROM replacement

[Gary from OPA]

58 minutes ago, RXB said:

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 22 kB · 1 download

Yes, it amazing stuff. I used them in my Pop-Cart and with my pgram+ as well.

 

To use it with the grommy2 it would require the user to run and solder two address lines, as console grom sockets of course don't have the extra address lines needed for multiple grom bases like the cartridge port.

 

I published long time ago sample code using these commands, I should release that Library on GitHub soon and here as it has a number of useful extensions, but currently except for those with hsgpl or pgram+ all current hardware sadly don't support it.

 

Classic99 does have the ability to load multiple grom bases so that is good.

 

In my ongoing thoughts for @speccery an update for grommy2 to allow for two extra wires to automatically switch between bank 0 / 1 / 2 and if he adds bank 3 as there is room would be great. 

 

I thinking this way, if possible, controlling two modes via PA3 if left unconnected grommy2 boots up into bank 0 with default system grom and doesn't do from base switching.

 

And if PA3 is pulled low, it then monitors the two extra external address lines to automatically allow switching between banks 0/1/2/3.

 

Now for this new advanced mode to get fully useful it would also have to unlock bank 0 to be flashable, unless there was tiny bit more room to have a permanent 6k original grom 0 for failsafe boot up if PA3 is not low.

[RXB]

I guess I should order a GROMMY2 when it is released.

[Gary from OPA]

2 minutes ago, RXB said:

I guess I should order a GROMMY2 when it is released.

It's available now, you can PM him, and when he has one built up you can have it shipped to you, it was affordable for me to get the StrangeCart and grommy2 at the same time, with shipping costs, etc. I have one and Erik been busy updating the firmware. It's very useful. I going to be working on a whole much better version of my opa micromanager for it, adding in ton of little features and support for tipi, etc.

 

Currently to switch banks you just have to issue some firmware commands to the interface which is located in the last 16 bytes at 5ff0 but having extra two wires for advanced automatic mode would be nicer when it comes to working alongside other devices like pgram+ and proper grom base support.

[RXB]

21 hours ago, Gary from OPA said:

It's available now, you can PM him, and when he has one built up you can have it shipped to you, it was affordable for me to get the StrangeCart and grommy2 at the same time, with shipping costs, etc. I have one and Erik been busy updating the firmware. It's very useful. I going to be working on a whole much better version of my opa micromanager for it, adding in ton of little features and support for tipi, etc.

 

Currently to switch banks you just have to issue some firmware commands to the interface which is located in the last 16 bytes at 5ff0 but having extra two wires for advanced automatic mode would be nicer when it comes to working alongside other devices like pgram+ and proper grom base support.

How come 16 bytes?

GROM/GRAM has the POWERUP bytes to auto run a routine a single 2 bytes tell the OS to run that routine.

16 bytes seems really odd considering that a DSR or Power up 2 bytes could do that faster with less work.

***********************************************************
*                        GROM HEADER
***********************************************************
       GROM >2000
       AORG 0
       DATA >AA01      * VALID GROM / VERSION 
       DATA >0100      * (FUTURE EXPANSION) (YOU COULD USE THESE 2 BYTES AS THEY OS IGNORES THEM)
       DATA >0000      * POWERUP                  (YOU COULD USE TO RUN A ROUTINE HERE)
       DATA >0000      * PROGRAMS                (THIS IS XB OR OTHER CARTS PROGRAM LIST WITH HEADERS)
       DATA >0000      * DSR                          (YOU COULD USE TO RUN A ROUTINE HERE BY CALLING IT FROM BASIC OR DSR ACCESS)
       DATA >0000      * CALL                         (YOU COULD USE TO RUN A CALL LIKE IN XB)
       DATA >0000      * INTERUPT                  (YOU COULD USE TO RUN A INTERUPT SUBROUTINE ALSO)
       DATA >0000      * BASIC CALL               (BASIC CALL LIST WITH HEADERS NOT THE SAME AS XB)

 

What is preventing the GROMMY from using this instead?

[Gary from OPA]

2 hours ago, RXB said:

How come 16 bytes?

GROM/GRAM has the POWERUP bytes to auto run a routine a single 2 bytes tell the OS to run that routine.

16 bytes seems really odd considering that a DSR or Power up 2 bytes could do that faster with less work.

***********************************************************
*                        GROM HEADER
***********************************************************
       GROM >2000
       AORG 0
       DATA >AA01      * VALID GROM / VERSION 
       DATA >0100      * (FUTURE EXPANSION) (YOU COULD USE THESE 2 BYTES AS THEY OS IGNORES THEM)
       DATA >0000      * POWERUP                  (YOU COULD USE TO RUN A ROUTINE HERE)
       DATA >0000      * PROGRAMS                (THIS IS XB OR OTHER CARTS PROGRAM LIST WITH HEADERS)
       DATA >0000      * DSR                          (YOU COULD USE TO RUN A ROUTINE HERE BY CALLING IT FROM BASIC OR DSR ACCESS)
       DATA >0000      * CALL                         (YOU COULD USE TO RUN A CALL LIKE IN XB)
       DATA >0000      * INTERUPT                  (YOU COULD USE TO RUN A INTERUPT SUBROUTINE ALSO)
       DATA >0000      * BASIC CALL               (BASIC CALL LIST WITH HEADERS NOT THE SAME AS XB)

 

What is preventing the GROMMY from using this instead?

I was talking about the command interface on how you can talk to the microcontroller firmware on the grommy2, it is a 16 byte area at the end of grom 2 from 5ff0 to 5ffe.

 

See the wiki for more information: https://github.com/Speccery/StrangeCart-Doc/tree/main/grommy2#command-interface

 

Now the way it works, it is fine if you have code located somewhere else like in a cartridge or the 32k to send commands to do operations line switch firmware banks.

 

But from within the grommy2 own space it makes it a bit tricky to switch banks, it is still possible with a single move command as long as the next line of code you going to execute is placed correctly in the new bank you just ended up in.

 

Programming wise if you truly want to fully use all the extra space as one solid larger operating system, it would be easier to have the banks switch base on the grom base address using two external address wires.

 

Still it is possible with careful coding to use the existing software interface, even easier if the program is running in the cartridge space or 32k, but that doesn't work if you want to code something totally standalone using only grommy2 without the need of other memory.

 

Hopefully, this explains it a bit better for you, read over Erik docs he posted and you understand the 16 byte command interface I was talking about.

[RXB]

What about something that is already built into the TI99/4A console?

SWGR switches GROM/GRAM base and address to another GROM/GRAM

RTGR returns GROM/GRAM base to a previous GROM/GRAM

 

[Gary from OPA]

57 minutes ago, RXB said:

What about something that is already built into the TI99/4A console?

SWGR switches GROM/GRAM base and address to another GROM/GRAM

RTGR returns GROM/GRAM base to a previous GROM/GRAM

 

yes, at some point i want to do that it would make coding alot easier for larger ti99 operating system, and I am working with Erik in updating the firmware, for this to work on the grommy2 we have to run and solder two ext. wires to the a12/a13 lines to latch in the grom address base, as unlike the cartridge port, the default grom sockets, don't have any extra lines to tell what base they are assigned to. -- it is doable, and when @speccery has time we see what he cooks up for a new firmware to allow official bank switching, by the user adding two external wires when they install the grommy 2 device inside their /4a console.

[Artoj]

On 7/24/2024 at 6:14 PM, Gary from OPA said:

But these cheap Chinese red board worked perfectly

Gary, I have the same board version 5.2, the only thing is that I never got any instructions with it, so I have only hit and miss situation to set it up for the TI.

Edited August 5 by Artoj

[speccery]

Update on my work with the grommy2: I haven't had as much time as I would have liked to work on it. I still have made some progress, but the firmware is not ready for release yet.

Let' start with the hardware wiring, it goes as pictured below. These are the two bank selection address lines wired up (note that I use the normal numbering for address lines, not the reversed TI order, although that too is indicated below i.e. A13 TI order, A2 for normal people). Note that I haven't yet tested that this wiring works for reading address lines but it should be ok, with the old firmware it works as in the past.

ROM Pin 7 = A1 of ROM = A13 of the TMS9900 (A2) = PA8 of GROMMY2 pin 1 of J6 = blue wire

ROM Pin 6 = A2 of ROM = A12 of the TMS9900 (A3) = PC6 of GROMMY2 pin 2 of J6 = yellow wire

Since we're adding wires, it also makes sense to add a third wire, to the ground of the console (brown wire). Console ground is not available in the GROM chip socket.

As far as firmware goes, I have now added a new parameter, banking mode, but implementation is only halfway done at this point. The system is now a whole lot more complex than before, to support operation without soldering the address wires and to provide more flexibility for software. New terminology:

• bank=memory area selected for the entire 24K system GROM area
• page=8K page within the system GROM area. There are three 8K pages to make up a bank of 24K. You can think that one page equals to one 8K GROM chip.

 

There are four banking modes:

• Mode 0: TI standard bank switching. Two address lines used to select the GROM base select the bank. The whole bank of 24K changes depending on the state of wired address lines. The state changes for each read and write. The SWGR and RTGR will work in this mode.
• Mode 1: grommy2 banking. This is the way how the grommy2 has worked so far. The entire 24K system GROM bank is switched the same way as before. But there are now four banks of 24K, so one more than before, and the previously read-only system GROM bank 0 is now also writable. The state of the address lines has no impact. The same 24K system bank is seen in all GROM bases.
• Mode 2: 8K paging. For each 8K GROM address space slot at >0000, >2000 and >4000 a byte is written through the command interface, selecting one of 256 possible 8k pages for each slot. On the grommy2 there are 12 possible ROM pages (96K of flash), ranging from page number 0 to 11. There are also three GRAM pages numbered as 128, 129 and 130. These correspond to the grommy2 banking so that pages 0,1,2 form bank 0, pages 3,4,5 form bank 1 and so on for GROM banks, and the pages 128,129 and 130 correspond to the 24K GRAM bank. Because in the 8k paging mode you can select for each 8k area it's own page, it is possible mix and match GROM and GRAM pages from different banks into the 24K system GROM address space. This mode is also useful for the grommy2 config tool to manage the different banks.
• Mode 3: Failsafe mode. 6K system GROM0 is paged in to addresses >0..>17FF. This 6K GROM0 is not stored into any of the four 24K banks, but is outside of them. This mode is enabled programmatically or by bringing external pin PA2 low at boot up. The idea here is that if one somehow messes up the system GROM area, this bank can be brought in and the grommy2 tool can be used to reprogram the GROM banks.

I've made the banking mode 0 the default boot up mode. I've enabled internal pulldown resistors for the two address lines, this is useful if the extra address wires do not exist. If the address lines are not wired the GROM bank 0 is selected for the system GROM bank.

 

Regardless of the mode there command interface can be used to issue commands to the grommy2. The interface has been extended to include new commands to change between the banking modes, see the current banking mode, read and write the page numbers for mode 2.

 

I will follow up when I get this finished. Comments are welcome.

Edited August 6 by speccery

[Gary from OPA]

29 minutes ago, speccery said:

Update on my work with the grommy2: I haven't had as much time as I would have liked to work on it. I still have made some progress, but the firmware is not ready for release yet.

Let' start with the hardware wiring, it goes as pictured below. These are the two bank selection address lines wired up (note that I use the normal numbering for address lines, not the reversed TI order, although that too is indicated below i.e. A13 TI order, A2 for normal people). Note that I haven't yet tested that this wiring works for reading address lines but it should be ok, with the old firmware it works as in the past.

ROM Pin 7 = A1 of ROM = A13 of the TMS9900 (A2) = PA8 of GROMMY2 pin 1 of J6 = blue wire

ROM Pin 6 = A2 of ROM = A12 of the TMS9900 (A3) = PC6 of GROMMY2 pin 2 of J6 = yellow wire

Since we're adding wires, it also makes sense to add a third wire, to the ground of the console (brown wire). Console ground is not available in the GROM chip socket.

As far as firmware goes, I have now added a new parameter, banking mode, but implementation is only halfway done at this point. The system is now a whole lot more complex than before, to support operation without soldering the address wires and to provide more flexibility for software. New terminology:

• bank=memory area selected for the entire 24K system GROM area
• page=8K page within the system GROM area. There are three 8K pages to make up a bank of 24K. You can think that one page equals to one 8K GROM chip.

 

There are four banking modes:

• Mode 0: TI standard bank switching. Two address lines used to select the GROM base select the bank. The whole bank of 24K changes depending on the state of wired address lines. The state changes for each read and write. The SWGR and RTGR will work in this mode.
• Mode 1: grommy2 banking. This is the way how the grommy2 has worked so far. The entire 24K system GROM bank is switched the same way as before. But there are now four banks of 24K, so one more than before, and the previously read-only system GROM bank 0 is now also writable. The state of the address lines has no impact. The same 24K system bank is seen in all GROM bases.
• Mode 2: 8K paging. For each 8K GROM address space slot at >0000, >2000 and >4000 a byte is written through the command interface, selecting one of 256 possible 8k pages for each slot. On the grommy2 there are 12 possible ROM pages (96K of flash), ranging from page number 0 to 11. There are also three GRAM pages numbered as 128, 129 and 130. These correspond to the grommy2 banking so that pages 0,1,2 form bank 0, pages 3,4,5 form bank 1 and so on for GROM banks, and the pages 128,129 and 130 correspond to the 24K GRAM bank. Because in the 8k paging mode you can select for each 8k area it's own page, it is possible mix and match GROM and GRAM pages from different banks into the 24K system GROM address space. This mode is also useful for the grommy2 config tool to manage the different banks.
• Mode 3: Failsafe mode. 6K system GROM0 is paged in to addresses >0..>17FF. This 6K GROM0 is not stored into any of the four 24K banks, but is outside of them. This mode is enabled programmatically or by bringing external pin PA2 low at boot up. The idea here is that if one somehow messes up the system GROM area, this bank can be brought in and the grommy2 tool can be used to reprogram the GROM banks.

I've made the banking mode 0 the default boot up mode. I've enabled internal pulldown resistors for the two address lines, this is useful if the extra address wires do not exist. If the address lines are not wired the GROM bank 0 is selected for the system GROM bank.

 

Regardless of the mode there command interface can be used to issue commands to the grommy2. The interface has been extended to include new commands to change between the banking modes, see the current banking mode, read and write the page numbers for mode 2.

 

I will follow up when I get this finished. Comments are welcome.

Wow... great work... better than I thought when we exchanged some PM's regarding my ideas for changes and improves.

 

This will work out perfectly, can wait to be a beta tester for you with the new firmware once you get it working.

 

I like your idea of mixing and matching the pages in mode 2 as well, useful for development/testing work, when coding new software before switching up to mode 0.

 

Mode 3 (failsafe) is good as well, means that switch I already wired up will still come in handy, to boot up into failsafe mode, if the data is messed up somehow in the mode 0 banks.

 

looking forward to your next results.

 

thanks again.

[speccery]

@Gary from OPA I think I have now a new firmware version for testing. The new grommy2 firmware has version number 0.7.82 and supports all the banking modes discussed earlier. I was able to upgrade from 0.7.21 to it using the firmware upgrade facility as explained below. The upgrade method explained below cannot be used to upgrade from old versions, since it assumes the address space layout as 0.7.21. However, from this point on the address space layout will remain the same going forward. The process explained earlier in this thread can be used to get to 0.7.21.

 

I attach a bunch of files:

- firmware.binfor strangecart, it contains the grommy2 config utility two times, once just as the utility (cart 3) and another time with the firmware upgrade content (cart 4).

- g2config.binwhich is the GROM image, same as cart 4 above, can be loaded into any GROM system supporting 32K GROM cart. This is a 30K GROM image containing the GPL program grommy2 config 8k, 16k firmware, and 6k for the system GROM0.

- config.bingrommy2 GPL binary for the new version of the config software.

- grommy2-0.7.82.binfirmware for the grommy2. This can be programmed with ST-Link or USB serial dongle. It contains the firmware and system GROM image. Thus if everything else fails, with this the grommy2 can be brought to a known state using the STM32CubeProgrammer.

 

In principle, if everything works as expected (and you have still bank 0 containing the system GROMs), you should be able to upgrade as follows (nearly the same process as in the past):

1. First update strangecart with the new firmware.bin 

2. Reset strangecart and the console

3. Select TI BASIC, use CALL CARTS to check that cart 3 and cart 4 are there. Carts up to 5 come from the firmware, from there on from the external flash chip and may vary from what you have.

 

4. Assuming things are as expected, use CALL CARTS(4) to select the update. 

5. Select grommy2 config. You should see that you have the earlier version 0.7.21 firmware. The MODE indication and PG numbers will be wrong, since 0.7.21 does not support that.

6. From the main screen turn on shadow RAM (push 5). This is important so that GRAM can be written.

7. Switch to the dump screen (push U)

8. Copy firmware etc. from cartridge GROM space to GRAM (push 5). This takes a short while. The bit pattern on the top right hand corner will cycle once done.

9. Burn new firmware (push 0, then 1 to confirm). The update should go very quickly. Best to wait 10 seconds and then cycle the power.

And that's it. You should be able to boot normally.

 

With this config tool at present the process is unnecessarily complex and takes time to explain, but the steps for me took less than a minute to complete. In short what happens here is that first some mechanism is needed to get the g2config.bin into the GROM space as a normal cartridge image, the final GROM could be used as well (steps 1-5). After that the GRAM needs to be made writable and the new firmware copied to it (steps 6-8). The final step is to burn the firmware (step 9).

 

Next thing to check is that was the failsafe bank programmed automatically. You can do this by going to back to grommy2 config and to the new paging screen:

In here you can select the banking mode. Press 3 to select failsafe mode. This switches to a mixed mode where the failsafe (original GROM0) occupies the lowest 6K of GROM space, the rest is GRAM. If the fail-safe GROM space got programmed, nothing happens. If you exit back to the console's title screen, and then by pressing any key to the cartridge list, where TI BASIC should have disappeared. Obviously if the failsafe area did not get programmed, the system will get stuck. In that event cycle power. That should put you back to GROM bank 0, where you should have still the system GROM image. You can setup the failsafe area manually as well:

1. In the main screen enable GRAM shadow (press 1)

2. In the main screen copy GROM bank 0 to GRAM (press A)

3. Switch to dump screen (press U)

4. There is an undocumented function to burn the failsafe by copying the bottom 6K of GRAM to the fail safe area (press 8, then 1 to confirm). Note that this will check if the failsafe area is already programmed i.e. it is not empty.

 

I have had fun testing banking modes 1,2 and 3. I especially like the mode 2, 8K paging.

As discussed earlier, initially I was going to make banking mode 0 the default, but that does not work: the TI will get stuck when going from the title screen to the cartridge list screen. I assume this happens since for me the GROM banks 1,2 and 3 are empty, and when it is making the scanning between the different GROM bases the system GROM disappears if the bank is not zero.

 

That reminds me that I need to test if that is the cause - and it seems to be: after I copied the system GROM bank 0 to GRAM, and then from GRAM to flash banks 1,2 and 3 the cartridge list does appear even in banking mode 0! I haven't tested things too much, but the little I have tested things seem to work. I need to write some more documentation, but probably not today.

[Gary from OPA]

1 hour ago, speccery said:

@Gary from OPA I think I have now a new firmware version for testing. The new grommy2 firmware has version number 0.7.82 and supports all the banking modes discussed earlier. I was able to upgrade from 0.7.21 to it using the firmware upgrade facility as explained below. The upgrade method explained below cannot be used to upgrade from old versions, since it assumes the address space layout as 0.7.21. However, from this point on the address space layout will remain the same going forward. The process explained earlier in this thread can be used to get to 0.7.21.

 

I attach a bunch of files:

- firmware.binfor strangecart, it contains the grommy2 config utility two times, once just as the utility (cart 3) and another time with the firmware upgrade content (cart 4).

- g2config.binwhich is the GROM image, same as cart 4 above, can be loaded into any GROM system supporting 32K GROM cart. This is a 30K GROM image containing the GPL program grommy2 config 8k, 16k firmware, and 6k for the system GROM0.

- config.bingrommy2 GPL binary for the new version of the config software.

- grommy2-0.7.82.binfirmware for the grommy2. This can be programmed with ST-Link or USB serial dongle. It contains the firmware and system GROM image. Thus if everything else fails, with this the grommy2 can be brought to a known state using the STM32CubeProgrammer.

 

In principle, if everything works as expected (and you have still bank 0 containing the system GROMs), you should be able to upgrade as follows (nearly the same process as in the past):

1. First update strangecart with the new firmware.bin 

2. Reset strangecart and the console

3. Select TI BASIC, use CALL CARTS to check that cart 3 and cart 4 are there. Carts up to 5 come from the firmware, from there on from the external flash chip and may vary from what you have.

 

4. Assuming things are as expected, use CALL CARTS(4) to select the update. 

5. Select grommy2 config. You should see that you have the earlier version 0.7.21 firmware. The MODE indication and PG numbers will be wrong, since 0.7.21 does not support that.

6. From the main screen turn on shadow RAM (push 5). This is important so that GRAM can be written.

7. Switch to the dump screen (push U)

8. Copy firmware etc. from cartridge GROM space to GRAM (push 5). This takes a short while. The bit pattern on the top right hand corner will cycle once done.

9. Burn new firmware (push 0, then 1 to confirm). The update should go very quickly. Best to wait 10 seconds and then cycle the power.

And that's it. You should be able to boot normally.

 

With this config tool at present the process is unnecessarily complex and takes time to explain, but the steps for me took less than a minute to complete. In short what happens here is that first some mechanism is needed to get the g2config.bin into the GROM space as a normal cartridge image, the final GROM could be used as well (steps 1-5). After that the GRAM needs to be made writable and the new firmware copied to it (steps 6-8). The final step is to burn the firmware (step 9).

 

Next thing to check is that was the failsafe bank programmed automatically. You can do this by going to back to grommy2 config and to the new paging screen:

In here you can select the banking mode. Press 3 to select failsafe mode. This switches to a mixed mode where the failsafe (original GROM0) occupies the lowest 6K of GROM space, the rest is GRAM. If the fail-safe GROM space got programmed, nothing happens. If you exit back to the console's title screen, and then by pressing any key to the cartridge list, where TI BASIC should have disappeared. Obviously if the failsafe area did not get programmed, the system will get stuck. In that event cycle power. That should put you back to GROM bank 0, where you should have still the system GROM image. You can setup the failsafe area manually as well:

1. In the main screen enable GRAM shadow (press 1)

2. In the main screen copy GROM bank 0 to GRAM (press A)

3. Switch to dump screen (press U)

4. There is an undocumented function to burn the failsafe by copying the bottom 6K of GRAM to the fail safe area (press 8, then 1 to confirm). Note that this will check if the failsafe area is already programmed i.e. it is not empty.

 

I have had fun testing banking modes 1,2 and 3. I especially like the mode 2, 8K paging.

As discussed earlier, initially I was going to make banking mode 0 the default, but that does not work: the TI will get stuck when going from the title screen to the cartridge list screen. I assume this happens since for me the GROM banks 1,2 and 3 are empty, and when it is making the scanning between the different GROM bases the system GROM disappears if the bank is not zero.

 

That reminds me that I need to test if that is the cause - and it seems to be: after I copied the system GROM bank 0 to GRAM, and then from GRAM to flash banks 1,2 and 3 the cartridge list does appear even in banking mode 0! I haven't tested things too much, but the little I have tested things seem to work. I need to write some more documentation, but probably not today.

Thanks for the update. I will test it out later on today and report back.

 

One question since you said banking mode 0 not the default, how does that switch I hooked up before on PA3 works now. You mentioned before when it is pulled LOW now it goes to failsafe, what does it do when it is not pulled low, left unconnected.

 

Is it recommended I also run the ground wire now that I run the two new address lines, do you have closeup photos of where I connect them on grommy2. I need to review your older post. 

 

Is there any harm running the new wires before I update the firmware, or should I update the firmware first, make sure it works then add the new address lines.

 

Yes. For the banking to work properly the grom 0 needs to be in all 4 banks. And if grom 1 and 2 are empty and there is no cartridge in the port you should get displayed INSERT CART on the second screen after the title screen.

[speccery]

35 minutes ago, Gary from OPA said:

Thanks for the update. I will test it out later on today and report back.

 

One question since you said banking mode 0 not the default, how does that switch I hooked up before on PA3 works now. You mentioned before when it is pulled LOW now it goes to failsafe, what does it do when it is not pulled low, left unconnected.

 

Is it recommended I also run the ground wire now that I run the two new address lines, do you have closeup photos of where I connect them on grommy2. I need to review your older post. 

 

Is there any harm running the new wires before I update the firmware, or should I update the firmware first, make sure it works then add the new address lines.

 

Yes. For the banking to work properly the grom 0 needs to be in all 4 banks. And if grom 1 and 2 are empty and there is no cartridge in the port you should get displayed INSERT CART on the second screen after the title screen.

Thanks for testing when you have time. 

 

PA3 still works the same as in the past, it selects GROM bank 1 as the active bank instead of bank 0.

PA2 low selects the failsafe mode.

We can change these if another arrangement makes more sense.

 

Now that you will be soldering I recommend also putting in the ground wire. I connected it to the cathode of the LED, the pin closest to the edge of the board, that is the ground of the board (Vss). I think the pictures I posted earlier should show the wires pretty well. If not or if they're not clear enough, let me know and I can take new photos.

 

There should be no harm running the wires before the update.

 

One more thing, I told earlier about the manual failsafe bank programming, I think that must be done for the failsafe bank to work. That's what I did as well. I did add automatic programming, but it is not in the old firmware you have.

 

I will work on a simpler automated update process, which will do all the steps programmatically. It's just that during this development phase it's useful to manually control the settings.

[Gary from OPA]

5 minutes ago, speccery said:

Thanks for testing when you have time. 

 

PA3 still works the same as in the past, it selects GROM bank 1 as the active bank instead of bank 0.

PA2 low selects the failsafe mode.

We can change these if another arrangement makes more sense.

 

Now that you will be soldering I recommend also putting in the ground wire. I connected it to the cathode of the LED, the pin closest to the edge of the board, that is the ground of the board (Vss). I think the pictures I posted earlier should show the wires pretty well. If not or if they're not clear enough, let me know and I can take new photos.

 

There should be no harm running the wires before the update.

 

One more thing, I told earlier about the manual failsafe bank programming, I think that must be done for the failsafe bank to work. That's what I did as well. I did add automatic programming, but it is not in the old firmware you have.

 

I will work on a simpler automated update process, which will do all the steps programmatically. It's just that during this development phase it's useful to manually control the settings.

Ok. I understand now.

 

So. I should install a second toggle switch for PA2 so I can access the failsafe mode, incase both bank 0 and 1 are screwed up. So if PA3 is pulled low with PA2 it still be in failsafe right?

 

And the default is mode 1 on power-up right? So what is the simplest GPL command to switch it in mode 0 so I can insert it into my custom grom 0 startup code? Would be a one just move of 16 bytes of data right?

[speccery]

24 minutes ago, Gary from OPA said:

Ok. I understand now.

 

So. I should install a second toggle switch for PA2 so I can access the failsafe mode, incase both bank 0 and 1 are screwed up. So if PA3 is pulled low with PA2 it still be in failsafe right?

 

And the default is mode 1 on power-up right? So what is the simplest GPL command to switch it in mode 0 so I can insert it into my custom grom 0 startup code? Would be a one just move of 16 bytes of data right?

Whether you want to install another switch is up to you... I am not sure having two switches is necessary. PA2 overrides PA3. One option is to have only one switch and put that to PA2. The banking mode can be forced with a command over the serial port of the grommy2 as well. I don't have any switches on my console... But my console motherboard is without the top of the case so I can jumper things as needed.

 

Default mode is indeed mode 1. The simplest way is set mode is something like below (this is a partial copy of my code, the GSENDCMD is what I use). I use XDT99 to compile code with xga9.py. Of course if you don't issue other commands, you could just use the array move:  MOVE  >0010,@GCMDBYTE,G@HWIF

The source data must come from RAM or ROM, not GROM, since for the commands to work they need be contiguous writes to GROM. My code uses scratchpad RAM for the array, although that is quite a waste but I am testing my stuff without memory expansion.

GCMDBYTE 	* the following array in RAM
		BYTE >09, >F6, >00, >00, >00, >00, >00, >00	; Already set for banking mode 0
		BYTE >45, >50, >47, >52, >4F, >4D, >4D, >59 ; command key

GCMDP2 EQU GCMDBYTE+2
* Hardware interface address
HWIF     EQU >5FF0

* Switch to bank 0
SETBANK0	
    ST    9,@GCMDBYTE       ; Command 9 set banking mode
    ST    >00,@GCMDP2    	; Set banking mode 0
    B     GSENDCMD          ; Send command to HW

GSENDCMD
       ST   @GCMDBYTE,@GCMDBYTE+1        Setup the complement of command byte
       XOR   >FF,@GCMDBYTE+1             
       MOVE  >0010,@GCMDBYTE,G@HWIF      Send command to grommy2
       RTN

 

One more thing: if you want you can do the update without any wiring. Banking mode 0 won't work then, but the other modes will work.

Edited August 11 by speccery

[Gary from OPA]

@speccery I did some testing, i haven't installed the new wires yet, I wanted to config the 4 banks first, before putting in the new wires.

 

So I was able to upgrade the firmware with no issues.

 

But, of course the failsafe didn't program, so I had to do it manually.

 

For my own purposes since I am running a v9938 system, I decided to edit the failsafe grom 0 before programming it, so that way even in failsafe mode, I have a visible screen to operate from.

 

I made the following hexbytes changes to the original GROM 0:

 

044F = 80 becomes  A0 (R1 screen off)
0450 = 60 becomes  E0 (R1 screen on)
0451 = 00 nochange 00 (VDP R0)
0452 = 20 becomes  A0 (VDP R1)
0453 = F0 becomes  00 (VDP R2)
0454 = 0E nochange 0E (VDP R3)
0455 = F9 becomes  01 (VDP R4)
0456 = 86 becomes  06 (VDP R5)
0457 = F8 becomes  00 (VDP R6)
0458 = F7 nochange F7 (VDP R7)

 

Those are min. changes, I made a couple of others just for my own usage, changing the TEXAS INSTRUMENTS to FAILSAFE GROMMY2 (so i know I am in that mode)

 

That works great, it programmed and the failsafe mode works.

 

And I was able to program banks 1 / 2 / 3 with the data I wanted.

 

Now my only issue is bank 0 is still NOT-WRITABLE, even tho I pressed 7 to copy GRAM to bank 0, nothing happens, it doesn't mirror the changes I made in GRAM to old system bank 0, I tried everything, but sadly I could change the info.

 

Any hints on how I can update bank 0, would be greatly welcomed, that is so far the only bug I have found, of course I am doing all my testing without adding the two wires, but I need to be able to update bank 0 before I solder the new address lines.

 

Also, I didn't test it but you said the failsafe writing only works if its empty, it could come in handy, to be able to re-program the failsafe with of course a double ARE YOU SURE warning.

 

anyway, if we can at least get bank 0 to be updatable, then that would be great, other then that, everything seems to be ok.

 

Thanks.

 

[speccery]

Thanks @Gary from OPA glad to hear it went well despite the lengthy instructions. I will try to find some time during the day to look at the code and fix the issue. I actually already looked at the code and spotted the bug. As you can tell, I did not test everything... 

The version of the firmware you have already supports forced programming of the failsafe area. Another feature I did not test yet, but in theory that should work. The firmware you have also has a feature to program any 2K flash page in the 96k flash area for the four banks, also untested but available as undocumented feature in key 9 of the dump screen in grommy config you already have. For that the variables X,Y,Z need to be setup so that:

- low byte of X = source page number in GRAM (2k pages, so 0 to 11)

- low byte of Y = destination page number in Flash (2k Pages, 0 to 47)

- low byte of Z = number of 2K pages to program (at least 1)

So that could work even with your firmware, but let me test that first!

[Gary from OPA]

7 minutes ago, speccery said:

Thanks @Gary from OPA glad to hear it went well despite the lengthy instructions. I will try to find some time during the day to look at the code and fix the issue. I actually already looked at the code and spotted the bug. As you can tell, I did not test everything... 

The version of the firmware you have already supports forced programming of the failsafe area. Another feature I did not test yet, but in theory that should work. The firmware you have also has a feature to program any 2K flash page in the 96k flash area for the four banks, also untested but available as undocumented feature in key 9 of the dump screen in grommy config you already have. For that the variables X,Y,Z need to be setup so that:

- low byte of X = source page number in GRAM (2k pages, so 0 to 11)

- low byte of Y = destination page number in Flash (2k Pages, 0 to 47)

- low byte of Z = number of 2K pages to program (at least 1)

So that could work even with your firmware, but let me test that first!

Thanks, looking forward to the minor bugfix.

 

You did a great job, it's has turned into a amazing masterpiece of totally configurable set of software in such tiny piece of neat looking powerful hardware.

Edited August 12 by Gary from OPA

[speccery]

Thanks @Gary from OPA for your kind words!

I fixed the bug and did a quick test, now from power up I get this after mocking around with GROM0:

What I did was that I upgraded my grommy2 to the new version 0.7.83 which has the bug fix, and then used the version of Easybug which is in the default menu of StrangeCart to modify the string in GROM0 by hand.

That version of Easybug supports writes to GROM with the G command, and it has an extra command X which can be used to issue commands to grommy2. For example X0103 chooses bank user bank 3, X0200 copies user bank 00 to GRAM, and X0301 turns on the shadow GRAM mode. Thus the first two digits after X are the command code to grommy2 and the following two digits are the first parameter byte to grommy2. Commands requiring more than one parameter byte cannot be used with this simple thing.

 

Attached are the new files.

-firmware.binfor the strangecart, includes the new firmware again as cartridge 4. This is the only file you should need.

- g2config-0.7.83.binGROM cartridge containing grommy2 config with the firmware update

- grommy2-0.7.83.binfirmware binary for burning with STLink or serial method with STM32CubeProgrammer

 

The firmware update goes the same way as before: update the strangecart, select cart 4, enter grommy2 config. Then enable shadow RAM, switch to dump screen, copy from GROM 8000 to GRAM, and finally burn the firmware. Same stuff as in the message above. Probably best to follow that process, as I wrote this just very quickly.

[Gary from OPA]

3 minutes ago, speccery said:

Thanks @Gary from OPA for your kind words!

I fixed the bug and did a quick test, now from power up I get this after mocking around with GROM0:

What I did was that I upgraded my grommy2 to the new version 0.7.83 which has the bug fix, and then used the version of Easybug which is in the default menu of StrangeCart to modify the string in GROM0 by hand.

That version of Easybug supports writes to GROM with the G command, and it has an extra command X which can be used to issue commands to grommy2. For example X0103 chooses bank user bank 3, X0200 copies user bank 00 to GRAM, and X0301 turns on the shadow GRAM mode. Thus the first two digits after X are the command code to grommy2 and the following two digits are the first parameter byte to grommy2. Commands requiring more than one parameter byte cannot be used with this simple thing.

 

Attached are the new files.

-firmware.binfor the strangecart, includes the new firmware again as cartridge 4. This is the only file you should need.

- g2config-0.7.83.binGROM cartridge containing grommy2 config with the firmware update

- grommy2-0.7.83.binfirmware binary for burning with STLink or serial method with STM32CubeProgrammer

 

The firmware update goes the same way as before: update the strangecart, select cart 4, enter grommy2 config. Then enable shadow RAM, switch to dump screen, copy from GROM 8000 to GRAM, and finally burn the firmware. Same stuff as in the message above. Probably best to follow that process, as I wrote this just very quickly.

Thanks for the quick update. Hopefully, I can find time today to test, but I got a long scheduled important zoom meeting, being Monday so afterwards might not have the time or focus to get to my ti99, but as soon as I do I will report back, worse case will be on Tuesday.

[RXB]

20 hours ago, speccery said:

Whether you want to install another switch is up to you... I am not sure having two switches is necessary. PA2 overrides PA3. One option is to have only one switch and put that to PA2. The banking mode can be forced with a command over the serial port of the grommy2 as well. I don't have any switches on my console... But my console motherboard is without the top of the case so I can jumper things as needed.

 

Default mode is indeed mode 1. The simplest way is set mode is something like below (this is a partial copy of my code, the GSENDCMD is what I use). I use XDT99 to compile code with xga9.py. Of course if you don't issue other commands, you could just use the array move:  MOVE  >0010,@GCMDBYTE,G@HWIF

The source data must come from RAM or ROM, not GROM, since for the commands to work they need be contiguous writes to GROM. My code uses scratchpad RAM for the array, although that is quite a waste but I am testing my stuff without memory expansion.

GCMDBYTE 	* the following array in RAM
		BYTE >09, >F6, >00, >00, >00, >00, >00, >00	; Already set for banking mode 0
		BYTE >45, >50, >47, >52, >4F, >4D, >4D, >59 ; command key

GCMDP2 EQU GCMDBYTE+2
* Hardware interface address
HWIF     EQU >5FF0

* Switch to bank 0
SETBANK0	
    ST    9,@GCMDBYTE       ; Command 9 set banking mode
    ST    >00,@GCMDP2    	; Set banking mode 0
    B     GSENDCMD          ; Send command to HW

GSENDCMD
       ST   @GCMDBYTE,@GCMDBYTE+1        Setup the complement of command byte
       XOR   >FF,@GCMDBYTE+1             
       MOVE  >0010,@GCMDBYTE,G@HWIF      Send command to grommy2
       RTN

 

One more thing: if you want you can do the update without any wiring. Banking mode 0 won't work then, but the other modes will work.

Your ST >00,@GCMDP2 should be CLR @GCMPD2 it is faster then the ST command and takes less bytes.

 

Also why are you using a B to go to a subroutine with a RTN?

Why do you need the RTN as you are using a B in first place?

Far as I can see you could remove the B and it would work fine if that RTN is valued.

[speccery]

57 minutes ago, RXB said:

Your ST >00,@GCMDP2 should be CLR @GCMPD2 it is faster then the ST command and takes less bytes.

 

Also why are you using a B to go to a subroutine with a RTN?

Why do you need the RTN as you are using a B in first place?

Far as I can see you could remove the B and it would work fine if that RTN is valued.

Good tip on the CLR, thanks.

I initially had both of these routines as callable routines ending with RTN. The first routine was using CALL to get to the second at the end, which would return with RTN and then the first would return with another RTN. It’s standard practice in assembly (with processors which have a stack unlike the tms9900) to save a return by branching to the second routine and the RTN at the end will return then to the caller of the first routine. 

 

Anyway this is just simple example code, not optimal in any way.

[Gary from OPA]

Ok @speccery - I finally had time to sitdown today and focus on nothing but ti99 things, after having a horrible monday and taking tuesday off to recover from my crazy monday.

 

Here is my latest BUG report.

 

First step, new firmware you made, uploaded fine, and no problems writing/changing now user bank 0 the system bank! -- Thanks, at least that works now!

 

Next step, was to make a small change in each bank so I could test the automatic bank switching, I copied my OS to all 4 banks, full grom0/1/2 and in each Grom 1, I changed the text TI BASIC, with just the space changed to 0 or 1 or 2 or 3, that way I would see if everything is working, TI0BASIC / TI1BASIC / TI2BASIC / TI3BASIC.

 

Now the fun part adding the two new address wires, I followed your pictures, and soldered the A12 and A13 lines, and checked with digital multimeter, and also added the ground wire, and then moved my PA3 switch over to PA2.

 

Now for the BUGS part, first thing the PA2 switch, doesn't work at least for me, I get a BAD TONE, and blank screen, no failsafe mode, I tested with config Failsafe mode and it works, but not with physical switch, PA3 still works for selecting bank 0 or 1 on power-up, but no good with PA2 pulling it low, doesn't do nothing but lockup the console on power-up.

 

Second BUG, powering up of course without PA2 pulled low works, and of course your grommy2 goes into default paging mode, so I load up the config, change it to standard and press reset, and zippy-do, it reboots fine, but it only displays TI0BASIC and TI1BASIC, it doesn't display 2 or 3 in the screen of modules.

 

So I load up the memory editor I have which allows you to select page 1 / 2 / 3 / 4 and display the groms, and checking with it, I find that bank 0 is ok, and bank 1 is ok, but pages 2 and 4 are both bank 1.

 

So something is not right, it can't be a bad second wire, because if that would be the case, you would have bank 0 / bank 1 / bank 0 and bank 1 but instead its bank 0 / bank 1 / bank 1 / bank 1 (if that makes sense to you).

 

I attached a bunch of photos, and also my ea5 (assembly) memory editor i use as well. (tifiles format, from my tipi drive)

MEMEDIT

Edited August 14 by Gary from OPA

[speccery]

Thanks @Gary from OPA for the testing, bug report and all the details! The part you are testing is the part I haven’t tested much, my primitive test was too simplistic. 
I will check this and get back to you as soon as I have time.

[speccery]

Hi @Gary from OPA after your bug report I thought about the PA2 issue and knew the problem even without opening my computer. I changed the banking a little at some point, and that broke the PA2 fail safe mode entry. The firmware crashed. Here is the usual collection files, version 0.7.87, it fixes the failsafe mode entry. I don't have time right now for more testing.

I repeated what you did and have TI BASIC renamed for banks 0,1,2,3. Something indeed is not right for the standard mode banking yet.

firmware.bin- strangecart firmware with the new firmware for grommy2 (cart 4)

g2config-0.7.87.bin- config pgm + firmware

grommy2-0.7.87.bin- firmware only