Super Extended Attribute Mode. Dan’s MEGA65 Digest for September 2025.

I just got back from the Vintage Computer Festival Midwest 2025 in Schaumburg, Illinois, USA. I ran another two-day MEGA65 exhibit, this time in collaboration with YouTuber retroCombs. I also gave another talk, which was recorded and will be uploaded soon. It was great to meet up with friends old and new, and talk to many people interested in the MEGA65.

I’d make this Digest issue another trip review, but I have tarried too long on the next article in our character graphics series, and I shall tarry no longer! We’ll save the VCF photos for next month.

That said, we have some major project announcements this month. It’s a jam-packed Digest, so let’s get started!

Who Remembers the Commodore 65?

The talk I gave at Vintage Computer Festival West 2025 in Mountain View, California, Who Remembers the Commodore 65?, is now up on YouTube. I had a good time with this, and hope to explore this thesis in more detail someday. I hope you like it!

Mega-IP, by xlar54

xlar54 has released an initial version of Mega-IP, a TCP/IP networking stack for the MEGA65 intended for use from BASIC 65 programs. This release includes a simple telnet BBS client using the library. Mega-IP even supports incoming connections, for potentially hosting a BBS or other services from a MEGA65. See the Github repo for instructions and source code.

Amazing work and thoughtfully designed. Looking forward to what else comes from this!

Super Mega Assembler, by 0x30507DE

Bobby Tables (aka 0x30507DE) has released the first edition of Super Mega Assembler, a fork of Mega Assembler by grubi, using an all-new assembler engine implemented in machine code for speed. SMA is “self-hosting,” a milestone for any assembler or compiler written in its own language that says it is capable of building its own code. This on-device assembly language programming environment includes the original text editor.

Visit the #super-mega-assembler channel in the Discord to ask questions, or to read Bobby’s developer notes.

MegaPET, a Commodore PET core for the MEGA65

Rhialto’s Commodore PET core MegaPET is now officially released! The core supports every known version of the PET, and comes packed with features. Check out the documentation for details.

It’s been a real pleasure watching Rhialto’s steady updates of this project on the Discord. Congrats on the launch!

King’s Quest I, running on the MEGA65

King’s Quest, the 1984 classic graphic adventure game by Roberta Williams and published by Sierra On-Line, runs on a game engine known as Adventure Game Interpreter (AGI). AwesomeDolphin has developed Mega65-AGI, a MEGA65 version of the engine. You can now play the first game in the King’s Quest series on your MEGA65!

Similar to kibo’s MEGASPUTM, which plays Maniac Mansion by LucasArts, Mega65-AGI requires that you obtain the original King’s Quest data files to play the game. You can purchase the original game from GOG.com, and use the included Python script to merge the resource files into a playable D81 disk image.

Congrats to AwesomeDolphin on this major accomplishment!

More that’s new on Filehost:

Speaking of MEGASPUTM, there’s a new version that can play the Spanish language version of Maniac Mansion with the appropriate game data files.

Even more arcade cores from muse! Check ’em out: Pitfall 2, Wonder Boy in Monster Land, and Choplifter. (Yes, there were arcade cabinet versions of these games!)

Alpha Maze, by Drex. A 3D maze generator with nice color gradients.

Slidepuzzle 65, by BOBELE, the classic sliding tile puzzle.

Heli-Demo, by SirGeldi, a short demo of a helicopter flying over smooth scrolling text. Use a joystick in port 2 to move the helicopter, and press the button to fire, Choplifter-style!

Haiku - The Duel, by mk9. Select from a library of lines to construct a haiku, and try to outscore your computer opponent with the best poem.

Filehost watchers have noticed that we have uploaded a new version of the MEGA65 platform. This is not a new release that you need to care about: the MEGA65 team is making a routine update to the mainboard to adjust for parts availability, and this inevitably requires small changes to the core. Neither the mainboard nor the release package have new features or bug fixes, and you don’t need to upgrade. We just do a new release when any supported board needs a change.

