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.)

Building a 68000 Single Board Computer - Books

While there are many excellent web resources on the 68000 microprocessor, this is something of a nostalgia project and printed books still have a lot of appeal. I'd like to mention a few books on the 68000 that I own and have found useful.

Microprocessor Systems Design 68000 Hardware, Software, and Interfacing, Third Edition, by Alan Clements

This is the book that the TS2 design is described in. At almost 1000 pages, it has full coverage of hardware and software for the 68000 series up to and including the 68030. Everything is presenting in logical manner with many diagrams. If you are more interested only in the software side, you can skip the relevant sections. It came with a CD-ROM that includes a number of tools including a 68000 cross-assembler and simulator.

An Introduction to 68000 Assembly Language, by R.A. & J.W. Penfold

This little book represents the opposite end of the spectrum. Aimed at people who might have owned a 68000-based microcomputer like an Apple Macintosh, Commodore Amiga, Atari ST, or Sinclair QL, if presents the basic of 68000 assembly language programming. In it's 100 or so pages it covers the basic programming model, instructions, and address modes and give a few program examples Nothing is specific to a particular computer. It doesn't go into a lot of depth, but meets the goal of a small pocket-sized book that was inexpensive (British Pounds 2.95 at the time).

68000 Assembly Language Programming, Second Edition, Lance A. Leventhal, Doug Hawkins, Gerry Kane, and William D. Cramer.

This book was the 68000 version of a very popular series of books by Osborne that covers assembly language programming (I also have the 6502 version). At almost 500 pages, it provides extensive coverage of the 68000 including architecture, instructions and addressing modes. It includes many diagrams and dozens of detailed basic and advanced code examples. This edition also covers the 68010 and 68020.

On the hardware side I also referred to my Engineer's Notebooks by Forrest M. Mims III to refresh my knowledge on TTL gates and best design practices.

Building a 68000 Single Board Computer - Another Forth

I found another Forth implementation for the 68000 here. This one was distributed by Albert van der Horst from a Forth group in Holland. Unlike eForth that I described in my last blog post, this one
is compatible with the fig-FORTH standard.

It comes with default I/O routines to use a 6850 UART address $10040 (presumably the Motorola ECB), the same as my TS2.

I was able to build it with the VASM assembler with one trivial change. Loading it onto the TS2 over the serial port, it came up and seems to work fine.

Here is a sample session:

TUTOR  1.3 > GO 3648
PHYSICAL ADDRESS=00003648

68000 fig-FORTH V1.0 
1 2 3 4    OK
. 4    OK
+    OK
. 5    OK
* . 1    OK
." HELLO, WORLD! " HELLO, WORLD!    OK

( LARGE LETTER-F)    OK
: STAR 42 EMIT ;    OK
: STARS 0 DO STAR LOOP ;    OK
: MARGIN CR 30 SPACES ;    OK
: BLIP MARGIN STAR ;    OK
: BAR MARGIN 5 STARS ;    OK
: F BAR BLIP BAR BLIP BLIP CR ;    OK

F 
                              *****
                              *
                              *****
                              *
                              *
   OK

I think it's time to dig out my old copy of Starting Forth by Leo Brodie and refresh my knowledge of this programming language.

Building a 68000 Single Board Computer - Forth

Forth is an interesting programming language. It is an imperative, stack-based, language that the programmer extends by defining new commands. Years ago, I used an in-house developed variant of Forth (we called it Alice) for programming test software. It happened to run on 6809 and 68000 processors.

I looked for available implementations for the 68000 and found a few options. One, for example, was written for early Sun workstations that used 68000 series processors. This was in the 1980s when a Unix workstation with a few megabytes of RAM cost tens of thousands of dollars. I got it to assemble with only a few changes but it relies heavily on calls to the Unix operating system to perform i/o, and would not be easy to port to the TS2. It also looks a little too large for the TS2, wanting to have 96K of memory for storing Forth code.

The Easy68K web site has a copy of this version called eForth. Wrtiten by Bill Muench and C. H. Ting around 1990, this version was adapted by Paul R. Santa-Maria to run on the Motorola MC68000 Education Computer Board (ECB).

Both source code and a S record binary file are in the archive. The binary works perfectly on my TS2, since it is compatible with the ECB.

Here is a short sample session:

TUTOR  1.3 > GO 1000
PHYSICAL ADDRESS=00001000

eForth 68k v1.1
1 .S
 1
1 2 3 4 .S
 1 1 2 3 4
+ ok
.S
 1 1 2 7
* ok
.S
 1 1 14
0 32 DUMP
   0   0  0  4 44  0  0 81 46  0  0 80 30  0  0 80 3A  ___D___F___0___:
  10   0  0 8D E4  0  0 83 AC  0  0 83 B6  0  0 83 C0  ___d___,___6___@
  20   0  0 83 CA  0  0 8C BA  0  0 83 DE  0  0 83 E8  ___J___:___^___h ok
 ok

