TI-GROMmy, the system GROM replacement

[GDMike]

21 hours ago, 9640News said:

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

For sure 

Edited September 16, 2022 by GDMike

[speccery]

An update to this project: I have the first useful firmware version now ready. It is very simple: it emulates the entire 24k of system GROM successfully, and also supports writes to this region, i.e. it acts as GRAM.

 

The GRAM functionality works as I contemplated here before: there is a 6K section of RAM which is divided into 256 byte pages. When a given memory location is written, say address >1234, that entire page is copied to RAM. Thus the data from >1200 to >12FF would be copied to RAM, and then within this page location >34 would be modified with the data written. Subsequent accesses to the GROM address range from >1200 to >12FF will both write to and read from RAM. 

 

This GRAM functionality works as long as the total number of modified 256 byte pages fits into the 6K RAM. The pages do not need to be consecutive. For example, @senior_falcon's interesting project here at AtariAge works with TI GROMmy on the real iron. It only writes a few bytes to GRAM, to pages >50 (>5000..>50FF) and >36 (>3600..>36FF), which get copied to RAM and then modified.

Edited September 26, 2022 by speccery
clarification

[kl99]

It really sounds like a nice project.
Can you confirm the following assumptions:

The 24K GROM can only be permanently "programmed" via some controller.

"GRAM" writability is working during runtime, but when the TI is turned off, only the originally "programmed" 24K GROM content is served again.

 

I can imagine this being used as well for projects to

- restore a 99/4 with broken or missing GROM chips

- restore a 99/8 with broken or missing GROM chips

