The 65816 as the basis for a virtual 16 bit CPU ("65V16")

[scotws]

So the thread about how "yucky" the 65816 (and broccoli) is got me thinking: If the problem with this chip is its complexity, maybe we could use an assembler/compiler to create a simpler, cleaner virtual 16 bit CPU on top of it -- a "65V16". Completely hide emulation mode, get rid of decimal mode, make X and Y full-time 16 bit registers, make 16 bit C the default, but expose A and B as ("slow") 8 bit registers. Make the memory seem like it is linear 16 Mb of RAM, with the exception of the reserved "Zero Bank" (so program memory starts at $01:0000). No more PBR or DBR! We would end up with something like this:

We give the C register all the modes we have for A (LDC, PHC, STC, TCX, etc), and reserve a few for A as 8 bit access for I/O chips (LDA, STA, PHA; even LBA, STB, PHB). We can keep an "expert mode" for direct entry of pure 65816 code, for instance for interrupt handling (more on that later). Other than that, those "yucky" details of the chip are hidden. No SEP, REP or XCE, for instance - mode switches are handled unter the hood. The Status Register as exposed to the user is shrunk down to N, V, I, Z, and C.

Obviously the resulting code would be slower, larger, and have less flexibility than native 65816 assembler. We lose the 1:1 of instruction and machine code. However, it would be a lot easier to work with and expecially to code, which means the programmer saves time unterstanding, writing, and debugging the code. I'm guessing that for a lot of us hobbyist types, less complexity might be worth a bit of bloat and slower execution: The limiting factor is the time we can spend at the keyboard.

There are some obvious problems with this scheme, starting with the fact that RESET dumps us in emulation mode again. An assembler/compiler would have to add some boilerplate code to make sure we get back to 16 bit land ASAP. Also, I'm not sure how you would go about converting the virtual linear memory addresses to the hardware segment model, but this can't be a new problem. And I'm sure there are other problems I haven't thought of. I don't think this could be handled with a simple single-pass assembler .

[BigDumbDinosaur]

scotws wrote:

So the thread about how "yucky" the 65816 (and broccoli) is got me thinking...

What happened to the status register? It would be pretty tough to do anything without SR to tell you what the MPU is doing.

As for getting rid of decimal mode, that would automatically cause me to lose interest.

[BigEd]

I quite like this idea. It reminds me of the idea that C++ can be a real handful but there are useful subsets which improve productivity. Same for JavaScript.

It's also a kind of flip side to buying an '816 and only using it in 6502 mode.

[scotws]

BigDumbDinosaur wrote:

As for getting rid of decimal mode, that would automatically cause me to lose interest.

Having just spent three days figuring out decimal mode for ADC and SBC on my 65816 emulator in 8 and 16 bit (and still not getting N,Z, and V quite right in every case), I'm inclined to see the whole mode in Lovecraftian terms at the moment. Just what does one use this for in real life? I see the NES got along without it perfectly well.

[BigEd]

BCD is good for cash registers and vending machines... and some games use it for high scores. It's certainly no better for floating point, unless you're making a calculator.

But it's true, it's a pig for emulation, and very difficult to get it exactly right. I left it out of my a6502, and the 65Org16.

[Arlet]

BCD is useful for running existing programs. For new software, it's easy to do without. BCD is really only useful when displaying numbers to humans. But since human perception is slow anyway, we may as well use a binary implementation, and a slow(ish) conversion routine to display format. Besides, the 6502/65816 only has BCD forms of add/subtract, and not multiply, divide or any other mathematical functions, so it's usefulness is even more limited.

[BigDumbDinosaur]

scotws wrote:

Having just spent three days figuring out decimal mode for ADC and SBC on my 65816 emulator in 8 and 16 bit (and still not getting N,Z, and V quite right in every case), I'm inclined to see the whole mode in Lovecraftian terms at the moment. Just what does one use this for in real life? I see the NES got along without it perfectly well.

I use BCD for binary to decimal conversion, among other things. Plus it's a good choice for arithmetic in which the inevitable ASCII-binary rounding errors can't be tolerated. Many real-time clocks store and report the date and time in BCD. It's got lots of uses.

