Dan's MEGA65 Digest : Dan Sanderson

Taste the Rainbow. Dan’s MEGA65 Digest for June 2025.

Hey all! I’ve been a bit busier than usual lately, so this Digest is tardy. If we could all pretend that it’s still June for just a few moments I’d appreciate it.

A character graphics system limits the amount of memory needed to describe what appears on a raster display, and thus the amount of computation needed to update it. It does this through indirection: instead of describing every pixel on the screen, it describes a smaller set of repeatable patterns, or characters, along with a description of where those patterns appear in a grid.

Such systems typically apply a similar idea to color, finding benefits in describing characters and colors separately. For example, declaring the character to display and its color separately allows a program to reuse the image data in different colors. Flexible color systems such as the MEGA65’s VIC-IV also use indirection for defining the colors: color data references entries in a palette (“color #2”), and each entry describes the color value to use when the entry is referenced (“2 = red”).

Last month (remember we’re pretending it’s June), we began exploring character graphics using the built-in PETSCII character set and the default system palette. We covered how to describe the display in terms of these presets with data in screen and color memory. This month, we’ll look at defining custom colors and custom character images. We’ll take this opportunity to explore two color-related alternate display modes from the VIC-II era, and see how different graphics modes make tradeoffs to give us more options.

Let’s do some Features Files, then get right to it.

muse has three arcade cores for us this month:

Kiwi has given us a beta release of a text editor: Mega Edit. Some features are still in progress. Inspired by Compute!’s SpeedScript.

Fifth Wins by Hanyic Róbert, a two-player logic game. Play against the computer or another player.

Great work everyone, keep it up!

Let’s make a card game! The PETSCII character set has symbols for the four playing card suits. You can type these directly onto the screen: hold Shift, then type A, S, Z, or X. Just as on a Commodore 64, the keys on your MEGA65 have their corresponding graphics symbols printed on the front. Hold Mega to type the left-hand symbol, Shift for the right-hand symbol.

To draw the playing card image above, I typed the graphics symbols as follows:

Try drawing your own playing card by typing into the screen editor.

Remember, a screen code refers to an entry in the active character set. When you type Shift + A, the screen editor writes screen code 65 to the location in screen memory that corresponds with the cursor position. See “Appendix D: Screen Codes” in the User’s Guide.

If we wrote our card game in assembly language, we might represent the card images as screen codes in our program data, and draw them by storing these codes directly into screen memory. A BASIC program could do the same with T@&(X,Y) = ... and C@&(X,Y) = ..., or use POKE with the screen memory address as shown in the last Digest.

Another way to draw the cards is to manipulate the screen editor’s cursor. This is what happens when a BASIC program uses the PRINT command, or when an assembly language program calls the CHROUT KERNAL routine. Instead of a screen code, the program emits a PETSCII code that tells the cursor what to do. Some codes print a character at the cursor’s position and in the cursor’s color. Other codes change the cursor’s color or position. We explored PETSCII codes in a previous Digest. The screen editor implements the cursor’s behavior by writing screen codes to screen memory and color codes to color memory.

So what’s the deal with these color codes? Each available color is assigned a number. The number written to color memory for a location on the screen determines the foreground color of that character. The background and screen border also each have a color code, stored in dedicated registers.

BASIC 65 has commands that can change the background and border colors. Try these with numbers in the range 0 to 31:

For a list of the default colors of the system palette, see “Appendix E: System Palette” in the User’s Guide, or refer to this chart:

The C64 has a fixed palette of 16 colors, numbered 0 to 15. I’m used to thinking that 0 is always black, 1 is white, 6 is blue, etc., and might be comfortable calling these “color codes.”

On the MEGA65, you can change the color of any entry to any of 4,096 possible colors. Here, color codes are probably better known as “palette codes.” Similar to a painter’s palette, you can put any color you want into any palette entry.

I want the background color for this card game to be a dark green, like the felt of a traditional card table. The default system palette doesn’t have a dark green. But no worries, we can make our own:

The PALETTE COLOR command takes a palette code, and a value for how much red, green, and blue to mix into the color, each a number from 0 to 15. The MEGA65 is mixing light, not paint, so the more color you add, the brighter the result. 0,0,0 is black, 15,0,0 is bright red, 15,15,15 is white, and so on. Here, I chose 0,7,0 for the green felt. Feel free to adjust this to your taste.

To set a system palette color from machine code, write the value from 0 to 15 to each of the red, green, and blue palette registers. The reds are at addresses $D100 to $D1FF, the greens are $D200 to $D2FF, and the blues are $D300 to $D3FF. For example, to change palette entry #22 (hexadecimal $16) to felt green, as above:

A palette actually contains 256 entries, not just the 32 entries accessible by characters in our current text mode. The PALETTE COLOR, BACKGROUND, and BORDER commands support all 256 entries, numbered 0 to 255:

There are a few ways to give characters access to more of the palette. We’re about to see two limited but interesting ways. We’ll cover full-color character modes in a later issue.

The VIC-IV has four palette banks, each with 256 entries. The character system and the sprite system can use any of the four banks, and you can set characters and sprites to use different banks at the same time. There are not yet BASIC 65 commands for using other palette banks, but this is planned for a future ROM update (see issue 220, 221).

Palette bank selection goes through two-bit registers at address $D070. Each bit pair can select palette 0 (%00), 1 (%01), 2 (%10), or 3 (%11).

Here’s a quick demo. Enable sprite 0, set it to palette entry 7, and move it onto the screen:

Next, change hardware sprites to use palette bank 1 instead of 0:

The AND %11110011 clears bits 2 and 3, while preserving the other settings. The OR %00000100 sets SPRPALSEL to palette bank 1, also while preserving the other settings. Yes, you can use SETBIT $D070,2 : CLRBIT $D070,3, but using POKE in this way ensures that both bits are set simultaneously with no time for the VIC to get confused while it is drawing.

Finally, change palette entry 7 of palette bank 1 to aquamarine:

Now switch the cursor to palette entry 7: press Ctrl + 8 (yes, 8). The cursor switches to yellow, and you can type yellow text. Characters are using palette bank 0 while sprites are using palette bank 1.

What would happen if you switch characters to palette bank 1? How would you do this with a single BASIC command?

So far, we’ve been exploring character graphics using the built-in PETSCII character set. We can customize the character set to use any collection of 256 8-by-8 images that we want. This is one of the most powerful ways to add graphics to a game, and many Commodore games use custom character sets for game objects, backgrounds, and alternate text fonts.

A character set contains 256 character images, and each character image is 8 bytes, for a total of 2,048 bytes (2 kilobytes). The images are ordered by screen code.

A copy of the PETSCII character set is built into the ROM, starting at address $2.D000. We can find the image data for the suit symbols in this area using the screen code. For example, the spade is screen code 65, so its image data starts at byte offset 65 x 8 = 520 = $0208 from $2.D000, or address $2.D208.

Here’s a program that makes it easy to inspect a character of the PETSCII character set. Try changing line 10 to inspect other screen codes.

The PETSCII character data in ROM consists of two character sets, one for uppercase and graphics, and another for lowercase and uppercase. When you press Mega + Shift to change the letter casing mode, it is just switching between these character sets. The lowercase variant starts at address $2.D800. Try modifying this program to display screen codes from the lowercase character set.

On the Commodore 64, the VIC-II starts in a state that uses the PETSCII character set from the built-in ROM. A program can tell the VIC to use a custom character set instead by setting registers to an address in RAM where the charset is stored. As a kid, I wrote many programs that would copy the PETSCII charset from ROM to RAM, point the VIC to the RAM address, then make changes to certain characters.

The VIC-II integrates with the C64’s memory system in a somewhat complicated way, with restrictions on what memory the VIC can see and where in memory graphics data can be located. The MEGA65 emulates these methods for backwards compatibility. I won’t explain these methods here, because the MEGA65 offers other ways to use custom character sets that are easier to understand.

The VIC-IV provides a 24-bit pointer register, CHARPTR D068-D06A, that can locate the active character set at any address in the first 384 KB of memory. Here’s a simple demonstration that sets CHARPTR to the location in ROM where FONT B is stored ($3.D000):

Note that as of ROM 920416, Run/Stop + Restore does not restore CHARPTR to its default. This will be fixed in a later update; see issue 236.

Similar to changing SCRNPTR to quickly switch between sets of screen memory, a program can use CHARPTR for special graphical effects that require quickly switching between character sets.

For backwards compatibility with the VIC-II, CHARPTR treats addresses in the ranges $00.1000 - $00.1FFF and $00.9000 - $00.9FFF as special. When looking for character set data, the VIC-IV translates these addresses to a special area of memory, the VIC-IV character set buffer, at $FF7.E000 - $FF7.EFFF. The MEGA65 sets up this buffer with the PETSCII character set that the VIC-II would expect in ROM at these addresses.

It turns out, the VIC-IV character set buffer is more useful to MEGA65 programs than was originally intended.

When the MEGA65 starts, it copies the PETSCII font from ROM to the VIC-IV character set buffer at the address range $FF7.E000 - $FF7.EFFF. Similar to a C64, the computer starts with CHARPTR set to $00.1000, so it uses $FF7.E000 for the active character set, uppercase PETSCII.

Early MEGA65 developers noticed that programs can write directly to the character set buffer. In many cases, you don’t have to hassle with copying ROM to RAM or re-pointing CHARPTR just to get a custom character set. You can just poke directly into the buffer to change what it thinks “character ROM” is. This is totally cheating! Kids today don’t know the pain of throwing 2 KB of RAM onto the fire just to customize the font.

BASIC 65 takes full advantage of this capability. The CHARDEF command locates the character’s image data in the buffer via the screen code ($FF7E000 + C * 8), then writes the new image data to that location. Similarly, the FONT C command resets everything back to the PETSCII font by copying the character set from $2.D000 to $FF7.E000.

Here’s an equivalent program that writes values directly to the character set buffer. This illustrates values in DATA statements, but this could easily come from a file. (This resembles how you’d do this in assembly language.)

It’s common for games to completely replace the character set with a custom font, as well as with tiles for in-game graphics. On the MEGA65, this is as simple as loading that data into the character set buffer. For a quick experiment, we can find C64 character sets on the Internet that have been extracted from vintage games and various versions of Commodore ROMs.

Try this:

If the file is a .64c file, invoke BLOAD like so, to skip the two-byte address header and load the data into the buffer:

If the file is a .bin file, provide the ,R argument to tell BLOAD that the file does not have an address header:

See also Commodore character ROMs at zimmers.net, and C64 fonts by patrickmollohan. These archives distribute .bin files, so use BLOAD ..., R with these.

When you’re done enjoying the custom charset, press Run/Stop + Restore to return to PETSCII. (Run/Stop + Restore does know how to reset the character set buffer.)

This playing card looks roughly like the Ace of Spades, but something is off. The characters on the card are drawn with reverse characters, using white for the foreground color and letting the green background through for the card’s value and suit. Ideally, we’d draw the value and suit of the card in black (spades and clubs) or red (hearts and diamonds) onto the white card surface. Can we do this, and still keep our green background?

For that, we need to introduce a new graphics mode. Extended Background Color Mode (ECM) allows us to choose three additional background colors (for a total of four), and select from one of the four background colors for each character individually. ECM works the same way as it does on the Commodore 64’s VIC-II chip. With the MEGA65, it also works in the higher resolution text modes and with custom palettes.

ECM comes at a price. The Commodore 64 did not have additional memory for storing background color selections for each character, so instead, ECM steals the upper two bits of the screen code for this purpose. This leaves fewer bits for selecting a character from the character set, limiting the selection to the first 64 screen codes.

To enable ECM, set $D011 bit 6. The registers for the four background colors are $D021 (the normal background color register), $D022, $D023, and $D024. These registers can be set to any of the 256 entries of the selected character graphics palette.

The following program draws all 256 screen codes onto the screen, waits for a key press, then enables ECM. The selected background colors are blue (6), black (0), red (2), and purple (4).

Remember how the screen editor’s blinking cursor toggles bit 7 on the screen code, which normally goes back and forth between normal and reversed characters? With ECM enabled, this actually flips between two background colors. This is a neat effect—unless the two background colors are the same, in which case the cursor becomes invisible.

Extended Background Color Mode seems like it would be useful for our card game. The regular background color is our custom felt green color, there’s an alternate background color we can set to white for the card background, and the text on the card can be any of the first 32 palette entries, such as black-on-white or red-on-white.

Maybe you’ve already noticed: there’s a problem with this plan. ECM denies us access to the characters we were using to draw spades, clubs, hearts, and diamonds, not to mention the snazzy border characters. We only get 64 possible characters in this mode, and they’re showing up as letters, numbers, punctuation, and that’s about it. What else is there to do?

Custom character sets to the rescue! We just need to replace four of the available 64 characters with the images for the suit symbols, and use those characters to draw cards.

We could figure out the bytes for each symbol and write them into our program as above. In this case, the characters we want are already in the character set, so we could just copy them down. The screen codes for the spade, club, heart, and diamond are 65, 88, 83, and 90, respectively. Let’s copy these to slots 27, 28, 29, and 30.

Here’s the updated character set with ECM enabled, with the copied symbols.

With the appropriate background color settings, we can now draw values and suits in their correct colors, over a white card background, on a green felt tabletop.

To get those nice border characters, I could sacrifice eight more punctuation symbols. Every project has to decide what it needs and what it’s willing to give up.

The VIC-II has another way to get more color into its characters. In Low-res Multicolor Mode (MCM), a character can use any of four possible colors for each pixel. As always, you can’t get something from nothing, and this comes with tradeoffs: each pixel is doubled in width, and a character is four such pixels across.

The character set data is still one byte per row, with each pair of bits selecting the color for that double-wide picture element. These bit-pairs select the following color options:

As with ECM, the background and colors $D022 and $D023 apply to the entire screen. Bit-pair %11 selects the foreground color, which can be different for each character, as usual.

You can mix high resolution and low resolution characters on the same screen. This is great if you want to display PETSCII text alongside low-res high color images. But yes, this comes with another tradeoff. With MCM enabled, color bit 3 determines whether the character is hires (0) or lowres (1). You can only use the first 8 palette entries for the foreground color.

MCM also ignores color bits 4 through 7. Character attributes are disabled with MCM enabled.

Sound like fun? Let’s try it.

This program defines a character pattern using all four bit pairs, then displays eight of these characters in hires mode in the first eight colors, followed by the same eight characters in lowres mode. Press a key to disable MCM to see all sixteen characters in hires mode. Try experimenting with different character patterns, color combinations, and color attribute values.

If these tradeoffs make Low-res Multicolor Character Mode seem a bit disappointing, consider this: The MEGA65 has customizable palettes, so you have quite a few more color options than on a C64. Also, the MEGA65 has double the horizontal resolution of a C64. If you’re willing to give up some space in the character set, you can display a full 40 columns of four-color characters.

Extended background color mode and low-res multicolor character mode are two ways the VIC-II, VIC-III, and VIC-IV give you more options for displaying character graphics. They work by changing the way screen code bits are interpreted, trading off one capability for another, using the same amount of screen memory as normal (hires, low color) text mode. This was critical with the C64, which didn’t have more memory to spare.

The MEGA65 comes bundled with 384 kilobytes of memory usable for graphics. What could the VIC-IV chip do for us if we give it more memory? We’ll find out next month. Er, this month. You know what I mean.

This Digest is made possible by a group of amazing people making monthly donations. If you’d like to join this group, visit ko-fi.com/dddaaannn.

Happy hacking!

— Dan

Character Study. Dan’s MEGA65 Digest for May 2025.

It’s upgrade season in the MEGA65 community! We partied hearty for the 10th anniversary last month, and the result is an all-new stable release of the MEGA65 platform packed with features and bug fixes, a bug fix update to the C64 core, and a new version of the M65Connect app. We also finished up the Screenful of BASIC compo, with 26 entries!

For this month’s feature article, I’m starting my series on MEGA65 character graphics. It’s a big subject that we’ll cover over multiple issues. We’ll probably take breaks to cover other subjects just to mix things up.

Here we go!

It’s here! Over 14 months in the making, the new MEGA65 platform release v0.97 is now available. The MEGA65 team recommends that all owners upgrade to this version.

Sign in to Filehost with your registered owner account, then download the release package appropriate for your mainboard version:

Upgrade instructions are in the latest User Guide. Remember to copy the SD card files to your SD card, including the .M65 system software files and the MEGA65.ROM file.

Also remember to install the core in slot 1, then also in slot 0. Upgrading slot 0 is easy if you previously upgraded slot 0 to v0.96: press Mega + , (comma) from the core selection menu to start the process. If you have an older core in slot 0, you’ll need to start v0.97 from slot 1 then immediately press and hold No Scroll to re-open the newer version of the core selection menu, then press Mega + , and proceed.

We reviewed the changelogs back in the March Digest. Check out all the new stuff you’re getting.

Various C64 cartridges tested with the C64 core.

While you’re updating cores, be sure to pick up C64 core v5.2. This maintenance release fixes several bugs, including the HDMI display bug that has blocked a minority of users with a set of vertical bars. It also adds support for COMAL 80, Simons BASIC, Waterloo Structured BASIC, Mikro Assembler, and BMP-Data Turbo 2000 as CRT files.

Huge thanks to everyone testing and contributing fixes to the C64 core!

M65Connect, the essential desktop companion app for the MEGA65, has an update also! Version 2.4 includes richer support for subdirectories, creating new D81 disk images, and many usability improvements. Whether you connect to your MEGA65 via Ethernet or JTAG adapter, or just move a microSD card between your MEGA65 and your PC, M65Connect is the easiest way to manage your files and perform other tasks.

Starting with M65Connect v2.4, macOS no longer complains that the app is “corrupt,” thanks to a long-awaited bug fix in a library that the app uses. As with many open source apps, the macOS version is “unsigned,” and the first time you run it will be blocked by the operating system. In macOS Sequoia, open the app, dismiss the message with the “Done” button, then open the Privacy & Security panel in macOS settings and scroll down to find the button to give it permission to run (“Open Anyway”).

Thanks as always to Tayger for this great tool.

The Screenful of BASIC Compo 2025 compilation disk menu.

From February to April, the Screenful of BASIC Compo 2025 challenged us to write a game, demo, or tool using just an 80x25 screenful of BASIC 65 code. There were 26 fabulous entries.

I put together a compilation disk with all of the entries and a browsable menu. Try them all!

After a friendly round of voting, three winners came out on top:

Want to know more about compact BASIC coding techniques? Check out The 8 Bit Theory’s YouTube video explaining his Screenful Compo entry, “Screenful Crawler,” a 3D maze in just 16 lines.

Several entries have already had updates and expanded versions published to Filehost, so be sure to check those out as well.

More amazing things recently uploaded to Filehost:

Don’t forget that you can follow the MEGA65Files bot on Mastodon or your favorite federated social media service. The bot posts about both new files and updates to existing ones. If you don’t have a fediverse account, you can also follow the bot’s page in your RSS reader.

When you first switch on your MEGA65, it shows a screen with a displayable area 640 pixels wide and 200 pixels tall, capable of displaying up to 4,096 possible colors. The MEGA65’s VIC-IV video chip determines the color of each pixel by reading graphics data from memory, and generates a video signal that draws the final image to the screen, many times per second.

If we were designing a graphics system, how would we design the data that describes the image drawn to the screen? One possibility would be to store the color of each pixel. This screen is 640 x 200 = 128,000 pixels. With 4,096 possible colors, each pixel needs to be stored as 12 bits. 128,000 x 12 = 1,536,000 bits = 192,000 bytes, or 187.5 kilobytes. That’s a lot of memory to dedicate to graphics data. Even if we could find a place to put it in the MEGA65’s RAM, it would require substantial computational power to update this memory to draw or animate objects, or scroll a playfield.

The most obvious way to reduce the memory demand of the graphics system is to reduce the quality of the image. Using a pixel resolution that’s 320 pixels wide instead of 640 cuts the needed memory by half. Reducing the number of possible colors to 256 (a bit depth of 8) cuts it by a third. Naturally, these changes diminish the amount of graphics information we can display. Instead of 80 columns of text, we can only display 40 columns. A program that displays a photograph has to settle for less detail or less color accuracy. Space aliens are chonkier.

There are other ways a graphics system can reduce its capabilities without making such obvious sacrifices in image quality—and this is where things get interesting. Many computer applications do not need the ability to set every pixel on the screen to any possible color at any time. By limiting the system’s capabilities to just what common applications need, a graphics system can use less memory to describe the full display, and still produce high quality images.

Character graphics are one such scheme. You probably already have a sense of how this works from typing letters, numbers, and symbols at the READY. prompt. In the default text mode, each of these symbols — let’s call them characters — is a small image, 8 pixels wide and 8 pixels tall. On our 640 x 200 pixel screen, 80 of these characters fit on a row, and 25 rows fill the screen. The graphics system knows what each character looks like from a character set stored in memory, containing the images for each of 256 possible characters, including a blank character to represent empty space. By assigning each character a screen code from 0 to 255, we can describe the entire screen in just 80 x 25 = 2,000 bytes of memory.

This scheme uses a monochromatic character set: each character cell is assigned a single foreground color, and the image in the character set describes which pixels should be set to this color. The graphics system uses another 2,000 bytes to describe attributes of each character cell, including five bits to set the foreground color. Each cell can use a different foreground color for its foreground pixels. All other pixels share a common background color for the entire screen, set in a VIC register.

Of course, five color bits can only represent up to 32 colors, not 4,096. Just as the graphics system uses a character set of 256 character patterns, it also uses a palette of 32 colors. Each palette entry is assigned a 12-bit color setting. The MEGA65 starts with a system character set of PETSCII symbols and a system palette of 32 pre-defined colors.

This character graphics scheme uses very little memory compared to the 12-bit pixel scheme, and allows for much faster updates. In exchange, it trades away flexibility in what images can be represented. The entire screen must consist of repeated patterns of 8 pixel x 8 pixel characters selected from a set of 256, only a single foreground color can be used for each character, and colors must be selected from a set of 32.

This trade-off is obviously worth it for text applications, such as the BASIC screen editor, a word processor, or a BBS terminal program. Less obvious, at least at first, is that character graphics are also useful for graphical displays for some games. The default PETSCII character set includes glyphs that can serve as game graphics on their own, such as the heart, diamond, spade, and club for playing card suits. Some symbols are designed to be combined with others in adjacent cells to draw larger objects. Commodore programmers and artists have been exploiting the default character graphics mode for decades, with spectacular results.

Both screen memory and color memory organize characters by row, starting in the top-left corner and going down the screen. For the default 80 x 25 text mode, each row is 80 bytes, so the first row left-to-right is represented by screen codes in positions 0 to 79, the second row is positions 80 to 159, and so on.

You can tell the VIC-IV chip to use any address within the first 384 KB of memory as the start address of screen memory. This is a special feature! The Commodore 64’s VIC-II, in contrast, has restrictions on which memory can be used as screen memory. With the VIC-IV, the starting address for screen memory is stored as a 28-bit address, in a register called SCRNPTR at addresses $D060 to $D063.

Here is a simple BASIC program that reads the SCRNPTR register to get the starting address of screen memory, then draws all 256 characters from the default character set in a nice rectangle:

WPEEK() is a special form of PEEK() that reads two bytes of memory and interprets them as a 16-bit value stored in little endian order. Line 10 reads all four bytes, and assembles them into a 32-bit number, in this case the address stored in SCRNPTR.

You can change the location of screen memory at any time by updating this register. This can be used for switching between multiple displays stored in different regions of memory, or for techniques such as screen scrolling.

Try this. Set the SCRNPTR address to $6000:

You are now looking at the contents of memory at address $6000, interpreted as screen codes by the VIC-IV chip, one byte per character. If you did this on Xemu, the screen is probably filled with @ symbols, which use a screen code of 0. On the MEGA65, this could be all manner of crazy characters, whatever happens to be in memory at that location.

If you did this just after switching on the computer, you may also see that the characters in the top left corner have retained the colors of the rainbow bar of the welcome banner. The VIC keeps screen codes and color codes in separate areas of memory, and so far all you have done is tell the VIC to look somewhere else for screen codes.

Another thing to notice: the screen editor’s READY. prompt and cursor have followed you to the new screen location. It’s cool that this seems to work, but note that not every feature of the KERNAL, screen editor, and BASIC know how to do this. Some features of the KERNAL still believe screen memory is where it originally put it. Reset the screen editor, including its SCRNPTR, by holding Run/Stop and tapping Restore. Or just reset the computer.

The Commodore 64’s VIC-II is capable of text in 40 columns and 25 rows. This was extended for the Commodore 65’s VIC-III to also support 80 columns. The VIC-III can switch between these two modes. In fact, this is how GO64 mode works: it downshifts the VIC-III into its VIC-II compatibility mode, including adjusting the screen to 40 x 25 text mode.

The 640-pixel wide 80-column text mode is controlled by the H640 register, bit 7 of address $D031. You can switch to 320-pixel wide 40-column text by clearing this bit:

Naturally, 40-column text uses less screen memory than 80-column text. It’s still using the same screen memory location of SCRNPTR, but only reading the first 1,000 bytes to describe the 40 x 25 screen. The memory layout is similar, organized by rows of 40 instead of 80.

Once again, the KERNAL doesn’t know you have changed modes, and still thinks the display is 80 characters wide. Re-enable 80-column mode:

The MEGA65 VIC-IV can also double the vertical resolution from 200 pixels tall (25 rows) to 400 pixels (50 rows). This is controlled by the V400 register, bit 4 of $D031. Try enabling it:

If you’ve tried the screen editor’s 80 x 50 mode before, this might look familiar—except there’s a bunch of garbage on the bottom half of the screen. Also, if you try typing multiple lines, it scrolls at line 25. What’s going on?

You guessed it: the KERNAL doesn’t know you enabled V400 mode in the video chip. The VIC-IV is now reading 4,000 bytes of screen memory starting at the screen editor’s internal location. This space is not meant to hold so many screen codes, and the KERNAL is using the latter 2,000 bytes for something else. Restore sanity by disabling V400 mode:

But wait, we know that the screen editor does support an 80 x 50 mode. Press Esc then 5 to enter this mode, and notice that the screen is nice and clean, and you can use the full space. How does this work?

We can get a hint by inspecting the SCRNPTR register while this mode is active:

Notice the address that it prints. Switch back to 80 x 25 mode (Esc then 8) and enter the command again.

The screen editor uses a different SCRNPTR address for 80 x 50 mode, switching to a location with more space to use as screen memory. It also keeps track of which mode you selected, so it knows how many rows and columns it should be using in this space. It does not check the H640 and V400 registers in case some smart aleck changed them, so it is easily fooled if you don’t switch screen editor modes properly.

Can the VIC-IV display text 40 columns wide and 50 rows tall? Only one way to find out.

Each character on the screen has a corresponding color code assigned to it. The code refers to a color defined in a palette. In the text modes we’ve seen so far, the assigned color becomes the foreground color for the character: referring to the character set images, the VIC draws an “on” pixel in the character’s color, and an “off” pixel in the background color.

Programming color memory is a bit weird.

The VIC-IV maintains a whopping 32 kilobytes of color memory from address $FF8.0000 to $FF8.7FFF. By default, color memory starts at the beginning of this range. The memory layout is the same as screen memory. An 80 x 25 text screen uses the first 2,000 bytes of this range for color data.

You can adjust the starting address of color memory, but only within this range. The COLPTR register at $D064 to $D065 stores a 16-bit offset to the start of color memory. Think of it as the last four hexadecimal digits after “FF8.”

Imagine a program that maintains two screens of 80 x 25 text. Such a program would determine two locations in memory for the 2,000 bytes of screen memory per screen, and set SCRNPTR to the starting address of the screen to be displayed. The program would also determine two locations in color memory for 2,000 bytes per screen, and set COLPTR to the current screen’s color data.

By changing the VIC pointers, a program can make a big change to the display using very little CPU time. While the user is looking at one screen, the program draws the next screen in the other set of memory, then at the last millisecond, it changes the pointers. As soon as the pointers have changed, the VIC immediately starts drawing from the new screen data. From the user’s perspective, the screen switch is instantaneous, and they never see any of the computation that goes into updating screen and color memory.

There is a teensy amount of time after updating SCRNPTR and before updating COLPTR, such that the VIC is drawing from the second screen’s screen codes and the first screen’s color codes. If this is a concern for your program, you can use a VIC raster interrupt to make sure the switch happens while the VIC is drawing the top or bottom border. By the time the raster beam gets to drawing characters, both pointers are updated.

The Commodore 64 only supports a 40 x 25 character graphics screen, and so only ever needs 1,000 bytes of color memory. The VIC-II keeps these bytes among the I/O registers, at addresses $D800 to $DBFF (that’s dee-bee-eff-eff).

The Commodore 65 introduced 80-column mode, requiring 2,000 bytes of color memory. To keep this data among the registers and stay compatible with the C64, the VIC-III has a one-bit register, CRAM2K, bit 0 of $D030, that switches the upper I/O registers to act as more color RAM, extending the range: $D800 to $DFFF.

To make it possible to access all 2,000 bytes of color memory without hiding I/O registers, the C65 also exposes the same memory at $1F800 to $1FFFF. This is outside the first 64 KB of memory, so a program has to use the 4502’s indirect addressing modes to access it. (A program could also use the 4502’s MAP feature to associate 16-bit addresses with 28-bit addresses. Personally, I only use MAP for executing CPU instructions in upper memory, and use indirect addressing for data. You have to be careful with the MAP feature to not accidentally un-MAP your program while it is running.)

The MEGA65 supports all of this. $D800 and $1F800 are the beginnings of two equivalent windows into the color memory starting at $FF8.0000. If the first 1,000 or 2,000 bytes of color memory are all you need, you can use these legacy methods, perhaps for the added convenience of $D800 being in the first bank. Remember that 80 x 50 text mode uses 4,000 bytes of color memory, which is more than these windows can see.

There’s one rather large caveat: these windows always reflect the top of color memory at $FF8.0000, not where COLPTR is pointing. If you set COLPTR to $0800, $D800 and $1F800 will continue to represent memory at $FF8.0000, and won’t be able to reach any of the memory that the VIC is using to paint color on the screen. The windows don’t move, which limits their usefulness.

If you’re not using the windows, there’s a neat trick you can do here. By setting COLPTR to $0800, the windows point to memory that’s not being used, from $FF8.0000 to $FF8.07FF. With this setting, you can use the windows as regular memory for other purposes. (If you need to be really technical, this memory is slightly slower to access than other memory in banks 0 through 5, but your program might not notice.)

Each byte of color memory stores eight bits of information. I mentioned that five of these bits select the color, with the ability to select any of the first 32 colors in the palette. The remaining three bits apply interesting text effects to the character.

The color bits are 0, 1, 2, 3, and 6. Another way to think of it is, bits 0 to 3 select one of 16 colors, and bit 6 selects either the first 16 colors (0 to 15) or the second 16 colors (16 to 31).

C65 documentation and the MEGA65 documentation describe bit 6 as “bold.” The idea is for a program to set colors 16 to 31 to be “bold” versions of colors 0 to 15, when such an effect is desired. Neither the C65 nor the MEGA65 have a boldface text effect, it’s just using a different set of colors.

Bit 4 causes the character to blink in a steady pattern. With only this attribute set, the VIC alternates between two states: draw “on” pixels in the foreground color, or draw all pixels in the background color.

Bit 5 reverses the character. With a monochrome character set, this means that “off” pixels are drawn in the character’s foreground color, and “on” pixels are drawn with the background color.

Bit 7 underlines the character. The bottommost line is drawn with all “on” pixels, regardless of how the character appears in the character set.

Things get a little dicey when you turn on more than one character attribute at a time. This was so confusing to me at first that I filed it as a bug years ago, and even submitted a “fix” to make it more intuitive. I eventually discovered that Commodore explicitly intended it this way, so I removed the “fix” in favor of a backwards-compatible feature request that we have not yet implemented.

For starters, “reverse” does not take effect if the “bold” palette is selected. There is no way to reverse a character and also set it to a color from 16 to 31.

“Blink” has a different behavior if any other attribute is set. With no other attributes set, “blink” causes the foreground pixels to alternate on and off. With any other attribute set, including the “bold” attribute, “blink” causes the attributes to blink on and off, and the character stays visible. Blink + underline: blink just the underline. Blink + reverse: alternate normal and reverse. Blink + bold: alternate between the two sets of colors.

Here’s a program that demonstrates every attribute combination and color:

I don’t like how this makes certain combinations inaccessible, especially the ability to blink a character that’s using the “bold” color set between visible and invisible. But I eventually convinced myself that Commodore had good intentions, and if we want to add more control over the attribute behaviors, we need to preserve Commodore’s design as the default. At least it’s quirky.

The blink + reverse effect resembles the blinking cursor of the screen editor. It’s interesting to notice that this is not actually how the blinking cursor works. Just as on the C64, the C65 default character set consists of 128 characters, followed by their reversed equivalents, for a total of 256 characters. The cursor blink is actually modifying the screen code, switching between the reversed and non-reversed variants of the character under the cursor. That seems like a waste considering there’s a blink + reverse mode that achieves a similar effect. The cursor could just set these attributes, and the default font could contain 128 more useful characters.

Unfortunately, an attribute-based cursor would be constrained by the unusual way that attributes combine. If an attribute-based cursor were above a character using the “bold” palette, the cursor would try to set “bold” and “reverse,” which cancels the “reverse” effect. Earlier versions of the MEGA65 ROM attempted this, and we had to go back to the screen code-based cursor because users noticed that the cursor would vanish when using the upper 16 colors.

In this Digest, we introduced the main idea behind character graphics: representing a screen as a coarse grid of characters, instead of a fine grid of pixels. Restricting the flexibility of the display to a common category of applications saves memory and compute time, an essential resource on microcomputers. We saw how the default text mode of the MEGA65 displays a grid of 80 x 25 characters, selected from a set of 256 characters, each displayed in one of 32 colors. Programs can manage display memory using pointer registers. We also took a brief look at how the text display can be switched between two horizontal resolutions (320 pixels or 640 pixels) and two vertical resolutions (200 pixels or 400 pixels), each combination fitting a different number of characters on the screen.

Vintage video systems typically support multiple video modes to give programs the opportunity to choose their own tradeoffs of capabilities and costs. Over several Digest articles this year, we’ll explore more features of the MEGA65’s character graphics system. We’ll see that many of these features involve switching modes that adjust specifications and change the way screen and color memory are interpreted by the VIC.

Next month, we’ll dive deeper into character sets and color palettes, both of which can be completely customized by a program. We’ve visited custom character sets a few times in previous Digest issues, and it’s about time we lay all the cards out on the table. We’ll also play around with some multi-color character graphics modes from the VIC-II and VIC-III, and work our way up to the crown jewel of MEGA65 VIC-IV character graphics, Super Extended Attribute Mode.

If you’re as excited about this series as I am, please consider supporting this Digest. Visit: ko-fi.com/dddaaannn

So much to do, so little time! See you next month.

— Dan

MEGA65: The First Ten Years. Dan’s MEGA65 Digest for April 2025.

Ten years ago, Paul Gardner-Stephen and the Museum of Electronic Games and Art announced a joint effort to recreate the Commodore 65. The MEGA65 would be an open-hardware open-source product, based on the original Commodore designs and prototypes, manufactured in Germany and sold worldwide. Instead of fading into obscurity as a historical footnote, the Commodore 65 would achieve new potential as a modern day platform for recreational computing, a revival both familiar and new to thousands of people looking for a way to reconnect with the creativity, stimulation, comfort, and digital sovereignty of the 8-bit era.

In this special edition of the Digest, we’ll review the first ten years of the MEGA65 project through published media, articles, videos, and conference talks. Take your time to click through the links below and experience the project through the eyes of the people that built it and the community around it.

We also have some exciting announcements to celebrate the anniversary! Don’t miss this one!

Breaking news from Detlef “deft” Hastik:

Having used citations and celebrated events from the history of computer nerds, and being fans of the book (not the movie!) Ready Player One, we have hidden an Easter egg in every MEGA65! The first person to find it will win an insane piece of MEGA65 history: the very first working and beautifully shaped MEGA65 prototype, shown in 2015 at AMIGA 30 in Neuss/Germany, six months after the project was officially announced by Paul Gardner-Stephen (AU) and Detlef Hastik (DE). This unicorn computer has an insurance value of over 15K USD, is signed by Dave Haynie, RJ Mical, Chris Hülsbeck, Dino Dini and other famous people, sports an unprinted (!) original C65 keyboard inside an SLS fabricated C65 case (yes, it’s made with lasers!) and - it also works!

Prepare for an unforgiving hunt through the depths of the MEGA65, through time, and of course, through space! There can be only one person to enter the nerd throne and win this nerd’s dream machine. Will it take days, weeks, months - or even years to solve the mind bending puzzles left by the creators and not discovered for years? Will you be the one to earn the crown?

Friends (and friends of friends) of the MEGA65 core team are not allowed to participate. Be prepared to be questioned. A time stamp will decide who the lucky winner is in case several people find the egg. It is allowed to build clans and search in groups :)

