Members/kono/os9/sbc09: doc/sbc09.creole comparison

comparison doc/sbc09.creole @ 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

-:4fa2bdb0c457
+:2088fd998865
+= SBC09, an Emulator for a 6809-Based Single Board Compuer. =
+author: **L.C. Benschop**
+This file is the content of **sbc09.tex** converted 2013 by Jens Diemer into
+this creole markup.
+Revisions:
+2014-06-26 Jens Diemer
+Merge some text parts from the origin README textfile
+== Introduction ==
+The {{{sbc09}}} package contains an emulator of a 6809-based single board
+computer that runs under UNIX. It contains all the programs needed to work
+with the emulator, such as the emulator itself, an assembler, a monitor
+program, a BASIC interpreter, a Forth interpreter, several example programs
+and several tools needed to build the programs. The program should work
+under most more-or-less POSIX-compliant versions of UNIX and they were
+developed under Linux. Of course I believe that the programs that currently
+run on the emulator would also run on a real 6809 machine.
+=== A Bit of Background on SBCs. ===
+In the seventies you could buy single board microcomputers that had a
+hexadecimal keypad and 7-segment displays. These computers typically had
+less than 1 kilobyte of RAM and a simple monitor program in ROM. An
+interface to a cassette recorder (or paper tape reader/writer) and a
+terminal was possible, but not standard. The typical way to program the
+machine was entering hexadecimal machine codes on the keypad. Machine code
+was the only language in which you could program them, especially if you
+only had a hexadecimal keypad and 7-segment led displays. You typically used
+these machines to experiment with hardware interfacing, as games and
+calculations were a bit limited with only six 7-segment digits.
+Next came simple home computers, like the TRS80, the Apple ][ and the
+Commodore PET. These machines had BASIC in ROM and they used a simple
+cassette recorder to store data. These computers had a TV or a low quality
+monitor as display and a QWERTY keyboard. These machines could be upgraded
+with a floppy disk drive and a printer and then they could be used for
+professional work. These machines had 4 to 64 kilobytes of memory.
+Apart from assembly language you could use BASIC, Forth
+and sometimes Pascal to program these machines. Most useful programs (and
+the best games) were programmed in assembly language. Many of these machines
+had BASIC in ROM and no machine code monitor. You had to load that
+separately.
+Today we have personal computers that run DOS, Windows, UNIX or something
+else. New computers have 4 to 16 megabytes of RAM and hard disks of more
+than 500 Megabytes. Apart from having in the order of 1000 times more
+storage, they are also 1000 times faster than the old 8-bit home computers.
+Programming? You can use Visual BASIC, C++ and about
+every other programming language on the planet. But programs have become
+bigger and bigger. Programming is not the same as it was before.
+I guess there is some demand for small 8-bit computer systems that are simple
+to build, easy to interface to all kinds of hobby projects, fun to program
+and small enough to integrate into a home-built project.
+Do we want to use hexadecimal keyboards and 7-segment displays? I guess not
+many people want to use them. Do we want to use a cassette recorder for data
+storage and a TV as a display? Not me. And if you build your own 8-bit
+microprocessor, do you want to waste your time and money on a hexadecimal
+keypad or a cassette interface that you do not like to use and that you do
+not need anyway? PCs of five years ago are more than adequate to run an
+editor, a terminal program and a cross assembler for your favourite 8-bit
+processor. The terminal program can then be used to send the programs to the
+8-bit micro.
+If you equip an 8-bit system with some static CMOS RAM, a serial
+interface and a monitor in ROM, you can use the keyboard, hard disk and
+monitor of your PC for program development and the 8-bit micro can be
+disconnected from the PC and do its task, once it is programmed.
+Cross development is nothing special. How do you think the microprocessor in
+you microwave was programmed? But it is not practical for a hobbyist to
+program an EPROM for each program change. Professional developers of
+embedded processors have expensive tools, like ROM emulators, processor
+emulators etc. to see what the processor is doing on its way to the next
+crash. For a hobbyist it is much more practical to have a slightly more
+expensive embedded computer that you can run an interactive debugger on.
+And you are not even limited to assembly language. If you have 32k ROM you
+can have both the monitor program and a BASIC interpreter and some
+application code in ROM. Nothing prevents you from having Forth as well.
+=== The Emulated System. ===
+{{{
+RESET
+|        /---- 32K ROM
+|        |
+v        |
+6809 CPU --|---- 32K RAM
+^        |
+| FIRQ   |
+|        \---- 6850 ACIA <--- RS232
+TIMER
+}}}
+Block Diagram of SBC.
+The program {{{sbc09}}} emulates the above mentioned single board computer
+{{{plus}}} the terminal program that communicates with it.
+== Building the Programs. ==
+== The 6809 Assembler a09. ==
+The assembler is a09. Run it with
+{{{
+a09 [-l listing] [-o object|-s object] source
+}}}
+Source is a mandatory argument. The -l listing and {{{-o}}} or {{{-s}}}
+object arguments are
+optional. By default there is no listing and the object file is the
+sourcefile name without an extension and if the source file name has no
+extension it is the source file name with {{{.b}}} extension.
+A09 recognises standard 6809 mnemonics. Labels should start in the first
+column and may or may not be terminated by a colon. Every line starting with
+a non-alphanumeric is taken to be a comment line. Everything after the
+operand field is taken to be comment. There is a full expression evaluator
+with C-style operators (and Motorola style number bases).
+There are the usual pseudo-ops such as ORG EQU SET SETDP RMB FCB FDB FCC etc.
+Strings within double quotes may be mixed with numbers on FCB lines. There
+is conditional assembly with IF/ELSE/ENDIF and there is INCLUDE. The
+assembler is case-insensitive.
+The object file is either a binary image file (-o) or Motorola S-records (-s).
+In the former case it contains a binary image of the assembled data starting
+at the first address where something is assembled. In the following case
+{{{
+ORG 0
+VAR1	RMB 2
+VAR2	RMB 2
+ORG $100
+START	LDS #$400
+...
+}}}
+the RMB statements generate no data so the object file contains the memory
+image from address $100.
+The list file contains no pretty lay-out and no pagination. It is assumed
+that utilities (Unix pr or enscript) are available for that.
+There are no macros and no linkable modules yet. Some provisions are taken
+for it in the code.
+After the assembler has finished, it prints the number of pass 2 errors.
+This should be zero. So if you see
+{{{
+0 Pass 2 Errors.
+}}}
+then you are lucky.
+== The Virtual SBC v09. ==
+The simulator is v09. Run it with
+{{{
+v09 [-t tracefile [-tl tracelo] [-th tracehi]] [-e escchar]
+}}}
+{{{tracelo}}} and {{{tracehi}}} are addresses. They can be entered in
+decimal, octal or hex using the C conventions for number input.
+If a tracefile is specified, all instructions at addresses between
+{{{tracelo}}} and {{{tracehi}}} are traced. Tracing information such as program
+location, register contents and opcodes are written to the trace file.
+{{{escchar}}} is the escape character. It must be entered as a number. This is
+the character that you must type to get the v09 prompt. This is control-]
+by default. (0x1d)
+The program loads its ROM image from the file {{{v09.rom}}}, which is a 32
+kilobyte binary file. This file should have been generated by the {{{Makefile}}}.
+The program starts executing at the address found at $FFFE in
+the ROM, just like a real 6809 would do on reset.
+The address map is as follows:
+| **$0000--$7FFF** | RAM.
+| **$8000--$FFFF** | ROM (except the I/O addresses). These addresses are write-protected.
+| **$E000--$E0FF** | I/O addresses. Currently only one ACIA is mapped.
+At addresses $E000 and $E001 there is an emulated serial port (ACIA). All
+bytes sent to it (or read from it) are send to (read from) the terminal and
+sometimes to/from a file.
+Terminal I/O is in raw mode.
+If you press the escape char, you get the v09 prompt. At the prompt you
+can enter the following things:
+**X**
+to exit the simulator.
+**R**
+to reset the emulated 6809 (very useful).
+**L**//filename//
+(no space in between) to log terminal output to a file.
+Control chars and cr are filtered to make the output a normal
+text file. L without a file name stops logging.
+**S**//filename//
+to send a specified file to the simulator through its terminal
+input. LF is converted to CR to mimic raw terminal input.
+**U**//filename//
+(terminal upload command) to send a file to the 6809 using the
+X-modem protocol. The 6809 must already run an X-modem receiving
+program.
+**D**//filename//
+(terminal download command) to receive a file from the 6809 using
+the X-modem protocol. The 6809 must already run an X-modem
+sending program.
+All of these commands, except the R command, can be seen as commands of the
+communication program that is used to access the single board computer.
+The R command is a subsitute for pushing the RESET button on the emulated
+computer.
+== Machine Language Monitor. ==
+The program {{{monitor.asm}}} is a program that is intended to be included
+in the ROM of a 6809 based single board computer. The program allows a user
+to communicate with the single board computer through a serial port. It
+allows a user to enter machine code, examine memory and registers, to set
+breakpoints, to trace a program and more. Furthermore, data can be sent to
+and be received from the single board computer through the X-MODEM protocol.
+==== Getting Started. ====
+If you start v09 with the standard ROM, then you will run the monitor
+program.
+If all goes well you see something like
+{{{
+Welcome to BUGGY 1.0
+}}}
+and you can type text. Excellent, you are now running 6809 code.
+The following example programs you can run from the 6809 monitor.
+All of them start at address $400. For example to run the program bin2dec
+you type.
+{{{
+XL400
+}}}
+Then press your escape character (default is control-] ).
+Then at the v09 prompt type
+{{{
+ubin2dec
+}}}
+Now you see some lines displaying the progress of the X-modem session.
+If that is finished, you type
+{{{
+G400
+}}}
+Now it runs and exits to the monitor with SWI, so that the registers are
+displayed.
+** cond09.asm **
+** cond09.inc **
+Nonsense program to show conditional assembly and the like.
+** bench09.asm **
+Benchmark program. Executes tight loop. Takes 83 secs on
+25 MHz 386. Should take about 8 sec. on 1MHz real 6809. :-(
+** test09.asm **
+Tests  some nasty features of the 6809. Prints a few lines
+of PASSED nn and should never print ERROR nn.
+** bin2dec.asm **
+Unusual way to convert numbers to decimal using DAA instruction.
+Prints some test numbers.
+** basic.asm **
+Tiny BASIC by John Byrns. Docs are in basic.doc.
+To test it start the monitor and run basic.
+Then press your escape char.
+At the v09 prompt type: sexampl.bas
+Now a BASIC program is input.
+Type RUN to run it.
+Leave BASIC by pressing the escape char and entering x at the
+prompt.
+=== Use of the monitor commands ===
+==== Single Letter Commands ====
+===== D - Dump memory =====
+Syntax:
+** Daddr,len ** Hex/ascii dump of memory region.
+** Daddr ** length=64 bytes by default.
+** D ** address is address after previous dump by default.
+Examples:
+{{{
+DE400,100
+}}}
+Dump 256 bytes starting at $E400
+{{{
+D
+}}}
+Dump the next 64 bytes.
+===== E - Enter data into memory =====
+** Eaddr bytes **
+Enter hexadecimal bytes at address.
+** Eaddr"ascii" **
+Enter ascii at address.
+** Eaddr **
+Enter interactively at address (until empty line).
+Examples:
+{{{
+E0400 86449D033F
+}}}
+Enter the bytes 86 44 9D 03 3F at address $400.
+{{{
+E5000"Welcome"
+}}}
+Enter the ASCII codes of "Welcome" at address $400.
+===== F - Find string in memory =====
+Syntax:
+** Faddr bytes **
+Find byte string string from address.
+** Faddr"ascii" **
+Find ASCII string.
+Find the specified string in memory, starting at the specified address. The
+I/O addresses $E000-$E0FF are skipped. The addresses of the first 16
+occurrences are shown.
+Example:
+{{{
+FE400"SEX"
+}}}
+Search for the word "SEX" starting in the monitor.
+===== M - Move memory region =====
+** Maddr1,addr2,len **
+Move region of memory from addr1 to addr2. If addr2 is
+1 higher than addr1, a region is filled.
+Example:
+{{{
+M400,500,80
+}}}
+Move 128 bytes from address $400 to $500.
+===== A - Assemble instructions =====
+Syntax:
+** Aaddr **
+Enter line-by-line assembler.
+You are in the assembler until you make an error or until you enter an empty
+line.
+Example:
+{{{
+A400
+LDB #$4B
+JSR $03
+SWI
+<empty line>
+}}}
+===== U - Disassemble instructions =====
+Syntax:
+** Uaddr,len **
+Disassemble memory region.
+** Uaddr **
+(disassemble 21 bytes)
+** U **
+Examples:
+{{{
+UE400,20
+}}}
+Diassemble first 32 bytes of monitor program.
+{{{
+U
+}}}
+Disassemble next 21 bytes.
+===== B - Set, clear and show breakpoints =====
+Syntax:
+** Baddr **
+Set/reset breakpoint at address.
+** B **
+Display active breakpoints.
+Four breakpoints can be active simultaneously.
+Examples:
+{{{
+B403
+B408
+}}}
+Set the breakpoints at the addresses $403 and $408.
+{{{
+B
+}}}
+Show the breakpoints.
+{{{
+B403
+}}}
+Remove the breakpoint at $403.
+===== J - Call a subroutine / G - Go to specified address =====
+Syntax:
+** Jaddr **
+JSR to specified address.
+** Gaddr **
+Go to specified address.
+** G **
+Go to address in PC register.
+The registers are loaded from where they are saved (on the stack) and at the
+breakpoints SWI instructions are entered. Next the code is executed at the
+indicated address. The SWI instruction (or RTS for the J command) returns to
+the monitor, saving the registers.
+===== H - Calculate HEX expression =====
+Syntax:
+** Hhexnum{(+|-)hexnum} **
+Calculate simple expression in hex with + and -
+Examples:
+{{{
+H4444+A5
+H4444-44F3
+}}}
+===== P - Put a temporary breakpoint after current instruction and execute it,
+P is similar to T, because it usually executes one instruction and returns
+to the monitor after it. That does not work for jumps though. Normally you
+use P only with JSR instructions if you want to execute the whole subroutine
+without single-stepping through it.
+===== R - Display or modify registers =====
+Syntax:
+** R **
+Register display.
+** Rregvalue **
+Enter new value into register Supported registers:
+X,Y,U,S,A,B,D (direct page),P (program counter),C (condition code).
+The R command uses the saved register values (on the stack). There are some
+restrictions on changing the S register.
+Examples:
+{{{
+R
+}}}
+Display all registers.
+{{{
+RB03
+RP4444
+}}}
+Load the B register with $03 and the program counter with $4444.
+===== T - Single step trace =====
+===== I - Show the contents of one address =====
+Syntax:
+** Iaddr **
+Display the contents of the given address. (used to read input
+port)
+Example:
+{{{
+IE001
+}}}
+Show the ACIA status.
+==== S-Records Related Commands. ====
+** S1bytes **
+Enter Motorola S records.
+** S9bytes **
+Last S record in series.
+S records are usually entered from a file, either ASCII transfer (S command
+from the v09 prompt) or X-MODEM transfer (XX command in monitor, U command
+from v09 prompt). Most Motorola cross assemblers generate S records.
+** SSaddr,len **
+Dump memory region as Motorola S records.
+These S records can be loaded later by the monitor program.
+Usually you capture the S records into a file (use L command at v09 prompt)
+or use XSS instead.
+The XSS command is the same as SS, except that it outputs the S records
+through the X-modem protocol (use D command at v09 prompt).
+** SOaddr **
+Set origin address for S-record transfer.
+Before entering S records, it sets the first memory address where S records
+will be loaded, regardless of the address contained in the S records.
+Before the SS command, it sets the first address that will go into the S
+records.
+Examples.
+{{{
+SO800
+S1130400etc...
+}}}
+Load the S records at address $800 even though the address in the S records
+is $400
+{{{
+SO8000
+SS400,100
+}}}
+Save the memory region of 256 bytes starting at $400 as S records. The S
+records contain addresses starting at $8000.
+==== X-Modem Related Commands. ====
+** XLaddr **
+Load binary data using X-modem protocol
+Example:
+{{{
+XL400
+}}}
+Type your escape character and at the v09 prompt type
+{{{
+ubasic
+}}}
+to load the binary file "basic" at address $400.
+** XSaddr,len **
+Save binary data using X-modem protocol.
+Example:
+{{{
+XS400,100
+}}}
+to save the memory region of 128 bytes starting at $400
+Type your escape character and at the v09 prompt type:
+{{{
+dfoo
+}}}
+Now the bytes are saved into the file "foo".
+** XSSaddr,len **
+Save memory region as S records through X-modem protocol.
+See SS command for more details.
+** XX **
+Execute commands received through X-modem protocol
+This is usually used to receive S-records.
+Example:
+{{{
+XX
+}}}
+Now press the escape character and at the v09 prompt type
+{{{
+usfile
+}}}
+where {{{sfile}}} is a file with S-records.
+** XOnl,eof **
+Set X-modem text output options, first number type of newline.
+1=LF, 2=CR, 3=CRLF, second number filler byte at end of file
+(sensible options include 0,4,1A) These options are used by
+the XSS command.
+Example: Under a UNIX system you want X-modem's text output with just LF
+and a filler byte of 0. Type:
+{{{
+XO1,0
+}}}
+=== Memory Map ===
+Apart from the monitor commands, the monitor program contains I/O routines
+that can be used by applications started from it.
+=== Operating System Facilities ===
+| **getchar** | address **$00** Input one character into B register.
+| **putchar** | address **$03** Output one character in B register.
+| **getline** | address **$06** Input line at address in X, length in B.
+| **putline** | address **$09** Output string at address in X, length in B.
+| **putcr**   | address **$0C** Output a newline.
+| **getpoll** | address **$0F**
+| **xopenin** | address **$12**
+| **xopenout** | address **$15**
+| **xabortin** | address **$18**
+| **xclosein** | address **$1B**
+| **xcloseout** | address **$1E**
+| **delay**     | address **$21** On input the D register contains the number of timer ticks to wait. Each timer tick is 20ms
+There are other routines that redirect these I/O operations through the
+X-modem protocol.
+=== Extending the built-in Assembler ===
+EXAMPLE PROGRAMS
+The following example programs you can run from the 6809 monitor.
+All of them start at address $400. For example to run the program bin2dec
+you type.
+XL400
+Then press your escape character (default is control-] ).
+Then at the v09 prompt type
+ubin2dec
+Now you see some lines displaying the progress of the X-modem session.
+If that is finished, you type
+G400
+Now it runs and exits to the monitor with SWI, so that the registers are
+displayed.
+cond09.asm
+cond09.inc  Nonsense program to show conditional assembly and the like.
+bench09.asm Benchmark program. Executes tight loop. Takes 83 secs on
+25 MHz 386. Should take about 8 sec. on 1MHz real 6809. :-(
+test09.asm  Tests some nasty features of the 6809. Prints a few lines
+of PASSED nn and should never print ERROR nn.
+bin2dec.asm Unusual way to convert numbers to decimal using DAA instruction.
+Prints some test numbers.
+mon2.asm is an alternative version of the monitor program.
+alt09.rom is a version of the ROM that contains the alternative monitor and
+Forth. Forth is transferrred to RAM by a small loader.
+To start Forth type G8000. To start it again, type G400.
+== The Forth Language. ==
+kernel09 and the *.4 files. FORTH for the 6809. To run it, type
+**XX**
+Then press the escape char (default is control-] ) and at the v09 prompt type:
+**ukernel09**
+Then type
+**G400**
+From FORTH type
+**XLOAD**
+Then press your escape char and at the v09 prompt type
+**uextend09.4**
+From FORTH type
+**XLOAD**
+Then press your escape char and at the v09 prompt type
+**utetris.4**
+From FORTH type
+**TT**
+And play tetris under FORTH on the 6809!
+== The BASIC Interpreter. ==
+basic.asm Tiny BASIC by John Byrns. Docs are in basic.doc.
+To test it start the monitor and run basic.
+Then press your escape char.
+At the v09 prompt type: sexampl.bas
+Now a BASIC program is input.
+Type RUN to run it.
+Leave BASIC by pressing the escape char and entering x at the
+prompt.
+== History of the Project. ==
+=== Introduction. ===
+Of all the 8-bit home computers only a few had the Motorola 6809 CPU, the
+most famous of which was the Tandy Color Computer. Then there was its clone
+(from Wales) the Dragon and there was an old obscure SuperPet that I have
+never seen. The 6809 was the 8-bit processor finally done right, but it came
+a bit too late to have a real influence on the market.
+The book that raised my enthousiasm for the Motorola 6809 processor was:
+Lance A. Leventhal, //6809 Assembly Language Programming//, 1981
+Osborne/McGrawhill. ISBN 0-07-931035-4. I borrowed it several times from the
+university library and finally I bought my own copy.
+The first sentence on the back of that book reads:
+While everyone's been talking about new 16-bit microprocessors, the 6809 has
+emerged as {{{the}}} important new device.
+Though it was not the processor that changed the world, it certainly was the
+processor that changed my idea of what a good instruction set should look
+like. Before that I thought that the Z80 was superior to everything else on
+the planet, at least superior to every other 8-bit processor.
+It was in April 1987. I borrowed the book for the first time and I had just
+written a Forth interpreter for my Z80 machine. It struck me that the
+following 7-instruction sequence on a Z80
+{{{
+EX DE,HL
+LD E,(HL)
+INC HL
+LD D,(HL)
+INC HL
+EX DE,HL
+JMP (HL)
+}}}
+could be replaced by just {{{one}}} instruction on the 6809.
+{{{
+JMP [,Y++]
+}}}
+BTW the above instructions are the heart of a Forth interpreter and making
+them more efficient has a tremendous effect on efficiency.
+=== The 6809 Emulator in Forth. ===
+The years went by and I had bought an XT compatible computer in 1988. I
+didn't buy a 6809 system though I could have done so. But it would either be
+too expensive or I would have to build it myself (I wasn't too handy with
+soldering) or it would be a primitive machine like the Tandy Color Computer
+without expansions and I didn't like to use cassettes and a 32-column
+display.
+In 1989 I saw a 6502 simulator at a meeting of our Forth club. One could
+interactively enter hex codes, page through memory, modify registers, trace
+intructions etc. I just got to have this, but for a 6809 instead.
+Around Christmas of that year I wrote a 6809 Forth assembler and an
+interactive simulator, like the one I had seen on the club meeting.
+Everything was written in F-PC, a very comprehensive Forth system for the
+PC.
+{{{
+0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F 0123456789ABCDEF
+0000  10 8E 00 40 E6 A0 D7 80 8E 00 81 3A 5D 27 07 A6 ...@f W ...:]'.&
+0010  A0 A7 82 5A 26 F9 7E FF FF 00 00 00 00 00 00 00  '.Z&y~  .......
+0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+0040  05 46 4F 52 54 48 00 00 00 00 00 00 00 00 00 00 .FORTH..........
+0050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+0080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+0090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+00F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+CC=00000000  A=$00 B=$00 DP=$00 X=$0000 Y=$0000 U=$0000 S=$0000
+EFHINZVC PC=$0000 LDY # $0040
+}}}
+Screen snapshot of the Forth-based 6809 simulator
+I even made a start with writing an implementation of Forth for it, but the
+obvious lack of speed (among other things) witheld me from finishing it.
+I had a fairly complete set of assembly routines though.
+The estimated speed was around one thousand instructions per second, good
+for an equivalent processor speed of around 4kHz.
+In May 1992 I changed my trusted 8MHz Turbo XT for a blistering fast 25MHz
+80386 and it could run the simulator more than 5 times as fast. But then I
+wasn't really working on it. In the summer of 1992 I changed to Linux, which
+I have been using ever since.
+Around the summer of 1993 I was working with pfe, a brand new Forth system
+for Unix written by Dirk Zoller. It had reached such state of completeness
+and usability that porting the 6809 simulator to it would be feasible.
+I ported it and by doing so I regained interest in the 6809 processor.
+PFE is written in C instead of assembler and at least on the 80386 it is
+considerably slower than a Forth written in Assembler, like FPC. My
+simulated processor speed was around 5kHz, nothing to write home
+about. It was faster than on the XT, but not much.
+=== The Assembler and Simulator in C. ===
+The switch from Forth to C was caused by the fact that I wanted a
+traditional 6809 assembler, instead of the 'Forth' assembler, in which the
+syntax is slightly tweaked to make the thing easy to implement in Forth and
+easy to use within Forth. In the fall of 1993 I wrote a traditional two pass
+assembler in a few days. It worked more or less, but only recently it has
+become bug-free in that it assembles all the instructions and all the
+addressing modes (even PC relative) without error.
+Now that I had a real assembler, I could write real 6809 assembly programs,
+such as a BASIC interpreter (maybe kidding) or a monitor program or god
+knows what. If I would ever run real code on that 6809 simulator, I had to
+increase its speed considerably. So I wrote a very straightforward
+6809 simulator in C using tables of function pointers. It did really well in
+terms of speed, I could reach an equivalent processor clock speed of around
+200kHz. The C simulator didn't have any fancy display, memory edit or single
+step functions. Its only I/O was through the SWI2 instruction for character
+output and SWI3 for character input, something I had added to the
+Forth-based simulator quite some time ago.
+One afternoon in optimized hack mode brought me a crude port of E-Forth, a
+tiny and very slow (most was interpreted, very few assembler words)
+implementation of Forth. The original was written in MASM for the 8086  and
+other ports (like the 8051) wre already around. That was the first time I
+had Forth on an emulated 6809. BTW this Forth would also run, or should I
+say crawl, on the Forth-based simulator.
+I released the assembler, simulator and EForth on {{{alt.sources}}} in November
+1993.
+Of course I also wrote some test and toy programs (what about a program to
+convert binary numbers to decimal using that oddball DAA instruction?).
+In the spring of 1994 I picked up that old TINY BASIC interpreter written by
+John Byrns. And tiny it was. Not even arrays were supported. I ported it to
+my simulator and found some bugs, both in my simulator and in TINY BASIC
+itself.
+I made some improvements to the 6809 simulator. Now I could send ASCII files
+to it and log the output to another ASCII file. That way I could 'load' and
+'save' BASIC programs for one thing. Further I had a trace facility to write
+a trace of all the instructions in a certain address range to a file. Last I
+cleaned up the I/O and signal handling somewhat, making it portable across
+several Unix versions.
+That version of the software, along with some example programs, was also
+released on {{{alt.sources}}}. The assembler implemented includes and conditional
+assembly in that version.
+=== The Virtual SBC. ===
+That blistering fast 80386 that I bought back in 1992 has become slow as
+molasses. It has actually become slower since the memory upgrade with
+slow memory (it was cheap) that necessitated an extra wait state.
+Fortunately I recently pruchased a Pentium.
+At the moment I actually have plans to build (or have somebody build for me)
+a single board computer containing a 6809. I would like to have 32k RAM plus
+32k EPROM. I definitely like to have a monitor program with the features I
+want. Hence another project was born, the virtual SBC that I could prototype
+my monitor ROM and some other software on.
+The virtual SBC emulates a single board computer that communicates with a PC
+through an ACIA. On that PC there runs a simple terminal program that
+supports XMODEM file transfer. Things I recently did.
+* I rewrote the 6809 emulator engine with giant switch statements to hammerout all unnecessary procedure calls and to gain some speed by enabling thecompiler to use register variables where appropriate. On my 386 thespeed increase was disappointing. The equivalent processor speed is now250kHz, up from about 170kHz (remember that extra wait state?). On a HPUXworkstation, I got a factor of 2 speed increase. That sucker runs at anemulated processor speed of about 3.5MHz. A Pentium-90 is even faster,more than any real 6809 can (officially) run.
+* I added XMODEM upload/download features to the 'terminal front end' of thesimulator. On the other end of the 'serial link' a 6809 machine codeprogram runs the other end of the XMODEM file transfer protocol.
+* I changed the SWI2/SWI3 hack to real ACIA emulation at a port address.
+* I write-protected the ROM area.
+* I added a 20ms timer interrupt.
+* I wrote a monitor program for the virtual SBC that has to followinfeatures.
+** Simple (vectorized) operating system functions, like character I/Oline I/O, XMODEM transfer. Usable by application programs.
+** a hex/ascii dump command.
+** a hex/ascii enter command.
+** a hex/ascii memory search command.
+** memory move command.
+** S-record send and receive capabilities (directly in ASCII orthrough XMODEM).
+** Binary load and save of memory region through XMODEM
+** register display and modify.
+** go to address (or current program counter) and call subroutine commands.
+** breakpoints.
+** program step tracing (breakpoint after next instruction), DEBUG Pcommand
+** single step tracing (based on timer interrupt). I had to cheat with theemulator to implement this.
+** one-pass (no labels) disassembler (DEBUG U command).
+** line-by-line assembler (DEBUG A command) I wrotethis one such that an additional real assembler can use most of the guts ofit.
+Finally I wrote a real 6809 Forth, based on some other Forth I wrote for an
+imaginary stack machine. Those old dusty primitives that I had written back in
+1990 proved very useful now. This Forth can load programs through XMODEM
+too. It can recompile (metacompile) itself and, very importantly, it runs
+tetris! (crawls on the 386) This is the tetris implementation written in
+ANSI Forth by Dirk Zoller and it is used as a test program.
+Next I have to make this Forth ROM-able.
+What else will go into that 32k ROM area? The monitor will be around 7k, 1k
+is reserved for the I/O space. Forth (with its own Forth assembler) will
+take about 12k, 8k without. A few additional k could be used for a 'real'
+assemler, but I doubt I will ever use that. A cross assembler is much more
+convenient. BASIC no doubt. But I'm afraid I'll have to write it myself,
+more so as I want to have {{{source code}}} of all my 6809 stuff. I already have
+the floating point routines for it.

Mercurial > hg > Members > kono > os9 > sbc09

comparison doc/sbc09.creole @ 57:2088fd998865