Commander X16

tim1724 wrote: ↑Tue Mar 18, 2025 8:36 pm If you wanted the other features (mapping RAM in place of ROM banks) then an FPGA would be the way to go. But honestly I can't see much of a use case for that; the flat 16 MB address space is much more useful than extending the already convoluted banking of the base CX16 address space.

I think Kevin is trying to make use of all 32MB on that memory module, including shadow ROM and ROM switching. However, going with a simpler approach and just creating two 16MB partitions might be the smarter thing to do, if one wants to make the Dev board forward-compatible.

I think it's a reasonable approach for the CX16GS. One could imagine an alternate history where an in-between machine still using the 65C02 could have done the RAM-in-place-of-ROM banks trick to add more memory. And then if the CX16GS were the third system, it would have to keep that in place even while adding the native 16 MB with the 65C816.

And it's a pretty clever way to make use of the RAM in that chip. (The alternative would be to use a 16 MB SRAM for the 24-bit address space plus a separate smaller RAM chip to handle the standard CX16 RAM, but using the single 32 MB chip is likely cheaper if they were already going to use an FPGA anyway.)

But for an upgrade for our CX16 dev boards, I'd probably just do the flat 16 MB and ignore the rest to keep things simpler. (If they don't do any official upgrade board then this is what I'll do, as I'm pretty sure it's within my very limited hardware design skills.)

tim1724 wrote: ↑Tue Mar 18, 2025 7:07 pm The Game Boy used a Sharp SM83 processor, which was sort of in between an 8080 and a Z80.

Ack, pardon, yea I meant SNES instead of GameBoy! I didn't have either, I went the Genesis/Lynx route instead in my day. Still, main point was that appealing to the early 1990s platforms crowd is going to be a larger population of enthusiasts.


