Alto-1822 Interface, Updated Design
Page Numbers: Yes X: 527 Y: 10.5"
ToTaft, Boggs, Shoch,DateFebruary 7, 1978
FromLarry StewartLocationPalo Alto
New, Up-to-date stuff
Filed on: [Maxc1]<LStewart>AInewDesign.press
As a result of various conversations and considerable soul searching, I have made substantial changes (again) to the Alto-1822 interface hardware and microcode. This memo includes the newest iteration of the emulator level interface, the microcode, and the hardware. It does not include a description of the PROM contents. In terms of complexity, the microcode uses one S register and is 47 words long. The hardware is around 45 or 46 packages.
Major differences (and homespun philosophy)
Rather than use a 16-way branch to set up the priority of the various wakeups, the priority encoding is now done in hardware. On a wakeup, the microcode executes a 4-way branch to routines for SIO-set control, SIO-start receiver, Input data wakeup, and Output data wakeup. Oddly enough, this change simplified both hardware and microcode.
Packet Throwaway Mode:
By executing an SIO-set control function, the user may set the receiver hardware into "Packet Throwaway Mode". On each SIO-start receiver call (until the throwaway mode is cleared), the microcode will read in a packet (i.e. until the next Last Imp Bit) and throw it away. Although it is not used, the input buffer must have some space in it. This capability cost one microinstruction and one IC package.
Read Status - Set Control function:
In order to take advantage of available MSI, the style of the command word was changed. The key difference is that only one thing at a time may be set or cleared (i.e. the commands are encoded now).
Zero buffer length:
It was suggested to me that the initial tests for zero buffer length were a waste of microinstructions. Here’s what happened: On output, there is no longer any initialization microcode - the SIO reaches down into the output finite state machine and makes it think it was running already. The FSM then requests a normal output data wakeup to get the first word. Thus if the buffer size is zero, on that first wakeup the microcode will conclude that transmission is done and return normal end status - without having done anything. On input, while it is true that a zero length buffer probably represents a programming error, I included the test anyway. If the receiver were actually started with a zero size buffer, the condition would not be noticed until the first input data wakeup. At that time, the microcode would have no choice but to throw away the input word and return a buffer overflow error - the entire packet would be messed up. As things stand, you can request input into a zero length buffer, get an error status back, and restart the operation with a non-zero buffer without losing data.
In addition, there are a variety of minor changes designed to simplify the hardware and microcode. From a user’s point of view there have been subtle changes to the layout of the emulator interface. Elsewhere, things are more incomprehensible than before, but smaller.
Emulator - Task interface
An emulator program can wake up the IMP task by executing an SIO instruction with either or both of AC0 bits 5 and 6 set. Possible functions are start receiver, start transmitter, and read status/set control register. AC1 is must point to a command block during the execution of the Read Status / Set Control Register SIO. The task saves the control block pointer in an S register for later use. This means that a read status call must be made before trying to do a data transfer.
In order to hold the use of S registers to a minimum, both input and output buffer pointers are kept in main memory. This means that input/output operations require three main memory cycles per word. The single S register contains a pointer to the 12 word control block. The single control block contains entries for input, output, and control functions.
Control Block Structure
The command block must be on an even word (for AI compatibility).
inputPointer/next word to be used
inputBufferEnd/first word not in buffer
outputPointer/next word to be used
outputBufferEnd/first word not in buffer
ControlPost/control post location
controlIntBits/control interrupt channels
InputPost/input post location
inputIntBits/input interrupt channels
OutputPost/output post location
outputIntBits/output interrupt channels
The receiver will collect a packet from the IMP. The final buffer location used ( +1 ) is returned in inputPointer. Returns error if the buffer size is zero on entry, or if the buffer overflowed.
The transmitter will send a packet (buffer) to the IMP. If the buffer length is zero, no bits will be sent, and the returned status will indicate sucessful completion.
Read Status / Set Control Register
This command allows an emulator program to observe the interface without disturbing it. It is also used to tell the microcode where the command block is. The command word is used to set and clear some control flip-flops in the hardware.
LDAAC1,CmdBlock //(pointer to)
On completion of a command, the microcode status occupies the left byte of the Post location and the hardware status occupies the right byte.
Possible microcode status bytes:
00000010-buffer overflow (input only)
00000011-input buffer length was zero on entry
Hardware status bits:
unusedbit5; //These bits come back as 1’s
The command word is used to set and clear some control flipflops in the hardware. Except for SetLastWord, these functions are never used by the microcode.
Possible command words:
1hardware master reset
2set last word - causes Last Host Bit to appear eventually
(intended for use by microcode only)
3try clearing IMP Was Down flop
(will not work if the IMP is still down)
4turn on test mode - hardware loop back
(beware: this mode holds the Host ready line off)
5turn off test mode
6turn on Host Ready relay
7turn off Host Ready relay
10turn on packet throwaway mode
20turn off packet throwaway mode
A copy of the newest SIL drawings is appended to this memo. I include no detailed explanation of how it is supposed to work. See the companion memo which describes the PROM contents and look at BBN 1822.
A copy of the newest microcode is attached. The code uses one S register. I include here a table of timing information. A ’+’ indicates a TASK.
Emulator control/status call15
Emulator input request17
(Buffer length zero)
Emulator input request12
(Buffer length non-zero)
Emulator output request0
Input wakeup(Buffer Overflow)20
Input wakeup(Last word)18+10(wierd kludge)
Input wakeup(Normal throwaway)13
Input wakeup(Last throwaway)13+10
Output wakeup(Last word)18
Output wakeup(Normal end)19
; Alto 1822 Interface microcode
; Larry Stewart 2/6/78
; 2-way branches using NEXT9
; 2-way branch using NEXT7 (Caused by IREAD)
; 2-way branch using NEXT7 (Caused by IPTMOD)
; 4-way branch using NEXT6,NEXT7 (Caused by IBRNCH)
; Task Specific Function Definitions
$IREAD $ ; F1-12Input data
$IWRITE$ ; F1-11Output data
$IOCLR $ ; F1-9Clear hardware output wakeup
$ISWAKC$ ; F1-10Clear SIO generated wakeup
$IIENBL$ ; F2-10Start read (turn on RFNIB)
$IBRNCH$ ; F2-114-way branch on wakeup
$IPOSTF$ ; F1-8Post (gate status to bus)
$ISETCS$ ; F2-9Set control functions from bus
$IPTMOD$ ; F2-82-way branch on throwaway mode
;R (S) registers NOTE: WHAT REGISTER?
$ICBPTR$R1;Control Block Pointer
;$MTEMP $R25Temporary storage
;$AC1 $R2Emulator register
;$NWW $R4Interrupt system reg
; Task constants
$ISOVF $1377;buffer overflow (input only)
$ISIBLZ$1777;block length zero (input only)
;Main loop. Task waits here when not processing something.
;IBRNCH gates two bits onto NEXT6 and NEXT7
; 00 - Set Control 01 - Start input
; 10 - Input data wakup 10 - Output data wakeup
IMLOOP:T← ICBPTR,IBRNCH;test wakeup conditions
;Read status and set control register
;ISWAKC clears a wakeup caused by an SIO instruction
;ISETCS loads hardware control flops from the bus
ICTST:MAR← L← AC1;Start fetch of args
ICBPTR← L;Save ctl block pointer
T← 6,ISWAKC;post location offset
ISETCS← MD;Control done
INEND:L← ISDON,:IPOST;Set control flops
;Common Post routine
; Expects offset of post location in T
;and task status in L,M
;IPOSTF gates hardware status bits to the bus
IPOST:MAR← ICBPTR+T;Start double reference
MD← M,IPOSTF;Bus AND hardware status
L← MD OR T,TASK;NWW OR interrupt bits
;IIENBL enables the hardware to receive a 16 bit word (turns it on)
T← MD;read data pointer
IIBLOK:L← NWW,IIENBL,TASK,:INXT;length ok,start reader
;Input Main loop
;IPTMOD gates the state of the Throwaway mode flop to NEXT7
; The branch is taken if the flop was set (by an ISETCS)
IIDATA:MAR← L← 2+T;Start fetch
MTEMP← L,IPTMOD;save cb ptr,test mode
T← MD;get pointer [IIACPT,IIDISC]
IIACPT:L← MD-T;past end of buffer?
MAR← T,SH=0;start data fetch
;IREAD gates the receiver shift register to the bus
; and the PAD flop to NEXT7
; If the branch is taken (which happens when the last word of
; a packet is read), the wakeup will not be cleared, otherwise
; the wakeup will be cleared
IIDMOR:MD← IREAD;Read and branch on last word.
;Except on the last word, this
;clears the wakeup
IDCON:MD← M,:IMLOOP;update ptr,restart
IIDLST:TASK;this TASK only works
;because the hardware doesn’t really clear the
;wakeup until the next IREAD in this case
MD← M;update pointer
IIDPST:SINK← IREAD;clear wakeup (again)
IIDISC:L← T← IREAD,:IICLNU;throwaway word,branch if last
IIDFUL:L← ISIOVF,:IIDPST;overflow status
;Main output loop
IODATA:MAR← L← 4+T;start pointer fetch
MTEMP← L;save cb ptr
T← MD;get pointer
L← MD-T;past end of buffer?
MAR← T,SH=0;start data fetch
;IWRITE loads the output shift register from the bus,
; clears the (hardware generated) wakeup if there was one,
; and starts the output hardware
IODMOR:IWRITE← MD,SH=0;send data,last?
MAR← MTEMP,:IONLST;start update [IONLST,IOLST]
IOLST:SINK← 1,ISETCS;set last word
;IOCLR resets the output hardware. This is how you clear the
; last wakeup without restarting the output hardware
IODEND:T← 12,IOCLR,:INEND;offset of post loc