Robot Game: 65C02 C, assembly, and Forth Comparison

The last six months or so, I have been working on a project to compare the performance of C, assembly, and Forth on the 65C02. This week I finally finished everything and published the results on my website. A few days later, the project was featured on Hackaday!

To compare the performance between the languages, I made a simple game called Robot Game in Python in order to have something to port. The C version is compiled with CC65 and the Forth version with Tali Forth 2. There are two assembly versions. One is plain 65C02 assembly using the X register as a data stack and the other uses the Assembly Optimizer I have been working on to get slightly better performance by putting locals in zero page at fixed addresses. All four version of the game work in my JavaScript-based emulator and can be played on my website. The source code for all the versions of the game, the emulator, and optimizer are now on my GitHub page.

Porting the four games was a challenge and also a lot of fun! I learned a lot about how C and especially Forth work internally. After I had the games ported, I looked at 28 different tasks the game does internally and compared performance across languages. Here are the results where traditional assembly is normalized at 100%:

The optimizer adds up to 10% performance and 25% in one very short routine. C was about 2-3 times slower than regular assembly in the tests and Forth was usually around 10-20 times slower. One of the really interesting things was figuring out why Forth is so much slower despite Forth fans claiming it's much better than C. 

Optimized MSP430 Assembly in Mecrisp Forth

A few years ago, I got interested in Forth due to its connection to RPN calculators but lost interest because of the huge hit to performance a stack-based system takes on an architecture like 6502. Recently, my interest was piqued again during a conversation in the #Forth IRC channel on FreeNode about Mecrisp-Across, which uses an ARM-based microcontroller board to produce optimized assembly for the MSP430. Because the compiler tries to keep values in registers instead of the stack, it has the potential to reclaim some of the performance lost in most Forths. Some of these optimizations might be useful for a 6502-based Forth, so I tried to understand how optimizations in Mecrisp work.

The first step was getting Mecrisp running on a PC. The author provides versions that are compiled for ARM with Linux system calls, so you can use QEMU for emulation under Linux. Getting this working on Windows was a real challenge. One Debian image I tried emulating with QEMU crashed the emulator outright. Another image booted into Linux but refused to install QEMU complaining about needing the Linux CD in the drive before it would install any packages. Getting Ubuntu working on VirtualBox under Windows 10 and installing QEMU on it wasn't too tough, but the Mecrisp image wouldn't run until I got the right type of QEMU (there are several). The right combination was VirtualBox, an Ubuntu image from OSboxes, and QEMU-user-static.

New Project: 6502 Assembly Optimizer

This is another project on the list of open projects from a few months ago. The goal is to improve 6502 assembly code used in the firmware of a graphing calculator project. The first step is to manage how local memory is used, since the current options are not that great. One option is stack-based addressing in zero page, which monopolizes the X register. This is one cycle slower than hard coding a static address in zero page and mostly prevents the use of the X register for anything else useful, leading to less efficient code. The other option is assigning each local variable to its own address in zero page, which is very wasteful. With only 256 bytes, you run out of room pretty fast. This project assigns zero page automatically by determining which functions call each other (call graph pictured above) and assigning memory so that functions which never overlap share the same memory. In this test code, 38 bytes of local variables fit into only 19 bytes of zero page. Here is a graph where each row represents one byte of zero page and each block one byte of local memory in a function:

Depending on the shape of the call graph, it might be possible to fit a large number of variables in a small amount of zero page.

6502 Calculator Emulator: Website

 Yesterday I finished setting up a website to host my 6502 calculator emulator: www.calc6502.com. So far, it's just running EhBASIC to test that everything works. Getting the website going with AWS was a lot easier than I thought it would be! It's about as straightforward as possible with S3.

Since the last post, I've made a lot of tweaks and improvements to the emulator. One big difference is caching the color values for the screen pixels to avoid accessing an array within an array. This brought draw time down from 150-280ms to 15-70ms. Before that, typing was noticeably laggy. The new version also has the option to follow the program counter and memory accesses in the bottom two panes that were hard coded to 0xC000 and 0xFF00. You can also select which page to view there if you don't want to follow along. There were a few bugs to work out too. The assembly listing was totally blank after loading EhBASIC since the code started at 0xC000 and the emulator was treating those addresses as labels. Lines like LDA <#CharTable were being corrupted since the < was being treated like an HTML tag until it was replaced with &lt;. After that was fixed, I added a feature to scroll the listing to the currently executed line when single stepping. The last change was enabling access to peripherals from any addressing mode so PEEK and POKE work correctly. Before that, the emulator only checked direct addressing for peripheral access to save time.