That there is still no solid-support for a C compiler on the 65816 still makes me doubt one will appear anytime soon. Beyond just the compiler itself, but one with a standard library targeted to the platform as a whole (for standardizing things like main entry point, command line arguments, etc). The general "runtime library" is a critical aspect beyond just the compiler. It's why Borland's compilers were so successful, they had very easy to use and fast runtime libraries (but it's also got developers into trouble, as the code got vendor-locked and not as portable). We've had outstanding volunteer support on the X16 KERNAL so far, hopefully they continue to have an appetite with the 816 as well (which so far they have, recent ROM updates were to better support that mode).


For the multi-tasking itch, I just stick with the NitroOS9 work on the 6809. But resurrecting GeOS would be interesting also.


As for a 65816 BASIC - perhaps not, just that's a difference we're talking about: intro text describe the X16 as a "boot to BASIC system", but now it has to be explained "unless, blah blah" and technical thought and development has to be spent on supporting these alternative modes (startup sequence explained, etc) instead of shoring up docs/tutorials on what we have. That's why some have suggested to call this "other system" an X17 or something along those lines (a follow up generation).

NOTE: Not trying to suggest any change in direction - it'll be an 816-system with a lot of care on maintaining backwards compatibility, no new 2nd boards should be necessary . But I do get some of the concerns other people have (such as 6502-activity dries up and everyone is just using the newer 816 stuff)

Xiphod wrote: ↑Tue Mar 18, 2025 9:17 pm As for a 65816 BASIC - perhaps not, just that's a difference we're talking about: intro text describe the X16 as a "boot to BASIC system", but now it has to be explained "unless, blah blah" and technical thought and development has to be spent on supporting these alternative modes (startup sequence explained, etc) instead of shoring up docs/tutorials on what we have. That's why some have suggested to call this "other system" an X17 or something along those lines (a follow up generation).

I'm not sure what you mean by "alternative modes"

From what has been described I would expect it to be running the exact same software as the current CX16.

When your turn on a 65C816 it starts out in 6502 emulation mode. (To switch to native mode you have to clear the carry bit (e.g., with the CLC instruction) then run the new XCE instruction to swap the carry and emulation mode bits.) So when you turn on a SNES or an Apple IIGS, it's running in emulation mode until the ROM switches it to native mode.

The Apple IIGS firmware switches to native mode to run its diagnostics and to do some setup, then switches back to emulation mode to continue booting as if it were an 8-bit Apple II. (This is so it can boot 8-bit Apple II software. If you boot IIGS-specific software, such as the GS/OS operating system, then obviously it switches back to native mode pretty early on in the boot process.)

What the SNES does on boot obviously depends on what cartridge is inserted, but I'd assume just about every SNES cartridge must start out with the CLC, XCE sequence as there's no reason for a SNES to ever be in emulation mode.

The reset routine in the CX16 KERNAL stays in emulation mode (since it's designed to work with both 65C02 and 65C816 CPUs). After it initializes the system it drops into BASIC which runs in emulation mode.

It would be up to third-party software to switch the CPU into native mode (via the CLC, XEC instruction sequence) if it wanted to run in that mode.

tim1724 wrote: ↑Tue Mar 18, 2025 10:09 pm

Xiphod wrote: ↑Tue Mar 18, 2025 9:17 pm As for a 65816 BASIC - perhaps not, just that's a difference we're talking about: intro text describe the X16 as a "boot to BASIC system", but now it has to be explained "unless, blah blah" and technical thought and development has to be spent on supporting these alternative modes (startup sequence explained, etc) instead of shoring up docs/tutorials on what we have. That's why some have suggested to call this "other system" an X17 or something along those lines (a follow up generation).

I'm not sure what you mean by "alternative modes"

From what has been described I would expect it to be running the exact same software as the current CX16.

When your turn on a 65C816 it starts out in 6502 emulation mode. (To switch to native mode you have to clear the carry bit (e.g., with the CLC instruction) then run the new XCE instruction to swap the carry and emulation mode bits.) So when you turn on a SNES or an Apple IIGS, it's running in emulation mode until the ROM switches it to native mode.

The Apple IIGS firmware switches to native mode to run its diagnostics and to do some setup, then switches back to emulation mode to continue booting as if it were an 8-bit Apple II. (This is so it can boot 8-bit Apple II software. If you boot IIGS-specific software, such as the GS/OS operating system, then obviously it switches back to native mode pretty early on in the boot process.)

What the SNES does on boot obviously depends on what cartridge is inserted, but I'd assume just about every SNES cartridge must start out with the CLC, XCE sequence as there's no reason for a SNES to ever be in emulation mode.

The reset routine in the CX16 KERNAL stays in emulation mode (since it's designed to work with both 65C02 and 65C816 CPUs). After it initializes the system it drops into BASIC which runs in emulation mode.

It would be up to third-party software to switch the CPU into native mode (via the CLC, XEC instruction sequence) if it wanted to run in that mode.

Will you be able to map the ROM completely out for 16MB of RAM (minus IO, of course)? If so you could completely replace the ROMs with a 16bit OS. I think I plan on taking a crack at writing on that is similar to AmigaOS with a GUI and preemptive multitasking.

mgkaiser wrote: ↑Wed Mar 19, 2025 12:53 am Will you be able to map the ROM completely out for 16MB of RAM (minus IO, of course)? If so you could completely replace the ROMs with a 16bit OS. I think I plan on taking a crack at writing on that is similar to AmigaOS with a GUI and preemptive multitasking.

The first 64k is mostly the same as the CX16 memory map (described in chapter 8 of the reference, and summarized below) but they're considering the possibility of mapping additional RAM in place of the 16 KB ROM window.* The other 15.9375 MB of address space is all RAM that's new to the CX16GS (and is what I would expect to see in a CPU interposer board plugged Ito an old system).

That first 64K is particularly important because that's where the stack and direct page live. (It's also where things like the reset and interrupt vectors are located, which is why you need to have some ROM mapped there, at least at startup.)

On the 65C816 the Stack Pointer can be anywhere in that first 64k, unlike the 6502 and 65C02 where it's stuck on page 1 ($0100–01FF). The Direct Page, which can be located anywhere in that first 64K acts like the 6502/65C02 zero page (which was fixed at $0000–00FF on a 6502 or 65C02) except that you can now move it around. Being able to map it (and the stack) anywhere in the first 64KB is useful for making a real operating system and was heavily used on GS/OS on the Apple IIGS where each running program got its own stack and direct page and various parts of the operating system and libraries also had their own direct pages.

The current CX16 memory map looks like this:

$0000–00FF: zero page
$0100–01FF: stack
$0200–9EFF: Normal RAM
$9F00–9FFF: memory-mapped I/O
$A000–BFFF: Banked RAM (8 KB window into any one of 266 banks of RAM, 2 MB total)
$C000–FFFF: Banked ROM (16 KB window into one of 32 banks of system ROM, or one of 224 banks of cartridge ROM)

The CX16GS has significantly more memory. The 65C816 has a 24-bit address space, segmented into 256 64KB banks. Unfortunately the CX16 is already using the term "bank" for its $A000–BFFF RAM window and $C000–FFFF ROM window, so using the word bank for both of those as well as the 65C816's 64k banks might be confusing. We could refer to the bigger banks as segments or something (which would match up with 80x86 naming) but all 65C816 documentation refers to banks, so I think we're probably stuck with that terminology.

Most 65C816 instructions are inherited from the 6502 or 65C02 architectures, so for the most part they use 16-bit addresses. Only a handful of instructions use "long" addressing that can directly use 24 bits. So how do the older instructions reach the full 24-bit address space? Well, there's a "Program Bank" register that holds the top 8 bits of the program counter and when using JMP and JSR instructions that take a 16-bit address, they always use the Program Bank register for the top 8 bits of the destination address. Similarly there's a Data Bank register that store the top 8 address bits to use for Instructions that load or store data in memory. (Aside from the handful that specify full 24-bit addresses.) As a result it's usually best to think of the memory as being in 256 separate memory banks, even though there are a few instructions that can treat it as one linear 24-bit address space.

The convention on the Apple IIGS was to write addresses with a slash between the bank byte and the 16-bit address within the bank. So the first bank was $00/0000 through $00/FFFF, the second bank was $01/0000 through $01/FFFF, etc. I don't know what the typographical convention will be on the CX16GS, so I'll use the IIGS notation here.

From what I understand, the CX16GS memory map will look like this. (I could be wrong, and hopefully someone will show up with corrections if I misunderstood anything.) Changes from the CX16 are in bold:

$00/0000–9EFF: normal RAM. (In emulation mode the direct page will be at $00/0000–00FF and the stack will be at $00/0100–01FF, but in native mode they can be moved to anywhere in bank $00.)
$00/9F00–9FFF: memory-mapped I/O
$00/A000-BFFF: banked RAM (8 KB window into one of 256 banks of RAM, 2 MB total)
$00/C000–FFFF: banked ROM/RAM (16 KB window into one of 32 banks of system ROM, or one of 224 banks of cartridge ROM OR one of 256 banks of RAM (4MB total)*)


$01/0000–FFFF: normal RAM
$02/0000–FFFF: normal RAM
$03/0000–FFFF: normal RAM
$04/0000–FFFF: normal RAM
…
$FF/0000–FFFF: normal RAM

So as you can see, the entire 24-bit address space is mapped as normal RAM (with banks $01 through $FF completely free for you to use for anything you want, as the KERNAL doesn't use it) except for a few parts of bank $00. (And it looks like CX16GS might* even let you replace the ROM areas with more RAM, but unless you end up needing it for stack or direct page space I don't see why you'd bother, given you have a full 16 MB available for everything else. You can see why I think supporting the main 16 MB in the native 24-bit address space in an add-in card on the CX16 would be way more useful than bothering with mapping RAM into the 16KB ROM window at $00/C000–FFFF.)

* It looks like the mapping RAM in place of ROM isn't implemented yet and may be subject to change, according to the FAQ.

My 2c on the "yet another system" problem (I say this as someone who genuinely wants the CX16 to succeed...):

The Commander X16's only "marketing" so to speak was through the 8-bit guy's Youtube channel. David appears to have lost interest in promoting it what with the arcade and other public projects. There hasn't been anything decent reported in ages. The only Community is a very small group here and an equally small group on Discord.

I only learned 6502 assembly because of the CX16. I think that was one of the original goals - to introduce people to computing much the same way the C64 did. I'd love for the community to continue to grow, and for more people like myself to take on projects. But by "muddying the waters" so to speak with many systems, its only gonna make the barrier for entry greater. Some commentators are already calling the CX16 dead and some even said it was DOA.

There are currently many active projects (including my own) that are targeting the CX16 65c02. I've done so bloody much to squeeze performance out of it and the VERA. If I had a 16-bit processor I would have been finished by now probably. Or maybe I wouldn't have even tried to take on the challenge. Where's the fun in that?

I've been waiting to pull the trigger on buying a CX16. Now which one do I buy? I get it's backwards compatible, but it's not the same. Would you prefer an original NES, or a New-Style NES or a NES System on a Chip? Might as well just use an emulator.

The community needs a stable platform to build for, not a constantly moving target. I know David mentioned porting Sam’s Journey and other games on his channel, but maybe more could be done to actively draw people to the platform?

Constantly developing new versions of the system doesn’t solve that problem. If anything, it makes it harder for developers to commit. If the platform keeps shifting, it risks becoming just a niche project for a handful of enthusiasts (if it wasn't already), rather than something with real traction.

So I suppose the real question is - who is it for?

Couple thoughts:

1. Anyone who has been in the retro space for any length of time knows (and anyone who hasn't yet discovered this will find out): There's -100% everyone will be pleased. As I often say, "everyone has their own dream computer, this is David's". So it's Kobayashi Maru. If they left hardware on the table with the GS instead of utilizing it, folks that wanted the 65816 would be disappointed. As it stands, David and Kevin know the impact of changes. I've personally talked to Kevin at length about this by phone. They're very aware. But they also have to balance price, enticing new folks, appeasing current ones (again the 816), among many other things. It's easy to armchair officiate. What they are doing is both hard and expensive. I think we should give them some latitude and one major reason is because...

2. ...The X16-GS will have compatibility with X16-Dev. This is pretty huge and not something other retro solutions have tended to do. So ultimately the question about "who is this for?" is in a way everyone. Folks can keep writing X16-dev apps. They are no less relevant than they are today. Especially given all of this is by-choice. We no longer live in a world where the 6502/65816 was the only reasonable choice as a home computer. So to a degree, everything we do is arbitrary.

For me, while I love the X16-Dev for it's expansion capability, the console version was always only going to have a cart slot. Kevin at leat gave us the edge connector for a potential future backplane to turn it into a more "normal" computer with expanability. Secondarily, what I enjoy the most is that it's a baremetal machine. That hasn't changed.

3. Worth noting the design can (and likely will) change from what we see today. So there's some pre-judgements happening for a solution that doesn't yet exist outside of a few prototypes.

David didn't have to share any of this with us, but I'm very glad he did and I think we should celebrate what we have. For folks that find this is not a solution for them, that's also perfectly ok. There may be other retro platforms that are more your jam. Maybe it's something important enough to you that you make your own platform. I encourage folks to consider the exercise in fact so folks can see what it's like for David and Kevin to have to balance all these things. Both personal expense and the risk that entails, but also the time, the marketing, the feedback, etc.

Having said all that, note about the community. I haven't heard any of these DOA claims but I'm not in all the places where the X16 is discussed. What I do see is folks that have worked incredibly hard to make this platform what it is beyond Kevin and David, many of whom do so voluntarily. These folks should be celebrated too and should be considered when folks are being negative towards the platform. I'm not suggesting folks should have criticism, just pointing out there's a lot of people doing a lot of good work on this platform and I'd challenge folks that have concerns to consider lending a hand to make the platform better. There is an awful lot of work to do still. The documentation is a great place to contribute and doesn't require deep understanding of the hardware internals to make a difference.

Agreed, I didn't mean to sound lukewarm or anything; I'm genuinely excited to see Gen 2 materializing, and I'm sure everyone who was waiting for Gen 2 is also excited that they're getting something more upgraded than Gen 1 for their patience.

I was just feeling out what the development ecosystem was going to look like, and I'm totally happy sticking with a 65C02-powered Gen 1 (for now at least) and I'm especially happy that it's viable to do so, and that it takes almost no effort on my part to make my stuff forward compatible with upgraded machines. You're right, that's a pretty awesome feature about how the X16 is being designed, and I agree 100%.

Also, people saying the X16 is DOA, I just roll my eyes at, and that's all the consideration I care to give that sentiment.

Consider that the Commodore 64 happened two and a half years after the VIC-20. The 128 happened three years after the 64. The original Apple II likewise was followed up by the II+, IIe/IIc, and IIGS at three year intervals. This upcoming Commander X16 GS, once it happens, will come out four years, at least, after the first regular production run of the original version shipped to end users. I see no special cause for concern over any hypothetical upgrade schedule based on the current history of this endeavor, at least on grounds of excessive haste.

Most of the planned alterations to the internal system itself, from a software perspective, are things I consider to be improvements. I am currently working on a list of things I would have added beyond that, but that is a matter for a different post, possibly in a different thread and/or forum. The currently planned changes to system expandability are disappointing, but for the most part, Mr. Murray warned us about them from the beginning, so none of us, especially I, have any reason to complain about them.

That said, deleting the Commodore Disc Drive port is in my opinion a mistake. My original plans for my personal Commander X16 rig involve(d) a Silverstone horizontal upright case, the extra RAM and VIA, some way to realize the full backplane expandability potential, and two brand spanking new copies of the recently reverse-engineered Creative Micro Devices CMD 4000 3.5" Double-Sided, Extended Density floppy drives, among other things. What is the use of maintaining support for the original Commodore 8-bit peripheral ecosystem and third-party additions thereto in software and then dropping direct physical connectivity to them, forcing someone to solder together a dongle and hack a USB driver through them using one of ESP32 cores as a mediator and writing at least two extra abstraction layers each way bigger than Kernal and Commodore DOS just to make it work?