Showing posts with label single board computer. Show all posts
Showing posts with label single board computer. Show all posts

Tuesday, February 5, 2019

A 6809 Single Board Computer: Disassembler and Thoughts on the 6809


As a project to use my 6809 SBC and learn more about 6809 assembly language programming, I wrote a disassembler that can run on the board. The design was loosely based on the one I did for the 6502.

While straightforward in principle, a disassembler for the 6809 is a little more challenging that for the 6502 for a number of reasons:
  • It supports many instructions.
  • Some instructions have unique operand formats (e.g. TFR/EXG, PSH/PULS).
  • There are many (24) different indexed addressing modes.
  • The instruction length can change based on the indexed addressing mode being used.
  • Some instructions are two bytes long, prefixed by $10 or $11 (the so-called page 2 and page 3 op codes).
Implementation was pretty straightforward. I used lookup tables for a number of things including op codes, instruction types, addressing modes, and mnemonics. I strove to make the code readable and avoided any tricks that might increase efficiency slightly at the expense of clarity.

It is mostly portable. It uses ASSIST09 monitor routines for i/o, but other than that could be used on other systems with minor changes.

I implemented over a few evenings, building it up in pieces. It took some time (but less than I expected) to handle all the index addressing modes and to correctly handle the differing instruction lengths and page 2/3 instructions.

My basic approaches for testing and debug were:
  1. Test low level functions, like PrintString, on their own with some test code.
  2. "Desk check" complex code on paper to try to verify the logic, use of registers, etc.
  3. Build it up in stages and confirm them working before adding on (e.g. initially just display hex bytes)
When I ran into bugs I used the "desk check" method as well as making use of breakpoints when running the code to see what it was doing at various steps. Having a working monitor to run, display and change memory and registers, etc. was a requirement and ASSIST09 worked well for that. Downloading new versions of code over the serial port only took a few seconds.

I initially ran it standalone, but at the end I was able to also support installing it as an external command in the ASSSIST09 monitor, so you can run it by typing U (for unassemble). ASSIST09 has calls to add new commands, so it can be done without changing the code in ROM.

Here is some sample output (disassembling the start of the ASSIST09 ROM code):

>U F800
F800  30 8D 68 BE  LEAX  $68BE ,PCR
F804  1F 10        TFR   X,D
F806  1F 8B        TFR   A,DP
F808  97 9D        STA   $9D 
F80A  33 84        LEAU  ,X
F80C  31 8C 35     LEAY  $35 ,PCR
F80F  EF 81        STU   ,X++
F811  C6 16        LDB   #$16 
F813  34 04        PSHS  B
F815  1F 20        TFR   Y,D
F817  E3 A1        ADDD  ,Y++
F819  ED 81        STD   ,X++
F81B  6A E4        DEC   ,S
F81D  26 F6        BNE   $F815 
F81F  C6 0D        LDB   #$0D 
F821  A6 A0        LDA   ,Y+
F823  A7 80        STA   ,X+
F825  5A           DECB
F826  26 F9        BNE   $F821 
F828  31 8D F7 D4  LEAY  $F7D4 ,PCR
F82C  8E 20 FE     LDX   #$20FE 
F82F  AC A1        CMPX  ,Y++
F831  26 02        BNE   $F835 
F833  AD A4        JSR   ,Y
PRESS SPACE TO CONTINUE, Q TO QUIT 

With a little more 6809 assembly language programming experience under my belt, it is interesting to compare it to the other 8-bit processor I am most familiar with, the 6502. Let me list a few thoughts here.

Having two accumulators is very handy. Often one is being used as an accumulator for some form of data, but another may be needed for indexing or as a parameter to calling another routine. Surprisingly, I also found myself using the 16-bit D register (which uses A and B) because I needed 16-bit data. Some functions, like addition and subtraction, are supported on the D register, but many only have 8-bit versions which you need to combine using several instructions to work on 16 bits of data.

