Retro Assembler V2020.1 Released

February 20, 2020Retro Assembler.NET

The assembler project is now built exclusively for .NET Core 3.1 and it's a single portable package for Windows, macOS and Linux, running on X86, X64 and ARM architectures.

With this step, the code base and the release package are simplified. All you have to do is install .NET Core 3.1 once and you're good to go. You may also follow the guide How to Install .NET Core on Linux and macOS (and Windows) if necessary.

The .NET Framework 4.7 version is now discontinued. Microsoft basically deprecated the .NET Framework, with the next version they will merge everything into .NET 5.0. Hopefully at that point Windows Update will install it for everybody on Windows, but until then .NET Core needs to be installed manually to make Retro Assembler work.

For simplicity, the assembler's version number has been changed to the modern style Year.Release, kicking off with 2020.1

Thank you for your support!

See the documentation for details.

Download the latest version from the Retro Assembler page!

Retro Assembler V2.4.2 Released

October 19, 2019Retro Assembler

Small update.

See the documentation for details.

Download the latest version from the Retro Assembler page!

Using Retro Assembler with Visual Studio Code

June 6, 2019Retro AssemblerVS Code

Visual Studio Code is perhaps the best programming environment to use Retro Assembler with. I have a frequently updated Extension in the VS Code Marketplace that offers multiple themes, syntax highlighting and command execution integration. Here is a screenshot of the latest Blue theme, showing a code file used for highlighting testing.

This application is available on all major operating systems and can be downloaded from

Setting it up is easy. After you installed it, click on the Extensions icon on the left side, or choose View -> Extensions. Enter Retro Assembler into the search field and install the extension from the marketplace. Choose one of the offered color themes for the assembler. You can change this later in Preferences -> Color Theme

