z80.doc 2.9 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
  1. . \" $Id$
  2. .ND April 1985
  3. .TL
  4. THE Z80 BACK END TABLE
  5. .AU
  6. Frans van Haarlem
  7. .NH 1
  8. INTRODUCTION
  9. .PP
  10. This table was written to make it run, not to make it clever!
  11. The effect is, that the table written for the intel 8080,
  12. which was made very clever runs faster and requiers less space!!
  13. So, for anyone to run programs on a z80 machine:
  14. n attempt could be made to make this table as clever as the one for the i80,
  15. or the i80 table could be used, for that can run on every z80 too.
  16. .NH
  17. IMPLEMENTATION
  18. .PP
  19. It will not be possible to run the entire Amsterdam Compiler Kit on a
  20. Z80-based computer system.
  21. One has to write a program on another
  22. system, a system where the compiler kit runs on.
  23. This program may be a mixture of high-level languages, such as
  24. C or Pascal, EM and z80 assembly code.
  25. The program should be compiled using the compiler kit,
  26. producing z80 machine code.
  27. This code should come available to the z80 machine
  28. for example by downloading or
  29. by storing it in ROM (Read Only Memory).
  30. Depending on the characteristics of the particular z80 based system, some
  31. adaptions have to be made:
  32. .IP 1)
  33. In \fIhead_em\fP: the base address, which is the address where the first
  34. z80 instruction will be stored, and the initial value of the
  35. stackpointer are set to 0x1000 and 0x7ffe respectivally.
  36. The latter because it could run on a 32K machine as well.
  37. Other systems require other values.
  38. .IP 2)
  39. In \fIhead_em\fP: before calling "__m_a_i_n", the environment
  40. pointer, argument vector and argument count will have to be pushed
  41. onto the stack.
  42. Since this back-end is tested on a system without any knowledge
  43. of these things, dummies are pushed now.
  44. .IP 3)
  45. In \fItail_em\fP: proper routines "putchar" and "getchar" should
  46. be provided.
  47. They should write resp. read a character on/from the monitor.
  48. Maybe some conversions will have to be made.
  49. The ones for the Nascom and Hermac z80 micro's are to be found
  50. in the EM-library.
  51. .IP 4)
  52. In \fIhead_em\fP: an application program returns control to the monitor by
  53. jumping to address 0x20.
  54. Thie may have to be changed on different systems.
  55. For an CPM-machine for example this should be 0x5, to provide a warm boot.
  56. .IP 5)
  57. In \fItail_em\fP: the current version of the z80 back-end has very limited I/O
  58. capabilities, because it was tested on a system that
  59. had no knowlegde of files.
  60. So the implementation of the EM-instruction \fImon\fP is very simple;
  61. it can only do the following things:
  62. .DS
  63. Monitor call 1:
  64. Exit
  65. Monitor call 3:
  66. read, always reads from the monitor.
  67. echos the read character.
  68. ignores file descriptor.
  69. Monitor call 4:
  70. write, always writes on the monitor.
  71. ignores file descriptor.
  72. Monitor call 5:
  73. open file, returns file descriptor -1.
  74. Monitor call 6:
  75. close file, returns error code = 0.
  76. Monitor call 54:
  77. io-control, returns error code = 0.
  78. .DE
  79. If the system should do file-handling the routine ".mon"
  80. should be extended thoroughly.