Two index registers is also handy (the 6502 has two, but the 6809's predecessor the 6800 only had one). But I found in practice that I rarely needed a second one. Having 16-bit index registers, unlike the 8-bit registers of the 6502, was much more convenient as you often find you are using them to store addresses.

The 6502 typically makes the programmer heavily use addresses in the first 256 bytes of memory (page 0). Some key instructions and addressing modes can only work with page zero. For that reason, these tend to become valuable real estate and you can run out of them or run into collisions between different uses of them. In contrast, the 6809 has a more orthogonal instruction set and all relevant instructions can work with full 16-bit addresses. It does have direct mode (8-bit addresses) but with the Direct Page register you can have them work with any page of memory, not just page zero. I did not use this feature (the ASSIST09 monitor does) but I can see it being useful when you wanted to optimize the size of your code.

In general the 6809 is more orthogonal than the 6502, with few limitations on the addressing modes or operands of instructions. Unlike the 6502 you can push, pull, transfer, or exchange any registers. The push and pull (PSHS/PSHU/PULS/PULU) instructions are particularly nice in that you can push or pull a set of registers in one instruction. The order of push and pull is defined, so that you do not have to ensure that the order is correct in your code (provided you push and pull the same list of registers). There are two stack pointers, but I only used one. And of course, the 16-bit stack pointer is much more reasonable than the 8-bit stack on the 6502 that is fixed in page 1 of memory.

Transfer (TFR) and Exchange (EXG) are two other instructions which are very handy for moving registers around without any restrictions. The 6502 had some limitations on what registers you could transfer and had no equivalent to EXG.

The 6809 introduced a MULtiply instruction, which sounded at the time like a luxury for assembly language programmers. I actually used it in an early version of my disassembler program when I needed to multiply the offset to a table by 4 and get a 16-bit result. I felt it was overkill using a multiply to do this, and later did it using two shifts (you can easily implement a 16-bit shift of the D register using two instructions: ASLB, ROLA).

The 6809 has many more addressing modes than the 6502, with 24 variations of indexed addressing. I think it is unlikely that assembly language programmers would use the majority of these as just a few of them generally suffice. I suspect the original intention may have been to help support compilers of high-level languages that could use these.

One quirk with indexed addressing that could confuse programmers is that the 5, 8, and 16 b-t offset modes consider the offset to be signed. So, for example, the 5 bit offsets are not 0 to 31 but rather -16 to 15. If you have a lookup table of 256 elements, for example, and expect the 8-bit offset indexed addressing mode to access all of them starting from an offset of zero, you will be surprised when values of $80 and higher don't read the table entries you expected. I ran into this, and solved it by using 16-bit offset in this case.

One instruction that you could easily overlook is LEA (Load Effective Address). It might not seem particularly useful, essentially removing one level of indirection. In fact it is very useful, and is the key to a lot of efficient programming as it can make use of all of the indexed addressing modes and make code position independent.

The 6809 supports position independent code (PIC). The ASSIST09 monitor, for example, is fully position independent. It is not particularly hard to write PIC code, and I made some effort to try this in the disassembler. Mostly it is a matter of using branches rather than jumps and using the PCR (program counter relative) addressing mode when working with addresses. I did leave the memory locations in RAM used by the program at fixed addresses. One annoyance is that as code gets larger during development 8-bit branches often fail and need to be converted to long branches. Unlike some assemblers, the one I was using did not automatically select short or long branches as needed.

Overall, the 6809 is quite a pleasant processor to program, with more instructions, more and larger registers than the 6502. Of course, it is not really a fair comparison as it came a generation later and could make use of advanced in technology that allowed a more complex chip. The 6800 was of the same vintage as the 6502. In fact, the decision to use the 6502 over the 6800 in a number of early computers was based on cost. Compared to the $300 price tag of the 6800, the 6502 sold for $25. The Apple 1 was originally designed to use a 6800, but was converted to the 6502 when Steve Wozniak learned about it. The schematic diagram for the Apple 1 still listed the circuit changes needed on the board to use a 6800.

Sunday, January 27, 2019

A 6809 Single Board Computer


As well as the 6502, 6800, and 68000 chips, another CPU I used early in my career was the Motorola 6809, the more powerful successor to the 6800. Having completed some retrocomputing projects with the other chips, I start looking for a project where I could play with this CPU for nostalgia purposes.

I soon came across a Single Board Computer design by Grant Searle. A five or six chip design, it has serial i/o and can run a version of Microsoft BASIC that he adapted from the version in the Radio Shack Color Computer.

The basic specs are a 6809 processor running at just under 2 MHz, 32K of static RAM, 16K of EPROM, and a 6850 ACIA-based serial port.

The design is simple, potentially buildable on a breadboard, and had been reproduced by other people, so I decided to give it a try.

I entered my own schematic using the EasyEDA web-based CAD software. This would make it easier to make design changes and potentially a printed circuit board (PCB).

I made a few small changes in my version of the board:

  • Used a 6-pin connector for a standard FTDI USB to serial breakout board and omitted any RS-232 line driver/receiver circuitry. I also omitted the optional hardware handshaking circuit.
  • Added a simple power on reset circuit to the pushbutton reset.
  • Added a power on LED.
  • Provided a jumper to select USB or external power source.
  • Added a 32-pin header with access to most signals, for future expansion and to help with debug.

The system can plug into a computer's USB port where it shows up as a serial port. It is powered by USB (taking about 230 mA of current) and you communicate with it using a terminal emulator.

The provided BASIC is a port of Microsoft Extended BASIC for the 6809-based Radio Shack Color Computer. A disassembly of it was published in two books. In Grant Searle's port, all code and commands that were not applicable (e.g. graphics, sound, cassette tape i/o) were removed. It is just under 10KB in size. Pretty typical of Microsoft BASIC of the era, it has a few quirks, e.g. available memory i available from the variable MEM rather than a function FRE(). Extended Color Computer BASIC has some additional commands that are useful like RENUMber, additional math functions, PRINT USING, TRON/TROFF and even EDIT to support editing program lines. Apparently this was the last version of Microsoft BASIC that Bill Gates personally worked on. You can find online copies of books on the Colour Computer and its version of BASIC.

I took the BASIC firmware and got it to build under Linux using the as09 cross-assembler with no warnings. I found and fixed a small typo that might have affected the PRINT USING command.

I breadboarded the CPU, clock, and reset circuit on a solderless breadboard. Then I got the 6809 to free run by forcing all the data lines all low. I decided not to breadboard the entire circuit as it would be quite tedious to do so, wouldn't fit on my small breadboard, and the design looked stable and had been verified by others, so I opted to move directly to a PCB layout.

I made a PCB layout from EasyEDA (using the autorouter). Once it looked good, I ordered some PCBs from JLPCB, a partner of EasyEDA which offers PCBS for as little as $2 per board.

There are high quality double-sided boards with plated-through holes, silkscreened, solder masked and even electrically tested. They are built in about one day and arrive in about 5 business days. With the availability of suppliers like this, it really doesn't make sense to etch your own boards at home.


I had found and orders the remaining parts I needed on Ebay. Some, like the Motorola 68B50 and 68B09, are readily available as new old stock (NOS).


I programmed the firmware onto a 27C128 EPROM using my UV eraser and programmer.


Once the boards arrived, I build one up, starting with the power, then clock and reset circuits. Everything checked out and before long BASIC was up and running!

I read some books on Color Computer BASIC to review the commands, played with the commands and tested some old programs. Here is an example, a little horoscope program I wrote in BASIC some time again, which ran with some minor changes:

           YOUR HOROSCOPE
           --------------

THE PROGRAM GENERATES A PERSONAL
HOROSCOPE. I NEED SOME INFORMATION
ABOUT YOUR DATE AND LOCATION OF BIRTH.
I WILL THEN GENERATE AN ANALYSIS BASED
ON YOUR ASTROLOGICAL DATA.

WHAT IS YOUR FIRST NAME? Fred
YOUR YEAR OF BIRTH (E.G. 1980)? 1980
YOUR MONTH OF BIRTH (1=JAN)? 6
DAY OF THE MONTH (1-31)? 21
COUNTRY OF BIRTH? Canada
IN WHAT CITY? Ottawa
CALCULATING HOROSCOPE...PLEASE WAIT.

Fred, YOUR ASTROLOGICAL SIGN IS:
CANCER.

HERE IS MY ANALYSIS:

AT TIMES YOU ARE EXTROVERTED, AFFABLE,
SOCIABLE, WHILE AT OTHER TIMES YOU ARE
INTROVERTED, WARY, RESERVED.

YOU WORRY ABOUT YOUR HEALTH AS YOU GET
OLDER.

YOU ARE CONCERNED ABOUT THE HEALTH OF
AN AGING RELATIVE.

GENERATE ANOTHER HOROSCOPE (Y/N)? 

Looking for machine language monitors, I found source code for the ASSIST09 program that Motorola offers for their 6809-based development ports. I got it to cross-assemble under Linux, and modified it to work with the 6850 ACIA instead of what the Motorola hardware used. With a little debugging, I got it running. It works well, and provides most feature you want for development and debug, including memory display and change, register display and change, running and breakpoints, and generating and loading Motorola S record files. here is a sample session:

ASSIST09
>D 1000 20

      0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F  
1000 45 41 4C 49 53 54 49 43 2E 22 20 3A 20 90 00 10  EALISTIC." : ...
1010 56 2F 26 87 20 22 54 48 45 20 42 49 52 54 48 44  V/&. "THE BIRTHD
>R
PC-F842 A-00 B-00 X-20FE Y-F002 U-60C2 S-6051 CC-F4 DP-00 
PC-
>M 1000
45-55
>P 1000 100F
S13100055414C49535449432E22203A2090001014
S9030000FC
>

I am able to cross-assemble code on a Linux computer and then load the S record file onto the board via the serial port. This is much more efficient than erasing and burning EPROMs.


Note that for uploading you need to add delays due to no hardware handshaking. I use the ascii-xfr program on Linux to do this, as well as the minicom terminal emulator.

I wrote a couple of example programs that run with the ASSIST09 monitor, using it's SWI functions for i/o.

Next, I combined BASIC and ASSIST09 into one EPPROM. It comes up in ASSIST09 but you can get to BASIC using the "G D000" command. This offers the ability to play with BASIC or machine language without swapping EPROMs.

ASSIST09
>G D000
6809 EXTENDED BASIC
(C) 1982 BY MICROSOFT

OK
10 FOR I = 1 TO 10
20 PRINT I,
30 NEXT I
RUN
 1               2               3               4               5
 6               7               8               9               10
OK

I have built up a second board and am just waiting to receive a second 68B09 chip to complete it. I have a few programming projects in mind to work on, and some code (like a small C compiler) that I want to look at.

If you want to give this a design a try, I encourage you to do so. Feel free to use my PCB design files if you wish, or just breadboard it up.

References


  1. Grant's 6-chip 6809 Computer: http://searle.hostei.com/grant/6809/Simple6809.html
  2. My git code with firmware and other software: https://github.com/jefftranter/6809/tree/master/sbc
  3. EasyEDA project: https://easyeda.com/tranter/6809-Single-Board-Computer
  4. AS9 assembler: http://home.hccnet.nl/a.w.m.van.der.horst/m6809.html

Thursday, June 8, 2017

Building a 68000 Single Board Computer - The Newlib C Library



To protect it, I made a Lexan cover for the TS2 board, similar to what I did for the prototype. I mounted it using nylon standoffs and mounted the switches on the cover. I don't yet have the correct toggle switches, so the units here are temporary.




In order to run C programs of any complexity, you need a C run-time library to provide functions for things like input/output (e.g. printf) and string manipulation (e.g. strcmp). Since the TS2 is not running an operating system like Linux, this is not available.

A full C library is too large to run on a board like this with only 32K of RAM. Fortunately, there are some smaller alternative C run-time libraries available, mostly designed for embedded systems.

I spent some time looking at one of the popular ones, newlib. Designed for embedded systems, it supports the Motorola 68000 processor (usually referred to as m68k).

It is quite complex and documentation is sparse. I found and read a number of references. I found the easiest way to port it to the TS2 board was to start with the newlib code for another 68000-based single-board computer, copy it, and adapt it (As someone once said: "adopt, adapt, and improve").

Porting newlib involves creating at least some minimal functions for low-level input output and returning from the main() functions. These are in a part of newlib known as libgloss.

I won't cover all the details, but these were the files I needed to modify or create, all located in the libgloss/m68k/ direcytory of newlib:

Makefile.in - This is the make file which needed to be modified to add the new TS2 target platform.

crt0.S - This is the C run-time startup file. This only needed one minor change to work around a problem I encountered with atexit handling.

tutor.S - This file implements basic routines for character and string input and output and returning after main(). They are implemented in assembler and call the TUTOR ROMs routines via trap 14 with the exception of one routine which returns if a character is ready for input. It needed to talk directly to the UART hardware as TUTOR did not implement such a function. After executing main, controls returns to the TUTOR monitor.

tutor.h - This file defines some constants use by tutor.S, specifically the names of the TUTOR trap 14 functions.

ts2.ld - This is a linker script which defines the memory map to use when building for the TS2 board. You refer to this when linking your program with newlib.

The relevant files can all be found here.

The newlib directory contains a script which downloads the gcc and newlib source code, and then configures and builds gcc and newlib. It patches newlib with the files needed to support the TS2.

Also included is a sample program and make file which builds using the cross-compiler and newlib and runs on the TS2. It is a small C program I wrote some years ago to solve the "n queens" chess problem. It is very CPU and stack intensive program that can take a long time to run depending on the speed of the system and the size of the chessboard for the problem.

I ran it for a 5x5 board. The output is below:

TUTOR  1.3 > GO 804
PHYSICAL ADDRESS=00000804
Solving n queens problem for n = 5
+---------------+
| Q  .  .  .  . |
| .  .  Q  .  . |
| .  .  .  .  Q |
| .  Q  .  .  . |
| .  .  .  Q  . |
+---------------+
+---------------+
| Q  .  .  .  . |
| .  .  .  Q  . |
| .  Q  .  .  . |
| .  .  .  .  Q |
| .  .  Q  .  . |
+---------------+
+---------------+
| .  Q  .  .  . |
| .  .  .  Q  . |
| Q  .  .  .  . |
| .  .  Q  .  . |
| .  .  .  .  Q |
+---------------+
+---------------+
| .  Q  .  .  . |
| .  .  .  .  Q |
| .  .  Q  .  . |
| Q  .  .  .  . |
| .  .  .  Q  . |
+---------------+
+---------------+
| .  .  Q  .  . |
| Q  .  .  .  . |
| .  .  .  Q  . |
| .  Q  .  .  . |
| .  .  .  .  Q |
+---------------+
+---------------+
| .  .  Q  .  . |
| .  .  .  .  Q |
| .  Q  .  .  . |
| .  .  .  Q  . |
| Q  .  .  .  . |
+---------------+
+---------------+
| .  .  .  Q  . |
| Q  .  .  .  . |
| .  .  Q  .  . |
| .  .  .  .  Q |
| .  Q  .  .  . |
+---------------+
+---------------+
| .  .  .  Q  . |
| .  Q  .  .  . |
| .  .  .  .  Q |
| .  .  Q  .  . |
| Q  .  .  .  . |
+---------------+
+---------------+
| .  .  .  .  Q |
| .  Q  .  .  . |
| .  .  .  Q  . |
| Q  .  .  .  . |
| .  .  Q  .  . |
+---------------+
+---------------+
| .  .  .  .  Q |
| .  .  Q  .  . |
| Q  .  .  .  . |
| .  .  .  Q  . |
| .  Q  .  .  . |
+---------------+
Found 10 solutions after 53130 tries.
TUTOR  1.3 > 

This took about 2.5 minutes to find all the solutions. On a modern 64-bit computer running at a 2 GHz or so clock speed, the same program runs in negligeable time.

With newlib, I can now write C programs that use most of the common ANSI C library functions other than file i/o, threads, or other things lacking without a "real" operating system. The program also has to fit within the 32K RAM limit.

Sunday, February 26, 2017

Building a 68000 Single Board Computer - Revision 2.1

I've now updated the design with some changes that I call revision 2.1. It is in a different github directory from revision 2.0: https://github.com/jefftranter/68000/tree/master/TS2/v2.1

In revision 2.1, the large and hard to obtain MC14411 baud rate generator is replaced by a smaller, simpler circuit using the more easily obtained 74HC4060. The difficult to obtain 25LS2548 chip is replaced by more commonly available parts.

Both circuit changes were tested with the wirewrap prototype and a breadboard.


I've done a new PCB layout and checked it reasonably carefully. I'm confident enough in it that I have ordered some boards from easyeda.com. These will take some time to arrive. I plan to build up one board using the parts from the wirewrap prototype.

Sunday, January 22, 2017

Building a 68000 Single Board Computer - Possible Future Enhancements

I've learned a lot with this TS2 project and done much more with that than I had originally hoped. While I have some more things to work on, I think it is time to put it on the back burner for a while and get back to some other projects.

Looking forward, it might be interesting to do a new revision of the board, which I could call revision 2.x (I called my version 2.0 since it revised the original Teesside design).

Here are some thoughts on some possible changes and features in a new version.

Printed Circuit Board Layout

A printed circuit board would make it much easier and faster to assemble than the wirewrap prototype. Professionally manufactured PCBs that are double-sided (or more), silkscreened, and solder masked can be obtained very inexpensively now from a number of vendors. Since the design is now in a CAD system (kicad) which has a PCB layout facility, it should not be too much effort to lay out a board. I've never used kicad for PCB layout or even laid out other than very simple single-sided boards, so this would be a good learning experience. Now that the design is proven, the risk of a PCB layout should be quite low.

Replace Baud Rate Generator With Fixed Clock Oscillator/Counter

The Motorola MC14411 baud rate generator chip used in the current design is a little difficult to obtain and overkill if only one baud rate is ever used. Newer UART chips have on-chip baud rate generators, but assuming the design stayed with the 6850 to remain software compatible, a baud rate generator could be created with simpler and more easily obtained circuitry. This link, for example, shows how to do it with a 74HC4060 and the existing 1.8432 MHz crystal.

Support Higher Baud Rates (Through Jumpers or Software)

It would be desirable to be able to run the serial port at baud rates higher than 9600, when downloading programs for example. A new baud rate generator circuit would allow this, since the 6850 can run at higher rates given a suitable clock.

Add One Or Two PIA, VIA, or PIT Chips

A parallel port would allow controlling hardware. This could be the Motorola 6820 or 6821, the more powerful MOS Technology 6520 or 6522 VIA, or the Motorola 68210 Parallel Interface/Timer (PIT) which was present in the Motorola ECB.

Optionally Support Line Drivers/Receivers For True RS-232 Serial Ports

True serial ports might be desirable for some users, so the line driver/receiver circuitry from the original TS2 could be included as an option. This could be simplified by using a chip like the MAX232 which does not require +/12V supplies.It might also be useful to support hardware handshaking with RTS/CTS, which currently do not connect through to the FTDI connectors.

Add Connectors For External Parallel I/O, Interrupts, Etc.

A connector for some external signals would be useful if there was a parallel port. The interrupt lines could also be available here.

Replace 25LS2548 Chip

The 25LS2548 decoder chip is quite hard to obtain and may be an impediment to people who want to reproduce the circuit. This could be replaced by more commonly available chips. Probably a 74LS138 decoder plus a 74LS06 open collector driver and maybe and another gate or two.

On-board 5 Volt Power Regulator

To allow running off of unregulated power, an on-board 5 volt regulator could be added, either a 78L05 series regulator or a more modern buck converter.

Add an LED Display

A seven segment LED display would be useful for diagnostics and other purposes. This could be driven from a PIA (if present) or with dedicated circuitry (see the Clements book p.649 for a possible approach to drive a 7 segment LED).

Prototype Area

If there is room on the PCB, an area with a grid of 0.1" holes could be provided for prototyping.

Support Either RAM or EPROM/EEPROM In All Sockets

With a few changes, the design could support either RAM or EPROM/EEPROM chips on any of the memory sockets (the boot code would need to be in ROM). This would allow, for example, 48K or RAM for users who only needed 16K of ROM). It might also be handy to optionally (via a jumper) allow the EEPROM devices to be written to.

