Using an Arduino as an ACIA with the CDP1802

Purpose:

A very easy and inexpensive way to add an Asynchronous Communications Interface Adapter (ACIA) to receive and transmit data for serial data communications to any microprocessor system (in this case, my New ELF II CDP1802 based system).
The Arduino is programmed to function as the ACIA device.


The schematic in PDF format can be downloaded here - CDP1802_Arduino_ACIA.pdf

The sketch for the Arduino can be downloaded here - ACIAfor1802.pdf


Operation and Programming:

Programming is pretty straight forward.
Data is simply written to or read from the Arduino via two 74373 octal latches.
To send a byte (serial output), you just use the CDP1802 Op Code Instruction 5N D-->M(R(N)).
To receive a byte (serial input), you just use the CDP1802 Op Code Instruction 0N M(R(N))-->D;FOR N NOT 0. The byte is retrieved using the interrupt mechanism of the CDP1802 CPU.
When the Arduino receives a byte from the serial program (i.e.HyperTerminal), it latches the byte (pin A5) in the "Input byte from Arduino" 74373, initiates the 1802 INT (pin A2) then waits until the 1802 acknowledges it has 'read' the byte (Arduino External interrupt 1 - pin 3).
When the 1802 sends a byte, it latches the byte in the "Output byte to Arduino" 74373, initiates the Arduino External interrupt 0 (pin 2), the Arduino then 'reads' the byte (pin A3) then sends it off to the serial program.

The following test program will compile with my Special 1802 Assembler which can be downloaded from my main web page:
Programming Notes:
The maximum speed that can be set in HyperTerminal is 921600 bps. Therefore the test program and the Arduino program (sketch) are configured to run at that speed.
With my newELFII running at 2 MHz, I needed to put a C4 NOP instruction Op Code after the 5N instruction to slow it down a bit to allow the Arduino to process the byte and
send it out to the serial program (HyperTerminal). If the baud rate of the Arduino is to be reduced lower than 921600, the delay has to be increased; thus the D4 #DELAY subroutine I have included (currently commented out with the semicolon). You will have to find the proper value for the delay to achieve the best possible speed. If the delay is too short, the output will be garbled.
The following are snap shots of the test program: