Patch Commodore KERNAL ROMs to permanently remap keyboard

Figure 1. Result: ROM patch statements for C128

Already there is a solution for Commodore 64 systems including patching ROMs into RAM in real-time, in addition to building a patch file for making your own ROM (e.g. physical EPROM) or file for emulator.

With a few more additions, the following platforms are also supported for EPROM or emulator .bin file:

• 128
• plus/4 or 16 (264 series)
• Vic-20

All of these, plus the 64 are now supported via c-keymaps on github.

(Alternatively drivers are supported in the same project for 128 and Vic-20 for remapping in real-time, using additional system resources, which also allows remapping of the Alt keymap for 128)

Figure 2. Source: C128 DATA statement specifying keymap patches

Directions for patching a ROM.

1. LOAD the appropriate rom patch file for your system from the files folder, or drive image. You MUST match your system exactly.
• 64KEYS ROM PATCH
• 128KEY ROM PATCH
• TEDKEY ROM PATCH
• 20KEYS ROM PATCH
2. LIST the program, and review the keyboard mapping included in DATA statements in the file, refer to keyboard table references for key scan code numbers of your system, and verify the layout changes you desire.
3. RUN the program
4. Transfer the patch statements to your modern system.  These are a series of hex offsets, followed by colon, followed by one or more hex bytes.   The offsets have the ROM starting address subtracted, so they are offsets from the start of this individual ROM (see figure 1).
5. Get an original KERNAL ROM file (image your own ROM, or download from zimmers.net, or copy from VICE emulator).
6. Make a copy of the KERNAL ROM .bin image file, and name it appropriately anticipating the patch being performed.
7. Verify the size of the KERNAL ROM file
• C64: 8K
• C128: 16K
• plus/4: 16K
• C16: 16K
• Vic-20: 8K
8. Patch with xxd
   xxd -r patch.txt new.bin
9. Transfer the file into an EPROM or equivalent compatible for physical system only
   
10. Install the physical EPROM into your physical system, or binary file into your emulator (VICE system settings)
11. Enjoy!

Note: recommended to test your patches on an emulator first (or Commodore 64 in RAM patches, compatible with the most critical C128 keys), especially if not on a C64/128.   The debug/test cycle is faster with an emulator.  And consider whether your mapping is best suited for positional or symbolic keyboard mapping in the emulator.  If you prefer physical machines, use the emulator temporarily, or skip it, and good luck! (It took me over 5 iterations to get it right for the Vic-20.)

You may also have your Commodore save all output of the running program to a .txt file so you can transfer to your computer and extract the patch statements. Note: do not use RUN because it will close the file, use the first statement, and be sure to include CLR first so variables are reset, uninitialized.

CLR:OPEN1,8,3,"PATCH.TXT,S,W":CMD1:GOTO100

When done, be sure to close up

PRINT#1:CLOSE1

My Survival Guide to using a Commodore 64 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

More detailed instructions are available.

Commodore Programmer's Keyboard References

Commodore 128 scan codes

Composite Commodore 64 and 128 keyboard references

Composite Commodore plus/4 and 16 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.