Jump to content
speccery

StrangeCart

Recommended Posts

It's a naked ARM processor.  The instruction set is well documented and there are loads of compiler toolchains.

 

 

I am not terribly interested in purchase at this time, but I already mentioned what I would try with it-- Adapting linux's ZRAM code to supply compressed 4k pages on the TI, to make that ~128kb of memory act more like 384k.

Share this post


Link to post
Share on other sites

128K... I see that this would be cool to use in Ex B to make a lot of sub-rutines. Then I could code in my "stone age way" and still have space.

DAC, so a 3,5mm jack to take out sound? Stereo? It sounds good AND... as I understand, this could be a way to take out sound and maybe have more flexibility?

Just the memory card to this Cart is great.

From what little I understand... I like it!

  • Like 1

Share this post


Link to post
Share on other sites

The board has support for what is known as I2S bus. It is a digital audio bus. You can hook it up to a stereo DAC and have something like 48kHz 16 bit stereo audio output. That would need to be driven by something like a software synthesizer.

 

The additional memory on the cartridge requires new software. I have been playing with the idea of creating an implementation of Basic which would run on the ARM processor. Ideally it would be compatible with extended basic. But would be nice to have fast Basic with access to more memory. 

  • Like 3

Share this post


Link to post
Share on other sites
16 hours ago, Asmusr said:

I'm curious about what those people lining up to buy the board expect to be using it for at this stage? Personally I wouldn't have any idea how to program the cart.

In my case, testing what it already does against the hardware in my reference set, as I am much more of a hardware guy than a software one.

  • Like 1

Share this post


Link to post
Share on other sites

Since you have I2S, you could also put a simple UART on there.  Why is that potentially neat?

 

There are UART->Wifi solutions for retro computers. A simple I2S UART module could be slaved with such a module (and maybe even still fit inside the cart shell?), and permit the TI to do some additional tasks.  Since the UART and WIFI would be controlled by the ARM processor, the whole thing could be software controlled from the TI just by writing to and reading from some memory addresses.

 

Imagine a terminal cartridge, that is a fully capable terminal.

 

Another interesting use could be an I2S bluetooth module (which do in fact exist), which could let you pair your TI with bluetooth speakers, mice, and bluetooth file storage capable devices.

 

Rather than integrate a sound DAC there, I would leave it as a 90 degree 4 wire header, and give a retention clip of some kind, so that a module could be added by the user later.

  • Like 2

Share this post


Link to post
Share on other sites

I like the idea of having a gram kracker-ish device. I'm also very interested in the language idea.

What's the cosin(30) - then rather then running a bunch of instructions on the 9900 - little zippy cpu could have the answer back in no time.

Not sure how much ram will be available, but a small ramdisk like provided in the minimem might also be achievable.

  • Like 1

Share this post


Link to post
Share on other sites

Just to explain, I wasn't questioning the usefulness of the card, it just sounds like people think it's more of a consumer ready product than I believe it is. For instance, if you think it already provides a BASIC with 128K RAM you will be disappointed. As far as I understand, to do anything with the cart except run the preinstalled demos, you would need to set up a compiler toolchain on a PC and access the cart using a cable. I wouldn't know how to do that without a lot of reading. 🙂 

  • Like 1

Share this post


Link to post
Share on other sites

Yes, that is exactly the situation I see also, (also, why not interested in purchase at this time.)

 

Ultimately, I see this thing defaulting to some kind of pre-baked "idle" loop with an exit condition, with a mapper chip exposing 4k of RAM to the TI. The mapper chip should be controlled by the ARM cpu, but since the ARM cpu has no program to run (other than the idle loop), the page just stays there.

 

The TI is then able to write 4k of IPL to this page, and then do a write-on-rom to set the loop's exit condition, which then jumps execution of the ARM cpu to the exposed page.  The IPL loads, and the ARM CPU can then move its window (because it has the software to run the mapper chip now), and can accept a larger program from the TI.

 

This would make the strangecart fully configurable by whatever software tries to handle it, because that software controls the ARM chip's boot cycle.  Whatever personality or featureset would be determined by this initial bootstrap, and whatever code gets shuttled to the ARM chip.

 

 

