Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1,043 Excellent

About speccery

  • Rank

Recent Profile Visitors

4,634 profile views
  1. 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. 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. 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. And this is how the output of the script looks like: 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.
  2. A simple question: what is the SuperCart? Just wondering if it is something I can build into the StrangeCart... If it is paged RAM, should be simple
  3. 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). - 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.
  4. 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.
  5. speccery

    StrangeCart TI-99/4A

    My long overdue project of building a new powerful single-chip cartridge for the TI-99/4A
  6. 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.
  7. For example here: CoreForth Cortex M4 is a superset of M3.
  8. 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.
  9. 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.
  10. Got a good question about the test/prototype nature of the board, and whether there would be a "final" version of the board, I thought I share my answer with everyone interested: I spoke about test version or prototype, because the board has only been tested by me in very limited hardware environments. There's a possibility it's not compatible with something important, such as the normal PEB. If during more extensive testing - done by others independently from me - compatibility issues requiring hardware changes do not arise, this can be the final version. There are two features which could be nice to have: SD card support and audio DAC. But there are connectors (well holes in the PCB for a pin header 🙂) for both, so they can be added to this version already. For the sake of simplicity I'd like to keep this board quite plain, it actually makes the thing more versatile. If for instance audio DAC is included, it means that some of the now free pins will be spoken for, and that may limit other experimentation. No promises for further development though... Regarding RAM capacity: The MCU has 192K of RAM. Some of that is needed for housekeeping tasks, but I could imagine a Basic with 128K of free RAM.
  11. Built first V2 board and did some quick firmware modifications to support the new board. It worked straight out the bat, as far as I tested. Zaxxon demo ran as beautifully as ever. I need to work on the firmware to support the flash chip; having that there enables so many things. I spent at almost 3 hours building it, since I wanted to try out the stencil I ordered, but it really just slowed me down. I think the solder paste I had was old, and at the end of it I had to resolder many components since the paste was all over the place. I also soldered the MCU again. I don't have reflow oven, so it was just a frustrating experience with the SMD hot air gun. One design error is that the SWD debug connector (top right hand corner) is too close to the reset button, so I needed to mount a flat button as the debug cable connector was surprisingly wide. I am not planning to include the connector anyway on all boards, since it's not really needed. I haven't tested the SWD connector on the board yet, just flashed the MCU through the USB port.
  12. Yes should not be a problem. I am in the process of acquiring more components, so hopefully the chip supply will not be a problem.
  13. The PCBs arrived yesterday evening, at the last hour of delivery. I was eager to start building, but no energy left at that point. Instead I just used a multimeter to check the board. At least everything is not shorted and this PCB fits into a cartridge case nicely! My silkscreen design job is far from perfect, but much better than with the previous boards.
  14. Yes that should be fine. I did some recalculation of the BOM, the range I provided before was lacking the PCB price and VAT I needed to pay for the parts. I think I will set the price of the prototypes / first batch to around 50 EUR each + shipping. That would enable me to recoup the price of the components and prototype boards. I can't really put a price on the manual assembly and testing work, otherwise the price becomes stupid.
  15. thanks for the comments. I have actually written video encoders and decoders in my past jobs. Real-time encoders for MPEG-4 for instance... running a video decoder could be fun, but it would require a custom codec. The thought of emulation did cross my mind too, I was actually thinking about the spectrum and also CP/M as options. The VDP memory bandwidth is low compared to the Spectrum, but it could be done. There are many possibilities, but need to think about the software architecture and keep the project scope from becoming too big.
  • Create New...