TI-GROMmy, the system GROM replacement

[speccery]

Enter the TI-GROMmy, a modern replacement board for the system GROMs of a TI-99/4A.

 

I already posted about this project in Facebook a while ago, so many of you may already be aware of what I have been working on. I took a short break from StrangeCart development and created this small board, which can be used to replace the three internal GROM chips. I have had it in sort of working order for a week or so, but only yesterday or the day before ironed out the last bugs.

Here is the board in the flesh installed into my TI-99/4A. As you can see from the dimensions, it takes the space of two GROM chips. For my latest testing I removed the remaining GROM, so all three are being served by the TI-GROMmy.

This board can be used to replace the system GROM chips, therefore enabling:

- Fixing a TI with defective GROM chip(s)

- Run any of the TI operating system versions, at least as far as the GROMs are concerned. In the current firmware version the MCU has to be reprogrammed with the GROMs you want to use.

- Extend the system GROMs to 8k each, as the TI-GROMmy already serves the entire 8K instead of the regular 6K for each chip, enabling additions to the standard GPL code.

- Create your own improved version of the GROM code and run it on the real iron.

 

Not done yet, but I will also alter the firmware so that the GROMs become writable. The LPC824 microcontroller used here has 8K of SRAM, and my plan is to use 6K of that for RAM based override: I will modify the firmware so that I will split the 24K of system GROM space into 256 byte pages, thus having 96 pages in total. If a GROM write is done, the 256 byte page containing the target byte is entirely copied to SRAM, and the write is done into SRAM. From that point on the SRAM version of the 256 byte page will be used. This way one can non destructively write to various areas of the system GROM, as long as the total amount of changes is less than 6K, you will be able to go on developing.

 

Edit: 2022-09-25 the writing now works.

 

The board has a LED, it is lit whenever the TI-GROMmy is driving data to the bus. Thus whenever a read operation into the system GROM is in progress, the LED is lit. In practice it is constantly dimly lit when TI BASIC is running.

 

I have tested the board with an actual Mini memory cartridge, and they seem to happily coexist. I have also tested it with the StrangeCart, and they can also nicely coexist. I have to locate my stash of the cartridges to try with other boards , but with the limited testing so far this all seems to work.

 

I have several test boards I've built, the one in the picture above as a straight pin header for programming the MCU, while another board has a right angle header to make the height of the board lower. A simple FTDI USB dongle is all that's needed to program the MCU, the open source program lpc21isp does the job nicely.

 

Compared to all of my other boards I've done so far, this one is super simple and a fast build. There are only 11 components and some pin headers. The 3D model shows an additional zener diode D1 which does not need to be populated.

 

As can be seen in the picture, there is one wire going to ground. I chose to go this way, since the ground level Vss on the GROM socket is actually -0.7 volts, not zero volts, another TI weirdness. No real ground level is available on the socket. Using Vss level as ground would mean that the signal swing of the 3.3V microcontroller would only go to about 2.3V level above the real ground. While this level works, it is a bit low. Also the input pins of the microcontroller would be seeing signal levels higher than 5 volts, which might but their 5V tolerance to the test.

 

I will check if I could remove the need of the dangling ground wire and use the Vss level provided in the socket. I could add a simple forward biased diode from the board's own ground to Vss. A 1N4148 diode has typically a forward voltage drop of 0.6 volts. It would lift the board's ground relative to Vss to about -0.1V, which should be fine and would allow removing the bodge wire to ground.

 

Edited September 25, 2022 by speccery
updates, clarity

[ti99iuc]

It is a very interesting project! thanks!

[+9640News]

Not having much recollection of the grom chips on the TI-99/4A, are they socketed, or does the modification require desoldering the grom chips?

[Hans23]

15 minutes ago, 9640News said:

Not having much recollection of the grom chips on the TI-99/4A, are they socketed, or does the modification require desoldering the grom chips?

They're always socketed, at least in the non-QI machines.

[+9640News]

Great! Sounds like a much easier process for an upgrade.

[RXB]

Guess this gives me a new GPL project!