Again, I would want to use it to supply zram-like compressed 4k pages, using write-on-rom switching.  Depending on the data you want to put in the cart, the compression could yield a lot of storage there, and some routines for other useful functions (since the ARM cpu actually owns all that memory flatly, and just moves the TI's window around) that manipulate that memory without the TI's involvement, so some pretty sophisticated games could be made that leverage the cpu there, even with the compressed ram function.

 

I would approach it as a software programmer's multitool, rather than a consumer device at this stage in the game-- As programmers play with the toy, and find ways to use it, then it would become useful for consumers who want to use that software.

 

Right now though? No-- It's a development powertoy.

  • Like 2

Share this post


Link to post
Share on other sites

Yep.. Chicken and Egg.. Strange created the hardware capability, for hardware to reach it's full potential, it will take many developers.

  • Like 1

Share this post


Link to post
Share on other sites
8 hours ago, Asmusr said:

Just to explain, I wasn't questioning the usefulness of the card, it just sounds like people think it's more of a consumer ready product than I believe it is. For instance, if you think it already provides a BASIC with 128K RAM you will be disappointed. As far as I understand, to do anything with the cart except run the preinstalled demos, you would need to set up a compiler toolchain on a PC and access the cart using a cable. I wouldn't know how to do that without a lot of reading. 🙂 

Thanks for the very good comment.

I got sick and haven’t been able to code anything in a couple of days, but at least I can respond here when I can’t sleep... 

 

The easiest native programming environment for the StrangeCart is plain C. The code can be compiled with the gcc tool chain available from ARM for free. I’ve been using that with a Makefile to compile the firmware. Thus software can be developed using a very common tool chain and language, and there is a ton of software available which could be ported over. What is needed is some kind of software development kit.

 

To go back in time, I first learned C using Turbo C for MS DOS (that’s strictly speaking not true, I first learned some C using the ZX Spectrum and a tape based C compiler, but that was so cumbersome that I didn’t really learn C before Turbo C). I bought Turbo C 1.0 and used that for a long time. It came with a small graphics library, the Borland Graphics Interface (BGI) or something like that.  BGI supported some simple graphics commands. If you combined that with kbhit() and getkey() - or what ever the latter was called - you could do very simply interactive content with graphics.

 

I am looking to build something similar to BGI for the strangecart. Basically a library, which would handle the basic functions and generate the required TMS9900 code or just use prebuilt TMS9900 code. If that library also included some of C’s standard I/O functions, one could use familiar constructs such as printf for output. That in turn enables a lot of software to work. I already have a syscall module which handles some of this stuff.

 

I have used gcc on my Mac [targeting the mac] to develop and debug code, and then just recompiled the module for the strangecart. This method doesn’t work for everything, but at least the algorithms can be debugged. This is how I am working on the Basic interpreter.

 

Of course there would need to be support for TI994a specific stuff as well. What I am building is a system which associates TI cartridges (ROM and GROM content) with code modules running on the ARM. For regular TI cartridges there is no ARM side, just the ROM/GROM content. But for StrangeCart specific content there is code associated with the ROM/GROM. The TMS9900 and the ARM communicate simply through shared memory. I am currently mostly using the shared memory just for the TMS9900 to say “I am ready”, and then the ARM creates the next batch of TMS9900 code and tells the TMS9900 to go and execute it - at the end there is code saying “I am ready” again.

 

To @dhe’s point, I am going to implement some simple flash based local file system. One of the inspirations for the strangecart is the mini memory, one way to think about the cartridge is that it’s like mini memory, but ROM/GROM/RAM can all be writable at times and then you have a co-processor on top of that.

 

  • Like 4

Share this post


Link to post
Share on other sites

With a shared memory as the i/o I can envision some kind of interpreter running on ARM as the API for the programmer.

It would be so much faster than 9900 that it should not be a problem in the speed department.

It would allow BASIC programmers to simply send formatted strings to the StrangeCart as commands.

Something like a PCL or Postscript kind of thing. It could even be a BASIC like language or maybe LUA that would allow entire programs to be uploaded onto the ARM that would run like a secondary process.

Might be a simple first interface to explore the board.  It might need a command line that can be accessed via a little terminal program that runs from BASIC using CALL LOAD/LINK

Some of the shared memory of course would be output data but also StrangeCart variables and status indicators for the TI-99 programmer to easily access.

 

I bet we could even find a Forth interpreter that runs on ARM ...  :) 

