pico9918: A replacement TMS9918A/TMS9929A VDP using a Raspberry Pi Pico(github.com)
github.com
pico9918: A replacement TMS9918A/TMS9929A VDP using a Raspberry Pi Pico
https://github.com/visrealm/pico9918
24 comments
The designers of the 9918 also coined the term "sprite" for pixel-movable graphic elements. It was the basis for all Sega console graphics chips up through the Genesis (most of which had additional capabilities), and even the NES PPU is patterned somewhat after the 9918 design (albeit, again, with more capability).
The Colecovision was awesome for its time. I bought one brand new just after it came out. It's graphics and sound walked all over the 2600 and Intellivision. A great Donkey Kong port as a pack-in? Yes please. Some other real gems in its library as well. The Super Action Controller as standard vs the crappy Intellivision-like one would have been icing on the cake.
The TI-99/4A version of Donkey Kong was the only home port (that I know of) that had all four screens from the arcade original. Graphics and sound-wise it's a bit inferior to the ColecoVision port, but the ColecoVision version, afaik, had only three screens.
The TI-99/4A community is really (and somewhat surprisingly) still very active. Among other things, the monthly stream from the CTIUG on YouTube ( https://www.youtube.com/@chicagotiug5404 ) of their monthly meetings at the Evanston Library is actually quite fun, and the js99er.net (somewhat recently rewritten in Angular) emulator is just amazing.
It's really cool that the Pico has the horsepower to do this sort of thing instead of having to reach for a FPGA.
The PIOs really are a superpower for this kind of thing. Interestingly the RP2040 documentation mentions that each PIO uses roughly the same silicon area as a dedicated peripheral for something like SPI or I2C, so now that the concept has been proven to work in practice it would be amazing if the successor chip ditched most of the single-purpose I/O peripherals and replaced them with a huge battery of PIO channels which can each be programmed to do SPI, I2C, or whatever else as needed.
Here's a quote from Eben Upton (CEO of Raspberry Pi Trading, 2023):
“We know what people don’t like about [RP]2040,” Upton admitted at the event, “the [Arm Cortex-]M0+ [architecture], could have more RAM, could have more GPIO [General-Purpose Input/Output], and we know what people do like — the PIO [Programmable Input/Output blocks]… and we have a chip team.”, [0][1]
That doesn't sound too bad, hmm?
[0] https://blog.adafruit.com/2023/12/04/raspberry-pi-hints-at-n...
[1] https://www.hackster.io/news/eben-upton-hints-at-an-rp2040-s...
“We know what people don’t like about [RP]2040,” Upton admitted at the event, “the [Arm Cortex-]M0+ [architecture], could have more RAM, could have more GPIO [General-Purpose Input/Output], and we know what people do like — the PIO [Programmable Input/Output blocks]… and we have a chip team.”, [0][1]
That doesn't sound too bad, hmm?
[0] https://blog.adafruit.com/2023/12/04/raspberry-pi-hints-at-n...
[1] https://www.hackster.io/news/eben-upton-hints-at-an-rp2040-s...
Sounds good to me. The decision to go for two tiny cores rather than one beefier core with an FPU was strange, and it would be nice to have a PSRAM interface like the ESP32s do. They seem to want to have one chip SKU which does everything rather than a million variants, hence why they made the flash external on the RP2040, so if they can extend that to one chip which can be configured with variable flash size, memory size, and has tons of PIOs...
> The decision to go for two tiny cores rather than one beefier core with an FPU was strange
It's very useful to dedicate an entire core to running your timing-critical assembly code, and only run higher level non timing critical application code on the other core.
It's very useful to dedicate an entire core to running your timing-critical assembly code, and only run higher level non timing critical application code on the other core.
[deleted]
This is exciting because the current defacto standard for upgrading the graphics in a TI-99/4A is the F18A project, which is an FPGA based solution. It's really cool, but it's expensive and frequently unavailable.
I am interested to see if this project evolves in the direction of F18A compatibility. It will need to support 80 column mode at a minimum before I switch.
I am interested to see if this project evolves in the direction of F18A compatibility. It will need to support 80 column mode at a minimum before I switch.
I'll certainly be looking to add some F18A compatibility in the near future. Like you, it seems the overwhelming majority are primarily interested in 80 column mode, so that will be first up.
Ask and you shall receive :)
https://www.youtube.com/watch?v=qdCapu0CVJ8
https://www.youtube.com/watch?v=qdCapu0CVJ8
Awesome work!!!
The main constraint appears to be the number of available GPIO's. For 8-bit projects the bus can take a large number of pins, not leaving a lot for the other functions.
Annoyingly the RP2040 has 30 GPIOs but the official Pico boards only break 26 of them out, which seems like an unforced error given the layout would have enough pins for all of them if it had less than 8 redundant GND pins. Those spare GPIOs are used to connect the WiFi coprocessor on the Pico W, but on the regular Pico one of them is just used for the onboard LED and the other 3 aren't connected to anything.
The redundant GND pins are necessary for signal integrity and low EMI when running at higher speeds; the high speed signals need a return current path with as little loop area as possible, so you want those signal pins close to GND on the connector.
On the RP2040 this is solved by having a huge ground pad in the middle[1], as it has somewhat modest needs.
On modern CPUs there are tons of "redundant" ground pins sprinkled all over[2]. Just about every high-speed GPIO pin and power pin has it's own ground pin right next to it.
Keep in mind "high speed" mostly relates to having fast edges. You can have EMI issues with a "slow" 1MHz signal if the edges have rise/fall times are say a few ns, which modern microcontrollers can do.
[1]: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p... (1.4.1)
[2]: https://en.wikichip.org/wiki/amd/packages/socket_am5#Pin_Map
On modern CPUs there are tons of "redundant" ground pins sprinkled all over[2]. Just about every high-speed GPIO pin and power pin has it's own ground pin right next to it.
Keep in mind "high speed" mostly relates to having fast edges. You can have EMI issues with a "slow" 1MHz signal if the edges have rise/fall times are say a few ns, which modern microcontrollers can do.
[1]: https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p... (1.4.1)
[2]: https://en.wikichip.org/wiki/amd/packages/socket_am5#Pin_Map
Use the flash in single-SPI mode and you may use the unused pins for other purposes, gaining a few more.
VDP: video display controller/processor
"The TMS9918 and its variants were used in the ColecoVision, CreatiVision, Memotech MTX, MSX, NABU Personal Computer, SG-1000/SC-3000, Spectravideo SV-318, SV-328, Sord M5, Tatung Einstein, TI-99/4, Casio PV-2000, Coleco Adam, Hanimex Pencil II, and Tomy Tutor...
"Texas Instruments' TMS9918A was succeeded by Yamaha's V9938, which added additional bitmap modes, more colorful sprites, a vertical full-screen scroll register, vertical and horizontal offset registers, a hardware blitter and a customizable palette."
https://en.wikipedia.org/wiki/TMS9918
MAME also implements the 9918 in software, as many of its emulation targets bundled it as a component (mostly video arcade games).
https://www.reddit.com/r/MAME/comments/pw8285/is_it_possible...