So this ESP32-8048S070 showed up from AliExpress today. It is a 7" IPS with touchscreen with ESP32-S3-WROOM-1 module, 16MB flash, 8MB PSRAM, microSD card, USB-C serial (CH3400 serial), Speaker connector, and other IO connectors. The large LCD is 800x480 resolution.
The ordering page had a ZIP download of the examples, so I made sure I could build their Arduino Hello World TFT sample (I downgraded to Arduino_GFX library 1.3.1), and then ported my c-simple-emu6502-cbm project including upscaling from one to four pixels to cover the screen with C64 goodness. Without upscaling, the C64 was using less than a quarter of the screen. I skipped the SD support, and went straight to creating a FATFS partition and uploading a D64 image. Saves me from pulling an SD, but moving files up and down will be a bit more cumbersome. Included in the project already was custom wireless BLE keyboard support, so I was typing away and running my programs right away.
The largest IPS I had on hand was 3.5" 480x320, so this is a definite upgrade.
The only downsides to this board that I can tell are the lack of an enclosure (ships in a nice plastic storage box though - I hear there is a 3D printable one on github somewhere though), and the lack of direct connection to the native ESP32-S3 USB port. Then again, a permanent serial connection is more convenient for flashing Arduino sketches otherwise you have to keep selecting the COM port on other solutions.
Even though I've worked with it only a few hours, I highly recommend this board!
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.
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 it 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.
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.
I both create and fix defects in code that I've written. Hopefully I find the bugs quickly, but sometimes they linger for weeks, months, years, before being discovered or reproduced.
My story is not unique. It is difficult or impossible to write software without introducing defects. Computers are complex systems, but very obedient. They do exactly as they are told if you know how to speak their language, precisely, without misunderstanding or any inaccuracies. Problems can crop up if the developer didn't understand the system requirements in the first place (design/requirements issues), didn't thoroughly test all inputs and code paths, didn't understand concurrency issues, made assumptions, or makes the simplest of mistakes. As humans, we learn to overlook some inconsistencies, mistakes of others, so as to not disrupt the social norm. But with most of the languages we use with computers (Assembly, C, C++, C#, Java, etc.) many of these don't allow for the slightest of change. Some scripting languages (HTML, JavaScript, CSS, etc.) allow for some variance, but still are expecting a valid input.
Am I making an excuse for my mistakes? No, but explaining that they will exist. I wrote a limited Commodore/6502 emulator a while back and have ported it to various platforms with demonstrable results. I can run Commodore 64 and related systems at the BASIC prompt and it appears to mostly function normally.
Then I ported to Vic-20 including adding full-screen editing support and conversion from Commodore 64 key scans to Vic-20 key scans. And it did not work. But I swore up and down that I did everything correctly (ha!). Then dove in deeper to see what was different. Turned out the ROL ABS and ASL ABS instructions were doing the value shift but not storing the result in memory. A normal 6502 knows how to do this just fine, but the emulator needed to accurately replicate this behavior to be correct. The fix was to store the result at the absolute 16-bit address.
My first mistake was that I never performed a formal test of the instruction set of the emulated 6502. I knew they existed, but when bringing up the C64 I only spot checked a few instructions, and even compared traces between Vice and my emulator to note differences, and correct the emulation in a few places. (There's a reason my trace looks exactly like that from Vice -- so the comparison would be easy!) But once the system appeared to function correctly, I stopped testing.
Fast forward over 3 years later, and I know that some of my systems are not 100% correct. The effort I had brushed away came back to nag me. I really should test better. I have a saying that if it's not tested, it's not working. And I had ignored that saying. But I buckled down and did the effort of running a 6502 test suite against my emulator. And sure enough there were problems.
And since I have multiple emulator instances, the problems were slightly different, as I hadn't applied fixes consistently between all of them (still have missed a few at date of this article! STM32, mbed, TypeScript still have known bugs). [update 2023-11-05: TypeScript emulator updated with fixes]
Here are the instructions and features of the 6502 that required fixes in my emulator:
ROL (absolute address)
LSR (absolute address)
PHP (B flag)
PLP (B flag)
IRQ (push processor state without B flag)
(zp,X) indirect zero page indexed by X addressing not truncated to byte address when overlap page, affecting both load value and store value
SBC resulting in a negative result when in decimal mode
Many changes are now checked in for C++, C#, Arduino, M5, Teensy and related projects.
There are remaining bugs in emulation, probably closer to individual system systems outside the 6502 emulation. A few issues can be reproduced on demand, so I can tackle those next.
But the 6502 emulation should be good, at least as much as it has been tested.
This "portable" Commodore 64 and 128 emulator (m5 source code branch) is my work in progress, one in a series of minimalist emulators ported to different hardware targets. Only text (on LCD) with background, foreground, border colors, keyboard entry via USB serial tethered web browser, and general 6502/6510 and C64 memory management emulation is present (no, won't play games, make sound, or do bitmapped graphics) with some D64 emulation [added 7/2/2023].
Even my son asked, "Why do you need to do that?" Well, he has a point. I wanted a C64 that fit in my pocket or even on my wrist. And targeting new hardware platforms with my emulator is part of my hobby.
How does it work? Check out my highly technical drawing.
Now I already here you asking why I didn't connect Bluetooth to the M5Core, because certainly it has Bluetooth as well, and why didn't I use a USB keyboard connected to CoreS3, because it includes USB Host. But I've had trouble tracking down examples of HID Host examples for M5; client examples are prevalent, but host?
Pictured here is a phone is running Chrome with a custom copy of the html/javascript keyboard adapter including web-serial-polyfill because mobile Chrome doesn't directly include Serial API support. A Palm Pilot foldable keyboard has a Bluetooth adapter, paired with the phone. HID keystrokes are captured by the web page, converted to C64 key scan codes, and a list of the active key scan codes (or 64 when keys released) is sent over USB Serial to the M5Core device which is running the C64 ROMs which are tricked into thinking a real keyboard is attached; keystrokes are processed by the C64 KERNAL IRQ as normal.
The M5Core is being powered by the phone. Why M5Core? Because it's a polished packaged solution.
Yeah, we could just run a Commodore 64 emulator on the phone, but this way, I could have complete control over the keyboard emulation, what keys are present, how CTRL and Commodore keys work, etc. And it's just because I can, not because I should.
Why the Palm Keyboard? Because it folds in my pocket! And because I had one from back in the day. Any keyboard you can attach to a phone or computer should work. And this Bluetooth adapter just makes it so cool, and easier than a tethered keyboard.
The next step is to merge this solution with my Commodore 128 keyboard adapter to completely reject the portability feature. That would look really cool hooked up to my phone! Update (7/31/2023): check out YouTube for connection from ItsyBitsy/keyboard to Core Port.A.
I am excited about my nonsense crazy adventures. Even if only I enjoy them.
=====
Update (7/2/2023): D64 support is currently working with Core2 only (Basic Core doesn't usually have the additional SPI RAM, but not yet sure why CoreS3 is failing to attach SD).
Update (7/3/2023): Got CoreS3 working with SD switching header to M5Unified.h for that target (was M5Cores3.h) and adding special definition, override logic for SD_CS to use GPIO_NUM_4 instead of default. See updates to M5Core.h.
Update (7/28/2023): Commodore 128D extended keyboard working with UART connection to Port.A of Core, and Commodore 128 emulation is ported as well.
Here is my third iteration of an eBible interface -- browsing the Bible (KJV) by electronic means. First was a tiny 8x2 text screen on mbed NXP LPC1768 (ARM M3), second was a Nokia cell phone screen on mbed NXP LPC1114 (ARM M0 through hole package), and this third one looks very similar to a familiar 8-bit system, running in the browser.
The third revision required no soldering, and works with desktop, tablet, mobile phone devices, anything with a modern web browser. This current iteration builds on cbmish-script, providing the Commodore-like look and feel.
History
Back 35+ years ago I brainstormed on how to put the Bible on a Commodore computer. For example, with the Bible containing 66 books, I had planned to combine I John, II John, III John as one book, saving two so the book number would be 0..63 fitting in 6 bits. Nah, that's probably silly, one byte is proper to fit the book number. But I never got that far on the Commodore.
With my first mbed based eBible iteration, I focused on being able to navigate book to book, chapter to chapter, and verse to verse. So I built an index that was stored on the SD card, FAT filesystem.
The second eBible iteration had a different screen and used simpler block flash memory device (no filesystem whatsoever), with text, indexes, and bookmarks stored at different offsets.
Just prior to the third iteration, I restored the indexing code, porting from its original state working with mbed and linux, now to Microsoft Visual C++ on Windows. With indexing working, I was playing around and output the Bible text to a flat JSON format now shared on github.
Then I created a few JavaScript routines to navigate the text and perform basic operations required for navigation. I hosted the solution on StackBlitz to begin with as it is a good solution for shared web development with no local tools needed. I just wrote some JavaScript that output very simple HTML, and it was doing something useful very quickly. With some additional polish, it switched from outputting fixed results to populating drop down controls for the books, chapter numbers, and verse numbers, resulting in rudimentary navigation. This solution was shared back to a GitHub repository as well, and has since been revised to work more standalone from a local file system folder in addition to being hosted on the web.
All along the way I had planned to revive my Bible on Commodore project, and the idea was to leverage my existing cbmish-script solution, which provides a Commodore look while programming in modern TypeScript.
So I set out on that journey, and saw results right away. Almost all the bitmapped text on the screen is a link. First the navigation was limited to book/chapter/verse, allowing selection of book, book by book selection of chapter numbers, chapter by chapter selection of verse numbers, and navigation of the text verse by verse, with back links to book, chapter, and verse selections.
Added on was an about page, stats page, link to cbmish samples, and search for words.
Links are almost everywhere
Virtually every word and number on the screen is a link. Clicking on text will perform a search of that word showing other references to it. One of the latest features added is being able to replace the word (or phrase) searched for, to truly make this solution interactive.
How information is accessed, efficiency
How is the latest incarnation indexed? It is not. Each entry has book name, chapter number, verse number, and verse text. It is one long array of verses with this context in order.
To retrieve a specific verse, code scans the entire array for that data, returning a match.
How much data? About 4 megabytes. Or 6 megabytes with references per entry. Almost 32,000 records/verses in this flat file format.
The operations involved include retrieving the book names, counting the chapters in a book, counting the verses in a specific book/chapter, retrieving the text of a verse, retrieving all the verse records for a chapter, and finding the verse records containing a specific word or word portion.
Is it slow? No. It just works. Scanning the 6 megabytes of data is fine on a modern desktop computer or mobile device. Even retrieving a list of all verses containing an "e" or "the" seems instantaneous.
I was not used to this kind of performance or memory or storage capability when originally coding Commodore or embedded development platforms. But fast processors with lots of resources handle these tasks with ease. It's almost like they were designed to handle big 3D virtual games and a few megabytes of text is no big deal.
Is it a waste? Is it inefficient? Sure, but today megabytes are measly, and cycles are cheap too. When should we optimize for speed and energy? Of course the answer is that it depends. As this is an interactive application used by a single user occasionally, and performance is absolutely fine, no optimizations are necessary. We are done!
If you are developing a multi-user system in a VM process in a server farm where you are paying for resources, you may need to prioritize your optimizations for cost, energy use (be a good steward!), and performance.
It would be easy enough to adapt the flat file into a hierarchical structure, and add indexing for words and text. Handling this complexity is a useful skill even if the performance/processing optimizations are not at all necessary. For now it's just useful enough to consider what effort would be necessary rather than actually performing the extra work.
Comparison with Commodore
It looks like a Commodore 64 because the resolution, fonts, colors, and behaviors are the same or similar.
Though a port to a Commodore would require some special work including the indexing.
Storage - original Commodores didn't have megabytes of storage. Using an SDIEC or similar may be possible, or another hard disk solution. Another choice would be to offload to an add-on board such as ESP32 and optionally a web service.
Most Commodores didn't have a mouse back in the day, and mouse handling would require extra work too. Additional software and hardware is required, or use of emulation.
All in all, developing the cbmish-script environment alleviates much of the resource limitations of the original Commodore microcomputer and while it may not be a technically accurate representation, it provides much of the look and feel of the original system.
Cbimsh-script technical details
cbmish-script uses multiple canvases to provide the border, background, foreground, and sprite layers which are drawn independently, and combined by the browser software. Commodore fonts are drawn pixel by pixel with both character sets available to be displayed simultaneously. Transparent pixels allow a lower level behind to show through (like background).
Mouse support is provided with click, mousemove, mouseleave window event handlers for the sprite (highest visible) layer. Clickable regions and buttons are drawn highlighted (or unhighlighted) when hovered to demonstrate they may be interacted with the mouse. Similarly they animate when clicked on a touchscreen device. The cbmish-script system keeps track of a list of active buttons and is able to compute which ones are being interacted with.
This Bible software leverages these regions to also act as a text input field. When the region is clicked on, it activates a bounding box for the region to limit screen updates and cursor movement to that region, exited when Enter or Escape keys are pressed, or the mouse clicks outside the region. An onexit handler regains control and is able to grab the modified text from the screen.
Before these changes, cbmish-script had limited input capabilities. It had operated in a display only and echo only capacity, displaying what is typed, not intelligently responding to input.
What could be added next?
Next I should add more input and graphical capabilities to cbmish-script. And/or a responsive mode that changes resolution and orientation with the mobile device or browser window. Maybe add a Bible reading plan/tracker, bookmarks, multiple search terms, and a master word list. Add another Commodore emulator to my repos? Just ideas for now.
If it looks like a Commodore, acts like a Commodore, and feels like a Commodore, is it a Commodore? Not always. This cbmish is not a Commodore, and not made by Commodore Business Machines (CBM). But it is like a Commodore, thus the "-ish" (means like).
Cbmish is like a Commodore. This web software solution provides the feel of a Commodore in a web browser. There's a retro look and feel. But with a more modern programming language.
READY.
But it says "READY." Is that BASIC? No, it is lying to you. It is not ready for commands. It won't PRINT or GOTO. It is only ready for typing at this point. You can navigate the screen with cursor keys and typing letters, numbers, punctuation, and other symbols. You can change colors, type PETSCII, change to upper/lowercase, switch to reverse characters. It does feel like a Commodore.
Mouse
It also responds to mouse motion and clicks. That's not a Commodore I ever owned. Those rounded corners and text are buttons, and there are links too. Clicking on a rounded button will present the user with a relevant sample screen, or navigate to another web page. Colors may change, graphics may be drawn, text will display, and sprites may move.
Why?
So why do this? The about screen goes into some detail. I'm ready to move on from BASIC (gasp!) and 6502 Assembly (gasp!) and I don't really want to program on my Commodore (gasp!), but I do want to continue the look and feel of Commodore. My current efforts are web based and I have been using TypeScript from some years now. My skill is mostly is C languages (C, C++, C#) and while I had shunned web development for sometime, my professional and hobby efforts have collided with doing full-stack development including C# and also TypeScript.
While interpreted languages aren't usually my thing (though I love me some AWK) I have seen features of JavaScirpt and functional programming influencing C#, and of course there are underpinnings of C in TypeScript too, and similar functional programming in JavaScript/TypeScript too. While they are all quite distinct languages, there is enough familiarity between them, also also gotchas that keep them interesting when they are different. It's fun to know multiple languages!
This is stuff you could do with your real Commodore, but it's done here using TypeScript written code. TypeScript that is transpiled to JavaScript so it runs in the user's web browser. A combination of HTML, CSS, and TypeScript results in code to provide the cbmish interfaces to present things like one of the favorite 80s retro systems.
You can code interactively using the browser developer tools, or you can launch Visual Code (or similar) with typescript compiler dependency to have code transpiled as soon as you save. Instructions for both are on github in the README (see link below).
10 PRINT "Hello ";: GOTO 10
So do you really want the equivalent of PRINT/GOTO? Well this will have to do, see immediate mode JavaScript entered into the console of the development tools of Google Chrome web browser.
PRINT/GOTO equivalent
Conclusion
So long story short, it's a fine time to do Commodore like programming on the web, in a modern language. Take the best of modern languages and pair that with the look and feel of a great retro computer. Are you keeping up with the Commodore? Because cbmish is keeping up with the web.
The BASIC commands are implemented, small font created, and demonstrations implemented. Please enjoy this Space War and Omega Race inspired flying ship.
Source, disk image, and more details are on github for Commodore Vic-20 with memory expansion.
BASIC extension command syntax is:
COLOR [foreground[+8][,[background][,[border][,auxillary[,inverse]]]]]
COLOR [foreground[+8]] @ x1,y1 [TO x2,y2]
TEXT
HIRES xresolution, yresolution [,fillbyte]
DELAY jiffies
PLOT COLOR ON|OFF
PLOT [NOT|CLR] (@ x1,y1)|(TO x2,y2)... **
PLOT 0|1|2|3 (@ x1,y1)|(TO x2,y2)...
PLOT "ABC" @ x,y [,addr [,width,height [,bytes]]]
RECT [NOT|CLR] [@] x1,y1 TO x2,y2
RECT 0|1|2|3 @ x1,y1 TO x2,y2
SHAPE GET|PUT|OR|XOR|AND|NOT|CLR addr @ x1, y1 TO x2, y2
