speccery

It never ceases to surprise me how fast time goes... Already half a year no update in this thread. And this update is off-topic, but an update of my recent activities. As background, I've been very busy with work and I guess somewhat tired due to the dark season we're going through in my neck of the woods. Not much energy to work on retrocomputing. Also the hobby seems to go in cycles for me, I've playing with my synthesizers and trying to make progress with my piano playing in the meantime. With that, this update is going to be somewhat off-topic but related to the pico cart one way or the other. Firstly, I've been curious to know if I can manually assemble boards with QFN packaged chips. Two chips interest me in particular: the RP2040 (powers the rasberry pi pico) and ICE40UP5K (small FPGA). In order to test this, I ordered already ages ago (I think maybe already in 2022) boards from PCBWAY with Minimal Design Example by the Raspberry Pi people. No changes on my side at all, a simple two layer board, minimal design for the RP2040. I finally today got around seeing if I can build these by hand. I assembled two boards, and got both working. The first prototype build took something like four hours... A big chunk of that time went into finding the PCBs, components, going through the schematics etc. I don't even want to mention all the mistakes I made - but let me say that I did the big one and despite double checking managed to install the RP2040 chip 180 degrees off first...The other problem I had was that I my micro USB connectors were not the same as in the design originally and it shorted VBUS (the 5V power input) to ground. Once I figured out this was the problem, I was able to fix this easily by just moving the connector a bit. Easy with the hot plate, which I used my hot plate to bake the boards, and that greatly speeded up both the assembly and the numerous iterations of assembly bug fixes. The second board assembly only took about 35 minutes, starting from having the components and the bare PCB, to the board passing a simple test program - the LED blink, although there is no LED on the board so I observed the blinking with an oscilloscope. Here are the finished boards: Here are some pictures of the build process. First after applying paste (in a bad way - too much paste mostly, and not enough in some spots): Then most components placed on top of the paste - including the RP2040 misoriented by 180 degrees... And finally the board after first bake - the RP2040 still in the wrong orientation. I did not realise the chip was mis oriented before applying power... That meant the first chip became toast, but I replaced the chip and put another in place and the board worked If you open the picture and look closely, you can see many solder balls next the QFN chip "pins", there was too much solder paste. Removing the balls turned out to be very easy, just apply flux and give it a touch of the soldering iron, with a pretty sharp tip. The QFN packaged chips don't have any real pins, they just have the contacts exposed at the very edge of the plastic. Despite the numerous problems with the first board I was surprised how easy the QFN packaged chips were to work with. The key is to order a stencil when ordering PCBs, and let solder paste, flux and surface tension do the job. This board also uses 0204 sized capacitors and resistors. I have never so far dared to use these in my own designs. They are very small, virtually inseparable from pecks of dust... But using the stencil and solder paste they were surprisingly easy to work with, you basically just drop them where they need to go and baking takes care of the rest. Except when there is too much solder paste, and they float a bit... Anyway with this experience I'm probably going to design my first FPGA board using the ICE40UP5K. Perhaps I will do a revision of the picocart which would include both the FPGA and RP2040. I think the original picocart design is still the way to go for most DIY people (when I have time and inspiration to finish the firmware) as it is a much simpler build that using the plain RP2040 chip. Then a completely off-topic thing, before the holiday season I completed one of my simple dream electronics projects and built a small mechanical keyboard, pictured below. It is my own design, the Raspberry Pi Pico board to powers it. The board has two quadrature encoders (with push button functionality), 15 Kaihl low profile hot-swappable mechanical switches, and 15 neopixel RGB LEDs, one for each key switch. After building the board and developing some software, I realised that I can run the QMK firmware on it. I also added a screen as an afterthought. The current QMK based firmware supports 4 key layers, one of which is a MIDI layer enabling notes to be played with the keys. Depending on the layer the encoders can be used to control multimedia features such as volume or adjust RGB backlighting effects. I still need to do more work with the firmware, very many ideas where to go from here. Also this design would benefit from not using the Pico board but rather the RP2040 chip directly on the board. I built four of these so far, gave two to my brothers as xmas presents and one to my son Not sure if they appreciate the effort though but fun project - and very tactile

Yes, sure. This was my original thought, before I started to think that loading from disk could be easier for some. I will make an example cartridge image in the coming days.

