Jump to content
IGNORED

Icy99 FPGA 99/4A


speccery

Recommended Posts

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.

 

  • Like 12
  • Thanks 3
Link to comment
Share on other sites

It looks like a very interesting project! ? I have some questions regarding your project and the BlackIce board.

 

Do you plan to implement also the disk and speech support in order to have a complete TI99 system in FPGA?

 

The second question is related to the board used for the implementation. What's the main reasons for the choice? What are the advantage over other more common solutions used for retrocomputing? In particular, I'm referring to the use of a De10-Nano of the MiSTer project. You'll be probably aware that your EP994A code was converted for MiSTer and is running quite fine, although the implementation is missing disk and speech support. So, why not starting from that point to implement a more complete FPGA solution for our TI99?

 

At the end of the project the BlackIce board will permit to run a TI99 FPGA solution in a standalone manner, similar to MiSTer/Mist? Or it will require to be always connected to a PC to be operable (e.g. to load a new SSS module, etc.)?

 

I think that a lot of TI fans are expecting a implementation of our TI99 in FPGA, similar to those available for other systems like the C64 for completeness and robustness. It's the "orphan" syndrome since 1983.. ?

 

Many thanks for your work and support to the TI community and please keep us updated with the progresses! ?

 

  • Like 3
Link to comment
Share on other sites

BlackIce MX has fewer GPIO pins (48), and replaces static RAM with SDRAM. So you need some more code before you can get RAM up and running.

 

The BlackIce II went out of stock more than a year ago. MX is about the same price. MX was created to be more friendly to builders who want to drop it into their own "carrier" board alternate to the simple one provided.

 

I had a triple-PMOD on BlackIce II connected to the 4A side port, providing SAMS memory and memory mapped devices. I had to redesign it for MX to use just 16 pins, but I'm still using it on the II for the static memory.

 

 

  • Like 1
Link to comment
Share on other sites

On 10/12/2019 at 11:46 PM, Ksarul said:

Looks like the current product is the Blackice Mx. It seems to be using the same FPGA though.

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.

Link to comment
Share on other sites

On 10/13/2019 at 10:29 AM, tmop69 said:

It looks like a very interesting project! ? I have some questions regarding your project and the BlackIce board.

 

Do you plan to implement also the disk and speech support in order to have a complete TI99 system in FPGA?

 

The second question is related to the board used for the implementation. What's the main reasons for the choice? What are the advantage over other more common solutions used for retrocomputing? In particular, I'm referring to the use of a De10-Nano of the MiSTer project. You'll be probably aware that your EP994A code was converted for MiSTer and is running quite fine, although the implementation is missing disk and speech support. So, why not starting from that point to implement a more complete FPGA solution for our TI99?

 

At the end of the project the BlackIce board will permit to run a TI99 FPGA solution in a standalone manner, similar to MiSTer/Mist? Or it will require to be always connected to a PC to be operable (e.g. to load a new SSS module, etc.)?

 

I think that a lot of TI fans are expecting a implementation of our TI99 in FPGA, similar to those available for other systems like the C64 for completeness and robustness. It's the "orphan" syndrome since 1983.. ?

 

Many thanks for your work and support to the TI community and please keep us updated with the progresses! ?

 

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.

  • Like 1
Link to comment
Share on other sites

On 10/15/2019 at 11:48 PM, FarmerPotato said:

BlackIce MX has fewer GPIO pins (48), and replaces static RAM with SDRAM. So you need some more code before you can get RAM up and running.

 

The BlackIce II went out of stock more than a year ago. MX is about the same price. MX was created to be more friendly to builders who want to drop it into their own "carrier" board alternate to the simple one provided.

 

I had a triple-PMOD on BlackIce II connected to the 4A side port, providing SAMS memory and memory mapped devices. I had to redesign it for MX to use just 16 pins, but I'm still using it on the II for the static memory.

 

 

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?

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...
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.
Flea_Ohm_rev_A2_nice.jpg
 
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.
 
IMG_9642-vga.thumb.jpg.164f7552960413a2a94b03bce3652d57.jpgIMG_3723-lcd.thumb.jpg.fba8d0e1216783aa57b47e3ae4d53b53.jpg
 
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... :)

Edited by speccery
  • Like 13
Link to comment
Share on other sites

  • 1 month later...

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...

Link to comment
Share on other sites

4 hours ago, speccery said:

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...

