Commander X16

Considering that even throwaway computers these days have 4 GByte of DRAM. It seems kind of limiting that the machine would be physically limited to 2 MByte because of the lack of address lines. Even the REU can handle 16 MB by looking at layout of its DMA registers. So the critical part is to have a proper register layout and secondly to have the pins for the higher address bit present or reserved.

One way to make cheap "SRAM" can be to put a DDR2 chip together with an FPGA or CPLD on a DIL chip socket PCB. And exploit that they are most likely way faster than the host bus. So that from the perspective of the X16 its a SRAM. The time to make a RAS+CAS cycle  and additional pipeline delays would tell how fast this can work.

 

Psst. More traces on the motherboard = more interference, more capacitance, and more cost to manufacture.

And a 6502 only has 16 address lines. The banking system we've got supports as many as 256 chunks of 8K of RAM that can be switched. If you add more pages, how are they going to be chosen? If you make the page bigger, that interferes with the size of either the ROM above it, or causes the I/O to be pushed down lower (and the non-banked RAM also gets smaller).

Why would you want to completely redesign the entire system this way, and why would you think that the design team hadn't already given this thorough consideration before coming to the decision to do things the way they're being done?

Reminder too that the machine will have an expansion bus, so many things can be added after the fact if one is so inclined

On 10/20/2022 at 9:43 PM, kelli217 said:

The banking system we've got supports as many as 256 chunks of 8K of RAM that can be switched. If you add more pages, how are they going to be chosen?

Reserve addresses in the memory map right next to the current memory page select. Just like the REU have all the address select registers in sequence.

https://codebase64.org/doku.php?id=base:reu_registers

MOS 8726: $DF00 register 4,5,6 combines to a 24-bit selection of which REU address to use. (little endian)

https://github.com/commanderx16/x16-docs/blob/master/X16 Reference - 07 - Memory Map.md

Change from:

$0000   Current RAM bank (0-255)

To:

$0000   Current RAM bank MSB 23 .. 16

$0001   Current RAM bank bits 15 .. 8

$0002   Current RAM bank LSB 7 .. 0

Enables selecting memory page using big endian ordering which make hex dumps easier to read. By having the address sequence reserved, future expansions will be possible in a compatible manner. No need for a physical implementation right now. When future expansion is desired the hardware simple implements address decoding for these positions.

 

On 10/20/2022 at 9:34 PM, neutrino said:

Change from:



$0000   Current RAM bank (0-255)



To:



$0000   Current RAM bank MSB 23 .. 16



$0001   Current RAM bank bits 15 .. 8



$0002   Current RAM bank LSB 7 .. 0

$0001 is used for ROM bank switching, and $0002 is currently reserved for the KERNAL's "virtual registers".  Taking over 2 more addresses for RAM switching is more than likely going to eat away at the user allocated zero page addresses, which a lot of people are taking advantage of.  It also makes selecting a bank as complicated as selecting VERA addresses.  Hardware and cost issues aside (which is already being very dismissive), at this stage in the game that's going to break a lot of people's code.

Also...I'm not sure I understand the point.  If we are okay with a more complicated selection process for HI RAM, why not just do what @x16tial suggests and have this be an optional hardware component on the expansion bus?  I mean, you're already suggesting that address selection works like an expansion unit...why not just make it an expansion unit?  And frankly, even then I don't know if this much RAM is needed on what is effectively a "toy" computer whose design goals align more with simplicity than utility.  What use case is important enough to delay manufacturing, break people's software, and make it more difficult to teach my 7 year old daughter how to switch RAM banks?  I'm just not seeing it.

The point is to have the RAM page selector addresses in sequence, an orthogonal address structure. Also only people that want to use more than 2 MB would need to bother with the MSB registers because the Kernal would set these to zero at boot.

An expansion board solution would necessitate "special addresses" etc and make address selection complicated should anyone ever want more than 2 MB.

 

On 10/20/2022 at 10:09 PM, neutrino said:

The point is to have the RAM page selector addresses in sequence, an orthogonal address structure. Also only people that want to use more than 2 MB would need to bother with the MSB registers because the Kernal would set these to zero at boot.



An expansion board solution would necessitate "special addresses" etc and make address selection complicated should anyone ever want more than 2 MB.

Since it's highly unlikely that there will ever be a Commander X16 with more than 2MB of RAM, this is pointless. 

If you want to do something like you describe, using DDR memory, you can't do synchronous access, anyway. DDR uses a different accessing scheme that is designed around larger reads and writes with CPU cache. On a system like this, DDR would be almost unusable without an FPGA to act as an interface controller, which means it's going to have to sit in the expansion address space, regardless. 

 

An FPGA + DDR memory can sit on a piece of PCB attached to a DIL socket acting like a SRAM provided the RAS+CAS+pipeline timing is shorter than the bus cycle of the CPU. Large SRAM are usually quite expensive.

I really feel the issue here isn't technical in the slightest.  We all know there are ways to increase the RAM, yet all of them will delay manufacturing and increase the price.  The one and only question to be answered is "why is this important enough to delay manufacturing and increase the price?"

Without an extremely compelling answer to that question, this whole idea is a non starter.  Do you have a compelling answer?

On 10/20/2022 at 7:34 PM, neutrino said:

Reserve addresses in the memory map right next to the current memory page select. Just like the REU have all the address select registers in sequence.



https://codebase64.org/doku.php?id=base:reu_registers



MOS 8726: $DF00 register 4,5,6 combines to a 24-bit selection of which REU address to use. (little endian)



https://github.com/commanderx16/x16-docs/blob/master/X16 Reference - 07 - Memory Map.md



Change from:



$0000   Current RAM bank (0-255)



To:



$0000   Current RAM bank MSB 23 .. 16



$0001   Current RAM bank bits 15 .. 8



$0002   Current RAM bank LSB 7 .. 0



Enables selecting memory page using big endian ordering which make hex dumps easier to read. By having the address sequence reserved, future expansions will be possible in a compatible manner. No need for a physical implementation right now. When future expansion is desired the hardware simple implements address decoding for these positions.

 

The MOS 8726 had a 19-bit selection of REU address. It did not physically have enough pins to address more than that. The top bit selected the bank and the other 18 were split 9 bits for row and 9 bits for column.

What is the goal with more memory here? Why couldn't a RAM expansion like this work like the REU and DMA from its local storage into X16 main memory? The X16 bus is 8X faster than the C64 bus.