That’s right, this one-of-a-kind piece of MEGA65 history can be yours—if you know where to look! This multi-step trail has been under our noses for years and has not yet been discovered independently. Best of luck to everyone!

Every MEGA65 comes bundled with a large collection of software produced by the community, browsable by a menu that opens automatically when you first turn on the computer. The Intro Disk collection has added more titles each year since the MEGA65’s debut in 2022, and it’s time to expand it again!

Intro Disk #4 is now available for download. MEGA65 owners, sign in to Filehost and use this link for a version with extra licensed content. The new archive has an all-new menu system by MirageBD with music by Hein, and adds 72 new titles and dozens of articles about projects you can download and install. This brings the total size of the Intro Disk collection to 264 games, demos, and tools.

The entire collection has been revised and tested with the upcoming v0.97 release core, ROM, and system software. ID4 should work with release v0.96, but if you notice issues, I recommend installing the test version of the upcoming release (as discussed in last month’s Digest).

Huge thanks to Gurce, who has spearheaded the Intro Disk project from the very beginning. Thanks to his efforts curating, building, and testing the collection, everyone can experience what the MEGA65 has to offer, right out of the box.

If you’ve been waiting until the last minute to enter the Screenful of BASIC Compo, congratulations! It is now the last minute! The itch.io game jam page will accept entries until 11:59 pm GMT, April 22, 2025.

After the deadline, all entries will be revealed for download, and a friendly round of voting will begin. Try out all the entries for yourself, cheer on your fellow competitors in the comments, and boost your favorites.

If you have any last minute questions or technical issues with your entry, be sure to ask in the Discord or the Forum64.de thread. Go go go!

Another note from deft:

But what’s this? Something stirs behind the curtain - quiet talks, shifting shapes, and a name long thought dormant may soon rise to breathe new life into an extraordinary machine. Could something we all hold dear be wearing new clothes in the future? Those threads are being woven in fractures between past and present, by hands both trusted and unexpected. Something is cooking. What’s on the menu? Nothing is confirmed. Everything is possible. Watch this space.

At the Consumer Electronics Show of 1985 in Las Vegas, Nevada, Commodore Business Machines announced two new computers: the Commodore 128 and the Commodore LCD. The C128 went on to sell 2.5 million units over the next four years. The CLCD was cancelled before it was released.

That same year, Commodore began developing the 4502 CPU, later rebranded as the CSG 65CE02. Originally intended as a more efficient CMOS version of the 6502, the final design of the 4502 was faster and more featureful, compatible with the documented 6502 instruction set, with new instructions and enhancements for making use of more memory. The new chip would be a drop-in replacement for the 6502, at least in some applications.

Chip designer Bill Gardei conceived of a new home computer using the new CPU, an 8-bit successor to the C64 and C128 that would eventually be known as the Commodore 65. The C65 would feature the 4502 (packaged with other components as the “4510”), along with an enhanced VIC-III (4567) graphics chip to follow the VIC-II from the C64 and C128. Like the C128, the C65 would run existing C64 software and support most C64 peripherals. And the faster CPU, improved graphics, and target price would beat the new home game console everyone was talking about: the Nintendo Entertainment System.

By 1989, Commodore needed the C65 to fill out the low end of its home computer line, something that would capitalize on the popularity of the seven-year-old C64, and be less expensive than the Amiga 500 (1987). Three people were tasked with delivering the new system in time for the 1989 holiday season. Gardei continued to work on the chipset. Fred Bowen developed the KERNAL ROM and BASIC 10 language, emboldened by a luxurious 256 KB of ROM space and a budget to hire contractors. Paul Lassa designed the motherboard and hardware layout. Despite the team’s best efforts, hopes for a 1989 release of the C65 were dashed by issues with the test chips coming back from the Commodore Semiconductor Group. Only a few prototype systems had been assembled by August 1989, and many bugs remained.

The delays gave Lassa an opportunity to work on a new feature: a DMA chip capable of copying large regions of memory at high speed. Lassa even managed to sneak in Amiga-like features for drawing large graphical objects using the chip. Gardei and others worked on improving the 4502’s compatibility with C64 software, made difficult by efficiency improvements that caused legacy programs to run with incorrect timing. By the time chip designs stabilized, 1990 had come and gone.

While there was still some residual momentum within Commodore to launch the C65 in 1991, North American sales teams were no longer interested, and work had already begun on a low-cost Amiga that would be released as the Amiga 600 the following year. Commodore leadership de-staffed the already under-staffed teams, and the C65 project was cancelled. In the throes of financial difficulty, Commodore began selling off the contents of its warehouses in 1993, including an unknown number of C65 prototypes, estimated to be fewer than 200. By mid-1994, Commodore was out of business.

The Commodore 65 prototypes drifted among dealers and enthusiasts, mostly as curiosities, considering there was no software written for the unreleased platform. On the outside, the prototypes looked nearly finished, with the familiar wedge-style case, keyboard, and built-in floppy drive. Inside, the prototypes varied, with inconsistent versions of the mainboard and chips. The KERNAL ROM was incomplete, no meaningful software existed other than a few simple in-house demos, and no documentation was publicly available at the time.

One C65 prototype made it into the hands of engineer Paul Gardner-Stephen. Despite the lack of commercial software, Paul made regular use of the machine, learning what he could through experimentation and writing his own programs. Over the next sixteen years, the historical value of the prototype machine eventually exceeded Paul’s ability to care for it, and he sold it to a collector in the year 2010.

For the lucky few that owned them, the C65 was a glimpse into an alternate history with one more generation of 8-bit home computers. Paul conceived of a new 8-bit based on his experience with the C65. By 2010, FPGA technology had become fast enough and inexpensive enough for a single person to develop such a computer, without the large scale chip fabrication facilities used by Commodore developers to iterate on the original designs.

His C65 now in other hands, Paul started work on the “C65GS,” a new computer with the same spirit as the C65 and some degree of backwards compatibility. Paul originally expected the project to take the form of an “accelerator” board that would connect to vintage Commodore 64 hardware. The C65GS would be built using an off-the-shelf FPGA development kit, so early stages of the project could proceed without fabricating any parts.

The Museum of Electronic Games & Art (MEGA), a German non-profit organization dedicated to computer engineering education, creativity, and preservation, already had some experience recreating vintage computer history by the time they heard of Paul’s project. In 2011, MEGA members recreated Tennis for Two (1958), the early video game milestone played on an oscilloscope. In 2013, MEGA debuted their recreation of the ENTEX Adventure Vision (1982) with its unique spinning mirror display. These projects produced research documentation, emulators, tools, and prototypes that would join MEGA’s traveling exhibits that also included preserved hardware and modern demo software.

MEGA was exploring a potential project based on the Commodore 65 when they discovered Paul’s C65GS developer blog. MEGA and Paul joined forces in 2014, and relaunched the project in April 2015 as the MEGA65. The new computer would put Paul’s FPGA-based design into historically accurate reproductions of the Commodore 65 case with keyboard and built-in 3-1/2" floppy drive, as well as modern conveniences such as digital video output and Ethernet connectivity.

MEGA made steady progress on the keyboard case, exhibiting generations of prototypes in 2015 and 2016. The earliest prototypes were already measurement-exact reproductions of the C65 case and keyboard. Meanwhile, FPGA development was well under way. Paul and Detlef established the project with open source and open hardware licenses, and began the process of building a community of volunteer developers and testers. Paul published regular updates to his developer blog. As part of his work as a researcher and lecturer at Flinders University in Australia, Paul used the MEGA65 as a learning platform for his students. MEGA began promoting the project to solicit developer interest, and to stoke the imagination of the vintage computing community.

It’s easy to assume that the warm feelings we have for personal computers from our childhoods are purely nostalgia. Perhaps we only feel this way about these piles of junk because we grew up with them. But most people I know in this hobby cite another reason for the attraction: simplicity. Modern computing is built upon huge stacks of software. The lowest layers wrangle the unfathomable complexity of electrons coursing through switching circuits, and upper layers make the computer easier to program and easier to use. Over time, the depth and complexity of these layers have grown to alienate a computer’s owner from its power, ceding control of our data-driven personhood to software and service companies. Even when this exchange has obvious benefits—you didn’t have to code that web browsing program to use it—we get the creeping sense that our modern computers aren’t entirely ours. The technological centerpieces of our lives are merely rented, not owned, and don’t always act in our best interests.