Thanks, I took a look at the files. There is no documentation how to use GPL@LOADER here, it seems to be an executable program. I assume it is part of the GRAM Kracker software. It does not appear there is source code, that's really what I was looking for. How is GPL@LOADER used? Do you load it with E/A or how does one launch it?

Thanks Fred, this is the information I was looking for! The INT/FIX 128 format is probably the best for me.

I don't think this is what you're looking for, but anyway, for what it's worth: I've been contemplating with the idea of making a simple FlashGROM type cartridge, with only a microcontroller implementing GROM capability and a separate regular SRAM chip connected to the cartridge port (probably also with latch to support paging of SRAM if larger than 8K, and a little glue logic to choose whether writes from TMS9900 go to SRAM or the address latch). I've advanced my grommy2 project lately, and this idea of MCU+SRAM came to mind. Looking at documentation on TI Tech Pages, it appears that GROMs can contain power up routines. Such a routine could copy initialisation data from GROM space to SRAM, making the SRAM work like ROM. Although I've been thinking about this idea in the context of a very simple cartridge, there's nothings stopping using the same idea to init a DSR RAM from GROM. A single GPL instruction MOVE >1000,G@>8000,@>4000 would copy 4K of code from GROM address >8000 to the DSR RAM (provided the DSR memory was enabled with the right CRU settings).

I created the first version of the config tool for grommy2. I continued to write this on GPL. There are two screens, and single keystroke commands (in the time honored way commands are issued on the TI) are used to perform actions. Here is the main screen, under js99er.net. I have also run this on the real hardware. The version number is 0.0.99 when grommy2 is not detected. The second screen, accessed with command 9, has a GROM dump tool. It also will have the ability to flash a new firmware, provided it has somehow been loaded to the 24K GRAM. Here is a screenshot: I attach the new config.bin, a GROM cartridge image which can directly be loaded with js99er or presumably any other emulator. It can be tested (the GROM dumping thing) without a grommy2, it will just show contents of GROM. But this is shockingly slow! Probably the GPL code could be optimised further. The source code config.gpl can be found here. This second screen is a bit cryptic, but there are 4 commands: 1 : Decrement GROM address by 64 (hex 40) and dump 64 bytes 2 : Increment GROM address by 64 and dump 64 bytes 3 : return to previous screen. 0 : flash firmware (not implemented yet but trivial) So here pushing 1 or 2 will show the next crop of 64 bytes of GROM contents. But it is dead slow, you can see as the progress as the code updates the next page. I did not have high expectations for GPL execution speed, but this still is slower than I expected (haven't tried this screen on the real iron yet). Given that for me it is much harder and slower to write GPL than assembler code, I really was hoping this would go faster. Well, a piece of GPL code can always copy machine code snippets from GROM to the scratchpad memory and use the GPL instruction XML to run it, perhaps that's the way to go. I went with GPL since I want this config tool to run from the grommy2 without additional hardware (the code is currently less than 2K and will fit into the unused areas of GROM space). Then a question: to update the firmware, the new firmware needs come from somewhere. Perhaps it should be in a disk file. Does anyone have a piece of GPL code which would load binary data from disk? I also wonder what would the right format for a disk file, probably a 80 byte fixed record file as there are no pure binary streams to my understanding available. What I need is a way to load 24K of payload from a file to GRAM. A simple way would be use the LOAD PAB opcode, but that is limited to what can fit in the VDP RAM given the way the TI works. I could break the 24K firmware to three 8K files, which would then be loaded with the LOAD command to VDP RAM and copied from there to GRAM 8K at a time. But it would be better if the firmware was stored in a single file. config.bin

Hi Arto, my source of information and inspiration with GPL have been the TI intern book (available in PDF format, contains disassembly of ROM TMS9900 code and system GROM disassembly in GPL). However, like I mentioned, the TI Mini Memory module's GPL disassembly files and explanation here are easier to approach and play with. I have said it before, and I will probably say it again in the future, but as a kid I really should have bought the Mini Memory Cartridge instead of extended Basic. They were both bloody expensive at that time and had the same price.

Wow it's been almost 3 years since the last update... I had received reports that the code no longer works with new versions of the oss-cad-suite toolchain. No wonder, as I haven't worked on the project for way too long. The project now works with the 2023-11-18 release which I used during debugging, although I had to disable SDRAM support for now as this is not working anymore. I was using code from @pnr but it instanciates a component which is no longer there. The project is still here at GitHub :) I will try to find a bit more time to work on this thing, I didn't quite remember how cool this one was even if I made it... I have been working on so many other projects in the meantime - and I had a bit of a pause with TI stuff during summer. Perhaps it's time to enjoy some more FPGA goodness. Maybe I will combine a couple of projects - I could expose a GROM port on the GPIO pins of the ULX3S and connect that to the Grommy2 board for example. The nice thing is that with the ULX3S I get HDMI output. Although at the moment the video mode I use does not work with my capture device, need to see if I can increase the resolution.

