CPCWiki forum

Hi everyone.

I have a vague memory of reading a post a long time ago regarding the use of the extra 64KB in a 6128, and that it's possible to use different 16KB banks of the extra RAM for double buffering. However I can't find the post where I read that, and I haven't been able to find out how to do it using Google either.

Has anyone done something like this?
Any tips on good uses of the extra 64KB?

I would love to use it in the project I'm working on, but I don't know how.

When I was working on Spellbound & Sly Spy, I used this memento I found on ChibiAkuma website.
Back then, I used the C2 configuration, where the Instruction Pointer would "jump" in extra-ram. It then ran the music player code, with all the music data stored in extra-ram as well. Then it switched back to regular ram. Check out the diagram below.
For a double buffer, I guess you could use the C7 setup, to have RAM7 windowed at offset 4000h, and switch the CRTC reading from C000h to 4000h.

Quote from: ervin on 12:54, 11 February 24and that it's possible to use different 16KB banks of the extra RAM for double buffering.

Please note that you can't use the extra 64K as video memory.

The most common way is to map one of the four additional 16K blocks into the visible memory at #4000-#7FFF with...
OUT #7Fxx,#C4 (maps block 0)
OUT #7Fxx,#C5 (maps block 1)
OUT #7Fxx,#C6 (maps block 2)
OUT #7Fxx,#C7 (maps block 3)
(xx can be everything)

Another possibility is to map block 3 at #c000-#ffff with
OUT #7Fxx,#C1

What is really cool about the CPC is the possibility to map the whole 64K at #0000-#ffff:
OUT #7Fxx,#C2
which was necessary for the large TPA of CP/M Plus.

You can always switch back to the primary 64K with
OUT #7Fxx,#C0

See...
https://www.cpcwiki.eu/index.php/Gate_Array#Register_3_-_RAM_Banking
...for all configurations.

Quote from: Jean-Marie on 15:05, 11 February 24For a double buffer, I guess you could use the C7 setup, to have RAM7 windowed at offset 4000h, and switch the CRTC reading from C000h to 4000h.

The CRTC will still display the content of the primary 64K. It can't access the extra ram.

You don't need extra RAM to use double buffering.
MEMORY &3fff - Now you can switch to display lower screen.
OUT &BDFF,&10 - Now displays lower screen from address &4000, and PRINT and DRAW commands still work on upper screen from &C000.
OUT &BDFF,&30 - Now displays top screen again.
POKE &B7C6,&40 - Now PRINT and DRAW work on lower screen.
POKE &B7C6,&C0 - Now back to top one.

To use RAMDISK, you may switch blocks of 16KB assigned to address &4000.
OUT &7F00, - and as a parameter you specify from 204 to 207 as extra RAM blocks, or number 192, this will restore standard block. However, only the processor sees these blocks and graphics always displays standard block (not the one from the RAMDISK),
even if you do OUT &BDFF,&10 and OUT &7F00,240

Now you need a procedure with LDIR in code to flip entire top screen to the bottom and back.
DATA 21.00,C0,11,00,40,01,00,40,ED,B0,C9 - top screen going down
DATA 21,00,40,11,00,C0,01,00,40,ED,B0,C9 - bottom screen going up
I hope you know what to do with it. :)

But keep in mind that the Gate Array will always only read from the first 64KB. It can't read from the second RAM bank.

You can, of course, use the extra 64K for software buffering of the screen but the main advantage is being able to move more code/data out of the core 64K leaving room for a hardware double buffer.

The "easiest" way to use banked RAM was just to write your game as a multi-loading 64K game and then patch the "load level" routine to pull data out of the extra RAM rather than from tape/disk. Managing the banks to switch code/data in and out on the fly is a bit more complex but perfectly doable if you have a solid grasp on how your memory is laid out (classic mistakes being paging out running code or the stack).

And You can change PAL to NewPAL version.  ;D

https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/banked-video-ram/msg231993/#msg231993

Thanks everyone for your thoughts and info.
It gives me some ideas and things to think about.

You can also use BANKMAN program from your system disk, and USER GUIDE describes how. :)

best way to double buffer is C1, C3. Now you have two screen at the same place &4000-7FFF. BANKs 0,1,2,7 and 0,3,2,7 and work firmware.

Quote from: McArti0 on 08:39, 12 February 24best way to double buffer is C1, C3. Now you have two screen at the same place &4000-7FFF. BANKs 0,1,2,7 and 0,3,2,7 and work firmware.

