uTracer11 - The Message Protocol

GUI and the PDP-11 communicate via a well-defined "Message-protocol"

Formats

Messages are defined as C++ objects, with

• a list of data fields
• a method to print the data to a short text string ("render")
• a method to convert a text string to data field values ("parse")

Message transmission is in text form.
Via serial RS232, every message is terminated with a CR (0x13) or LF (0x10) character.
Over TCP/IP sockets, a message is terminated with a semicolon char ';'.

See sources messages.txt, messages.h and messages.cpp in https://github.com/j-hoppe/uTracer11/tree/main/common

Requests, responses

Typically The GUI sends a "request message", the probe answers with a "response message".

Example: to let the Probe read out /Examine) a UNIBUS address 1234 (wich should be set tu 112233, GUI sends

E 1234

The probe then responds then with a UNIBUS cycle

DATI 1234 112233

The probe can also send "asynchronous" responses (not queried by GUI), if something interesting happens in the PDP-11.
Notably if a UNIBUS cycle was captured, which was generated by the PDP-11 CPU in some micro-step.
Asynchronuous responses are marked with a "!".
For example, if the CPU writes the letter 'A' to its DL11 console, you's see a response of:

DATI 777566 101 !

GUI-less probe operation

 You can operate the M92X2 probe directly by connecting a RS232 serial terminal to the M93X2 serial port. Typically the baudrate is standard 115200. 

You type requests directly into the terminal and see responses. However your input is not echoed back, so ou're working half-blind.

See a sample session. I work on an PDP-11/34 with KY11-LB programmers console, with M93X2 probe. The 11/34 is HALTed. so we can use the UNIBUS. The probe connects to a "putty" terminal via a RS2323 COM port, with 115200 baud.

1.  First I change some memory cell by sending a "DEPOSIT" request to change memory addr 1234 to data 112233.
   I type "D 1234 112233<enter>", but the probe does not echo it back.
2. Then the Probe executes the DEPOSIT by generating a DATO cycle via its UNIBUs interface. It responds with the cycle: "DATO 1234 112233"
3. To verify I examine the same address by sending a  EXAM request.
   I blindly "type E 1234"
4. and the Probe responds properly with "DATI 1234 112233" (yes,  memory cell 1234 is really holding its data)
5. As user input is not echoed back, and there's no mean to "backspace" ill-typed characters, you will make lots of errors.
   The Probe checks its inputs and responds.
   Here I forgot a <space> in "DATO 1234 112233", and the probe responds:
   ERROR Syntax error on D <addr><data>, argC != 2, found "D 123411223344"

***

As another exercise, I finallyI send the character "U"(octal 125) to the PDP-11 serials  port via the KY11-LB programmers console as described here.
No Probe request is sent, but the Probe monitors UNIBUS all time .

1. On the KY11 keypad, press [7] [7] [7] [5] [6] [6] [LAD], the address of the serial card DL11-W transmit buffer.
2. Enter the octal ASCII code of the character to transmit. For an "U", this is [0] [0] [0] [1] [2] [5].
3. Press [DEP]. The "U" is written to the Transmitter Buffer Register via a DATO cycle and appears on an connected console terminal.
4. The Probe captures the DATO and sends an asynchonuos response:
   DATO 777566 125 !

Direct connection to a simulator

Remember: a simulator must expose the "probe" message interface.
In contrast to a physical M93X2 probe, the simulator used a simple TCP/IP socket connection, and messages still are transfered in text form.
The socket interface support not the telnet protocol, but:
a basic telnet client still can send an receive these message strings.

Thats good, as you get a simualotr-diurect-terminal for free. But I have no idea why this works.
And: The simple Windows/Linux standard client support this, put the more highlevel "putty" telnet client refuses to connect.

So just do:

$ ./pdp1134sim 65392 &
$ telnet localhost:65392