pimoroni-pico VS yocto-8

It takes some time to decode, but I can grab- for example- this 259k JPEG: http://placekitten.com/3840/2160

And display it from the microSD card with this code: https://gist.github.com/Gadgetoid/0b8e352e377135d743338c9483...

As more or less demonstrated by this example: https://github.com/pimoroni/pimoroni-pico/blob/main/micropyt...

Decoding is done via Larry Bank's JPEGDEC: https://github.com/bitbank2/JPEGDEC

It uses roughly 20k RAM to provide the necessary buffers both for decoding JPEGs into blocks which are passed to a drawing routine that handles copying the data into the display RAM buffer (on our larger Inky display this is backed by PSRAM). I don't believe there's a hard limit to the size of the JPEGs you can display. The main bottlenecks are decoding time and the relatively limited scaling options: FULL, HALF, QUARTER, EIGHTH.

This aside, the authors solution is actually quite elegant. As long as you have control over the image pipeline there's no real reason to encumber the device with handling large (both in bytes and pixel dimensions) files. You'll also get much better dithering results writing your own routine to convert files from JPG to the raw 4-bits per pixel format for the display. Our built-in dithering is just a plain ordered dither matrix and, while quaint and retro, it leaves much to be desired visually.

If you're trying to use a public API you can also make GitHub actions automate the whole image conversion process and publish the results to GitHub pages. This works great for, for example, the daily XKCD, serving both to reformat the strip for the display, credit the author, extract the "alt" text and avoid excess requests to the origin. Eg: https://pimoroni.github.io/feed2image/xkcd-800x480-daily.jpg. Though the astute will notice I still opted for jpeg in this case.

I've done a lot of programmable LED projects (keyword Neopixel or WS2812) and by far my favorite hardware has been this little raspberry pi pico board that takes care of the power requirements for you, a USB-C cable can supply 3 amps, powering one or two hundred LEDs with ease. There's lot of Arduino boards that let you program a few neopixels, but supplying power for lots of them is usually the annoying part.

https://shop.pimoroni.com/en-us/products/plasma-2040

https://github.com/pimoroni/pimoroni-pico/tree/main/micropyt...

https://shop.pimoroni.com/collections/pico is the pi version of that.

I'm still not sure why the BBC went down the route of making its own platform when adapting the arduino world would have been simpler and more effective. Still its good to see that the BBC is doing computing again.

I have a problem with an I2C connection to a SCD41 sensor (Pimoroni Breakout). The strange thing is: The example provided by Pimoroni works perfectly fine.

But I'm using the https://github.com/pimoroni/pimoroni-pico firmware with the PicoGraphics module. There doesn't seem to much documentation about compiling their version (except the c version?)

I used the Pimoroni Micropython and the clock.py here.

However you'll find that the file you have linked includes breakout_sgp30.hpp which in turn includes drivers/sgp30/sgp30.hpp which you can find here: https://github.com/pimoroni/pimoroni-pico/tree/main/drivers/sgp30

No in this case the Pico part comes from its use of the Pi Foundation's Pico microcontroller. There are projects[1] that are working on porting PICO-8 to the Picosystem. Unfortunately it will never be fully compatible with the PICO-8 standards as it isn't powerful enough but some games work.

[1]https://github.com/yocto-8/yocto-8

Some folks are working on it, but as far as they know, many Pico8 games may never run on it: https://github.com/yocto-8/yocto-8

Sure! Feel free to message me in github or via email.

I've abandoned my Pico8 on RP2040 port though, a lot of games simply need more memory than there's available. There's this crazy guy: https://github.com/yocto-8/yocto-8/blob/main/doc/extmem.md that managed to get external RAM over SPI working (RP2040 does not support memory remapping)

On ESP32 with SPIRAM (/PSRAM) Pico8 is definitely achievable, and _most_ games will run at a playable frame rate, but some won't; as an example "Rockets!", does too many calculations per frame to run smoothly, and the Lua overhead starts showing so I'm exploring ideas like an optimizing compiler that can run off-console, etc.

I don't thing TIC-80 will be doable, the constraints are significantly more relaxed. A Pico8 framebuffer is 32KB; in TIC-80 it is 64KB (and this doubles with buffering/DMA) but most importantly, code is no longer something simple like Lua

Currently no, but someone is currently working on a project to implement it (https://github.com/yocto-8/yocto-8). Personally would love to see it completed as I have a few RP2040 chipset based things now.

There’s no support for mapping external memory but you can apparently get creative: https://github.com/yocto-8/yocto-8/blob/main/doc/extmem.md