speccery

Yes of course! I'd be happy to.

Thanks for the interest - and looking at the thread, it is a very long one by now... I'd be happy to deliver you a board, I should have a few immediately available and if not I can put together a couple over the weekend. The price is 50 EUR + shipping. Please note that all boards are hand assembled by me so should be treated as prototypes. Having said that, I take all boards I've sent through an extensive test list and my understanding is that they all have worked fine. You have probably seen the wiki at GitHub , it should give you a pretty good idea what to expect.

Off-topic, but hey it's my thread and I will probably also create a cartridge case for the StrangeCart. Here are a couple 3D printed "base boards" I've been lately working on. The pictures are not great, I didn't care to setup my proper light. As you can see in these examples there are mounting screw posts for the circuit boards, some wiring holes and places for Cherry MX mechanical switches. These designs keep evolving, but at least so far they're in my opinion pretty great for noodling around. This bigger design below has two "base boards" and some supporting rods connecting the two below the display. The display is an Adafruit 3.5" 480x320px display. Then there is the CPU board, MIDI interface board and the audio DAC board. I'm still working on the software, but the display works (actually both of them work simultaneously), and the DAC board outputs a stereo saw wave at 48kHz sample rate. It uses double buffered DMA for audio output and interrupt based audio generation. The buttons don't yet do anything, I am actually just now printing another button mount to support more buttons. I'm going to use this setup to build a software synthesiser, which is something I've thinking about a long time.

Hi @Artoj sorry for the long silence. I have been very busy at work - and then I've also played around with some electronics music hardware. I was actually reading my post above and that was a pretty good refresher for me as well. I hope I find the time and energy to work on the StrangeCart and my other TI related projects soon. Of course finding time is also partially a matter of priorities like one would guess. I have a pretty basic 3D printer which I've had for at least five years, but I only recently started to spend a bit of time learning FreeCAD and thanks to that I have rediscovered my 3D printer and been using it to make some fairly simple designs. The primary use case for me has been to design "base boards" for some simple electronics projects, i.e. slabs of plastic with mounting to screw in some boards. This has been a pretty interesting journey so far, I have been able to put into good use some of my microcontroller and peripheral boards to build more "complete" systems from those. I'll post a picture when I get home. It's such a basic use of the 3D printer, but extremely useful for me, turning a mess of loose boards and wires into a more rugged and organised mess of boards and wires

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.