We are hoping to do a new major platform release sometime soon. Watch the usual spaces for updates.

Back in July, we played with mixing red, green, and blue light to make new colors in the system palette. We saw that we could use 16 possible amounts of each component, from none (0) to most (15), for a total of 16 x 16 x 16 = 4,096 possible colors.

Here are all of the colors we can make with 16 levels of green, and none of the red or blue:

SA and CA are the starting addresses for screen and color memory, respectively. The FOR loop populates the first 16 palette entries with the 16 possible green colors, and draws rectangles in the first 16 character positions, one for each color. We’re using BASIC 10’s PALETTE command, which accepts the values 0 to 15 for each of the red, green, and blue amounts. PALETTE RESTORE brings back the default system palette before exiting.

The MEGA65 improves upon the Commodore 65’s 4,096 colors by allowing you to add fractional amounts of each color component. To each of these possible greens, you could add just a smidge more green to get a new shade, up to 16 possible smidgens of green, for a total of 256 possible green values in roughly the same range.

There’s a lot going on in this example, but take a moment to notice that this displays 16 intermediate shades of green above each of the major 16 green values. In line 40, the C variable is the major shade as before, and the S is the smidgen of green that we’re adding. The brightest green in this example is just a bit brighter than the brightest green in the previous example, because we’ve added 15 smidgens.

We can’t use the BASIC 10 PALETTE command here, because it only supports the “major” values 0 to 15. Instead, this example POKEs directly to palette memory. The greens of the palette entries are at addresses $D200-$D2FF. Each value is an 8-bit byte: 4 bits for the major value, and 4 bits for the minor value.

The MEGA65 has to do something clever to stay backwards compatible with the C65, which only supports the major value POKEd to the palette as the numbers 0 to 15. The MEGA65 stores the fractional (minor) color value in the upper bits of the byte. For example, if you want a palette entry to be 7 smidgens above the 3rd major green, you would store the 7 in the upper four bits (the upper “nybble”) and the 3 in the lower four bits:

This explains the unusual (S*16)+C in line 51: (S*16) pushes the smidgen value four binary places to the left, and +C adds the major value to the lower four binary places. Doing this for every possible major value (FOR C=0 TO 15) and every possible minor value (FOR S=0 TO 15) gets us every possible green.

Another way to think of this is, there are 256 possible green values, stored as a byte value 0 to 255, with the two nybbles swapped. The green of magnitude $37 (= 55) is stored in palette memory as the value $73 (= 115).

There are 4 fractional bits available for green and blue, and 3 fractional bits available for red. The “least significant” red bit, in bit position 4 after the nybble swap, is reserved for a different purpose. With 23 bits to describe a color, that’s 2^23 or 8,388,608 possible colors, for each palette entry.

The Commodore 65 was intended to have a feature where its video output could be combined with another video signal, using an analog video synchronization technique called genlock. Back in the day, this technique was used to generate titles or graphics that appeared over a video camera recording or live broadcast.

Imagine using a Commodore 65 to generate the text that appears at the bottom of the screen of the nightly news. The C65 would produce a full screen image with the text at the bottom and the rest of the screen painted in a palette entry with this “transparency” bit set. When merged with the video camera signal, the news anchors would appear in the transparent portion.

We actually do have a future use for the transparency bit on the MEGA65, specifically for the MEGAphone project. In general, for the most future-proofed results, keep bit 4 of red palette values written to $D100-$D1FF clear.

In Character Study, we said that each character can be assigned a five-bit value that identifies the color of the character from the first 32 entries of the palette. But if characters can only use up to 32 possible colors, how did the example above display 256 different shades of green?

By using a new character graphics mode, of course! The magic is on line 35, and the original text mode is restored on line 95. Let’s take a closer look.

In Taste the Rainbow we introduced Low-res Multicolor Character Mode, or MCM. In this mode, characters can be either in high resolution (8 pixels across) with a single foreground color, or in low resolution (4 double-wide pixels across) with a choice of a character-specific foreground color or two screen-wide alternate colors for each pixel. MCM is enabled by setting bit 4 of register $D016.

