FAQ Update for Gen-2 aka "CX16GS" system

[DragWx]

Think about who the GS is for, and it makes sense why they'd remove the IEC port on it. It'll still be on the non-GS though, so just get that one if it has what you want.

[BruceRMcF]

Will modifications to Gen-1 boards be offered to have flat address space and more than 2MB RAM?

We don't know, yet. It's possible to create a CPU carrier board that has a 32MB memory module on board, but it's also almost certain that this board's function will differ slightly from the GS. Also, with the GS being Kevin and David's focus, designing a CPU/memory board would take even more time and push back the release of the GS.

So honestly, I wouldn't count on it.

Ok, I'm no hardware designer but it seems like it would be pretty easy to build a carrier board that just provided the extra 16 MB of RAM for the native 24-bit addressing space.

To map a 16 MB SRAM to the native 24-bit address space (but leave bank $00 using the motherboard RAM/ROM/IO) I think you'd just need an 8-bit latch to grab the bank number when it shows up on the data bus, then a comparator (or even just some cascaded OR gates if they're fast enough) to see if it's zero. If zero, pass the memory access to the motherboard RAM (and let the motherboard's address decoding logic handle all of the bank switching that goes on in the original 16-bit address space), and if non-zero then use the latched bank byte and the 16-bit address to index into 16 MB of SRAM on the carrier board. (The bottom-most 64k of that RAM chip would go unused.) There are some timing issues to worry about and some extra logic for chip select lines and such, but that's not too hard.

Yes, for the kind of 16bit Forth system which would work well on the GS system, with a 64KB code space, a 64KB data space, and IO@/IO! for the Zero Bank, a 16MB RAM on a CPU carrier would be plenty ... whatever the second tier system for directing ROM banking into different spaces of the second 16MB on the GS might have primitives defined to access it on a GS system, but the system itself would not be built around those additional spaces, so it would be a common system on either board.

I figure if the Zero Bank / High Bank decode is done in parallel with latching the value of the 65816, the latch can be tied directly to the onboard RAM high address lines and the decode determines which memory bus to access.

[doslogo]

I agree with every rant post above (and probably any rant posts below as well).

My own rant is that my entire project relied on the system being 8-bit. Now, I can just say it is 8-bit but sneak in some 16-bit code... Who would ever know? It is not like I am lying to my followers. It is not like there is some skill involved coding 65C02 on the actual 8-bit limits.

Also, my project depends on VERA doing exactly what it did in the Dev board, and the system running exactly the same cycles at 8 MHz. Because if it doesn't, then it is just bad design.

Anyone who actually needs more memory but doesn't need VERA DMA? Anyone?

[kelli217]

The 65C816 still only accesses data eight bits at a time. In that respect, it's still an 8-bit processor, as much as the Z80 is (since it also has some 16-bit internals).

[TomXP411]

I agree with every rant post above (and probably any rant posts below as well).

My own rant is that my entire project relied on the system being 8-bit. Now, I can just say it is 8-bit but sneak in some 16-bit code... Who would ever know? It is not like I am lying to my followers. It is not like there is some skill involved coding 65C02 on the actual 8-bit limits.

Also, my project depends on VERA doing exactly what it did in the Dev board, and the system running exactly the same cycles at 8 MHz. Because if it doesn't, then it is just bad design.

Anyone who actually needs more memory but doesn't need VERA DMA? Anyone?

The computer was named "Commander X16" because it was originally supposed to use a 65C816. Kevin and David backed off from that, because Kevin couldn't figure out the 24-bit address decoding without an FPGA (which people also screamed and yelled about), and the PET style X16 was the result.

I'm honestly glad for the upgrade, even if this means one or two features won't be available on my dev board. I imagine they'll shove in a couple more new features with the Lite edition, sometime in 2030. =)

[BruceRMcF]

I agree with every rant post above (and probably any rant posts below as well).

My own rant is that my entire project relied on the system being 8-bit. Now, I can just say it is 8-bit but sneak in some 16-bit code... Who would ever know? It is not like I am lying to my followers. It is not like there is some skill involved coding 65C02 on the actual 8-bit limits.

I'm basically agreeing with every anti-rant post above (and probably most anti-rant posts below as well).

I mean, sure, somebody could always misrepresent their project, but nothing about the hardware forces them to do so. If someone is doing a 65C02 project, relying on the original 65C02 opcodes and not using the Rockwell extensions is not going to be a crippling limitation ... and it, in any event, is "purely" 8bit and will work on power up on the prototype version of the GS board.

And it's all symbolic differences anyway ... the 65816 is an 8bit processor that uses clever addressing to allow some 8bit operations to work on two consecutive memory locations and/or on two distinct 8bit registers in the CPU hardware. Someone who has the 65816 in their 1st gen board already has a 64KB address space 65816 system, without any interference with running original 65C02 code. The only code broken is code that ignored the by-now multi-year old warning not to use the Rockwell extension opcodes.

Also, my project depends on VERA doing exactly what it did in the Dev board, ...

From the FAQ:

Stuff that is not changing:
...
VERA video. VERA will be the same, aside from digital video output. ...

So there is no problem on that front.

... and the system running exactly the same cycles at 8 MHz. Because if it doesn't, then it is just bad design.

Also from the FAQ,

CPU Speed upgrade: CPU speed will be software adjustable. 12MHz is the current number being proposed.