[+Ksarul]

This would also be interesting for folks with old-school 80-column cards, as it would allow updating the TI BASIC ROMs so they wouldn't trigger strange behavior in the additional registers of the 9938/9958.

[speccery]

I will need to put some finishing touches to the firmware (i.e. to support the writability) but that should not take long. Would someone be interested in testing these boards? Would be nice to collect feedback and improvement ideas.

 

I would not recommend putting this in at this stage if you only have one console to work with, but I guess most people discussing here have several (I think I have four, two of which I use for testing and hardware development). The legs of the TI-GROMmy are thicker than those of ordinary GROM chips, but for me this has not been a problem and they fit in snuggly into the sockets. I've just soldered in standard pin headers.

 

Please let me know if you're interested in testing.

[+Vorticon]

Great project! That said, aside from allowing the replacement of defective GROMS, it's most interesting potential is going to be with someone expanding TI Basic or XB to add better functionality for example or something along those lines given the 8K space available. Rich, I'm talking to you 😄

[RickyDean]

I bet the TIM SOB firmware would be usable on this too. I want 3. You know, I've never really considered it, but I bet it's possible to load the sob firmware to my GramKracker too.

Edited September 14, 2022 by RickyDean

[RXB]

6 hours ago, Vorticon said:

Great project! That said, aside from allowing the replacement of defective GROMS, it's most interesting potential is going to be with someone expanding TI Basic or XB to add better functionality for example or something along those lines given the 8K space available. Rich, I'm talking to you 😄

A updated GPL of the SOB for F18 and Tursi fixes would be the best first approach to try.

[Reciprocating Bill]

I'd like to see the basic functionality of a disk manager built into the console. 

[RXB]

9 minutes ago, Reciprocating Bill said:

I'd like to see the basic functionality of a disk manager built into the console. 

Not enough space to do that, I modified Disk Manager to handle up to 9 disks or RAMDISKS and to do this would remove TI Basic from the GROMs.

I also put out a modified EA cart support installed into TI Basic that some people use but does not have disk access like Disk Manager.

[+9640News]

19 minutes ago, RXB said:

Not enough space to do that, I modified Disk Manager to handle up to 9 disks or RAMDISKS and to do this would remove TI Basic from the GROMs.

I also put out a modified EA cart support installed into TI Basic that some people use but does not have disk access like Disk Manager.

I agree Rich, not enough space.  However, another way to possibly tackle this is to have a routine that loads a disk manager from a device, similar to the original CorComp roms. 

 

My thought here is to either have a menu item as another menu option at the TI Main Menu, or be able to execute code within GPL from another running RXB program or from assembly languate.

 

If the calling grom routine was coded to switch in other pages of SAM memory before entry, and the disk manager executed code from grom to map itself back out, one would not overwrite existing/default 32K ram.  Thus, the program could either be resident, or available to call from another program without corrupting the existing program running.  The big issue might be screen restoration which would be copying/restoring VRAM to/from SAMS memory, as well as the calling program to execute passing a variable for screen mode.

 

Just a thought.  I know it is easier said than done, but just an idea.  DM1000 source code is readily available as one option for code that could be modified as a test bed for future individuals that would want to implement such an idea.

 

 

 

[speccery]

4 hours ago, RickyDean said:

I bet the TIM SOB firmware would be usable on this too. I want 3. You know, I've never really considered it, but I bet it's possible to load the sob firmware to my GramKracker too.

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?

[speccery]

2 hours ago, RXB said:

Not enough space to do that, I modified Disk Manager to handle up to 9 disks or RAMDISKS and to do this would remove TI Basic from the GROMs.

I also put out a modified EA cart support installed into TI Basic that some people use but does not have disk access like Disk Manager.

How much space would you need? 

[GDMike]

Would be nice to remote turn it on off without opening the case. But even a toggle outside the case is cool.

[+Lee Stewart]

5 hours ago, RXB said:

Not enough space to do that, I modified Disk Manager to handle up to 9 disks or RAMDISKS and to do this would remove TI Basic from the GROMs.

 

