TI-GROMmy, the system GROM replacement

[speccery]

23 hours ago, RXB said:

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.

That would be really great! I need to look up the RXB documentation to see the syntax. Also would be nice to add PEEK/POKE/etc. to TI Basic.

[+Lee Stewart]

25 minutes ago, speccery said:

Also would be nice to add PEEK/POKE/etc. to TI Basic.

 

You probably already know this, but, if you define functions like PEEK, POKE, etc. for TI Basic, you will interfere with TI Basic functions of the same name added by the E/A cartridge, which defines INIT, LOAD (doubles as POKE), LINK, PEEK, PEEKV, POKEV, and CHARPAT.

 

...lee

[RXB]

1 hour ago, speccery said:

That would be really great! I need to look up the RXB documentation to see the syntax. Also would be nice to add PEEK/POKE/etc. to TI Basic.

RXB has all the source code you need as I release that to everyone.

[RXB]

46 minutes ago, Lee Stewart said:

 

You probably already know this, but, if you define functions like PEEK, POKE, etc. for TI Basic, you will interfere with TI Basic functions of the same name added by the E/A cartridge, which defines INIT, LOAD (doubles as POKE), LINK, PEEK, PEEKV, POKEV, and CHARPAT.

 

...lee

I made a version of TI Basic Support for Assembly that resides in TI Basic GROMs you can load into GRAMKRACKER or GRAMULATOR or CLASSIC99 or MESS.

I did not include my CALL MOVE but all the EA Support routines are there so you can plug in any module and still have EA TI Basic Support too.

Mostly this is used by people that use the TI DOS cart but works with any Cartridge.

[speccery]

15 hours ago, Lee Stewart said:

 

You probably already know this, but, if you define functions like PEEK, POKE, etc. for TI Basic, you will interfere with TI Basic functions of the same name added by the E/A cartridge, which defines INIT, LOAD (doubles as POKE), LINK, PEEK, PEEKV, POKEV, and CHARPAT.

 

...lee

Yes I am aware of that, but still would be handy. This relates to having the ability to host multiple system GROM images at once, which is something my new boards support...  

 

A quick rant: One thing I really never understood is that why did BASIC's only provide 8-bit pokes? One of my retro computer systems is the Oric Atmos, and it has DOKE and DEEK features. DOKE is a 16-bit poke and DEEK is 16-bit peek. These would be especially handy with a true 16-bit system like the TI99/4A. Especially as the BASIC has no provision to simply and effectively break 16-bit words to bytes and vice versa. The 8052BASIC from Intel is another example of a nice BASIC with good bitwise operations. Of course BASIC was intended to be high level and beginner friendly, but in my personal opinion there was no harm (except a little ROM space consumption) to add these types of features.

[speccery]

14 hours ago, RXB said:

I made a version of TI Basic Support for Assembly that resides in TI Basic GROMs you can load into GRAMKRACKER or GRAMULATOR or CLASSIC99 or MESS.

I did not include my CALL MOVE but all the EA Support routines are there so you can plug in any module and still have EA TI Basic Support too.

Mostly this is used by people that use the TI DOS cart but works with any Cartridge.

Is this version of TI Basic GROMs available somewhere?

[RXB]

8 hours ago, speccery said:

Is this version of TI Basic GROMs available somewhere?

Cannot seem to find the original package. Over 30 years I have thousands of thousands of things I have written.

I did find this:

REABASIC.zip

[speccery]

I had today time to work on building more TI-GROMmy boards. I built two different types of boards: TI-GROMmy version 0.2 boards, got three built and fully tested. These use new v.0.2 version PCB. Also started to build a batch of four TI-GROMmy2 boards, which I will describe later, hopefully in a video. I have also designed third board, now in its second generation. Overall in this TI-GROMmy project I have designed 5 different PCB layouts in total for various versions... Four of these work, the last one I haven't had the time to work on. I think I have in total ordered and received 80 PCBs so far, quite a few.

 