I updated the '1bpp2basic.py' python script so that it now also creates a GPL version of the screen definition The new version is on my Github repository. I also created a module header & setup program called config.gpl (inspired by the setup code from Mini Memory) which includes the generated screen.gpl code and draws the screen. The code is compiled with python3 1bpp2basic.py xga99.py --aorg 0x6000 config.gpl -L config.lst -o config.bin and the generated config.bin file is a small GROM image which can be loaded with js99er.net. Since the name ends with a 'g' the emulator detects its a GROM. The BASIC program SCREEN.BAS is still generated as well. Compared to the BASIC program, the GPL code is more compact (if you only consider the screen definition) and very fast. Below is the output rendered by the example GPL, I also attach the GROM image 'config.bin' which can be loaded to an emulator. It is not very interesting, as there is no interaction. But anyway this completes the workflow from a 1bit per pixel BMP image to a GROM image. Also, the source code config.gpl might be interesting to someone willing to learn GPL (I still learning myself). config.bin

My next step in this project is a program, running on the TI and probably written in GPL, which will create a simple user interface to display the status of the grommy2 and to perform the typical tasks such as enabling GRAM and copying stuff to it from one of the user GROM banks. I wanted to have some graphics in that as well, and I ended up creating a simple python3 program which converts a 1bpp BMP format picture into a TI Basic program drawing the picture - as long as there are enough user characters available. I'm not going to implement the final program in Basic, but this was a quick way to test that the conversion works and a fun exercise. The code of the python program 1bpp2basic.py is available and "documented" at GitHub: the tool in GitHub Here is the generated BASIC program for the test program. Thus the input is a picture and output SCREEN.BAS listed below. Here is the output captured from js99er.net after running the program:

I don't know where you get this idea of 3*6k capacity with the grommy2. I have all the time communicated that the grommy2 does 3*8k in the system GROM area (meaning the bottom 3 GROMs, total 24k). When loaded with original TI system GROM contents, then only 6k of each of the 3 GROMs contains useful data, and the top 2K of each 3 GROM areas (1800..1FFF, 3800..3FFF, 5800..5FFF) is unused - or available for extensions. The grommy2 has enough flash memory space to provide another 40k on top of the bottom 24K, making a total of 64k. That is not implemented in the current firmware, but would be easy to do - if it makes sense.

Thanks @RXB for the feedback. I was looking for this. Before I respond to your comments, a couple of pieces of background information: the grommy2 is a system GROM replacement device. Due to this, it only has access to GROM signals. It is not connected to CRU signals nor can it act as a normal RAM or ROM. It can only do its thing in the GROM space. It cannot support multiple GROM bases, since being compatible with the GROM chip pinout it is not connected to extra address lines. I on purpose limited the address range it covers to the system GROM area. Remember that this thing plugs inside the console in the place of the GROM chips. If the grommy2 was to serve GROM addresses beyond 24K, it would conflict with GROMs connected to the cartridge port. Unlike the normal system GROM chips with weak data bus drivers, the grommy2 has strong drivers and would overpower GROMs connected to the cartridge port. As the documentation says, it operates always in 8K GROM mode. So not 6K but 8K per GROM for a total of 24K with 3 GROMs. The exception is that the command interface is at address 5FF0, masking the top 16 bytes of the 3rd 8K GROM. Indeed the command interface, being at the top of 8K GROM slot #3 does not interfere with any 6K GROMs. I can make the command interface more sneaky to enable access to those 16 last bytes in the system area if needed. I can place it anywhere in the GROM space, for example to FFF0..FFFF. The grommy2 could easily serve the entire 64K GROM space, but the problem is, what happens if you plug in a cartridge? I suppose I could add some sensing code to only serve the area from >6000 onwards if nobody else is driving the bus then, but that functionality would need to rely on heuristics. Please enlighten me, I posted the spec to collect feedback. Please also note that there are other devices, like my StrangeCart cartridge, which can act as a large GRAM and large RAM/ROM simultaneously. With regards to hardware vs software know-how, I do much more software than hardware, also professionally I've done much more software than hardware design. I enjoy both

