X8 memory layout

[pzembrod]

@The 8-Bit Guy @Frank van den Hoef

Hi David, hi Frank, (taking this topic off the "Change of product direction, good and bad news!" thread as @TomXP411 rightly suggested)

it's cc64's author here. Can I ask a question about the X8's RAM layout? Where do the 64K live? Is there RAM underlying the ROM, C64-style? Are the 24K RAM that aren't needed for $0000-$9EFF mapped in as 3 RAM banks at $A000-BFFF? Are there just regular 8K mapped in at $A000-BFFF, as in: just 1 bank?


I'm asking because the base RAM from $0800-$9EFF turns out to be the limiting factor for further development of cc64, and I'm thinking about how to use banked RAM for code to overcome that limit; if banked RAM isn't available, then that would cap cc64 development on the X8. And even now, just compiling cc64 on the X16 needs one bank at $A000 to be present.



Cheers

/Philip

[BruceMcF]

1 hour ago, pzembrod said:

@The 8-Bit Guy @Frank van den Hoef

Hi David, hi Frank, (taking this topic off the "Change of product direction, good and bad news!" thread as @TomXP411 rightly suggested)

it's cc64's author here. Can I ask a question about the X8's RAM layout? Where do the 64K live? Is there RAM underlying the ROM, C64-style? Are the 24K RAM that aren't needed for $0000-$9EFF mapped in as 3 RAM banks at $A000-BFFF? Are there just regular 8K mapped in at $A000-BFFF, as in: just 1 bank?


I'm asking because the base RAM from $0800-$9EFF turns out to be the limiting factor for further development of cc64, and I'm thinking about how to use banked RAM for code to overcome that limit; if banked RAM isn't available, then that would cap cc64 development on the X8. And even now, just compiling cc64 on the X16 needs one bank at $A000 to be present.



Cheers

/Philip