I have also assembled the recent boards using new techniques to me, I went for low temperature solder paste (which is also lead free). I'm also using lead free solder for the components which cannot be soldered with solder paste. I'm using a hot plate to bake the boards with solder paste, and this speeds up the process quite a bit, especially with TI-GROMmy 0.2 boards which only have components on the top side.

In the picture above on the right there are three finished TI-GROMmy 0.2 boards, top middle is one TI-GROMmy 0.1 board. I have modded it to behave as 0.2 boards. In the center is a TI-GROMmy2 prototype board (which works without any patching) and the remaining four are half built TI-GROMMy2 boards. Need to still populate the bottom of those boards with some passive components and the pin headers. But getting ready to send the first ones over.

Edited October 30, 2022 by speccery

[speccery]

After spending quite a few hours today I have the first boards ready for shipment, trying to get them out the door tomorrow as I have business travel ahead. All kinds of new learnings when building these boards. Perhaps this is a good time to introduce the TI-GROMmy2 board:

• Form factor almost identical to the TI-GROMmy
• Uses STM32G070KB6 MCU.
  • 128K Flash
  • 36K SRAM
  • 32-pin LQFP, pin pitch is a leisurely 0.8mm as opposed to the 0.5mm with the first grommy or most other boards I have recently worked on.
• Firmware lags behind TI-GROMmy.
• With both boards the functionality is quite minimal.
• The grommy2 extra flash is not yet used in any meaningful way, it just sits there. But the extra capacity means it can easily store multiple GROM images.

The flash memory can be programmed with either a simple FTDI adapter or with ST-LINK2.1. I today learned how to configure the chip for serial port flashing.

 

After bringing up the board I also ordered a NUCLEO-G70RB board, it has the same MCU but in a 64 pin package. I "ported" Mecrisp Forth for this board (there was almost no effort as there already was a version for NUCLEO-G71RB which is very similar). This might be interesting for the @TheBF and not hard to guess what firmware add-on I am planning for the TI-GROMmy2  I think the ported Mecrisp-RA probably would already directly run on my board, but both it and my firmware are baremetal versions, so I need to find some software glue and put these two together...

 

[Tursi]

I'd be down for a grommy2  Might finally get me off my butt to finish MPD

 

[+TheBF]

20 hours ago, speccery said:

This might be interesting for the @TheBF and not hard to guess what firmware add-on I am planning for the TI-GROMmy2  I think the ported Mecrisp-RA probably would already directly run on my board, but both it and my firmware are baremetal versions, so I need to find some software glue and put these two together...

 

Is your firmware written in C++ ?

Not sure what it has to do, but could Mecrisp just become the "resident monitor" by adding the extra functionality either by calling your existing routines or even re-writing some of them in Mecrisp?

(I worked with a project team years ago who were maintaining an ugly little debugger and using it as the boot monitor. 

 I had them replace it with and an 8K Forth kernel that was written in MPE Forth. It was much more powerful as monitor and fit in the same space.) 

 

[speccery]

4 hours ago, TheBF said:

Is your firmware written in C++ ?

Not sure what it has to do, but could Mecrisp just become the "resident monitor"

It’s written in C, and it is a simple program. The benefit of C is that ST micro’s tools (STM32CubeIDE) make it easy to get the on-chip hardware initialized without reading 1000+ pages of the reference material. There are only a few hundred lines of real code once the hardware is set up. The whole thing could be ported to Forth. The tricky initialization code could be ported to Forth as well.

 

I’ve looked at the code generated by mercisp (it comes with ‘see’) and it’s pretty damn good. I also really really like that its disassembler (and assembler!) both use postfix notation even if they’re written in forth. Further, the source code is written in normal assembler, making it easy to understand, it’s compiled with gcc’s assembler and not using some forth cross compiler (at least the parts I’ve looked at).

 

When I have time I will try to see if the GROM service routine could just be an interrupt handler.

 

