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.

Tuesday, March 31, 2015

They grow up so quickly: Tali Forth now in BETA

In which our protagonist claims a milestone for Tali and then sends the poor woman out into the big, evil world with nary a drone to defend herself.

At some point you just have to draw a line and get the thing out the door: I have designated Tali Forth, my small, simple Forth for the 65C02, as feature-complete, and so it is now officially in BETA.

This doesn't mean that it is even close to being finished, of course. Large parts haven't been tested beyond "it compiles", and don't even think of talking to me about optimization. But we've fooled around with software so long that it is time to get back to hardware. It's good enough for now.

[BETA actually began a few weeks ago, but I was off with the Inquisition in Thedas. Long story, involves dragons.]

So much has changed with the hardware by now that we're going to have to discuss everything in separate post. Until then, interested parties might want to read up on the SPI interface and the 65816 CPU. Megabytes, here we come!

Tuesday, January 6, 2015

My very own 65c02 assembler in Forth

In which our protagonist insists on writing his own assembler in a quirky language for a 30-year-old CPU and then makes everything worse by inventing his own syntax.

One of the things Forth traditionally excels at is assembler programming -- see Brad Rodriguez' BYO Assembler in Forth for more details on this. Since at some point I'm probably going to switch from the 65c02 to the more powerful 65816, which will likely involve writing my own assembler, I decided to give it a try.

The result is A Typist's 65c02 Assembler in Forth [GitHub], so named because I used the occasion to create a different syntax that doesn't have those annoying uppercase symbols like "$" and "(". In other words, it's more fun for ten-finger typists. See the introduction on for details. I've just started dogfooding larger programs, so it might be a while before that sort of code shows up here.

(If anybody is interested in assemblers as such, and why else would you be here, take a look at the free PDF version of Assemblers
and Loaders
by David Salomon.)

In the next entry, we will at least try to get back to our regular scheduled programming.