Commander X16

The memory location of bank 0, address  $A000 till $A7FF is utilized or preserved by the kernal ROM.

Wouldn't it be better than this zone of memory would be moved to the upper area of the bank 0, for example to $B800 - $BFFF.

That would allow larger program files to be loaded inside the memory as a sequential file.

Because the address $A000 till $A7FF prevents program files to be loaded including the allocation of memory from $A800 to $BFFF.

I think the design of the CX16 can still be optimised before it is too late. 

I know this creates backward compatibility issues with programs written in assembly or basic, but if the change is not done now then it will always be like this forever.

What are your views?

Sven

The "problem" is that IO space is between low memory and banked RAM. You really can't read across that window anyway.

In fact, doing a bulk load is better with the status quo, as you can start loading at 00:B000 and automatically continue through the later banks.

On 3/26/2022 at 8:30 AM, Scott Robison said:

The "problem" is that IO space is between low memory and banked RAM. You really can't read across that window anyway.

I see! Now that is an answer.  That explains why. Is the hardware enforcing to address IO from $A000 onwards or is it because of kernal design of the CBM "roots".

On 3/26/2022 at 2:21 PM, SlithyMatt said:

In fact, doing a bulk load is better with the status quo, as you can start loading at 00:B000 and automatically continue through the later banks.

True. That requires you however to have separate files to be loaded at runtime in memory.

On 3/26/2022 at 1:12 PM, svenvandevelde said:

True. That requires you however to have separate files to be loaded at runtime in memory.

If you are going to be using banked RAM, that's pretty much a requirement, unless you are populating that memory strictly programmatically.

On 3/26/2022 at 6:15 PM, SlithyMatt said:

If you are going to be using banked RAM, that's pretty much a requirement, unless you are populating that memory strictly programmatically.

I do both. In bank 0 from A800 till BFFF I store the data segments that have the fixed tables for the sprite control logic. In bank 1 I want to keep the fixed tables to control the tile slots (working on it now). I have my own loader which loads in banked ram using my own memory manager for dynamic memory allocation.

On 3/26/2022 at 11:08 AM, svenvandevelde said:

I see! Now that is an answer.  That explains why. Is the hardware enforcing to address IO from $A000 onwards or is it because of kernal design of the CBM "roots".

I've not looked at the kernal to know if it is smart enough to fail a load that tries to use IO space or if it will just load bytes into IO space and corrupt the machine state.

On 3/26/2022 at 1:19 PM, svenvandevelde said:

I do both. In bank 0 from A800 till BFFF I store the data segments that have the fixed tables for the sprite control logic. In bank 1 I want to keep the fixed tables to control the tile slots (working on it now). I have my own loader which loads in banked ram using my own memory manager for dynamic memory allocation.

You should not use Bank 0.  Bank 0 is reserved for system use. Use Bank 1 through 63 or 255 (depending on how many RAM chips are installed).

On 3/26/2022 at 6:33 PM, Scott Robison said:

I've not looked at the kernal to know if it is smart enough to fail a load that tries to use IO space or if it will just load bytes into IO space and corrupt the machine state.

So is this space between A000 and A7FF not available due to hardware defined addressing? (address line logic on the board).