From news.columbia.edu!watsun.cc.columbia.edu!lasner Sat Sep 19 13:16:45 EDT 1992 Article: 1 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Welcome to the PDP-8 Newsgroup Message-ID: <1992Sep19.171553.8055@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University Date: Sat, 19 Sep 1992 17:15:53 GMT This group will discuss all aspects of PDP-8's and related machines, peripheral devices, DECmates, non-DEC clones, homebrew machines and peripherals. Other DEC "old iron" topics also welcome. Anyone already subscriped to the PDP8-lover's mailing list is obviously welcome here :-). A FAQ will be prepared soon, etc., perhaps several. cjl From news.columbia.edu!watsun.cc.columbia.edu!lasner Sat Sep 19 18:03:23 EDT 1992 Article: 2 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Some purposes of this newsgroup Message-ID: <1992Sep19.220243.14243@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University Date: Sat, 19 Sep 1992 22:02:43 GMT As we get started, this list will be expanded: Open for discussion are any topics to do with the hardware of the DEC PDP-8 series, which includes: PDP-5 PDP-8 LINC-8 PDP-8/s PDP-8/i PDP-8/l PDP-12 PDP-8/e PDP-8/f PDP-8/m PDP-8/a VT-78 VT-278 [DECmate I] PC-278 [DECmate II] PC-238 [DECmate III] PC-248 [DECmate III+] Also various non-DEC PDP-8-like products such as: Fabritek MP-12 Intersil Intercept series and micro-PDP-8 chips Pacific CyberMetrix PCM-12 series Various products from CESI inc. Harris Semiconductor micro-PDP-8 chips Digital Computer Controls DCC-112 series homebrew projects, etc. Additional hardware topics covered include other "old iron" machines such as PDP-10, -11, -6, -20, -7, -9, -15, and any relevant memory, terminal, or other peripheral equipment such as RK/RX disks, etc. Items relevant to the Rainbow, Pro, or Micro-11 are welcome if of a "generic" nature, such as the commonality of Rainbow and DECmate MS-DOS or CP/M. IBM-PC topics will be allowed on such issues as formatting RX50 disks or PDP-8 simulators, etc. In fact all architectures supporting PDP-8 simulators are welcome here on such topics, etc. All aspects of PDP-8 software and documentation are welcome here, including paper-tape software, and the various operating systems for the machines: PS/8-PS/12, OS/8-OS/12, OS/78, OS/278, and especially the proposed replacement system OS/8 Version 5. P?S/8, a proprietary alternate operating system for PDP-8 and DECmates. RTS-8. WPS-8. COS-300-COS-310 aka DIBOL-8. "Traditional" systems such as the Disk Monitor and the PDP-5/PDP-8/LINC-8 Library System. Additional relevant topics are welcome of course. cjl From news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!agate!agate!jym Tue Sep 22 15:09:51 EDT 1992 Article: 3 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!agate!agate!jym From: jym@mica.berkeley.edu (Jym Dyer) Newsgroups: alt.sys.pdp8 Subject: A Show of Hands, Please! Date: 22 Sep 92 10:24:57 Organization: The Naughty Peahen Party Line Lines: 4 Message-ID: NNTP-Posting-Host: remarque.berkeley.edu =o= Who else out there kept seeing the popular abbreviation for _Saturday_Night_Live_ and thought to themselves, "Skip on Nonzero Link?" <_Jym_> From news.columbia.edu!watsun.cc.columbia.edu!lasner Tue Sep 22 15:10:23 EDT 1992 Article: 4 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: A Show of Hands, Please! Message-ID: <1992Sep22.183202.21237@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: Date: Tue, 22 Sep 1992 18:32:02 GMT In article jym@mica.berkeley.edu (Jym Dyer) writes: >=o= Who else out there kept seeing the popular abbreviation >for _Saturday_Night_Live_ and thought to themselves, "Skip on >Nonzero Link?" > <_Jym_> I certainly did. SNL was Skip on Nonzero Link years before. Also, Saturday Night Live isn't the name of the show, it's just Saturday Night. The SNL buzzword came about later as the critics described the show, and also to diffentiate it from the Howard Cosell show aka Saturday Night. But, in any case, the show is now, and always has been "live from New York, it's Saturday Night!", not "from New York, it's Saturday Night Live". The live was merely the emphasis on the fact that in a virtually all-taped network era, this was a live show, as in "It's on Saturday (late) Night! (And it's not just a Carson re-run.) Also, "It's live!" (Unlike taped Carson shows that are taped the same day for replay a few hours later in case they screw up.) Today, the "live" part is no novelty, considering shows like Leno, or even Fox's Roc. When it came out in the '70's, it did mean something though, and the critics recognized that, so the (incorrect) abbreviation and name have stuck. In any case, SNL goes back to 1962 and the original plans for the PDP-5. Here's an alternate story about 12-bit mnemonics: There is an instruction on the LINC which is 0455 which is skip on the low-order bit of the LINC's version of the MQ register being clear. The reason for such an instruction is the somewhat quirky way the DP instructions are implemented on the LINC (and also an 11-bit multiply, etc.). You need to retrieve that bit to correct other values, etc., so it's clearly useful. The LINC numbers the bits in a very un-PDP-8 way: L 11 10 9 8 7 6 5 4 3 2 1 0 as opposed to PDP-8 standard of: L 0 1 2 3 4 5 6 7 8 9 10 11 So, the reference is to bit[0], not bit[11]. The original name for the register in question is the Z register, later renamed in the PDP-12 as the Q register. Of course, all bit references in the LINC-8 and PDP-12 are PDP-8-style. The original mnemonic for this instruction is ZZZ meaning skip on the Z register bit Zero being Zero. The replacement mnemonic for the same instruction as it applies to prevailing LINC-8 and PDP-12 systems is QLZ meaning Q register Low-order is Zero is what to skip on. LINC mnemonics in general don't start with S for skip. The stated condition is what to skip on, and appending I to the instruction (which OR's in 0020, not 0400 as in PDP-8 and means an entirely different thing) makes the sense of the skip reverse, thus ZZZ I is skip if the low-order Z register bit is set, not clear. The LINC variants for our original example are LZE for skip on Link is ZEro and to exactly replicate it LZE I for skip on Link ZEro Isn't true. Note that in the LINC-8, the AC and LINC and Z register in question are part of a separate CPU. From the PDP-8's point of view, the LINC A register or accumulator is a peripheral register, as is its memory buffer or B register, and there are I/O instructions provided to access all of these registers. In the PDP-12, there is only one set of registers, and the operations refer to the PDP-8 accumulator and MQ register, but the arithmetic operations are identical to the original (separate) LINC processor operations in the LINC-8's LINC CPU. When the LINC CPU is running, the PDP-8 is operating in 100% DMA grant mode, and the BREAK light glows brightly. The operation that puts the PDP-8 into this mode has 0012 in the AC at the time. Invariably the lamps for bit[8] and bit[10] of the AC are blown out in LINC-8 systems. To handle dual mode assembly of these distinctly different operations, there are several assemblers for different systems such as OS/8's user-written PAL12, P?S/8's PAL with the /8 or /9 switch enabled, LAP6-DIAL's assembler for the PDP-12, and a PDP-10-based cross-assembler known as DIAL-10 (which is a "cousin" of PAL-10). All of these systems use assembler directives PMODE and LMODE to change over the assembler mode of the moment to suit either PDP-8 or LINC requirements: PMODE SNL LMODE LZE I This would assemble the correct binary values for our mnemonics, but won't run unless surrounded by the appropriate control instructions, but that's an entirely different topic, etc. (PDP-12 needs a mode-change instruction while LINC-8 needs a major amount of register initialization culminating with a LINC CPU start operation, etc.) cjl From news.columbia.edu!sol.ctr.columbia.edu!usenet.ucs.indiana.edu!ux1.cso.uiuc.edu!news.iastate.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Thu Sep 24 18:06:23 EDT 1992 Article: 5 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!usenet.ucs.indiana.edu!ux1.cso.uiuc.edu!news.iastate.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: PDP-8 Sender: news@news.uiowa.edu (News) Message-ID: <1992Sep24.163750.28776@news.uiowa.edu> Date: Thu, 24 Sep 1992 16:37:50 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA I have a PDP-8/E and a PDP-8/F at home, in various states of restoration. For each, I have an RX01 drive, one that may have worked when turned off, and one that needs a new drive transistor. Does anyone know the proper JDEC number for the stepping motor drive transistors in an RX01? Also, I only have one RX8E interface board, so I can't use both drives until I get another RX8E. Does anyone know where that interface is to be found? Doug Jones jones@cs.uiowa.edu From news.columbia.edu!watsun.cc.columbia.edu!lasner Thu Sep 24 18:24:14 EDT 1992 Article: 6 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Multiple RX drive pairs (was PDP-8) Message-ID: <1992Sep24.222258.16414@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1992Sep24.163750.28776@news.uiowa.edu> Date: Thu, 24 Sep 1992 22:22:58 GMT In article <1992Sep24.163750.28776@news.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: > >Also, I only have one RX8E interface board, so I can't use both drives >until I get another RX8E. Does anyone know where that interface is to be >found? There are only a few handlers for using a second RX8E on one machine, but it is supported by changing the device code selected for the board from 75 to I believe 76. There are other ways to get more than one pair on a machine: The VT-78 supports two pair on one interface and uses the new instruction SEL (6750) to select which pair. Power-clear default is to select pair 0 which is the same pair used by the (ignorant of all of this) OS/8 system handler. When the non-system handler exits, it must ensure that the feeble system handler addresses the pair 0 drives in all cases, including error returns. The VT-278 supports the two-pair mode as well. The DECmate II supports two pair of RX50 and optionally one or two pair of RX01/02 as well on the RX78 option board. If that board is used, a hard disk is not allowed as the hard disk controller requires being plugged into the same slot. The select process is the same except that additionally SEL is responsible for another bit that switches between RX50 and RX01/02. (AC[11] is the pair bit and AC[0] is the RX type switch.) When the RX78 isn't present, only the pair select is active. Warning: there are certain RX01/02-specific programs such as RTFLOP which can't run on the DECmate unless it's a version that sets the RX-type bit. Also, if the RX78 hardware isn't present, the program will erroneously attempt access of RX50 disks, which are not supported. There is also a non-DEC version: the DSD-210 supports four drive selects on its drive buss. In fact, there is a known variant where three drives are installed vertically in one chassis. By extending the buss, up to four drives are allowed. If you examine the command structure of the RX01/02, there is a "vacant" bit to the left of the unit select bit, and DSD uses that as the high-order select bit for access to other drive(s). The P?S/8 system and non-system handler for RX01 actually work on all of the described configurations, although a reassembly is required to change the device code to support a second RX8E. This is accomplished by always setting both SEL bits accordingly, and also setting the DSD unit-select bits as well. In all versions, some aspect of this gets ignored, so there need not be any special-case checks. cjl From news.columbia.edu!sol.ctr.columbia.edu!caen!uwm.edu!linac!convex!darwin.sura.net!sgiblab!rtech!ingres!jpk Sat Sep 26 01:38:45 EDT 1992 Article: 7 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!caen!uwm.edu!linac!convex!darwin.sura.net!sgiblab!rtech!ingres!jpk From: jpk@Ingres.COM (Jon Krueger) Subject: any SKED users out there? Message-ID: <1992Sep25.210638.14609@pony.Ingres.COM> Reply-To: jpk@Ingres.COM (Jon Krueger) Organization: Ingres Division, ASK Computer Systems. References: Date: 25 Sep 92 21:06:38 GMT Lines: 6 My experience with 8's was mostly in connection with SKED. Any SKED users out there? -- Jon Jon Krueger jpk@ingres.com From news.columbia.edu!watsun.cc.columbia.edu!lasner Sat Sep 26 01:44:36 EDT 1992 Article: 8 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: any SKED users out there? Message-ID: <1992Sep26.054210.19143@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1992Sep25.210638.14609@pony.Ingres.COM> Date: Sat, 26 Sep 1992 05:42:10 GMT I may have a SKED manual somewhere, but I never used it, because the real-time stuff I had to do outclassed SKED, and the non-real-time isn't what SKED is for. SKED really doesn't give you much of a PDP-8-specific viewpoint; it could have been written for about anything, but just happened to be an early -8 program that was available for a limited audience that could make use of it. A lot of PDP-8 users really expected that off-the-shelf software was going to somehow do what they wanted. Much of my work was based upon fixing up for the mistakes of that notion, etc. cjl From news.columbia.edu!sol.ctr.columbia.edu!caen!uwm.edu!ux1.cso.uiuc.edu!news.cs.indiana.edu!azamora@hexagon.cs.indiana.edu Sat Sep 26 09:18:35 EDT 1992 Article: 9 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!caen!uwm.edu!ux1.cso.uiuc.edu!news.cs.indiana.edu!azamora@hexagon.cs.indiana.edu From: azamora@hexagon.cs.indiana.edu (Tony Zamora) Subject: Is there an online version of DEC's PDP-8 diagnostics? Message-ID: <1992Sep26.012605.22410@news.cs.indiana.edu> Reply-To: azamora@cs.indiana.edu Organization: Computer Science, Indiana University Date: Sat, 26 Sep 92 01:26:01 EST Lines: 7 Does anyone have or know where I could get online copies of DEC's PDP-8 diagnostics? Specifically I would like an online listing of Instruction Test 1, Instruction Test 2, and Instruction Test 2B. Thanks, Tony From news.columbia.edu!watsun.cc.columbia.edu!lasner Sat Sep 26 11:01:14 EDT 1992 Article: 10 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: Is there an online version of DEC's PDP-8 diagnostics? Message-ID: <1992Sep26.145534.25251@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1992Sep26.012605.22410@news.cs.indiana.edu> Date: Sat, 26 Sep 1992 14:55:34 GMT In article <1992Sep26.012605.22410@news.cs.indiana.edu> azamora@cs.indiana.edu writes: >Does anyone have or know where I could get online copies of DEC's PDP-8 >diagnostics? Specifically I would like an online listing of Instruction Test >1, Instruction Test 2, and Instruction Test 2B. > >Thanks, > >Tony Currently there is no such facility per se, however, we now have an archive at ftp.telebit.com in /pub/pdp8 courtesy of Eric Smith. Since it's just starting up, we are still sorting out just exactly how to put the relevant stuff there. Obviously paper-tape-original diagnostics belong there, but in what form? As part of the Kermit-12 package I have written several utilities to handle different format files that may be what's needed. While many unix-oriented sites use uuencode/uudecode, this was not chosen, in part because of the "slop" in its implementation. A more robust form has been created, using some features requested by the Kermit group to overcome uuencode's weaknesses. This format is generally known as PDP-8 ENCODE format. Specific improvements are: 1) Uses a more robust character set: bi-Hexadecimal. Only letters and numbers need be uniquely translatable, and no concern for upper/lower case. As a consequence, each character has only 5 bits of binary information in it, as opposed to uuencode's 6. However, ENCODE can get through "paths" that uuencode cannot. 2) Supports PDP-8-oriented compression. While not a comprehensive compression method, any-data repeat-compression is supported. This is important in PDP-8 files because repeated sections of identical data could be HLT instructions (7402 octal) that only repeat when looked upon as 12-bit words. Many compressions schemes only work for 8-bit byte representations of files, and then sometimes only for special cases of data, such as all zeroes bytes, and then sometimes only for somewhat limited repeat counts. It is true that some data is a string of all 0000 12-bit words, which when represented a few bits at a time would compress down in zero-data repeat systems, but items such as the packed representation of binary paper-tapes in OS/8 .BN format wouldn't compress in a zeroes-only system; ENCODE format will compress this data effectively. 3) Supports an overall file checksum to prevent "hoping" that a file was received intact. It is unlikely that a delivered file will be actually defective yet pass the checksum test. 4) Is more robust against e-mail quirks such as the conversion of the file's contents merely because the first characters on a line happen to look like the word "from". In this format, that construct never happens, because all lines are surrounded by non-data delimiters. 5) The file format supports a command set. In theory, this makes it more of a "tar" than a uuencode format, but current programs only support a single binary file within the encoded file. An explicit (FILE XXXXXX.XX) command is used to indicate the imbedded file's filename. The OS/8 utilities recognize this command as the default name of the decoded file, although the user can override this with an explicit filename at the command level. Additionally, there are comment commands to help embellish the information content about the file. The usual things automatically generated are some "advertising" comments about the utility, version, etc., and some comments about the date the original file was created, as well as the date the encoded file was created. By providing file date information, the file can carry with it information for date reconstruction should it be derived from untrustable sources, or even have passed through OS/8 systems with directories set for no additional information words (AIW), which is an option that is sometimes set in OS/8 when the directory covers many small files, such as binary paper-tape files. Currently, ENCODE files are only supported by OS/8 family systems, but as such, any OS/8 file is supported at the 12-bit binary level, thus an image of any file can be delivered intact. In addition, entire devices can be transmitted in ENCODE format using the so-called "image" mode switches. The device may be split into two roughly equal parts if desired. If decoded onto a device of equal or larger size at the target system, all files and the directory are delivered together intact; devices with larger inherent size should then be readjusted using OS/8 PIP to restore their true size. By using the image switches to split the encoded image into two parts, it is possible to take advantage of this mechanism on an OS/8 system as minimal as two drives of equal size to each other and to the contents of the image file. For example, a dual-drive RX01 system can be used to recreate an RX01 image because you can create a system diskette containing only the DECODE.SV program and one of the split files while placing a target diskette in the other drive. After running the decoder on one half, a similar disk with the other half is used. Afterwards, the other drive now contains a complete image of the transmitted RX01 disk. So, perhaps someone should put together a "suite" of binary diagnostic files and place them in the archive as "part 1" and "part 2" of an image of an RX01 diskette containing many diagnostics as .BN files. Such files wouldn't be unreasonably long for a net-accessable archive such as ftp.telebit.com. RX01 images are about the smallest popular OS/8 device, and thus represents a useful "size" for this purpose. Those with larger devices can reprocess the files accordingly. It isn't necessary to have RX01 hardware to create such a file, just modify the directory size of the device using OS/8 PIP so it matches the size of an actual RX01, then copy the intended files onto the "shortened" device, and then use ENCODE.SV to create the image files. An alternate method: If we restrict ourselves to binary paper-tape files, there is an alternate method available to better interact with non-PDP-8 systems. The binary paper-tape file can be viewed as nothing more than a sequential list of 8-bit frames which the BIN loader happens to be able to load into memory of a PDP-8. Thus the objective then becomes to merely create an image of the data as sequential bytes. This is the scheme currently being used with several PDP-8 simulators, etc., which expect the file to be a sequential stream of bytes on the native system's file structure. Towards this end, I have also included in the Kermit-12 package a pair of utilities to support .BOO format. While not as robust as ENCODE format, .BOO format is still somewhat better for the purpose than uuencode format, and is widely supported, especially on PC's. Programs to process .BOO format have been written in assembler, C, PASCAL, FORTRAN, and even BASIC. If the BASIC version is used, it is recommended that it only be used for one purpose: to acquire the binary of a faster version; the binary executable of a .BOO decoder written in C is distributed as part of the PC Kermit package. This file is itself encoded in .BOO format, thus another decoder is needed first to process it before it can be used. The BASIC program is short enough to be typed in if the need arises towards this purpose. In any case, the executable .BOO decoder runs at a decent rate for all subsequent decoding purposes. With a PC-based .BOO decoder, it is possible to convert .BOO files to binary format. The Kermit-12 ENBOO.SV program will convert OS/8 .BN files into .BOO format files suitable for sending to other systems with .BOO decoders. Assuming the original file was on paper tape, OS/8 PIP is used to convert it to .BN format. This file would then be encoded with ENBOO.SV and sent as an ASCII file to the PC where it is decoded into a binary file. The resultant file is a stream of 8-bit bytes as in the original binary paper tape. Note that OS/8 .BN files are either the result of using PIP with the /B option on paper-tapes, or perhaps the binary output of an assembly. In any case, the resultant file on the other end of the transmission is in a format suitable for loading with a BIN loader. The only file "distortion" induced by this process is that OS/8 PIP /B modifies the paper-tape binary to have a short standard leader and trailer length, followed by an innocuous ^Z for an end-of-file indicator. Since the ^Z character follows the trailer characters, a proper loader never sees this. Unless the file is meant to be uses with an actual paper-tape reader, this lossage is not problematic. OS/8 paper-tape punch handlers can be used with PIP /B to recreate longer leader/trailer sections if desired. Files in this format should be called xxxxxx.BIN to remind us that only a BIN loader is capable of loading them; as such they have no other PDP-8 operating system significence at that point. As long as the file is describing the 32K addressing space, any BIN loader will handle it. If the file was meant to be used with the KT8A extended address space (128K) it will function only if the loader recognizes the KT8A data-field extensions. Since there are so few files requiring this, it's not likely to be a problem. Diagnostics are not likely to appear in source form, but are often distributed with write-ups containing a poor xerox copy of a listing. If hardy individuals type up the sources (and verify the accuracy!) of these files, perhaps these ASCII source files of diagnostics and other programs could be distributed in the archive as well. Appropriate binary and documentation files could be provided for those not requiring source files as well. cjl From news.columbia.edu!rpi!usc!sol.ctr.columbia.edu!spool.mu.edu!sgiblab!rtech!ingres!jpk Sat Sep 26 20:10:48 EDT 1992 Article: 11 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!rpi!usc!sol.ctr.columbia.edu!spool.mu.edu!sgiblab!rtech!ingres!jpk From: jpk@Ingres.COM (Jon Krueger) Subject: Re: any SKED users out there? Message-ID: <1992Sep26.195920.25026@pony.Ingres.COM> Reply-To: jpk@Ingres.COM (Jon Krueger) Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501 References: <1992Sep25.210638.14609@pony.Ingres.COM> <1992Sep26.054210.19143@news.columbia.edu> Date: 26 Sep 92 19:59:20 GMT Lines: 34 Charles Lasner writes: > SKED really doesn't give you much of a PDP-8-specific viewpoint True, it gives you a state language viewpoint. Had it given you more of a PDP-8-specific viewpoint, its users probably wouldn't have been able to master it, and their programs probably would have been either trivial or incorrect. The nice thing about SKED was how it made realtime data acquisition and process control of multiple concurrent processes accessible to nonprogrammers through use of the state language. It could and later did run on other machines. Still, SKED's historical and technical connection to 8's is well established. The 8 was reliable and affordable enough for a lab to buy one of its very own. It's hard to explain to youngsters what a revolution that was. You couldn't do realtime stuff with your slice of the department's timesharing machine. Suddenly, you could afford to buy a machine to dedicate to automating Skinner boxes. The 8 was also fast enough to do reasonable amounts of I/O getting and putting things from your lab device. DEC documented enough of the hardware, interfaces, and operating system that you could write a system like SKED. They kept the 8 standardized enough that most 8 programs ran on most 8's, a property found only in the mainframe world up until then. And they sold enough that you weren't on your own. Hard to explain to folks now how amazing that was too -- "you have an 8? Wow! We have an 8." -- Jon -- Jon Krueger jpk@ingres.com From news.columbia.edu!watsun.cc.columbia.edu!lasner Sat Sep 26 20:33:45 EDT 1992 Article: 12 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: any SKED users out there? Message-ID: <1992Sep27.002930.5197@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1992Sep25.210638.14609@pony.Ingres.COM> <1992Sep26.054210.19143@news.columbia.edu> <1992Sep26.195920.25026@pony.Ingres.COM> Date: Sun, 27 Sep 1992 00:29:30 GMT In article <1992Sep26.195920.25026@pony.Ingres.COM> jpk@Ingres.COM (Jon Krueger) writes: >Charles Lasner writes: >> SKED really doesn't give you much of a PDP-8-specific viewpoint > >True, it gives you a state language viewpoint. Yes, at much sacrifice of certain kinds of capability, which was a necessary requirement at many other installations. More power if you could "live" under SKED; we and the other places I consulted for could not. > >Had it given you more of a PDP-8-specific viewpoint, >its users probably wouldn't have been able to master it, >and their programs probably would have been either trivial >or incorrect. The nice thing about SKED was how it made >realtime data acquisition and process control of multiple >concurrent processes accessible to nonprogrammers through >use of the state language. It could and later did run >on other machines. Users didn't write the programs at the installations I worked for; I did. > >Still, SKED's historical and technical connection to 8's is >well established. The 8 was reliable and affordable enough >for a lab to buy one of its very own. It's hard to explain >to youngsters what a revolution that was. You couldn't do >realtime stuff with your slice of the department's timesharing >machine. Suddenly, you could afford to buy a machine to >dedicate to automating Skinner boxes. The 8 was also fast >enough to do reasonable amounts of I/O getting and putting >things from your lab device. DEC documented enough of the >hardware, interfaces, and operating system that you could >write a system like SKED. They kept the 8 standardized >enough that most 8 programs ran on most 8's, a property >found only in the mainframe world up until then. And they >sold enough that you weren't on your own. Hard to explain >to folks now how amazing that was too -- "you have an 8? >Wow! We have an 8." That's true; and it also allowed me to take the guts of my code from one machine to another where the "application layer" of the real-time code was all that was different, since the interrupt-level is constrained to be nearly identical in each case. The only variance has to do with whether the Lab clock was to be put into whichever of its several modes made more sense for the application. BTW, some of the applications were beyond the capabilities of the hardware provided in the LAB-8/e series, and required the addition of non-standard modifications to the clock to allow two clock board sets. Additionally, multiple D-A converters were often needed to display certain real-time calculations. My main point is that the -8 was used for lots of real-time applications, including certain things where SKED would literally get in the way. There's a world of difference between caring about 10's of microseconds versus 10's of milliseconds. A lot of ornate programming is needed to get the performance out of the machine that it's capable of. Real-time is what you make of it; some people were happy with the limited world of LAB-8/e BASIC, and others were happy with the "canned" packages provided by DEC that were, as far as I/m concerned, glorified demo programs, such as the "Time Interval Histogram" program and its ilk. Moreover, the quality of the code in some of these programs was quite below "par" compared to the code myself and others wrote both before and since these programs became available. Some of what I refer to is the so-called "skip chain" interrupt handling. This is an inefficient technique whereby actual SKP instructions are used to skip over jumps (perhaps indirect to make them even slower) where the SKP's are themselves skipped over should a device flag be raised. Perhaps it's insignificantly easier to follow, or it conforms to someone's notion of "structure" but regardless, it unnecessarily raises the interrupt latency. Moreover, some programs require an aspect of unavailable API, namely that an interrupt routine needs to be interruptable lest a higher-priority device be interrupting. In this case, a "recursive" interrupt handler is required so that after the device has been "tamed", the rest of the device servicing is guaranteed to be a lower priority than a potential interrupt from another device. Priority can't be finely controlled, but you can do things like make sure that a trivial and unimportant blurb printing routine outputting to the terminal on interrupt doesn't materially slow down the ability for the clock to give you clock-counter readouts from the clock buffer at crucial times, or to get additional A-D channels started soon enough before the sampling rate exhibits a jitter, etc. (Ever debug a real-time program with an oscilloscope? I have. I had to ensure that tasks that "woke up" periodically didn't impact negatively on sampling rate by inducing jitter, etc. and the best way was to watch the automatic a-d start pulse generated by the clock, etc.) Yes, SKED has a place in applications for the -8, but hardly in the realm of certain "faster" real-time applications. User flexibility can mean program impossibility sometimes. > >-- Jon >-- >Jon Krueger jpk@ingres.com cjl From news.columbia.edu!rpi!think.com!spool.mu.edu!decwrl!rtech!ingres!jpk Sun Sep 27 09:56:36 EDT 1992 Article: 13 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!rpi!think.com!spool.mu.edu!decwrl!rtech!ingres!jpk From: jpk@Ingres.COM (Jon Krueger) Subject: Re: any SKED users out there? Message-ID: <1992Sep27.050516.16253@pony.Ingres.COM> Reply-To: jpk@Ingres.COM (Jon Krueger) Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501 References: <1992Sep25.210638.14609@pony.Ingres.COM> <1992Sep26.054210.19143@news.columbia.edu> <1992Sep26.195920.25026@pony.Ingres.COM> <1992Sep27.002930.5197@news.columbia.edu> Date: 27 Sep 92 05:05:16 GMT Lines: 29 Charles Lasner writes: > There's a world of difference between caring about 10's of > microseconds versus 10's of milliseconds. You bet. But not to recording behavior of intact organisms. That's what SKED was designed for. 10 millisecond resolution was what its applications needed and what it gave. Realtime isn't notably "do this as fast as you can". It's "do this and guarantee you will complete within time T". Sometimes T is measured in milliseconds, sometimes microseconds, nanoseconds, or hours. > A lot of ornate programming is needed to get the > performance out of the machine that it's capable of. True. But ornate can also mean impossible to validate. SKED had advantages to those who wanted to write a variety of nontrivial realtime programs and have confidence that they were correct. SKED's "tick" was configurable, by the way. The default was 10 msec, but you could set it as low as 1 msec (on 8's) or as high as you wanted and run more stations. -- Jon -- Jon Krueger jpk@ingres.com From news.columbia.edu!watsun.cc.columbia.edu!lasner Sun Sep 27 10:02:44 EDT 1992 Article: 14 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: any SKED users out there? Message-ID: <1992Sep27.135408.15899@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1992Sep26.195920.25026@pony.Ingres.COM> <1992Sep27.002930.5197@news.columbia.edu> <1992Sep27.050516.16253@pony.Ingres.COM> Date: Sun, 27 Sep 1992 13:54:08 GMT In article <1992Sep27.050516.16253@pony.Ingres.COM> jpk@Ingres.COM (Jon Krueger) writes: >Charles Lasner writes: >> There's a world of difference between caring about 10's of >> microseconds versus 10's of milliseconds. > >You bet. But not to recording behavior of intact >organisms. That's what SKED was designed for. >10 millisecond resolution was what its applications >needed and what it gave. I agree; the applications I did needed more, although some of them did qualify for the word "intact" but some could argue that it was just barely so. > >Realtime isn't notably "do this as fast as you can". >It's "do this and guarantee you will complete within >time T". Sometimes T is measured in milliseconds, >sometimes microseconds, nanoseconds, or hours. Exactly. This is what bothers me about certain other programs hawked by certain vendors. They aren't capable of anything but relatively slower units, yet use the "banner" of "real-time" application to get unwanted praise. Moreover, someone once defined real-time as either "fixed" or "floating". Clearly we're talking about the fixed kind, which is always more difficult to pull off. My level was into the instruction/cycle counting kind. This has been known to be done on other machines as well, such as when people found out that overly stripped down CPU's didn't function as expected (thinking LAB-1103 here; someone wound up building DMA peripherals for more functions than anticipated because the CPU was the bottleneck as compared to other models). Moreover, there is an industry of hardware people willing to ride on this bandwagon. Thus we would always get our time wasted looking through brochures for A-D convertors when we wanted fast convertors (either continuous or at least successive-approximation types) and instead were getting glossies about the latest and greatest dual-slope integrator type A-D convertors. (These are fine if your application is 3 orders of magnitude slower than ours; it's intended for applications like digital voltmeters, etc., not fairly fast real-time; yet these companies hear about applications that monitor liquid levels in tanks, or super-slow chemical reactions done in so-called real-time and assume that anyone in a real-time situation is to be lumped in, thus we are an appropriate audience for this slow stuff :-(.) > >> A lot of ornate programming is needed to get the >> performance out of the machine that it's capable of. > >True. But ornate can also mean impossible to validate. >SKED had advantages to those who wanted to write a >variety of nontrivial realtime programs and have >confidence that they were correct. This is also true, but irrelevant. Sometimes the intrusion of code that is present merely to validate what's being done guarantees that it can't. Merely getting an I/O error on our disk was "fatal" to the application, so the error routines indicated aborting the run. Fortunately there was enough time to check for the errors, because the disk handler itself was run by DMA as well as the DMA that wrote the data out (during the sampling, etc.). BTW, there is another level of task interaction that comes up here: too-fast disks that need to be "throttled back" to allow enough cycles to get the job done. While one constraint is the disk being fast enough on average to keep up with the aggregate sampling rate, another constraint is that when the disk is actually transferring, it doesn't take too many CPU cycles that the sampling routines (on clock interrupt) are adversely affected. All too often, a disk transfers all of its data at once, and can be granted virtually every buss cycle for a brief period, which should it coincide with an interrupt handling routine that has a short critical window, means that the application has failed to keep up with the data. By slowing down the transfer rate, this can be avoided. For one such application, there was a better solution: an inter-processor buffer (DB8E). This allowed one machine to carry out the real-time application while the other machine (with the too-fast disk) acted as a disk server. When both machines are available, the DB8E transfers words quite quickly in the background. The background code is interrupted as necessary by the clock- driven events. Most of the time is spent in the background shoveling 12-bit words at the disk server machine. Periodically, the disk server is not available as its cycles are taken away by the fast disk, which can afford to get certain kinds of errors and yet, through multiple buffers still keep up if the recovery is successful after at most 2 retries. But usually, the disk server is available in the real-time sense. Thus each CPU's need to service some higher-priority task doesn't interfere with the other's. As long as both machines were available to each other 60% of the time, the data transfer was successful. I mentioned a few articles back about the need for two clocks. The reason for this only tends to come up when the data rate is high: You need to put the clock into the mode that schedules the first of N A-D conversions when the clock overflows, and then auto-reloads the clock counter from the clock buffer/preset register. The interrupt handler for the clock does a blind read of the A-D buffer because sufficient microseconds have gone by since the clock overflow interrupt which is what's checked for in the interrupt routine. Then, additional channels are scheduled, etc. This all works fine if that's all you want to do. However, we also needed to use the Schmitt trigger hardware to put the clock into the mode that dumps the clock counter into the buffer register to count frequency of the events hooked up there. Needless to say we were running the clock at the 1 microsecond/tick rate at the time. This can be done only with two clocks, each doing one of the operations. It was once tried with one clock: You have the clock overflow, and you load the buffer-preset register with the new value of the clock counter for next time. The problem is that the single register is the only avenue of loading the clock counter, so it's necessary to do it this way. The instructions are either AC -> clock buffer, or AC -> clock buffer -> clock counter; there is no way to leave undisturbed the buffer register. So, you run the clock in that mode that reloads the clock from the buffer every time the counter overflows and interrupts. So far so good. But, you also enable the Schmitt trigger inputs, thus they also interrupt occasionally. Perhaps even relatively infrequently (not in our applications when data was at the expected highest value of valid data, but the problem exists even if the data is slower). When the Schmitt trigger interrupt occurs, what we want to do is to load the clock buffer with what's currently in the clock right now, and then read it into the AC. (This is what the instruction does; the basic problem is that there is only one path in and out of the clock counter for all functions.) Then we quickly want to restore the constant reload factor back to the buffer so it's correct for when the clock overflows (usually in awhile) so it will reload correctly at that time. (Again, this is reasonable because the instruction used is AC -> clock buffer only.) But there is an insidious problem: what if the clock is nearly ready to overflow? You have just dumped out the clock counter into the buffer register and could have a clock count of something like -20 through -1. If this is the case, the clock will in just a few CPU instruction times be overflowing and before you can do anything about it start reloading itself from this unintended buffer value. The worst case is if the clock count is -1, because it means that the clock is now repeatedly going -1, 0, -1, 0, -1, 0, etc. and there's nothing you can do about it :-(. By the time you have reloaded the buffer with the larger number intended to be there (such as -800) some semi-unknown amount of cycles may have gone by where the clock was out of control causing multiple overflow/auto-reload events. If a DMA disk is stealing cycles during this worst-case event, the results aren't even fully predictable. Thus, the overall effect is a "creeping" loss of real-time :-(. The only reliable solution is to redesign the clock. In our case, we did by using two clocks to avoid the interaction. There was enough program time available to service the two interrupts. BTW, there is a logistic problem in modifying the DK8EP hardware: they never intended the clock to be anything other than device 13, whereas most cards have spare device codes or even free-choice in a six-bit range. We had to hack on the logic to make it respond to device 14 :-(. > >SKED's "tick" was configurable, by the way. The default >was 10 msec, but you could set it as low as 1 msec (on >8's) or as high as you wanted and run more stations. We just had one faster station. > >-- Jon >-- >Jon Krueger jpk@ingres.com cjl