6502.org

They list the manufacturer as "Western Digital."

There are tons of ways to represent Lisp internal objects, even when just sticking to cons cells. I've done a ton of pondering & taken plenty of notes in the past on exploring this space. Plus, I've been giving attention to AcheronVM trying to get the overhaul of it published, on top of which I certainly want to build GC, typed memory objects, and such.

What I would opt to do is have pages of homogeneous types, so you could check the first bytes of the page, or look up the pointer's high byte(s) in a table, to check the type of a pointer without making individual objects more complicated. At least from a 6502 perspective, there's tons of fun puzzles to solve in this space, and I think it's possible to have these sorts of features running "at scale". The '816 might just be cheating in comparison.

Thankyou, Andrew! I put it in the 65xx parts sources sticky topic head post.

The "quantity available" line indicates there are thousands, but it seems to be an item number instead. (The number is 2547 through 2551, consecutive, for the five speeds.)

I may use a 65C816 in my desk calculator, not because it *needs* one - I'm currently intending to only use 65C02 instructions - but because that makes it easier to reuse the design (and maybe spare PCBs) for something that requires more RAM later, and the price seems to be very similar.

The behaviour of VDA/VPA also seems cleaner to me than the "every cycle is an access" behaviour of the pure '02 bus, and opens the possibility of implementing a low-priority DMA system if I feel like a challenge.

The extended instruction set, though, is an absolute horror.

My only use of it has been with the C32 assembler, and I've liked it a lot; but after seeing how other assemblers deal with it, I can see why people might not like it.

Please explain.

Do we have a thread, or a reference, explaining the facilities and benefits of the '816 already? I feel we must have gone over this question quite a few times...

... certainly for me, my first reaction on learning of the '816 was joy, that here was a 16 bit extension to my my favourite micro. My second reaction was that the four-mode design makes things rather less accessible than I'd hoped. My third position was that all is well provided you set out to choose a mode and stick with it most of the time - different applications and different people will have different preferences as to how to set the M and X bits for 8 or 16 bit operations and 8 or 16 bit indexing. In any case, some specific routines might change modes to do some work: in a 16/16 setup, one might find string-handling routines switch to 16/8 mode.

The important thing with the 816 is surely the compatibility mode, and the familiar programming model. That is, compare it with the 6502 and it comes up looking pretty good. If instead you look at all the CPU architectures out there for your comparison, the 816 might come off as a bit clunky - that's the cost of the backward compatibility and the incremental design.

So, comparisons with 68000 or with ARM or any recent architecture are likely to come to unfavourable conclusions, especially if they disregard the other aspects of a system design, like memory width or glue complexity, or if they emphasise programming in a compiled high level language.

The basic ability to hook up lots of memory and use three-byte pointers is great. The moveable stack and direct page are very handy. The 16 bit operations are handy. Slightly less obvious, the stack-relative addressing can be handy. And so on.

Yep! It's deja vu all over again.
Exactly. One needs only to look at the x86 architecture and the baggage it drags around so some old 8086 programs can be run on x86-64 MPUs (if anyone is still running 1980s code on a contemporary PC). I still get headaches think about that segment:offset nonsense.

My principal objections to the '816 instruction set are the mode flags (which can affect instruction length as well as the amount of data accessed), and the fact that the address space is not *quite* linear in ways that are inconsistent across addressing modes. These warts increase the cognitive load of dealing with the extra capabilities, on a CPU family where getting useful work done efficiently already involves a lot of careful juggling.

By comparison the 65C02 is reasonably orthogonal and flat in its addressing, with the easily-remembered exceptions of the stack and zero-page. Granted, the '816's discontinuities occur at 64K boundaries, so some of the headaches basically go away if you ignore the extra address space, but…