In contrast, vintage computers are knowable, stable, comfortable. They do what you tell them to, and don’t do anything else. There are no background processes, there’s no unsolicited network activity, there are no operating system updates being installed remotely by the manufacturer, and there’s no user telemetry data being sent out to who knows where by something you didn’t know you installed years ago. It doesn’t take rose-tinted glasses to see this has some benefit over modern commercially-available computing products, something valuable that we may have lost.

Could modern-day personal computing learn from its ancestry? Could we restore the powers and freedoms we once had without sacrificing utility, or are the tradeoffs we’ve made for modern conveniences inevitable? Could the implicit principles of early personal computing be applied intentionally to the design of a modern computer? To a smartphone?

The MEGAPhone attempts to answer to that question. Funded by grants from the NLnet Foundation, MEGAPhone is the modern smartphone reimagined through the lens of the MEGA65 and Commodore 8-bit computers. It’s literally the same platform, running the MEGA65 FPGA core and ROM on portable hardware, extended with discrete mobile communication components. The “apps” are just programs, and you can write your own phone apps in BASIC 65 or machine code. The MEGAPhone architecture takes personal security and privacy to its strongest useful conclusion, mobile computing not beholden to a single manufacturer or provider, accessible and extensible by its user.

The MEGA65 hit another milestone towards wide distribution with the “pre-series” prototypes in 2019, a short run of complete units with early revision (R2) mainboards. These were sold privately to team members to raise money for the next phase of the project.

The final version of the MEGA65 would use an injection molding process to produce the replica plastic case and keycaps. Unlike short-run processes like the vacuum shaping used for the pre-series cases, injection molding requires a significant up-front tooling cost, carving the shape of the plastic into reusable metal molds capable of surviving the injection process. MEGA turned to the growing community of enthusiasts for support, raising over 69,000 EUR in donations.

While the final cases were being developed, MEGA wanted to get the nearly-completed mainboards into the hands of eager developers. They produced a limited run of feature-complete MEGA65 DevKit models, with cases made from clear laser-cut acrylic panels. These would be the first MEGA65s sold to the public. The 100 units sold out quickly.

The MEGA65 project had permission from Commodore intellectual property licensor Cloanto to distribute the original Commodore 65 prototype KERNAL ROM with the computer. The code dumped from the C65 prototype ROM chips was incomplete, and it seemed clear that it wouldn’t provide the best experience for MEGA65 owners in its original form.

The team formed two projects to address this. One group dug out the original Commodore 65 KERNAL source code from archives, wrote a custom assembler compatible with its vintage syntax, and began fixing bugs, completing features, and adding useful extensions. Another group began work on an all-new ROM, a clean-room implementation of the KERNAL intended to be API compatible with software written in BASIC 10 or using C65 KERNAL APIs, using no original Commodore IP so that it could be fully open-source licensed. The “closed ROM,” “open ROM,” and the original C65 prototype ROM would be included with the MEGA65, with an easy way for users to switch between them. The closed ROM was the most complete option by the time of launch, and it was chosen as the default experience.

Meanwhile, the community began writing and polishing a professional-quality user’s guide, to be printed and included in the box. The guide included a complete reference for the closed ROM’s built-in BASIC with the latest extensions, now called “BASIC 65” to differentiate it from the original C65’s BASIC 10. The typesetting was designed to resemble an idealized form of the original Commodore 64 manuals, and contributors spent many months editing and testing the material.

By September 2021, the MEGA65 was finally ready for its first production run. Manufacturing and distribution partner Trenz Electronic opened for pre-orders, and sold out the first batch within a few days.

Thousands of people joined the queue for the new computer, excited that the project was close to achieving its lofty goals—and perhaps eager for something to do at home during the continuing global health crisis. Unfortunately, that same crisis disrupted supply chains for electronic components and other materials, and Trenz had to delay delivery of the first batch by several months. Subsequent delivery dates would be difficult to predict, dependent entirely on availability of components.

Work continued on the FPGA core and KERNAL ROM projects. The MEGA65 was designed to be upgradeable, such that everyone who would receive hardware would continue to benefit from improvements. The first batch of computers shipped with what would be known as v0.9 of the platform.

Also included with every computer: an SD card populated with dozens of programs written by early developers, DevKit owners, and team members. When a new owner first turns on the MEGA65, they are greeted by the Intro Disk menu, a colorful animated display with jaunty music. The SD card also bundled many Commodore 64 games and demos, which the user could run from the Commodore 65’s C64 compatibility mode.

I received my MEGA65 in May of 2022. To help new owners get over some of the rough patches in the early experience while the team worked to fix them, I wrote a Welcome Guide with advice and explanations. The project needed help staying in contact with people waiting on pre-orders and others who had expressed interest, so I started Dan’s MEGA65 Digest, a monthly email newsletter and read-aloud podcast. My hope was to get more information about the MEGA65 into various forms of online media, improve the ability to find the project through search engines, and keep people informed of project activity as we bootstrapped the community.

The first delivery batch in May 2022 consisted of 400 units. Another 400 units shipped eight months later, in 2023. The supply chain crisis was ongoing, with limited FPGA supply going to the world’s biggest customers and leaving smaller projects on hold. As word spread about the project, more people got in line, but many who pre-ordered in late 2021 were still waiting.

With more computers in the hands of developers, the MEGA65 was coming into its own, both as a capable 8-bit home computer with attractive features for games and demos, and as an FPGA platform for alternate computer chipsets. One of the most influential FPGA projects was the C64 core, a highly accurate recreation of the Commodore 64 based on a similar project for the MiSTer FPGA platform. The C64 core was especially welcomed by MEGA65 owners who were hoping to use it as a C64 while waiting for the community to produce more MEGA65 software. The original Commodore 65 team never fully overcame design choices that limited compatibility with existing C64 software, and some speculate that this was a contributing factor that led to the C65 getting cancelled. With the C64 core, the MEGA65 could reconfigure itself with a C64 chipset and run nearly all C64 software with high fidelity.

Then came the first MEGA65 accessories. Publisher poly.play released several MEGA65 games as deluxe boxed editions. Paul designed a four-player joystick adapter for the cartridge port, and Jim Happel assembled some to distribute along with a disk of four-player games. Boutique vintage computer clothier Sew Ready produced a dust cover for the C65/MEGA65. I designed a machine code quick reference for the CPU that you can purchase as a mousepad or a poster. Paul also started work on an expansion board, a DIY kit that would sit inside the MEGA65 case and provide additional hardware features. (The expansion board is still a work in progress.)

We declared a new release of the MEGA65 platform—specifically the MEGA65 core, ROM, and system software—as version 0.95 in late 2022, in time to be installed at the factory on second-batch machines. Of course, owners of first-batch machines could upgrade to v0.95 for free. To accompany the release, we finished a 2nd edition of the User Guide that was used for the next printing of bundled manuals, and also made it available via print-on-demand so owners of the 1st edition could upgrade this as well.

Keeping a hardware project perpetually available at low volumes requires some flexibility when it comes to components. The MEGA65 is not a mass-produced appliance, and neither MEGA nor Trenz can purchase and store thousands of identical parts just to keep using the same mainboard design. In 2023, Trenz notified the team that components of the R3A revision of the mainboard used in the first 800 MEGA65s shipped would soon become unavailable. Paul updated the board design with newer replacement parts. He also took the opportunity to fix a few issues we encountered with R3A boards, such as unreliable Real-Time Clock chips. The R6 mainboard revision would be used for MEGA65s going forward, at least until the next component end-of-life notice.

Some members of the community expressed concern that the hardware revision meant that some MEGA65s were different than others, and certain products might only work with one revision or another. This was mostly noticed with the FPGA core projects, which needed to be updated by their authors for the newer board. Eventually, nearly all alternate cores were updated for both mainboard revisions. (As of this writing, only a few arcade cores remain to be updated.) More controversially, the R6 mainboard included a few extra features in addition to repairs. At the request of the community, Trenz Electronic began selling bare mainboards for anyone wishing to upgrade.

By 2024, the supply chain crisis abated. All remaining pre-orders for MEGA65s were fulfilled, and Trenz Electronic upgraded the MEGA65 to in-stock status in their store. Today, Trenz assembles computers in small batches to keep new orders for the MEGA65 on a short delivery timeline.

The thing that excites me most about the MEGA65 is that I keep meeting new people who are also excited about it. Trenz Electronic continues to receive new orders, and sometimes people tell me when they place their orders after seeing the MEGA65 at a conference or in a YouTube video. I’ve met people who had never heard of it before, people who heard rumors about it in the early days, and people who were on the verge of buying one and decided to take the plunge. Kids love it, at least the ones attending vintage computing conventions. They play the games, but they have just as much fun flipping through the User Guide and trying out the BASIC commands.

A healthy recreational computing community has multiple layers, each one grown from and supported by the one below it. Initially, these layers form around the platform itself: hardware hackers, FPGA core developers, KERNAL coders, technical writers. Then new people try it out, and find purchase to explore their interests and share their results: programming learners, game makers, demosceners, tool builders, media creators. As people are inspired by the passions of others, they contribute their own passions back, giving everyone more ways to enjoy and engage. People come and go, but the surface area continues to expand. This, more than anything, is what prevents technological abstractions from alienating users: there are people at every layer willing to help other people learn and explore.

What I most like about the MEGA65 specifically is how its layered design welcomes a community with diverse backgrounds and interests. The authentic Commodore-style BASIC is more accessible than ever, for running programs and for learning how to write new ones. Programmers both novice and expert can explore the undiscovered country of the architecture, pushing this alternate 8-bit timeline forward. And Commodore enthusiasts can access a previously inaccessible piece of history, use it with vintage peripherals and software, and summon more platforms with FPGA cores.

The community at the FPGA layer has been surprisingly active in the last couple of years. The MiSTer2MEGA65 framework and the excellent work of the MiSTer community draw a clear path toward someday having a complete Commodore computer museum that fits on your desk, in an authentic Commodore keyboard-wedge form factor. C65/MEGA65 and C64 cores exist today, PET and VIC-20 cores have public test releases, and there’s a great deal of interest in a potential Amiga core as well. There are cores for the ZX Spectrum, Game Boy, and TI-99/4A, with an Apple IIe core also in development, not to mention a dozen arcade cabinet cores. The MEGA65 has huge potential as an FPGA learning tool, as well.

Specific to the MEGA65 platform (that’s the core, ROM, system software), the MEGA65 Steering Committee is marshaling the project on a steady path to a v1.0 release, with an emphasis on feature quality and API stability. Development will continue beyond v1.0, using a high bar for backwards compatibility of changes, while continuing to track the interests of the community as it evolves and grows. As the current ROM lead, I’m especially interested in formalizing more of the KERNAL API surface and building hooks for third-party extensions. (Inner layers beget outer layers.) And we have tons of ideas for improving the non-platform parts of the user experience: on-screen interfaces, documentation, PC tools, networking.

MEGAPhone research will contribute features back into the MEGA65 platform. It may even be hardware you can purchase someday. The MEGA65 hardware will continue to adapt to shifts in global conditions, as resources allow, so the community can continue to grow.

And what was that “new clothes” thing deft was on about? 🤔

To ensure the growth and longevity of the platform and the community, we must continue to pump energy through the layers, inviting more people with diverse interests and enthusiasm. It’s why I write this Digest.

If you find this Digest useful, please consider becoming a supporter. Visit: ko-fi.com/dddaaannn

Congratulations to the MEGA65 team on an incredible ten years!

— Dan

What’s New in v0.97. Dan’s MEGA65 Digest for March 2025.

We’re getting ready to release the next major update to the MEGA65 firmware and system software, and you can help! We’re still finishing up the last few fixes before declaring a release candidate, but you can grab the latest development versions of the core and ROM and try them out. The more information we have about what works and what doesn’t, the stronger this release will be.

In this Digest, we’ll review installation and testing instructions, and look through the changelogs for things that could use some exercise. Soon, we will declare a release candidate, get all hands on deck to test for a bit, then announce the new version. The result will become release package version 0.97, the new recommended stable platform for all MEGA65 users.

But first, even more new stuff!

A kaleidoscopic design from one of my Screenful 2025 entries.

The Screenful of BASIC 2025 compo is open and accepting submissions. Thanks to everyone who has entered so far! Remember that the deadline is April 22, 2025, 11:59 pm GMT.

I managed to get a couple of entries in. They only took me about an afternoon each. I tried to pack a lot of code into the small amount of space, but that’s hardly necessary. Poems don’t have to be dense to be effective.

Give it a try, and when you’re ready, upload your entry to itch.io and submit it to the Screenful game jam.

kibo and M3wP continue to evolve MEGASPUTM, their LucasArts adventure game player, currently capable of running the Amiga version of Maniac Mansion. The newly released v1.2 of MEGASPUTM adds a really cool feature: the ability to switch between the Amiga version’s sound and music, and the Commodore 64’s SID-based sound and music.

Installing the data files from the Amiga and C64 versions of Maniac Mansion can be a challenge, so M3wP has made it easier with a new utility included with the player. Provide the original Amiga ADF and Commodore 64 D64 disk image files for the game, and the utility will install the appropriate files onto the D81 disk images, directly on your MEGA65.

Huge thanks to kibo and M3wP for this fun update, and for continuing to work on the project!

The MiSTer2MEGA FPGA framework

sy2002 and MJoergen have updated the MiSTer2MEGA framework, upon which multiple alternate cores are based, to repair issues with R6 boards, HDMI output, and the joystick swapping feature. Authors of alternate cores will need to re-build and re-release the cores to pick up the fixes.

muse has already started the process of updating the arcade cores, starting with Bank Panic and Burnin’ Rubber. There is also now an R6 version of the Burnin’ Rubber core.

Mega Chase, by shad0wfax.

Mega Chase by shad0wfax is an asymmetric 1-player or 2-player space battle game. Player One controls a powerful laser cannon capable of destroying ships in a single blast. Player Two (or the computer) pilots their ship, trying to dodge the laser. If the ship is hit before time runs out, Player One is victorious, otherwise Player Two escapes to fight another day. The game features original quad-SID music, multicolor sprites, custom text fonts, and sampled sound effects, and is written in BASIC.

muse’s arcade core of the month! Dig Dug (Namco, 1982) is now available for both R3 and R6 mainboards. Dig Dug was voted the 6th most popular arcade game of all time by the Killer List of Videogames, and was the 36th highest grossing according to sources gathered by Wikipedia. See the Github repo of the core for installation instructions, as usual.

Meteor Defense by Nuwanda puts you in charge of defending your city against a barrage of meteors. 80-column character based graphics give this challenging shooter extra charm.

Mars, 2049 AD by fredrikr is a short dialog-based text adventure game, written for PunyComp 2024 using the Inform 6 programming language and the PunyInform library. This MEGA65 version uses the Ozmoo interactive fiction player. You can visit the game’s itch.io page, or rate it at IFDB.org.

You can download the latest development core and ROM at the following links. The core builds include the system files to copy to the SD card, as well as the core file to install from the core menu.

We covered installation steps and tips last year when we were testing v0.96, so I won’t repeat those. The User’s Guide, 2nd edition also has improved instructions for installing cores and system files.

The ROM changes in this release are expected to all be functional with the v0.96 core. If you can, please test the development core and ROM together, but if it’s more convenient for you, you can test the ROM separately. (This is not always the case for release testing, it just happens to be the case this time.)

If you don’t yet own a MEGA65 and want to help test the ROM in the Xemu emulator, the ROM FAQ explains how to use the latest ROM patch file. Please use the latest “future next stable” release of Xemu.

Remember that you can have multiple ROMs installed on your SD card. The ROM whose file is named MEGA65.ROM is used by default. To install a secondary ROM, give its file the name MEGA652.ROM, then hold the 2 key during boot. You can install up to eight ROMs this way with the v0.96 core; the latest development core expands this to ten ROMs, one for each digit key.

The development core includes changes to the Configuration interface. If you don’t want to make the development core your default core, you can access a non-default core’s interface by booting to the core selection menu (hold the No Scroll key while switching on the computer), selecting the core, then immediately pressing and holding the Alt key to open its version of the Configuration menu.

Pay attention to the Discord for updates and other testing instructions. Please file bugs in Github:

New features for everyday use:

New features for programmers:

Hardware support:

The v0.97 RC core also has improvements in these areas:

There are currently known issues with mounting disks from the Freezer in the latest build. Also, formatting a new SD card doesn’t correctly offer to populate the SD card with the system software. We’re working on fixing these, and will hold this release until they are fixed.

See the mega65-core changelog for more details and links to resolved issues.

These ROM changes include corresponding changes in the latest User’s Guide PDF, as appropriate. Feel free to report documentation issues, if you find any.

New features for everyday use:

New features for BASIC programmers:

New and improved KERNAL routines; see the “KERNAL Jump Table” appendix of the Compendium:

Important changes to existing features:

Stuff that already existed but has now been documented in the latest User’s Guide PDF:

The v0.97 RC ROM also has improvements in these areas:

See the ROM changelog for more details.

Thanks to everyone who is available to help test this release. Even if you only have a moment to install it and run through a few games and demos, it’d be really appreciated.

Also, huge thanks to everyone who has contributed to the platform in the last year and a half! Every bug fixed makes the MEGA65 better for everyone, now and into the future.

Remember, you can support this Digest and my other work. Visit: ko-fi.com/dddaaannn

— Dan

Dan’s MEGA65 Digest for February 2025. A new BASIC code competition for the MEGA65 10th anniversary!

On April 22, 2015, the Museum of Electronic Games & Art and Paul Gardner-Stephen announced the MEGA65 project to the world. Paul also announced the project on his development blog, where he had been documenting his work on a “C65GS” FPGA bitstream, on which the MEGA65 would be based. The MEGA65 has been a thing for ten years!

To help celebrate the ten-year anniversary of the MEGA65, ZeHa of Dr. Wuro Industries is throwing a short-form BASIC competition—and you’re invited! We want as many entries as possible, so power up your MEGA65 and crack open your User’s Guide. No experience necessary!

I’ll keep this Digest brief so you have extra time to start playing with code. We’ll go over how to enter the compo, check out some recent Featured Files, and take a brief look at a fun and obscure feature of the VIC-IV video chip: high resolution text fonts.

It’s time for a good ol’ fashioned short-form BASIC competition!

The twist: Your program must be written in BASIC 65, and the program listing must fit entirely in one screen of 80 x 25 text, including space for the READY. prompt at the bottom of the screen. Someone should be able to type your program in from a single screenshot, and type LIST to see the entire program on screen. No data files allowed, one screen of code is all you get!

The deadline: Entries must be submitted by 11:59 pm GMT, April 22, 2025.

How to submit: Go to the itch.io page for the compo, create an itch.io account, and follow the instructions. Upload a D81 disk image containing a single PRG file of your program.

Pick your favorites: Public voting will open from April 23 to April 30. All entries will be available for download from itch.io. Results will be announced on May 1st.

Your program can do anything you’d like, and use any feature of the MEGA65. Just don’t destroy someone’s files or commit any crimes. Submissions should be family friendly in content. Multiple submissions are allowed, if you’re feeling productive.

Most MEGA65 users are running the latest stable release package v0.96, including ROM 920395. If your program requires a more recent ROM beta version, be sure to say so in the description of your entry. (We’re close to releasing v0.97 with all of the changes, but it won’t go out before the compo deadline.)

By submitting an entry to the competition, you assert that you have copyrights to the code, and you are assigning the Museum of Electronic Games & Art (MEGA) a non-exclusive right to distribute your program globally. Your entry will be hosted on itch.io, and may also be included in a compilation disk distributed on Filehost or bundled with the MEAG65 on the SD card as part of the “Intro Disk” anthology.

For complete rules and submission instructions, visit the Screenful of BASIC 2025 compo home page on itch.io. Many thanks to ZeHa for hosting this event!

For BASIC To One-Liners, by Holger Weßling.

Clever coders have devised many ways to cram a lot of BASIC into a little space, just as a personal challenge or for a short-form coding competition like Screenful. Figuring out what works and what doesn’t is part of the fun. If you’d like a bit of inspiration, there’s a book I can recommend. For Basic to One-Liners by Holger Weßling is packed with time-tested tips and tricks that apply to many dialects of microcomputer BASIC, with a focus on the Commodore 64 and short-form BASIC competitions. ZeHa himself is mentioned in the book!

We’ve covered BASIC programming topics in past issues of this Digest. In particular, check out October 2023: Robot Finds Kitten, part 1 and July 2024: Let’s Paint for some ideas.

For the purposes of short-form compos, the biggest difference between BASIC 65 and other Commodore BASICs is the breadth of graphics, sound, and music commands available. The language is mostly the same. I’d watch out for an unusual fact about BEGIN-BEND blocks from BASIC 7, where everything after the BEND on the same line is considered part of the block. If you discover any more language oddities, please mention them in the Discord or on Forum64.de.

“Hunt the Wumpus on the Mega65!” from the YouTube channel Coding with Culp.

Hunt the Wumpus by Dave Culp revives the classic computer game in BASIC 65. Traverse the dungeon, watch for clues, and take the Wumpus by surprise—before it surprises you. Don’t miss Dave’s video about his game on his YouTube channel, Coding with Culp.

It seems like muse has a new arcade core for us every month! I won’t hold him to that schedule, but I will very much enjoy Bank Panic (1984) from Sega. This western-themed reflex action game features colorful cartoon graphics and a unique user interface. This bank has so many doors! R6 owners will prefer the VGA video output. We’re waiting on a video fix for R6 boards in the MiSTer2MEGA framework that affects HDMI output of some arcade cores. I needed to use the horizontal position adjustment feature in the menu system, but then it looked great over VGA on my screen. As usual, see the Github repo for installation instructions.

WarGames simulator, originally by Andy Glenn, ported to BASIC 65 by Mr. Jones. Recreate scenes from the classic movie WarGames (1983) and avert Global Thermonuclear War. The game features a narrative hint mode if you don’t remember the movie.

BasicTracker by ZeHa is a simple, intuitive music composition program with a tracker-like interface. Compose for six simultaneous voices, each with six possible instruments. Enter two octaves worth of notes using letters and numbers, move the cursor with the cursor keys, and follow on-screen instructions for the rest. There’s no way to save or export song data, this is just for fun.