It should build using the VASM assembler with only a few trivial changes, but I didn't need to since it works "out of the box".

Building a 68000 Single Board Computer - Tiny Basic

Tiny BASIC is a dialect of the BASIC programming language that was originally written by Dennis Allison for early microcomputers including 6502 systems like the KIM-1. It could fit into as little as two or three kilobytes of memory. I earlier blogged about running the 6502 version on my Replica 1 computer.

Tiny Basic spawned a newsletter called Dr. Dobb's Journal of Tiny BASIC Calisthenics and Orthodontia, which evolved into the magazine Dr. Dobb's Journal. In 1985, the 100th issue of Dr. Dobb's Journal published an article by Gordon Brandly describing a Tiny Basic interpreter he had written for the Motorola 68000 microprocessor.

I came across this and thought I would try porting it to my TS2 computer. It turns out that no porting is needed, as it was designed to run on the Motorola MEX68KECB Educational Computer Board, which the TS2 is compatible with. I simply loaded the Motorola S record file and it came up on the console:

TUTOR  1.3 > GO 900
PHYSICAL ADDRESS=00000900

Gordo's MC68000 Tiny BASIC, v1.2

OK
>

The supported Basic keywords are BYE, CALL, FOR, GOSUB, GOTO, IF, INPUT, LET, LIST, LOAD, NEW, NEXT, PEEK, POKE, PRINT, READ, REM, RETURN, RUN, SAVE, STEP, STOP, AND TO. It is quite a limited version of Basic (it is only about 3K in size!), but some programs have been developed for or ported to it. One that comes with the Tiny Basic distribution is a version of the classic Star Trek game. Here is a transcript of a portion of a game:

> RUN
Do you want a difficult game?  (Y or N): N
Stardate 3200:  Your mission is to destroy 5 Klingons in 30 stardates.
There are 3 starbases.
Enterprise in Q-75 S-31
Captain: HELP
R=Report       S=SR. sensor   L=LR. sensor
G=Galaxy map   P=Phaser       T=Torpedo
W=Warp engine  * Please use one of these commands *
Captain: R
Status report:
Stardate      3200
Time Left     30
Condition     Green
Position      Q-75 S-31
Energy        4000
Torpedoes     10
Klingons left  5
Starbases     3
Captain: G
Enterprise in Q-75 S-31
Computer display of galaxy map

1:   0   0   0   0   0   0   0   0

2:   0   0   0   0   0   0   0   0

3:   0   0   0   0   0   0   0   0

4:   0   0   0   0   0   0   0   0

5:   0   0   0   0   0   0   0   0

6:   0   0   0   0   0   0   0   0

7:   0   0   0   0   0   0   0   0

8:   0   0   0   0   0   0   0   0
    ..  ..  ..  ..  ..  ..  ..  ..
     1   2   3   4   5   6   7   8

Captain: S
Enterprise in Q-75 S-31
Short range sensor
1 . . . . . . . .
2 . . . . . . . .
3 E . . . . . . .
4 . . . . . . . .
5 . . . . . . . .
6 . . . . . . . .
7 . . . . . . . .
8 . . . . . . . *
  1 2 3 4 5 6 7 8
Captain: L
Enterprise in Q-75 S-31
Long range sensor
   1   7   7
   1   1   1
 101   5   1
Captain: W
Captain: W
Warp engine
Sector distance: 10
Course (0-360): 180
Enterprise in Q-84 S-61
Klingon attack
218 units hit from Klingon at S-63
160 units hit from Klingon at S-51
143 units hit from Klingon at S-21
124 units hit from Klingon at S-12
3305 units of energy left.
Captain: S
Enterprise in Q-84 S-61
Short range sensor
1 . K . . . . . *
2 K . . . . . . .
3 . . . . . . . .
4 . . . . . . . .
5 K . . . . . . .
6 E . K . . . . .
7 . . . . . . . .
8 * . . . . . . .
  1 2 3 4 5 6 7 8
Captain: W
Warp engine
Sector distance: 1
Course (0-360): 0
**EMERGENCY STOP**
Spock: "To err is Human."
Enterprise in Q-84 S-61
Klingon attack
242 units hit from Klingon at S-63
172 units hit from Klingon at S-51
189 units hit from Klingon at S-21
 83 units hit from Klingon at S-12
2619 units of energy left.
Shield damaged, 4 stardates estimated for repair
Captain: S
Enterprise in Q-84 S-61
Short range sensor
1 . K . . . . . *
2 K . . . . . . .
3 . . . . . . . .
4 . . . . . . . .
5 K . . . . . . .
6 E . K . . . . .
7 . . . . . . . .
8 * . . . . . . .
  1 2 3 4 5 6 7 8
