FAQ Update for Gen-2 aka "CX16GS" system

[rosettif]

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.

Don't worry: the system still remains an 8-bit one. On one hand, the CPU is only a part of the architecture, and even if it's capable of more, it won't affect it as a whole. On the other hand, the 65816 has two operating modes: emulation and native (and independent flags to extend the A or X/Y registers). Of which, the emulation mode is its factory default (since it boots up in this mode always when switched on or reset, and stays so until you manually switch over to native mode), where it is completely restricted to 8-bit (that's also the case on SuperCPU64/128). And it seems it must be the factory default of the CX16 Kernal, too.

... 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.

Unfortunately, they won't always match each other exactly, even though on the same frequency clock signal (or at least not completely cycle-accurately... if it is the complaint). The 65C02 may run the same code slightly faster than a 6502 (or a 6510 etc.) since there are some minor differences in the execution of their opcodes here or there (e.g. fetch-modify-write instructions are optimized to take 1 less cycle in some cases). Whereas the 65816 returns to the 6502 behaviour again (as well as the 65CE02 or the 4510 in 1 MHz mode filling its gaps up with those so-called "dummy cycles") for better backwards compatibility, but it has some other minor timing differences of its own, too (which is even affected by the current state of E/M/X flags according to the operating mode).

That said, deleting the Commodore Disc Drive port is in my opinion a mistake.

I absolutely agree with that.

[TomXP411]

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

Obviously true.

I think the thing people are annoyed about is that they can't actually use the Dev system for developing and testing 16-bit code. Once you switch to the flat memory model and start writing code to exploit the 16MB of addressable memory on the GS, you've broken the ability to run on the Dev.

That doesn't mean my Dev system is useless, but as time goes on and the GS user base increases, it will marginalize the Dev system's capabilities.

[BruceRMcF]

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

Obviously true.

I think the thing people are annoyed about is that they can't actually use the Dev system for developing and testing 16-bit code. Once you switch to the flat memory model and start writing code to exploit the 16MB of addressable memory on the GS, you've broken the ability to run on the Dev.

That doesn't mean my Dev system is useless, but as time goes on and the GS user base increases, it will marginalize the Dev system's capabilities.

Yes, if no DIP daughter-board with a surface mount 65816 and 16MB of RAM is developed, that becomes an issue with the Dev board. But if I understand the FAQ correctly, that sounds doable.

Indeed, once the GS board designed is finalized, I'd recommend hammering that kind of DIP daughter-board out and getting it available before the GS board release, to get a better head start on the availability of flat memory model code.

____________________

...

... 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.

Unfortunately, they won't always match each other exactly, even though on the same frequency clock signal (or at least not completely cycle-accurately... if it is the complaint). The 65C02 may run the same code slightly faster than a 6502 (or a 6510 etc.) since there are some minor differences in the execution of their opcodes here or there (e.g. fetch-modify-write instructions are optimized to take 1 less cycle in some cases). Whereas the 65816 returns to the 6502 behaviour again (as well as the 65CE02 or the 4510 in 1 MHz mode filling its gaps up with those so-called "dummy cycles") for better backwards compatibility, but it has some other minor timing differences of its own, too (which is even affected by the current state of E/M/X flags according to the operating mode). ...

Yes, to get perfect cycle matching between a Dev board with a 65C02 and one with a 65816, you have to run the 65816 in emulation mode and avoid some address modes of FMW instructions, or else in setup test for the processor in use and have a speed align subroutines that keep things aligned.

But to be sure, the GS design seems likely to increase the share of Dev boards that end up getting a 65816 installed, so in that sense the GS design will make this more of an issue over time.

[paulscottrobson]

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.

It's actually both. Well , three. I find writing 65816 assembler it's best to pick a mode and stick with it, switching out briefly when needed, rather than bounce about.

But you can use it as :

- a 65C02 with 64k RAM, which you can do nifty things like task switch, or just leave it.
- a 65C02 with 16Mb RAM, write 8 bit 6502 code, use the extended data/address modes as you want
- a 65816 with 16Mb RAM and 16 bit code.

[paulscottrobson]

Yes, if no DIP daughter-board with a surface mount 65816 and 16MB of RAM is developed, that becomes an issue with the Dev board. But if I understand the FAQ correctly, that sounds doable.

Indeed, once the GS board designed is finalized, I'd recommend hammering that kind of DIP daughter-board out and getting it available before the GS board release, to get a better head start on the availability of flat memory model code.

This board could actually end up being more expensive than simply have a Gen 2 board ....

[Mkopack73]

While I can certainly appreciate the added simplicity of a flat memory model, I have to wonder what the heck anybody is planning to do with 16MB (or 32!) of RAM on this thing! That’s more than I have in any of my fairly well decked out Amigas!

I find it hard to believe that anyone will use that much ram on these machines. Is the bank switching model REALLY that much harder to work with ? (I honestly don’t know, haven’t gotten that far).

[TomXP411]

While I can certainly appreciate the added simplicity of a flat memory model, I have to wonder what the heck anybody is planning to do with 16MB (or 32!) of RAM on this thing! That’s more than I have in any of my fairly well decked out Amigas!