I spent this weekend a couple of solid sessions on improving the grommy2 firmware and testing it. It now has a pretty solid level of functionality, I still need to test the firmware upgrade capability though. I also took some time to write a document about the grommy2 software interface, it's available here in the StrangeCart-Doc documentation tree. It's not the right place for the document, but I wanted to make it available for review immediately. As the document explains, I used some GPL code on a modified version of the Mini Memory cartridge to test the grommy2. Out of the eight commands I outlined in the previous message I have tested five - including flashing of the MCU inside of the TI under the control of TMS9900! In other words, I was able to use GPL code to first copy default GROM to GRAM, enable shadow RAM (i.e. writes) and select the GRAM bank, edit the contents of system GROM/GRAM with a modified version of Easybug, and finally write the modified version to the Flash memory of the grommy2. I tested this with both user banks, programmed them back to the grommy2 and powered off the computer. After powering on again I re-entered Easybug and switched back to user GROM area - and the changes remained! I also realised that the GRAM area can be used as a 24k memory expansion of sorts, and started to think of adding a couple of calls to normal TI BASIC for example to move strings back and forth the GRAM area... I am happy I took the time a week ago to think about the specs as above and got some structure into this project.

The microcontroller I am using in the grommy2 project could easily do this (128k of Flash and plenty of horsepower for something like this). I took a very quick look at the TMS6100 pinout and I think it probably be a simple matter of just wiring the grommy2 board to replace the TMS6100 chips. I can try it out when I have time. I am currently working on the Grommy2 firmware already, although haven't had time to advance it this week.

I've been a little under the weather and watched some retrocomputer related videos. I discovered a ZX Spectrum project from Spain, the Dandanator and its extensions. I studied this project and the code in Github briefly. This somehow motivated me to continue with the grommy2 firmware development, and I was able to spare a few hours during the weekend to work on it. The basic realisation for me was just that I need to limit the feature set to something useful to be able to get a better full-fledged firmware out. A device like the grommy2 can do so many things, that it's easy enter the idea land which leads to feature creep... So I decided to put in some constraints, and I would be interested in feedback from the community. What follows is what I decided to do, and I have already written in the firmware. I have tested most of these features already in isolation on dev board, but I haven't yet tested any of this running when the board connected to the TI. Since the previous firmware version was already working well, I have no reason to think this would be hard to get running. This is the feature set: Four 24K memory banks covering the system GROM area. One of these is active for reads at a time. #0 normal TI-99/4A system GROMs, stored in Flash. This is the default. Read only. #1 user system GROM bank 1, stored in flash. Read only. #2 user system GROM bank 2, stored in flash. Read only. #3..#7 reserved #8 24K GRAM area stored in RAM. By default read only, but writes can be enabled. The RAM area works as a shadow area: when writes are enabled, the written data goes to this RAM, regardless what GROM bank is chosen for reads. Command interface at GROM address 0x5FF0 (last 16 bytes of the system GROM area) By writing 16-byte commands to this memory area, the grommy2 will perform certain tasks The simple command interface implementation means that the system GROM code cannot use the last 16 bytes of GROM. Since normal TI GROM chips are 6k each, occupying a 8k memory slot in the GROM address space - with 2k dummy data at the end - the command interface does not interfere with standard system GROMs. I know there are some extensions of the system GROMs, and if they use these very last 16 bytes there might be a problem. I hope in practice not, and if that happens, the interface can be modified. Commands. At this point there are a 8 commands, invoked by writing a 16 byte command to 0x5FF0 continuously. The commands are: 0: Read version. Makes the grommy2 firmware version information available for reads at address 0x5FF0..0x5FF7. 1: Select GROM bank to be used for system GROM reads. Valid banks are 0..2 for Flash and 8 for GRAM. 2: Copy a Flash bank to GRAM, valid banks are 0,1 and 2. 3: Enable/disable RAM shadow mode. When enabled, writes to system GROM area go to GRAM (bank 8). 4: Write contents of GRAM to Flash bank 1 or 2. One parameter of the write command is a bit mask, choosing in 4k chunks what parts of the GRAM to write to Flash. This can be the entire 24K, or any combination of 4k areas in the 24k system GROM range. 5: Compare contents of GRAM to flash bank 0,1 or 2. 6: Write the contents of GRAM as new firmware for the grommy2. Needless to say this command is dangerous, but allows updating the firmware while the grommy2 is inside the TI without any debugging cables etc. 7: Execute code in the GRAM region by the ARM processor of the grommy2. In addition to the above, I will modify the firmware so that it monitors one of the spare I/O pins of the grommy2 when it boots. Depending on the level of the I/O pin, the grommy2 will boot with Flash bank 0 or 1. This makes it possible to run custom GROM code from the boot. The command set above I think is enough to enable all kinds of use cases: GRAM mode: Copy one of the flash banks 0,1 or 2 to RAM. Switch to RAM bank. Enable shadow ram writes. Run custom system GROM: Select user bank 1 or 2. Write custom GROM contents: enable shadow RAM mode, write new GROM contents by just writing to the system GROM area, and finally issue the command to write the contents of GRAM to flash user bank 1 or 2. After this the contents are non volatile and can be entered by just selecting that bank for reads. Note that the normal system GROM bank can be active for reads throughout this process. Update firmware: enable shadow RAM mode, write new firmware contents by just writing to the system GROM area, and finally issue the command to write the contents of GRAM as new firmware. Note that the normal system GROM bank can be active for reads throughout this process. The system probably needs to be reset after this... I haven't tested this functionality yet. Feedback is welcome.

