1986-02-28 18:02:00 +00:00
|
|
|
. \" $Header$
|
|
|
|
.ND April 1985
|
|
|
|
.TL
|
1985-04-01 14:00:00 +00:00
|
|
|
THE Z80 BACK END TABLE
|
1986-02-28 18:02:00 +00:00
|
|
|
.AU
|
|
|
|
Frans van Haarlem
|
|
|
|
.NH 1
|
1985-04-12 20:07:13 +00:00
|
|
|
INTRODUCTION
|
1986-02-28 18:02:00 +00:00
|
|
|
.PP
|
1985-04-12 20:07:13 +00:00
|
|
|
This table was written to make it run, not to make it clever!
|
|
|
|
The effect is, that the table written for the intel 8080,
|
|
|
|
which was made very clever runs faster and requiers less space!!
|
|
|
|
So, for anyone to run programs on a z80 machine:
|
|
|
|
You could try to make the table as clever as the one for the i80,
|
|
|
|
or you could run the i80 table, for that can run on every z80 too.
|
1986-02-28 18:02:00 +00:00
|
|
|
.NH
|
1985-04-01 14:00:00 +00:00
|
|
|
IMPLEMENTATION
|
1986-02-28 18:02:00 +00:00
|
|
|
.PP
|
1985-04-01 14:00:00 +00:00
|
|
|
It will not be possible to run the entire Amsterdam Compiler Kit on a
|
|
|
|
Z80-based computer system.
|
|
|
|
One has to write a program on another
|
|
|
|
system, a system where the compiler kit runs on.
|
|
|
|
This program may be a mixture of high-level languages, such as
|
|
|
|
C or Pascal, EM and z80 assembly code.
|
|
|
|
The program should be compiled using the compiler kit,
|
|
|
|
producing z80 machine code.
|
|
|
|
This code should come available to the z80 machine
|
|
|
|
for example by downloading or
|
|
|
|
by storing it in ROM (Read Only Memory).
|
|
|
|
Depending on the characteristics of the particular z80 based system, some
|
|
|
|
adaptions have to be made:
|
1986-02-28 18:02:00 +00:00
|
|
|
.IP 1)
|
|
|
|
In \fIhead_em\fP: the base address, which is the address where the first
|
|
|
|
z80 instruction will be stored, and the initial value of the
|
|
|
|
stackpointer are set to 0x1000 and 0x7ffe respectivally.
|
|
|
|
The latter because it could run on a 32K machine as well.
|
|
|
|
Other systems require other values.
|
|
|
|
.IP 2)
|
|
|
|
In \fIhead_em\fP: before calling "_m_a_i_n", the environment
|
|
|
|
pointer, argument vector and argument count will have to be pushed
|
|
|
|
onto the stack.
|
|
|
|
Since this back-end is tested on a system without any knowledge
|
|
|
|
of these things, dummies are pushed now.
|
|
|
|
.IP 3)
|
|
|
|
In \fItail_em\fP: proper routines "putchar" and "getchar" should
|
|
|
|
be provided.
|
|
|
|
They should write resp. read a character on/from the monitor.
|
|
|
|
Maybe some conversions will have to be made.
|
|
|
|
The ones for the Nascom and Hermac z80 micro's are to be found
|
|
|
|
in the EM-library.
|
|
|
|
.IP 4)
|
|
|
|
In \fIhead_em\fP: an application program returns control to the monitor by
|
|
|
|
jumping to address 0x20.
|
|
|
|
If this is not the right way on your system, change it.
|
|
|
|
For an CPM-machine for example this should be 0x5, to provide a warm boot.
|
|
|
|
.IP 5)
|
|
|
|
In \fItail_em\fP: the current version of the z80 back-end has very limited I/O
|
|
|
|
capabilities, because it was tested on a system that
|
|
|
|
had no knowlegde of files.
|
|
|
|
So the implementation of the EM-instruction \fImon\fP is very simple;
|
|
|
|
it can only do the following things:
|
|
|
|
.DS
|
1985-04-01 14:00:00 +00:00
|
|
|
Monitor call 1:
|
|
|
|
Exit
|
|
|
|
Monitor call 3:
|
|
|
|
read, always reads from the monitor.
|
|
|
|
echos the read character.
|
|
|
|
ignores file descriptor.
|
|
|
|
Monitor call 4:
|
|
|
|
write, always writes on the monitor.
|
|
|
|
ignores file descriptor.
|
|
|
|
Monitor call 5:
|
|
|
|
open file, returns file descriptor -1.
|
|
|
|
Monitor call 6:
|
|
|
|
close file, returns error code = 0.
|
|
|
|
Monitor call 54:
|
|
|
|
io-control, returns error code = 0.
|
1986-02-28 18:02:00 +00:00
|
|
|
.DE
|
1985-04-01 14:00:00 +00:00
|
|
|
If the system should do file-handling the routine ".mon"
|
|
|
|
should be extended thoroughly.
|