Mercurial > hg > Members > kono > os9 > sbc09
comparison doc/origin/sbc09.tex @ 57:2088fd998865
sbc09 directry clean up
| author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Mon, 23 Jul 2018 16:07:12 +0900 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| 56:4fa2bdb0c457 | 57:2088fd998865 |
|---|---|
| 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} |