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: <JYM.92Sep22102457@remarque.berkeley.edu>
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: <JYM.92Sep22102457@remarque.berkeley.edu>
Date: Tue, 22 Sep 1992 18:32:02 GMT

In article <JYM.92Sep22102457@remarque.berkeley.edu> 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
