NoRecess - Advanced memory usage for 128Kb-based Amstrad CPCs

[NewsBot]

Advanced memory usage for 128Kb-based Amstrad CPCs
4 March 2011, 7:21 pm

For years, I used poor memory design scheme with my programs to adress the extended 64Kb of RAM - it was time to learn more about other available options. This article will let programmers understand the benefits of using &C1, &C2 and &C3 modes of the Gate Array. You can read it here (also added in Articles section).

Source: NoRecess {the website} - Blog

[TFM]

Nice article

Further on.. &C3 allows to read (and write) the standard screen ram (block 3) relocated beginning at &4000 using routines located in a ROM (beginning at &C000)

[Sykobee (Briggsy)]

Thanks for the article. Very interesting to see how that bank switching works.

[norecess]

Glad reading you. I'm happy to see I was not the only one fearing these modes before 

[andycadley]

Nice article, I'm a big fan of those memory configurations myself - they're a little unusual compared to the simpler arrangement used by the other configurations, but offer so much more when writing 128K code.

[Axelay]

A timely article     I've been thinking about the possibilities with &C1-&C3  and they are certainly interesting, but I'm not convinced you don't just end up swapping one problem for another.


I mean if I use bank 0 for the core loop location and bank 2 & 3 for the two screens, then between C0 and C4-7 I can access every other bank while having access to the screens - clumsily.  There's just the one "constant" 16k ram bank in 0, and bank 1 can only acquire data from bank 7 without 'double handling', making bank 1 potentially difficult to utilize.


On the other hand, using bank 7 for the core loop means I could use bank 1 & 3 for screens, and always have access to bank 0,2 & 7 while accessing the screens.  Which feels like an improvement on the previous model because I don't pointlessly have access to both the screens simultaneously, but now the only way I can get data from banks 4-6 to the screens would be to pass it through a buffer in bank 7 which brings me back to the kind of double handling problem I'd have in the first approach, only worse, I think.


At least, that's my take on it, but perhaps I'm missing something?

[Optimus]

I've just read the article and understood further those C1-C3 modes. Though, I am in a dilema whether to use the classic mode or the advanced mode.


The advantages of the C1-C3. I haven't noticed this before even if we might have dicussed it. You get bank 1 & 3 in &4000, so this could work nicely as vram switching while my vram_address tables for example would look at &4000 and I won't need to make two of them, one with &4000 address and one with &C000 data. That's neat. And from bank 7 I can always look at those two vram pages and switch the modes, works like real double buffering switch. Also I can see 0 and 2. Cool!


I can't think of what to do with mode &C2 now. The thing is, I never ever needed in any of my project to copy data between the extra banks. I just placed my extra data there, fixed and switched them to &4000 (with the classic model). Those extra data were either massive unrolled codes that are routines which render to the screen. Or several graphics data that I want to bring in &4000 so that my code which might be in bank0 or bank2 will use to render something on the screen. I always wanted to have access to the screen.


Now, with the new C1-C3 modes, I can see both page1 and page3 vrams and the rest have to be on 0,1 and 7. So, I have code and data on these three that render on the screen. With the old scheme, if my code was at 0 and I used bank2 and bank3 as vram pages, I could bring 4,5,6,7 as data and also have some initial data or maybe code in bank1, so in a sense I have visibility at both screens and can bring directly five 16kb pages of data to use for rendering. With the advanced model I only have three 16kb pages to load with data that I directly use. I can only switch to C2 but then I have to do what Axelay said, double the ammount of work to bring stuff (also, not good in a game I want to run in realtime)


So, the new model is appealing because of double buffer switching looking at the same address and access to all banks from bank7, but there are some things missing from the way I worked with the old model. If I give it more thought, I might think of a nice framework to be able to work easier with the new model and how I could fit things from my current model to the new one.

[redbox]

With the old scheme, if my code was at 0 and I used bank2 and bank3 as vram pages, I could bring 4,5,6,7 as data and also have some initial data or maybe code in bank1, so in a sense I have visibility at both screens and can bring directly five 16kb pages of data to use for rendering. With the advanced model I only have three 16kb pages to load with data that I directly use.

I found NoRecess's article very interesting and too liked the idea of using the 'advanced' scheme for double buffering etc.  But as you and Axelay say, you have the problem with &C2 of having to copy 4,5 and 6 into 7 to get it back to the screen in 1 and 3.

But your suggestion is nice Optimus and think I will use it for my new 128kb demo 

[norecess]

Great. This article made you think more about these memory schemes. That was the aim! 

[arnoldemu]

Great. This article made you think more about these memory schemes. That was the aim! 

The only correction I have is that the gate-array doesn't handle ram paging, well at least not in the standard CPC.
It's the PAL16L8 that does it.
In the Plus and costdown it *is* handled by the asic/gate-array.
minor point I know

Another point is that these schemes work only with 100% dk'tronics ram expansions, and some of the ram expansions (e.g. Yarek's may not be 100% dk'tronics compatible). Only way to know for sure is to examine the schematics or run some tests.

