Commander X16

It's probably better to just start a thread about it already.

The current X16 Gen 1 is a 6502 (W65C02S) just like it's always been, but there's talks of a possibility that Gen 2 and beyond would use a 65816 (W65C816S) instead, leading to some recent advice to avoid using '02 opcodes that are unavailable on the '816, namely BBR, BBS, RMB, SMB, TRB, and TSB, and that all hardware would need to be '816 compatible, as well as the Kernal supporting '816 native mode as well as '02 emulation mode and actual '02 CPUs.

My questions would be, given a hypothetical X16 running a 65816, would the address map be any different from what the 6502 sees (and if so, what should we know)? And, does it look like there'd be a viable upgrade path for Gen 1'ers to upgrade to a 65816?


(As a note, I'm personally planning to stick to 6502 for now, but with the knowledge that it might eventually be a 65816 in the future, so I'm reading up on the '816 since I'm not nearly as familiar with it as I am the '02.)

DragWx wrote: ↑Wed Feb 14, 2024 6:52 pm My questions would be, given a hypothetical X16 running a 65816, would the address map be any different from what the 6502 sees (and if so, what should we know)? And, does it look like there'd be a viable upgrade path for Gen 1'ers to upgrade to a 65816?

For now, the plan seems to be to simply replace the CPU with the 65816. No changes to the banking system or memory map would be made.

Gen 1 users can simply... plug in the new CPU. There are no other hardware changes necessary.

DragWx wrote: ↑Wed Feb 14, 2024 6:52 pm ... My questions would be, given a hypothetical X16 running a 65816, would the address map be any different from what the 6502 sees (and if so, what should we know)? And, does it look like there'd be a viable upgrade path for Gen 1'ers to upgrade to a 65816? ...

If a 65C02 board is going to be made to be compatible with plugging in a 65816, it needs to have a pull-up resister on a rarely used output line on the 65C02 that is an input on the 65C816 that can interrupt operation if it is allowed to float low. Also there are some aspects of how select lines and bus states work together that are advised to be handled in a particular way for 65C02 but required for the 65C816, to avoid contention for the data bus during the first phase of the clock cycle.

The people that put the X16 board together were well aware of these, and it seems like they took them into account when designing the board, so for the X16, it's mostly about compatibility on the software side. Two particular issues are (1) not using four 65C02 bit-specific instructions that have 32 opcodes (4 instructions times 8 possible bit locations), since the 65816 uses those 32 opcodes for the bulk of it's new instructions & new address modes and (2) processing interrupts properly when they occur when the 65816 is in "native" mode rather than in "emulation" mode.

Thanks for the clarifications.

About native mode interrupts needing to be handled properly, what does that mean exactly? I see in the datasheet that there's separate vectors for native mode and emulation mode interrupts, and native mode pushes/pulls one more byte (PBR) to the stack than emulation mode, and programmers should always RTI in the same mode the interrupt started in. Is that it or is there more?

DragWx wrote: ↑Wed Feb 14, 2024 9:15 pm Thanks for the clarifications.

About native mode interrupts needing to be handled properly, what does that mean exactly? I see in the datasheet that there's separate vectors for native mode and emulation mode interrupts, and native mode pushes/pulls one more byte (PBR) to the stack than emulation mode, and programmers should always RTI in the same mode the interrupt started in. Is that it or is there more?

Lots of chat today about that on the Discord. There are indeed separate vectors and making those work is most of what's being done. This involves some non-trivial ROM changes, some of which will be of benefit even for the 65C02 it would appear as there were some code size improvements that seem to be made. This is important because the bank 0 of ROM is really tight on space so every byte counts.

For the most up to date info, I think #cpu-65816 on the Discord is probably the space you'll want to watch. There's rapid movement where trying to do that over a forum wouldn't be so easy though you will be seeing various attempts and proposed solutions some of which may or may not end up being the final solution. I'm sure the conclusions will end up on the forums and elsewhere if/once David and Kevin make an official decision. At present, even with the above changes, the official CPU for the X16 is still the 65C02. I suspect though if the ROM changes make the 816 viable, it will become an official upgrade option given no hardware changes would be required. Just be mindful to avoid those 4 instructions.

Some other places to keep track of the convo would be:

https://github.com/X16Community/x16-doc ... ocessor.md
https://github.com/X16Community/faq/blo ... %20Path.md

DragWx wrote: ↑Wed Feb 14, 2024 9:15 pm Thanks for the clarifications.

About native mode interrupts needing to be handled properly, what does that mean exactly? I see in the datasheet that there's separate vectors for native mode and emulation mode interrupts, and native mode pushes/pulls one more byte (PBR) to the stack than emulation mode, and programmers should always RTI in the same mode the interrupt started in. Is that it or is there more?

AFAIU, the native mode vectors are actually in the middle of the CBM KERNEL jump table, which is where clever programming was required to square that circle.

And, yes, you do need to RTI in the same mode, otherwise there is a change in CPU operating mode in the middle of executing the routine that was executed. That is, after all, why a separate bank of vectors are required, so the routine that is executed can be written for the operating mode in place when it was called and to which it will have to return. Often those are bridge routines on one side, that switches to the other mode, calls an appropriate routine, then on return switches back and RTI.

I'm not familiar with the 65816. As a regular user, what advantages, if any, would there be to upgrading?

This is something that should have been decided four years ago, not as we are shipping. It requires changes to the Kernal and forces changes to the whole software base. There's a bunch of commands we can't use anymore, all our interrupt routines have to change, what else?

I can't understand why this is even being considered at this late date. If we were going to use the 816 then we should have been using it right from the start.

Heya Ed,

Which commands are you referring to exactly? I've been testing by apps on real C02's and 816's for compatibility. I was among the (seemingly few) that got burned by using the 4 instructions not available on the 816 (SMBx, RMBx, etc.) but beyond that, I'm unaware of any compatibility issue that would even require recompiling software and I haven't run into any myself. There may be some subtle timing differences between the CPUs which can't be mitigated however. I haven't knowingly run into those. But if you know of commands that are indeed breaking, and have tested them, I think it'd be good send that over to the folks working on the 816 support. They would surely need to know about it.

The KERNAL modifications are being careful scrutinized to avoid breaking existing applications.

ROM upgrades may be required but the ROM is changing all the time anyway as new built-in apps are being added and KERNAL bugs are being fixed such that keeping the ROM up to date would be a wise decision either way.

All that said though, the 816 situation is best described here: https://github.com/X16Community/faq/blo ... %20Path.md

(That may address your questions as well, mortarm)

Since the time that was written, the dominant solution, by far, seems to be software only changes, precisely for the reasons above (no changes to most apps, no hardware changes, etc.). But, at it stands today *X16 is a 65C02 based computer* and that hasn't changed, at least not at present.

mortarm wrote: ↑Thu Feb 15, 2024 3:54 pm I'm not familiar with the 65816. As a regular user, what advantages, if any, would there be to upgrading?

As an ordinary non-developer:
You get to run software that says "this only runs on a 65816" or whatever our colloquial term for a 65816-powered X16 is going to be ("Super X16"? ).


Programming wise:
The 65816 gives you actual 16-bit operations, which means one opcode can handle loading two bytes of memory into a 16-bit accumulator, and you can do actual 16-bit math on that accumulator.

Indexed memory access (e.g., LDA $nnnn,X) can use a 16-bit index so you can have more than 256 bytes in a single table (for example).

The stack pointer is a full 16 bits, which means the CPU stack can be located anywhere in memory, not just $01xx, and I'm assuming that means the stack can hold more than 256 bytes.

Instead of zeropage addressing, you have "direct" addressing, which is just like zeropage except you can move around to anywhere you want.

One of the biggest advantages of the 65816 which is sadly unavailable on the X16 is its ability to address up to 16 MB of memory. The way it works is, you have two "bank select" registers: one used when the CPU is reading opcodes and arguments (PBR) and one used when the program is accessing memory (DBR), so for example, instead of needing to write to a memory address to switch banks, you use an opcode to load PBR or DBR with the desired bank number, and you can have the program running in one bank and have it manipulate memory in a different bank at the same time.

On the X16, the A16..A23 output from the 65816 is ignored, so you still see the same memory map that a 6502 sees (regardless of PBR and DBR), complete with the bankswitching regions and the memory-mapped bank select registers at $0000 and $0001.

Edit: There's also a "block move" command but I haven't looked into how it works just yet. I imagine it just copies a chunk of memory from one location to another with just one opcode.