Subject: Paper Tape
From: Richard Segal <[email-masked]>
To: [email-masked]
Date: Tue, 25 Aug 92 11:23:19 EST

Date: Tue, 25 Aug 92 11:23:19 EST
From: Richard Segal <[email-masked]>
To: [email-masked]
Subject: Paper Tape

Has anyone reminded anyone that paper (well, mylar) tape is still the standard
for Navy data archive? It's both EMP and salt-water proof.

I've worked on Gov. contracts in the past 2 years where tape punch support is
required - notably a small (~9"x~9"x~6") box with a RS232 in and a spool
holder on top. It's still out there, frighteningly enough...

JB

From: "Lawrence T. LeMay" <[email-masked]>
Date: Tue, 1 Sep 92 21:46:07 CDT
To: [email-masked]
Subject: paper tape

From: "Lawrence T. LeMay" <[email-masked]>
Date: Tue, 1 Sep 92 21:46:07 CDT
To: [email-masked]
Subject: paper tape

The Navy still requires paper (mylar) tape? Great! Now, where does the
Navy buy this tape, so i can buy some???

-Lawrence LeMay
 [email-masked]

Date: Wed, 2 Sep 92 1:40:39 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: Tape handlers for various O/S'es

Date: Wed, 2 Sep 92 1:40:39 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: Tape handlers for various O/S'es

    The recent post here about the tape drive handling on the Disk
Monitor System seems to indicate a "driver" for the tape for the Disk
Monitor?  I don't see how that format can be a driver-worthy format
because DM format requires a "link" word to point to the next data
block, thus blocks need 129 words, not 128.  The described format would
make sense for 8-bits stored in one tape byte, 4 in the other with 4
wasted.  But where's the link word?

    Perhaps it's not a handler, but rather a pseudo-handler that is
called in just like a regular handler, but can only be used by
cogniscent programs that know what the restrictive nature is (probably
written true sequentially and the link word can only be imputed to be
pointing to the next block) can make use of the "handler".

    In any case, to make this work in OS/8 was suggested.  It sounds
barely doable as a non-system handler because the 12K system handler
doesn't get a full page buffer to do the assembly/disassembly in.  I
assume the hardware is DMA so you have to have an area where the blocks
exist page-sized strung out as 256 bytes; this can't be done there.  If
you want to reserve a still higher (assuming availability) field, then
it could be, but the only way (in 12K, forget it in 8K) would be to make
smaller tape blocks that were only 64 bytes, thus 32 12-bit words.  This
is a waste of the tape gaps because we only need granularity to 256 byte
records.  (Thus in 12K it's better to use an 8K system and claim that
field 2 is unavailable.  Of course, that means that the whole field
becomes unavailable to other utilities, but you can't have everything
:-(.

    The P?S/8 picture is a lot brighter:

    The basic 4K system can load a handler into any field depending on
handler size.  To make a record that would be page-sized requires a
256-word buffer within the handler, and presumably one-two pages of code
for a total size of 3-4 pages.  This is entirely reasonable for P?S/8
programs such as BLKCPY, even in only 4K.  (If more memory is available,
larger handlers can be accomodated, or if necessary loaded into extended
memory, a feat OS/8 doesn't do, and/or use larger read/write and compare
buffers.

    Even a system handler is possible, although 8K would be required;
P?S/8 allows for a nine-page maximum-sized system handler: one page
where OS/8 puts it - 07600-07777 and if necessary X6000-X7777 where X is
the highest field available in 1-7.

    The performance of such a handler is another matter entirely.
Magtapes don't do well turning around and move rather stiltedly unless
sequentially transferring.  BLKCPY should do it fine though, because it
does nothing but sequential transfers.

    The reason the TM8E is so much easier to use is that it supports
core-dump mode, meaning 12-bit transfers.  The same amount of tape space
is required, but is allocated slightly differently such that each tape
character is 6 of the 12 bits, and the data is in 12-bit memory without
requiring assembly/disassembly as in the previously described post.
OS/8 never had a block-replaceable handler with long gaps, just a
non-system handler to write files sequentially.  But, it clearly can be
done if needed.

    There is a minor conceptual problem in OS/8 that only comes up in
such a handler:

    OS/8's call is a kludge in that the subroutine argument is a count
of single pages of transfer of blocks the size of two pages each.  The
reason this usually works is that most devices that transfer via DMA
support a one-page transfer mode such as the RK8E.  You can read in the
whole two-page record, or the first half.  Notice that it is impossible
to create an OS/8 call requesting the second half only of a record, just
the first half only.  The SAVE command is deliberately "rounded up" to
enforce this convention.  (You can save 000-177, or 000-377, but you
can't save 200-377 because that's an "odd" page.  Actually, in theory
you could do this, but then you couldn't combine the element with a save
of 400-577 or 400-777, since this would span multiple records in an
untenable way.)

    Thus, it is necessary to write blocks that are one page long,
because the DMA can't be turned off in the middle if an odd page count
is given.  For writing, this is meaningless, and indeed, OS/8 on an RK8E
writes junk into the second half of records which are first-half-only
significent.  This is perfectly OK, as long as the record is
read/writable for a two-page usage later.  (Note that odd-page writes
during SAVE become odd-page reads during GET or RUN, so the junk is
unreferenced.  Should the data get copied, the junk goes for the ride
innocuously.) 

    Unfortunately, this means that the block size has to be one page,
while must calls would prefer two-page.  Thus, the tape is effectively
smaller because there are twice as many gaps required as otherwise might
be necessary.  (This is also the reason why OS/8 LINCtapes are 128/129
words long, not the more standard 400 words long.  There is a defective
handler attempting to do the impossible, supporting standard LINCtapes
for OS/8, but it can't work.  Simple way to crash it: RUN LNC0:PAL8 or
any other program that loads into 7400-7577.  The tape can't help but
DMA over 7600-7777 at the same time thus killing the system handler
:-(.)

    In any case, tape can make a nice backup device if used this way.
Or, as many people have done, write a full-device backup program from
disk <-> tape using standalone drivers, not handlers.  If all you want
is a tape backup, it need not try to be a full-fledged handler.

cjl

To: [email-masked]
Subject: Re:  Tape handlers for various O/S'es
Cc: [email-masked]
Date: 2 Sep 92 00:23:47 PDT (Wed)
From: [email-masked]

To: [email-masked]
Subject: Re:  Tape handlers for various O/S'es
Cc: [email-masked]
Date: 2 Sep 92 00:23:47 PDT (Wed)
From: [email-masked]

In Message-Id: <[email-masked]>,
Charles Lasner writes:
>
>The recent post here about the tape drive handling on the Disk Monitor
>System seems to indicate a "driver" for the tape for the Disk Monitor?
>I don't see how that format can be a driver-worthy format because DM
>format requires a "link" word to point to the next data block, thus
>blocks need 129 words, not 128.  The described format would make sense
>for 8-bits stored in one tape byte, 4 in the other with 4 wasted.  But
>where's the link word?

Each tape "block" contained two 128 byte records. A total of 256*8 data
bits (2048). That worked out to 170 data words. 129 were used by the
4K DMS, a few were used for statistics on how many times a block had been
written and checksum, and the rest were wasted. Each 128 byte record was a
little over 1/2 inch long at 800bpi including a short gap. The EOF and long
gap was about 3" long. A 2400 foot tape could hold more blocks than a DECtape.
The tape drive was mechanical tension arm. It was a pleasure to watch.
I'd hate to admit how long it took me to figure out the link word usage in
that DECtape handler in PIP.

>
>Perhaps it's not a handler, but rather a pseudo-handler that is called
>in just like a regular handler, but can only be used by cogniscent
>programs that know what the restrictive nature is (probably written
>true sequentially and the link word can only be imputed to be pointing
>to the next block) can make use of the "handler".

It only worked with PIP, but it was a directory device. Listings and
everything. Even paper tape to magtape copies. :-) The disk dump/restore
program was a stand-alone, though it could be loaded from DF-32 and would
return to the 4K-DMS cleanly.

>
>In any case, to make this work in OS/8 was suggested.  It sounds barely
>doable as a non-system handler because the 12K system handler doesn't
>get a full page buffer to do the assembly/disassembly in. [...]

I never got the mechanical drive with the hobbled DMA to work with either
PS/8 or OS/8. The tape drive showed up at the same time that the 8/I got
4K additional to make 8K words, so there wasn't a third field to use for
buffer space. Besides, the machine had 1 (one), count it, one, DF-32.
That's 32K words. I actually loaded PS/8 on it, but it was a joke. Especially
considering that the input device for loading the system was an ASR-35. It
was better after being able to dump the disk stand alone and restore it. That
made it feasable to switch between 4K DMS for work with the diffractometer and
PS/8 for fooling around.

I had access to two other PDP-8/I machines. One was a 20K machine with a
TU10 9-track drive and a TU20 7-track drive an A/D and D/A, an ASR-33, and
what I remember as a blackface Tek 503 scope. That machine started with no disk.
I fit a system handler for PS/8 (and later OS/8) into the allowed area
in field 0. The 7-track drive could write a 12-bit word as 2 6-bit characters.
The 9-track drive had a core-dum mode where it would write a 12-bit word in
2 bytes using the low order 6 bits in each byte. It took 10 months to write
the driver and get it to fit. All but the last week was spent in frustration.
When I finally got it to work in that last week, I had scrounged enough space
to have the handler be smart enough to rewind if it was faster than
backspacing. That depended upon the placement of the PS/8 or OS/8 directory
near the beginning of the tape. It was fortuitous. The handler had all of the
endearing features of using instructions as constants, being self-modifying,
destroying itself and rebuilding itself as it went...It depended upon the DMA
(3-cycle) used by the tape controller, and one could even switch the system
device from the 7-track to the 8-track by manually twiddling the thumbwheel
switches while waiting at a dot prompt. The non-system handler could support
up to 8 drives, if one could afford that many. If my memory is right, a TU20
was about $20K. :-) I actually thought that a text-editor from DECUS that
used the 503 scope was a good thing.

Two drives were fun to watch doing an assembly. These were directory device
handlers. They rewrote blocks in the middle of the tape. There was also a
sequential handler for the non-system drive. The drives were vacuum-column.
Neat noises when they loaded and unloaded the tape for rewinding. Neat clunking
and clicking noises from the TU20 (with the lovely lime green trim) while doing
everything else, the TU10 (with two-tone tan/yellow trim) was pretty quiet.

That machine eventually got a Systems Industries controller and drive (kind of
like an RK03, but 16 sectors), and that removed the necessity of using the
tapes for other than sequential data storage.

The other machine had two beautiful HP mechanical tape drives. Pretty silent.
It eventually got an RK01 800K word cartridge drive. One slick peripheral that
it had was a three-word 1usec resolution timer.

>
>The P?S/8 picture is a lot brighter:
>[...]
>
>The performance of such a handler is another matter entirely.  Magtapes
>don't do well turning around and move rather stiltedly unless
>sequentially transferring.  BLKCPY should do it fine though, because it
>does nothing but sequential transfers.

These systems were fun to watch and use, though, and when compared with an
ASR-33 or ASR-35, almost anything is fast.

>
>The reason the TM8E is so much easier to use is that it supports
>core-dump mode, meaning 12-bit transfers.  The same amount of tape
>space is required, but is allocated slightly differently such that each
>tape char is 6 of the 12 bits, and the data is in 12-bit memory without
>requiring assembly/disassembly as in the previously described post. 
>OS/8 never had a block-replaceable handler with long gaps, just a
>non-system handler to write files sequentially.  But, it clearly can be
>done if needed.

The controller used with the TU10/TU20 also supported core-dump mode.

>[...]
>In any case, tape can make a nice backup device if used this way.  Or,
>as many people have done, write a full-device backup program from disk
><-> tape using standalone drivers, not handlers.  If all you want is a
>tape backup, it need not try to be a full-fledged handler.

But the handler makes it so much more satisfying to watch.

>
>cjl
>

A 4K PDP-8/I with a DF-32 and a magtape and an X-Ray diffractometer with
shutter solenoid control, and control over a 4-axis full-circle goniometer
was fun. Lights flashed, noises noised, and gears and motors turned. I kind
of miss it. I don't miss trying to squeeze one more word of code into a page,
though. I prefer a 16MB '486 running 386BSD, though it would be nice if it had
more than one flashing light :-)
--
Mike Murphy    [email-masked]    ucsd!sceard!mrm    +1 619 598 5874

Date: Tue, 15 Sep 92 16:33:41 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: Classic 8

Date: Tue, 15 Sep 92 16:33:41 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: Classic 8

It looks like I'm getting a Classic PDP-8, circa 1965, on permanent loan.
(The permanent loan business is to keep me from disposing of it without
consulting the owner.)  The machine was in working order when mothballed.

What we'll be getting is a machine with 4K memory, TTY, high-speed paper
tape reader and punch, a rackload of strange interfaces to long-gone lab
equipment, and possibly a 7-track tape drive.  There's a chance we can get
a 9-track tape drive from another source, and a working (as of when it was
turned off) DF-32 disk.  I'm not sure that the DF-32 is worth getting
except as a museum piece, but then, the entire system is a museum piece,
so perhaps it's justified.

We'll definitely strip off the strange interfaces (although the flip-chips
from which they were built may prove to be useful as spare parts).

My goal is to get up an asynch link from the -8 to some other machine in
our departmental lab, then use that machine to support the -8 as something
of a file-server and simulated tape reader-punch.  For this, we can probably
dispense with most of the original peripherals.

So, what I'm asking for now is pointers to 4K PDP-8 software that runs on a
Classic -8.  Things like 4K PAL, Focal, 4K FORTRAN, 4K ADA, 4K TeX, 4K
Microsoft Word, and whatnot.  If I can get them as FTP-able ASCII files,
that would fit my goal of being able to pump them over asynch lines into
the -8 from a machine that pretends to be a TTY.

Also, I'd appreciate hearing from others who have working straight -8
hardware.  How many straight -8 machines are still out there in working
order?
				Doug Jones
				[email-masked]

Date: Tue, 15 Sep 92 16:47:52 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: PDP-8 production history

Date: Tue, 15 Sep 92 16:47:52 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: PDP-8 production history

Having just acquired the permanent loan of a PDP-8, I'm curious to know
how many straight -8 machines there might still be out there.

My 1968 copy of DEC's logic handbook says that by that date, there were
more than 10,000 PDP-8 installations, but how many have survived to the
present?

For that matter, how many PDP-8 machines of all the other models were
made or sold, from the straight-8 all the way to the DECmate III.
Surely, someone at DEC has the figures.  Despite the fact that they're
not "family of 8" machines, this list should include the PDP-5 and the
PDP-8/S, and it should also include the PDP-12 models because they are
"family of 8" despite the lack of an 8 in their name.

I gather that the DECmate III was the final end to the PDP-8 product
line for DEC, and that DEC sold the last one in 1990.  Is either the
6100 or the 6120 chip still made?  Is either chip still being
incorporated into products by other manufacturers?

						Doug Jones
						[email-masked]

To: "Douglas W. Jones" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Classic 8 
Date: Tue, 15 Sep 92 15:36:24 -0700
From: [email-masked]

To: "Douglas W. Jones" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Classic 8 
In-Reply-To: Your message of "Tue, 15 Sep 92 16:33:41 CDT."
             <[email-masked]> 
Date: Tue, 15 Sep 92 15:36:24 -0700
From: [email-masked]

> It looks like I'm getting a Classic PDP-8, circa 1965, on permanent loan.

> So, what I'm asking for now is pointers to 4K PDP-8 software that runs on a
> Classic -8.  Things like 4K PAL, Focal, 4K FORTRAN, 4K ADA, 4K TeX, 4K
> Microsoft Word, and whatnot.  If I can get them as FTP-able ASCII files,
> that would fit my goal of being able to pump them over asynch lines into
> the -8 from a machine that pretends to be a TTY.

I have some paper tapes for the -5, -8I, -12, and others. Some of these
are probably good on a classic -8. Most of them are in files on my PC
but I can get them onto the Internet fairly easily. I don't remember
what's there but I know there are many diags and I think Focal and 4K Fortan.
I'll try to find the list tonight.

Unfortunately, the diagnostics are useless without the listings. There are
many shelf-feet of listings.

I would be interested in obtaining paper tapes for the classic -8, especially
diags and the same stuff Doug is looking for.

> Also, I'd appreciate hearing from others who have working straight -8
> hardware.  How many straight -8 machines are still out there in working
> order?

I have a 4K classic -8 with essentially no options. It runs pretty well.
I really need a maintenance manual for it - anyone have an extra or can
make me a copy?

>				Doug Jones
>				[email-masked]

Paul Pierce
[email-masked]

Date: Tue, 15 Sep 92 19:16:19 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: Binary paper-tape files on PC's.

Date: Tue, 15 Sep 92 19:16:19 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: Binary paper-tape files on PC's.

    As part of the Kermit-12 package, there are utilities to encode OS/8
files into .BOO format.  Once printably encoded, they can easily be
e-mailed or otherwise sent around the net.  When the file is decoded on
a PC, the resulting file is a string of bytes representing the original
binary paper-tape.  This assumes that the OS/8 file was created in the
usual way, meaning the binary output file of PAL8, etc., or conversion
using PIP with the /B option.  Thus, the only thing lost is the exact
length of leader/trailer, but no important contents.  I was careful to
preserve the bit and byte order to allow for this; the resultant PC
files are used as input to developing PDP-8 simulators on PC's.

    So, if anyone has managed to get PDP-8 paper-tapes read into PC
files in proper frame order, then you can use the MS-DOS .BOO encoding
program, and the result e-mailed, and eventually decoded at an OS/8 site
into a .BN file for ABSLDR loading.  (Or punching onto paper-tape!)

    We desparately need an open archive site for this stuff.  It ain't
big, and will really help.  Anyone got a few spare anonymous ftp'able
megs?  (Eric, are you listening?)

cjl

Date: Tue, 15 Sep 92 20:04:07 PDT
From: [email-masked] (Eric Smith)
To: [email-masked]
Subject: The PDP-8 Anonymous FTP Archive is Here!

Date: Tue, 15 Sep 92 20:04:07 PDT
From: [email-masked] (Eric Smith)
To: [email-masked]
In-Reply-To: Charles Lasner's message of Tue, 15 Sep 92 19:16:19 EDT <[email-masked]>
Subject: The PDP-8 Anonymous FTP Archive is Here!

> We desparately need an open archive site for this stuff.  It ain't big,
> and will really help.  Anyone got a few spare anonymous ftp'able megs? 
> (Eric, are you listening?)

Yes.

The PDP-8 archive is now available for anonymous FTP access on
ftp.telebit.com, in the directory /pub/pdp8.

There's not much in it yet, so I urge everyone that has PDP-8 software to
contribute.

The README file is enclosed below.

Cheers,
Eric
------------------------------ cut here ------------------------------
PDP-8 ARCHIVE
-------------

This archive contains information and software relating to the PDP-8 series
of machines which were produced by Digital Equipment Corporation, as well as
other related machines, peripherals, etc.

The maintainer of the archive does not have a significant amount of PDP-8
information and software, so the contents of the archive are provided
principally through the generosity of others.  If you have any information
which may be useful to other PDP-8 users, please consider submitting it to
the archive.

For information on the current contents of the archive, please refer to the
file "INDEX".

WHAT IS A PDP-8?
----------------

DEC produced a family of 12-bit mini- and micro- computers which are
generically referred to as "PDP-8"s, although the actual "PDP-8" designation
refers to a single model.  The PDP-5, LINC-8, and PDP-12 are generally
considered to be part of the PDP-8 family, as are later machines such as the
VT-78 and DECmate.  These machines all use essentially the same simple yet
elegant instruction set, although the LINC-8 and PDP-12 additionally offer
the LINC instruction set.

Some people consider the PDP-8/e to be the first personal computer, as it
generally supported one user, cost under $10,000, and was easy to use
(relative to other machines of its day).

For more details, refer to the file "WHAT-IS-A-PDP8", by Charles Lasner.

MAINTAINER
----------

This archive is maintained by Eric Smith ("[email-masked]").  Although it
is intended that the archive will be offered on a permanent basis, there is
no guarantee.

SUBMISSIONS
-----------

Files may be submitted for inclusion in the archive by putting them in the
directory /pub/incoming.

Please send mail to [email-masked] to notify me that I should move the
submitted files to an apropriate place.

DISCLAIMER
----------

Neither the maintainer of the archive nor Telebit Corporation offer any
warranty for the contents of this archive.  Use at your own risk!

FOR FURTHER INFORMATION
-----------------------

There is a mailing list for the PDP-8 and related topics called PDP8-LOVERS.
Please send administrative email such as subscription and cancellation
requests to "[email-masked]".

Submissions to the list should be emailed to "[email-masked]".

From: [email-masked] (Huw Davies)
Subject: Software for DECmate-II
To: [email-masked]
Date: Wed, 16 Sep 92 13:14:49 EST

From: [email-masked] (Huw Davies)
Subject: Software for DECmate-II
To: [email-masked]
Date: Wed, 16 Sep 92 13:14:49 EST
X-Mailer: ELM [version 2.4dev PL17]

Well, I've finally managed to extract our departmental DECmate-II from
our secretary (she now has a Mac). Given that I want to run 'real' PDP-8
software, where do I go from here? 

I understand that OS/278 is what I want and I can get it through the 
local DECUS library, but there appear to be two options, one including 
source and one without. Is there any real reason not to get the sources?

  Huw Davies           | [email-masked]
  Computing Services   | Phone: +61 3 479 1500   Fax: +61 3 479 1999
  La Trobe University  | I own an Alfa to keep me poor in a monetary
  Melbourne Australia  | sense, but rich in so many other ways

Date: Fri, 18 Sep 92 00:11:37 EDT
From: [email-masked] (Ethan Dicks)
To: [email-masked]
Cc: [email-masked]
Subject: Classic 8

Date: Fri, 18 Sep 92 00:11:37 EDT
From: [email-masked] (Ethan Dicks)
To: [email-masked]
Cc: [email-masked]
Subject: Classic 8

I, too, own a Classic 8 (two, actually),  They were previously used in a
typesetting shop and one is covered in ink.  I have cleaned the chassis,
but not the guts.  One significant problem I have is this...  A very
stupid photographer re-arranged the R-series logic in the right-hand
bay to make a promotional picture "look better" 'cause he didn't like
all the gaps from missing cards.  As a result, I have two CPUs, no
documentation and no clue.

Does anyone have a board map for the Classic 8?  I have one for the
8/L, so I know that DEC made them (eventually).  I am willing to
trade information for information.  I have paper-tape diagnostics
with the documentation as well as some paper-tape games and some
other stuff for OS/8 on RX01 disks.  Warning: not all of my PDP-8
information is quickly accessable.  The paper tapes are close at
hand;  some of the documentation is piled high in a basement having
narrowly escaped a flood!  

-ethan

P.S.  I also have a large quantity of RX01 drives that I would love
to trade for other parts, especially an OMNIBUS serial card (like
a KL8E)

P.P.S.  I have access to 5.0688Mhz crystals needed to convert a 110
baud serial card to a 300/1200...9600 baud serial card.  Trades
preferred.

--
Ethan Dicks     N8TVD ! This message is brought to you by the breakfast cereal
[email-masked] ! of Pennsic Veterans everywhere: Beerios.
                      ! "They don't stay crisp in beer, but who cares?" 

Summary-line: 18-Sep    [email-masked]  #UNIX utilities to read/write DECmate 5.25 disk ?
To: [email-masked]
Subject: UNIX utilities to read/write DECmate 5.25 disk ?
Date: Fri, 18 Sep 92 23:40:40 EDT
From: Harris L. Gilliam - MIT Project Athena <[email-masked]>

To: [email-masked]
Subject: UNIX utilities to read/write DECmate 5.25 disk ?
Date: Fri, 18 Sep 92 23:40:40 EDT
From: Harris L. Gilliam - MIT Project Athena <[email-masked]>

Hi,

	Has anyone ever worked on utilities for UNIX based
workstations that can read/write DECmate 5.25 disks ?  There are
plenty of utilities of this sort to do MSDOS disks for example.  Or is
this asking to much :-) ?

				---Harris

