Thursday, 25 April 2013

Serial communications and the start of a "monitor"

"Monitors" were pouplar tools for debugging programs, along with other useful facilities. Some were also powerfull enough to be considered development environments in there own right. They provided the user with the ability to read memory content, modify memory contents and registers, execute external code, set breakpoints etc. Some had built in assemblers and dissasemblers. I will be writing my own, without external reference except to old books and datasheets. This will form the building blocks of the computer's software and allow me to experiment with talking to different hardware devices, as well as improve my knowledge of the 6809.
The input and output to the monitor is on RS232 via the previously described 6850 UART (PDF), so the first thing to do is get that working. No graphical display for my computer just yet!

Here I found the first big problem: baud rate generation. The 6850 is extremely basic in this regard, and lacks a proper baud rate generator. Instead it can only be configured to use the E clock asis, or divide it by 16 or divide it by 64. Since my E clock is at a quater of the crystal frequency (at 4 MHz) this leaves me with no useful baud rates: 1000000, 62500 or 15625. None of these are even close to standard rates.
There are two solutions:
  1. Use a dedicated baud rate generator circuit with its own crystal.
  2. Switch the main crystal to something more useful for baud rate generation.
Option 1 is ideal but requires extra circuitry and I have very little room as it is. As it happens a 3.6864 MHz crystal is available, which when divided down by 4 and then 16 yields a nice and standard 57600 baud rate. So I duly ordered several of these. Actually I meant to order 3 but ended up with 12 because I didn't notice that they were being sold in batches of 4!

Of course a downside of this change is that my computer is now a tiny bit slower then it was with the 4 MHz crystal. Oh well.

In addition to the UART the circuit also needs a level shifter. This is because RS233 generally uses -12V and +12V signalling levels, vs 0V and 5V used in TTL. A MAX232 IC fits the bill nicely, and only needs four electrolitic capacitors to form a complete circuit. Whilst I could have used the same USB serial port converter as on my EEPROM programmer, I feel that this is not in the spirit of the 80s tech the rest of my computer uses.

Programming the UART is fairly simple. It has four 8 bit registers:
  • Read data to receive
  • Write data to send 
  • Read status
  • Write configuration
A single Register Select pin is used in combination with the R/W pin to select which register to manipulate. Register Select is connected to A0. With the same address decoding as used on the LED output circuit, the UART is therefore at addresses:

$8000 - send and receive data
$8001 - status and configuration

The 6850 has three Chip Select lines, to aid in address decoding. But since I already have an address decoder, only the active low CS2 line is required.

The only other connections of note are the E signal and rx/tx clocking inputs. All 3 are connect to the MPU E line. (If I had an external baud rate generator it would connect to the rx/tx pins instead of using E.)

That pretty much describes the circuit:

As usual, a postscript version can be downloaded here.

Software wise, the first job is to test my understanding of the UART by running some code.  A way to do this is to write a program which can both output text to the port, and read user input. To keep things simple, polling instead of interrupts is to be used.

The 6850 is configured through the configuration register. The UART must first be reset, then the comms parameters configured.  In my case I need a divisor of 16 on the clock, and 8 databits without parity. Also interrupts should be disabled.

Sending data is as simple as polling for "transmit empty" and when it is writing a byte. Receiving is similar; poll for "receive full" and then read a byte. Subroutines for sending and receiving strings (or any other data) can be built up out of these basic blocks.

Thus the serialtest.a program was written. It will output a greeting, then wait for some input before echoing the input back to the user, before looping back to waiting for another string. It is fairly crude and does not support backspace or any input editing, but it works well. In addition, because serial terminal software does not generally echo keystrokes directly, each byte is sent back to the terminal as it us received. Thus the user can see what they are typing.

The code is on github, for anyone curious.

And here is a picture of breadboard, along with a screenshot of the program in "action". The terminal software used was minicom, running on ny linux box, which in turn was accessed over SSH on my Mac.

I have "bodged" serial input into the computer via the breadboard by removing one of the plugs from a null modem cable and soldering on three PCB pins. This is the grey lead coming onto the board at the bottom left.

The next task, which I've started, is to turn the setialtest.a program into a monitor. I doubt I will ever write an assembler, but for debugging code cross-assembled on my linux machine it should prove invaluable. One other use I plan to make of the monitor is to make the EEPROM programmable from the 6809 directly. Once this is done I can try new programs without having to move the EEPROM chip from the 6809 breadboard to my homemade programmer and back again...

[This blog post had to be rewritten due to the Android "blogger" software consuming the finished posting.  Utterly rubbish "modern" software which I have now removed from my phone. Thank you Google!]

No comments:

Post a Comment