I had a thought... It seems feasible to create a 16- or 32- bit core that is closely compatible with the 6502 instruction stream. Let's consider a 16-bit variant for this discussion.

The registers are 16-bit wide. Instructions are 16 bits; if the upper 8 bits are 0, the instruction set is directly compatible with the 6502 (or the 65C02 perhaps). 8-bit 6502 code is loaded (by a loader) a byte at a time and stored a word at a time (zero-extend instructions and sign-extend data). 8 and 16-bit instructions can be freely mixed.

The high byte is used to extend the instruction set to 16 bits. In 6502 mode (the mode is on per-instruction basis anyway) the carry flag is really bit 8 and the zero flag is for the low 8 bits of the operation. In 16-bit mode (high byte != 0), the instruction set is fully 16 bits and the flags are adjusted accordingly (or we can add 'extended' c and z flags).

Addresses can be 32 bits using the extra 2 bytes.

I kind of like this arrangement, although I am sure there are some situations where it might cause issues. It seems too obvious to be novel - has there been a previous discussion? I don't think I am describing 65Org16 - I am thinking of compatibility first. The low 64K words (or perhaps low 32K and high 32K if addresses are sign-extended) should closely mimic the 6502 space, and 6502 code (properly expanded) should just run.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Thinking a bit more...

The instruction set space is basically constrained to the 6502/65C02. The high byte can generally modify the instruction to select from a set of accumulators and index registers, where that makes sense.

Accumulator 0 may be fixed as an 8-bit accumulator (and encoded as 0); selecting another accumulator makes it a 16 bit instruction... Same with index registers.

Zero page instructions can address 64K.

Branches can go +/-32K.

For shifts, the upper byte may be used for multi-byte shifts.

Unused instruction slots may be used for more interesting instructions such as multiply, etc.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

It is indeed a little different from 65Org16. That machine is word-addressed, and so any read or write is always 16 bits. Sounds like your machine would be byte-addressed. Your data bus might be 16 bits wide, or it might be 8... if it's 8, that means the core takes 2 cycles to transfer each 16-bit word. If it's 16, that means you have to decide whether all word accesses must be word-aligned, or not.

But if you allow yourself a word-addressed machine, what you have is an extension of the 65Org16. The original (simplest) variation just ignores the top 8 bits of each instruction, whereas you have ideas to make use of that. That's a perfectly reasonable thing to do, and there are many many different ways of approaching it.

The 65Org16 can talk to 8-bit peripherals, of course, in which case the high byte is ignored (for a write) or undefined (for a read.) To load data, I've always done it by sending pairs of bytes in the obvious way. To send a byte stream and have it implicitly zero-extended or sign-extended might well be possible, but might not be very simple. Did you mean to do that data expansion in hardware or in software?

Cheers
Ed

If I understand it correctly, the difference between this and 65Org16 is that it still allows 8-bit data transfers. So, you can have a 16 bit data bus in hardware, with 16-bit operations (I would recommend only allowing aligned access for simplicity). But in addition, you have 8 bit instructions that can access 8-bit chunks. So you could do INC $01, and increment the upper byte of the first word.

To clarify, it is basically a 16-bit machine. But if the upper byte of an instruction is 0, it performs operates on the low byte. You can think of it as a 6502 with 16-bit memory with only the low 8 bits in use... Does this make sense?

It is very close to 'org16. The memory is 16 bits wide. However the accumulator/index registers selected by index 0 (resulting in a 0 upper byte) operate on the low byte only.

So the databus is 16-bit and there is no way to operate on the high byte except as part of a 16-bit operation. Or you can treat it as a 6502 with 64K. In fact you can run 8-bit code in the low 64K words, and have a 16-bit OS around it.

INC 01 would increment the first word. I think it doesn't matter if it's in 16 bit mode or 8 bit mode, the entire word can be incremented. Two distinct carry flags are maintained simultaneously. If the next instruction is an 8 bit BCS, the 8-bit carry flag is used (from the 9th bit), otherwise, the 16-bit carry (from the 17th).

A more pertinent instruction is ROR. In 8-bit mode it pulls in bit 8 from the carry, in 16-bit mode it gets bit 16 from the 16-bit carry. Some instructions just do the same thing in both modes and the high byte is just not relevant in 8 bit mode.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Why not use odd addresses to access high byte only ? It would make it more powerful (and increase compatibility with old 6502 code), and it's not that much harder to implement.

I kind of like the clarity of the 16 bit operation, a 16-bit bus, and some legacy opcodes working with the low 8 bits. Otherwise it gets really confusing.

With 8 bit instructions you get a contiguous byte space as the processor ignores the high 8 bits.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

What I'm proposing is basically how the ARM7 does it. You have a 32 bit bus, 32 bit instructions, and 32 bit data, but even though the memory is physically 32 bit wide, the logical memory addressing is done in 8-bit bytes. So, first word is at address 0, and second word is at address 4. The 32-bit instructions can only do whole, 32-bit aligned, words, but there are some 8 bit LDRB/STRB instructions that can access any of the individual bytes.

So, you still have a contiguous byte space, but without the holes. I've never found it particularly confusing.

While this is doable I don't like it.

I like the symmetry of what I proposed much more. I like the hidden bytes quietly extending the processor, clean 16-bit fetching, the same 6502 decoder (pretty much), not worrying about alignment.

There are two different ways to work the modes. One is to have A, X and Y as 8-bit registers and have the rest (5 or 13) be 16-bit. A,X,and Y should really sign-extend to 16 bits so they can be in the mix in 16-bit operations.

The other is to have mode bits somewhere in the instruction that tap the registers at 8 bits (you can even mix - 16 bit A and 8-bit x). Then we can stay with the same instruction set, even keep the assembly language intact and use capitalization to indicate register size. I like this option - but it needs more thought. 6502 works pretty well without all those registers (which must be stacked all the time). And we still have a 64K zero page.

P.S.I don't like the ARM architecture that much, to be honest.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

I guess what I like the most is the ability to cleanly virtualize a 6502 in a 16 (or 32) bit environment. I suppose having extra registers in 16-bit mode is nice.

Does anyone have a clean 65org16 'starting point' code? I don't have much time to work on this yet, but it would be fun to mess around.

Is the original 65org16 here https://github.com/BigEd/verilog-6502 what I want?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Hi enso, yes that's the minimal and furthest upstream version of 65Org16.
Cheers
Ed