FAQ Update for Gen-2 aka "CX16GS" system

[BruceRMcF]

... Ok, so this *ISN'T* like how the memory expanders on say the C64 worked? ...

No. During the first phase of the memory clock cycle, the 65816 puts the high 8 bits of a 24bit address on the data lines. In the Gen1 if a 65816 was installed, those bits would basically be ignored, so a 65816 in the Gen1 CPU socket can only access the same 64KB as a 65C02 is limited to.

But if that "third byte" of address data is grabbed, then rather than pump data into or out of the 64KB address space, you can have:

LDA [block],Y

... with "block" being a 24 bit base address in the direct page and Y being a 16bit offset, and go directly to where the data is located in the 16MB address space.

But you don't have to always use 24bit addresses. If you do a 16bit JMP, the 8bit program bank register provides the high eight bits, and for data read or write operations with a 16bit address, the 8bit data bank register provides the high eight bits. And for what would be zero page operations in the 65C02, the operations always occurs in the bottom 64KB and the 8bit "direct" page register provides the "middle" byte of the "direct page" operation, so basically different tasks can, in effect, each have their own dedicated zero page.

In the prototype, the FPGA grabs that "high address" data and can put it on the high address lines of the 32MB RAM chip when appropriate, so the whole 16MB of address space is directly available to the CPU.

It would also put together the "High RAM Bank" address and put the appropriate address to get into 2MB of that chip for the High RAM Bank, and the FlashROM contents (or, I guess, an alternative for the FlashROM contents) can be written into a different range of the 32MB address and be used as a ROM Bank ... and the "expansion port" Bank when the ROM Bank number is 32-255 is directed to a different zone of the 32MB RAM chip.

If an 8MB surface mount RAM chip was substantially cheaper than a 32MB one, you could say, "OK, we have 2MB for High RAM, and 4MB for soft-ROM and expansion port RAM/ROM, and 2MB left over so allocate 2MB for direct access by the 6586". And 2MB is quite a bit.

But since it seems like the difference in cost is very small, then I guess it probably does make a certain amount of sense to just max out the directly accessible RAM, and then put all of the possible Gen1 RAM / soft-ROM in the other half somewhere.

[Kalvan]

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.

Well, for a GUI, I keep finding myself recommending ConTiki. It's fully functional, has already been ported to five different 6502-based platforms (Atari 8-bit. Commodore VIC-20, Commodore 64/128, Apple II, and Acorn Atom/Electron/BBC Micro), and the full executable is at most 30K in size. Well within the reserved 512K of reserved ROM space.

[DragWx]

Sorry if this was answered already, but there's been confirmation that the GS will have all 2MB of banked RAM available, right? I remember the original plan was that Gen 1 would be expandable up to 2MB but Gen 2 was going to be 512KB only.

[BruceRMcF]

Sorry if this was answered already, but there's been confirmation that the GS will have all 2MB of banked RAM available, right? I remember the original plan was that Gen 1 would be expandable up to 2MB but Gen 2 was going to be 512KB only.

The point of that was cost reduction.

However, with the prototype board that was produced, it turned out that the cost of a single surface mount {Edit:} DRAM 32MB chip was low enough there was no need to trim back on the HighRAM capacity. There's even enough to support the cartridge mode 3.5MB in the higher banks of the ROM Bank.

[TomXP411]

Sorry if this was answered already, but there's been confirmation that the GS will have all 2MB of banked RAM available, right? I remember the original plan was that Gen 1 would be expandable up to 2MB but Gen 2 was going to be 512KB only.

Yes, that was originally the plan, but as David explained in the live stream, Kevin found an inexpensive 32MB DRAM chip.

Of course, that means dealing with DRAM refresh, but using an FPGA makes that a bit easier, as the FPGA can perform that task.

[BruceRMcF]

... Of course, that means dealing with DRAM refresh, but using an FPGA makes that a bit easier, as the FPGA can perform that task.

