Commander X16

It's nice that the 816 can address 16Mb of memory. We have 2 Mb on the board and that is it. The board is not changing.

I bet Commodore wishes they'd have had that option, just drop in a new chip and change the packaging a little and voila, the C64 becomes a C128. But look what happened to the C128. People had the option of C64 mode, so how much C128 software was actually written? People stuck with the C64 software, because it was already there.

We've had people developing software for the 65c02 all this time. OK, great, we can drop in a 65816, but if you actually take advantage of the 816's 16 bit instructions then your program won't work on the 65c02 anymore, so anyone using your software has to make that upgrade. So you would either program only for the 816, or accept programming in plain 6502 without the 32 bitwise instructions on the WD chip.

And there's no emulator to even test that software, whereas our 65c02 emulator is basically mature software at this point, all bugs stomped. Dropping in the 816 at this stage is bringing us all back to square 2 on the software side. Having two CPUs to write for is going to split the codebase into two.

If it's going to be the 816 then let's get an emulator so we can start taking advantage of the new instructions, and scrap all plans for the 65c02. If it's going to be the 65c02 then scrap the plans for the 816. Pick one or the other and stick with it. Stop moving the target.

I think the X16 using the 16-bit chip is the right choice, and that the team should have stuck with the 65816. If they make the change now then it ought to be total; no more 65C02, just the 65816, so we have compatibility across the ecosystem.

It is rather unprofessional that the X16 team is going back to this decision again after boards have already shipped. This makes me really nervous about the future of the X16. How do we know that they aren't going to mess with the consoIe version? Just start changing stuff as they please in the hardware or kernel on some subsequent run. If they do make this change to the X16, then I think David and co. should swear, in writing, that they won't be messing with the console once it ships. Every piece of software released for the console version, that works upon release, should continue to work indefinitely without patches. If they want a commercial software ecosystem for the X16, centered on the console version, software compatibility with all X16 consoles is essential.

I very much would like to be a part of that ecosystem if the X16 console sells enough units to be a viable target, and I don't want to have to worry about this.

encw wrote: ↑Fri Feb 16, 2024 9:46 am I think the X16 using the 16-bit chip is the right choice, and that the team should have stuck with the 65816. If they make the change now then it ought to be total; no more 65C02, just the 65816, so we have compatibility across the ecosystem.

... I very much would like to be a part of that ecosystem if the X16 console sells enough units to be a viable target, and I don't want to have to worry about this.

I don't hang out on Discord, but I'm guessing that the reason this has finally come to a head after four years of postponing making a final decision is that the X16 console can't continue with the "well, the socket is happy to accept either CPU" hardware design of the Dev board. You don't say "this is the cost-reduced version of the Dev Board system", and then start socketing SMB chips. One 512KB High RAM chip is going to be available, and that's it, because it's going to be picked up by a pick and place machine and surface soldered to the board. One 6522 is going to be available, and that's it: no option for a "user port" VIA#2, so no socket (indeed, the chip select logic likely won't even bother to generate the select).

Same with the CPU: it's going to be soldered to the board. So there's no socket to accept the swap.

So when they commit to which CPU they are going to use for the X16 console, then that should be (at long last) finally it: it doesn't make sense for the CPU swapping option to ever physically exist for the X16 console.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ed Minchau wrote: ↑Fri Feb 16, 2024 8:22 am It's nice that the 816 can address 16Mb of memory. We have 2 Mb on the board and that is it. The board is not changing.

Precisely. It is "as if" it is the 65c802 is being plugged in.

I bet Commodore wishes they'd have had that option, just drop in a new chip and change the packaging a little and voila, the C64 becomes a C128. But look what happened to the C128. People had the option of C64 mode, so how much C128 software was actually written? People stuck with the C64 software, because it was already there.

Remember that at that time, the C64 was still outselling the C128, so the install base advantage that the C64 had was growing throughout the life of the C128. If the 65816 is used in the third production run of the Dev Board, and used for the X16 console, the install base gap is going to shrink and then reverse in favor of the 65816.

We've had people developing software for the 65c02 all this time. OK, great, we can drop in a 65816, but if you actually take advantage of the 816's 16 bit instructions then your program won't work on the 65c02 anymore, so anyone using your software has to make that upgrade. So you would either program only for the 816, or accept programming in plain 6502 without the 32 bitwise instructions on the WD chip.

Or, if a program spends 80% of it's time in 20% of it's code, you can make two versions of that 20%, one for the 65C02 and one for the 65816, and after running the code to test which processor you have:
... you use the version that you have.

But that's not how things would evolve ... if the X16 console has an '816, then most software will just be written for the '816, for the same install base reason that the C128/C64 commercial software market was all C64 software ... on the one hand, the console can't switch, and on the other hand, a first or second production run Dev board becomes an '816 by prying the 'C02 out of the socket and putting an '816 in its place. So it's the X16 console that plays the "can only do one thing" role of the C64 and the X16 Dev Board that plays the "can do either thing" role of the C128.