I’m also interested in porting Mecrisp to the StrangeCart, to replace the simple shell I’ve written for it.

[speccery]

20 hours ago, Tursi said:

I'd be down for a grommy2  Might finally get me off my butt to finish MPD

 

I’d be happy to send you one. Just send a PM. And what is MPD?  

[+acadiel]

A bit off topic... reading all this makes me wonder if we can eventually make the TI run a Z-80 core... like the TI-99/3B was originally made.  Sources say it actually was up and running and ran circles around the 99/4.  But the "that's not a TI chip" got it killed.  Quite a bit of data on it too - and that they built 7 or eight of them and got them going was pretty impressive.

 

Be cool to get the basic TI BASIC and GPL going on a virtualized Z-80 console just for fun to emulate what they did back then.  It would be entirely a pursuit to do it "just to do it", and probably wouldn't serve any useful purpose at all.  (Yeah, I know everything would have to be rewritten/recompiled....) 🙂

 

 

[+TheBF]

4 hours ago, speccery said:

It’s written in C, and it is a simple program. The benefit of C is that ST micro’s tools (STM32CubeIDE) make it easy to get the on-chip hardware initialized without reading 1000+ pages of the reference material. There are only a few hundred lines of real code once the hardware is set up. The whole thing could be ported to Forth. The tricky initialization code could be ported to Forth as well.

 

I’ve looked at the code generated by mercisp (it comes with ‘see’) and it’s pretty damn good. I also really really like that its disassembler (and assembler!) both use postfix notation even if they’re written in forth. Further, the source code is written in normal assembler, making it easy to understand, it’s compiled with gcc’s assembler and not using some forth cross compiler (at least the parts I’ve looked at).

 

When I have time I will try to see if the GROM service routine could just be an interrupt handler.

 

I’m also interested in porting Mecrisp to the StrangeCart, to replace the simple shell I’ve written for it.

Ya Mathias has a done pretty great job. He has some state-of-the-art thinking in optimizing a single pass compiler. Way above my pay grade.

 

Yes the MPE guys pioneered prefix assemblers in Forth. I have been threatening to change mine but I am too busy making bugs.

I don't know if Mecrisp has any libraries for interfacing to C code but I used to do that in DOS so I know it can be done. 

 

Sounds like you have found a great tool for your project.  Always fun to hear about your progress.

 

 

 

 

Edited November 8, 2022 by TheBF
typo

[Tursi]

12 hours ago, speccery said:

I’d be happy to send you one. Just send a PM. And what is MPD?  

Cool.

MPD is an old project to run multiple versions of the OS in a single 4A chassis. It was pretty far along and then stalled.

 

I don't have a video anymore, but you can run it in Classic99 using these files (note: not drag and drop - you'll have to add an entry to Classic99.ini ).

 

mpd.zip

[Tursi]

11 hours ago, acadiel said:

A bit off topic... reading all this makes me wonder if we can eventually make the TI run a Z-80 core... like the TI-99/3B was originally made.  Sources say it actually was up and running and ran circles around the 99/4.  But the "that's not a TI chip" got it killed.  Quite a bit of data on it too - and that they built 7 or eight of them and got them going was pretty impressive.

 

Be cool to get the basic TI BASIC and GPL going on a virtualized Z-80 console just for fun to emulate what they did back then.  It would be entirely a pursuit to do it "just to do it", and probably wouldn't serve any useful purpose at all.  (Yeah, I know everything would have to be rewritten/recompiled....) 🙂

If you want to know what a TI with a Z80 CPU runs like, just look at the ColecoVision/Adam.

 

[RXB]

On 11/6/2022 at 11:59 AM, speccery said:

After spending quite a few hours today I have the first boards ready for shipment, trying to get them out the door tomorrow as I have business travel ahead. All kinds of new learnings when building these boards. Perhaps this is a good time to introduce the TI-GROMmy2 board:

• Form factor almost identical to the TI-GROMmy
• Uses STM32G070KB6 MCU.
  • 128K Flash
  • 36K SRAM
  • 32-pin LQFP, pin pitch is a leisurely 0.8mm as opposed to the 0.5mm with the first grommy or most other boards I have recently worked on.
• Firmware lags behind TI-GROMmy.
• With both boards the functionality is quite minimal.
• The grommy2 extra flash is not yet used in any meaningful way, it just sits there. But the extra capacity means it can easily store multiple GROM images.

The flash memory can be programmed with either a simple FTDI adapter or with ST-LINK2.1. I today learned how to configure the chip for serial port flashing.

 

After bringing up the board I also ordered a NUCLEO-G70RB board, it has the same MCU but in a 64 pin package. I "ported" Mecrisp Forth for this board (there was almost no effort as there already was a version for NUCLEO-G71RB which is very similar). This might be interesting for the @TheBF and not hard to guess what firmware add-on I am planning for the TI-GROMmy2  I think the ported Mecrisp-RA probably would already directly run on my board, but both it and my firmware are baremetal versions, so I need to find some software glue and put these two together...

 

Turns out you can get EA Basic support routines in Basic from my series GPLHOW2 on AtariAge

 

 

 

[speccery]

7 hours ago, RXB said:

Turns out you can get EA Basic support routines in Basic from my series GPLHOW2 on AtariAge

 

Thanks, will take a look!

[+arcadeshopper]

On 11/8/2022 at 2:08 AM, Tursi said:

If you want to know what a TI with a Z80 CPU runs like, just look at the ColecoVision/Adam.

 

or a NABU

[+DuaneAL]

18 minutes ago, arcadeshopper said:

or a NABU

I have been seeing NABU everywhere this week.  I had never heard of it before.  One of the YouTubers showed a picture of a couple of pallets of NIB/NOS units waiting to be purchased. The challenge for that model was lack of local storage.

[+arcadeshopper]

Just now, DuaneAL said:

I have been seeing NABU everywhere this week.  I had never heard of it before.  One of the YouTubers showed a picture of a couple of pallets of NIB/NOS units waiting to be purchased. The challenge for that model was lack of local storage.

There was storage..  you just had to buy it extra.  a guy who's dad used to work there has it working with the original software..  some interesting graphics and games  I'll pm you a video link

 

[Geoff Oltmans]

On 11/8/2022 at 4:08 AM, Tursi said:

If you want to know what a TI with a Z80 CPU runs like, just look at the ColecoVision/Adam.

 

Indeed... lately I've been wondering about how hard it would be to do a GPL interpreter for the ADAM.

 

 

(and...you could probably I'm guessing put a GROM port in IO space on the Z80). I guess the real question is how much "pure" GPL programs there are out there... it seems like a good chunk of the console GROMs for sure unless they reference DSR routines at specific addresses, Car Wars is supposedly 100%, but my knowledge of GPL/GROMs is pretty superficial.

 

It does make me wonder if part of the motivation for GPL was to abstract the hardware design enough that they could change the underpinnings more easily.

Edited December 30, 2022 by Geoff Oltmans

[Geoff Oltmans]

 (dupe removed)

Edited December 30, 2022 by Geoff Oltmans
dupe

[Tursi]

13 hours ago, Geoff Oltmans said:

Indeed... lately I've been wondering about how hard it would be to do a GPL interpreter for the ADAM.

 

 

(and...you could probably I'm guessing put a GROM port in IO space on the Z80). I guess the real question is how much "pure" GPL programs there are out there... it seems like a good chunk of the console GROMs for sure unless they reference DSR routines at specific addresses, Car Wars is supposedly 100%, but my knowledge of GPL/GROMs is pretty superficial.

 

It does make me wonder if part of the motivation for GPL was to abstract the hardware design enough that they could change the underpinnings more easily.

I've looked at it a few times... and I always get hung up on the fact that while it seems like it should be really abstracted, there are just enough gotchas to make it annoying. That, and I don't want to reimplement the format command.