You knew I had to say that. Come on. You knew it.

 

  • Like 2
  • Thanks 1
  • Haha 2

Share this post


Link to post
Share on other sites
On 4/17/2021 at 5:33 AM, TheBF said:

I bet we could even find a Forth interpreter that runs on ARM ...  :) 

You knew I had to say that. Come on. You knew it.

 

For example here: CoreForth

Cortex M4 is a superset of M3.

  • Like 1

Share this post


Link to post
Share on other sites
On 4/16/2021 at 8:27 AM, wierd_w said:

Since you have I2S, you could also put a simple UART on there.  Why is that potentially neat?

 

There are UART->Wifi solutions for retro computers. A simple I2S UART module could be slaved with such a module (and maybe even still fit inside the cart shell?), and permit the TI to do some additional tasks.  Since the UART and WIFI would be controlled by the ARM processor, the whole thing could be software controlled from the TI just by writing to and reading from some memory addresses.

 

Imagine a terminal cartridge, that is a fully capable terminal.

 

Another interesting use could be an I2S bluetooth module (which do in fact exist), which could let you pair your TI with bluetooth speakers, mice, and bluetooth file storage capable devices.

 

Rather than integrate a sound DAC there, I would leave it as a 90 degree 4 wire header, and give a retention clip of some kind, so that a module could be added by the user later.

I had missed this message. There is already a UART, with pin header brought in front of the cartridge. It is a full fledged UART with FIFOs, DMA support etc.

In fact for serial interfaces with pin headers already on the board there are:

  • UART (just TX and RX, drivers already on StrangeCart)
  • I2C bus (multipurpose, master and slave modes, I have used in master mode with small OLED displays, 128*64 pixels, drivers already on StrangeCart firmware)
  • I2S bus (for audio output, need to develop more software for it, supports high sample rates with 16 bits stereo)
  • SPI bus (could be used for SD cards, color displays, etc. The SPI bus is also connected to the on board 16Mbyte serial flash chip)
  • SWD (ARM debug interface)
  • USB (I am using it as CDC serial port)

Except for USB of the above are supported with the Flexcomm hardware on the MCU, if I remember properly there are 7 Flexcomm units in total. To my understanding they all support FIFOs, interrupts, DMA etc. The USB also has DMA etc. The MCU is mid range chip from some years ago but has very many on chip peripherals. It is a very complex chip.

 

I have also brought to a header two pins which can be configured as analog inputs to the 12-bit on chip ADC.

 

  • Like 3

Share this post


Link to post
Share on other sites
1 hour ago, speccery said:

For example here: CoreForth

Cortex M4 is a superset of M3.

Mecrisp Stellaris generates native code and is mostly ANS/ISO. State of the art Forth compiler.

Mecrisp Forth

  • Like 1

Share this post


Link to post
Share on other sites

When I started GPL on the TI99/4A reading Miller Graphics data on GROM/GRAM and finding out that

the TI99/4A Cartridge Port was set up to access 16 Banks of 40K of GPL and that did not include the 

agility to modify and load GROM/GRAM 0, 1 and 2 also set my mind on fire for possibilities.

 

To date no one has created what I wanted to have as a device in the Cartridge Port.

1. 640K of GRAM/GROM

2. 8K Supercart type of multiple banks (1 Meg) in use with that 640K of GRAM/GROM 

3. A loader/saver for this device in Cart Port.

 

In case you did not know GPL can switch from one GRAM BASE (bank) to another with a command in the TI99/4A called SWGR that I have demoed.

That means you can switch from any GROM BASE (bank) to another and back again, and again I have demoed this as easy to do with 6 GPL commands.

  • Like 2

Share this post


Link to post
Share on other sites
32 minutes ago, RXB said:

In case you did not know GPL can switch from one GRAM BASE (bank) to another with a command in the TI99/4A called SWGR that I have demoed.

