|
57
|
1 \documentstyle[12pt,a4wide]{report}
|
|
|
2 \title{SBC09, an Emulator for a 6809-Based Single Board Compuer.}
|
|
|
3 \author{L.C. Benschop}
|
|
|
4 \begin{document}
|
|
|
5 \def\SetFigFont#1#2#3{\rm}
|
|
|
6
|
|
|
7 \maketitle
|
|
|
8 \tableofcontents
|
|
|
9 \chapter{Introduction}
|
|
|
10
|
|
|
11 The {\tt sbc09} package contains an emulator of a 6809-based single board
|
|
|
12 computer that runs under UNIX. It contains all the programs needed to work
|
|
|
13 with the emulator, such as the emulator itself, an assembler, a monitor
|
|
|
14 program, a BASIC interpreter, a Forth interpreter, several example programs
|
|
|
15 and several tools needed to build the programs. The program should work
|
|
|
16 under most more-or-less POSIX-compliant versions of UNIX and they were
|
|
|
17 developed under Linux. Of course I believe that the programs that currently
|
|
|
18 run on the emulator would also run on a real 6809 machine.
|
|
|
19
|
|
|
20 \section{A Bit of Background on SBCs.}
|
|
|
21
|
|
|
22 In the seventies you could buy single board microcomputers that had a
|
|
|
23 hexadecimal keypad and 7-segment displays. These computers typically had
|
|
|
24 less than 1 kilobyte of RAM and a simple monitor program in ROM. An
|
|
|
25 interface to a cassette recorder (or paper tape reader/writer) and a
|
|
|
26 terminal was possible, but not standard. The typical way to program the
|
|
|
27 machine was entering hexadecimal machine codes on the keypad. Machine code
|
|
|
28 was the only language in which you could program them, especially if you
|
|
|
29 only had a hexadecimal keypad and 7-segment led displays. You typically used
|
|
|
30 these machines to experiment with hardware interfacing, as games and
|
|
|
31 calculations were a bit limited with only six 7-sengment digits.
|
|
|
32
|
|
|
33 Next came simple home computers, like the TRS80, the Apple ][ and the
|
|
|
34 Commodore PET. These machines had BASIC in ROM and they used a simple
|
|
|
35 cassette recorder to store data. These computers had a TV or a low quality
|
|
|
36 monitor as display and a QWERTY keyboard. These machines could be upgraded
|
|
|
37 with a floppy disk drive and a printer and then they could be used for
|
|
|
38 professional work. These machines had 4 to 64 kilobyts of memory.
|
|
|
39 Apart from assembly language you could use BASIC, Forth
|
|
|
40 and sometimes Pascal to program these machines. Most useful programs (and
|
|
|
41 the best games) were programmed in assembly language. Many of these machines
|
|
|
42 had BASIC in ROM and no machine code monitor. You had to load that
|
|
|
43 separately.
|
|
|
44
|
|
|
45 Today we have personal computers that run DOS, Windows, UNIX or something
|
|
|
46 else. New computers have 4 to 16 megabytes of RAM and hard disks of more
|
|
|
47 than 500 Megabytes. Apart from having in the order of 1000 times more
|
|
|
48 storage, they are also 1000 times faster than the old 8-bit home computers.
|
|
|
49 Programming? You can use Visual BASIC, C++ and about
|
|
|
50 every other programming language on the planet. But programs have become
|
|
|
51 bigger and bigger. Programming is not the same as it was before.
|
|
|
52
|
|
|
53 I guess there is some demand for small 8-bit computer systems that are simple
|
|
|
54 to build, easy to interface to all kinds of hobby projects, fun to program
|
|
|
55 and small enough to integrate into a home-built project.
|
|
|
56 Do we want to use hexadecimal keyboards and 7-segment displays? I guess not
|
|
|
57 many people want to use them. Do we want to use a cassette recorder for data
|
|
|
58 storage and a TV as a display? Not me. And if you build your own 8-bit
|
|
|
59 microprocessor, do you want to waste your time and money on a hexadecimal
|
|
|
60 keypad or a cassette interface that you do not like to use and that you do
|
|
|
61 not need anyway? PCs of five years ago are more than adequate to run an
|
|
|
62 editor, a terminal program and a cross assembler for your favourite 8-bit
|
|
|
63 processor. The terminal program can then be used to send the programs to the
|
|
|
64 8-bit micro.
|
|
|
65 If you equip an 8-bit system with some static CMOS RAM, a serial
|
|
|
66 interface and a monitor in ROM, you can use the keyboard, hard disk and
|
|
|
67 monitor of your PC for program development and the 8-bit micro can be
|
|
|
68 disconnected from the PC and do its task, once it is programmed.
|
|
|
69
|
|
|
70 Cross development is nothing special. How do you think the microprocessor in
|
|
|
71 you microwave was programmed? But it is not practical for a hobbyist to
|
|
|
72 program an EPROM for each program change. Professional developers of
|
|
|
73 embedded processors have expensive tools, like ROM emulators, processor
|
|
|
74 emulators etc. to see what the processor is doing on its way to the next
|
|
|
75 crash. For a hobbyist it is much more practical to have a slightly more
|
|
|
76 expensive embedded computer that you can run an interactive debugger on.
|
|
|
77 And you are not even limited to assembly language. If you have 32k ROM you
|
|
|
78 can have both the monitor program and a BASIC interpreter and some
|
|
|
79 aplication code in ROM. Nothing prevents you from having Forth as well.
|
|
|
80
|
|
|
81 \section{The Emulated System.}
|
|
|
82
|
|
|
83 \begin{figure}
|
|
|
84 \input{sbc09fig.tex}
|
|
|
85 \caption{Block Diagram of SBC.}
|
|
|
86 \end{figure}
|
|
|
87
|
|
|
88 The program {\tt sbc09} emulates the abovementioned single board computer
|
|
|
89 {\em plus} the terminal program that communicates with it.
|
|
|
90
|
|
|
91 \chapter{Building the Programs.}
|
|
|
92
|
|
|
93 \chapter{The 6809 Assembler {\tt a09}.}
|
|
|
94
|
|
|
95 The assembler is a09. Run it with
|
|
|
96 \begin{verbatim}
|
|
|
97 a09 [-l listing] [-o object|-s object] source
|
|
|
98 \end{verbatim}
|
|
|
99
|
|
|
100 Source is a mandatory argument. The -l listing and {\tt -o} or {\tt -s}
|
|
|
101 object arguments are
|
|
|
102 optional. By default there is no listing and the object file is the
|
|
|
103 sourcefile name without an extension and if the source file name has no
|
|
|
104 extension it is the source file name with {\tt .b} extension.
|
|
|
105
|
|
|
106 A09 recognizes standard 6809 mnemonics. Labels should start in the first
|
|
|
107 column and may or may not be terminated by a colon. Every line starting with
|
|
|
108 a non-alphanumeric is taken to be a comment line. Everything after the
|
|
|
109 operand field is taken to be comment. There is a full expression evaluator
|
|
|
110 with C-style operators (and Motorola style number bases).
|
|
|
111
|
|
|
112 There are the usual pseudo-ops such as ORG EQU SET SETDP RMB FCB FDB FCC etc.
|
|
|
113 Strings within double quotes may be mixed with numbers on FCB lines. There
|
|
|
114 is conditional assembly with IF/ELSE/ENDIF and there is INCLUDE. The
|
|
|
115 assembler is case-insensitive.
|
|
|
116
|
|
|
117 The object file is either a binary image file (-o) or Motorola S-records (-s).
|
|
|
118 In the former case it contains a binary image of the assembled data starting
|
|
|
119 at the first address where something is assembled. In the following case
|
|
|
120 \begin{verbatim}
|
|
|
121 ORG 0
|
|
|
122 VAR1 RMB 2
|
|
|
123 VAR2 RMB 2
|
|
|
124
|
|
|
125 ORG $100
|
|
|
126 START LDS #$400
|
|
|
127 ...
|
|
|
128 \end{verbatim}
|
|
|
129
|
|
|
130 the RMB statements generate no data so the object file contains the memory
|
|
|
131 image from address \$100.
|
|
|
132
|
|
|
133 The list file contains no pretty lay-out and no pagination. It is assumed
|
|
|
134 that utilities (Unix pr or enscript) are available for that.
|
|
|
135
|
|
|
136 There are no macros and no linkable modules yet. Some provisions are taken
|
|
|
137 for it in the code.
|
|
|
138
|
|
|
139 After the assembler has finished, it prints the number of pass 2 errors.
|
|
|
140 This should be zero. So if you see
|
|
|
141 \begin{verbatim}
|
|
|
142 0 Pass 2 Errors.
|
|
|
143 \end{verbatim}
|
|
|
144 then you are lucky.
|
|
|
145
|
|
|
146 \chapter{The Virtual SBC {\tt v09}.}
|
|
|
147
|
|
|
148 The simulator is v09. Run it with
|
|
|
149 \begin{verbatim}
|
|
|
150 v09 [-t tracefile [-tl tracelo] [-th tracehi]] [-e escchar]
|
|
|
151 \end{verbatim}
|
|
|
152
|
|
|
153 {\tt tracelo} and {\tt tracehi} are addresses. They can be entered in
|
|
|
154 decimal, octal or hex using the C conventions for number input.
|
|
|
155
|
|
|
156 If a tracefile is specified, all instructions at addresses between
|
|
|
157 {\tt tracelo} and {\tt tracehi} are traced. Tracing information such as program
|
|
|
158 location, register contents and opcodes are written to the trace file.
|
|
|
159
|
|
|
160 {\tt escchar} is the escape character. It must be entered as a number. This is
|
|
|
161 the character that you must type to get the v09 prompt. This is control-]
|
|
|
162 by default. (0x1d)
|
|
|
163
|
|
|
164 The program loads its ROM image from the file {\tt v09.rom}, which is a 32
|
|
|
165 kiliobyte binary file. This file should have been generated by the {\tt
|
|
|
166 Makefile}. The program starts executing at the address found at \$FFFE in
|
|
|
167 the ROM, just like a real 6809 would do on reset.
|
|
|
168
|
|
|
169 The address map is as follows.
|
|
|
170 \begin{description}
|
|
|
171 \item[\$0000--\$7FFF] RAM.
|
|
|
172 \item[\$8000--\$FFFF] ROM (except the I/O addresses). These addresses are
|
|
|
173 write-protected.
|
|
|
174 \item[\$E000--\$E0FF] I/O addresses. Currently only one ACIA is mapped.
|
|
|
175 \end{description}
|
|
|
176
|
|
|
177 At addresses \$E000 and \$E001 there is an emulated serial port (ACIA). All
|
|
|
178 bytes sent to it (or read from it) are send to (read from) the terminal and
|
|
|
179 sometimes to/from a file.
|
|
|
180 Terminal I/O is in raw mode.
|
|
|
181
|
|
|
182 If you press the escape char, you get the v09 prompt. At the prompt you
|
|
|
183 can enter the following things.
|
|
|
184 \begin{description}
|
|
|
185 \item[X] to exit the simulator.
|
|
|
186 \item[R] to reset the emulated 6809 (very useful).
|
|
|
187 \item[Lfilename] (no space in between) to log terminal output to a file.
|
|
|
188 Control chars and cr are filtered to make the output a normal
|
|
|
189 text file. L without a file name stops logging.
|
|
|
190 \item[Sfilename] to send a specified file to the simulator through its terminal
|
|
|
191 input. LF is converted to CR to mimic raw terminal input.
|
|
|
192 \item[Ufilename] (terminal upload command) to send a file to the 6809 using the
|
|
|
193 X-modem protocol. The 6809 must already run an X-modem receiving
|
|
|
194 program.
|
|
|
195 \item[Dfilename] (terminal download command) to receive a file from the 6809 using
|
|
|
196 the X-modem protocol. The 6809 must already run an X-modem
|
|
|
197 sending program.
|
|
|
198 \end{description}
|
|
|
199 All of these commands, except the R command, can be seen as commands of the
|
|
|
200 communication program that is used to access the single board computer.
|
|
|
201 The R command is a subsitute for pushing the RESET button on the emulated
|
|
|
202 computer.
|
|
|
203
|
|
|
204 \chapter{Machine Language Monitor.}
|
|
|
205
|
|
|
206 The program {\tt monitor.asm} is a program that is intended to be included
|
|
|
207 in the ROM of a 6809 based single board computer. The program allows a user
|
|
|
208 to communicate with the single board computer through a serial port. It
|
|
|
209 allows a user to enter machine code, examine memory and registers, to set
|
|
|
210 breakpoints, to trace a program and more. Furthermore, data can be sent to
|
|
|
211 and be received from the single board computer through the X-MODEM protocol.
|
|
|
212
|
|
|
213 \subsection{Getting Started.}
|
|
|
214
|
|
|
215 If you start v09 with the standard ROM, then you will run the monitor
|
|
|
216 program.
|
|
|
217 If all goes well you see something like
|
|
|
218 \begin{verbatim}
|
|
|
219 Welcome to BUGGY 1.0
|
|
|
220 \end{verbatim}
|
|
|
221 and you can type text. Excellent, you are now running 6809 code.
|
|
|
222
|
|
|
223 The following example programs you can run from the 6809 monitor.
|
|
|
224 All of them start at address \$400. For example to run the program bin2dec
|
|
|
225 you type.
|
|
|
226
|
|
|
227 XL400
|
|
|
228
|
|
|
229 Then press your escape character (default is control-] ).
|
|
|
230
|
|
|
231 Then at the v09 prompt type
|
|
|
232
|
|
|
233 ubin2dec
|
|
|
234
|
|
|
235 Now you see some lines displaying the progress of the X-modem session.
|
|
|
236 If that is finished, you type
|
|
|
237
|
|
|
238 G400
|
|
|
239
|
|
|
240 Now it runs and exits to the monitor with SWI, so that the registers are
|
|
|
241 displayed.
|
|
|
242
|
|
|
243 \begin{description}
|
|
|
244 \item[cond09.asm]
|
|
|
245 \item[cond09.inc] Nonsense program to show conditional assembly and the like.
|
|
|
246
|
|
|
247 \item[bench09.asm] Benchmark program. Executes tight loop. Takes 83 secs on
|
|
|
248 25 MHz 386. Should take about 8 sec. on 1MHz real 6809. :-(
|
|
|
249
|
|
|
250 \item[test09.asm] Tests some nasty features of the 6809. Prints a few lines
|
|
|
251 of PASSED nn and should never print ERROR nn.
|
|
|
252
|
|
|
253 \item[bin2dec.asm] Unusual way to convert numbers to decimal using DAA instruction.
|
|
|
254 Prints some test numbers.
|
|
|
255
|
|
|
256 \item[basic.asm] Tiny BASIC by John Byrns. Docs are in basic.doc.
|
|
|
257 To test it start the monitor and run basic.
|
|
|
258
|
|
|
259 Then press your escape char.
|
|
|
260 At the v09 prompt type: sexampl.bas
|
|
|
261
|
|
|
262 Now a BASIC program is input.
|
|
|
263 Type RUN to run it.
|
|
|
264
|
|
|
265 Leave BASIC by pressing the escape char and entering x at the
|
|
|
266 prompt.
|
|
|
267 \end{description}
|
|
|
268
|
|
|
269
|
|
|
270 \section{Use of the monitor commands}
|
|
|
271
|
|
|
272
|
|
|
273 \subsection{Single Letter Commands}
|
|
|
274
|
|
|
275 \begin{description}
|
|
|
276 \item[D] Dump memory.
|
|
|
277
|
|
|
278 Syntax:
|
|
|
279 \begin{description}
|
|
|
280 \item[Daddr,len] Hex/ascii dump of memory region.
|
|
|
281 \item[Daddr] length=64 bytes by default.
|
|
|
282 \item[D] address is address after previous dump by default.
|
|
|
283 \end{description}
|
|
|
284
|
|
|
285 Examples:
|
|
|
286 \begin{verbatim}
|
|
|
287 DE400,100
|
|
|
288 \end{verbatim}
|
|
|
289 Dump 256 bytes starting at \$E400
|
|
|
290 \begin{verbatim}
|
|
|
291 D
|
|
|
292 \end{verbatim}
|
|
|
293 Dump the next 64 bytes.
|
|
|
294
|
|
|
295 \item[E] Enter data into memory,
|
|
|
296
|
|
|
297 \begin{description}
|
|
|
298 \item[Eaddr bytes] Enter hexadecimal bytes at address.
|
|
|
299 \item[Eaddr"ascii"] Enter ascii at address.
|
|
|
300 \item[Eaddr] Enter interactively at address (until empty line).
|
|
|
301 \end{description}
|
|
|
302
|
|
|
303 Examples:
|
|
|
304 \begin{verbatim}
|
|
|
305 E0400 86449D033F
|
|
|
306 \end{verbatim}
|
|
|
307 Enter the bytes 86 44 9D 03 3F at address \$400.
|
|
|
308 \begin{verbatim}
|
|
|
309 E5000"Welcome"
|
|
|
310 \end{verbatim}
|
|
|
311 Enter the ASCII codes of "Welcome" at address \$400.
|
|
|
312
|
|
|
313 \item[F] Find string in memory.
|
|
|
314
|
|
|
315 Syntax:
|
|
|
316 \begin{description}
|
|
|
317 \item[Faddr bytes] Find byte string string from address.
|
|
|
318 \item[Faddr"ascii"] Find ASCII string.
|
|
|
319 \end{description}
|
|
|
320
|
|
|
321 Find the specified string in memory, starting at the specified address. The
|
|
|
322 I/O addresses \$E000-\$E0FF are skipped. The addresses of the first 16
|
|
|
323 occurrences are shown.
|
|
|
324
|
|
|
325 Example:
|
|
|
326 \begin{verbatim}
|
|
|
327 FE400"SEX"
|
|
|
328 \end{verbatim}
|
|
|
329 Search for the word "SEX" starting in the monitor.
|
|
|
330
|
|
|
331 \item[M] Move memory region.
|
|
|
332
|
|
|
333 \begin{description}
|
|
|
334 \item[Maddr1,addr2,len] Move region of memory from addr1 to addr2. If addr2 is
|
|
|
335 1 higher than addr1, a region is filled.
|
|
|
336 \end{description}
|
|
|
337
|
|
|
338 Example:
|
|
|
339 \begin{verbatim}
|
|
|
340 M400,500,80
|
|
|
341 \end{verbatim}
|
|
|
342 Move 128 bytes from address \$400 to \$500.
|
|
|
343
|
|
|
344 \item[A] Assemble instructions.
|
|
|
345
|
|
|
346 Syntax:
|
|
|
347 \begin{description}
|
|
|
348 \item[Aaddr] Enter line-by-line assembler.
|
|
|
349 \end{description}
|
|
|
350
|
|
|
351 You are in the assembler until you make an error or until you enter an empty
|
|
|
352 line.
|
|
|
353
|
|
|
354 Example:
|
|
|
355 \begin{verbatim}
|
|
|
356 A400
|
|
|
357 LDB #$4B
|
|
|
358 JSR $03
|
|
|
359 SWI
|
|
|
360 <empty line>
|
|
|
361 \end{verbatim}
|
|
|
362
|
|
|
363 \item[U] Disassemble instructions.
|
|
|
364
|
|
|
365 Syntax:
|
|
|
366 \begin{description}
|
|
|
367 \item[Uaddr,len] Disassemble memory region.
|
|
|
368 \item[Uaddr] (disassemble 21 bytes)
|
|
|
369 \item[U]
|
|
|
370 \end{description}
|
|
|
371
|
|
|
372 Examples:
|
|
|
373 \begin{verbatim}
|
|
|
374 UE400,20
|
|
|
375 \end{verbatim}
|
|
|
376 Diassemble first 32 bytes of monitor program.
|
|
|
377 \begin{verbatim}
|
|
|
378 U
|
|
|
379 \end{verbatim}
|
|
|
380 Disassemble next 21 bytes.
|
|
|
381
|
|
|
382 \item[B] Set, clear and show breakpoints.
|
|
|
383
|
|
|
384 Syntax:
|
|
|
385 \begin{description}
|
|
|
386 \item[Baddr] Set/reset breakpoint at address.
|
|
|
387 \item[B] Display active breakpoints.
|
|
|
388 \end{description}
|
|
|
389 Four breakpoints can be active simultaneously.
|
|
|
390
|
|
|
391 Examples:
|
|
|
392 \begin{verbatim}
|
|
|
393 B403
|
|
|
394 B408
|
|
|
395 \end{verbatim}
|
|
|
396 Set the breakpoints at the addresses \$403 and \$408.
|
|
|
397 \begin{verbatim}
|
|
|
398 B
|
|
|
399 \end{verbatim}
|
|
|
400 Show the breakpoints.
|
|
|
401 \begin{verbatim}
|
|
|
402 B403
|
|
|
403 \end{verbatim}
|
|
|
404 Remove the breakpoint at \$403.
|
|
|
405
|
|
|
406 \item[J] Call a subroutine.
|
|
|
407 \item[G] Go to specified address.
|
|
|
408
|
|
|
409 Syntax:
|
|
|
410 \begin{description}
|
|
|
411 \item[Jaddr] JSR to specified address.
|
|
|
412 \item[Gaddr] Go to specified address.
|
|
|
413 \item[G] Go to address in PC register.
|
|
|
414 \end{description}
|
|
|
415 The registers are loaded from where they are saved (on the stack) and at the
|
|
|
416 breakpoints SWI instructions are entered. Next the code is executed at the
|
|
|
417 indicated address. The SWI instruction (or RTS for the J command) returns to
|
|
|
418 the monitor, saving the registers.
|
|
|
419
|
|
|
420 \item[H] Calculate HEX expression.
|
|
|
421
|
|
|
422 Syntax:
|
|
|
423
|
|
|
424 \begin{description}
|
|
|
425 \item[Hhexnum\{(+|-)hexnum\}] Calculate simple expression in hex with + and -
|
|
|
426 \end{description}
|
|
|
427
|
|
|
428 Examples:
|
|
|
429 \begin{verbatim}
|
|
|
430 H4444+A5
|
|
|
431 H4444-44F3
|
|
|
432 \end{verbatim}
|
|
|
433
|
|
|
434 \item[P] Put a temporary breakpoint after current instruction and exeucte it,
|
|
|
435
|
|
|
436 P is similar to T, because it usually executes one instruction and returns
|
|
|
437 to the monitor after it. That does not work for jumps though. Normally you
|
|
|
438 use P only with JSR instructions if you want to execute the whole subroutine
|
|
|
439 without single-stepping through it.
|
|
|
440
|
|
|
441 \item[R] Display or modify registers.
|
|
|
442
|
|
|
443 Syntax:
|
|
|
444 \begin{description}
|
|
|
445 \item[R] Register display.
|
|
|
446 \item[Rregvalue] Enter new value into register Supported registers:
|
|
|
447 X,Y,U,S,A,B,D (direct page),P (program counter),C (condition code).
|
|
|
448 \end{description}
|
|
|
449 The R command uses the saved register values (on the stack). There are some
|
|
|
450 restrictions on changing the S register.
|
|
|
451
|
|
|
452 Examples:
|
|
|
453 \begin{verbatim}
|
|
|
454 R
|
|
|
455 \end{verbatim}
|
|
|
456 Display all registers.
|
|
|
457 \begin{verbatim}
|
|
|
458 RB03
|
|
|
459 RP4444
|
|
|
460 \end{verbatim}
|
|
|
461 Load the B register with \$03 and the program counter with \$4444.
|
|
|
462
|
|
|
463 \item[T] Single step trace.
|
|
|
464
|
|
|
465 \item[I] Show the contents of one address.
|
|
|
466
|
|
|
467 Syntax:
|
|
|
468 \begin{description}
|
|
|
469 \item[Iaddr] Display the contents of the given address. (used to read input
|
|
|
470 port)
|
|
|
471 \end{description}
|
|
|
472
|
|
|
473 Example:
|
|
|
474 \begin{verbatim}
|
|
|
475 IE001
|
|
|
476 \end{verbatim}
|
|
|
477 Show the ACIA status.
|
|
|
478 \end{description}
|
|
|
479
|
|
|
480 \subsection{S-Records Related Commands.}
|
|
|
481
|
|
|
482 \begin{description}
|
|
|
483 \item[S1bytes] Enter Motorola S records.
|
|
|
484 \item[S9bytes] Last S record in series.
|
|
|
485
|
|
|
486 S records are usually entered from a file, either ASCII transfer (S command
|
|
|
487 from the v09 prompt) or X-MODEM transfer (XX command in monitor, U command
|
|
|
488 from v09 prompt). Most Motorola cross assemblers generate S records.
|
|
|
489
|
|
|
490 \item[SSaddr,len] Dump memory region as Motorola S records.
|
|
|
491
|
|
|
492 These S records can be loaded later by the monitor program.
|
|
|
493
|
|
|
494 Usually you capture the S records into a file (use L command at v09 prompt)
|
|
|
495 or use XSS instead.
|
|
|
496 The XSS command is the same as SS, except that it outputs the S records
|
|
|
497 through the X-modem protocol (use D command at v09 prompt).
|
|
|
498
|
|
|
499 \item[SOaddr] Set origin address for S-record transfer.
|
|
|
500
|
|
|
501 Before entering S records, it sets the first memory address where S records
|
|
|
502 will be loaded, regardless of the address contained in the S records.
|
|
|
503
|
|
|
504 Before the SS command, it sets the first address that will go into the S
|
|
|
505 records.
|
|
|
506
|
|
|
507 Examples.
|
|
|
508 \begin{verbatim}
|
|
|
509 SO800
|
|
|
510 S1130400etc...
|
|
|
511 \end{verbatim}
|
|
|
512 Load the S records at address \$800 even though the address in the S records
|
|
|
513 is \$400
|
|
|
514 \begin{verbatim}
|
|
|
515 SO8000
|
|
|
516 SS400,100
|
|
|
517 \end{verbatim}
|
|
|
518 Save the memory region of 256 bytes starting at \$400 as S records. The S
|
|
|
519 records contain addresses starting at \$8000.
|
|
|
520 \end{description}
|
|
|
521
|
|
|
522 \subsection{X-Modem Related Commands.}
|
|
|
523
|
|
|
524 \begin{description}
|
|
|
525 \item[XLaddr] Load binary data using X-modem protocol
|
|
|
526
|
|
|
527 Example:
|
|
|
528 \begin{verbatim}
|
|
|
529 XL400
|
|
|
530 \end{verbatim}
|
|
|
531 Type your escape character and at the v09 prompt type
|
|
|
532 \begin{verbatim}
|
|
|
533 ubasic
|
|
|
534 \end{verbatim}
|
|
|
535 to load the binary file "basic" at address \$400.
|
|
|
536
|
|
|
537 \item[XSaddr,len] Save binary data using X-modem protocol.
|
|
|
538
|
|
|
539 Example:
|
|
|
540 \begin{verbatim}
|
|
|
541 XS400,100
|
|
|
542 \end{verbatim}
|
|
|
543 to save the memory region of 128 bytes starting at \$400
|
|
|
544 Type your escape character and at the v09 prompt type:
|
|
|
545 \begin{verbatim}
|
|
|
546 dfoo
|
|
|
547 \end{verbatim}
|
|
|
548 Now the bytes are saved into the file "foo".
|
|
|
549
|
|
|
550 \item[XSSaddr,len] Save memory region as S records through X-modem protocol.
|
|
|
551
|
|
|
552 See SS command for more details.
|
|
|
553
|
|
|
554 \item[XX] Execute commands received through X-modem protocol
|
|
|
555 This is usually used to receive S-records.
|
|
|
556
|
|
|
557 Example:
|
|
|
558 \begin{verbatim}
|
|
|
559 XX
|
|
|
560 \end{verbatim}
|
|
|
561 Now press the escape character and at the v09 prompt type
|
|
|
562 \begin{verbatim}
|
|
|
563 usfile
|
|
|
564 \end{verbatim}
|
|
|
565 where {\tt sfile} is a file with S-records.
|
|
|
566
|
|
|
567 \item[XOnl,eof] Set X-modem text output options, first number type of newline.
|
|
|
568 1=LF, 2=CR, 3=CRLF, second number filler byte at end of file
|
|
|
569 (sensible options include 0,4,1A) These options are used by
|
|
|
570 the XSS command.
|
|
|
571
|
|
|
572 Example: Under a UNIX system you want X-modem's text output with just LF
|
|
|
573 and a filler byte of 0. Type:
|
|
|
574 \begin{verbatim}
|
|
|
575 XO1,0
|
|
|
576 \end{verbatim}
|
|
|
577 \end{description}
|
|
|
578
|
|
|
579 \section{Memory Map}
|
|
|
580
|
|
|
581 \section{Operating System Facilities}
|
|
|
582
|
|
|
583 \begin{description}
|
|
|
584 \item[getchar] address \$00.
|
|
|
585 \item[putchar] address \$03.
|
|
|
586 \item[getline] address \$06.
|
|
|
587 \item[putline] address \$09.
|
|
|
588 \item[putcr] address \$0C.
|
|
|
589 \item[getpoll] address \$0F.
|
|
|
590 \item[xopenin] address \$12.
|
|
|
591 \item[xopenout] address \$15.
|
|
|
592 \item[xabortin] address \$18.
|
|
|
593 \item[xclosein] address \$1B.
|
|
|
594 \item[xcloseout] address \$1E.
|
|
|
595 \item[delay] address \$21. On input the D register contains the number of
|
|
|
596 timer ticks to wait. Each timer tick is 20ms.
|
|
|
597 \end{description}
|
|
|
598
|
|
|
599 \section{Extending the built-in Assembler}
|
|
|
600
|
|
|
601 \chapter{The Forth Language.}
|
|
|
602
|
|
|
603 \begin{verbatim}
|
|
|
604 kernel09 and the *.4 files. FORTH for the 6809. To run it, type
|
|
|
605 XX
|
|
|
606
|
|
|
607 Then press the escape char and at the v09 prompt type
|
|
|
608
|
|
|
609 ukernel09
|
|
|
610
|
|
|
611 Then type
|
|
|
612
|
|
|
613 G400
|
|
|
614
|
|
|
615 From FORTH type
|
|
|
616
|
|
|
617 XLOAD
|
|
|
618
|
|
|
619 Then press your escape char and at the v09 prompt type
|
|
|
620
|
|
|
621 uextend09.4
|
|
|
622
|
|
|
623 From FORTH type
|
|
|
624
|
|
|
625 XLOAD
|
|
|
626
|
|
|
627 Then press your escape char and at the v09 prompt type
|
|
|
628
|
|
|
629 utetris.4
|
|
|
630
|
|
|
631 From FORTH type
|
|
|
632
|
|
|
633 TT
|
|
|
634
|
|
|
635 And play tetris under FORTH on the 6809!
|
|
|
636 \end{verbatim}
|
|
|
637
|
|
|
638 \chapter{The BASIC Interpreter.}
|
|
|
639
|
|
|
640 \chapter{History of the Project.}
|
|
|
641
|
|
|
642 \section{Introduction.}
|
|
|
643
|
|
|
644 Of all the 8-bit home computers only a few had the Motorola 6809 CPU, the
|
|
|
645 most famous of which was the Tandy Color Computer. Then there was its clone
|
|
|
646 (from Wales) the Dragon and there was an old obscure SuperPet that I have
|
|
|
647 never seen. The 6809 was the 8-bit processor finally done right, but it came
|
|
|
648 a bit too late to have a real influence on the market.
|
|
|
649
|
|
|
650 The book that raised my enthousiasm for the Motorola 6809 processor was:
|
|
|
651 Lance A. Leventhal, ``6809 Assembly Language Programming", 1981
|
|
|
652 Osborne/McGrawhill. ISBN 0-07-931035-4. I borrowed it several times from the
|
|
|
653 university library and finally I bought my own copy.
|
|
|
654
|
|
|
655 The first sentence on the back of that book reads:
|
|
|
656 \begin{quote}
|
|
|
657 While everyone's been talking about new 16-bit microprocessors, the 6809 has
|
|
|
658 emerged as {\em the} important new device.
|
|
|
659 \end{quote}
|
|
|
660
|
|
|
661 Though it was not the processor that changed the world, it certainly was the
|
|
|
662 processor that changed my idea of what a good instruction set should look
|
|
|
663 like. Before that I thought that the Z80 was superior to everything else on
|
|
|
664 the planet, at least superior to every other 8-bit processor.
|
|
|
665
|
|
|
666 It was in April 1987. I borrowed the book for the first time and I had just
|
|
|
667 written a Forth interpreter for my Z80 machine. It struck me that the
|
|
|
668 following 7-instruction sequence on a Z80
|
|
|
669 \begin{verbatim}
|
|
|
670 EX DE,HL
|
|
|
671 LD E,(HL)
|
|
|
672 INC HL
|
|
|
673 LD D,(HL)
|
|
|
674 INC HL
|
|
|
675 EX DE,HL
|
|
|
676 JMP (HL)
|
|
|
677 \end{verbatim}
|
|
|
678
|
|
|
679 could be replaced by just {\em one} instruction on the 6809.
|
|
|
680 \begin{verbatim}
|
|
|
681 JMP [,Y++]
|
|
|
682 \end{verbatim}
|
|
|
683
|
|
|
684 BTW the above instructions are the heart of a Forth interpreter and making
|
|
|
685 them more efficient has a tremendous effect on efficiency.
|
|
|
686
|
|
|
687 \section{The 6809 Emulator in Forth.}
|
|
|
688
|
|
|
689 The years went by and I had bought an XT compatible computer in 1988. I
|
|
|
690 didn't buy a 6809 system though I could have done so. But it would either be
|
|
|
691 too expensive or I would have to build it myself (I wasn't too handy with
|
|
|
692 soldering) or it would be a primitive machine like the Tandy Color Computer
|
|
|
693 without expansions and I didn't like to use cassettes and a 32-column
|
|
|
694 display.
|
|
|
695
|
|
|
696 In 1989 I saw a 6502 simulator at a meeting of our Forth club. One could
|
|
|
697 interactively enter hex codes, page through memory, modify registers, trace
|
|
|
698 intructions etc. I just got to have this, but for a 6809 instead.
|
|
|
699
|
|
|
700 Around Christmas of that year I wrote a 6809 Forth assembler and an
|
|
|
701 interactive simulator, like the one I had seen on the club meeting.
|
|
|
702 Everything was written in F-PC, a very comprehensive Forth system for the
|
|
|
703 PC.
|
|
|
704
|
|
|
705 \begin{figure}
|
|
|
706 \begin{verbatim}
|
|
|
707 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF
|
|
|
708 0000 10 8E 00 40 E6 A0 D7 80 8E 00 81 3A 5D 27 07 A6 ...@f W ...:]'.&
|
|
|
709 0010 A0 A7 82 5A 26 F9 7E FF FF 00 00 00 00 00 00 00 '.Z&y~ .......
|
|
|
710 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
711 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
712 0040 05 46 4F 52 54 48 00 00 00 00 00 00 00 00 00 00 .FORTH..........
|
|
|
713 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
714 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
715 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
716 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
717 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
718 00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
719 00B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
720 00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
721 00D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
722 00E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
723 00F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
724 CC=00000000 A=$00 B=$00 DP=$00 X=$0000 Y=$0000 U=$0000 S=$0000
|
|
|
725 EFHINZVC PC=$0000 LDY # $0040
|
|
|
726 \end{verbatim}
|
|
|
727 \caption{Screen snapshot of the Forth-based 6809 simulator.}
|
|
|
728 \end{figure}
|
|
|
729
|
|
|
730 I even made a start with writing an implementation of Forth for it, but the
|
|
|
731 obvious lack of speed (among other things) witheld me from finishing it.
|
|
|
732 I had a fairly complete set of assembly routines though.
|
|
|
733 The estimated speed was around one thousand instructions per second, good
|
|
|
734 for an equivalent processor speed of around 4kHz.
|
|
|
735
|
|
|
736 In May 1992 I changed my trusted 8MHz Turbo XT for a blistering fast 25MHz
|
|
|
737 80386 and it could run the simulator more than 5 times as fast. But then I
|
|
|
738 wasn't really working on it. In the summer of 1992 I changed to Linux, which
|
|
|
739 I have been using ever since.
|
|
|
740
|
|
|
741 Around the summer of 1993 I was working with pfe, a brand new Forth system
|
|
|
742 for Unix written by Dirk Zoller. It had reached such state of completeness
|
|
|
743 and usability that porting the 6809 simulator to it would be feasible.
|
|
|
744 I ported it and by doing so I regained interest in the 6809 processor.
|
|
|
745 PFE is written in C instead of assembler and at least on the 80386 it is
|
|
|
746 considerably slower than a Forth written in Assembler, like FPC. My
|
|
|
747 simulated processor speed was around 5kHz, nothing to write home
|
|
|
748 about. It was faster than on the XT, but not much.
|
|
|
749
|
|
|
750 \section{The Assembler and Simulator in C.}
|
|
|
751
|
|
|
752 The switch from Forth to C was caused by the fact that I wanted a
|
|
|
753 traditional 6809 assembler, instead of the 'Forth' assembler, in which the
|
|
|
754 syntax is slightly tweaked to make the thing easy to implement in Forth and
|
|
|
755 easy to use within Forth. In the fall of 1993 I wrote a traditional two pass
|
|
|
756 assembler in a few days. It worked more or less, but only recently it has
|
|
|
757 become bug-free in that it assembles all the instructions and all the
|
|
|
758 addressing modes (even PC relative) without error.
|
|
|
759
|
|
|
760 Now that I had a real assembler, I could write real 6809 assembly programs,
|
|
|
761 such as a BASIC interpreter (maybe kidding) or a monitor program or god
|
|
|
762 knows what. If I would ever run real code on that 6809 simulator, I had to
|
|
|
763 increase its speed considerably. So I wrote a very straightforward
|
|
|
764 6809 simulator in C using tables of function pointers. It did really well in
|
|
|
765 terms of speed, I could reach an equivalent processor clock speed of around
|
|
|
766 200kHz. The C simulator didn't have any fancy display, memory edit or single
|
|
|
767 step functions. Its only I/O was through the SWI2 instruction for character
|
|
|
768 output and SWI3 for character input, something I had added to the
|
|
|
769 Forth-based simulator quite some time ago.
|
|
|
770
|
|
|
771 One afternoon in optimized hack mode brought me a crude port of E-Forth, a
|
|
|
772 tiny and very slow (most was interpreted, very few assembler words)
|
|
|
773 implementation of Forth. The original was written in MASM for the 8086 and
|
|
|
774 other ports (like the 8051) wre already around. That was the first time I
|
|
|
775 had Forth on an emulated 6809. BTW this Forth would also run, or should I
|
|
|
776 say crawl, on the Forth-based simulator.
|
|
|
777
|
|
|
778 I released the assembler, simulator and EForth on {\tt alt.sources} in November
|
|
|
779 1993.
|
|
|
780
|
|
|
781 Of course I also wrote some test and toy programs (what about a program to
|
|
|
782 convert binary numbers to decimal using that oddball DAA instruction?).
|
|
|
783
|
|
|
784 In the spring of 1994 I picked up that old TINY BASIC interpreter written by
|
|
|
785 John Byrns. And tiny it was. Not even arrays were supported. I ported it to
|
|
|
786 my simulator and found some bugs, both in my simulator and in TINY BASIC
|
|
|
787 itself.
|
|
|
788
|
|
|
789 I made some improvements to the 6809 simulator. Now I could send ASCII files
|
|
|
790 to it and log the output to another ASCII file. That way I could 'load' and
|
|
|
791 'save' BASIC programs for one thing. Further I had a trace facility to write
|
|
|
792 a trace of all the instructions in a certain address range to a file. Last I
|
|
|
793 cleaned up the I/O and signal handling somewhat, making it portable across
|
|
|
794 several Unix versions.
|
|
|
795
|
|
|
796 That version of the software, along with some example programs, was also
|
|
|
797 released on {\tt alt.sources}. The assembler implemented includes and conditional
|
|
|
798 assembly in that version.
|
|
|
799
|
|
|
800 \section{The Virtual SBC.}
|
|
|
801
|
|
|
802 That blistering fast 80386 that I bought back in 1992 has become slow as
|
|
|
803 molasses. It has actually become slower since the memory upgrade with
|
|
|
804 slow memory (it was cheap) that necessitated an extra wait state.
|
|
|
805 Fortunately I recently pruchased a Pentium.
|
|
|
806
|
|
|
807 At the moment I actually have plans to build (or have somebody build for me)
|
|
|
808 a single board computer containing a 6809. I would like to have 32k RAM plus
|
|
|
809 32k EPROM. I definitely like to have a monitor program with the features I
|
|
|
810 want. Hence another project was born, the virtual SBC that I could prototype
|
|
|
811 my monitor ROM and some other software on.
|
|
|
812
|
|
|
813 The virtual SBC emulates a single board computer that communicates with a PC
|
|
|
814 through an ACIA. On that PC there runs a simple terminal program that
|
|
|
815 supports XMODEM file transfer. Things I recently did.
|
|
|
816
|
|
|
817 \begin{itemize}
|
|
|
818 \item I rewrote the 6809 emulator engine with giant switch statements to hammer
|
|
|
819 out all unnecessary procedure calls and to gain some speed by enabling the
|
|
|
820 compiler to use register variables where appropriate. On my 386 the
|
|
|
821 speed increase was disappointing. The equivalent processor speed is now
|
|
|
822 250kHz, up from about 170kHz (remember that extra wait state?). On a HPUX
|
|
|
823 workstation, I got a factor of 2 speed increase. That sucker runs at an
|
|
|
824 emulated processor speed of about 3.5MHz. A Pentium-90 is even faster,
|
|
|
825 more than any real 6809 can (officially) run.
|
|
|
826 \item I added XMODEM upload/download features to the 'terminal front end' of the
|
|
|
827 simulator. On the other end of the 'serial link' a 6809 machine code
|
|
|
828 program runs the other end of the XMODEM file transfer protocol.
|
|
|
829 \item I changed the SWI2/SWI3 hack to real ACIA emulation at a port address.
|
|
|
830 \item I write-protected the ROM area.
|
|
|
831 \item I added a 20ms timer interrupt.
|
|
|
832 \item I wrote a monitor program for the virtual SBC that has to followin
|
|
|
833 features.
|
|
|
834 \begin{itemize}
|
|
|
835 \item Simple (vectorized) operating system functions, like character I/O
|
|
|
836 line I/O, XMODEM transfer. Usable by application programs.
|
|
|
837 \item a hex/ascii dump command.
|
|
|
838 \item a hex/ascii enter command.
|
|
|
839 \item a hex/ascii memory search command.
|
|
|
840 \item memory move command.
|
|
|
841 \item S-record send and receive capabilities (directly in ASCII or
|
|
|
842 through XMODEM).
|
|
|
843 \item Binary load and save of memory region through XMODEM
|
|
|
844 \item register display and modify.
|
|
|
845 \item go to address (or current program counter) and call subroutine commands.
|
|
|
846 \item breakpoints.
|
|
|
847 \item program step tracing (breakpoint after next instruction), DEBUG P
|
|
|
848 command
|
|
|
849 \item single step tracing (based on timer interrupt). I had to cheat with the
|
|
|
850 emulator to implement this.
|
|
|
851 \item one-pass (no labels) disassembler (DEBUG U command).
|
|
|
852 \item line-by-line assembler (DEBUG A command) I wrote
|
|
|
853 this one such that an additional real assembler can use most of the guts of
|
|
|
854 it.
|
|
|
855 \end{itemize}
|
|
|
856 \end{itemize}
|
|
|
857
|
|
|
858 Finally I wrote a real 6809 Forth, based on some other Forth I wrote for an
|
|
|
859 imaginary stack machine. Those old dusty primitives that I had written back in
|
|
|
860 1990 proved very useful now. This Forth can load programs through XMODEM
|
|
|
861 too. It can recompile (metacompile) itself and, very importantly, it runs
|
|
|
862 tetris! (crawls on the 386) This is the tetris implementation written in
|
|
|
863 ANSI Forth by Dirk Zoller and it is used as a test program.
|
|
|
864 Next I have to make this Forth ROM-able.
|
|
|
865
|
|
|
866 What else will go into that 32k ROM area? The monitor will be around 7k, 1k
|
|
|
867 is reserved for the I/O space. Forth (with its own Forth assembler) will
|
|
|
868 take about 12k, 8k without. A few additional k could be used for a 'real'
|
|
|
869 assemler, but I doubt I will ever use that. A cross assembler is much more
|
|
|
870 convenient. BASIC no doubt. But I'm afraid I'll have to write it myself,
|
|
|
871 more so as I want to have {\em source code} of all my 6809 stuff. I already have
|
|
|
872 the floating point routines for it.
|
|
|
873
|
|
|
874 \end{document}
|
