setting up paging options

When are the page register selected?

For example, one set of hardware could say that:

Use PageA if data access and address <  0x8000
Use PageB if data access and address >= 0x8000
Use PageC if code access

So in this case:

  i = *(* code)0;  would get PageC, Byte0
  i = *(* xdata)0; would get PageA, Byte0
  i = *(* xdata)0x8000; would get PageB, Byte0 

That may be true, not 100% sure as the datasheet is VERY light on.
The Page bytes are SFR's and maybe they can be set so we can customize the device.

Whether the hardware will generate the correct addressing it doesn't really say, i'm trying to get more info out of them.

So you are syaing that the compiler can treat it as a flat memory model up to the full space and the hardware will generate the correct address? ie set the page registers itself? I thought the compiler would have to tell it somehow?

David

There are a couple of approaches to extending 16 bit memory space.

One approach is to create N * 32KB pages. Page selection is done by extra address pins via some register. To use this approach you need to "set the extra address, do the access". This allows access to only one large page without changing the page address.

Another approach is to map certain small pages (size < 32K) into your 16 bit memory space. Page selection is usually done by using some of the high order bits of the 16 bit address. This allows access to multiple small pages without changing the page registers.

(Another pageing scheme common in 805x micros, is to have a MPAGE sfr that maps one 256 byte page of memory into the external 16 bit memory space so you can do pdata access for your exrernal data.)

Since your page sizes were less than 32kB and since you had 3 "PAGE" registers, I guess that your ASIC used the 2nd method. Of course I could be wrong. You need the documentation. If you can post what documentation you have, I could take another guess.

To answer your question, since Kiel has only 16 bit pointers, there is no support for automatic external data space paging. Keil does have great support for code space paging.

The easiest thing would be just to give you the datasheet, however there web site doesn't contain the full sheet yet.

It has paging to extend the pdata as well.

The company is Winedge Electronics.
If we could attach files here i would.

David

I look at that chip too (lots of ram), however I could not get the needed techical information. My handle is JYoung and I work at Martinsound. I'll let you figure out my EMail address. I would be glad to look at it for you.

The latest release of the C51 supports a new 24-bit pointer type. Variables of type far and const far may be declared. Far accesses RAM and const far accesses ROM.

Refer to the following message for more information.

http://www.keil.com/forum/msgpage.asp?MsgID=2382

Jon

// Example of using page registers with 16 bit Keil addressing

typedef unsigned char BYTE;

enum { ptROM, ptRAM, ptIO };

sfr PageType = 0x9A;

#define PAGETYPEFOR4000(pt) ( PageType = ( PageType & ~0x03 ) |   (pt) )
#define PAGETYPEFOR8000(pt) ( PageType = ( PageType & ~0x0C ) | ( (pt) << 2 ) )
#define PAGETYPEFORC000(pt) ( PageType = ( PageType & ~0x30 ) | ( (pt) << 4 ) )
 
sfr PageFor4000 = 0x9B;
sfr PageFor8000 = 0x9C;
sfr PageForC000 = 0x9D;

#define PAGESZ 0x8000

#define PAGE(PhysicalAddr)   ( (unsigned int)(PhysicalAddr) >> 14 )
#define OFFSET(PhysicalAddr) ( (unsigned int)(PhysicalAddr) & (PAGESZ-1) ) 

//ROM   00_0000 to 01_FFFF
//RAM   00_0000 to 01_FFFF
//CGROM 20_0000 to 23_FFFF

//Define type and physical_address for objects
typedef BYTE typVar1[ 0x1000 ];
#define phyVar1  0x11020   //check PAGE( &phyVar1[0] ) = PAGE( &phyVar1[ 0x0fff] )

typedef BYTE typVar2;
#define phyVar2  0x05023

void main( void )
{
   PAGETYPEFOR4000( ptRAM ); 
   PageFor4000 = PAGE( phyVar1 );
   #define pVar1 ( (typVar1 xdata*)( OFFSET(phyVar1) || 0x4000) )

   PAGETYPEFORC000( ptRAM ); 
   PageForC000 = PAGE( phyVar2 );
   #define pVar2 ( (typVar2 xdata*)( OFFSET(phyVar2) || 0xC000) )

   (*pVar1)[20] = *pVar2;
}

I don't think your new 24 bit pointer would help him. As you can see in my example abouve, the 16 bit part of the address is not only an offset, but the high order 2 bits are the page register select bits. These bits must be non-zero. In otherwords, my guess is that your new 24 bit pointers support page selection, not page register selection. Am I wrong?

The new 24 bit addressing is translated into WHATEVER WEIRD memory architecture you have by...YOU. You modify the source of the XBANKING file to dictate just what exactly the 24-bit address is. If you munge it down into a 14-bit offset with a 2-bit selector that's just fine and will work AOK with the compiler.

From the program's perspective, it appears that you have 24-bit addresses.

Jon

You're right. The compiler emits calls to your user defined functions to to load and store data.

If you can tolerate the speed hit, this is a simple way to go.

I erroneously assumed, that for the sake of speed, that loads and store would be split into a "8 bit page changing macro" and "16 bit dptr accesses".

BYTE far Var1[ 0x1FFE ];
BYTE far Var2[100];

Var1[20] = Var2[5];

0008 7B00        R     MOV     R3,#MBYTE Var2
000A 7A00        R     MOV     R2,#HIGH Var2+05H
000C 7900        R     MOV     R1,#LOW Var2+05H
000E 120000      E     LCALL   ?C?CLDPTR
0011 7B00        R     MOV     R3,#MBYTE Var1
0013 7A00        R     MOV     R2,#HIGH Var1+014H
0015 7900        R     MOV     R1,#LOW Var1+014H
0017 020000      E     LJMP    ?C?CSTPTR

So i in terms of the options of the compiler i still put in off chip xdata memory:

0000 to 0xffff for my 64k page and then mod these routines using far to gain the correct access.

thanks guys for the great help.
David

Yes.

There is also page switching for the plain data access ram also. But since they swap out the entire 256 bytes of ram, I think there are too many gotcha's to use it.

If you have anymore questions, post to a new thread, since the e-mail notification is not work for me on this thread.