- extend a 99/8 with support for P-CODE (since this is only a GROM board extension)
- update a 99/8 which is not on the latest system software (remember, we used the one from Ciro's machine for preservation purposes).

- usage for hardware projects like TI(ny)-99

- aren't Speech Modules (the canceled extension modules) in fact GROM chips? (here are some pics of a Speech Synthesizer with the interface, basically it is only a soldered port http://www.ti99.eu/?page_id=1705&lang=en ) And the modules exist for other TI products. 

 

Is it meant to be followed by a similar thing for "programmable"/writable ROM chips?

[RXB]

On 9/16/2022 at 3:02 AM, GDMike said:

For sure 

Kinda disagree, GPL is much more easy to write with then Assembly.

GPL is Byte or Word based, Assembly is 100% Word based and really hard to do Byte based things.

Some GPL commands cannot really be written with Assembly and made faster without insane complications needed.

IO (Input/Output) CRU commands are the best example or Device access.

 

[+FarmerPotato]

@kl99

Quote

aren't Speech Modules (thecanceled extension modules) in fact GROM chips? (here are some pics of a Speech Synthesizer with the interface, basically it is only a soldered port http://www.ti99.eu/?page_id=1705&lang=en ) And the modules exist for other TI products.

No, the VSM or TMS6100 or 0350 ROMs are not the same. There are similarities.  
 

VSM have an internal 14-bit address, auto-incrementing, and a 4bit chip base address.   (GROM has 13 bit address and 3 bit base.) VSM are organized for bit-serial operation. The 6100 outputs 4 bits at a time. (The 1 bit version I’ve never seen.) 

 

Still, a VSM emulator is not too different from a GROM simulator. 
 

Weird fact: VSM use only 10 pins of a 28 pin package. With a 4 bit address/data they use fewer pins  than a GROM!  perhaps the bigger size is from a process to accommodate the die with 128Kbit storage. 
 

 

 

[speccery]

9 hours ago, kl99 said:

Is it meant to be followed by a similar thing for "programmable"/writable ROM chips?

Thanks for your comments!

Actually the TI-GROMmy is writable from a hardware standpoint, I just need to enable this in the firmware as well. The way I am planning to do it is by reserving a bit of space, for example the last 16 bytes, from 5FF0 to 5FFF for special commands. By writing a magic signature there, the firmware would write the modified content (in SRAM at that time) to the Flash, while the device is inside of the TI.

With a similar mechanism the device could be put into an update mode, where the entire 24K could be updated. Probably the easiest way to do it would be to prepare a paged cartridge image, which you could run from FinalGROM or StrangeCart or something similar to do the update.

Edited September 28, 2022 by speccery

[speccery]

I got the TI-GROMmy working without the patch wire to ground. The nice thing with a very simple two sided PCB is that it is very easy to modify  

 

I only did three changes:

• Cut the trace going to pin 16 of the GROM socket. This is the Vss pin, effectively ground, which is at -0.7V level in the TI-99/4A.
• Added an 1N4148 diode from the board's ground to pin 16, effectively lifting the ground level to 0V. According to my voltmeter the level is now at 35mV which is effectively zero. I don't trust my voltmeter too much, but this close enough to zero.
• Added an extra wire to make the board flashable while in the TI using a FTDI dongle. In the past I used a jumper to select whether the board is in programming mode, but now I swapped a pin and altered the firmware accordingly.

Below pictures, it doesn't look too bad in my opinion. I will revise the PCB accordingly for the next spin of the board, but this mod is quick to make even for the existing PCBs.

 

Edit: forgot to mention that I also worked on the firmware to reduce it's size and to align the 24K GROM image on a flash sector boundary. The firmware does not yet support in-system flashing, but it's now just under 28K with 24K GROM data. The additions I am planning to make (primarily ability to reprogram the Flash while in the console) are minor, and should easily fit into 1K. So it should be possible to have an extra 3K of flash space free when all features are there  

Edited October 3, 2022 by speccery
comment on firmware size

[SkyPilot]

Add CTRL-T as a hook for a TIPI program.  The user could decide what the program did, whether loading a menu, directory program or whatever.  Would save a fair amount of typing.

[Switch1995]

Hi @matthew180

 

I've been diving into your assembly posts and you mentioned:

 

The value >8300 is used here because that represents the first address in the scratch pad RAM, which exists from >8300 to >83FF (256 bytes.) Actually there is a lot of waste in the memory-mapped devices in the 99/4A and the scratch pad RAM is not fully decoded, which means it will respond to memory address in these ranges:

 

>8000 to >80FF

>8100 to >81FF

>8200 to >82FF

>8300 to >83FF

 

Each range is accessing the same memory, however it is pretty much universally accepted that the scratch pad should be addressed from >8300 to >83FF. Something I've always wanted to do is add real memory to each of those address ranges and give the 99/4A 1K of real 16-bit scratch pad RAM! But that's another day, another project.

 

Would you envision a solution similar to GROMmy where a board would span across the two sockets that held the MCM6810Ps?

[HOME AUTOMATION]

It's my understanding that >8300->83FF, is fully decoded on the QI.

[Switch1995]

Did the QI fully decode >8000 to >82FF?  Are they just "four copies" of the same map?

[Switch1995]

Answered my own question:

 

>8000 Duplication of scratch pad RAM at >8300 - >83FF
>8100 Dup. as above
>8200 again
>8300 Scratch Pad RAM

[matthew180]

10 hours ago, Switch1995 said:

Would you envision a solution similar to GROMmy where a board would span across the two sockets that held the MCM6810Ps?

 

Sure, but unlike the GROMs, the SRAM chips are not in sockets.  So doing something like this depends on if you are making your hardware upgrade for yourself, or if you plan to make kits or hope other people will make their own, etc..  Removing ICs from these old motherboards is not easy and most hobbyists don't have the means for this, or know anyone who can help them.  Even opening the console to install an update in an already socketed IC is sometimes more than people are willing to do.

 

This is a slippery slope of retro-computing, and the question is not usually "can it be done", but rather "why am I doing this?", "am I having fun and enjoying myself?", or "do I care if other people will be able to use my new software or hardware?"

 

If you move all the technical and philosophical arguments from the table, then you should first look at this:

 

http://www.mainbyte.com/ti99/32K16/32k16.html

 

Also, if you are going to remove the SRAM, don't stop there, make a board for both the SRAM and ROMs, and make it such that the ROMs are really SRAM as well, and are loaded from something at power-on, such that they can be replaced with new code.  This would allow for truly new capability of the 99/4A.  It would be really cool if such a device could connect to a PC via USB or network, and allow real-time reading/writing of the RAM.  This would make writing and debugging software for the 99/4A really awesome.

 

Anyway, like I said, slippery slope.  If you search around the forum you will certainly find many threads discussing these kinds of ideas, going way back.

 

[speccery]

16 hours ago, Switch1995 said:

 

Each range is accessing the same memory, however it is pretty much universally accepted that the scratch pad should be addressed from >8300 to >83FF. Something I've always wanted to do is add real memory to each of those address ranges and give the 99/4A 1K of real 16-bit scratch pad RAM! But that's another day, another project.

I have in my other projects (FPGA implementations of the entire TI-99/4A) supported 1K scratchpad, and that's something which works well. I have actually also tested filling some of the other gaps in the I/O area with RAM too. 

[speccery]

5 hours ago, matthew180 said:

Also, if you are going to remove the SRAM, don't stop there, make a board for both the SRAM and ROMs, and make it such that the ROMs are really SRAM as well, and are loaded from something at power-on, such that they can be replaced with new code.  This would allow for truly new capability of the 99/4A.  It would be really cool if such a device could connect to a PC via USB or network, and allow real-time reading/writing of the RAM.  This would make writing and debugging software for the 99/4A really awesome.

Two comments, a small and a big one  

• My FPGA implementations of the entire TI-99/4A support modifying RAM/ROM contents on the fly over USB. That's a very convenient feature to have, and it's how I debugged those designs. It could be taken much further of course, and integrated with a PC side IDE...
• I've been thinking about designing this type of 32K 16-bit wide memory board. Due to the hassle of installing such a thing, I've almost arrived at the conclusion that it would be easier and more accessible to "just" do a whole new motherboard. For video functionality just have a normal socket for F18A, CPU and TMS9901 would have to be extracted from an actual TI or sourced otherwise, GROMs would be come from my GROMmy board, sound chip seems to be socketed at least on the TI I have open here, all glue logic would go into a CPLD or small FPGA. Such a board could be less than half the size of the normal motherboard, and run from a 5V power supply. If an actual TMS9900 is used as the CPU, there would be the need for a small switching power supply to generate the -5V and other potentially required voltages. I'm not very interested in the discussion when a TI is no longer a TI, but in my opinion if an original CPU would be used it would be pretty close. Doing a prototype with TMS9995 would be easier, and actually would be roughly identical to the Tomy Tutor.

[matthew180]

7 hours ago, speccery said:

I've almost arrived at the conclusion that it would be easier and more accessible to "just" do a whole new motherboard.

 

Agree, 100%

 

7 hours ago, speccery said:

all glue logic would go into a CPLD or small FPGA

 

If I were doing the design, the 9900 would be in the FPGA, which allows for 100% compatibility while fixing some of the architecture problems, allowing for increased speed (for those who want it), small easier board, easier interfacing, etc..  I did new sound cores for the Phoenix, so I would also put that into the FPGA, which also allows for multiple sound chips, and different sound chips.  Slippery slope.  I'm probably more in the camp of almost 100% FPGA, while staying electrically compatible with I/O like the cartridge and side-expansion port.

 

7 hours ago, speccery said:

. I'm not very interested in the discussion when a TI is no longer a TI, but in my opinion if an original CPU would be used it would be pretty close.

 

Again, agreed.

[speccery]

A quick update: I have added to the firmware the ability to write to flash permanently the changes written first to RAM. I haven't been fully able to test this since I'd need a GROM editor / monitor program for that purpose. I think Easybug, provided in Mini Memory module, supports GROM reading but not sure if it supports writing. Haven't had time to try that out yet, as I just realised it might.

 

Also got today a batch of boards from PCBWAY, new version of TI-GROMmy PCB and two other brand new designs... 

Edited October 10, 2022 by speccery

[+FarmerPotato]

 

I have not heard of anybody trying this but:

 

Is there any reason you could not remove the GROMs from the console and put them in a cartridge?  Using the E/A type cartridge board, which has room for more GROMs.

 

Plug in the cart, and the 4A operates as usual. Take it out though, and there is no operating system, oops.  I was just wondering if it  would work. 

 

If nothing else, a similar device would let you plug TI GROMmy into the cartridge port conveniently. 

 

 

[Tursi]

EasyBug does support writing to GROM, it's how I tested the UberGROM

Console GROMS work fine from the cartridge port.

 

[+9640News]

16 hours ago, FarmerPotato said:

 

I have not heard of anybody trying this but:

 

Is there any reason you could not remove the GROMs from the console and put them in a cartridge?  Using the E/A type cartridge board, which has room for more GROMs.

 

Plug in the cart, and the 4A operates as usual. Take it out though, and there is no operating system, oops.  I was just wondering if it  would work. 

 

If nothing else, a similar device would let you plug TI GROMmy into the cartridge port conveniently. 

 

 

The GramKracker allowed you to run Grom 0, 1, and 2 from the cartridge port.

[+FarmerPotato]

33 minutes ago, 9640News said:

The GramKracker allowed you to run Grom 0, 1, and 2 from the cartridge port.

Oh yeah… 

 

never had a GRAM Kracker to play with, but I’d seen it in use at Front Range 99ers meetings. 
 

There’s the sentence in Console and PES Technical Data: “the GROMs are poor line drivers at best” which means that another device can shout them off the bus. 
 

 

 

[speccery]

On 10/11/2022 at 7:17 AM, Tursi said:

EasyBug does support writing to GROM, it's how I tested the UberGROM

Console GROMS work fine from the cartridge port.

 

Well I was really scratching my head why the heck my second version board did not work properly with writes. The reason: easy bug in mini memory DOES NOT support writing to GROM. Not at least the version I have compiled myself as part of the Strangecart image. I built a little involved test circuit:

 

There is a 74HC138 logic chip I attached for debug purposes to trigger my scope, in a configuration where output Y0 of that chip goes low when a GROM write occurs (i.e. /GCS, MO and R/W are all low simultaneously). I tried to write to GROM with Easy bug, no luck. When I looked at the source code, it explicitly was not writing to GROM. I added a bit of code to change that, so now it can write to GROM. I got the source code from Thierry's tech pages. I edited the source a long time ago so that I can compile it with xdt99 toolchain (xga99.py). Below is the edited version with support for writing, starting from the label G_EP_WR_GRAM. Without this addition, when pressing enter with the G command it would just jump to G@G73E0. 

*                             write to CRU
G7437  CEQ   >43,V@>02C3      ------------ was command <C>?
***       BR    G@G73E0          no: next address (can't write to GRAM)
       BR    G@G_EP_WR_GRAM
       DST   @>839A,@>83B0    address will be CRU address
       ST    >01,@>83B2       1 bit operation
       ST    >99,@>83B3       value is in >8399
       DSRL  >0001,@>83B0     divide CRU by 2 (GPL multiplies it again)
       I/O   >03,@>83B0       CRU output
       B     G@G73E0          next address

* Erik: added ability to write to GRAM
G_EP_WR_GRAM
       CEQ   >47,V@>02C3    --- was command <G>?
       BR    G@G73E0        no
       MOVE  >0001,@>8399,G@>0000(@>9A)   -- Write to GRAM (Does this work?)
       B     G@G73E0          next address

With the added code I immediately got triggers for my scope when writing to GROM.

My development TI is pretty full of ARM processors these days, one in TI-GROMmy, one in StrangeCart (actually two cores there), one in the ET-PEB board on the side expansion port, one in the Nucleo board I've plugged in to the keyboard port....

Edited October 21, 2022 by speccery

[Tursi]

2 hours ago, speccery said:

Well I was really scratching my head why the heck my second version board did not work properly with writes. The reason: easy bug in mini memory DOES NOT support writing to GROM. Not at least the version I have compiled myself as part of the Strangecart image. I built a little involved test circuit:

[...]

There is a 74HC138 logic chip I attached for debug purposes to trigger my scope, in a configuration where output Y0 of that chip goes low when a GROM write occurs (i.e. /GCS, MO and R/W are all low simultaneously). I tried to write to GROM with Easy bug, no luck. When I looked at the source code, it explicitly was not writing to GROM. I added a bit of code to change that, so now it can write to GROM. I got the source code from Thierry's tech pages. I edited the source a long time ago so that I can compile it with xdt99 toolchain (xga99.py). Below is the edited version with support for writing, starting from the label G_EP_WR_GRAM. Without this addition, when pressing enter with the G command it would just jump to G@G73E0. 

*                             write to CRU
G7437  CEQ   >43,V@>02C3      ------------ was command <C>?
***       BR    G@G73E0          no: next address (can't write to GRAM)
       BR    G@G_EP_WR_GRAM
       DST   @>839A,@>83B0    address will be CRU address
       ST    >01,@>83B2       1 bit operation
       ST    >99,@>83B3       value is in >8399
       DSRL  >0001,@>83B0     divide CRU by 2 (GPL multiplies it again)
       I/O   >03,@>83B0       CRU output
       B     G@G73E0          next address

* Erik: added ability to write to GRAM
G_EP_WR_GRAM
       CEQ   >47,V@>02C3    --- was command <G>?
       BR    G@G73E0        no
       MOVE  >0001,@>8399,G@>0000(@>9A)   -- Write to GRAM (Does this work?)
       B     G@G73E0          next address

With the added code I immediately got triggers for my scope when writing to GROM.

My development TI is pretty full of ARM processors these days, one in TI-GROMmy, one in StrangeCart (actually two cores there), one in the ET-PEB board on the side expansion port, one in the Nucleo board I've plugged in to the keyboard port....

I'm really sorry about that! I just checked in Classic99 and it doesn't work there either... so I guess my memory was faulty on this one.

 

The patch to make it actually work is really cool, nice work on that!

 

And yeah, put those modern processors to work serving a REAL machine

 

[speccery]

1 hour ago, Tursi said:

I'm really sorry about that! I just checked in Classic99 and it doesn't work there either... so I guess my memory was faulty on this one.

 

The patch to make it actually work is really cool, nice work on that!

 

And yeah, put those modern processors to work serving a REAL machine

 

No worries, has happened to me many a time. As a side product the simple test circuit is nice as it allows tuning of the code and seeing how much time it takes to serve requests.

 

The mini memory cart is really cool, I have modified it a lot to work as a gateway to StrangeCart basic. But now I see there are many ways it can be improved in its original form too. Among very simple modifications would be the addition of better documentation. The help screen is very nice, but I always find myself wondering how the CRU addresses should be entered, I have to look at the source or experiment every time.

[RXB]

7 minutes ago, speccery said:

No worries, has happened to me many a time. As a side product the simple test circuit is nice as it allows tuning of the code and seeing how much time it takes to serve requests.

 

The mini memory cart is really cool, I have modified it a lot to work as a gateway to StrangeCart basic. But now I see there are many ways it can be improved in its original form too. Among very simple modifications would be the addition of better documentation. The help screen is very nice, but I always find myself wondering how the CRU addresses should be entered, I have to look at the source or experiment every time.

RXB has GPL command CALL MOVE that moves any type of memory to any type of memory of any size, including GROM/GRAM 

This command could be included into TI Basic.