The 816 is really not a great processor. In some ways I'd rather just have an MMU bolted on the side rather then the uncomfortable way that the 816 makes 24-bits memory available.
The segmented architecture is one thing, but the painful way it was hacked into the instruction set is not at all enjoyable to code for.
a) You're constantly having to flip modes between 16 and 8 bit for various registers, and keep track of which mode you're in.
b) There's no register that can hold a full 24 bit address. So imagine doing bitmap graphics in, say, a 640x480 display when you can only directly address the first 64k of it before having to futz with segments.
c) The thing sucks to interface. Many people have solved this problem but having to demultiplex the bus is not fun, especially when the 65xx already does so much in a single cycle.
The 816 was a hack, but not a particularly brilliant one. It does add some nice things (relocatable base page, etc.), but the 6502's instruction set didn't really have room for doing it right. So they didn't.
This is very interesting. Thanks for the insight. You go into more depth than I've seen before.
Have you ever looked at the 65C832? It never made it to production but there are detailed specs and a datasheet; probably enough for someone to implement one on FPGA or something. I'm curious if it would have fixed some of the issues you report.
I have read about it, but never read the actual datasheet til now. In some ways it looks like it fixes some of the 816's problems in that there would be 32-bit accumulator and index registers, so you could put a full address and do pointer arithmetic in there etc.
But it still has the problem of futzing around between modes for the registers, modal instruction set... terrifying. And the program counter is still inexplicably 16-bits, so have fun writing a compiler for programs bigger than 64k, you have to manually manage the bank register when you move between banks.
And looks like direct page and stack still stuck in the bottom bank? At least I think I read that?
And for god's sake, why multiplex the databus still, like the 816?! Why wouldn't they just make a 64-pin DIP version like Motorola did with the 68000?
Anyways, it never made it to production. But basically looks like an 816 x 2, which isn't terrible in that having double the size on those registers makes doing a lot of things a lot easier.
A '816 would indeed be much better suited to access 512K of banked memory rather than banking through an 8K window but perhaps they don't think 65816 counts as retro enough, or maybe they're just masochists
I briefly somewhat followed this project until it became obvious it was going a direction I wasn't interested in. Originally they were going to use a 65816 but then switched to the 6502. I believe it had to do with the increased complexity of implemention caused by the 65816 sharing data and address lines which requires the lines to be multiplexed.
Part of the decision was that there aren't as many good tools available to compile/assemble/disassemble. Also, the length of some instructions depends on the current state of flags in the processor, which is a pain for disassembly.
It's not segmented, it's banked. And due to instructions that can use far pointers, you can directly access the entire memory. The main annoying part for me is that the stack and zero page are stuck within the first bank, limiting usability for a multitasking system.
Can't you still have 128 tasks even without sharing pages between tasks? That is, one direct page and one stack page for each task, with 256 pages total in bank 0.
With sharing I mean, when you have two or more tasks of which only one instance will run, they can use the same direct page. Similar if you can statically limit the stack size of the tasks to a fraction of 256 bytes, you can fit multiple stacks on the same page with some work.
Said far pointers are only for certain instructions, and there's no register which can hold a full 24-bit address, so there's always a bunch of hassle when dealing with addresses. They should have added a "pointer" register, which could hold both a 16 bit value and a bank value.
Program counter is 16 bit, with a separate bank byte; it'll wrap when it hits the bank boundary.
Constantly having to flip between register modes is a hassle. And makes it very difficult to write compilers and high level languages. Many common patterns require flipping back and forth a few times.
Either they needed to have a whole new set of addressing modes, or they should have just added 3 new registers -- 16 bit versions of X Y and A -- and let the two co-exist.
Honestly, this is an era when a 68000 could be had with a full 16 register set of 32-bit registers. The 65816 doesn't look so hot in that light, though it certainly was faster at interrupt handling.
I guess Nintendo made do with their modified 816, but it really is not a nice architecture.