When you first turn on the computer, it starts up with a text screen 80 character wide and 25 characters tall, where each character is 8 pixels wide and 8 pixels tall, for a resolution of 640 x 200. There are two other text mode resolutions you can access directly from this screen: press Esc then 4 to enter 40 x 25 text mode, Esc then 5 to enter 80 x 50 text mode, and Esc then 8 to return to 80 x 25 text mode. All of these modes use 8 x 8 characters.

The MEGA65 has another way to draw text—and it’s practically a secret. Tall Character mode (TCR mode) doubles the vertical pixel resolution without changing the dimensions of the screen. Each character becomes 8 pixels wide and 16 pixels tall, making the text sharper and easier to read. TCR mode needs a 8x16 font to do this, and the MEGA65 does not have any TCR fonts built in. But there’s an easy way to load such fonts yourself.

Xemu users, note that TCR support was very recently added to the next branch (as of version 20250216001821), so download the latest if you want to try this in the emulator.

M3wP has been experimenting with this feature recently, and produced TCR conversions of several modern fixed width fonts. Download M3wP’s conversions of the fonts Courier, Xirod, Hack, and Noto.

These fonts are distributed in the .TCR file format, a binary format that matches how this data appears in the MEGA65’s memory. To load a .TCR file into the MEGA65:

These are lowercase ASCII character sets only, and naturally are missing PETSCII graphics symbols. They contain ASCII symbols such as underscore (_) and tilde (~).

Inspired by M3wP’s example, I spent an afternoon playing with The Oldschool PC Font Resource, a large collection of high fidelity reproductions of system fonts for IBM PCs, PC compatibles, and various BIOSes and devices. I wrote a script to convert the 8x16 bitmap fonts to TCR files, and put together a font browser in BASIC:

Mount this disk image, then RUN "*" to play with the font browser.

A PC font normally has 256 unique characters in it, with the usual cast of ASCII characters in the first half and some familiar PC graphics characters and symbols in the second half. I attempted to relocate the ASCII-style characters to the corresponding screen codes used for PETSCII, such that ASCII text could be displayed without changes. I put some of the PC symbol characters (like the smiley faces) at useful but arbitrary locations.

There are two TCR files for each font: a 128-character version and a 256-character (“all characters”) version. The 128-character version uses the first 128 characters of the PC font, then repeats them in “reverse” video for the second 128 characters, such that the screen terminal cursor blinks correctly. When the screen terminal’s cursor is over a letter, it blinks between the letter and its reverse, so both need to be present in the character set.

The 256-character version of the TCR font uses all 256 characters of the PC font, with no reverses. This makes more symbols available, at the expense of not working correctly with the screen terminal. If you’re writing your own program, you could implement a new cursor using the reverse character attribute instead of dedicated reverse characters. (We tried upgrading the screen terminal to do this, but ran into issues with how the VIC-III defines character attributes. That’s a story for another day.)

See the mega65-pcfonts Github repo for documentation, loose TCR files, and the scripts I used to put it all together. Or just enjoy the demo disk.

To use a TCR font in your own program (or AUTOBOOT.C65 startup sequence), the TCR file must be on a D81 disk image. You can use the usual PC tools to make such an image, or you can do it on the MEGA65 with the BSAVE command, like so:

The PCFONTS.D81 disk has the TCR files on the disk, so you can copy those with the COPY command. Note that the PC fonts are released under a Creative Commons license with attribution and “share-alike” provisions. See the licensing terms in the README.md file.

In your program, load the font file into memory, and activate the TCR mode:

In BASIC:

To return to 8x8 PETSCII:

In the VIC-IV TCR mode, character set data is read directly from the character generator memory at $FF7E000-$FF7EFFF (4 KB). The screen terminal does not switch between “uppercase + graphics” and “lowercase + uppercase” text modes. There is only one text mode. Whereas a PETSCII character set has a set of 256 characters for each text mode, TCR mode uses the same amount of memory for a single mode, with twice as many pixels per character.

TCR character set data is interpreted as a single set of 256 characters of 8 x 16 resolution, using interleaving lines from charset positions n and n+256. For example, screen code 1 is normally a lowercase “a” character. Its image is made of alternating lines of the data at positions 1 and 257 in the character set, like so:

In memory, the lines look like this:

There’s a fun way to get an intuition for how this works. The original 8x8 PETSCII font keeps uppercase letters in the first half and lowercase letters in the second half. Without loading a TCR font, enable TCR mode by setting the CHARY16 register: SETBIT $D07A,4 The VIC-IV interleaves the uppercase and lowercase PETSCII characters at double the vertical resolution.

Character graphics are a big subject on the MEGA65, and I’m planning a series of Digest feature articles for later this year to cover as much of it as I can.

If you like this kind of thing, please consider supporting the Digest. Your patronage makes this Digest possible—and makes it free for everyone. Visit: https://ko-fi.com/dddaaannn

Now get cracking on that screenful!

— Dan

Disassembling Crossroads, part 2. Dan’s MEGA65 Digest for January 2025.

In last November’s Digest, we started a project to dissect the classic C64 title Crossroads, published by Compute!’s Gazette magazine in December 1987. We got a handle on how the game works by playing it, and by inspecting the running game state in Retro Debugger, a C64 emulator with memory visualization features. In this issue, we’ll get up close and personal with the Crossroads machine code, using a tool called a disassembler. Combined with what we’ve learned, and some world knowledge of Commodore programs, we can begin to produce human-readable assembly language source code for the game.

Crossroads was so popular that Compute! commissioned a sequel, Crossroads II: Pandemonium, which was published in December 1988. I did some searching to see if anyone has disassembled the Crossroads games already, and discovered an excellent disassembly of Crossroads II by Github user hyphz. For the sake of the exercise, I did not look closely at this disassembly at first, but I do expect the original Crossroads to be similar in many ways.

We won’t do a full disassembly of Crossroads in a single newsletter, but we’ll answer some of the most important questions. Before we do that, let’s see what everyone else is up to!

The Commodore PET core, running on the MEGA65.

Olaf “Rhialto” Seibert is working on a Commodore PET core for the MEGA65, and has invited everyone to help test a pre-release version. The Filehost download includes core builds for R3 and R6 boards, and a copy of the necessary ROM files that you install on the SD card in a folder named pet/.

Do keep in mind that this is a pre-release and may be missing features. Check out the Commodore PET core on Github to see source files and file bugs. Many thanks to Rhialto for this exciting project!

Gaplus arcade game, by Namco

muse continues to deliver arcade core goodness! This month, it’s Gaplus, the third game in the Galaga series from Namco. As usual, you will need to download the Gaplus core, locate MAME ROMs on the Internet, then follow the set-up instructions to produce the files for the SD card. The Gaplus core is available for both R3 and R6 mainboards.

I encountered an issue with the R6 version when using HDMI video where after a few seconds the game video becomes a static screen of vertical bars. This does not occur over VGA, or with the version for the R3 mainboard. A fix is in progress.

The 8 Bit Theory on developing QR code generators for Commodore computers.

Goodwell, aka The 8 Bit Theory on YouTube, recently attempted an experiment to write a QR code generator for multiple vintage Commodore computers in multiple languages, including BASIC 2, BASIC 7, C, 6502 assembly language—and BASIC 65 for the MEGA65. The video about the experience discusses implementation techniques and performance characteristics of these implementations. Definitely check it out, it’s worth watching the whole thing.

Goodwell uploaded the MEGA65 version to Filehost, and is continuing to refine it. It might even get added to the MEGA65 Intro Disk menu system, to make it easier to share URLs in the menu text. The Github repo for the QR code generator has all of the versions of the experiment, as source code.

Don’t miss Goodwell’s follow-up video about the MEGA65’s technical design, based on his early experiences developing for the computer.

MEGAMage, by SirGeldi.

Hot off the presses! SirGeldi on Forum64.de has posted MEGAMage, a Roguelike adventure game written entirely in BASIC. Adorable character graphics and fast map scrolling enhance the gameplay. Even better, SirGeldi built the tools used to develop the graphics, map, and object and monster metadata for the game on the MEGA65 in BASIC, and has included these tools on the disk!

Download the .zip file from SirGeldi’s message post, unpack it, and transfer the D81 disk image to your MEGA65. To start the game, mount the disk image, then:

Soccer, by SirLazarus

Soccer, by SirLazarus, is a new soccer-themed paddle game. It is written in BASIC, and requires the latest ROM beta version 920409 because it uses recently added features. (This ROM update will be included in the next stable release package.) Grab your paddle controllers and check it out!

Jotto 2020, by ToneDeF, is a word puzzle game similar to Mastermind. It plays something like Wordle, though its invention pre-dates Wordle by a year. ToneDeF originally wrote this for other micros, and made this new version for the MEGA65 in BASIC.

Pac-man in BASIC demo, by xlar54. This playable demo sports many features of the arcade classic, including music, sound, and polished graphics. xlar insists this is just a demo, but only a few features are missing (most notably power pellets). And yes, this too is implemented entirely in BASIC 65.

Opal Dance, by lochmana, is a colorful puzzle and maze game. Match colored pieces by walking into them, but think before you move! Each match of two pieces replaces the first piece with a wall, and removes the second piece. Clear as much of the level as you can.

Mega65 Perpetual Calendar, by gcastel (MiddleAgedCoder on Discord). Generate calendars for any month of any year. Developed for BASIC 65 with Eleven, you can get the source code from Github.

Xemu keyboard layout reference for Windows, by Discord user Digger. Windows users, keep this handy app open alongside the Xemu emulator to remember how to replicate MEGA65 keystrokes on the PC keyboard. See also the project homepage (in German), and the README file (in English) included with the download.

mouSTer, the USB-to-Commodore DB9 adapter for modern USB mice and game controllers, is back in stock after a long hiatus. This is one of the best ways to use a modern USB mouse with the MEGA65. It even works with wireless mice that use USB dongles. Get one while you can!

See RetroHax’s update from December 30, 2024 for details.

I am considering migrating the Digest to a new email newsletter service. As Substack evolves their business model and practices, I want to make sure the Digest is hosted on services that remain open and compatible with the values of the MEGA65 project. I’ll let everyone know in advance before I make changes.

The change should be fully automatic, including migrating donations made through the Substack interface as paid subscriptions. Hopefully I can migrate the read-aloud podcast feed URL automatically as well, but this will depend on how your podcast app is subscribed. I’ll try to figure it out and let you know. If anyone has any feedback on this change, please let me know. I know a couple of you are using the Substack app to read it, which should be the only case affected by a migration.

You can always find all issues of the Digest on my website and subscribe to it using an RSS feed reader. You can also become a patron of the Digest at ko-fi.com/dddaaannn.

A quick recap: A computer’s CPU performs instructions encoded as bytes in the computer’s memory. This machine code is difficult to work with as a list of numbers, so when we humans want to write a program, we use a programming language, and a tool that converts that language to machine code for the computer to execute. Assembly language is a human language that most closely resembles the machine code, with human-readable names for each machine code instruction. The corresponding conversion tool is called an assembler.

There’s a simple assembler built into the MEGA65’s machine language monitor. You can start the monitor by entering the MONITOR command at the READY prompt. Try doing this now, and use the A command to assemble this short program:

After the last line, press Return on a line by itself to stop the assembler.

As you type each line, the monitor converts the instruction to the corresponding machine code. It stores the machine code at the requested address in memory, and also prints the address and machine code bytes to the screen, as hexadecimal values.

The monitor can also reverse this process, to show you which instructions are represented by bytes in memory. This process is known as disassembly. Use the D command followed by the address:

Sure enough, the program you just entered is right where you put it, at address $1600. There’s also a bunch of other stuff after the last instruction you typed starting at address $160B, maybe garbage data or something left behind by another program. These bytes may or may not represent machine code instructions, but the disassembler diligently tries to interpret them as instructions either way. These instructions are what the CPU would perform if you told it to treat that memory as code.

The number of bytes used to encode an instruction differs depending on the instruction. Some instructions, like RTS, are encoded as a single byte. Others, like LDA #$01, use two bytes. Still others such as STA $D020 require three bytes. Anything trying to interpret bytes as machine code—whether that’s a disassembler or the CPU itself—needs to know the address of the first byte of the first instruction, or it could get very confused.

Try using the disassemble (D) command again, this time with a starting address of $1601:

The monitor tries to disassemble some of the memory of the program you entered, but the result looks nothing like the program. $1601 is the address of the second byte of the LDA instruction, $01, which to the disassembler (and the CPU) looks like a version of the ORA instruction that uses two bytes. At address $1603, the next byte $20 looks like a three-byte JSR instruction. Coincidentally, the next incorrect instruction gets the disassembler back on track, aligned with the correct first instruction byte at address $1607. But by now, a CPU trying to execute this code will get very lost, and probably crash.

Disassemblers are not magic, and they need help from the operator—that’s you—to convert machine code back into human-readable assembly language. The disassembly process requires research, maybe some guessing and checking, taking notes, and labeling addresses and values once you’ve figured out what they mean. A modern disassembly tool can make this process surprisingly easy.

Ghidra is a powerful disassembler and reverse engineering multi-tool. It supports many types of CPU machine code, including the 6502, and supports extensions to add more. Ghidra was originally developed by the United States National Security Agency (NSA), and has been released as open source and free of cost.

I want to credit two YouTube videos on the topic of using Ghidra for reverse engineering Commodore 64 programs: Introduction to Ghidra by David Youd, and How to start a new C64 project in Ghidra by Jarkko Lehti. These are worth watching when you get a chance, and we’ll be using Lehti’s configuration files in a moment.

As of this writing, the latest version of Ghidra is v11.2.1. It’s a Java-based application, and it requires a recent version of the Java runtime (21 or later), which you may need to install or upgrade. Ghidra will tell you if your Java is too old. Properly installed, Windows users can double-click on ghidraRun.bat to start the program, and macOS and Linux users invoke the ghidraRun shell script.

As usual, macOS will refuse to run the scripts and tools until you have blessed them in the Privacy & Security panel. You probably know the drill by now. Attempt to start ghidraRun, dismiss the complaint, open macOS Settings: Privacy & Security, scroll down, click Open Anyway. If you use Ghidra for other stuff later, you’ll need to similarly bless some internal components, which you can do in the Terminal app on the command line:

When you run Ghidra for the first time, it will ask for the path to the Java home directory. This will depend on your operating system. On macOS using Java 23 from Oracle, the path is:

Ghidra opens its main window, from which you create or select a project, and open tools.

Let’s start a new project using the crossroads.prg file that we extracted from the disk image in last month’s Digest.

Create a new project:

Next, import the crossroads.prg file:

Finally, double-click on the crossroads.prg file in the project to open it in the CodeBrowser tool. The first time you do this, Ghidra will offer to analyze the file. Say Yes. Leave the default set of analyzers selected, then click Analyze. The analysis doesn’t produce spectacular results just yet, but it’s usually worth doing.

Here is crossroads.prg in all its glory, in the CodeBrowser window. These are the same bytes we saw in the hex dump, but now they’re listed one per line. We will use this interface to massage the data as we learn what each part of it means.

Let’s start by telling Ghidra the C64 memory address where this data gets loaded. Because this is a PRG file, it begins with two bytes that are not loaded into memory. We could have gone through an extra step to remove these bytes before importing the data, but for our purposes, it’s enough to just take these into account when telling Ghidra where everything lives.

This data gets loaded into a single block of memory that starts at address $0801. Minus the two PRG header bytes, we can tell Ghidra to start counting addresses at $07FF:

Notice that the data is now lined up with the memory addresses. The first byte of the BASIC bootstrap is at $0801, and the two-byte end-of-BASIC terminator is at $080B. (We peeked at this in the previous Digest.)

Let’s add a comment describing this data. Right-click on the line for $0801 to open the context menu. Select Comments > Set EOL Comment… In the window that opens, type a useful description, such as: “Start of BASIC bootstrap.” You may wish to add a similar comment on $080C, for “End of BASIC bootstrap.”

The BASIC bootstrap uses the SYS command to invoke machine code starting at decimal address 2300. Ghidra even shows the “2300” characters next to the byte listing, guessing that we might be interested in what these look like as ASCII characters. In hexadecimal, this address is $08FC.

Navigate to this address in the byte listing. Here’s a quick way: press “G” (for “go”), then enter the address in hexadecimal (08fc).

Start the disassembly at this address: press “D” (for “disassemble”).

Ghidra has just done a bunch of work for us! It took our word for it that the bytes starting at $08fc are machine code: $a9 $ff represent the LDA #$ff instruction, which Ghidra spells LDA #0xff, and updated the code listing accordingly. It proceeded to the next instruction, and kept going as long as it was reasonably certain that the CPU would treat those bytes as instructions as it executed.

Scroll down, and notice that Ghidra stopped disassembly at address $0cab, where it found an RTS instruction. The bytes starting at $0cac may be more CPU instructions, but Ghidra doesn’t know this for sure. In fact, we can see evidence that it may be data and not instructions: the bytes from $0cb1 to $0cba spell out “CROSSROADS” in ASCII. Ghidra doesn’t know this is more likely to be PETSCII and not ASCII, but it displays the ASCII letters for our benefit, just in case.

Keep scrolling, down to $0dc5. Ghidra found more code! Starting with the first address we gave it, Ghidra decoded each instruction, and when it found a branching instruction or subroutine call, it continued disassembly at that location, filling everything in. It assigned some temporary labels for things that look like functions, such as FUN_0dc5. As we try to understand what the program does, we can replace these labels with more intuitive names. In the end, we’ll have a fully human-readable assembly language program. (Or as human readable as assembly language gets, anyway.)

Ghidra made similar attempts to highlight data locations referenced in the code, assigning labels such as DAT_08b0. Everything referenced by something else is annotated with the cross references. For example, the byte at address $08b0 is read by an instruction at address $0a7a, so it lists 0a7a(R) (“R” for “read”) next to $08b0.

We can add our own labels. Let’s do this for our entry point, $08fc:

Ghidra has invented labels for all of the data and code referenced by the disassembled code. The addresses within the imported data range have blue labels and cross references.

Where the code references an address not in the imported range, Ghidra also generated a label, and colored it red. Consider the first few instructions of the program, starting at $08fc:

This loads $ff into the accumulator, and stores that value to addresses $d40e and $d40f. If these were just memory locations, we would assume that these are variables used by the game for storing game state, like the player’s position. In this case, we can apply some knowledge of how the Commodore 64 works: addresses in the range $d000-$dfff are input-output registers that control, or are controlled by, the computer’s hardware. We can look up what these registers do in a Commodore 64 technical reference.

In this case, these registers belong to the SID sound chip, specifically the frequency of the oscillator on voice #3. We don’t yet know why the program does this, but we do know that’s what it does. The next two instructions and a bit more knowledge of C64 programming gives us a hint:

The technical reference says $d412 is the SID voice #3 control register. Setting bit 7 like this tells it to use the “noise” waveform. Crossroads is certainly a noisy game, but it’s probably setting this up to use as a random number generator, or at least a seed for one. We’ll have to keep our eye out for something that samples a value from voice #3.

Now that we’ve identified DAT_d40e et al., we could update the labels to something that describes their functions. To do this, you would right-click on the label and select Edit Label… (or move the cursor onto the label and press “L”).

Considering that the C64 I/O registers always do the same thing in every program, it would be nice if Ghidra could automatically recognize all of them and give them useful names. The following is one way to do this, based on the files supplied by Jarkko Lehti to accompany his YouTube video on the subject.

Download these C64 symbol files:

The .txt files tell Ghidra to apply certain labels to certain addresses when they appear in the code. The .bin files fill in the memory ranges themselves in the Ghidra project, so you can get some idea of what’s actually there in the C64’s memory.

In your project, the IO and KERNAL data will exist as overlays. An overlay is a portion of memory that may contain different things at different times, based on system state. With the Commodore 64, I/O registers and KERNAL ROM occupy addresses that can also refer to RAM, based on the memory banking register. Ghidra can only see that an instruction accesses an address, not the memory map of the computer at the time the instruction is called. Telling Ghidra that these memory regions are overlays accounts for the possibility that a given reference to an address may refer either to I/O and ROM, or the underlying RAM.

To create the IO overlay:

To create the KERNAL overlay, repeat these steps with the kernal_e000.bin file, using a Block Name of KERNAL and a Base Address of e000.

Now we can import the symbols that describe addresses in these regions. Ghidra is a highly scriptable application environment, and we can use a script that comes with Ghidra to import the .txt symbols files.

To import the symbols:

Ghidra now knows about the I/O registers via an overlay with sensibly named symbols. Ghidra still doesn’t know which references refer to RAM and which refer to I/O. We have to tell it.

Go (“G”) back to the STA instruction at $08fe. Its destination is still the red symbol DAT_d40e. Click on it, then press “R” to edit the reference. In the pop-up window, double-click the reference, then change the dropdown menu that says “RAM:” to “IO:”. Click Update, and close the reference editor. The symbol has changed to D40E_FRQ_3_LO. That’s… better.

It’s unusual for a C64 game to un-bank the I/O registers, so it’s a little inconvenient that each label needs to be applied like this. I haven’t found a good way to automatically declare all references to be for the IO overlay. One possibility might be to add IO_d000.bin as a non-overlay region, then edit the IO.txt symbols file to remove the IO:: part of each address. For now, I like keeping IO as an overlay, because it accurately describes how the C64 works.

I did find a reasonably fast way to update all of the labels manually using Ghidra’s search feature. In the Search menu, select Program Text… Prepare a search for DAT_d in All Fields of the Listing Display, and click Search All. A window opens with the search results, and clicking on a result causes the Listing display to jump to that location. I got 38 results, and it only took me a few minutes to update all of the references to use the IO labels. It’s not the most fun I’ve ever had with a computer, but it didn’t take so long that I regretted not automating it.

Now that we have at least some idea of what we’re looking at, let’s try to answer a few questions that will help us understand how Crossroads works. These are just questions that occurred to me, in the order I thought to ask them. They may not be the best questions, or in the best order. But let’s see what happens.

This is an easy one. A call to the KERNAL jump table would look like a JSR to a hexadecimal address beginning with an f. Ghidra will have generated a label like FUN_ffd2 prior to me updating it to use the KERNAL overlay’s symbols, so just like we used a search of DAT_d to find I/O register references, we can search for FUN_f to find calls to KERNAL routines. I get no results from this search, so I’m fairly confident that Crossroads does not call KERNAL routines. Alas, we don’t get to use our KERNAL overlay. Maybe next time.

As we’ve discussed in previous issues of the Digest, most games drive their game loop using CPU interrupts. There are two ways to set up an interrupt handler: replace the KERNAL’s interrupt handlers in $fffa-$ffff, or use a KERNAL vector to add a custom subroutine to the KERNAL’s interrupt handler. Let’s check the latter option first, because it’s more common for simple C64 games.