Is the Disk Manager 2 cartridge written in GPL, ALC or both?

 

...lee

[+Ksarul]

Considering that I have been playing with some test boards that replicate the TIM (I can send you an assembled one if you like, @speccery, along with a few strips of the pins I use, as they are as thin as regular chip socket legs), it would definitely be interesting for me to test one of these using the SOB GROMs. Timing is good too, as I just got a small group (10) of V9938 pulls that supposedly came from working game cabinet boards that were being parted out.

[speccery]

5 hours ago, Ksarul said:

Considering that I have been playing with some test boards that replicate the TIM (I can send you an assembled one if you like, @speccery, along with a few strips of the pins I use, as they are as thin as regular chip socket legs), it would definitely be interesting for me to test one of these using the SOB GROMs. Timing is good too, as I just got a small group (10) of V9938 pulls that supposedly came from working game cabinet boards that were being parted out.

That’s great, I will send you one and also very interested in the TIM. Where do you source the thin strips? I will send you a PM.

[RXB]

12 hours ago, 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?

The SOB is a cartidge utility that handles up to 16 carts much like Classic99 does.

But also has a disk loader for EA5, EA3 and TI Basic or XB programs.

It also can catalog hard drives or ramdisks too.

[Reciprocating Bill]

11 hours ago, Lee Stewart said:

Is the Disk Manager 2 cartridge written in GPL, ALC or both?

The Disk Manager 2 cartridge contains just 2 GROMs (12k).  Still makes me wonder if a useful subset of its functionality - cataloging disks, copying files, etc. (modified to talk to devices such as the TIPI) could not be squeezed into 8k of GROM.

[+9640News]

49 minutes ago, Reciprocating Bill said:

The Disk Manager 2 cartridge contains just 2 GROMs (12k).  Still makes me wonder if a useful subset of its functionality - cataloging disks, copying files, etc. (modified to talk to devices such as the TIPI) could not be squeezed into 8k of GROM.

Is the GPL source code for Disk Manager 2 available?

 

And is it to have it only available as permanently installed module?  Or is the intent to have user available hooks to be able to call the routines from assembly or potentially RXB?

 

The reason I posted my previous note about DM1000 earlier in this thread, is that if someone were to replace their groms, they are likely to have SAMS.  With something like DM1000, someone could include the source modifications on the entry/exit with the extended GPL interface someone would need to write to expand to other opportunities besides disk management.  Either way, if someone is going to copy files, then there is likely other memory (VDP, RAM) that would likely need to be stored/paged via some method. 

 

On another note, if the GPL code on the groms could be modified by RXB once @speccery completes his updates, then a RXB program could load other items beyond disk management for the program.

 

Anyways, there are a limited number of individuals that could write the GPL code.

 

 

  

 

[+Ksarul]

@speccery, here is one source that currently has the headers I use. The place I got the last batch from is no longer selling parts. I'll send you one of my assembled test boards for the V9938 TIM clone. The original TIM used a V9958, but as I have a good stock of V9938s, I went with that chip instead.

[RXB]

4 hours ago, 9640News said:

Is the GPL source code for Disk Manager 2 available?

 

And is it to have it only available as permanently installed module?  Or is the intent to have user available hooks to be able to call the routines from assembly or potentially RXB?

 

The reason I posted my previous note about DM1000 earlier in this thread, is that if someone were to replace their groms, they are likely to have SAMS.  With something like DM1000, someone could include the source modifications on the entry/exit with the extended GPL interface someone would need to write to expand to other opportunities besides disk management.  Either way, if someone is going to copy files, then there is likely other memory (VDP, RAM) that would likely need to be stored/paged via some method. 

 

On another note, if the GPL code on the groms could be modified by RXB once @speccery completes his updates, then a RXB program could load other items beyond disk management for the program.

 

Anyways, there are a limited number of individuals that could write the GPL code.

 

 

  

 

These are some of my GPL projects like Rich DM and Basic Support Module.

Also the XB CALL INIT source code.

GPL Projects.zip