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.

Building a 68000 Single Board Computer - The TS2 Monitor

The original Teesside TS2 computer included a small machine language monitor program called TS2MON or TSBUG. There is a source listing for it in the book as well as on the included CD-ROM.

As I posted here earlier, I ported the monitor so it could be cross-compiled with the GNU assembler for the 68000. I now have it running on my prototype board. It is a very rudimentary monitor program, running out of ROM, and is a little over 3 Kilobytes in size.

I programmed it into two 27C64 64KB EPROMs. I've also verified that the board works with 28C64 EEPROMs.

The monitor provides twelve commands offering some basic features:

• Examine and change memory.
• Display and change registers.
• Start program execution.
• Load and save memory though a serial port using Motorola hex (S record) format.
• Basic support for breakpoints, allow the setting and clearing of breakpoints and program execution to be halted and continued after a breakpoint.

I've documented the commands here. Here are a few examples.

?TSBUG 2 Version 23.07.86
?

Display and change some memory:

?MEM 1000
?
?00001000 0000  1234
?00001002 1234  2345
?00001004 2345  6789
?00001006 0000 -
?00001004 6789 N
?00001006 0000 N
?00001008 0000 

Display registers:

?DISP
?
?  Data reg       Address reg
?0 00000000        00000000
?1 00000000        00000000
?2 00000000        00000000
?3 00000000        00000000
?4 00000000        00000008
?5 00000040        00000000
?6 00000000        00000000
?7 00000000        00000000
?
? SS  =  00000000
? SR  =  2700
? PC  =  00001000

Change a couple of registers:

?REG PC 1000
?00001000
?
?REG D0 12345678
?00000000
?
?DISP
?
?  Data reg       Address reg
?0 12345678        00000000
?1 00000000        00000000
?2 00000000        00000000
?3 00000000        00000000
?4 00000000        00000008
?5 00000040        00000000
?6 00000000        00000000
?7 00000000        00000000
?
? SS  =  00000000
? SR  =  2700
? PC  =  00001000

Dump a range of memory to an S record file:

?DUMP 8000 8080
?
S113800000000800000080084DF80C0042AE004A51
S1138010422E0048422E00496136610005D86100B5
S1138020044E49FA09D06164207C0000C00020108D
S11380300C80524F4D3266044EA800084E714E71AA
S113804042876128614C61000080610000BE60F0DD
S113805041F90001004010BC0003117C0003000141
S113806010BC0015117C001500014E7548E700088E
S113807049FA099C61064CDF10004E752F00101C54
S10480806794
S9

The code was designed to be simple and readable. Despite its simplicity, it does have some more advanced features. It uses device control blocks (DCBs) in RAM to allow modifying the device input/output routines to redirect them. It can also be extended by code in the second set of ROMs to add more commands.

I've now wired up the second 6850 UART chip. The board has two serial ports. The rationale at the time was that users would typically have a dumb serial terminal connected to one port to use as a console, and the other port would connect to a development system computer for uploading or downloading programs. The TSMON LOAD and DUMP commands use the second serial port for this reason.

One of the simplifications in my design is to use an FTDI USB to serial (TTL-level) converter for the serial ports, avoiding the need for some additional chips and +/- 12 volt power supplies, and allowing it to be connected to a USB port. You can also power the board from USB if desired.

