My Survival Guide to using a C64 today

Are you using a Commodore 64 keyboard and disk drive today?  I try to, and I can't live without some combination of the following.  (Self-promotion disclaimer - I created software for 1 & 2)

1. Remap the keys to match my PC keyboard muscle memory

• patch your KERNAL ROM (physically, virtually, or run in RAM)
• run a software keyboard remap driver (pre-built, or edit your own mappings)
• use positional keyboard mapping if using an emulator

2. scroll through program listings and make editing on the C64 more enjoyable

• SCRLEDIT Scrolling BASIC Editor original January 1988 Compute!'s Gazette, and updated
• SCRLEDIT2 Scrolling BASIC Editor updated 2025, more features, different keystrokes
  
  (note: not currently compatible with remap driver because of the way they sit in memory and hook the keyboard table vector for key presses.)

3. Use microSD or similar solution to managing disk images and files instead of floppies

• SD2IEC
• Pi1541
• Or a modern C64 replacement (Commodore 64 Ultimate, Ultimate64, TheC64)
• Many emulated C64 solutions support drive images, and host directories (e.g. VICE)

Patch Commodore 64 Kernal Roms to remap keyboard

Punctuation remapped Commodore 64 keyboard layout

I have presented software and drivers to remap the Commodore 64 keyboard before.  But those solutions install into lower BASIC RAM at a fixed location, and disappear when you restart your computer.

Because the KERNAL ROM stores the keyboard mappings (4 maps: Normal, Shift, Commodore, and Control), if you can replace the ROM, you can remap the keyboard.

Here I present a new program of mine: 64KEY ROM PATCH (PRG) added to c-keymaps project.

This program will find where the keyboard mappings are, and with a patch list (DATA statements) containing shift mask, key scan code, and PETSCII character, will patch the ROM into RAM with changes and activate the ROM.

From here, you have some choices.  You can use the program on demand as is, or make the change more permanent.

For those with physical machines, there are already processes for replacing your ROMs.  You can search for them.  Now that the ROM is in RAM, you can figure out how to save to a file, transfer to your PC, and flash a ROM replacement to insert into your C64.   This change is semi-permanent in that the keyboard mapping will be there as long as the new ROM (usually EEPROM) is in place.

If you have a ROM switcher capability (Easy Flash 3), or a toggle switch allowing physical switching between multiple ROMs (may be piggy backed with a toggled chip select), then you change on the fly.

And if you run an emulator, you can save the patched ROM into your collection of C64 ROMs and choose it as your current ROM.

The BASIC program includes the following maps (effect is shown in the screenshot above):

300 rem patch table
310 rem shift,scancode,petscii
320 data 0,40,45:rem + to -
330 data 0,43,61:rem - to =
340 data 0,46,91:rem @ to [
350 data 0,49,93:rem * to ]
360 data 0,54,92:rem ^ to \
370 data 0,45,59:rem : to ;
380 data 0,50,39:rem ; to '
390 data 0,53,13:rem = to return
391 :
392 data 1,59,64:rem " to @
393 data 1,19,94:rem & to ^
394 data 1,24,38:rem ' to &
395 data 1,27,42:rem ( to *
396 data 1,32,40:rem ) to (
397 data 1,35,41:rem shift 0 to )
398 data 1,40,95:rem shift + to l.arrow
399 data 1,43,43:rem shift - to +
400 data 1,53,141:rem shift = to s.ret
401 data 1,45,58:rem shift : to :
402 data 1,50,34:rem shift ; to "
408 data 1,57,221:rem shift _ to v.bar
409 data 2,57,219:rem cbm _ to cross

Commodore Programmer's Keyboard References

C128 scancodes

Composite C64 and C128 keyboard references

Composite plus/4 and C16 keyboard references

Vic-20 keyboard references

The programs are

• 64keymaps.prg
• 128keymaps.prg
• +4keymaps.prg
• 16keymaps.prg
• 20keymaps.prg

These and more are available at the following:

Link: https://github.com/davervw/c-keymaps

C64 keyboard remapper, these keymap displays, and related utilities

Commodore BASIC .TXT listing out and in

This image shows a quick-reference for how to LIST out to a file, and have BASIC type in a listing from a file.  This is not original work except for fixing the port to plus/4 and similar.

Links:

• https://www.sx64.net/info/disk_commands.html
• https://www.scribd.com/document/1055555189/Twin-Cities-128-Issue-08

(plus/4,16,116 version is a careful and thoughtful port of the sx64.net version, meaning AI Gemini tried really hard, but kept getting confused by C64 knowledge.  AI got the 2035 and 810 addresses right, but I had to research the values to poke.  Informing AI of the correction, it kept trying to supplement the answer getting it more wrong, so I put an end to that!)

Extending C128 BASIC using REM statement parameters

 

So on the C64 you could have commands like SYS 49152,X,Y,"TEXT" where your machine/assembly code could specifically parse the commas and numbers.  The result was a way to interface between BASIC and Assembly to use the best of both worlds.   BASIC is easy to edit, debug, and change.  6502 is fast and can do some low level operations including accessing all 64K RAM, and all the ROMs.