The designers of the Commodore ROM wanted people to use the VECTOR KERNAL call to read and update the KERNAL vector table, and that’s still a best practice for MEGA65 programs. Even early on, C64 programmers skipped over that part of the manual, and just wrote to the C64 vector table at $0314-$0333. We can search for the string 0314 to find any direct references to the IRQ vector.

Yup, there it is. The instructions at $0ba8-$0bb1 are writing address $11c4 to the KERNAL IRQ vector $0314-$0315.

This appears to be the only vector touched, and it is only set in this one location in the code that Ghidra has disassembled. Let’s go to the address being written to the vector and check it out: “G”, then 11c4.

Hoo boy, Ghidra hasn’t disassembled this yet! This is because the main routine, which sets up the game and installs the IRQ vector, doesn’t actually call the IRQ handler directly. We have a bit more work to do. Press “D” to start disassembly from this address. Also, press “L” to add an entry point label, with a name such as irq.

We’ll have to re-do our searches for I/O register labels and KERNAL calls now that we have more disassembled code. That’s just how it goes. I found 8 more I/O registers, but still no KERNAL calls.

I mentioned that most games leave I/O registers banked to $d000-$dfff, the initial state of the C64. We can double-check that by looking for references to the C64 bank switching register, address $0001.

A search for DAT_0001 does produce two results in the start-up routine, so it’s worth taking a closer look. Starting at address $09f9, the routine sets this to $73, or binary %01110011. According to C64 technical documentation, this setting makes sure the C64 character ROM—the graphics data for the PETSCII font—is visible at $d000-$dfff instead of the I/O registers. It’s not that way for long, though. Just below, at address $0a10, the banking register gets set to $77, or binary %01110111, which switches the I/O registers back in.

While the character ROM is visible, a short loop copies the first 472 bytes of PETSCII graphics data to address $2000.

Now that we know what this does, we can rename the LAB_09ff label to something like copy_char_loop, and add explanatory comments to the bank switching instructions. We can also relabel DAT_0001 while we’re at it.

From our perspective as reverse engineers, one of the scariest things a program can do is modify its own code. The program is entirely within its right to do this—code is just data in memory—but it means that the disassembler may not be seeing the code in the form it is executed.

To find places where the program might be modifying itself, we have to look for attempts to store values in locations that Ghidra believes are inside subroutine code. I bet there’s a way to get Ghidra to make a list of such places, but I haven’t found one yet. I did notice, however, that Ghidra refers to such addresses by the name of the function, plus an offset, like this example near the entry point:

These address expressions appear in a grey color. From visual inspection, I found only a few examples of this. Thankfully, they were all short subroutines that were easy to understand, and all of the self-modifications were to addresses for LDA and STA instructions.

Several of these appear to be simple utility functions for using addresses from variables together with indirect addressing. For example, FUN_0b4a is simply the STA instruction in absolute Y-indexed addressing mode, followed by an RTS. To use this routine, the program writes an address into the STA instruction, sets the A and Y CPU registers, then calls the subroutine:

This probably saved the developer some headache, using a single self-modifying mechanism instead of having every subroutine modify its own instructions. The initialization routine near the entry point uses this mechanism as part of a loop to fill some memory with zeroes.

We found the entry point and the IRQ vector routine, and we identified self-modifying code and confirmed that it’s not doing something crazy like dynamically writing JMP instructions to memory at run time. It looks like Ghidra has found most of the code in the program. Are we safe to conclude that the remaining unidentified regions are static data, or perhaps initialized variable space?

This requires a bit of judgement, a bit of guesswork, and a willingness to change our minds later, but we can start to form some conclusions from a visual inspection of Ghidra’s analysis. Here’s what I see so far:

For now at least, I feel confident that these regions are static data and not code, and that Ghidra has found all of the code in the program.

We can learn more about the suspected data regions by double-clicking on the cross-references and digging around the code that refers to them. We can also make some guesses about how the data is encoded, and try to decode it to see if we recognize any patterns, similar to how we identified text strings with Ghidra’s built-in ASCII decoding.

I’m especially interested to find the character graphics data that gives Crossroads its special flair. This is likely to take the form of monochrome character pixel data, where each byte represents a row of 8 pixels, and consecutive bytes are stacked, usually in a square of 8 rows. If we visualized the bytes in suspicious data regions this way, would the Crossroads cast of characters jump out at us?

Ghidra has extensive features for visualizing data structures. Once we have a guess as to how data should be interpreted, we can paint data types onto the bytes and see if they make sense. For example, to visualize a byte as a binary number:

Let’s try this for a chunk of the data region $080d-$08f9. (We can always undo it later.) Click-drag with the mouse, or move the cursor to the first line and hold Shift while cursoring down, to select lines. Use the Data context menu to make them all bytes displayed as padded binary.

It’s a little difficult to make out when displayed as 0’s and 1’s, but I see some familiar faces. Going eight bytes at a time, I see two frames of animation for each of an enemy missile ($080d), a bullet ($081d), the Human/player ($082d), the Purple Rubberhead ($083d), and more. I have to squint to see the rest, but if each of the nine enemies gets 16 bytes starting at $083d, it feels safe to say these are graphics tiles up to at least $08cd.

We have a rough idea that the game keeps its graphics assets starting at $080d, and establishes its custom character font at $2000 with some combination of this data and PETSCII characters from character ROM. We’ve already found where the set-up routine ($08fc) copies the character ROM to $2000. What else does it do?

It’s relatively easy to see that a big chunk of the set-up routine is messing around in the $2000 memory region. Starting from the beginning, it sets a few registers, then immediately dives into the work of rendering the character data, with various loops and STA instructions indexing into this memory.

The characters of Crossroads walk in four directions, with two frames of animation. We only found two frames of animation in the graphics data, with the characters facing to the right. Can you guess where it gets the graphics for the other three directions?

To achieve the full effect, the set-up loop takes the 8x8 right-facing creature graphics and writes it into character graphics memory. Then it flips each byte horizontally and writes the left-facing copy. Then it rotates it 90 degrees one way for up-facing, and 90 degrees the other way for down-facing.

Moreover, the second step of each character’s animation is drawn across two character tiles, for that slick grid-breaking animation. The creature takes up two characters on the 40x25 screen for this half step, and no other creature or item is allowed in either tile at this moment. The set-up routine renders these half-steps dynamically from the 8x8 pixel data, using bit shifting instructions to produce half-tile images. I see groups of four bit shifting instructions at $0a5d and $0a6d that might be involved in this process.

Just after setting up the character data at $2000, the program sets VIC register $d018 to $18. This establishes how the VIC uses memory, and indeed, it sets the character memory pointer to $2000. It also sets the screen memory location to $0400. The VIC-II can only see 16 KB of the address space at a time, and which 16 KB is selected by a register at $dd00. Crossroads does not appear to change this register from its default setting.

That’s a good start, and plenty for a single newsletter. Ghidra is a very powerful tool and I’m still learning about all it can do.

Ghidra is highly extensible, and there is substantial potential for extensions and scripts to support C64 and MEGA65 development and reverse engineering. In his video, Jarkko Lehti is using his own Ghidra fork with a few nice features such as PETSCII string visualization.

When I was squinting at the character set data, I was wishing for a bit of tool support for visualizing bitfields as graphics, much like how Retro Debugger lets you view memory contents in different ways. I wonder if Ghidra can do custom inline data visualizers like this, or if a feature like this is already available.

The annotated disassembly can be exported in multiple formats, but none of them resemble something that could be re-assembled by a tool such as Acme assembler. A custom export tool or post-processing script would be handy for that, and would be easy to write.

Of course, the thought naturally occurs to someday use Ghidra to disassemble MEGA65 machine code programs. It’d take some effort, but it is possible to write an extension to provide 45GS02 CPU support to the disassembler. Ghidra has an entire language for specifying new processors called SLEIGH.

It’d also be good to generate symbols files and overlays for all of the MEGA65’s I/O register personalities. I already have symbol generator scripts that could be tweaked to produce something that Ghidra can import.

In practice, most MEGA65 machine code programs that exist today have friendly authors that have open sourced their code. It’s still fun to think about.

I chose Crossroads for this demonstration for a few reasons. For one, it really was one of my favorite games, so I was excited to play with it. But also, I had a suspicion that its internals were straightforward enough to understand through disassembly. As fast and seamless as Crossroads is to play, you only need to know a few things about C64 programming to start to make guesses about how it works just from looking at it.

Many C64 games and demos use data compression techniques to limit disk space and loading times. This can make disassembly more difficult, because you can’t just load the PRG into Ghidra directly. One possible technique is to run the program in Retro Debugger, let it decompress everything into memory, then take a snapshot of the memory of the running program. You can then apply disassembly techniques to the snapshot. I suspected that Crossroads did not use compression for code, and felt comfortable just loading the PRG file directly into Ghidra.

If you’re interested in writing programs for the MEGA65, it’s worth studying C64 programs. The Commodore 65 was designed as a true technological successor to the C64, and many C64 programming techniques apply to C65 and MEGA65 programs. The original source code for many C64 programs have been lost to time, but we can use tools like Retro Debugger and Ghidra to pull them apart and reconstruct their secrets.

There’s one more tool that we can use to reverse engineer C64 programs—and it’s sitting right beside you. The MEGA65 can run many C64 programs in its GO64 mode, and you can use the MEGA65 core’s serial debugger, along with a powerful frontend like m65dbg, to analyze a running program. We’ll have to revisit this in a future Digest.

Onward into the new year!

— Dan

Santa’s Souped-Up MEGA65. Dan’s MEGA65 Digest for December 2024.

Hey everyone! I hope you’re all ready for some end-of-the-year relaxation, maybe some time off work, spent with family, in whatever temperature extreme you’re experiencing in your hemisphere. I also hope you’ll get some time to play with your MEGA65, because you’re gonna need it!

There are so many project announcements this month that I’ve decided to dedicate this entire issue to new downloads, to celebrate everyone’s talent and enthusiasm, and to give thanks for our wonderful community. We will finish our Crossroads disassembly project in January.

SidPlay65 by LightTangent.

There’s a new way to make music with your MEGA65, thanks to MEGA65 developer LightTangent! SidPlay65 is a MEGA65 program that re-implements the SIDPlayer music system from Compute! Publishing. It plays single-SID and dual-SID songs, and supports some advanced SIDPlayer format features like colorful PETSCII banner displays and karaoke lyrics.

SIDPlayer was one of several major tentpole products for the Commodore 64 from Compute!,along with Crossroads and the hit word processing package SpeedScript. The initial version of SIDPlayer appeared as a type-in in the book All About the Commodore 64, Volume Two by Craig Chamberlain. It included rudimentary music editing software, and a player routine that could be embedded in your BASIC or machine language programs. Chamberlain revised the system and published the Enhanced SIDPlayer in the book COMPUTE!’s Music System for the Commodore 128 & 64, this time with a companion floppy disk instead of type-in code.

The SIDPlayer system was a huge hit in the United States, and C64 owners produced thousands of songs and shared them on online services like Delphi and Quantum Link. Some SIDPlayer songs were written to be played on two SID chips simultaneously for a total of six simultaneous voices, made possible by either having two C64s, hacking a C64 to add a second SID chip, or using the SID Symphony Stereo Cartridge from Dr. Evil Laboratories. Today, this legacy lives on in the Compute!’s Gazette SID Collection (CGSC). You can download the whole set, or browse and play the collection in a web browser with the website DeepSID.

LightTangent disassembled the original SIDPlayer program, and used the findings to write SidPlay65. Many thanks to LightTangent for this ambitious project!

HyperBallad by Bjork, as rendered on the MEGA65 by MirageBD.

MirageBD has been researching methods for streaming full-color full-motion video from the SD card. So far, Mirage has produced two brilliant demos: HyperBallad (1995), the Björk music video masterpiece, and Duel, a scene from the movie Electric Dreams (1984). Both demos launch from a D81 disk image, and stream data directly from a large file on the SD card.

Important note: Running these demos requires a fast SD card, very likely an SD card faster than the one that was included with your MEGA65. As lydon explained on Discord, the bundled cards are optimized for a longer lifespan, at the expense of some speed. If these demos glitch out after the first couple of seconds, consider getting a SanDisk Ultra brand microSD card.

COPA65 by Bananzi. (Image from the manual.)

Ever wanted to copy and paste text in the MEGA65 screen editor? Now you can, with this clever extension by Bananzi! COPA65 adds a text clipboard to the built-in editor experience, as well as both keyboard and mouse methods for selecting text.

With COPA65 installed, simply press Ctrl + C to wake it up, then press one of the command keys. For example, use the C command (press Ctrl + C, then press C) to set the start of a selection, move the cursor to the end of the selection, then use the C command again to copy the text. Finally, move the cursor to where you wish to paste, then use the V command.

Other commands can quickly select characters, words, and lines, and can insert pasted text instead of overwriting. See the detailed manual included with the download for instructions on installation and use.

COPA65 requires ROM beta version 920398 or later, which is when we formalized the extension mechanism being used. This is newer than the ROM included in release package v0.96. You can update to the latest ROM beta version, or wait for the v0.97 release package, which hopefully will be out soon.

Really amazing work, Bananzi!

Midnight Mega by nobruinfo.

Bruno (nobruinfo on Discord) has been working on a powerful file browser, which he calls Midnight Mega. You can use Midnight Mega to browse your SD card, mount disk images, and view and copy files.

Midnight Mega is still in a beta testing release, and it is recommended to back up your data regularly. Please report any issues you find, and join the discussion on the #midnight-mega channel of the MEGA65 Discord. Also note that it only supports disk images and the internal floppy drive; it does not yet support external IEC drives.

Gurce’s version of Sea Wolf for the Commodore 64, modified to support four players.

My series on disassembling Crossroads is directly inspired by Gurce, who recently disassembled another classic C64 game, Sea Wolf. In this submarine battle game, you (and an optional second player) use paddle controls to maneuver submarines to fire missiles at battleships. The game’s lineage goes all the way back to the electro-mechanical arcade game Periscope by Sega (1966), followed by a similar electro-mechanical version by Midway called Sea Devil. Midway launched a video arcade version under the name Sea Wolf in 1976. Commodore International produced a home version for the VIC-20 and C64 in 1982.

Gurce made two videos about his disassembly project. Part 1 introduces the game and the project, and presents a few findings. The extended part 2 presents the entire project, with live demos and slides. You can read Gurce’s complete notes and the final disassembly on Github. With disassembly in hand, Gurce was able to modify the game to support four players, with two paddles on each of the two joystick ports.

Disassembling classic games is a great way to learn about programming for the C64 and the MEGA65. What game would you disassemble?

Stargate (1981).

muse has given us another arcade core! Stargate is the 1981 sequel to the arcade classic Defender, a fast-paced horizontal shooter. As with other arcade cores, you will need to search for ROM data files and follow the installation instructions. The core is available for both R3 and R6 mainboards.

Fireplace is a short BASIC demo by Urban Lindeskog, featuring PETSCII flames and crackling sound effects. Drag your MEGA65 out to the living room and run this for the holidays to keep your family warm.

RobH developed an example of sprite to character collision detection in BASIC, then followed up with a Lode Runner-like ladder climbing demo. These demos show off how to implement several game mechanics with this technique, including a player sprite, walls, collectibles, ladders, and doors. Both include well-commented BASIC source code.

Alpha Burst is a brief graphics-only demo by Drex, with brilliant colors and a borderless display. Run this on real hardware for full effect.

Disk Doctor Mega by tundra/C is a low-level disk viewer and editor for both physical floppy disks and virtual D81 disk images. Inspect your disk tracks and sectors, and potentially recover data from damaged disks.

Unelite Part 1 by mk9 is a text adventure game with PETSCII graphics. Use the joystick to select options in this branching sci-fi narrative.

45GS02 quick reference, by dddaaannn (that’s me).

I brought a few gifts to the party as well. You can still buy the 45GS02 quick reference as a mousepad or a poster. If you’d prefer a digital copy, you can now download the 45GS02 Quick Reference PDF for free. I also uploaded the BASIC65 Quick Reference PDF from the User’s Guide for similar convenience.

When I took my MEGA65s to computer shows earlier this year, I made some paper items to keep at the table to help show it off. I have uploaded these designs to Filehost, in case anyone else wants to use them. The MEGA65 Conference Table standee design is designed to be printed professionally on a 11" x 17" sign, and has facts and figures about the computer. The MEGA65 Demo Booklet prints in landscape orientation on 8-1/2" x 11" paper, suitable for spiral binding on the top long edge, and features diagrams, screenshots, and very brief instructions intended for someone unfamiliar with the computer to try it out in just a few minutes. Accompany this with an SD card pre-loaded with the mentioned disk images for full effect.

Santa called his elves together

He’s got a million miles to travel

Got a rocket burnin’ mighty quick

When you hear that rocket roar

— “Santa’s Souped-up Sleigh,” from the film Melvin & Howard, dir. Jonathan Demme

Have a great holiday! See you next year.

— Dan

Disassembling Crossroads, part 1. Dan’s MEGA65 Digest for November 2024.

One of my all-time favorite games for the Commodore 64—and I know I’m not alone in this—is Crossroads, the single-screen maze shoot’em’up by Steve Harter, published in Compute!’s Gazette magazine as a type-in program in December 1987. The game features dozens of enemies of a variety of types and colors, all fighting each other in a cacophony of attacks and explosions. You’re dropped into the fray to collect items called “spars,” which provide you some protection against attacks, and which the enemies also consume. The game supports one or two players on joysticks, and both players battle for survival simultaneously.

Some people like to say that typing in programs from magazines and books helped them learn how to write programs of their own. I can see how that might be true for BASIC programs, though I can’t honestly say I learned anything from type-ins when I was in grade school. For programs written in languages other than BASIC, Compute! offered no way to learn. In this interview with Steve Harter by Kirk Israel, Steve says he wrote Crossroads in assembly language, but Compute! never published assembly language listings for full programs in magazines. Instead, Compute! published such programs as columns of numbers, along with a helper program that assisted with keying these values directly into memory. The most you could learn from these type-ins was data entry, and perseverance.

(I’m aware of only two cases where Compute! published full assembly language program listings for the C64, both as books: the LADS assembler and the SpeedScript word processor. Steve wrote Crossroads using LADS. Also, as I mentioned a while back, Compute!’s Gazette did include the assembly language source code for Fast Assembler on the cover disk, just not in the magazine.)

Over the next two issues of this Digest, we’ll crack open the original Crossroads program and see what we can learn, using two modern reverse engineering tools for your PC. This month, we’ll take a look at Retro Debugger, a C64 emulator with real-time memory visualization features. To keep this newsletter to a reasonable length (😬) we’ll discuss just enough to get started, and ask a few specific questions of interest about the game.

As always, let us begin with some MEGA65 news!

Filehost high score tables.

Filehost has a fun new feature for competitive MEGA65 gaming: high score tables! When you upload your game to Filehost, you can choose to enable “Highscore submission.” This allows players to submit their high scores by clicking the plus ("+") button on your game’s Filehost detail page, uploading a screenshot as evidence. All score submissions must be approved by you before appearing on the page. You will receive a message when a player submits a score for your game.

Check out the high score table on Classy as an example.

Thanks as always to Tayger for the Filehost innovations! Everyone go out and rack up those high scores!

Ghosts’n’Goblins arcade core for the MEGA65, now available for R6 boards.

Over the last year or so, muse has given us alternate cores for the arcade games Galaga, Ghosts’n’Goblins, and Xevious, originally released for the R3 mainboard. Now, thanks to Robert Jaremczak (rjaremczak), there are R6 versions for these cores: Galaga R6, Ghosts’n’Goblins R6, and Xevious R6. See the original installation instructions for the R3 cores, which also apply to the R6 versions.

zeldin has updated the TI-99/4A core several times since its initial release, and as of version 1.3, the core is available for the R3 mainboard as well as R6. Go grab the latest, and be sure to file any bugs you find.

I had a few people respond to last’s month’s Digest to point out that core availability is currently a sticking point with regards to mainboard revisions, with some cores only available for R3 and others only for R6. Core developers must put in additional effort to support both mainboards, and not everybody owns both boards for testing. If you’re working on a core and need assistance building it for a board revision that you do not own, please reach out to the MEGA65 community on Discord or by email. We will eagerly connect you with resources for building and testing your core on both revisions.

Thank you Robert and zeldin for working on cores!

Back in 2022, we noticed that a small but significant percentage of R3 mainboards had faulty Real-Time Clock (RTC) chips. Paul quickly put together a workaround involving a core update and an inexpensive RTC breakout board and Grove connector. This requires a soldering iron to put together, but no expertise: it’s just four wires. Nevertheless, I wanted to make sure that everyone who needed one could get one easily, so I built a bunch of them and made them available for the cost of shipping. The MEGA65 team also supported this effort financially out of their own pockets.

I will be ending my distribution offer at the end of 2024. I have about a dozen units remaining, and am willing to send them out to anyone who needs them. If you have an R3 mainboard and believe your Real-Time Clock is faulty, please follow these instructions for testing your RTC and requesting a unit. I will email you with instructions to send me the shipping cost by PayPal, then get one out to you, while supplies last.

Please do not request one if you don’t need one. Only a fraction of the MEGA65s delivered in 2022 have this issue. Follow the instructions to test your MEGA65 before requesting a replacement. If you discover you need one later than the end of this year, consider ordering the parts and cooking one up yourself. These are easy to build!

Controlling a MEGA65 with a Switch Pro controller, 8bitDo Retro Receiver, and sega-adapter.

Last month I mentioned the sega-adapter project by Eyvind Bernhardsen as a fun way to connect Sega Genesis-style game controllers to Commodore computers. Since I sent the newsletter, I had some boards printed, got the parts together, and assembled a few. Chat, I recommend it, especially when used with the 8bitDo Retro Receiver for Sega Genesis ($16 on Amazon). The 8bitDo Retro Receiver pairs with almost any modern Bluetooth game controller, including Nintendo, Playstation, and older Xbox controllers (but not newer Bluetooth LE Xbox controllers). 8bitDo also makes a Bluetooth Sega Genesis gamepad; be sure to get the M30 Bluetooth model, not the “M30 2.4G wireless” model. I got my Nintendo Switch Pro controller to be a 3-button game controller for my MEGA65!

I wrote a brief article on my blog about assembling this project if you want to know more. It was easy, but it was my first encounter with PIC microcontrollers, so I had a few things to learn. It was a fun afternoon project with a satisfying result, and because I made ten, I have my holiday gifts all sorted.

The first step to reverse engineering anything is to understand what the thing does. We can learn a lot about Crossroads just from playing it.

