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.
Sunday, January 15, 2017
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.
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.
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.
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:
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.
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:
- Display and modification of memory as byte, word, longwords, strings, characters, or disassembled instructions.
- Display and modification of registers.
- Memory fill, move, search, and test functions.
- Number conversion between decimal and hexadecimal.
- The ability to set and clear breakpoints.
- Ability to run programs with breakpoints or line by line tracing.
- Output to either of two serial ports, parallel printer port, or cassette tape.
- Loading and saving of memory in S record format.
- 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
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.
Thursday, January 5, 2017
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.
Tuesday, January 3, 2017
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.
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.
Subscribe to:
Posts (Atom)