I got an idea the other day to write a display driver in pico8 using the GPIO pins and here it is. The cart replaces the flip() function with a custom one that writes the pico8 frame buffer to a connected display (with a ssd1351 controller) over SPI using the GPIO pins on a Raspberry Pi. Turns out that it actually works :)
I use this display/controller board from Adafruit
Emulating SPI over the GPIO pins seems to be quite slow however and it takes about 5 seconds to render a single frame. I believe that if zep exposes the hardware SPI functionality of wiringPi in addition to the GPIO pins it would run in real time. You can try commenting out the first line in spi_write_n() to "emulate" hardware SPI (with DD_ENABLE=TRUE).
Instructions are included in the cart if you would like to try it at home. Remember to enable GPIO pins on the RPi first and running pico8 as super user ("sudo ./pico8")
Wishlist:
* hardware spi (example: spi8(byte), spi32(four_bytes), spi(0x6000,8192) -- from memory) * delay functionality (like Arduino's delayMicros()) |
nice work!!!
you can use fbtft/fbcp to get the display working faster.
if Zep could have the option to pipe the display output to SPI, then it should run even faster than the fbtft method.
a friend of mine has a good library for tft access https://github.com/bitbank2/SPI_LCD
Thanks!
@moosepr: Yea, I found out about fbtft when researching this and I guess that is the most practical way. This is much more fun though :) I like the idea of everything being done through pico8.
It would be really cool if there was a way of loading other carts while retaining the modded flip() function. Then one could make a custom cart launcher (splore variant) that could be used in a physical gameboy-like console. I can't quite figure out how to do that though since the lua code is not stored in cart memory (as far as I know?). I've tried replacing the flip() function before calling load("othercart") but that resets the lua state again.
By the way, why would hardware spi run faster than fbtft? Do you mean that it would be less overhead?
@zep: Imagine having more Arduino-like functionality in voxatron as well (spi and delay mainly), then one could experiment with custom volumetric displays :p
[Please log in to post a comment]