Obviously, some of that software written for the 65816 will be written for the original 65C02 instruction set, because there's a lot more code available in the wild to borrow from for the NMOS 6502 than for the 65816, which is mostly SNES code and written assuming SNES video and audio. But if the console design settles on the 65816, that is still going to be 65C02 code written assuming that it's running on a 65816 in early 65C02 mode.

...

If it's going to be the 816 then let's get an emulator so we can start taking advantage of the new instructions, and scrap all plans for the 65c02. If it's going to be the 65c02 then scrap the plans for the 816. Pick one or the other and stick with it. Stop moving the target.

That'd be the decision point they've reached ... they've got a 65C02 system code base on hardware that isn't committed to either, but the X16 console will be one or the other, so they are either going to finally close out the 65816 possibility that they've left open for the past four years or are going to finally make the transition to using the 65816 option that they've had designed in since the prototype stage.

Ed Minchau wrote: ↑Fri Feb 16, 2024 8:22 am We've had people developing software for the 65c02 all this time. OK, great, we can drop in a 65816, but if you actually take advantage of the 816's 16 bit instructions then your program won't work on the 65c02 anymore, so anyone using your software has to make that upgrade. So you would either program only for the 816, or accept programming in plain 6502 without the 32 bitwise instructions on the WD chip.

Remember that the Gen-1 system is the "Developer" system. The development target is not so much other gen-1 users as it is the Gen-2 "Console" systems - which, if equipped with 65C816, will all have the 65C816.

And there's no emulator to even test that software, whereas our 65c02 emulator is basically mature software at this point, all bugs stomped.

https://github.com/X16Community/x16-emu ... ree/65c816

OK, I have stewed on this for a while and I think I see a solution.

If you are programming in assembly for the 65c02, and you don't use the SMB/RMB/BBS/BBR commands, your program will still work on the 65816 in emulation mode. However, if you are programming in assembly for the 65816, there's actually 59 commands you can't use (the 32 corresponding to SMB/RMB/BBR/BBS, and 27 corresponding to no-ops) if you also want your program to work on the 65c02. This will make programmers either program for one processor or the other, as it makes no sense to artificially hobble your code, and that will make it harder to code for all Commander X16 users.

However, there is a way out of this. The following hexadecimal bytes: $18, $E2, $01.

This code is interpreted by the 65c02 as: And it is interpreted by the 65816 as: The result is carry clear if the processor is a 65c02, and carry set if the processor is a 65816. By using this short section of code the program can branch on carry clear to load 65c02 code and branch on carry set to load 65816 code. The programmer can make two versions of the code, each optimized for the two processors and taking full advantage of all the available opcodes of each. Or this allows the code to fail gracefully, if the code is mismatched to the processor on board.

This means we get our cake and eat it too: both processors, and code for both, without hamstringing programmers for either one, and a simple way to fail gracefully if the code is incompatible with the processor. All that for only 3 bytes and 4 cycles.

I'm going to continue with just programming 65c02 code for now, but I'm upgrading the META/L editor and think I can make an 816 version as well, or perhaps one that works for both. The Surreal game engine is on hold until I get that done, but a 65816 version of that would be an extensive rewrite to take advantage of the 16 bit commands. And then eventually I'll get back to Asteroid Commander, which has been on the back burner since the last breaking change. I just need the target to stop moving for a few years.

Since R47 the ROM detects and supports 65C816.
What is the memory map of the system in the 16-bit native mode?

TestPleaseIgnore wrote: ↑Sun Sep 29, 2024 6:49 am Since R47 the ROM detects and supports 65C816.
What is the memory map of the system in the 16-bit native mode?

Largely the same. You can repoint the DP though as I recall that doesn't work with kernal interrupts. That might be a question to ask on the Discord in the #cpu-65816 chan. That may have changed but I'm not sure.

The hardware portions of the memory map are identical. Still 8k RAM banks, 16k ROM/Cart banks. Or said another way, swapping in an 816 doesn't add an expanded memory map with hardware (816) banking. It's still what is documented in the memory map (https://github.com/X16Community/x16-doc ... y%20Map.md).

TestPleaseIgnore wrote: ↑Sun Sep 29, 2024 6:49 am Since R47 the ROM detects and supports 65C816.
What is the memory map of the system in the 16-bit native mode?

There is no hardware to capture the bank address multiplexing. The memory map looks like 255 mirrors of the first 64K.

Wavicle wrote: ↑Sun Sep 29, 2024 9:19 pm

TestPleaseIgnore wrote: ↑Sun Sep 29, 2024 6:49 am Since R47 the ROM detects and supports 65C816.
What is the memory map of the system in the 16-bit native mode?

There is no hardware to capture the bank address multiplexing. The memory map looks like 255 mirrors of the first 64K.

Could hardware to capture bank address multiplexing be provided via the expansion bus on a card ???

Capture? Yes. Meaningfully use? Most likely not.

The current bus decoding only considers the low 16 address bits. You would need a way to stop everything from responding any time the bank address is non-zero. E.g. you do not want the RAM bank register to change when you write to $10000.