After a long pause I've been working a bit on improving the StrangeCart Basic interpreter. Performance improvement attempt I have used Noel's (I forget his handle here) Basic program as a test program, as I am sure I have written here before. I have also written about how much excess work the interpreter does when running the code. The test program goes like this: 10 FOR I=1 TO 10 20 S=0 30 FOR J=1 TO 1000 40 S=S+J 50 NEXT J 60 PRINT "."; 70 NEXT I 80 PRINT S The inner loop consists of lines 40 and 50. The TI-99/4A Basic runs this in 77 seconds if I remember properly. On the STM32G431 port of StrangeCart Basic (explained below a bit) this code ran in 0.137 seconds. That's only 560 times faster, and I know there is a lot to do optimise execution. One thing to do is to just optimise the code in general, step by the step to get incremental gains. I think I have previously contemplated here about transforming the code into a different representation, and rather than making simple optimisations I made a complex modification to the code. I targeted expression evaluation, specifically LET statements (above lines 20 and 40). I modified the expression evaluator so that in addition to interpreting, it builds a parse tree of the expressions. The parse tree generation builds a directed graph of the expression. It doesn't support yet support all expressions, as this more of a proof of concept. Anyway now when a LET statement is encountered, the code checks if a node tree exists already for the line in question. If it does, the code skips interpretation completely and uses the stored node tree to evaluate the expression. If no node tree exists, it will build the tree and stores it. For debugging I added code to dump the parse trees into textual format, so that I can see if it works right. This the output after inserting a line "45 stop" to halt execution so that the output can be observed without the crazy loops. The code writes spaces in front of the operations in the node tree to reflect the depth in the tree: >45 stop >run *** STRANGECART RUN *** BIOP STORE: ADDR &0x20001AD4 CONSTF 0 BIOP STORE: ADDR &0x20001AD4 BIOP ADD: FETCH ADDR &0x20001AD4 FETCH ADDR &0x20001AEC Stop. Use cont to continue.Runtime 0 seconds and 19802 us. 0.019802 The two let statements have as root nodes "BIOP STORE" nodes. BIOP stands for binary operator, in this case that means the operator takes two arguments. Line 20 S=0 generated this: BIOP STORE: ADDR &0x20001AD4 CONSTF 0 The first operand of the LET contains the target address for the store (it is the left node of BIOP in the tree). The address is the address of the variable S' data field in the symbol table. The first execution of the line 20 runs in interpreter mode, and among other things creates the variable S in the symbol table, in this example the actual floating point value storage address of S is at 0x20001AD4. The second operand of store is the value, which in this case is presented with the terminal node CONSTF 0 (floating point constant with value of zero). When this simple tree is evaluated, it simply writes the floating value of zero to the address 0x20001AD4. Note that when the stored tree is evaluated, the code does not need to search for variables or anything, it's all stored in the tree. [For Forth aficionados this would be the same as "0.0 0x20001AD4 !" or something like that, I don't remember how floating point numbers are expressed.] The second tree for the Basic line 40 S=S+J is a little more complex: BIOP STORE: ADDR &0x20001AD4 BIOP ADD: FETCH ADDR &0x20001AD4 FETCH ADDR &0x20001AEC The beginning is the same, with the STORE and the destination address. The data to be stored is more interesting, as it is another BIOP node, this time ADD. The two children of this node are both memory fetch unary operations, one from the address of S and the other from the address of J. Running normally - without displaying the contents - the benchmark now runs on the STM32G431 much faster, finishing the benchmarking 0.036 seconds, which happens to be 3.6 times faster than the previous time 0.129 seconds. Each iteration of lines 30 and 40 together now takes 3.6 microseconds. This can still be substantially improved. The TMS9900 can hardly execute a single machine instruction in that time, and here we do on line 40 two fetches, one add, a store, plus all the activities of NEXT (fetch J, add the step of 1.0 to it, store new value of J, compare it to the limit of 10.0 and do a conditional branch) back to line 40. In case you are wondering, this kind of node presentation of expressions is typical for compilers. However, I am not compiling the Basic code (yet) to machine code, but rather storing the whole tree as a data structure and evaluating (in practice traversing through) the tree on the fly. The node trees consume a lot of memory compared to the Basic tokens, and the STM32G431 only has 32K of SRAM. But this functionality is getting close to what a just-in-time compiler would do. Still, in many programs certain inner loops consume most of the time, and storing a bunch of expression evaluation trees for those would not need to consume much memory. One kilobyte would go a long way. A couple of ports of code I ported the current version over to two microcontrollers, the STM32G0B1 and STM32G431. The former is based on the Cortex M0 core and the latter on the Cortex M4 (incidentally the MCU on the StrangeCart contains both of these cores). I've used the ST Micro's software development toolchain now for a while, and have started become familiar with it. My GROM replacement grommy boards use the STM32G0 series chips too. Even if Cortex M4 and M0 are very similar, there are differences which uncovered a few bugs, or at least portability issues, with the code. It turned out that Cortex M0 does not support unaligned memory loads. The Ti99/4A tokenised lines of code contain line numbers stored as 16-bit integers. I was loading them as 16-bit quantities with a 16-bit load, but that raises a memory access exception on the Cortex M0 if the 16-bit quantity is located on an odd address. Also the TMS9900 cannot do unaligned loads like that. That was simple to fix. Bug fixes I uncovered some bugs, the expression evaluator was not doing math in the correct order. An expression such as 1/2*3 was evaluated as 1/(2*3) instead of the correct order (1/2)*3. That was simple to fix. I also noticed that I didn't properly handle everywhere in the code the valid unusual variable name characters: @ [ ] are valid characters in TI Basic. You can write: ]=3 And use that as a variable name. Now those are supported too. I've also done work to make the tokeniser work better. It can now correctly tokenise more complex programs, although I know there are still some issues. Overall, this is interesting stuff to work on. I will make a new StrangeCart firmware version when I am a bit further with all of this.

