6502.org

For VBR's original question - what small delta would you make to 65c02 - I'd start with the '816's B accumulator, and then I'd take some other goodies from the '816. I'd prefer separate opcodes for 16-bit operations, if there were any. I don't much like the modes.

Relocatable code would be good, so I'd throw in BSR for a relative subroutine call, and I'd allow 16-bit offsets for that and for branches. Stack relative sounds good too. Where this fits in the opcode map I don't know: perhaps I'd allow myself prefix bytes.

I'd probably want to sneak in an 8x8 multiply, if I could afford it.

Considering Garth's larger scale suggestions, I'd want to focus on what the implementation might be. If it's to fit a processor into a 40-pin or 44-pin programmable part, then memory will be external and there's not much room for wider address or data. If it's to embed inside a huge FPGA, memory might be internal and efficient use of it would be important. But pincount wouldn't matter.

If you're not thinking of some particular implementation, a paper sketch or an emulation has no limits to what you can throw in. Arguably one of the ARM's original weak spots for implementation was such a rich instruction set that the register file needs an immoderate number of ports. (In fact thinking of the ARM as a reinvented 32-bit 6502 isn't a bad model, if you look at the history.)

The 6502 should be just about implementable in a cheap part which can be put on a breadboard, so I'd go for that first and then add some minor tweaks.

I'd probably throw out some compatibility and try for fewer unused bus cycles, on the guess that memory access will limit performance. A wider data bus could improve performance but you'd need a careful approach for I/O devices. I'd like to consider a 16-bit data bus with byte enables, faithful to byte-addressable memory, but able to do twice as much per access in the best case. (But have I got the extra pins?) A single RAM chip is attractive, otherwise why not a 32-bit data bus, and go for an 84-pin part.

Overall, as a matter of personal preference, I'm thinking small scale single-CPLD incremental improvements, rather than a 32-bit re-architecting.

A "B" register isn't a bad idea. Could be used for temporary storage and as an implicit source for new arithmetic instructions (A = A op B)
Yeah, the 65CE02 had that.
That's why I like the idea of a stack-relative mode; it conserves opcode space. If you are using a locals-oriented programming style (or a C compiler), you would set the mode and leave it set. If using a globals-oriented style, you would use it rarely, if at all.

Interesting - I must have seen the 65CE02 mentioned here but I never looked into it. I'll have a read of the datasheet - it might be that it's quite close to my ideal upgrade (for a home built re-implementation pipedream!)

Some time ago I see Garth said "There were not very many 65CE02's made, and the '816 was a much better upgrade to the 65c02 than the CE02 was, so I'm glad to have that." I'm in broad agreement in that I can buy an '816, but I wouldn't want to try to implement it.

The B register is handy though: XAB/XAB feels better than PHA/PLA. But saving everything in an interrupt handler is painful in the 816 - I'd be tempted to propose a push everything / pull everything. It's a problem when adding registers or making them wider, with only an 8bit data bus.

The only reason I can think of offhand that the '816 can't be in 16-bit mode for both A and index registers full-time is that reading or writing them will take two consecutive addresses since the data bus is only 8-bit, which sometimes will give unwanted results. But along the same lines:

On the 6502, I've addressed 4-bit I/O devices too (actually an RTC) and even 1-bit (actually just a flip-flop); and addressing these with an 8-bit bus was no problem. Having a 6522 on a 32-bit bus simply means 24 of the bus bits don't get connected, as I mentioned before.


The '816 isn't perfect for relocatable code, but it is orders of magnitude better for it than the 6502 is. On the 6502, if a program gets moved after it's already loaded and running (which probably won't happen without multitasking), JSR (and BRK, if you even want to count that) is the only way to get the PC (as it puts it on the stack) to add or subtract an offset for long-relative branching or data access. I wrote some routines to try relocatable code, and while the program part of it wasn't so bad (because you don't branch or jump that often), the big killer was the constant access to variables or I/O-- and that definitely killed the idea. If the PC and all other registers are all the same size (my preference being 32-bit) and in a set of registers as I proposed earlier, the PC becomes just as accessible as the rest.


