Thursday, February 22, 2018

Venus, a web-based simulator for RISC-V instructions

For those looking for a way to fool around with RISC-V assembler without the hassle of installing an emulator, Keyhan Vakil has created an online instruction simulator called Venus at It's RV32IM -- basic integer and multiplication functions. The GitHub page is at

Venus was built for education, and it seems Prof. Martin Schoeberl at the Technical University of Denmark uses it in his course Computer Architecture and Engineering. Some of the class notes with (very, very simple) RISC-V code are on GitHub at

(Speaking of code, at the moment, I'm finding it hard to get into RISC-V quickly because of a lack of non-trivial examples that explain why which commands were chosen -- which structures are recommended for, say, even simple loops over strings. The RISC-V Reader by David Patterson and Andrew Waterman is good, but a very brief introduction. What seems to be missing is the equivalent of Lance Leventhal's legendary 6502 Assembly Language Programming or, even more useful, his 6502 Assembly Language Subroutines.)

Sunday, February 18, 2018

ALPHA version of Tali Forth 2 for the 65c02 released

Hence plan to throw one away; you will, anyhow.
-- Fred Brooks, "The Mythical Man-Month"

Yeah, so that really wasn't the original plan. But the first version of Tali Forth, the first Forth I ever wrote, turned out to be so horrible under the hood that in the end, it was easier to start over with what I had learned through Liara Forth for the 65816. Of course, the first thing that Liara taught me was that a 16-bit CPU is so much more powerful than an 8-bit CPU that it isn't even funny ... once you you have tasted 16-bit ...

No, we must stay strong! I've now coded all words of the new version of Tali Forth (at and so I'm declaring this an ALPHA release. "ALPHA" in this context means that "everything does something, and usually even the right thing". You can run it out of the box with your py65 simulator.

Tuesday, February 13, 2018

So this guy is building his own RISC-V CPU

Did I mention RISC-V in the last posting? Turns out that Robert Baruch is building his own RISC-V CPU [YouTube] out of chips.
The LMARV-1 (Learn Me A Risc-V, version 1) is a RISC-V processor built out of MSI and LSI chips. You can point to pieces of the processor and see the data flow. It should be a nice way of demonstrating how RISC-V works and how simple it is to implement.
The video also includes a good introduction to RISC-V itself. (Via Hackaday)

Saturday, February 3, 2018

Current projects: and Tali Forth 2

One of the strange things about getting older are the curious and somewhat uncanny attacks of self-discipline. These days, instead of my usual rushing off and doing three, four, five projects at once, which then each proceed at a crawl, I have managed to cut the number down to two at a time. Two! And lo and behold, you actually make progress that way.

Currently, those two projects are:

A rewrite of for OpenZFS in Python 3

