XC16 Memory location bank 0 address $A000 till $A7FF

[Michael Steil]

On 3/27/2022 at 11:23 AM, svenvandevelde said:

And also, I had been noticed that A800 till BFFF was available for use in bank 0 in an earlier post ...

It is NOT available.

[svenvandevelde]

On 3/28/2022 at 7:57 AM, Michael Steil said:

It is NOT available.

Hello Michael, nice to see you around. Thanks for your feedback. So it is clear now. I wanted to post a bit more on this answer because i feel that there is a huge confusion and that people are reacting rather emotionally on it. My question was humble.

[Scott Robison]

On 3/28/2022 at 12:00 AM, svenvandevelde said:

Hello Michael, nice to see you around. Thanks for your feedback. So it is clear now. I wanted to post a bit more on this answer because i feel that there is a huge confusion and that people are reacting rather emotionally on it. My question was humble.

My apologies if I came across in an emotional way. I've just been trying to explain why loading can't cross the $9F00 - $9FFF threshold and how to treat block 0. Your questions were not bad or untoward, and people here can vouch for my ability to lash out at what I find inane (which yours was not). Though I'm trying to be better. ?

[svenvandevelde]

On 3/28/2022 at 8:10 AM, Scott Robison said:

My apologies if I came across in an emotional way. I've just been trying to explain why loading can't cross the $9F00 - $9FFF threshold and how to treat block 0. Your questions were not bad or untoward, and people here can vouch for my ability to lash out at what I find inane (which yours was not). Though I'm trying to be better. ?

Don't worry guys.

Again, as you can see in this thread, I'm re-experiencing my 16 year old wizz kid feeling again at the age of 52, although now using C and more modern equipment.




You see, the reason why i'm coming up with all these strange questions is because i'm digging now deeply into the machine making this game engine.

I got now into the phase of "segmentation"; where to put code, where to put data, how to manage the "memory".

So this brought me to how to construct the prg file and it appears that prg files for the CX16 will never be larger than 48KB, which is ok.

No issue, i just wondered by there was not a continuous RAM space beyond the 48KB border into banked ram 0.

Where I could load into bank 0 pre-initialized data like math (sine) tables, control blocks, "stuff" as part of the prg file.



I'm in a discovery trying to define the strategy to extend this almost working prototype to a working engine with

- levels,

- state machine control

- more graphics

- more tiles

- more event types

- adding enemy fire-

- more bullet types

- defences

- AI control

And sharing my experiences along the way, I have questions, ideas, things I may have understood wrong etc.

This forum is the platform to ask these questions and to share the ideas, right?



The CX16 platform will become great through its users. I don't know how else it would grow, right?

 

So to come back to the topic, it seems that the design of the game will need to apply dynamic loading of memory in the banks, applying the banks during runtime.

It will need to be done by creating several bin files that are loaded dynamically into the banks as the game execution progresses (loading stages).

I'm using banks already extensively, and the demo shows, all the sprites, tiles and control data is loaded in the banked memory and then gradually copied into the VERA when needed.

 

Sven

 

[rje]

I have a 400K data file I load into banked RAM.  I've adapted nicely to using banks -- I can externalize a lot of data that way.

 

[Ed Minchau]

On 3/28/2022 at 12:38 AM, svenvandevelde said:

I'm in a discovery trying to define the strategy to extend this almost working prototype to a working engine with

- levels,

- state machine control

- more graphics

- more tiles

- more event types

- adding enemy fire-

- more bullet types

- defences

- AI control



And sharing my experiences along the way, I have questions, ideas, things I may have understood wrong etc.

This forum is the platform to ask these questions and to share the ideas, right?



The CX16 platform will become great through its users. I don't know how else it would grow, right?



 



So to come back to the topic, it seems that the design of the game will need to apply dynamic loading of memory in the banks, applying the banks during runtime.

It will need to be done by creating several bin files that are loaded dynamically into the banks as the game execution progresses (loading stages).



