Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by speccery

  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.
  16. If I counted correctly it would seem there is interest for 7 boards at this point. I am glad to see that. Good to keep in mind that I consider all of these boards being prototypes. The V1 prototypes have only been tested on two of my consoles, so more testing definitely needed. I don't know if the StrangeCart somehow interferes with other peripherals. It shouldn't, but I have only tested it with ET-PEB boards. Those two work fine together. The limiting component for builds at the moment is the MCU, which is in short supply. I think I have around 15 of them in stock at the moment. The PCB order should come in today, there are 10 boards. The new revision is of course untested at this point. Getting more PCBs is easy, once I know the boards work.
  17. This is sort of what my test software does already: the ARM core draws some test graphics, generates code for the TMS9900 to load the graphics into VDP memory, alerts the TMS9900 that code is ready. The TMS9900 starts to write stuff to VDP memory, and the ARM renders the next frame in parallel. From the ARM's point of view the TMS9900 takes ages to write the stuff, so it has plenty of time. The TMS9900 code is basically a long string of "load workspace register immediate" instructions, with the workspace pointing to the VDP. In the time each LI instruction executes (24 clocks at 3MHz i.e. 8 microseconds) the ARM core can run up to 768 instructions, in practice somewhat less than that (due to flash memory wait states and some instructions taking more than 1 cycle). Once the TMS9900 is done with the VDP memory writes (basically it reaches the end of cartridge ROM area), it writes to a magic memory location, and the ARM generates another 7.5K bytes of instructions for it. Once that's done, the TMS9900 is signalled to execute the next batch, and os it goes. This could be done with bank switching, but the ARM generates the 7.5K of code so quickly that in my initial tests the TMS9900 code only runs about 2% slower as it is waiting for the ARM to do its thing. This is quite a difference, since the TMS9900 only executes the simplest of instructions, the LI instruction, while the ARM has to do quite bit of computation to transform the frame buffer in its memory into a TMS9900 instruction stream.
  18. Thanks, I'm looking to hand build the first batch which could be good enough for first testers. I wonder what is the level of interest, how many people would be interested... Currently one problem in general is that many chips are in really short supply. If there is some demand, I probably need to order all the chips Mouser has in stock, they only have 12 of them...
  19. I've been doing some testing, measuring the VDP write bandwidth with StrangeCart generated data. It appears that doing LI R1,data instructions with workspace pointer set at VDP >8C00 only gives me about 127 kbytes per second of bandwidth to the VDP. At 3MHz this would be about 23.5 clock cycles per LI execution. Does this seem right? The instructions are in cartridge ROM area, so we're talking slow accesses. I should verify the measurements with oscilloscope, currently I've just looked at the timer of the MCU. The half cycle in 23.5 is probably just some measurement error or other overhead. Each LI R1,data only writes one byte to the VDP, since the VDP is a 8-bit device only connected to the upper half of the 16-bit data bus. According to Thierry's tech pages the LI instruction in ideal circumstances takes 12 clocks and has three memory accesses - I assume them to be opcode fetch, immediate operand fetch and write to workspace. Out of those three accesses the two fetches occur over 8-bit bus, the last write to workspace is to the VDP and should go at maximum speed. According to Thierry's pages the 8-bit bus accesses require 4 additional clocks, which would mean 12+4+4=20 cycles. So in that case I'm not too far off... and the max speed even with nothing else than LI instructions is quite slow. Well I guess 127kbytes per second is not bad for the 99/4A. I need to hook up the oscilloscope to check the bus activity, hopefully tomorrow.
  20. The processor is a cortex M4 running currently at 96MHz. It achieves about 125 drystone MIPS. I would say that in integer operations it is 1000 times faster than the TMS9900, and those are 32 bit integers. It has a hardware floating point unit, enabling it to perform single cycle floating point (single precision) operations. Thus if single precision floating point is all you need, and it is enough for many things, it will perform those pretty much as fast as integer operations. Compared to the TMS9900 it is a rocket. It also support DSP operations, enabling it to compute for example four 8-bit saturating adds per cycle, or to compute multiply accumulate operations in single cycle. Since the board plugs to the cartridge port, it appears to the TMS9900 as a 8K range of memory. It cannot access 32K extension. If you wanted to do vector graphics, the way I would do it is that I would render the graphics in on-chip RAM first and then construct a series of LI instructions for the TMS9900 so that workspace is set to VDP write address. This TMS9900 instruction stream would reside in the cartridge memory area. While the TMS9900 is running that, I.e. writing to VDP memory, the cortex M4 would render the next frame. The microcontroller can simultaneously serve the TMS9900 CPU bus and do other things such as render graphics, since there are two processor cores. The cartridge is affordable, the component cost is probably around 10-15 EUR, excluding case. of course assembling the board will also cost something. But cost wise it probably is similar to a multi bank ROM cartridge. Cost can be less if cost optimized. The board can support multiple games too, of course depending on the memory needs of a game. The new version will have 16 megabytes of Flash ROM.
  21. Looks like I might be receiving the new boards from manufacturing early next week, perhaps even on Monday. In anticipation to that, I did some development and tested a feature @dhe asked in this thread approximately one year ago: whether it would be possible to override the console GROMs using the StrangeCart? The answer is yes, as the picture below shows... The StrangeCart is overriding all of the system GROMs, with 24K of GROM content (6K unused). This is my development computer, it has F18A installed and StrangeCart in the cartridge port. No other peripherals connected, nothing in the expansion bus. I loaded a modified version of system GROMs into the StrangeCart (just text changes). The new version PCBs will support additional Flash memory, which enables much more content to be loaded, especially GROM content. The on-chip flash image on the microcontroller is now using nearly all of flash memory when storing firmware for the processors as well as ROMs and GROMs for Invaders, Extended Basic, Mini Memory, Parsec, Car wars, two 8K test cartridges, 24K of system GROM override and finally @Asmusr's cool Zaxxon demo (64K cartridge). Thus the current firmware feature set includes: - Cartridge ROM emulation (paging supported) - Cartridge GROM emulation - Mini Memory emulation (ROM, GROM, RAM) - System GROM override - Execution of cartridge ROM TMS9900 code dynamically generated by the ARM core on the fly, with a synchronisation system enabling the ARM core to know when the TMS9900 reaches a certain point in the code. This enables the TMS9900 to write data to the VDP with maximum bandwidth. V2 PCB, if working, enables me to move all ROM and GROM code over to the additional flash chip, leaving a lot of space for firmware development. Oh, and I found some old code of mine: I started to write a Basic interpreter in C back in 1999. I revived that code (a couple of thousand lines of C), and have the interpreter working on my Mac. It's still the beginning and missing a lot of features, but once I have a meaningful amount of functionality I will port that to the StrangeCart and write a simple I/O library for the TMS9900. Then we should have a very fast Basic
  22. I don't know why but my projects seem to go in cycles, almost exactly in 1 year cycles in this case. I just finished designing second version of the StrangeCart. This PCB design took many times longer than I expected. This was for me also a bit educational, I tested several things I haven't tried before, mainly much narrower traces and smaller vias. I had serious feature creep, but finally cut down several things to make the design process come to an end. I attach a screen capture from Cuprum, a Gerber file viewer of the final board. I sent the board to manufacturing, it's currently waiting for audit. I decided to test PCBWay for the first time, it will be interesting to see how it goes. The main changes of the board, compared to the first version, are: A completely rerouted design. Nearly all components now on the top side, just a few passives on the other side. Fixed the location of the cartridge hole, I made a mistake in the first design. Fixed font size for silkscreen labels, and added much more information on the silkscreen Added SWD debug connector for the MCU. 10 pin SMD connector with 1.27mm pitch. Added serial flash chip for additional storage. I am going to populate prototypes with 16 megabyte flash chips. Changed buttons to be through hole type, which should enable them to be accessible when mounted inside a cartridge box Since I had some space, I added some prototyping stuff which are optional and not really relevant for TI-99/4A but may be useful for other use cases: place for 1.2V regulator (or any other voltage, 1.2V relevant for FPGA prototyping) and two transistor buffers to enable the euro rack trigger or gate signals be processed (will accept -12V to 12V range digital inputs) The main motivation for the redesign was to have the SWD connector. I also wanted to have the the MCU on the topside, making the boards faster to build. I realised that using NXP's MCUxpresso toolchain I can clock the MCU at 150MHz, which is of course much higher than the 96MHz I previously used, making the timing of the bus interface better. More important than raw clock speed, MCUxpresso connected via SWD enables much easier debugging with hardware breakpoints. There is also now a connector for SPI interface, which could for many things, for example connecting to Gameduino or to a SD card. While placing an order for the components, I have noticed that many semiconductors are out of stock. I have many ideas for add-ons, and eventually did find some interesting chips in stock for future boards. Now that I'm up to speed again with PCB design (assuming this comes out well from manufacturing) I am planning to continue and do a few more designs shortly 🙂
  • Create New...