Support Larger RAM and ROM Chips

Larger RAM and ROM chips (e.g. 27128, 27256, etc.) are available and could be supported to allow more memory. This would impact the memory map and address decoding circuitry and make it more complex. Given more RAM, the board could potentially run a stripped down version of an operating system such as Linux or Minix.

Mass Storage for File System

To run a "real" operating like Linux would require some form of mass storage for the file system. This could be done with some flash memory and some suitable interface, maybe using an SD card interface intended for Arduinos. This is probably more of a version 3.x feature (at which point maybe I could add video, a real-time clock, Ethernet, etc.)

Wednesday, January 18, 2017

Building a 68000 Single Board Computer - Interrupt Control Circuitry (schematic page 9)

See https://github.com/jefftranter/68000/blob/master/TS2/v2/ts2.pdf

The interrupt circuitry being tested on a breadboard
before it was constructed on the wirewrap board.

The interrupt control circuitry surrounding the 68000 is conventional. A 74LS148 eight line to three line priority encoder, U28, converts the seven levels of interrupt request input into a 3-bit code on IPL0* to IPL2*. Note that each interrupt request input must have a pull-up resistor, except IRQ7* which is always driven by U35A.

The function code from the 68000 is decoded by U32, a 74LS138, and the resulting IACK* output is used to enable a second decoder, U33. U33 is also strobed by AS* and converts the information on A01 to A03 during an IACK cycle into one of seven levels of interrupt acknowledge output (IACK1* to IACK7*). Other function code information supplied by U32 that may be useful in debugging the system is the "user/supervisor" memory access codes and the "program/data" bus cycle codes.