Ooooh, just starting out with that (using the "Look mum no computer" plans for now), really cool stuff! Do you have a blog somewhere where you chronicle your builds?

Link to comment
Share on other sites

On 1/14/2020 at 1:22 PM, TheMole said:

Ooooh, just starting out with that (using the "Look mum no computer" plans for now), really cool stuff! Do you have a blog somewhere where you chronicle your builds?

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?

Edited by speccery
Link to comment
Share on other sites

  • 4 months later...
On 1/14/2020 at 9:30 AM, speccery said:

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...

 

Hi, do you have any update to share with us for this really interesting project? How is proceeding? I bet that there are a lot of people here that would like to see a video on how it's working. ;-)

 

Link to comment
Share on other sites

1 hour ago, tmop69 said:

 

Hi, do you have any update to share with us for this really interesting project? How is proceeding? I bet that there are a lot of people here that would like to see a video on how it's working. ;-)

 

I haven't worked on the Icy99 lately, but I did run a test with it today in connection to my new project, the StrangeCart (pls see that thread if you're interested). I did find a bug in the VDP code with the test.

 

Making a video has been in my mind, I will try to find some time to do it.

Link to comment
Share on other sites

1 hour ago, speccery said:

I haven't worked on the Icy99 lately, but I did run a test with it today in connection to my new project, the StrangeCart (pls see that thread if you're interested). I did find a bug in the VDP code with the test.

 

Making a video has been in my mind, I will try to find some time to do it.

Great, many thanks! ?

 

The VDP bug fix you mentioned is a cue for a question, since I'm not an expert of FPGA development. I've recently found on github a F18A implementation (.vhd files) from the CollectoVision project. How complex is porting this F18A implemetation to an existing FPGA TI99 core (e.g. in MiSTer or in your Icy99)? It's similar to integrating some C library?

 

Link to comment
Share on other sites

The F18A HDL is included with Phoenix source. I did quite a bit of work on the Phoenix, which included providing the F18A core. Because the Phoenix is open source, I included the F18A HDL as well (trying to do my part). I do not have a repo for the F18A set up yet, but it is there for anyone looking hard enough. Most people tend to not read code, so it has remained somewhat hidden in plain sight. 

  • Like 4
Link to comment
Share on other sites

4 hours ago, tmop69 said:

Okay, I wasn't seeing that one, felt that it may have some benefit, if Michael someday decides to try adding f18a functionality to Mame, this may point the way.

7 hours ago, tmop69 said:

I've recently found on github a F18A implementation (.vhd files) from the CollectoVision project. 

 

Can you post a link? thanks.

Link to comment
Share on other sites

11 hours ago, tmop69 said:

Great, many thanks! ?

 

The VDP bug fix you mentioned is a cue for a question, since I'm not an expert of FPGA development. I've recently found on github a F18A implementation (.vhd files) from the CollectoVision project. How complex is porting this F18A implemetation to an existing FPGA TI99 core (e.g. in MiSTer or in your Icy99)? It's similar to integrating some C library?

 

The MiSTer version of TI-99/4A is based on my EP994A core.

 

Integrating an existing component is conceptually similar to integrating a C library. But frequently it is not like that. There are differences in the chip capabilities, pinouts, peripheral chips a design relies on, and so on.

 

I haven't studied F18A code even if I have had access to it for a while, but it is designed with the Xilinx dual port memories in mind. My Icy99 core targets multiple FPGA chips, including the Lattice ICE40HX family, which has really humble specs. One key area of differences in specs are the on-chip block memories.

 

The ICE40HX chips do have dual port block memories, but only 16K in total, and one port is a fixed write-only port while the other is a fixed read-only port. The Xilinx block memories support changing roles, so you can have for example one read-write port and another read port. This setup works well for a VDP implementation. Long story short - I do not think it is possible to port the F18A for the ICE40HX chips. I have already tested Icy99 with Lattice ECP5 FPGAs as well as Xilinx chips, they could support the full F18A.

 

16K is not enough for TMS9918 + VRAM implementation, since in practice you always want to include a scan doubler to have VGA or DVI output. The scan doubler needs some memory too, and anyway in my opinion it would be wasteful to use all the internal block RAM for VDP alone when doing a complete system-on-a-chip setup. So the Icy99 VDP only uses a few internal block memories, and relies on fast external SRAM access (or in the case of the larger FPGAs, using internal block RAMs). Now the reason I am writing all of this is that I believe the bug occurs due to external SRAM bus arbitration and the way the VDP is using the bus. This part is very different from how I think the F18A works (without looking at the source) and definitely different from how the EP994A core works.

  • Like 3
