Commander X16

I want to propose a new naming convention.

Commander X16: the current computer, shipping with the 65c02 CPU. Software labeled X16 may include commands exclusive to that chip: SMB, RMB, BBR, and BBS. These commands will not work on the 65816.

Commander 816: the upgraded system with the 65816 CPU. Software labeled 816 may include commands exclusive to that chip which will not work on the 65c02.

Commander X8: Software labeled X8 would only use the original 6502 instruction set, or would have two programs and would automatically choose the appropriate one, and thus would run on either processor. (Edited to change 8X to X8, which is better)

This naming convention would make it easy to classify software into 65c02 only, 65816 only, or either. It wouldn't tie assembly language programmers down to only using the common 6502 instruction set, and would let users quickly know if the software will run on their system.

Since the CPU can be swapped out by the user, having different model names wouldn't really work. As for software, the author would simply identify which type of system is needed, just like commercial software does.

While I like the idea of a naming convention, it's only really good if everyone follows it.

I haven't seen any code to do a check of which processor is on the board. Perhaps it warrants a simple ROM routine in the kernel, so not to be repeated/reinvented by each developer. Such a routine wouldn't be able to detect whether the application was only "base" 6502 instructions or include the 65C02 ones. Oh well....

Edmond D wrote: ↑Sat Apr 13, 2024 3:56 pm I haven't seen any code to do a check of which processor is on the board.

It's a very short piece of 65816 code:

CLC
SEP #$01

65c02 sees this as:

CLC
NOP #$01; two byte no op

If it's a 65c02, this will return carry clear, but if it's a 65816 on board it'll return carry set.

mortarm wrote: ↑Sat Apr 13, 2024 3:50 pm As for software, the author would simply identify which type of system is needed, just like commercial software does.

Yes, the proposal is for a consistent way to indicate which processor is needed, or whether it will work for both.

Ed Minchau wrote: ↑Sat Apr 13, 2024 5:03 pm

Edmond D wrote: ↑Sat Apr 13, 2024 3:56 pm I haven't seen any code to do a check of which processor is on the board.

It's a very short piece of 65816 code:

CLC
SEP #$01

65c02 sees this as:

CLC
NOP #$01; two byte no op

If it's a 65c02, this will return carry clear, but if it's a 65816 on board it'll return carry set.

Thanks - definitely not worth a ROM/kernel function.

I guess my follow up question would be how to place this code into a compiler that doesn't recognize the 65816 instructions.
I'll have to try it out and see how to address it.

Edmond D wrote: ↑Sat Apr 13, 2024 5:22 pm

Ed Minchau wrote: ↑Sat Apr 13, 2024 5:03 pm

Edmond D wrote: ↑Sat Apr 13, 2024 3:56 pm I haven't seen any code to do a check of which processor is on the board.

It's a very short piece of 65816 code:

CLC
SEP #$01

65c02 sees this as:

CLC
NOP #$01; two byte no op

If it's a 65c02, this will return carry clear, but if it's a 65816 on board it'll return carry set.

Thanks - definitely not worth a ROM/kernel function.

I guess my follow up question would be how to place this code into a compiler that doesn't recognize the 65816 instructions.
I'll have to try it out and see how to address it.

The opcode for SEP is E2, so:

CLC
.byte E2
.byte 01

Depending on the compiler for the specific syntax.