|Harris L. Gilliam           ()       4 Ames St. Cambridge MA 02139 |
[email-masked]     ()    [email-masked] |
|!bloom-beacon!mit-athena!hackeron               GEnie : H.GILLIAM1 |
[email-masked]					<><~~~      |

From [email-masked] Sat Sep 19 20:33:39 1992
Date:    Sat, 19 Sep 1992 19:21:45 -0500 (CDT)
From: [email-masked] (Mark E. Levy, ext. 8056)
Subject: subscribe
To: [email-masked]

subscribe

From [email-masked] Sun Sep 20 04:07:02 1992
Date: Sun, 20 Sep 92 02:07:04 CDT
From: [email-masked] (Ed McGuire)
To: [email-masked]
Cc: [email-masked]
Subject: subscribe

   Date:    Sat, 19 Sep 1992 19:21:45 -0500 (CDT)
   From: [email-masked] (Mark E. Levy, ext. 8056)
   X-Vmsmail-To: SMTP%"[email-masked]"

   subscribe

You'll have better luck mailing this to pdp8-lovers-request.

Date: Tue, 22 Sep 92 12:28:00 edt
From: [email-masked]
To: [email-masked]
Subject: Desktop PDP-8?

Date: Tue, 22 Sep 92 12:28:00 edt
From: [email-masked]
To: [email-masked]
In-Reply-To: A.Sporner's message of Mon, 21 Sep 92 20:03:07 -0500 <[email-masked]>
Subject: Desktop PDP-8?

