Add some hex version of binary, add some comments

[RussellSenior]

From my own reverse engineering, using a Saleae logic analyzer clone with Sigrok's Pulseview and protocol decoding and observing the commands appearing on the bus in response to keyboard presses on a WheelWriter 5.

Observations:

• The protocol is a 9-bit serial, apparently the so-called "mode 2" referred to in the Intel 8051 documentation: http://datasheets.chipdb.org/Intel/MCS51/MANUALS/27238302.PDF
  • The 9-bit bytes with the most-significant bit set indicate that the remaining bits are a processor address intended to listen to the commands that follow, so the many 0x121 are just spamming an announcement that the microprocessor on the bus that thinks of itself as 0x21 should pay attention, and that other microprocessors can sleep (only looking for the most-significant bit to see if they should check the address again). One can reasonably deduce that 0x21 is the address of the motor controller board. All other bytes, where the 9th bit is not set, are commands or arguments.
  • horizontal motion is typically measured in microsteps, 1/120th of an inch;
  • carriage motion is most often commanded relative to the current position, so it is necessary for the programming issuing commands to maintain a notion of where the carriage is located for carriage returns and to prevent venturing off the right end;
  • 0x03 takes two arguments, the first byte being the absolute rotation of the daisy wheel (between 0 and 0x60, inclusive) to strike, and the second byte being the number of microsteps to move the carriage to the right afterwards;
  • 0x04 seems to be similar to 0x03, except that it causes the ribbon positioning motor to rotate the rubout tape into position to be struck instead of the normal ribbon;
  • 0x05 command is a platen positioning command, the most significant bit of the single byte argument is a direction bit (1 for up, 0 for down), the rest indicate the magnitude of motion;
  • 0x06 command is a carriage positioning command, taking two byte arguments: the most significant bit of the first byte indicates the direction (1 to move the carriage right, 0 to move the carriage to the left), the remaining bits indicate the number of microsteps (1/120th of an inch) to move horizontally;
  • 0x09 command followed by the single byte argument 0x04 seems to turn on underlining;
  • 0x09 command followed by the single byte argument 0x00 seems to turn off underlining;
  • 0x0B commands seem to not result in any actions, maybe a "rest" or "request status" command (we sometimes see non-zero replies to it);
  • 0x0C commands appear after a rubout operation;
  • 0x0D commands appear in connection with:
  • 0x05 during rubout;
  • 0x04 during backspace;
  • 0x07 during carriage return;
  • 0x0a during tab resolution;
  • 0x12 during tab set;
  • 0x0E commands appear in association with "code" related key presses;

[RussellSenior]

I measured the vertical resolution (e.g. associated with the 0x05 commands) as 1/96th of an inch. A carriage return with a Courier 15 printwheel installed emitted an argument of 0x0c (decimal 12), which equates to 8 lines per inch. I also discovered that after an 0x03 command (i.e. printing/advancing), another addressing byte (0x121) was needed before a 0x05 (or probably any other command) was recognized or acknowledged.