In several cases it might be required to provide Amélie with setup or status information, or to have Amélie provide a sort of running commentary on her status.

The problem is, a basic 16-key keypad requires eight I/O lines to decode (4x4), and an LCD has its own I/O requirements which range from 6 lines to 10 or more; not to mention that some LCD panels have unusual voltage and/or timing requirements.

It was considered that a better alternative would be to provide Amélie with a 2400bps serial link. For the cost of only two more ICs (plus a few minor parts), the keyboard and display (which could include real-time graph plotting and/or logging) could be pushed onto a computer (the one you're using now will be fine, thank you!)... or at least, a "dumb terminal".
For the ultimate in portability, it could be possible to control the application within Amélie using a Psion 3a organiser (Acorn Pocketbook II ) connected serially.

The serial port is likely to be implemented using a 6551 ACIA (and a MAX232 serial interface).

Page Three (&0200-&02FF ) is reserved for the serial buffering. It is split into 128 bytes input, 96 bytes output, and 32 bytes for status and internal pointers. The reception of serial data takes place under interrupt, and upon reception a vector is called so the data in the buffer can be serviced. There are three vectors available for serial reception:

The serial interface presented to the external world will be a standard 9-pin D so any decent null-modem cable will allow interfacing. It is possible that Amélie's BIOS will 'sample' DTR to know whether or not a cable (and responsive computer) is connected.

Serial control

A potential enhancement is in the planning for the very first release of the RickBot application code. Instead of handling the control of what to do with the motors and system, it will respond as follows:

• Upon a 'bump', the application code will stop all movement and report the status via serial link. It will then await a command back from serial link instructing how to behave.

The purpose of this is to reduce the entire system to being little more than a "dumb terminal". The complicated drive/control software will be written in OPL and will run an a serial-linked Psion 3a (Acorn PocketBook II) organiser. This will permit the control algorithms to be worked out in a fairly high level sense before a 6502 version is committed to EPROM. It further benefits from the ability to hold source on the organiser, allowing modification and subsequent 'translation' to executable form to be performed in the field as real-life testing progresses.

All status codes from the system are three bytes in length.

As the application code is started, it must send a "ready" sequence to ther serial port to inform the connected machine that all is go. The sequence chosen is ":-)".

Upon a BUMP, three bytes will be sent. The first byte is always "B". 'B' for bump. The next byte will be either "F" or "R" depending on if the front or rear sensor was activated. The final byte will be either "L" or "R" depending on whether the bump was also to the left or the right. If left/right is not valid, then the third byte will be an "X". For invalid input, like front/rear or left/right both being triggered, then "?" will be retured in the appropriate byte(s).
Therefore: "BFL" means bump front left, "BRX" means bump rear exclusive (rear straight-on), and "B??" means bump with invalid responses.

Upon a LINETRACK event, the bytes "LT" will be sent, followed by either "L" or "R" depending on whether the tracking miss was to the left or to the right.

Upon a panic button press, the standard panic sequence will be initiated, however "!!P" will be sent via serial to inform the connected machine of this situation. Depending on BIOS, the system will either be frozen or will enter the debugger.

If the watchdog is triggered, the output "!!W" is sent serially, and then the system is either frozen or debugger entered.

If the connected machine sends a control signal, then the system will respond with the sequence ">**" where the '**' is an echo of the command sent.

The complete list is:

The following commands may be sent (all are two bytes in length):

LF	Left motor forwards
LB	Left motor backwards
LS	Left motor stop
LH	Left motor hold (if implemented, else will just stop)
L1	Left motor slow, speed 1 (if implemented)
L2	Left motor medium, speed 2 (if implemented)
L3	Left motor fast, speed 3 (if implemented)
RF	Right motor forwards
RB	Right motor backwards
RS	Right motor stop
RH	Right motor hold (if implemented, else will just stop)
R1	Right motor slow, speed 1 (if implemented)
R2	Right motor medium, speed 2 (if implemented
R3	Right motor fast, speed 3 (if implemented)
BF	Both motors forwards
BB	Both motors backwards
BS	Both motors stop
BH	Both motors hold (if implemented, else will just stop)
B1	Both motors slow, speed 1 (if implemented)
B2	Both motors medium, speed 2 (if implemented)
B3	Both motors fast, speed 3 (if implemented)
10	LED #1 (green) off
11	LED #1 (green) on
12	LED #1 (green) flash 1/2 sec on, 1/2 sec off
20	LED #2 (yellow 1) off
21	LED #2 (yellow 1) on
22	LED #2 (yellow 1) flash 1/2 sec on, 1/2 sec off
30	LED #3 (yellow 2) off
31	LED #3 (yellow 2) on
32	LED #3 (yellow 2) flash 1/2 sec on, 1/2 sec off
40	LED #4 (red) off
41	LED #4 (red) on
42	LED #4 (red) flash 1/2 sec on, 1/2 sec off
XX	Lock down, freeze status. Behave as if panic switch pressed.
??	Request system to repeat previous status code. In this case, the request command is not echoed. In other words, if the previous status code was "BFL" then sending this command will cause the reply "BFL" and not ">??BFL" as might be expected.