Rabbit 2000 User manual
Rabbit
2000™
Microprocessor
Designers
Handbook
Revision
C
Rabbit
2000
Microprocessor
Rabbit
2000
Microprocessor
Designer’s
Handbook
Part
Number
019-0070
•
Revision
C
Last
revised
on
July
5,
2000
•
Printed
in
U.S.A.
Copyright
©
2000
Rabbit
Semiconductor
•
All
rights
reserved.
Rabbit
Semiconductor
reserves
the
right
to
make
changes
and
improvements
to
its
prod-
ucts
without
providing
notice.
Trademarks
•
Dynamic
C®
is
a
registered
trademark
of
Z-World
•
Z80/Z180™
is
a
trademark
of
Zilog,
Inc.
Notice
to
Users
Rabbit
Semiconductor
products
are
not
authorized
for
use
as
critical
components
in
life-
support
devices
or
systems
unless
a
specific
written
agreement
regarding
such
intended
use
is
entered
into
between
the
customer
and
Rabbit
Semiconductor
prior
to
use.
Life-
support
devices
or
systems
are
devices
or
systems
intended
for
surgical
impantation
into
the
body
or
to
sustain
life,
and
whose
failure
to
perform,
when
properly
used
in
accor-
dance
with
instructions
for
use
provided
in
the
labeling
and
user’s
manual,
can
be
reason-
ably
expected
to
result
in
significant
injury.
No
complex
software
or
hardware
system
is
perfect.
Bugs
are
always
present
in
a
system
of
any
size.
In
order
to
prevent
danger
to
life
or
property,
it
is
there
responsibility
of
the
system
designer
to
incorporate
redundant
protective
mechanisms
appropriate
to
the
risk
involved.
Company
Address
Rabbit
Semiconductor
2932
Spafford
Street
Davis,
California
95616-6800
USA
Telephone:
(530)
757-8400
Facsimile:
(530)
757-8402
Web
site:
http://www.rabbitsemiconductor.com
Designer’s
Handbook
1.
Introduction.....................................................................................................................1
2.
Hardware
Design
Overview............................................................................................3
3.
How
Dynamic
C
Cold-Boots
the
Target
System............................................................5
3.1
How
the
Cold
Boot
Mode
Works
In
Detail.................................................................................5
3.2
Program
Loading
Process
Overview...........................................................................................6
3.3
Program
Loading
Process
Details ...............................................................................................6
4.
Dynamic
C
Rabbit
Programming
Overview...................................................................9
4.1
Memory
Organization ...............................................................................................................10
4.2
How
The
Compiler
Compiles
to
Memory.................................................................................14
5.
The
Rabbit
BIOS ..........................................................................................................17
5.1
Startup
Conditions
Set
Up
By
the
BIOS...................................................................................17
5.2
BIOS
Flowchart.........................................................................................................................18
5.3
Internally
defined
macros..........................................................................................................19
5.4
Modifying
the
BIOS..................................................................................................................19
5.5
Origin
Directives
to
the
Compiler.............................................................................................20
6.
The
System
ID
Block....................................................................................................23
6.1
Definition ..................................................................................................................................23
6.2
Access........................................................................................................................................24
6.3
Reading
the
ID
block.................................................................................................................24
7.
BIOS
Support
for
Program
Cloning .............................................................................27
8.
Low-Power
Design
and
Support...................................................................................29
8.1
Software
Support
for
Low-Power
Sleepy
Modes .....................................................................31
8.2
Baud
Rates
in
Sleepy
Mode......................................................................................................32
9.
Memory
Planning .........................................................................................................33
10.
Flash
Memories...........................................................................................................35
10.1
Writing
Your
Own
Flash
Driver..............................................................................................36
11.
Hardware
Bring-Up
Procedure ...................................................................................39
11.1
Bringing
up
a
New
Rabbit
System..........................................................................................39
11.2
Initial
Checks...........................................................................................................................39
11.3
Diagnostic
Test
#2...................................................................................................................39
11.4
Diagnostic
Test
#3...................................................................................................................40
Legal
Notice.....................................................................................................................41
Rabbit
2000
Microprocessor
Designer’s
Handbook 1
1.
Introduction
This
manual
is
intended
for
the
engineer
designing
a
system
using
the
Rabbit
micropro-
cessor
and
Z-World’s
Dynamic
C
development
environment.
It
explains
how
to
develop
a
Rabbit-based
microprocessor
system
that
can
be
programmed
with
Z-World’s
Dynamic
C.
This
manual
is
preliminary.
An
improved
manual
will
be
issued
at
a
later
date.
With
the
Rabbit
and
Dynamic
C,
many
traditional
tools
and
concepts
are
obsolete.
Com-
plicated
and
fragile
in-circuit
emulators
are
unnecessary.
EPROM
burners
are
unneeded.
The
Rabbit
microprocessor
and
Dynamic
C
work
together
without
elaborate
hardware
aids
provided
that
the
designer
observes
certain
design
conventions.
The
design
conven-
tions
are
straight
forward
and
enhance
design
creativity.
As
shown
in
Figure
1,
the
Rabbit
programming
cable
connects
a
PC
serial
port
to
the
pro-
gramming
connector
of
the
target
microprocessor
system.
Figure
1.
Dynamic
C
Programming
The
Rabbit
programming
cable
is
a
smart
cable
with
an
active
circuit
board
in
the
middle
of
the
cable.
The
circuit
board
converts
RS-232
voltage
levels
used
by
the
PC
serial
port
to
CMOS
voltage
levels
used
by
the
Rabbit.
Dynamic
C
runs
as
an
application
on
the
PC,
and
can
cold-boot
the
Rabbit-based
target
system
with
no
pre-existing
program
installed
in
the
target.
The
flash
memory
on
the
tar-
get
system
can
be
blank
or
it
may
contain
any
data.
The
cold-boot
capability
permits
the
use
of
soldered-in
flash
memory
on
the
target.
Soldered-in
memory
eliminates
sockets,
boot
blocks
and
prom
programming
devices.
However,
it
is
important
that
the
memory
have
its
software
data
protection
enabled
before
it
is
soldered
in.
PC
Hosts
Dynamic
CRabbit
Programming
Cable
Programming
Connector
Target
Microprocessor
System
Rabbit
Microprocessor
Level
Conversion
PC
Serial
Port
2Rabbit
2000
Microprocesssor
Designer’s
Handbook 3
2.
Hardware
Design
Overview
Because
of
the
glueless
nature
of
the
external
interfaces,
especially
the
memory
interface,
it
is
easy
to
design
hardware
in
a
Rabbit-based
system.
More
details
on
hardware
design
are
given
in
the
Rabbit
2000
Microprocessor
User’s
Manual.
Generally
a
system
will
have
two
oscillator
crystals,
a
32.768
kHz
crystal
to
drive
the
bat-
tery-backable
timer,
and
another
crystal
that
has
a
frequency
that
is
1.8432
MHz
or
a
mul-
tiple
of
3.6864
MHz.
Typical
values
are
1.8432,
3.6864,
7.3728,
11.0592,
14.7456,
18.432,
25.8048,
and
29.4912
MHz.
These
crystal
frequencies
(except
1.8432
MHz)
all
allow
generation
of
standard
baud
rates
up
to
at
least
115,200
bps.
The
clock
frequency
can
be
doubled
by
an
on-chip
clock
doubler,
but
the
doubler
should
not
be
used
to
achieve
frequencies
higher
than
about
22.1184
MHz
on
a
5
V
system
and
14.7456
MHz
on
a
3.3
V
system.
A
quartz
crystal
should
be
used
for
the
32.768
kHz
oscillator.
For
the
main
oscil-
lator
a
ceramic
resonator,
accurate
to
0.5%,
will
usually
be
adequate
and
less
expensive
than
a
quartz
crystal.
Most
systems
have
one
static
RAM
chip
and
one
or
two
flash
memory
chips,
but
more
memory
chips
can
be
used
when
appropriate.
Static
RAM
chips
are
available
in
32K
x
8,
64K
x
8,
128K
x
8,
256K
x
8
and
512K
x
8
sizes.
The
256K
x
8
is
mainly
available
in
3
V
versions.
The
other
chips
are
available
in
5
V
or
3
V
versions.
Suggested
flash
memory
chips
between
128K
x
8
and
512K
x
8
are
given
in
Chapter
10,
Flash
Memories.
The
operating
voltage
in
Rabbit-based
systems
will
usually
be
5
V
or
3.3
V,
but
2.7
V
is
also
a
possibility.
The
maximum
computation
per
watt
is
obtained
in
the
range
of
3.0
V
to
3.6
V.
The
highest
clock
speeds
require
5
V.
The
maximum
clock
speed
with
a
3.3
V
sup-
ply
is
18.9
MHz,
but
it
will
usually
be
convenient
to
use
the
less
expensive
R25
part
and
a
7.3728
MHz
crystal,
doubling
the
frequency
to
14.7456
MHz.
Good
computational
per-
formance,
but
not
the
absolute
maximum,
can
be
implemented
for
5V
systems
by
using
an
11.0592
MHz
crystal
and
doubling
the
frequency
to
22.1184 MHz.
Such
a
system
will
operate
with
70
ns
memories.
If
the
maximum
performance
is
required,
then
a
29.4912
MHz
crystal
or
resonator
(for
a
crystal
this
must
be
the
first
overtone,
and
may
need
to
be
special
ordered)
or
a
29.4912
MHz
external
oscillator
can
be
used.
A
29.4912
MHz
sys-
tem
will
require
55
ns
memory
access
time.
A
table
of
timing
specification
is
contained
in
the
Rabbit
2000
Microprocessor
User’s
Manual.
When
minimum
power
consumption
is
required,
a
3.3
V
power
supply
and
a
3.6864
MHz
or
a
1.8432
MHz
crystal
will
usually
be
good
choices.
Such
a
system
can
operate
at
the
main
3.6864
MHz
or
1.8432
MHz
frequency
either
doubled
or
divided
by
8
(or
both).
A
further
reduction
in
power
consumption
at
the
expense
of
computing
speed
can
be
obtained
by
adding
memory
wait
states.
Operating
at
3.6864
MHz,
such
a
system
will
draw
approximately
11
mA
at
3.3
V,
not
including
the
power
required
by
the
memory.
Approximately
2
mA
is
used
for
the
oscillator
and
9
mA
is
used
for
the
processor.
Reduc-
ing
the
processor
frequency
will
reduce
current
proportionally.
At
1/4th
the
frequency
or
(0.92 MHz)
the
current
consumption
will
be
approximately
4
mA.
At
1/8th
the
frequency,
(0.46
MHz)
the
total
power
consumption
will
be
approximately
3
mA,
not
including
the
memories.
Doubling
the
frequency
to
7.37
MHz
will
increase
the
current
to
approxi-
mately
20
mA.
4 Rabbit
2000
Microprocessor
If
the
main
oscillator
is
turned
off
and
the
microprocessor
is
operated
at
32.768
kHz
from
the
clock
oscillator,
the
current
will
drop
to
about
200
µA
exclusive
of
the
current
required
by
the
memory.
The
level
of
power
consumption
can
be
fine-tuned
by
adding
memory
wait
states,
which
have
the
effect
of
reducing
power
consumption.
In
order
to
obtain
microampere
level
power
consumption,
it
is
necessary
to
use
auto
powerdown
flash
mem-
ories
to
hold
the
executing
code.
Standby
power
while
the
system
is
waiting
for
an
event
can
be
reduced
by
executing
long
strings
of
multiply
zero
by
zero
instructions.
Keep
in
mind
that
a
Rabbit
operating
at
3.68
MHz
has
the
compute
power
of
a
Z180
microproces-
sor
operating
at
approximately
triple
the
clock
frequency
(11
MHz).
Most
design
advice
given
for
the
Rabbit
assumes
the
use
of
surface-mount
technology.
However,
it
is
possible
to
use
the
older
through
hole
technology
and
develop
a
Rabbit
sys-
tem.
One
can
use
Z-World’s
Rabbit-based
Core
Module,
a
small
daughter
circuit
board
with
a
complete
Rabbit
core
that
includes
memory
and
oscillators.
Another
possibility
is
to
solder
the
Rabbit
processors
by
hand
to
the
circuit
board.
This
is
not
difficult
and
is
sat-
isfactory
for
low
production
volumes
if
the
right
technique
is
used.
Designer’s
Handbook 5
3.
How
Dynamic
C
Cold-Boots
the
Target
System
Dynamic
C
assumes
that
target
controller
boards
using
the
Rabbit
CPU
have
no
pre-
installed
firmware.
It
takes
advantage
of
the
Rabbit’s
bootstrap
(cold
boot)
mode
that
allows
memory
and
I/O
writes
to
take
place
over
the
programming
port.
When
the
programming
cable
connects
a
PC
serial
port
to
the
user’s
system
the
PC
run-
ning
Dynamic
C
is
connected
to
the
Rabbit
as
shown
in
Table
1..
The
programming
cable
includes
an
RS-232
to
CMOS
signal
level
converter
circuit.
The
level
converter
is
powered
from
the
+5
V
or
+3.3
V
power
supply
voltage
present
on
the
Rabbit
programming
connector
(see
Figure
7
on
page
31).
Plugging
the
programming
cable
into
the
Rabbit
programming
connector
results
in
pulling
the
Rabbit
SMODE0,
SMODE1
(startup
mode)
lines
high.
This
causes
the
Rabbit
to
enter
the
cold-boot
mode
after
reset.
3.1
How
the
Cold
Boot
Mode
Works
In
Detail
The
microprocessor
starts
executing
a
12-byte
program
contained
in
an
internal
ROM.
The
program
contains
the
following
code.
; origin zero
00 ld l,n ; n=0c0h for serial port A
; n=020h for parallel (slave port)
02 ioi ld d,(hl) ; get address most sig byte
04 ioi ld e,(hl) ; get least sig byte
06 ioi ld a,(hl) ; get data (h is ignored)
08 ioi or nop ; if D(7)==1 ioi, else nop
09 ld (de),A ; store in memory or I/O
10 jr 0 ; jump back to zero
; note wait states inserted at bytes 3, 5 and 7 waiting
; for serial port or parallel port ready
The
contents
of
the
boot
ROM
vary
depending
on
the
settings
of
SMODE1,
SMODE2
and
on
the
contents
of
register
D
bit
7
which
determines
if
the
store
is
to
be
an
I/O
store
or
a
data
store.
If
the
boot
is
terminated
by
storing
80h
to
I/O
register
24h
then
when
the
boot
Table
1.
Programming
Port
Connections
PC
Serial
Port
Signal Rabbit
Signal
DTR
(output) /RESET
(input,
reset
system)
DSR
(input) STATUS
(gen
purpose
output)
TX
(serial
output) RXA
(serial
input,
chan
A)
RX
(serial
input) TXA
(serial
output,
chan
A)
6 Rabbit
2000
Microprocessor
program
reaches
address
zero
the
boot
mode
is
disabled
and
instruction
fetching
resumes
at
address
zero.
Wait
states
are
automatically
inserted
during
the
fetching
of
bytes
3,
5
and
7
to
wait
for
the
serial
or
parallel
port
ready.
The
wait
states
continue
indefinitely
until
the
serial
port
is
ready.
This
will
cause
the
processor
to
be
in
the
middle
of
an
instruction
fetch
until
the
next
character
is
ready.
While
the
processor
is
in
this
state
the
chip
select,
but
not
the
out-
put
enable,
will
be
enabled
if
the
memory
mapping
registers
are
such
as
to
normally
enable
the
chip
select
for
the
boot
ROM
address.
The
chip
select
will
stay
low
for
extended
periods
while
the
processor
is
waiting
for
the
serial
or
parallel
port
data
to
be
ready.
Additionally,
the
chip
select
will
go
low
when
a
write
is
performed
to
an
I/O
address
if
the
address
is
such
as
to
enable
that
chip
select
if
it
were
a
write
to
a
memory
address.
3.2
Program
Loading
Process
Overview
On
start
up,
Dynamic
C
first
uses
the
PC’s
DTR
line
on
the
serial
port
to
assert
the
Rabbit
RESET
line
and
put
the
processor
in
cold-boot
mode.
Next,
Dynamic
C
uses
a
four
stage
process
to
load
a
user
program:
1. Load
an
initial
loader
(coldloader)
via
triplets
sent
at
2400
baud
from
the
PC
in
to
a
tar-
get
in
cold-boot
mode.
2. Run
the
initial
loader
and
load
a
secondary
loader
(pilot
BIOS)
at
19200
baud.
3. Run
the
secondary
loader
and
load
the
BIOS
(as
Dynamic
C
compiles
it)
4. Run
the
BIOS
and
load
the
user
program
at
115200
baud
(after
Dynamic
C
compiles
it
to
a
file).
3.3
Program
Loading
Process
Details
When
Dynamic
C
starts,
the
following
sequence
of
events
takes
place:
1. The
serial
port
is
opened
at
with
the
DTR
line
low,
closed,
then
reopened
with
the
DTR
line
high
at
2400
baud.
This
pulses
the
reset
line
on
the
target
low
(the
programming
cable
inverts
the
DTR
line)
and
prepares
the
PC
to
send
triplets.
2. A
group
of
triplets
defined
in
the
file
COLDLOAD.BIN
consisting
of
2
address
bytes
and
a
data
byte
are
sent
to
the
target.
The
first
few
bytes
sent
are
sent
to
I/O
addresses
to
set
the
up
MMU
and
MIU
and
do
system
initialization.
The
MMU
is
set
up
so
that
RAM
is
mapped
to
0x00000,
and
flash
is
mapped
0x80000.
3.
The
remaining
triplets
place
a
small
program
at
memory
location
0x00000.
The
last
triplet
sent
is
0x80,0x24,0x80,
which
tells
the
CPU
to
ignore
the
SMODE
pins
and
start
running
code
at
address
0x00000.
4.
The
PC
now
bumps
the
baud
rate
on
the
serial
port
being
used
to
19200.
5.
The
primary
loader
measures
the
crystal
speed
to
determine
what
divisor
is
needed
to
set
a
baud
rate
of
19200.
The
divisor
is
stored
at
address
0x4002
for
later
use
by
the
BIOS,
and
the
programming
port
is
set
up
to
be
a
19200
baud
serial
port.
Designer’s
Handbook 7
6.
The
program
enters
a
loop
where
it
receives
a
fixed
number
of
bytes
which
comprise
a
secondary
loader
program
(pilot.bin
sent
by
the
PC)
and
writes
those
bytes
to
memory
location
0x4100.
After
all
of
the
bytes
are
received,
program
execution
jumps
to
0x4100.
7.
The
secondary
loader
does
a
wrap-around
test
to
determine
how
much
RAM
is
avail-
able,
and
reads
the
flash
ID.
This
information
is
made
available
for
transmittal
to
Dynamic
C
when
requested.
8.
The
secondary
loader
now
enters
a
finite
state
machine
(FSM)
that
is
used
to
imple-
ment
the
Dynamic
C/Target
communications
protocol.
Dynamic
C
compiles
the
core
of
the
regular
BIOS
and
sends
it
to
the
target
at
address
0x00000
which
is
still
mapped
to
RAM.
Note
that
this
requires
that
the
BIOS
core
be
0x4000
or
less
in
size.
9. The
FSM
checks
the
memory
location
0x4001
(previously
set
to
zero)
after
receiving
each
byte.
When
the
compilation
and
loading
to
RAM
of
the
BIOS
is
complete,
Dynamic
C
signals
the
target
that
it
is
time
to
run
the
BIOS
by
sending
a
one
to
0x4001.
10.
The
BIOS
runs
some
initialization
code
including
setting
up
the
serial
port
for
115200
baud,
setting
up
serial
interrupts
and
starting
a
new
FSM.
11.The
BIOS
code
modifies
a
jump
instrucction
near
the
beginning
of
the
program
so
that
the
next
time
it
runs,
it
will
skip
Step
12.
12.The
BIOS
copies
itself
to
flash
at
0x80000,
and
switches
the
mapping
of
flash
and
RAM
so
that
RAM
is
at
0x80000
and
flash
is
at
0x00000.
As
soon
as
this
remapping
is
done,
the
BIOSís
execution
of
instructions
begins
happening
in
flash.
13.Dynamic
C
is
now
ready
to
compile
a
user
program.
When
the
user
compiles
his
pro-
gram
to
the
target,
it
is
first
written
to
a
file,
then
the
file
is
loaded
to
the
target
using
the
BIOS’
FSM.
The
file
is
used
as
an
intermediate
step
because
fix-ups
are
done
after
the
compilation
is
complete
and
all
unknown
addresses
are
resolved.
The
fix
ups
would
cause
extra
wear
on
the
flash
if
done
straight
to
the
flash.
14.When
the
program
is
fully
loaded,
Dynamic
C
sets
a
breakpoint
at
the
beginning
of
main
and
runs
the
program
up
to
the
breakpoint.
The
board
has
been
programmed,
and-
Dynamic
C
is
now
is
debug
mode.
15.If
the
programming
cable
is
removed
and
the
target
board
is
reset,
the
user’s
program
will
start
running
automatically
because
the
the
BIOS
will
check
the
SMODE
pins
to
determine
whether
to
run
the
user
application
or
enter
the
debug
kernel.
8 Rabbit
2000
Microprocessor
Designer’s
Handbook 9
4.
Dynamic
C
Rabbit
Programming
Overview
When
Dynamic
C
compiles
the
user’s
program
it
includes
a
BIOS
or
basic
input-output
system.
The
BIOS
a
fairly
small
piece
of
code
that
provides
a
variety
of
low
level
services
for
the
user’s
program.
The
BIOS
also
takes
care
of
microprocessor
system
initialization.
The
BIOS
provides
the
communications
services
required
by
Dynamic
C
for
downloading
code
and
performing
debugging
services
such
as
setting
breakpoints
or
examining
data
variables.The
BIOS
defines
the
setup
of
memory.
An
existing
BIOS
can
be
used
as
a
skel-
eton
BIOS
to
create
a
new
BIOS.
Frequently
it
will
only
be
necessary
to
change
#define
statements
at
the
beginning
of
the
BIOS.
In
this
case
it
is
unnecessary
for
the
user
to
understand
or
work
out
the
details
of
the
memory
setup
and
other
processor
initialization.
The
designer
should
follow
Rabbit
system
design
conventions
so
that
Dynamic
C
can
work
with
his
system.
The
design
conventions
are
listed
below.
•Include
a
standard
Rabbit
programming
cable
(see
Figure 1).
The
standard
10-pin
pro-
gramming
connector
provides
a
connection
to
serial
port
A
and
allows
the
PC
to
reset
and
cold-boot
the
target
system.
•Connect
a
static
RAM
having
at
least
32K
to
chip
select
#1
(/CS1,
/OE1,
/WE1).
It
is
useful
if
the
PC
board
footprint
can
also
accommodate
a
RAM
large
enough
to
hold
all
the
code
anticipated.
If
a
large
RAM
can
be
accommodated,
software
development
will
go
faster.
Although
code
residing
in
some
flash
memory
can
be
debugged,
debugging
and
program
download
is
faster
to
RAM.
There
are
also
types
of
flash
memory
that
can
be
used,
but
they
cannot
support
debugging.
•Connect
a
flash
memory
that
is
on
the
approved
list
and
has
at
least
128K
of
storage
to
chip
select
#0
(/CS0,
/OE0,
/WE0).
Nonapproved
memories
can
be
used,
but
it
may
be
necessary
to
modify
the
BIOS.
Some
systems
designed
to
have
their
program
reloaded
by
an
external
agent
on
each
powerup
may
not
need
any
flash
memory.
•Install
a
crystal
or
oscillator
with
a
frequency
of
32.768
kHz
to
drive
the
battery-back-
able
clock.
(Battery-backing
is
optional,
but
the
clock
is
used
in
the
cold-boot
sequence
to
generate
a
known
baud
rate.)
•Install
a
crystal
or
oscillator
for
the
main
processor
clock
that
is
a
multiple
of
614.4 kHz,
or
better,
a
multiple
of
1.8432
MHz.
These
preferred
clock
frequencies
make
possible
the
generation
of
sensible
baud
rates.
If
the
crystal
frequency
is
a
multi-
ple
of
614.4
kHz,
then
the
same
multiples
of
the
19,200
bps
baud
rate
are
achievable.
Common
crystal
frequencies
to
use
are
3.6864,
7.3728,
11.0592
or
14.7456
MHz,
or
double
these
frequencies.
The
user
may
be
concerned
that
the
requirement
for
a
programming
connector
places
added
cost
overhead
on
his
design.
The
overhead
is
very
small—less
than
$0.25
for
com-
ponents
and
board
space
that
could
be
eliminated
if
the
programming
connector
were
not
made
a
part
of
the
system.
•The
programming
connector
can
also
be
used
for
a
variety
of
other
purposes,
including
user
applications.
A
device
attached
to
the
programming
connector
has
complete
con-
trol
over
the
system
because
it
can
perform
a
hardware
reset
and
load
new
software.
If
10 Rabbit
2000
Microprocessor
this
degree
of
control
is
not
desired
for
a
particular
situation,
then
certain
pins
can
be
left
unconnected
in
the
connecting
cable,
limiting
the
functionality
of
the
connector
to
serial
communications.
Z-World
will
be
developing
products
and
software
that
assume
the
presence
of
the
programming
connector.
•Dynamic
C
and
a
PC
are
not
necessarily
needed
for
the
production
programming
of
flash
memory
since
the
flash
memory
can
be
copied
from
one
controller
to
another
by
cloning.
This
is
done
by
connecting
the
system
to
be
programmed
to
the
same
type
of
system
that
is
already
programmed
by
means
of
a
cloning
cable.
The
cloning
cable
con-
nects
to
both
programming
ports
and
has
a
button
to
start
the
transfer
of
program
and
an
LED
to
display
the
progress
of
the
transfer.
Dynamic
C
programming
uses
the
Rabbit’s
serial
port
A
for
software
development.
How-
ever,
it
is
still
possible,
with
some
restrictions,
for
the
user’s
application
to
also
use
port
A.
4.1
Memory
Organization
The
Rabbit
architecture
is
derived
from
that
of
the
original
Z80
microprocessor.
The
orig-
inal
Z80
instruction
set
used
16-bit
addresses
to
address
a
64K
memory
space.
All
code
and
data
had
to
fit
in
this
64K
space.
The
Rabbit
adopts
a
scheme
similar
to
that
used
by
the
Z180
to
expand
the
available
memory
space.
The
64K
space
is
divided
into
zones
and
a
memory
mapping
unit
or
MMU
maps
each
zone
to
a
block
in
a
larger
memory;
the
larger
memory
is
1 megabyte
in
the
case
of
the
Z180
or
the
Rabbit
2000.
The
zones
are
effec-
tively
windows
to
the
larger
memory.
The
view
from
the
window
can
be
adjusted
so
that
the
window
points
to
different
blocks
in
the
larger
memory.
Figure 2
on
page 12
shows
the
memory
mapping
schematically.
The
Rabbit
has
a
basic
20-bit
or
1-megabyte
physical
memory
space.
In
special
circum-
stances
more
than
1-megabyte
of
memory
can
be
installed
and
accessed
using
auxiliary
memory
mapping
schemes.
Typical
Rabbit
systems
have
two
types
of
physical
memory—
flash
memory
and
static
RAM
memory.
Flash
memory
follows
a
write
once
in
a
while
and
read
frequently
model.
Depending
on
the
particular
type
of
flash
used,
the
flash
memory
will
wear
out
after
it
has
been
written
around
10,000
to
100,000
times.
Rabbit
flash
memory
may
be
small-sector
type
or
large-sector
type.
Small-sector
memory
typically
has
sectors
of
128
or
256
bytes.
Individual
sectors
may
be
separately
erased
and
written.
In
large-sector
memory
the
sectors
are
often
16K
or
64K
or
more.
Small-sector
memory
provides
better
support
for
program
development
and
debugging,
and
large-sec-
tor
memory
is
less
expensive
and
has
faster
access
time.
The
best
solution
will
usually
to
lay
out
a
design
to
accept
several
different
types
of
flash
memory,
including
the
flexible
small-sector
memories
and
the
fast
large-sector
memories.
At
the
present
time
develop-
ment
support
for
programs
tested
in
flash
memory
is
confined
to
flash
memories
with
sec-
tors
of
256
bytes
or
128
bytes.
If
larger
sectors
are
used,
the
code
must
be
debugged
in
RAM
and
then
loaded
to
flash
for
a
final
test
that
does
not
involve
setting
break
points.
In
future
releases
it
is
planned
to
support
direct
debugging
in
large-sector
flash.
Large-sector
flash
is
desirable
for
the
better
access
time
and
power
consumption
specifications
that
are
available.
Designer’s
Handbook 11
Static
RAM
memory
may
or
may
not
be
battery-backed,
which
means
it
retains
its
data
when
power
is
off.
Static
RAM
chips
typically
used
for
Rabbit
systems
are
32K,
64K.
128K,
256K,
or
512K.
When
the
memory
is
battery-backed,
power
is
supplied
at
2
V
to
3V
from
a
backup
battery.
The
shutdown
circuitry
must
keep
the
chip
select
line
high
while
preserving
memory
contents
with
battery
power.
A
basic
Rabbit
system
has
two
static
memory
chips,
one
flash
memory
chip
and
one
RAM
memory
chip.
Additional
static
memory
chips
may
be
added.
If
the
user’s
application
requires
storing
data
in
flash
memory,
particularly
a
lot
of
data,
then
it
will
often
be
pru-
dent
to
add
another
flash
memory
chip
for
the
user’s
data,
creating
a
system
with
three
memory
chips—two
flash
memory
chips
and
one
RAM
chip.
Trying
to
use
a
single
flash
memory
chip
to
store
both
the
user’s
program
and
live
data
that
most
be
frequently
changed
often
creates
software
problems.
When
data
are
written
to
a
small-sector
flash
memory,
the
memory
becomes
inoperative
during
the
5
ms
or
so
that
it
takes
to
write
a
sector.
If
the
same
memory
chip
is
used
to
hold
data
and
the
program,
then
the
execution
of
code
must
cease
during
this
write
time.
The
5
ms
is
timed
out
by
a
small
routine
execut-
ing
from
RAM
while
system
interrupts
are
disabled,
effectively
freezing
the
system
for
5
ms.
The
5ms
lockup
period
can
seriously
affect
real-time
operation.
From
the
point
of
view
of
a
Dynamic
C
programmer,
there
are
a
number
of
different
uses
of
memory.
Each
memory
use
occupies
a
different
segment
in
the
16-bit
address
space.
The
four
segments
are
shown
in
Figure 1
on
page 12.
The
segments
are
named
the
root
segment,
the
data
segment,
the
stack
segment,
and
the
extended
code
segment.
Note:
Logical
addresses
above
0xDFFF
are
referred
to
as
extended
memory,
and
some-
times
all
of
the
logical
memory
below
that
is
sometimes
referred
to
as
“root”
memory.
However
root
in
the
following
context
refers
to
lowest
segment
in
logical
memory,
which
usually
comprises
only
a
part
of
the
non-extended
memory.
•Root
Code—Instructions
in
the
root
segment.
Instructions
may
also
be
stored
in
the
extended
code
segment.
Code
in
the
root
segment
operates
slightly
faster
and
plays
a
special
role
for
certain
special
uses.
The
root
segment
is
normally
mapped
to
flash
memory
since
the
code
does
not
change
except
when
the
system
is
reprogrammed.
•Root
Constants—C
constants,
such
as
quoted
strings
or
data
tables
are
stored
in
flash
memory
in
the
root
segment.
This
constants
intermixed
with
root
code.
The
constants
only
change
when
the
system
is
reprogrammed.
•Root
Variables—Root
variables
are
stored
in
the
data
segment
which
is
mapped
to
RAM.
Variables
include
C
variables,
including
structures
and
arrays
that
are
not
initial-
ized
to
a
fixed
value.
•Stack
Memory—Stack
is
implemented
in
the
stack
segment.
The
stack
segment
is
nor-
mally
4K
long
and
is
always
mapped
to
RAM.
Multiple
stacks
may
be
implemented
by
defining
several
stacks
in
the
4k
space
or
by
remapping
the
4K
space
to
different
loca-
tions
in
physical
RAM
memory,
or
by
using
both
approaches.
12 Rabbit
2000
Microprocessor
•Extended
Code—Instructions
not
in
root
that
often
require
20-bit
addressing
for
access.
These
are
accessed
via
the
extended
code
segment,
which
is
an
8K
page
for
executing
code.
Up
to
a
megabyte
of
code
can
be
executed
by
moving
the
mapping
of
the
8K
window
using
special
instructions
(long
call,
long
jump
and
long
return)
that
are
designed
for
this
purpose.
•Extended
Constants—Constant
data
not
in
root
that
requires
20-bit
addressing
for
access.
This
is
mixed
together
with
the
extended
code.
•Extended
Bulk
Memory—Data
items
stored
in
multimegabyte
memory
and
accessed
using
special
functions
using
32-bit
addressing.
Code
may
be
placed
in
either
extended
memory
or
root
memory.
Code
executes
slightly
more
efficiently
in
root
memory.
In
large
programs
the
bulk
of
code
is
stored
in
extended
code
memory.
Since
root
constants
and
root
variables
share
the
memory,
space
needed
for
root
code,
and
as
the
memory
needed
for
constants
or
variables
increases,
the
amount
of
code
that
can
be
stored
in
root
must
decline
by
moving
code
to
extended
memory.
The
rel-
ative
size
of
the
root
and
data
segments
can
be
adjusted
in
4K
steps.
Figure
2.
Schematic
Map
of
16-bit
Addressing
Space
It
should
be
clear
from
the
above
Dynamic
C
memory
types
that
the
Rabbit
does
not
have
a
“flat”
memory
space.
The
advantage
of
the
Rabbit’s
memory
organization
is
that
the
use
of
16-bit
addresses
and
pointers
is
retained,
ensuring
that
the
code
is
compact
and
executes
quickly.
4.1.1
The
Root
(or
Base)
Segment
The
root
segment
has
a
typical
minimum
size
of
8K
and
a
maximum
size
of
48K.
The
larger
the
root
segment,
the
smaller
the
data
segment
and
vice-versa.
Root
segment
address
zero
is
always
mapped
to
20-bit
address
zero.
Usually
the
root
segment
is
mapped
64K
56k
52K
0k
Extended
Code
Segment
Stack
Segment
Data
Segment
Root
Segment
1-megabyte
Typical
mapping
16-bit
to
20-bit
address
space
RAM
Flash quadrant
0
quadrant
3
quadrant
1
quadrant
2
flash
RAM
RAM
Designer’s
Handbook 13
to
flash
memory.
It
may
be
mapped
to
RAM
for
debugging,
or
if
it
is
decided
to
copy
code
to
RAM
to
take
advantage
of
faster
access
time
offered
by
RAM.
The
root
segment
holds
a
mixture
of
code
and
constants.
C
functions
or
assembly
language
programs
that
are
com-
piled
to
the
root
segment
are
interspersed
with
data
constants.
Data
constants
are
inserted
between
blocks
of
code.
Data
constants
defined
inside
a
C
function
are
emitted
after
the
end
of
the
code
belonging
to
the
function.
Data
constants
defined
outside
of
C
functions
are
emitted
as
encountered
in
the
source
code.
Except
in
small
programs,
the
bulk
of
the
code
is
executed
using
the
extended
memory
window.
But
the
root
segment
has
special
properties
that
make
it
better
for
some
types
of
code.
The
types
of
subroutines
and
functions
that
are
best
placed
in
the
root
segment
are
as
follows.
1. Short
subroutines
of
about
20
instructions
or
less
that
are
frequently
called
will
use
sig-
nificantly
less
execution
time
if
placed
in
the
root
because
of
the
faster
calling
linkage
for
16-bit
versus
20-bit
addresses.
A
call
and
return
using
16-bit
addressing
requires
20
clocks,
compared
to
32
clocks
for
20-bit
addressing.
2. Interrupt
routines.
Interrupts
use
16-bit
addressing
so
the
entry
to
an
interrupt
routine
must
be
in
root.
3. Functions
called
indirectly
using
traditional
C
pointers.
4. The
BIOS
core.
A
certain
part
of
the
BIOS
must
be
at
the
start
of
the
root
segment.
Figure
3.
Typical
Layout
of
Root
Segment
4.1.2
The
Data
Segment
The
data
segment
is
mapped
to
RAM
and
contains
C
variables.
Typically
it
starts
at
8K
or
above
and
ends
at
52K.
Data
allocation
starts
at
or
near
the
top
and
proceeds
in
a
down-
ward
direction.
It
is
also
possible
to
place
executable
code
in
the
data
segment
if
it
is
cop-
ied
from
flash
to
the
data
segment.
This
can
be
desirable
for
code
that
is
self
modifying,
code
to
implement
debugging
aids
or
code
that
controls
write
to
the
flash
memory
and
0K
System
Constants
BIOS
Start
System
ID
(256
bytes)
BIOS
Functions
Constant
defs
Max
48K
14 Rabbit
2000
Microprocessor
cannot
execute
from
flash.
In
some
cases
the
RAM
may
require
fewer
wait
states
so
code
executes
faster
if
copied
to
RAM.
4.1.3
The
Stack
Segment
The
stack
segment
normally
is
from
52K
to
56K.
It
is
mapped
to
RAM
and
holds
the
sys-
tem
stack.
If
there
are
multiple
stacks
then
multiple
mappings
with
multiple
stacks
in
each
mapping
can
be
used.
For
example
if
16
stacks
of
1k
length
are
needed
then
4
stacks
can
be
placed
in
each
4k
mapping
and
4
different
mappings
for
the
window
can
be
used.
4.1.4
The
Extended
Memory
Segment
This
8K
segment
from
56K
to
64K
is
used
to
execute
extended
code
and
it
is
also
used
by
routines
that
manipulate
data
located
in
extended
memory.
While
executing
code
the
map-
ping
is
shifted
by
4K
each
time
the
code
passes
the
60K
point.
Large
code
can
be
effi-
ciently
executed
while
using
up
only
8K
of
16-bit
addressing
space.
4.2
How
The
Compiler
Compiles
to
Memory
The
compiler
actually
generates
code
for
root
code,
constants,
extended
code
and
extended
constants.
It
allocates
space
for
data
variables,
but,
except
for
constants,
does
not
generate
data
to
be
stored
in
memory.
Any
initialization
of
variables
must
be
accom-
plished
by
code
since
the
compiler
is
not
present
when
the
program
starts
in
the
field.
In
any
but
the
smallest
programs,
most
of
the
code
is
compiled
to
extended
memory.
This
code
executes
in
the
8K
window
from
E000
to
FFFF.
This
8K
window
uses
paged
access.
Instructions
that
use
16-bit
addressing
can
jump
within
the
page
and
also
outside
of
the
page
to
the
remainder
of
the
64K
logical
space.
Special
instructions,
particularly
lcall,
ljp,
and
lret,
are
used
to
access
code
outside
of
the
8K
window.
When
one
of
these
transfer-of-control
instructions
is
executed,
both
the
address
and
the
view
through
the
8K
window
change,
allowing
transfer
to
any
instruction
in
the
1M
physical
memory
space.
The
8-bit
XPC
register
controls
which
of
two
consecutive
4K
pages
the
8K
window
aligns
with
(there
are
256
pages.)
The
16-bit
PC
controls
the
address
of
the
instruction,
usually
in
the
region
E000
to
FFFF.
The
advantage
of
paged
access
is
that
most
instructions
con-
tinue
to
use
16-bit
addressing.
Only
when
a
page
change
is
needed
does
a
20-bit
transfer
of
control
need
to
be
made.
As
the
compiler
compiles
code
in
the
extended
code
window,
it
checks
at
opportune
times
to
see
if
the
code
has
passed
the
midpoint
of
the
window
or
F000.
When
the
code
passes
F000,
the
compiler
slides
the
window
down
by
4K
so
that
the
code
at
F000+x
becomes
resident
at
E000+x.
This
automatic
paging
results
in
the
code
being
divided
into
segments
that
are
typically
4K
long,
but
which
can
be
very
short
or
as
long
as
8K.
Transfer
of
con-
trol
within
each
segment
can
be
accomplished
by
16-bit
addressing.
Between
segments,
20-bit
addressing
is
required.
Designer’s
Handbook 17
5.
The
Rabbit
BIOS
The
Dynamic
C
programming
system
for
the
Rabbit
uses
the
concept
of
a
BIOS
(basic
input
output
system).
The
BIOS
is
a
separate
program
file
that
contains
the
basic
code
needed
to
interface
with
Dynamic
C.
It
also
normally
contains
a
software
interface
to
the
user’s
particular
hardware.
Certain
drivers
in
the
Dynamic
C
libraries
require
BIOS
rou-
tines
to
perform
tasks
that
are
hardware-dependent.
When
the
user
compiles
a
program
under
Dynamic
C,
the
BIOS
is
compiled
first
as
an
integral
part
of
the
user’s
program.
A
single
general-purpose
BIOS
is
supplied
with
Dynamic
C
for
the
Rabbit.
This
BIOS
will
allow
you
to
boot
Dynamic
C
on
any
Rabbit-based
system
that
follows
the
basic
design
rules
needed
to
support
Dynamic
C.
The
BIOS
requires
either
both
a
flash
memory
and
a
32K
or
larger
RAM,
or
just
a
128K
RAM,
for
it
to
be
possible
to
compile
and
run
Dynamic
C
programs.
If
the
user
uses
a
flash
memory
from
the
list
of
flash
memories
that
are
already
supported
by
the
BIOS,
the
task
will
be
simplified.
If
the
flash
memory
chip
is
not
already
supported,
the
user
will
have
to
write
a
driver
to
perform
the
write
operation
on
the
flash
memory.
This
is
not
difficult
provided
that
a
system
with
128K
of
RAM
and
the
flash
memory
to
be
used
is
available
for
testing.
5.1
Startup
Conditions
Set
Up
By
the
BIOS
The
BIOS
sets
up
initial
values
for
the
following
registers
by
means
of
code
and
declara-
tions.
•The
four
memory
bank
control
registers
—MB0CR,
MB1CR,
MB2CR,
and
MB3CR—are
8-
bit
registers,
each
associated
with
one
quadrant
of
the
1M
memory
space.
Each
register
determines
which
memory
chip
will
be
mapped
into
its
quadrant,
how
many
wait
states
will
be
used
for
accessing
that
memory
chip,
and
whether
the
memory
chip
will
be
write
protected.
•The
STACKSEG
register
is
an
8-bit
register
that
determines
the
location
of
the
stack
seg-
ment
in
the
1M
memory.
•The
DATASEG
register
is
an
8-bit
register
that
determines
the
location
of
the
data
seg-
ment
in
the
1M
memory,
normally
the
location
of
the
data
variable
space.
•The
SEGSIZE
register
is
an
8-bit
register
holding
two
4-bit
registers.
Together
the
reg-
isters
determine
the
relative
size
of
the
root
code,
data
segment
and
stack
segment
in
the
64K
root
space.
•The
MMIDR
register
is
an
8-bit
register
that
modifies
memory
system
functions
having
to
do
with
support
for
battery-backed
memory
and
separate
instruction
and
data
space
control.
•The
XPC
register
is
used
to
address
extended
code
memory.
Normally
the
user’s
code
frequently
changes
this
register.
The
BIOS
sets
the
initial
value.
•The
SP
register
is
the
system
stack
pointer.
It
is
frequently
changed
by
the
user’s
code.
The
BIOS
sets
up
an
initial
value.
All
together
there
are
11
MMU,
MIU
registers
that
are
set
up
by
the
BIOS.
These
registers
determine
all
aspects
of
the
hardware
setup
of
the
memory.
18 Rabbit
2000
Microprocessor
In
addition,
a
number
of
origin
declarations
are
made
in
the
BIOS
to
tell
the
Dynamic
C
compiler
where
to
place
different
types
of
code
and
data.
The
compiler
maintains
a
num-
ber
of
assembly
counters
that
it
uses
to
place
or
allocate
root
code,
extended
code,
data
constants,
data
variables,
and
extended
data
variables.
Each
of
these
counters
has
a
start-
ing
location
and
a
block
size.
5.2
BIOS
Flowchart
The
following
flowchart
summarizes
the
functionality
of
the
BIOS:
Figure
5.
BIOS
Flowchart
Start
at
address
0
Initialize
BIOS
Flag? Yes Relocate
BIOS
if
necessary.
Clear
flag
in
source
code.
Setup
memory
control
and
ba-
sic
BIOS
ser-
vices.
Is
the
program-
ming
cable
connected?
Start
Dynamic
C
communications
and
state
ma-
chine.
Divert
to
BIOS
service?
Act
as
master
for
program
cloning.
Service
diag-
nostic
port.
(not
yet
available)
Remote
pro-
gram
down-
load.
(not
yet
available)
Call
user
appli-
cation
program
(main).
BIOS
services
for
user
appli-
cation
pro-
gram.
Application
Program
Other manuals for 2000
6
Table of contents
Other Rabbit Computer Hardware manuals
Rabbit
Rabbit RabbitCore RCM2200 User manual
Rabbit
Rabbit 2000 User manual
Rabbit
Rabbit RabbitCore RCM2200 User manual
Rabbit
Rabbit RCM2100 User manual
Rabbit
Rabbit 2000 User manual
Rabbit
Rabbit RCM2000 User manual
Rabbit
Rabbit 2000 User manual
Rabbit
Rabbit 2000 User manual
Rabbit
Rabbit 3000 User manual
Rabbit
Rabbit RabbitCore RCM4100 User manual
