Ruby816 – Build and initial booting

The last step of making my Ruby 6502 board was to fit a WDC 65C816 CPU. This involved some really minor changes to the PCB (literally one wire) and of-course all the existing software “just worked” in the ‘816 emulation mode (which is the boot default).

So with that in-mind, I decided to build a proper 65816 board with more RAM, but keeping the same ATmega 1284p host processor system I’d developed for the 6502 board. I went directly to PCB as I felt quite confident after my breadboard -> stripboard -> PCB progression with the 6502 board.

It didn’t quite work first time, but only because I’d made a small error in judgement to do with taking the main clock signal to the 2nd GAL. A single ‘bodge wire’ fixed that and it booted. It also ran perfectly well at 16Mhz, as does the Ruby6502 board.

Ruby 816

Ruby 816 board with the LED board

I then spent some time adapting the Ruby operating system (RubyOS) to the ‘816, although I’ve only so-far made some minor changes. I had to relocate some of the OS entry points to cater for the new hardware entry vectors and while I could re-assemble EhBASIC with the new vector entry points, it made some existing software (e.g. BBC BASIC) not work. It wasn’t hard for me to find and patch the OS calls inside BBC BASIC to make it work though and this now happens at BASIC launch time. I still have to run BBC BASIC in emulation mode but that’s not an issue for now. The BCPL ROM eluded me – it uses an indirection table for various OS entry points, so rather than a JSR on JMP it does something else, so a Plan B was hatched. More on this later…

The next step was getting to grips with programming the 65816. I have not really enjoyed this and personally, I think its no surprise that the chip didn’t do well back when it was launched in 1983. It may well be a 16-bit CPU, but accessing banks of 64KB with a mixture of instructions, some which will wrap into the next bank and some which wrap round to the same bank is quite confusing. At that time, the 32-bit M68000 was already well established as was the Intel 8086 so it was a tough market to crack and very few commercial systems were made then – the Acorn Communicator (1985), the Apple //gs (1986), and the Super Nintendo (1990).

In addition to learning the instruction set, switching the CPU from 8-bit to 16-bit modes (the accumulator and memory can be switched independently of the X and Y index registers), the assembler needs to know the mode you want so it can generate the correct opcodes and operands. The whole thing makes for a somewhat confusing experience.

However while not an insurmountable problem, still one that adds to the overall effort and of-course hindsight is what it is, and with that, starting today would I still make an ‘816 based SBC? I’m not sure. I love the 6502 but while the ‘816 has a 6502 inside it it’s not really a 6502, so who knows.