Archive.org has complete scans of Compute!’s Gazette magazine, and Crossroads is in issue 54, December 1987. An amusingly nostalgic way to acquire the Crossroads program would be to enter the “MLX” data entry program listed in the magazine, then use MLX to enter the 6,676 hexadecimal numbers for the game. (That’s 5,935 program bytes, plus error checking digits.) I recommend simply downloading the Compute!’s Gazette cover disk image archive. The disk image for the December 1987 issue is named 1987-12.d64. This disk image works great with the C64 core for the MEGA65. (Alas, I could not get it to run in GO64 mode. Maybe later we can figure out why.)

We can learn some useful things about Crossroads even before we run it. If we browse the disk directory, we can see that there are many files from this issue of the magazine, but the game likely consists of a single PRG file named CROSSROADS.

We can load this file from disk into memory, using the ,8,1 arguments to LOAD to tell it to use whatever memory start address that CROSSROADS prefers:

The program loads, and we’re back at the READY. prompt. Because the game didn’t do anything fancy to start automatically, we can guess that the program has loaded to the start of BASIC memory, and probably begins with a BASIC bootstrap program that invokes the machine code, like we’ve done for our own programs. Let’s confirm this:

Sure enough, there is a one-line BASIC program in memory:

Connect a joystick to port 2 (first player), then start the program with the RUN command. The game starts without any further disk activity, which confirms our hypothesis that this is a single-file game.

If you’ve never played Crossroads before, take some time to enjoy it! Shoot bullets at monsters by pressing the fire button, and collect the white spinning “spars” to gain shields and progress to the end of the level. Connect a second joystick and invite a friend!

As you play, try to make some guesses about how the game works, and come up with some questions you would like answered. Your own questions and hypotheses will guide your reverse engineering process.

Here are just a few things I noticed that might be worth exploring:

Program states. The game starts with an “attract mode” where a bunch of enemies duke it out on a maze without a player present, and with a scrolling message across the top of the screen. Like many vintage arcade games, attract mode appears very similar to gameplay, and likely reuses the game’s logic with minor changes. The game starts the first level when the player presses the fire button. Each level starts with an introductory animation where creatures appear with special graphical and sound effects. The players are the last to arrive. Then play begins. A level ends when a player collects a number of spars, at which point the game pauses until a key is pressed, and the game restarts at the next level. The game ends when both players are out of lives.

Creature properties. Creatures and players have a number of shields that protect them from attacks. Each attack deducts a shield, and the creature is destroyed when attacked without shields. A creature or a player gains a shield by picking up a spar. The player’s shield count appears at the top of the screen, under the “S.” Other creatures also have shield counts, but these are not visible. Player actions are controlled by joystick inputs; creature actions are controlled by algorithms. Each creature is of one of nine types, and the type describes their action patterns, reactions to collisions with bullets and other creatures, and the initial number of shields.

Character graphics. The maze and the creatures appear to occupy a grid in the same shape as the C64’s 40 x 25 character mode, and every element appears to be the size of a single character. It’s likely that at least some of these graphical elements are using VIC-II character graphics, where the glyphs of some letters, numbers, and symbols in the PETSCII typeface have been replaced with these designs. Each element is of a single color and high resolution, 8 x 8 pixels per character.

Creature half-steps. Even though creatures are the size of a single grid tile, they appear to traverse the screen in half-tile steps! If creatures are implemented with character graphics, the game must be doing something interesting to allow a creature to appear this way.

Sprites. There appear to be too many creatures and bullets on the screen at one time for the game to be using the eight VIC sprites to draw them. While advanced techniques like sprite multiplexing (which we discussed previously) could use sprites to draw more than eight objects at a time, there’s nothing in the design of this game that prevents more than eight objects from appearing on the same scan line, so this seems unlikely. However, there is an explosion effect that occurs when a creature takes damage, and this appears to overlay the character graphics. This suggests that this effect might be done with sprites.

Sound. The soundscape of Crossroads consists entirely of sound effects that represent activity on the screen: creatures appearing at the start of the level, player bullets firing, enemy bullets firing, shields absorbing damage, creatures and bullets being destroyed, and spars getting collected. There’s so much going on early in the level that each sound may be difficult to pick out, and it’s a bit easier after the screen is mostly clear. I’ll be interested to see how sounds are allocated to the three SID channels, especially when there are more than three events causing sound at a time.

In that interview with the developer that I mentioned earlier, Steve confirms that the creatures use character graphics, and the explosions use sprites. Steve also mentions that the sprite images for the explosion animations are generated randomly.

We want to use modern PC tools to examine the program, so we need to extract the PRG file from the disk image. Graphical tools like DirMaster (Windows only) or DroiD64 (Java, multi-platform) work nicely, or you can use the c1541 command included with the VICE emulator:

You can use a tool called a hex viewer to examine the bytes of the PRG file. I like a terminal-based hex viewer called hexyl, and there are many others to choose from. We won’t spend more than a minute staring at raw bytes, but we can use this to get our bearings. Here are the first few dozen bytes of the PRG file:

As we’ve seen before, a PRG file starts with two bytes that specify the load address for the program. In this case, the first two bytes are $01 and $08, specifying the Commodore 64 BASIC start address of $0801 hexadecimal, or 2049 decimal. The PRG address bytes are not written to memory, they only tell the BASIC command LOAD "CROSSROADS",8,1 where to put the rest of the data.

The subsequent bytes describe the one-line BASIC program we saw earlier:

These 12 bytes start at address 2049, which means the rest of the program data starts at address 2061 ($080d). Interestingly, the SYS command uses address 2300 ($08fc). The data starting at address 2061 might be code, or it might be something else. We don’t know yet. We only know that the byte at address 2300 is the beginning of a machine code instruction, and that it’s the first instruction executed by the program.

It’s amusing to compare this hex dump to the listing in the magazine. (Well I think it’s amusing.) Note that Compute!’s Gazette program listings have nine bytes on a line, but only the first eight bytes are part of the program. The ninth byte is a checksum, which the MLX program uses to verify that you entered the line correctly. If it didn’t do this, entering these programs would be a nightmare, as opposed to merely a nuisance.

If programming is the art of telling a computer what to do, debugging is the art of figuring out why it’s not doing what you meant. One of the best ways to do that is to peek inside the computer’s memory as it steps through your instructions, and try to line up the evolving state of the computer with your own mental model. This process is often so opaque and frustrating that I sometimes wish I could just rip the top off the chips and look inside as the program is running. Thanks to high fidelity emulators running on modern computers, this fantasy is now a reality.

Retro Debugger by Marcin Skoczylas is an emulator for the C64, Atari XL/XE, and Nintendo Entertainment System, with some powerful real-time debugging tools. As the emulator runs, you see the C64 screen in one window, and use other windows to render the memory in different useful ways: as hex values, as machine code instructions, as graphics in common VIC-supported formats, and as a color-coded memory map. All of this is updated as the emulation runs at full speed, and you can pause execution and manipulate system state as a program runs.

Let’s use Retro Debugger to inspect Crossroads, and follow up on a few of our assumptions about how the game does graphics.

Download the latest Retro Debugger release for your platform (Windows, macOS, or Linux). You also need the original C64 ROM and 1541 DOS code. Retro Debugger opted not to include these in the distribution, but you can get them directly by installing the VICE emulator. You’ll have to dig around the VICE folder for the appropriate .bin files. On my Mac, I found them here:

Retro Debugger needs the ROM files to be in a single folder, with specific filenames. Create a new folder for these (such as inside the Retro Debugger folder), make duplicates of the files from VICE, and rename them as shown:

When you start Retro Debugger for the first time, you need to tell it where to find the ROM files. Open the Settings menu, select C64, then Select C64 ROMs folder. Navigate to the folder you created with the ROM files in it. Retro Debugger loads the ROMs and starts the emulation. If it complains, make sure the ROM files are in the right place and have been renamed as expected.

Behold, the insides of the C64! You can see the CPU bouncing around the instructions for blinking the cursor at the READY prompt, and all of the memory and register updates that go with it. With the “C64 Screen” window active, you can interact with the C64 as you would with VICE, typing BASIC commands and whatnot.

Retro Debugger starts with some of its tools visible, but there are many more. With the cursor still at the READY prompt, open the VIC Editor menu, and select C64 Charset. The C64 Charset window opens. At this point, you should see what the VIC is currently using for its character set, which at the moment is standard C64 PETSCII. Resize the window to make the characters easier to see.

On my computer, I need to make the text bigger to be useful. Some windows, like the C64 Screen and Charset windows, have fixed-sized content, and you can drag the window corners to resize. In other windows, to increase the text size, right-click on the window, then adjust the Font Size slider. These windows can also be resized to display more information. The app will remember your window layout between sessions.

Retro Debugger is based on VICE, and has all of its debugging features. To pause the emulator, press F10 (or open the Code menu, then select Pause). While paused, press F10 repeatedly to advance by one instruction at a time. Press F11 to resume full speed. You can also set breakpoints on instructions, set watchpoints on memory locations, and can navigate to instructions that access specific memory addresses. You can even rewind the emulation to the instruction that last accessed a memory address.

For more information on features and keyboard shortcuts, see docs/README-C64-65XE-NES_Debugger.txt, included with the program.

There are two ways to get Crossroads running in the emulator. One method is to open the D64 disk image, then type the BASIC commands to load and run the game, as you would on a C64. Because Crossroads is a single PRG file, you can also just open the PRG file that we extracted earlier. Opening the PRG is often faster, especially if you need to reset the program.

Open the File menu, then select Open. Select the crossroads.prg file. This will load and run the game immediately, so prepare your speaker or headphones volume for the game’s violent introduction.

Next, open the Settings menu, then Joystick #2, and select a configuration for the joystick. With the joystick set to “Keyboard,” the cursor keys move the stick, and the right Alt key is the fire button. Or you can connect any PC-compatible game controller. If a controller is connected, its device name will appear in the menu.

Select the C64 Screen window, then press fire to start a game. Good luck!

We have a hypothesis about how Crossroads uses character graphics. Let’s see if we can confirm this hypothesis in Retro Debugger.

When you started the game, it installed a new character set and told the VIC to use it. The Charset window now shows new graphics tiles: a limited set of PETSCII letters and numbers, and nearly all of the graphics for the game. You can see four types of maze wall, the “spar,” and various images for each of the creature types and bullets facing all four directions. Each of these are unique tiles of 8-by-8 pixels, and the tiles can be placed anywhere on the 40-by-25 tile grid.

We’ve made a discovery! The spar appears to be animating directly inside the Charset window! While Crossroads animates creatures using multiple static tile definitions, it animates the spar simply by continuously updating its single tile definition. This conserves charset tiles, at the expense of some CPU time.

If we squint, we can start to see how the game achieves its “half step” effect for creatures. When a creature is standing fully on a tile position, it is drawn as a single tile based on which direction it is facing. When a creature is walking between two tile grid spaces, it occupies both spaces, with a tile for each half of the image. There is a tile pair for each of the four directions. Each creature has two animation frames, and it appears that Crossroads stores both frames as single tiles, and uses only the second frame for the half-step tiles, for a total of 16 tile definitions per creature.

The Charset window determines the memory location of the character set data that the VIC is using based on hardware registers, then draws the data it finds as characters. We can use some Commodore 64 knowledge to figure out where in memory this character set is stored.

The way the VIC-II accesses memory is a little bit complicated. The VIC can only access one of the four 16 KB banks at a time. Additionally, the C64 architecture makes a special accommodation so the VIC can access the PETSCII character set from an upper bank of ROM even when a lower bank is selected. This configuration for how the VIC sees memory is managed by the second of the C64’s two CIA chips. This is controlled by the lowest two bits of the CIA data register at $DD00.

In Retro Debugger, select the C64 Memory window. With this window selected, you can use either the Page Up/Page Down keys or your mouse’s scroll wheel to browse memory. You can also jump directly to an address by pressing Ctrl+G (or on macOS, Command+G), then typing the address in hexadecimal. Use this to jump to the register address $DD00.

Tip: Be careful what you type when the Memory window is active. If the cursor is on a memory value, typing hexadecimal digits will modify memory. When you type Ctrl+G (or Command+G) to go to an address, double-check that the cursor has moved into the address column before typing the address.

With Crossroads running, the register at $DD00 is set to $C7, so the lowest two bits are %11. According to C64 technical documentation, this points the VIC at bank 0, addresses $0000-$3FFF. It also tells the VIC to see the PETSCII character set at addresses $1000-$1FFF, hiding the RAM at these addresses from the VIC. This only hides the RAM from the VIC, not the CPU.

Still in the C64 Memory window, jump to register $D018 (53272 decimal). This register tells the VIC where to find screen memory within the selected bank, and where to find the character set. With the game running, this appears to be set to $19. This value is interpreted as follows:

Be aware that the character memory offset gets described in manuals and online resources in different ways. I just described it the way the C64 wiki does: a three-bit number times 2048. Other books, including the MEGA65 manual, describe it as the upper three bits of a four-bit number whose last bit is 0, times 1024. The math works out the same either way.

With the selected CIA configuration, a program could tell the VIC to use the PETSCII character set from ROM by setting the three bits to %010 = 2 times 2048 = address $1000. Crossroads tells the VIC to look at $2000 instead, which is RAM where Crossroads can install its custom character set.

Let’s confirm our understanding. In the C64 Memory window, go to address $2000.

The C64 Memory window doesn’t know what the values in memory mean, but it tries to help us out by displaying them in four different ways: as hex bytes, as PETSCII characters, as character graphics data, and as sprite graphics data. In this case, we’re looking at character graphics data, so that view makes the most sense, and the other views are mostly nonsense. Scroll down to address $21F8 to see the spar glyph data being animated by the program.

The C64 Memory window lets us peek into the computer’s memory as it is running, and also lets us change memory as we like. If we knew where to look, we could change properties of the game, such as the number of lives the player has. So how do we know where to look?

Locating variables is such a common task that the debugger has a tool just for this. Open the C64 menu, then select the C64 Memory Monitor. (This is a new tool, not the C64 Memory window that we’ve been using.) Resize this innocuous-looking little window to make it bigger.

Start a new single-player game by pressing the fire button on the joystick configured for port #2. The level clears, creatures spawn in, and finally the player arrives.

The player starts with 4 lives. We can know for sure that somewhere in the computer’s memory is a representation of this value, and this representation will change when the player loses a life. We don’t know where it is, or how the value is represented.

Let’s take a guess that the number of lives is stored as a byte, encoded as a non-negative integer. In other words, if we search the computer’s memory for a value of 4, there’s a chance that this might be how it stores the number of lives. This is just a guess! We can start with this, and refine our guess if it doesn’t work out.

With the emulation still running, in the C64 Memory Monitor, click the Capture button. Retro Debugger takes a snapshot of all of memory, and a giant list of memory addresses and values appears. Next, set the filter settings:

The list narrows to just the memory addresses that were 4, and are now 3. You may see more than one row, but likely only a few. Of all 65,536 memory addresses in the computer, these are the only ones that meet the criteria. This list updates in real-time as the emulation runs, and some rows will flicker in and out as memory changes.

Select the C64 Screen window again, and use your gamepad or the keyboard to move the player into harm’s way until they run out of shields and lose a life. The number of lives shown in the top display reduces to 3. Press F10 to pause the emulation.

One of the addresses that meet the filter criteria in the Memory Monitor is $0011. Let’s take another guess that this is player 1’s life count. This is a good guess for at least two reasons. It’s an address in the Zero Page (addresses $0000-$00FF), which is a common place to put variables. It’s also the only row that doesn’t flicker while the emulation is running.

On the row showing address $0011, click the “Memory” button. This updates the C64 Memory window to highlight that location. As expected, its value is currently $03. Now change this value: select the Memory window, then type 07. Press the F11 key to unpause the emulator.

Hmmm, the number of player lives on the screen still shows “3.” Was our guess incorrect? Try killing off the player one more time. Success! The life count now reads “6,” one less than the value we set. Double-check that the value at address $0011 is now $06.

When we dig deeper into the machine code next month, we should expect to find instructions that manipulate address $0011, and can probably assume that the code is related to the number of lives of player 1. We can use that information and some inductive reasoning to determine the purpose of the surrounding code, and figure out the rest of the program.

We got a bit lucky with our guesses in this example, though truthfully many games store the number of player lives this way. What if our guesses were wrong, and the number of lives wasn’t stored as a non-negative integer in a byte value? One possible strategy would be to locate the code that updated the “4” on the screen to a “3.” We could use the Memory Monitor against the screen codes for those characters, or we could locate the screen memory address and ask Retro Debugger to tell us which instruction last changed it. It might be possible to figure out from nearby code where it reads the value that it displays, and how the value is interpreted.

Retro Debugger comes packed with plenty of toys for messing with the state of the emulator. Browse the menus and experiment! Most menu items open a new window with interesting features. Here are just a few ideas.

Locate that first instruction. Recall that the BASIC bootstrap invokes the machine code at address 2300, or $08FC in hexadecimal. Pause the emulator by pressing F10. Select the C64 Disassembly window, type Ctrl+G (or Command+G for macOS) to go to address $08FC. We can see that the first few instructions initialize some hardware registers: $D40E, $D40F, $D412. You can look up these addresses in C64 technical documentation to see what they do. Researching all of the code this way is a bit tedious, but it’s fun to see the code sitting right there in memory. We’ll use a more powerful tool for investigating this code in next month’s Digest.

Watch the SID chip make sound. Open the C64 menu, then the C64 SID sub-menu, then the C64 SID tool. The C64 SID window opens, showing information about the SID chip’s three sound voices. (Check out one of the earliest Digest issues for an introduction to the SID chip.) Keep this window open, play the game for a bit, and watch the SID waveforms as the enemies duke it out.

Draw on the screen. Open the VIC Editor menu, and select Show VIC Editor. This window resembles the screen, and by default shows the tile grid and the pixel grid. This is a powerful tool for updating the VIC data in real time, and there’s quite a bit of documentation of its features in the text file. For now, select the C64 VIC Editor window, then left-click on an empty space on the Crossroads maze. It fills in with a character. Try making a wall of characters in the maze. Another discovery! The characters block the path of creatures, and the player! It is likely that the game code reads screen memory directly to detect whether a creature is adjacent to a wall.

Watch for sprites. The VIC Editor highlights sprites with a red box. If you zoom out in this window with the mouse scroll wheel, you can see that Crossroads keeps the sprites off screen when not in use. Play the game to cause explosion effects as shields and creatures are destroyed. Notice that the red boxes appear around the explosions in progress, then retreat out of view when no longer needed.

We’ve only scratched the surface of what Retro Debugger can do, and we’ve already learned quite a bit about how Crossroads works. We’ll be able to apply this knowledge as we start investigating the code.

Next month, we’ll introduce Ghidra, a powerful tool for inspecting machine code. With some effort and ingenuity, we’ll be able to produce a complete human-readable assembly language source listing for the game—the listing that Compute!’s Gazette refused to print.

Before you ask: no, there is currently no real-time memory visualization tool like Retro Debugger for the MEGA65 or the Xemu emulator. Yes, it would be cool. LGB tells me more work is needed on Xemu before it can support real-time memory visualization. In the short term, we’re more likely to see investment in the serial debugging protocol and tools like m65dbg, which can be used with both the Xemu emulator and with real MEGA65 hardware over a JTAG connection.

This Digest is made possible by an amazing group of supporters. Only supporters are allowed to complain when the feature article isn’t specifically about the MEGA65. To become a supporter, visit: ko-fi.com/dddaaannn

More next month!

— Dan

Up Up Down Down Left Right Left Right B A Start. Dan’s MEGA65 Digest for October 2024.

Everyone who owned a Commodore 64 had at least one joystick, a game controller consisting of a lever that could be pushed in eight directions and a single action button. Games based on this controller typically involved the player using the stick to move an avatar—a spaceship, a person, a creature—as well as pushing the action button to activate a weapon against some enemies. The button on this kind of joystick was almost universally referred to as the “fire” button for how often it was used to launch missiles or shoot bullets.

Then came the Nintendo Entertainment System with its gamepad controller, a plastic rectangle with a directional thumb pad, two action buttons, and two more business-like buttons intended for pausing the game and accessing menus. NES games, especially Super Mario Bros. and The Legend of Zelda, popularized a new game design language based on the two action buttons. While Mario-like platform games were made for the C64 and its one-button joystick, expecting the player to shove the joystick forward (“up”) to jump, every generation of gamers that followed the NES expected to be able to jump in a platform game by pressing one of the two action buttons.

The vast majority of C64 games used the one-button joystick protocol. But there have been several attempts, both vintage and modern, to bring multi-button gaming to the C64, and to other computers with 9-pin joystick ports. This is of particular interest to modern retro game developers who want to use multi-button game design conventions while coding for the C64 and MEGA65.

In this Digest, we’ll explore a bit of the history of 9-pin game controllers, and investigate several methods used to implement multi-button schemes. We’ll look at the fundamentals of game controller electronics, and game controller programming. We’ll also take a closer look at several modern game controllers and controller adapters you can buy today for your MEGA65.

But first news!

MEGA65 replacement keyboard, one of several MEGA65 parts now available separately.

Last month, we noticed that Trenz Electronic is now making the MEGA65 mainboard available for preorder as a standalone part. Trenz has since added more MEGA65 parts to their store: the MEGA65 keyboard, the plastic case, the floppy drive, and the power supply. The keyboard is a sophisticated part, including the mechanical key switches, keycaps, cable, metal frame, and LEDs. The case includes other plastic bits such as the ALPS floppy drive eject button and reset button cap. You could, in theory, assemble a full MEGA65 from the spare parts available.

Math wizards may notice that the cost of the parts all together add up to more than the cost of a complete MEGA65. I can’t speak for Trenz, but this jibes with my limited understanding of the microeconomics of short-run niche electronics. Without economies of scale, Trenz has to account for labor, logistics, and potential lossage to support the individual items, even when pulling from the same stock they use to assemble full units. As deft puts it, “Imagine buying a car one piece at a time.”

I’m grateful that they’re making these available, so we have potential replacement parts, as well as options for other projects.

Did you receive your MEGA65 in 2022, or buy it second-hand from someone who did? Then your computer has the revision 3 (R3) mainboard. Starting in 2024, Trenz Electronic began shipping MEGA65s with the revision 6 (R6) mainboard, which has several changes from R3. If you’re unsure which MEGA65 mainboard you have, you can double-check which one you have in the MegaInfo panel: open the Freezer (hold Restore for one second, then release), then press Help. It’ll say which one you have next to “MEGA65 Model.”

Should owners of the R3 board upgrade to the R6? Probably not. It is unlikely that a difference between the R3 and R6 mainboards would be worth the cost of a new mainboard to most R3 owners. The differences may not even be noticeable.