The ABORT switch can generate a level 7 interrupt. This is present on the ECB and with the TUTOR firmware can be used to interrupt program execution. The switch is debounced by cross-coupled NAND gates U34A and U34B and then clocks flip-flop U35A high (it has its data input tied high). The Q* output of the flip-flop goes low, and is connected to the IRQ7* input. Note that, unlike interrupts 1 through 6, a level 7 interrupt cannot be masked or disabled. During an interrupt acknowledge cycle for a level 7 interrupt, IACK7* will go low and clear the flip-flop. The IACK7* signal will also ripple through U7D, U34C and U4F, driving VPA* low to indicate to the 68000 to perform an autovectored interrupt operation. The CPU will then use the level 7 autovector interrupt address in RAM.

Interrupts 5 and 6 are connected to the two ACIAs, allowing interrupt driven i/o to be performed if desired (the TS2 and TUTOR monitor programs do not make use of this). These interrupts are used in the same way on the Motorola ECB board. Like level 7, the interrupts are also configured for autovectored operation. The relevant IACK5* or IACK6* signal will go low and in turn drive VPA* low to perform autovectored interrupt handling.

IRQ4* is also available and configured for autovectored operation. Interrupts IRQ1* through IRQ3* are not -- they could be used with vectored interrupts if external circuitry is added for this.