In my opinion, this configuration is not so practical if you want to use the extra 64kb.

Quote from: gurneyh on 10:58, 12 February 24

Quote from: McArti0 on 08:39, 12 February 24best way to double buffer is C1, C3. Now you have two screen at the same place &4000-7FFF. BANKs 0,1,2,7 and 0,3,2,7 and work firmware.

In my opinion, this configuration is not so practical if you want to use the extra 64kb.

It really depends on what you need the extra RAM for. C2 can work well with this in some situations. Or a small amount of code in RAM0 that access the rest via C4/5/6.

Quote from: McArti0 on 08:39, 12 February 24best way to double buffer is C1, C3. Now you have two screen at the same place &4000-7FFF. BANKs 0,1,2,7 and 0,3,2,7 and work firmware.

This is precisely what I would like to do.
However, since either bank1 or bank3 is not accessible at any one time, I can't figure out how to use one as a back buffer, as the back buffer won't be accessible.

And even then, if I then use C2 in order to bring in data or code from banks 4 to 6, will that mess up the screen display?
(As banks 1 and 3 will be switched out)

Quote from: ervin on 14:15, 12 February 24And even then, if I then use C2 in order to bring in data or code from banks 4 to 6, will that mess up the screen display?
(As banks 1 and 3 will be switched out)

No, RAM banking won't mess up the screen display.

RAM banking only affects the CPU. The Gate Array will always access the first 64KB and always see data at exactly the same position. So if you e.g. set C3, the CPU will see RAM bank 3 at "virtual address" &4000 but the Gate Array will still access the same data at the physical address &C000. If the CPU writes e.g. 255 to &4000, the Gate Array will see that &255 at &C000.

Quote from: eto on 14:39, 12 February 24

Quote from: ervin on 14:15, 12 February 24And even then, if I then use C2 in order to bring in data or code from banks 4 to 6, will that mess up the screen display?
(As banks 1 and 3 will be switched out)

No, RAM banking won't mess up the screen display.

RAM banking only affects the CPU. The Gate Array will always access the first 64KB and always see data at exactly the same position. So if you e.g. set C3, the CPU will see RAM bank 3 at "virtual address" &4000 but the Gate Array will still access the same data at the physical address &C000. If the CPU writes e.g. 255 to &4000, the Gate Array will see that &255 at &C000.

That's very interesting! And certainly not what I expected.

I'll do some experiments.

When you kick off firmware use bank 0 and 1 for soft+data and bank 2 and 3 for screen.

Quote from: ervin on 15:03, 12 February 24That's very interesting! And certainly not what I expected.

Imho it's not very well documented. However these pages helped me to understand it better:

http://norecess.cpcscene.net/advancedmemoryusage.html

https://www.grimware.org/doku.php/documentations/devices/gatearray#memory.mapping.in.the.cpu.address.space

Thanks to everyone's advice and assistance... I've been able to get this working!
I'm using banking schemes C1 and C3, all my drawing code is pointing to 0x4000 and the screen is double-buffered without any flicker between 0x4000 and 0xC000.
Now I need to think of some ways to intelligently use banks 4 to 7 for data and/or code.