[TFM]

Dobbertin works
SF2 works
Inicton works partially

[Optimus]

Now I am thinking it, one could combine both memory models. If one wants to stick to the classic model, one can still switch and use easilly the other one for other tasks. I have my code in bank 0, I could just switch to C1 or C3 while my code runs and then have some other code module in bank7 where I jump to do what I need. It could be memory block copy routines if I ever need to move stuff between the banks or it could be something else. For example I am thinking for my wolfenstein game, if I need the memory, it could be a nice idea to have the game logic code in bank7 for use in the advanced model and keep the rendering code in bank0 for use in the classic model. That would be cool. I only need to see how easy it will be to work with different modules of code that one needs to call the other after switching.

[rpalmer]

hello all,

All this talk of using the extra memory... wow

Well i have developed the RAM disk driver in the HDOS Drivers ROM source which allows for both the standard 512K dk'tronics ram disk as well as the Yarek 4096K memory expansion.

If people were to look at the code one can easily see how the yarek expansion works.

Hope this is helpful for all those who wish to understand memory usage (from a RAM disk point of view) .

Regards
Ray

[arnoldemu]

Dobbertin works
SF2 works
Inicton works partially

Thanks.

[TFM]

Now I am thinking it, one could combine both memory models. If one wants to stick to the classic model, one can still switch and use easilly the other one for other tasks. I have my code in bank 0, I could just switch to C1 or C3 while my code runs and then have some other code module in bank7 where I jump to do what I need. It could be memory block copy routines if I ever need to move stuff between the banks or it could be something else. For example I am thinking for my wolfenstein game, if I need the memory, it could be a nice idea to have the game logic code in bank7 for use in the advanced model and keep the rendering code in bank0 for use in the classic model. That would be cool. I only need to see how easy it will be to work with different modules of code that one needs to call the other after switching.

There are no different "memory models". The CPC just has different configurations. And to use one of them doesn't exclude the other. Just use the banking configuration, which is the most efficient for your task :-)

[TFM]

Thanks.

You are welcome, Sir :-)   And have a great weekend all together!

[matahari]

Hello,

In this great article, NoRecess mentions that pure 32KB page-flipping is possible by making use of the first 64Kb of memory as VRAM.

Assuming the code is running in Bank7 and the screen address starts from Bank0; when we use &C1 and &C3 for memory config, only Bank1 and Bank3 are switched. Bank0 (first bank of 32k screen) remains the same! In fact, we need to switch 2 Banks at a time for 32KB page-flipping, right?

Does NoRecess mean something like this?

&C1 => 32KB Screen = Bank0 + Bank1
&C3 => 32KB Screen = Bank3 + Bank2

Kind Regards,

[norecess]

Hi,


I'm not sure to understand exactly what is your point.


But don't forget that whatever you do, only the first 64Kb will be displayed - bank 0 to bank 3 (included). If you have Bank C7 at &C000 (such as used with &c1, &c2 and &c3), this memory data won't be shown on screen.

[matahari]

Hi NoRecess,

I'm not sure to understand exactly what is your point.

Well, I am just trying to understand what you mean by "32KB page-flipping". Sorry for bothering 

What I understand (or misunderstand) is, we can "double buffer 2 different overscanned 32KB screens" by using all 4 banks in the first 64KB. Am I getting it right?

But don't forget that whatever you do, only the first 64Kb will be displayed - bank 0 to bank 3 (included). If you have Bank C7 at &C000 (such as used with &c1, &c2 and &c3), this memory data won't be shown on screen.

Yes, I'm aware of that. Thank you.

[norecess]

Yes, you are right. Now I guess it's time to practice for real 

[matahari]

Yes, you are right. Now I guess it's time to practice for real 

That's exactly what I am working on it 

It's very easy to set the memory config and switch between double buffers, but unfortunately very difficult to feed these banks with sprite/gfx data from other banks (except Bank7, of course). Assuming the code is executing in Bank7, there is no "direct" way of transfering data from Bank4-5-6 to Bank0-1-2-3. Just trying to figure out how things can be done "indirectly" via minimum amount of bank switching + data transfer...

Thanks again for the nice article, NoRecess.
Keeps us brainstorming... 

[TFM]

You can directly transfer data from 4-5-6-7 to 0-2-3 using &C4,&C5,&C6,&C7.

[matahari]

Assuming the code is executing in Bank7, there is no "direct" way of transfering data from Bank4-5-6 to Bank0-1-2-3.

[TFM]

You need subroutines in different blocks. If you arrange them in a smart way, it's not a disadvantage.

So, you can work with the first 64 KB using as V-RAM only.

However 32 KB are enough, for example:


Giana Sisters Clone for Amstrad CPC - Level 2

[TomEtJerry]

Hi,

I have just discovered that topic :-). To answer to Optimus, &C2 can be useful sometimes, mostly for cracking purposes :-). But, it has been used on the Hacker ROM (Alternate mode) and on my little music player, TSP 1.4. On that tool, it allows the use of commercial music that are located in system memory areas.

T&J/GPA