Thanks for sharing your experiences, very interesting read. What you explain about the special robotics controller sounds a lot like what SPARC CPUs do, they also have overlapping register windows. Unlike on the TMS9900, there is a massive register file, off-chip memory is not used register storage. The programmer sees 32 registers at a time, 8 of which are a global, and 24 are a window to a larger register file, which could for example have 160 registers in total. @TheBFsome TI DSPs have VLIW architecture. I have programmed professionally some TI DSPs, but unfortunately it was before the VLIW chips like TMS320C6201 became available. The TMS320C6201 packs up to eight 32-bit instructions into one instruction packet, so the DSP fetches 256-bits worth of instructions every clock cycle. In practice it might be able to execute only some of those in a given cycle, as each instruction within a packet needs to use separate functional hardware units to run in parallel. The architecture places a lot of burden on the programmer or compiler to get the best speed out of the system. My understanding is that these DSPs are purely in-order execution engines and they have marker bits in the instruction stream to tell which instructions of a packet can be run simultaneously on a given cycle. For example you might have an instruction packet where three instructions can be executed in a cycle, and the remaining 5 would be merged with 3 instructions from the next packet, and then checked which of those can be run. But it all happens in order, even if there are no data dependencies. It is very interesting stuff. Contrary to that, from the Pentium Pro onwards the x86 architecture introduced speculative execution, register renaming and out of order execution. The CPUs became more or less data flow machines, requiring a lot of hardware to extract parallelism from non parallel instruction streams. Compared to that the VLIW designs are much simpler and more elegant - hardware wise...