[barrym95838]

scotws wrote:

... I'm inclined to see the whole mode in Lovecraftian terms at the moment ...

Bruce's new article goes into exquisite detail of the many idiosyncrasies of the '816. I'm link-challenged at the moment, but I'll edit it in when I find it. "Lovecraftian" seems like an excellent choice of adjective for me as well, with all the wrap/don't-wrap and truncate stuff.

Is it worth the effort for some? Definitely. Is it worth it for me? Probably not.

Mike B.

[Update: http://6502.org/tutorials/65c816opcodes.html
]

[Alienthe]

Broccoli requires delicate handling. If you boil it until it changes colour into a green-yellow tinge you have overdone it. It should remain dark green and be a little crispy, or "al dente". Alternatively you can stir fry it - fast and efficient.

I should perhaps make some witty comments on boiling or stir frying your virtual machine but I cannot find the energy. While the idea is interesting (virtual machine, not stir frying) I wonder which direction do you want to go: an abstract machine like Parrot, JVM etc. or an abstraction for more expressive and compact coding such as SWEET-16? I'd aim for the latter as the former would be cramped in 64KB memory.

Your design seems inspired by 6809, so why not go in that direction? Or a 6309 for added registers where the registers are reused with SWEET-16? 6502 is good at 8 bit handling. SWEET-16 is good at 16 bit pointers. That leaves an opening for 16 bit arithmetic.

[scotws]

barrym95838 wrote:

Is it worth the effort for some? Definitely. Is it worth it for me? Probably not.

At this point, it's simply too late to quit . I have about six more opcodes and a bit of interrupt stuff before I can declare it ALPHA, so I might as well finish it now.

[scotws]

Alienthe wrote:

I wonder which direction do you want to go: an abstract machine like Parrot, JVM etc. or an abstraction for more expressive and compact coding such as SWEET-16?

I honestly have no idea yet, this sort of just popped into my head: Why not hide that complexity? I'll have to think about it some more next time I standing in line waiting somewhere.

@BDD, sorry, I just realize I hadn't answered your question: P byte is still there, with the NZVIC flags, but not M or X, and maybe not D (though your objection is noted, so I'm going to leave that open till I have a more clear idea of what this would be). Just forgot it in the graphic.

[Rob Finch]

Quote:

P byte is still there, with the NZVIC flags, but not M or X, and maybe not D (

The D,X and M bits in the status register could be viewed as a kludgy way of extending the instruction register. With a virtual machine why not go the way of other designs and just include additional instructions rather than these control flags ?

[Dr Jefyll]

Rob Finch wrote:

The D,X and M bits in the status register could be viewed as a kludgy way of extending the instruction register. With a virtual machine why not go the way of other designs and just include additional instructions rather than these control flags ?

Good idea, but I think Scot's goal was to eliminate the extra functionality so as to achieve a simpler, easier-to-understand machine.

Maybe I'm missing something, but it seems the goal could be largely achieved just by inhibiting and then ignoring stuff like Decimal Mode, Emulation Mode and 8-bit modes for index and memory. It would be nice to have 8-bit operations available for string handling, though... [Edit:] in the lead post he mentions exposing the 8 bit registers.

[scotws]

Dr Jefyll wrote:

Maybe I'm missing something, but it seems the goal could be largely achieved just by inhibiting and then ignoring stuff like Decimal Mode, Emulation Mode and 8-bit modes for index and memory.

That's sort of the idea. A lot of the instructions would be one-to-one, but with the processor stuck on native 16-bit mode, so you don't have to think about x and m and e and whatnot at all.

Actually, I'm wondering if the instruction set wouldn't be almost trivial compared with the problem of how to make the memory banks pretend to be one continuous address space. So far, all I can think of is assembling the code to the point where the bank is about to end, and then insert a bank switch. That pretty much kills the abiliity to use absolute addresses -- everything would have to be labels. Hmm.

[BigDumbDinosaur]

You would still need the ability to handle data eight bits at a time, especially in I/O. It's the relatively rare I/O device that accepts or dispenses data in multi-byte chunks.