Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Tue, 1 Sep 1992 22:34:53 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Tue, 1 Sep 1992 22:34:51 -0400 Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15110; Tue, 1 Sep 92 22:17:35 EDT Received: by mc.lcs.mit.edu id aa03377; 1 Sep 92 19:06 EDT Received: from uu.psi.com by mc.lcs.mit.edu id ab03369; 1 Sep 92 19:06 EDT Received: from klgai.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA11966; Tue, 1 Sep 92 18:15:29 -0400 Received: from cc:Mail by klgai.com (2.0/Outmail) id Message-ID: <570@klgai.com>; Tue, 25 Aug 92 11:23:19 EST Date: Tue, 25 Aug 92 11:23:19 EST From: Richard Segal Message-Id: <570@klgai.com> To: pdp-8-lovers@mc.lcs.mit.edu Subject: Paper Tape Date: Tue, 25 Aug 92 11:23:19 EST From: Richard Segal To: pdp-8-lovers@mc.lcs.mit.edu 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 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Wed, 2 Sep 1992 01:06:38 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Wed, 2 Sep 1992 01:06:36 -0400 Received: from mc.lcs.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA20791; Wed, 2 Sep 92 00:48:18 EDT Received: from mail.cs.umn.edu by mc.lcs.mit.edu id aa05007; 1 Sep 92 22:45 EDT Received: from centi.cs.umn.edu by mail.cs.umn.edu (5.65c/) id AA29919; Tue, 1 Sep 1992 21:45:37 -0500 From: "Lawrence T. LeMay" Received: by centi.cs.umn.edu id AA19485; 4.1/; Tue, 1 Sep 92 21:46:07 CDT Date: Tue, 1 Sep 92 21:46:07 CDT Message-Id: <9209020246.AA19485@centi.cs.umn.edu> To: pdp-8-lovers@mc.lcs.mit.edu Subject: paper tape From: "Lawrence T. LeMay" Date: Tue, 1 Sep 92 21:46:07 CDT To: pdp-8-lovers@mc.lcs.mit.edu 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 lemay@epx.cis.umn.edu Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Wed, 2 Sep 1992 01:58:12 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Wed, 2 Sep 1992 01:58:10 -0400 Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21478; Wed, 2 Sep 92 01:40:45 EDT Received: by watsun.cc.columbia.edu (5.59/FCB) id AA07522; Wed, 2 Sep 92 01:40:41 EDT Date: Wed, 2 Sep 92 1:40:39 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: Tape handlers for various O/S'es Message-Id: Date: Wed, 2 Sep 92 1:40:39 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu 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 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Wed, 2 Sep 1992 05:43:14 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Wed, 2 Sep 1992 05:43:12 -0400 Received: from ucsd.edu by life.ai.mit.edu (4.1/AI-4.10) id AA24311; Wed, 2 Sep 92 05:18:49 EDT Received: from sceard.UUCP by ucsd.edu; id AA05685 sendmail 5.67/UCSD-2.2-sun via UUCP Wed, 2 Sep 92 02:08:56 -0700 Received: by Sceard.COM (smail2.5/deliver1.5) id AA06434; 2 Sep 92 00:24:21 PDT (Wed) To: lasner@watsun.cc.columbia.edu Subject: Re: Tape handlers for various O/S'es Cc: pdp8-lovers@ai.mit.edu Message-Id: <9209020023.AA06420@Sceard.COM> Date: 2 Sep 92 00:23:47 PDT (Wed) From: mrm@sceard.com To: lasner@watsun.cc.columbia.edu Subject: Re: Tape handlers for various O/S'es Cc: pdp8-lovers@ai.mit.edu Date: 2 Sep 92 00:23:47 PDT (Wed) From: mrm@sceard.com In Message-Id: , 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 mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 18:09:31 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 18:09:29 -0400 Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12059; Tue, 15 Sep 92 17:44:22 EDT Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (5.64.jnf/920408) on Tue, 15 Sep 92 16:44:19 -0500 id AA28003 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Tue, 15 Sep 92 16:33:41 CDT id AA26810 Date: Tue, 15 Sep 92 16:33:41 CDT From: Douglas W. Jones Message-Id: <9209152133.AA26810@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: Classic 8 Date: Tue, 15 Sep 92 16:33:41 CDT From: Douglas W. Jones To: pdp8-lovers@ai.mit.edu 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 jones@cs.uiowa.edu Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 18:26:02 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 18:26:00 -0400 Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) id AA12841; Tue, 15 Sep 92 17:58:35 EDT Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (5.64.jnf/920408) on Tue, 15 Sep 92 16:58:33 -0500 id AA28108 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Tue, 15 Sep 92 16:47:52 CDT id AA26820 Date: Tue, 15 Sep 92 16:47:52 CDT From: Douglas W. Jones Message-Id: <9209152147.AA26820@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: PDP-8 production history Date: Tue, 15 Sep 92 16:47:52 CDT From: Douglas W. Jones To: pdp8-lovers@ai.mit.edu 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 jones@cs.uiowa.edu Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 18:57:20 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 18:57:16 -0400 Received: from SSD.intel.com by life.ai.mit.edu (4.1/AI-4.10) id AA14336; Tue, 15 Sep 92 18:36:37 EDT Received: from nautilus.ssd.intel.com by SSD.intel.com (4.1/SMI-4.1) id AA21704; Tue, 15 Sep 92 15:36:29 PDT Message-Id: <9209152236.AA21704@SSD.intel.com> To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu, prp@ssd.intel.com Subject: Re: Classic 8 In-Reply-To: Your message of "Tue, 15 Sep 92 16:33:41 CDT." <9209152133.AA26810@pyrite.cs.uiowa.edu> Date: Tue, 15 Sep 92 15:36:24 -0700 From: prp@ssd.intel.com To: "Douglas W. Jones" Cc: pdp8-lovers@ai.mit.edu, prp@ssd.intel.com Subject: Re: Classic 8 In-Reply-To: Your message of "Tue, 15 Sep 92 16:33:41 CDT." <9209152133.AA26810@pyrite.cs.uiowa.edu> Date: Tue, 15 Sep 92 15:36:24 -0700 From: prp@ssd.intel.com > 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 > jones@cs.uiowa.edu Paul Pierce prp@ssd.intel.com Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 19:39:36 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 19:39:34 -0400 Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA15824; Tue, 15 Sep 92 19:16:29 EDT Received: by watsun.cc.columbia.edu (5.59/FCB) id AA26674; Tue, 15 Sep 92 19:16:20 EDT Date: Tue, 15 Sep 92 19:16:19 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: Binary paper-tape files on PC's. Message-Id: Date: Tue, 15 Sep 92 19:16:19 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu 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 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 23:22:21 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 23:22:18 -0400 Received: from apache.telebit.com by life.ai.mit.edu (4.1/AI-4.10) id AA22375; Tue, 15 Sep 92 23:04:14 EDT Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA08234 to pdp8-lovers@ai.mit.edu; Tue, 15 Sep 92 20:04:10 PDT Received: from iceland.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA23863 to eric@telebit.com; Tue, 15 Sep 92 20:04:07 PDT Date: Tue, 15 Sep 92 20:04:07 PDT From: eric@napa.telebit.com (Eric Smith) Message-Id: <9209160304.AA23863@napa.TELEBIT.COM> Received: by iceland.telebit.com (4.1/SMI-4.1) id AA19688; Tue, 15 Sep 92 20:05:23 PDT To: pdp8-lovers@ai.mit.edu In-Reply-To: Charles Lasner's message of Tue, 15 Sep 92 19:16:19 EDT Subject: The PDP-8 Anonymous FTP Archive is Here! Date: Tue, 15 Sep 92 20:04:07 PDT From: eric@napa.telebit.com (Eric Smith) To: pdp8-lovers@ai.mit.edu In-Reply-To: Charles Lasner's message of Tue, 15 Sep 92 19:16:19 EDT 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 ("eric@telebit.com"). 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 eric@telebit.com 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 "pdp8-lovers-request@ai.mit.edu". Submissions to the list should be emailed to "pdp8-lovers@ai.mit.edu". Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 23:44:47 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Tue, 15 Sep 1992 23:44:10 -0400 Received: from lucifer.latrobe.edu.au by life.ai.mit.edu (4.1/AI-4.10) id AA22662; Tue, 15 Sep 92 23:15:06 EDT Received: by lucifer.latrobe.edu.au (5.57/Ultrix3.0-C) id AA04799; Wed, 16 Sep 92 13:14:50 +1000 From: cchd@lucifer.latrobe.edu.au (Huw Davies) Message-Id: <9209160314.AA04799@lucifer.latrobe.edu.au> Subject: Software for DECmate-II To: pdp8-lovers@ai.mit.edu Date: Wed, 16 Sep 92 13:14:49 EST X-Mailer: ELM [version 2.4dev PL17] From: cchd@lucifer.latrobe.edu.au (Huw Davies) Subject: Software for DECmate-II To: pdp8-lovers@ai.mit.edu 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 | cchd@lucifer.latrobe.edu.au 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 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Fri, 18 Sep 1992 08:24:19 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Fri, 18 Sep 1992 08:24:15 -0400 Received: from volitans.morningstar.com by life.ai.mit.edu (4.1/AI-4.10) id AA18107; Fri, 18 Sep 92 08:02:49 EDT Received: from trigger.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA06056; Fri, 18 Sep 92 08:02:22 -0400 Received: by trigger.morningstar.com (5.65a/92042102) id AA14740; Fri, 18 Sep 92 08:02:20 -0400 Received: by n8emr.cmhnet.org (Ohio AMPR Gateway Smail3.1.16.1 #16.33) id ; Fri, 18 Sep 92 07:25 EDT Received: by jcnpc.cmhnet.org (/\=-/\ Smail3.1.16.1 #16.31) id ; Fri, 18 Sep 92 04:56 EDT Received: by kumiss.cmhnet.org (V1.15/Amiga) id AA003mo; Fri, 18 Sep 92 00:11:37 EDT Date: Fri, 18 Sep 92 00:11:37 EDT Message-Id: <9209180411.AA003mo@kumiss.cmhnet.org> From: erd@kumiss.cmhnet.org (Ethan Dicks) To: prp@ssd.intel.com Cc: pdp8-lovers@ai.mit.edu Subject: Classic 8 Date: Fri, 18 Sep 92 00:11:37 EDT From: erd@kumiss.cmhnet.org (Ethan Dicks) To: prp@ssd.intel.com Cc: pdp8-lovers@ai.mit.edu 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 erd@kumiss.cmhnet.org ! of Pennsic Veterans everywhere: Beerios. ! "They don't stay crisp in beer, but who cares?" Summary-line: 18-Sep hackeron@athena.mit.edu #UNIX utilities to read/write DECmate 5.25 disk ? Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Sat, 19 Sep 1992 00:16:13 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sat, 19 Sep 1992 00:15:56 -0400 Received: from Athena.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA19489; Fri, 18 Sep 92 23:40:50 EDT Received: from MINOR.MIT.EDU by Athena.MIT.EDU with SMTP id AA29659; Fri, 18 Sep 92 23:40:48 EDT Received: by minor.MIT.EDU (5.61/4.7) id AA17272; Fri, 18 Sep 92 23:40:43 -0400 Message-Id: <9209190340.AA17272@minor.MIT.EDU> To: pdp8-lovers@ai.mit.edu 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 To: pdp8-lovers@ai.mit.edu 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 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 | |hackeron@athena.mit.edu () hgilliam@media-lab.media.mit.edu | |!bloom-beacon!mit-athena!hackeron GEnie : H.GILLIAM1 | |harris@fly.lcs.mit.edu <><~~~ | From LEVY@dcd00.fnal.gov Sat Sep 19 20:33:39 1992 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA03579; Sat, 19 Sep 92 20:33:31 EDT Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA03190; Sat, 19 Sep 92 20:33:12 EDT Received: from LEVY.FNAL.GOV by life.ai.mit.edu (4.1/AI-4.10) id AA07415; Sat, 19 Sep 92 20:21:54 EDT Date: Sat, 19 Sep 1992 19:21:45 -0500 (CDT) From: LEVY@dcd00.fnal.gov (Mark E. Levy, ext. 8056) Message-Id: <920919192145.292000ea@fndcd.fnal.gov> Subject: subscribe To: pdp8-lovers@ai.mit.edu X-Vmsmail-To: SMTP%"pdp8-lovers@ai.mit.edu" subscribe From fuller!intellection.com!emcguire@uu.psi.com Sun Sep 20 04:07:02 1992 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA09569; Sun, 20 Sep 92 04:06:54 EDT Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA01688; Sun, 20 Sep 92 04:06:34 EDT Received: from uu.psi.com by life.ai.mit.edu (4.1/AI-4.10) id AA14955; Sun, 20 Sep 92 03:48:20 EDT Received: from fuller.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) id AA03235; Sun, 20 Sep 92 03:45:30 -0400 Received: by fuller.intellection.com (4.1/SMI-4.1) id AA22788; Sun, 20 Sep 92 02:07:04 CDT Date: Sun, 20 Sep 92 02:07:04 CDT From: emcguire@intellection.com (Ed McGuire) Message-Id: <9209200707.AA22788@fuller.intellection.com> To: LEVY@dcd00.fnal.gov Cc: pdp8-lovers@ai.mit.edu In-Reply-To: Mark E. Levy, ext. 8056's message of Sat, 19 Sep 1992 19:21:45 -0500 (CDT) <920919192145.292000ea@fndcd.fnal.gov> Subject: subscribe X-Face: 1234567890ABCDEFEGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFEGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFEGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz Date: Sat, 19 Sep 1992 19:21:45 -0500 (CDT) From: LEVY@dcd00.fnal.gov (Mark E. Levy, ext. 8056) X-Vmsmail-To: SMTP%"pdp8-lovers@ai.mit.edu" subscribe You'll have better luck mailing this to pdp8-lovers-request. Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Tue, 22 Sep 1992 13:00:37 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Tue, 22 Sep 1992 13:00:05 -0400 Received: from albert.gnu.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA27592; Tue, 22 Sep 92 12:28:07 EDT Received: from kropotkin.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Tue, 22 Sep 92 12:28:03 -0400 Received: by kropotkin.gnu.ai.mit.edu (15.11/4.0) id ; Tue, 22 Sep 92 12:28:00 edt Date: Tue, 22 Sep 92 12:28:00 edt From: bson@gnu.ai.mit.edu Message-Id: <9209221628.AA09682@kropotkin.gnu.ai.mit.edu> To: pdp8-lovers@ai.mit.edu In-Reply-To: A.Sporner's message of Mon, 21 Sep 92 20:03:07 -0500 <9209220103.AA24392@eagle.ibc.edu> Subject: Desktop PDP-8? Date: Tue, 22 Sep 92 12:28:00 edt From: bson@gnu.ai.mit.edu To: pdp8-lovers@ai.mit.edu In-Reply-To: A.Sporner's message of Mon, 21 Sep 92 20:03:07 -0500 <9209220103.AA24392@eagle.ibc.edu> Subject: Desktop PDP-8? Andy, I've added you to the list. -- Jan Brittenson bson@gnu.ai.mit.edu Date: Mon, 21 Sep 92 20:03:07 -0500 From: grrr@eagle.ibc.edu (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 fluke!doctor@uunet.uu.net Tue Sep 22 22:02:09 1992 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA16026; Tue, 22 Sep 92 22:02:00 EDT Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB) id AA16185; Tue, 22 Sep 92 22:01:30 EDT Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) id AA19591; Tue, 22 Sep 92 21:52:03 EDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA00567; Tue, 22 Sep 92 21:52:10 -0400 Received: from fluke.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 215147.21005; Tue, 22 Sep 1992 21:51:47 EDT Received: by sputnik.tc.fluke.COM (version 2.52) from dudley.tc.fluke.COM for pdp8-lovers@ai.mit.edu id AA25578; Tue, 22 Sep 92 15:03:10 PDT Received: by dudley.tc.fluke.COM (version 2.52) for pdp8-lovers@ai.mit.edu id AA08911; Tue, 22 Sep 92 15:03:08 PDT Message-Id: <9209222203.AA08911@dudley> Date: Tue, 22 Sep 92 15:03:08 PDT From: doctor@tc.fluke.com (Doug Klopfenstein) To: pdp8-lovers@ai.mit.edu Subject: attn Rob Seastrom Please add me to the list. Doug Klopfenstein doctor@tc.fluke.com Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Thu, 24 Sep 1992 01:06:50 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Thu, 24 Sep 1992 01:06:48 -0400 Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02545; Thu, 24 Sep 92 00:42:30 EDT Received: by watsun.cc.columbia.edu (5.59/FCB) id AA12567; Thu, 24 Sep 92 00:42:28 EDT Date: Thu, 24 Sep 92 0:42:26 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu Subject: alt.sys.pdp8 is up Message-Id: Date: Thu, 24 Sep 92 0:42:26 EDT From: Charles Lasner To: pdp8-lovers@ai.mit.edu 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 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Thu, 24 Sep 1992 10:37:39 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Thu, 24 Sep 1992 10:37:37 -0400 Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) id AA16098; Thu, 24 Sep 92 10:05:10 EDT Received: from pyrite.cs.uiowa.edu by ns-mx.uiowa.edu (5.64.jnf/920408) on Thu, 24 Sep 92 09:04:51 -0500 id AA01411 with SMTP Received: by pyrite.cs.uiowa.edu (5.59/890218) on Thu, 24 Sep 92 08:54:11 CDT id AA04565 Date: Thu, 24 Sep 92 08:54:11 CDT From: Douglas W. Jones Message-Id: <9209241354.AA04565@pyrite.cs.uiowa.edu> To: pdp8-lovers@ai.mit.edu Subject: alt.sys.pdp8 Date: Thu, 24 Sep 92 08:54:11 CDT From: Douglas W. Jones To: pdp8-lovers@ai.mit.edu 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 jones@cs.uiowa.edu From andrewm@bio.uts.edu.au Fri Sep 25 04:30:24 1992 Return-Path: Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB) id AA20883; Fri, 25 Sep 92 04:30:08 EDT Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB/jba) id AA11346; Fri, 25 Sep 92 04:29:26 EDT Received: from sequoia.ccsd.uts.EDU.AU ([138.25.16.1]) by life.ai.mit.edu (4.1/AI-4.10) id AA20797; Fri, 25 Sep 92 04:10:44 EDT Received: from IRIS.bio.uts.EDU.AU by sequoia.ccsd.uts.EDU.AU with SMTP id AA17993 (5.65c/IDA-1.4.4 for ); Fri, 25 Sep 1992 18:10:16 +1000 Received: by IRIS.bio.uts.EDU.AU (911016.SGI/900605.SGI) (for pdp8-lovers@ai.mit.edu) id AA06691; Fri, 25 Sep 92 18:11:22 +1000 From: andrewm@bio.uts.edu.au (Andrew Mears) Message-Id: <9209250811.AA06691@IRIS.bio.uts.EDU.AU> Subject: UNSUBSCRIBE To: pdp8-lovers@ai.mit.edu Date: Fri, 25 Sep 92 18:11:21 EST X-Mailer: ELM [version 2.3 PL4] UNSUBSCRIBE Andrew Mears Please remove me from the list Cheers Andrew Mears Summary-line: 26-Sep francini@narfvx.enet.dec. #RE: alt.sys.pdp8 is up Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Sun, 27 Sep 1992 00:26:56 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sun, 27 Sep 1992 00:26:54 -0400 Received: from enet-gw.pa.dec.com by life.ai.mit.edu (4.1/AI-4.10) id AA17835; Sun, 27 Sep 92 00:05:01 EDT Received: by enet-gw.pa.dec.com; id AA01361; Sat, 26 Sep 92 21:04:54 -0700 Message-Id: <9209270404.AA01361@enet-gw.pa.dec.com> Received: from narfvx.enet; by decwrl.enet; Sat, 26 Sep 92 21:04:57 PDT Date: Sat, 26 Sep 92 21:04:57 PDT From: He was a dark and stormy Knight. 26-Sep-1992 1929 To: asimov::decwrl::"lasner@watsun.cc.columbia.edu"@ranger.enet.dec.com Cc: pdp8-lovers@ai.mit.edu Apparently-To: pdp8-lovers@ai.mit.edu 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 To: asimov::decwrl::"lasner@watsun.cc.columbia.edu"@ranger.enet.dec.com Cc: pdp8-lovers@ai.mit.edu Apparently-To: pdp8-lovers@ai.mit.edu 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 foner@media-lab.media.mit #TSS/8 Received: from ELI.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU via SMTP; Sun, 27 Sep 1992 01:29:13 -0400 Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Sun, 27 Sep 1992 01:29:10 -0400 Received: from media-lab.mit.edu (media-lab.media.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA18463; Sun, 27 Sep 92 01:08:17 EDT Received: by media-lab.mit.edu (5.57/DA1.0.3) id AA04275; Sun, 27 Sep 92 01:08:15 -0400 Date: Sun, 27 Sep 92 01:08:15 -0400 From: Leonard N. Foner Message-Id: <9209270508.AA04275@media-lab.mit.edu> To: pdp8-lovers@ai.mit.edu Subject: TSS/8 Cc: foner@media-lab.media.mit.edu Date: Sun, 27 Sep 92 01:08:15 -0400 From: Leonard N. Foner To: pdp8-lovers@ai.mit.edu Subject: TSS/8 Cc: foner@media-lab.media.mit.edu Date: Sat, 26 Sep 92 21:04:57 PDT From: He was a dark and stormy Knight. 26-Sep-1992 1929 [ . . . ] [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.]