For the character-specific foreground color, Low-res Multicolor Mode ignores color bits 4 through 7, and character attributes are disabled. In this new Full-palette Low-res Multicolor Mode, all eight color bits identify the foreground palette entry, from 0 to 255. To enable Full-palette Low-res Multicolor Mode, set bit 6 of register $D063 (FCOLMCM), in addition to bit 4 of register $D016.

One oddity of this mode is that it still behaves like MCM: if color bit 3 is set, the character image is rendered in bit-pair low resolution. This means that half of the palette entries render in low-res mode, and the other half in hi-res mode. In the greens example, we used the block glyph at screen code 160, which looks the same in both modes. To see the difference color bit 3 makes, change line 60 to replace the 160 screen code with, say, 65. Half of the shapes look different.

I can’t think of a reason why we couldn’t also have a full-palette non-MCM mode, using just the FCOLMCM register bit 6 of $D063, replacing attribute bits for color bits without the MCM feature. I filed this as a feature request. (I could be forgetting a detail that prevents this from being a good idea. It’s difficult to keep track of all of the video mode combinations!)

All of the character graphics modes we’ve seen so far have given us new ways to draw pictures, but they have insisted that we trade away features such as resolution or available characters in exchange for more colors. Tradeoffs are necessary because all of these modes use the same amount of memory for a given screen size: one byte of screen memory and one byte of color memory for each character. If we want to go further—and further we must go!—we need a screen mode that lets us exchange memory for features.

Super Extended Attribute Mode (or “SEAM”) is one of the VIC-IV’s big upgrades to Commodore character graphics. Enabling it doubles the amount of memory used for each character: 16 bits (or two bytes) of screen memory and 16 bits of color memory. This both expands the possible size of the character set and makes room for additional rendering features on a character-by-character basis (the “super-extended” attributes).

We’ll stay in BASIC for the rest of this Digest just to make it easy to experiment. Similar to other ways we’ve tried messing with the VIC-IV registers, the KERNAL screen editor doesn’t know anything about SEAM, so you can’t use its cursor-like printing features in these modes. The only way to take advantage of SEAM is to write directly to screen and color memory. In practice, these modes are easier to use from machine language, where we can do high-speed manipulation of memory.

Let’s set up a program that enables SEAM, waits for a keypress, then disables SEAM and returns to the READY prompt. We can put our experiments in the middle.

Step 1: Set the CHR16 register, bit 0 of register D054. The VIC-IV reads two consecutive bytes per character, of both screen memory and color memory.

Step 2: Set the line step according to the desired horizontal resolution. The LINESTEP register at D058-D059 is the number of bytes that make up each line of characters. In normal 80-column text mode, this value is 80, one byte per character. SEAM doubles the number of bytes per character, so if we’re staying in 80-column mode, the new value is 160. This may feel superfluous, but the LINESTEP register will come back in a big way in a later Digest!

Recall that 80-column text mode is controlled by the H640 register, D031 bit 7. You could switch to 40-column mode by clearing this bit, then set LINESTEP to 80, for forty columns of 16-bit screen and color codes.

Step 3: Set SCRNPTR D060-D063 to a memory location where we can put 80x25x2 bytes of screen memory. Let’s use $4.0000 for now.

Recall that the WPEEK() function takes an address, and returns the 16-bit value stored in two bytes, in little endian format. Similarly, the WPOKE command takes an address and a 16-bit value, then writes the value as two bytes. Line 30 uses two WPEEK() calls to read the 32-bit SCRNPTR address into two variables. Line 40 sets SCRNPTR to address $0004.0000, using two WPOKE calls. The original SCRNPTR setting is restored in line 970, as the program is exiting.

If you run this program now (and you should!), you’ll see whatever is sitting in screen and color memory, interpreted as two bytes per character. Press a key to restore normal text mode and the original SCRNPTR value.

Step 4: Clear the screen. We’ll explain how this works in a moment, but for now, add this to the program to start from a clean slate.