We've had various topics on the '816, but here's something I don't remember any of them having addressed. Someone said they wished that instead of the M and X flags, it had separate op codes for 8- versus 16-bit operations, but IIRC, only mentioned loads and stores. That by itself would already require two-byte op codes since the table is full as it is; but the fact is that you'd have to have separate op codes also for any register or memory operation that affects the C, N, or V flags. ROR A for example, even though it does not involve memory, still needs to know whether to rotate the C flag into bit 7 or bit 15, also which bit to reflect in the N flag. INA and DEA, even though they do not involve memory, still need to know whether to operate on 8 or 16 bits, because if the accumulator is in 8-bit mode, it's actually two 8-bit registers, A and B, and you might be expecting data in B to be left undisturbed. PHA, PLA, PHX, PLX, PHY, and PLY (a different kind of load and store) could be made to always be 16 bits, but that would be more wasteful of memory and execution time.

There's more, but these should make the point. I have wished sometimes that Bill Mensch hadn't been required to make it backward compatible with the '02; but I think he did a great job given Apple's requirements.

Regarding the not-quite-linear address space, Samuel Falvo (forum name kc5tja), professional programmer, said the key is to make the banking work for you, not against you. Now that memory (even SRAM) is super cheap compared to what it cost back when the Apple IIGS was introduced, one could extend the 65816 design with 32-bit buses and all 32-bit registers (except maybe the status register which probably doesn't have any use for 32 bits); and then the program and data bank registers and direct-page register simply become offsets into the entire 4-gigaword address space, à la 65org32. If any of the 32-bit 65-family processor designs ever become reality, I expect Michael Barry's (forum name barrym95838) 65m32 might be the closest to it. His scheme is more efficient than the 65org32's but has less of the familiar 65 flavor.

Not sure I follow what you're saying here. I agree there's discontinuity in terms of code space. For example, when PC reaches $FFFF it wraps around to 0 without PBR getting incremented. That's disappointing, but only a minor downside, IMO.

On the upside we have the shining glory of the '816 -- specifically, that the data space is continuous! Those 3-byte pointers really work -- even with indexing applied. Example: using [d],y address mode, adding y to the 24-bit base address may result in a bank crossing. This event will execute successfully and transparently. The same is true with al,x mode (where the three-byte address is part of the instruction).

Unlike most schemes that "break the 64K barrier," the 816's three-byte pointers make it easy for the programmer to store and manipulate objects which...

• straddle bank boundaries and/or
• exceed 64K in size

-- Jeff

Looking into it, there *are* some limitations on '816 data addressing:

1: Stack relative addressing wraps around at 64K; the bank address generated is always zero. This effectively means you can't move the stack into high memory.

2: Direct Page register is 16 bits wide but aligned low, and the bank address generated is always zero (*not* taken from the DBR!) in direct or direct-indexed addressing modes, so it also wraps around at 64K and you can't use it as a fast shortcut into high memory.

3: The index registers are also only 16 bits wide, so you can't use them as fast universal address registers.

4: In Emulation mode there appear to be some odd behaviours if the DBR, PBR and/or DPR are non-zero. This is really just a warning to zero them before returning to Emulation mode.

This imposes some requirements on the hardware which could be considered inconvenient in some cases: you need ROM at $00FFxx for the reset vector, *and* RAM elsewhere in $00xxxx to use the stack and direct-page. Granted, there are ways to shadow a small ROM with a monolithic 16MB RAM.

Right, Bank 0 is a bit special for the '816 - some things live there. It's a kind of generalisation of the way Page 0 is special for the '02. If you want acres of unrestricted RAM, start looking at Bank 1 and onwards.

I picked up a couple of 65816s recently. I don't have a specific project in mind yet, but I'm toying with either taking the SBC I've been working on and hacking the 816 in, or designing a whole new board around them. The main things I'm interested in are the larger address space, the 16 bit index registers, and the stack relative address mode.

One of the software projects I've been playing with is a 6502 version of a (very simple) LISP interpreter. I can get it working on a 6502... it's actually very close now, but the code has to do so much work to follow all the references. Another language I think would be interesting to try to implement is Smalltalk, but I don't even want to think about trying to implement it in 8-bits.