FAQ Update for Gen-2 aka "CX16GS" system

Chat about anything CX16 related that doesn't fit elsewhere
kelli217
Posts: 556
Joined: Sun Jul 05, 2020 11:27 pm

Re: FAQ Update for Gen-2 aka "CX16GS" system

Post by kelli217 »

mortarm wrote: Mon Mar 31, 2025 5:28 am There's no reference to this either in the forum or Wikipedia.
A port would have to be undertaken. The 6502 is already a known target for the system; the VERA screen driver and network card driver would have to be written.

For a while, Contiki was the retrocomputing equivalent of DOOM: See what you can get it to run on. But then Dunkels took it to the 'professional' microcontroller market and removed most of the 'fun' porting projects from the main web pages for the system and so retro hobbyists stopped finding it as interesting.
BruceRMcF
Posts: 259
Joined: Sat Jan 07, 2023 10:33 pm

Re: FAQ Update for Gen-2 aka "CX16GS" system

Post by BruceRMcF »

Wavicle wrote: Sun Mar 30, 2025 7:23 pm 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.
Note the previous comment I made regarding a DRAM controller in a CPLD was from a paper published in the late 90s, and it was using a CPLD with 128 macrocells. However, given that 16MB in Native Banks is massive overkill for most of the benefits of Native Banks, a 512KB SRAM on a daughterboard with a ATF1504 CPLD, a 50ns line delay for timing, and a Surface Mount version of the 65816 to fit it all into a DIP socket daughter-board would offer access to the original system 64KB address space (include its banked memory), and 8 Native Banks, from 1-8, which would give the bulk of the benefit of having Native Banks. After all, the Appl2GS shipped with 256KB, 512KB and 1MB of RAM, with additional RAM up to 8MB in RAM expansion boards (and mostly used as RAMdisk).

Seriously, I would be perfectly fine with the GS giving 2MB to low RAM and the Native Banks, making 4MB when the High RAM is includes, and using the remainder for seven 4MB "slots" of ShadowROM and/or Cartridge RAM.

Note that +5v versions of all of those parts are available, saving in the voltage transition support that drive up the BOM cost of using an FPGA on a daughter-board in a +5v socket.

After looking at it, one might think that the main 64KB memory map living in Bank0 means that it would "notch out" 64KB of the SRAM, but that is not the case ... the first three bits of the data bus would be latched to provide the high three address lines for the Native Bank RAM on the daughterboard, but the fourth bit is latched to contribute to the select between the main 64KB over the socket pins and the daughterboard RAM. If all four are zero, the main board data bus talks to the 65816, and if any are one, the daughterboard SRAM talks to the 65816. So banks 9-15 access the same RAM as banks 1-7, but bank 0 goes to the main board, and bank 8 goes to the daugherboard.

It might not need all 64 of the cores of the ATF1504, but the ATF1504 has 32 I/O pins, so it has plenty to put in a directional transceiver between the socket data pins and the internal data bus of the daughter-board. It also supports In-Service Programming via JTAG (while the smaller ATF750 does not support), so if a populated board is ordered, the programming of the ATF1504 doesn't have to be shared with the company making the board, and it can be programmed by an inexpensive USB to JTAG cable.
Post Reply