I'm using banks already extensively, and the demo shows, all the sprites, tiles and control data is loaded in the banked memory and then gradually copied into the VERA when needed.

 



Sven

 

Yes, this is exactly the right place to ask these questions. 

Loading 8kb files as you need them can be done pretty quickly.  You can even start loading them a few at a time as the player passes checkpoints, to reduce delays between levels. And an initial splash/title screen can be loaded first and displayed while the program loads the rest of its initial files.

[Michael Steil]

On 3/28/2022 at 8:00 AM, svenvandevelde said:

Hello Michael, nice to see you around. Thanks for your feedback. So it is clear now. I wanted to post a bit more on this answer because i feel that there is a huge confusion and that people are reacting rather emotionally on it. My question was humble.

Now that your confusion has been cleared up, do you have a suggestion where in the Programmer's Reference Guide this should be made clearer? Feel free to send a pull request. (This applies to anyone ;-))

[BruceMcF]

On 3/28/2022 at 2:38 AM, svenvandevelde said:

... You see, the reason why i'm coming up with all these strange questions is because i'm digging now deeply into the machine making this game engine.



I got now into the phase of "segmentation"; where to put code, where to put data, how to manage the "memory".

So this brought me to how to construct the prg file and it appears that prg files for the CX16 will never be larger than 48KB, which is ok.

No issue, i just wondered by there was not a continuous RAM space beyond the 48KB border into banked ram 0.

Where I could load into bank 0 pre-initialized data like math (sine) tables, control blocks, "stuff" as part of the prg file.



...



...



So to come back to the topic, it seems that the design of the game will need to apply dynamic loading of memory in the banks, applying the banks during runtime.

It will need to be done by creating several bin files that are loaded dynamically into the banks as the game execution progresses (loading stages).Don

Don't confuse the space at $A000-$BFFF with "Bank 0". WHICHEVER Bank is selected will appear in that space. Bank 1 is at $A000-$BFFF when you set the BANK to 1. Bank 31 is at $A000-$BFFF when you set BANK to 31.

So you don't actually NEED dynamic loading as long as the HighRAM contents fit into the available HighRAM. (Though you could USE dynamic loading if you wish.)

In other words, you only need TWO PRG files. One contains what you are loading into Low RAM, and the other contains what you are loading into a contiguous series of Banks. It's just that the Bank you start should be a Bank bigger than 0, because Bank 0 is reserved for system use.

If you load 128KB into Bank 8, that will be 16 banks worth of content, so it will be loaded into Banks 8 through 23.

And that is another reason why "spilling over" is not a great fit to the HighRAM window system ... the HighRAM file needs to be organized so that it "knows" that everything within an 8KB segment is "local" to each other, and anything more than 8KB away is "in a different bank". By contrast, Low RAM is a normal, old fashioned, "start at $000 and count up" RAM space.

[svenvandevelde]

On 3/28/2022 at 11:17 PM, Ed Minchau said:

Loading 8kb files as you need them can be done pretty quickly.  You can even start loading them a few at a time as the player passes checkpoints, to reduce delays between levels. And an initial splash/title screen can be loaded first and displayed while the program loads the rest of its initial files.

I read exactly my thoughts in your answer. I'm still not there and much to learn further and try things out but your answer confirms I'm on the right path. 

[svenvandevelde]

On 3/28/2022 at 11:26 PM, Michael Steil said:

Now that your confusion has been cleared up, do you have a suggestion where in the Programmer's Reference Guide this should be made clearer? Feel free to send a pull request. (This applies to anyone ;-))

To be honest I checked immediately the md file of the documentation when I read the feedback and it is  documented but it's a bit hidden in the details. To make things concrete, allow me indeed to contribute doing a little update to the MD file and I'll send a pull request. The memory layout is well documented already but it's a bit unclear for novice like me. It might be an idea to add a picture and a short text of the overall memory design at the start, and at the explanation of the ram banks, to clearly indicate that bank 0 is reserved for the cx16 designers and shall not be used. (And explain why).