TI-GROMmy, the system GROM replacement

[Gary from OPA]

4 minutes ago, speccery said:

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

Thanks for fixing the PA2, failsafe option.

 

Hopefully, you can figure out the banking at least first two 24k banks are switching ok, just last two are staying stuck on bank 1 instead of being banks 2/3.

[speccery]

Hi @Gary from OPA I took another look during a short break and I found the problem and fixed it, I thought I was calling a function but I had optimized it to a macro and the macro expansion lacked parentheses which caused an expression not to work.

A quick question, with the fix in place I am using mode 0 standard banking, but for me the normal module list list is not showing multiple basic versions (i.e. different programs at GROM address 2000 across the four banks), is that how it is supposed to work?

Edited August 15 by speccery

[Gary from OPA]

2 hours ago, speccery said:

Hi @Gary from OPA I took another look during a short break and I found the problem and fixed it, I thought I was calling a function but I had optimized it to a macro and the macro expansion lacked parentheses which caused an expression not to work.

A quick question, with the fix in place I am using mode 0 standard banking, but for me the normal module list list is not showing multiple basic versions (i.e. different programs at GROM address 2000 across the four banks), is that how it is supposed to work?

With standard original ti operating system you will not see multiple ti basics, as it only checks for different module names from g6000 area.

 

If you had another device doing multiple grom bases in the cartridge space, you would see "review module library" as the last option and selecting it then you would see the second ti basic and so on.

 

You would need to have a patched OS to check starting at g2000 instead, or be running my SOB version.

 

I am on my mobile, so I can't right now quickly attach my SOB version or give you the hex address of the two bytes in grom 0 to change.

 

Instead use that attached memory editor I included in my previous message to check each page to see if the name changes.

 

Thanks again for your quick bug fixing...

Edited August 15 by Gary from OPA
spelling

[Gary from OPA]

Silly me, @speccery I forgot my phone I have all the original source codes on it.

 

See attached page from TI's last printed assembly job from 1982.

 

Change the two highlighted parts ending in >60 to >20 at locations g01C9 and g01D4

 

Of course make that change in all 4 banks of grom0, doing that you should see the added automatic option "review module library" and the TI BASIC name changing each time you select it.

Edited August 15 by Gary from OPA
oops forgot the screenshot of the source...

[speccery]

Thanks @Gary from OPA for the information. I didn't get the cart listing working and I am once again running out of time, but the bugs **should** be fixed in here, so I am sharing the files anyway with you.If you have time to test, this build should at least not put you into any worse situation. 

 

firmware.bin- includes in cart 4 version 0.7.91

g2config-0.7.91.bin - GROM module with firmware update package

grommy2-0.7.91.bin - firmware only

[Gary from OPA]

12 hours ago, speccery said:

Thanks @Gary from OPA for the information. I didn't get the cart listing working and I am once again running out of time, but the bugs **should** be fixed in here, so I am sharing the files anyway with you.If you have time to test, this build should at least not put you into any worse situation. 

 

firmware.bin- includes in cart 4 version 0.7.91

g2config-0.7.91.bin - GROM module with firmware update package

grommy2-0.7.91.bin - firmware only

Been feeling a bit under the weather today...

 

Took some Motrin and NyQuil to help me through tonight.

 

So, with luck I will get to it tomorrow and report back. Got a one hour zoom meeting tomorrow as well, so most likely will be after it.

 

Thanks again for your quick fixes.

[speccery]

8 hours ago, Gary from OPA said:

Been feeling a bit under the weather today...

 

Took some Motrin and NyQuil to help me through tonight.

 

So, with luck I will get to it tomorrow and report back. Got a one hour zoom meeting tomorrow as well, so most likely will be after it.

 

Thanks again for your quick fixes.

Sorry to hear about that, hopefully you recover quickly. At least here we’ve having an increase in covid cases, hopefully it’s not that.

 

No rush with testing, I’m trying to fix bugs fast when I still remember what I was working on. If I have time I will do some more testing on my own. 