This FOR loop visits every character position in memory: 80 columns, 25 rows, 2 bytes per character.

Line 60 writes a space character (screen code 32) to each character position in screen memory, which we relocated to $4.0000. It uses WPOKE to treat “32” as two bytes, with the least significant byte (32) first and the most significant byte (0) second.

Line 70 and 80 write two bytes to color memory: the first byte is a 0, and the second byte is the color white (1) with no character attributes.

On exit, line 960 revises color memory for our normal text display, with all white text. We’re reusing the same color memory for both our normal display and the CHR16 display, but they use different data formats, so we need to put things back in order before switching off CHR16. Another option would be to relocate color memory the way we did screen memory to preserve the colors of the original normal-text display.

In CHR16 mode, each character gets two bytes of screen memory. This includes 13 bits for the screen code, and 3 bits for another feature that we’ll ignore for now. The screen code bits are arranged with the 8 least significant bits in the first byte, and the 5 most significant bits at the bottom of the second byte. As long as you’re not using the unmentioned feature, you can treat this as a 13-bit number stored in little endian format, and leave the last three bits set to zero.

In normal text mode, screen codes are 8 bits (one byte) wide, for a character set of 256 possible characters. In CHR16 mode, you can write any byte value from 0 to 255 to the first byte, with zero as the second byte, to see these characters as usual. Here’s our familiar PETSCII uppercase set, as four rows of 64 characters:

Notice that we can’t use the BASIC T@& special array as we did last month, because BASIC knows nothing about custom screen memory locations or CHR16 mode. Instead, we calculate the address and screen code for each location. We used a similar technique to POKE the PETSCII screen codes in an earlier Digest. Here, we use WPOKE and increment two bytes at a time to write the full CHR16 screen memory value.

8-bit screen codes can describe 256 possible characters. SEAM expands this to 13 bits, for a whopping 8,192 characters in a single character set! The easiest way to see this in action is to update the program to display more rows:

Check it out: lowercase letters and PETSCII graphics characters on the same screen! As usual, the VIC uses the character set memory pointed to by CHARPTR D068-D06A, and locates the image data for a given character by counting up by 8 bytes per character, up to the given screen code. With CHARPTR pointing at the PETSCII font, screen codes 0 to 255 refer to the PETSCII uppercase + graphic characters, and codes 256 to 511 refer to PETSCII lowercase + uppercase, because both sets are next to each other in memory.

But that’s not all! There are plenty more characters available beyond 511. For now, the memory the VIC sees is filled with non-character data, so it looks like random snow. A game or application can install all manner of game graphics, alternate typefaces, or frames of animation in this memory. Thanks to CHR16 mode, they can all live happily on the same screen.

That is, if you’re willing to spend the memory. To use all 8,192 possible characters in a single character set, you need to dedicate 8,192 x 8 = 65,536 bytes—the entire available RAM of a Commodore 64—to character set data. If you don’t need that much, just don’t use all of the screen codes.

Similar to screen memory, CHR16 mode doubles the amount of color memory used to describe each character. Only the second of the two bytes is used for actual color and attribute data, and this byte alone provides no additional color or character attribute features. This may be disappointing to hear at first, but the remaining eight bits are used for graphics features so powerful that we’ll have to discuss them in a later Digest.

As with normal text mode, the second byte of character memory can select from the first 32 palette entries for a character’s foreground color, using bits 0, 1, 2, 3, and 6. And as with normal text mode, bit 4 is a blink effect, bit 5 is a reverse effect, and bit 7 gives the character an underline.

Here’s a quick way to see all of the characters displayed in 32 colors with all of the attribute combinations. It’s a bit garish, but it gets the point across.

Note that this cannot be combined with the Full-palette Low-res Multicolor Mode we used for the 256 greens earlier. There’s another way to get more color in SEAM. We’ll take a good look at that in the next Digest.

With as many as 8,192 screen codes at our disposal, we can have all manner of graphics tiles on the screen in any combination. Imagine Crossroads with hundreds of enemy types.