That means you can switch from any GROM BASE (bank) to another and back again, and again I have demoed this as easy to do with 6 GPL commands.

That would allow you to build a killer RXB compiler into RXB, Rich--it could even output the compiled code in GPL to create lots of nice new GPL programs for people to enjoy. The 40K limit per GROM base would be more than enough for some truly epic programs. . .

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
53 minutes ago, RXB said:

When I started GPL on the TI99/4A reading Miller Graphics data on GROM/GRAM and finding out that

the TI99/4A Cartridge Port was set up to access 16 Banks of 40K of GPL and that did not include the 

agility to modify and load GROM/GRAM 0, 1 and 2 also set my mind on fire for possibilities.

 

To date no one has created what I wanted to have as a device in the Cartridge Port.

1. 640K of GRAM/GROM

2. 8K Supercart type of multiple banks (1 Meg) in use with that 640K of GRAM/GROM 

3. A loader/saver for this device in Cart Port.

 

In case you did not know GPL can switch from one GRAM BASE (bank) to another with a command in the TI99/4A called SWGR that I have demoed.

That means you can switch from any GROM BASE (bank) to another and back again, and again I have demoed this as easy to do with 6 GPL commands.

The StrangeCart V2 has 16 megabytes of serial Flash memory. One of the reasons I wanted to have that memory there is to be able to load GROM content directly from the serial flash. I am currently clocking it at 12MHz, enabling reads of 1.5Mbytes per second. Random access is slower, since the serial flash needs to be sent a command  to set read address, and that takes 4 bytes. However, it should still be plenty fast for GROM accesses. And the chip supports clock speeds up to 133MHz... I don't know how fast I can make it run on my board, but I think it should easily be able to support random access to GROM, 16 banks of 64K.

 

The normal RAM/ROM accesses are probably not going to be possible from the serial flash directly, so the RAM/ROM content needs to be first downloaded into on chip RAM of the MCU. It still can give at least 128K, i.e. 16 pages of 8K.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I haven't had as much time as I wanted to develop software and build boards, but I have made some progress. My plan is to make a video soonish of the current status of the firmware and functionality, but I still need to get a few more things together.

 

- I built three more StrangeCart V2 boards. The good news are that they all worked on first try. Building several boards simultaneously speeds up the manual assembly process quite a bit, but it still takes at least one hour per board (i.e. 3 hours or something like that for the three boards).

IMG_4318.thumb.jpg.53b80f73f934cdfe8fa5cca8ba6042e9.jpg

 

- I've worked on adding serial flash support to the firmware. I had to dig deeper into the peripheral code than I originally thought for this, but now it seems to work. The serial flash is connected to one of the Flexcomm serial /IO units of the MCU, configured in SPI mode. It is a pretty complex peripheral which I am using naively but at least it now seems to work. Code development for the on-chip peripherals seems to take some time whenever something is not working the first time around. The reference code didn't work for me the way I wanted.

 

- One of the missing pieces I have had is to provide a method of uploading data outside of flashing the entire ROM of the MCU. For that purpose I now have XMODEM receiver working. It took some debugging and deeper understanding how the USB CDC driver buffers data, but seems good now. At the moment the XMODEM receiver just stores incoming data to the cartridge ROM buffer in RAM (currently set as 32K). Sending a 26K test file is pretty much instantaneous.

 

I want to modify this still so that XMODEM reception directly programs the serial Flash chip. Once that's done I will remove the ROM images from the firmware binary, and move all of them to the serial flash chip.

 

The ability to send cartridge ROM images quickly over USB could also be interesting for development purposes for testing software on the real iron.

  • Like 7

Share this post


Link to post
Share on other sites
10 hours ago, speccery said:

The ability to send cartridge ROM images quickly over USB could also be interesting for development purposes for testing software on the real iron.

Yes, I would certainly use that feature. It would allow me to automate the build pipeline for Stevie. 

Currenly I am using FGROM99 and swap SD-cards a lot.

  • Like 1

Share this post


Link to post
Share on other sites

I haven't posted an update in the while, sorry about that. I have worked quite a bit on the software last weekend and some evenings before that, but then tied up with work.

 

