PICO9918: A drop-in replacement for a TMS9918A (with source)

[visrealm]

cbmeeks wrote:

You sir, just made my decade. I've been doing a lot of VGA work with the Pico lately (well, been a few months).

https://github.com/cbmeeks/VgaPico

Thanks! Glad you like it

You might find my VGA-on-Pico implementation interesting too. My PIOs are very lightweight (4 PIO instructions for sync and 5 for rgb), yet flexible. The PIOs are configured dynamically for any display mode - tested up to 1280x1024@60Hz. You just fill out a small struct of VGA parameters:

Code: Select all

case VGA_1280_1024_60HZ:
  params.pixelClockKHz = 108000;
  params.hSyncParams.displayPixels = 1280;
  params.hSyncParams.frontPorchPixels = 48;
  params.hSyncParams.syncPixels = 112;
  params.hSyncParams.backPorchPixels = 248;
  params.hSyncParams.syncHigh = true;

  params.vSyncParams.displayPixels = 1024;
  params.vSyncParams.frontPorchPixels = 1;
  params.vSyncParams.syncPixels = 3;
  params.vSyncParams.backPorchPixels = 38;
  params.vSyncParams.syncHigh = true;

Pass it in, and it does the rest. It also includes pixel doubling/tripling/quadding, etc. in either direction.

Obviously, at 1280x1024, you'll be hard-pressed to feed it unique pixels, but doubled, it's fine.

[barnacle]

And you've just indirectly confirmed an idea I had this morning: the ability to change display modes on the fly. I'd like four basic modes, all using the internal ram of the Pico and using a default 640x480 VGA format:

- basic 80 column white (or green) text on a black ground
- an 80 column with foreground/background attributes
- 3-bit RGB pixels at full resolution (150k!)
- 4-bit grayscale pixels at full resolution (also 150k)

I suspect this is going to need some sort of analog switching, probably controlled by more IO from the PICO, and ideally I'd like to be able to read and write to the Pico as if it were a normal 6502 bus part - perhaps three or four bits of address, maybe less, I haven't thought this through yet. 8 bits of data, a chip enable, and a r~w signal.

Neil (must order the Picos!)

[visrealm]

That sounds reasonable. Easily achievable with the Pico.

In My PICO-56 repo, I started making some tutorial "episodes" on building up the various components. Including VGA. There, I demonstrate a framebuffer mode at 800x600 with a 16-color palette. Could obviously also do 3-bit RGB or 4-bit greyscale (with or without the palette). The palette can contain 12-bit RGB values.

FWIW, the TMS9918A only has one lonely address bit (MODE) and separate READ/WRITE signals. So, it doesn't need a CE since READ and WRITE can both be inactive.

[barnacle]

I shall probably be raiding your stores

I'm looking at including a ps/2 keyboard input and serial uart i/o (though that might go through an arm core) and one can probably use external logic to generate a rd and wr signal... I'm still thinking through the options but I think I need access to some sort of status byte, and the ability to read/write multiple bytes to internal buffers - different depending whether it's a data transfer or e.g. a request to write text to an 80x25 or graphics commands.

Neil

[visrealm]

I have PIO code for PS/2 keyboard in the PICO-56 repo. Serial/UART I handle via the built-in USB to UART interface, though the Pico does have built-in hardware UART support using GPIO pins as well.

[cbmeeks]

For my VGA project I really only cared about 64 colors. In fact, that's all I'm going to stick with going forward because for me it just seems to fit an 8 bit design better. Which means I can save a few pins.

[visrealm]

Yep. Fair enough.

[Yuri]

Curious about this. I've considered using my Teensy as a VGA driver, though the reactions from people who have tried seemed mixed.

I'd think I'd have an easier time of it with the Teensy as it's an M7 @ 600Mhz vs. the Pico M0+ @ 133 MHz

I've thought about finding an actual TMS9918A, or a Yamaha V9958 (they seem kinda pricey tho)

The neat thing about the Pico is there's a wireless variant, which has hardware support for Bluetooth. (Makes me wonder if I could use it to connect wireless keyboards and what not)

[cbmeeks]

I think the part you're missing is that the Pico has 8 PIO channels that act like 8 tiny processors that can do things like implement VGA, UART, etc. protocols with minimal intervention from the two cores.

This is how they are able to get that $4 unit ($1 MCU) output VGA.

Other micro-controllers have to bit-bang much of that in their cores. I realize there may be exceptions out there. But that's the "secret sauce" of the Pico.

[barnacle]

Finally able to build and write code to the pico; it was an uphill struggle. It turns out that the pi tools don't work well with flatpack (linux/mint)... the default download/install from rpi doesn't complete because it can't find the ms code package; the arduino flatpack won't talk to the udisksctl, but eventually discovered that the non-flatpack version of the Arduino IDE does actually work.

Having to remove and replace the pico every time I want to update the code is a bit odd; still investigating. And a blinky program that has 10k of global variables and takes 50k of flash suggests there's a lot being loaded that isn't being used...

But at least the LED is flashing

Neil

[barnacle]

To be honest, I'd like to see a linux command line example of the complete build process, including the upload (or stopping with the .uf2 file so I can copy it in)... I haven't yet found where Arduino keeps its compiled result.

[JohanFr]

barnacle wrote:

Having to remove and replace the pico every time I want to update the code is a bit odd; still investigating. And a blinky program that has 10k of global variables and takes 50k of flash suggests there's a lot being loaded that isn't being used...

Neil

IIRC rather than unplugging it and plugging it, you can hold down the "Boot sel" button while programming it. But it's been over a year since I did this so I might remember it wrong.

Edit: It seems I remembered it incorrectly, at least according to chapter 4.1 of the datasheet. "The simplest way to reprogram the Pico’s Flash is to use the USB mode. To do this, depower the board, then hold the
BOOTSEL button down during board power-up (e.g. hold BOOTSEL down while connecting the USB)."

[BigEd]

I think you need a power-cycle with the button pressed. But there might be some USB way to force a program in, using their tool... yes, see
https://github.com/raspberrypi/picotool ... ile#readme

[visrealm]

JohanFr wrote:

barnacle wrote:

Having to remove and replace the pico every time I want to update the code is a bit odd; still investigating. And a blinky program that has 10k of global variables and takes 50k of flash suggests there's a lot being loaded that isn't being used...

Neil

IIRC rather than unplugging it and plugging it, you can hold down the "Boot sel" button while programming it. But it's been over a year since I did this so I might remember it wrong.

There are a number of ways to do it.

2. You can add an external RESET button (button which shorts PIN 30 to ground). Then it's a similar process, but instead of unplugging/replugging while holding BOOTSEL, you can hold RESET, hold BOOTSEL, release RESET. This double button action becomes 2nd nature after a bit.
3. You can link in the pico_bootsel_via_double_reset library. Then tapping your new reset button twice will enter BOOTSEL mode.
4. You can add your own button to enter BOOTSEL mode programatically.
5. You can use the Serial Wire Debug interface
6. You can use picotool

I'm sure there are others. I use #2 and sometimes #3.

[cbmeeks]

This is exactly what I do. I use Linux and CLion to develop for the Pico.

I added an external button and like visrealm said, it becomes muscle-memory to just press both buttons and then release the reset button then the BOOT button.