The interrupt circuitry can be tested from the TUTOR monitor. Pressing the ABORT switch should generate a level 7 interrupt which will produce a "SOFTWARE ABORT" message and register dump.


Pulling IRQ5* or IRQ6* low should cause TUTOR to produce "AV#5 TRAP ERROR" and "AV#6 TRAP ERROR" messages, respectively. In order for this to happen the interrupt mask in the status register must be set to enable these interrupts.

Building a 68000 Single Board Computer - ACIAs (schematic page 8)

See https://github.com/jefftranter/68000/blob/master/TS2/v2/ts2.pdf

The only I/O ports implemented on the TS2 CPU module are the two 6850 ACIAs shown on schematic page 8. The circuit is almost identical to that found in the ECB module. One port is dedicated to the terminal (IC U29 at address $00010040) and the other (IC U30 at address $00010041) is dedicated to the host computer interface.

The baud rate can be selected by selecting the appropriate output of the baud rate generator U31, but there is little reason to use a rate lower than 9600 bps. The two ACIAs can also be run a different baud rates if desired.

Omitted from my design is the serial port transparent mode feature of the original TS2, also present on the ECB, which connected the terminal interface directly to the host port whenever RTS from U29 was high. This means that the TS2 monitor TRAN and TUTOR TM commands will not operate correctly, but the transparent mode is of little use unless the console is actually a dumb terminal rather than a host computer.

An error should be noted on the schematic on page 896 of the Clements book. The chip selects for the ACIAs should be driven by the signal CS_PERI2* and not CS_PERI1* as shown in the book.

My design also replaces the 1488 and 1489 RS-232 line drivers and receivers with an FTDI connector to support FTDI USB to serial devices rather than true RS-232, which would require the connected computer to have RS-232 serial ports. This also removed the need for +12V and -12C power supplies.

Optionally the board it can be powered by USB using either of the FTDI serial ports - a jumper needs to be connected on the port where power is taken from, in which case an external power supply should not be used.

Tuesday, January 17, 2017

Building a 68000 Single Board Computer - DTACK and BERR Control Circuitry (schematic page 7)

See https://github.com/jefftranter/68000/blob/master/TS2/v2/ts2.pdf

Each memory access cycle begins with the assertion of AS* by the 68000 and ends with the assertion of DTACK* (or VPA*) by the addressed device or with the assertion of BERR* by a watchdog timer. Schematic page 7 gives the diagram of the DTACK* and BERR* control circuitry on the CPU module.

Whenever a block of 16 KBytes of memory is selected on the CPU module, one of the four select signals, SEL0* to SEL3*, goes active-low. The output, MSEL, of the NAND gate U19A is then forced active-high. MSEL becomes the ENABLE/LOAD* control input of a 74LS161 4-bit counter, U22. When MSEL=0 (i.e. on-board memory is not accessed), the counter is held in its load state and the data inputs on P0 to P3 are preloaded into the counter, by default 1100. The desired preload value can be set using DIP switches. The Q3 output from the counter is gated, uninverted, through U10B and U7B to form the processor's DTACK* input.

When MSEL goes high the counter is enabled. The counter is clocked from the 68000's clock and counts upward from 1100. After four clock pulses, the counter rolls over from 1111 to 0000 and Q3 (and therefore DTACK*) goes low to provide the handshake required by the 68000 CPU. At the end of the cycle, AS* is negated and MSEL goes low to preload the counter with 1100 and negate DTACK*.

At the same time that U22 begins counting, a second timer, U21 (another 74LS161), also begins to count upward. The count clock is taken from the 68000's E output which runs at CLK/10. This counter is cleared to zero whenever AS* is negated. The rippled output from the counter goes high after the fifteenth count from zero and is inverted by the open-collector gate U4E to provide the CPU with a BERR* input. Therefore, unless AS* is negated within 15 E-clock cycles of the start of a bus cycle, BERR* is forced low to terminate the cycle. Note that the counter is disabled (Cep=0) in the singlestep mode (discussed later) to avoid a spurious bus error exception.

A useful feature of the DTACK* circuit is the addition of a single-step mode, allowing the execution of a single bus cycle (note bus cycle, not instruction) each time a button is pushed. This facility can be used to debug the system by freezing the state of the processor.

One of the inputs to the OR gate U10B is INHIBIT_DTACK. If this is active-high, the output of the OR gate is permanently true and the generation of DTACK* by the DTACK* delay circuit is inhibited. Therefore, a bus cycle remains frozen with AS* asserted, forcing the CPU to generate an infinite stream of wait states.

Two positive-edge triggered D flip-flops, U20A and U23A, control INHIBIT_DTACK. U20A acts as a debounced switch and produces an SS/RUN* signal fro its Q output, depending only on the state of the single-step/run switch. Unfortunately, it would be unwise to use the output of U20A to inhibit DTACK*, because changing from run to single-step mode in mid bus cycle might lead to unpredictable results. Instead, the output of U20A is synchronized with AS* from the processor by a second flip-flop, U23A. The INHIBIT_DTACK signal from U23A is forced high only when AS* is negated at the end of a bus cycle. The 68000 always enters its single-step mode at the start of a new cycle before AS* is asserted.

In the single-step mode, DTACK* pulses are generated manually by pressing the "step" switch. The output of this switch is debounced by flip-flop U20B. A second flip-flop, U23B, generates a single, active-low pulse, SS_DTACK*, each time the step button is pushed. SS_DTACK* is gated in U7B to produce the DTACK* input needed to terminate the current bus cycle.

There are two simple ways of testing the DTACK* control circuits. One is in the free-run mode and is done by connecting, say, SEL0* to AS*, so that a delayed DTACK* is produced for each bus cycle. The single-step circuit can also be tested in this mode. Another procedure is to construct a special test rig for the circuit, which simulates the behavior of the 68000 by providing AS*, CLK, and SEL0* signals.

Building a 68000 Single Board Computer - RAM and ROM (schematic pages 5 and 6)

See https://github.com/jefftranter/68000/blob/master/TS2/v2/ts2.pdf

The use of 8Kx8 memory components permits the design of a memory with a very low component count and virtually no design effort. Page 5 gives the design of half of the components of the CPU module -- the others on page 6 (omitted in the Clements book) are arranged in exactly the same fashion but are enabled by different chip-select signals from the address decoder.

No further comment is required other than to point out that the EPROMs have their active-low output enables (OE*) driven by R/W* from the processor via an inverter. This action is necessary to avoid a bus conflict if a write access is made to EPROM memory space.

The original design used 2764 ultraviolet-erasable EPROMs. It is also compatible with 2864 electrically erasable EEPROMs. Either will work, but the latter are more easily erased and programmed. It can also use more modern CMOS memory devices (e.g. 27C64 and 28C64) which have lower current consumption.

Monday, January 16, 2017

Building a 68000 Single Board Computer - RAM and ROM Address Select (schematic page 4)