Last night I got a text-based mandelbrot program from Gordon Henderson's website going. It worked fine after adjusting the screen height and width. Then I tried using POKE to change the color of the characters:

New Project: 6502 Calculator Emulator

In my post about Open Projects, I mentioned this project, and now I'm officially announcing it. This is a JavaScript based emulator of the 65C02 processor that runs in the browser. My plan is to write assembly and load the assembled binaries into the emulator where I can test them. Eventually, the page will be hosted on a public site where other people can try the software for the 6502 calculator I'm working on and report bugs.

Before I started on this project, I looked at a lot of other browser based emulators hoping I could use one of them. Some are unbelievably slow, working at way less than 1MHz and would not work well to test the calculator code that will eventually run at at least 10MHz. All of the emulators I looked at also lacked bank switching. The calculator will probably need several hundred kilobytes of memory which none of the emulators provide. The last reason is being able to map the peripherals into memory how I like and have them resemble the actual physical calculator I'll build when the software is finished.

The slower emulators I looked at do the emulation and interface in one thread as far as I can tell. Doing the emulation in a second thread with a Web Worker is a huge performance increase. In my emulator, the emulation thread performs a set number of instructions then checks in with the interface thread to get keyboard input and relay new screen contents. Setting the number of instructions to 1,000,000 yields around 70MHz performance, which is five times faster than the actual chip. It also makes typing a little unresponsive, so I set it to just 100,000 which is a good balance between responsiveness and performance of around 20MHz.

The emulation code ended up fairly compact. This is my first JavaScript project, and when I showed it to someone asking for advice, he said it looked like low-level C code. Each addressing mode has its own function and each operation (ADC, AND, ORA, etc) has its own function. The functions for the instructions themselves are very short since they are mostly combinations of those two types of functions. Rather than a switch statement, I use the op codes to index into an array of functions, which is probably a lot faster. This is how I would do it in C and it works in JavaScript, although the guy who was helping me pointed out that there are higher level structures in JavaScript that you could use instead. Banking works by splitting the first three 16k segments into banks (minus the first 200 bytes for zero page and the stack) and leaving the fourth segmented unbanked since it will always be EEPROM.

The first thing I tried when I got the emulator working was the test suite by Klaus Dormann. It passed after a few modifications, mostly to memory address wrapping. Then I mapped two banks of RAM to a simulated 256x128 video output where each pixel is represented by one byte. The final calculator might be black and white or have less color resolution, but I'll use this for now. I made a simple font which is copied to the display memory pixel by pixel. This didn't look especially impressive, so I found a much better looking one online to use instead. Next I added support for transparent backgrounds.

I got EhBASIC running after a couple days of fighting with it. The first command entered would work and the second would fail with "Syntax Error" depending on what the command was. I tried all kinds of things to find the problem, including stepping through the code to evaluate input, before I tracked it down to a location in zero page. It looked like one of the bytes there holding interrupt information was somehow corrupt since the error was thrown after it was evaluated. The source listed a handful of zero page bytes as free to use, so I put the pointer for updating the screen there. As it turns out, the byte is not actually free! Everything worked fine after I moved the pointer somewhere else.

More Calculator Processors

Last year I wrote a post about a lot of different processors that could be used to make a calculator. Recently I decided to buy some of them from the CPU Shack Trade List and found some others that might also work. John, who sold me the chips, was really helpful and sent everything very quickly.


These are the processors from the last post that I got examples of:

CDP1806ACE
E87C196KDH20
N80960SA-16
N80C196KC16
NS32FX164V-25
TMS320C25FNL

The really exciting one is the NS32FX164. It seems like a really neat chip, and I was having trouble finding any of the NS32FX160 series chips to play with. There are a lot of variants built on this core, and this seems like one of the best ones to have. The instruction set is really interesting since there are so many options and extensions. This is definitely a CISC processor.

These are new chips not covered in the last post:

2650AN - This is an 8 bit microprocessor with more registers and instructions that a 6502. However, it has a strange 13-bit address system that makes it less useful than all the other processors that can address at least 16 bits. The one I got is the A version which is missing some of the added instructions of the B version. Top speed is apparently 1.25MHz.

INS8073/N - This is another 8 bit chip that that also has limited addressing potential. The main appeal of this processor is that it has a version of BASIC built into ROM. I don't think I would rely on that for the calculator's main language, but it might be neat to have it as an option to play with. Hopefully there is a way to boot from external memory and jump into BASIC later.

