Retro Assembler V2020.1 Released

February 20, 2020

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!

Kindle eBook Preservation Without DRM

February 4, 2020

In the past few years I've become an avid reader again, after a long time of neglect. I standardized on eBooks from the Amazon Kindle store and used the Kindle app on various devices, until recently I got myself an eInk Kindle Oasis, the 2019 version. The previous Kindle devices just wouldn't cut it for me compared to an iPad Mini (I'd still vouch for that as the second best option), but this newest one has a pleasant form factor, page turn buttons, warm LED front light (a must have for me), it's comfortable to hold and has nice cover options with magnetic wake and sleep functionality. The battery life is very good, if you use it in airplane mode most of the time like I do. It isn't cheap but it's worth it for me, with removed ads which costs extra, but makes it all better. No more swiping up to read the current book; it's a cheap fix for a major annoyance.

As someone who's been in the IT world since the '90s, I'm a bit paranoid about backups, data preservation, file formats and storage in general. No need to store anything, it's all available on the internet! Just keep it in the cloud! All I can offer to those claims is a bittersweet smile. In this case with eBook stores, it's not unheard of that a publisher decides to take the ball home and previously purchased books become unavailable for further download. Or maybe they replace the old version with an inferior one. Or perhaps you choose to move your data into a completely different ecosystem.

Books in the Amazon Kindle store are DRM-protected, but luckily (currently) there are ways to get rid of the DRM and make it possible to move books from one device to another in the uncertain future, even when the books are no longer available for download.


This tutorial requires having a Kindle eInk device and purchased books on your Amazon account. Technically it may be possible to use the Kindle for Mac/PC app instead of a device, but that may depend on older, specific versions of the app so I will leave it to others to figure it out. I also don't know how this would work with Kindle Fire tablets. The DeDRM FAQ may be able to answer these questions.

The currently used Kindle file format is called AZW3, but later on this may change to AZW4 or something, depending on Amazon's decisions. The then-latest versions of the software described below will likely be able to handle it using the same general method.


Download your eBooks

Find the Manage Your Contents and Devices section on the Amazon website where the Content section will look something like this. Pick a book and in the Actions menu choose Download & transfer via USB. Then you'll have to choose your eBook device to download the file for. This is important, the DRM will be generated for the chosen device, based on its unique serial number.

The resulting file is in Amazon's DRM-protected AZW3 format, or in their legacy AZW format for MOBI files. eBook files can be obtained from the Kindle's file system too, but these days most of them are stored there as KFX, which is harder to work with using additional Calibre plugins, if you want to go down that route. I choose not to, partially because in the books Amazon sends to the device's library, the cover images are converted to grayscale. With this manual download method the cover images are preserved in their original color format.

Configure Calibre

Install Calibre, then go into Preferences and locate Advanced → Plugins. Click the Load plugin from file button and select the DeDRM Calibre plugin zip file. This will be added under File type plugins. Next, you need to configure it and enter the serial number of your Kindle eInk device, which will be used to decipher and remove the DRM protection from the book that is currently tied to the specific device.

After this, when you import a Kindle eBook file into Calibre, the DRM will be stripped by the DeDRM plugin automatically and you can open the book in the Viewer. If Calibre can't open the book and complains about DRM, the plugin either wasn't configured properly, or it can't handle the file you tried to import.

eBook management

The converted eBook files can be found in Calibre's library structure, categorized by author. AZW3 files remain in the same format, while the legacy AZW gets converted to MOBI by default, so it varies what file extension you need to look for. MOBI files can be converted to AZW3 for a consistent library. Beside format conversions, you can update the embedded cover art, meta data, and even the whole book can be edited if necessary.

I opt to store my eBook files myself, outside of the Calibre library structure, by keeping both the original and the DRM-free version of each. The unlocked books then can be transferred to the Kindle device via USB connection into the Documents/Downloads directory, or they can be emailed to the unique Kindle email address of the device, which will download it via WhisperSync. The Kindle device will find it, import it into its library and do the necessary indexing automatically. If down the road you decide to move the books to a different type of device, Calibre will likely be able to convert them to the required file format, or to a commonly used one like ePub.

Retro Assembler V2.4.2 Released

October 19, 2019

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, 2019

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 20, 2020

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.
#(Obviously this command is one single line, edit it together)
wget -q
packages-microsoft-prod.deb -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, 2019

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, 2019

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, 2019

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, 2018

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, 2018

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, 2018

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, 2018

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, 2018

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, 2018

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, 2017

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, 2017

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, 2017

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!

How To Enable JSON Compression in IIS

November 17, 2017

In the past year most of my web work has been reduced to the development of Web APIs with clear JSON request and response. The response sent by the web server can be quite big, so it's a good idea to enable dynamic compression on it. However, even when you enable compression in IIS, it won't compress files sent with content type application/json. Not by default. Luckily the compression settings can be configured. To do it for the whole web server, open the settings panel for the web server root (these settings are applied to all websites) and open the Configuration Editor in the Management section.

In the Configuration Editor there is a Section selector on the top. Open the section system.webServer and choose httpCompression to access the dynamic and static file compression settings. As you can see, there are plenty more you can adjust in IIS, but I'd say it's best to leave most settings as vanilla as possible and apply adjustments in individual web.config files. But in this case it won't hurt to enable JSON compression for the entire web server.

Here you can set up the content types handled by the file compressor. Obviously it's not worth to GZip a Jpeg file, but text based files are good candidates. The types can be set for Dynamic and Static file compression individually.

In Dynamic Types add a new MIME type to the list: application/json and mark it as Enabled (True). You may also add application/json; charset=utf-8 just to be on the safe side.

Then do the same additions for Static Types, you may need it in certain situations. Don't forget to actually enable compression in the server root's IIS section, by going into the Compression editor.

Ford Escape 2016 Long-Term Review

August 3, 2017

Meet Nyunyu, my blue Ford Escape. It's more than just a car. It's my dream car. I've always been a big fan of the Ford Focus, we even got one for Leslie in 2012. I liked the boxy Escape from that era, then the revised version came out in 2013 and it was love at first sight. The same tech as in the Focus with the same interior, but in a slightly bigger package. I really wanted one, but I didn't even have a driver's license at that point, and Leslie definitely didn't want us to deal with two car payments anyway.

So I was just dreaming about it for quite some time, saving up for it, and in the meantime I bugged the heck out of my wife about what color I'd pick, what kind of tools and gadgets I'd carry in its obviously infinite trunk space and stuff like that. I always played with one at the Ford dealership, I even test-drove one later on. Mike the dealer kept nudging me to just sign a contract and get one already. No Mike, I have to save up for it... I had to be really annoying at times, but my wife is clearly an angel because she coped with it, and by 2015 she said alright, once we paid off the Focus, we can buy me the Blue Escape I want so much. Our adventure vehicle. Okay, say no more!

In 2016 January the news broke about the 2017 Escape face lift, and I didn't like it too much. It's surely a fine car, but looks too much like the Edge and the Deep Impact Blue color isn't even an option anymore. Ford already stopped manufacturing the now old car, and by talking to Mike it became obvious that it's gonna be hard to find a blue Escape with the packages I wanted. Found one in Ford's dealer system that was close enough, Mike had to do a swap with another dealership from another state to get it, but he's a nice guy. And I bet he wanted this constant annoyance to be over anyway. On January 30th of 2016, Nyunyu was born. So to speak.

Maybe I went a bit overboard with the specs, but I wanted a car that I can keep forever. So it's Titanium trim level with the beefiest engine available, a turbo charged 2.0L EcoBoost with 240 hp and 270 lb/ft torque. Coupled with the Intelligent 4WD system that we need here with all the hills and cold winters, it's a beast. There is no legal speed in the USA at which I couldn't just step on the gas without being kicked in the back by nearly instantaneous acceleration, sometimes with wheel spin. It's ridiculously stupid fast, almost at the point of questioning, why is there such an engine in a soccer mom car? It's a real sleeper, but it's just my opinion, your mileage may vary. With its keyless entry and push button start, it makes older solutions feel archaic. It's easy to get used to good things.

It came with Ford SYNC 3, which is sadly not developed by Microsoft anymore, but it's a really decent QNX based entertainment and navigation system with a proper touch screen. I love the navigation, it was a must have and we already had some epic trips with it, including driving to Wisconsin. The media player is fine, nothing fancy but it works and that's what matters. Two USB ports in the center console, either can take a flash drive with MP3 and AAC files and the bluetooth connectivity works like a charm for podcasts. I have no complaints apart from the song shuffle algorithm which has some issues and heavily favors Marvin Gaye. You'd think I have a hundred songs from him by the rate he keeps popping up on the Sony audio system, which sounds awesome by the way.

It's really pleasant inside, like being in a leather cocoon. The dashboard is modern enough to look good, but not too modern to age badly as time goes by. There is a small screen between the analog gauges that can show some essential information, including the current speed that I keep on all the time; I don't look at the analog speedometer at all. It even has a small area for navigation integration to show the upcoming turn which is really handy. It's a high definition display that doesn't show any noticeable pixels, but isn't too large or dense to cause issues. I would hate to have a car where the whole gauge cluster is just a large LCD or OLED screen, and suffer from (rows of) dead pixels down the road. The gauges have ice blue lighting during the night, it's just tasteful all around with a design I'd describe as timeless.

The car has some configurable lights in the doors, cup holders and in the foot rest area, the color of the light can be picked from a predefined palette. I roll with teal. There are physical buttons for the essential functions, it's rare that I need something that can be controlled only from the touch screen. The AC works fine, but I have some ear issues that makes me wish I could set up the vents and the temperature just right. Sadly I just can't, it's warm or too cold or drafty. The problem is likely located between the front seat and the steering wheel, Leslie has no issues on her side. The power windows work well too, but I open mine only when necessary and when the car is stationary, otherwise my next trip would be to the doctor's office with a nasty ear infection.

The fuel consumption is okay. It wouldn't be a good long distance commuter car, but with my usage habits it's fine. It can do 25 MPG in mixed city and highway and about 30 MPG in pure highway use. On long trips the fuel gauge is amusing to look at, as if there were a bunch of frat boys in the engine bay yelling chug-chug-chug! At least it's always fun to stop at service plazas to refill the 12-gallon tank and have a little break from the monotony of USA highways. Since I got the car, in just over 15000 miles it consumed 656 gallons of 93 octane premium gas that cost me $1600.

I'm happy with the car altogether and I have no buyer's remorse over a year of having the 2017 version on the roads. It's hard to find things I don't like about it, takes some nitpicking to list any. Beside the AC issues that are rooted in user error, I don't like how there are only a few storage compartments. It's hard to put stuff away in a neat, organized way. The space in the back seat area is fine, but could be bigger. Kids would fit alright, but longer trips may not be so pleasant for adults. However this is probably true for most cars with a normal wheel base.

I thought the trunk space will be bigger, too. It's big enough, sure, and can be made huge by folding the rear seats down. I really wish I could go to IKEA and buy a new dresser or something, it would fit in like a charm. We don't need new furniture now. But in day to day use, the trunk is a space hard to utilize neatly without some proper storage solution. It's true for most cars anyway, and maybe I'll figure something out for it. When I put my 29" mountain bike into the car, it's a bit of a logistical challenge but it just fits. Popping the front wheel off the bike would help a lot, I just keep forgetting to order a set of quick releases.

Ford has been teasing that the SYNC 3 that comes with this car will receive a software update to bring it up to the level of the 2017 version with Apple CarPlay and Android Auto capabilities. It didn't happen yet, in fact not a single update came so far and Ford is backpedaling now, saying that it would need hardware modifications to enable that... Yeah sure, sure it would. Sounds like BS to me, and I'm not sure what's gonna happen with it later on. Luckily I like the functionality as-is, so it's not a burning issue, but after several years the need may arise to replace it with Apple CarPlay. Also there are no map updates over the air as predicted, Ford is milking customers with that one. I'll probably wait a couple of years then get that paid update. It's okay so far, didn't run into any traffic issues due to outdated maps, yet.

Either way, it's a great car that's a joy to drive and I find it beautiful. If you're looking for a used one, try one, sounds like a good choice to me. But don't ask for mine, it's not for sale. We are inseparable.

Retro Assembler

July 21, 2017

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!

Platform: Windows (.Net Framework 4.7) or Portable (.Net Core 2.1)


July 20, 2017

This is a bit of a recap. I wrote this app in April 2015 and now I issued a minor update.

Ambience puts you into the mood for work or relaxation by playing ambient sounds in the background. Whether it's nature or a busy coffee shop that helps you to get into the zone, Ambience got you covered. The app is based on Noizio for macOS and iOS, but it had no Windows version, so I made one.

Ambience – Noizio for Windows

Back then not only I made it High DPI aware, but also created an installer version. I decided to drop the installer due to its issues, the app can be used in portable mode which is better anyway. And with the release of Windows 10, I made a small adjustment in the header to look better with white title bars and compiled the app for .net Framework 4.7 which will be the minimum version for my applications from now on.

Download it from the Apps page!

Platform: Windows (.Net Framework 4.7)

Big thanks to the makers of Noizio for the sounds and images, they deserve all the credit for those. Go and check them out if you've got a Mac, iPhone or iPad.

Here We Go Once Again

July 20, 2017

A couple of years ago I restarted this website, but it didn't go too far before I neglected it, as it happened before. Now once again I'm doing the same thing, hoping this time it sticks. As usual, these reboots are tied to blog engine rewrites and guess what, I've rewritten this blog engine again. One might think that I don't like to blog, I just like to write blog engines. One might be right. One may also recall the definition of insanity at this point.

Anyway, this blog is a platform for my thoughts, an outlet where I can write about things I developed, used, enjoyed, experienced, or just interesting to me. It may even contain some details of my personal life. How it will go remains to be seen, these pages are here to be filled with something you may find valuable or just entertaining. There are so many things in life that won't fit into a tweet.