Captain: 

The article about Tiny Basic was also published in a book: Dr. Dobb's Toolbook of 68000 Programming. I'll have to see if I can find a copy of this.

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.

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.

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.

Building a 68000 Single Board Computer - Reset, Halt, and Clock Control Circuits (schematic page 2)

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

Every CPU requires a certain amount of basic control circuitry to enable it to operate -- this circuitry includes its clock, reset, halt, and similar functions. Such circuitry can be designed largely independently of the rest of the system and is needed to perform even the simplest tests on the CPU. Therefore, we will design and test these circuits first.

Page 2 gives the diagram of the control circuitry surrounding the 68000, excluding the interrupt request inputs. The control of HALT* and RESET* is conventional. At power-on, a 555 timer configured as a monostable, U1, generates a single active-high pulse.

Open-collector buffers, U4C and U4D, apply the reset pulse to the 68000's RESET* and HALT* inputs, respectively. A manual reset generator is formed from two cross-coupled NAND gates, U3A and U3B, and applied to the reset lines by a further two open-collector buffers, U4A and U4B. An inverting buffer, U5A, gates the reset pulse from U1 onto the system bus as the active-low POR* (Power On Reset). This signal is used by other modules to clear circuits on power-up.

An LED, D1, is connected to the HALT* pin via a buffer. This LED is fitted to the front panel and confirms the reset operation. It also shows if the CPU has asserted HALT* because of a double bus fault.

The 68000 clock input is provided by an 8 MHz crystal-controlled clock in a DIP package. If desired, a lower speed clock oscillator can be used either for test purposes or to allow using a lower-speed 68000 chip.

The high impedance control circuits shown on page 1 are pulled up to the Vcc by resistors. Although pullup resistors are necessary on BR*, DTACK*, etc., the reader may be surprised to find them on AS*, UDS*, LDS*, and R/W*. They are required here because these pins are driven by tristate outputs in the 68000. When the 68000 relinquishes the bus all tristate lines are floated. To leave the state of these bus lines undefined is unwise, as a spurious bus cycle might possibly be generated in certain circumstances. A better course is to be safe rather than sorry. During the testing phase, some of the pullup resistors were temporary and used only for testing purposes, because they were connected to lines that will later be pulled up or down by totem-pole outputs. They appear so that the circuit can be tested independently of the rest of the system.

Testing the CPU control circuitry is very easy. The power on reset circuit is tested by attaching an oscilloscope probe to test point 1 (TP1), switching on the Vcc power supply, and observing the positive-going pulse. A negative-going pulse should be observed at the CPU's RESET* and HALT* pins. The manual reset pulse generator should force HALT* and RESET* low whenever the reset button is pushed.

An 8 MHz square wave should be observed at the CLK input to the CPU. All inputs pulled up to a logical 1 should be at a logical 1 state.

The next step is to install the 68000 and force the CPU to free-run. As no memory components have yet been fitted, the CPU must be fooled into thinking that it is executing valid bus cycles. To do this, DTACK* is temporarily connected to the AS* output. Whenever the 68000 starts a memory access by asserting AS*, DTACK* is automatically asserted to complete the cycle.

The 68000 is tricky to test in a free-running mode, because it generates an exception if a nonvalid op-code is detected. Should the 68000 then generate a second exception, the resulting bus fault will cause it to halt. Therefore, the 68000 must always see a valid op-code on its data bus. One way of doing this is to pull up (or down) the data bus lines with resistors to Vcc (or ground). Traditionally, CPUs are tested by placing a NOP (no operation) op-code on the data bus. The 68000 NOP code is $4E71 (i.e. %0100 1110 0111 0001). If this code is jammed onto the data bus, the 68000 will also use it for the stack pointer and reset vectors during the exception processing. Sadly, this code will lead to an address error. When the CPU reads the stack pointer from addresses $00000000 and $00000002 at the start of its reset exception processing, it obtains $4E714E71. Unfortunately this value is odd and generates an address exception. We need to use a dummy op-code that is even to allow the CPU to free-run. One suitable opcode is $0000 which corresponds to the instruction ORI.B #0,D0.

When a suitable op-code has been jammed into D00 to D15, the 68000 should free-run and a square wave observed on address pins A01 to A23. The frequency at pin Ai should be one half of that at Ai-1.

Building a 68000 Single Board Computer - Top Level Schematic (schematic page 1)

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

Each IC has a 0.1 uF ceramic bypass capacitor across the Vcc and GND pins. A single 100 uF capacitor provides additional power supply filtering. It requires a +5 volt supply. A switch controls power and a green LED (D2) indicates power on.

The majority of chips are 7400 series LS family TTL devices. There are a few spare gates. Their inputs are grounded as per standard TTL design practice.

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.

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.

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.