[Gary from OPA]

8 hours ago, speccery said:

Sorry to hear about that, hopefully you recover quickly. At least here we’ve having an increase in covid cases, hopefully it’s not that.

 

No rush with testing, I’m trying to fix bugs fast when I still remember what I was working on. If I have time I will do some more testing on my own. 

WEEE -- Good News --- IT WORKS! -- Many Many Many Thanks.

 

The PA2 mode now works fine, boots into my failsafe grom, with no ti basic available, when the switch installed previously is to the right (pulled low).

All tho, I have not been able to re-flash the "failsafe grom" area, now that its no longer empty, it is stuck as is, but no big deal, at least its there, as a backup if I fuck up the other 4 banks.

 

Of course, currently your grommy2 defaults to mode 1, so I need to go into the config and change to "standard banking" mode 0 and then reset the console, lucky your strangecart has reset button that works, for some reason on my finalgrom99 my reset button is flaky, doesn't always work, and zippy-do the 4 different TI BASIC's appear, so the banking is working, and my previous solder job is ok, no need to open up the console again.

 

next step on my end, is to fit in the command to switch to mode 0 on power-up, so I don't need to manually load your config and select that mode, and reset the console.

 

And i then tested the banking, if 3 programs, the pgram+ BOOT menu that supports 4 different paging banks by pressing the G button, and then in the EA5 memory editor (pgram+ edition / 4 pages only) and finally in my unreleased RAMOS directory (which supports up to 8 banks), all working smoothly, no errors at all.

 

Now, I can start coding up a 96k operating system, uses all 4 banks, as TI Basic is only needed in the first page, all the other banks can have new fancy code instead, without any compatibly issues with other cartridges out there. of course the first 6k of grom 0 should be mirrored always in all 4 banks, with the last 2k used mainly for new common code as well. So all together, at most without problems you can easy have around 56k of all new code, with the top 7k of each grom 0 shared, and the 12k of ti basic in bank 0 reserved, giving you around 5k of new code in bank 0, and around 17k times 3 of new code in the other banks.

 

sorry for the stack of pictures, just wanted to show it all working perfectly.

 

Many Many thanks again.

 

P.S. -- Now we need a SuperGrommy2 with 16 pages of 24k, since we got this figured out perfectly, but 96k (4 pages) is good enough, don't want to go overboard. because really you could have 256 pages of 24k if you really wanted!! -- haha - imagine 6mb OS!

,

[speccery]

Thanks @Gary from OPA for all the testing work! I really appreciate the work and guidance to your i.e. the community's needs.

 

Yes the supergrommy prototype already could support the 16*24k banks for GROM and 4*24k banks of GRAM. Even supporting 8-bit base addresses and 6MB of OS GROM would be possible by adding a memory chip. I have many ideas how to improve the hardware, but I'm not sure if it needs improvements in the short term. Knowing myself I will probably try a few things...

But as far as developing very large programs for GROMs goes, the community is probably very small. Probably for larger software projects people would use C language? At least that's what I would personally do, but it's just my opinion.

 

If you want to try reprogramming the Failsafe area, there is the command #8 which does that. It comes in two variants, the latter one I have not tested yet but it is implemented and should work to force reprogramming.

Programming of failsafe GROM from the first 6K of GRAM. Normal programming.
The following 16 bytes written to >5FF0..>5FFF using one MOVE command from GPL:
08, F7, 00, 00,  00, 00, 00, 00,  45, 50, 47, 52,  4F, 4D, 4D, 59  

The above version only works if the failsafe area is empty, there is a safeguard in the code. But there is this version of the same command, with forced write, should work even if the failsafe area has been programmed earlier:

08, F7, 00, 00,  F0, 00, 00, 00,  45, 50, 47, 52,  4F, 4D, 4D, 59

 

Edited August 20 by speccery

[+dhe]