The '816 puts all the stack-relative op codes in column 3.

I was thinking more like an 84-pin, in order to get 32 address bits, 32 data bits, and the other signals. Oh, I see you got to that:

RAM chips and modules also come in 2- and 4-byte-wide data buses.

If you really only want an upgrade to the '02 and only plan to use the first 64K of memory space, keep in mind that you don't have to latch, decode, or use the high address byte on the '816 (ie, you can totally ignore that it even exists), and you don't ever have to change or save the bank registers. So in that situation the '816 has none of the drawbacks that people think it does. You could even leave A, X, and Y in 8-bit mode all the time and still take advantage of a lot of new instructions and addressing modes, movable zero page, much deeper stack space, etc.. Hmmm... I suppose you could even use the bank registers as extra registers for temprorary storage if your hardware ignores A16-A23.

The outer interrupt handler in my '816 Forth consists of:

Really quite painless. ACCUM_16 is just a one-line macro that assembles REP #00100000B, but it is much more clear to humans that it's putting the accumulator into 16-bit mode.

I was thinking it might be good if LDA toggled between A and B. As in:

lda #1 ; A = 1, B = ?
lda #2 ; A = 2, B = 1
lda #3 ; A = 3, B = 2

The advantage is that you don't need an LDB instruction.

An on-chip register stack? See the transputer and Forth Chips

One of the implementation points to look out for is the complexity of the processor handling interrupts. It looks like the 65CE02 doesn't take interrupts between single-cycle instructions. That'll be a consequence of the more aggressive pipeline, I think.

I think the 6502 and perhaps the 65816 are both architected around the time cost of an 8-bit addition: hence the extra cycle for crossing page boundaries. These days we can probably do a 32-bit addition in the time it takes for one memory access, if we stick to small static-RAM memory. DRAM modules are another question: I think the memory controller alone could quickly become more complex than an original 6502.

Edit: spello

I would like to see more speed. Even if no new instructions or add-ons. Just RAM/EEprom with the CPU on a single die, and 100+ MHz.

Going on the issue of "toggling",

How do you know which accumulator LDA affects? What if some code branches to the above code, and the "phase" is reversed from expectation?

You always want CPU instructions to be as explicit as possible. RISC has taught us as much. Functional reconstitution of assembly language code, a method instrumental in figuring out just what the heck some inscrutible code actually does, depends heavily on it. Having a LDA and LDB is overwhelmingly more preferable to random guesswork.

Thankfully, what you illustrated above is not toggling, but rather is clearly a "data stack" in the Forth processor parlance. You have, simply, a 2-deep stack.

However, this, too, yields quite the problem too -- of what value is B when it's always being overwritten by the implicit-DUP with each LDA? I can think of numerous, and very frequently executed, code sequences where you want B's value to remain constant as you load another value into A for processing.

In either case, I must shoot these ideas down as impractical for the 6502's architecture.

If you want a genuine stack architecture, you just plain have to design the CPU, from the get-go, to support stack operations.

Garth: perhaps a new forum for the 65Org32 on here? That way, the various subjects can have their own threads, such as basic architecture, real world interfacing, opcodes, VHDL design, etc.

Yup on the emulation of the 6502 though it would kill cycle counts UNLESS the emulator is designed to throw in delay loops from a table for the various instructions, to try and emulate the timing. I am not sure how MAME handles the 6502 cycling, but they have a C core that seems to work out fairly well for arcade graphics.

Memory controller: maybe a small controller circuit portion that can be updated when required?

also on the data, a friend had used a command in his game design called PackBytes and UnpackBytes. Perhaps an assembler macro to sort into 4 8 bytes in a row kind of deal? this way, you do not have to encode as a new instruction or bitwise mode. There is a definite simplicity in keeping it all in 32 wide mode.





PS: you are NOT monopolizing, you got a lot of ideas towards this wich will form a solid base for the design....

Assuming you're reading from/writing to RAM, this is a non-issue.

The reason you don't always want to sit in 16-bit mode is simply the issue of carry-over. Manipulating a series of 8-bit bytes (not always strings, mind you) as such is not only faster, but completely eliminates the issue of stray carry over.