There are a few notable categories of changes between the R3 and R6 boards: bidirectional cartridge and joystick I/O lines, an added SDRAM chip, and electrical fixes.

Bidirectional cartridge lines. The original R3 mainboard supports the vast majority of cartridges made for the Commodore 64, which provide program data as input to the computer. It will also support cartridges made for the MEGA65 in the future. The cartridge port changes in the R6 board apply to a few electronically fancy cartridges that communicate with the computer using both input and output. For example, the MSSIAH MIDI interface cartridge works with the C64 core, and requires the R6 mainboard. EasyFlash 3 is also known to require the R6. Notably, an EasyFlash 1 cartridge can be both read from and written to by an R3 MEGA65. That’s how we’ve been testing the MEGA65 cartridge protocol.

Bidirectional joystick port lines. The original R3 mainboard also supports the vast majority of game controller peripherals for the C64, which provide input to the computer about how the user is manipulating the controller. A few unusual peripheral designs use the data lines for both input and output, to implement more buttons or other features with proprietary protocols. The R6 mainboard adds support for such protocols. See this month’s feature article for more on game controller protocols.

SDRAM chip. The R6 adds an SDRAM chip that is intended to broaden the possibilities for alternate FPGA cores. It is possible that someday there could exist an alternate core that requires the R6 and doesn’t run on the R3. Personally, I think it’s worth tempering these expectations. I’ve discussed this with a bunch of people familiar with MiSTer-style core development, and they have all estimated that the most compelling alternate cores for the MEGA65—including an Amiga core—should fit the original R3 board. There may never be an alternate core that requires the SDRAM, even though it was added for this purpose. No core exists today that requires an R6, and I’m not aware of anyone working on one.

Most importantly, the MEGA65 core does not use the new SDRAM component. All software written for the MEGA65 will run on both R3 and R6 mainboards, now and in the foreseeable future. There are no plans to treat the SDRAM chip as a memory expansion for the MEGA65.

Minor fixes. Lastly, the R6 board implements some minor fixes for known issues. If you are noticing these issues on an R3 board, you may be able to use inexpensive workarounds, such as an HDMI repeater or a replacement Real-Time Clock. If you’re not noticing these issues, you won’t notice the fixes with an upgrade. This category also includes a few changes to accommodate the availability of components; these changes don’t affect the functionality of the computer.

I know I’ve spent a lot of money over the years indulging my FOMO by buying hobby computers “just in case” I want them later, and it’d be hypocritical of me to say an R6 is not a worthy upgrade to an R3 when I own one of each. But given that a new mainboard is more than half the cost of a new MEGA65, it’s worth resisting the temptation to think other people have all of those things and you have none of them. Really, R3 and R6 are mostly identical.

The MEGA65 at the Portland Retro Gaming Expo 2024, prior to opening.

I took the MEGA65 to the Portland Retro Gaming Expo in Portland, Oregon, mere weeks after getting back from Chicago. PRGE is another massive show, but with a different vibe from VCF Midwest. As the name implies, the show is dominated by vintage gaming, with free-to-play arcade and gaming console exhibits, gaming tournaments, several concurrent tracks of talks and panels, meet-and-greet booths with voice acting and YouTube celebrities, and a massive vendor floor with multiple eras of console games and related merchandise.

PRGE has always featured vintage home computing in its line-up, but representation of the home 8-bits on the vendor floor has waned as our vintage hardware has become more collectible. This year, PRGE established a “home computing” exhibit to keep some of our favorite computers in the show. My MEGA65 booth joined several large displays of Texas Instruments, Commodore, Atari, and Apple vintage equipment, as well as more obscure Z80-based computers. I sat closest to the tournament area, where competitors tore through Street Fighter and Rivals of Aether as commentators hyped up the crowd. I was also across from the big surprise of the show, a large display by The Last Blockbuster, with Blockbuster video iconography, merch, and racks of VHS tapes.

My MEGA65 table was much larger and more welcoming to visitors than it was at VCF Midwest. I’m grateful to Hans, the show runner, for gifting me two tables, and for lending me a big screen TV. And I got to hang up the banner! Even in this back corner of the show floor, the MEGA65 drew a lot of attention, and I spent nearly all of the first day on my feet, answering questions, shaking hands, and handing out cards and mousepads. Several people from press outlets wanted interviews. If the fire alarm hadn’t gone off in the middle of the day, I may never have had a break for lunch. The second day was quieter, but I still had quite a few kids stop by for a round of Unicone or First Shot.

It was especially gratifying to see young people take an interest in the MEGA65. Some of them already knew what it was and were excited to see it in person, some dragged their parents over to the table for a look, and several sat down at the computer for long stretches of time to peruse the demo disks and write short programs. I talked to MEGA65 owners and wannabe owners, and plenty of people simply intrigued by an 8-bit style computer that seemed familiar but unlike anything they’d seen before. I got to introduce many people to the stories of both the Commodore 65 and the MEGA65.

The Last Blockbuster

Mega99, a TI-99/4A core by zeldin.

My very first computer was a Texas Instruments TI-99/4A, and now thanks to zeldin, I can recreate those childhood memories! Mega99 is a TI-99/4A core, written from scratch exclusively for the MEGA65. The core needs the ROM files from the MAME project (ti99_4a.zip, ti99_fdc.zip, and ti99_speech.zip) as well as the provided mega99sp.bin file in the root of the SD card. Flash the core to a spare slot in the core selection menu.

As of this writing, the core is only available for the R6 boards. This is not a matter of hardware capacity, and hopefully zeldin can produce a build for R3 owners in the future.

Be sure to read the README.md file for installation and usage instructions. The core matches the 99/4A CPU timing by default, and can also run in a turbo mode. And get yourself the TI-99/4A User’s Guide to remind yourself how this thing works! Hint: the Mega key is the FUNC key, and many text entry features use it.

Thank you zeldin for this excellent and nostalgic core!

Shodan, by Drex

Here are some recent demos uploaded to Filehost worth checking out:

This month’s Digest is all about joystick and paddle programming, so I made a joystick and paddle tester app to go with it. It includes documentation and assembly language source code.

The C64 was one of several early computers that adopted the Atari joystick port standard from the Atari 2600 (1977), and supported the use of Atari game controllers to play C64 games. I’m most familiar with the classic Atari CX40 joystick, but there were many others, and everyone has a favorite. Commodore used the Atari-style controller connector on everything from the VIC-20 to the Amiga, and they intended the C65 to have two 9-pin peripheral ports, just like the C64. The MEGA65 has two 9-pin peripheral ports on the left-hand side.

Nintendo released the NES in the USA with a proprietary controller connector and more buttons, and the game console arms race that followed produced more custom connectors, more buttons, and more evolutions in game design language. Commodore made two attempts to follow suit in their final years, both using new protocols over the original 9-pin connector: the C64GS and the Amiga CD32. These protocols were backwards compatible with older Commodore computers, and the new consoles also supported the one-button controllers and ran compatible games.

Commodore also made several types of computer mice that used the 9-pin connector, especially the 1351 mouse for the 8-bit computers, and the Amiga mouse. As you probably know by now, your MEGA65 supports both types of mice, using built-in adapter logic to make the Amiga mouse appear to software as a 1351. See the User’s Guide, 2nd edition, for information on how to configure the mouse emulation mode. We won’t cover the mice protocols in this issue of the Digest.

What follows is a description of how Atari and Commodore computers use the 9-pin connector for game controllers. Other 8-bit computers and early game consoles used the connector, but not necessarily the same wiring or protocols.

A standard 9-pin one-button joystick tells the computer that the action button is being pressed by connecting pin #6 to pin #8 (the ground pin, labeled “GND”). This doesn’t require any fancy electronics, it’s typically just a button connected to these two pins. When the player presses down on the button, two pieces of metal in the button make contact, completing an electronic circuit. When the player releases the button, a mechanical spring-like action separates the two pieces of metal, breaking the circuit and signaling to the computer that the button was released. This kind of button is also known as a momentary switch.

Pins #1, #2, #3, and #4 work similarly, representing the joystick directions up, down, left, and right, respectively, when connected to pin #8. The joystick indicates a diagonal direction by completing two circuits simultaneously, such as up and left. Typically, there are no fancy electronics involved here either. The joystick is built such that when the user pushes on the stick, it closes one or two momentary switches wired to those pins.

Within the MEGA65, these pins are connected to the Complex Interface Adapter (CIA) chip, which translates these electronic signals into register values that can be read by a program. Try this: connect a joystick to port 2, and run the following simple program:

The program prints the number 127 repeatedly. Move the joystick and press the fire button. The number changes depending on which buttons are pressed.

This register value is a bit field, where each button is assigned to a bit. If the button is not pressed, the bit is 1 (“high”). If the button is pressed, the bit is 0 (“low”). This is why the register value is 127 when no buttons are pressed: all of the bits associated with the buttons are “held high” until they are “pulled low” by the button presses. (The register has additional bits not connected to the joystick pins.)

The one-button 8-direction joystick protocol can be summarized as follows:

It is the program’s responsibility to read these register values, do the math, then change the game state appropriately, such as to move the player sprite around the screen.

Like the C64, the MEGA65 has two CIA chips. Only the first CIA is used to read the joystick ports. And yes, these are the same CIA chips that provide timers and other features.

Register $DC00 represents joystick port 2. To read the status of joystick port 1, you read register $DC01.

C64 owners remember this one: with a joystick connected to port 1 and the cursor at the READY prompt, you can get junk to show up on the screen just by jiggling the stick around. This is no longer true with the MEGA65 in MEGA65 mode (as of release v0.96), but you can still reproduce this in GO64 mode or the C64 core. Try it!

The C64 uses the CIA chip connected to the joystick ports for multiple purposes. This includes reading the keyboard. When you type on the keyboard, it pulls down the CIA bits in certain patterns, just like a joystick on port 1 does. This is why, when the C64 is expecting keyboard input, a joystick in port 1 moving around can seem like typing. Even though you can prevent this effect in code for a game, many C64 games simply assumed that most people would keep their joystick connected to port 2.

The MEGA65 is better behaved because its keyboard handling uses a different mechanism that is not as reliant on the CIA chip. A couple of specific functions still test the CIA for specific key presses, but in general, port 1 joystick events are much less likely to interfere with the keyboard.

BASIC 65 provides a handy function for reading the state of the joysticks. The JOY(port) function returns a value that represents joystick activity on the requested port (1 or 2). Instead of a bit field, the JOY() function returns a number from 0 to 8, where 0 means the joystick is in the center, and 1 through 8 are the eight directions counting clockwise from “up.” When the button is pressed, it adds 128 to this value. See the User’s Guide for a table and example program.

As of ROM beta version 920397, the JOY() function can also read both joystick ports simultaneously, and report a merged result. To request this, use a port number of “3”: JOY(3). This is intended solely to allow a game to work with a single joystick in either port, so the player doesn’t have to change their joystick connections to play. It does not return a useful result when two joysticks are connected and moved simultaneously. If your game uses two joysticks, use JOY(1) and JOY(2) separately. This feature will be in the next MEGA65 stable release.

A machine code program can read the state of the joystick by accessing the CIA registers and interpreting the bits directly. For best results, such a program must take interrupts into account if it leaves the KERNAL interrupt handler active.

The KERNAL interrupt handler messes with the CIA registers many times per second to process certain keyboard events. A program wanting a clean read of the CIA register must disable interrupts to prevent the handler from messing up the result.

The program has to tell the CIA chip to ignore the state of the keyboard when reading the joystick. I won’t cover how this works in detail, just know that the way to do this is to write the value $FF to the data register ($DC00 or $DC01) before reading it.

Here’s the complete sequence for a clean read of port 2 in assembly language:

In addition to joysticks, the Atari controller standard also supports a paddle controller. A paddle uses a dial-like wheel instead of a joystick. A game can detect how far the wheel is turned by reading more registers. This controller is called a “paddle” after the seminal home computer game Pong, which used such a controller to manipulate a paddle in a virtual game of ping pong.

Each joystick port supports two paddles, each with its own dial and fire button. The MEGA65, Commodore 64, and Atari 2600 all have two joystick ports, for up to four paddle players. The two dial-like controls are also used together by peripherals such as light pens or mice, where the two inputs represent movement along X and Y axes.

The paddle protocol is different from the joystick protocol. Electronically, the fire buttons are wired to joystick port pin #3 for the first paddle and pin #4 for the second paddle, connecting them to pin #8 (GND) when pressed. A program can read these pins using the CIA data registers, just like reading the joystick. The register bits read 0 when the button is pressed.

The paddle dial itself is a potentiometer, also known as a variable resistor or “pot.” Instead of simply connecting or disconnecting the path between two pins like the fire button, the potentiometer forms an electrical connection between two pins through an amount of electrical resistance that the computer can measure. When the player turns the knob, the amount of resistance changes, indicating the position of the dial. The first paddle on a port connects signal pin #5 (“POTX”) to pin #7, where the computer provides a voltage of +5V. The second paddle on the port uses signal pin #9 (“POTY”) and pin #7.

The paddle protocol:

Strangely, Commodore used a different potentiometer in their own paddles compared to the ones by Atari, and the two paddle types produce different numbers when accessed from a Commodore program. It is generally understood, and some have measured, that Commodore paddles use a potentiometer rated at 470 kΩ (kilo-ohms), and Atari paddles are rated at 1 MΩ (mega-ohms), with the measured resistance range a bit less but on that order of magnitude. This means that when an Atari paddle is connected to a Commodore, turning the knob goes from the minimum value to the maximum value in half the rotational distance (half the “throw”) than an official Commodore paddle. In practice, this can be both good and bad: shorter throw can result in faster play, but with less accuracy and a large “dead zone” where the resistance is above the maximum recognized by the computer.

I wanted to know the actual resistance value range recognized by the MEGA65, so I started by measuring the resistance of my Commodore and Atari paddles with an ohmmeter. What I discovered was a bit of a surprise.

I took some ohmmeter measurements of my Commodore and Atari paddles, and also tested the values returned by the BASIC 65 POT() function, which returns a value from 0 to 255 based on the dial setting. Both paddles had a minimum resistance in the fully clockwise position, then increased counter-clockwise to their maximum. The Commodore paddles measured a minimum of 44 Ω to a maximum of 166 kΩ. The POT() function returned a value of 220 at the maximum, not the full 255. Atari paddles had a higher resistance of 124 Ω at minimum to 782 kΩ at maximum. Here, the POT() function returned the full 255 after only a third of a turn, with a whopping dead zone of two thirds of a rotation, returning 255 for that portion.

So I opened the cases of both sets of paddles, and discovered that my Commodore paddles have a potentiometer rated at 200 kΩ, far less than the 470 kΩ that others have reported. My Commodore paddles also have a capacitor in parallel with the signal lines. I asked some friends to open theirs and they all reported 470 kΩ pots, so I must have some weird ones. The capacitor doesn’t change the DC resistance, but it does change the way the paddles are read by the computer!

To understand why, let’s first look at how a program reads the state of the paddles.

As with joysticks, BASIC 65 has a function for reading paddles: POT(paddle) returns a paddle position as a number between 0 and 255, and adds 256 if the paddle’s button is pressed. The paddles on joystick port 1 are #1 and #2, and the paddles on joystick port 2 are #3 and #4.

The MEGA65 has dedicated circuitry and registers for reporting the four paddle values. A MEGA65 machine code program can read these values directly from registers.

The fire buttons on the two paddles work just like joystick buttons, and can be read directly from the CIA data register for the appropriate port.

That’s all a MEGA65 programmer needs to know. On the C64, the process is a little more elaborate, and it’s interesting to know why.

The CIA chip only knows how to handle digital signals (1’s and 0’s), and can’t read a resistance value (an analog value in a range). Instead, it gets the help of another chip in the chipset more familiar with converting between analog and digital signals: the SID sound chip.

To read a paddle value, a program first tells the CIA to connect the SID to one of the joystick ports. The program must then wait briefly before reading the value from a SID register. The SID needs a small amount of time to read the resistance value and update the register.

During this time, the SID charges an internal capacitor that is connected to the signal and voltage lines of the controller. Once it is charged, the SID flips to a different circuit that discharges it. The SID determines the resistance of the paddle controller from the amount of time it takes to perform this charge-discharge process.

This is why my paddles still work with a lower resistor value and added capacitors. The capacitors in the paddles are affecting the discharge time of the full circuit that includes the SID.

To convert the discharge time to a value between 0 and 255, the SID needs 512 CPU cycles. At the end of this time, the SID updates its register value.

512 machine cycles at a rate of 1 MHz takes about 1/1950th of a second. That doesn’t sound like a lot, but it can be a long wait for an action game, over 10% of the time it takes to draw a frame of graphics. Of course, the program is welcome to do other things during this time. A game loop could set the CIA select bits at the beginning of the frame, then read the paddle values near the end of the game logic, adding a busy-wait at the end as needed.

The SID can only be connected to one joystick port at a time. To read paddles from both ports, a program must connect to the first port, wait the 512 cycles, read the SID registers, then connect to the second port, wait another 512 cycles, and read the SID registers again. A game that reads all four paddles may or may not need to be clever to use the waiting time wisely, depending on how much time the game needs per frame.

If the program leaves the SID connected to a single port and takes over the hardware interrupt vectors (such that the KERNAL interrupt handler isn’t messing with the CIA connections), it can skip the wait and just read the SID register at its convenience. The register will contain the last stable value.

A C64 machine code program must perform the full procedure to read an analog value from the SID chip: select the port to connect the SID chip, wait briefly, then read the result from a SID register.

To select the port, set bits 6 and 7 of register $DC00: for joystick port 1, set bit 6 = 1 and bit 7 = 0; for joystick port 2, set bit 6 = 0, bit 7 = 1. This is the same address as the CIA data register for reading joystick pins on port 2, but you use this address even when connecting the SID to joystick port 1. That’s just how the CIA chip is wired.

The program then waits briefly for the SID to get the value. On a C64, this is relatively easy: perform a busy-wait loop for some number of iterations. Based on a reference table of cycle counts per instruction, you probably only need 103 or so repetitions of a loop, but it doesn’t hurt to wait longer. The C64 CPU runs at 1 MHz, so 512 CPU cycles is sufficient.

(The MEGA65 normally runs its CPU at 40 MHz. To reproduce the SID reading procedure, you have two options: temporarily down-clock the CPU to 1 MHz for the busy-wait, or perform the busy-wait loop 40 times. Note that instruction cycle counts differ on the 45GS02 CPU than on the 6502.)

After the delay, the values of the two paddles can be read from SID registers $D419 and $D41A. The ROM code that implements the BASIC POT() function takes an additional step to debounce the register value, which just means to wait until two consecutive reads of the register return the same value.

Here is code for the complete procedure, reading the state of both paddles on port 2:

The Commodore 64 Games System (1990), aka the C64GS, repackaged the C64 into a keyboard-less console box. To enhance the console’s gaming potential, the Cheetah Annihilator joystick had two buttons: a trigger button in the joystick grip, and a second button that could be detected separately in the base. This two-button protocol worked over the 9-pin connector and could be supported by any C64 game that knew about it. Only a few games were written to support it.

Math wizards may notice that all nine of the joystick port pins have been assigned: up, down, left (or paddle A button), right (or paddle B button), paddle B (“POTY”), fire, +5V, GND, and paddle A (“POTX”). That’s nine. So how is the second button connected?

