After you’ve finished Ben Eater’s 6502 computer project, if not long before, as with me, you may be wondering about editor and assembler options for your 6502 coding work. Ben uses a basic Linux based editor and the VASM assembler throughout his project. If you are a regular Linux user you may be comfortable using these tools for all of your coding work. But there are other options available that you might want to consider as your project grows to include multiple source files.
Editors
As Ben showed, you don’t need a fancy editor to write your code, but opting for a more functional one can help you better manage a growing project. There are numerous editors available, just Google code editors. Atom, Sublime Text and Notepad++ are popular choices. Many editors have the capability to manage multi-file projects and to run your chosen assembler directly from the editor. Some editors allow third-party modifications to add features and capabilities. A popular option is assembly language highlighting making it easier to review your code.
I use Visual Studio Code. It’s available for Windows, Mac and Linux, has built-in source control and extension capability. I use it for all of my programming needs. I recently learned I can also use it for debugging (6502 debugging requires the use of an emulator and assembler support).
At the end of the day, selecting an editor will be a very personal decision. Try out several and see which ones meet your needs. Once you find one that you like you’ll likely use it for more than just your 6502 programming.
Assemblers
There are a wide range of assemblers targeting the 65C02 processor with varying capabilities and options. Perhaps you’ve already tried VASM while following along with Ben’s videos. Or perhaps, like me, this didn’t work for you and you went looking for an alternative.
I recommend that you first search for options that your favorite editor might support. Visual Studio Code, for example, lists a number of extensions that relate to the 6502 in some manner. Most of these editor options aren’t assemblers but provide support to the editor for an external assembler. If the two are well integrated, your work flow will be greatly enhanced.
Retro Assembler
Searching for 6502 extensions in Visual Studio Code introduced me to Retro Assembler, which targets a number of different processors in addition to the 6502. I like it’s clean, straightforward syntax. It’s Visual Studio Code extension provide language syntax highlighting and build and debugging support.
If you use Visual Studio Code, I highly recommend Retro Assembler, especially if you’re just starting out. It’s very accessible for the beginner, but also has some advanced features such as macros.
Retro Assembler however, doesn’t have a formal linker, so a multi-file project must either be linked externally or you can first assemble the individual files and then use Retro Assembler again to assemble a separate project that includes the previously assembled binary files in the proper location of the memory map. This process can be automated into a Visual Studio Code task to simplify the build process.
Retro Assembler has many features found in more powerful assemblers. Like me though, at some point you might be ready to move on to one of them, likely because your project has grown to a dozen or so files. It was at this point that I noticed an annoying bug in Retro Assembler.
Retro Assembler has an error in resolving the zero page address mode of some instructions if a zero page label is used before it is defined. This is much more likely to occur if your project has multiple files. It appears that on it’s second pass Retro Assembler corrects the instruction to use the zero page address mode (2 byte instruction vs 3 bytes) but doesn’t adjust the addresses of any labels that were defined after that point in the code.
It took me quite a bit of troubleshooting to find the problem. The Retro Assembler documentation does have a note about defining zero page labels before they’re used but only in reference to having faster code execution with zero page addressing. I think a warning is appropriate at the minimum.
Once my project grew enough to encounter this problem, I realized it was time to begin looking for something more powerful. I still recommend Retro Assembler for the beginner and especially if you use Visual Studio Code. Just be aware of its limitations and zero page bug.
cc65
If you have a bit of time to dig into the documentation, cc65 might be a good 6502 programming package to consider. It is an assembler, C compiler and linker, targeting many old 6502 systems.
I had previously looked at cc65 and liked its capabilities, but found it not particularly accessible to the new user, at least those just starting with the Ben Eater build (and especially when compared to Retro Assembler for a Windows user using VS Code). I wanted to be able to type something like
cl65 *.s
and have it spit out my ROM binary file without having to worry about target systems, libraries or configuration files. Obviously cc65 is geared toward a different user base.
After not finding anything else to my liking, I created a modified version of the cc65 assembler and linker to do what I wanted. By the end of that project, I came to fully understand how to properly configure and run cc65, but I still like my version better. Perhaps someday I’ll tackle adding in the C compiler with a library geared toward my build.
Woz Monitor – A Fun, Retro Place To Start
After you’ve explored your 6502 build a bit, as I did on mine, you’ll probably look for other things to do with it. Many hobbyists try coding a monitor program and a retro place to start is getting the Woz Monitor running on your system.
The Woz Monitor, or Wozmon as some call it, is the original monitor program for the Apple 1 computer, written by Steve Wozniak back in 1976. At this point in your build, it’s quite an accessible program to play with, being only 254 bytes in length. It’s not too hard to find the source listing for Wozmon. Jeff Tranter has a clean, commented version of the original code at his GitHub.
Wozmon, of course, was designed to run of the Apple 1 and will not run on your 6502 computer without modification. Learning what it does and modifying it to run on your build is the fun part. Wozniak used a number of tricks to fit his code into the Apple 1’s 256 byte ROM. You’re likely no longer constrained by the size of your ROM, but be careful in making changes. It’s easy to break Wozmon by changing the value in a register that seemingly isn’t being used anymore, only to find out that Wozniak relied on the register having that value elsewhere in his code. Today you would just reinitialize the register, but Wozniak didn’t have the spare bytes to do so.
Once you get Wozmon running, you’ll likely want to know how to use it. San Bergmans’ website has a straightforward discussion on the usage and inner workings of Wozmon. His site also has other interesting information on the Apple 1 as well, including a downloads page that includes a pdf of the original Apple 1 Operation Manual. It’s an interesting read, especially getting a glimpse at the apparent word-processing capabilities of the day.
Where To Next?
You might wonder what else you can do with this old processor. The answer is, a lot. True, you’re not going to get anything near the interactive experience of today’s computers but that doesn’t mean you can’t have a lot of fun programming your new 6502 computer.
I, like many hobbyists, have continued working on my monitor program, as I work up to my ultimate goal of building a handheld 6502 computer. There are plenty of examples online to draw inspiration from, including the original Apple II operating system. I still remember working with it decades ago. Other popular next steps that I intend working on are Basic, Microchess, Forth and maybe even an old style adventure game. The options are almost endless, just Google.
How about you? Where are you taking your 6502? Let me know in the comments.