Link to comment
Share on other sites

The F18A MK1 has no external RAM since the Spartan-3E 250 FPGA has 24K or Block-RAM, which was enough for the 16K of original VDP RAM, plus line buffers and GPU-only RAM.  The F18A design makes extensive use of the dual-port capability of the FPGA's Block-RAM, and if a target FPGA does not have dual-port Block-RAM I don't think you would get the F18A ported, short of a complete rewrite.  I was also a little wasteful with Block-RAM use in the MK1, since I did not think to expand the VRAM to something like 20K (I still need line buffers).  That mistake is going to cost me dearly in the near future.

 

The MK2 will introduce a lot of change in the design, since it does have 512K of external RAM.  However, even though the external SRAM is fast (10ns), it does not have the dual-port capability of the FPGA's internal Block-RAM, so the memory timing on the MK2 is going to get a lot more complicated and things are going to get tight.

  • Like 2
Link to comment
Share on other sites

I ported the Icy99 again for the ULX3S FPGA board. I looked at my notes, in this thread actually, and I can see I did port it before. But I couldn't find the files anymore, probably since I only have some of my computers in the temporary apartment we're staying (moving to permanent location next week). I clearly use too many computers for the same stuff... Anyway it was not a lot of work to port the design from the Flea FPGA Ohm files, as both boards use the Lattice ECP5 family FPGA chips.

Once I got the porting done and started to look at the cause of the VDP video bug I mentioned above, and it only took me 5 minutes to both find and fix the bugs. Sometimes it helps to to return to a project after a pause :) although I wouldn't recommend 6 month pauses...

The basic problem was that my verilog code checked for end of scanline and end of frame conditions in a stupid way: if a CPU memory access would occur while the logic was waiting for the said event, the logic would miss the event... The fix was simple, just moving these end of line/frame checks to their own parallel blocks, evaluated on every clock cycle. Now the image is solid, although the first scanline repeats now for lines, so there is an edge condition still needing fixing.

I'm still only using internal block memory on the ULX3S. The ECP5-85 chip has over 400K of internal block RAM, and I am now using just over 100K to support the 99/4A, system ROMs, system GROMs, 32K RAM expansion, VDP VRAM, 16K cartridge ROM space and 32K cartridge GROM space. 

I am now wondering how I could connect strangecart to the FPGA design, as that would be a fun exercise. Perhaps I will just go with a simple SPI bus, as that would only require four wires. The code on the StrangeCart side would need to be changed, so that instead of listening to the parallel TMS9900 address & data buses it would get the address and data over the serial bus. Also, the FPGA would need to capture reads and writes to cartridge space and transfer the data in SPI format. If the SPI clock is something like 25MHz  I would get very close to the bandwidth of the standard cartridge interface: 16 clocks to transfer address, perhaps 8 bits for command (read/write, ROM/GROM), and 16-bits for data.

  • Like 4
Link to comment
Share on other sites

On 10/12/2019 at 9:31 AM, speccery said:

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.

 

You forgot that Cart space has 16 pages built into TI99/4A for 640K of GROM/GRAM total. 16 pages of 40K each.

Link to comment
Share on other sites

5 hours ago, RXB said:

You forgot that Cart space has 16 pages built into TI99/4A for 640K of GROM/GRAM total. 16 pages of 40K each.

The Blackice-II board which I was using as the primary design target when writing the above only has 512K of memory in total. Thus I was trying to come up with an allocation of that memory which would support most use cases. Clearly it's not possible to allocate 640K for GROM/GRAM space when there is only 512K to work with in total :)

 

On other boards, such as the ULX3S, there is a SDRAM chip on board. It provides 32 megabytes of memory, but I'm not yet supporting that in this design, although I have earlier worked on another board with SDRAM providing system memory for my TMS9900 core. With that kind of memory space it becomes possible to support the full GROM space, as well as full 1M AMS memory space.

 

I don't actually even know what would be a reasonable amount of memory to allocate for GROM content? If memory serves me right the Ubergrom supports around 100K of GROM spacce.

I was thinking that 40K of cartridge GROM space would support pretty much all individual GROM programs, but of course it is possible to have multiple programs in different GROM bases simultaneously. 

  • Like 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...