I find it hard to believe that anyone will use that much ram on these machines. Is the bank switching model REALLY that much harder to work with ? (I honestly don’t know, haven’t gotten that far).

Yes, it is - especially if your code data both require banked memory. There's no simple way to have code in one bank and data in another bank, so if you have something like 100K of code and 200K of data, there's no simple way to store them all in banked RAM at the same time. What you'll end up doing is caching data or code in low memory, with routines to pull data into cache from high memory as needed.

This gets complex and slows down your programs.

With the 65C816's memory model, you get a series of 64K banks, with separate code and data banks. Not only that, but the most common data transfer and flow control opcodes have 24-bit address modes, which allow you to simply read from a far bank without needing trampolines or other complicated bank control mechanisms.

Does anyone need 16MB on an 8 bit computer? Maybe or maybe not... but wouldn't it be interesting to find out what people can DO with all that memory?

[BruceRMcF]

Yes, if no DIP daughter-board with a surface mount 65816 and 16MB of RAM is developed, that becomes an issue with the Dev board. But if I understand the FAQ correctly, that sounds doable.

Indeed, once the GS board designed is finalized, I'd recommend hammering that kind of DIP daughter-board out and getting it available before the GS board release, to get a better head start on the availability of flat memory model code.

This board could actually end up being more expensive than simply have a Gen 2 board ....

(to repeat from discord), For the "16MB" part, I don't think it comes close to $200ish. A 65816, a small CPLD, a 16MB RAM, the circuitry to isolate the 65816 from the motherboard bus, some level shifters. At low volumes, it might require soldering the pins, but it seems like a small surface mount circuit that can fit in the footprint of of the Gen1 CPU socket.

Since the Gen1 board does have expansion ports, it seems like an expansion card could be designed which emulates the operation of the "high" 16MB, to avoid trying to cram everything into the daughterboard and not have to worry about the final design of access to the "high" 16MB while working on the daughterboard.

If Gen3 is in high volumes and this daughterboard is in low volumes, I could see the price of a Gen3 board starting to squeeze out the case for a Gen1 owner getting the daughterboard, but if the introduction of Gen2 is something like a year away, worrying about Gen3 is taking out a loan of worries from really far into the future.

[Mkopack73]

While I can certainly appreciate the added simplicity of a flat memory model, I have to wonder what the heck anybody is planning to do with 16MB (or 32!) of RAM on this thing! That’s more than I have in any of my fairly well decked out Amigas!

I find it hard to believe that anyone will use that much ram on these machines. Is the bank switching model REALLY that much harder to work with ? (I honestly don’t know, haven’t gotten that far).

Yes, it is - especially if your code data both require banked memory. There's no simple way to have code in one bank and data in another bank, so if you have something like 100K of code and 200K of data, there's no simple way to store them all in banked RAM at the same time. What you'll end up doing is caching data or code in low memory, with routines to pull data into cache from high memory as needed.

This gets complex and slows down your programs.

With the 65C816's memory model, you get a series of 64K banks, with separate code and data banks. Not only that, but the most common data transfer and flow control opcodes have 24-bit address modes, which allow you to simply read from a far bank without needing trampolines or other complicated bank control mechanisms.

Does anyone need 16MB on an 8 bit computer? Maybe or maybe not... but wouldn't it be interesting to find out what people can DO with all that memory?

Ok, so this *ISN'T* like how the memory expanders on say the C64 worked? Because I've seen some pretty amazing demos where data gets pushed up into the expanded memory and you program is in the base 64KB, and then you pull data in and manipulate it (or display it) and push new data back or whatever... My understanding is that it effectively blitted data back and forth. Guess I don't understand (and that's fine). But yeah I just fail to see what 16MB will be used for... Amigas and Apple2GS's had only like 512KB-1MB and had full GUI desktops and did video and all sorts of stuff.

[BruceRMcF]

... With the 65C816's memory model, you get a series of 64K banks, with separate code and data banks. Not only that, but the most common data transfer and flow control opcodes have 24-bit address modes, which allow you to simply read from a far bank without needing trampolines or other complicated bank control mechanisms. ...

Yes, this is the BLOCK/BUFFER approach I would have in mind. A 4 deep "least recently used" stack of 1KB Blocks, in the 64KB dataspace, using Long address modes to read or write directly between the buffer that is immediately addressable by a 16bit Forth, and the location of the BLOCK in the 16MB dataspace. Then the 15 1MB "big block files" of the Block Space can be loaded from or saved to the SD card, and also 3 256KB "small" block files.

Now, the "natural" "medium" model for a 16bit Forth is not 256KB but rather 192KB ... 64KB for the IO, stack, one direct page per task, internal assembler support routines, etc, 64KB for codespace, including the linked lists of names of defined words, 64KB for dataspace (including block buffers). So there's 64KB unclaimed there, but I'm sure that uses for it will emerge.

With the Gen1 memory model, I was going to have a separated name-header model, to increase the code density of code space, with the names in High RAM, underlying support code in 8KB modules, to reduce the dictionary footprint in main memory, and Block Buffers in High RAM copied into and out of block buffers through the HRAM Bank ... like I said, a 3-ring circus.

Instead, I aim to finish up the xForth I started as a minimal 65C02 model, and then focus on working toward a proper 65816 Forth.