In the two-button protocol, the second button uses paddle A’s analog line (pin #9, “POTX”). Unlike the other joystick buttons that connect their respective pins to pin #8 (GND, “pulled low”), this button connects pin #9 to pin #7 (+5V, “pulled high”), with a current-limiting resistor to protect the sensitive CIA and SID chips. (One recommended resistance value I’ve seen is 270-330 ohms.) To a program, a button press looks like a paddle dial flipping between its minimum and maximum positions.

The Cheetah Annihilator only had two action buttons, but if someone were to add a third button to such a controller, it would have an easy way to connect: just use the other paddle line (pin #5, “POTY”). This three-button protocol was uncommon in vintage joysticks, but is generally accepted by controller modders and homebrew controller makers, because it’s a natural extension of the two-button protocol, and doesn’t require fancy electronics beyond the button and safety resistor.

The three-button protocol:

The JOY() function in BASIC 65 knows about the 3-button protocol, and translates high values on the POTX and POTY lines to bit values 256 and 512 added to the total.

To read the complete state of a three-button controller, simply combine the techniques for joysticks and paddles. Here’s an example of reading all buttons from port 2 in BASIC:

Reading the additional buttons from machine code is similar to reading the paddle values. A C64 program must still connect the SID to the port, wait for the SID to sense the button value, then read the value from the SID register. A MEGA65 program can just read the paddle registers.

An 8-way joystick with two or three action buttons brings Commodore gaming one step forward in 1980’s game design language. Math wizards may notice that the NES gamepad has not three but four buttons: A, B, Start, and Select. Can we support all four with minimal changes to the protocol?

5plusbuttonsJoystick, by crystalct, specifies a five-button protocol using a neat trick: button #4 triggers “up” and “down” simultaneously, and button #5 is “left” and “right.” A normal joystick can’t activate these opposing directions at the same time, so they uniquely identify the buttons. This scheme has the disadvantage of not being able to use buttons #4 and #5 simultaneously with the joystick—pressing button #4 and “up” at the same time would only register the button—but they can still plausibly be used as Start and Select buttons, which aren’t typically combined with other buttons during play.

crystalct has published the schematic and board design for a joystick that supports this protocol, and you can order the board from PCBWay. It would be easy to hack a NES-style gamepad to support this with just a few wires.

MEGA65 BASIC’s JOY() function supports this interpretation of the five button protocol. Buttons 4 and 5 add the bit values 1024 and 2048, respectively, to the result. Machine code programs can use the CIA registers to implement this protocol.

Game consoles that followed the NES had seven or eight buttons in addition to the directional pad. How far can we go, using the same 9-pin joystick port?

The protocols we’ve discussed so far could all be considered passive protocols: the controller can report the state of the joystick and buttons to the computer by mechanically completing circuits across the connector pins, and the computer does all the work to interpret these input signals. To be able to report more sophisticated inputs using the same pins, we need an active protocol, where the computer not only reads signals from the controller, but also sends signals to the controller. Perhaps it’d be more accurate to call these bidirectional protocols, because the output signals could be manipulating otherwise “passive” digital electronics in the controller, such as a key matrix. These days, microcontrollers are cheap, and modern game controllers contain tiny computers of their own, capable of an active dialog with the host computer.

The Amiga CD32 game controller provided seven buttons: red, blue, green, and yellow action buttons, left and right shoulder buttons, and one menu button. It used the same 9-pin connector, and did so in a way that allowed the CD32 to support all previous Commodore-compatible passive controllers and allowed the CD32 controller to be used as a passive two-button controller on other Commodores. This required the computer to treat pin #5 as an output pin to select either active or passive mode: the CD32 would hold this pin low relative to the +5V line to request the active protocol—something other Commodores wouldn’t do. When in active mode, the computer sends pulses to the controller on pin #6. With each pulse, the CD32 controller rotates through the seven buttons, reporting the status of each button on pin #9. This mechanism is called a shift register and is typically implemented with a common shift register chip in the controller.

While the backwards-and-forwards compatibility of this design is impressive, it rules out the ability for C64 programs to support a CD32 controller, because the C64 cannot treat pin #5 as an output. Perhaps someday we could add a CD32 controller mode to the MEGA65 core, but there just aren’t many CD32 controllers around.

Sega game consoles also used a 9-pin connector, though they did not use Commodore-compatible pin assignments. The Sega Master System started with a passive two-button controller protocol, and the Sega Genesis (aka Mega Drive) added more buttons (first 3+1 then 6+1) with an active protocol: one pin was a dedicated output from the console that marched through two, four, or eight cycles, alternating high and low, and the definition for each of six input pins changed for each cycle. The full state table is a bit complex, trying to be backwards compatible with previous standards. (This appears to be based on timing? I got a bit lost trying to read about it.)

I always feel obligated to mention: Do not connect a Sega Master System or Sega Genesis controller directly to a Commodore. The incompatible wiring protocol could damage the delicate CIA chip. The MEGA65 is a bit more robust in this regard, but the MEGA65 core won’t assign the pins in a way that matches the controller.

These newer controllers weren’t the first to take advantage of bidirectional communication to support more buttons. The ColecoVision Hand Controller sported the usual 8-way joystick, and also had a number pad with twelve buttons. Surprisingly, this protocol only uses seven of the nine pins, and the computer selects between one-button joystick mode or number pad mode by connecting one of two pins to power. In number pad mode, each button is represented as a combination of the pin signals. For example, when the “5” button is pressed in this mode, pins #2 and #3 are pulled low. When the “4” button is pressed, pins #1, #2, and #3 are pulled low. This means that only one button can be recognized reliably at a time. If “4” and “5” are both pressed, only “4” is recognized.

None of these protocols work with the Commodore 64, and due to the lack of a prevalent commercial implementation, there is no real consensus on a common protocol for Commodore 8-bit computers that supports more than three buttons. One glimmer of hope is the in-progress Protovision Protopad, a project that intends to produce an eight-button controller (four action, two shoulder, two menu) with support for both the passive three-button protocol and a proprietary eight-button protocol, selectable by software. The active protocol uses an elegant and fast multiplexing technique compatible with the C64’s CIA bidirectional capabilities. It’s not clear if or when the hardware part of this project will come to fruition, but the Protopad Development Guide defines the protocol. It’s a fun read. (Well I think it’s fun.)

This brings us back to the topic of MEGA65 mainboard revisions. A Commodore-compatible active protocol game controller would use bidirectional communication over the joystick port data lines, and therefore would require an R6 mainboard. That is, if such a controller existed. I’m rooting for the Protopad, but in the meantime, I’m focusing on passive protocol controllers, which work with both R3 and R6 mainboards.

You can find plenty of vintage Commodore-compatible one-button 9-pin game controllers at flea markets, computer conventions, and online auction websites. Many are still in working order, and hobbyists refurbish and re-sell them. You can also get new 9-pin game controllers ranging from hand-assembled hobbyist projects to limited run Kickstarters to fully manufactured products.

There are also quite a few hobbyist electronics projects to make adapters for non-Commodore game controllers, both new and vintage, so that they work as Commodore 9-pin game controllers. A few of these implement the three-button protocol, or have a way to switch between multiple protocols. You can buy some of these pre-assembled; others are only available as schematics, and require ordering the parts separately and assembling them with a soldering iron.

The following are just a few examples of useful and interesting game controllers and adapters.

RetroGameBoyz gamepads. Mike of retrogameboyz.com has been making new game controllers for vintage computers since 2017. Mike offers a wide variety of styles, platforms, and configurations. My favorites are the NES-style game pads, which include 9-pin connectors, long cables, and attractive decorative faceplates. Mike even makes a MEGA65-themed game pad! This one supports the one-button protocol, and wires the second action button to “up,” which is used as “jump” in many C64 platform games. I’m working with Mike—well, I’ve asked Mike and he’s doing all the work—to produce a custom MEGA65-themed controller that supports the three-button protocol, for future MEGA65 multi-button games.

Neo-Atari controllers. The modern-day company that owns the Atari trademark has made a largely successful play for our nostalgia-filled hearts with recreations of vintage consoles with varying degrees of authenticity and modernity. This includes new versions of the classic 9-pin game controllers, including the CX40+ joystick, the CX30+ paddles, and the CX78+ two-button gamepad. (We didn’t get the Atari CX78 in the USA back in the day, so this is news to me!) Wireless models of the CX40+ and the CX78+ include both 9-pin and USB-A wireless dongles, so you can use them with emulators on a PC and with vintage and retro hardware. I haven’t tested this model of paddles yet and would expect them to support the Atari resistance range.

Hyperkin 9-pin controllers. Hyperkin makes a series of retro gaming consoles, as well as game controller peripherals for consoles old and new. Two of their controllers are compatible with Commodore and Atari computers. The Hyperkin Trooper most resembles the classic Atari CX40, with the fire button duplicated for left-handed and right-handed play. The Hyperkin Ranger is a gamepad-style controller with one fire button, and even includes a single paddle wheel in a unique design. The Ranger also supports left-handed and right-handed play with a switch. Both the Trooper and the Ranger are in stock at Amazon.com.

Note: The Ranger’s paddle wheel is useless on Commodores. The potentiometer covers the full Atari range, 0 Ω to 1 MΩ. Less than a fifth of the throw registers between 0 and 255 with the SID, worse than an Atari paddle. I can barely get a middle value to register in my joystick-paddle tester, and can’t imagine using this paddle knob for Commodore gaming.

Ultimate ArcadeR Classic. The ArcadeR is a one-button protocol 9-pin joystick built to last. It uses arcade-quality parts and is designed to be repairable and moddable, including auto-fire options. The joystick has quite a bit of travel, for better and for worse, and the switches make satisfying click sounds.

(No longer available:) The Commotron wireless gamepad. The Commotron Gamepad Turbo 2000 Super is a fully assembled gamepad with two unique properties. For one, it’s wireless, with a dongle and a range of six meters. And for two, it supports six remappable button layouts including an “up” button in addition to the three-button protocol. Unfortunately, the company that made them no longer exists, and third-party sellers are out of stock. I’m retaining this mention because, well, I own one, and I have included usage instructions below, which to my knowledge are no longer available online.

The Commotron powers on into a mode compatible with the three-button protocol described above, where button “1” is the primary fire button. I couldn’t find the instructions for the Commotron online, so for the benefit of future web searchers:

Retro Rewind C64 Genesis adapter. This pre-assembled adapter converts a Sega Genesis controller to a C64/Amiga controller. It supports both the one-button + “up” button configuration and a C64GS-style two-button configuration, selectable by a jumper (a little metal piece you push onto some pins on the adapter). Another jumper changes which pin is used for the second action button: POTX for “C64” mode and POTY for “Amiga” mode. Use this with a vintage Sega Genesis controller, or combine it with the 8BitDo wireless Genesis-compatible controller for cable-free multi-button gaming.

sega-adapter. If you’re handy with a soldering iron, the sega-adapter project is a Sega Genesis controller adapter with some cool features. It supports both the one-button + “up” protocol and the three-button protocol, and you can switch between them by holding the Start button. This project was tested extensively with the 8BitDo wireless Genesis-compatible controller. The microcontroller code is open source, so you can customize it with your own features. Note the special instruction to invert the 2nd and 3rd button signals to comply with the C64 version of the three-button protocol.

mouSTer. I would put the mouSTer multi-function USB 9-pin adapter at the top of my list for lots of reasons, except they’re sold out everywhere, and not available as a DIY board either. This clever versatile device is the best way to connect a modern USB mouse to the MEGA65 or other Commodores, and it also adapts USB gamepads and joysticks with support for the three-button protocol, as well as crystalct’s 5plusbuttonsJoystick protocol. It’s highly configurable: to upload new configuration, put a configuration file on a USB stick and shove the stick into the adapter. I love it, but yeah, it’s currently unavailable.

Unijoysticle 2. This bare board project connects to both joystick ports simultaneously, and pairs with any modern Bluetooth game controller. The C64 model supports the three-button protocol and the 5plusbuttonsJoystick protocol. Normally for sale on Tindie, this one is also out of stock, though designs are available under an open hardware license so you can make your own.

SNES controller adapters. snes2c64 and PadSwitcher64 are two projects with interesting takes on multi-button support. snes2c64 adapts the six-button SNES controller to a three-button C64 controller, using a programmable Arduino Nano for custom button mapping and auto-fire options. PadSwitcher64 connects to both 9-pin joystick ports to support all six SNES buttons with a proprietary passive protocol.

I’m most excited about the possibility of the three-button protocol for MEGA65 games. It’s relatively easy to find pre-assembled controllers, easy to implement in software and modified hardware, compatible with both R3 and R6 mainboards, and is the closest thing we have to an implemented standard for multi-button Commodore-compatible game controllers.

Give joytest65 a try and let me know how it works for your game controllers.

Happy gaming!

— Dan

Greetings from Chicagoland. Dan’s MEGA65 Digest for September 2024.

It’s a busy month! I just got back from the Vintage Computer Festival Midwest (VCFMW), the large-and-getting-larger-every-year vintage computer show. This was my first visit at this particular show, and it was great fun. I bring back a few photos, a few stories, and too much stuff from the free table.

But first, the news.

The MEGA65 mainboard, now available separately

Trenz Electronic is making steady progress on shipping all of the pending MEGA65 preorders, on schedule to get everyone taken care of by the end of the calendar year. A new pre-order for a MEGA65 placed today should have a lead time of only a few months. If you placed a pre-order and have received an email with an invoice, be sure to submit payment promptly. Invoiced but unpaid orders expire within a few weeks, to allocate inventory to others waiting on a pre-order. (Thankfully, you can just re-make your expired order, and you’ll receive it fairly soon.)

With this milestone comes some exciting news! Trenz Electronic is now accepting preorders for MEGA65 mainboards without the enclosure, keyboard, or floppy drive. This is great for electronics projects, custom enclosures, or just keeping a spare. You can make your own keyboard with some effort, and the floppy drive is a standard IDE drive and cable. The standalone mainboards are expected to ship in mid-2025.

Many owners of the 2022 edition of the MEGA65 (mainboard revision R3A) asked for the ability to replace the mainboard with the latest hardware revision (R6), and it’s great that Trenz is providing this option. This is just my opinion, but if you simply want a MEGA65 with the revised hardware, you might get a better result buying a complete new computer, and selling your 2022 edition on the secondary market. The mainboard is more than half the cost of the computer, and unless you want to keep the spare R3 board, you’re unlikely to recoup that cost after an upgrade. Of course, there are no guarantees on the secondary market, but it’s worth giving it a thought. Personally, I own two MEGA65s and a spare board, a Nexys dev board—and dozens of other computers. But you might not want to follow my example.

Speaking of owning lots of computers, Trenz has lifted the one-per-person limitation on MEGA65 pre-orders. If you want to outfit a classroom, hand out MEGA65s at parties, or just make a cool fort out of the boxes, now is your chance!

Thanks as always to everyone at Trenz Electronic for their partnership on the MEGA65 project.

Filehost new message notification

Filehost, our community file and information sharing board, has a new feature! You can now receive private notifications from the system, and send and receive private messages with other users. If you have a pending notification or incoming message, a red dot will appear on the user icon in the upper right corner.

To receive incoming notifications and messages, you must enable them: go to User menu > User Settings, check “Allow to receive messages from users” and “Inform me about comments on my entries,” then click Submit.

Filehost message settings

To access your messages: User menu > Messages.

To start a new private conversation with another user: click the plus sign next to Subjects, select the user, enter a subject, then enter the first message. Only users who have enabled incoming messages appear in the list of users.

Starting a new conversation

To add to an existing conversation: select the subject from the list, then scroll to the bottom of the conversation and enter the next message.

Adding to an existing conversation

Huge thanks to Tayger for this new feature, and all of his work on this essential community resource!

Boris has been working on extended documentation for the C64 core. The docs are now “feature complete,” with coverage of every feature and common task, including how to install JiffyDOS or use the built-in RAM expansion unit (REU). Be sure to send Boris your feedback and thanks, via Discord or email. Thank you, Boris!

Pelota, a single-player paddle game, by SirLazarus

A few recent Filehost uploads for you to try:

I just flew back from Vintage Computer Festival Midwest and boy are my arms tired. Literally. I took my MEGA65, printed table displays, a bunch of backup equipment, and bundles of 45GS02 mousepads to give away. I use this weatherproof hard case when I travel with my MEGA65, and I always carry it onto the plane and put it in the overhead bin. For this trip, the less delicate stuff went into a large checked bag. Who knew 100 mousepads would be so heavy! Thankfully, everything made it there and back safely.

The event took place at the Renaissance Schaumburg Convention Center Hotel, in Schaumburg, Illinois, in the Chicagoland area. The show consumed an entire expo floor and a separate presentation space for talks. This venue is also a nice hotel, and many exhibitors and visitors stayed here or in a nearby Embassy Suites. I didn’t take enough photos to do justice to the scale of this show, but hopefully you can get a sense of it.

I prepared a bunch of table tchotchkes, more than I actually needed, including a colorful banner, an informational standee, a “demo” booklet that someone could use to launch and browse software on the SD card, and various boxed software and accessories. I didn’t have a good way to hang the banner, so it ended up being more of a tablecloth, but it still added some color. I also made business cards with a full-color photo on one side and links to resources on the other. And a custom t-shirt to wear, because why not.

My table included my MEGA65, Jim Happel’s MEGA65, and two original Commodore 65 prototypes owned by Jim Brain. After having been on the MEGA65 project for two years, it was a real thrill to be able to see a C65 prototype and the MEGA65 side by side. It was also the best conversation starter: most passersby knew the C64 and never heard of the C65, so I could just point to the C65 first, then tell the rest of the story. Several people knew of the C65 and were excited to see it in person, taking selfies with the computer. I took a bunch of photos myself for future reference.

I tried to spend some time with Jim Brain’s copies of the demo disks, both on the C65 and on the MEGA65. It was a sobering reminder of how the C65 prototypes were not ready to be software platforms that the demo disks were hard-coded to specific versions of the ROM. Disks were generally not working on the C65. I could list directories but not load files. I got the IFF slideshow disk to work on the MEGA65—and of course I forgot about the topless woman until it showed up right as some young kids were walking up to the table.

One especially fun find was a message that Fred Bowen posted to the comp.sys.cbm Usenet group on September 17, 1993, subject line, “What’s a C-65???” Fred’s message puts the date of the liquidation sale around July 1993, and claims the prototypes numbered around 50. (According to Brian Bagnall’s Commodore: The Final Years, “By 1991, Commodore had at least 205 pilot production C65 machines. ‘We had a room full of them at one point,’ says [chip designer Bill] Gardei. ‘If you counted all the variants, 205 would not be an unreasonable guess.’”) In the message that follows, “Grapevine” refers to The Grapevine Group Inc. of Suffern, New York, one of two companies known to have acquired and re-sold the prototypes.

From: [email protected] (Fred Bowen)

Apparently Grapevine picked up some C65’s during Commodore’s liquidation of its warehouse/storage areas a couple of months ago.

What is a C65? A product that almost made it out the door. What you’re seeing are “alpha” pilot-production units. There were only something like 50 units made, and a dozen or more of these were distributed around engineering, system developers, etc. Obviously, they were never meant to be sold to the public, but…

CPU CSG65CE02, running at 3.54MHz

I guess that’s enough for now. But be warned- these boards are very out of date-the ROMs, PLA’s, etc. are pre-pre-preALPHA, there are absolutely NO spare parts (so if it breaks, that’s it!), all systems are PAL (but they display okay on regular 1084-type monitors in analog mode). Oh, and there aren’t any manuals. I’m surprised that Grapevine can sell them as “new” equipment. Buyer beware, and all that.

All things considered, not a bad machine, though. I still use mine :-)

At some point during the conference, some guy I’d never met showed up at the table and started opening the C65 case. I politely but firmly discouraged him from touching it without Jim Brain’s permission. The guy smiled and introduced himself as Jim Brain. 😅 We were having some difficulty with non-functioning keys on one of the C65s, and Jim noticed a small break in the keyboard ribbon cable that will need repair. Thankfully, and amazingly, Jim has two C65s, so we temporarily swapped the keyboards to form a fully functioning unit. Jim was careful to keep track of the fact that we swapped the keyboards, so they could be reunited with their original cases later.

The C65 prototype is held together with one screw in the front-right of the case near the floppy drive. The rest of the case is all plastic tabs, to make it easy to open and repair. I got to see and photograph the internals of both machines. Developer unit #23 contained the revision 2A mainboard, and a memory expansion module.

As impressive as the C65 is as a historical artifact, I’m relieved to realize that I don’t want to own one. Not that that was ever an option, with working units selling on eBay for $30,000. A recent auction for a broken one ended north of $12,000. The prototype plastic is weird, the keyboards are mushy compared to a good condition production C128, and the working ones barely work and are difficult to maintain. I’m grateful for collectors like Jim for keeping them alive as long as possible and sharing them with the world. And I’m grateful for the MEGA65 for not only letting me access a piece of this history in my own home, but for being a satisfying instrument of recreational computing in its own right.

Quite a few people saw the READY. prompt and wanted to type their own GOTO 10 program. Several young kids took the time to write a longer program, though they did it all from memory and didn’t bother exploring the manual. I ended up standing in front of the table and doing guided demos for most of the time. First Shot, Maniac Mansion, and Unicone attracted attention. Nobody bothered with the “demo” booklet, even with encouragement. I’m still glad I made the demo book: the full-color screenshots made it something you could flip through in seconds, and get a glimpse without having to wait for software to load.

I had stacks of the mousepads on the table. At first I was concerned that if I gave away the mousepads for free that they would disappear quickly, and wouldn’t provide much promotional value, so I had intended to maybe sell them at cost, and even made a little for-sale sign for it. I figured out within the first few hours that this wasn’t going to be a problem. I took down my for-sale sign and just arbitrarily handed mousepads to people that seemed even remotely interested in programming. At the end of the last day, I ran around the floor looking for coders I admired by reputation, and used mousepad gifts as excuses to say hi.

I had many good conversations with many people with a wide variety of interests and backgrounds, and I handed out many business cards. Greetz to all the new newsletter subscribers!

Many of the Commodore exhibits were colocated together in a common section. There ended up being so much diversity in the exhibits that you almost couldn’t tell they were related by platform. I was delighted that my table was next to the brilliant CityXen, who were showing off “Whackadoodle,” their C64-powered whack-a-mole game with giant colorful light-up arcade controller, along with a miniature version with custom handheld controllers.

June of the excellent Nybbles & Bytes was also in my area, demoing and distributing her unique C128 game, Nybbles: Legend of the Drunken Snake. When you first start playing, Nybbles looks like a traditional snake game, until just moments later you eat something unusual and things get utterly wild. The game uses two displays, and manipulates both the VIC-II and the VDC in ways I have never seen before. I waited to the end of the show to buy one to give others a chance, and I did indeed end up with one of the last copies to be distributed on floppy disk. Be sure to subscribe to the Nybbles & Bytes YouTube channel for future updates and technical details about the game.

Right around the corner, I met Craig of BitBinders, maker of 1581 clone floppy disk drives. I was especially impressed by his unique dual drive units, available in both vertically and horizontally arranged variants. I bought one of the horizontal units immediately. Craig already knew about the MEGA65, and we discussed the un-produced Commodore 1565 external drive, and how a modern clone would make a great MEGA65 accessory (along with the expansion board that provides the 1565 mini-DIN connector).

There isn’t enough space to show all the photos of cool and unusual computers I saw throughout the show, but I had such a strong reaction to this one I have to include it. I’ve wanted a Heathkit Hero 1 robot kit all of my life, having only known it through advertisements in magazines. This is the first time I’ve ever seen a Hero in person. The Hero Jr., on its 40th anniversary, was sharing a table with two Androbot Topo robots.

VCFMW is as much a swap meet as a share-out, and about half of the show floor was for sale. Many exhibitors had new and vintage items for sale, and VCFMW also held an auction of unusual items donated by exhibitors to help fund the event. What really gives the convention a pervasive electric air is the ominous entity known as the Free Table. People leave stuff to give away, and other people take stuff they like, a waxing and waning of trash and treasure throughout the convention. The table is largely unsupervised, which gives the added thrill of worrying that something that isn’t free might get taken. (This has happened.) The table this year was well labeled, with a useful partition between the free table and the next table over, so it was pretty chill.

I knew I was flying home, and I’m kind of at my limit for hardware anyway, so pretty much nothing on the free table interested me. I saw some ’90s-era Microsoft software in original boxes pass across the table. My big finds were all books, where at least one person was shedding a nerd’s bonanza of famous titles on computer science and programming. I grabbed what I could carry, and left behind some of my favorite books just because I know I already owned them. I was glad to see the good ones eventually found new owners.

Of course, with the bundles of mousepads, booth decor, and equipment, my luggage was already quite full and quite heavy. The books pushed my checked bag over the weight limit, and ended up costing me a $100 heavy bag fee. So not exactly free. Still a decent haul.

I owe huge thanks to Jim Happel (jim_64 on Discord) for making my VCFMW trip possible. Jim encouraged me to make the trek in the first place, and provided logistical, technical, and moral support throughout the experience. Jim also introduced me to many excellent people in the community whom I’ve known only by reputation online and I now consider friends. This was such a good time, I’m eager to visit the other annual shows around the country as time and budget allows, with my MEGA65 in its carrying case.

Thanks to everyone for your kind words and feedback on EasyAsm v0.1. I’ve only received a couple of bug reports—which just means you’re not trying hard enough to break it! I hope to start a revision as soon as I’m through this very busy month. I’m working on the draft of this year’s community survey, I’m dropping off a kid at college, and I still have the Portland Retro Gaming Expo in a couple of weeks.

Special thanks to all of my supporters, who are making my promotional tours and other projects possible. If you like what I’m doing, please consider becoming a supporter. Visit: ko-fi.com/dddaaannn

Cheers!

— Dan