I have done a fair amount of refactoring of the code, as well as fixing bugs. And of course adding more functionality. 

 

I am doing quite a lot of development in standalone mode, with the StrangeCart out of the TI. The board can be USB powered in addition to be powered by the TI, which makes development environment portable and convenient in these days when a lot of time is spent at home.

 

I had to debug the USB code a bit, and for that purpose I used a FTDI based USB to serial converter connected to the UART pins. That enables me to see what happens before USB connection kicks in. So much of the time I have two USB connections, one to the microcontroller's USB port (running CDC serial over USB at 12Mbps) while the UART connected to the FTDI chip is running at 115200 bps. The good news is that I got the USB to run the way I wanted.

 

IMG_4343.thumb.jpg.c397d8879049283b25662cef2d169d5d.jpg

 

There are two simple command shells running on the StrangeCart, they are accessible via the USB connection. I use a Mac OS terminal program called Serial as terminal emulator. Below is a screen capture listing the single character commands (shell #1). Most of these are for debugging and not meaningful for much longer. Pressing space takes me to the command interpreter (shell #2). This command interpreter is a simple line editor with history memory of the last 16 commands. I originally wrote it in C for the TMS9995 based minicortex board, but ported it now over to the StrangeCart.2124800271_Screenshot2021-05-06at20_23_23.thumb.png.d58ad3e80f04509f38dbb4ecee8d296e.png

The listing at the end is the output of the command "L", to list content of serial Flash. Now the 16 megabyte serial flash chip is used to store cartridges and other files. I wrote a simple flash image creator program (in C++) which is used to create a binary file containing one or more cartridge images or other files. The final binary image is sent to the strangecart using the XMODEM protocol. The firmware programs it into the serial flash. 

 

As you might expect, the file format is proprietary (because of cause the world needs another file system). The format is simple, there is a 64 byte header containing the name of the cartridge (or file) and then fields which indicate what sort of stuff the cartridge has in it, followed by that very stuff, and finally some padding to make each entry size a multiple of 4k.

 

Currently the cartridge can be simply a file, in which case it just a stream of bytes, or it can contain TI-99/4A cartridge contents: ROM, GROM, System GROM replacement, and accompanying ARM Cortex M4 code. The current version of cartridge loader just loads the stuff into the processors RAM. I did quite a bit of work to rearrange the memory map of the processor (i.e. GCC linker configuration and other similar stuff), and there is now a contiguous 148K region of RAM where the contents are loaded. The strangecart firmware then feeds the data from RAM to the TMS9900 as required by the cartridge functions. The cartridge format also supports some flags, such as marking a cartridge to be the Mini Memory module, in which case the top 4K of ROM will actually be RAM. Although a cartridge image can now contain also related ARM code, I haven't yet implemented the activation of that code - since that requires writing another GCC linker script. But the idea is that cartridge memory images can indeed contain ARM code associated with the cartridge, and that code would written in C or C++, and the firmware will not need to be changed to support cartridges with ARM code.

 

I created the custom cartridge file format to be able serve GROM content directly from serial flash, so in future versions GROM contents will not need to be loaded into the CPU's RAM. It may be possible to also serve ROM contents this way, but that will very likely require increasing the CPU clock to the maximum speed, 150MHz, which in turn requires me to back port some code from NXP's newer SDK. I haven't done that yet due to the SDK change. The SPI bus clock also needs to run in that case much faster than the 12MHz I am currently using.

 

Here is the shell script I am currently using to create the example contents of the flash chip. The flash image creator program is called multiple times, first it creates the desired image file, and subsequent activations have the "-append" flag which just adds the new cartridge image to the end.

Spoiler
[email protected] strangecart % cat build-flash-image.sh
#!/bin/bash
# EP 2021-04-30
# Create the rom images into a merged file.

./flash_creator -name "TI Invaders"         -out flash_image.bin -rom roms/TI-InvaC.Bin -grom roms/TI-InvaG.Bin -gshrink
./flash_creator -name "Parsec"      -append -out flash_image.bin -rom roms/PARSECC.BIN  -grom roms/PARSECG.BIN
./flash_creator -name "Car Wars"    -append -out flash_image.bin -grom roms/CarWarsG.Bin -gshrink
./flash_creator -name "Defender"    -append -out flash_image.bin -rom roms/Defender.C.bin
./flash_creator -name "Mini Memory" -append -out flash_image.bin -grom roms/MiniMemG.Bin -rom roms/MiniMemC.Bin -gshrink -minimem
cat roms/TIExtC.Bin roms/TIExtD.Bin > roms/TIExtC16K.Bin
./flash_creator -name "TI Extended Basic" -append -out flash_image.bin -grom roms/TIExtG.Bin -rom roms/TIExtC16K.Bin
./flash_creator -name "Raycaster"   -append -out flash_image.bin -rom roms/raycaster8.bin
./flash_creator -name "Zaxxon"      -append -out flash_image.bin -rom roms/zaxxon8.bin
./flash_creator -name "Modifed system GROM" -append -out flash_image.bin -sysgrom roms/sysgrom.bin
./flash_creator -name "Cortex Basic 80 columns" -append -out flash_image.bin -rom roms/cortex80.bin
cat roms/RXBC.Bin roms/RXBD.Bin > roms/RXB16K.Bin
./flash_creator -name "Rich Extended Basic" -append -out flash_image.bin -rom roms/RXB16K.Bin -grom roms/RXBG.Bin
./flash_creator -name "Munch Man"   -append -out flash_image.bin -rom roms/MunchMnC.Bin -grom roms/MunchMnG.Bin -gshrink
./flash_creator -name "Alpiner"     -append -out flash_image.bin -rom roms/ALPINERC.Bin -grom roms/ALPINERG.Bin -gshrink

 

 

And this is how the output of the script looks like:

Spoiler
[email protected] strangecart % source build-flash-image.sh
Generating cartridge (TI Invaders): (roms/TI-InvaG.Bin read 8192 bytes) (roms/TI-InvaC.Bin read 8192 bytes) Shrinking GROM from 8192 to 6144 bytes.
Destination size 16384

Generating cartridge (Parsec): (roms/PARSECG.BIN read 24576 bytes) (roms/PARSECC.BIN read 8192 bytes)
Destination size 36864

Generating cartridge (Car Wars): (roms/CarWarsG.Bin read 8192 bytes) Shrinking GROM from 8192 to 6144 bytes.
Destination size 8192

Generating cartridge (Defender): (roms/Defender.C.bin read 8192 bytes)
Destination size 12288

Generating cartridge (Mini Memory): (roms/MiniMemG.Bin read 8192 bytes) (roms/MiniMemC.Bin read 8192 bytes) Shrinking GROM from 8192 to 6144 bytes.
Destination size 16384

Generating cartridge (TI Extended Basic): (roms/TIExtG.Bin read 32768 bytes) (roms/TIExtC16K.Bin read 16384 bytes)
Destination size 53248

Generating cartridge (Raycaster): (roms/raycaster8.bin read 32768 bytes)
Destination size 36864

Generating cartridge (Zaxxon): (roms/zaxxon8.bin read 65536 bytes)
Destination size 69632

Generating cartridge (Modifed system GROM): (roms/sysgrom.bin read 24576 bytes)
Destination size 28672

Generating cartridge (Cortex Basic 80 columns): (roms/cortex80.bin read 32768 bytes)
Destination size 36864

Generating cartridge (Rich Extended Basic): (roms/RXBG.Bin read 40960 bytes) (roms/RXB16K.Bin read 16384 bytes)
Destination size 61440

Generating cartridge (Munch Man): (roms/MunchMnG.Bin read 8192 bytes) (roms/MunchMnC.Bin read 8192 bytes) Shrinking GROM from 8192 to 6144 bytes.
Destination size 16384

Generating cartridge (Alpiner): (roms/ALPINERG.Bin read 32768 bytes) (roms/ALPINERC.Bin read 8192 bytes) Shrinking GROM from 32

 

 

So there is quite a bit progress (or at least more firmware code and time sunk into the project), but still a lot remains to be done. But it is getting there.

 

  • Like 9

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...