[LispM] Xerox 1186 "D-Machine"
Kevin Schoedel
schoedel@kw.igs.net
Wed, 14 Nov 2001 00:58:39 -0500
>I'm trying to find more information and/or sources for spare parts in order
>to
>resurrect a Xerox "AI workstation", also called a Daybreak or 1186.
First, Al Kossow <http://www.spies.com/~aek/> has some scanned hardware
documentation under <http://www.spies.com/~aek/dbreak/>. I seem to recall,
however, that some of the 1186 documentation there is incorrect because it
was copied without change from the 1080 documentation.
Second, the following message from the ClassicCmp mailing list explains the
keyboard interface and encoding.
>From: ard@p850ug1.demon.co.uk (Tony Duell)
>Subject: Re: Xerox DayBreak
>To: classiccmp@classiccmp.org
>Date: Sat, 1 Jul 2000 00:34:55 +2500 (BST)
>
>>
>> Hi. I have a Xerox DayBreak workstation lying on a corner back
>> home and I'd really much liked to do something with it. I have already
>> posted emails to this list about this subject, but since so much time
>> passed since then I resolved to re-post to see I get something
>> new. The issues I'd like to solve are:
>
>I've got a Daybreak sitting a couple of metres from me... I also must get
>round to getting it working.
>
>
>>
>> 1. decent interface of the display output to some monitor -- I
>> worked on a small circuit to convert the ECL levels and separate syncs
>> into a composite video output, for a mono monitor, using discrete
>> components, but the image was sort of fuzzy. Are there any ideas on
>> doing these the right way (if any)?
>
>I'd probably use a 10125 (ECL-TTL translator) to turn the signals to TTL,
>then feed the syncs and video (the latter suitably reduced by a potential
>divider) into a multisync monitor and hope it could lock to it. I don't
>think many composite monitors are going to work at the sync rates of the
>D'break, are they?
>
>
>> 2. interfacing the keyboard/mouse connector to a PC's serial
>> port -- I managed to build a decent interface for this (using a
>> MAX232), but now the problem is protocol: anyone knows the protocol
>> for sending key presses/releases signals? I believe they have
>> something from 1 to 3 bytes.
>
>Kevin Schoedel (?spell) lent me a Daybreak keyboard for an afternoon some
>months back. During that afternoon, I pulled it to bits, figured out most
>of the hardware details, powered it up from my bench supply and grabbed
>the output waveforms. Yes, Kevin did know I was doing this :-)
>
>The keyboard pinout, both for the DE9 on the IOP card and the DIN socket
>on the monitor base is :
>
>1 Data
>2 Data/
>3 Ground
>4 +5V
>5 Keyboard Reset/
>
>(The other pins on the DE9 are to drive a speaker and I've not got
>details of that to hand).
>
>In the keyboard, the data lines are driven by one section of a 26LS31
>differential driver. The E/ input is tied to +5V, the E input is linked
>to Keyboard Reset/ from the interface connector (remember the 26LS31 has
>the enables ORed not ANDed, so that if at least one is asserted, the chip
>is enabled). The Reset Keyboard/ signal also goes through a few gates to
>the reset pin of the 8048 in the keyboard. Serial data output from th
>8048 is inverted and then fed to the input of the 26LS31 section I've
>just mentioned.
>
>I have a lot more hardware details of the keyboard, but they're probably
>not useful to you. The above will let you link a PC serial port to the
>keyboard with a couple of chips (it's _essential_ to disable the keyboard
>outputs when the reset line is low, since during that time the keyboard
>data lines are driving by part of the 75176 chip on the IOP. This is used
>as a self-test of the keyboard interface).
>
>The data is sent at 9600 baud, no parity, 8 data bits, 1 stop bit. Each
>key (and mouse button) sends a code with the high bit clear when pressed
>and the same code with the high bit set when released. The codes sent
>are:
>
># name keycode
># code shown is key down code. Add 80h for key up code.
># Mouse buttons :
>left 01
>middle 03
>right 02
># function keys
>F1 63
>F2 64
>F3 65
>F4 66
>F5 67
>F6 68
>F7 69
>F8 6A
>F9 6B
>F10 6C
># top row
>Stop 54
>Del 55
>Esc 04
>1! 05
>2@ 06
>3# 07
>4$ 08
>5% 09
>6^ 0A
>7& 0B
>8* 0C
>9( 0D
>0) 0E
>-_ 0F
>=+ 10
>Bspc 11
># Number pad top row
>+ 40
>Numlk 41
>Sclllk 42
>Break 43
># 2nd row
>Undo 56
>Again 57
>Tab 12
>Q 13
>W 14
>E 15
>R 16
>T 17
>Y 18
>U 19
>I 1A
>O 1B
>P 1C
>[{ 1D
>]} 1E
>Ret 1F
># Number Pad 2nd row
>DoIt 44
>N7 45
>N8 46
>N9 47
># 3rd row
>Find 58
>Copy 59
>Lock 6D
>A 21
>S 22
>D 23
>F 24
>G 25
>H 26
>J 27
>K 28
>L 29
>;: 2A
>'" 2B
>`~ 2C
># Number pad 3rd row
>Next 48
>N4 49
>n5 4A
>N6 4B
># 4th row
>Same 5B
>Move 5C
>LShft 2D
>Z 2F
>X 30
>C 31
>V 32
>B 33
>N 34
>M 35
>,< 36
>.> 37
>/? 38
>RShft 39
>#Number row
>N1 4D
>N2 4E
>N3 4F
># Bottom row
>Help 5D
>Edit 5E
>Meta 3A
>Space 3D
>Expand 3F
># Number pad bottom row
>N0 50
>|. 52
>\, 53
>
>When the keyboard is idle, it repeatedly sends 3-byte packets. The first
>byte is FF. The other 2 bytes seem to be the mouse movement data (X and
>then Y) in 2's complement binary, but I've not confirmed this.
>
>But the above should be a start to building a keyboard (something that I
>have to do sometime as well!).
>
>
>>
>> I have a set of PDF of scanned Xerox manuals (TechRef and IOP)
>> including some schematics (awesome work! congrats for the one who
>
>If that's the IOP manual I think it is, be careful!. It's preliminary
>schematics, and they're not very similar to the actual IOP in the machine!
>
>-tony
--
Kevin Schoedel
schoedel@kw.igs.net