Perhaps you already know it, but the FinalGROM cartridge could be what you're looking for, it plugs to the cartridge port and includes GROM support. It loads both ROM and GROM contents from a SD card and writes that data to the RAM chip. That board has a CPLD chip which emulates the GROM logic. The grommy boards are meant to be a replacement for the internal GROM. I have implemented GROM support in the StrangeCart and Picocart cartridges, in both cases using microcontrollers.

The could be done with system GROM changes for sure, but I think it could also be done with power up routines in the cartridge space. There are already multiple cartridge Forth implementations. If you're thinking about not requiring the cartridge port i.e. keeping it available, the grommy2 could include code in GROM space which could be copied to 32K RAM expansion and execution transferred there. It does not make sense to implement a Forth in the GROM GPL, you really want to be running a machine code Forth.

Hi and sorry for the very slow reply, I have been absent from the forums for a while. Yes the devices are for sale, I have some PCBs and ready constructed boards too. I do need to work a bit on the software though, since I want to make it upgradeable while plugged in. For your use case, are you looking for basically a system GROM which would also include the E/A GROM? That certainly is doable but not implemented in the present software build. Not difficult to change and include that support.

Thanks! That did the trick!

Thanks @HOME AUTOMATION and let me ask a simple question - what are the recommended tools to look into the .tidisk files contained in the zip files? I know I should know this but I don't. I quickly tried with with classic99 and xdm99.py but they don't work immediately. I am looking for software running on Windows, Linux or macOS (the latter my preferred host OS). Thank you!

@TI_Ken thanks for making the game available! I haven't been doing anything with my TI for the past 4 months or so, but this TIBASIC game made me want to see if my StrangeCart can run it. And it could not, I had not implemented the RANDOMIZE keyword - this turned out to be the first game or other program I have tested to use it. So needed to add that. I had to refresh my memory about where I was with the code, I have been doing refactoring of my Basic interpreter. There appears to also be a graphics bug with my basic, the black background did not initialise properly. After looking into the code, I see that the background character 112 is initialised like this: 2010 CALL CHAR (112,"0") I guess when the hex string is just one nibble, I have an off by one error in defaulting the character init to zero. Well, these are just my StrangeCart Basic bugs, after fixing the Randomise thing the game runs so fast that it's totally unplayable, so need to insert some CALL VSYNC calls into the code. At any rate, great to see an interesting new Basic game! Great job!

Sorry for my long absence, I have been busy with real life, not much time for retro computing. With the autumn coming I hope I will have some more time. The GPL acceleration interesting. I am not familiar with the Geneve (other than wanting one), I mean I know what it is but not from a user's perspective. I suppose they have done a better job with implementing the GPL interpreter. To @RXB's question, about speeding up GPL, I have ventured into this domain in the icy99 project where I added a few new instructions to the TMS9900 core I built, and modified the ROM GPL interpreter to use those instructions in a few places. Accelerating GPL could be done with an accelerator like the StrangeCart, but I haven't found enough interest in me yet to try to do it. One issue is that the GPL interpreter is very tied to the scratchpad memory, and my understanding is that any machine code called by GPL using the XML opcode expects that the scratchpad is laid out exactly as it is normally. XML calls are quite common in GPL, so accelerating it becomes an exercise to interfacing the TMS9900 code too, it's not only running a very fast GPL interpreter.

This is something I was planning to try out as well, no surprise someone else already jumped on it. Thanks @Willsy for posting!