Jump to content
  • 0

XC16 Memory location bank 0 address $A000 till $A7FF


svenvandevelde
 Share

Question

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

Link to comment
Share on other sites

Recommended Posts

  • 0
  • Administrators
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 ;-))

  • Like 1
Link to comment
Share on other sites

  • 0
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.

Edited by BruceMcF
  • Like 1
Link to comment
Share on other sites

  • 0
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. 

Link to comment
Share on other sites

  • 0
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).

Link to comment
Share on other sites

  • 0

Came late to this thread, but I would like to add that the top half of bank 0 is used by DOS for things such as LOAD/SAVE buffer space, current file offset pointers, etc.

It's definitely NOT clear to use just because Kernal doesn't use it.

And as for LOAD's behaviors:

If you start a LOAD anywhere, it will happily overwrite ZP, the stack, IO, ROM, etc. As of R39, whatever RAM bank is active when LOAD is called is the one which will be used for LOADs that go into banked memory. Whenever a LOAD crosses the BFFF -> C000 boundary, it increments the bank number and wraps back down to A000, and continues. If the inc(bank#) overflows, it fails (I think - I forget whether I made it check that or not)

When LOAD finishes, it returns the address of the next byte in memory above the last one loaded, and leaves the updated RAM bank active.

So if you were to load exactly 8K into $A000 using Bank 3, then it would return $A000 as the "next address" and Bank 4 would be active.

Link to comment
Share on other sites

  • 0
On 3/30/2022 at 3:57 PM, Edmond D said:

Remember the simple days, when you typed LOAD,  pressed play on the dataset, and waited? 😄

 

Back when you started loading a big game before you went to school so that it would be almost finished loading by the time you got home. 😄

  • Like 1
Link to comment
Share on other sites

  • 0
On 3/30/2022 at 5:02 PM, Scott Robison said:

Back when you started loading a big game before you went to school so that it would be almost finished loading by the time you got home. 😄

With only 3K the VIC 20 didn't take a whole school day. When at school with a 32Kb PET, we'd stick to one game to avoid wasting time with waiting, as we'd be asked to do school work while loading.

Link to comment
Share on other sites

  • 0
On 3/30/2022 at 8:03 PM, Edmond D said:

With only 3K the VIC 20 didn't take a whole school day. When at school with a 32Kb PET, we'd stick to one game to avoid wasting time with waiting, as we'd be asked to do school work while loading.

Well, even a C64 didn't take a full school day. It's just my version of walking to school uphill in waist deep snow both ways.

  • Like 1
Link to comment
Share on other sites

  • 0
On 3/30/2022 at 11:33 PM, Scott Robison said:

Well, even a C64 didn't take a full school day. It's just my version of walking to school uphill in waist deep snow both ways.

What I find hilarious about this analogy is that my preferred bus stops for school were, in fact, on opposite sides of our family's house in the morning vs. the evening, and our house was, in fact, located on a hillside. So I did literally walk uphill (a very short, short ways) both going to the school (bus) and coming from it. And since I grew up in a snowy, wintry part of the world, that did sometimes mean braving waist-high snow (while trudging through our backyard), because it meant I could get home in time for the start of my favorite afternoon cartoons, rather than being stuck on the bus for another 30 minutes while it looped its way around.
#firstworldproblemsforkids

Edited by StephenHorn
  • Like 1
  • Haha 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use