Newsgroups: comp.robotics
Path: cantaloupe.srv.cs.cmu.edu!fs7.ece.cmu.edu!hudson.lm.com!netline-fddi.jpl.nasa.gov!nntp.et.byu.edu!news.kei.com!news.mathworks.com!uunet!juniper.almaden.ibm.com!garlic.com!nic.scruz.net!earth.armory.com!rstevew
From: rstevew@armory.com (Richard Steven Walz)
Subject: Re: Z80 Assem Question
Organization: The Armory
Date: Sun, 12 Feb 1995 14:16:27 GMT
Message-ID: <D3w4zH.9qJ@armory.com>
References: <3hcq5u$g1@newsbf02.news.aol.com> <3hhr43$b9o@hemp.imel.kyoto-u.ac.jp>
Sender: news@armory.com (Usenet News)
Nntp-Posting-Host: deepthought.armory.com
Lines: 80

In article <3hhr43$b9o@hemp.imel.kyoto-u.ac.jp>,
Onat Ahmet <onat@turbine.kuee.kyoto-u.ac.jp> wrote:
>In article <3hcq5u$g1@newsbf02.news.aol.com>
>centauri7@aol.com writes:
>
>>>     I am used to programming on systems that have full memory.
>>>    I am currently building a little robot that will utilize EPROM and
>>> DRAM.
>>>   I'm pretty sure I can work out the details for addressing the chips.
>>> 
>>>    This is really a Z80 assembler question.  How you you specify where
>>> the end of memory is?  I nned to know where the stack is going to want 
>>> to be.   The code can be stored in EPROM, and by using the ORG statement,
>>> I can segment, but I can't find into in the Zilog book about where the 
>>> stack goes.    Hmmmm....
>
>The stack pointer's initial position is up to you solely; 
>and it does not have any preference of its own. The usual
>Z80 system uses a stack that starts from the last adress of
>RAM. You set the stack pointer by the Z80 command designated
>for that, and not with the assembler (LD SP XXXX).
>
>I do not really get what you mean by full memory, but if you
>mean that full memory address decoding is not done (which
>means you will be seeing images of the same device repeatedly
>in different places in the memory map), that is no problem either.
>Just use a single set out of those images and forget about the
>rest. For example, if you use 8K EPROM, and 8K RAM, and use only
>the A15 line for chip select, then the memory map is going to
>look like this:
>0000~0FFF EPROM
>1000~1FFF Same EPROM here once more!
>2000~2FFF EPROM seen here too.
>3000~3FFF EPROM
>.
>.
>.
>7000~7FFF EPROM
>8000~8FFF RAM
>9000~9FFF RAM here again
>.
>.
>.
>EFFF~FFFF RAM
>
>The reason is that you are not using address lines A12 
>A13 and A14 for decoding, so when you address memory, you
>do not care about their values.
>
>For this example, you can set the stack pointer to the
>address 8FFF. You could use 0000 to 0FFF for the ROM
>addresses, and 8000 to 8FFF for RAM(but you could
>opt for 3000~3FFF for ROM and 9000~9FFF for RAM and
>get the same result.)
>I hope this helps.
>
>Ahmet ONAT
-----------------------------------
Oh yeah, this is called "ambiguous addressing". It's used to simplify
addressing circuitry by using a limited number of address lines to save
decoding wide addresses. Same can be done with I/O on the Z-80's 8 bit I/O
address lines. If you only need 16 ports, then use either the low four, the
high four, or the middle four, or such, like that, and of course any other
"don't care" address that matches and whose address lines are not decoded
will cause that address to answer as well. You select banks of ports with
the addresses contiguous by leaving the low address lines "don't care"'s.
You intermesh them by selecting them with the low lines, and then they will
repeat over and over all the way up to the 256th port, 0xFFH. By the way,
the lower address byte is the one used just for I/O when the /IOx control
lines are enabled, but I believe that the upper byte has the same address
as well, making for some easier wiring at times. A VERY easy chip to use!
An old Morrow or Ampro makes a dandy little development computer for
software for these as controllers. The CP/M comes with an ASM assembler and
DDT Dynamic Debugging Tool for that usage. Very similar to DOS. Write me
for any info about those machines, as I have complete documentation and
software. I have used the Morrow boards as the heart of robots a couple
times, as the Rev 2 board has a partially decoded 40 pin I/O header that
Morrow never used.
-Steve Walz   rstevew@armory.com