(The Preferences menu option will be referenced below, so I better clarify that it's under File in Windows and Linux, and under the application name Code on macOS.)

For best practices select the installed Retro Assembler Extension on the Extensions page and read the Details page. (In an ideal world this is where this guide would finish.)


Go into Preferences -> Settings and search for Retro Assembler. Or you can just open its section up directly under the Extensions tree branch. You'll find 3 editable fields.

Retroassembler: Path

You have to enter the full path to the Retro Assembler executable file that you already installed somewhere. On Windows use the "retroassembler.exe" file from the Windows directory, and on other systems you need to enter the command "dotnet ~/retroassembler/Portable/retroassembler.dll" substituting the actual directory path from your system. If you followed my .NET Core installation guide, you can use that command alias ra (or similar) that you created for this.

Retroassembler: Args

Optional command line arguments that will be passed in for the assembler when you compile the selected code file. Refer to the documentation.

Retroassembler: Mainfile

If you are working on a bigger assembly project with multiple files, perhaps even in a deeper directory structure, you can enter the full path to your main code file that should always be compiled, instead of the currently edited file.

This whole Settings is saved as a JSON file and can be edited directly by clicking on { } on the right side. Here are my settings, for inspiration, in case you also need to disable visible white spaces, use tabs, and enjoy a cleaner editor interface in general.

    "retroassembler.path": "C:\\RetroAssembler\\retroassembler.exe",
    "retroassembler.args": "-x",
    "retroassembler.mainfile": "",
    "workbench.colorTheme": "Retro Assembler Blue",
    "window.zoomLevel": 0,
    "editor.fontFamily": "'Lucida Console', Consolas, monospace",
    "editor.fontSize": 13,
    "editor.insertSpaces": false,
    "editor.detectIndentation": false,
    "editor.renderIndentGuides": false,
    "editor.multiCursorModifier": "ctrlCmd",
    "editor.minimap.enabled": false,
    "editor.renderWhitespace": "none",
    "editor.renderControlCharacters": false,
    "breadcrumbs.enabled": false

Keyboard Shortcuts

Go into Preferences -> Keyboard Shortcuts and search for retroassembler. You'll find 2 editable commands. Bind your desired keyboard shortcuts to them.

Retro Assembler: Build

This opens the Terminal and compiles the currently edited file, or the Mainfile if set in Settings.

Retro Assembler: Build & Start

This opens the Terminal and compiles the currently edited file, or the Mainfile if set in Settings. It also passes in the -L command line argument to the assembler, which can start the compiled binary file with an emulator. In the compiled source code file you need to have a line similar to this example:

.setting "LaunchCommand", "C:\\Emulator\\emulator.exe {0}"

I personally prefer to bind these to shortcuts Alt+1 and Alt+2, respectively.

File Naming Conventions

Visual Studio Code is a great editor but needs a little help with the file type detection. There wouldn't be much use to see 6502 instruction highlighting in a Z80 assembly code file, so you need to tag your files with the CPU type you use in them. You can do this by adding a secondary file extension between the file name and the .asm (or .s, .inc) extension, like this:

Get to work!

Now you're ready to code for some good old CPUs. Just edit and save your files as usual, then press the keyboard shortcut you set up for Build or Build & Start to compile your selected file. You will see in the terminal window slotted somewhere inside the IDE whether your code compiled correctly or it has some error you need to fix. You can Alt+Click the VS Code link of the error report to open the referenced file and jump to the problematic line of code.

How to Install .NET Core on Linux and macOS

Updated on February 28, 2020Retro Assembler.NETLinux

If you want to use Retro Assembler to code on Linux (even on a Raspberry Pi) or on macOS, you have to install .NET Core on your computer. Normally you'd just go to and follow the instructions, but if you need help, I'll try to provide some here.


Installing on Windows

Installing on macOS

Installing on Linux

Here are the commands you'll need to enter into the Terminal:

#Download the Ubuntu 19.10 related packages for the package manager.
wget -q -O packages-microsoft-prod.deb

#Install it for the package manager.
sudo dpkg -i packages-microsoft-prod.deb

#Install this utility.
sudo apt-get install apt-transport-https

#Update the package manager.
sudo apt-get update

#Install the .NET Core Runtime.
sudo apt-get install dotnet-runtime-3.1

Installing on Raspberry Pi and on other ARM based SBCs

Here are the commands you'll need to enter into the Terminal:

#Install some possibly missing packages that will be needed.
sudo apt-get install libunwind8 gettext curl wget

#Make the dotnet directory where the .NET Core Runtime will be installed.
sudo mkdir /usr/share/dotnet

#Extract the files from the downloaded file.
sudo tar -xvf dotnet.tar.gz -C /usr/share/dotnet/

#Set up a symbolic link to this directory so it will be found on path
#when you type in the command "dotnet".
sudo ln -s /usr/share/dotnet/dotnet /usr/local/bin

This works perfectly, the only caveat is that you'll need to perform this manual install with every updated .NET Core version you want to use.

Testing in the Terminal

Run this command to check whether the .NET Core Runtime has been installed successfully. It will list the currently installed version's details.

dotnet --info

Now you can run Retro Assembler with this command:

dotnet retroassembler.dll

Optional, but it is recommended to edit the command shell's startup file with a command alias to run Retro Assembler with ease, as if it was a Linux/Mac native command line application.

Open your user's home directory and edit the hidden file .bashrc on Linux, or .bash_profile on macOS. The latter usually doesn't exist and you have to create it. Then enter this line into the bash file with your chosen file path:

alias ra='dotnet ~/PATH/retroassembler.dll'

This will allow you to just enter the command ra and run the assembler from either the Terminal or from Visual Studio Code.

Retro Assembler V2.4.1 Released

May 31, 2019Retro Assembler

It's a small but useful update for those who use the Visual Studio Code Extension, which is recommended for the best coding experience.

The display format of errors and warnings got tweaked a little to display a clickable link that allows Visual Studio Code to open the referenced source code file at the problematic line number.

Unfortunately in such links Visual Studio Code doesn't correctly recognize paths with spaces in them (yet), but I chose the best option (quotes around the filename) that will likely be handled by it in the future.

I also added a new output file format called SBIN which is similar to the PRG format, but the file data length is also saved into the header, making it typically 4 bytes long.

The rest of the important changes are in the Extension which is now elevated to version number 1.1.0

See the documentation for details.

Download the latest version from the Retro Assembler page!

Retro Assembler V2.4 Released

April 4, 2019Retro Assembler

I had a couple of small bug fixes to do and in the same time I took the opportunity to update some directives, add new ones and work on the documentation a bit.

See the documentation for details.

Download the latest version from the Retro Assembler page!

Retro Assembler V2.3.1 Released

February 13, 2019Retro Assembler

This is just a smaller bug fix for Linux. I noticed that the Windows version doesn't run on Ubuntu Linux using Mono, mainly because of the Gnome Terminal's default TERM environment value. It's set as xterm-256color while Mono apparently needs it to be set as xterm, otherwise it fails when the Console is accessed. This can be remedied from the user's login script like in .bashrc but I fixed it from software for the application's thread.

Then there was another bug that happens only with the x86-64 version of Mono, it always worked fine on ARM. That issue has been fixed too.

Either way, I still recommend using the .Net Core version on Linux and macOS.

See the documentation for details.

Download the latest version from the Retro Assembler page!

Retro Assembler V2.3 Released

November 13, 2018Retro Assembler

As it happens, while I was working on an assembly project, I ran into some shortcomings that I tried to fix in this new release.

There was no way to just allocate bytes in memory, without actually writing data into the virtual memory. This normally isn't a problem in Commodore 64 projects, but in Gameboy projects the code is in ROM and the RAM is separated from it. Even though the ROM builder would ignore those bytes, words and arrays that you'd put between $c000-$dfff, it's not too elegant to write the code that way. Now it's possible to just allocate bytes these ways:

      RAM          .org $c000
      ButtonState  .byte ?
      Buffer       .storage $20

Other changes, some were made in version 2.2.1

See the documentation for details.

Download the latest version from the Retro Assembler page!

Retro Assembler V2.2 Released

October 1, 2018Retro Assembler

The new version is out with a quite a lot of goodies. It took a while to implement all this, but it was worth it.

If everything goes right, this will be the first time current users will be notified about a version update by the assembler itself. Exciting times!

See the documentation for details.

Download the latest version from the Retro Assembler page!

Retro Assembler V2.1.1 Released

August 23, 2018Retro Assembler

I didn't plan to put out an update so quick, but a friend suggested some changes and I went for it, plus added some other useful things. I adore this project!

See the documentation for details.

Download the latest version from the Retro Assembler page!

Retro Assembler V2.1 Released

August 20, 2018Retro Assembler

Support for the 65816 CPU is here, along with the SNES ROM output format. Adding this CPU was not possible in the 1.x days, but with the new foundation it wasn't too hard. Since this CPU is a special one with 8 bit and 16 bit modes and 24 bit address size, I had to add some special things.

Other changes:

See the documentation for details.

Download the latest version from the Retro Assembler page!

Retro Assembler V2.0 Released

July 24, 2018Retro Assembler

A new, completely refactored and updated Retro Assembler is here!

A lot has changed since the last version, both in the assembler and in the world of computing alike. It's clear now that .Net Core is a thing, it's available on numerous operating systems which makes it possible to do true portable app development in C#. And also Visual Studio Code is becoming a mature product, available for most people, no matter what their favorite OS is.

I'm happy to announce that Retro Assembler has reached version 2.0 and after serious refactoring and improvements is now available as both Windows (.Net Framework 4.7, runs on Mono too) and Portable (.Net Core 2.1) builds. Not only that, it's even integrated with Visual Studio Code via a custom Extension, making it a powerful development tool for all the popular operating systems.

Retro Assembler in Visual Studio Code

There's more! Now it's a full-fledged development environment for Nintendo Entertainment System and Nintendo Gameboy with the recently added Gameboy CPU and ROM support.

The target memory management got completely overhauled, now there is no practical memory limit for the projects, as long as they fit into the 32 bit address space. Labels and values can be up to 32 bit numbers. The Segment support has been changed, now combined with Banks it can do a lot more than before. If you used .target and .segment directives, update those in your source code files to the latest specification. The command line options also changed, be aware of that.

See the documentation for details, there are a lot of additions and changes to read up on.

Download the latest version from the Retro Assembler page!

It's been a lot of work, I hope you'll like it as much as I do.

Epic Comeback in C64 Debugger

February 23, 2018Retro AssemblerCommodore 64

You may remember Epic Comeback, the small but punchy Commodore 64 demo I made last summer. There is a utility called C64 Debugger which, among other things, can visualize what's happening in the C64's memory while a program is running. This can reveal some interesting stuff, even if you are not that much into programming in assembly. I made a video of it, check it out in full screen!

Some of the observations that you can make...

‐ The memory activity colors are: Blue for reading, Red for writing, Green for mixed reading and writing.

‐ Upon a hard reset the Commodore 64's memory is initialized with a 00 00 00 00... FF FF FF FF... byte pattern, so you can see stripes in the visualized memory.

‐ When the demo is first loaded from disk, it takes up about 1/3rd of the 64K RAM. It's compressed though. First the decompressor copies the whole compressed data to the top of the memory, then starts working on it and fills up the memory with decompressed data from the bottom up. At one point the decompressed data starts overwriting the original compressed data (red line) while the rest of the data is still being decompressed (blue line). Red catches up at the end, just as the decompression ends, filling up nearly the whole 64K RAM of the Commodore 64. This is so much data that the C64 kernel couldn't load it from disk in a decompressed state by default.

‐ The chessboard animation is not too interesting in memory activity, it's mostly a character set based animation with a bunch of video matrices and video bank switching. On the bottom of the screen you can see the constant update of those zero page variables that the animation is using.

‐ When the animation goes away, the demo generates a bunch of wave tables for the plotter, this takes up about 1/4th of the RAM in the middle of the visualizer. The rest of the memory is filled up with two generated executable code blocks, one for each video buffer. The effect is redrawn on each screen refresh, but uses so much CPU time (well, all of it) that double buffering is necessary to avoid screen tearing.

‐ In the middle you can see the X and Y double-sine wave of each of the 128 plots (this looks awesome in the memory visualizer) applied to the lookup wave tables, to figure out where to draw the plots in the video memory. This is all reading, so it's shown with Blue color. The plotter drawing is pure writing, so it's shown with Red color above the waves.

‐ The generated plotter drawing code gets executed and self-modified all the time, as you can see it from the activity on the bottom part of the memory visualizer. As the plotter slides out of the visible screen area, less and less plots need to be drawn, so the memory darkens a bit until the next plotter configuration slides up into view.

‐ I did a hard reset at the end, so you can see how the memory is cleared up before the kernel initializes the BASIC interpreter, which is the default user interface of the Commodore 64.

Cool, isn't it?

Retro Assembler V1.2 Released

December 12, 2017Retro Assembler

Retro Assembler Version 1.2 is ready with 65C02 and 65SC02 CPU support.

After the last release of V1.1 I received a lot of support and encouragement from Commodore 64 and 6502 enthusiasts on Facebook, it was nice. As a result of it, the assembler has been fixed to work on Linux using Mono, I even set up my dusty Raspberry Pi 3 with an environment that can run it.

I began researching other CPU types and ended up adding support for the 65C02 and 65SC02 CPUs. They looked like small updates at first with a few new instructions, but the 65C02 has these weird bit instructions that combine a zero page address for bit testing and a relative address for branching. That was a bit of a trouble for the assembler, as it couldn't deal with instructions that use two parameters. However, it was added and it works nicely.

I also realized that I didn't address the D64 maker option for Linux, which was clearly made for Windows, using "c1541.exe" under WinVICE. I can't really test that one (yet), but I changed the call to use "c1541" and we will see if it works. If you can test it, let me know, I'd appreciate it. Alternatively I put the command line call into the ReadMe.txt file that you can use on Linux, to get a D64 file out of a T64 file.

See the documentation for details.

Download the latest version from the Retro Assembler page!

Epic Comeback

December 8, 2017Retro AssemblerCommodore 64

As I mentioned before, when I started out developing Retro Assembler, I had a demo in mind that I wanted to make with it as a starter project. I've done it, took some time, I worked on it between July 25 and August 10 – finished it just in time for the 19th Árok Party, a cozy 8-bit gathering held in Ajka, Hungary. I couldn't be there but some of my friends were, the demo was sent in for the Commodore 64 demo competition and to my surprise it won 1st place. I couldn't be happier with how things turned out with this little passion project, it was quite the confirmation that it was worth the time I spent on it.

I uploaded a video capture to Youtube (and this way I have my own Youtube channel, yay!), check it out! The imperfections are due to the 50Hz system vs 60Hz video capture differences.

Now if you're interested, I can tell you about some technical details. As you may know, the Commodore 64 has 64 kilobytes of RAM, that's about the size of a blank Microsoft Word document before compression. That's a challenge on its own. The demo, without loading from disk, uses way more RAM than that, about 90K to be exact, by generating most code and data for the plotter effect.

The demo runs on both PAL and NTSC systems alike, by detecting the system type and making the music play on its intended 50Hz speed on NTSC systems that use 60Hz screen refresh. This can only be achieved by skipping the music player call in every 6th frame. That can cause some audio artifacts, but this is all we can do to make it sound right. The home of Commodore 64 demos (and better games) is mainly Europe, despite the computer's American roots.

The main block of the demo takes up the first 14K of the RAM, it contains the framework that runs the demo itself, the scroller and the chessboard zoomer's code, music, logo, scroller font and text. Then from $3800 the effects use basically the rest of the available memory. I didn't bother using the register area between $d000-$e000, that would come with too many complications that I tried to avoid.

Chessboard Zoomer

It's an animation, but that doesn't make it less cool. It would be hard to make this run in real time on this hardware, in 320*128 pixels. The raw data for it is 36K, with 22 animation phases (with 640 bytes of character matrix for each, taking up 14K in total), squeezed into 11 character sets (2K each, 22K in total).

22 phases of this animation would give us only 180 degrees of rotation. Due to the properties of the chessboard and the loop I went for, I can fake the other 22 animation phases by swapping the foreground and background colors halfway. Originally I wanted to go for a smoother animation with twice the phases, but that turned out to be impossible to hold in the RAM. Since the animation would run way too fast if it got refreshed in every frame, I only step to the next phase in every 2nd screen refresh. That still makes it smooth enough to be enjoyable. Every 4th loop of the animation the color palette changes to make the effect more interesting, while I'm babbling about in the scroll text.

The animation was made by using this data generator I wrote back in 2010 (see, I did plan to make this demo for a while). I can step the animation manually, and it calculates how many unique characters (8*8 pixel blocks) the phase contains, and how many unique characters we need for the entire animation so far. This way I could experiment with the optimal size, rotation speed and zoom properties without wasting time on implementing the entire effect on the Commodore 64 itself, only to realize halfway that something doesn't add up.


I love this effect, it's 128 plots forming cool blobs. I wrote something similar in a demo in 1997, only that couldn't refresh in each frame, unlike this one. Remember how the demo's framework and the chessboard animation took up 50K of the 64K RAM? When the chessboard disappears, I start the execution of a small program (2K) that generates 14K sine wave data and 13K unrolled code that can draw the plotter on the screen. With the effect's execution code, video memory buffers and all this generated stuff, it takes up about 40K RAM above the 14K for the framework.

The plotter refreshes during each screen refresh and takes up so much CPU time that it barely fits into the "raster time" as we call it. Due to this, to avoid screen tearing, it has to use double buffering. That means, we see the previously drawn animation phase, while we draw the next animation phase in the other buffer. Then switch. The code for it is highly optimized, with this flow:

This way it's self-sustained, the plotter cleans up after itself in the video memory after each frame. Each buffer requires its own code because they draw to different memory locations, each requires 6.5K of code.

For the curious, here is a sample of the code that draws one plot out of 128. It would be a bit too complicated to explain what exactly it does, but in short, it draws a plot with a dynamic vertical shift applied to it (the blobs swing up and down, then leave the entire screen to switch animation style) after figuring out where to draw in the video memory, and updates the cleaner code for this buffer to clean up after itself the next time the code is called.

lda $6200
adc $a2
cmp #$80
bcs (to Next plot code)
ldx $6280
lda $aa80,x
sta $a0
ora $a0
sta $e001
lda $ab80,x
sta $a1
sta $e002
lda $aa00,x
ora ($a0),y
sta ($a0),y
(Next plot code)

The plotter's execution takes up so much CPU time that I had to unroll even the scroll routine to make it all fit into a single frame. But as you may know, the NTSC systems work with 60Hz refresh and basically a smaller screen border, which results in smoother animation with less CPU time to use. The plotter uses two kinds of blob shapes, simpler ones and more complex ones with additional position calculations. The shapes are controlled by a playlist that modify the values of the plot position calculator and on NTSC systems I was forced to skip the complex ones. This way the demo runs smoothly on both video types, but the PAL version is more colorful, so to speak.

The demo takes up so much initial memory space, that the Commodore 64 kernel can't even load it into the memory without serious compression, for which I used Pucrunch. But this isn't a surprise, most C64 executables are compressed some way. Only in this case I couldn't even test the demo without compressing it first, once I put it all together into one file.

Download, D64 image file (20KB)

Platform: Commodore 64 (a real one or an emulator like VICE)

See its profile page on among other Commodore 64 demos.

Retro Assembler V1.1 Released

December 6, 2017Retro Assembler

Retro Assembler Version 1.1 is ready with improvements and bug fixes.

Among other things, the new .memory directive lets you perform byte manipulation in the target memory. This is useful for ad-hoc data duplications, conversions or other modifications.

See the documentation for details.

Download the latest version from the Retro Assembler page!

Retro Assembler

July 21, 2017Retro AssemblerCommodore 64

I spent the majority of my childhood and my early adult life coding a lot of demos and a few games on Commodore 64 and Plus/4, in assembly. Later I also worked on demos for the Amiga and Gameboy Color. I miss those days a lot, and in the recent years I had this recurring urge to write a new C64 demo. Or at least do something in assembly because it's just fun. After spending quite some time reading up on the ins and outs of ARM V7 that I could code for in my Raspberry Pi, I realized that it's just silly to go down that route. The Pi hardware is surprisingly poorly documented, people are just guessing or reverse engineering Linux distributions to figure out how the GPU's screen buffer can be accessed, mail slots and messaging, ummm no thanks. I can spend my time a bit more wisely, and my heart is captured by the Commodore 64 forever anyway.

My friends and I used to code in an awesome utility called Turbo Assembler, it's still a fascinating piece of marvel. It loaded to the memory address $9000 and upwards, and the tokenized source code was building downwards from there, so it left us plenty of work space in the 64 kilobytes RAM that the Commodore 64 and Plus/4 were built with.

Back in those days I wished I could write my own assembler, but I couldn't even imagine how I could do that effectively, with at least the same features I used in Turbo Assembler. Then decades passed, I worked on a bunch of serious software, and suddenly it didn't sound impossible anymore, just a bit challenging. I decided that if I'm going to code a new demo (or twenty), it must be done in my own assembler. I got to it, started working on the project on a Sunday morning on June 18th, and by the next Saturday it compiled the first test source code, a music player.

Retro Assembler was born.

Retro Assembler – Commodore 64 source code in Notepad++

After a month of work on it (not full time, just evenings and weekends), it's ready to be published. It's so advanced that it could easily be called a version 2.0 but I'll just go with a solid 1.0 for good measure. I'm afraid I got a bit carried away with it (in the meantime my wife Leslie binge-watched all five seasons of Orange Is The New Black), now it's a macro assembler with a lot of serious features. I made it to support the MOS6502 microprocessor family, so most Commodore computers and some early game consoles (Nintendo NES, Atari 2600 etc) can be targeted with it. But it's not all it will ever do. The application was designed in a way that adding other CPU types is doable with moderate amount of work, so in a future release the Gameboy CPU will be supported too, and shortly after the Zilog Z80 as well. I might even code something for the ZX Spectrum I never had. Motorola 68000 and perhaps ARM may be supported as well, but those can wait.

For all the features check out the rather extensive documentation, but here are the highlights:

I guess that's good enough for an initial release. I don't expect too many people to start using it, but even if nobody ever downloads it, I don't mind. I'm really proud of this assembler and now it's time for me to start working on that demo. Fellow sceners, I'm back!

Download the latest version from the Retro Assembler page!