For example, working with graphics data is a common case. Imagine you're blitting a mouse pointer image a few pixels to the left or right. Since the mouse image is typically a 16x16 bitmap, you need a multi-precision shift. PROBLEM: nearly ALL graphics chips shift MSB first, not LSB, and are big-endian, since it yields the simplest possible logical mapping of bits to pixels on the screen. However, the CPU's shift/rotate instructions assume the opposite bit and byte ordering -- thus, using ROR/ROL/LSL/ASR on a word-sized piece of byte-sized bitmap data will result in garbage graphics!!
Not necessarily. Assuming your 32-bit CPU has byte-addressing capability, that 32-bit bus will also have 4 byte-enable lines, which can also contribute to the address decoding logic. Thus, it's possible to interleave your 6522s so that all port As are adjacent in memory, all port Bs are adjacent, etc. If you're ganging multiple 6522s to emulate a "wider 16- or 32-bit I/O chip," this can be a useful technique.
Even with multitasking, the image stays fixed in RAM. The Amiga demonstrated an excellent solution -- include address fixup meta-data in your binary loader format, so that the loader can repair broken operands. This allows you to assemble your code to a fixed virtual address ($00000000 in the case of AmigaOS; I believe $00000100 for Atari TOS), while the OS is capable of relocating the image upon load-time. Once loaded, of course, it's fixed in RAM.

However, through careful design, you can dynamically relocate code and statically known addresses for data and variables (but not data allocated at run-time!) by simply traversing the relocation metadata after moving the code chunk.

There's no difference between an exchange of A and B, followed by LDA, and a transfer from A to B, followed by LDA.
Say you want to add a multiply operation...

lda operand1
lda operand2
mul ; A*B
Without the implicit XAB (exchange A and B), you would need more explicit XAB instructions.

I know. You misunderstood what I wrote.
I'm intimately familiar with stack processors and the Forth language, having designed CPUs and implementations of the language in the past.

The problem is not with that you're advocating a stack. The problem is that the rest of the CPU utilizes all explicit operations, registers, etc. (Contrary to popular belief, "implicit" register operands are still explicit, since the use of those registers is still an explicit part of that instruction's mathematical semantics.)

When I see LDA, I see this as Load Accumulator. Of which there are two. I cannot look at any single LDA and determine what its effects are. Saying "A goes to B" is only partially correct; the ambiguity happens when you don't know what A had originally, thus you no longer know what is in B, and yet, is vital to debugging the program. When dealing with a register-oriented architecture, of which the 6502 is a degenerate instance of, this situation happens all too often.

The fix for this is to have a separate instruction. LDA touches A, and only A. To get the stack effects you are looking for, use a new instruction, such as LAS -- Load Accumulator Stack. The fact that this is a whole new instruction means that the semantics are unambiguous, and provides a ready indicator to the code reviewer that additional context is needed to determine the value of B.

In all honesty, though, implementing LAS won't offer a significant time advantage to XBA/LDA, since the 6502 has only a single bus inside it. Far more important to mee are instructions that add (and/or subtract) immediate values to X, Y, and S.

Without this facility, even implementations of Forth spend unnecessary amounts of time tweaking the registers instead of executing the user's program.
On a register machine, this is actually an advantage, not a disadvantage, as it greatly simplifies the internal design of the CPU (read, runs at lower power, has fewer transistors, can run at higher clock frequencies, etc). Also, you'll find that XAB would occur only around those instructions that actually use the B register.

I've been coding 65816 software for several years, and I've used the B register exactly once, in the middle of a graphics blit routine. Most other uses were far more easily expressed using direct page in 16-bit native mode.

But, like I said earlier, on a dedicated stack architecture, where the CPU is expressly built for such a mode of operation, the rules change.

You don't have to physically move data from one register to another; you can just rename the accumulator. That's why I used the word "toggle", because I thought of it as a renaming.
Indeed, having worked on the cc65 compiler I'm aware of how painful stack operations are.
Personally I don't see a huge difference between an accumulator CPU and a stack CPU. They are close cousins in my view.