Yes, I have a similar issue for xForth ... as a best case, if it is simply three 8K banks, one of them used by the system, that scratches one of the uses of the CX16 banks I have sketched out (where I am waiting for the official release of the emulator to be updated to the Proto#3 bank registers), but leaves the other two live.

[Wavicle]

14 hours ago, pzembrod said:

@The 8-Bit Guy @Frank van den Hoef

Hi David, hi Frank, (taking this topic off the "Change of product direction, good and bad news!" thread as @TomXP411 rightly suggested)

it's cc64's author here. Can I ask a question about the X8's RAM layout? Where do the 64K live? Is there RAM underlying the ROM, C64-style? Are the 24K RAM that aren't needed for $0000-$9EFF mapped in as 3 RAM banks at $A000-BFFF? Are there just regular 8K mapped in at $A000-BFFF, as in: just 1 bank?


I'm asking because the base RAM from $0800-$9EFF turns out to be the limiting factor for further development of cc64, and I'm thinking about how to use banked RAM for code to overcome that limit; if banked RAM isn't available, then that would cap cc64 development on the X8. And even now, just compiling cc64 on the X16 needs one bank at $A000 to be present.



Cheers

/Philip

I'm not in any fashion related to the dev team, so take with a grain of salt, but going by the Verilog design for X8 published last December:

The 64K of RAM lives at address $0000-$FFFF, with a few exceptions. RAM banking only applies to VRAM which has 256 pages of 256 bytes mapped in at $0400. Sprite, PSG, and Palette RAM live in the $0500 page; and $0600-$0617 (24 bytes) are used for general hardware control and IO (e.g. VRAM bank select is at $0605). The only "ROM" is a "Boot ROM" overlay at the top two pages ($fe00-$ffff) and can be disabled / turned into normal RAM by, I think, clearing bit 3 of $0602 (can't quite tell which due to the lateness of the hour, but it looks like the logic is inverted in the design where it is labeled "bootrom_dis", so I would imagine that bit is functionally "bootrom overlay enabled").

$0000-$03ff, and $0618-$fdff are always RAM and writes to $fe00-$ffff are always written to RAM but vary their read behavior depending on what the bootrom overlay bit's value is. Presumably the bootrom's job is to fetch the OS kernel from SPI and write it into RAM; it should then disables the bootrom overlay and execute entirely out of RAM.

[BruceMcF]

1 hour ago, Wavicle said:

I'm not in any fashion related to the dev team, so take with a grain of salt, but going by the Verilog design for X8 published last December:



The 64K of RAM lives at address $0000-$FFFF, with a few exceptions. RAM banking only applies to VRAM which has 256 pages of 256 bytes mapped in at $0400. Sprite, PSG, and Palette RAM live in the $0500 page; and $0600-$0617 (24 bytes) are used for general hardware control and IO (e.g. VRAM bank select is at $0605). The only "ROM" is a "Boot ROM" overlay at the top two pages ($fe00-$ffff) and can be disabled / turned into normal RAM by, I think, clearing bit 3 of $0602 (can't quite tell which due to the lateness of the hour, but it looks like the logic is inverted in the design where it is labeled "bootrom_dis", so I would imagine that bit is functionally "bootrom overlay enabled").



$0000-$03ff, and $0618-$fdff are always RAM and writes to $fe00-$ffff are always written to RAM but vary their read behavior depending on what the bootrom overlay bit's value is. Presumably the bootrom's job is to fetch the OS kernel from SPI and write it into RAM; it should then disables the bootrom overlay and execute entirely out of RAM.

So it's like a 6502 version of a classical 64K CP/M 2.2 system.

So the Kernel will be in RAM at the top, don't overwrite it if you want to use it, Basic below it, from the basic load point to the bottom of the basic interpreter code is the basic program and variable space. If you have a program that doesn't use Basic, use the RAM holding the Basic interpreter if you want. Calling the system cold start reloads the basic again. Or cycling power.

That also answers the question of how much simulated ROM: 512 bytes. 

That all sounds like fitting everything into the same logic resource as Vera has available plus the existing 128kB internal RAM. So it's sounds like it's the thing.

[x16tial]

1 hour ago, Wavicle said:

I'm not in any fashion related to the dev team, so take with a grain of salt, but going by the Verilog design for X8 published last December:



The 64K of RAM lives at address $0000-$FFFF, with a few exceptions. RAM banking only applies to VRAM which has 256 pages of 256 bytes mapped in at $0400. Sprite, PSG, and Palette RAM live in the $0500 page; and $0600-$0617 (24 bytes) are used for general hardware control and IO (e.g. VRAM bank select is at $0605). The only "ROM" is a "Boot ROM" overlay at the top two pages ($fe00-$ffff) and can be disabled / turned into normal RAM by, I think, clearing bit 3 of $0602 (can't quite tell which due to the lateness of the hour, but it looks like the logic is inverted in the design where it is labeled "bootrom_dis", so I would imagine that bit is functionally "bootrom overlay enabled").



$0000-$03ff, and $0618-$fdff are always RAM and writes to $fe00-$ffff are always written to RAM but vary their read behavior depending on what the bootrom overlay bit's value is. Presumably the bootrom's job is to fetch the OS kernel from SPI and write it into RAM; it should then disables the bootrom overlay and execute entirely out of RAM.

Thank you for this, but I'm still baffled why would couldn't have gotten this on the first day.

But anyway, $0000 to $00ff is of course zero page, $0100-$01ff is stack, $0200-$03ff is going to be basic/kernal variables, the rest as you mentioned.  I'm gonna guess basic program storage still starts at $0800, leaving $0618-$07ff as a free/ML area, so $0800 to $9fff (38912 bytes), unless that 512 bytes of Boot ROM pushes the Kernal and BASIC down to $9e00, but even so, that's 38,400 bytes for BASIC, which is what you'd expect.  Not using BASIC would then give you a contiguous block $0618 - $bdff, 47080 bytes.

[BruceMcF]

There’ll be some working out how far down the Kernel functions they actually use reside to squeeze out some more space.

Since the bootrom is a read-only overlay, it is likely it loads the basic/kernel code all the way to $FFFF before it turns itself off. Just make sure that the instruction waiting to be executed when the bootloader turns off is the call to start Basic.

[pzembrod]

10 minutes ago, x16tial said:

Thank you for this, but I'm still baffled why would couldn't have gotten this on the first day.

I feel you may want to dial it down a bit. Give them a break!

10 minutes ago, x16tial said:

But anyway, $0000 to $00ff is of course zero page, $0100-$01ff is stack, $0200-$03ff is going to be basic/kernal variables, the rest as you mentioned.  I'm gonna guess basic program storage still starts at $0800, leaving $0618-$07ff as a free/ML area, so $0800 to $9fff (38912 bytes), unless that 512 bytes of Boot ROM pushes the Kernal and BASIC down to $9e00, but even so, that's 38,400 bytes for BASIC, which is what you'd expect.  Not using BASIC would then give you a contiguous block $0618 - $bdff, 47080 bytes.

Let's wait for Frank or David to chime in, but if Wavicle is right, then I'd rather expect the BASIC interpreter to live from $8000-$BFFF - unless I'm mistaken the extended X16 BASIC is 16k; at least it lives in a 16k ROM bank.

[x16tial]

15 minutes ago, pzembrod said:

Let's wait for Frank or David to chime in, but if Wavicle is right, then I'd rather expect the BASIC interpreter to live from $8000-$BFFF - unless I'm mistaken the extended X16 BASIC is 16k; at least it lives in a 16k ROM bank.

Of course what I said isn't authoritative, and should be confirmed or corrected. 

Edit: yes, if BASIC is 16K, that would put it at $8000, or $7e00, adjusting for the Boot ROM.  Leaving then 30208 bytes for BASIC RAM.

[BruceMcF]

Yes, the Kernel may not have all of the CX16 code, so it may be less than a full 16KB. The original C64 KERNAL was under 7KB, after all, with the first 1KB+ of the "KERNAL ROM" holding spillover code for Basic.

For instance, I don't think there is an IEC port, so all the IEC Kernal code (and a number of IEC specific kernel calls) might be omitted.

[Wavicle]

9 hours ago, BruceMcF said:

Yes, the Kernel may not have all of the CX16 code, so it may be less than a full 16KB. The original C64 KERNAL was under 7KB, after all, with the first 1KB+ of the "KERNAL ROM" holding spillover code for Basic.



For instance, I don't think there is an IEC port, so all the IEC Kernal code (and a number of IEC specific kernel calls) might be omitted.

(Insert same non-authoritative source disclaimer here.)

Expansion options for the X8 are very limited. There are no VIAs in the design. USB seems to be the only general purpose IO interface, but I'm not certain that it is reasonable to use for anything beyond a keyboard, mouse, or joystick. USB host controller software is not an area I have much experience in.

There is one SPI interface and two chip select lines: one for the flash ROM; and one for the SD card. The SPI CS lines can be controlled by the CPU through two bits in one of the IO registers. Setting the register bits to 'b01 asserts the SD select, 'b02 asserts the flash select, 'b00 and 'b11 will deassert both. It should be possible to attach an external SPI GPIO expander (e.g. MAX7301AAX) by ORing the two CS lines together and using that as the GPIO expander's CS wire -- provided the SPI and CS wires are accessible.

Ideally, we'd have two available pins and could either bit-bang I2C or use the FPGA's built-in I2C hard IP. Some possibilities for pins to repurpose:

• 
  There is one possibly unused pin; it is not routed to anything internally and cannot be used by software.
  


• 
  One pin drives an LED and is internally connected to the SPI busy signal, it effectively acts as a disk activity light.
  


• 
  One pin is connected to a button and appears to be used as a "soft reset" which resets the designed components in FPGA but not the FPGA itself (i.e. the FPGA doesn't have to bootstrap its configuration from flash after pressing this button).
  


• 
  Two pins are dedicated to a debug serial interface which is internally connected to a UART driver and accessible to software via IO registers. This seems like an attractive candidate for dual-purposing as both a debug UART and I2C, mode selectable with a bit in an IO config register.