See https://github.com/jefftranter/68000/blob/master/TS2/v2/ts2.pdf

The selection of the individual RAM and EPROM components from the address decoder outputs is carried out by the circuit of page 4. Two-input OR gates combine one of the four device-select signals (SEL0* to SEL3*) from the address decoder with the appropriate data strobe (UDS* or LDS*) to produce the actual active-low chip-select inputs to the eight memory components on the CPU module.

The circuit is also responsible for overlaying the reset vector space onto the ROM memory space. When the RV* signal goes active-low while a reset vector is being fetched, the read/write memory at $00000000 to $00003FFF is disabled and the EPROM at $00008000 to $0000BFFF substituted.

Building a 68000 Single Board Computer - Address Decoding (schematic page 3)

See https://github.com/jefftranter/68000/blob/master/TS2/v2/ts2.pdf

The specification for the TS2 CPU module calls for up to 32 Kbytes of static RAM and up to 32 Kbytes of EPROM at the bottom of the processor's 16-MByte address space, permitting up to eight memory-mapped components, each occupying 64 bytes. The table below gives the memory map of the TS2 CPU module.

  Size (bytes)  Device        Address Space
  ------------  ------        -----------------
 1   8          EPROM1        $00000000-$00000007
 2  16K         RAM1          $00000008-$00003FFF
 3  16K         RAM2          $00004000-$00007FFF
 4  16K         EPROM1        $00008000-$0000BFFF
 5  16K         EPROM2        $0000C000-$0000FFFF
 6  64          Peripheral 1  $01000000-$0100003F
 7  64          Peripheral 2  $01000040-$0100007F
 8  64          Peripheral 3  $01000080-$010000BF
 9  64          Peripheral 4  $010000C0-$010000FF
10  64          Peripheral 5  $01000100-$0100013F
11  64          Peripheral 6  $01000140-$0100017F
12  64          Peripheral 7  $01000180-$010001BF
13  64          Peripheral 8  $010001C0-$010001FF

The address decoding table corresponding to the memory map above is given in the table below.

Device    A23 A22 ... A16 A15 A14 A13 A12 A11 A10 A09 A08 A07 A06 A05 A04 A03 A02 A01
 1 EPROM1  0  0   ...  0   0   0   0   0   0   0   0   0   0   0   0   0   0   X   X
 2 RAM1    0  0   ...  0   0   0   X   X   X   X   X   X   X   X   X   X   X   X   X
 3 RAM2    0  0   ...  0   0   1   X   X   X   X   X   X   X   X   X   X   X   X   X
 4 EPROM1  0  0   ...  0   1   0   X   X   X   X   X   X   X   X   X   X   X   X   X
 5 EPROM2  0  0   ...  0   1   1   X   X   X   X   X   X   X   X   X   X   X   X   X
 6 PERI1   0  0   ...  1   0   0   0   0   0   0   0   0   0   0   X   X   X   X   X
 7 PERI2   0  0   ...  1   0   0   0   0   0   0   0   0   0   1   X   X   X   X   X
 8 PERI3   0  0   ...  1   0   0   0   0   0   0   0   0   1   0   X   X   X   X   X
 9 PERI4   0  0   ...  1   0   0   0   0   0   0   0   0   1   1   X   X   X   X   X
10 PERI5   0  0   ...  1   0   0   0   0   0   0   0   1   0   0   X   X   X   X   X
11 PERI6   0  0   ...  1   0   0   0   0   0   0   0   1   0   1   X   X   X   X   X
12 PERI7   0  0   ...  1   0   0   0   0   0   0   0   1   1   0   X   X   X   X   X
13 PERI8   0  0   ...  1   0   0   0   0   0   0   0   1   1   1   X   X   X   X   X

A five-input NOR gate, U24A, generates an active-high output whenever A19 to A23 are all low. Together with A18 and A17, this gate enables a three line to eight line decoder, U26, that divides the lower 128 KBytes of memory space from $00000000 to $0001FFFF into eight blocks of 16K. The first four blocks decode the address space for the read/write memory and ROM. We deal with the selection of the reset vector memory space in ROM later.

The active-low peripherals group select output of U26 (i.e. the address range $00010000 to $00013FFF) enabled a second three line to eight line decoder, U27. U27 is a 25LS2548 that has two active-low and two active-high enable inputs. It also has an active-low open-collector output, ACK*, that is asserted whenever the device is enabled and strobed by a negative going pulse on its RD* or WR* inputs.

U27 is also enabled by U24B, which is high when A09 to A13 are all low, and by AS* from the CPU. Thus, whenever a valid address in the range $00010000 to $000101FF appears on the address bus, one of U27's active-low outputs is asserted, indicating a synchronous access to a peripheral by asserting the processor's VPA* input. Note that this arrangement is intended to be used in conjunction with 6800-series peripherals.

An access to the reset vectors in the range $00000000 to $00000007 is detected by gates U24A, U25A, U24B, U25B, U10C, and U19B. When the output of each NOR gate is high, signifying a zero on A03 to A23, the output of the NAND gate U19B, RV*, goes active-low. That is, RV* is low whenever a reset vector is being accessed and is used to overlay the exception table in read/write memory with the reset vectors in ROM.

The address decoder on page 3 can be tested to a limit extent by free-running the CPU and detecting decoding pulses at the outputs of the address decoder. A better technique is to insert a test ROM and to execute an infinite loop which periodically accesses the reset vector space. This makes it easy to observe the operation of the circuit with an oscilloscope.

Saturday, January 14, 2017

Building a 68000 Single Board Computer - Specifications of the TS2

Over the next few blog posts I'll go over the theory of operation of the TS2 68000 board. You'll want to open up the schematic diagram to follow the description.

This is based on the "Design Example Using the 68000" section of the book Microprocessor Systems Design 68000 Hardware, Software, and Interfacing, third edition, by Alan Clements. It has been adjusted to reflect my modified design.

First, a high level summary of the design goals and specifications of the board:

Specifications of the TS2

1. The TS2 uses a 68000 CPU.

2. It is built on a single circuit board.

3. The CPU card is capable of operating on its own. System testing is thus facilitated because other modules are not required to operate the CPU card in a stand-alone mode.

4. The original TS2 provided an external bus. This was omitted in my design as it was not required and reduced the chip count considerably.

5. The memory on the CPU card is static RAM and EPROM/EEPROM to avoid the complexity and associated difficulty of debugging dynamic RAM circuitry.

6. Full seven-level interrupt facilities are provided, but are optional. If included, these can support a level 7 interrupt (abort) switch, interrupts from the two ACIAs, and external interrupts.

7. Full address decoding is provided. The address space is compatible with the Motorola MEX68KECB Educational Computer Board (ECB) development system in order to facilitate the transfer of software between the TS2 and ECB.

8. The vector table at $00000000 to $000003FF is implemented in RAM, with the exception of the reset vectors which are mapped to the first 8 bytes of ROM (this will be described in more detail later).