@speccery  - Now that you have worked out some bugs, and @Gary from OPA has ported his super awesome SOB software, and we'll have need of GROMmy's for TI-99/22 board.

  Do you have any plans to send GROMmy out for manufacturing so @arcadeshopper can stock these in quantity?

[speccery]

On 9/1/2024 at 2:20 PM, dhe said:

@speccery  - Now that you have worked out some bugs, and @Gary from OPA has ported his super awesome SOB software, and we'll have need of GROMmy's for TI-99/22 board.

  Do you have any plans to send GROMmy out for manufacturing so @arcadeshopper can stock these in quantity?

Thanks @dhe yes I will be making more boards and plan shipping some to @arcadeshopper. Currently I haven’t planned getting them manufactured but that will depend on the demand. Anyway first step is to build the ones I have parts for and see how far it goes. I will also make a minor revision for next PCB batch to make them faster to build regardless how they get build. The functionality will stay the same.

[Gary from OPA]

1 minute ago, speccery said:

Thanks @dhe yes I will be making more boards and plan shipping some to @arcadeshopper. Currently I haven’t planned getting them manufactured but that will depend on the demand. Anyway first step is to build the ones I have parts for and see how far it goes. I will also make a minor revision for next PCB batch to make them faster to build regardless how they get build. The functionality will stay the same.

maybe, if possible for minor revision to make the points to add the two extra address lines (if required) more accessible, by at least adding a two pin header for a detachable cable with wires.

[speccery]

I've been in the past few evenings editing the grommy2 PCB design a little, to bring all the components to the top side in order to make the boards faster to build. I've built the boards so far without a stencil, but for a little bit bigger quantities a stencil will be needed to speed up the assembly process. The board size is exactly the same, as is the functionality. J7 is a ground pad and adjacent to it is a bigger header with 0.1" pin pitch for the two address lines for banking. I needed to route a bunch of signals again to make space for the components on the top.

I haven't yet ordered the new boards, as I'm also planning to design a couple other boards and order them in one go. One of those boards would be a simple USB programming adapter for the grommy2 board, it would pretty much just be a FTDI USB adapter chip with the right pinout for the grommy2. It would be good for me to speed up initial flashing of the boards but also for people like @Gary from OPA doing deeper GROM / grommy programming; it would allow recovery of a firmware upgrade going awfully wrong.

I have also updated the documentation (not for the new PCB which is functionally the same) adding the information for the banking, failsafe etc. 

grommy2 presentation.pdf

[speccery]

I think I'm done with the design of the grommy programmer board, which is effectively just a FTDI breakout board which the same pinout as grommy2. It enables the grommy2 microcontroller to be programmed with STM32CubeProgrammer software.  This board is not normally needed for a grommy2, but it should make my life a bit easier when programming the firmware for the first time for a new board.

 

There are two small buttons on the board, I don't have a 3D model for them as I created the footprint myself, so the buttons do not show up below. I suppose I could create the model with Freecad but not this time.

The switches are of type TL1030AF350AQJ from E-Switch. If someone has a good recommendation for another tiny push button please let me know, I am looking for surface mount buttons, the size of this one is 3.5mm * 2.9mm. The extra pin headers would not be mounted normally, I did want to break out the pins though since I've used this same chip (on the ULX3S FPGA board) to program FPGAs, I needed to tweak the programming software at that time to get it running on macOS.

 

Edited September 13 by speccery

[speccery]

A few updates on my progress with the grommy project. First, there was a bit of delay due to work and some family matters getting into the way. Then there was a pretty major distraction within my retrocomputing time for a few days as I (in completely unplanned way of course) acquired a well working Commodore 128D. I needed to clean that up, install a much more silent new fan and put together another rgbtohdmi device to get HDMI output from the 80 column RGBI interface. Last but not least, my wife contracted covid, her first. She seems to be getting better now luckily, the beginning was pretty rough for her.

 