ZFS, or more common these days, OpenZFS, is a next-generation file system that puts the emphasis on really, really, really keeping your data safe at the cost of higher hardware requirements (Adam Leventhal claims that it was almost Apple's next file system). I got my initial hands-on experience when I built my first own FreeNAS server -- FreeNAS is based on FreeBSD. ZFS comes with a brutal learning curve, but rewards your pain with seriously advanced features. In FreeBSD Mastery: ZFS, Michael Lucas and Allan Jude famously speculate:

The Enterprise's computer on Star Trek probably runs ZFS.

After a while, the paranoia built into ZFS becomes infectious, and it becomes hard to take file systems seriously that don't checksum every single byte of data. By now, I've moved my Ubuntu home partition over to ZFS.

Now, buried in a far-away corner of OpenZFS in the Linux GitHub tree is small program called which provides information on the Adjustable Replacement Cache (ARC) of ZFS. The original version was written by Ben Rockwood in Perl for Solaris in 2008, and was later ported to Python and (among other things) Linux. However, the Perl roots kept showing, and Pythonic this wasn't. So I did some cleanups under the hood, which was fun -- not the least because the people in charge of OpenZFS on Linux are enormously helpful and friendly even if you ask really stupid questions.

However, was written for Python 2, and Python 2 it must remain because ZFS is backwards compatible to various ancient operating systems. This is frustrating, because the only thing worse than Python 2 is old Python 2. So, to finally get to the point, I've started a complete rewrite of in Python 3. In the grand scheme of ZFS, this is sort of like reorganizing the broom closet in the Sistine Chapel -- but hey, it's the Sistine Chapel. This project should be completed soon.

A rewrite of Tali Forth for the 65c02

Tali Forth was the first Forth I every wrote myself. It, ah, worked. After that, I wrote Liara Forth for the 65816, which was far, far better because I kinda-sorta knew what I was doing. After that (and a whole lot of further reading), the original Tali Forth looked silly, so I'm doing a clean rewrite named, obviously, Tali Forth 2.

Beyond minor technical differences, Tali Forth 2 should be far easier for other people to port their own 65c02 projects to. This time, I'm writing it for the Py65 simulator and trying to strictly isolate all hardware dependencies. A Forth is always fun to code because you can just do a word here, a word there as time allows once the main loop is up and running.

And after that?

We'll see. One thing I'm considering is trying my hand at RISC-V assembler now that there is actual hardware to run it on. Also, there doesn't seem to a modern implementation of Lisp for the 6502, which would be so completely different from Forth that it sounds like fun. And then ...

... nope, only two projects at a time. Because, like, adult.

Monday, January 22, 2018

A slight change of focus

Fair warning: Since the Übersquirrel is as built as it will probably every be -- it turns out that software is easier to fit into my life than hardware -- I'll be repurposing this blog for more general ramblings about computer projects. There will still be a large dose of 6502 assembler, but there will probably be more on Forth, Python, Go, and ZFS. Updates will still be infrequent, but hopefully the pauses will be measured in weeks and not years. So if this is not what you wanted to read, jump ship now.

Wednesday, September 23, 2015

Building tools for the 65816 Übersquirrel

In which our protagonist proves how amazingly productive procrastinators can be, unless color choices are involved.

Remember last time we talked about switching from the 6502 to the 65816, and that we'd have to write our own assembler and emulator? Well, it turns out that there is a reason that the world is not overflowing with emulators for a 8/16- bit hybrid chip with a banked memory structure and emulation/native modes: It's complicated, to the point where we're already dealing with questions the experts describe as "esoteric" and have to test on actual hardware to answer. That is never, ever a good sign.

So my chips are gathering dust in a box while I'm writing the emulator from hell.

Forth code from the crude65816. In which other language can you get away with naming a function "24>lsb/msb/bank" ?

But wait, how do you test an emulator? You need an assembler, because hand-assembling test routines will drive you insane. So we set the emulator aside and upgrade our Typist's Assembler for the 65C02 for the 65816. As a nice side effect, we can replace some of the most confusing mnemonics (PEA becomes PHE.#), and there is none of this "LDA <$123456" or "LDA !$32" stuff.

A simple testing routine for the emulator in Typist's Assembler. Loop names get silly when the hours get long.

But wait, normal Forth syntax highlighting looks like crap in vim for assembler. So we set the assembler aside and write a vim syntax plugin for Typist's Assembler.

Code from the vim plugin for Typist's Assembler. I am not willing to discuss how much time I spent deciding which colors to use.

Back to the emulator? Not so fast, because we really should have a test suite for it. Because this is Forth, it is simply an add-on (accessed by INCLUDE CRUDETEST.FS after loading the emulator). Because I'm easily amused, we display the result of the test run in a matrix.

Early test run of the matrix of results from the test suite for the emulator. Note the complete lack of spoons.

After all of that, how far along is the emulator? In pre-ALPHA with maybe a third of the opcodes working. Since I went for the simple instructions first (duh), it's only going to get harder from here on out. In other words, this is going to take a while, quite possibly till the end of the year.

Still, we can dream. In the next entry, we'll get back to the overreaching design plans for the Übersquirrel Mark I and that bad Mass Effect joke I promised.

Friday, June 12, 2015

Hooking up with big sister: Switching to the 65816

In which our protagonist whines about getting sidetracked by ancient board games and dead Romans and then makes excuses for abandoning the very processor he claimed he loved so much.

I should probably explain why these entries are few and far between. Apart from the demands and joys of job, family, and house, life in the 21st century turns out to be really, really distracting. In the past weeks, I've rediscovered the game Go -- much more easy to learn with YouTube lectures than with books back in the 80s -- and lost far too much sleep reading The Swerve: How the World Became Modern by Stephen Greenblatt in two late-night sittings. All this means less time for the Übersquirrel.

However, one thing I decided very early with this project is that it is going to be long-term, escapist in the best sense, and not another contributor to my to-do-list. So, it's going to progress in fits and starts.

My latest fit is switching to a different processor.

Let's not pretend this isn't a biggie. The Übersquirrel started out because of my love of the 6502, and abandoning it seems cruel and unfair. However, Tali Forth has shown me that though you can do an amazing amount with a small processor, 64 KByte of memory are simply not enough. A few megabytes, now that should be fine for any system without a GUI.

Fortunately, we can have our cake and eat it, too, regardless of what GlaDOS says. The 6502 has a big sister, the 65816 8/16-bit hybrid CPU. Historically, it only saw brief use, because computer builders quickly switched to full 16- or 32-bit designs such as the 68000 that powered my beloved Atari ST. But while those chips have fallen by the wayside from an hobbyist's point of view, the 65816 is still in production -- and the last CPU standing wins.

The 65816, which really doesn't look much different than the 65c02. Photo by Anthony King, placed in the public domain

The main advantage of the 65816 from our point of view is its address space of 24 bits, giving us 16 MByte of RAM and/or ROM. Consider the memory problem solved. Transition from the eight bit world is easy because its big sister starts off in "emulation" mode which makes it pretend it is a 6502 (with minor differences). In the beginning, we can use our old software. Flipping a bit turns it into a 16 bit machine. That should make lots of things easier.

However, this is also where the problems start. As a hybrid processor, the 65816 is more complicated than a simple 16 bit CPU. For instance, you set the the accumulator (A) and index registers (X and Y) to be eight or 16 bits independently of each other. This means a simple command such as TAX -- transfer contents of the accumulator to the X register -- has four different cases:

A is 16 bit, X is 16 bit
A is 16 bit, X is 8 bit
A is 8 bit, X is 16 bit
A is 8 bit, X is 8 bit

The command itself is always the same: TAX. Remembering what width A, X, and Y have at any given time is one of the things that make programming the 65816 harder. Also, that nice 16 MByte memory range is split up into 256 64 KByte segments. On a more practical level, there is no free emulator for Linux available and fewer assemblers that for the 6502. We might have to write both ourselves.

Our breadboarded 6502 machine was the Übersquirrel Mark Zero, so this new project will be the Mark I. In the next entry, I'll be presenting the rough design of this computer, including a slightly radical step regarding the voltage, and a new horrible pun based on the Mass Effect universe.