9. The RAM is implemented by 8Kx8 CMOS devices to minimize the component count.

10. The ROM is implemented by 2764 type 8Kx8 EPROMs or 2864 type 8Kx8 EEPROMs (or equivalent CMOS devices).

11. The terminal (console) interface is through a serial port. A secondary port is also provided. Configuration is the same as in the ECB development system.

12. The module's local address and data buses have not been buffered as the CPU has adequate fanout.

Friday, January 13, 2017

Building a 68000 Single Board Computer - Enhanced Basic




The TUTOR monitor is quite powerful, but a high-level language makes programming much easier. In the 1980s the standard programming language for home computers was BASIC.

One of the options for BASIC on the 68000 is Enhanced Basic. Written by Lee Davison, Enhanced BASIC is a BASIC interpreter that he wrote from scratch, for both the 6502 and 68000 processors. It is designed to be easy to port to different systems and is free for non-commercial use.

I earlier looked at Enhanced Basic on my 6502-based Briel Replica 1 computer. The 68000 version looked interesting and feasible to port to the TS2.

Unfortunately, Lee Davison passed away in 2013 and his web site is no longer on-line. I was able to find the source for version 3.5.2, one version older than the latest 3.5.3 release.

It was originally written to compile using the Windows-based Easy68K assembler. While I was able to run this on Linux using the Wine software, it found that it would assemble with only a couple of trivial changes using the VASM assembler, which runs natively on Linux.

To port it to the TS2 I only needed to write routines for character input and output. I wrote them to talk directly to the 6850 console UART. I also needed to adjust the program addresses to work within the memory map of the TS2.

Enhanced Basic is almost 16K in size and and needs at least 16K of RAM for programs. The TS2 has 32K, so it was just enough for it to run out of RAM. It takes about 30 seconds to download the S record file over the serial port at 9600 bps.

Another machine dependent feature is loading and saving. As there is no easy way to implement the LOAD and SAVE commands, I modified it to display an unimplemented error if these commands are used. One could save programs by running LIST and capturing the output to a file from the terminal emulator program, and load using the reverse method.

Once I got it working from RAM, I then assembled it to run out of ROM. I first had to wire up the additional 16K ROM sockets on the TS2. Enhanced Basic conveniently fits in the second pair of 16K ROM, with TUTOR in the first 16K.

Running from ROM, it can now use all of the RAM. About 23K is available to BASIC programs when it starts up. Here is as sample session, starting from reset into the TUTOR monitor:

TUTOR  1.3 > GO C000
PHYSICAL ADDRESS=0000C000

23056 Bytes free
Enhanced 68k BASIC Version 3.52

Ready
10 FOR I = 1 TO 100
20 PRINT I;
30 NEXT I

RUN
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 3
0 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 
57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83
 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
Ready

20 PRINT HEX$(PEEK(I),2);" ";
LIST
10 FOR I = 1 TO 100
20 PRINT HEX$(PEEK(I),2);" ";
30 NEXT I

Ready
RUN
00 04 44 00 00 81 46 00 00 80 30 00 00 80 3A 00 00 8D E4 00 00 83 AC 00 00 83 B6
 00 00 83 C0 00 00 83 CA 00 00 8C BA 00 00 83 DE 00 00 83 E8 00 00 99 62 00 00 9
9 62 00 00 99 62 00 00 99 62 00 00 99 62 00 00 99 62 00 00 99 62 00 00 99 62 00 
00 99 62 00 00 99 62 00 00 99 62 00 00 99 62 00 00 83 F2 00 
Ready

The source code for the port can be found here on github.

Enhanced Basic has floating point and integer variables and over 100 keywords. It includes advanced functions like conversion to hexadecimal and binary. Keywords must be in uppercase.

It is not totally compatible with other BASICs so you will typically need to port programs to it. I tried the classic Hamurabi program that was in a book published by Creative Computing and found that it worked without changes, although there were some formatting issues in the output due to differences in the way the PRINT command functions. Here is a sample run of the game:

                                HAMURABI
               CREATIVE COMPUTING  MORRISTOWN, NEW JERSEY

TRY YOUR HAND AT GOVERNING ANCIENT SUMERIA
FOR A TEN-YEAR TERM OF OFFICE.

HAMURABI:  I BEG TO REPORT TO YOU,
IN YEAR 1, 0PEOPLE STARVED, 5CAME TO THE CITY,
POPULATION IS NOW 100
THE CITY NOW OWNS  1000ACRES.
YOU HARVESTED 3BUSHELS PER ACRE.
THE RATS ATE 200BUSHELS.
YOU NOW HAVE  2800BUSHELS IN STORE.

LAND IS TRADING AT 17BUSHELS PER ACRE.
HOW MANY ACRES DO YOU WISH TO BUY? 0
HOW MANY ACRES DO YOU WISH TO SELL? 0

HOW MANY BUSHELS DO YOU WISH TO FEED YOUR PEOPLE? 2000
HOW MANY ACRES DO YOU WISH TO PLANT WITH SEED? 20

HAMURABI:  I BEG TO REPORT TO YOU,
IN YEAR 2, 0PEOPLE STARVED, 3CAME TO THE CITY,
A HORRIBLE PLAGUE STRUCK!  HALF THE PEOPLE DIED.
POPULATION IS NOW 51
THE CITY NOW OWNS  1000ACRES.
YOU HARVESTED 1BUSHELS PER ACRE.
THE RATS ATE 0BUSHELS.
YOU NOW HAVE  810BUSHELS IN STORE.

LAND IS TRADING AT 17BUSHELS PER ACRE.
HOW MANY ACRES DO YOU WISH TO BUY? 10
HOW MANY BUSHELS DO YOU WISH TO FEED YOUR PEOPLE? 600
HOW MANY ACRES DO YOU WISH TO PLANT WITH SEED? 10

HAMURABI:  I BEG TO REPORT TO YOU,
IN YEAR 3, 21PEOPLE STARVED, 4CAME TO THE CITY,
A HORRIBLE PLAGUE STRUCK!  HALF THE PEOPLE DIED.
POPULATION IS NOW 17
THE CITY NOW OWNS  1010ACRES.
YOU HARVESTED 1BUSHELS PER ACRE.
THE RATS ATE 0BUSHELS.
YOU NOW HAVE  45BUSHELS IN STORE.

LAND IS TRADING AT 17BUSHELS PER ACRE.
HOW MANY ACRES DO YOU WISH TO BUY? 0
HOW MANY ACRES DO YOU WISH TO SELL? 0

HOW MANY BUSHELS DO YOU WISH TO FEED YOUR PEOPLE? 45
HOW MANY ACRES DO YOU WISH TO PLANT WITH SEED? 0