There’s another thing we can do with such a large character set. On a screen 80 characters across and 25 characters down, there are 2,000 characters visible at any time. With CHR16 mode, we can put a different character in every screen location.

Our test program was displaying characters 64 per row just to keep the PETSCII character set tidy. To completely fill the screen with unique characters requires only a modest change to the loop:

What’s the big deal? With the screen filled with the first 2,000 characters of the character set, the character set is the screen. We can draw individual pixels onto the display by updating the character set!

One more flashback to the previous Digest: The character set describes what each character looks like as a monochrome set of pixels. Each character is eight pixels across and eight pixels down, represented as eight bytes from top to bottom, most significant bit on the left. You can store the character set anywhere in the first 384 KB of memory. The CHARPTR register D068-D06A stores the starting address.

For a character set of 2,000 characters and eight bytes per character, we need 16,000 bytes, or 15 KB. We’ve put 2,000 x 2 = 4,000 bytes of screen memory for our tapestry at address $4.0000, so we can put the character set immediately after it at address $4.0FA0.

Here’s one way to clear the character set so every character is an empty space:

Now for the tricky bit. This 640 x 200 pixel screen is organized into little 8 x 8 pixel stacks. To light up a specific pixel, we need to figure out which bit in which byte represents the pixel, then update that byte. Feel free to try this little math problem on your own.

Here’s what I came up with:

If this looks confusing, notice that Y >> 3 is the same as INT(Y / 8), that is, divide Y by 8 and drop the remainder. Y AND 7 is the same as the remainder that was dropped when dividing Y by 8. With 8 as the divisor, it’s faster to do this with bitwise math, and is how you would do it in machine language. 7-(X AND 7) is the bit number of the byte to change, with 7 being the leftmost bit.

Now that we can draw a dot at a given set of coordinates, we can do something fun, like this:

We’ve filled the screen with the entire character set, and are drawing pixels directly onto the character set, for a bitmap graphics display. Pretty neat!

Thanks for sticking with me through this series on character graphics. Each new concept is built on the last, and we still have at least two more major topics to cover.

This marks the 40th issue and the three year anniversary of Dan’s MEGA65 Digest. I’m grateful to everyone for their support throughout this project. I couldn’t do this without you.

If you’re finding this newsletter valuable, and I hope you are, consider becoming a supporter of the Digest. Visit: ko-fi.com/dddaaannn

Don’t touch that dial! More to come!

— Dan

So Many Things. Dan’s MEGA65 Digest for August 2025.

I haven’t been slacking, I swear! In fact, so much MEGA65 stuff has been going on in the last couple of months that I haven’t had time to work on feature articles for the Digest. I’m excited to have had the opportunity to contribute to both the Commodore International and Compute!’s Gazette revival projects. And I was able to present a talk and run an exhibit at Vintage Computer Festival West at the Computer History Museum in Mountain View, California.

Meanwhile, multiple talented people have released MEGA65 games and videos in the last month, so many that I haven’t had a chance to play them all until now. Let’s catch up a bit! We’ll pick up our color graphics series next issue, fingers crossed.

We’ve all thought about it. What would you do if you could rescue the original Commodore name from getting mired in the portfolios of private equity firms? Would you found a company with the community’s best interests at heart? Would you help foster the creativity of hundreds, and bring the joys of recreational computing to thousands? Would you take the best modern retro computing has to offer, and make it more accessible to the world?

Perifractic of the YouTube series Retro Recipes has gone and done just that. After many months of intense effort, Commodore International is now live. Not only that, they’re taking pre-orders for the Commodore 64 Ultimate, a modern all-in-one C64 with a vintage feel and modern conveniences. (Kind of like another project I’m rather fond of.) They’ve also got some pretty neat logo merch.

The team is a real who’s-who of Commodore veterans and modern retro developers. I’m grateful to be listed as a partner, though my contributions are all volunteer in my off hours.

Peri is gradually releasing a series of teaser-heavy videos laying the groundwork for the project, with more to come. Check these out if you haven’t already:

Congratulations to Perifractic and the team on this initial launch, and best wishes for the company’s success!

COMPUTE!’s Gazette, the venerable home computing magazine from the ’80s and ’90s, is also being reborn. Edwin Nagle acquired the rights to the name, and has started a new magazine all about modern retro computing across multiple platforms, old and new. The new Gazette has published its first issue, including a feature article on the new Commodore. You can buy the single issue as either a print + digital bundle or digital-only, or you can start a subscription.

I’m thrilled to announce that Gazette includes a regular column about the MEGA65, by me! I am syndicating Dan’s MEGA65 Digest feature articles with the magazine, starting with the first issue. Going forward, the column will include existing and new material, edited for the Gazette audience. The MEGA65 will have a regular presence in the magazine, in more ways than one.

Congrats to Edwin, the team at COMPUTE! Publishing, and contributors for making this happen!

retroCombs has completed his video series on the MEGA65 User’s Guide, with a video all about chapter 7: transferring files.

The full series dedicates a video to each chapter of the User’s Guide, providing useful video demonstrations and commentary:

Don’t miss more retroCombs MEGA65 videos for even more fun!

The YouTube channel Level Up with Jeffrey covers vintage and modern retro home computer games, with entertaining playthroughs and discussion. In the last year, Jeffrey has taken a shine to the MEGA65, in particular running Commodore 64 games in the MEGA65’s “GO64” compatibility mode (not just the C64 core). It’s great to be reminded that GO64 mode is actually quite capable. I tend to steer people toward the C64 core just to avoid disappointment with the occasional compatibility issue, but GO64 mode has workflow advantages with the MEGA65 Freezer, and is just neat from a technical perspective.

All of Jeffrey’s back catalog is fun to watch. As a programmer, I especially enjoyed his recent diversion from form, Fixing C64 Frantic Freddie: For MEGA65, in which Jeffrey uses the MEGA65’s built-in programming tools to dig into the C64 classic’s machine code. This video is a follow-up to 8-Bit Show and Tell’s recent Frantic Freddie code dive using Super Snapshot on the C64. Both videos are gold for fans of the game, or of screenfuls of assembly language.

Can’t wait for me to get around to finishing my Digest series on advanced graphics? Other MEGA65 developers have been documenting their own journeys for your benefit.

Here’s a look ahead at common abbreviations used to describe VIC-IV graphics features:

RetroCogs, the author of the upcoming side-scrolling shooter First Shot, has published two new articles on VIC-IV graphics: Setting up FCM and NCM and Using RRB for Pixies. RetroCogs has previously published a few other blog articles, MEGA65 graphics tutorials in Github, and the beginnings of a MEGA65 game development framework called GameShell65.

ubik has published a BASIC65 full-color image demo, a demonstration of full-screen images rendered with Full-Color Mode character graphics. Also check out this nifty tutorial in C for the MEGA65, with a Python script for converting images from the PNG format for use with this code.

Gurce has been doing his own SEAM experiments, in Eleven/BASIC 65, including the beginnings of a graphics editor and experiments with pixies and bounding box collision detection. Gurce reports that these advanced graphics modes are little bit too CPU intensive for performing large animations in pure BASIC, but BASIC examples are useful to understand the ideas.

I still intended to document my own journey learning these features here in this Digest. I’m grateful to everyone who has published articles and sample code, so I can compare notes.

GRAVMAN, a MEGA65-themed gravity-lander game by Robhawk (RobH on Discord). RUN "GRAVMAN.PRG" to start. Joystick fire to thrust upward, left and right to thrust sideways. Collect MEGA65 pieces—and pages of this Digest!—and land safely on the green pad. Level editor included (RUN "LEVEL-EDITOR"), and don’t miss the well-commended BASIC source code.

Commando B65, by SirGeldi, a tribute game to Commando for the C64, using character graphics and a scrolling playfield. Music by Gurce. Use a joystick in port 2 to move, and move + fire to shoot in the direction of movement.

