Richard, You asked for it - you got it (poor memory and all - I have no references to hand just now). If anyone else wants to correct me as we go - please feel free.
As I recall the MMU is configured such that the physical memory space is viewed as 4k pages - the power on default is to address the physical space linearly from 0x0000. There are only three (3) definable areas of memory - lower, middle and upper - bank registers define starting 'logical' address in 4K chunks and the corresponding 'physical' address (also in 4K chunks). I cannot remember if the lower bank ALWAYS starts from 0x00000 (physical) or not. I do remember something about only being able to address in incrementing values - ie the middle page cannot be of higher physical address than the upper one and vice versa. The biggest concern is that the Z180 CPU core is only ever aware of 64K of addressable memory - the MMU is a add-on that allows access to larger address spaces BUT DOES NOT provide the CPU with knowledge of the 'mapping' unlike the (eternally cursed) segmented architecture of the 80x86. This means that all access to 'paged' memory is fixed in its 'current' settings when important things happen - like IRQ processing, push/pop'ing stuff on/off the stack etc. This can be useful, but it can also be a nightmare as none of your code can be sure of the state of the banking registers (without checking) and therefore cannot be sure of WHAT physical address is being accessed at any given time. Making extra ram available as a page addressable resource is relatively simple, making code execute out of paged ROM is more complex (this is true of all BANKED memory arrangements) as you need to get the compiler to generate code to be executed at the logical address and located in the physical address, not to invoke other code within another bank, etc, etc. Further more, I'm not altogether sure that the combination of physical/logical addressing you have described as ideal is possible. Anyhow, I hope the data contained here in (such as it is) is helpful and not misleading. Maybe we are (in keeping with the documentation hullabaloo) planting the seed of documentation on the z180/64180 MMU - or not. PeterT :-> -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Gray Sent: Friday, 5 September 2008 9:28 AM To: sdcc-user@lists.sourceforge.net Subject: Re: [Sdcc-user] Z80/Z180 MMU question(s) Well, I created a nice heap of EPROMS for the eraser in the attempt! I've ended-up with a reasonably satisfactory result - the analyser tells me my stack is at the top of memory (17FFF), which is what I wanted. This means I've got 64K of stack, which seems a bit excessive; but what the hell. My data area begins at 08000 physical and logical, and my static variables seem to go there, so I've got 32K of static variable space to play with too. There's potential for the stack to overwrite the static variable space, but I'll have made a most dreadful ballsup if that should ever occur! The key to this seemed/seems to be the BBR (Bank Base Register), which set to 0x08 seems to give the result described above. I've left everything else at their reset values. It's not exactly what I wanted... I would have liked _DATA to start at 0 (logical), 08000 physical and the program code to execute from 0 (logical and physical), with the stack at 17FFF pushing down; but this might not be reasonable. It seems to be a reasonable restriction that the addressable (static) data be in the same logical address space as the code; but I don't know really. I must confess, I don't really understand what I've done; but it does work. I would be happy to have any further light shed upon this...? On Thursday 04 September 2008 23:29:11 Peter Townson wrote: > Richard, > > Glad to hear that you solved your problem. > > I was literally composing a response for you when your message arrived a > few minutes ago - good timing. (I'm no expert but no one else seemed to > be jumping in so I was going to have a go based on faded memories of a > much earlier project :->) > > Cheers, > > PeterT > -- Richard. PGP Key-id: 0x5AB3D350 Math is like love -- a simple idea but it can get complicated. -- R. Drabek ------------------------------------------------------------------------ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user ########################################################################## CONFIDENTIALITY NOTE: Please consider our environment before printing this email.This email and any attachments are confidential and may be subject to copyright, legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). They may only be copied, distributed or disclosed with the consent of the copyright owner. If you have received this email by mistake or by breach of the confidentiality clause, please notify the sender immediately by return email and delete or destroy all copies of the email. Any confidentiality, privilege or copyright is not waived or lost because this email has been sent to you by mistake. ########################################################################## ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