L3903-57 - This is part of an offshoot of the 6502 family that was used as part of modem chipsets. It has a lot of microntroller features like internal RAM and peripherals like timers. It runs at up to 20.5MHz, compared to the 8MHz of the 6502 derived microcontroller made by WDC and the 14MHz of a 65C02. It is not entirely compatible with the 65C02 since it handles indirect jump instructions differently and has additional instructions for threaded code. It might have more flexible timing constraints, which could be helpful even if it isn't running at top speed.

N8X305N - This is the weirdest processor in the list by far. It has a 16-bit wide instruction bus but no dedicated bus for data. External data access can only be conducted through two "ports." The really strange thing about this chip is that it only has eight instructions. The OR instruction, for example, has to be synthesized from AND and XOR. It seems like it would be a big challenge to write assembly for this.

SAB80199 - This is a neat 16-bit chip made by Siemens. Unfortunately, I can't find a datasheet for it, so I'm not sure yet if it would work well for a calculator. I paid to access the datasheet database at eca.de, but the link they sent was broken. Hopefully they will respond to my messages soon.

As I wrote in my another post, I'll have to finish some of the projects I have open now before I start on something with one of these chips.

Tiny Calculator: Keypad

The last few weeks I have spent a lot of time on the keypad for my Tiny Calculator project and the results are a little surprising! After considering a lot of different ways to make caps for the keys, I finally bought a 3D printer, specifically an Ender 3. Before that, I tried using an Xacto knife to cut out a base and a slightly smaller square post from PVC I bought at the craft store. The result was pretty uneven and there didn't seem to be any way to make them all exactly the same size, so I bought the 3D printer the same day. It was easy to put together and has produced great prints from the very first time I tried it!

The first thing I worked on was designing a button cap with a skirt that would keep it from falling out of a grid overlay. It was really easy to do in OpenSCAD. I printed several versions to get the dimensions right and design a hole in the base so it would fit over the posts of the tactile switches. The first version was black and looked really nice. Next, I started on the overlay and experimented with several versions. One that was only 0.5mm thick fell apart when it came off the raft it was printed on, and I eventually settled on 1mm for the thickness. As I experimented with improving it, I added supports that fit over the header pins on the keypad to keep everything straight and holes for longer pins to keep the grid attached. This worked really well to keep the keys straight and attached but the grid was still a little flexible because it was so thin, so I added a 3mm wall around the edge which made the print very rigid.

The buttons themselves were printed with the holes for the posts facing down. The slicer program inserts tiny supports to keep the hole from collapsing while the button is being printed. It took a long time to carve the supports out and the results ended up being a little uneven. Some of the holes were slightly too deep and the entire button post fit in them with no clearance for the button to be pressed. This led some buttons to have a stronger click and some to stick up farther than the others. One thing I tried to make them more even was to print them in rows of five with the hole facing up. The hole depths all turned out extremely uniform but the lip holding them together came out garbled and they easily broke apart since the lip had to basically be printed parallel to the ground with no support. The next time, I turned the row of five on its end, which worked since I had removed the lower skirt edge to make room for the lip holding them together. Printing five of them in a row like this makes the button presses more uniform and the rows straighter.

The design for the keys labels was done in Google Sheets and copy and pasted into Paint. This worked really well! It was way easier to make modifications and keep all the text uniformed and aligned than doing it in Gimp, which I tried a few months ago. Once I had the design, I went to Staples and had them printed on overhead transparencies. Unfortunately, there is no way to print in white on a standard printer, so you couldn't see anything when the labels were put on black buttons. I bought a roll of white plastic and now the labels look exactly how I planned. For the next iteration, I bought a cheap inkjet printer and transparency paper so I can make the labels myself. They are printed in reverse so I can glue the ink side down and avoid smudges from finger presses. I designed and printed a little bracket for cutting out the labels at exactly the right size, but it turned out not to be useful. Super gluing all of the labels on took a couple tries to get right, but I'm very happy with the result! Now that I have the 3D printer, I plan to make similar keypads for some of my other projects.

Test button made from PVC	Different versions of the button cap	Under side of the button caps. The middle one still has supports.
Failed 0.5mm overlay print	1mm overlay print	Overlay with added wall for stability
Failed print of five connected buttons	Successful print of five connected buttons	Bracket for cutting out labels

Keypad labels