HAMURABI 65, by BOBELE. A MEGA65 version of a simple economic simulation, based on the game published in 101 BASIC COMPUTER GAMES by David Ahl of Digital Equipment Corporation in 1975.

Mitosis, by ubik. A strategy board game for two players, similar to Ataxx. Claim territory by adding your pieces to the board, and mutate your opponent’s neighboring pieces.

So many people are pushing their projects forward this summer (or winter as the case may be), and sharing updates with the community. Rhialto is making steady progress on the PET core (Discord link), including in-progress SuperPET extensions, still in “pre-release” status; download the latest. sy2002 has released an experimental update to the C64 core (Discord link) specifically for use with IDE64, a modern mass storage cartridge device. TwoBitRetro continues to revise the beta version of Pascal65. Boris is keeping the alternate cores documentation up to date. xlar54 continues work on an Internet-capable networking library (see #weeip on Discord). ctalkobt is working on an assembler with text editor (see #vim). Bobby Tables is working on an all-new fast assembler engine for Mega Assembler (see #super-mega-assembler). And of course Paul is still working on the MEGAphone and posting updates to his developer blog. And these are just projects I know about from Discord discussions.

You’re all crushing it! Keep up the good work!

I’ve been looking forward to the Vintage Computer Festival West all year, and it did not disappoint. This two-day event at the Computer History Museum in Mountain View, California, USA, received over 3,500 attendees. It featured two full days of talks, a large exhibition floor, and three rooms of consignment sales.

This year’s event celebrated the 40th anniversary of the Amiga with a special exhibit of early Amiga prototypes from 1984, multiple Amiga-related talks, and a special ticketed event recreating the famous Amiga launch event at Lincoln Center, including a bit of fun with stand-ins for Andy Warhol and Debbie Harry.

I had the honor of being the first speaker of the show. I was busy working on the talk all the way up to the last minute, including on breaks during the 14 hour drive down from Seattle. It went pretty well. I wish I had more time to fill out my thesis with research, but it was sufficient for a casual talk at a volunteer event. VCF West will upload talk videos at a later date, and I’ll be sure to mention it when they do.

I didn’t get to see much of the show otherwise, as I was also an exhibitor, and my booth had almost full-day attendance on both days. I was grateful to meet for the first time in person multiple people I already know from Discord communities, including MEGA65 owners. I also met more than one former Commodore employee, and more than one professional author of 1980’s computer books and magazine articles.

The highlight of the event for me was meeting Paul Lassa, one of the original developers of the Commodore 65. We talked for a long while about working for Commodore, the challenges of the C65 project, and the present and future of the MEGA65 project. I’m very pleased to know that Paul owns a MEGA65 and reads this newsletter. As such, I’ll try not to embarrass him further. 😅 I’m grateful that Paul sought out my exhibit and was generous with his time. Thank you Paul!

I was also delighted to briefly meet Kenneth Dyke, a graphics software engineer with a long career at Apple that also worked on the Amiga at Commodore. Kenneth also wrote the 6502 CPU Verilog implementation that the MEGA65 uses to power its Matrix Mode debugger. He was walking around the show wearing a backpack containing two Commodore 65 prototypes. I’m not sure why. We got them out and took some pictures.

I had brief moments to run around the floor and take some quick pictures. This is not a good representation of the show overall, but who doesn’t love pictures of old computers!

See magic-1.org, a website served by the Magic-1 homebrew computer.

“I love deadlines. I love the whooshing noise they make as they go by.” — Douglas Adams

What’s next? I still have a bunch of work to finish for Commodore, which will probably eat up my hobby time for August. Then I’m off to Schaumburg, Illinois, for VCF Midwest 2025, September 13 and 14, where I will be giving another talk and running another MEGA65 exhibit. They have two speaker tracks this year, and thanks to generous volunteers, both tracks will be recorded. My speaker slot for this one is Saturday at 10:30 am in the secondary venue.

I’m eager to get back to MEGA65 ROM and documentation work, not to mention the Digest. I’d love to write a game someday. Man, too much to do.

— Dan

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