YOU STARVED 15PEOPLE IN ONE YEAR!!!
DUE TO THIS EXTREME MISMANAGEMENT YOU HAVE NOT ONLY
BEEN IMPEACHED AND THROWN OUT OF OFFICE BUT YOU HAVE
ALSO BEEN DECLARED NATIONAL FINK!!!!

SO LONG FOR NOW.

Maybe in the future I will try porting the classic Star Trek game, one of my favourite BASIC programs of that era.

Friday, January 6, 2017

Building a 68000 Single Board Computer - The TUTOR Monitor

When the 68000 chip was introduced, Motorola offered the MEX68KECB Educational Computer Board (ECB). It included a monitor program called TUTOR. I remember briefly having access to one where I worked back in the mid 1980s when some products were moving to this new processor and staff was becoming familiar with it.

The Teesside TS2, while similar, is a simpler design using static rather than dynamic RAM, and lacks some features like the parallel port and timer (PIT) and cassette tape interfaces. The TS2 was designed to be compatible with the ECB in terms of the memory map for ROM and RAM and serial ports. This allows it to run the TUTOR monitor program.

I was able to find source and binary code for TUTOR here. I ported it to the GNU assembler so that I could modify it if desired.

It is 16KB in size (unlike the TS2 monitor which is about 3Kb) and will fit in the first two 8K EPROMs of the TS2.

I wasn't sure if TUTOR would run as is on my design. The Clements book implied that it should, but did not say so explicitly. After programming the two EEPROMs and inserting them in the board I was pleased to see that it came up and accepted commands.

The Motorola ECB included a parallel printer port and cassette tape interface using the 68230 parallel Interface/Timer (PIT) chip. That chip is not included in the TS2. However, other than commands specific to the printer port and cassette tape, everything else works.

There is a copy of the review of the Motorola ECB from Byte magazine in 1983 here. At US$495 it would be equivalent to about US$1200 today. I believe one of the reasons that the University of Teesside designed their own educational board rather than the ECB was that they could significantly reduce the cost.

The TUTOR monitor is well documented in chapter 3 of the M68000 Educational Computer Board User's Manual. It is quite sophisticated, even including a disassembler and assembler. I'll just cover a few highlights and examples of what it offers.

It provides the following features:

  1. Display and modification of memory as byte, word, longwords, strings, characters, or disassembled instructions.
  2. Display and modification of registers.
  3. Memory fill, move, search, and test functions.
  4. Number conversion between decimal and hexadecimal.
  5. The ability to set and clear breakpoints.
  6. Ability to run programs with breakpoints or line by line tracing.
  7. Output to either of two serial ports, parallel printer port, or cassette tape.
  8. Loading and saving of memory in S record format.
  9. An assembler which allows entering assembly language mnemonics.

Here is a example of displaying memory, first as hex and ASCII data, then as a disassembly:

TUTOR  1.3 > MD 8008 80
008008    60 00 0C B0 41 F8 04 4C  20 3C 00 00 02 0E 42 81  `..0Ax.L <....B.
008018    10 C1 53 80 66 FA 48 7A  00 10 21 DF 00 08 48 7A  .AS.fzHz..!_..Hz
008028    00 12 21 DF 00 0C 4E 75  21 FC 42 55 53 20 00 30  ..!_..Nu!|BUS .0
008038    60 08 21 FC 41 44 44 52  00 30 21 DF 04 CA 21 DF  `.!|ADDR.0!_.J!_
008048    04 CE 21 CF 04 44 4F FA  00 0A 21 CF 04 D6 60 00  .N!O.DOz..!O.V`.
008058    0C 34 61 00 1C 3A 3C FC  0D 0A 30 38 04 CA 61 00  .4a..:<|..08.Ja.
008068    19 48 1C FC 00 20 20 38  04 CC 61 00 19 2E 1C FC  .H.|.  8.La....|
008078    00 20 30 38 04 D0 61 00  19 30 61 00 1B 86 60 00  . 08.Pa..0a...`.

TUTOR  1.3 > MD 8008 80 ;DI
008008    60000CB0             BRA.L   $008CBA 
00800C    41F8044C             LEA.L   $0000044C,A0 
008010    203C0000020E         MOVE.L  #526,D0 
008016    4281                 CLR.L   D1 
008018    10C1                 MOVE.B  D1,(A0)+ 
00801A    5380                 SUBQ.L  #1,D0 
00801C    66FA                 BNE.S   $008018 
00801E    487A0010             PEA.L   $00008030(PC) 
008022    21DF0008             MOVE.L  (A7)+,$00000008 
008026    487A0012             PEA.L   $0000803A(PC) 
00802A    21DF000C             MOVE.L  (A7)+,$0000000C 
00802E    4E75                 RTS      
008030    21FC425553200030     MOVE.L  #1112888096,$00000030 
008038    6008                 BRA.S   $008042 
00803A    21FC414444520030     MOVE.L  #1094992978,$00000030 
008042    21DF04CA             MOVE.L  (A7)+,$000004CA 
008046    21DF04CE             MOVE.L  (A7)+,$000004CE 
00804A    21CF0444             MOVE.L  A7,$00000444 
00804E    4FFA000A             LEA.L   $0000805A(PC),A7 
008052    21CF04D6             MOVE.L  A7,$000004D6 
008056    60000C34             BRA.L   $008C8C 
00805A    61001C3A             BSR.L   $009C96 
00805E    3CFC0D0A             MOVE.W  #3338,(A6)+ 
008062    303804CA             MOVE.W  $000004CA,D0 
008066    61001948             BSR.L   $0099B0 
00806A    1CFC0020             MOVE.B  #32,(A6)+ 
00806E    203804CC             MOVE.L  $000004CC,D0 
008072    6100192E             BSR.L   $0099A2 
008076    1CFC0020             MOVE.B  #32,(A6)+ 
00807A    303804D0             MOVE.W  $000004D0,D0 
00807E    61001930             BSR.L   $0099B0 
008082    61001B86             BSR.L   $009C0A 
008086    600018F6             BRA.L   $00997E 

TUTOR  1.3 > 

The assembler is quite powerful, mostly compatible with Motorola's cross-assembler but lacking support for editing, line numbers, and labels. In pinch, if you could not afford a development system with a cross-compiler, you could use TUTOR's assembler for development and upload the disassembled source and assembled S record file.

Using TUTOR I can easily cross-compile code on a Linux laptop, generate a Motorola hex file, and then transfer it to the TS2 over the serial port.

I'm shortly going to wire up the second 16K of RAM on the board. I can use the memory test command to verify that the new memory is working.

One quirk of TUTOR is that you need to enter all commands in upper case.

Also, some commands can be interrupted by typing BREAK. This is a special serial port sequence and not a character. From minicom it can be sent using F although this doesn't seem to work if you are using a USB to serial convertor.

Overall I see little reason to use the TS2 monitor as TUTOR is much more powerful. The features like breakpoints, tracing, and disassembler make it much easier to debug test programs.