So just set the CPU speed to 8MHz, and no problem.

Anyone who actually needs more memory but doesn't need VERA DMA? Anyone?

Yes, the CX16 memory map is really constraining for a Forth system. 64KB "IO" space, including stack and direct pages, 64KB codespace and 64KB dataspace is much more comfortable for a 16bit Forth (which is the normal Forth model for the 8bit CPUs).

__________________

... I'm honestly glad for the upgrade, even if this means one or two features won't be available on my dev board. I imagine they'll shove in a couple more new features with the Lite edition, sometime in 2030. =)

With the FPGA "internal registers" accessed "as if" they are located on the expansion port, then the "emulatable" parts of the GS -- the UART, the SAM2695, much of the access to the "2nd" 16MB could be put onto an expansion card and accessed in parallel with the GS registers, just in IO7 rather than in the "high" registers of the YM2151. Now, it would only be possible to access the 3.5MB banks that are accessible on the expansion port, but that would be "most of the way" to the relevant feature set that fits the 8MHz speed limit of the Gen1 board.

[doslogo]

...

All valid and good answers to my worries.

The 65C816 still only accesses data eight bits at a time. In that respect, it's still an 8-bit processor, as much as the Z80 is (since it also has some 16-bit internals).

If it is the same CPU as in the SNES, then it will be difficult to say it is an 8-bit system. The SNES fanbase will refuse to call the SNES an 8-bit console just because Commander X16 fanbase says so.

Similar to how the 8088 CPU in the original IBM PC has an 8 bit data bus, it was still considered a 16-bit CPU. It's not as fast as the 8086, but it is easier to code for than an 8-bit CPU.

My YouTube videos (already suffering from algorithm) do get more traffic if they say "8-bit" compared to saying something like "Commander X16". 8-bit really is a thing, sometimes even a username can attract more if it has "The 8-Bit" in it. 8-bit is also more difficult to code for (I first started out coding 8-bit last September, very scared I wouldn't make it, but it was manageable).
Marketing is important, and "Commander X16" will most likely get bigger once more software and games come out, and changing the hardware might not be the right call to make that happen.... Or it might?

How about a slogan:
"Commander X16, the 8-bit computer dream, that is now 16-bits in the right hands"

[TomXP411]

After learning about the internals of the 65C816 (and having learned 8086 assembly years ago), I have decided to call the 65C816 an 8/16 bit processor.

It's mostly 8-bits, but can act like a 16 bit CPU when needed.

The 8088, on the other hand, is definitely a 16-bit CPU that can act like an 8-bit CPU when needed.

The difference being that the 65C816 is an extension of the 6502, whereas the 8088 is a cut-down 8086.

All that comes back to... Yes, it's safe to keep calling the Commander X16 an "8-bit computer", because it basically still is... and arguing with pedantic fanboys over the "technical definition of an 8-bit computer" is honestly half the fun.

[BruceRMcF]

...

All valid and good answers to my worries.

The 65C816 still only accesses data eight bits at a time. In that respect, it's still an 8-bit processor, as much as the Z80 is (since it also has some 16-bit internals).

If it is the same CPU as in the SNES, then it will be difficult to say it is an 8-bit system. The SNES fanbase will refuse to call the SNES an 8-bit console just because Commander X16 fanbase says so.

Yes, the SNES fanbase are committed to the hyping of the 65816 as a pure 16bit CPU.

Commitment of a fanbase to a talking point that flatters the system they are a fan of is not about how valid the argument is, but more about how emotionally attached they are to the argument.

Similar to how the 8088 CPU in the original IBM PC has an 8 bit data bus, it was still considered a 16-bit CPU. It's not as fast as the 8086, but it is easier to code for than an 8-bit CPU.

But while the 8088 has an external 8bit data bus, it is the same internal processor as the 8086 with the same 16bit registers, with a modified bus access to read 16bit inputs in two gulps and to write 16bit data in two gulps, but the actual operations are taking place in 16bit registers.

The 65816 literally does a "16bit ADC" by executing an 8bit ADC on one 8bit accumulator register, setting the carry along with the result, then incrementing the address and executing the same 8bit ADC on a second 8bit accumulator register. That state machine that does the "increment address while toggling which accumulator to use, re-use the operation, then toggle back to the first accumulator" is the heart of the "16bit" operations. It's a very clever trick to allow an 8bit CPU to perform a selection of 16bit operations by automatically chaining 8bit operations together.

My YouTube videos (already suffering from algorithm) do get more traffic if they say "8-bit" compared to saying something like "Commander X16". 8-bit really is a thing, sometimes even a username can attract more if it has "The 8-Bit" in it. 8-bit is also more difficult to code for (I first started out coding 8-bit last September, very scared I wouldn't make it, but it was manageable).
Marketing is important, and "Commander X16" will most likely get bigger once more software and games come out, and changing the hardware might not be the right call to make that happen.... Or it might?

In my view (admittedly a projection, so time will tell), making the hardware available substantially cheaper is a far bigger deal.

How about a slogan:
"Commander X16, the 8-bit computer dream, that is now 16-bits in the right hands"

"Learn 8-bit computing on the Commander X16", and if they end up finding 8bits a bit too restrictive and end up using the pseudo-16bit ops, there's no real harm in that

[Mkopack73]

I mean, really, who here who has and develops for the X16 ISN'T going to ALSO get a Gen 2 when available???