Here is my current cpctelera code (it's very much a prototype for bank switching experiments).

#include <cpctelera.h>

void populateYaddress();

void checkInput();
void updateScreen();

void changeVideoMemoryPage();
void ramBankC1();
void ramBankC3();

void printVerticalLine();
void drawTile();

#define SCREEN_BUFFER (u8*)0x4000

const u8* pTile;

u8 ramBank;

u8 x;
u8 y;

__at(0x0200) u8* yAddress[200]; // 400 bytes MUST BE BYTE ALIGNED

__at(0x0400) const u8 tile[16]={ // 16 bytes MUST BE BYTE ALIGNED
    0x44,0x22,0x44,0x22,0xE8,0x99,0xE8,0x99,0x22,0x44,0x22,0x44,0x88,0x40,0x88,0x40
};

void main(void) {
   cpct_disableFirmware();
   cpct_setStackLocation((u8*)0xC000);

   cpct_memset_f64(CPCT_VMEM_START,0x00,0x4000);
   cpct_setBorder(HW_BRIGHT_WHITE);
   cpct_setVideoMode(0);

   cpct_setVideoMemoryPage(cpct_pageC0);
   ramBankC1();
   ramBank=1;

   populateYaddress();

   while(1){
      checkInput();
      updateScreen();
      changeVideoMemoryPage();
   }
}

void populateYaddress(){
    for (u8 i=0;i<200;i++){
        yAddress[i]=cpct_getScreenPtr(SCREEN_BUFFER,0,i);
    }
}

void checkInput(){
   cpct_scanKeyboard_f();

   if (cpct_isKeyPressed(Key_CursorLeft)){
      x-=2;
   }

   if (cpct_isKeyPressed(Key_CursorRight)){
      x+=2;
   }
}

void updateScreen(){
   cpct_waitVSYNC();
   cpct_memset_f64(SCREEN_BUFFER,0x00,0x4000);
   printVerticalLine();
}

void changeVideoMemoryPage(){
   if (ramBank==1){
      cpct_setVideoMemoryPage(cpct_page40);
      ramBankC3();
      ramBank=3;
   }
   else{
      cpct_setVideoMemoryPage(cpct_pageC0);
      ramBankC1();
      ramBank=1;
   }
}

void ramBankC1(){
   __asm

   ld b,#0x7f
   ld c,#0xc1
   out (c),c

   __endasm;
}

void ramBankC3(){
   __asm

   ld b,#0x7f
   ld c,#0xc3
   out (c),c

   __endasm;
}

void printVerticalLine(){
   u8 px;

   pTile=tile;
   px=x;

   for (u8 j=0;j<=2;j++){
      for (u8 i=0;i<=24*8;i+=8){
         y=i;
         drawTile();
      }

      x+=4;
   }

   x=px;
}

void drawTile(){
    __asm

    ld de,(_pTile)

    // vram=yAddress[y]+x/2;

    ld hl,(_y)
    ld h,#0x00
    add hl,hl
    ld bc,#_yAddress
    add hl,bc

    ld c,(hl)
    inc l
    ld b,(hl)

    ld hl,(_x)
    ld h,#0x00
    srl l
    add hl,bc

    // ROW 1

    ex de,hl

    ldi
    ldd

    set 3,d
    inc l
    inc l

    // ROW 2

    ldi
    ldd

    set 4,d
    res 3,d
    inc l
    inc l

    // ROW 3

    ldi
    ldd

    set 3,d
    inc l
    inc l

    // ROW 4

    ldi
    ldd

    set 5,d
    res 4,d
    res 3,d
    inc l
    inc l

    // ROW 5

    ldi
    ldd

    set 3,d
    inc l
    inc l

    // ROW 6

    ldi
    ldd

    set 4,d
    res 3,d
    inc l
    inc l

    // ROW 7

    ldi
    ldd

    set 3,d
    inc l
    inc l

    // ROW 8

    ldi
    ldd
   
    ex de,hl

    __endasm;
}

Now that I've got bank switching and double buffering working together, I'm thinking about code and data.

Is it sensible to put code into the banks of the extra 64KB?
I'm just wondering how the main loop (likely in the 16KB block at 0x8000) would know how to find code that sits in the extra 64KB.
That code would probably need to be loaded in to one of the extra banks manually, but I'm struggling to figure out how the main program would know the addresses of functions up there.
Actually even storing data in the extra banks confuses me. Would I need to have some sort of mapping so that the main program knows where such data lives?
(Sorry I'm having trouble explaining all of this!)

It depends.

In the simple case, you always know that, e.g. sprite graphics are in Bank 4 (and only there) so all you code needs to do is select a suitable banking arrangement and then fetch data. Everything else "just works".

In more complex cases data may be in multiple banks, so you might need to start storing pointers such that you can switch to the relevant bank first.

For code, I generally try to avoid it if I can as that simplifies things (or exclusively use one of the banks, like bank 7 for code). This is probably even more true with C code than assembly. If you have to have code across multiple banks, you can borrow a trick from the firmware and set up one of the RSTs to act as a "FAR CALL". Then maintain a jump table of parameterized RST instructions somewhere in memory you won't page out. Since your jump table entries are static, you can write code to call them and it doesn't matter if you end up having to move code around inside the banks (you just have to regenerate that jump table when you do).

; soft in &4000 to &7fff only. call to all banks C4,C5,C6,C7 and return.
org #4000

ld de,1234 ; sample data
ld hl,#6000 ; sample adress to call
ld a,#c4    ;bank number
call far ;to c4
inc a
call far ;to c5
inc a
call far ;to c6
inc a
call far ;to c7
ret

org #7ff0
.far
ld bc,#7FC0
out (C),A
push BC
ld bc,return
push bc
jp (hl) ;call hl
.return
pop bc
out (C),C
ret

write direct -1,-1,#C4

;far
org #7ff0
ld bc,#7FC4
out (C),A
push BC
ld bc,return
push bc
jp (hl) ;call hl
;return
pop bc
out (C),C
ret

org #6000
ret

write direct -1,-1,#C5

;far
org #7ff0
ld bc,#7FC5
out (C),A
push BC
ld bc,return
push bc
jp (hl) ;call hl
;return
pop bc
out (C),C
ret

org #6000
ret

write direct -1,-1,#C6

;far
org #7ff0
ld bc,#7FC6
out (C),A
push BC
ld bc,return
push bc
jp (hl) ;call hl
;return
pop bc
out (C),C
ret

org #6000
ret

write direct -1,-1,#C7

;far
org #7ff0
ld bc,#7FC7
out (C),A
push BC
ld bc,return
push bc
jp (hl) ;call hl
;return
pop bc
out (C),C
ret

org #6000
ret

Thanks @andycadley and @McArti0. I'll have a think about your ideas and advice. 😊

The coolest CPC Banking feature is RAM configuration &C3. It's like &C1, but in addition it moves the upper 16 KB block of the main RAM (usually Video-RAM) from &C000-&FFFF to &4000-&7FFF. That's used by CP/M Plus, FutureOS and some cool demos too.

Quote from: GUNHED on 17:37, 16 February 24The coolest CPC Banking feature is RAM configuration &C3. It's like &C1, but in addition it moves the upper 16 KB block of the main RAM (usually Video-RAM) from &C000-&FFFF to &4000-&7FFF. That's used by CP/M Plus, FutureOS and some cool demos too.

I can understand that C3 is the best mode to adapt a normal 64KB game to use double buffering on a 128KB machine as it requires  minimal change to the original code, but why is C3 a benefit for games that take real advantage of 128K memory and more? There I would have expected that C3 is even slower as it's impossible to copy anything from RAM4,RAM5 and RAM6 to RAM 1 directly.

#C3 is mainly for ROM-based software, which want to read-access the video ram at #C000 directly (the reason why someone is so excited about it).
Using the same routines for doing video operations for both #4000 and #C000 maybe another usecase, but as you said, in this case you can't e.g. transfer sprite data from different secondary ram blocks to the video ram.

Quote from: eto on 09:52, 19 February 24

Quote from: GUNHED on 17:37, 16 February 24The coolest CPC Banking feature is RAM configuration &C3. It's like &C1, but in addition it moves the upper 16 KB block of the main RAM (usually Video-RAM) from &C000-&FFFF to &4000-&7FFF. That's used by CP/M Plus, FutureOS and some cool demos too.

I can understand that C3 is the best mode to adapt a normal 64KB game to use double buffering on a 128KB machine as it requires  minimal change to the original code, but why is C3 a benefit for games that take real advantage of 128K memory and more? There I would have expected that C3 is even slower as it's impossible to copy anything from RAM4,RAM5 and RAM6 to RAM 1 directly.

There isn't really any combination that allows easy copying between RAM4/5/6 and RAM1. There is always going to be some compromises and carefully organising the memory map to fit your use case is crucial. The C1/C2/C3 configurations are often overlooked in favour of the "easier" methods that just page at #4000 though.

Quote from: andycadley on 14:37, 19 February 24

Quote from: eto on 09:52, 19 February 24

Quote from: GUNHED on 17:37, 16 February 24The coolest CPC Banking feature is RAM configuration &C3. It's like &C1, but in addition it moves the upper 16 KB block of the main RAM (usually Video-RAM) from &C000-&FFFF to &4000-&7FFF. That's used by CP/M Plus, FutureOS and some cool demos too.

I can understand that C3 is the best mode to adapt a normal 64KB game to use double buffering on a 128KB machine as it requires  minimal change to the original code, but why is C3 a benefit for games that take real advantage of 128K memory and more? There I would have expected that C3 is even slower as it's impossible to copy anything from RAM4,RAM5 and RAM6 to RAM 1 directly.

There isn't really any combination that allows easy copying between RAM4/5/6 and RAM1. There is always going to be some compromises and carefully organising the memory map to fit your use case is crucial. The C1/C2/C3 configurations are often overlooked in favour of the "easier" methods that just page at #4000 though.

Sure, als we can see in the post before yours. In addition people tend to forget the mode &C3 was introduced to allow CP/M Plus to run on 128 KB CPCs.

Quote from: GUNHED on 19:58, 19 February 24people tend to forget the mode &C3 was introduced to allow CP/M Plus to run on 128 KB CPCs.

Could you please share where I can find that information? I can only find information on the Wiki and in a book that CP/M plus is using C2 and C0. C3 was nowhere mentioned. 

IIRC CP/M+ was using #C2 (for the 63K TPA) and #C1 for the "common area". And probably #C4-#C7 for managing/initialisation of the 2nd 64K bank.

Maybe the ROM-Part of Dr.Logo, which was placed in the second 8KB of the Amsdos ROM, was using #C3? But yes, that's not really CP/M(+) related, just another example that #C3 was designed for Rom software.
[this Dr.Logo for CP/M+ was a very strange oddity of Amstrad anyway: including a part of an alternative programming language in ROM, which still required booting another OS from disc + the remaining part of the programming language, and which wasn't used at all by most of the users :) ]

Quote from: eto on 20:37, 19 February 24

Quote from: GUNHED on 19:58, 19 February 24people tend to forget the mode &C3 was introduced to allow CP/M Plus to run on 128 KB CPCs.

Could you please share where I can find that information? I can only find information on the Wiki and in a book that CP/M plus is using C2 and C0. C3 was nowhere mentioned.

In Chapter 8, Page 2 of the 6128 user manual you can read:
"There are three other bank selections possible (apart from the five shown below), but they are only useful to the implementation of CP/M Plus."

The drawing following the above statement clearly shows the use of memory modes #C0, #C4, #C5, #C6 and #C7. So the remaining 3 modes that are only useful to CP/M Plus are #C1 (not #C0), #C2, and #C3.

In fact memory modes #C1 to #C3 correspond to CP/M memory pages 0 to 2.

In "The Amstrad CP/M Plus" by David Powys-Lybbe & Andrew R M Clarke, page 433 you can read a detailed description of the usage of modes #C1 to #C3.
#C1 contains the banked portions of the BIOS and BDOS, the screen memory, disk buffers and the extended BIOS jumpblock.
#C2 is the TPA bank in which all application programs are run.
#C3 contains a copy of the CCP, disk hash tables and data buffers.

It is obvious that Amstrad designed memory modes #C1, #C2 and #C3 specifically for use with CP/M Plus so that the upper 16K of memory (block 7) is common to all 3. A prerequisite of the banked version of CP/M Plus.
They also designed almost identical memory configurations for the PCW and the Spectrum +3.

d_kef

But when we have a 512KB RAM expansion, we will get an additional 112KB RAM in the C1(C3)+n*8 settings, where n=1-7. And full access to bank 1 and 3

Quote from: d_kef on 00:58, 20 February 24#C3 contains a copy of the CCP, disk hash tables and data buffers.

Thanks, interesting, I still wonder why this is required, when you have #C4-#C7 anyway.

Quote from: d_kef on 00:58, 20 February 24They also designed almost identical memory configurations for the PCW and the Spectrum +3.

The PCW has a flexible 4x16K memory mapping. I don't know of any alternative CPC-like mapping. Even in "CPC mode" it is using independant 4x16K pages. Maybe you mixed it?

Indeed the +2A/+3 memory mapping is using the same combinations like #C0-#C3:

Spectrum %00 -> same as -> CPC #C2
Spectrum %01 -> same as -> CPC #C0
Spectrum %10 -> same as -> CPC #C1
Spectrum %11 -> same as -> CPC #C3
(with blocks 0-3 and blocks 4-7 swapped).

Something like #C4-#C7 is missing on the Amstrad Spectrums.

Quote from: Prodatron on 14:25, 20 February 24Thanks, interesting, I still wonder why this is required, when you have #C4-#C7 anyway.

Probably because the bulk of CP/M is running from page 7, so you need memory combinations that keep it located at #C000.

Quote from: Prodatron on 14:25, 20 February 24Indeed the +2A/+3 memory mapping is using the same combinations like #C0-#C3:

Spectrum %00 -> same as -> CPC #C2
Spectrum %01 -> same as -> CPC #C0
Spectrum %10 -> same as -> CPC #C1
Spectrum %11 -> same as -> CPC #C3
(with blocks 0-3 and blocks 4-7 swapped).

Something like #C4-#C7 is missing on the Amstrad Spectrums.

That's only the "all RAM" combinations. The paging system also allows any 16K page of the memory to be made visible at #C000 when the ROM is visible in the lower 16K.

Quote from: andycadley on 15:01, 20 February 24That's only the "all RAM" combinations. The paging system also allows any 16K page of the memory to be made visible at #C000 when the ROM is visible in the lower 16K.

Yes, but then you can't have your own RSTs and interrupt handler, and 16K of visible RAM is missing  :(

Quote from: Prodatron on 15:40, 20 February 24

Quote from: andycadley on 15:01, 20 February 24That's only the "all RAM" combinations. The paging system also allows any 16K page of the memory to be made visible at #C000 when the ROM is visible in the lower 16K.

Yes, but then you can't have your own RSTs and interrupt handler, and 16K of visible RAM is missing  :(

That's the Speccy way.  :laugh:

Since the "all RAM" paging schemes only work on a subset of 128K machines (the +2A/+3), you're pretty much going to be using the more compatible RAM arrangements anyway and that means no RSTs and only 48K of visible RAM. Well unless you're targeting +3 disk only.

And then you have to deal with the messy way that contended (aka slow) RAM is different between the Sinclair and Amstrad models. And weird bugs when I is pointing at uncontended RAM.

Paging on the Amstrad is an absolute luxury in comparison.  :laugh:

Quote from: eto on 20:37, 19 February 24

Quote from: GUNHED on 19:58, 19 February 24people tend to forget the mode &C3 was introduced to allow CP/M Plus to run on 128 KB CPCs.

Could you please share where I can find that information? I can only find information on the Wiki and in a book that CP/M plus is using C2 and C0. C3 was nowhere mentioned.

Well, it's common knowledge for me. You can look into Computer Journals, Google it or eventually use the Wiki. Sorry, I'm not the Silver Platter. My time is as precious as yours.

Quote from: Prodatron on 21:38, 19 February 24IIRC CP/M+ was using #C2 (for the 63K TPA) and #C1 for the "common area". And probably #C4-#C7 for managing/initialisation of the 2nd 64K bank.

Maybe the ROM-Part of Dr.Logo, which was placed in the second 8KB of the Amsdos ROM, was using #C3? But yes, that's not really CP/M(+) related, just another example that #C3 was designed for Rom software.
[this Dr.Logo for CP/M+ was a very strange oddity of Amstrad anyway: including a part of an alternative programming language in ROM, which still required booting another OS from disc + the remaining part of the programming language, and which wasn't used at all by most of the users :) ]

If CP/M Plus (Amstrad Version) would NOT require &C3, then it would run on CPC464 with RAM expansion. Later on CP/M Plus was patched to run on CPC464 too - by 3rd party developers. And before you ask: That's common knowledge, you can google it - Don't ask me for details, my time is as precious as yours.

Quote from: GUNHED on 18:01, 20 February 24Well, it's common knowledge for me. You can look into Computer Journals, Google it or eventually use the Wiki. Sorry, I'm not the Silver Platter. My time is as precious as yours.

I searched Google, I checked the Wiki, I looked into the Markt&Technik book about CP/M and they all mention C2 but not C3. 

So it obviously isn't common knowledge as otherwise it would be present e.g. on the Wiki. 

But no worries, d_kef already answered.

Quote from: d_kef on 00:58, 20 February 24In "The Amstrad CP/M Plus" by David Powys-Lybbe & Andrew R M Clarke, page 433 you can read a detailed description of the usage of modes #C1 to #C3.
#C1 contains the banked portions of the BIOS and BDOS, the screen memory, disk buffers and the extended BIOS jumpblock.
#C2 is the TPA bank in which all application programs are run.
#C3 contains a copy of the CCP, disk hash tables and data buffers.

It is obvious that Amstrad designed memory modes #C1, #C2 and #C3 specifically for use with CP/M Plus so that the upper 16K of memory (block 7) is common to all 3. A prerequisite of the banked version of CP/M Plus.
They also designed almost identical memory configurations for the PCW and the Spectrum +3.

awesome. Thanks a lot.

Is it C3 work on normal 6128, or on Plus only?

Quote from: ZorrO on 21:13, 20 February 24Is it C3 work on normal 6128, or on Plus only?

Normal 6128.

Quote from: eto on 19:26, 20 February 24

Quote from: GUNHED on 18:01, 20 February 24Well, it's common knowledge for me. You can look into Computer Journals, Google it or eventually use the Wiki. Sorry, I'm not the Silver Platter. My time is as precious as yours.

I searched Google, I checked the Wiki, I looked into the Markt&Technik book about CP/M and they all mention C2 but not C3.

So it obviously isn't common knowledge as otherwise it would be present e.g. on the Wiki.

But no worries, d_kef already answered.

Yes, the wiki sadly lacks a lot of basic information. Thanks to d_key - who gave a reference - it shall become common knowledge here too.  :) :) :)

Quote from: ZorrO on 21:13, 20 February 24Is it C3 work on normal 6128, or on Plus only?

CPC6128 and 6128plus natively. CPC464 and CPC664 with Revaldhinos RAM expansion (not the other ones though).

Quote from: Prodatron on 14:25, 20 February 24The PCW has a flexible 4x16K memory mapping. I don't know of any alternative CPC-like mapping. Even in "CPC mode" it is using independant 4x16K pages. Maybe you mixed it?

I wasn't very clear on this.
The PCW has a flexible 4x16K memory mapping indeed. It can map any 16K memory page to any of the 4 16K memory banks of the Z80 (#0000-#3FFF, #4000-#7FFF, #8000-#BFFF, #C000-#FFFF)
What I meant is that the CP/M Plus memory configuration is very similar between the PCW and the CPC or the +3. I had the following tables in mind (I had to dig them out of my notes)

PCW

Z80 address space	CP/M Bank 0	CP/M Bank 1	CP/M Bank 2
#C000-#FFFF	RAM page 7 common	RAM page 7 common	RAM page 7 common
#8000-#BFFF	RAM page 3 BIOS,BDOS	RAM page 6 TPA	(RAM page 3)
#4000-#7FFF	RAM page 1 screen	RAM page 5 TPA	RAM page 8 CCP,hash tables, data buffers
#0000-#3FFF	RAM page 0 BIOS jumpblock	RAM page 4 TPA	(RAM page 0)

CPC

Z80 address space	CP/M Bank 0	CP/M Bank 1	CP/M Bank 2
#C000-#FFFF	RAM page 7 common	RAM page 7 common	RAM page 7 common
#8000-#BFFF	RAM page 2 BIOS,BDOS	RAM page 6 TPA	(RAM page 2)
#4000-#7FFF	RAM page 1 screen	RAM page 5 TPA	RAM page 3 CCP,hash tables, data buffers
#0000-#3FFF	RAM page 0 BIOS jumpblock	RAM page 4 TPA	(RAM page 0)

Spectrum +3

Z80 address space	CP/M Bank 0	CP/M Bank 1	CP/M Bank 2
#C000-#FFFF	RAM page 3 common	RAM page 3 common	RAM page 3 common
#8000-#BFFF	RAM page 6 BIOS,BDOS	RAM page 2 TPA	(RAM page 6)
#4000-#7FFF	RAM page 5 screen	RAM page 1 TPA	RAM page 7 CCP,hash tables, data buffers
#0000-#3FFF	RAM page 4 BIOS jumpblock	RAM page 0 TPA	(RAM page 4)

d_kef

Quote from: Prodatron on 21:38, 19 February 24IIRC CP/M+ was using #C2 (for the 63K TPA) and #C1 for the "common area". And probably #C4-#C7 for managing/initialisation of the 2nd 64K bank.

Maybe the ROM-Part of Dr.Logo, which was placed in the second 8KB of the Amsdos ROM, was using #C3? But yes, that's not really CP/M(+) related, just another example that #C3 was designed for Rom software.
[this Dr.Logo for CP/M+ was a very strange oddity of Amstrad anyway: including a part of an alternative programming language in ROM, which still required booting another OS from disc + the remaining part of the programming language, and which wasn't used at all by most of the users :) ]

Not sure about that but what I had in mind is that they had to do it due to a licence topic or copy protection. Will dig the info out somewhere...

Hi folks.

I've been thinking for some time about how best to start planning data storage to best make use of 128KB.
But I've realised that's not the hard bit.

I'm planning on using C0 to run the game, with main() at #8000, and other code and data from #100 to #3FFF.
I dunno... maybe that will change.

What I'm struggling to figure out is how to load data tables into banks 4 to 7.
Using C4 to C7 I can access data in banks 4 to 7, but I don't get how to get the data into those banks in the first place.

My z80 is not strong enough to write a game in 100% asm, but I'm very comfortable with cpctelera.
However, I'm wondering if it's possible to use a basic loader, and use OUT commands to change the current banking scheme, and then load a BIN file into the appropriate bank.

Does anyone have any ideas or tips or experiences that they could share?
Thanks!

[EDIT]

I've tried the following in BASIC after a fresh reboot:
out &7f00,&c0   OK
out &7f00,&c1   FREEZE
out &7f00,&c2   FREEZE
out &7f00,&c3   FREEZE
out &7f00,&c4   OK
out &7f00,&c5   OK
out &7f00,&c6   OK
out &7f00,&c7   OK

Now, I think I only need C4 to C7 (and then back to C0) during loading.
I'll need to try loading some stuff into those banks somehow... maybe poking data into memory locations?

C1 and C3 is not freeze.

https://www.cpcwiki.eu/forum/index.php?msg=235879

You dont see printing chars because You are writing to the bank 7.

Oh, that's interesting.
I'll need to try some more tests.

Also, I tried some tests in BASIC (using C4 to C7), and they worked!

10 out &7f00,&c4
20 poke &4000,4
30 out &7f00,&c5
40 poke &4000,5
50 out &7f00,&c6
60 poke &4000,6
70 out &7f00,&c7
80 poke &4000,7

100 out &7f00,&c0
110 print peek(&4000)
120 out &7f00,&c4
130 print peek(&4000)
140 out &7f00,&c5
150 print peek(&4000)
160 out &7f00,&c6
170 print peek(&4000)
180 out &7f00,&c7
190 print peek(&4000)

200 out &7f00,&c0

GENIUS! :D

Quote from: McArti0 on 12:11, 04 March 24GENIUS! :D

;D 8) :laugh:

@ervin - You almost did RAM tester. :)
10 a=&4000:o=&7F00:FOR b=252 TO 196 STEP-8:OUT o,b:POKE a,b:NEXT:OUT o,192:POKE a,188:FOR b=252 TO 196 STEP-8:OUT o,b:r=MAX(r,(8*PEEK(a)-180)):NEXT:PRINT r"K

Quote from: ervin on 11:38, 04 March 24However, I'm wondering if it's possible to use a basic loader, and use OUT commands to change the current banking scheme, and then load a BIN file into the appropriate bank.

You can page in RAM bank 4-7 at &4000 and then use a normal load command for binary files with the target address &4000.

LOAD "binary.bin",&4000

Yeah, BASIC won't mess up your banking arrangement, so you can just do MEMORY &3FFF, page with an OUT and the load binary data into &4000.

Excellent! Thanks everyone.
:)