BUT!!!   On the C128, the SYS command was extended to allow ease of passing registers.  This is fine if you want to transfer data in 0..255 chunks.  But coordinates on the screen are 320x200, so that goes past a byte, and addresses are 0..65535, they definitely go past a byte.  And strings are another animal.

On the C128 the statement SYS 4864,1,2,3 will call the routine with .A, .X, .Y registers populated with 1, 2, and 3 respectively.  That's fine and dandy, but if you want to do something more, you have to do it another way.

Here comes the new syntax:

SYS 4864 : REM 300, 65535, "Hello C128"

By using the token getter, you can check for colon, REM token, then proceed to parse values and variables as before on C64.  (With the exception that I couldn't get expressions like 2+3 to work, maybe something to do with REM.  But we can work around that.)

Check out the github repository for program listings including commented assembly for more details, and to grab a copy of the D64 containing the PRG.

Touch points and buttons on M5Core 2" displays, Tab 5" display, and Sunton 7" display for keyboard emulation

I have targeted the following M5 Stack models with my C64/C128/Vic-20/Apple 1 emulator:

• M5Stack Fire IoT
• M5 Core2
• M5 CoreS3

(Even though I have targeted other boards, I had only implemented touch on the CoreS3)

The primary reason for targeting these boards was the common 2" 320x240 display perfect for most C64 emulation, and the availability of a wristband that works with Core2 and CoreS3 (it works with the Fire if and only if you never need to charge the battery - not aware of a universe where that works out long term).

[aside... Originally I had supported the M5 Core Basic, but without PSRAM, it was difficult to support the different computer models that currently load into that memory.  So M5 Core BASIC was dropped after its initial development.]

The Basic and Fire have three UI hardware buttons.   The Core2 has three virtual touchscreen buttons (touchscreen expands farther down from the LCD screen to allow for capacitive touch button points, and the M5 library abstracts them similar to physical buttons, so your code doesn't even have to know the difference).  The CoreS3 has no UI buttons, but I've manually implemented virtual touch screen buttons at the bottom of the screen.   From left to right the buttons are known to M5 as A, B, and C.

So button support for Basic, Fire, and Core2 was straightforward.

• press Button A: Cursor UP
• press Button B: RETURN
• press Button C: Cursor Down

With hold functionality as well.

• hold Button A: toggle computer model (C64, C128, Vic-20, Apple 1, repeats)
• hold Button B: LOAD"*",8 / RUN for Commodore, snapshot system for Apple 1
• hold Button C: STOP

Thus, one can demonstrate the emulator loading a menu of programs, scrolling though the listing, and choosing one.  And toggle between the emulators.   The Apple 1 snapshot system allows choosing a snapshot and loading or saving it.

I support other hardware targets, and I have BLE pairing functionality.  So I am thinking of expanding support of the virtual buttons, including more virtual buttons, and providing 8-position joystick inputs (and button) too.  But for now, here is the documentation for the existing buttons.

And then just like that, the CoreS3, Tab5, and Sunton 7" now have more touch points implemented for their capacitive touch screens to allow for more virtual keys.

BLE HID coprocessor for microcontrollers

 

Teensy in green, ESP32-C3 in blue

I have a Teensy 4.1 operating as a Commodore 64 (and Vic-20, and 128, and Apple 1) emulator.  It already supports USB Host (via 5 pin header on top) and web page helper (via USB CDC).

The Teensy doesn't have wireless capability, but I wanted to add BLE keyboard support.  So enter the ESP32-C3 as a coprocessor.  It is running a custom firmware using the NimBLE library to enumerate BLE HID devices in pairing mode, and connects as soon as it finds one. If everything works successfully, it sends HID reports as ASCII over the UART channel (received at Teensy RX pin 0).  

While the Teensy is busy driving the LCD with a bunch of connections, the ESP32-C3 is only wired at 5V input, ground, and a TX pin.  The ESP firmware is built without USB CDC support so that the Serial line defaults to GPIO.  

Shown is a USB only ESP32-C3 board with the advantage of being slightly cheaper.  When I purchased it years ago when ESP32-C3 was relatively new, it was about US$2 on AliExpress.  Looking today, there's even more choices available in all sorts of price ranges and sizes.

So the Teensy is doing what it is good at, and the ESP32-C3 is filling in a wireless connection gap.  The red jumper is provided to be able to pull power.  Though the power connection does have its advantage that the ESP32-C3 has a USB-C port, while the Teensy has a USB-Micro connector.

Look Ma -- no wires!

Mouse, Trackpad, and Gamepad/Joystick are supported as well.  Gamepads and Joysticks will require HID maps which are loaded but not interpreted yet, nor passed on the interface (work to be done).  Joystick support is not implemented yet in my emulators, but stay tuned!

Update (2026-07-03): coprocessor firmware updated to support my custom BLE CBM keyboard sources, and optionally convert standard HID reports to Commodore key scan codes.  By focusing on Commodore scan codes, the integration with the emulators is now simpler, and seamlessly supports more of my keyboards -- while also as being an option, the coprocessor can be used by those that expect standard HID bytes. (Note: no conversion from Commodore to keyboard HID, only the other way around.)