Jump to content

speccery

Members
  • Content Count

    427
  • Joined

  • Last visited

Community Reputation

690 Excellent

About speccery

  • Rank
    Moonsweeper

Recent Profile Visitors

4,011 profile views
  1. 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?
  2. 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
  3. 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...
  4. 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...
  5. 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.
  6. I have the MX so I know it’s specs, although I am saving it for later. The current version has problems with its HDMI connector. I did not know that BlackIce II is history - that is a shame, I like that board. Thanks for letting me know, I assumed they would still be available. The BlackIce II thing you’ve made sounds similar to what I did with the Pipistrello 64M memory expansion for the 4A. Have you published your design?
  7. Thanks a lot for these comments and questions! These are really good ones. Regarding the choice of FPGA board. For this second design, I really wanted to try out the open source tool chain, and since that only support Lattice chips, I am stuck with those. However, there are important implications: Since the ICE40HX chips are primitive in FPGA standards, the design work that I have done now includes almost no platform dependent code. As an example, the multiplier is now implemented in verilog. That means that this second version of the design is very portable. I plan to implement this version of the design on multiple FPGA boards. I have now a whole bunch of FPGA boards (too many in fact, I don’t know how many), including MIST and MISTer. Of these I have not even powered on the MISTer yet... Even though I am working with FPGAs which by definition are new and not retro, I think it still is somehow in the spirit of retro computers to try to use a solution with limited resources. The MISTer is very cool but has huge resources compared to what a complete and expanded TI-99/4A needs. I admit that this point is a bit philosophical, but this work is more interesting for me if I learn and get challenged along the way, rather than just porting the same stuff over and over again. And yes, I want to make this standalone. My previous design already can run in standalone mode, but it required help from a microcontroller board. I have implemented a version of file system support, which supports storing TI files in a FAT file system. Since my last message I have added GROM support, but there is currently a bug which only shows up when running on hardware, in simulation it works perfectly as far as I can tell. So limited progress but still some progress. Finally, in the spirit of going simple, for this design I removed the cache and I plan to also make a cycle accurate version of the TMS9900 CPU. My original aspiration was to make my “dream TI” as in making a TI-99/4A that can go very fast, and got reasonably close to that already with 30x original speed and beyond. Having done that I realize that I also want go slow, close to original speed.
  8. Yes, I am aware of the Mx and in fact I have one. I just started to work with the Blackice II, for two reasons: I have several of them, and working with SRAM is easier than SDRAM. Having said that, I have ported an earlier design of mine to a cheap Xilinx board with SDRAM. That design uses SDRAM but comprises of the TMS9900 and UART only, it is my test bed for SDRAM work.
  9. Again it's been a long while since I wrote anything here... I thought to write a short update about my work on my new FPGA version of the TI-99/4A. This is work in progress. In short, I'm in the process of creating a version for the Blackice-II FPGA board. This is an affordable board (I hope it is still available) with a fairly small ICE40HX4K FPGA chip, 512K RAM and a fairly powerful microcontroller. The board is supported by the open source Icestorm toolchain, and I have used that for development work. This has been an interesting adventure so far. Icestorm very nice and compact toolchain compared to the bloated Xilinx and Altera tools. However, Icestorm only supports the Verilog hardware description language, so I had to learn Verilog and port my existing VHDL code base to Verilog. Most of the work so far (and I have but a fair amount of hours into this already) has gone to porting and modifying the code to work on this fairly limited platform, changing the language to Verilog and designing around the limitations. In the context of recreating the TI-99/4A the biggest drawback is that the small FPGA only has 16K of internal RAM (compared to 64K on the chip I used for the VHDL version). Also, the internal RAM is a lot less sophisticated. The result has been that I have had to redesign the system architecture quite a bit, so that the external 512K RAM chip is now used for code, data and video memory - as opposed to using on-chip RAM for video memory in the past. This may seem like a small change, and in a way it is, but in practice I had to design a much more involved memory controller which can arbitrate between CPU, VDP, and the bootloader accesses in real time. Although I have converted my whole code base to Verilog, currently only a portion of this has been fully ported and works. Namely I have a system now that has the TMS9900 CPU, TMS9918 VDP with VGA output, memory controller driving the external RAM, EVM-BUG debugger in a 8K ROM block, and finally pnr's TMS9902 UART. The ICE40HX4K chip is only supposed to have 4K LUTs (look up tables), but in practice the silicon is the same as ICE40HX8K with 7680 LUTs and the Icestorm toolchain enables access to all of them. Which is good, since the design already uses 4421 LUTs. The design runs at 25MHz, which is the VGA pixel clock. I am hoping I can fit in the whole thing into this FPGA. As the chip's resources gets close to full utilization the routing probably becomes impossible, so I cannot add too much more. I don't know yet where the limit is. One of the consequences of having the VDP use external RAM is that it now is possible to map video RAM to CPU's address space directly, and that is what I have done during debugging (I'm not yet using TI-99/4A ROMs, just EVMBUG). There are now two ways to access VRAM: using the standard indirect registers - this is obviously necessary for compatibility, and alternatively by just directly mapping it to CPU address space. Direct access to VRAM vastly increases the bandwidth and makes it very easy to use, but of course no existing software supports this... Next I need to add GROM support, which should be easy. When that is in place I should be able to boot this thing with the TI-99/4A ROMs. I still need to figure out how to split the 512K RAM between different functions, probably something like this: 8K system ROM (0000..1FFF) 8K disk support (4000..5FFF) 256K paged cartridge space (6000..7FFF) 64K GROM space (24K used by console GROM [actually 18K but multiplies of 2 are easier]) 64K VRAM space 32K normal RAM expansion That leaves 80K still to be allocated to something. If I can fit in my memory paging unit, it probably would make sense to have the ability to configure either 256K AMS memory space or 256K cartridge space.
  10. Very nice, good job adamantyr! I am hoping I'll find some time to hack something together too. This is such a delight
  11. Sorry for the long delay in answering. I have not tested to synthesise the plain vanilla TMS9900 core without any peripherals. Looking into one of the breadboard project targets on my GitHub account https://github.com/Speccery/breadboard/blob/master/bb-lx9/work/system_summary.html you can see that a minimal TMS9900 system took 1690 Xilinx Spartan 6 slice LUTs, or 29% of the XC6SLX9 chip. This system includes the TMS9900 core, 32K RAM, 32K ROM, and PNR's TMS9902 UART, all implemented using the FPGA's built-in resources. In a way this number is comparable to the 1072 logic cells for the J1 as that system also includes memory interface, some I/O and UART. However, the Spartan 6 logic core elements are much more advanced than what the Lattice ICE40HX provides, so the numbers 1690 vs 1072 are not directly comparable.
  12. The J1 implements its stacks as two huge shift registers, where each shift operation is a shift by word length, typically 16 or 32 bits. The stacks are not deep, they're for the 16-bit version by default 15 deep for data stack and 17 for the return stack. So these stacks are implemented in the FPGA logic fabric, not in block memory. This also means that there are no stack pointers, at least for the J1A version. So you don't know how deep you're in the stacks... The source code for J1A is about 130 lines of Verilog. It is tiny. It is inspired by the Novic NC4016 to my understanding. The J1 is an awesome project, and it comes with Swapforth already implemented. The basic J1 system for the BlackIce takes 1072 logic cells, so about one eight of the total capacity. It is not only that subroutine calls and pretty much every other instruction takes 1 clock cycle, you can also combine certain operations such as the subroutine return to it. Oh, and it runs at 48 MHz on the BlackIce-II. I did not try to optimize it. I think I also ported it over to the Pepino board, as 32 bit version. Along the lines James had done his version for the Xilinx Spartan 6. No but I guess I could set it up. I was playing with the Icestorm tools and used the J1 as the core to play with. I did not do much, my work amounted to merging the top level block from BlackIce examples with the J1. I tested it with both place-and-route tools: arcahne-pnr and the newer nextpnr. For the latter I had to study things a little to get the PLL done properly (the input clock is 100MHz, which the PLL takes to 48MHz).
  13. Thanks, that is a good comment. I have also used Forth to bring up hardware - the last project of this type was porting the J1 CPU for the BlackIce-II FPGA board. The J1 is essentially a Forth CPU. I'm tempted to add a co-processor system to my TI-99/4A FPGA system with this CPU. It is very compact and very fast. You probably already know about it. This could be used for example to aid debugging, to monitor TI-99/4A signals etc. To make it truly useful it would need to have some capability to interface with the TI's peripherals. On the other hand my next goal is to make my system more accessible by porting it to other low-cost and widely available boards. I'm trying to resist feature creep until then. https://excamera.com/sphinx/fpga-j1.html
  14. It was great to be able to use PeteE's software, I found and fixed two bugs: 1. Despite my "testing" there still was a bug with the treatment of ST1 (A> flag) with the ABS instruction. The processing just lacked completely the special case that ABS instruction sets ST1 based on the source argument. 2. SLA0 did not set overflow flag properly if shift count was greater than one. Fixing bug 1 got extended Basic fixed! So now I could resume what I was actually trying to implement, read access to the serial flash ROM chip. To my delight the code I had writing worked, and I was able to access the serial flash ROM from Basic with a series of call load(...) and call peek(...) statements. I wish the Basic had direct support for hexadecimal numbers, both input and output. The Oric Atmos Basic features these and also DOKE and DEEK operations, which enable peeks and pokes but with 16-bit values... Anyway, with the bugs fixed, all the test cases pass now. It's great that this test is now also very easy to repeat whenever the CPU is updated.
  15. Thanks, this is awesome and extremely helpful to have an independent piece of verification code! I've not had time during the week to test this, but I am looking forward to doing so this evening. Hopefully something shows up immediately Also your testing methodology is better than my test code, I should also test the instructions twice, to make sure the flags go both ways properly. Thus I can improve my test coverage by making a simple modification. Perhaps I should also work on the test code to make it a cartridge, could be useful to others too.
×
×
  • Create New...