Quote from: ervin on 11:38, 04 March 24However, I'm wondering if it's possible to use a basic loader, and use OUT commands to change the current banking scheme, and then load a BIN file into the appropriate bank.

That is what I did with Sly Spy allegro : I fill the banks with music files & the player from the basic loader.
1 SYMBOL AFTER 256:OPENOUT"JMB":MEMORY HIMEM-1:CLOSEOUT    
10 DATA CD,01,56,CD,6B,54,01,C0,7F,ED,49
20 MODE 1:BORDER 0:INK 0,0:INK 1,26:PEN 1:PAPER 0:CALL &BB00
30 h=HIMEM-1:MEMORY &3FFF:PRINT "LOADING PATCH..."
40 OUT &7F00,&C4
50 REM Setup a dummy interrupt handler in extra-ram, offset 38h
60 POKE &4038,&FB:POKE &4039,&C9
70 REM ORG &0717:jp &00AA
80 POKE &4717,&C3:POKE &4718,&AA:POKE &4719,0
90 REM ORG &0736:call &5601:call &546B:ld bc,&7FC0:out (c),c
100 FOR x%=&4736 TO &4740:READ a$:POKE x%,VAL("&"+a$):NEXT
110 LOAD"PATCH.BIN",&40AA
120 REM Bounce 64K users
130 OUT &7F00,&C0
140 IF PEEK(&4038)=&FB AND PEEK(&4039)=&C9 THEN PRINT"ERROR: 128K OF RAM REQUIRED. ";CHR$(225):END
150 PRINT"LOADING PATCH 2..."
160 LOAD"PATCH2.BIN",&6000
170 REM Load AYC player & music files in extra-ram (4000h to F???h)
180 PRINT"LOADING MUSIC BLOCK 1..."
190 OUT &7F00,&C5
200 LOAD"MUSIC1.BIN",&4000
210 PRINT"LOADING MUSIC BLOCK 2..."
220 OUT &7F00,&C6
230 LOAD"MUSIC2.BIN",&4000
240 PRINT"LOADING MUSIC BLOCK 3..."
250 OUT &7F00,&C7
260 LOAD"MUSIC3.BIN",&4000
270 REM Run original loader from default RAM banks
280 PRINT "RUNNING SLY SPY (allegro)... "
290 OUT &7F00,&C0
300 MEMORY h:RUN"CNG.BAS"

That's brilliant!
Thanks so much.