Huge you say? Not by many peoples standards maybe, but I'm being offered 2.7inches regularly, and have a 2.4" in my hot little hands already. Not content with just that, I also have a couple of 0.49" too. And that's before we get to the official Adafruit ones! Some lovely featherwings and StemmaQT displays...

What is this, the latest way to stream media through your microscope into your eye balls? No, not that, unless you're a fan of slow text based games... Welcome to the world of ASCII displays!

Pick your display, grouped by Adafruit product, screen size or chip. Then choose from the default regular, or large font size. The Adafruit IO website then automatically offers the correct width and height for the monospace font. There's a simple text area that supports newlines along with warning you about max size and if lines become too long. You can even copy and paste some wacky values to access the special characters!

Learn doesn't like showing the unprintable characters, so I've saved the text to copy on GitHub:

Better yet, if use the associated feed page or endpoints then anything you send will be fired straight to the screen. Both methods support "\" then "n" for a forced newline, but sending directly to the feed also allows reserved characters like 0x02 for smiley face (sent as \u0002 in JSON via the API).

To test the theory, I used an LLM to help automate some of the tedium of testing all 200-odd characters (0x00 to 0xFF), by creating a postman collection to test them in groups of four. Each test fired a new value to the feed with four new space and newline separated characters, with a 2second delay between tests, which would effectively cycle through them all.

Why in fours? Well on the 0.49inch screen (64x32 pixels) you get 5characters width and two lines high at the larger font size, or 10characters long and 4 high at default size. I wanted to be able to clearly see them so used large size initially, then went through them again in default size with more per screen refresh.

Ask an LLM to create a postman collection, with each request as a test run, and the entire suite to use 3 variables, io_user, io_key and feed. Then fix the broken url (its io.adafruit.com/api/v2/IO_USER/feeds/FEED/data), and the double escaping (\\u0002 instead of \u0002), and hey presto we can test the entire character set!

You'll need to update the IO user, IO key, and feed key, stored as variables in the collection.

Got no OLED displays, but still want to play with the new toys? Wokwi to the rescue!

Wokwi is a pretty accurate simulator (prides itself on such things), supporting Raspberry Pi Pico and ESP32 (and stm32 / arduino) boards, with free wireless internet built in, and a small treasure trove of components.

Here's a link to a wokwi project diagram (and readme), which has an SSD1306 I2C OLED display attached to an ESP32 (pretending to be a feather ESP32):

https://wokwi.com/projects/434679806018534401

Follow the instructions in the readme file, or just register a new esp32 WipperSnapper device on Adafruit IO, but for the wifi network use "Wokwi-GUEST" with a blank password, and download the offline firmware file (.bin).

Then use the firmware file inside the wokwi window, by clicking in the code window then pressing F1 for the menu, search for UF and pick "upload firmware and start simulation", then select the .bin file, and make sure to also have an IO page open to receive the new device registration request.