Typical usage today would be to connect to one computer using a terminal emulator (I'm using a laptop running Ubuntu Linux and use the minicom program). In that case it is probably more convenient to use only one serial port both as a console and for file transfers. While the monitor source code could be modified to use the monitor serial port for LOAD and DUMP, you can patch the DCB in RAM to direct the commands to use the console port rather than the auxiliary port. It is simply a matter of changing two words in the DCB. Addresses $00000D0E and $00000D26 need to be changed from $0041 to $0040. This needs to be done each time monitor is entered, i.e. after a reset.

Having done that, I can upload an S record file from my Linux laptop to the TS2 by cating the file to /dev/ttyUSB0 after running a monitor LOAD command. You can then run the program from the monitor. A simple test program can be found in git here.

In a future blog post I'll cover a more sophisticated monitor program, the TUTOR software, which was developed by Motorola for the 68000 Educational Computer Board (ECB), but also runs on the TS2 since it was designed to have a memory map compatible with the ECB.

Building a 68000 Single Board Computer - It's Alive!

I spent some of my recent holidays wiring up the rest of the board. With about 30 chips and a similar number of discrete components, it was quite time consuming. I followed a wiring color coding convention to distinguish between power, ground, data, address, and control signals.

To minimize the chance of errors I also marked the schematic in red pen for every connection that was made, and "ohmed out" the connections using a multimeter. As work progressed I only made and noticed a few wiring errors. I noticed a couple of small errors in my schematic as well during this process.

Last night I completed the wiring except for some portions that were not yet needed - the second set of EPROMs and RAM chips (not used by the monitor software) and the second serial port.

Today I did a last check that all chips were correctly installed and then powered it up. There were a few good signs immediately: no smoke, no chips got hot, and the current drain was reasonable. The halt LED did not come on, and looking at the CPU signals indicated that it seemed to be executing instructions.

However, no data came out the serial port, which should be expected if the monitor program was running. Some investigation with an oscilloscope indicated that the UART was never being enabled, so I started tracing back the address decoding chain.

I studied the relevant circuitry and looked at the description in the Clements book. Only a few minutes of study led me to realize that there was an error in the textbook and accompanying schematic. The wrong output for decoding the UART address was being used. This was confirmed by seeing that what I believed was the correct output was being enabled.

I made a quick change of one wire wrap, and tried the system again, hooked up using an FTDI USB to serial adaptor to a terminal emulator on my laptop. Sure enough, now I was seeing the monitor prompt!

I was able to type monitor commands and they worked correctly. I did some simple checks of the EPROM and RAM, and they appear to be working correctly. The single step circuit also seems to be working.

I'm amazed that it basically worked the first time. A lot of things had to all come together - the circuit design had to be correct, it needed to be correctly wired, and all components needed to be working.

I updated the schematic on github to correct the error, and better documented the monitor commands .

The next steps are to wire up the second UART and second set of RAM and ROM chips.

After that I can experiment with some more software. I've already entered a small program and confirmed that I can run it from the monitor, including hitting a breakpoint.

In taking some pictures of the board I noticed that it has something in common with some versions of the Raspberry Pi - it is sensitive to the camera flash, and will reset if a flash picture is taken close to it. The culprits are the EPROM chips.

Building a 68000 Single Board Computer - Freerunning on Protoboard

I'm now at the stage with the wirewrap version where I was on the earlier breadboard -- I have the clock, power on and pushbutton reset circuits, and CPU wired up so that I can free run the CPU. The power switch and power LED work, as well as the reset pushbutton and reset/halt LED.

By tieing AS* to DTACK* and pulling the 16 data bus lines low, it will continuously execute the instruction $0000 (which corresponds to ORI.B #0,D0) and cycle through all of memory. If I pull some data lines high, it gets an odd address exception and halts with the RESET/HALT LED lit, as expected.

Only five chips are wired up, but the rest have power and ground and bypass caps.

The next step is to wire up most of the remaining circuitry and attempt to get it running out of ROM and RAM. This will take some time as it involves almost everything in the circuit except the two UARTs. I will also only need half of the RAM and ROM chips to run the Teesside monitor program.

Building a 68000 Single Board Computer - Wirewrap Prototype

I've started assembly on a protoboard.

I am using a phenolic board with 0.1 inch hole spacing. I actually glued two boards together using Crazy Glue and some additional pieces of circuit board material for reinforcement to make a board large enough.

I've determined the locations for the ICs and inserted the wirewrap sockets. Until they are wired up, the sockets will fall out if the board is inverted, so to hold them in place I put a small dab of Gorilla Glue on one pin of each socket to hold it in place.

I also mounted the front panel switches and LEDs and some connectors. Power will connect using two binding posts. Two 6-pin headers will connect to the FTDI USB to serial adaptors for the two serial ports. A few discrete parts will be mounted on the perfboard but most will be installed into wirewrap sockets.

I installed 5 nylon standoffs, one on each corner and one in the center, to act as feet and lift the board up above the sockets.

Each IC has a 0.1 uF bypass capacitor installed next to it. There is a single large 100 uF electrolytic filter capacitor installed near the power connections.

The next steps are to wire up power to the power switch and LEDs and some of the ICs, then assemble the clock oscillator, power and pushbutton reset circuits and the microprocessor so I can get it to the same state as I had earlier on the breadboard - being able to run in freerun mode.