Exactly. While SRAM makes the interfacing easier, I see 32Mx8 143MHz DRAM in a TSOP package for $2.60 when bought by the 100s at Mouser, which is cheaper then 4Mbit (512kx8) SRAM.

A DRAM refresh controller can be done in a CPLD -- while it's a bit hungry in terms of pins, AFAMLU, it's not hungry for logic. And you need the address line pins tied to the FPGA anyway. So if there is an FPGA to implement the memory banking scheme and VIA cores, etc., having enough logic capacity to also have a DRAM controller core is not surprising.

[Wavicle]

The biggest problem with SDRAM (or DRAM) is that memory access latency is relatively long and that latency has not changed much in the past couple of decades. E.g. an SDRAM with CAS latency of 2 typically has a tRC of 9-10 cycles. At 200MHz, that's 45-50 ns between random memory accesses. Their sequential page access is quite fast; these parts are generally tuned for cache line filling/flushing of modern CPUs. The bus controller can leverage that to fill its own internal cache which means that sequential access (i.e. running a program without branching) can go fairly quickly, but you hit a similar issue to modern CPUs in the event of a cache miss. To combat that you need to implement some sort of branch prediction to pre-fetch the program data. The bus controller will need to not just handle the memory interface, but also generate some sort of delay back to the CPU until the data is ready. It doesn't take long before this looks nothing like an 8-bit system and there's a valid point to be made in asking why the system has a discrete CPU at all.

As a hardware person, a bigger concern to me is that this likely breaks the bus mastering model of the original X16. Not that the original X16 had a great bus mastering model (e.g. all access has to be synchronous because the system clock is used to generate the RE# and WE# signals). One of the presumed benefits of the 816's expanded memory space would be memory mapped expansion cards, but it isn't clear that those would work here at all, and even if they did, they'd require their own bus decoder because there are no spare pins to carry the additional 8 address signals, similar to how all X16 cartridges must also contain their own ROM bank decoder because the ROM bank signals are not available at the card edge. Saved some cost on the board but adds that back, with interest, on every cartridge.

[Kalvan]

Well, the good news is that we have at least a year for the team to sort that matter out. The bad news is that Mr. Murray has two different YouTube channels to manage and produce content for and an arcade to work at during its usual hours, and several of his crew have similar commitments on their respective time.

BTW, Mouser also has 8 Megabyte (64 Megabit) Pseudo-SRAM chips with a clock speed of 200MHz at $1.66 a pop when ordered in lots of 250 or more each. This solution adds US $5.66 plus appropriate shipping charge changes to the materials cost and at least 25 cm^2 to motherboard space, if you aren't using both sides of the PCB, but so long as you don't clock the CPU faster than 16. 384MHz., you can forgo the extra bus headaches from external DRAM refresh hardware, and the internal refresh cycles happen so infrequently that branch hiccups shouldn't matter.

The only downside is that internally, it's still DRAM, so you can't use its interior memory clock to time the entire system. But I'm pretty certain Mr. Murray and crew know that, since they were planning to use DRAM for this model anyway. They'll simply have to stick a master clock chip on the motherboard or use some other thing(s) to time everything. (My two leading candidates are the VERA pixel clock of ca. 24.576 MHz times VERA's internal bitwidth, and the Atmel Atiny controlling the keyboard and mouse.)

[Wavicle]

Always check the datasheet on these things before making assumptions about how performant memory is. The APS6408L is a *synchronous* pseudo SRAM with a highly multiplexed ADQ bus and a tRC latency of 60ns. Strictly speaking, there is no way to meet the datasheet minimums at anything faster than 8MHz (possibly 9MHz, but it seems we're looking at increments of 2MHz).

One can bump tRC latency down to 45ns using fast SDRAM with a /CAS latency of 2, which has a chance of meeting strict timings at 10MHz, but no chance at 12MHz. Over the past couple of decades, several clever things have been done to improve sequential access speed of RAM, but there has been little change in memory latency performance.

[mortarm]

Well, for a GUI, I keep finding myself recommending ConTiki.

There's no reference to this either in the forum or Wikipedia.