PICO9918

A drop-in replacement for a classic TMS9918A VDP using a Raspberry Pi Pico.

Currently in the early prototyping stages, but looks very promising.

Hardware

Gerbers will be released soon once I validate the v0.3 PCB. The next stage will be to shrink it down, by including the RP2040 directly, rather than pluggin in an external Pi PIco module.

v0.3 Schematic is available now, however this revision has not yet been tested.

Raspberry Pi Pico Module

Note: Due to GROMCLK and CPUCLK using GPIO23 and GPIO29, a genuine Raspberry Pi Pico can't be used. v0.3 of the PCB is designed for the DWEII? RP2040 USB-C module which exposes these additional GPIOs. A future pico9918 revision will do without an external RP2040 board and use the RP2040 directly.

Purchase links:

I could reduce the VGA bit depth to 9-bit or 10-bit to allow the use of a genuine Raspberry Pi Pico board, but given the longer-term plan is to use the RP2040 directly, I've decided to go this way for the prototype.

Videos

Initial "raw" videos recorded in the moments following the first boot on my TI-99/4A.

These videos are showing the v0.2 hardware with an external Pi Pico providing the required GROMCLK signal to the TI-99. This signal has been added to v0.3. I'm still waiting on v0.3 boards to arrive.

It freaking works!

Don't mess with Texas!

License

This code is licensed under the MIT license

Project Logs

Collapse

PICO9918 v0.4 PCBs have arrived!
Troy Schrapel • 4 hours ago • 0 comments

Still waiting on parts to assemble, but the v0.4 PCBs have arrived and look great. Seen here next to their predecessor and an original TMS9918A.

Given this is my first PCB designed to take an RP2040 directly, I wouldn't be surprised if there are issues, but hoping for a usable board. I should have the parts to build one early next week.
v0.4 PCB Design Progress
Troy Schrapel • 06/26/2024 at 13:46 • 0 comments

Started working on the next revision of the board (v0.4). The all-in-one.
Looking pretty good. Managed to have it mostly single-sided (good for cheaper PCBA). Most of the components will be on the underside. 4 layers with the middle layers being a solid ground pour and a (mostly) power layer. Signals mostly on the IC layer (bottom) with some on the back (top).

On the top side are a couple of optional LEDs for read and write (for those who like the blinkenlights). The Boot button and USB-C connector required for reprogramming to little RP2040.

Not ordering these yet as I like to give it a few days to "simmer" in case I think of anything I've missed or could do better. Likely order the initial batch next week.
v0.3 Gerbers Released
Troy Schrapel • 06/26/2024 at 13:44 • 0 comments

I have just released the Gerbers for the PICO9918 PCB v0.3. I've been running tests continuously for a week or so on this revision and it is working great.
I've been thinking about how to go about getting this tested on more machines as I've only tested on two TI-99/4A's (PAL and NTSC) and my HBC-56. I might produce a few of these to send out to those who are willing and able to try it on a wider range of machines. Let me know if you're interested in this.
Note: This PCB revision is not representative of the final release which will be a single board without the need to the piggy-backed Pi Pico board. However, v0.3 is fully functional. If you're a tinkerer or early-adopter type, go ahead and give it a go. If not, I suggest waiting.
Real-time scanline benchmarks
Troy Schrapel • 06/13/2024 at 07:57 • 0 comments

Thought I'd do some initial real-time benchmarks - just to see how much wiggle room I have to implement more advanced features. It's looking quite good.

These images will look bad, but bear with me. :D

What's happening here is I'm switching the VGA signal to output BLUE when it's done generating the next scanline. So, if it was at 100% generating scanlines, these images would look perfectly normal since it wouldn't have time to switch to BLUE. If the image was mostly blue, that means it has loads of time left to do more cool stuff. Keep in mind, the VGA is at 640x480, so I'm doubling the scanline vertically for a virtual resolution of 640x240 (used to be 320x240, but switched to 640x240 to support 80 column mode). I generate a scanline once and use it twice. With that in mind, if I was using 50% of my single CPU core capacity to generate scanlines, you would see alternating lines: correct image, BLUE, correct image, BLUE, etc.

Ok. that's the gist of it. Now here's the results:

Graphics I - No sprites

Using around 33% of the available scanline generation time. ie. It finishes around 2/3 of the way through the first pass of a doubled scanline.

Multicolor

About the same: 33%.

Mixed modes

Here, you can see MC mode is the fastest. Graphics II lagging a bit at roughly 40% of the available time used.

Sprites

Adding in sprites gets us a pinch over 50% of a scanline time used (hence the black appearing on the left where sprites appear).

Anyway, all-in-all, I'm happy with the results. It means I have some room to move. For the most part, I could render the entire display twice (or more). I also haven't done much work to target my TMS9918A library to the Pico (was originally written for desktop use), so I'm sure there would be performance gains to be had by keeping the RP2040 in mind. Also, the scanline rendering is all taking place on a single CPU core. The second core is mostly twiddling its thumbs waiting for interrupts from the PIOs - I could allocate some work (such as the sprite layer) to that CPU core.
Cheers
Troy
Added 80 column mode
Troy Schrapel • 06/11/2024 at 12:42 • 0 comments

Had a bunch of people asking about adding support for the F18A 80 column mode. Ask and you shall receive :)
It works! PICO9918 running the TI-99 mega demo
Troy Schrapel • 06/09/2024 at 08:57 • 0 comments

The PICO9918 prototype is working great. Seen here running the awesome "Don't mess with Texas" mega demo on my TI-99/4A