Andy, I've added you to the list.

						-- Jan Brittenson
						   [email-masked]

   Date: Mon, 21 Sep 92 20:03:07 -0500
   From: [email-masked] (A.Sporner)

   I am a proud owner of a pdp 11/23+ with 1 Meg Mem and an RDQ style controller
   for a RD52 Disk.  I know that your group is specifically for the PDP-8,
   I have been looking for a PDP-8 with the original front panel, but when I
   was told that it was next to impossible to find one, I resorted to the PDP-11
   If in fact there is one (or some kind of computer with a front panel --
   must be a table-top (10.5" box MAX!!!!) that is reasonably prices (It need
   not work as I am a hardware techie) please let me know.

   I used to have a PDP-11/05 with a front panel.   Please let me know
   how it is that I subscribe to your list and if anyone can help me.

   Thanx.

   Grrr (Andy Sporner, 5700 College Road, Kolhbeck hall #303, Lisle, IL 60532)

From [email-masked] Tue Sep 22 22:02:09 1992
Date: Tue, 22 Sep 92 15:03:08 PDT
From: [email-masked] (Doug Klopfenstein)
To: [email-masked]
Subject: attn Rob Seastrom

Please add me to the list.

Doug Klopfenstein
[email-masked]

Date: Thu, 24 Sep 92 0:42:26 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: alt.sys.pdp8 is up

Date: Thu, 24 Sep 92 0:42:26 EDT
From: Charles Lasner <[email-masked]>
To: [email-masked]
Subject: alt.sys.pdp8 is up

The subject line says it all: there is now a newsgroup on usenet called
alt.sys.pdp8 which is essentially a "parallel" to our mailing list
here.  While that doesn't obsolete our present venue, hopefully it adds
more people on, etc.

Can anyone suggest a method of "linking" pdp8-lovers to alt.sys.pdp8?

cjl

Date: Thu, 24 Sep 92 08:54:11 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: alt.sys.pdp8

Date: Thu, 24 Sep 92 08:54:11 CDT
From: Douglas W. Jones <[email-masked]>
To: [email-masked]
Subject: alt.sys.pdp8

The new newsgroup hasn't made it to Iowa yet; I suspect that either
some administrator on some site along our feed path thinks that
groups devoted to obsolete hardware are obviously jokes, or some
prude is afraid it will be used to distribute pornographic material.

				Doug Jones
				[email-masked]

From [email-masked] Fri Sep 25 04:30:24 1992
From: [email-masked] (Andrew Mears)
Subject: UNSUBSCRIBE
To: [email-masked]
Date: Fri, 25 Sep 92 18:11:21 EST

UNSUBSCRIBE Andrew Mears

Please remove me from the list

Cheers

Andrew Mears
<[email-masked]>

Summary-line: 26-Sep  [email-masked].  #RE: alt.sys.pdp8 is up
Date: Sat, 26 Sep 92 21:04:57 PDT
From: He was a dark and stormy Knight.  26-Sep-1992 1929 <[email-masked]>
To: asimov::decwrl::"[email-masked]"@ranger.enet.dec.com
Cc: [email-masked]
Apparently-To: [email-masked]
Subject: RE: alt.sys.pdp8 is up

Date: Sat, 26 Sep 92 21:04:57 PDT
From: He was a dark and stormy Knight.  26-Sep-1992 1929 <[email-masked]>
To: asimov::decwrl::"[email-masked]"@ranger.enet.dec.com
Cc: [email-masked]
Apparently-To: [email-masked]
Subject: RE: alt.sys.pdp8 is up

Maybe you should talk to the guy who runs the SF-Lovers Digest, Saul Jaffee.
There's a rather complex two-way interconnection between rec.arts.sf.*
and the Digest.  There may be elements of this that can be used for
a mailing list as well.

Just a thought...

John Francini
Digital Equipment Corp.
Littleton Mass

[I cut my teeth on TSS/8 on a PDP-8/e in high school.  Wish I could
find TSS/8; then I'd be interested in having an 8 system again! Till then,
I just follow the list....]

Summary-line: 27-Sep  [email-masked]  #TSS/8
Date: Sun, 27 Sep 92 01:08:15 -0400
From: Leonard N. Foner <[email-masked]>
To: [email-masked]
Subject: TSS/8
Cc: [email-masked]

Date: Sun, 27 Sep 92 01:08:15 -0400
From: Leonard N. Foner <[email-masked]>
To: [email-masked]
Subject: TSS/8
Cc: [email-masked]

    Date: Sat, 26 Sep 92 21:04:57 PDT
    From: He was a dark and stormy Knight.  26-Sep-1992 1929 <[email-masked]>

[ . . . ]

    [I cut my teeth on TSS/8 on a PDP-8/e in high school.  Wish I could
    find TSS/8; then I'd be interested in having an 8 system again! Till then,
    I just follow the list....]

Speaking of TSS/8, if you [or anyone else on this list] runs across a
working TSS/8 system with DECtapes, and especially if it's anywhere
near Boston, I'd love to have some time with it to read about 30
DECtapes I wrote on a TSS/8.22B and TSS/8.24 system (8/e hardware, 16K
words core, 10 terminal lines, RS08 [I think?  200K 12 bit words?
fixed heads] disk, two DECtape drives, high-speed papertape punch &
reader) about 15 years ago...  if I can read them and just blast them
out a serial line to some other system to capture the data (or
anything else that I can do to get the data elsewhere so I can store
it in a more modern form), I'd love to do so.

I _could_ just grab it using some OS/8 system, I suppose, but it seems
like it'd be easier to use a real TSS/8 system rather than getting raw
bits that would need to be decoded later...

[Some of those tapes, btw, might actually be an image of TSS/8, so it
might be possible to build a system on someone else's 8.  I haven't
looked at the tapes in about a decade, though, so I'm not sure if this
is true, or how practical it would be to try to do this.]