Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by speccery

  1. Thanks Lee! Need to take a look at this, but not now as it is late here where I live. And thanks to all the other responses by others as well! It is a shame that TI left this half baked on their part. Not that I like GPL, but it is part of what makes the 99/4A what it is, part of it’s character. One more thing to fix if we ever get to building the TI-99/4A Next 🙂
  2. I have written the SD card DSR for my ET-PEB board (and before that for the FPGA system). I suppose that has been the 'easy' part. The receiving end of a DSR is just parsing the PAB, and trying to do the right thing. My DSR does not properly deal with all the weird single character named DSR routines (named hex 10 to hex 16) for sector I/O. But calling the DSRs is another matter. A related matter is that I still don't know how to call machine code from GPL, or vice versa, and this is something I should learn at some point rather soon. If I have understood correctly, all the various DSRLNK routines are simple header walking routines, resolving a string to an address. If the address is in ROM, it's all good to go and ready for a branch to that address, but if it is a GROM address I suspect some setup is needed for scratchpad variables before jumping to somewhere in ROM to start the GPL interpreter. And I don't know how to return from there.
  3. Well GROM support is already there, in fact my current prototype software houses GROM code for 3 separate cartridges. Among the directions StrangeCart could take is interpreting GPL by the CPU on the cartridge.
  4. Switching gears to another topic, I read through some of the source code for the Mini Memory module. One thing I learned is that apparently it is possible to implement DSRs in cartridges. I guess it should have been obvious, but I was somehow thinking that they're linked to the expansion bus and enabled with CRU bits in an address space not available in the cartridge slot. As most people reading this probably already know, the cartridge slot only presents 13 address lines and a chip select signal for the address range >6000..>7FFF. Thus it is not possible to have a DSR in this address space, if it would have to appear in the range >4000..>5FFF, where the CRU bits are used to page in the ROMS for different devices. Anyway, Mini Memory does implement DSRs, and it even does that in GPL code. I have never written any GPL, but reading parts of the mini memory source was pretty straightforward - actually a good starting point for GPL. What I learned (and should have realised before) is that the mini memory save/load mechanism uses the standard DSR interface and you indeed can do it with a cartridge. So that means that the StrangeCart could easily have filesystem support as well. So with that out of the way, I am thinking about something like this: you write a Basic program, and save it on the strangecart. Then you could ask the StrangeCart to run it, on behalf of the ordinary Basic interpreter. And you would go very fast.
  5. Thanks, makes sense. My current code assumes 6K GROMs (to conserve flash space) but switching to 8K GROMs is a no brainer and will actually speed up the code slightly.' Yes, it could run the P-system. I was not familiar with p-code, but after a very quick read about the P-code architecture that should not be a problem. Of course it would require writing a P-code interpreter in C. I am sure those must already exist, so it would be a porting job.
  6. Sorry I missed your message. I am not familiar with override, do you mean 1 - replacing the console GROM content (by pulling them out and using the board to provide alternative GROM content) or 2 - I seem to have read from somewhere that GROMs have weak output drivers and another chip could drive the data bus simultaneously, effectively overriding GROM content. If it is option 2 you have in mind, I have not tested this and don't know if the drivers on the microcontroller are strong enough on the pins I am using for data bus. The chip is operating at 3.3V, which may further limit the drive capability if it needs to "fight" against other chips. For option 1, the current version of the board does not handle the GREADY signal, although that could easily be wired to one of the spare headers. With that setup the StrangeCart could replace all GROMs. I am curious what content you have in mind for replacement GROMs? Has somebody worked on a new version? Or just to use old GROM code with the version 2.2 systems to support ROM only cartridges?
  7. Something plugged into the cartridge port cannot replace the functionality of the built-in VDP. As mentioned by @OLD CS1 above the signals are not there. I am not sure what you're looking for. For better video functionality, the options are F18A, F18A Mk2, or just replacing the entire computer with a FPGA chip. My Icy99 design supports digital video output on some of the FPGA boards I use for development (this project is not complete yet). The MiSTer port of my EP994A core is also one option. An add on device could provide an auxiliary display, but then we would need software support. In fact StrangeCart supports a very limited version of this, there is a pin header for a small 128x64 OLED display. I have used these displays in the past as status indicators, and was planning to do the same here. The connection is via I2C bus, which is a slow bus for video content.
  8. Not much - there is a lot of space for all kinds of add ons. I will definitely be using the extra space at some point, I have many ideas for that. By the way, since this is essentially a single chip thing, it could also be attached to the side expansion bus, with a very small PCB. Of course the same applies for the cartridge. Without all the expansion headers and other extra stuff the PCB could be a lot smaller. The package is a 64-pin LQFP. Makes for a nice and simple build.
  9. speccery

    StrangeCart TI-99/4A

    My long overdue project of building a new powerful single-chip cartridge for the TI-99/4A
  10. From the album: StrangeCart TI-99/4A

    This is where all the action happens :)
  11. A quick update: got Mini Memory support working. Thus now StrangeCart provides ROM, GROM and RAM. Not much testing, but I was able to save and load BASIC code to the mini memory. I powered off the 99/4A while providing power to StrangeCart over USB, and after powering on the 99/4A I was able to load the Basic program back. I dumped the saved basic program bytes to a serial console, and spent a while in trying to understand what they are. Using Thierry's 99/4A tech pages it appears that when doing "save MINIMEM.test" and looking at the bytes which got written to >7000, I have: >7000..>7007: the mini memory file header >7008..>700F: 8 mysterious bytes, part of the Basic program. It appears there are 4 words, here, one being a count of something, followed by three pointers in VDP memory, perhaps location of line number table before saving. >7010.. Line number table of basic code, stored in memory in reverse order, highest numbered line first. The first word is the line number, then another word which is a pointer to the Basic code for that line. Thus 4 bytes per line, first line last in the line number table. My test program had 4 lines, so the line number table had 16 bytes. This leads us to: >7020.. Finally the Basic program in reverse order, last line stored in the lowest memory address, in tokenised format. I suppose I could add support for flashing the contents of the 4K RAM section of mini memory to the MCU's flash memory, to make the RAM persistent.
  12. Nice! I should take a look at this too. I have acquired the parts for a MiSTer build - gosh I don't even remember when, I guess it was last year - but haven't gotten around putting this together. I guess it would be about time. In the meantime I have ported the code base to Verilog and I have cleaned up the design a little, I have now had a pause in the development but I was using three different boards for testing. One Xilinx boards and two Lattice ECP5 boards. On Xilinx I used ISE 14.7 but on the ECP5 boards the open source Icestrom toolchain.
  13. I am glad you are interested. To your question on cost, I haven't calculated the cost of BOM but it is probably below USD 20 even in small quantities. When I bought the components for prototypes I bought also other materials simultaneously, and instead of buying for example only something like 5 resistors actually needed (of a given resistance) I usually buy a hundred. I can build a prototype board for you and send it over, if you cover the shipping costs and materials, something like that. For the audio part, my thought process was something like this: it would be cool to provide enhanced audio capabilities, and since this cartridge would also contain the content (i.e. game), the original audio could be just replaced with audio generated by the board. Thus one could modify the binary of the content, to for instance perform writes somewhere in the address space of the cartridge, and then have the processors on the cartridge pick up that information and generate the appropriate audio response. I already did something like this with my ET-PEB, where it captured writes to >8400 and mapped that information to MIDI notes passed to an external synthesizer.
  14. Thanks! I think it still remains to be seen, once the "standard" features are there (ROM, RAM, GROM support). A clear use case is to emulate old cartridges. The software running on the StrangeCart is written in C or C++, so development for this platform is fast. One of my original ideas was to create a Basic implementation, which would run fast enough to enable creation of sophisticated software in Basic. That might be attractive to people here. Basic code running on the StrangeCart could use probably at least 128K of RAM, so one would have much more space to work with. If that basic was compatible with extended basic, one could take existing software and just run it on the cartridge faster. Its worth noting that this version of the board is a prototype, I may amend future versions with more low-cost features. The header J4 breaks out an I2S bus, in a pinout compatible with Adafruit I2S Stereo DAC. I have tested these DAC boards with other microcontrollers, but haven't written drivers yet for the StrangeCart. Adding the DAC gives you stereo 16-bit (or even 24-bit) 48kHz audio. My other use case for this board (with or without the TI-99/4A) is implementation of software synthesisers.
  15. Not really. FinalGrom supports larger cartridge images and does well what it is designed to do. This design is in some sense a simpler single-chip version of my ET-PEB, but adapted for the cartridge port. I was planning to have on the same board also the side connector, but decided to drop that since it would have meant a four layer board and it would have taken more time than I wanted to spend at this time.
  16. I finally got around building my first TI-99/4A cartridge, the StrangeCart. My intention was to introduce this only after I have created a demo for it, but since I don't know when I have the time to do that, I will just go ahead and tell about it now. I actually already posted some picture in facebook a few days ago, but at that moment not much was working. This is effectively a modern single chip cartridge for the TI-99/4A. It can eventually act as ROM, GROM, RAM and a ton of other things. I have tested so far only little and I am implementing new functionality as I go. So far I have used it to to provide ROM and GROM and tested it with: Invaders Extended Basic asmusr's raycaster. It can host all of them at the same time (i.e. there is enough storage for multiple cartridge images even without any storage device). (story continues after the pictures below) The PCB design did not really go according to plan: the mounting hole is in the wrong place, the pin headers are too far back to fit into the module bay. The silk screen text is all over the place, some fonts are so small that you can just see a blob next to a component. But that doesn't really matter, since the main thing is that it works. I wanted to keep the PCB design very simple, since I am manually building these. Even if I want to build boards with complex FPGA chips, there is still merit in keeping thins super simple. The main action happens on the underside of the board, where a LPC54114 microcontroller implements all the functions. It is the only component on the underside. The microcontroller has two ARM processor cores: one Cortex M0+ core and one Cortex M4F core. I am running them at 96 MHz. In my opinion the really cool thing about this setup and my proof-of-concept software is that the less powerful M0+ core alone is sufficient to serve the bus of the TI-99/4A in real time, leaving the M4F core free for other things. The two cores can communicate via shared memory. Think about running a native code basic interpreter on the StrangeCart, providing something like 1000x performance over extended Basic. Or to say it differently, the raw processing power here is more than 5x of gameboy advance. Plus it has hardware floating point support... The microcontroller chip has 256K of Flash memory and 192K of RAM. Due to these capabilities the board has a bunch of extension headers: if one brings in extra address lines from the expansion connector, the StrangeCart could also implement memory expansion and mass storage expansion. I have provided header pads for the signals which are only present on the expansion connector. The most difficult bit in this has been setting up the software properly so that both cores operate properly and the toolchain works. These chips are very complex, with a huge amount of on-chip peripherals. Still, the "bus server" program running on the M0 core is less than 4K bytes in size. I have setup things so that the M4F is the master processor, it configures everything and then boots the M0. The M0 is running from RAM for maximum performance, with interrupts disabled. My plan is to implement support for the mini memory cartridge, before moving to testing things with parallel processing.
  17. This really a cool project, thanks asmusr for working on this and congrats of making it work! Incidentally it also is a pretty much perfect test platform my new project, the StrangeCart cartridge for the TI-99/4A. This is something I wanted to try out for ages, but got around of implementing it only now. Here I have my TI-99/4A running your raycaster from the StrangeCart cartridge. 32k RAM expansion is provided by ET-PEB. The USB cables are used for debugging the cartridge and not needed to run.
  18. speccery


    From the album: StrangeCart TI-99/4A

    Topside of the PCB.
  19. From the album: StrangeCart TI-99/4A

    Asmusr's raycaster running on the StrangeCart.
  20. No I don’t; I’ve been just building existing designs so far. I am planning to design my own module next. I’m currently traveling but listing what I remember - I have so far built two kits (manhattan audio mixer, Erica synths input module) and a bunch of modules where I got the PCBs and panels from a few sources, and then got components from mouser and thonk.co.uk. These include mutable instruments clouds, mutable instruments tides, as well ornament & crime (I have built two of them, one full size and one micro). Oh and then I also built the Ardcore, which is basically an euro rack Arduino. On that one I should have checked the schematics a bit closer before deciding to build the module, it is a pretty inflexible design - and I dare to say I could have designed a much better one myself. A fair amount of SMD component work with the mutable instruments modules and ornament & crime, but fun builds. All of them have worked the first time I powered them on (and flashed firmware). Good luck for your build! I am interested in hearing how it went. What are you building?
  21. Me and pnr had a few threads a couple of years ago talking about TMS99105 and TMS99110. If I recall properly we did also talk about sourcing TMS99110 chips. One of the interesting results was that some TMS99105 chips actually turned out to be TMS99110 chips, i.e. they had the floating point macrostore ROMs. I haven't played around with my TMS99105 chips for a while, but I think I have three of them and one is actually a TMS99110. You may already know, but I built a TI-99/4A clone using a TMS99105 and a FPGA chip: My TMS99105 project on hackaday.io Here are the links to threads on this forum: TMS99110 ROM disassembly discussion Musings on 99000 macro code
  22. A quick update: I haven't had lately much time to work on this project, but I haven't dropped it and will continue. Since I last posted I ported the design over to the ULX3S board (thanks go to pnr for the recommendation). This board has a HDMI connector and that works nicely, thanks to pnr's HDMI driver module. One of the next steps here would be the inclusion of SDRAM controller, so that the system could support the 1M AMS RAM memory space. One of my other hobbies is building Eurorack music synthesizer modules, these compete for time with TI-99/4A projects. Need to find a way to combine these two...
  23. It’s been a while, so I thought I’ll drop an update. I have gotten to the point where my Verilog design has started to work like a TI/994A. One of my design goals was to make the design highly portable, and to that end I’ve been developing on three different FPGA boards more or less simultaneously: BlackIce2 with Lattice ICE40HX FPGA (open source Yosys and Nextpnr-ice40 toolchain) FleaFPGA Ohm with Lattice ECP5 25K FPGA (open source Yosys, project trellis and Nextpnr-ecp5 toolchain) Pepino FPGA which I used in the past already, Xilinx Spartan XC6SLX9 FPGA, Xilinx toolchain Picture of the FleaOhm board. Same form factor as Raspberry Pi, but powered by the ECP5 25F FPGA. It has 32M SDRAM onboard, but my code is not using that yet. I’ve structured the design in a way where the differences between FPGA platforms are isolated to the toplevel module, and I’ve been trying to keep the top level modules minimal. Also, since my primary toolchain has been the open source toolchain, it has forced me to stick to standard Verilog. Thus I’ve been avoiding vendor specific FPGA features - everywhere except at the top level where one really needs chip specific configuration for example for clock generation. Thus with this structure the base TI-99/4A functionality can easily be ported to different architectures, my intention is to port the code to some more boards that I have, including Altera based platforms such as the MIST. The great benefit of the open source toolchain is that the development cycle is very fast, much faster than with for example Xilinx tools. Of course the Xilinx tools are in very many ways more robust and without doubt more reliable, once I got to the point that I could do less simulation and more testing on actual hardware, the speed development cycle becomes iteration. The FleaFPGA Ohm port is interesting in that it has HDMI output. Thanks to work done by @pnr I was able to quickly add HDMI support to that version. In addition to HDMI, the other piece of functionality I have added is PS/2 keyboard support. Currently the Flea FPGA Ohm version is the most advanced, as it has enough block RAM to support all the ROMS, enabling the system to boot directly to a mode where one can use PS/2 keyboard for input and HDMI for output. The PS2 module I also borrowed from pnr's TI-99/2 design, and adapted it to support TI-99/4A. His code is inspired by Grant Searle's VHDL PS2 code - I have in the past used this code as basis for PS2 keyboard support for my ZX Spectrum VHDL implementation. The BlackIce 2 version is interesting in that I also added support for a small 0.96" LCD display, which has a resolution of 96x64 pixels. It display that amount of pixels from the upper left hand corner of the screen (not perfectly aligned yet). Below you can see a Basic test program running on the BlackIce 2, I was testing the colors here. The FPGA board is driving both displays simultaneously. There is still work to be done here, the next major task I am planning to tackle is to have the system boot from SD card, so that the ROM images could be loaded from there. I have in the past written code in TMS9900 assembler to access SD card directly, supporting a small part of FAT16. Unfortunately these days I would need to support SDHC cards and FAT32, so there is programming work ahead to support this. I am planning to jump start the development by ignoring the filesystem altogether, and initially store the content as raw sectors on the SD card. To summarize, so far ported and written new code in Verilog: TMS9900 CPU (port from my VHDL version) TMS9901 parallel interface chip (my new implementation) TMS9918 VDP (based on my VHDL code, but extensively modified, can now use external SRAM for the framebuffer) Multiport memory controller (based on my VHDL code, but revised heavily) Serloader to enable memory initialization and debugging from PC (ported from VHDL) TMS9902 serial interface chip (pnr's code) VGA timing module (very simple) GROM support module (port from my VHDL code) HDMI support (pnr's code) PS2 support (port of pnr's code) 96x64 LCD driver, this is from Link to open tech lab New system level module. To integrate most of the above into a simple module. Combines now has a trace buffer, greatly helping debugging. It enables me to see past 256 memory cycles from a breakpoint. Framebuffer and screen capture logic to drive the optional 96x64 screen New toplevel module for the FleaFPGA Ohm board, integrating on-chip memories (RAM and ROM) as well as HDMI output. New toplevel module for the BlackIce2 board, integrating the 96x64 LCD support New toplevel for the Pepino board A number of Verilog testbenches for the system module, CPU, VDP, memory controller I have also written a bunch of Python utilities to convert files from various formats, and to analyze tracebuffer dumps. Oh, and I also wrote TMS9900 disassembler in C. This is very handy when looking at simulation output, as it can be used as a filter process for the instruction register in GtkWave. Thus a fair bunch of code written and ported. Still more to be written...
  24. Yes it's been a bit on the side. I use the tinypeb with my TI-99/4A whenever I use the actual hardware. I think I have around 7 unpopulated PCBs laying around, as hand assembling the SMD stuff takes a good while. I haven't measured but I believe it takes me around 4 hours to do all the soldering on one of these. There are two issues with the design: the CPLD chip I choose turned out to be too modest, making it hard to fit everything in. I did manage to get it working with 256K SAMS, and this doesn't seem to be what people want, but rather the full 1MB. I've made progress with the Icy99, so more to come.
  • Create New...