diff --git a/Makefile b/Makefile index 834260ee..7edcd12c 100644 --- a/Makefile +++ b/Makefile @@ -31,7 +31,7 @@ DOC = info _info_ sysdoc sysnet syshst kshack _teco_ emacs emacs1 c kcc \ chprog sail draw wl pc tj6 share _glpr_ _xgpr_ inquir mudman system \ xfont maxout ucode moon acount alan channa fonts games graphs humor \ kldcp libdoc lisp _mail_ midas quux scheme manual wp chess ms macdoc \ - aplogo _klfe_ pdp11 chsncp cbf rug bawden llogo eak clib teach + aplogo _klfe_ pdp11 chsncp cbf rug bawden llogo eak clib teach pcnet BIN = sys2 emacs _teco_ lisp liblsp alan inquir sail comlap c decsys \ graphs draw datdrw fonts fonts1 fonts2 games macsym maint imlac \ _www_ hqm gt40 llogo bawden diff --git a/doc/_info_/cgol.recent b/doc/_info_/cgol.recent new file mode 100644 index 00000000..40876a5c --- /dev/null +++ b/doc/_info_/cgol.recent @@ -0,0 +1,51 @@ +New features in CGOL 74. Please report any bugs to MJF;. + +[1] The lexical syntax has been cleaned up a little. An altmode + may be included in a character string or in a comment by + preceeding it with the escape character "?". An unprotected + altmode now causes an error. To put a quote character (") + into a character string, it must be doubled. + +[2] CGOLREAD now takes an argument which is treated just like + the argument to READ. Namely, if CGOLREAD encounters an end-of-file + as the first thing upon being called, the argument is returned; + otherwise it is assumed that there follows a complete CGOL + expression followed by the input terminator (an altmode or dollar). + If not, an error is reported. If the argument is NIL, then + initial end-of-files are passed over. Sometime in the future, + the argument may become optional, but for now it is required. + +[3] The necessary changes for compatibility with [2] have been made + in MAKLISP. + +[4] A new bracketing operator "OCT" allows the reading of a + portion of CGOL text with IBASE=8 so numbers are read in octal + (unless followed by a dot). The following text MUST be + enclosed in parentheses. E.g. oct(12) $ prints 10., and + oct(12+14) prints 22. + +[5] Tokens may now be composed of multiple characters. NEWTOK "foo" defines + the string foo to be a token. It may then be used like any + other token, e.g. appear in infix, prefix, and define statements, + be used as a variable, etc. There are two points of caution. + (i) The only characters which may appear as the FIRST character + of such a token are special characters other than quote ("), + percent (%), exclamation (!), dollar, altmode, and question mark (?). + (ii) Every prefix of a multiple character token also becomes + a token. Thus, defining NEWTOK "*-*" causes 2*-3 to parse + incorrectly. Of course, 2* -3 will still work all right. + +[6] New bit-vector operators have been defined using the multiple + character token feature described above. They are: + .N. - complement; + .A. - logical and; + .V. - logical or; + .X. - exclusive or; + .^. - left shift. + +[7] The current version of CGOL may be fasloaded from COM: CGOL FASL. + Two other ways of invoking it are: (i) Type + (CGOL) or (CGOLREAD) at LISP (they have autoload + properties); or (ii) Type :L CGOL; when you start + your LISP. + \ No newline at end of file diff --git a/doc/aplogo/-read-.-this- b/doc/aplogo/-read-.-this- new file mode 100644 index 00000000..f13ff500 --- /dev/null +++ b/doc/aplogo/-read-.-this- @@ -0,0 +1,3 @@ +This file directory is used for Apple Logo development. +It is maintained by Stephen Hain, Patrick Sobalvarro, +Leigh Klotz, John Palevich, and Hal Abelson. diff --git a/doc/info/tip.2 b/doc/info/tip.2 new file mode 100644 index 00000000..79860ecf --- /dev/null +++ b/doc/info/tip.2 @@ -0,0 +1,404 @@ + +File: TIP, Node: Top, Up: (DIR), Next: Calling + +The TIP is the wonderful machine that lets you connect to any host +on the ARPA net if you have access to a telephone. It is the usual +way for ordinary people to get on the ITS machines. + +This info tree can be viewed in two ways: 1) by using the M and D +commands to get to the particular topic(s) that interest you, or +2) by using N to visit all the nodes in sequence. Option 2 will +skip information on 2741's, unless you use M at Calling. From there +on N will give you everything. + +* Menu: + +* Calling:: Calling up the TIP, telling it your speed +* 2741:: Special speed recognition chars for the 2741 +* Commands:: Useful commands, like how to connect to your host +* Hosts:: Some hosts and their numbers +* NIC:: The Network Information Center +* Manual: (MC: .INFO.; TIP MANUAL)* + The official word on the TIP + +File: TIP, Node: Calling, Previous: Top, Up: Top, Next: Commands + +The first step in establishing connection with the TIP is to call it up. +The telephone numbers of the MIT TIP are available for legitimate users +from Janet Schoof (617-253-1458 or Jan@MIT-XX). + +Once you have gotten a connection, you must type a "hunt character" +to tell the TIP your terminal speed and character code: + + ASCII 110, 150, 300 baud E + ASCII 110 trans / 1200 rcv D + ASCII 1200 doesn't need any + 2741 see menu topic "2741" + +Once you have typed your hunt character, the tip will respond with +its name and your port number. (If you are ASCII 1200 baud, it will not +give any response.) If you get nothing (except 1200 baud) or garbage, +hang up and try again. + +* Menu: + +* 2741:: Hunt characters for the 2741 + +File: TIP, Node: 2741, Previous: Calling, Up: Calling, Next: Commands + +Using 2741's on the TIP is complicated by their peculiar communication +protocol and nonstandard character set. The following list gives the +proper hunt character for various typeballs. (The number is printed +on the top of the typeball. If you can't find it, try all of them until +you get something reasonable. Try "f" first.) Typing N from this node +goes on to the Commands node. + +2741 PTTC Terminals type: + +6 for model 938, 939, 961, 962, or 997 +o for model 942 or 943 +w for model 947 or 948 +f for model 963, 996, or 998 + +2741 Correspondence Terminals type: +(Type elements marked with * can be customized for you. Contact your +local IBM office for information.) + +NUMBER NAME HUNT CHARACTER +001 Scribe 4 +005 Letter Gothic 4 +006 Manifold 72 j +007 Elite 72 * 4 +008 Pica 72 * 4 +010 Manifold 72 j +012 Prestige Elite * 4 +014 Light Italic j +015 Courier 72 * 4 +019 Manifold 72 j +020 Dual Gothic 4 +021 Dual Gothic o +025 Scribe o +026 Elite 72 * o +027 Pica 72 * o +028 Manifold 72 o +029 Courier 72 * o +030 Adjutant 4 +031 Adjutant o +032 Light Italic o +033 Prestige Elite * o +034 Script o +035 Delegate o +036 Advocate o +039 Letter Gothic o +043 ASCII l +050 Advocate 4 +053 Artisan 12-72 4 +055 Artisan 12-72 o +059 Orator j +060 Orator o +067 Courier 12 4 +068 Courier 12 o +070 Delegate 4 +085 Courier 72 4 +086 Courier 12 Italic o +090 Script j +123 Prestige Pica o +129 Adjutant o +130 Advocate o +131 Artisan 12-72 o +132 Courier o +133 Courier 12 Italic o +134 Courier 72 o +135 Delegate o +136 Dual Gothic o +137 Elite 72 o +138 Letter Gothic o +139 Light Italic o +140 Manifold 72 o +141 Orator o +142 Pica 72 o +143 Prestige Elite 72 o +144 Scribe o +145 Script o +154 ASCII l +158 Bookface Academic 72 o +161 Large Elite 72 o + +File: TIP, Node: Commands, Previous: Calling, Up: Top, Next: Hosts + +Once you have extablished your connection with the TIP, you must tell +the TIP to connect you to the proper host. Once your host connection +is established, you can mostly ignore the TIP. + +TIP commands begin with the "interrupt character". Initially, it is "@", +but you can change it with the command @I (see below). Any time you type +the interrupt character, you begin a TIP command. The way you send a copy +of your interrupt character to the host is to type it twice. (This leaves +two or three (if the host echos also) copies of the interrupt character +on your output.) Here we will assume that the interrupt character is "@". + +The first thing to do is to tell the TIP the amount of padding that your +terminal needs. Initially the TIP puts enough in to satisfy any terminal, +so you can speed things up quite a bit if you tell it how much you really +need. The commands are: + +(In all TIP commands, spaces are important but case is not.) + +@D C x x = E Extra (for slow terminals, like TI Silent 700's) + O ODEC line printers + A ASCII (no padding, scopes and LA36's) + 3 TTY 37's (which require special parity handling) + +Once you have the padding corrected, you can then adjust the echo: + +@E x x = R Remote (the TIP doesn't echo, the host does) + A All (the TIP echos everything) + +Note that this doesn't apply to command characters, the TIP always echos +them. + +The final important commands are: + +@O n n = host number (octal) +@C + +@O (attempts to) open a connection to the specified host. (See Hosts for +the host numbers.) @C disconnects from the host. If you cannot connect +to the host because it is down, the TIP will tell you. Also, if it seems +to be taking forever to connect to the host, use @C to close the attempt +and try something else. + +To change your interrupt character, give the command: + +@I n n = DECIMAL ASCII code of the character to be the + interrupt character (i.e., 96 means "`") + +File: TIP, Node: Hosts, Previous: Commands, Up: Top, Next: NIC + +This node lists various host numbers on the ARPA net. For a complete +list, inquire at the NIC (see next node). + +Address Hostname Interface->Computer (System) +------------------------------------------------------------------- + 6 0/6 MIT-MULTICS H-6180 (MULTICS) + 70 1/6 MIT-DMS PDP-10 (ITS) +134 2/6 MIT-AI PDP-10 (ITS) -> PDP-11 + -> PDP-6 +198 3/6 MIT-ML PDP-10 (ITS) + + 1 0/1 UCLA-ATS PDP-11/45 (ANTS, ELF, UNIX, or UCLA-VMN) + 65 1/1 UCLA-CCN IBM 360/91 (OS/MVT and TSO) +129 2/1 UCLA-SECURITY PDP-11/45 (UNIX) + + 2 0/2 ARC-RD PDP-11/40 (ELF) + 66 1/2 SRI-KL DEC-1090T (TOPS-20) +130 2/2 SRI-VIS11 PDP-11/10 +194 3/2 SRI-NSC11 PDP-11/40 (ELF) -> SPS-41 (D0S) + + 3 0/3 NOSC-CC PDP-11/40 (ELF) -> UNIVAC 1110 + 67 1/3 NOSC-SECURE1 PLI -> H-716 -> UNIVAC 1108 +131 2/3 NOSC-SDL PDP-11/40 (ELF, UNIX) +195 3/3 NWC PDP-11/40 -> UNIVAC 1110 + + 4 0/4 UTAH-11 PDP-11/45 (RSX11M) +132 2/4 UTAH-TIP + + 5 0/5 BBN-TENEXE PDP-10 (TENEX) + 69 1/5 BBN-INLAT PDP-11/40 (Custom built) +133 2/5 BBN-PTIP PLURIBUS +197 3/5 BBN-TENEXA DEC-2050T (TOPS-20AN) + + 7 0/7 RAND-RCC IBM 370/158 (OS/MVT 21.7, HASP, WYLBUR) +135 2/7 RAND-TIP +199 3/7 RAND-UNIX PDP-11/70 (UNIX) + + 8 0/8 NRL PDP-11/40 -> TI-ASC + 72 1/8 NSRDC PDP-11/40 -> CDC 6400 +136 2/8 NSWC-DL PDP-11/40 -> CDC 6700 +200 3/8 NADC PDP-11/40 -> CDC 6500 +264 4/8 NSWC-WO PDP-11/40 -> CDC 6500 + + 9 0/9 HARV-10 PDP-10 (TOPS-10) + + 10 0/10 LL IBM 370/168 (VM/370) +202 3/10 LL-11 PDP-11/45 (UNIX) -> SPS-41 (DOS) + + 11 0/11 SU-AI DEC-20/40 (TOPS-10) -> PDP-10 (TOPS-10) + -> PDP-11/45 -> SPS-41 (DOS) + -> PDP-6 + + 12 0/12 ILL-CAC PDP-11/50 (UNIX) + 76 1/12 ILL-NTS PDP-11/20 (ANTS) or PDP-11/50 (UNIX) + + 13 0/13 GUNTER-ELF PDP-11/35 (ELF) -> B-4700 (MCPV) +141 2/13 GUNTER-TIP + + 14 0/14 CMU-10B PDP-11 -> PDP-10 (TOPS-10) + 78 1/14 CMU-10A PDP-11 -> PDP-10 (TOPS-10) +142 2/14 CMU-10C DEC-1090T (TOPS-20AN) -> PDP-11 (UNIX) +206 3/14 CMU-CMMP 4 PDP-11/20s + 12 PDP-11/40s (HYDRA) + Multiprocessor + + 15 0/15 I4-TENEX PDP-10 (TENEX) -> ILLIAC-IV (ACL) + -> B-6700 -> ILLIAC-IV (ACL) + -> PDP-11s-> ILLIAC-IV (ACL) + 79 1/15 I4-ELF PDP-11 (ELF) -> ILLIAC-IV (ACL) +143 2/15 I4B-TENEX PDP-10 (TENEX) -> ILLIAC-IV (ACL) + + 16 0/16 AMES-67 IBM-360/67 (TSS/360) +144 2/16 AMES-TIP +208 3/16 AMES-11 PDP-11/45 (ELF) -> PDP-11/10 + +145 2/17 MITRE-TIP + + 18 0/18 RADC-MULTICS H-6180 (MULTICS) + 82 1/18 ROCHESTER DCU-50 -> ECLIPSE 450B +146 2/18 RADC-TIP +210 3/18 RADC-XPER PDP-11/40 (RSX11M, ELF, UNIX) + + 19 0/19 NBS-10 PDP-10 (TOPS-10) +147 2/19 NBS-TIP +211 3/19 NBS-UNIX PDP-11/45 (UNIX) -> Internal Network + + 20 0/20 CCTC PDP-11/70 (UNIX) -> H-6000 (GCOS) +148 2/20 DCA-TIP +212 3/20 DCEC PDP-11/40 (RSX11M, RSX11D) + + 21 0/21 LLL-COMP PDP-11/70 (RATS, UNIX) + 85 1/21 LLL-MFE PDP-10 up Fall 77 + + 22 0/22 ISI-SPEECH11 PDP-11/45 (EPOS, DOS) -> FPS AP-120B + 86 1/22 USC-ISI PDP-10 (TENEX) +150 2/22 USC-ISIC PDP-10 (TENEX) + +151 2/23 USC-TIP +215 3/23 USC-ECL PDP-10 (TENEX) + +152 2/24 GWC-TIP + + 89 1/25 OT-ITS PDP-11/40 (ELF) +153 2/25 DOCB-TIP + +154 2/26 PENTAGON-TIP +218 3/26 PENT-UNIX PDP-11 (UNIX) + + 27 0/27 BELVOIR PDP-11/40 (ANTS) + + 28 0/28 ARPA-DMS PDP-15 (DMS) + 92 1/28 ARPA PDP-11/70 (UNIX) up Fall 77 +156 2/28 ARPA-TIP +220 3/28 ARPA-XGP11 PDP-11/40 (ELF) -> Xerox Graphics Printer + + 29 0/29 BRL PDP-11/40 (ANTS, ELF) + +158 2/30 BBN-TESTIP + + 31 0/31 CCA-TENEX PDP-10 (TENEX) -> DATACOMPUTER + 95 1/31 CCA-SPEECH PDP-11/40 +223 3/31 CCA-SIP PDP-11/40 (SIP Custom) + + 32 0/32 PARC-MAXC MAXC (TENEX) + 96 1/32 PARC-GATEWAY NOVA-800->Internal Net->PARC-MAXC2 (TENEX) + + 33 0/33 FNWC CDC-3200 -> CDC-6500 (SCOPE) + + 34 0/34 LBL CDC-6600 (SESAME) -> CDC-7600 (BKY) + + 35 0/35 NOSC-SECURE2 PLI -> PDP-10 (TENEX) + 99 1/35 LOGICON PDP-11/45 (UNIX) +163 2/35 ACCAT-TIP +227 3/35 NOSC-SECURE3 PLI -> PDP-11/70 (UNIX) + +164 2/36 CINCPAC-TIP + +101 1/37 DEC-MARLBORO DEC-1090T (TOPS-20AN) + + 39 0/39 SDAC-CCP PLURIBUS +103 1/39 SDAC-DP IBM 360/40 (DOS/360) +167 2/39 SDAC-NEP IBM 360/40 (DOS/360) +231 3/39 SDAC-44 IBM 360/44 (DOS) + + 40 0/40 BBN-NCC H-316 +168 2/40 NCC-TIP +232 3/40 BBN-GATEWAY PDP-11 + + 41 0/41 NORSAR-40A IBM 360/40 (DOS 15) +105 1/41 NDRE NORD-10 (SINTRAN-3) up 7/77 +169 2/41 NORSAR-TIP +233 3/41 NORSAR-11 PDP-11 + + 42 0/42 LONDON PDP-9 -> IBM 360/195 Dual Processor + (OS and ELECTRIC) + -> CDC 6400/6600->7600(SCOPE) + -> GEC 4080 (GECOS) + -> ICL System 4-72 +106 1/42 LONDON-VDH PDP-9 +170 2/42 LONDON-TIP +234 3/42 LONDON-SATNET- + GATEWAY PDP-11 + +171 2/43 TYMSHARE-TIP + + 44 0/44 MIT-DEVMULTICS H-68/80 (MULTICS) +108 1/44 LL-ASG PDP-11/50 (UNIX) +172 2/44 MIT-TIP +236 3/44 MIT-MC DEC-10/80 (ITS) + + 45 0/45 MOFFETT-ARC PDP-10 (TENEX) +109 1/45 MOFFETT-SUBNET PL1 -> PDP-10 (TENEX) + + 46 0/46 RUTGERS-10 PDP-10 (TOPS-10) +110 1/46 UPENN +174 2/46 RUTGERS-TIP +238 3/46 NUSC PDP-11/40 (ELF) -> UNIVAC 1108 + + 47 0/47 WPAFB PDP-11/50 (RSX11M) -> CDC-6600 (SCOPE) +111 1/47 WPAFB-AFAL VDA -> PDP-10 (TOPS-10) -> PDP-10 +175 2/47 WPAFB-TIP + + 48 0/48 AFWL PDP-11/50 (RSX11M) -> CDC-6600 (SCOPE) +112 1/48 ASL PDP-11/10 (ELF) +176 2/48 AFWL-TIP + + 49 0/49 BBN-TENEXB PDP-10 (TENEX) +113 1/49 BBN-TENEXD DEC-1090T (TOPS-20AN) +177 2/49 BBN-SPEECH-11 PDP-11/40 (RT11) -> SPS-41 (EPOS) +241 3/49 BBN-TENEX PDP-10 (TENEX) + + 51 0/51 SRI-KA PDP-10(TENEX) +115 1/51 SRI-IA11 PDP-11/40 (RSX11M) +243 3/51 SRI-PKT11 PDP-11/40 (ELF,RT11,DOS)->Packet Radio Net + + 52 0/52 ISI-XGP11 PDP-11/40 (ELF) -> Xerox Graphics Printer +116 1/52 USC-ISIE DEC-1090T (TOPS-20AN) +244 3/52 USC-ISIB PDP-10 (TENEX) + + 53 0/53 EGLIN PDP-11/45 (RSX11M) -> CDC-6600 (SCOPE) +117 1/53 NCSL PDP-11/40 (ELF) -> B-5500 + + 54 0/54 SCRL-DEV PDP-11 (RSX11) +118 1/54 SCRL-RSX PDP-11/45 (RSX11) +182 2/54 CHII MP-32/MP-32A -> AP-90 (SIGNAL) + + 55 0/55 ANL VARIAN-73->IBM 370/195 + (OS/MVT 21.7,ASP 3.1) + + 56 0/56 SUMEX-AIM PDP-10 (TENEX) Dual Processor -> PDP-10 + + 57 0/57 NSA PDP-11/40 (ELF) + + 58 0/58 NYU PDP-11/40 (ELF) -> CDC-6600 (KRONOS) +122 1/58 BNL PDP-11/34 -> 2 CDC-6600s -> CDC-7600 + (ELF)->(SCOPE 3.4)->(SCOPE 2.1, INTERCOM) + + 59 0/59 ETAC PDP-11/45 (ELF) + + 62 0/62 UTEXAS PDP-10 (TENEX) + +File: TIP, Node: NIC, Previous: Hosts, Up: Top + +The Network Information Center (NIC) is available at host 66 (SRI-KL). +To use it, connect to host 66 and give the command "NICGUEST" this will +log you in as a guest and run the NIC inquiry system automatically. It +is somewhat obnoxious to use, but mostly self-documenting. + diff --git a/doc/pcnet/proto.info b/doc/pcnet/proto.info new file mode 100644 index 00000000..7a81189d --- /dev/null +++ b/doc/pcnet/proto.info @@ -0,0 +1,2666 @@ +This is the file containing the INFO-ized documentation describing the +formal specs for PCNET protocol. It largely replaces oldstyle +non-treeified documents, at least for the time being. + +File: PROTO, Node: Proto, Up: (MC:PCNET;PCNET INFO)Top + +[This info-frame: Definition of the word "protocol", what PCNET + protocols are designed to accomplish, overview of our layered + protocol, and index of info about individual layers of PCNET protocol] + +In order for two entities to communicate, they need agreements as to +what physical medium will be used, what signals may be sent on it, +what those signals mean, and what actions an entity is required to +perform upon receipt of any particular signal. +The meaning of the word "protocol" includes all of that. + +PCNET is designed primarily for reliable unattended data communication +using low-speed modems over direct-dial telephone lines. Since +only two parties are connected at one time, we can save a lot of +overhead by not requiring a node address in every packet. Since the +link is direct, transmitted data reaches the other end virtually +instantly, we don't have to worry about having many packets already +transmitted but not yet arrived at the other end, so we can use a +simple acknowledgement method using a small outstanding-packet window. + +Because the protocol is layered, with clean simple interfaces, it's +easy to patch layers of PCNET protocol with layers of other protocols, +to communicate over other media. For example, the telephone interface +could be replaced by a satellite transponder or EtherNet tap, node +addresses could be added to packets to handle multi-tap connections, +and the outstanding-packet window could be enlarged to handle the long +turnaround delay inherent in synchronous satellite communications. + +But at the present time we're concentrating on those layers adapted to +low-speed direct-dial communications between small computers. All the +protocol definitions below are optimized for this environment. The +alternative layers that might be used for alternative environments +aren't described here. + +* Menu: + + ---- FIRST SOME INRODUCTORY SUMMARIES OF THE OVERALL PROTOCOL ---- + +* New layer run-thru:: + This is the best place to start reading to understand PCNET + protocols, and why we have so many micro-layers. Each has a purpose! + +* Quick layer run-thru:: + Summary of layered protocol design, emphasizing value-added + services of each layer. You may want to read this too before + reading the detailed specs of the individual layers. + +* Comparison with ISO model for open system:ISO + + ---- NOW THE MAJOR PARTS OF THE PROTOCOL, TREATED SEPARATELY ---- + +* Physical layers:: (major layer 1, TPC and microlayer 0) + Telephone switching and voice-grade lines, Bell 103 modem, + UART/ACIA -- providing full-duplex 8-bit binary communication. + +* Changing mode at low level:: + When establishing and breaking a PCNET connection, only the + physical layers and the HELLO or BYE protocol is in effect, not + the communication protocols (lower&middle, node-control protocol, + application-program protocol). Originate-mode HELLO must establish + physical connection (by calling the appropriate physical-layer + subroutine), log in to the remote machine, select PCNET mode, and + recognize the end-of-HELLO signal. -- Also when changing from + Radix-41 to 8-bit mode or changing baud rate, a "dangerous mode + change" must be done. + +* Lower&middle PCNET layers:: (major layers 2;3, microlayers 1,2,3,4,5,6; 7) + Half-duplex turnaround, packet framing, characterset translation, + validation, sequencing and retransmitting lost packets, + multiplexing multiple logical streams -- providing reliable + communication of blocks of 8-bit bytes along multiple logical + streams between multiple application programs, including the + node-control program. + +* PREAD&PWRITE:: Interface between middle layers and the following... + + (Everything after here sits above microlayer 7) + +* NOde-control program:: + Messages sent between this "program" on the two nodes are used to + activate other application programs, allocate streams to them, and + change parameters such as baud rate and maximum packet size. + +* Invoking application programs:OPNSTR + tells the node-control messages used to invoke application programs. + +* Application programs:: + The programs themselves: ECHO, MAIL1, FTP1, and many others... + + ---- NOW SOME OTHER ITEMS PERHAPS NOT PROPERLY INCLUDED HERE ---- + + Technically this next item has nothing to do with formal protocol + (and in fact I might move this section elsewhere in the info tree), + and we have no business imposing on implementors how to do this, + but if we don't say something here, at least throw up a straw man for + programmers to either emulate or replace, the world-net based on PCNET + protocol may never come to be... +* Overall software organization:: + Scheduling automatic execution of tasks at late night hours, + calling sequences to maintain subroutine heirarchy without losing + capability, unified user interface, ... + + ---- MISC RELATED INFO ---- + +* Some old files proposing/documenting new protocols:old RFC +* ADditional text not yet incorporated in the tree structure:proto add + +File: PROTO, Node: proto add, Up: Proto + +Date: 4 May 1983 06:22 EDT +From: Robert Elton Maas +Subject: Recent progress, capsule summary of PCNET +To: INFO-PCNET @ MIT-MC + +PCNET protocol/software has two major interfaces: + - the lower interface, whereby PCNET protocol/software talks to the + hardware (modem&uart) drivers, + - the upper interface, whereby application programs talk to the PCNET + packet protocol/software. + +When connecting, disconnecting, or changing modes in a dangerous way +that requires dropping out of packet protocol, only the lower +interface exists. The hello or bye or dangerous-mode-change +protocol/software talks through the lower interface to the hardware drivers. + +At all other times when online, both interfaces exist. The application +program talks through the upper interface to the PCNET packet +protocol/software, which in turn talks through the lower interface to +the hardware drivers. + +PCNET packet protocol/software provides error- and flow-control, +including multiple logical streams. Application programs provide +services desired by the user, such as electronic mail, file transfer, +loopback testing, remote virtual-terminal login, or whatever. + +File: PROTO, Node: old RFC, Up: Proto + +Most of these important files exist only on SU-AI backup tapes. +Please send REM any requests for files you urgently need. +They'll be restored from tape and mailed here and incorporated into + this info tree in the appropriate spot. + + ?... +81106A PRO Upper levels of non-watered PCNET protocol +81207A WRU PCNET flow control (TVR wanted it) + +File: PROTO, Node: OPNSTR, Up: Proto + + Initially only the NODE-CONTROL program is activated. +NODE-CONTROL messages are sent to it asking for ECHO or MAIL1 to +be activated. Logical channels are allocated for the program on +one node to talk to the corresponding program on the other node. +Communication then shifts to these logical channels where the +two programs conduct their business. When they are done, communication +reverts to the NODE-CONTROL program. When all activity is finished +for this particular telephone connection, the NODE-CONTROL programs +agree to terminate the call. + +ASKING FOR PROGRAMS. + To request activation of a program and allocating streams to it, +a NODE-CONTROL message of Please-Do Open-Streams (C0+04 = C4) is issued. +It contains a query number, used to identify requests when more than +one is outstanding, and the name of the program wanted. The opcode, +then the query number, then the ASCII name of the process, is sent +on logical stream 0. For example, to request the MAIL1 process: + O-->A Stream=0 EOD: C4 01 "MAIL1" +The other (answer) node then replies with an I-Will Open-Streams (80+04) +NODE-CONTROL message. It contains the query number from the query it +is answering, the starting stream number (always 41 in simple mode +or for the first/only application program in advanced mode), and +the number of streams (hexadecimal 3F for ECHO and 2 for MAIL1). +For example, the reply to the above request would be: + A-->O Stream=0 EOD: 84 01 41 02 +To refuse the request, perhaps because the program hasn't been installed, +send a I-Won't Open-Streams NODE-CONTROL message. It contains the opcode, +the query number from the request, followed optionally by an explanation +of the problem, which may be put in the log or printed on the operator's +console or just ignored. For example, to refuse the above request, +the following might be sent: + A-->O Stream=0 EOD: 04 01 "Has bug, maybe up tomorrow" +or just: + A-->O Stream=0 EOD: 04 01 + +<> +At the time an application program is invoked, streams are opened on +both nodes. When an application program is all done (presumably the +program on both nodes arrives at this point essentially simultaneously +by means of some explicit cue sent from one to the other, such as a +BYE opcode in the private application protocol or an End-of-Data bit +set on some critical stream), it exits. At that time the streams that +were allocated to it are deallocated, returned to the pool of +available streams. Although both nodes must now stop using these +streams, only the node that allocated them must update its table of +free streams that might be reallocated later. -- Although it's +conceivable that the appliction program itself might do this updating +of the allocation tables, this is rather dangerous. Perhaps the right +way to implement this is that each node has a table listing +application programs and how many streams they require. When a request +to invoke an application program is being processed, the node-control +program looks in this table to decide how many streams to allocate. +The node granting the request then performs the allocation and sends +the starting stream number and count of streams to the other node, and +that other node then verifies the proper number of streams have been +allocated. Alternately these tasks may be performed by a support +subroutine that is called from inside each application program. Later +when the application programs exit, that is after a RETURN is executed +and control returns to the node-control process, the node-control +process then deallocates those streams. Alternately deallocation could +be performed by service subroutines called from inside the two +application programs just before RETURNing. + +File: PROTO, Node: ISO, Up: Proto + +Date: 15 March 1983 1439-mst +From: Paul Schauble <"Schauble@M.PCO.LISD.HIS"@udel-relay> + + ISO Model PCNet +------------------------------------------------------------------ + Application Application Basically the same + + Presentation None Incorporated into application + + Session None Services not needed + + Transport Directing layer PREAD/PWRITE + + Network None Assumed point-to-point + + Link Sequencing + + " Validating + + " Translating&framing + + " Half duplex + + Physical Physical PCNet assumes Bell 103, which + is one of several ISO standards. + + +The result of this is that the PCNet protocols could be used in an +ISO structured system, and that ISO protocols could be used in PCNet, +with only minor modifications. + +File: PROTO, Node: PREAD&PWRITE, Up: Proto + +When an application program (or the node-control "program") wants to +send data across to the corresponding application program on the other +node, it uses PCNET-WRITE which is often abbreviated to PWRITE. The +program at the other end uses PCNET-READ, abbreviated PREAD, to see if +there is any data that has arrived, and to fetch that data if it has. +If the application program is sure there should be some data arriving, +it can use PCNET-READ-WITH-WAIT, abbreviated PREADW, to keep calling +PREAD over and over until some data arrives or the communication link +breaks down preventing any further arrival of data. + +* Menu: + +* R:Specification for PREAD (These 3 sections not yet created, +* W:Specification for PWRITE +* RW:Specification for PREADW refer to older specs below for now.) + +* Older specifications:(MC:PCNET;INTRO INFO)PREAD&PWRITE + +PWRITE PRO PCNET: proposal for read/write interface under servers + +File: PROTO, Node: Specification for PREAD, Up: PREAD&PWRITE +[Need to extract from the protocol document specs for PREAD.] + +File: PROTO, Node: Specification for PWRITE, Up: PREAD&PWRITE +[Need to extract from the protocol document specs for PWRITE.] + +File: PROTO, Node: Specification for PREADW, Up: PREAD&PWRITE +[Need to extract from the protocol document specs for PREADW.] + +File: PROTO, Node: New layer run-thru, Up: Proto + [See to do, edit, below] + +[This info-frame: Introduction to PCNET protocols describing what the +hardware provides and what the application program really needs, +listing of individual needs and layers of protocol that satisfy them.] + +Suppose we have two computers on opposite ends of a telephone line, +with modems to convert between binary and analog signals, a UART to +convert between octets of binary data and carefully-timed sequences of +bits in real time, and some very primitive software to perform +device-dependent things through the modem&UART such as establishing a +connection, sending bytes of data, and collecting bytes of data that +have arrived from the other computer. Thus either of the two computers +can send an octet of data to the other which will be received it if no +phone line noise interefered with the analog signals used to carry the +data. + +Suppose we an application program on one of the two machines that +wants to communicate to an application program on the other. It wants +to be able to open several data channels (streams) to the other so it +can send commands on one channel and data on another, or perhaps +several kinds of data on different channels. It wants the receiving +program to be able to distinguish data on the different channels, and +it doesn't want the data to be damaged (deleted, duplicated, changed, +rearranged, put on the wrong stream) en route. The receiving program +doesn't want to hassle with bad data or temporary errors. It wants to +receive exactly the correct data on exactly the correct stream, +without being bothered by temporary error conditions that can be +corrected, but it does want to be told if the communication link has +completely broken down preventing further data transfer. + +The purpose of the lower&middle layers of PCNET protocol is to fill +the gap between the needs of the application program and the services +offered by the low-level software that drives the telephone-interface +hardware, i.e. to insulate the application program from the +error-prone telephone line and to provide the multiple streams and +other facilities not available on a bare modem&UART link. Below are +the various problems that exist in two application programs trying to +communicate with each other, and the solutions provided by various +micro-layers of PCNET protocol. (There are two major layers, the Link +layer, also known as the packet layer, and the Directing layer, also +known as the stream-multiplexing layer. But the Link layer is +subdivided into about six smaller layers called "micro-layers".) + +* Menu: (Numbers 0 thru 8 indicate the sequence in which all these + microlayers are stacked on top of each other when putting them + all together to make the full PCNET protocol, where 0 + represents the device-dependent code for modem&UART, 8 + represents the application program, and 1 thru 7 represents + the lower&middle layers to be inserted between them.) + +* 0-1 Interface:: Interface by which software can easily send and + receive raw data on the modem&UART. This is what's provided + for talking to the device-dependent software (microlayer 0) to + make it do the primitive things it can do. (Actually it's a 0-x + interface because any program can use it to talk to microlayer + 0. For example initially during establishing of PCNET + connections, the HELLO program talks directly to microlayer 0 + through this interface, so it's the 0-HELLO interface at that + time; and in full-duplex mode where microlayer 1 isn't used, + microlayer 2 talks to microlayer 0, so it's the 0-2 interface.) + We've specified names for each of the individual facilities + provided by the hardware, both to clarify precisely which + facilities are provided, and to standardize terminology in + documentation and software. + +* 7-8 Interface:: Interface by which an application program sends + and receives data on various streams. This is what the + application program wants to see available for its use, + instead of what's actually provided to calling programs by the + 0-1 interface standing alone. Again we've standardized the + interface both for clarifying facilities provided to the + application program and for standardizing documentation and software. + +Whatever the difference is between services provided by the 0-1 +interface and services needed by the 7-8 interface, represent +protocol that must supplied in addition to the 0-1 interface to +satisfy the needs of the 7-8 interface, i.e. layers of protocol that +sit on top of the 0-1 interface before the 7-8 interface can be created. +The microlayers introduced below provide these additional services. +Thus the 0-1 interface (including the hardware and device-dependent +software implied by it), plus the additional layers introduced below, +provide all the functionality required by the 7-8 interface, that is +by the application program that uses the 7-8 interface to obtain its +communication services. Both of the above sections should be studied +before the problems listed below will make much sense. + + motivation for each micro-layer, rearranged into teaching sequence... + +[To do, edit: Stuff about app'l program needing multiple streams and +EOD bit should be moved into the 7-8 interface, while stuff about need +to put number in directing byte to accomplish this keep in 7str/7eod] + +* 7str Motive:: How to multiplex multiple logical streams on one modem? +* 7eod Motive:: How to communicate the end-of-file point on a stream? + Needs are satisfied by the Directing layer + +* 5 Motive:: How to make sure only good data gets through? + Need is satisfied by the Validating microlayer + +* 6 Motive:: How to retransmit when data didn't get through the first time? + Need is satisfied by the Sequencing microlayer + +* 2 Motive:: How to recognize start&end of a block of data on the + line? How to assure that the UART will be correctly + framed at the start of a block even if it was + misframed from noise during the preceding block? + Needs are satisfied by the packet framing microlayer + +* 1 Motive:: When genuine full-duplex operation is impossible, how + to decide whose turn it is to speak without getting confused? + Need is satisfied by the half-duplex turnaround handshake microlayer + +* 3&4 Motive:: If data in the block conflicts with framing or + half-duplex-turnaround characters, how to avoid + confusing the two? What if the operating system + doesn't allow 8-bit data to be sent/received over the modem? + Needs are satisfied by the translating microlayer + +Summary, micro-layers listed here in normal sequence as data feeds +through each micro-layer to the next: + + Application program sits at the top, transmitting data + downward, and receiving data that arrived at the bottom and + has now made its way to the top. + + Application-level command to other program "PLEASE DO ACCEPT MAIL" + Encoded as [8-bit opcode and binary arguments], on some stream. + Sent down via a call to PWRITE. Received on other node via PREAD +7 Directing layer + Block prefixed by header octet telling stream number and EOD bit. +6 Sequencing layer + Structure passed between these layers includes sequence + number, acknowledgement number, and the original + [directing octet & opcode octet & args] from above. +5 Validating layer + Sequence & acknowledgement numbers packed into one octet which + is appended, checksum or CRC in two more appended octets. + Now have: [dir. octet & opcode octet & args & sequence octet & cksm] +3&4 Translating layers + All data from just above translated into Radix-41, which + doesn't include any characters that would conflict with + framing atsigns or turnaround characters below, or data kept + in binary as-is except characters that would conflict with + framing/turnaround or with quoting mechanism are quoted. +2 Packet framing layer + Each block now has atsigns around it to reframe the UART and + to signal the start of each block. [NB 1983.March, there is a + possibility atsign may be changed to another character in + Simple mode, to permit communication with Honeywell computers + which don't pass atsign to user programs.] +1 Half-duplex turnaround handshake + (Used only when in HDX software mode using FDX modems.) + Nodes take turns sending one or more packets, sending trailing + brackets, watching for lead-in atsigns from the other node + within ten seconds sure it saw the turnaound (if not, + retransmit turnaround and wait for atsigns again), then + buffering up the other node's transmissions until receiving + the trailing brackets from the other node, immediately sending + leading atsigns to acknowledge turnaround, then processing the + data that has been buffered and preparing the outgoing data to + be sent as packets at the top of this loop. [NB 1983.March, + there is a possibility brackets may be changed to other + characters in Simple mode, to permit communication with IBM + computers which use EBCDIC internally and don't convert brackets.] +0 Modem interface software + UART/modem hardware sit at the bottom. + (Well, actually the telephone line is at the VERY bottom.) + +File: PROTO, Node: 7-8 Interface, Up: New quick layer run-thru + +Sigurd.UDel-CC-Relay@UDel-Relay wants this when it's written. + +A communication application consists of two parts, a program on the +originate node and its mate on the answer node. The two parts talk to +each other, sending and receiving blocks of data that have particular +meanings to them. For example a file-transfer program might need to +communicate the name of the remote file (the one on the machine +different from the machine on which filenames on both machines are +initially known; the local file is the one on the same machine where +both names are initially known, and that needn't be communicated to +the other machine) as well as the data of the file. + +To simplify the code provided by PCNET, i.e. everything except the +application program itself, we assume each application program can +reblock its own data, that is break data into blocks small enough to +fit into PCNET packets, and at the receiving end collect the data from +PCNET packets and put them where they belong. To support applications +that want multiple logical streams, we provide that. For example, an +FTP program might send commands on one stream and data files on +another. + +PCNET therefore provides two basic mechanisms: PCNET-WRITE (PWRITE) to +transmit a block of data to the the other machine along some logical +stream, analagous to WRITE or OUTPUT from a program to an operating +system; and PCNET-READ (PREAD) to check for incoming data that has arrived +from the other machine and if such data has arrived then to return the +data together with the number of the stream it arrived on, somewhat +analagous to READ or INPUT except with the ability to return +immediately if no data has yet arrived thus allowing applications that +listen for input that may or may not arrive while in the midst of +transmitting. For programs that are expecting incoming data and can't +do anything else until it arrives, we also provide a waiting form of +PCNET-READ called PCNET-READ-AFTER-WAIT (PREADW), which merely calls +PREAD over and over until it has data. + +File: PROTO, Node: 0 Interface, Up: New quick layer run-thru +[need to define calls to RCWBT, SDWBT etc.] + +File: PROTO, Node: 7str Motive, Up: New quick layer run-thru + +-- Why the "Directing layer", in particular multiple streams? -- + +Almost any application program needs more than one logical stream, for +example it needs one stream to transmit data and another to transmit +occasional commands to initiate terminate or modify the data stream. + +Arpanet protocol does this in a very clumsy manner. All data in a +particular direcion travels on a single stream, but commands are +prefixed by a byte of hexadecimal FF while data isn't. If a data byte +of FF is to be transmitted, it is sent as two bytes, FF FF, which is a +command to quote a byte of FF. Thus commands must be parsed exactly +correctly in real time as data is passing by, and the slightest +parsing error causes commands to be interpreted as data or vice versa. +This is complicated by variable-length commands such as anything with +a file name in it, requiring the command structure to contain +length-of-command information as well as the actual command. + +Many other protocols either don't allow commands at all when in +the midst of transmitting data, or use special kinds of packets which +somehow must be delivered to the application program by special means. + +Arpanet and some other protocols use multiple streams to allow +multiplexing several application programs on a single hardware device. +PCNET has extended this concept to allow individual application +programs to have multiple streams themselves, thus solving both the +control-vs-data problem described above and the multiple-program +problem by a single mechanism. An advantage of this is that commands +don't have to be carefully parsed and don't need to have length +information contained in them, since commands can simply run to the +end of the data block (on the control stream). Unknown commands can be +ignored or explicitly rejected by the receiving machine without having +to know their internal syntax. + +The PCNET directing layer provides 128 logical streams, 64 of which +are allocated by the originate node at the request of the answer node, +and 64 of which are allocated by the answer node at the request of the +originate node. Thus if the machines are in full-duplex, both talking +and listening at the same time, requests can be issued and granted in +both directions at the same time without need for synchronizing to +avoid the same stream being allocated by the different machines for +different purposes at the same time. In each group of 64, number 0 is +pre-allocated and is reserved for the Node-Control program, while the +remaining 63 are dynamically allocated to any desired application +program. Even in the most unbalanced case where only one group is +used, because one node is making all the requests and the other node +is merely granting them, there should be enough streams to allow as +many application programs as one would ever want to be running at the +same time, even if some of them use several more than the normal two +streams (control and data). Of course, if some application program +really needs a very large number of logical streams, it can always +multiplex its logical streams onto a single PCNET logical stream, for +example by reserving the first byte of each 7-8 data block for its +own logical stream number, thus effectively multiplying the number of +logical streams available by 256. But a majority of application +programs use only a small number of logical streams, and the PCNET +directing layer adequately handles these needs. + +File: PROTO, Node: 7eod Motive, Up: New quick layer run-thru + +-- Why the "EOD bit" in the Directing layer? -- + +Given that we have multiple logical streams, it's often useful to +indicate something like an end-of-stream signal. For example, when +sending a long file, rather than declaring the length of the file at +the start and carefully keeping track of the byte count all along, +one might just start sending data and then when the end of the file is +reached send an end-of-file mark as an end-of-stream signal on the +data stream. If commands can sometimes be longer than a single data +block (even if the current implementation doesn't allow that), an +end-of-stream signal can be sent on the control stream when each +command is done, which will normally be on every block if commands +don't actually use more than block currently. + +It takes only a single bit to specify whether an end-of-stream occurs +at the end of a particular bit, thus the PCNET directing layer +provides this useful feature. + +Together the stream number (1 bit to specify the group, that is who +allocated the stream, and 6 bits to specify the stream number within +the group), and the end-of-stream bit (1 bit), are 8 bits. These are +packed (by the directing layer) into a single octet when transmitting +data and unpacked on receipt. An application program thus sends a +certain number of bytes of data on a particular stream with the +end-of-stream bit either 1 (end) or 0 (normal). (Elsewhere the +end-of-stream bit is called the end-of-data or EOD bit.) + +File: PROTO, Node: 5 Motive, Up: New quick layer run-thru + +-- Why the "Validating layer" and how in general it works? -- + +Now that we're sending data on multple streams to possibly multiple +application programs, things would really get confused if an error +occurred on the telephone line causing data to go to the wrong stream, +and it takes only a single-bit error in the stream number to do that! + +Obviously we need some way to detect when an error has occurred, so +that we can reject the bad data. But bad data can take many forms: +Individual bits can be clobbered, causing a 1 to become a 0 or vice +versa. Several bits in a row can be so clobbered, with some accidently +clobbered to their correct value while others changed to the opposite +value. Due to the way UARTs handle start&stop bits, the UART can be +thrown out of corrct frame, causing bits to be shifted in a strange +way, with each byte as received to be composed of bits from two +adjacent bytes as originally transmitted. Due to problems in the +software, or due to rather long bursts of noise, entire bytes or +several bytes in a row can be totally lost with no indication of +trouble or with only a single data-overrun flag for several lost +bytes. Finally due to the strange way voice-grade telephone circuits +are sometimes switched on long distance circuits, especially via +satellites, data may possibly be rearranged. + +PCNET transmits two bytes of checksum with each block of data. These +two bytes are an alternating checksum (one byte for bytes in first, +third, ... position; other for second, fourth, ...) when using +Radix-41 (see later, microlayers 3&4), and a Cyclic Redundancy Check +(CRC) when using 8-bit mode. These methods assure that the bits in the +checksum are pseudo-random, so that out of every 65536 bad blocks only +one will get through these error checks. Since there is usually only +about one error-burst each 5-10 minutes even on noisy low-quality +residential telehone circuits, this means there's an undetected error +only about every 3E5 to 6E5 minutes which is about a year of +continuous 24-hour-a-day operation. Even so, this represents a +compromise between ideal performance (less than one error in the +lifetime of the network) and overhead (only two bytes of checksum per +packet). Applications requiring a higher level of data assurance +should include additional error protection, such as a 4-byte checksum +on an entire file or an additional 2-byte CRC (using a different CRC +plynomial!!) on each data block. But for ordinary electronic mail and +file transfer our undetected errorrate should be quite sufficiently low. + +File: PROTO, Node: 6 Motive, Up: New quick layer run-thru + +-- Why the "Sequencing layer" and how in general it works? -- + +Now that we have detected blocks of data that got munged by telephone +line noise, and have ignored such blocks, how do we get the correct +data retramitted so we can have another chance to receive it, +hopefully correctly the second time? + +PCNET solves this problem elegantly by including in each data block +(packet) a sequence number for that block and also a "want" number +that says what block number in the reverse direction hasn't yet been +received even though all earlier blocks have been received. "Received" +in this context means "received correctly", since anything that wasn't +correct has been rejected by microlayer 5 already. Each node maintains +a want number, telling which block it wants next. If it receives that +block, the number is bumped up to the next value. If it receives an +earlier block, it is rejected, since it's a duplicate of a block +already received. If it receives a later block, that block may either +be saved for looking at later (if there is enough buffer space) or +simply ignored (if there isn't enough buffer space to keep it around). +Each time a block is sent out (in the reverse direction from blocks this +"want" number refers to), the current value of the want number is +stuffed into it. If that block reaches the other node, that node knows +we've received all blocks preceding the one "want"ed. If after a +reasonable time our want number as seen by the other node hasn't moved +past some particular value, the other node realizes that block we are +still wanting must have gotten lost somewhere, so it sends us that +block again. + +To avoid needing more than one byte for all this sequence and want +numbering, we use three bits for each. The mathematics is that if we +never transmit more then the currently wanted block plus three +additional blocks after it, there will never be confusion as to +whether we're talking about a certain block or the block with the same +3-bit number that is 8 earlier or 8 later in the overall sequence. + +For simple nodes that don't have enough buffer space to receive blocks +out of sequence and put them back in to order, the window is 1, which +means only the one block with the "want"ed number is ever accepted, +and it must be sent over and over until it gets through, before any +later block will be accepted. Since blocks with any later or earlier +number are rejected, and the want number is bumped up by one each time +a block is received, it's impossible for blocks to get out of sequence +as they are passed up to the directing layer above, and it's +impossible for any block to be duplicated or skipped over. The worst +that can happen is that no data at all is passed up for a while if the +same block keeps getting munged each time it is retransmitted, but +finally it gets thru correctly and the data is passed up to the +directing layer as if nothing had gone wrong in the first place; or +else that after many retries without success the sequencing layer +finally gives up and declares the telephone line too noisy to be used +at all, and aborts, forcing the application program to abort whatever +it was trying to do. Thus either correct data in correct sequence is +passed, with possible delays due to retransmissions (which are +invisible to higher layers except for their realtime delay, which most +application programs won't notice at all), or a clean abort of the +whole connection is signaled. + +There is one minor hitch. If no data is being sent in one direction, +for example in the midst of a long file-transfer, how do we send the +want number in the reverse direction. (Remember that normally a packet +contains one byte of sequence&want numbers, two bytes of checksum, one +byte with stream number and EOD bit, and some bytes of data being sent +on that stream.) We could of course pick a stream number at random and +send zero bytes of data on it, but that might confuse some +applications, and it's rather strange to pick on some random +application when the problem is down in the lower layers that should +be invisible to it. PCNET solves the problem this way: It sends an +empty packet, that is one that doesn't have the directing byte at all, +even though it still has the sequence&want number byte and the two +bytes of checksum. The sequencing layer filters out these empty +packets on receipt, processing the sequence and want number as usual, +but not passing anything up to the directing layer. These empty +packets can therefore be inserted by the transmit side of the +sequencing layer any time it needs to acknowledge incoming data but +doesn't have any outgoing data to send, without messing up the rest of +the protocol. Lower layers (up through validating) treat these the +same as ordinary data packets, while higher layers (directing and +application) never see them at all. + +File: PROTO, Node: 2 Motive, Up: New quick layer run-thru + +-- Why the "packet-framing layer", and how it's accomplished? -- + +The validation layer assumes we can recognize the start and end of +incoming blocks (packets) of data. But all that is provided by the 0-1 +interface for receiving data is the ability to receive individual +bytes. How do we know the start and end of each checksummed&numbered +block of data? + +We could put a length field in each packet, somewhere near the start, +so then we can be counting bytes until we reach the end. But if phone +line noise happens to mung that length field we are lost. The checksum +will fail, so we can reject this packet, but how do we know where the +next packet starts? + +A better (more robust) way is to put special bytes of data between +packets to separate them. PCNET has chosen atsign with mark parity, +because it tends to re-frame the UART, thus assuring the subsequent +block will be seen even if the preceding was lost due to phone line +noise knocking the UART out of frame, because it's a printing +character, and because it's not a lowercase character that might be +converted to upper case. To assure that not only will the subsequent +block of data be seen in correct UART frame but also that the atsign +itself will be seen, we transmit two of them together, the first to +reframe the UART and the second to be actually seen. If both are seen, +the normal case in the absense of an error, the software simply +rejects the zero-length "block" between the two atsigns, since every +actual packet (even "empty" packets inserted by the sequencing layer) +contains at least three bytes, the two bytes of checksum and the one +byte containing the sequence and want numbers. + +File: PROTO, Node: 1 Motive, Up: New quick layer run-thru + +-- Why handle Half-Duplex by software? How to do it? -- + +Most modems available on small computers, as well as the normal dialup +modems on large machines (except on IBM 360/370/3033 systems) are +inherently full-duplex, that is they can both receive and transmit at +the same time. Accordingly they have no means built-in for allowing +the two machines to take turns talking. + +When a human is using a text editor or other program, it's generally +useful to have full-duplex. That way the human doesn't have to wait +after each command for the remote host to finish executing it and be +ready for the next command, with the keyboard locked (logically if not +physically) in the meantime. (Have you ever broken your fingernails +or painfully stubbed your fingertips on an IBM 2741 terminal, because +you made the mistake of trying to press a key too early while the +keyboard was still locked, with the keys as hard as rocks? Or have you +ever tried to use an IBM system from a normal non-locking keyboard, +and had to wait a second or two after every prompt just to make sure +it was really your turn to type, lest the machine reject your whole +line of input *AFTER* you had spent a half minute carefully typing it, +because at the *START* of the line it wasn't yet your turn yet, and as +soon as it WAS your turn to talk the IBM system recognized that you +had tried to type ahead and the controller had lost some of your +input, but the IBM machine couldn't tell you until you were done with +your line because it wasn't IBM's turn to talk until then??? +Half-duplex is totally in-humane!!) + +Given that we need full-duplex modems to achieve a decent humane +interface to the remote computer during editing and other interactive +sessions, and given that we can't afford to have two different sets of +modems, full-duplex for direct interactive use and half-duplex for +PCNET connections, we are stuck with using full-duplex modems for +PCNET use. But writing software to receive and transmit packets at the +same time is much harder than writing software to take turns receiving +and transmitting. In fact, in some languages it's impossible to handle +interrupts or in any other way service the receive side of the UART +fast enough to avoid losing most of the data, except by running in +half-duplex mode where when receiving we're sitting in a wait-for-data +loop most of the time and not trying to do anything else like +transmit. Thus we need to provide a half-duplex mode of communication +even though our modems are designed for full duplex. + +We do this by sending some data that means "I'm done sending, your +turn to send, I'll be listening now" which can be recognized at the +other end. That's what microlayer 1 of protocol does. We send brackets +to say we're done, and the other node sends atsigns back to say it got +the brackets ok and will be sending packets now. + +File: PROTO, Node: 3&4 Motive, Up: New quick layer run-thru + +Sigurd.UDel-CC-Relay@UDel-Relay wants this when written. + +-- Why use Radix-41 or 8-bit transparency instead of just packet as-is? -- + +Now that we can turn the line back and forth so we don't have to write +code that listens for incoming data while transmitting, and we can +recognize packets, throw away the bad ones, put the good ones in +correct sequence, and pass the data to the correct application program +along the correct logical stream, we're almost done. We have one +problem: What if some data we want to transmit, or some byte generated +by the directing or validating layer, happens to be an atsign or +bracket that might be mis-interpreted as the end of a packet or as +half-duplex turnaround (I'm done transmitting)? We need some way to +represent atsigns and brackets in some way that doesn't involve +actually transmitting an atsign or bracket on the UART. Furthermore +there are many systems that can't handle all eight bits of data (in +particular they throw away the parity bit), or which can't even handle +all 128 possible 7-bit characters as data (for example they interpret +certain control characters in magic ways, ignore NUL and RUBOUT, +convert all text to upper case, etc.). We need a way to represent more +than half the 8-bit characters in some way that is restricted to the +very few remaining characters that are handled correctly. + +When BOTH machines, originate and answer, can handle 8-bit data +correctly, and the only problem is atsigns and brackets, we offer +8-bit mode. Most octets are transmitted as-is. One value is reserved +as a quote signal. The quote signal is then used to quote itself as +well as atsigns and brackets. + +When EITHER machine can't handle 8-bit data, we offer Radix-41 mode, +whereby we use an extremely restricted set of characters (41 out of +the possible 256) in triples to represent pairs of 8-bit values +(41*41*41 is slightly larger than 65536). Radix-41 mode slightly +complicates the validating layer since when transmitting an odd-length +block an extra byte of zero must be appended and when receiving a +block the validating layer must decide whether to throw away the last +octet or not. The rule is: if the last octet received isn't zero, or +if the block checksumms correctly as-is without dropping the zero +octet, it isn't thrown away; if the last octet IS zero and the block +checksumms incorrectly with it but correctly with it dropped, then it +is dropped. This is slightly ugly, but it's the best solution we could +come up with. + +File: PROTO, Node: Overall software organization, Up: Proto + + + +File: PROTO, Node: Changing mode at low level, Up: Proto + +(tim.uci@Rand-Relay wants this when ready for release) + +After establishing hardware (modem&UART) connection and logging in and +selecting the generic mode as PCNET, the specific PCNET sub-mode must be +negotiated before any packets can be exchanged. Possible modes are: + Simple at same speed (110 or 300 or 1200); + Enhanced at same speed (300 or 1200); + Enhanced at faster speed (was 300, will be 600 baud). +Details of this negotiation is in a separate file not online presently. +Update 1983.3.19, the file name is 82120A.PRO, and has been requested +at SU-AI for restoration from magtape. Awaiting arrival of file. + +* Menu: + +* HELLO specs:(PCNET;82120A PRO)* + +79C07A RFC PCNET -- How to change modes at bottom level +82120A PRO PCNET: Proposal for HELLO (from 80A01A.PRO,81202A.PRO) +CRIPPL ICP PCNET: Initial Connection Protocol for crippled mode +RCVMSG PRO PCNET, propose dialout to deliver msgs to customers + +File: PROTO, Node: Quick layer run-thru, Up: Proto + + PCNET LAYER OVERVIEW To support mix&match of layers + +Mixing and matching parts of various protocols has been suggested. +Before this can be done intelligently, we must understand just what +services are provided by each layer of protocol and what the +interfaces are at the top and bottom of each layer. I haven't yet seen +a clear description of Internet layers in this way (although from +reading their documents one can sort of piece together some of this, +and the Internet protocol is surely layered cleanly), nor the other +big protocols (X.25, SDLC, HDLC, DIALNET, IFIP WG6.5, Arpanet, TYMNET, +Telenet) although they too are probably cleanly layered, and maybe +somewhere there's an overview of layers like this. In the case of the +several micro protocols proposed here (MMDF, MODEM2, CIS/MNET, Kermit) +I haven't seen this kind of overview either, but I doubt it could be +done because I don't think these protocols aren't as cleanly layered, +but I might be mistaken. Advocates of those protocols, take this as a +challange! + +Anyway, here's my attempt at describing PCNET major layers in this way: + +PCNET is divided into two major parts, the part that makes it possible +for applications programs to talk to each other using multiple +streams (called here the "support protocol"), and those applications +programs themselves. The support protocol is further divided into +three major layers: + (1) The communications-channel drivers and interfaces. + This package provides a way to open a channel, which for the + telephone means dialing or answering a call and initializing the + modem; a way to send/receive data over the modem&phone, which + includes four essential functions (see if receive-data available, + read a byte, see if transmit-buffer free, send a byte); and a way + to terminate a channel, which for the telephone means to hang up. + (2) The character-mapping and error-control methods. + This includes mapping between a subset of ASCII and full 8-bit + binary data to allow communication over user-dialup ports into + timesharing systems, handling logical half-duplex turnarounds so + that the higher levels of protocol can effectively have use of + virtual full-duplex, ignoring packets that have been damaged and + thus contain uncertain data, acknowledging packets that have been + received correctly, retransmitting packets that haven't been + acknowledged, and putting data from packets back in sequence after + an out-of-sequence retransmission has occurred. + (3) Multiplexing multiple logical streams on a single lower-level stream. + Up to 63 two-way streams may be allocated by the local node and up + to 63 may be allocated by the remote node. + +Level (1) lower interface is hardware dependent. + +Level (1) upper interface consists of 8-bit bytes of data in +half-duplex or full-duplex mode, with possible restrictions on the +characterset allowed, and with uncertain error rate depending on +hardware used. + +Level (2) lower interface matches level (1) upper interface except +that in Radix-41 mode it uses only the following characters: +Letters (upper case only), numerals, specials ";:<=>@", and . + +Level (2) upper interface consists of alternately accepting (to +transmit) and returning (after receiving) blocks of 8-bit bytes. +Blocks may be of varying lenths, including empty, thus effectively +emulating full-duplex (asynchronous send/receive) half-duplex (take +turns send/receive) and simplex (long monolog) modes of communication +at various times during a single connection even when the level (2) +lower interface is half-duplex only. This data has an error rate that +is less than 1/(2^16) of the error rate at the level (2) lower interface. +Thus with a typical noisy-phone-line error rate of one per minute or +so, the undetected error rate in level 2, which becomes the total +error rate at the upper interface, is less than one every three +months, adequate for most personal-computer applications, and masked +by more frequent errors on the microcomputers themselves such as +diskette read errors. + +Level (3) lower interface requires a virtually error-free 8-bit-binary +channel, such as that provided by level (2) upper or by a short direct +connection between two computers. It also requires alternating +send/receive of varying length blocks (including empty ones) such as +provided by level (2) upper. + +Level (3) upper interface consists of one permanently-allocated +channel for handling control information such as opening/closing +channels and changing communication parameters (baud rate, maximum +packet size), and 254 other channels that may be opened and closed at +will. Each open channel can send a block of data, check for receipt of +a block of data, or receive a block of data that has arrived, at any +time. (Trying to send a block when there's already received data +waiting fails with an error flag, as does trying to receive a block +when there isn't any waiting, but these failures may be used as normal +programming practices in lieu of pre-checking for data-arrived, to +avoid race conditions when the modem is operating in true full-duplex +mode.) In various implimentations, the responsibility of matching +these logical streams to the corresponding logical I/O channels of the +applications programs may be the responsibility of the application +program itself (in simple mode, for both the control stream and other +streams), the node-control program (in advanced mode, for all streams +except the control stream), or the level (3) itself (in advanced mode, +for asynchronous/unanticipated control messages only). + +We currently have several (three at last count) application programs +defined: + (A) Node-control, permamently assigned to logical stream 0, generates + and answers requests to activate/deactive other application + programs and open/close the associated streams, and handles other + assorted general node functions. + (B) ECHO, allows testing of the support layers by sending data from + the master ECHO program to the slave ECHO program and back again, + then comparing to see if what came back was on the same stream and + with the identical data as what was sent. + (C) MAIL1, supports electronic mail (text files addressed to + people's mailboxes and to mailing lists, optimized for automatic + forwarding) and electronic file transfer (text or binary files + addressed to a particular file name; both in blind mode that + permits automatic forwarding, and in end-to-end negotiated mode). + +(A,B,C) all have what may be considered major level (4) of protocol, +interpretation of opcodes and arguments (syntax may be regarded as the +lower interface, semantics may be regarded as the upper interface) +communicated along one of the logical data channels between two +applications programs of the same type. +(C) also has what may be regarded as major level (5) of protocol, the +header of electronic messages that continues to exist even after the +connection has been closed and levels (1,2,3,4) have effectively +ceased to exist, and the interpretation (semantics) of the header. +Both (B) and (C) use (require) more than one logical channel (stream) +at their lower interfaces. + +We hope that many other applications programs, many using multiple +logical channels (streams) to simplify program logic (control on one +channel, data on another, for example), will be written and then run +over PCNET support layers. For example, one might write a +multiple-disk-channel server, and then random applications programs on +another machine can connect to it and act as if the disk were local, +reading and writing several files at the same time on the remote +system. Or one might install a multi-terminal TIP, multiplexed thru a +high-speed leased line using PCNET protocol, demultiplexed at some +Arpanet host into separate local jobs and/or TELNET connections, and +run some FTP or electronic mail task in background whenever no +terminal needs service. + +In summary, we start with a hookup to TPC (The Phone Company), which +supplies simple direct-dial switching and voice-grade connections, +then value-added services are as follows: Level 1 (modem&UART +hardware) provides unreliable octet-binary data communications, level +2 (turnaround, framing, translation, validation, sequencing) provides +one reliable block-of-octet-binary full-duplex data channel, level 3 +(directing) provides multiple logical channels connecting various +applications programs together, level 4 (online portion of application +programs) performs individually desired applications tasks, level 5 +(offline portion of applications software) maintains permanent data +structures such as electronic-mail archives&queues. + +File: PROTO, Node: Physical layers, Up: Proto + +PCNET uses the standard direct-dial telephone system together with +standard modems and UARTs or ACIAs. None of this is the invention of +PCNET. + +* Menu: + +* New hardware summary:: + Describes telephone system and what is needed to send data thru it. + +* Requirements for modem:: + Capabilities needed in a modem to be usable for PCNET service, + especially fully-automatic unattened operation. + +* Modem interface standards:: + PCNET-specified names for hardware-access primitives described above + +* CAT modems:: Message from EH and GENTRY about DL-11E and CAT modems + +File: PROTO, Node: Requirements for modem, Up: Physical layers + +[This was formerly in the separate file PCNET;MODEM REQUIR] + + August 1979 + +PCNET MODEMS +All telephone based data communication systems require modems to +function. The features required for a PCNET modem are as follows: + +Hardware Features + +-Receive sensitivity of at least -40dBm; -45 to -50 dBm preferred. + +-10 pole receive filter; 6 pole transmit filter. + +-300 baud operation. + +Features Under Software Control + +-Answer/originate mode select. + +-Switch hook control;pulse dialling. + +-Carrier detection. + +-Incoming ring signal detection. + +Desirable But Not Necessary Features + +-FCC Part 68 registration, permitting direct connection to +the phone line without an otherwise legally required +Data Access Arrangement. + +-Telephone signalling tone discrimination, allowing software to +detect DIAL TONE, BUSY, CALLED PARTY RING, etc. + +-Software selectable baud rate + +-Power up on incoming ring detect. + +The PCNET Project has found a number of modems that are suitable +for PCNET use. A list of them is given below. + +TYPE - S100 Compatible + +The MM-103, from +Potomac Micro-Magic, Inc. +First Lincolnia Bldg, Suite B1 +4810 Beauregard St +Alexandria,VA 22312 +Costs $359.95; is FCC Part 68 certified + +The Micromodem-100, from +D.C. Hayes Associates, Inc. +16 Perimeter Park Dr, Suite 101 +PO Box 9884 +Atlanta, GA 30319 +Costs $350.00; is FCC Part 68 certified + +The 88-MODEM, from +International Data Systems, Inc. +400 N. Washington St +Suite 200 +Falls Church,VA 22046 +Costs $395.00 + + +TYPE - Apple Compatible + +The Micromodem II, from +D.C. Hayes (see address above) +Costs $389.00; is FCC Part 68 certified + +TYPE - PET Compatible + +The TNW488, from +The TNW Corporation +5924 Quiet Slope Drive +San Diego, CA 92120 +Costs $320.00 + +TYPE - TRS-80 Compatible + +The AFFS Modem, from +Bill Abney +7600 E 48th Terr. +Kansas City,MO 64129 +Costs $299.95 +We have not seen the specs on this unit, but believe it to be +suitable for PCNET use. + + +File: PROTO, Node: New hardware summary, Up: Physical layers + +Here's a description of this layer from the point of view of +value-added services. + +The telephone switching system uses primitive on/off signals in +varying time-patterns to make&break connections. Lifting a phone +off-hook closes a circuit. If the phone is "ringing" from an incoming +call, this establishes a connection with the calling party. Otherwise +lifting off-hook connects the phone to a "dialer" unit in the central +office, which accepts sequences of on-hook pulses in an off-hook +background to convey a telephone number from the telephone to the +central office, to establish a connection with a remote phone. +Touch-tone (TM) phones use the same system for going off-hook but use +dual tones of audio frequencies to convey the telephone number to the +central office. After establishing a connection, voice and similar +signals may be sent between the two telephones. There's a little +crosstalk, but mostly there are two independent channels, one in each +direction. When either telephone (the one that originated and dialed +the call, or the one that answered) goes off-hook for longer than +about a half second, it signals the central office to break the +connection. The other phone gets a dead line for a while, then sooner +or later it gets a new dial-tone if it is still off-hook. + +During the time the two phones are connected, that is after +establishing a connection and before either hangs up, a voice-grade +connection exists between them. A modulator may be connected at one +end and a demodulator at the other end to transmit binary (two-valued, +i.e. on/off) data across the phone connection. When a zero value is +present at the input to the modulator, one frequency is sent +continuously, and when a one value is present another frequency is +sent. The demodulator discriminates between these two frequencies and +outputs a zero or one accordingly. Thus a modulator and demodulator +using the same pair of frequencies may send data in one direction +(from the modulator to the demodulator) across a voice-grade line. + +With both a modulator and demodulator at each end of the phone +connection, using two pairs instead of one pair of frequencies, with +the pairs crossed (one pair is used by the originate-modulator and by +the answer-demodulator, the other pair used by the answer-modulator +and by the originate-demodulator), data may be sent in both +directions, at the same time if there isn't too much crosstalk between +the two pairs of frequencies traveling in the two different +directions. A single device with both modulator and demodulator is +called a "modem" (MOdulator + DEModulator). If both parts can be used +at the same time, to transmit data in both directions at the same +time, it's called "full duplex", while if only one direction can be +used at one time, either because there's too much crosstalk or because +in fact only one pair of frequencies is actually used instead of two +pairs, it's called "half duplex". PCNET is designed to use modems in +either half-duplex or full-duplex modes. + +When binary data is sent/received in the above way, it's unclocked. +That means a zero can switch to a one or a one back to a zero at any +random time. The exact time at which it switched at the modulator +can't be determined at the demodulator because signals travel at only +the speed of light (or slower) and the two telephones could have an +arbitrary amount of wire between them. The duration during which the +signal stays at one before switching back to zero, i.e. the difference +between the times of the two events (switch zero-to-one, then switch +back to zero), or between any other two events, can be determined +since the transit time is pretty much a constant during one phone +connection, but only to a certain accuracy, typically about a +millisecond with low-speed modems down to a tenth of a millisecond +with medium-speed modems. If we can identify the start of a sequence +of on/off switchings, then we can measure the binary state at certain +times after that and determine whether a zero or one was being sent at +that time. If the modulator is given regularily-spaced data, and if +the the signal from the demodulator is checked for binary value in +the middle of each individual data value, the data values can be read +off with high reliability. This is how a UART or ACIA works. The +transmitter sends a continuous value of one until it's ready to start +sending a byte of data. Then it sends one datum of zero, then each of +the data in sequence, then at least one datum of one before starting +the next zero+data+one pattern. The receiver starts timing when it +sees the initial zero bit, samples the middle of each data bit, and +checks to make sure the final one bit is present. + +Usually eight bits of data are sent (oldstyle Baudot communication +uses only five bits of data, but PCNET uses the new eight-bit ASCII +method). An octet of data is fed (in parallel) to the transmitter, +which stores it in an 8-bit buffer. It waits until it's finished with +any preceding data plus the trailing one bit, then it sends the eight +bits of data from its buffer, one after another, starting with the low +order bit and ending with the high-order bit, and finally sends the +final one bit. The receiver sees the initial zero bit, stores the +following eight data bits, checks for the final one bit, and then +signals the computer that it's ready with an octet of data. The +computer then strobes the UART, and the the eight bits of data are +sent from the UART to the computer (in parallel). + +The result of all this equipment, from the computer's view (and from +the programmer's view) is that an integrated dialer&modem&UART device +is available with the following capabilities: + +Ring from an incoming call can be detected as a status bit. + +Under computer command, the incoming call can be answered. + +Outgoing calls can be established under computer command. + +Once a voice-grade connection is established, a modem&UART connection +is automatically established. (The answer modem puts up carrier, the +originate modem responds with its carrier and also signals its +computer that the modems are half-connected and presumably will be +fully-connected in a moment, and finally the answer modem sees the +originate carrier and signals its computer that the modems are now +fully-connected.) + +Once a modem&UART connection is established, status bits from the UART +tell whether there is any incoming data not yet fetched by the +computer and whether there is any outgoing data still being sent bit +by bit thus occupying the single-byte buffer in the UART. Whenever +status indicates incoming data available, the computer may fetch it. +Whenever status indicates the output buffer isn't busy with previous +data still in transit, and at the same time the computer has some data +it now wants to transmit, one byte of that data may be sent to the UART. + +There are two problems with this. First, the only reliable signals +obtainable from the telephone system are the incoming ring and the +remote carrier. In particular when first going off-hook to establish a +connection it's not possible to tell the difference between (1) +accidently picking up just as an incoming call arrives (2) getting a +normal dial tone (3) getting a dead line due to busy or broken +equipment. Also, after dialing, it's not possible to distinguish +between (4) a long pause before the telephone equipment actually +starts to ring the remote phone, often as long as fifteen seconds (5) +ringing (6) busy signal (7) wrong number or other out-of-order +condition (8) somebody answered the phone but didn't put up +answer-carrier. To solve all these initial-connection problems, it's +necessary to guess a little, to wait a couple seconds after going +off-hook to be reasonably sure a dial-tone is present, then after +dialing to wait perhaps ten seconds before checking for carrier and +continue to wait perhaps 15 more seconds before giving up. We just +have to live with this cruftiness by designing software with all these +allowences and timeouts. + +The second problem is that the voice-grade lines aren't entirely +noise-free. Those little chatters and clicks you hear when talking on +a phone can really confuse demodulators, making a zero where there +should be a one or vice versa. Adding the UARTs, we get missing data +because the start or stop bit was missing, extra data because a start +bit appeared out of nowhere, data with bits wrong because the noise +appeared during the data bits, and data that has been shifted because +an early or late start bit occurred. We have to live with this +unreliable data by designing software that distinguishes good from bad +data, eliminating the bad data and asking the data it should have been +to be retransmitted. + +In summary, the interface between the hardware (phone & modem & UART) +and the software consists of: + - Status of incoming ring detect and remote carrier present; + - Control to establish and terminate connections; + - Status of receive-data-available and transmit-buffer-busy; + - Receiving data and transmitting data; +with all the above subject to errors due to signalling deficiencies +and noise. + +File: PROTO, Node: Modem interface standards, Up: Physical layers + +In our 1980 PCNET workshop we decided to specify standard functions +for accessing the telephone interface (hook control, dialer, modem, +UART/ACIA), and to propose standard names for these functions. Later +REM wrote an 8080-asm interface to the PMMI modem according to these +specs, then realized a lot of code was duplicated between this PMMI +access module and his 88-2SIO module. He then proposed improved specs +which include all terminal-like I/O devices in a single unified +interface that shared as much code as feasible, and wrote a second +version of the 8080-asm interface using this new unified design. + +* Menu: + +* Original specs:(MC:PCNET;INTRO INFO)Hardware interface + (included in main protocol document, now treeified for direct access) + +* Proposed additions to specs:io1 new + +File: PROTO, Node: io1 new, Up: Modem interface standards + +* Menu: + +* Introduction to proposed changes:io1 new intro +* Change of wording in function of INITM:io1 change initm +* S = New function, select logical channel:io1 new selch +* G = New function, get current logical channel:io1 new getch +* Errata in SETOH:io1 change setoh +* Preliminary sketchy definitions of additional new functions:io1 new misc + +File: PROTO, Node: io1 new misc, Up: io1 new + +Some additional high-level functions have been found very useful in +writing PCNET software. They'll be documented here soon... +SELMO -- Select modem channel by calling SELCH with appropriate constant. +SELLO -- Select KBD&CRT channel by calling SELCH with appropriate constant. +R7WBT -- Call RCWBT and strip off the parity bit. +S1WBT -- Turn the parity bit on and call SDWBT. +S1WST -- Transmit string with mark parity by calling S1WBT for each + character of the string. +S1AST -- Same as S1WST except watch for ISTRR between each character. + If ISTRR comes true, abort the output-string. + +File: PROTO, Node: io1 change setoh, Up: io1 new + +OLD TEXT: + * Call SETOF(TRUE). +NEW TEXT: + * Call SETOH(TRUE). + +File: PROTO, Node: io1 new getch, Up: io1 new + +GETCH: --> NUM + Obtain the current logical channel number, i.e. tell what + channel was selected by the most recent SELCH. This is useful + if a subroutine wants to save and restore the channel number + but doesn't know (until it calls this function) what the + current channel number is. + +File: PROTO, Node: io1 new selch, Up: io1 new + +SELCH: NUM --> status + Select the logical channel to be used for subsequent + operations. Each implementation has its own conventions for + channel numbers, for example channel 0 might be the local + keyboard and CRT while channel 1 might be the modem. + +File: PROTO, Node: io1 change initm, Up: io1 new + +OLD TEXT: + Initialize modem after power-up or non-PCNET use. This + routine does whatever system-specific stuff may be needed + before the other routines will work correctly. +NEW TEXT: + Initialize modem and other I/O devices (local keyboard&CRT) + serviced by this package, after power-up or non-PCNET use. This + routine does whatever system-specific stuff may be needed + before the other routines will work correctly. + +OLD TEXT: + either in a high-level language or in machine language. These + routines perform almost all the functions called directly by the +NEW TEXT: + either in a high-level language or in machine language. Furthermore + they are uniform across all devices, thus they may be written once + for an entire system rather than once per device. (This is part of the + reason for having channel numbers. The low-level functions earlier can + execute different code depending on which device is currently + selected. These functions merely call those low-level functions in a + uniform way regardless of which device is currently selected. In fact, + these functions don't even have to know what channel number is + currently selected when they are called in order for them to execute + correctly.) + These routines perform almost all the functions called directly by the + +OLD TEXT: + routines, together with INITM and ISTRG, are the only routines ever + needed to be called from high-level half-duplex software such as PCNet + (checking ISTCA is implicit in the failure-return from various of + these routines). +NEW TEXT: + routines, together with INITM SELCH GETCH and ISTRG, are the only + routines ever needed to be called from high-level half-duplex software + such as PCNet (for example, checking ISTCA is implicit in the + failure-return from various of these routines). Full-duplex code will + also have to call ISTRR and ISTTR inside the polling routine or + interrupt handler. + Note that the internal workings of the next three functions (ORICL + ANSCL and ENDCL) are purely suggestive. Some kinds of modems don't + allow direct access to the mode-setting actions (SETOH, SETAN etc.), + doing things in a more streamlined way. In any case, it's the function + that is wanted, originating a call, answering a call, or ending a + call, that is wanted, not the particular sequence of internal workings. + + +File: PROTO, Node: io1 new intro, Up: io1 new + +Once a telephone&modem connection is established and the local and +remote UARTs or ACIAs are effectively in communication with each +other, the functions for sending and receiving data to/from the local +CRT and keyboard are analagous to those for sending and receiving data +to/from the remote modem via the telephone link. We have therefore +extended this "modem interface" to include multiple logical I/O +channels for handling both remote (modem) and local (direct) I/O +within a uniform framework. Functions relating to establishing and +breaking telephone and modem communications are of course defined only +for the modem, not the local CRT&keyboard. + +File: PROTO, Node: CAT modems, Up: Physical layers + + Message from EH and GENTRY about DL-11E and CAT modems + +EH@MIT-AI 09/09/81 22:41:01 auto-CAT and other good&cheap modems +To: GENTRY at MIT-AI, REM at MIT-MC +CC: EHUANG at MIT-AI + GENTRY@MIT-AI 09/09/81 00:07:14 + ... Anyway, in regards to your query about RS-232 ports on my machine. + Yes, I have a DL11-E interface for my unibus machine. It has complete + MODEM control and 20ma or RS-232 capabilites. I have one + attached to a second terminal on my system and the other is attached to + my A-J 300 baud coupler. As I mentioned in a previous letter, I have a + chance of getting ahold of a DF03 (DEC modem, $1700) for my use at home. + It has 300/1200 baud auto originate (dialing under computer control) and + auto answer. Unfortunately, I will not receive it until sometime in + october. It is my groups property, so I can't keep it. Ah, well... + +Blast! So thats what DEC,TI,IBM charges for things as they always +make BIG computers and charges LOTS of bucks..so,TI failed in their +personal computer attempt.. +So,here's the Novation 4202B auto-ans/org 1200 buad for $540. +Or 300 buad modems: +Novation AUTO-cat Org/auto-ans/dial $240 +Micropheral Corp Auto-COnnection Org/auto-ans/dial $270 +they use Rs-232 interface. My book says the DL-11e (Ihave a bunch +of DEC books) is one serial port/asych./with all control lines. +I would like to know how much the DL-11E costs! + +ps: I havea Novation CAT acoutics..maybe will buy a Auto-CAT +esp for PCnetting..SHouldnt be hard to get $240 from mother.. + +EH@MIT-AI 09/12/81 00:04:13 Re: auto-CAT and other good&cheap modems +To: REM at MIT-MC +CC: EHUANG at MIT-AI +SUPRISE!!!!!!!!!!!!!! MODEM-80 by ICROM Ents has auto-answer/auto-dial/org +and plugs directly into the TRS bus thus the $99 rs-232 is free for +other things! And it's complete with detailed software for binary/text +transmission between TRS-80s and its ONLY a cheep $210. +Remeber,this kind of modem plugs direct into TRS-80 so it cant be compared +with Auto-CAT but you can compare it with the MicroCOnnection and +Lynx which are $300 and $350 repectvely. + +File: PROTO, Node: Lower&middle PCNET layers, Up: Proto + +People who want a copy of this node when it's ready: + heller.umass-coins@UDel-TCP what I mainly want is the lowlevel packet format + tim.uci@Rand-Relay -- all of it?? + +Except for some random items at the end of this menu, +here are the different micro-layers of PCNET, presented as problems +and solutions (what communication problem exists, how does a +microlayer of PCNET protocol solve it), with the bottommost (nearest +modem) layer at the TOP (start) of this section of this menu. + +* Menu: + +Given full-duplex modems and UART/ACIAs talking to each other, over +noisy phone lines, with software incapable of full-duplex operation, +how do we reliably turn the phone line back and forth to emulate +half-duplex (taking turns talking) mode... +* Half-duplex microlayer:: + +Given that nodes are taking turns talking, how do we stuff one or more +packets of data into a turn-talking, in a way that doesn't get +confused badly when phone noise causes characters to occasionally get +modified, and sometimes even the UART goes out of correct frame... + Packet-framing microlayer:: + +Given that nodes are exchanging packets of data, possibly in a +restricted characterset consisting only of printing characters, due to +limitations of the operating system modem interface, how do we +represent binary data in this medium so that higher levels of protocol +don't have to use different protocols depending on what characterset +limitations are imposed, and so that in fact binary data may be +transmitted&received and the packet-header information may assume +arbitrary binary values... + Translation microlayer:: + +Given that nodes are exchanging packets of binary data, except error +due to phone line noise may appear, how to error-protect the packets +so that bad data is rejected, so that only good data gets through +unchallanged... + Validation microlayer:: (Could be called the "error-control" layer) + +Given that packets that appear wrong (both normal packets that have +been damaged by phone line noise, and bursts of noise that at first +appear to be additional packets but which don't pass the validation +checks) are rejected, how do we cause normal packets that were damaged +and rejected to be retransmitted so that we have another chance to +receive them correctly... + Sequencing microlayer:: (Analagous to packet-reassembly layer) + +Given that we now have a way to exchange blocks of binary data, with +virtually no errors present, how do we direct this data to various +programs and to various channels of a given program, so that for +example control information can be separated from actual data... +* Directing microlayer:: (Could be called the "Multiplexing" layer) + + Until I can get around to filling in all those menu items, refer + to this instead for all the above micro-layers... +* Old (1980) documentation:(MC:PCNET;INTRO INFO)Lower&middle + This is the treeification of PCNET;INTRO > + Just a one-level breakdown of that file into major layers. + + +Below are some miscellaneous items... + +* Explanation of Radix-41:: (Belong in Translation section) +* Worked out example of R41:: (Ditto) + +File: PROTO, Node: Half-duplex microlayer, Up: Lower&middle PCNET layers + +In summary, a node transmits about five lead-in characters (atsigns), +then one or more framed packets (see the next layer up for info about +packet framing), then five turnaround characters (brackets), then an +optional carriage return just to force IBM systems to let the program +see the preceding characters. + +See menu items for parity on lead-in and turnaround characters and +other detailed matters. + +* Menu: + +* Pre-info by Gilmore:(MC:PCNET;INTRO INFO)tr fr hdx intro + Preface to this microlayer and two others, by John Gilmore +* Documentation by Gilmore:(MC:PCNET;INTRO INFO)Half-duplex + Description of this microlayer by John Gilmore + +* Lead-in why:: Why do we need lead-in characters (atsigns)? +* Atsign-why:: Why do they have to be atsigns? + +File: PROTO, Node: Lead-in why, Up: Half-duplex microlayer + +When five turnaround characters (brackets) are sent by one node, the +other node stops receiving and gets ready to transmit as soon as it has +seen three of them. In this way if one or two of them are lost for +some reason, turnaround will still be effective. + +Now if the node that was receiving and is now transmitting starts +sending packets of data immediately, the first few characters of the +first packet will usually be lost by the other node because it was +still transmitting the last of the turnaround characters and hadn't +yet switched to receiving mode. Typical UARTs and ACIAs have room to +buffer only one character ahead, thus it's impossible for them to +retain all the characters that arrived while the node was still +transmitting. We're also assuming the software can't receive data +while transmitting (if it could, it would be using full-duplex mode +instead of half-duplex mode). + +Therefore we have to arrange that the node that is starting to +transmit doesn't send any real data (packets) until several character +times after it sees three turnaround characters. Since realtime delays +are not available on all machines, and timeouts (such as not +transmitting until the other node seems to have stopped sending) are +undesirable (tricky to program on most machines, unavailable on some), +the only solution seems to be to transmit a few characters of no data +value before starting to transmit real data. We decided to use the +same character as packet framing, to avoid the need for yet another +character beyond the fourty-five we already use (radix-41, packet +framing, two kinds of turnaround, and ). + +Sending five or so lead-in characters has a fringe benefit. The node +that just stopped transmitting can use these as a reliable signal that +turnaround has been successful, rather than waiting to see if regular +data arrives. Majority logic can be used, with 3-of-5 lead-in +characters being clearly distinguished from phone line noise. Also if +the node that is starting to transmit is very slow, it may not have +actual data available for several seconds, whereas it can transmit the +lead-in characters immediately, allowing for a short (5-10 second) +timeout to be used in this one place (elsewhere we use a longer +timeout, perhaps 50 seconds, since some systems on PCNET are *very* +slow and may take 20 or 30 seconds of processing to handle the data it +received and to get a block of data ready for transmitting). + +Note that only node needs to have timeout capability under our design. +If the node ending transmission doesn't see lead-in within ten +seconds, and it has timeout capability, it then re-sends turnaround +and listens for lead-in again. If that node doesn't have timeout +capability but the other node does, the other node times out after 50 +seconds of no data arriving, sends turnaround, and then the first node +tries again. It's not optimal, but it works. With both nodes having +timeout of course the delay is 10 seconds worst-case regardless of who +doesn't see turnaround. In any case, with 3-of-5 majority logic to +start with, timeout should be quite rare, and even the 50 seconds once +in a blue moon should be tolerable. + +File: PROTO, Node: Atsign-why, Up: Half-duplex microlayer + +In the process of turning the line around (in half-duplex mode) it's +possible for the UART/ACIA to go out of correct frame, for example by +crosstalk from the transmit side due to low-quality residential phone +lines and cross-country echo suppressors out of adjustment. Also +during normal data transmission the UART/ACIA can go out of correct +frame due to random noise spikes that override a bit of data, +especially the start bit. With normal data being received after the +out-of-frame condition is initiated, it's possible for this state of +incorrect frame to persist for a very long time. (REM) I've observed +this condition to persist for a full screenful of data, over a +thousand characters. It would be a shame if some transient during +half-duplex turnaround could create incorrect frame, and cause +half-duplex lead-in to be missed and/or cause a whole packet (or +several packets in a row) to come through as total garbage. Even +worse, the longer such a mis-frame persists the higher the likelihood +of some nasty control character to be seen instead of a data +character, some control character that for example aborts the PCNET +job and logs the terminal out or possibly even worse leaves the +originate node talking to a bare EXEC on the other machine, attempting +to execute Radix 41 packets as Tops-20 or Unix commands!!! + +To avoid loss of half-duplex lead-in (turnaround acknowledgement), we +try to put the UART/ACIA back into frame during lead-in. Since we +don't know when the other node will be done transmitting and start to +listen to the lead-in, we re-frame on each character. To avoid loss of +a packet unnecessarily due to some error that misframed the UART/ACIA +before the packet even started, we also reframe the UART/ACIA just +before the start-of-packet signal. To avoid proliferation of +characters, we use the same character for (1) lead-in, (2) UART/ACIA +reframing, (3) start-of-packet signal. This has the fringe benefit +that we don't have to alternate UART/ACIA reframing and lead-in +characters, we just send five or so of these combined-purpose +characters, the first one puts the UART/ACIA in frame and the rest are +actually received correctly as lead-in. + +I (REM) did experiments in 1977 when PCNET first started. I tried all +possible printing characters, making my 6502 spew them out at full +speed to my Beehive terminal, and glitching the incoming data every so +often by pressing some key (I forget which) on the Beehive +momentarily. Each time I pressed it the UART was thrown out of frame +and I got garbage on my screen instead of the correct data being sent +by the 6502. With every character except atsign it got into a +mis-framed state permanently, getting out only when I glitched it +again and by random luck the glitch put it in correct frame again. +With atsign, there were a few characters of garbage during the glitch +itself, but immediately after it reframed and gave me atsigns again. + +I then tried sending normal data with atsigns ever so often. When I +glitched it, there'd often be garbage until the next atsign, then good +data after that. Therefore I reccommended that atsign be chosen for +this magic multi-purpose framing character, and the PCNET Protocol +committee accepted my reccommendation. + +Note that atsign works this way regardless of the parity bit on my +Beehive, and I don't know why. It's easy to explain why it works with +mark parity, since the serial data is 0,0000001,1,1; i.e. start=0, 7 +data bits low-order-first, parity=1, stop=1), and thus there's only +one transition from 1 back to 0 (the signal to the receiving part of +the UART/ACIA to get ready to start the next character), at the start +of the next character, never in the middle of the character as would +be possible with most other bit patterns. Thus we specify mark-parity +atsign to be used where possible, although space-parity isn't too bad +(0,0000001,0,1), and does somehow magically work on my Beehive's UART. + +Note that mark-parity NUL (0,0000000,1,1), back-apostrophe +(0,0000011,1,1), lower-case-p (0,0000111,1,1), lower-case-x +(0,0001111,1,1), vertical bar (0,0011111,1,1), tilde (0,0111111,1,1), +and rubout (0,1111111,1,1) might be as good as atsign, but are less +likely to be accepted by upper-case-only text-only systems. Atsign +seems to be acceptable on all systems except some old Univacs an +possibly some Honeywells. + +File: PROTO, Node: Directing microlayer, Up: Lower&middle PCNET layers + +This layer might also be called the "Multiplexing" layer since it +multiplex several logical streams onto one physical stream. +Unfortunately Kim Harris insisted that random people with personal +computers don't know what "Multiplexing" means, hence "Directing". + +* Menu: + +* Formal specs:(MC:PCNET;INTRO INFO)Directing layer + +File: PROTO, Node: Explanation of Radix-41, Up: Lower&middle PCNET layers + + RAD41.WRU -- Explains Radix-41 + + EXPLANATION OF RADIX-41 IN PCNET + by Robert Elton Maas (REM at SU-AI,MIT-MC) + written 1977.Aug.27 via Beehive 3A terminal + +(Disclaimer: The Beehive 3A isn't worth the $3000 it costs +new, probably worth about $1200-1500, I got mine for $800.) + +INTRODUCTION + A lot of complaints about Radix-41 have been received, +mostly based on misunderstandings as to the use we make of it. +This writeup is an attempt to explain just what Radix-41 is, +what we are using it for, why we selected it, and under what +circumstances we will phase it out. + +DEFINITION + Radix-41 is a mapping between characters and the +numbers from 0 to 40 (decimal) defined as follows: ("(" = 0) +("0" = 1) ("1" = 2) ("2" = 3) ... ("8" = 9) ("9" = 10) ("A" = +11) ("B" = 12) ... ("Z" = 36) ("/" = 37) ("+" = 38) ("-" = 39) +(")" = 40). It was invented by Mike Wilber and first +presented in [Wilber Ciespec]. When applied to data being +transmitted over a serial I/O line such as RS-232 and/or +BELL-103, there is an implicit mapping composed of the usual +ASCII or EBCDIC encoding plus the Radix-41 mapping. Thus in +the case of ASCII Radix-41, the following composite mapping +occurs (in each tuple below, the first field is in bit-serial +binary as it appears on the line with start+stop bits and low +order bits of data first, the second field is in octal as DDT +might print it when examining a byte that has arrived via the +UART, the third field is an abstract printable character as +above, and the fourth field is a decimal number as above): +(00001010p1 050 "(" 0) (00000110p1 060 "0" 1) (01000110p1 061 +"1" 2) ... (01001110p1 071 "9" 10) (01000001p1 101 "A" 11) ... +(01011010p1 055 "-" 39) (01001010p1 051 ")" 40). When +receiving, the UART parses the serial input of bits and +creates the 8-bit byte, and the software (eventually hardware) +maps directly from the 8-bit byte to the decimal value 0:40 +with values above 40 reserved for special representing +non-Radix-41 characters received. + +PURPOSE + Serial I/O would seem to allow us to transmit and +receive binary data in 8 out of every 10 bits transmittid +across the line. But most computer installations have +installed hardware and/or software (usually the latter) which +severely restricts what can be transmitted and/or received. +The parity bit is usually set by a flag in the hardware to +always transmit odd or even parity with respect to the other 7 +bits, and this bit is almost always ignored upon receipt of a +character. Thus at most 7 bits of data can be transmitted or +received when talking to almost all existing timesharing +systems over dialup lines. We need to interface with such +systems in order to rent disk space which they have and most +personal computers don't have much of, and we want to be able +to exchange network mail with such sites and with the networks +they are on (Arpanet, Tymnet, Decnet, ...). Also, until +answering modems are cheap enough that most personal computer +systems can have them installed, we will have to rely on using +their answering modems, using timesharing houses as +intermediaries between personal computers that have only +originate modems. Thus we are virtually forced to use a +subset of the 7-bit characterset. + Most timesharing houses totally ignore certain +characters, for example IBM 360/370 systems ignore 177 +(rubout) and most DEC PDP-10 systems ignore 000 (null). Also +most systems have a large number of control characters +reserved for special purposes (DEC SYSTEM10: 003 to interrupt +system, 002 to hold and release output, 017 to kill output, +032 to terminate input file -- TENEX: 003 to put EXEC into +command mode, 024 to type out statistics of system load and +job running status, 037 to hold and release output). Due to a +several changes in the design of the ASCII characterset, and +current ambiguity about what certain character codes are +supposed to do, different systems have different +interprtations of the same character, and certain interfaces +between computers provide mapping between different character +codes that are supposed to have the same meaning at the +different computers (note in particular the following: +Carriage-return vs. linefeed vs. altmode vs. escape vs. +newline vs. backspace vs. leftarrow vs. underscore, altmode +vs. close-brace vs. tilde, and uparrow vs. carat). Eliminating +all control characters and other ambiguous characters, we are +left with the specials from 040 to 100, the uppercase letters +from 101 to 132, the specials from 133 to 135 and 140, and the +lowercase letters from 141 to 172, for a total of 89 +characters. + Several programming languages map lower case +characters to upper case, and also several low-cost computer +timesharing houses we might use do too, thus we have to +eliminate lower-case characters, leaving 63 characters. +Finally, BASIC which is the only language available on most +computers built as a kit from hobby stores, doesn't like to +see certain characters as input, namely 040 (space), 054 +(comma) and a few others. When inputting and one of these +characters appears, either the string of input is prematurely +terminated or the character is simply ignored. Thus we are +down to 59 characters. In order to reserve a few characters +for framing and other control functions (they must not be +characters used fo data), it is desirable to transmit our data +in a characterset somewhat smaller than 59 characters. 41 is +an obvious choice because 41*41*41 is slightly larger than +65536 thus two bytes of binary data can be transmitted every +three bytes on the line, thus minimizing the need to transmit +our data in blocks that are quantized by a large number of +characters, and simplifying the routine that unpacks +characters on the line to produce internal binary data. + Thus we have decided that in our protocol, at least +the first-year version that is compatible with existing +computer systems, at the very bottom (just above the UART) +will be a routine to translate between the Radix-41 +representation that is transmitted and received on the line +and the 8-bit binary representation that is used everywhere +else in our protocols. + Although division of two arbitrary numbers on a +microprocessor is rather slow, dividing by a known constant +can be compiled into a much faster routine that actually +multiplies by the inverse of the divisor (with appropriate +scaling because all numbers are integers). Mike Wilber and +Marc Kaufman have written 8080 routines that divide by 41 with +various time/space tradeoffs, one takes a lot of memory but is +very fast, the other is only moderately fast (but much faster +than division) but takes a tiny amount of memory. By escaping +to machine language routines on hobby computers, and relying +on the gross speed of the timesharing-house computers to do it +by actual division, the mapping from binary to Radix-41 should +run reasonably fast everywhere. The mapping from Radix-41 to +binary requires only multiplication by 41 and thus should run +reasonably fast everywhere without any special programming. + +CODING EFFICIENCY + When transmitting text (English or other natural +language using ASCII characters having their usual +interpretation, as contrasted with binary data representating +programs etc.), a simple compression scheme based on a +truncated Huffman code can be used to reduce the text data +into about 4 bits per character. After mapping this binary +data into Radix-41 we have about 6/8 of a character on the +line for each character in the English text. After adding +framing and checksums, and all the other overhead in our +protocol, we end up with about one character on the line for +one character of text data. The difference between +transmitting the original text across the line, and doing all +this mapping and encoding, is that we have gained (1) virtual +elimination of errors caused by phone-line noise, and (2) +ability to relay our text messages through arbitrary +intermediary computer systems without worrying about the +restrictions on charactersets that each enforces. This allows +us to implement the higher level protocols for automatic +forwarding of mail without worrying about a message going +astray due to line noise garbaging the address or any other +part of the header or message-proper. (The author plans to +use the lower levels of the protocol plus data compression to +alleviate the problem of losing edits and premature +terminations of messages due to the horrible amount of phone +line noise on the Ames-TIP, including Diffie-Hellman-Rivest +trapdoor codes for protecting transmissions against +eavesdropping -- it is impossible to encrypt and then decrypt +data if any errors happen during transmission of the encrypted +data.) + +ALTERNATIVES + The smallest fraction between 1/2 and 1/1 is 2/3, thus +if transmission of 2 bytes on the line for every 1 byte of +binary data is intolerably inefficient, and if transmission of +full 8 bits of data on the line is impossible due to +timesharing-house restrictions listed above, our 2/3 mapping +is the simplest in terms of the number of characters that must +be passed to and received from the machine language routine +that performs the mapping. Other fractions such as 3/4 or 4/5 +etc. require larger routines to perform all the special-case +mappings for each of the characters that come into the +routine, or else a loop with indexed shifting or other +operations that runs slower than a straight-line piece of +code. If we want to avoid division (simulated by +multiplication by the inverse that has been computed ahead of +time) we'll have to use either a 32-character-set (with 5/8 +mapping) or a 64-character-set (with 3/4 mapping). The former +is intolerably inefficient and suffers from an intolerably +large blocking factor. The latter is incompatible with almost +every BASIC in the world, making machine language from the +UART thru the conversion to 8-bit binary mandatory, thus +preventing implementation on any timesharing house that offers +BASIC (with no machine-language routines allowed) as the only +programming language. + +PHASE OUT + When enough personal computers have answering modems +so that direct personal-computer to personal-computer links +become the rule instead of the exception, we will start +publishing ICP (Initial Connection Protocol) for those systems +which have dial-up ports that initialize themselves in 8-bit +mode instead of Radix-41. Dialout nodes that can handle 8-bit +mode will be encouraged to dial into one of these ports rather +than dialing into a Radix-41 ICP port and switching to 8-bit +mode after ICP. When virtually every node has 8-bit mode and +our directory of dial-up ports servicing 8-bit mode is +complete enough to make 8-bit mode the rule rather than the +exception, we will announce that Radix-41 is no longer the +standard. + After 8-bit mode has become the standard, it too will +gradually be replaced by one of the several bit-oriented line +protocols such as HDLC (these protocols require special +hardware which isn't yet on the market at prices hobbyists can +afford, and none of the competing protocols has yet become an +industry standard, hence we aren't even specifying in our +protocols what this will be, although we are rather sure that +that general type of protocol will totally replace +start+7+parity+stop within 5 or 10 years). The same procedure +for advertising nodes that can handle the not-yet-standard +protocol, and eventually making it the standard, will apply. + +BIBLIOGRAPHY + [Wilber Ciespec] ARPANET SRI-KL CIESPEC.TEXT + + +File: PROTO, Node: Worked out example of R41, Up: Lower&middle PCNET layers + + RADIX-41 Worked-out example + +Date: 17 Dec 1978 0148-PST +From: Robert Maas +Subject: How to go from T to AWB +To: FFM at MIT-MC + +Data entry: The character on your keyboard is hexadecimal 20 inside +the computer. The character T on your keyboard is hexadecimal 54. + +Binary to Mod-41 conversion: See the "Simplified Protocol" document, in +the transmit pipeline, for description of packing two bytes into a 16-bit +value then dividing by 41 twice to get two remainders and final quotient. +0B 21 0C (hexadecimal) are the remainders and quotient. + +Mod-41 to Radix-41: See the table right after that description where it +shows what Radix-41 characters correspond to which Mod-41 bytes. + +File: PROTO, Node: Node-control program, Up: Proto + + In addition to activating application-programs and assigning +stream numbers, the NODE-CONTROL program has some duties of its own. + +* Menu: + +* Exchanging node IDs:NODEID +* Invoking application programs:OPNSTR +* Terminating communication:BYEMSG +* Everything else:NODECTL misc + +* Old info on this subject:(MC:PCNET;INTRO INFO)Node-control + +File: PROTO, Node: NODEID, Up: Node-control program + +The NODEID message exchange (see interim mail protocol) +causes global variables to be set and/or a log entry to be made, +identifying the node to which communiction has been established. +Application programs such as MAIL1 may consult this information +to help make decisions about forwarding of mail or willingness to +accept mail at all. + +* Menu: + +* Node IDs:: Rigid formatting of latitude&longitude&phonenumber&hostname + +File: PROTO, Node: BYEMSG, Up: Node-control program + +The BYE message exchange (see interim mail protocol) causes the phone to be +hung up. + +File: PROTO, Node: NODECTL misc, Up: Node-control program + +* Menu: + +* General info from APPPRG.PRO:nodectl summ +* Old specs for node-control opcodes, from PROTO WR2:nodectl prowr2 + +File: PROTO, Node: nodectl prowr2, Up: NODECTL misc + +[Note, some of these opcodes, proposed in 1978 in PROTO.WR2, conflict +with newer ones installed during or after the 1980 workshop. +Presumably these old ones will have to be changed.] + + The mapping between server-level functions +and PURE-BINARY-DATA-STREAM bytes +needs two more items of information before it can be considered +completely defined, a table of opcodes and arguments for +control messages (messages to process 0), and a similar +table for messages sent between other processes (together with +a narrative of how process-to-process protocol +works since that hasn't yet been stated clearly). + The 8-bit opcode (for both control and server-process) is +composed of two parts. The two high-order bits (hexadecimal +mask C0) contain a flavor code, +and the 6 low-order bits (mask 3F) contain the type of message code. +Together, this 8-bit field is called the "opcode" and determines +how many arguments will follow and what they mean. Flavors +are listed here in binary:\. +\F0 00 = I WON'T (00) + 01 = PLEASE DON'T (40) + 10 = I WILL IF OK WITH YOU (80) + 11 = PLEASE DO IF YOU CAN (C0) +\F1\JThe idea (invented by Arpanet for the "New Telnet" protocol +which became the default for TIP software sometime in 1977 summer) + is that if a node receives a 10 or 11 flavor message +it doesn't understand at all, it can refuse whatever was +requested or offered by merely returning an identical message +with these two bits complemented (10 to 01, 11 to 00). +If it receives a 00 or 01 flavor message it doesn't understand +at all, it simply ignores it. +In either case, the receiving node wouldn't know how many bytes +long the message is, but since each control message occupies exactly +one PPS, the receiving node simply ignores or NAKs the entire PPS. +For the mail/ftp server, the relation between the request and the PPS it is in +isn't 1-to-1, so the situation +is more complicated and no +satisfactory uniform method of +NAKs has been designed. +Probably the receiving node will simply ignore anything +it can't understand. + Arguments (parameters) are listed beside each flavor of +each opcode where needed. Arguments are numbered 1,2,... in +consecutive order (each number represents one 8-bit byte), where +0 represents the opcode+flavor byte itself. Where a single +parameter requires more than one byte, for example control-3A +in flavor-11 (bytes 2 and 3 are amount of additional-allocation), +the first (lower-numbered) byte is the lowest-order part of +the numeric value. The exception to this rule is any parameter +that is in ASCII text, for example as control-01 flavor-10 + (MY NODEID IS ...), +where normal left-to-right printing sequence is used. + For control messages, the 6-bit type-of-message codes have been assigned +so-far as follows (hexadecimal). Arguments are +shown with their bytes numbered 1,2,... Note that required messages +are numbered 01, 02, ... to allow a simple table lookup and dispatch +to a routine to handle them, 00 is assigned to Close-Connection-Protocol, +and optional messages are numbered from 3F downward to leave +room at the lower end for more required messages to be +added later:\. + 01 = MY NODE ID IS + 10-FLAVOR ARGS: 1,2,... = ASCII NODE IDENTITY (UP TO END OF PPS) + 02 = SWITCH TO FDX + 03 = SWITCH TO 8-BIT TRANSMISSIONS (MUST ALREADY BE IN FDX) + + 00 = HANG UP PHONE NOW (CCP) + + 3F = (ESCAPE TO EXTENDED OPCODE SET IF EVER NEEDED) + + 3E = SEND LTBs UP TO THIS LENGTH (MINIMUM=7, MAXIMUM=255) + 11-FLAVOR ARGS: 1 = MAXIMUM NUMBER OF CHARACTERS IN LTB + 3D = CHANGE N-OF-8 WINDOW FOR LTBs + 11-FLAVOR ARGS: 1 = NUMBER OF LTBs IN WINDOW I CAN ACCEPT (MAXIMUM=4) + 10-FLAVOR ARGS: 1 = # OF LTBs I'LL SEND YOU (unnecessary) + 3C = SEND HDX UP TO THIS MAXIMUM TOTAL NCHAR + 11-FLAVOR ARGS: 1 = NUMBER OF CHARACTERS + 3B (THIS CODE WITHDRAWN, IGNORE) + 3A = INCREASE TEMPORARY DATA ALLOC BY THIS MANY BYTES + 11-FLAVOR ARGS: 1 = PPS-NO AFFECTED IN DESTINATION NODE + 2,3 = AMOUNT OF ADDITIONAL ALLOCATION + 39 = TELL WHAT VERSION OF SOFTWARE + 10-FLAVOR ARGS: 1,2,... = ASCII VERSION ID (UP TO END OF PPS) + 11-FLAVOR, NO ARGS + 38 = UNSYNC LT-BLOCKING FROM PPS-BLOCKING + 37 = BACK TO RADIX-41 MODE + +File: PROTO, Node: nodectl summ, Up: NODECTL misc + + In advanced nodes, additional NODE-CONTROL messages may be +used to change parameters of operation, such as switching to +full-duplex or changing the baud rate. These matters are not +discussed in this document. Also in advanced nodes, it's possible for +the answer node to request an application program and the originate +node to grant it. In such a case the words "originate" and "answer" +must be reversed in the above descriptions, for example the answer +node would then be the initial master and the originate the initial +slave in the MAIL1 program, and the originate node would be echoing +data back to the answer node in the ECHO program. + +File: PROTO, Node: Application programs, Up: Proto + +Each application program is a separate entity, performing some useful +task for the person invoking it or for some higher level of protocol. +Each application program has its own protocol for communicating with +its mates. That protocol is the main topic of the application-program +descriptions below. The user-interface might also be described, but +that isn't really a proper matter for PCNET protocol specs to decide, +since two programs with totally different user interfaces can talk to +each other if they use the same protocol. + +* Menu: + +* Invoking application programs in the first place:OPNSTR +* Notation used in protocol descriptions below:App notation +* Logical streams and their numbers:App streams + + Application programs whose protocol has been defined... +* ECHO:: Test echoback at application-program level. +* MAIL1:: Message-style (header&body, allows forwarding) + electronic mail and file transfer. Source and final recipient + don't have to be online at the same tie, providing forwarding + nodes are up at appropriate times to accept and forward the data. + +Other application programs whose design is in progress or planned... +* FTP1:(MC:PCNET;DEBATE INFO)Deb FTP1 + End-to-end live-style (no forwarding allowed) file-transfer and + mail fetch/store. Both source and recipient must be online simultaneously. + +* TELNET:: Remote single-channel virtual terminal login. +TCPIP -- Encapsulates TCP/IP datagrams into PCNET packets. +* INFO:(MC:REM;MISC INFO)Net INFO Access an info-tree database remotely. +GAME -- Ties into a network of gamesters, matching players and refereeing + their online games with each other. +UNTALK -- Two-window talk with other user, one person types in one window + and other in other, thus allowing true full-duplex chatting, both can talk + at same time without interupting each other. +* EWIND:: Remote multi-channel virtual terminal login using multiple + edit-windows to control the various logical terminal channels. + +%% end-user applications +LABEL WRU Proposal for PCNET service of making labels remotely + +File: PROTO, Node: EWIND, Up: Application programs + +Please read and understand the TELNET protocol before attempting to +read this. Also to appreciate this service one should be familar with +multi-window editors such as EMACS and/or with multi-window shells +(execs) such as various Xerox systems, Swinehart's ETV-based proposal, +the ETV-based interface to MacLISP "EMACLS" at SU-AI, the similar +EMACS-based interface to MacLISP at MIT, Apple's LISA, or the +Buroviseur proposed by the KAYAK project at INRIA. + +This is a generalization of the TELNET and the NVT (Network Virtual +Terminal) protocols. It is designed to make full use of CRTs and other +display terminals with random-access screen update. The basic concept +is still that the user is typing on a keyboard and seeing results on a +CRT. The difference is that the CRT screen is divided into windows, +and each window corresponds to a different logical stream to the host. +Furthermore, while some windows will be operated in standard +teletype-emulator mode (keys pressed are sent immediately, and +whatever comes back is display, typically end-to-end echo of what was +typd plus anything output by the remote program), others may be +operated in remote-display mode (keys pressed are still sent +immediately, but the remote host has total control over what appears +in the window), or in local edit mode (keys pressed cause the screen +to change locally, nothing is sent to the host except when a special +SEND-THIS command is typed or after the mode is changed back to one of +the other modes). + +While text typed on the keyboard is normally sent to the job currently +selected (the job corresponding to what window the cursor is currently +in), text output from ANY of the jobs is immediately send from the +host to the local system which upon arrival causes the appropriate +window to be updated. Thus the user may be interacting with one +program actively while watching several other jobs on the side. + +Text that appeared as program output in one window may later be edited +locally and/or copied to some other window. Thus it's easy to prepare +documentation containing edited transcripts of online sessions without +disturbing the still-running program being documented. Text that was +read in from a file in an edit window can be copied to another window +so it can be fed as input to a remote program. Or for a simpler case, +the user can be running some long program and editing an unrelated +document on the same terminal at the same time, running the program in +on window but editing in the other window most of the time, +occasionally watching to see how the long program is coming along. + +It's even possible for single programs on suitable hosts to be +connected to more than one PCNET EWIND stream, and thus be able to +produce output of different types into two different windows. For +example normal echo of typed input may appear in one window, normal +program-to-operator output may occur in a second, error diagnostics +may be emitted in a third (and the local system may be set to beep +whenever anything is sent to this window), and finally two files of +actual desired output may be written, one on the remote system and one +into yet a fourth window on the local system. + + * TESTIMONIAL BY REM * +I believe this kind of multiwindow interface, with many more specific +features like splitting or appending two windows, making some windows +invisible, keeping a window-status meta-window around, ... is the +shell of the future, both for operating local multiprocessing systems +and for operating remote systems via a network link from the local +workstation/system. + +File: PROTO, Node: TELNET, Up: Application programs + +The purpose of the TELNET (also called virtual-login or +virtual-terminal or remote-login) protocol is to allow somebody to +connect across the net from his/her terminal to some host without +being subject to errors caused by phone-line noise on the way. In the +case of PCNET, it simply means an error-free link between the terminal +and the CBBS or other host. + +The simplest implementation will have no method to abort data already +in route. The abort facility is important on the Arpanet where perhaps +a half minute of data may be en route and it's painful to have to sit +and watch it stream out after a command to abort that and switch +context has already been received at the host and acted on. But with +direct single-link connections such as PCNET the abort facility is not +essential. + +Nevertheless some commands may need to be sent along a different +channel from the ordinary data. Thus TELNET will use two logical +streams, one for ordinary data and another for end-to-end magic +commands. (But at this time no actual end-to-end commands will be +defined here.) + +SPECIFICATION: + +The application program is called TELNET. Ordinarily the originate +node requests service which is granted by the answer node. Ordinarily +the node requesting the service is the "master" or "user" while the +othernode is the "slave" or "host". In the description below, "local" +will mean "master" or "user" while "remote" means "slave" or "host". + +Two streams are allocated, #1 for TELNET-control messages and #2 for +normal data. Any key pressed on the local keyboard is sent along +stream #2 to the host where it is entered into the input buffer of a +virtual terminal port assigned to the user. Ordinarily the user will +first send a command to log in, then will send text +(monitor/exec/shell) commands to various programs and data text to +those programs. Finally the user will send a command to log out. + +All data output from the host thru that virtual-terminal port will be +send back along stream #2 (remember all PCNET streams are +bidirectional) where they will affect the CRT or teleprinter in some +way. Ordinarily text characters will be written on the CRT or typed on +the teleprinter while control characters will affect cursor or +carriage movement. + +It is possible that certain keys on the user's keyboard will be +defined by software in that local computer/PCNET system to affect the +local computer/system instead of being immediately transmitted to the +remote host. Some of these local effects may be to generate control +messages along stream #1. Anything sent along stream #1 will be +intercepted and acted upon by the remote TELNET program. Possible +effects are to directly modify the environment of the user's job that +is running on the remote system underneath the virtual terminal +interface, or to indirectly affect that remote job by generating (at +the host!) some text that is spliced into the stream of data coming +into the host system from PCNET stream #1. + +It is also possible for the host system to send TELNET-control +messages back to the local system along stream #1, either replies to +TELNET-control messages sent earlier from the local system to the host +system, or new messages totally initiated by the host PCNET system. +For example, the host might send a message indicating the host system +will be going down for maintenance in five minutes, and in response to +this the local system might want to flash a warning countdown at the +bottom of the screen or sound a beeper or even turn off the television +set to avoid distraction during the critical last minutes. + +Note that unlike the Arpanet TELNET protocol which uses a single +bidirectional stream, and thus needed to insert commands on the data +stream by sending a code of hexadecimal FF preceding each command, and +thus needed a way to quote FF if it ever appeared as normal data; +PCNET uses two streams, so the one dedicated to data is totally +transparent to 8-bit data and doesn't need any escape or quoting +mechanism. + +Since the New-Telnet protocol on the Arpanet has withstood a lot of +usage and experience, we might choose to simply use their protocol as +is, with the only difference being the separation of control and data +streams. Would anybody object to that? (I could FTP the relevant RFC +and edit it to be correct for PCNET, and insert it here for reference.) + +File: PROTO, Node: App streams, Up: Application programs + +STREAM NUMBERS. + As far as the application program is concerned, it can send +and receive data on any of n logical channels starting with channel 1. +Thus it can use channels numbered 1 thru n. The number of channels +depends on the application program. ECHO uses all 63 available channels +while MAIL1 uses only 2 channels. + The actual channels as specified in the directed-block depend +on whether SIMPLE or ADVANCED mode is being used. In SIMPLE mode, the +offset between logical channels used by the application program and +the actual channel numbers is a constant hexadecimal 40. Thus channels +41 thru 40+n are actually used. Lazy programmers intending their software +for use only in simple nodes may write it to actually use logical channels +41 thru 40+n instead of 1 thru n, and thus avoid the mapping. It's not too +hard later to upgrade it if and when mapping is installed. Note that +because of the constant offset, only one application program may be active +at any one time, because otherwise the stream numbers would conflict, +regardless of whether constant-offset is used or lazy-programming with +no offset at all is used. + In ADVANCED mode, the offset is variable. ECHO must exist by +itself, but MAIL1 may co-exist with other programs (not yet designed +at the time of writing this document). For example, MAIL1 may be +invoked first and get channels 41 and 42 (logical 1 and 2, offset 40), +then TTY may be invoked and get channel 43 (logical 1, offset 42). +Since the first (or only) program invoked always gets an offset of 40 +when requested by the originating node (the normal mode of operation), +SIMPLE and ADVANCED nodes may talk to each other freely using what +amounts to SIMPLE-mode protocol. + All the protocols and examples in this document will assume +SIMPLE mode. Stream numbers given will be logical, with the offset +of 40 supplied by the directing layer by turning on or off a bit. +The reader can make the appropriate modification to obtain the +fullblown ADVANCED protocol specification. + +<> +When we decided to allocate all streams for a process at the time it's +invoked (rather than have each process keep one stream open even when +the process was inactive, as our pre-1980 protocol did), we had the +choice of making streams uni-directional or bidirectional. If +uni-directional, then receive and transmit streams would have to be +allocated separately, increasing the code needed to allocate streams +and the table space needed to keep track of them, as well as the +protocol needed to tell the other node what streams were allocated to +a given process. We therefore decided to make all streams +bi-directional. But in full-duplex there's a possible problem. Suppose +that at some moment when both the originate and answer nodes are idle, +they each come up with something they want to do. For example +originate says "Please Do open MAIL1" while answer says "Please Do +open TCPIP". Suppose the packets requesting these services are en +route in opposite directions at the same time, that is each starts +before the other finishes. The tables of unused stream numbers are the +same on both nodes, so it's likely that each machine will allocate the +same stream to the other. Thus two different applications programs +will be using the same stream, and total confusion and crash of the +protocol can be the only result. To avoid this problem, we decided to +split the space of possible stream numbers into two parts, determined +by the high-order bit of the seven available (the high-order bit of +the directing octet is already used for the End-of-Data bit). This bit +(hexadecimal 40) is set according to the node that allocated the +streams, which is the stream granting the request for service. To +avoid confusion, stream zero in BOTH parts (i.e. streams 00 and 40) +are reserved for node-control, leaving the remainder (i.e 01-3F and +41-7F) for allocating to application programs. Of course in simple +mode where only the originate node can request service and only the +answer node can grant the request, only the range 41-7F is used. + +File: PROTO, Node: App notation, Up: Application programs + +NOTATION. + Examples of this protocol are given in a notation that combines +values of various parameters (direction between the two nodes, stream number +end-of-data bit) and the program-to-program (directed) data itself. +The data is given as a combination of hexadecimal-notation and actual ASCII +text, in the same format as input and output by the LISP program PCNSR6. +Here's an example: + O-->A STREAM#43 EOD: C2 "Test." +This is being sent by the Originate node and received by the Answer node, +using stream number 43 (hexadecimal), with End-Of-Data bit set, and the +data consists of a byte with hexadecimal value C2 followed by five bytes +of text "T" "e" "s" "t" and ".". (Text is with the high-order bit equal +to zero, for example "T" is hexadecimal 54 rather than D4. Note that +the above example could also have been presented as: + O-->A STREAM#43 EOD: C2 54 65 73 74 2E +which would have been correct but too obscure to the reader. + +File: PROTO, Node: MAIL1, Up: Application programs + +* Menu: + +* Introductory paragraph, from start of APPPRG.PRO:MAIL1 intro +* Latest protocol specs, from body of APPPRG.PRO:MAIL1 specs +* Old specs from 1978, from PROTO.WR2:MAIL1 prowr2 + +* Global considerations that affect MAIL1:glob cond + +File: PROTO, Node: glob cond, Up: MAIL1 + +* Menu: + +* Node IDs:: How nodes are addressed for purpose of elec. mail + + +File: PROTO, Node: MAIL1 prowr2, Up: MAIL1 + +[Warning, a lot of stuff here needs to be cleaned up!!] + + For FTP/MAIL server-processes, the following 6-bit type-of-message +codes have been assigned (hexadecimal): + 01 = INIT FTP (IFTP) + 11-FLAVOR ARGS: 1,2,3 = EXPECTED LENGTH OF FILE IN BITS + 10-FLAVOR ARGS: 1,2,3 = GUARANTEED FILESIZE ALLOCATED + 4,5 = MAXIMUM BUFFER SIZE THAT CAN BE FILLED + BEFORE GETTING ACK TO PROCEED WITH MORE + 6 = PPS-NO OF REQUEST THIS IS REPLY TO + 02 = ACCEPT THIS FILE + 11-FLAVOR ARGS: 1,2,... = DATA OF FILE (TO END OF PPS) + 10-FLAVOR ARGS: 1,2,3,4 = CHECKSUM AT EOF (0 IF NOT COMPUTED) +\J The overall way this works is that some process sends an +IFTP request to process 1 (the FTP/MAIL listener) and upon receiving +a I WILL reply to it the data is sent in a ACCEPT THIS FILE message +until the buffer allocation is filled, then transmission is +suspended until an ok for one more buffer is received. +After end of file, the transmit PPS is closed, and upon +receiving an ack of the entire file the checksum is compared +(if implemented and return checksum is nonzero). + The initial buffer allocation given in the I WILL IFTP +message has a special meaning if it is zero, namely that accounting +for allocation isn't being done, and hence the full size of the file +is allocated or can be allocated as fast as it is likely to be sent +over the link. Otherwise (nonzero allocation) the receiving node +(which sent the I WILL IFTP message) is guaranteeing that it will keep +track of buffer fullness and grant additional allocations as it empties +its buffers. If the file is less than 2^16 bits, another way to grant +the full allocation at once is simply to specify the file size in the +initial allocation. + + With all that at hand, it should be easy to +figure out what various internode messages will become in binary. +Here are the internode messages described above in the REM to HILLMAN +netmail relay. English (as used above) is at left (messages +from node#0 to node#1 are uppercase, from node#1 to node#0 +are lowercase), extra explanation +is in parenthesis:\. +\F0\N + F/L/..../MOD8 PPS-NO LEN SRC/DES/DATA +PLEASE DO FDX C 0 00 06 00 00 C2 +\F1\N + (8=0,000=(LAST-BLOCK-BIT=1, MOD-8-BLK=0) + C2=11,000010=(PLEASE DO, FDX)) +\F0\N +I will fdx C 0 00 06 00 00 82 +PLEASE 4-OF-8 C 0 01 07 00 00 FD 04 +Please 4-of-8 C 0 01 07 00 00 FD 04 +PLEASE DO 8-BIT C 0 02 06 00 00 C3 +My node id is C 0 02 27 00 00 81 33342E35...3041 +MY NODE ID IS C 0 03 28 00 00 81 33372E32...2D31 +I won't 8-bit C 0 03 06 00 00 03 +\F1\N + (C3 changed to 03 and repeat back rest of not-understood request, + which in this case is nothing except low-order 6 bits of C3=03) +\F0\N +PLEASE UNSYNC C 0 04 06 00 00 F8 +I won't unsync C 0 04 06 00 00 38 +PLEASE IFTP, I'LL SEND 1997 BITS + 8 0 05 09 01 01 C1 0007CD +I will iftp, I'll accept 2000 bits, each buffer 255 bytes, re PPS-NO 05 + 8 0 05 0C 01 01 81 0007D0 00FF 05 +"MAIL:34.52N... ... ..." (text of message) + 0 1 05 F9 C2 4D41494C... + 0 2 05 F9 ...... + 4 3 05 53 ...CD18 +Ack ftp 4 1 05 08 82 00 00 00 00 +\F1\J\N +(Note that these nodes aren't allocating PPS buffers (using +opcode (11)3A = FA) because with only one active stream blockage of +the whole link due to PPS-buffer constipation doesn't do any harm. +If data in the FTP is sent faster than node#1 can unbuffer it, LTBs +are simply not-acknowledged and node#0 retransmits them.)\. +\F0\N +PLEASE CCP C 0 06 04 00 00 00 +I will CCP C 0 05 04 00 00 00 + +File: PROTO, Node: MAIL1 intro, Up: MAIL1 + +MAIL1 is the first version of a MAIL/FILE +transfer program. It can send mail addressed to the other node, send mail +to other nodes via forwarding, collect (receive) mail for a specified +geographical area, negotiate to send a file to the other node (no +forwarding possible), and negotiate to receive a particular file +from the other node. By using the protocol for forwarded mail, +with a slight change in the header, files may be sent blindly with +forwarding, and requests may be issued (with forwarding) for files +to be sent back (again with forwarding). + +File: PROTO, Node: MAIL1 specs, Up: MAIL1 + +MAIL1 PROGRAM. + +* Menu: + +* General way MAIL1 operates:MAIL1 operat +* Opcodes and operation for "accept mail":MAIL1 accept +* When done with initiating requests:MAIL1 qru +* Summary of header format and usage:MAIL1 serpro +* More complete description of header format:(MC:PCNET;SERPRO TTY)* + +* Differences from "interim mail protocol" used in workshop:MAIL1 intdif + +File: PROTO, Node: MAIL1 intdif, Up: MAIL1 specs + + The protocol used by MAIL1 is essentially the interim mail +protocol defined by John Gilmore and implemented in existing software, +except (0) the commands defined here are sent on logical stream 1 (the +MAIL1 control stream), rather than logical stream 0 (the node-control +stream), thus are interpreted directly by the MAIL1 program instead of +by the node-control program; (1) ECHO command is flushed since it +belongs in the ECHO program; (2) BYE command means terminate this +process, not hang up the phone (The same BYE command, when issued by +the NODE-CONTROL program, i.e. on logical stream 0, means hang up the +phone.); (3) NODEID command is flushed since it belongs in the +NODE-CONTROL program. + Persons who have already implemented the interim mail protocol +may use that code for MAIL1 by making the above changes and by using +logical stream 1 instead of 0 for exchanging service requests. + For those who wish to implement MAIL1 from scratch, here's +the complete specs of the protocol: + +File: PROTO, Node: MAIL1 operat, Up: MAIL1 specs + + When MAIL1 is first invoked, the originate node is the master +and the answer node is the slave. The originate node issues requests for +service which the answer node either grants or rejects. When the +originate node is finished, it issues a PLEASE-QRU (I have nothing for you, +do you have anything for me?) command. The answer node then becomes +the master and the originate node the slave, so that the answer node +issues requests which the originate node grants or rejects. Finally +when the answer node is done too, it issues an I-WILL-QRU command +and exits, returning the node to the idle state when node-control +messages may be handled. + +Note, the term "QRU" comes from amateur radio Q-signals. +There doesn't seem to be anything more mnemonic that means the same thing. + +File: PROTO, Node: MAIL1 accept, Up: MAIL1 specs + + While MAIL1 is active, requests for services and grants/rejections +are passed on logical stream 1, data on 2, and end-of-data acknowledgements +on 3. + C3 = PLEASE-DO ACCEPT-MAIL + 83 = I-WILL ACCEPT-MAIL + 03 = I-WON'T ACCEPT-MAIL + The master issues a C3, and the slave replies 83 or 03. If the +slave accepted (83), data is passed from master to slave on stream 2, +the last block having EOD bit set. When the slave sees EOD on stream 2, +it processes the message to see if the header is correct and the message +can be delivered or forwarded. It issues a reply on stream 3 which is +"GOOD:..." or "BAD:..." depending on whether it is accepting responsibility +for delivering the mail or not. "..." may be any explanatory text, for example +some nodes say "GOOD:thanks for the good header" or "BAD:no header". + EOD is always set on the request&reply on stream 1 an on the +end-of-message final-ack on stream 3. (Multiple-block service requests +and acks are not permitted here.) EOD is set only on the last block +of the data on stream 2. + +Proposed change: None of the stream-1 commands take any arguments, but +I'm planning to add length-of-message-in-bits to both C3 and 83. I'm +thinking of 3 bytes, high-order-first. If all three bytes are zero, +it means "I have no idea how long the message is but I think it's +short enough to be acceptable to you". + +File: PROTO, Node: MAIL1 qru, Up: MAIL1 specs + + C1 = PLEASE-DO QRU + 81 = I-WILL QRU + These are used to relinquish masterhood to the other node, +as described in the introductory paragraph above. If the answer node +has no mail that it wants to send to the originate node, or the +answer node isn't programed for automatic downloading of mail, then +C1 from the originate node will be followed immediately by 81 from +the answer node, as if to grant the requested service of being done. +Otherwise reverse-direction (answer=master, originate=slave) requests +will appear after C1 and before 81. + Of course if the originate node isn't programmed to handle +reverse (answer-->originate) forwarding of electronic mail, or if +it's calling long distance and is unwilling to pay for the phone call +during reverse transfer of mail, it may either sit online refusing +all requests for service, or it may just hang up impolitely. + +File: PROTO, Node: MAIL1 serpro, Up: MAIL1 specs + + The data transferred via the ACCEPT-MAIL protocol consists of +a header, a blank line, and some text or binary data, as specified by +SERPRO TTY. Briefly, the header contains one or more "MAIL:" lines +specifying the destination of the mail, one "FROM:" line specifying +the originator, an optional "SUBJECT:" line and any number of other +random lines. The "MAIL:" lines must be before all other lines. Binary +(non text) data may never be put in the header. Binary data may be +put after the blank line only if the node accepting the mail is known +to be able to handle the binary data AND the header somehow warns that +binary data will follow, such as by saying that it's compressed or +encrypted. -- As an alternative to "MAIL:", the header may begin with +a "FILE:" or any of several other services, but none of these are +implemented in any software presently known to this author. + +* Menu: + +* Node IDs:: as used in MAIL: and FROM: lines + +File: PROTO, Node: Node IDs, Up: MAIL1 serpro + +* Menu: + +* Bourn adr:: Original proposal with rationale + [Current specs not extracted from PCNET;SERPRO TTY yet, see that file] + +File: PROTO, Node: Bourn adr, Up: Node IDs + +From the file (now deleted in favor of this info-tree frame): + 16 BOURN 1 0 +907 9/18/82 18:57:36 (8/18/83) REM + + A Proposal for Addressing Stations of the Personal Computing Network + + by Doug Bourn + + 19 May 1977 + + Among the proposed addressing schemes discussed at the last meeting +of the protocol committee were zip codes (with suffix extensions) and +latitude and logitude values. Each method has certain advantages. +However, I believe that any addressing system adopted for the PCNet +should have the following features: + + 1. Relatively easy comprehension by humans. + 2. A sufficiently universal framework to be implemented anywhere on the + planet. + 3. Some inherent form of interstation direction and distance. + 4. A capability for dynamically altering the size and location of + regional zones. + +The rationale for each of these features follows. + + Point 1 results from my conjecture that many computer hobbyists +will want to "try the network" with very minimal hardware (e.g. +a Penney-Whistle modem and a TV Typewriter). Thus, interfacing to the +network will be a manual operation for the most part. An address +which is understandable to humans would accommodate such experimentation +and would supply a potentially large number of nodes to the network. + Point 2 envisions the expansion of the PCNet to neighboring countries +and beyond. Already there is significant computerist activity in Canada. +Any addressing philosophy considered should be applicable to cultures +lacking a domestic structure such as the zip code system. + Point 3 allows intelligent routing decisions to be made. As the +PCNet matures it may be more economical to use radio links over certain +routes rather than land lines. + Point 4 presumes the existence of arbitrarily defined service areas. +The size of these areas might be determined by the number of nodes within +its borders. A node in a service area or regional zone would store the +addresses of each of the other nodes in the zone. Overlapping zone boundaries +would guarantee a path from one node to any other node in the network. +The size of the zone would decrease as the density of nodes increased. +Thus, a relatively small table of addresses could be maintained by a +given node. + In view of the considerations outlined above, I propose the following +addressing arrangement. On the lowest level, a station address would +consist of a telephone number or radio station call letters suffixed by +an extension number or name. A unique and highly understandable address +is thus created. + On a higher level, values of latitude and longitude could be used to +define service areas. A node would contain a table of values corresponding +to the boundaries of its service zone. As a message enters a zone the +receiving staion compares the longitude and latitude components of the +message address with those stored in its table. If the message target is +within the current zone, the station forwards the message to the node +specified by the low level address. If the target is outside the current +zone, the message is sent in the direction computed from the difference +between the latitude and longitude parameters of the message and those of +the current zone. This forwarding operation is accomplished by referring +to a list of addresses of nodes within the current zone boundaries as +described above. + A header supplying routing information would consist of the +originator's address, the final destination address, and an intermediate +destination address which would be modified as a message was forwarded from +zone to zone. An example of such a header might be: + + FR:40.33N110.35W/333.123.4321.JOHN/TO:35.52N100.46W/402.233.4545.MIKE/ + VIA:38.22N104.31W/908.456.3241.DON + +[Note by REM, this isn't exactly the format we eventually decided + upon, see other info nodes for the exact format.] + +While such an address may consume more bandwidth than say a zip code +based system, I believe that the universal nature of the scheme outweighs +its disadvantages. + In conclusion I offer two additional comments. First, the problem of +determining one's latitude and longitude is solved by calling a local +airport or a branch office of the U.S.G.S. Second, broadcasting over +the PCNet might be accomplished by omitting the final destination +address (or at least the low level portion) from a message header. +A message so transmitted would be disseminated in a tree-like fashion. + +File: PROTO, Node: ECHO, Up: Application programs + +ECHO is a test program to echo back (on the same stream) whatever +data is sent to it. + +ECHO PROGRAM. + The ECHO program is simple. The answer node acts as a slave +under control of the originate node, just echoing back anything +sent to it, on the same stream. For example, if the originate node +ECHO program sends: + O-->A Stream=25: "Hi, this is a test." 0D 0A "Another line." 0D 0A +the answer node will reply with: + A-->O Stream=25: "Hi, this is a test." 0D 0A "Another line." 0D 0A + If End-Of-Data is seen on ANY nonzero stream (that is, any data +stream, any stream except the node-control stream), ECHO exits, returning +to the state when node-control messages are accepted. + +File: PROTO, Node: DUMMY, Up: (MC:PCNET;PCNET INFO)Top diff --git a/doc/teach/ulisp.bugs b/doc/teach/ulisp.bugs new file mode 100644 index 00000000..727465fd --- /dev/null +++ b/doc/teach/ulisp.bugs @@ -0,0 +1,496 @@ +Date: 12 May 1980 01:22-EDT +From: Kent M. Pitman +Subject: Fixed. +To: BUG-ULISP at MIT-MC + +Date: 11 May 1980 23:09-EDT +From: Kent M. Pitman +To: BUG-ULISP + +Traced functions don't seem to be capable of being applied ... + +Date: 11 May 1980 23:09-EDT +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +Traced functions don't seem to be capable of being applied ... + +Date: 11 May 1980 21:21-EDT +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC +cc: GJC at MIT-MC + +ULISP should support a subst operator. + +Date: 1 May 1980 06:05-EDT +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +Date: 10 April 1980 13:52-EST +From: George J. Carrette +To: KMP + +illeagal memory write a 11056 or something. + +When they try and print out circular list structure (sigh...) +which can happen quite easily in the problem set, they get +;UNRECOVERABLE FIXNUM PDL OVERFLOW + +sometimes it just gets a PDL oveflow. + +I tried (setq foo '(a b)) +(rplaca foo foo) +and got a pdl oveflow. +then did ^b, o.k. then (cons foo foo) +threw me out to the monitor. I then used "start" to get +back in, futsed around for a while, and then got +things into a state where PAO had to bring the system down. +No kidding. Anyway, I think you need to put in a PDL +handler. You might have to write the printer using a go-to +instead of recursion. Which is a thought. I was talking to +JPG the other day about how crufty MEVAL1 was. He said it +was because it couldn't be written modular because of lack +of stack space. YUK. Do you know of a clean way, using macros +perhaps, to get tail recursion in maclisp compiled correctly? + +-gjc + +Date: 25 April 1980 01:01-EST +From: Kent M. Pitman +Sender: ___051 at MIT-MC +Subject: PROGN/PROG2 in ULisp +To: GJC at MIT-MC +cc: BUG-ULISP at MIT-MC + +Yeah, Leigh pointed out the PROGN problem a couple days ago and it's been fixed +in MC:TEACH;TS ULISP and [EE]ULISP.EXE.122 for a while now ... + +PROG2 is in the macros package (tho' actually not a macro). I will probably +make PROGN, PROG2, and a few others (probably DO) be special forms (=> FSUBRs) +pretty soon. But it's not worth the efficiency loss to have PROG2 do a check +for number of args ... a bad arg to cdr message for (PROG2 arg) or (PROG2) +is sufficiently informative I think. + +-kmp + +Date: 24 April 1980 17:03-EST +From: George J. Carrette +Sender: ___077 at MIT-MC +To: BUG-ULISP at MIT-MC + +(progn) i.e. no arguments. gives bad arg to cdr. +(prog2) also gives a lusing error message. + +Date: 22 Apr 1980 1741-EST +From: Leigh L. Klotz, Jr. +To: bug-ulisp at MIT-MC + +(progn) causes an obscure error. + +I got this while using displace inside a defmacro. + +Leigh. +------- + +Date: 16 April 1980 17:28-EST +From: Kent M. Pitman +To: MP at MIT-MC +cc: JIS at MIT-MC, PAO at MIT-MC, GJC at MIT-MC, CPR at MIT-MC, + BUG-ULISP at MIT-MC + + Date: 16 Apr 1980 0124-EST + From: MP at MIT-EE (Mark A. Plotnick) + To: kmp + Re: ftp to ee + + JIS says you have a program which enables the sending of 36-bit + byte files to and from EE. Could you tell me what it is? +----- +On MC:TURNIP;ASCII FASL are two functions ASCII->BINARY and BINARY->ASCII. +They each take two args of filenames. Eg, + + (BINARY->ASCII '((DSK FOO) BAR >) '((DSK FOO) BAR ASCII)) + +makes an ascii file. Then do text transfer to EE and load up ASCII.FASL +and do + + (ASCII->BINARY ...) + +to undo the effect. Sorry it can't all be done as one job -- I don't hav the +time to hack that up. But this has worked for me getting the latest ULisp +fasl over there, so maybe it'll do for you until they get FTP fixed. Let +me know if it gives you any problems. If you're paranoid, you can do +the inverse function on MC and verify that the file you get back out is the +same as the original. There is a third function in that file named +BINARY-COMPARE that takes two filespecs and tells you if the two are the same +and if not what the first word is where they differ. (Does no output, just +returns the info as a lisp list.) + +-kmp + +Date: 11 Apr 1980 1922-EST +From: KMP at MIT-EE +Subject: Patching the symptom: REGPDL overflow and Illegal Memory Write attempt +To: 031.ANDRE at MIT-EE, GJC at MIT-MC, BUG-ULISP at MIT-MC +cc: INFO-ULISP at MIT-MC + +The REGPDL overflow and illegal memory write error you reported is still +around -- a combination of several Maclisp bugs -- not yet resolved. But +I have put prinlevel/prinlength into ULisp, as you probably saw in system +messages (yeah, i know -- routed announcement to wrong place, oh, well). +Documentation in ULISP.NOTES ... -kmp +------- + +Date: 8 Apr 1980 1746-EST +From: KMP at MIT-EE +Subject: (((empty (((empty ... +To: 031.ANDRE at MIT-EE +cc: BUG-ULISP at MIT-MC + +Kinda too bad about that ... it's a Maclisp bug, by the way, not just +a ULisp bug -- hence I don't know what to say really. We will try to +trace it down and get it fixed as soon as possible... -kmp + +ps It's also a Maclisp bug that you end up in a ;BKPT PDL-OVERFLOW + when the stack runs out the first two times before the fatal error. + I have code that would trap all errors if the error trapping code + would just do its thing right ... sigh. + +------- + +Date: 8 Apr 1980 1603-EST +From: 031.ANDRE at MIT-EE +Subject: A bug in Ulisp (!) +To: bug-ulisp at MIT-MC +cc: jis at MIT-EE, pao at MIT-EE, 031.gunning at MIT-EE + +Printing an "infinite" list structure 3 times seems to trash the lisp. +Try loading morris.lsp and then: +Lisp->(setq foo (create-board)) +Lisp->(aref foo 0 0) || Three times. + -- Dave +------- + + +10003 +*** EOOH *** +Date: 7 April 1980 04:57-EST +From: Kent M. Pitman +To: JIS, GJC, HAL, CPR +cc: KMP + +I am now keeping a source to ULisp on EE. This source should be read-only +for the following reasons: + +(1) The lisp compiler on EE probably does not know about SFA's. + +(2) The master copy of the source lives on MC:TEACH;ULISP > and I don't + want to get an accidental divergence with copies on two different + systems being editted. + +I would prefer if people did not edit the file at all -- leaving it for me -- +In extreme emergencies (heaven forbid) this may, of course, not be possible. +If you do find a need to edit the file, be sure to tell me that you did +and what changes you have made. Write the file out to a higher version number +and make sure the version number is preserved in transfer to EE so we can tell +what version is installed. Until FTP starts to work more reliably, +the FASL for such changes should be mag-tape transfered to EE rather than +net-transfered. + +I will see about making a CTL file for dumping out a new ULISP.EXE and/or +a description of the process in case this needs to be done while I'm not +around. + +-kmp +Date: 7 April 1980 04:58-EST +From: Kent M. Pitman +To: JIS at MIT-MC +cc: BUG-ULISP at MIT-MC + +Btw, in case i forgot to mention it, the current ulisp.exe is running in your +new maclisp. the old ulisp.exe (same ulisp version, older maclisp) lives in +OULISP.EXE.108 and will go away in a day or two if this one seems to be +winning ok. -kmp + +Date: 5 April 1980 21:08-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +Date: 30 March 1980 19:34-EST +From: George J. Carrette +To: JIS at MIT-AI +cc: LISP-6001 + +KMP and I talked the other day about ways to speed up ULISP, +[1] have every defun and lambda create a closure by default, this + will speed up the search down the a-list since lexical environments + are usually small. +[2] special case the "global" end of the a-list. All KMP has to do is + redefine his look-up-in-alist function so that when it gets to the + **END*OF*ALIST** it does some faster thing like GET. (PUT for SETQ). + +There are some things to do which will slow down ULISP a little. +[1] generate a warning message when built-in functions are + "redefined" by using them as lambda variables. +[2] certain features ala TEACH;LISP maybe. + + -George + +Date: 5 April 1980 05:38-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +Date: 1 Apr 1980 0937-EST +From: JIS at MIT-EE +To: KMP +cc: cpr at MIT-EE +Re: UNIX LISP + +I have installed a bootstrap in SUBSYS called LISP that +when invoked, arranges to call ULISP.EXE so Kent ULISP.EXE +in your directory is now the "Live" version of the program. +MacLisp can be invoked by typing "maclisp." + + -Jeff + +Date: 5 April 1980 05:37-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +Date: 2 April 1980 00:35-EST +From: George J. Carrette +To: KMP +cc: JONL + +I think you should get rub-out processing somehow. +even if it means writing your own reader. (even if it means +that I have to write it.) I was lusing my ass an hour ago, +didn't realise that ^q is needed after a ^L. Even if you +do ^B you still get no response until the blasted ^q, which +must be seen by the operating system I suppose. Lusing ^Q ^S, +!!!!!. I want -MORE- !!!!. + +Kent, is there any way to get 20 maclisp to win easily on tty I/O? + +Date: 5 April 1980 04:41-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +Date: 04/04/80 10:58:38 +From: JEFERY at MIT-AI +To: KMP at MIT-AI + +Some observations which I find a little confusing, and which +there might some fix: + +if a student inadvertantly changes his directory on TOPS-20, +is it true he must type (fr (\031\.{name}) {name} lsp) to +get his stuff into LISP? How about (fr |031.{name}| {name} lsp)?? + +if a student names his file something simple (i.e., no extension), +is it true there is nothing he can type at lisp to get it? +How about (fr {name} nil)?? or (fr |{name}..|)? + +Perhaps a student message that warns of these, and says what the best +course a action is would be appropriate ... ? + + Mark Jeffery + +Date: 5 April 1980 04:41-EST +From: Kent M. Pitman +To: JEFERY at MIT-AI +cc: BUG-ULISP at MIT-MC + +Please send your comments to BUG-ULISP@MC so that it gets filed correctly. + + Date: 04/04/80 10:58:38 + From: JEFERY at MIT-AI + + Some observations which I find a little confusing, and which + there might some fix: + + if a student inadvertantly changes his directory on TOPS-20, + is it true he must type (fr (\031\.{name}) {name} lsp) to + get his stuff into LISP? How about (fr |031.{name}| {name} lsp)?? + +This is incompatible with Unix Lisp and will only serve to confuse people. +In fact, you only have to type (031\.{name}) which is less typing than +the |...|'d form. If and when we split off the two versions and do this +one 'right' then we can make such modifications trivially. Right now I am +trying to go to reasonable lengths so that people can say the two lisps +are equivalent. + + if a student names his file something simple (i.e., no extension), + is it true there is nothing he can type at lisp to get it? + How about (fr {name} nil)?? or (fr |{name}..|)? + +yeah, this is a problem, but the reason it is is because maclisp hacks +filenames in this way and it happens to work out fine. there are several +ways he can get it (i think -- haven't tested them) ... (fr fn1 ||) should +work ... if not, then try (load 'name\.\) ... sigh ... + + Perhaps a student message that warns of these, and says what the best + course a action is would be appropriate ... ? + +Well, I advertise in ULISP.NOTES that files should be named with +an extension of LSP so that they will read right in lisp without specifying +filename2. + +Sorry, it sounds like i don't appreciate your comments when really i do... +don't want it to sound like i'm writing you off -- just saying these happen +to be issues i've thought about in some degree and how i've ended up deciding. +let me know if my answers seem unsatisfactory and we'll hash it out some +more. see you later. +-kmp + +Date: 5 April 1980 04:35-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +Date: 4 April 1980 11:39-EST +From: Chris Ryland +To: KMP +Re: (STATUS LINMO) + +Kent: Ok, I think this is the right thing to do for the students' sake; +admittedly, it is sort of a screw that you can rubout over line boundaries, +but this should be fixed someday, no? Actually what's needed is a zwei- +like editor that is totally integrated with the top-level of lisp so you +never worry about these issues... + +Date: 5 April 1980 04:34-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +Date: 4 April 1980 11:40-EST +From: Chris Ryland +To: KMP +Re: Unix/Twenex Lisp Differences + +We just discovered this am that you can't specify a non-existent file +extension in uLisp (eg, morrow..1), or else we don't know how. I +tried nil, and it didn't buy it... + +Date: 4 April 1980 15:37-EST +From: Kent M. Pitman +Sender: JONL at MIT-MC +Subject: Unix/Twenex and Morrow..1 +To: CPR at MIT-MC +cc: BUG-ULISP at MIT-MC + +People should be using the extension LSP and not be specifying files anyway. +I suspect that doing (MORROW \ \1) will probably do it. So should the +string 'MORROW\.\.1 so take your choice. I recommend not using +the non-existent extensions, tho'. + +Date: 3 Apr 1980 0154-EST +From: KLOTZ at MIT-EE +Subject: arrays, character hacking +To: bug-ulisp at MIT-MC +cc: klotz at MIT-AI + +Addressing the nil'th element of an array is the same as referencing +the 0'th element. This screwed me when I got the order of arguments +to aset wrong. + +Also, this may not be the proper place, but... + +Even if the terminal is in page mode, print out something large +(like doing (getal)) scrolls off the screen. +Leigh. +------- + +Date: 2 April 1980 09:08-EST +From: Kent M. Pitman +Subject: (STATUS LINMO) +To: BUG-ULISP at MIT-MC + +Date: 28 March 1980 09:21-EST +From: Chris Ryland +To: KMP +cc: HAL, JIS, PAO +Re: linemode in twenex ulisp + +Kent: I would agree with you in theory --that we don't want to give people the +inconvenience of not being able to delete back arbitrarily far-- but remember +that these poor unix lisp students have never had that luxury, so it would be +much more 'compatible' to use the twenex linemode. (Someone correct me if +I'm wrong about real unix lisp.) And, I don't understand why the Maclisp +implementation is stupid enough to make linemode thwart full rubout handling +-- it certainly is doable (well, I guess I know why, since it's probably alot +of work). Comments? + +Date: 2 April 1980 09:07-EST +From: Kent M. Pitman +Subject: LPR/LPT fix +To: BUG-ULISP at MIT-MC + +Date: 28 Mar 1980 1126-EST +From: Chris Ryland +To: kmp +Re: lpt: is reinstated for now...let's say lpr: is the right thing + +to use, and this won't change when lpt: goes back to being tty:. + +Date: 29 March 1980 22:08-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +KMP@MIT-MC 03/29/80 22:06:41 +To: HAL at MIT-MC +CC: JIS at MIT-MC +Unix Lisp doesn't seem to let you say (add1 1.0) -- you get a non-numeric +arg (=> floating point arg) error. For the time being, I am going to set +things so that this is an error on floating point with my stuff as well. +I think that given how you are handling some of those other math operators, +that add1 and sub1 should be willing to do coercion. + +Unix Lisp also returns t for (and 'foo 'bar). Up 'til now my simulator has +been too. (or 'foo 'bar), according to PAO, who I just called up to have this +checked, does return foo (which is reasonable). I am changing the simulator +to give back t for (and 'foo 'bar) but I think that's a real loss. bar should +get returned as it does in maclisp. + +Applying and mapping nlambda's and fsubrs is currently still undefined in +my simulator. You get something utterly different than you would get in real +unix lisp. If you are going to want me to support things like +(mapcar '(nlambda (x) x) '(a b c)) => ('a 'b 'c) -- which I think is a +crock -- let me know and I'll install it, but I think it's very ugly. +Currently if you do that in mine you get just (a b c). Note also that this +means that +(mapcar and '(a nil b)) => (t () t) +in Unix Lisp but is undefined in the simulator (actually errs out, I suspect). +Let me know your thoughts on this subject. +-kmp +^_ + +Date: 25 March 1980 16:10-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +System functions should not get bashed if redefined. + +Date: 25 March 1980 16:02-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +(defun foo nil (print nil)) + +Date: 18 February 1980 15:02-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +what does (flodiv 3 4) return on delphi? + +Date: 18 February 1980 10:45-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +The "Lisp->" message should not display when reading from files. + +Date: 18 February 1980 10:44-EST +From: Kent M. Pitman +To: BUG-ULISP at MIT-MC + +This is a test. + diff --git a/doc/teach/ulisp.debug b/doc/teach/ulisp.debug new file mode 100644 index 00000000..d424dfe7 --- /dev/null +++ b/doc/teach/ulisp.debug @@ -0,0 +1,95 @@ +Debugging in ULisp KMP 25 April 80 + +------------------------------------------------------------------------------ + + Break Loops + +A Breakloop is just like the toplevel evaluation loop except it is a temporary +interruption of the evaluation of some other form, and as such occurs in a +context where some bindings from that evaluation may have taken place. +Breakloops may be unconditionally invoked from code by + + (break) or (break evaluated-message) + +or they may be conditionally invoked by + + (break evaluated-message evaluated-condition) + +where if the evaluated-condition returns non-(), then the break will occur. + +The function recover will become defined in a breakloop and can be used to +return from a breakpoint. With no args, it simply returns (value undefined), +or with one argument it will return that value. #### It may be that +recover will not always work. This is a known bug which will hopefully be +fixed soon. Report instances of it to speed service. #### + +When in a breakloop. You will see a prompt like: + +[Break Level n] +Lisp-> + +unless you do (prompt nil), which will of course suppress all prompting. + +------------------------------------------------------------------------------ + + Debug + +Debug is a system-provided stack-debugger. It can be used to explicitly +invoke the debugger from a breakpoint by typing (debug) or it can be caused +to activate automatically on an error by doing (backtrace debug). Disabling +of this feature is by (backtrace nodebug). + +Debug commands are one character. The following commands are available: + +? Gives short help description. +H Offers to document one or all commands. + +. Type out current stack frame in abbreviated form. +T Type out current stack frame in normal form, no abbreviation. +P Type out current stack frame in pretty-printed form, no abbreviation. + +F Displays all stack frames in abbreviated form. + +A Goes to top of stack +U Goes up a stack frame. + +D Goes down a stack frame. +Z Goes to bottom of stack + +B Gives a breakpoint at current stack frame level. + +C Continues from current stack frame by re-evaluating that form. + (Presumably this should be done if you have first done a "B" + and corrected the error or if the error was caused by external + conditions such as the file system which have since been cleared.) + +R Returns from the current stack frame by reading an expression from the + terminal and returning the value returned by that expression rather + than anything to do with the frame which had initially been at the + current form on the stack... + +Q Quits the debugger. If invoked from the error handler, control returns + to the next higher breakpoint or toplevel read-eval-print loop. + If invoked from (debug), then returns from that invocation. + +------------------------------------------------------------------------------ + + Quit Characters + + #### These are likely to change in the very near future #### + +Currently Likely to Become Description +--------- ---------------- ----------- +Control-B Control-G Quits to toplevel + +Control-X Control-X Error, or local, quit + +none Control-B Runs a break loop + +------------------------------------------------------------------------------ + + Tracing + + #### No trace facility yet exists. One is planned #### + +------------------------------------------------------------------------------ diff --git a/doc/teach/ulisp.info b/doc/teach/ulisp.info new file mode 100644 index 00000000..6fd321bb --- /dev/null +++ b/doc/teach/ulisp.info @@ -0,0 +1,258 @@ +Date: 12 May 1980 01:50-EDT +From: Kent M. Pitman +Subject: Closures +To: INFO-ULISP at MIT-MC + +Also, closures are their own datatype now and print as #. +-kmp + +Date: 12 May 1980 01:46-EDT +From: Kent M. Pitman +Subject: Tracing +To: INFO-ULISP at MIT-MC + +Versions of ULisp 156 and up (:TEACH;XULISP on MC currently the only such +thing) have trace capability. See the file TEACH;ULISP TRACE on MC for +details, or just load up a ULisp with the capability in it and try +(trace name1 name2 ...) and then run the functions. Comments welcomed -- the +i/o style is kinda wierd, taken from Rutgers Lisp, but probably helpful. +-kmp + +Date: 25 Apr 1980 1141-EST +From: KMP at MIT-EE +Subject: ULisp debugging +To: INFO-ULISP at MIT-MC, 031.ANDRE at MIT-EE + +The ULisp debugger which lives in all versions from 121 up is documented in +MC:TEACH;ULISP DEBUG and [EE]UDEBUG.INFO.0 for those who forget how +it works. It will be moved to a more public place if/when it gets released. +To run that version of ULisp, you can use :TEACH;ULISP on MC or +XULISP on EE. +------- + +Date: 20 APR 1980 0757-EST +From: KMP at MIT-MC (Kent M. Pitman) +Subject: You asked for it! +To: INFO-ULISP at MIT-MC + +I have released ULisp.121 on MC. Anyone who has time to play with it +is encouraged to do so. Differences... + +(1) Speedup. Alist lookup should now work in more or less + constant time if you have few local variables rather than + being dependent on the depth of your global var in the global + area. This can be as much as a factor of 40 speedup on looking + up some symbols, but probably averages in the range of a factor of + 10 speedup. There should be no user-visible change in how this stuff + works other than that new global variables go on the front of the + global area instead of the tail. + +(2) Debugging. We can quibble about what the default debugging mode should + be but I have all the bells and whistles enabled for this version on MC. + The following debugging features are new... + + (a) (debug) is a system-provided stack-debugger. Documentation on this + will be created. Please play with it and send me gripes/comments. + Basically, you can walk up and down the stack, ask to return a value + from a particular place on the stack, get a debug breakpoint at any + stack frame, or retry evaluation of a stack frame. + (b) (break [ message [ condition ] ] ) gives a debugging breakpoint. + *Important* -- The function "recover" becomes defined in a break + loop. It accepts an optional argument of a value to return from the + break. If someone would like to suggest a better function name to use + for this purpose, I'd be glad to take it... No fair "return" -- that's + strictly for (ugh) progs... and I'd rather not look for P + (c) ^X quits locally (to breakpoint or debugger) + ^B quits globally + Would anyone object strongly to making ^G, ^B, and ^X have the + ULisp analog of their Maclisp meanings? This might be less confusing. + (d) (backtrace debug) enables automatic running of (debug) on errors. + (backtrace nodebug) disables automatic running of (debug) on errors. + +(3) Break levels. You can't fall out into Lisp as easily. Lisp errors give + ULisp debugging breakpoints. [Break Level ] displays if you have + prompting selected to remind you of what's going on. Remember (as above) + the function "recover" will get you out of most breakpoints. MacLISP + makes you create thousands of different handlers to cover all the cases, + so please let me know where "recover" doesn't work from if you run across + such a place. I'm pretty sure PDL overflow is such a case and this will + be fixed soon. + +(4) Some improved error messages. Wrong-Type-Arg and Wrong-No-of-Args now + give nicer error display. + +I'll go over all these changes again to make sure all the code looks +reasonable when I am more awake. In the meantime, there has been such a +massive amount of added code that some exercising will do it good. + +-kmp + +ps No, there is still no trace facility. I will put one in soon -- I know + it is lacking. + + +Date: 11 Apr 1980 1922-EST +From: KMP at MIT-EE +Subject: Patching the symptom: REGPDL overflow and Illegal Memory Write attempt +To: 031.ANDRE at MIT-EE, GJC at MIT-MC, BUG-ULISP at MIT-MC +cc: INFO-ULISP at MIT-MC + +The REGPDL overflow and illegal memory write error you reported is still +around -- a combination of several Maclisp bugs -- not yet resolved. But +I have put prinlevel/prinlength into ULisp, as you probably saw in system +messages (yeah, i know -- routed announcement to wrong place, oh, well). +Documentation in ULISP.NOTES ... -kmp +------- + +Date: 9 APR 1980 1746-EST +From: HAL at MIT-MC (Hal Abelson) +To: INFO-ULISP at MIT-MC + + +i just spent an hour trying to help a 6.03 students debug a lisp +program. it seemed that every time she read in her file it would +clobber lisp ``do.'' + +the reason, it turned out, was that she had in her file a definition +of ``reverse'' that used ``do''......... + +KMP@MIT-MC 04/05/80 00:45:06 +To: INFO-ULISP at MIT-MC +ULisp.108 is now the standard on Unix. Features: + +(1) There was a gruesome bug in the way ULisp subscripts were being converted + into appropriate accessors for internal arrays. This affected non-linear, + non-square arrays and made 031.ANDRE's Morris solution die awfully. Anyway, + the bug has been squashed. + +(2) More type checking -- array subscripts are now more extensively + type-checked. also, rplaca and rplacd also do typechecking for + their first arg now. + +(3) At RZ's request, we have implemented a way of getting at MacLISP + functions. Don't advertise to students as it is likely to confuse them -- + this is mostly for implementing aids to them -- but if you do + + (import functionname propname flag) + + where functionname denotes a maclisp function name, + propname denotes its functional type (one of [SUBR, FSUBR, LSUBR]), + and flag denotes whether function should eval its args or not in + ULisp. If no, then function had better be a function that can get + called with one arg, as it will receive a single arg which is the + list of unevaluated args. The ULisp subr or fsubr pointer is + returned. + + Scenario: + + (setq fasload (import FASLOAD FSUBR nil)) | enable fasloading + (fasload (foo) bar fasl) | load helper file + (setq nifty-aid-for-students (import MYFUN SUBR t)) | import compiled fn + (defun f (x) (+ (nifty-aid-for-students x) 3)) | use compiled fn + + +KMP@MIT-MC 04/03/80 00:14:10 Re: (STATUS LINMO) +To: INFO-ULISP at MIT-MC +All right, CPR, this should make you happy. I was over at the terminal room +listening to a student telling me that anyone who would type in a long +expression at the terminal is obviously losing and that if you can't rub +back into previous line it will encourage you to type it to an editor +instead ... and he's probably right. So the lisp they've got now uses +the line-at-a-time reader. I'm going to see later about linking that in with +SFA's so that its less screw-prone and can maybe even work to rub back out +over that ... but we'll see. This should do for now... let me know if +you get good or bad comments about the way it works. +-kmp + +KMP@MIT-MC 04/03/80 00:10:44 Re: Unix/Twenex Lisp Differences +To: INFO-ULISP at MIT-MC +The files MC:TEACH;ULISP NOTES and [EE]ULISP.NOTES contain +descriptions of the most blatant differences between Unix Lisp and +the simulator. They have been augmented to describe filenaming +conventions. HAL, maybe these or some similar item should be distributed +to students or made available to TA's for curious students or something. + +KMP@MIT-MC 04/02/80 14:04:50 +To: INFO-ULISP at MIT-MC +The file directory is the EE equivalent of Unix's /mnt/lisp + +The files PS5.COMPLEX and PS5.ALGEBRA have what /mnt/lisp/complex +and /mnt/lisp/algebra should have had. I had copied them over and checked +the copies visually a couple times carefully, but an error or two might +have leaked in -- be on guard. + +The file ULISP.NOTES has useful information about my simulator. I will +install information about how to load the PS5 files (and files in general +later). The general syntax that you should be pushing is: + + (load '((dir) fn1 fn2)) + and/or + (fr (dir) fn1 fn2) + +where (dir) is optional if loading from their own directory. +-kmp + +KMP@MIT-MC 03/31/80 13:48:37 +To: INFO-ULISP at MIT-MC +ULisp.104 is now running on EE as ULISP. This is the version that +will be released to students if no one finds any bugs in it; it has been +tested on MC pretty thoroughly and rather cursorily on EE. Please give it +some exercise if you have the chance. Feedback will be appreciated. Thanks. +-kmp + +KMP@MIT-MC 03/30/80 03:46:48 +To: INFO-ULISP at MIT-MC +On MC, :TEACH;ULISP now is the canonical place to find ULisp. I have changed +some of the macros -- they've just been thru a bit of a workout tho' so should +be ok. The function gensym, which is installed in the simulator but not in +Unix Lisp, is being used in do and parallel-setq (which is called by do). So +if people ask what g0001 etc means and why they can't type it in, it's because +I am making real gensyms. + +Because I have not been able to get the ftp connection to work directly to +EE from MC for image files, I will have to wait until XX comes back up to +install this on XX. Mail will be sent out when that is done. + +ULisp version 104 (yes, the numbers took a giant leap backward when I did +a big rewrite the other night) has fixes for all known bugs so if something +isn't working right, please report it to BUG-ULISP@MC. + +The mapcar function works in version 104, although mapping of fsubrs and +nlambdas will not do the same thing as Unix Lisp will. That's a pretty ill- +defined thing to do -- students shouldn't be writing code that depends on it +anyway -- so hopefully it won't cause any trouble. + +-kmp + +KMP@MIT-MC 03/30/80 02:59:10 +To: INFO-ULISP at MIT-MC +There is a ULISP mode for Emacs on MC. To get it, do + + MM Load LibraryKP;ULISP + MM ULisp + +This is pretty much like Lisp mode but knows about ULisp's slightly +different syntax, including \ as slashifier and | as comment char. +-kmp + +Date: 30 March 1980 01:25-EST +From: Kent M. Pitman +Subject: New mailing list formed +To: "(FILE [DSK:TEACH;ULISP INFO])" at MIT-MC, GJC at MIT-MC, + CPR at MIT-MC, PAO at MIT-MC, RZ at MIT-MC, JEFERY at MIT-MC, + DCB at MIT-MC, JIS at MIT-MC, HAL at MIT-MC + +I have created an INFO-ULISP mailing list. If your name is in the header +above, you are on the list. If you don't want to be on it, feel free to +remove yourself -- my selection of initial names is probably somewhat +random. If you know people that got left out, please see that they get added +somehow. + +This mailing list is for me to send info about new ULisp features and +bug-fixes. There will likely be a number of notes to this mailing +list while things get started up, and hopefully it will dwindle in use +as things stabilize. + +More soon, I suspect. + -kmp + diff --git a/doc/teach/ulisp.notes b/doc/teach/ulisp.notes new file mode 100644 index 00000000..0461a993 --- /dev/null +++ b/doc/teach/ulisp.notes @@ -0,0 +1,104 @@ +DIFFERENCES BETWEEN TWENEX ULISP AND UNIX LISP 2 April 1980 + +########################### Terminal Input ########################### + +Control characters do different things. The following control characters +have special meaning: + + Control-B = Halt Evaluation. Return control to toplevel lisp. No Backtrace. + Control-C = Halt Evaluation. Return to exec, suspending the Lisp job. + Control-K = Retype any pending characters that have been typed but do not + yet form a full s-expression. + Control-L = Clear your screen. UNFORTUNATELY, because of the way Twenex + handles screen clearing, you will have to type Control-Q + before anything will happen. If it stops echoing your input, + maybe you typed ^L and haven't typed Control-Q. Unlike on Unix, + Control-Q on Twenex is quite harmless so it can't hurt to try + it if you feel like that might be the trouble. It will be + ignored by the Lisp reader if you happen to not need it. + +Note also that Lisp will evaluate your form as soon as you finish typing +it. It will not wait for you to type a carriage return. Atoms may be +terminated with either a carriage return or a space. + +########################### Filenames ########################### + +Filenames are different on Twenex. Every filename has several parts: +device, directory, filename, extension, and version. These are normally +displayed as-- + + device:filename.extension.version + +device and version are something you should never have to specify as they +should always default to the right thing, so just pretend they don't exist +while you are in lisp. + +The following syntaxes for getting files into Lisp will work: + + (load '((directory) filename extension)) + or + (fileread (directory) filename extension) + +So if your filename is BAR.LSP, you can load this in with + + (load '((FOO) BAR LSP)) + +or if you don't like typing, you can do the following because LSP +is the default extension: + + (load '((FOO) BAR)) + +or, if FOO is your home directory, then just saying + + (load '(BAR)) + +will work just fine. By similar reasoning, fileread can be done with + + (fr (FOO) BAR LSP) + (fr (FOO) BAR) +or just (fr BAR) + +########################### Datatypes ########################### + +Floating Point Numbers + + Floating point numbers, due to the nature of the machine, have a + different precision. + + IMPORTANT: Numbers with trailing dots do not read as floating + point numbers -- they are fixed point numbers in base 10 + (regardless of the value returned by inradix). Hence, + + 53 - is read as 53 in the current inradix (default 10) + 53. - is read as 53 decimal, regardless of inradix + 53.0 - is 53.0, a floating point number + +########################### Functions ########################### + +The operator "prog" in ULisp allows go's to tags outside of the scope +of the innermost prog. "gprog" is not implemented, since the power of +the "prog" available in this lisp makes it pretty much unnecessary. eg, + + (prog () top (prog () (print 'hi-there) (go top))) + +is a legal form and will sit in an infinite loop printing "hi-there". + +The operator "backtrace" allows a numeric arg in ULisp. + + (backtrace) turns off saving/displaying of backtrace debugging info. + (backtrace t) turns on backtrace debugging info. + (backtrace n) where n is a fixed point number tells ulisp + to show you only the most recent n stack frames + when an error occurs. + +The following functions are not implemented: + + getobl, cset, csetq, open, openi, openo, close, instream, outstream, + rename, create, link, unlink, seek, ttyread, ttywrite, fileread, filewrite + +########################### Errors ########################### + +Some error messages may be different. If an error message starts with a +";", it is probably a MacLISP error message rather than a ULisp error. +This is probably not a ULisp bug -- It is likely that the error is still +your fault. Check your code; if you think it's not your bug, ask a TA. diff --git a/doc/teach/ulisp.trace b/doc/teach/ulisp.trace new file mode 100644 index 00000000..1f56b6a0 --- /dev/null +++ b/doc/teach/ulisp.trace @@ -0,0 +1,37 @@ +The following objects are trace-able: closures, [f]subrs, [n]lambdas, macros. + +To trace, you do (trace name1 name2 ...). This will SETQ name1, name2, ... + to traced objects (they have actual datatype traced). + +To untrace, you do (untrace name1 name2 ...). This will SETQ name1, name2, ... + to the functional component of the trace object which the variables were + originally set to. + +Traced objects print as # or #. By default + name is used. (trace-print name) or (trace-print definition) can be used + to toggle this. (trace-print) tells you what the current mode is. Both the + system printer and pretty-printer will respect this setting. + +Traced functions will do typeout of "Enter name (arg1 arg2 ...)" where arg1, + etc have been evaluated already if appropriate (not an nlambda, macro, or + fsubr). If the name of the function is available, it is printed. If + the function was called through apply, the name will not be available, so + the traced-object will print instead -- eg, + "Enter # (arg1 arg2 ...)". An arrow will be drawn on the terminal + from the entry to the return value. + +Traced macros will do slightly different thing. "Macro name (name ...)" will + appear -- ie, the thing following name will be the whole form. Then arrows + will be drawn to the expansion and the result. If you only want to see macro + expansions or macro results, the toggle is + (trace-macro expansion), (trace-macro return), (trace-macro all). + Just doing (trace-macro) will give you information about the current state. + Traced macros cannot be applied. + +Possible later features: + + (1) Traced functions cannot be closed over; this may get changed later. + + (2) It is not possible to trace a nameless function. There is no reason + you couldn't but I haven't invented a protocol for it yet. +