There has been a steady stream of improvements to my wearable C64/C128 text emulators and related projects since the Summer 2023 debut at VCF West 2023 in Mountain View. My Twitter/X account includes posts of many of these advancements.
- used a 6502 test suite to find problems in my emulation
- Vic-20 emulator
- Vic-20 upscaled resolution
- A few more hardware targets supported, including much smaller sizes
- M5Fire 320x200
- M5Atom S3 128x128
- M5Stick-C 160x80
- LilyGo T-Display-S3 320x170
- Downscaling resolution as necessary
- Tilt and pan for 1:1 resolution on tiny screen sizes
- FATFS partition for files when no SD present, and when PSRAM not present
- M5Stack CardKb support
- wireless keyboard (BLE server/client)
And all these changes are stored on GitHub of course!
A fellow attendee at Vintage Computer Festival West 2023 sported a red M5Fire and it looked really good! So I ordered one soon after, it arrived with some other goodies, and I quickly ported the M5Core2 and M5CoreS3 solution to the M5Fire. Features are comparable.
Then I added keyboard support to the on-screen buttons. Left goes up. Right goes down. Center is Return. Left+Center is Shift+Run with a ROM change to make it load the first program from disk. And Left+Right toggles between the different emulators (C64 -> C128 -> Vic-20) This made an actual keyboard optional for demos. I had a boot program to provide a listing of programs selectable by cursor keys and Return key.
The only downside is that the M5Stack Fire is not watchband compatible in that the recharge circuit is in the detachable base, not in the unit itself. Otherwise it would make a classy wearable.
Vic-20
The Vic-20 was my original home computer. It is what I used to deep dive into Commodore, learning BASIC and 6502 Assembly Language inside and out from about 1982 to 1985. I still have a fondness for this system.
But it has an odd screen resolution. Text is 22 columns and 23 rows equating to 176x184 pixels.
The M5Core series controllers have an LCD 320x240. This was just perfect to match the standard text screen of the C64 which is 320x200 pixels.
Originally I simply increased the border sizes around 176x184 pixels.
Then I revisited my Teensy C64 which has an option for a 480x320 LCD screen. For that project I researched upscaling, which involved scaling an 8x8 character cell to a 12x12 character cell, using color averaging.
For the M5Core series, I similarly scaled the Vic-20 8x8 character cell to 12x8. To accomplish this, staring with pixel offset 1, an extra column is interpolated from the previous and next pixels, and repeated a total of four times. The LCD works in 16-bit color mode with 5 bits for red, 6 bits for green, 5 bits for blue. The color of the two pixels is broken down into its component red/green/blue parts, the corresponding color parts are averaged (totaled and divided by 2), then recombined into a 16-bit value for the interpolated pixel.
So far only the M5Cores with PSRAM have Vic-20 and C128 support.
This is the smallest target hardware I have ported to. Downscaling was implemented to see what would happen. The 8x8 character cell is downscaled to 3x4 pixels, so 64 pixels downscaled to 12 pixels which is a large number of pixels to through away. Priority was given to the center pixels, so it toggles between averaging 6 (3x2) or 4 (2x2) at once. It does a weighted average between the foreground color, and background color pixel counts, so the resulting downscaled pixel is closer to one or the other.
Surprisingly, the screen is somewhat readable even with this resolution loss. But to compensate for loss a zoom and tilt to pan feature was implemented. The whole screen is mounted as a single pushbutton. Clicking it toggles between zoomed out to the downscaled resolution, and the zoomed in to the pixel perfect 320x200 resolution that is panned, by tilting the device. Zoomed in, hold the device level with the floor, with the screen pointed to the ceiling, and you will see the top center of the C64 screen. Tilt to the right and forward to see the top left corner of the emulated screen, and so forth to switch between one of six views of various parts of the emulated screen with every pixel shown. Click again to zoom out for an overview of the entire screen, but downscaled. Break out a magnifying loop or such to see the detail of the teeny tiny pixels.
This platform does not include an external storage device such as SD card. Nor does it have PSRAM normally used by the D64 emulation. Instead, a FATFS partition was initialized, and individual C64 PRG files were selectively uploaded to the device. The "$" directory functionality is not present, but LOAD/SAVE/VERIFY are supported. There is room for about 1.5MB of files in the partition size selected, that's about 9 times larger than the standard single sided C64 floppy, so not too bad!
I had forgotten about this hardware device. It was the first M5Stack device I had purchased, and I had squirreled it away in a project box. Obviously it was too small for a C64 screen so I didn't give it another thought. Until I saw a post on Twitter/X showing the solution with CardKB. Looks like it's using my text-only emulation, using LCD fonts. Of course I respond! That would work very well. I've just been so focused on LCD pixelized solutions simulating the look and feel of Commodore instead of remembering the roots of my text emulation efforts with C64. Just hook CHARIN and CHAROUT and you're golden. You don't need a screen editor. You can just do buffered line input (local edit), and character output. I was laughing at myself for not pursuing this myself. CardKB provides ASCII output (from I2C polling) of the alphanumeric characters, and other byte ranges for functions and cursor keys.
I wanted to do CardKB, but as I have been focused on C64 scan code adapters, it seemed hard. But here was the challenge presented on the Internet. I had already implemented an adapter of sorts leveraging a SeeedStudio ATMEGA328P (Uno compatible) board with Grove connectors and an Arduino sketch to translate I2C reads into TTL serial scan code reports. And it worked, but was very clunky because of all the cords and extra board. My existing prototype solution was not great for a wearable solution.
The M5Core and such were focused on using the Grove connector as a software serial port, receiving the C64 scan codes. I had the original C128/C64/Vic-20 keyboard to Grove adapter running on an Adafruit ItsyBitsy and that was my favorite keyboard connection because it was true to the original! Next best was a web page to USB Serial adapter I had also developed. The common ground was scan codes, and serial communication. But the CardKB runs I2C. So how to do CardKB and serial communication simultaneously on the same Grove port? Originally I thought of getting the source to CardKB and rewriting, reflashing it to do serial communication instead. That would make it compatible with my existing solutions. But I was avoiding the reflashing that would also requiring rigging a programming interface, using an Uno or compatible.
Instead, I approached the Grove port as an either or, the emulators were updated to check for an I2C response at startup, and if found, regularly read from the I2C port for keyboard presses. Then adapt those presses from ASCII/function code presses into momentary C64 scan codes, and 1/60th of a second later, respond with no key pressed (key up) scan code response. This is an out of the box solution that will work for others too!
M5Stick-C also leverages a FATFS partition as there is no built in SD port. Again 1.5 million bytes., Though I did have to revise the partition choices manually via a JSON file as FATFS was not included in the default partition schemes presented.
But the screen resolution is 160x80, with downscaling of one character's 8x8 pixels to 4x3 pixels. This time the pixels are halved horizontally, and vertically there is an 8 to 3 pixel translation, very similar to
the downscaling on the AtomS3, but rotated to different axes.
This is by far the worst unreadable display for individual text characters. More than halving the vertical resolution makes the text completely unreadable (such as the startup screen). It's not it's fault completely, and is a cute form factor when not pretending to be a C64.
This is another inexpensive device with a wide yet shorter display 320x170. Oh so close to the necessary 200 pixels. So a custom downscaling algorithm favoring the center four vertical pixels of each character cell, while averaging the top two and bottom two pixels. This results in a very recognizable display of alphanumeric characters with some slight distortion at the top and bottom of each character.
While this device has plenty of flash storage and PSRAM comparable to the best of M5Stack Cores, there is no built in SD card, so the implementation also leverages a FATFS partition successfully. But with the PSRAM included, D64 support could be included allowing for the floppy drive image feature.
BLE keyboard support has also been included with this one, making it full featured.
The features missing are no Grove connector, no socket for CardKB support, and Vic-20/C128 support. A bit more effort could transfer these features with software and hardware.
Esc 1! 2@ 3# 4$ 5% 6↑ 7& 8* 9( 0) <x
Tab Q W E[ R] T/ Y£ U| IÏ€ O' P" fn
Up Shift A; S: D F+ G- H← J= K? L <-
Lt Rt Sym Z X C V B N M ,< .> __
Dn
fn+1..fn+0 is ctrl+1..ctrl+0
fn+A..fn+Z is commodore+A..commodore+Z
Esc is stop
fn+Esc is stop+restore
tab is load+run
fn+tab is restore
fn+<x is insert
fn+up is clear
fn+right is home
fn+down is toggle case (cbm+shift)
Wireless BLE Keyboard
Taking CardKB one step farther is joining it with a M5 controller such as M5Stick-C to turn it into a Bluetooth Low Energy keyboard. Currently integrated with M5Fire, M5Core2, M5CoreS3, and T-Display-S3, turn them both on at about the same time and they will automatically pair. While the keyboard is wired to the M5Stick-C, another ESP32 system can be battery powered and receive keystrokes over the air with the BLE (2.4GHz) radio.
I used to wire the full size C128 keyboard to my wrist, and it was a hilarious irony in mobile computing.