However, I have done some stuff: I did order the PCBs and stencils and a whole bunch of components, all of them arrived. I have built first test batches of both the new grommy2 v0.2 boards as well as the grommy2-pgm programmer boards. The assembly process went pretty much as planned, I used the stencils to apply solder paste, manually placed the components and then baked the boards using my still new hot plate. That build process was at least 5x faster than in the past, it took me about an hour to do the SMD assembly for a batch of six boards. The incremental time spent per board is small, for the next batch I will probably go with ten boards in one go. Little cleanup was needed after then reflowing process, I still do get a bit too much solder paste on some boards.

 

Here are a couple of pictures:

Above a close up of the new grommy2 and the programmer board. The electronics on the new grommy2 board revision is exactly the same as with the previous model, but the layout is a little different, with all components on the top.

Top left hand corner two earlier model grommy2 boards with new programmer boards attached, and a bunch of v0.2 boards, two fully assembled.

 

I haven't yet tested the new grommy2 boards in the console itself, but I have assembled two boards fully and they seem to work well. The new programmer boards worked well too. I did make a minor error with the programmer board, one of the two LEDs is accidentally connected to a different pin that planned (CBUS3, it was supposed to be CBUS1). The intention was to use those as indications of RX and TX activity on the serial bus, but now only one of them works as expected while the other is pretty much constantly lit. Those pins on the FTDI chips are programmable but I did not bother to look what CBUS3 is actually showing. It serves as power led for now  

The programming setup is as depicted above, the one extra wire is providing 5V power for the grommy2 board.

 

As a test I wanted to test different board thickness options, the new grommy2 is 1.2mm while the grommy2-pgm is only 1mm thick. So far all my boards have been the default 1.6mm. Especially the programmer is pretty slim. These are very small boards, so the mechanical strength seems to be all good.

 

Edited October 1 by speccery

[speccery]

Sorry for the delay in updates. We've been hit with the flu season, my wife is recovering from her first covid, and my son moved out and we've been helping him to get settled in his new home.

 

I just got around testing the new revised grommy2 PCBs within the console. I built these nearly two weeks ago, apart from pin headers which I soldered I guess about a week ago. All of them worked. I also retested two first revision grommy2 boards and they also work, so I now have 8 ready to go. In the coming days my plan is to build another batch of the new revision boards, the assembly process went fast the last time and now I should have the components even better organised so that the setup time should also be shorter  

I also received some more right angle pin headers so I should be all set.

 

I am not going to modify the firmware version right now, but I am thinking about adding the grommy2 config tool into the grommy2 itself. That would mean that through some mechanism the config tool could be enabled (probably through an extra wire bringing yet another config pin low during bootup), and it would populate the GROM space for example at >E000 so that the config tool would be discovered by the normal GROM scan routines. I'm still wondering if this is a good idea, suggestions are welcome!

[Gary from OPA]

2 hours ago, speccery said:

 

I am not going to modify the firmware version right now, but I am thinking about adding the grommy2 config tool into the grommy2 itself. That would mean that through some mechanism the config tool could be enabled (probably through an extra wire bringing yet another config pin low during bootup), and it would populate the GROM space for example at >E000 so that the config tool would be discovered by the normal GROM scan routines. I'm still wondering if this is a good idea, suggestions are welcome!

I think it is a good idea, it should be I think combined with the failsafe grom mode, and since the failsafe is only 6k with no ti basic, the config tool should be at 2000 the ti basic area, that way it would not get in the way if a cartridge is being used while in failsafe mode, and as well the same pin and switch can be used to do the triggering.

Edited 9 hours ago by Gary from OPA
made my suggestion more clear.

[speccery]

3 hours ago, Gary from OPA said:

I think it is a good idea, it should be I think combined with the failsafe grom mode, and since the failsafe is only 6k with no ti basic, the config tool should be at 2000 the ti basic area, that way it would not get in the way if a cartridge is being used while in failsafe mode, and as well the same pin and switch can be used to do the triggering.

Thanks Gary this makes total sense!