From sjm1@crux2.cit.cornell.edu Fri Sep 3 17:40:50 EDT 1993 Article: 399 of alt.sys.pdp8 Newsgroups: vmsnet.pdp-11,alt.sys.pdp8,alt.folklore.computers,comp.sys.dec Path: news.columbia.edu!sol.ctr.columbia.edu!caen!batcomputer!news.graphics.cornell.edu!newsstand.cit.cornell.edu!piccolo.cit.cornell.edu!crux2!sjm1 From: sjm1@crux2.cit.cornell.edu (dental floss) Subject: Need some MINC-11 stuff... Message-ID: Keywords: MINC, PDP, DEC, bootstrap Sender: usenet@piccolo.cit.cornell.edu (NNTP Connect) Nntp-Posting-Host: crux2.cit.cornell.edu Organization: Cornell University Date: 2 Sep 93 01:24:01 GMT Lines: 22 Xref: news.columbia.edu vmsnet.pdp-11:1420 alt.sys.pdp8:399 alt.folklore.computers:50786 comp.sys.dec:16358 Hi all... I just picked up a MINC-11, and am in need of a few bits and peices. Specifically, I'm in need of a bootstrap, a CPU board, and a QBus RX-02 controller. If anyone has any of these things lying around and wants to send them to a good, good home, please drop me a line. And hey, if you happen to have a VT-105 lying around, I suppose I could use one of those to put together a setup that looks like the "Artist's Rendering" in the users manual :) How 70's can you get... Thanks! --Seth J. Morabito President, Cornell University Classic Computer Club --------------------------------------------------------------------- You never saw this signature. If anyone | Seth J. Morabito tries to tell you you did, just say "ee!" | sjm1@cornell.edu and pretend there are spiders on that | Virtual Programming person's arms, then run. That should | available: BASIC work. | only, please. -------------------------------------------------------------------- From adam@owlnet.rice.edu Fri Sep 3 17:40:53 EDT 1993 Article: 400 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!uwm.edu!rutgers!rochester!cornell!uw-beaver!newsfeed.rice.edu!rice!adam From: adam@owlnet.rice.edu (Adam Justin Thornton) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: The Analytical Engine (CHAC newsletter!) Message-ID: Date: 2 Sep 93 23:33:23 GMT References: <1993Aug31.215837.4918@news.uiowa.edu> Sender: news@rice.edu (News) Organization: Milo's Meadow Lines: 16 Xref: news.columbia.edu alt.sys.pdp8:400 alt.folklore.computers:50879 In article <1993Aug31.215837.4918@news.uiowa.edu> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >2) Pong was not a computer game! It was a video game implemented with > TTL logic, with no computer. Hey. Enough TTL _is_ a computer. Just 'cause it didn't have an LSI CPU...sheesh. I think I still have my old home version of _Super Pong_ (4 whole games!); I wonder if I clean the crud from the battery case if it'll still work. Adam -- adam@rice.edu | These? Rice's opinions? Yeah, right. | "Might there have been fewer crimes in the name of Jesus, and more mercy in the name of Judas Iscariot?"--Thomas Pynchon | Overheard in Waco: "This is not an assault." Save the Choad! | Win/NT: Yesterday's technology tomorrow. | 64,928 | Fnord From jones@pyrite Fri Sep 3 17:40:56 EDT 1993 Article: 401 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: The Analytical Engine (CHAC newsletter!) Sender: news@news.uiowa.edu (News) Message-ID: <1993Sep3.140927.5251@news.uiowa.edu> Date: Fri, 3 Sep 1993 14:09:27 GMT References: Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 31 Xref: news.columbia.edu alt.sys.pdp8:401 alt.folklore.computers:50915 >From article , by adam@owlnet.rice.edu (Adam Justin Thornton): > In article <1993Aug31.215837.4918@news.uiowa.edu> > jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: > >>2) Pong was not a computer game! It was a video game implemented with >> TTL logic, with no computer. > > Hey. Enough TTL _is_ a computer. Just 'cause it didn't have an LSI > CPU...sheesh. And I collect computers made with TTL without an LSI CPU; I have three of them sitting in my study right now at home! Still, Pong isn't a computer game because it doesn't have a computer! I'm using the standard definition of a computer -- that is, a general purpose machine capable of executing a program provided by the user. The logic inside a Pong game is a special purpose controller with a single fixed (but fairly complex) program that does only one thing. The border between computers, calculators and controllers can get fuzzy, for example, ENIAC was clearly a programmable calculator, but was it a computer? You could reprogram it with a patch panel change, and it was powerful enough that someone could have programmed a patch panel to make it interpret a stored program, but to my knowledge, nobody did it. You can't make that kind of quibble about Pong though. There were no provisions for even rudimentary programmability. Doug Jones jones@cs.uiowa.edu From kcrosby@crayola.win.net Fri Sep 3 17:40:59 EDT 1993 Article: 402 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!psinntp!witch!crayola!kcrosby Newsgroups: alt.sys.pdp8,alt.folklore.computers,sci.electronics Followup-To: poster Message-ID: <248@crayola.win.net> References: <1993Aug31.145000.24130@news.uiowa.edu> Reply-To: kcrosby@crayola.win.net (Kip Crosby) From: kcrosby@crayola.win.net (Kip Crosby) Date: Thu, 02 Sep 1993 16:55:38 GMT Subject: Re: Computer History Association of California (long) Lines: 126 Xref: news.columbia.edu alt.sys.pdp8:402 alt.folklore.computers:50919 sci.electronics:54804 In article <1993Aug31.145000.24130@news.uiowa.edu>, Douglas W. Jones (jones@cs.uiowa.edu) writes: >I've just discovered an interesting organization, the Computer History >Association of California, and it's clear that their goals are very much >in keeping with the goals of many of the readers who follow these >newsgroups. > >As near as I can figure, they're the first general membership association >devoted to historic preservation of computers. Thus, they may be able >to provide the kind of hacker-centered orientation that is lacking in >places like the Computer Museum and the Smithsonian. > [....sample ENGINE text clipped....] > >These people are doing the right thing, with essentially the same goals >that led to the formation of alt.sys.pdp8, but with a broader charter >and a more formal organization. They clearly have a regional focus, but >at the same time, the job they're talking about needs to be done >nationally and internationally. > >I feel that we preservationists should support them actively, either by >joining their organization (particularly, those of us in the bay area), >or by referring California hardware and documentation rescue work to them. >They've picked up a significant membership outside of California, but my >long-term hope is that we can get similar local organizations running on >the east coast and in the midwest. We've got the critical mass in both >places, but here in the midwest, we may not have the critical density. > Doug, Thank you for this glowing tribute! and, beyond that, for all the critical support offered to us through alt.sys.pdp8. I wouldn't change a word of what you've written (why would I need to?) but just a couple of comments: 1) If indeed we are "the first general membership association devoted to historic preservation of computers," we're not surprised. We started it because _we also_ couldn't find an existing one. But it's our hope, too, that someday soon there'll be "similar local organizations" in other parts of the country. That would ultimately provide the strong, broad grassroots base that would facilitate the organization of a true Computer History Association of America. Now, before we started the CHAC in April, we toyed with the notion of _founding_ the CHA of America. After the CHAC's first four months, we're glad we didn't try. First of all, we have to get _some_ sleep. Secondly, even with our avowedly strict focus on California, we've had (welcome!) correspondence not only from (e. g.) Iowa, Pennsylvania, Massachusetts, Florida.... but (e. g.) Finland, Denmark, Sweden, Germany, the UK, and Saudi Arabia. The Internet is astounding, which is a separate topic, but none the less true. And third, the hardware....! (Details in the October ENGINE.) 2) I'm not sure we're "hacker-centered" but we're hacker-propelled. To be "hacker-centered" would, I think, risk being exclusive in a negative sense and tend to push aside certain real pillars of computer history in California; for instance, the Bank of America's pioneering of electronic check processing with ERMA, which wasn't especially hackish but it sure is part of what we're about! On the other hand, it's true that a lot of California's (and especially Silicon Valley's) computer history is inseparable from a certain....effervescent ad-hockery, ebullience, zaniness. And we'd like to keep that as a flavor. 3) "the job they're talking about needs to be done nationally and internationally." Absolutely true! At the same time it's important to know that it _is_ being _begun_, nationally and internationally. In the last four months we've heard from many fine people and organizations -- I couldn't even list them all here but we'll try in the October ENGINE -- and one of the most important things we've accomplished is to get some of _them_ talking _to each other_. The work before us is big enough that, as we confront it, we can be bolstered by the knowledge that we're not alone in this. It makes for a tremendous sense of friendship and community. 4) Finally, I take your point about "critical mass and critical density." If you want to know about critical mass, just count the interesting micros we have stacked up in boxes! But I think any doubts about critical density of interest are alleviated, if not wiped out, by the speed and rate of diffusion of net.communication. (That, incidentally, is why we're currently composing an RFD of a newsgroup.) Computer history _is and is not_ a local pastime -- or, so to speak, "Talk locally, post globally." We have before us the means to overcome isolation completely. 5) Yes, we will try to take on rescue work. Our current capacity for it is very limited, but we at least want to know about it. 6) We need: _Money_ because we're getting bigger faster than we ever thought we would. Right now, and for the foreseeable future, CHAC is all- volunteer. But by the time we're working on some of what we outlined in the July ENGINE (like the museum,) we will be facing significant administrative expense and at least part-time salaries. _Space_ (storage) because people are offering us hardware that we don't want to see junked. _Members_, first, because without members we're nothin'. CHAC is _about_ computers, but also _about_ the people who create them, and _by and for_ the people who work with them and respect them. Second, because only with a substantial membership can we confront corporations and ask them for real support. Fundraising, too, is about people. A couple of days ago I got net.mail from someone that began "Is this legit? If so I think it's wonderful!" Well, it's wonderful. We know that already. We know that it's real. We know, above all, that it's needed. It can also be "legit" if -- and _only_ if -- enough people are willing to join us in what we're trying to do. Thanks again, Doug, and thanks to all who read this, I didn't mean it to be quite so long! __________________________________________ Kip Crosby kcrosby@crayola.win.net Computer History Association of California "History is what you make it...." From davidh@harlequin.co.uk Fri Sep 3 17:41:02 EDT 1993 Article: 403 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!uunet!pipex!harlqn.co.uk!homebrew.cam.harlequin.co.uk!davidh From: davidh@harlequin.co.uk (David Hembrow) Subject: Old architectures ( was Re: The Analytical Engine (CHAC newsletter!)) Message-ID: Lines: 28 Sender: usenet@harlqn.co.uk (Usenet maintainer) Nntp-Posting-Host: homebrew.cam.harlequin.co.uk Organization: Harlequin Ltd X-Newsreader: Trumpet for Windows [Version 1.0 Rev Final Beta #10] References: <1993Sep3.140927.5251@news.uiowa.edu> Date: Fri, 3 Sep 1993 15:53:49 GMT Xref: news.columbia.edu alt.sys.pdp8:403 alt.folklore.computers:50921 In article <1993Sep3.140927.5251@news.uiowa.edu> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >The border between computers, calculators and controllers can get fuzzy, >for example, ENIAC was clearly a programmable calculator, but was it a >computer? You could reprogram it with a patch panel change, and it was >powerful enough that someone could have programmed a patch panel to make >it interpret a stored program, but to my knowledge, nobody did it. Not a quibble, but possibly the start of a new interesting thread: Is this in fact true ? If you know enough about the way in which ENIAC was put together, could you provide some details of what it was in fact capable of ? I'd be interested in knowing something about the workings of some of these early computers ( especially the programmable ones ). ie. o Amount of memory o Instruction set o I/O capabilities I'm afraid there isn't a lot I can contribute to this, I know only what I've read in various books. They tend to give information like the number of valves ( tubes ) in each machine and make some statement about the number of operations a second it was apparently capable of but little more. David. From jones@cs.uiowa.edu Fri Sep 3 17:41:05 EDT 1993 Article: 404 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@cs.uiowa.edu (Douglas W. Jones) Subject: Re: Old architectures Sender: news@news.uiowa.edu (News) Message-ID: <1993Sep3.185632.12450@news.uiowa.edu> Date: Fri, 3 Sep 1993 18:56:32 GMT References: Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 120 Xref: news.columbia.edu alt.sys.pdp8:404 alt.folklore.computers:50934 >From article , by davidh@harlequin.co.uk (David Hembrow): > > I'd be interested in knowing something about the workings > of some of these early computers That's why I prepared the alt.sys.pdp8 faq (and I'm still working on improving it). Eventually, I'd like to see similar faq files for a number of other old machines. The next one I'd like to hammer down is the IBM 701, a 1953 gem for which I happen to have the principles of operation book. If you like such things, here's a brief summary: Computer: The IBM 701 Date: 1953 Technology: Vacuum Tubes! Size: CPU -- about 9 to 10 feet wide, 6 feet high, 2.5 feet deep. Main Memory -- 4 or 5 feet wide; depth and height as above. Main memory: 2048 words, 36 bits each, Williams tube technology. Addressing: word and half-word addressable. even negative numbers address words. even positive numbers address left-half-words. odd positive numbers address right-half-words. Registers: Accumulator -- 37 bits. two extra bits are provided for magnitude overflow. MQ (multiplier-quotient) -- 38 bits. half-word loads and stores use the high 18 bits of registers. Number system: Signed magnitude Arithmetic assumes 35 bits right of the point. Instruction: 18 bit (half word) instructions, formed as: sign of address | 6 bit opcode | 12 bit address Instruction set: mnemonic opcode R ADD 10 reset and add memory to accumulator. ADD 09 add memory to accumulator. ADD AB 11 add absolute value of memory to accumulator. R SUB 06 reset and subtract memory from accumulator. SUB 05 subtract memory from accumulator. SUB AB 07 subtract absolute value of memory from accumulator. STORE MQ 14 store MQ in memory. ROUND 19 round accumulator by most significant bit of MQ. MPY 16 multiply MQ by memory giving result in AC-MQ. MPY ROUND 17 multiply followed by round DIV 18 AC-MQ div memory; MQ gets quotient, AC gets rem. A RIGHT 23 Accumulator shift addr field places right. A LEFT 22 Accumulator shift addr field places left. L RIGHT 21 AC-MQ shift address field places to the right. L LEFT 20 AC-MQ shift address field places to the left. TR 01 Transfer control to the given address. TR + 03 Transfer on accumulator positive. TR 0 04 Transfer on accumulator zero. TR OV 02 Transfer on overflow and reset overflow indicator. STOP 00 Stop, transfer to given address on restart. STORE A 13 Store address field from high halfword of AC. READ 24 Prepare to read one unit record from device. READ B 25 Prepare to read one unit record backward. WRITE 26 Prepare to write one unit record to device. WRITE EF 27 Write end of file to mag tape unit. REWIND 28 Rewind tape unit. SET DR 29 Set drum address of next unit record to read/write. COPY 31 Copy one data word to or from unit record. SENSE 30 Signal device and conditional skip on result. Notes on instructions: Note the lack of procedure call instructions or provisions for array addressing! The STORE A instruction was provided to allow easy construction of self-modifying code, and with careful self- modification, both could be accomplished. Note the lack of logical operations. The importance of shifting was understood, but if you wanted to mask something, you had to shift one way and then the other, letting bits fall off the ends of the accumulator to clear them, and keeping in mind the extra two magnitude bits on the accumulator. Note that the mnemonics weren't designed for processing by an assembler. Assemblers weren't routinely used yet, and programmers generally programmed in binary and then punched their programs in absolute binary on punched cards! The manual includes a bootstrap loader that will load a single card image into memory, and then it includes a loader that fits on one-card to load a card deck full of code into memory. I have one used coding form from the MIT Digital Computer Laboratory that was apparently for this machine, and I have Diazo copies of other similar forms. They never use the mnemonics given above! instead, they use cryptic two-letter abbreviations. Unit record formats: 80 column punched cards were handled as 12 rows of 72 columns, with each column stored in two consecutive memory locations, reading from the bottom of the card to the top. A patch panel determined which columns the printer and punch would handle. The printer had 120 columns, with a character set of 48 characters. Output was in card image format, so no more than 72 characters could be printed per line. A patch panel determined which 72. The magnetic tape drives stored data in 6 channels, with a 7th channel added for parity, all on half-inch wide tape with 1400 feet of tape per reel. This was the first computer to use this format, a format that lasted through the 1960's. The magnetic drum system stored 2048 words per drum, addressed by even integers as in main memory. Words on drum are randomly accessable (within the limits of latency), with a set-drum-address command used to specify the starting drum address of each transfer, followed by a sequence of copy instructions to move the data. I/O instructions, particularly the copy instruction, were blocking, and would hang the CPU until the transfer was complete. From lasner@sunSITE.unc.edu Fri Sep 3 23:02:50 EDT 1993 Article: 405 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!darwin.sura.net!news-feed-2.peachnet.edu!concert!samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Happy PDP-5 day Date: 4 Sep 1993 02:20:33 GMT Organization: University of North Carolina, Chapel Hill Lines: 13 Message-ID: <268u1h$rgq@samba.oit.unc.edu> References: <24tasv$cb6@apakabar.cc.columbia.edu> <1993Aug24.074226.1@cc.curtin.edu.au> NNTP-Posting-Host: calypso.oit.unc.edu Xref: news.columbia.edu alt.sys.pdp8:405 alt.folklore.computers:50947 In article <1993Aug24.074226.1@cc.curtin.edu.au>, Paul Repacholi wrote: >In article , bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >> In <24tasv$cb6@apakabar.cc.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: I didn't say that; watch the attribution! >Hey Charles, do you know the Zigglet story? No, please enlighten us. cjl From lasner@sunSITE.unc.edu Fri Sep 3 23:02:56 EDT 1993 Article: 406 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!darwin.sura.net!news-feed-2.peachnet.edu!concert!samba.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Happy PDP-5 day Date: 4 Sep 1993 02:31:15 GMT Organization: University of North Carolina, Chapel Hill Lines: 35 Message-ID: <268ulj$rr7@samba.oit.unc.edu> References: <1993Aug11.100431.71047@cc.usu.edu> <1993Aug27.125044.1@dstos3.dsto.gov.au> NNTP-Posting-Host: calypso.oit.unc.edu In article <1993Aug27.125044.1@dstos3.dsto.gov.au>, wrote: >In article , minow@apple.com (Martin Minow) writes: >> >> RT11 was done by many of the same people who had worked on OS/8. It >> used some of the OS/8 ideas, but wasn't very similar inside. Its > >One difference that seemed significant to me at the time I used these things, >was that OS/8 turned interrupt of, RT11 of course had it on. This is quite true, and is why OS/8 can get away with what was once known as "the glorious lack of overlap" which allows handlers the right to depend on the use of the data-break locations in 07750-07756 to be used as temporaries from OS/8 system handlers for other devices. If a handler were running on these devices, the locations could be in the state of being wiped out by those handlers, etc. unbeknownst to the system handler. Of course this also means that for all programs other than the likes of F4, which has its own interrupt system while active, you cannot get overlapped I/O on unit record stuff like the LPT or 03/04 console, etc. However, if you want to write a high-performance real-time system of your own design, the non-interrupt nature of OS/8 is such that it's totally out of your way, since you don't have to go around patching interrupt handlers to point to your code, and hooked to other routines from other areas of the system as well. Real-time applications and overly clumsy interrupt structures don't mix. Witness MS-DOS for an "interesting" example of this, etc. When every cycle matters, give me a system that gets out of my way, as opposed to something where everything is "built-in" but you have to conform to the structure, which can inevitable work against you. (Anyone ever met people who counted instructions on LSI-11-based real-time code?) cjl From lasner@watsun.cc.columbia.edu Sat Sep 4 02:58:35 EDT 1993 Article: 407 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: The Analytical Engine (CHAC newsletter!) Date: 4 Sep 1993 03:46:27 GMT Organization: Columbia University Lines: 109 Message-ID: <26932j$fg@apakabar.cc.columbia.edu> References: <1993Aug31.215837.4918@news.uiowa.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:407 alt.folklore.computers:50952 In article <1993Aug31.215837.4918@news.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: >There were indeed more than a few errors in that newsletter! Yes, as several people pointed out. I have an additional criticism: I truly believe in the intended cause the CHAC people are attempting, and I really hope they succeed, but unfortunately, they seem to be victims of their own predictions. In order for such an organization to succeed, it must *flawlessly* pursue its subject matter. Towards that end, I would suggest that groups such as alt.sys.pdp8 act as super-proof-readers of such material, i.e., post draft copies here first and allow us pedantic pdp-8'ers and other interested hanger-outers to tear apart their articles for technical accuracy, all in the interest of upping the quality of the product, etc. As it stands now, it's a little too revisional for me, although admittedly only a little. Forgive me for saying it, but from my vantage point, someone who happened upon a 1401 in 1965 ain't a pioneer! This is only marginally before my time, and I already knew enough to know the mistakes pointed out elsewhere, and I consider myself "second generation", not a true pioneer in the industry, etc. > >1) The IBM 1401 was not a vacuum tube machine! It was transistorized. Amen! And it always had all of the core memory present. There was a jumper to make half of the stack go away if the customer didn't pay for field service for it! (And sometimes a friendly tech could put it back in!) > >2) Pong was not a computer game! It was a video game implemented with > TTL logic, with no computer. Correct, Pong from Atari is a hard-wired TTL controller that plays a true video game using digital techniques to accomplish all the features. Contrast that with the earlier Magnavox Odyssey which wasn't even a digital device. Further, there is no provision to reprogram the device that Pong is, although you can get into a grey area if something akin to a patch panel or even a control ROM is used to transiently change the controller's exact function. In any case, it still ain't a computer, since it lacks a program that can be stored, nor has the storage itself to do such a thing either. This is also far afield from a true computer with a ROM-based program that as provided cannot be changed without changing the ROM, because the ROM *could* be changed if need be, and the changes could bring about either of two effects: 1) the program could run the same way with totally different contents because it's usually possible to program any reasonable task using entirely different algorithms thus different, yet equivalent program sequences, or 2) The program will run materially different if small changes to the code are made. The complications arise when a feature of the program is to sense external options such as DIP switches or perhaps even semi-random input devices to determine just what to do. (Meaning that it's possible to use a computer to simulate a hard-wired controller whose wiring gets patched, etc.) > >3) Spacewar wasn't a video game! Video encoding of data was not used to > paint the image on the face of the CRT. Instead, the software drove > a pair of ADC's to handle deflection in the X and Y directions, and > the software painted each dot on the screen. The resolution was far > better than standard video, but the number of dots that could be > painted without causing flicker was limited. This point is particularly galling as it's getting increasingly difficult to explain to people that just because a screen lights up, it ain't gonna necessarily be video! The great thing about oscilloscope graphics is the random access aspect of it. Without having to rigorously display in raster order, you totally avoid the jaggies, and most of these tubes use 12-bit D-A convertors to make matters even better. But when you don't use raster order, and instead draw points where you want/need them, the jaggies just don't happen. This is why DEC has made various displays that were adequate with as little as 8-bits D-A convertors, and not the slightest aliasing visible on the typical 'scopes used with them. (Such as the LINC-8 or the AX08 with various Tektronix scopes attached, etc.) > >(By the way, I have played spacewar myself on a DDP 224 computer at the >University of Michigan -- that machine was a nice 24 bit minicomputer, >and their version of spacewar used two joysticks on the graphics display.) The description of the PDP-1 spacewar, clearly the first version, entirely matches the 4K w/EAE PDP-8 version attributable to Richard Lary, Herb Jacobs, and Rod Dorman, etc., which is usually distributed with P?S/8, which is able to load it on a 4K PDP-8 it can run from, etc. > >In any case, the folks at CHAC clearly have their hearts in the right >place, and the kinds of errors they made in their newsletter only serve >to prove the point of their opening editorial! History is indeed being >lost and forgotten at an impressive rate! Yes, if those who are committed to wanting to preserve history can't quite get it together, we can't possibly succeed! We must help these folks get their act together completely. All of us have a part to play to get it correct, before the entire history of computing is personally attributed to Bill Gates, now sometimes erroneously attributed to as the author of the original BASIC among other things! > > Doug Jones > jones@cs.uiowa.edu cjl From lasner@watsun.cc.columbia.edu Sat Sep 4 02:59:15 EDT 1993 Article: 408 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: The Analytical Engine (CHAC newsletter!) Date: 4 Sep 1993 03:53:57 GMT Organization: Columbia University Lines: 35 Message-ID: <2693gl$iv@apakabar.cc.columbia.edu> References: <1993Sep3.140927.5251@news.uiowa.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:408 alt.folklore.computers:50953 In article <1993Sep3.140927.5251@news.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: >From article , >by adam@owlnet.rice.edu (Adam Justin Thornton): > >> In article <1993Aug31.215837.4918@news.uiowa.edu> >> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >> >>>2) Pong was not a computer game! It was a video game implemented with >>> TTL logic, with no computer. >> >> Hey. Enough TTL _is_ a computer. Just 'cause it didn't have an LSI >> CPU...sheesh. > >And I collect computers made with TTL without an LSI CPU; I have three >of them sitting in my study right now at home! And I (and Doug) collect computers that don't even have TTL in them, or even the forerunner DTL chips either, or even RTL! The original PDP-8, LINC-8, various peripheral controllers, etc., are all made out of discrete components meaning transistors, diodes, resistors, capacitors, a few pulse transformer coils, a few oscillator crystals hooked to analog oscillator circuits made of additional discrete components (years before the concept of the "oscillator in a can"), etc. Hundreds of little boards each stocked with a significant quantity of some of all of the above only. And surprisingly, the PDP-8/i, made mostly of TTL, isn't that much smaller, in large part because the little boards are the limiting factor. Most of the M-series cards are empty real-estate, because for most cards, all of the card-edge fingers are used up by the functionality of 3 TTL chips. In the R-series modules, even with 1/2 the fingers, the connectivity to density ratio was more favorable. Until DEC went to much larger modules, the fingers were a long-standing bottleneck, etc. cjl From corcoran@icd.teradyne.com Sat Sep 4 03:00:00 EDT 1993 Article: 409 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!olivea!hal.com!decwrl!netcomsv!attain!icd.teradyne.com!news_server!corcoran From: corcoran@difrel.world (Travis Corcoran) Subject: Re: The Analytical Engine (CHAC newsletter!) In-Reply-To: adam@owlnet.rice.edu's message of 2 Sep 93 23:33:23 GMT Message-ID: Sender: news@icd.teradyne.com (News admin) Reply-To: SILICA GEL - DO NOT EAT Organization: /u/corcoran/.organization References: <1993Aug31.215837.4918@news.uiowa.edu> Date: Sat, 4 Sep 1993 01:36:09 GMT Lines: 30 Xref: news.columbia.edu alt.sys.pdp8:409 alt.folklore.computers:50956 In article adam@owlnet.rice.edu (Adam Justin Thornton) writes: >2) Pong was not a computer game! It was a video game implemented with > TTL logic, with no computer. Hey. Enough TTL _is_ a computer. Just 'cause it didn't have an LSI CPU...sheesh. I think I still have my old home version of _Super Pong_ (4 whole games!); I wonder if I clean the crud from the battery case if it'll still work. My aptmate is the proud owner of a *WORKING* Pong game. Over the last few months we've played more Pong than...well, we've played a lot of Pong...;) Somehow the classics never go out of style... -- __ TJIC (Travis J.I. Corcoran) Corcoran@ICD.teradyne.com opinions(TJIC) != opinions(employer(TJIC)) "It's like the '64 Air Force mission to the moon-you want to be on the cutting edge, you gotta live with the secrecy." "What Air Force mission to the moon?" "See?" -'In the Hole w/ the Boys w/ the Toys' G.Landis IAFSM Oct 93 From corcoran@icd.teradyne.com Sat Sep 4 03:00:23 EDT 1993 Article: 410 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!olivea!hal.com!decwrl!netcomsv!attain!icd.teradyne.com!news_server!corcoran From: corcoran@difrel.world (Travis Corcoran) Subject: Re: The Analytical Engine (CHAC newsletter!) In-Reply-To: adam@owlnet.rice.edu's message of 2 Sep 93 23:33:23 GMT Message-ID: Sender: news@icd.teradyne.com (News admin) Reply-To: SILICA GEL - DO NOT EAT Organization: /u/corcoran/.organization References: <1993Aug31.215837.4918@news.uiowa.edu> Date: Sat, 4 Sep 1993 01:37:27 GMT Lines: 30 Xref: news.columbia.edu alt.sys.pdp8:410 alt.folklore.computers:50957 In article adam@owlnet.rice.edu (Adam Justin Thornton) writes: >2) Pong was not a computer game! It was a video game implemented with > TTL logic, with no computer. Hey. Enough TTL _is_ a computer. Just 'cause it didn't have an LSI CPU...sheesh. I think I still have my old home version of _Super Pong_ (4 whole games!); I wonder if I clean the crud from the battery case if it'll still work. My aptmate is the proud owner of a *WORKING* Pong game. Over the last few months we've played more Pong than...well, we've played a lot of Pong...;) Somehow the classics never go out of style... -- __ TJIC (Travis J.I. Corcoran) Corcoran@ICD.teradyne.com opinions(TJIC) != opinions(employer(TJIC)) "It's like the '64 Air Force mission to the moon-you want to be on the cutting edge, you gotta live with the secrecy." "What Air Force mission to the moon?" "See?" -'In the Hole w/ the Boys w/ the Toys' G.Landis IAFSM Oct 93 From lasner@watsun.cc.columbia.edu Sat Sep 4 03:02:55 EDT 1993 Article: 411 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: The Analytical Engine (CHAC newsletter!) Date: 4 Sep 1993 07:02:35 GMT Organization: Columbia University Lines: 15 Message-ID: <269eib$478@apakabar.cc.columbia.edu> References: <1993Aug31.215837.4918@news.uiowa.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:411 alt.folklore.computers:50966 In article , Travis Corcoran wrote: >My aptmate is the proud owner of a *WORKING* Pong >game. Over the last few months we've played more Pong than...well, >we've played a lot of Pong...;) Somehow the classics never go out of >style... (Coke|chinos|jeans|etc.) here.> Hmm... Stories like this seem to cut down on some of the CHAC story about there being only a few of them left? cj "owner of less than 4,000,000 PDP-8's" From cgordon@vpnet.chi.il.us Sun Sep 5 10:52:19 EDT 1993 Article: 412 of alt.sys.pdp8 Newsgroups: alt.technology.obsolete,alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!ames!koriel!lll-winken.llnl.gov!iggy.GW.Vitalink.COM!wetware!spunky.RedBrick.COM!psinntp!psinntp!laidbak!tellab5!vpnet!cgordon From: cgordon@vpnet.chi.il.us (gordon hlavenka) Subject: Re: WOODEN MEN AND IRON D Message-ID: <1993Sep3.064117.6177@vpnet.chi.il.us> Organization: Vpnet - Public Access Unix and Usenet References: <60.599.5476.0N1821B3@canrem.com> <9308290316.AA56470@fizbin.intercon.com> <1993Aug30.164557.24138@srzts100.alcatel.ch> Date: Fri, 3 Sep 1993 06:41:17 GMT Lines: 23 Xref: news.columbia.edu alt.technology.obsolete:153 alt.sys.pdp8:412 > Isn't core memory a "moving part" ? > >Lord no!!! > >It's quite rugged.... No kidding... I remember sitting in on a session at a DECUS symposium. The session was called "Strange Things To Do With Your Digital Computer". One of the things they talked about was a pdp8 that was used to record data from nuclear blast testing. The computer was in a trailer directly over ground zero for underground tests. When the shock wave hit, the whole trailer was thrown several feet in the air, and most of the PCBs were unseated from the computer and strewn about the inside of the trailer. The guys in devo suits would collect the core boards, which would then be plugged into other machines and the data read out. I guess this means that core memory is also rad-hard. -- ---------------------------------------------------- Gordon S. Hlavenka cgordon@vpnet.chi.il.us Proud father of Daniel Scott born August 9, 1993 From dave%gilly@speedway.net Sun Sep 5 10:53:23 EDT 1993 Article: 413 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news!news.world.net!speedway.net!gilly!dave Message-ID: <93635081313.dave.15112@gilly.UUCP> Date: Sat, 04 Sep 93 08:13:14 EDT Reply-To: dave%gilly@speedway.net Organization: Flat Earth Liberation Front Against Television From: dave@gilly.UUCP Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: The Analytical Engine (CHAC newsletter!) References: <269eib$478@apakabar.cc.columbia.edu> Lines: 16 Xref: news.columbia.edu alt.sys.pdp8:413 alt.folklore.computers:51023 lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >Stories like this seem to cut down on some of the CHAC story about there >being only a few of them left? > >cj "owner of less than 4,000,000 PDP-8's" Chill out dude, there's a difference between the coin-operated arcade games that article was about, and the home version that you can get anywhere these days for $15. Arcade games are "upgraded" to new games by swapping the guts and putting new stickers on the outside, so most of the early one are extremely rare now. ------------------------ uunet!quack!gilly!dave ------------------------ ================= Dave Fischer - Nature's Perfect Food ================= ----------------------- dave%gilly@speedway.net ------------------------ From erd@kumiss.cmhnet.org Sun Sep 5 10:54:20 EDT 1993 Article: 414 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!mstar!n8emr!jcnpc!kumiss!erd From: erd@kumiss.cmhnet.org (Ethan Dicks) Subject: Re: The Analytical Engine (CHAC newsletter!) Newsgroups: alt.sys.pdp8,alt.folklore.computers Followup-To: alt.sys.pdp8,alt.folklore.computers References: <26932j$fg@apakabar.cc.columbia.edu> X-Newsreader: TIN [version 1.1 PL9] Message-ID: Date: 4 Sep 93 23:21:01 EDT Organization: Not an Organization Lines: 24 Xref: news.columbia.edu alt.sys.pdp8:414 alt.folklore.computers:51028 Charles Lasner (lasner@watsun.cc.columbia.edu) wrote: : Correct, Pong from Atari is a hard-wired TTL controller that plays a true : video game using digital techniques to accomplish all the features. Contrast : that with the earlier Magnavox Odyssey which wasn't even a digital device. I just unpacked my old Magnavox, complete with the plastic colored screen overlays (in two sizes) for adding boundaries and other features to the games. I have dissected in more than once (and it still works :-), and can confirm personally that it is a strictly analog device. The motherboard is populated with edge-card connectors which are filled with 2"x2" circuit boards to perform things like horizontal timing, vertical timing, dot generation, drift, etc. The specifics of the game (control of the ball, display of paddles, response on collision detection, etc.) are selected by plugging in a "cartridge". This cartridge contains no active components, but rather jumpers various pins of the 44 pin connector, turning on or turning off various features. To play a game, you tape the correct colored overlay to the screen and plug in the correct cartridge. Stone knives and bearskins. -ethan From erd@kumiss.cmhnet.org Sun Sep 5 10:57:20 EDT 1993 Article: 415 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!mstar!n8emr!jcnpc!kumiss!erd From: erd@kumiss.cmhnet.org (Ethan Dicks) Subject: Re: Computer History Association of California (long) Newsgroups: alt.sys.pdp8 Summary: Keywords: X-Newsreader: TIN [version 1.1 PL9] Message-ID: Date: 5 Sep 93 00:23:16 EDT Organization: Not an Organization Lines: 94 In article <1993Aug31.145000.24130@news.uiowa.edu>, Douglas W. Jones (jones@cs.uiowa.edu) writes: >I've just discovered an interesting organization, the Computer History >Association of California, and it's clear that their goals are very much >in keeping with the goals of many of the readers who follow these >newsgroups. Yup. >As near as I can figure, they're the first general membership association >devoted to historic preservation of computers. Thus, they may be able >to provide the kind of hacker-centered orientation that is lacking in >places like the Computer Museum and the Smithsonian. Could be. >I feel that we preservationists should support them actively, either by >joining their organization (particularly, those of us in the bay area), >or by referring California hardware and documentation rescue work to them. >They've picked up a significant membership outside of California, but my >long-term hope is that we can get similar local organizations running on >the east coast and in the midwest. We've got the critical mass in both >places, but here in the midwest, we may not have the critical density. I've been toying with the idea of a preservation group, myself, but have been far too busy with job-related activities to actually sit down and write up a charter and incorporate. CHAC may actually be the kick-in-the-pants that I need. I am already interested and have already begun to collect the physical material that such a group would need to have access to. I have been (compulsively) collecting manuals and schematics for years and have quite a collection of aged equipment. One of the jewels of the collection is a VAX-11/750 S/N BT000254 with disks and other accessories, running as a production machine from shipment until last month. I also have a pair of classic PDP-8 (no TTL) CPUs, but with only DF-32 disks; these haven't been used in over 15 years - one of these units is in the ad on the back of "CPU WARS". My real question is this: how much interest is there in trying to put up an information preservation society, here in the midwest? Doug Jones is in Iowa; I am in Ohio; who else is close? What kind of information are people most interested in preserving? I have operating systems, system manuals, maintenance manuals, several dozen cartons of computer magazines from the 70's, and dozens of CPUs to go with the info. Most of my stuff is either IBM mainframe, DEC mini or Commodore micro related. There's obviously a lot more out there than that. I, too, am a bit sickened by the attitudes and actions of the Computer Museum in Boston. I've been to the technology exhibit at the Smithsonian and think it's a good start, but the history of computers is not the focus there, merely a reoccuring theme throughout the exhibit. We need groups (like CHAC) to study, collect and disseminate rapidly dwindling info on systems which are more than a few years old. Who here can read a LINCtape? I can't. If I get my PDP-8 hardware in better shape, I could read a DECtape, but not a LINCtape. Who here can read 7-track magtape? Not me. I can't even read 800 bpi magtape (if I could, I'd get a bunch of old BASIC games for RSTS off of a couple of tapes I've got which were cut in the late 1970's - if they are still legible). Even preserving non-technical information (like price/performance, kbytes/kilowatt, KIPS/metric ton, bytes/ BTU) is useful, because it lets us know how we got to where we are and where else we might be expected to go. Someone mentioned to me that microfische is an inexpensive way to go... 1000 pages/$20 for the first copy, subsequent copies cheaper. As was mentioned elsewhere, space is a premium, diskspace doubly so. Scanned pages take up a lot of space, but might be appropriate for a CD-ROM. So... who's willing to put up time, equipment, space or money? I am already preparing to start a 501(c3) organization to provide a home for wayward information and equipment. Do I hear any support from the people near me? Do I hear any support from people not near me? My first interest is in founding a library; my second, a museum. The library is a lot easier and cheaper. The museum would require at least 1000 sq. ft. of open space (which is not as large as you probably think it is) and would probably take about $10,000 - $20,000 annually for rent, electricity, A/C and other kinds of building related overhead; salaries (in the absence of an all-volunteer staff) would be a lot more. I don't see a museum happening for quite a few years (if ever), but it's been a distant goal of mine for a long time. The only way to get members (over the long term) is to provide a benefit for membership. A newsletter/magazine is one way, but the costs of providing a publication eat into the benefits to the organization. Another benefit for membership might be data conversion either free or at reduced prices to members. Still another might be repair of certain kinds of hardware at reduced prices or free to members. These other benefits also can produce hidden costs which can inhibit the growth of an organization. A very potential benefit might be the sale of spares and repair parts as well as manuals (duplicates of originals, or legal copies) to members only. This would not be the same as selling useful parts to gawking spectators, but could assist interested parties in keeping their own machines going. All proceeds of the sales would go towards maintenance and aquisitions. Feedback? Sugestions? Flames? Offers for help? -ethan From hahn@eisner.decus.org Tue Sep 7 00:57:46 EDT 1993 Article: 416 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!noc.near.net!eisner.decus.org!hahn From: hahn@eisner.decus.org Newsgroups: alt.sys.pdp8 Subject: PDP-8 latest version is a DECmate ! Message-ID: <1993Sep6.165628.505@eisner.decus.org> Date: 6 Sep 93 16:56:28 -0400 Distribution: world Organization: DECUServe Lines: 3 I also liked the PDP-8, and worked on the 8-I, but these days I am concentrating on DECmates (II and III). My collection of manuals will probably go to DECUS where there will be available to anyone - without membership needed. From lasner@watsun.cc.columbia.edu Tue Sep 7 01:24:28 EDT 1993 Article: 417 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: Computer History Association of California (long) Date: 7 Sep 1993 05:21:07 GMT Organization: Columbia University Lines: 128 Message-ID: <26h5o3$cma@apakabar.cc.columbia.edu> References: NNTP-Posting-Host: watsun.cc.columbia.edu In article , Ethan Dicks wrote: >systems which are more than a few years old. Who here can read a LINCtape? >I can't. If I get my PDP-8 hardware in better shape, I could read a >DECtape, but not a LINCtape. Who here can read 7-track magtape? Not me. >I can't even read 800 bpi magtape (if I could, I'd get a bunch of old BASIC >games for RSTS off of a couple of tapes I've got which were cut in the >late 1970's - if they are still legible). Even preserving non-technical Ethan's words don't go on deaf ears. We all get busy, but there are things that can be done, and the spirit of the CHAC people should at least be a guiding principle for some of us, but we have to have the time for it, which for me, sometimes seems to just disappear! OK, here's a run-down of what I do/can do. In no particular order, all of the following apply to me: 1) I do have a life! (This is more than a vicious rumor.) 2) I run a consulting business to eat, and it does occasionally take up large hunks of time as it should. It encompasses everything from PDP-8 programming to data conversion to PC construction/configuration upgrade/repair/trade-in/sell-off/application writing/installation MIDI applications to expert witnessing to the legal profession to computer advisor/consultant to the Board of Ed. locally. (Yeah, I wear a lotta hats :-).) 3) I started this newsgroup personally. (I can post the control messages if anyone's interested. Thanks to some net gurus who helped me immensely.) I contribute here regularly, and also to other groups such as comp.sys.dec.micro, alt.folklore.computers, and alt.folklore.urban. (I do *not* contribute to alt.sex.bondage.hamster.duct-tape.) And apparently our readership has grown over the approx. one year that a.s.p has been in business! 4) In my spare (!) time I support Kermit-12, the PDP-8/-12/DECmate Kermit program and related utilities, slowly develop P?S/8, the alternate O/S for the -8/-12/DECmates, and slowly develop OS/8 Version 5, the replacement OS/8 system that unifies all of the "orphan" versions currently around due to hardware dependencies, etc. One of the most significant aspects of this is to reveal the "secrets" of the DECmates, especially the DM II, III, III+. This has lead to various efforts of pleading with DEC people, mostly to no avail, and to a whole lot of disassembly of -8 binary, much of which has been obtained by dumping ROM's, and having to write whole sets of utilities to bring the code back to the appropriate form just to carry it out, etc. (Many thanks to the relevant contributors of the information I need to carry out a lot of this; you know who you are!) 5) I get a whole lot of e-mail! :-) (Who doesn't?) 6) I distribute lotsa -8/12/DECmate programs to many people, often through e-mail. Sometimes this involves using utilities for unix, PC's, and various RX50-based DEC machines all at once. I personally upgraded the specification for the Columbia University .BOO distribution format to eliminate design errors, and created the first correct version - the PDP-8 version for the OS/8 family. Others have followed suit with versions for unix, MS-DOS, VMS, etc., so there is now another whole level of compatibility between the -8 and other systems, etc. 7) I maintain a PDP-8 archives at sunsite.unc.edu in the /pub/academic/computer-science/history/pdp-8 area. Sources and binaries of PDP-8 and DECmate programs and even RX50 images can be obtained there through anonymous ftp. Archives of this newsgroup are stored in: /pub/academic/computer-science/history/pdp-8/usenet/alt.sys.pdp8 The file format is month-by-month. The August archive file has just been placed there as 9308.asp. Archive files are generally placed a few days into the following month. Read the associated file 00-INDEX in the same directory for more details, etc. 8) I have a few machines that can interact to allow media conversion to/from all of the following: DECtape (PDP-8/e-a with TC08/TU56 (4 drives) LINCtape (LINC-8 which can read/write DECtape and is also interfaced to the PDP-8/e-a) Paper-tape (PC04 reader/punch) RX01 (DSD-210 which can also *FORMAT* RX media!) RX02 (RX02 sharable between DECmate I, DECmate II, and PDP-8/e-a) RK8E (various RK05's on several 8/e, 8/e-a machines) 800/1600/3200 BPI 9-track magtape (M4 on PDP-8/e-a) 1.2 Meg floppy (on SCSI adaptor on PDP-8/e-a) (with some effort, it is possible to create 1.44 Meg 3.5" diskettes as well. Of course I can also support all of the popular PC versions of these diskettes, but I am referring to PDP-8 bootable floppies in these HD formats. Moreover, these bootable floppies can be used by various emulators such as PC-based PDP-8 emulators, etc. Someone has requested the 3.5" version for use with a MAC-based -8 emulator, etc.) 80 MByte MFM disks (on PDP-8/e-a SCSI) SyQuest SQ-555 45 MB cartridge disks (on PDP-8/e-a and also on PC) RX50 (DECmates) Colorado Memories DJ-10 and DJ-20 cartridge tape drives (on PC). All of the machines support serial communications between any two of them or to a modem and indirectly the net, etc. All of the machines run Kermit except the 4K LINC-8 which can transfer data to/from the PDP-8/e-a using either a hand-made bidirectionally interface or the LINC-8's ability to transfer data to/from DECtape due to hardware modifications made to it some years ago, etc. The DJ-20 tapes store 120 MBytes (Hyped ads talk about 250 MB; this is a boast about compression; your mileage may vary. Better to pre-compress the data with known better methods such as LHARC or PKZIP) and today the media can be had for about $16 quantity one if you shop around. Storing lotsa PDP-8 files in compressed form means that archiving our information can be done fairly cheaply, etc. These tapes lend themselves to snail-mailings if needed, etc. In any case, there is no reason to lose PDP-8 information if we all get our act together towards preserving what we have, etc. cjl ps: my own personal stack overflow is partially attributed to two major events in my life. One is self-induced, the other is circumstantial: The latter first: I have just come back from a family medical emergency where my mother was gravely ill and recently operated on, etc. Hopefully she will recover, but it's still too early to get any dependable data, etc. The former is that I have also spent the best part of the past year in major renovations of my building. One of the objectives is the better use of the facilities for different aspects of computing. Several rooms devoted exclusively to computers have been created, and are nearly completed a/o this writing. As a result, the long-term outlook is that other rooms already devoted to this purpose will no longer be (as) overloaded, etc. From cornelius@eisner.decus.org Tue Sep 7 11:46:00 EDT 1993 Article: 418 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!uunet!noc.near.net!eisner.decus.org!cornelius From: cornelius@eisner.decus.org Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Message-ID: <1993Sep7.073838.509@eisner.decus.org> Date: 7 Sep 93 07:38:38 -0400 References: <26932j$fg@apakabar.cc.columbia.edu> Followup-To: alt.sys.pdp8,alt.folklore.computers Organization: DECUServe Lines: 30 Xref: news.columbia.edu alt.sys.pdp8:418 alt.folklore.computers:51146 In article , erd@kumiss.cmhnet.org (Ethan Dicks) writes: > Charles Lasner (lasner@watsun.cc.columbia.edu) wrote: > > : Correct, Pong from Atari is a hard-wired TTL controller that plays a true > : video game using digital techniques to accomplish all the features. Contrast > : that with the earlier Magnavox Odyssey which wasn't even a digital device. > > I just unpacked my old Magnavox, complete with the plastic colored screen > overlays (in two sizes) for adding boundaries and other features to the games. > > I have dissected in more than once (and it still works :-), and can confirm > personally that it is a strictly analog device. The motherboard is populated > with edge-card connectors which are filled with 2"x2" circuit boards to perform > things like horizontal timing, vertical timing, dot generation, drift, etc. If it's putting dots on the screen (and if it contains TTL!), it's probably not an analog device. I suspect you mean that it does not contain a microprocessor or a semblance thereto. > The specifics of the game (control of the ball, display of paddles, response > on collision detection, etc.) are selected by plugging in a "cartridge". This > cartridge contains no active components, but rather jumpers various pins of > the 44 pin connector, turning on or turning off various features. To play > a game, you tape the correct colored overlay to the screen and plug in the > correct cartridge. > > Stone knives and bearskins. > > -ethan > From jones@pyrite Tue Sep 7 11:47:43 EDT 1993 Article: 419 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: Sender: news@news.uiowa.edu (News) Message-ID: <1993Sep7.143307.27896@news.uiowa.edu> Date: Tue, 7 Sep 1993 14:33:07 GMT References: <1993Sep7.073838.509@eisner.decus.org> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 24 Xref: news.columbia.edu alt.sys.pdp8:419 alt.folklore.computers:51147 >From article <1993Sep7.073838.509@eisner.decus.org>, by cornelius@eisner.decus.org: > > If it's putting dots on the screen (and if it contains TTL!), > it's probably not an analog device. I suspect you mean that > it does not contain a microprocessor or a semblance thereto. No, the point is that the Magnavox Odyssey used analog techniques to drive the logic of the game. No doubt there were some digital signals inside, in the sense of saturating transistors and on-off logic, but the basic mechanisms that moved the ball on the screen were analog. For an example of the kinds of things that go into an analog video game, consider the use of current sources and integrators instead of clocked counters to determine the X and Y positions of the "ball" on the screen. The decision to illuminate the dot on the screen then rests on an analog comparitor that compares the outputs of these integrators with the outputs of another pair of integrators that effectively track the current coordinates of the video scan on the display screen. Sure, there may be one and gate used to determine that both X and Y coordinates match, but the heart of the computation is analog! Doug Jones jones@cs.uiowa.edu From lasner@watsun.cc.columbia.edu Tue Sep 7 13:04:00 EDT 1993 Article: 420 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Date: 7 Sep 1993 16:46:49 GMT Organization: Columbia University Lines: 90 Message-ID: <26idtp$cud@apakabar.cc.columbia.edu> References: <1993Sep7.073838.509@eisner.decus.org> <1993Sep7.143307.27896@news.uiowa.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:420 alt.folklore.computers:51152 In article <1993Sep7.143307.27896@news.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: >From article <1993Sep7.073838.509@eisner.decus.org>, >by cornelius@eisner.decus.org: >> >> If it's putting dots on the screen (and if it contains TTL!), >> it's probably not an analog device. I suspect you mean that >> it does not contain a microprocessor or a semblance thereto. No, Nein, Nyet! There is nothing in the remotest sense digital about this device!!!!! There are no gates whatsoever. All is done with analog comparators including the gating on of the moving dot which unblanks the video directly at the tracked location which is determined as Doug says, which itself is an analog comparison. > >No, the point is that the Magnavox Odyssey used analog techniques >to drive the logic of the game. No doubt there were some digital >signals inside, in the sense of saturating transistors and on-off >logic, but the basic mechanisms that moved the ball on the screen >were analog. For an example of the kinds of things that go into >an analog video game, consider the use of current sources and >integrators instead of clocked counters to determine the X and Y >positions of the "ball" on the screen. The decision to illuminate >the dot on the screen then rests on an analog comparitor that >compares the outputs of these integrators with the outputs of >another pair of integrators that effectively track the current >coordinates of the video scan on the display screen. Sure, there >may be one and gate used to determine that both X and Y coordinates >match, but the heart of the computation is analog! Even that is done by two analog comparators. These people went out of their way to avoid digital. (I was part of the expert witness consultancy on a case directly concerned with this aspect. The Odyssey was covered by an overly broad patent that doesn't distinguish between a digital and an analog implementation. The case wasn't broken on this ground however, instead we got 'em on prior art using the PDP-8!) > > Doug Jones > jones@cs.uiowa.edu DEC uses an analog comparator to do the select logic on the TU55/TU56 DECtape connected to controllers such as the TC01/TC08. Every DECtape drive has a connection to a line called SELECT ECHO. It is driven with a DEC standard relay driver card which has predictable analog characteristics. When not selected, the driver contributes only a negligible leakage current, but when selected, the driver transistor is driven only into the active region. (Normally, this card, with a large output transistor, is meant to drive some large contactor relay coil or other multi-amp load, but in this application, it is "loafing" and driving a 1/4W resistor.) In the TU55, the relay driver module is of course driven by negative logic signals. In the TU56, the relay driver module is a newer card that is driven by TTL signals, but is otherwise the same design. (DEC had a habit of updating certain stock module designs for specific purposes. The TTL version of the relay module is essentially the original card with a level converter on the card.) Thus, it is perfectly OK to mix systems where some drives are TU55 and some are TU56, etc. So, there are up to 8 possible drives with individual relay drivers connected to SELECT ECHO. Within each tape controller there is an analog comparator connected to that line, along with the modest load resistor. When one drive selects, the resultant voltage is predictably within a narrow tolerance range. It will be too high if no drives select, and too low if 2-8 drives select. Thus, the analog comparator's output is used to create the internal signal called SELECT ERROR. The same "logic" is used to drive the WRITE ECHO signal. IFF there is not a SELECT ERROR condition, then another comparator checks the voltage on WRITE ECHO. Of course that signal could only be in two states, i.e., not driven or driven by the selected drive (or overdriven by too many drives, but then SELECT ERROR is set invalidating the WRITE ECHO signal). Thus, there is a purely analog interface between the drives and the controller on not only the head data, but also the select and write-protect logic. The command logic does use logic levels to control motion of the motors. For the TU55, either the old "relay" levels or negative logic levels are used, and the construction of the TU55 is all R-series logic, with an optional card to level convert from relay -> negative if needed in an older system (such as a 555 DECtape system. The TU55 was originally called the "Solid-State DECtape Drive".). The TU56 accommodates all of that, and additionally uses an additional level converter because it can also be driven by TTL levels. The TTL levels are used in the TD8E and the TC-11. The negative levels are used in the TC01, TC08, TC12, TC02, TC15, etc. (The last two are the PDP-9 and PDP-15 controllers respectively.) cjl From kcrosby@crayola.win.net Tue Sep 7 14:57:30 EDT 1993 Article: 421 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!psinntp!witch!crayola!kcrosby Newsgroups: alt.sys.pdp8,alt.folklore.computers Message-ID: <294@crayola.win.net> References: <1993Sep3.140927.5251@news.uiowa.edu> Reply-To: kcrosby@crayola.win.net (Kip Crosby) From: kcrosby@crayola.win.net (Kip Crosby) Date: Tue, 07 Sep 1993 00:43:49 GMT Subject: Re: ENIAC and stored program (Was: The Analytical Engine) Lines: 19 Xref: news.columbia.edu alt.sys.pdp8:421 alt.folklore.computers:51167 In article <1993Sep3.140927.5251@news.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 (jones@pyrite) writes: > [....arcana deleted....] >The border between computers, calculators and controllers can get fuzzy, >for example, ENIAC was clearly a programmable calculator, but was it a >computer? You could reprogram it with a patch panel change, and it was >powerful enough that someone could have programmed a patch panel to make >it interpret a stored program, but to my knowledge, nobody did it. > I don't have my copy of Goldstine's _The Computer from Pascal to von Neumann_ right to hand (chorus of "Why NOT?!",) but I think von Neumann, Adele Goldstine and Arthur Burks actually _did_ do that. If I can dig up ch. and verse I'll be back with it. __________________________________________ Kip Crosby kcrosby@crayola.win.net Computer History Association of California "History is what you make it...." From kcrosby@crayola.win.net Tue Sep 7 14:57:56 EDT 1993 Article: 422 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!psinntp!witch!crayola!kcrosby Newsgroups: alt.sys.pdp8,alt.folklore.computers Followup-To: poster Message-ID: <295@crayola.win.net> References: <1993Sep3.140927.5251@news.uiowa.edu> Reply-To: kcrosby@crayola.win.net (Kip Crosby) From: kcrosby@crayola.win.net (Kip Crosby) Date: Tue, 07 Sep 1993 01:00:52 GMT Subject: Re: Old architectures ( was Re: The Analytical Engine) Lines: 38 Xref: news.columbia.edu alt.sys.pdp8:422 alt.folklore.computers:51168 In article , David Hembrow (davidh@harlequin.co.uk) writes: >Is this in fact true ? If you know enough about the way in which ENIAC >was put together, could you provide some details of what it was in fact >capable of ? I'd be interested in knowing something about the workings >of some of these early computers ( especially the programmable ones ). > >ie. > >o Amount of memory >o Instruction set >o I/O capabilities > ENIAC had 20 ten-decimal-digit words in valves, 100 ditto in mag core, 304 ditto in a func. table, 96 in the patch panel, and 8 in mag relays as a single-card cache. There were 97 instructions of 2 decimal digits each, with 5 or 6 instructions per word (there were some 12-digit words,) and fixed-decimal arithmetic. I/O was by IBM 80-col card at 125 cards/min I and 100 cards/min O. All of this and much more is in: _Historical Dictionary of Data Processing_ James W. Cortada Greenwood Press, Westport, CT, USA which is three hardcover volumes, Technology, Biographies, and Organizations. Invaluable for the historian, fascinating reading, best for stuff before 1980, and (this is the hard part) about US$150 the set -- but you can buy the individual volumes. Cheers, __________________________________________ Kip Crosby kcrosby@crayola.win.net Computer History Association of California "History is what you make it...." From kcrosby@crayola.win.net Tue Sep 7 15:09:41 EDT 1993 Article: 423 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!psinntp!witch!crayola!kcrosby Newsgroups: alt.sys.pdp8,alt.folklore.computers Followup-To: poster Message-ID: <297@crayola.win.net> References: <1993Aug31.215837.4918@news.uiowa.edu><26932j$fg@apakabar.cc.columbia.edu> Reply-To: kcrosby@crayola.win.net (Kip Crosby) From: kcrosby@crayola.win.net (Kip Crosby) Date: Tue, 07 Sep 1993 13:25:08 GMT Subject: Re: The Analytical Engine (CHAC newsletter!) Lines: 124 Xref: news.columbia.edu alt.sys.pdp8:423 alt.folklore.computers:51169 In article <26932j$fg@apakabar.cc.columbia.edu>, Charles Lasner (lasner@watsun.cc.columbia.edu) writes: >I truly believe in the intended cause the CHAC people are attempting, and >I really hope they succeed, but unfortunately, they seem to be victims of >their own predictions. In order for such an organization to succeed, it >must *flawlessly* pursue its subject matter. > >Towards that end, I would suggest that groups such as alt.sys.pdp8 act >as super-proof-readers of such material, i.e., post draft copies here first >and allow us pedantic pdp-8'ers and other interested hanger-outers to tear >apart their articles for technical accuracy, all in the interest of upping >the quality of the product, etc. We're delighted to have super-proofers -- that's a lot of why we're on USENET to begin with. Tear away! (Not that people haven't.) On the other hand, I will concede (being one) that editors are human, and no less fallible in that capacity than in any other; flawless pursuit of subject matter is perennially desired and less often attained. If we publish articles that need no correction, great. If our articles go out to readers and somebody finds a bug, then, to publish the article _and_ the correction still does a service to the community and enriches the public record. When the October ENGINE appears you'll see that we do publish corrections, even at a length that will surely satisfy the most pedantic. >As it stands now, it's a little too revisional for me, although admittedly >only a little. Forgive me for saying it, but from my vantage point, someone >who happened upon a 1401 in 1965 ain't a pioneer! This is only marginally >before my time, and I already knew enough to know the mistakes pointed out >elsewhere, and I consider myself "second generation", not a true pioneer in >the industry, etc. > I don't quite get the intent of the word 'revisional', but in any case, certainly "someone who happened upon a 1401 in 1965 ain't a pioneer." IBM announced the 1401 in October 1959 and, in fact, projected in an internal report that the end of the useful life of the series would occur in 1965. But while pioneering work is important to CHAC, and preserving the record of it is an important part of our mandate, it ain't the whole story, either. If somebody can make an interesting, illuminating point about computer use in California, at the appropriate length, then it doesn't matter whether they were the first to gain experience with a system or (as might be equally intriguing) the last. >>1) The IBM 1401 was not a vacuum tube machine! It was transistorized. > >Amen! > >And it always had all of the core memory present. There was a jumper to >make half of the stack go away if the customer didn't pay for field service >for it! (And sometimes a friendly tech could put it back in!) > >> >>2) Pong was not a computer game! It was a video game implemented with >> TTL logic, with no computer. > >Correct, Pong from Atari is a hard-wired TTL controller that plays a true >video game using digital techniques to accomplish all the features. Contrast >that with the earlier Magnavox Odyssey which wasn't even a digital device. >Further, there is no provision to reprogram the device that Pong is, although >you can get into a grey area if something akin to a patch panel or even a >control ROM is used to transiently change the controller's exact function. >In any case, it still ain't a computer, since it lacks a program that can >be stored, nor has the storage itself to do such a thing either. This is >also far afield from a true computer with a ROM-based program that as provided >cannot be changed without changing the ROM, because the ROM *could* be changed >if need be, and the changes could bring about either of two effects: 1) the >program could run the same way with totally different contents because it's >usually possible to program any reasonable task using entirely different >algorithms thus different, yet equivalent program sequences, or 2) The program >will run materially different if small changes to the code are made. The >complications arise when a feature of the program is to sense external options >such as DIP switches or perhaps even semi-random input devices to determine >just what to do. (Meaning that it's possible to use a computer to simulate >a hard-wired controller whose wiring gets patched, etc.) > >> >>3) Spacewar wasn't a video game! Video encoding of data was not used to >> paint the image on the face of the CRT. Instead, the software drove >> a pair of ADC's to handle deflection in the X and Y directions, and >> the software painted each dot on the screen. The resolution was far >> better than standard video, but the number of dots that could be >> painted without causing flicker was limited. > >This point is particularly galling as it's getting increasingly difficult >to explain to people that just because a screen lights up, it ain't gonna >necessarily be video! > >The great thing about oscilloscope graphics is the random access aspect >of it. Without having to rigorously display in raster order, you totally >avoid the jaggies, and most of these tubes use 12-bit D-A convertors to >make matters even better. But when you don't use raster order, and instead >draw points where you want/need them, the jaggies just don't happen. This >is why DEC has made various displays that were adequate with as little as >8-bits D-A convertors, and not the slightest aliasing visible on the >typical 'scopes used with them. (Such as the LINC-8 or the AX08 with >various Tektronix scopes attached, etc.) > >> >>(By the way, I have played spacewar myself on a DDP 224 computer at the >>University of Michigan -- that machine was a nice 24 bit minicomputer, >>and their version of spacewar used two joysticks on the graphics display.) > >The description of the PDP-1 spacewar, clearly the first version, entirely >matches the 4K w/EAE PDP-8 version attributable to Richard Lary, Herb Jacobs, >and Rod Dorman, etc., which is usually distributed with P?S/8, which is able >to load it on a 4K PDP-8 it can run from, etc. > >>In any case, the folks at CHAC clearly have their hearts in the right >>place, and the kinds of errors they made in their newsletter only serve >>to prove the point of their opening editorial! History is indeed being >>lost and forgotten at an impressive rate! > >Yes, if those who are committed to wanting to preserve history can't quite >get it together, we can't possibly succeed! We must help these folks get >their act together completely. All of us have a part to play to get it >correct, before the entire history of computing is personally attributed >to Bill Gates, now sometimes erroneously attributed to as the author of the >original BASIC among other things! I wouldn't worry about billg getting _all_ the credit. He was born in the year that the first IBM 704 was delivered, so vacuum-tube computing is probably safe from the attribution :-) From wolfson@sps.mot.com Tue Sep 7 15:09:54 EDT 1993 Article: 424 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!spsgate!mogate!newsgate!regatta!wolfson From: wolfson@sps.mot.com (Stephen Wolfson) Subject: Re: The Analytical Engine (CHAC newsletter!) Message-ID: <1993Sep7.182705.28757@newsgate.sps.mot.com> Sender: news@newsgate.sps.mot.com Nntp-Posting-Host: regatta.sps.mot.com Reply-To: wolfson@sps.mot.com Organization: Motorola, Inc. References: Date: Tue, 7 Sep 1993 18:27:05 GMT Lines: 6 Xref: news.columbia.edu alt.sys.pdp8:424 alt.folklore.computers:51173 Well as I recall there was an article in IEEE on constructing a pong game. So look up back issues circa '75-76. Now then where did I put my old TV Typewriter terminal :-) From aty@ucssun1.sdsu.edu Tue Sep 7 15:49:06 EDT 1993 Article: 425 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!ucsnews!ucssun1.sdsu.edu.sdsu.edu!aty From: aty@ucssun1.sdsu.edu (young a t) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Old architectures Date: 7 Sep 1993 19:05:15 GMT Organization: SDSU Computing Services Lines: 103 Message-ID: <26im1b$s47@gondor.sdsu.edu> References: <1993Sep3.185632.12450@news.uiowa.edu> NNTP-Posting-Host: 130.191.1.100 Xref: news.columbia.edu alt.sys.pdp8:425 alt.folklore.computers:51175 In article <1993Sep3.185632.12450@news.uiowa.edu> jones@cs.uiowa.edu (Douglas W. Jones) writes: |>for a number of other old machines. The next one I'd like to hammer |>down is the IBM 701, a 1953 gem for which I happen to have the |>principles of operation book. If you like such things, here's a Hey -- maybe you're the person to answer my perpetual query about the Q bit! ... |>Registers: Accumulator -- 37 bits. |> two extra bits are provided for magnitude overflow. ^^^^^^^^^^^^^^ That sounds like the 704's AC: 35 bits + S,P,Q |> MQ (multiplier-quotient) -- 38 bits. ??? Really? Not 36? The 704 MQ had 36. |>Number system: Signed magnitude |> Arithmetic assumes 35 bits right of the point. I believe floating-point came in with the 704. People wrote "fixed-point" arithmetic routines for these machines, assuming the binary point was at some conventional place (left end, right end, or middle) of the word. Even wrote square-root routines and trig functions for fixed-point arithmetic. ... |>Notes on instructions: ... |> Note the lack of logical operations. The importance of shifting |> was understood, but if you wanted to mask something, you had to |> shift one way and then the other, letting bits fall off the ends |> of the accumulator to clear them, and keeping in mind the extra |> two magnitude bits on the accumulator. Yeah. Same problem with shifting the 704 AC. The Q bit would get you every time. ... |>Unit record formats: |> |> 80 column punched cards were handled as 12 rows of 72 columns, with |> each column stored in two consecutive memory locations, reading |> from the bottom of the card to the top. A patch panel determined |> which columns the printer and punch would handle. Which is why FORTRAN statements only used the first 72 columns. |> The printer had 120 columns, with a character set of 48 characters. |> Output was in card image format, so no more than 72 characters |> could be printed per line. A patch panel determined which 72. Yes; but if that was the same printer the 704 used, you could then print the rest of the 120 columns on a second print cycle. Took a special wiring panel to read the sense magnets back to the CPU, though. |> The magnetic tape drives stored data in 6 channels, with a 7th |> channel added for parity, all on half-inch wide tape with 1400 |> feet of tape per reel. This was the first computer to use this |> format, a format that lasted through the 1960's. You left out the density: 200 bpi. There used to be "tape developer fluid" you could buy that had little black magnetic particles suspended in something. Dip the tape in, and the bits turned black. After the solvent evaporated, you could lift them off with Scotch tape and read the bits from a damaged piece of mag tape. |> The magnetic drum system stored 2048 words per drum, addressed |> by even integers as in main memory. Words on drum are randomly |> accessable (within the limits of latency), with a set-drum-address |> command used to specify the starting drum address of each transfer, |> followed by a sequence of copy instructions to move the data. |> |> I/O instructions, particularly the copy instruction, were blocking, |> and would hang the CPU until the transfer was complete. Sounds just like the 704 in that respect. The Load-button sequence was: select card reader copy 9-left word to absolute address 0 copy 9-right word to absolute address 1 transfer control to location 0 Those first 2 words from the loader card had to read in the rest of the card, which had to read in the rest of the program. We had very thin bootstraps in those days.... It used to be a game to see if you could write an input-conversion routine fast enough to convert & store a card's worth of data before the card reader needed another "select" instruction. If so, you could keep the card reader running at its full speed of 90 cards/minute. If not, you lost a whole cycle, and the reader went CHUNK. CHUNK. CHUNK. instead of slurp slurp slurp.... The catch was that cards were punched column-wise, but read row-wise; so you had to read the *whole* card and rearrange all the bits just to read the 72 characters. Converting characters to binary representation took more time on top of that. A big speedup came with the 7090, which used Data Channels for I/O instead of having to synchronize the program with the rotation of the hardware. -- A.T.Young aty@mintaka.sdsu.edu Astronomy Department San Diego State University San Diego CA 92182-0540 From kcrosby@crayola.win.net Fri Sep 10 19:25:58 EDT 1993 Article: 426 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!wupost!cs.utexas.edu!uunet!psinntp!witch!crayola!kcrosby Newsgroups: alt.sys.pdp8,alt.folklore.computers Message-ID: <300@crayola.win.net> References: <1993Aug31.215837.4918@news.uiowa.edu> <269eib$478@apakabar.cc.columbia.edu> Reply-To: kcrosby@crayola.win.net (Kip Crosby) From: kcrosby@crayola.win.net (Kip Crosby) Date: Tue, 07 Sep 1993 21:17:09 GMT Subject: Re: The Analytical Engine (CHAC newsletter!) Lines: 22 Xref: news.columbia.edu alt.sys.pdp8:426 alt.folklore.computers:51202 In article <269eib$478@apakabar.cc.columbia.edu>, Charles Lasner (lasner@watsun.cc.columbia.edu) writes: >In article , >Travis Corcoran wrote: > >>My aptmate is the proud owner of a *WORKING* Pong >>game. >Hmm... > >Stories like this seem to cut down on some of the CHAC story about there >being only a few of them left? > We weren't talking about the one that was sold commercially to attach to your TV, but about the original arcade version in the big plywood box. The figure of nine is from a source at the American Museum of the Moving Image, which owns one. __________________________________________ Kip Crosby kcrosby@crayola.win.net Computer History Association of California "History is what you make it...." From kcrosby@crayola.win.net Fri Sep 10 19:26:16 EDT 1993 Article: 427 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!psinntp!witch!crayola!kcrosby Newsgroups: alt.sys.pdp8,alt.folklore.computers Message-ID: <314@crayola.win.net> References: <269eib$478@apakabar.cc.columbia.edu><93635081313.dave.15112@gilly.UUCP> Reply-To: kcrosby@crayola.win.net (Kip Crosby) From: kcrosby@crayola.win.net (Kip Crosby) Date: Wed, 08 Sep 1993 12:27:57 GMT Subject: Re: The Analytical Engine (CHAC newsletter!) Lines: 16 Xref: news.columbia.edu alt.sys.pdp8:427 alt.folklore.computers:51245 In article <93635081313.dave.15112@gilly.UUCP>, dave@gilly.UUCP (dave@gilly.UUCP) writes: >lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > >>Stories like this seem to cut down on some of the CHAC story about there >>being only a few of them left? >> >>cj "owner of less than 4,000,000 PDP-8's" > >Chill out dude, there's a difference between the coin-operated arcade >games that article was about, and the home version that you can get >anywhere these days for $15. Arcade games are "upgraded" to new games >by swapping the guts and putting new stickers on the outside, so most >of the early one are extremely rare now. My point exactly. -- kc From kcrosby@crayola.win.net Fri Sep 10 19:26:34 EDT 1993 Article: 428 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uunet!psinntp!witch!crayola!kcrosby Newsgroups: alt.folklore.computers,alt.sys.pdp8 Followup-To: poster Message-ID: <317@crayola.win.net> Reply-To: kcrosby@crayola.win.net (Kip Crosby) From: kcrosby@crayola.win.net (Kip Crosby) Date: Wed, 08 Sep 1993 15:26:32 GMT Subject: ANALYTICAL ENGINE, book review wanted Lines: 16 Xref: news.columbia.edu alt.folklore.computers:51247 alt.sys.pdp8:428 We mean to put a book review in every issue of the ENGINE from now on, but that doesn't mean we want to write them all. We want thousand-word reviews with general/technical interest of books specifically about computer history. Suggestion: Does anybody feel up to reviewing TNHD? Other ideas welcome. October's review is Palfreman and Swade's THE DREAM MACHINE, so that's taken. Thanks. __________________________________________ Kip Crosby kcrosby@crayola.win.net Computer History Association of California "History is what you make it...." From bsmart@bsmart.TTI.COM Fri Sep 10 19:27:12 EDT 1993 Article: 429 of alt.sys.pdp8 Newsgroups: alt.technology.obsolete,alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!usc!news.service.uci.edu!ttinews!bsmart!bsmart From: bsmart@bsmart.TTI.COM (Bob Smart) Subject: Re: WOODEN MEN AND IRON D Message-ID: <1993Sep9.081429.16102@ttinews.tti.com> Sender: usenet@ttinews.tti.com (Usenet Admin) Nntp-Posting-Host: bsmart.tti.com Reply-To: bsmart@bsmart.TTI.COM (Bob Smart) Organization: Citicorp+TTI References: <1993Sep3.064117.6177@vpnet.chi.il.us> <60.599.5476.0N1821B3@canrem.com> <9308290316.AA56470@fizbin.intercon.com> <1993Aug30.164557.24138@srzts100.alcatel.ch> Date: Thu, 9 Sep 1993 08:14:29 GMT Lines: 22 Xref: news.columbia.edu alt.technology.obsolete:156 alt.sys.pdp8:429 In article <1993Sep3.064117.6177@vpnet.chi.il.us>, cgordon@vpnet.chi.il.us (gordon hlavenka) writes: > > I guess this means that core memory is also rad-hard. More so than many other RAM technologies more commonly employed in machinery that won't be exposed to much radiation. This is why they still use core in some spacecraft, for instance. If you shine enough radiation on a core bank, it will eventually become corrupted, of course...but it's nowhere near as sensitive to the odd cosmic ray hit as, say, ordinary semiconductor chips. Use of core means you don't get as much memory per unit volume...but you also don't have to carry as much shielding. --------- A fanatic is someone who does what he knows that God would do if God knew the facts of the case. Some mailers apparently munge my address; you might have to use bsmart@bsmart.tti.com -- or if that fails, fall back to 72027.3210@compuserve.com. Ain't UNIX grand? From dave%gilly@speedway.net Fri Sep 10 19:27:20 EDT 1993 Article: 430 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!uunet!news!news.world.net!speedway.net!gilly!dave Message-ID: <93336195420.dave.15036@gilly.UUCP> Date: Wed, 08 Sep 93 19:54:21 EDT Reply-To: dave%gilly@speedway.net Organization: Flat Earth Liberation Front Against Television From: dave@gilly.UUCP Newsgroups: alt.folklore.computers,alt.sys.pdp8 Subject: Re: ANALYTICAL ENGINE, book review wanted References: <317@crayola.win.net> Lines: 15 Xref: news.columbia.edu alt.folklore.computers:51302 alt.sys.pdp8:430 kcrosby@crayola.win.net (Kip Crosby) writes: >We mean to put a book review in every issue of the ENGINE from now >on, but that doesn't mean we want to write them all. We want >thousand-word reviews with general/technical interest of books >specifically about computer history. Suggestion: Does anybody >feel up to reviewing TNHD? Related question: anyone remember _A_Fortran_Coloring_Book_? Did you learn Fortran from it? ------------------------ uunet!quack!gilly!dave ------------------------ ================= Dave Fischer - Nature's Perfect Food ================= ----------------------- dave%gilly@speedway.net ------------------------ From clef@aber.ac.uk Fri Sep 10 19:27:36 EDT 1993 Article: 431 of alt.sys.pdp8 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!spool.mu.edu!agate!doc.ic.ac.uk!uknet!gdt!aber!clef From: clef@aber.ac.uk (Jim Finnis) Subject: Re: ANALYTICAL ENGINE, book review wanted Message-ID: <1993Sep9.104959.27228@aber.ac.uk> Organization: University of Wales - Aberystwyth - Prifysgol Cymru References: <317@crayola.win.net> <93336195420.dave.15036@gilly.uucp> Date: Thu, 9 Sep 1993 10:49:59 GMT Lines: 30 Xref: news.columbia.edu alt.folklore.computers:51311 alt.sys.pdp8:431 In article <93336195420.dave.15036@gilly.uucp> dave%gilly@speedway.net burbled: >kcrosby@crayola.win.net (Kip Crosby) writes: > >Related question: anyone remember _A_Fortran_Coloring_Book_? > >Did you learn Fortran from it? 'fraid so - recently even! My SO recently found it in an old cardboard box. It used to belong to her father, who learnt Fortran from it when all the stuff about cards was relevant. She, being only 5 at the time used it as a colouring book! After digging it out after nearly twenty years of isolation, I did actually learn Fortran from it. I thought it was about time... I'm particularily fond of what Kaufman says about cute variable names... > >------------------------ uunet!quack!gilly!dave ------------------------ >================= Dave Fischer - Nature's Perfect Food ================= >----------------------- dave%gilly@speedway.net ------------------------ -- ----------------------------------------------------------------------------- Jim Finnis, | Unit 6A, Science Park, Aberystwyth, Dyfed, SY23 3AH Clef Digital Systems | clef@aber.ac.uk | Tel.: 0970 626601 Overseas: +44 970 626601 From jones@pyrite Fri Sep 10 19:27:52 EDT 1993 Article: 432 of alt.sys.pdp8 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Off the shelf computer sales. Sender: news@news.uiowa.edu (News) Message-ID: <1993Sep9.220703.17562@news.uiowa.edu> Date: Thu, 9 Sep 1993 22:07:03 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 12 Xref: news.columbia.edu alt.folklore.computers:51358 alt.sys.pdp8:432 I was going through old issues of CACM, and I found an interesting tidbit in the Oct 1967 issue, page 679. It said that, DEC had taken the unusual step of offering the PDP-8/S for off the shelf delivery. So, was this the first computer offered for sale "off the shelf", which is to say, the first computer where the manufacturer deliberately built up an inventory so that they could ship machines as soon as orders came in? Doug Jones jones@cs.uiowa.edu From kcrosby@crayola.win.net Fri Sep 10 19:28:11 EDT 1993 Article: 433 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!math.ohio-state.edu!uwm.edu!lll-winken.llnl.gov!iggy.GW.Vitalink.COM!wetware!spunky.RedBrick.COM!psinntp!psinntp!witch!crayola!kcrosby Newsgroups: alt.sys.pdp8 Message-ID: <344@crayola.win.net> Reply-To: kcrosby@crayola.win.net (Kip Crosby) From: kcrosby@crayola.win.net (Kip Crosby) Date: Thu, 09 Sep 1993 22:57:06 GMT Subject: DEC manuals for sale (forwarded) Lines: 76 FORWARDED MAIL ------- from CRAYOLA! From: rocker@csa.bu.edu (The Long Haired One) Date: 06 Sep 93 Originally Posted On: misc.forsale.computers Buyer pays shipping on the following items. Digital Industrial Networks Guidebook(1990) ($2) LA34 (decwriter IV) users guide ($5) LA75 Companion Printer - installing and using ($3) LA75 Companion Printer - programmer ref manual ($8) LJ250/LJ252 Companion Color Printer programmer ref guide ($8) LN03 programmer reference manual ($8) LN03R scriptprinter operator guide ($5) LS120 DECwriterIII operator guide & user guide ($5 2bookset) Microcomputers and memories (1981) ($3) Microcomputers and memories (1982) ($3) Security for Vax systems (1989) ($2) Ultrix Handbook (1990) ($2) VT103 LSI-11 video terminal - user's guide ($5) VT125 graphics terminal - users guide ($8) VT330/VT340 installing and using video terminal ($5) VT330/VT340 programmer pocket guide ($5) VT330/VT340 programmer reference manual vol1: text programming ($10) VT330/VT340 programmer reference manual vol2: graphics programming ($10) Vax 11/780 software handbook vol3 (1977-78) ($5) Vax Architecture (1981) ($5) Vax Architecture (1986) ($5) Vax Hardware Handbook (1982-83) ($5) Vax Hardware Handbook Vol1&2 (1986) ($5) Vax Software Handbook (1982-83) ($2) Vax vector processor handbook (1990) ($5) digital's local area network solutions guidebook (1989) ($1) LA50 installing and using the LA50 printer ($3) logic handbook (1976-77) ($5) memories and peripherals (1978-79) ($5) microcomputers and memories (1982) ($5) pdp-11 11/34 processor handbook (1976) ($5) pdp-11 Microcomputer Interfaces Handbook (1983-84) ($5) pdp-11 peripherals handbook (1976) ($3) pdp-11 peripherals handbook (1978-79) ($3) pdp-11 processor handbook pdp-11/04/24/34a/44/70 (1981) ($5) pdp-11 processor handbook pdp-11/45 (1972) ($5) pdp-11 processor handbook pdp-11/45 (1974-75) ($5) pdp-11/04/24/34a/44/70 processor handbook (1981) ($5) pdp-11/04/34/45/55/60 processor handbook (1978-79) ($5) peripherals handbook (1981-82) ($5) supermicrosystems handbook (1986) ($2) terminals and communication handbook (1980) ($3) terminals and communications handbook (1979) ($3) vt220 installation guide ($3) vt220 owner's manual ($5) ($50) RSTS/E V8.0 Volumes 1,2,2a,3,4,5,6,8,8a ($40) DigiData 9 track reel-to-reel model# 1749-86-4-110-UL originally controlled by an Emulex TC01, with densities of 800/1600. Used on a PDP-11/23 system. Last known condition was working, I have no way to verify it at present, so its being sold as UNKNOWN condition, no manuals. (weight 70 packed for shipping) ($300) VMS 5.0 Manual set (1988) system managment vols: 1a,1b,2,3,4,5a,5b programming vols: 1,2a,2b,3,4a,4b,5a,5b,5c,6a,6b,7a,7b,8,9 general user vols: 1,2a,2b,3,4,5a,5b email to rocker@cs.bu.edu From ivie@cc.usu.edu Fri Sep 10 19:28:30 EDT 1993 Article: 434 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu Newsgroups: alt.folklore.computers,alt.sys.pdp8 Subject: Re: Off the shelf computer sales. Message-ID: <1993Sep10.094651.403@cc.usu.edu> Date: 10 Sep 93 09:46:51 MDT References: <1993Sep9.220703.17562@news.uiowa.edu> Organization: Utah State University Lines: 18 Xref: news.columbia.edu alt.folklore.computers:51430 alt.sys.pdp8:434 In article <1993Sep9.220703.17562@news.uiowa.edu>, jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: > I was going through old issues of CACM, and I found an interesting tidbit > in the Oct 1967 issue, page 679. > > It said that, DEC had taken the unusual step of offering the PDP-8/S for > off the shelf delivery. > > So, was this the first computer offered for sale "off the shelf", which > is to say, the first computer where the manufacturer deliberately built > up an inventory so that they could ship machines as soon as orders came > in? Are you sure that buildup of inventory on the PDP-8/Slow was deliberate? :-) :-) :-) Roger "Never used one, so I have no first-hand knowledge" Ivie ivie@cc.usu.edu From root@foobar.hanse.de Fri Sep 10 19:29:11 EDT 1993 Article: 435 of alt.sys.pdp8 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!math.fu-berlin.de!news.rrz.uni-hamburg.de!lutzifer!wolfhh!foobar!root From: root@foobar.hanse.de (Jens Stark) Subject: Re: ANALYTICAL ENGINE, book review wanted References: <317@crayola.win.net> <93336195420.dave.15036@gilly.UUCP> Organization: Just another Linux site! Date: Fri, 10 Sep 1993 11:15:26 GMT Message-ID: <1993Sep10.111526.577@foobar.hanse.de> Lines: 25 Xref: news.columbia.edu alt.folklore.computers:51444 alt.sys.pdp8:435 dave@gilly.UUCP writes: >kcrosby@crayola.win.net (Kip Crosby) writes: >>We mean to put a book review in every issue of the ENGINE from now >>on, but that doesn't mean we want to write them all. We want >>thousand-word reviews with general/technical interest of books >>specifically about computer history. Suggestion: Does anybody >>feel up to reviewing TNHD? >Related question: anyone remember _A_Fortran_Coloring_Book_? Ah, yes ! Dr. Roger Kaufman's work. Great stuff. Slashes, in tyres : see Hell's Angels >Did you learn Fortran from it? No. I had written a FORTRAN teaching program before ever hearing of it. Greetings, Jens From erd@kumiss.cmhnet.org Fri Sep 10 22:59:55 EDT 1993 Article: 436 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!cis.ohio-state.edu!mstar!n8emr!jcnpc!kumiss!erd From: erd@kumiss.cmhnet.org (Ethan Dicks) Subject: Re: Newsgroups: alt.sys.pdp8,alt.folklore.computers References: <1993Sep7.073838.509@eisner.decus.org> X-Newsreader: TIN [version 1.1 PL9] Message-ID: Date: 10 Sep 93 08:59:40 EDT Organization: Not an Organization Lines: 17 Xref: news.columbia.edu alt.sys.pdp8:436 alt.folklore.computers:51462 cornelius@eisner.decus.org wrote: : In article , erd@kumiss.cmhnet.org (Ethan Dicks) writes: [ Discussion of Odessey deleted ] : If it's putting dots on the screen (and if it contains TTL!), it's probably not : an analog device. I suspect you mean that it does not contain a microprocessor : or a semblance thereto. I mean what I said! I never said that it contained TTL parts of any kind. I said that the Odessey is an analog device. TTL is not required to put dots on the screen. neither is a microprocessor. If there are any ICs on the main board, they are Linear, not TTL. -ethan From david.turner@asacomp.com Sat Sep 11 22:04:53 EDT 1993 Article: 437 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Subject: PDP-8's? From: david.turner@asacomp.com (David Turner) Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!darwin.sura.net!sgiblab!barrnet.net!infoserv!asacomp!david.turner Distribution: world Message-ID: <35.89.2946.0NCD022B@asacomp.com> Date: Sat, 11 Sep 93 00:19:00 -0500 Organization: ASA CompuHelp, Inc. Lines: 15 Greetings! I just now found this conference and was wondering if anyone really has any PDP-8 stuff/information? Is there sort of like a PDP-8 fan club? :) I once had a PDP-8/e but had to get rid of it when I moved. :( I still have several of the books, tho. Lets see a show of hands out there... What is everyone up to? Regards, ** David Turner ** --- þ QMPro 1.0 00-0000 þ Misspelled? Impossible. My modem is error correcting. From rflukes@silver.cs.umanitoba.ca Sat Sep 11 22:05:20 EDT 1993 Article: 438 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!spool.mu.edu!bloom-beacon.mit.edu!mcrcim.mcgill.edu!sifon!newsflash.concordia.ca!mizar.cc.umanitoba.ca!silver.cs.umanitoba.ca!rflukes From: rflukes@silver.cs.umanitoba.ca (Richard F. Lukes) Subject: FORSALE: RK8E disk controllers Message-ID: Sender: news@ccu.umanitoba.ca Nntp-Posting-Host: silver.cs.umanitoba.ca Organization: Computer Science Dept., University of Manitoba, Winnipeg, Canada Date: Sun, 12 Sep 1993 01:44:23 GMT Lines: 11 I have a small number of RK8E Omnibus disk controllers for PDP8 systems. It consists of two circuit boards, interconnecting blocks, and a set of cables. Asking $150US or best offer. Thanks, --Rich -- Richard F. Lukes rflukes@silver.cs.UManitoba.CA Computer Science Department University of Manitoba WORK: (204)-474-8696 HOME: (204)-257-6701 From bqt@Minsk.docs.uu.se Sun Sep 12 11:11:50 EDT 1993 Article: 439 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!doc.ic.ac.uk!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8's? Date: 12 Sep 93 11:31:35 GMT Organization: Uppsala University Lines: 47 Message-ID: References: <35.89.2946.0NCD022B@asacomp.com> NNTP-Posting-Host: minsk.docs.uu.se In <35.89.2946.0NCD022B@asacomp.com> david.turner@asacomp.com (David Turner) writes: >Greetings! Hi. >I just now found this conference and was wondering if anyone really has >any PDP-8 stuff/information? Is there sort of like a PDP-8 fan club? :) Well, I got seven pdp-8 myself. One 8/e, one 8/f, two 8/m, and three 8/a. I'm actually typing this using one of my 8/a. :-) There are more of us out there than you might suspect at first glance. Apart from this newsgroup, there is the pdp8 mailinglist: pdp8-lovers@ai.mit.edu But both that list, and this group is pretty quiet most of the time. I guess we're having a hard time to come up with subjects to talk about. The only things I can think of straight away is swapping hardware and software. I think I have put up a few pieces of software on ftp.update.uu.se for people to grab. I have lots of more, but transfering it with kermit takes some time, which I as usual don't have. However, if enough interest exists, I can put up a lot of stuff there. >I once had a PDP-8/e but had to get rid of it when I moved. :( Too bad. :-( >I still have several of the books, tho. Me too. >Lets see a show of hands out there... What is everyone up to? Here is one hand. What I'm up to? Well, apart from keeping one pdp8 in my student room (the rest is by my parents), I'm keeping two pdp-11/70 alive and running. About to get a VAX8650 up and running as well. I'd like to find a large place to live, where I could get my bigger pdp8-system up and running. I don't do anything special on my pdp8 at the moment. (Except for using it every day...) >Regards, >** David Turner ** -- Johnny Billquist || "I'm on a bus CS student at Uppsala University || on a psychedelic trip email: bqt@minsk.docs.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From bqt@Minsk.docs.uu.se Sun Sep 12 11:13:36 EDT 1993 Article: 440 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!doc.ic.ac.uk!pipex!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: FORSALE: RK8E disk controllers Date: 12 Sep 93 11:38:13 GMT Organization: Uppsala University Lines: 13 Message-ID: References: NNTP-Posting-Host: minsk.docs.uu.se In rflukes@silver.cs.umanitoba.ca (Richard F. Lukes) writes: >I have a small number of RK8E Omnibus disk controllers for PDP8 systems. >It consists of two circuit boards, interconnecting blocks, and a set of >cables. Asking $150US or best offer. Huh? My RK8E controllers are all three boards. Do you have a more modern version? -- Johnny Billquist || "I'm on a bus CS student at Uppsala University || on a psychedelic trip email: bqt@minsk.docs.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From john@gu.uwa.edu.au Sun Sep 12 11:13:47 EDT 1993 Article: 441 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!uniwa!john From: john@gu.uwa.edu.au (John West) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Old architectures Date: 12 Sep 1993 10:57:19 GMT Organization: The University of Western Australia Lines: 52 Message-ID: <26uvaf$bsa@uniwa.uwa.edu.au> References: <1993Sep3.185632.12450@news.uiowa.edu> NNTP-Posting-Host: mackerel.gu.uwa.edu.au Xref: news.columbia.edu alt.sys.pdp8:441 alt.folklore.computers:51522 jones@cs.uiowa.edu (Douglas W. Jones) writes: >That's why I prepared the alt.sys.pdp8 faq (and I'm still working >on improving it). Eventually, I'd like to see similar faq files >for a number of other old machines. The next one I'd like to hammer >down is the IBM 701, a 1953 gem for which I happen to have the >principles of operation book. If you like such things, here's a >brief summary: PDP1, anyone? I've got a heap of manuals and things (from an emulator/clone project I'm working on). The following is from memory, so it is incomplete and probably incorrect. Computer: PDP1 Date: erk. I've forgotten. 1960 is not more than 3 years away. Technology: Transistors >Main memory: 4096 words of 18 bits. Ferrite core. Memory extension box gives 65536 words of 18 bits and changes operation of some instructions to address it. >Addressing: words >Registers: AC: 18 bits IO: 18 bits 6(?) flag bits Number system: One's complement. 18 bits Instruction: 18 bits. Mostly 6 bits of opcode followed by 12 bits of address. Low bit of opcode is 'indirect' bit - operand is at location pointed to by the location given in the instruction. Some instructions use the address field as a micro-code instruction. Various bits control various operations. Opcode 72(?) is for IO - address specifies what operation to do. IO instructions depend on what extra boxes you have plugged in. Most instructions take 10us. Core memory is inherently RMW, and instruction set takes advantage of this - you have 'store instruction part' and 'store address part' instructions for self modifying code. No stack. Subroutine call places old PC into AC. Wonderful vector displays that put this VGA rubbish to shame. The cheap one was addressable to 1K*1K. Vector so no jaggies on your lines. You could buy a character generator box that drew 5*7 characters in one of 4 sizes, and could cope with 200 or so without flickering. I'm very impressed at how fast it was. 10us doesn't sound like a particularly speedy instruction, but if you compare it to things like the 6502 (nearly 20 years later) with an average 4us per instruction, it is quite good. With the multiplier option, you could multiply 18 bit words in under 25us. John West From rflukes@silver.cs.umanitoba.ca Sun Sep 12 15:44:09 EDT 1993 Article: 442 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!TAMUTS.TAMU.EDU!bloom-beacon.mit.edu!mcrcim.mcgill.edu!sifon!newsflash.concordia.ca!mizar.cc.umanitoba.ca!silver.cs.umanitoba.ca!rflukes From: rflukes@silver.cs.umanitoba.ca (Richard F. Lukes) Subject: Re: FORSALE: RK8E disk controllers Message-ID: Sender: news@ccu.umanitoba.ca Nntp-Posting-Host: silver.cs.umanitoba.ca Organization: Computer Science, University of Manitoba, Winnipeg, Canada References: Date: Sun, 12 Sep 1993 16:39:41 GMT Lines: 23 In article bqt@Minsk.docs.uu.se (Johnny Billquist) writes: >In rflukes@silver.cs.umanitoba.ca (Richard F. Lukes) writes: > >>I have a small number of RK8E Omnibus disk controllers for PDP8 systems. >>It consists of two circuit boards, interconnecting blocks, and a set of >>cables. Asking $150US or best offer. > >Huh? My RK8E controllers are all three boards. Do you have a more modern >version? >-- >Johnny Billquist || "I'm on a bus >CS student at Uppsala University || on a psychedelic trip >email: bqt@minsk.docs.uu.se || Reading murder books >pdp is alive! || tryin' to stay hip" - B. Idol Sorry for the confusion. The RK8E is three boards. I made a mistake in my posting... --Rich -- Richard F. Lukes rflukes@silver.cs.UManitoba.CA Computer Science Department University of Manitoba WORK: (204)-474-8696 HOME: (204)-257-6701 From lasner@watsun.cc.columbia.edu Sun Sep 12 16:05:46 EDT 1993 Article: 443 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: FORSALE: RK8E disk controllers Date: 12 Sep 1993 19:43:15 GMT Organization: Columbia University Lines: 338 Message-ID: <26vu4j$i9h@apakabar.cc.columbia.edu> References: NNTP-Posting-Host: watsun.cc.columbia.edu In article , Johnny Billquist wrote: >In rflukes@silver.cs.umanitoba.ca (Richard F. Lukes) writes: > >>I have a small number of RK8E Omnibus disk controllers for PDP8 systems. >>It consists of two circuit boards, interconnecting blocks, and a set of >>cables. Asking $150US or best offer. > >Huh? My RK8E controllers are all three boards. Do you have a more modern >version? Complete RK8E controllers aren't worth that much. I have taken away gratis complete systems, generally consisting of an 8/e with 32K and EAE, lab peripherals, two H960 cabinets, some kind of terminal, generally an LA-36, and an RK8E with two RK05. Sorry, but in the "real world" pieces of old computers have no commercial value. However, these cards do have some value to some of the collectors on this group, but it's more a matter of either spare parts, or expanding an existing hobby machine, not anything more. I will admit that RK8E cards did have a more lingering value to the used computer market, simply because they were commanding a relatively high percentage of their original over-price later than most other PDP-8 stuff. In part this is because they are modules, and thus take up less inventory space, thus less likely to wind up in the used computer broker's dumpster, or sold off to a trashman, etc. However, speaking from experience, these cards are very difficult to fix. They have a lot of chips used in circuits you can be tempted to "shotgun" meaning that if you suspect that the problem is in N chips, then change all N of them at once, etc. The reason this comes up is that a lot of the operations are too automatic, and only done once per overall disk operation. It's difficult to create scope-loopable events to trace out on a scope, etc. In any case, shotgunning techniques *also* don't work on these cards, because the lands are very tiny, and the holes in the lands are undersized! Thus, the mere event of unsoldering a chip without damaging the board becomes next to impossible. In fact, if only a hand-type vacuum desoldering tool is available, it's well nigh impossible! (Pump-operated desolderers are sucking solder while they are also heating the joint, while solder-suckers are manually released for a single shot from either a different vantage point if you have enough hands, or are applied a second or so later than the heat. Either way, they fail to pull out as much solder as the pump vacuum desolderer. In the case of the RK8E and a few other type boards, such as the motherboard of a DECmate III, etc. you need to such out that last bit of solder that's intimately touching the innards of the hole that the lead is shoved tight through. If not, you can't dislodge the lead without land/plate-through hole damage. Moreover, all of this assumes that you will destroy the chip you remove (although most aren't really worth too much per se) and are removing it pin by pin. In fact, I'll make a standing offer: if you can remove a chip from an RK8E that works, in my presence, and not break any lands/holes in the process, using a hand solder-sucker, and then can put the same chip back in where it was removed from, and it still works afterwards, you can *have* that RK8E! Mini-FAQ for RK8E family Here's some RK-isms that might apply somewhere. The RK8E is originally a three-board set where the third card connects to a special drive cable that is Berg-type on the RK8E end and is a double-height connector at the other end. That end is meant to go into an RK05 family drive which could be an RK05A, RK05J, or RK05F. (J is the upgraded A production, and includes ECO's to make the drive cheaper to manufacture, and eliminates a lot of expense and overhead dropping support of obsolete machinings that evolved over the lifetime of the A drive to become obsolete, or were dropped because they were actually detrimental! For example, the old air system included a bottom cover whose position contributed to the head alignment! To avoid the need to align the heads when changing the air filter, the air system was redesigned to eliminate the bottom cover entirely. The new drive eliminates the basic machining to support the cover at all. The F is a double-drive that responds as two selected A/J drives. It is actually not a fixed drive as purported, but rather a removable drive where the cartridge handling basket, etc. have been removed, so it's merely harder to remove, but still removable. It is possible to restore the full function of removability to an F drive, merely by using the proper components taken from a defunct J drive, etc. If you remove the false front, the F drive reveals a front logo clearly meant to be the front of a removable F drive. The reason all this was done is that DEC didn't want to confuse customers over more than one type of seemingly identical, yet incompatible pack! If you use premium media, they can be used in either J or F drives, but are not interchangeable media. Only an F can format and read/write a pack meant for an F, but if that pack is formatted in a J, it's then fine for all J drives, and now incompatible with an F. Moreover, it could get too dirty being used in a J to be later acceptable for an F (after reformat!), etc. And of course, since the drives can't read or write each others format, there is the additional confusion of people trying to place the pack in the wrong drive type, etc. To avoid all of this, they just decided to make the F a "fixed" pack. You still have to place in the drive an appropriate 12 or 16 sector pack in order to use it with an -11 or -8 system respectively. Also, a J drive's electronics are the same as the F's double-stepping drive, which wasn't anticipated in the original A drive. The modules are redesigned to have J-F option switches onboard, etc.) RK8E board sets normally support up to 4 RK05 drives (where an F drive counts as an even/odd pair) and are noted as *not* using RK11D-type unit selection. This means that there are four select lines, each waking up one drive. This is the same scheme as used commonly in more recent floppy drives, etc. The RK11D-type selection method means that you assert that line, and then ignore one of the four select lines. Then, the other three select lines form a 3 line -> 8 line encoder so that 3 bits support up to 8 drives. There exists a modification to the RK8E board set known as RKS8E. This implements the RK11D-type selection. To address four more drives, an additional bit is added, defined as AC[0] during the IOT 0 of the RK8E instructions. (RK8E normally doesn't use this instruction.) The latest version of the RK formatting programming supports this bit. If this IOT is never issued, the drives are totally compatible for any operations on drives 0-3. The rest of the RKS8E consists of adding a fourth card, and replacing all of the over-the-top interconnects with a flexible printed circuit cable device (similar technology to what's inside of many fairly recent telephones, i.e., flexible printed circuit boards) that connects to all four cards. The fourth card (M7107) is etched with the words "4096 Word Count Module" and this is precisely what (at most) it can cause to happen. The normal transfer of an RK8E is to read or write one sector of 256x12 words, then wait for additional programming to initiate another transfer. In real-time, this is nearly impossible; some people have had to resort to two-way interleave to achieve passable performance. Non-real-time handlers such as OS/8 and P?S/8 do manage to keep up with one-one interleave as long as there are no interrupts during the critical period between sectors, etc. (There is less than 100 microseconds available to issue the next operation to avoid a full rotation latency.) The M7107 implements a 4-bit register to allow extra automatic transfers to occur without program intervention. The only restriction is that the sectors are in search order on the disk, and all on the same track. Thus, if you ask for sector 00, you can ask for sectors 01 through 17 to be transferred as well, but if you ask for sector 01, and request 15 additional sectors, the last one will be sector 00 on the same track, not the next one! (Neither a head select or a track select change will result; all transfers are to the current head/track. However, if you maintain transfers to full tracks in normal order, this is precisely what will happen.) As far as I can tell, the modifications are limited to the first two cards when converting an RK8E -> RKS8E. The "conventional wisdom" in the used computer industry (and totally false!) was that the RKS8E was an "upgrade" to an RK8E, i.e., an unmodified RK8E board set merely needs to be plugged into the M7107 and the flexible cable set. In fact, they become a four board set that cannot be split up without unmodifying the boards! Due to confusion about how the bits are counted, the bits chosen for the word-count register are AC[1-4] during the same IOT 0 that is loading the AC[0] bit into the high-order unit select bit. But the bits are backwards in the PDP-8 sense, meaning that the least significant bit is on the left, and the most significant on the right! (The designers thought that 0 is the least significant bit, so they put the unit bit there, and that 1-4 were the next most significant bits, so they put them there, etc.!) The RK8E includes a maintainence instruction which is only used in diagnostics. It allows various registers to be shifted out for examination, etc. However, due to a timing quirk, the maintainence instruction *ONLY* doesn't work on a KK8A CPU-based machine! Thus, the diagnostic comes with a warning that to run it, the CPU has to be changed to KK8F (8/e card set) with terminator, etc. There is rumor that the entire RK8E was redesigned onto two hex boards and then designated RK8L (*not* RK8A!) and this is what the formatting programming calls it, etc. The RK8L implements the maintainence instruction correctly so there is no CPU consideration, and also supports the RKS8E enhancements, etc. This board certainly got into prototype production, if not actual production. There is an additional variant of the RK8E called RK8F. This is a modification made to allow the RK to be plugged into the DW8E level converter. The DW8E is available for all negative and positive buss machines using two variants - DW8E-P and DW8E-N. Each DW8E supports a set of common non-DMA slots and and certain slots reserved for individual DMA peripherals. You have to plug in certain option cards to "wake up" the slots at all even if there isn't a DMA peripheral plugged in there. (Rewiring the slot should cure this problem! The idea was that multiplexing was done by denying some of the basic Omnibus timing signals to the slots until the DMA had its "turn", thus the slots are "dead" even to non-DMA, etc. However, only the RK8F was ever designed for DW8E usage, so the need for a second DMA peripheral is moot, thus it's better to just jumper in the missing timing signals to those slots to get back more viable non-DMA slots, etc.) So, in essence, there are slots "reserved" for the RK8F in a DW8E, etc. The RK8F modification essentially implements positive-buss-type DMA control signals instead of Omnibus control signals commanding the RK DMA cycles. It takes about 20 add/cuts to implement it on the front card (M7104). According to documentation, the RK8F modification affects M7104 and M7105, not M7106. Close investigation reveals no changes on the M7105. Speculation is that the change was merely an ECO requirement, so that in-production M7105 needs not be changed to become part of RK8F. (I have participated in changing over two sets of RK8F back into RK8E.) In any case, M7106 is unmodified as documented. I have a print set marked in DEC-standard red and green to show adds/cuts, and all apply to the M7104. (And it's an RK8E print set that is neither the oldest nor the newest revision.) Each RK8E cable must be connected to the first RK05 drive. Each drive has a double-height wire-wrap green block connector for the purpose. Either slot can be used. The other slot must contain either an M930 UNIBUS terminator or a UNIBUS cable to another drive. In any case, the last drive in the chain must have an M930 terminator card. Each drive's unit select is determined in the drive according to a select module plugged into the wire-wrap block. The card contains a tap switch with eight positions to support 0-7. The part is the same switch used on PDP-8/e 4K and 8K memory stacks to tap off the memory strobe timing with. There is a modification to the RK05 which allows a cable to be placed into the switch's lands that terminates in an Mate'N'Lok connector in the bottom front of the drive, where another connector from a modified front panel plugs in. On the modified front panel is a unit select switch, the identical component as used in the TU56 for unit select. This allows user-selectable drives. In the case of a modified RK05F drive, the low-order bit of the unit select is ignored (as is the case back on the tap switch on the unmodified card as well!). Modifications can be found on A, J, and F drives and consists of removing the tap switch, adding the cable, cutting a hole on the front panel, and adding the switch and mating cable. RK8E software considerations: As explained above, there are problems with real-time on the original RK8E controller, mostly solved by using the RKS8E modifications (RK8L) if available. The alternative is to use 2:1 interleave which allows a few milliseconds between transfers to get the next one started, but does mean the aggregate transfer rate per track is cut in half. The software has to determine where the next sector to be accessed is, determine if that transfer is on the same or the other head, and if it involves a seek to another (usually the next) track. If a seek is involved, a bit must additionally be set to allow the sector headers to be checked for track validity to indicate a seek error didn't happen (only the track part of the address is checked; the sector number is ignored since that's always determined from the physical hard sector marks on the bottom of the media). Once the bit is set, at least one sector must be sacrificed as the one checked, so this must be avoided when a seek doesn't occur, or a full turn rotation penalty will be paid attempting to transfer the next physical sector, etc. Most users of OS/8 and P?S/8 don't use real-time applications, so the software can barely keep up with the one hundred microsecond window of time available to initiate the next sector in sequence. Should an interrupt occur from another part of the application, the disk performance suffers, but it's not detrimental in any other way, etc. Formatting the RK8E is actually rather trivial, because something somewhat risky is involved here: the drive *always* rewrites the sector header when writing to the disk. (This is why all the checking is done in the handlers for the disk!) Formatting consists of merely writing normally while always disabling that header-checking bit. The standard formatter writes out self-identifying data in each of the sectors while the header-check bit is disabled. After the fact, a normal read is attempted. The data must be written to the correct place, as evidenced by the self-identification, and of course there must be no data errors, and no seek errors, etc. There is a bug in the RK8ENS OS/8 non-system handler in that the error recovery routine chooses a less desirable error-clearing routine. In some circumstances, a certain kind of controller error can occur that the OS/8 attempt can't clear (it just gets the same error again), thus the handler fails unnecessarily. Using an alternate error-clearing routine (involves making a one-word patch to the handler) will correctly handle all cases. The P?S/8 non-system handler does the correct error-recovery action. Due to lack of room, the OS/8 system handler not only has the same bug, but it is less selective in its error recovery, i.e., the maximal effort including recalibration, is always applied regardless of error type. (The non-system handler only recalibrates when necessary, albeit with that problematic case that can perpetuate itself as described above, etc.) The same fix can likely be applied as in the non-system handler, but it still will take the long-way-around approach to handling all errors. For example, if a read parity error occurs, the non-system handler will realize that this error requires merely a retry, not a recalibrate (needed only on seek-type errors), while the system handler treats all error conditions equally, so it would recalibrate then re-read after a read-parity error, etc. Due to larger code space being available, the P?S/8 system handler does the same error recovery procedure as the patched OS/8 non-system handler or the P?S/8 non-system handler. Booting the RK8E requires that the disk read start at track 0 head 0 sector 0 into location 00000 and wait for overlay at 00031. Since the controller cannot determine which drive was involved in the last transfer, the AC is used as a convention to determine which drive is the one being booted to. The bits left over from loading the control register for unit select are to be placed in the AC while waiting, which is usually the case after the likely instruction sequence anyway. A curious feature of the OS/8 system handler is that it has a co-resident entry point for another handler for the other half of the disk. Each OS/8 logical device on an RK8E system represents either the inner half or the outer half of the 2.5 MB device. It is also possible to patch the system so that the first device is 4096 records long and waste the rest of the disk, but usually the device is addressed as two 3248 record devices. The system device is usually RKA0: and the other half would be RKB0:. These are the permanent names of the non-system devices as seen from the non-system handler. However, the system handler works off of the device just booted to, so these relationships are only conditionally true, i.e., only if booted to drive 0. If the disk is booted to say drive 1, then SYS: is currently equivalent to RKA1:, not RKA0:. Of course, it is always referred to as SYS:, and is always correct. However, due to the structure of OS/8, the handler that is co-resident with SYS:, and of course will likely be assigned to be also known as DSK:, must be configured as RKB0:, which will actually be incorrect in this situation, since it ought to be RKB1:, or more properly RKBu: where u= the currently booted unit. It is recommended that if the specific cartridge tends to be booted to different drives in different situations, that the non-system handler be used to reference specifically RKB0:, or RKB1:, or whatever, since that definition won't change. (Of course, this whole phenomena can be looked upon as either a quirk or a feature!) In the P?S/8 environment, the disk is partitioned into logical units each 1/2 the size of the OS/8 units, and the system handler addresses two drives total, since each P?S/8 system handler addresses (up to) eight logical units. Thus, if a P?S/8 system disk is booted to either drive 0 or 1, the units stay the same, except that the unit booted to could be any of the eight units, likely 0 if the drive is 0, and 4 if the drive is 1. (Actually, P?S/8 defines an extension of the standard bootstrap that allows booting to the nearest 1/4 drive. When used with the standard bootstrap, this means that the boot unit is either 0 or 4 as above.) As in OS/8, the entire process repeats itself if the drive unit is either 2 or three. There is sufficient space in the system handler to accommodate supporting the RKS8E or RK8L extension of drives 4,5,6,7 as well in a like manner, etc. In the P?S/8 environment, the disk is addressed to the nearest 128-word logical block, which in this case is to the 1/2 physical record. The handler includes code to manage this correctly so that unreferenced record halves remain undisturbed. (When OS/8 writes an odd number of pages to an RK8E, the other half of the last record gets zeroed out. When P?S/8 makes a similar call, the other half's data is preserved. Internally the handler carries this out by buffering the data, part from the original record, and the new data from the user's call, and both are written out together. Some CP/M and early MS-DOS systems work this way as well, using 1024 bytes per sector on floppies where the call is to read or write only 512 bytes, etc.) The handler does check for the (likely) cases where the extra kludging need not be done, so the usual disk performance is identical to OS/8 where comparisons can be made, etc. To accomplish this, P?S/8 requires 8K, rather than its usual 4K, so RK8E support comparing OS/8 to P?S/8 has the rather unusual nature that they both require 8K, whereas in most situations P?S/8 requires 4K while OS/8 requires 8K, or alternatively P?S/8 requires 8K while OS/8 requires 12K for more difficult devices, etc. COS-300/310 RK8E disks are layed out identically to OS/8 on RK8E, and each system can directly access each other's files without unusual handlers. (Of course COS internal conventions, such as file innards for non-executables, base date year, text format, restrictions on most executables, commands to access files being more restrictive and totally different, etc. still apply, but on most devices there is an extra layer of incompatibility because the device handling is also different, but not in the case of the RK8E, etc.) cjl From zrepachol@cc.curtin.edu.au Tue Sep 14 03:47:21 EDT 1993 Article: 444 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!uniwa!info.curtin.edu.au!cc.curtin.edu.au!zrepachol From: zrepachol@cc.curtin.edu.au (Paul Repacholi) Newsgroups: alt.folklore.computers,alt.sys.pdp8 Subject: Re: ANALYTICAL ENGINE, book review wanted Date: 13 Sep 93 22:24:39 +0900 Organization: Curtin University of Technology Lines: 15 Message-ID: <1993Sep13.222439.1@cc.curtin.edu.au> References: <317@crayola.win.net> <93336195420.dave.15036@gilly.uucp> <1993Sep9.104959.27228@aber.ac.uk> NNTP-Posting-Host: cc.curtin.edu.au Xref: news.columbia.edu alt.folklore.computers:51586 alt.sys.pdp8:444 In article <1993Sep9.104959.27228@aber.ac.uk>, clef@aber.ac.uk (Jim Finnis) writes: > In article <93336195420.dave.15036@gilly.uucp> > dave%gilly@speedway.net burbled: >>kcrosby@crayola.win.net (Kip Crosby) writes: >>Related question: anyone remember _A_Fortran_Coloring_Book_? >>Did you learn Fortran from it? > 'fraid so - recently even! My SO recently found it in an old cardboard Fraid not. I learnt Fortran from 'Teach yourself Computer Programing'. The yellow and black one. Thought it would be a good idea, just in case I ever got to see a computer for real. Pick up a copy a few years ago BTW. The library service had thrown it out... ~Paul From david.turner@asacomp.com Tue Sep 14 03:47:43 EDT 1993 Article: 445 of alt.sys.pdp8 Path: news.columbia.edu!news.media.mit.edu!bloom-beacon.mit.edu!xlink.net!howland.reston.ans.net!wupost!cs.utexas.edu!uwm.edu!biosci!barrnet.net!infoserv!asacomp!david.turner From: david.turner@asacomp.com (David Turner) Newsgroups: alt.sys.pdp8 Subject: RE: OLD ARCHITECTURES Message-ID: <35.98.2946.0NCD048E@asacomp.com> Date: 13 Sep 93 03:47:00 GMT References: <26uvaf$bsa@uniwa.uwa.edu.au> Organization: ASA CompuHelp, Inc. Lines: 15 J>PDP1, anyone? I've got a heap of manuals and things (from an >emulator/clone project I'm working on). The following is from memory, so it >is incomplete and probably incorrect. Just because I am insanely curious, what exactly is it that you are working on? A PDP-1 emulator? What would you run it on? Is it near completion? How in the world did you find manuals and stuff for it? I would love to hear more... if you don't want to post too much on the topic, I would be happy to swap e-mail. Regards, ** David Turner ** --- ~ QMPro 1.0 00-0000 ~ Misspelled? Impossible. My modem is error correcting. From david.turner@asacomp.com Tue Sep 14 03:48:50 EDT 1993 Article: 446 of alt.sys.pdp8 Path: news.columbia.edu!news.media.mit.edu!bloom-beacon.mit.edu!usc!cs.utexas.edu!uwm.edu!biosci!barrnet.net!infoserv!asacomp!david.turner From: david.turner@asacomp.com (David Turner) Newsgroups: alt.sys.pdp8 Subject: RE: PDP-8'S? Message-ID: <35.99.2946.0NCD048F@asacomp.com> Date: 13 Sep 93 03:47:00 GMT References: Organization: ASA CompuHelp, Inc. Lines: 29 B>>I just now found this conference and was wondering if anyone really has >>any PDP-8 stuff/information? Is there sort of like a PDP-8 fan club? :) B>Well, I got seven pdp-8 myself. One 8/e, one 8/f, two 8/m, and three 8/a. >I'm actually typing this using one of my 8/a. :-) Wow. You sure have (had) me beat. I thought I was one of the last people in the world to have one. I had a PDP-8/e and an 8/m. Everything was dead, and we (me and my friend) brought it back to life. Very neat. Almost died laughing when the date program wouldn't go past 1976! (I think). Had it up and running OS/8 on diskettes. I also used to use the big rack mounted 8/e to heat my bedroom. ;) Does anyone have an old PDP-8 they would like to give to a good home? B>Here is one hand. >What I'm up to? Well, apart from keeping one pdp8 in my student room (the >rest is by my parents), I'm keeping two pdp-11/70 alive and running. >About to get a VAX8650 up and running as well. I'd like to find a large >place to live, where I could get my bigger pdp8-system up and running. >I don't do anything special on my pdp8 at the moment. >(Except for using it every day...) Wow again. You must have very understanding parents! Just curious, where do you live? I am not too up on signatures and geography... :) Regards, ** David Turner ** --- ~ QMPro 1.0 00-0000 ~ Dogs come when you call. Cats have answering machines. From hsnewman@wixer.bga.com Wed Sep 15 18:58:44 EDT 1993 Article: 447 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!milano!cactus.org!wixer!hsnewman From: hsnewman@wixer.bga.com (Harris Newman) Subject: decwar Message-ID: <1993Sep14.155012.1723@wixer.bga.com> Organization: Real/Time Communications Date: Tue, 14 Sep 1993 15:50:12 GMT Lines: 8 I am looking for the source to a game which ran on a Dec 10 called Decwar. It was developed at the university of texas, in fortran. It is a multiplayer star trek game. If you have played Megawar on compuserve, that is it, but rewritten with slightly more functionality. Anyone with any information, please contact me at hsnewman@wixer.bga.com, or 512-322-3841. Thanks! From bqt@Minsk.docs.uu.se Thu Sep 16 21:11:35 EDT 1993 Article: 448 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!xlink.net!math.fu-berlin.de!news.rrz.uni-hamburg.de!news.dkrz.de!dscomsa!dxcern!mcsun!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt From: bqt@Minsk.docs.uu.se (Johnny Billquist) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8'S? Date: 16 Sep 93 23:10:03 GMT Organization: Uppsala University Lines: 48 Message-ID: References: <35.99.2946.0NCD048F@asacomp.com> NNTP-Posting-Host: minsk.docs.uu.se In <35.99.2946.0NCD048F@asacomp.com> david.turner@asacomp.com (David Turner) writes: >B>>I just now found this conference and was wondering if anyone really has > >>any PDP-8 stuff/information? Is there sort of like a PDP-8 fan club? :) >B>Well, I got seven pdp-8 myself. One 8/e, one 8/f, two 8/m, and three 8/a. > >I'm actually typing this using one of my 8/a. :-) >Wow. You sure have (had) me beat. I thought I was one of the last people >in the world to have one. I had a PDP-8/e and an 8/m. Everything was >dead, and we (me and my friend) brought it back to life. Very neat. Well, there are quite a few other people around here who has pdp8's up and running. >Almost died laughing when the date program wouldn't go past 1976! (I >think). Had it up and running OS/8 on diskettes. I also used to use the >big rack mounted 8/e to heat my bedroom. ;) Does anyone have an old >PDP-8 they would like to give to a good home? Hmmm, you must have had an old version of OS/8. It was modified to take dates until 1999. (Some strange effects can be noted from that patch, but that is another story...) >B>Here is one hand. > >What I'm up to? Well, apart from keeping one pdp8 in my student room (the > >rest is by my parents), I'm keeping two pdp-11/70 alive and running. > >About to get a VAX8650 up and running as well. I'd like to find a large > >place to live, where I could get my bigger pdp8-system up and running. > >I don't do anything special on my pdp8 at the moment. > >(Except for using it every day...) >Wow again. You must have very understanding parents! Just curious, where >do you live? I am not too up on signatures and geography... :) Well, the pdp-11s and the VAX is not by my parents, only the rest of my pdp8's are. The rest of the stuff is at the university here, owned by the computer club here, with me as chairman and one of the most active members. I'm slowly building up an ftp archive of DEC stuff by the way. Have a few OS/8 items there as well. Look at ftp.update.uu.se I live in Uppsala, Sweden. My parents are in Stockholm. -- Johnny Billquist || "I'm on a bus CS student at Uppsala University || on a psychedelic trip email: bqt@minsk.docs.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From david.turner@asacomp.com Sat Sep 18 01:35:10 EDT 1993 Article: 449 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Subject: Emulating the PDP-8 From: david.turner@asacomp.com (David Turner) Path: news.columbia.edu!sol.ctr.columbia.edu!caen!usenet.coe.montana.edu!decwrl!parc!barrnet.net!infoserv!asacomp!david.turner Distribution: world Message-ID: <35.103.2946.0NCD093B@asacomp.com> Date: Fri, 17 Sep 93 09:06:00 -0500 Organization: ASA CompuHelp, Inc. Lines: 11 Greetings... I was wondering if anyone has done any work on a PDP-8 emulator that runs on an IBM clone? I know that there is a computer chip based on the instruction set, but I don't want to buy/build more hardware (not to mention no money). I would also be interested in emulators for other old machines... Regards, ** David Turner ** David.Turner@asacomp.com --- þ QMPro 1.0 00-0000 þ Soon To Be A Major Motion Picture. From gsc@cairo.anu.edu.au Sat Sep 18 01:35:42 EDT 1993 Article: 450 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!usc!cs.utexas.edu!uunet!munnari.oz.au!newshost.anu.edu.au!cairo!gsc From: gsc@cairo.anu.edu.au (Sean Case) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Old architectures Date: 18 Sep 93 05:23:02 GMT Organization: Australian National University Lines: 20 Message-ID: References: <1993Sep3.185632.12450@news.uiowa.edu> <26im1b$s47@gondor.sdsu.edu> NNTP-Posting-Host: 150.203.76.16 Xref: news.columbia.edu alt.sys.pdp8:450 alt.folklore.computers:51824 aty@ucssun1.sdsu.edu (young a t) writes: > There used to be "tape developer fluid" >you could buy that had little black magnetic particles suspended in something. >Dip the tape in, and the bits turned black. After the solvent evaporated, you >could lift them off with Scotch tape and read the bits from a damaged piece of >mag tape. The hardware people where I work still use it... it's one way of checking the head alignment on the tape. I don't think they've tried recovering data with it. The other thing it's good for is demonstrating how tape works to trainees. Sean Case -- Sean Case gsc@coombs.anu.edu.au "The day is surely coming when bank robbers will plead in mitigation that the getaway car had its hazards on." -- Ben Elton, _Gridlock_ From lasner@watsun.cc.columbia.edu Sat Sep 18 04:12:53 EDT 1993 Article: 451 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Old architectures Date: 18 Sep 1993 05:38:27 GMT Organization: Columbia University Lines: 16 Message-ID: <27e6sj$m63@apakabar.cc.columbia.edu> References: <1993Sep3.185632.12450@news.uiowa.edu> <26im1b$s47@gondor.sdsu.edu> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu alt.sys.pdp8:451 alt.folklore.computers:51825 In article , Sean Case wrote: >aty@ucssun1.sdsu.edu (young a t) writes: > >> There used to be "tape developer fluid" >>you could buy that had little black magnetic particles suspended in something. Reeves-Soundcraft "Magnasee" was a brand of the stuff with the ferrite suspension in it dissolved in Carbon Tet. It evaporates and shows you the flux pattern, etc. It was also useful for quarter-track audio tape to see if the height adjustment was reasonable on the head before azimuth adjustments were made. On some tape decks, the azimuth adjustment might interact with height, so you had to check the final alignment with the liquid stuff, etc. cjl From zrepachol@cc.curtin.edu.au Sat Sep 18 20:51:24 EDT 1993 Article: 452 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!uniwa!info.curtin.edu.au!cc.curtin.edu.au!zrepachol From: zrepachol@cc.curtin.edu.au (Paul Repacholi) Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Old architectures Date: 19 Sep 93 05:43:01 +0900 Organization: Curtin University of Technology Lines: 14 Message-ID: <1993Sep19.054301.1@cc.curtin.edu.au> References: <1993Sep3.185632.12450@news.uiowa.edu> <26im1b$s47@gondor.sdsu.edu> NNTP-Posting-Host: cc.curtin.edu.au Xref: news.columbia.edu alt.sys.pdp8:452 alt.folklore.computers:51838 In article , gsc@cairo.anu.edu.au (Sean Case) writes: > aty@ucssun1.sdsu.edu (young a t) writes: >>could lift them off with Scotch tape and read the bits from a damaged piece of >>mag tape. > > The hardware people where I work still use it... it's one way of checking > the head alignment on the tape. I don't think they've tried recovering > data with it. Where do they get it from? I need some for head alighnments, and can't find any. ~Paul From lasner@watsun.cc.columbia.edu Sat Sep 18 22:29:39 EDT 1993 Article: 453 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8'S? Date: 19 Sep 1993 01:21:23 GMT Organization: Columbia University Lines: 74 Message-ID: <27gc6j$4ee@apakabar.cc.columbia.edu> References: <35.99.2946.0NCD048F@asacomp.com> NNTP-Posting-Host: watsun.cc.columbia.edu In article , Johnny Billquist wrote: >Hmmm, you must have had an old version of OS/8. It was modified to take >dates until 1999. (Some strange effects can be noted from that patch, >but that is another story...) Back in the days before OS/8 V3D, the date was only good from 1970-1977, since the OS/8 date format, which was hastily designed, only allocates three bits for the year. As of V3D, the format was "enhanced" in a kludged way: There are two bits in memory (in 07777) that affect the base year to be either 1970, 1978, 1986, or 1994. So, the current year is the value of the two bits times eight plus the current year offset. Thus the year (in theory) now runs from 1970-2001. However, there are several problems with this implementation: a) Most programs can't format out the year past 1999 due to the use of limited range arithmetic methods. This means that 2000 and 2001 get junk and non-digits in the output. Some are even just two digit routines to append onto a constant "19". OS/8 is not the first, nor the last, to have this problem! b) The existent routines to set the date can't parse input for 2000 and 2001. This can be corrected within OS/8 itself, but only extends the usefulness of the lifetime of the date for another two years. c) The worst problem - the date is anomolous! The common implementation of the date for virtually all files is to only store the three bits that merely define the date offset, not the absolute date! Thus, all systems "guess" at the date in terms of the current year. A file *must* be presumed to exist in the current year or at most the previous seven years. Note that at the beginning of the year, most files that seem to be in the nearby future are more likely eight years old! (Or multiples of eight years old!) This could be marginally corrected to check to see if the file's date is in the future of the apparent current year, and if so, at least proclaim it to be eight years old. This would be more helpful in January than December, but adds a drop in the bucket, etc. When OS/8 was formulated, the directory format supports the notion of an optional number of "additional information words" where the first one is defined as the date word. Most people just leave the defaults set, so the anomolous date is all they use, etc. However, the OS/8 directory structure is problematic, and if there are many small files, the directory can run out of entry space long before the device runs out of physical space! In that kind of situation, people jettison the first AIW, and then there is no date on the file at all. If the device can tolerate further intrusion into the directory space, then it's possible to store an additional AIW to store the extension to the date. There is no current support for this, but it could be easily added. While at it, the additional word can store additional year group bits to extend the usefulness of the overall date reckoning. Upgrading the rest of OS/8 to implement the year extensions is another matter entirely! Additional bits must be found to support the additional year offsets, etc. An alternative would be to declare an imputed group offset. All this means is that you can't fake the past as easy! The system could be defined in terms of a patch made to some centralized routine. (Note: the image of OS/8 PIP is currently used as the arbiter of device physical size!) Thus, the total date is the 32 year span of what's in memory plus eight times an imputed value taken from the centralized routine, etc. which is used to set the date, etc. If all of this is done, then only files with a single AIW are anomolous, and files with no AIW have no date, but then all the rest of the files will have unique dates as far forward as any of us could want! (I suspect this is part of what's going into OS/8 V5 :-).) cjl From dnichols@d-and-d.com Sun Sep 19 22:58:58 EDT 1993 Article: 454 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!ceilidh!dnichols From: dnichols@d-and-d.com (DoN. Nichols) Subject: Re: Old architectures Message-ID: <1993Sep20.001457.14310@d-and-d.com> Sender: usenet@d-and-d.com (Usenet) Nntp-Posting-Host: shindig Organization: D and D Data, Vienna VA References: <26im1b$s47@gondor.sdsu.edu> <1993Sep19.054301.1@cc.curtin.edu.au> Date: Mon, 20 Sep 1993 00:14:57 GMT Lines: 33 Xref: news.columbia.edu alt.sys.pdp8:454 alt.folklore.computers:51900 In article <1993Sep19.054301.1@cc.curtin.edu.au> zrepachol@cc.curtin.edu.au (Paul Repacholi) writes: >In article , gsc@cairo.anu.edu.au (Sean Case) writes: >> aty@ucssun1.sdsu.edu (young a t) writes: >>>could lift them off with Scotch tape and read the bits from a damaged piece of >>>mag tape. >> >> The hardware people where I work still use it... it's one way of checking >> the head alignment on the tape. I don't think they've tried recovering >> data with it. > >Where do they get it from? I need some for head alighnments, and can't >find any. Well ... what I have, _Mag View_ I obtained from Saxitone Tape Sales in the Washington D.C. area a few years ago, but they have gone out of business. It is in an aerosol can, labeled "Magnetic Tape Track Developer", and was manufactured/packaged by Nortronics, the company that makes replacement tape heads for almost any flavor of audio tape drive. The part number on the can is QM601, and contains 4 Oz. of TrichloroTrifloroEthane and Iron Power based on the label. It might be more difficult to get these days, with the increased concern about chloro-fluoro-carbons. It doesn't take much, so I have had many years of use from it. (I also don't need to use it often.) Good Luck DoN. -- Email: | ...!uunet!ceilidh!dnichols Donald Nichols (DoN.) | Voice (Days): (703) 704-2280 (Eves): (703) 938-4564 --- Black Holes are where God is dividing by zero --- From ivie@cc.usu.edu Mon Sep 20 13:09:20 EDT 1993 Article: 455 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu Newsgroups: alt.sys.pdp8 Subject: Re: PDP-8'S? Message-ID: <1993Sep20.100216.767@cc.usu.edu> Date: 20 Sep 93 10:02:16 MDT References: <35.99.2946.0NCD048F@asacomp.com> <27gc6j$4ee@apakabar.cc.columbia.edu> Organization: Utah State University Lines: 12 In article <27gc6j$4ee@apakabar.cc.columbia.edu>, lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > However, the OS/8 directory > structure is problematic, and if there are many small files, the directory > can run out of entry space long before the device runs out of physical space! OS/8 is certainly not the only operating system with this problem. CP/M and RT-11 spring to mind. I don't know enough about the Un*x file structures to be sure, but I suspect that even on Un*x you could run out of inodes before you've filled up the disk. Roger Ivie ivie@cc.usu.edu From jeff@crash.cts.com Mon Sep 20 22:36:56 EDT 1993 Article: 456 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!usc!pravda.sdsc.edu!news.cerf.net!crash!jeff From: jeff@crash.cts.com (Jeff Makey) Subject: Re: PDP-8'S? Organization: Future Procrastinators of America Date: 20 Sep 93 18:19:39 PDT Message-ID: <1993Sep20.181939.21982@crash> References: <27gc6j$4ee@apakabar.cc.columbia.edu> <1993Sep20.100216.767@cc.usu.edu> Lines: 12 In article <1993Sep20.100216.767@cc.usu.edu> ivie@cc.usu.edu writes: >but I suspect that even on Un*x you could run out of inodes before >you've filled up the disk. You could, but you don't have to. With BSD-derived versions of UNIX the ratio of disk space to inodes is a configurable parameter set when you do a newfs(8) command. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Domain: jeff@crash.cts.com UUCP: nosc!crash!jeff From brianm@cbme.unsw.EDU.AU Tue Sep 21 11:37:29 EDT 1993 Article: 457 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!metro!usage!brianm From: brianm@cbme.unsw.EDU.AU (Brian Murray) Subject: Re: The Analytical Engine (CHAC newsletter!) Message-ID: <1993Sep21.074923.7359@usage.csd.unsw.OZ.AU> Sender: brianm@cbme.unsw.edu.au Nntp-Posting-Host: plod.cbme.unsw.edu.au Organization: none References: <1993Sep7.182705.28757@newsgate.sps.mot.com> Date: Tue, 21 Sep 1993 07:49:23 GMT Lines: 18 Xref: news.columbia.edu alt.sys.pdp8:457 alt.folklore.computers:51989 In article <1993Sep7.182705.28757@newsgate.sps.mot.com> wolfson@sps.mot.com writes: >Well as I recall there was an article in IEEE on constructing a pong game. >So look up back issues circa '75-76. > >Now then where did I put my old TV Typewriter terminal :-) Around that time some clever sod put the whole pong game on a single chip and called it the AY-3-8500 (from memory). There were a number of projects in magazines that used that chip, and it is the basis for the commercial home TV pong games everyone has in a box in the back of the cupboard. Perhaps the IEEE article used this chip? P.S. has anyone got the schematics of the original TTL pong game? -- ------------------------------------------------ Brian Murray --- brianm@cbme.unsw.edu.au CBX250 Apple//c VAX 11/750 SGI Indigo ----------------------------------------------------------------- From david.turner@asacomp.com Wed Sep 22 18:05:22 EDT 1993 Article: 458 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!spool.mu.edu!uwm.edu!biosci!barrnet.net!infoserv!asacomp!david.turner From: david.turner@asacomp.com (David Turner) Newsgroups: alt.sys.pdp8 Subject: FAQ info wanted Message-ID: <35.111.2946.0NCD0E17@asacomp.com> Date: 22 Sep 93 16:17:00 GMT Organization: ASA CompuHelp, Inc. Lines: 6 Can anyone tell me how to get the alt.sys.pdp8 FAQ using PC-Board BBS system? The ONLY access I have to the Internet is via PC-Board. Thanks! ** David Turner ** --- ~ QMPro 1.0 14-3452 ~ It's not hard to meet expenses, they're everywhere. From jones@pyrite Thu Sep 23 13:32:26 EDT 1993 Article: 459 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: FAQ info wanted Sender: news@news.uiowa.edu (News) Message-ID: <1993Sep23.140509.7414@news.uiowa.edu> Date: Thu, 23 Sep 1993 14:05:09 GMT References: <35.111.2946.0NCD0E17@asacomp.com> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 13 >From article <35.111.2946.0NCD0E17@asacomp.com>, by david.turner@asacomp.com (David Turner): > Can anyone tell me how to get the alt.sys.pdp8 FAQ using PC-Board BBS > system? The next scheduled posting of the faq is Oct 8. If all goes well, I will have made a major addition of the faq, parts 2 and 3, which are something of a history of the PDP-8, model by model, complete with production history, where available, citations to advertisements and press releases for the model, notes on compatablility, notes on the applicable DEC manuals, etc. Doug Jones jones@cs.uiowa.edu From jones@cs.uiowa.edu Thu Sep 23 16:36:53 EDT 1993 Article: 460 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@cs.uiowa.edu (Douglas W. Jones) Subject: PAL-8 cross assembler Sender: news@news.uiowa.edu (News) Message-ID: <1993Sep23.161737.11077@news.uiowa.edu> Date: Thu, 23 Sep 1993 16:17:37 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 39 I have added (probably incorrect) support for the RELOC operation in my PAL-8 cross assembler written in C. Anyone interested in checking it out and telling me where I went wrong is welcome to a copy (by E-mail). Here's a little example assembly listing from my assembler showing the extent to which RELOC works: 1 *7000 /WHERE THIS LOADS 2 RELOC 200 /WHERE THIS THINKS IT IS 3 07000 0000 CODE, .-. 4 07001 1377 TAD (.) /A LITERAL, THE CURRENT LOC 5 07002 7041 CMA IAC 6 07003 1376 TAD (CODE) /A LITERAL 7 07004 5600 JMP I CODE /A REF ON CURRENT PAGE 8 07376 0200 PAGE /FORCE OUT THE LITERALS 07377 0201 9 RELOC /TURN OFF RELOCATION 10 07200 7200 . /PROVE THINGS ARE BACK TO NORMAL 11 $ Note that the literal reference to . on line 4 is interpreted as a ref to 0201 and not 7001, and note that it defines the label CODE as 0200 instead of 7000. Even so, it knows (on line 7) that CODE is a current page address. I haven't tested nested RELOC operations (I think they'll work), and I don't know whether or not to relocate origin settings! That is, should *7000 RELOC 200 work the same as RELOC 200 *7000 or not? It can be done either way! Doug Jones jones@cs.uiowa.edu From lasner@watsun.cc.columbia.edu Thu Sep 23 16:38:00 EDT 1993 Article: 461 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PAL-8 cross assembler Date: 23 Sep 1993 20:36:47 GMT Organization: Columbia University Lines: 207 Message-ID: <27t1cv$k5f@apakabar.cc.columbia.edu> References: <1993Sep23.161737.11077@news.uiowa.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article <1993Sep23.161737.11077@news.uiowa.edu>, Douglas W. Jones wrote: >I have added (probably incorrect) support for the RELOC operation in my >PAL-8 cross assembler written in C. Anyone interested in checking it out >and telling me where I went wrong is welcome to a copy (by E-mail). > >Here's a little example assembly listing from my assembler showing the >extent to which RELOC works: > > 1 *7000 /WHERE THIS LOADS > 2 RELOC 200 /WHERE THIS THINKS IT IS > 3 07000 0000 CODE, .-. This should read: 3 000200* 0000 CODE, .-. /WHERE THIS THINKS IT IS In other words, you need support for more address bits, since the DEC version of memory goes up to 128K, and the CESI version goes further. BTW, P?S/8 PAL goes up to 256K. You get these extensions either by specifying a larger field than 7, or by using the BANK pseudo-op which allows specifying memory to the nearest 32K. And the address displayed is the one where the RELOC took it, but a "*" is displayed to indicate that the assembler "knows" that relocation is in effect. BTW, P?S/8 PAL and PAL-8 differ on a minor detail here: RELOC is *not* the only way to make the current location counter for the program and generated binary differ. For example you could use a sequence such as: *7000 NOPUNCH *200 ENPUNCH This would mean that auto-generated origins such as literal dump origins would be incorrect, so that's why you can't use literals with that scheme, but it's otherwise totally viable, and historically used a lot, etc. But in any case, it does mean the assembler gets "fooled" the same way that RELOC can accomplish it. P?S/8 PAL merely compares whether the program counter and binary address counter differ. It so, the "*" is appended. PAL-8 isn't as "smart" and only outputs the "*" when a RELOC-in-progress flag is set. As a consequence of this, use of RELOC with no argument becomes mandatory for cosmetic purposes, even though cumulative use of RELOC could make the relocation go away. Concisely, RELOC . which doesn't actually relocate anything would show an asterisk on every line until RELOC with no arg might occur. Also, there are versions of PAL8 with a RELOC-related bug: if RELOC with no arg isn't given at the end of assembly, the relocation becomes pass-wise additive! Later versions initialize each assembly pass to prevent this! > 4 07001 1377 TAD (.) /A LITERAL, THE CURRENT LOC > 5 07002 7041 CMA IAC > 6 07003 1376 TAD (CODE) /A LITERAL > 7 07004 5600 JMP I CODE /A REF ON CURRENT PAGE > 8 07376 0200 PAGE /FORCE OUT THE LITERALS This isn't like either PAL-8 or P?S/8 PAL. PAL-8 would output the origin by itself that is apparent, meaning 0400 in this page (all the code above should be 0200-0204, not 7000-7004). P?S/8 PAL goes one step further: all origins have a "*" in front of the four-digit origin. Moreover, both assemblers output the dumped literals *FIRST* then the "PAGE" or whatever statement that triggered the dump. P?S/8 PAL goes one step even further: in front of the literal dump is an origin for it, complete with an asterisk on it since all P?S/8 PAL origins start with a preceding asterisk. So, what's wrong here is that the address field has to be blank, and the data field needs to have the origin's value, and optionally an asterisk in front of it to do it P?S/8 PAL-style. And all of the dumped literals need to come out first, not following. (Failure to do this will screw up thousands of pages of existing source code pagination!) Opting for P?S/8 PAL compatibility means to initiate the literal dump with an origin setting on it's own line, complete with its own asterisk, before the literal dump. Then the literal dump happens, then the source code line that triggered the whole dump. Also note that any origin or loc cntr-changing pseudo-op initiates this, such as PAGE, SEGMNT, FIELD or BANK. (PAGE is next page with no arg, or an explicit page number 0-37. (.AND. the supplied arg with 37), SEGMNT is the same except using 1K-sized objects. FIELD means an entire memory field difference, and BANK means 32K different. There needs to be an assembler option switch as to whether FIELD and BANK do/do not generate an automatic *0200 afterwards (and in the P?S/8 PAL version you can actually see the *0200 because of consistency with the above, while PAL-8 gives no clues on the listing, so you have to know how it was assembled to really be sure!) In the case of FIELD and BANK there is an automatic dump of a possible current page situation, *then* there is a possible dump of the page zero literals. And of course, the pseudo-op source line comes after the dumping has finished, etc. (And in the P?S/8 PAL version, each dump starts with the visibility of the origin setting of the dump. Note also, that in both assemblers, the dumped origins are always influenced by the relocation value!) P?S/8 has an extension over PAL-8 regarding FIELD: If it is desirable to relocate code into a different loading field, PAL-8 is incapable of doing this while also maintaining the page-zero literal table. Some people have just given up and either resorted to "faking" literals or just not using them at all, or to using only current page literals inefficiently. P?S/8 PAL has a mechanism to avoid this which is to add 4000 to the FIELD argument means to inhibit the page zero literal dump aspect of what FIELD does. Thus, you can change loading fields, then restore the original field, then dump all page-zero literals at that time: FIELD 0 /WHERE WE NORMALLY LOAD . /SOME CODE PAGE /GET TO A NEW PAGE FIELD 4001 /PRESERVE TABLE *7000 /LOAD IT THERE IN FIELD 1 RELOC 200 /BUT IT'LL EXECUTE THERE IN FIELD 0 . /SOME CODE FIELD 4000 /GET BACK TO FIELD 0; TABLE STILL PRESERVED The code continues normally, and eventually the page zero literal table gets dumped normally. Definitions apply to both the code actually loaded into field 0, and also to the relocated code that actually loaded somewhere in field 1. Using techniques like this, overlays can be defined that fully take advantage of the normal assembler literal usage, etc. (Note: RELOC was invented by Joseph R. Fischetti of the WCFMPG expressly to allow literals to be used in relocated code. I implemented it first in P?S/8 PAL and then it was added to PAL-8 to mimic my implementation, albeit with the cosmetic differences described above, etc. The extension to FIELD was discussed as a possible extension to MACREL, but was never implemented as a PAL-8 option.) > 07377 0201 And of course the address is wrong here, because it should be 7377 internally for the binary, but the assembler current location counter should be 0377 at that point due to the relocation. Relocated code never shows the unrelocated addresses, just the desired (future execution) address. And of course each address, since it's subject to relocation, would have an asterisk after it (in either assembler). > 9 RELOC /TURN OFF RELOCATION Yes, this "officially" turns off relocation. But in P?S/8 PAL, it is sufficient just to have the relocation mathematically add to 0000. When a RELOC statement is given, a relocation value is created that is the difference between where the current location counter was, and where it now becomes. This internal factor is added to all binary output origins at all times, although the cosmetic assembler output uses the current location counter so the output appears to be where the programmer intends. Thus, merely using RELOC . in PAL-8 sets a flag that relocation is in effect, and all cosmetic printouts that are affected get an asterisk until RELOC without argument is given. But in P?S/8 PAL, the relocation factor *is* the flag as to whether to output the asterisk, and also, there are more places in the output where origins are given, and thus it applies to all of them. And since P?S PAL would realize the relocation is null since the relocation value became 0000, the asterisks would be supressed in that case. Also notice that the definition of RELOC's relocation factor is cumulative so that relocated code can in fact contain code to be further relocated! This actually happens in some programs! Thus, the value of relocation is *added* to the current relocation factor, not set to it. (This is why code could use multiple RELOC statements to get back to a state of non-relocation without an express RELOC , etc.) > 10 07200 7200 . /PROVE THINGS ARE BACK TO NORMAL > 11 $ > >Note that the literal reference to . on line 4 is interpreted as a ref >to 0201 and not 7001, and note that it defines the label CODE as 0200 >instead of 7000. Even so, it knows (on line 7) that CODE is a current >page address. Again, the key to the whole thing is that RELOC creates a factor looked at only by the "back end" binary generation aspect of the assembler, and at the source level appears to be an ordinary origin setting. > >I haven't tested nested RELOC operations (I think they'll work), and I >don't know whether or not to relocate origin settings! That is, should > > *7000 > RELOC 200 > >work the same as > > RELOC 200 > *7000 > >or not? It can be done either way! Obviously, it does matter! Your first form is clear what to do: the code loads into 7000 in the current field, but it assembles as if in 0200 of the current field. The second example is indeterminate because it needs to state where it was loading into *before* the statements given! Assuming that it was on say, 1000 at the time, then it would load the binary into 1000, but make it appear to be on 0200. But then the *7000 comes along and makes the assembler's origin advance by 6600 more than the apparent 0200, thus the actual loading address for the binary to follow would be 7600! *1000 /WHERE WE NOW ARE RELOC 200 /WHERE WE WANT IT TO APPEAR *7000 /WHERE WE WANT IT TO APPEAR The concise interaction of all of these assembler directives, etc. is why we have most of the important PDP-8 software. Without it, creating the software would have been lots harder! > Doug Jones > jones@cs.uiowa.edu cjl From jones@pyrite Fri Sep 24 00:12:07 EDT 1993 Article: 462 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: PAL-8 cross assembler Sender: news@news.uiowa.edu (News) Message-ID: <1993Sep24.033251.26155@news.uiowa.edu> Date: Fri, 24 Sep 1993 03:32:51 GMT References: <27t1cv$k5f@apakabar.cc.columbia.edu> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 16 Thanks for the extensive comments! As I've said before, my PAL compatable cross assembler makes an attempt at a legible listing format, but the emphasis of the project is on getting the right BIN and RIM output! If the source code produces the right object code, I'm content to stop there and leave cosmetic listing issues to others. The purpose of the thing is to aid in bootstrapping when all you've got is a bare machine with device 03/04 support. I haven't put any effort into supporting large model addressing, so it supports fields 0 to 7, and no more. That's enough to get quite far. The clarification on the origin settings is useful! The net result is that *.+1 will work with RELOC in effect, but RELOC and * are not "commutative" in the sense that their order matters. Doug Jones jones@cs.uiowa.edu From lasner@watsun.cc.columbia.edu Fri Sep 24 10:13:01 EDT 1993 Article: 463 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PAL-8 cross assembler Date: 24 Sep 1993 04:13:41 GMT Organization: Columbia University Lines: 12 Message-ID: <27ts5l$868@apakabar.cc.columbia.edu> References: <27t1cv$k5f@apakabar.cc.columbia.edu> <1993Sep24.033251.26155@news.uiowa.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article <1993Sep24.033251.26155@news.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 wrote: >I haven't put any effort into supporting large model addressing, so it >supports fields 0 to 7, and no more. That's enough to get quite far. Please don't stop without it being language compatible down to the nitty gritties. And more importantly, we need a good cross-reference facility. PAL8 is lame in this area, and also limited. There are sources too big to get a cref on! cjl From bennett@dstos3.dsto.gov.au Fri Sep 24 10:13:34 EDT 1993 Article: 464 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!munnari.oz.au!yoyo.aarnet.edu.au!fang.dsto.gov.au!dstos3.dsto.gov.au!bennett From: bennett@dstos3.dsto.gov.au Newsgroups: alt.sys.pdp8,alt.folklore.computers Subject: Re: Old architectures Date: 24 Sep 93 13:45:55 +0930 Organization: Defence Science and Technology Organisation Lines: 18 Message-ID: <1993Sep24.134555.1@dstos3.dsto.gov.au> References: <1993Sep3.185632.12450@news.uiowa.edu> <26im1b$s47@gondor.sdsu.edu> <27e6sj$m63@apakabar.cc.columbia.edu> NNTP-Posting-Host: dstos3.dsto.gov.au Xref: news.columbia.edu alt.sys.pdp8:464 alt.folklore.computers:52167 In article <27e6sj$m63@apakabar.cc.columbia.edu>, lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > Reeves-Soundcraft "Magnasee" was a brand of the stuff with the ferrite > suspension in it dissolved in Carbon Tet. It evaporates and shows you the Carbon Tet ? I would have expected the tape to dissolve ! We had a little gadget once with the fluid between two plates of glass, less messy and reusable. It was about the size of a small compass. Regards, John Bennett bennett@scm.dsto.gov.au Head, I.T. Services Development Phone : +61 8 259 5292 Corporate Information Systems FAX : +61 8 259 5537 DEFENCE SCIENCE AND TECHNOLOGY ORGANISATION Postal: Bld 73 Labs Area AUSTRALIA PO Box 1500 Salisbury South Australia 5108 AUSTRALIA From lasner@watsun.cc.columbia.edu Fri Sep 24 13:59:49 EDT 1993 Article: 465 of alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: PAL-8 cross assembler Date: 24 Sep 1993 17:57:21 GMT Organization: Columbia University Lines: 97 Message-ID: <27vce1$df1@apakabar.cc.columbia.edu> References: <1993Sep23.161737.11077@news.uiowa.edu> NNTP-Posting-Host: watsun.cc.columbia.edu In article <1993Sep23.161737.11077@news.uiowa.edu>, Douglas W. Jones wrote: >I have added (probably incorrect) support for the RELOC operation in my >PAL-8 cross assembler written in C. Anyone interested in checking it out >and telling me where I went wrong is welcome to a copy (by E-mail). What follows are OS/8 PAL8 and P?S/8 PAL listings of Doug's example: / ASSEMBLER TESTS PAL8-VB0 24-SEP-93 PAGE 1 / ASSEMBLER TESTS 7000 *7000 /WHERE THIS LOADS 0200 RELOC 200 /WHERE THIS THINKS IT IS 000200* 0000 CODE, .-. 000201* 1377 TAD (.) /A LITERAL, THE CURRENT LOC 000202* 7041 CMA IAC 000203* 1376 TAD (CODE) /A LITERAL 000204* 5600 JMP I CODE /A REF ON CURRENT PAGE 000376* 0200 000377* 0201 0400 PAGE /FORCE OUT THEE LITERALS 7200 RELOC /TURN OFF RELOCATION 007200 7200 . /PROVE THINGS ARE BACK TO NORMAL $ / ASSEMBLER TESTS PAL8-VB0 24-SEP-93 PAGE 2 CODE 0200 ERRORS DETECTED: 0 LINKS GENERATED: 0 This shows where all the relocated origin stuff has had its effect, etc. The P?S/8 version follows: / ASSEMBLER TESTS P?S PAL V08S FRI 24-SEP-93 PAGE 1 / ASSEMBLER TESTS *7000 *7000 /WHERE THIS LOADS *0200 RELOC 200 /WHERE THIS THINKS IT IS 000200* 0000 CODE, .-. 000201* 1377 TAD (.) /A LITERAL, THE CURRENT LOC 000202* 7041 CMA IAC 000203* 1376 TAD (CODE) /A LITERAL 000204* 5600 JMP I CODE /A REF ON CURRENT PAGE *0376 000376* 0200 000377* 0201 *0400 PAGE /FORCE OUT THEE LITERALS *7200 RELOC /TURN OFF RELOCATION 007200 7200 . /PROVE THINGS ARE BACK TO NORMAL $ / ASSEMBLER TESTS P?S PAL V08S FRI 24-SEP-93 PAGE S-1 USER SYMBOL TABLE LISTING CODE 0200 / ASSEMBLER TESTS P?S PAL V08S FRI 24-SEP-93 PAGE S-2 ASSEMBLY STATISTICS NO ERRORS DETECTED NO LINKS GENERATED 5K MEMORY UTILIZED NO FILES CREATED 1 SYMBOL The P?S/8 origin outputs clearly show what's happening internally, and the relocation asterisks make it clear what's relocated, etc. Hope that helps a little cjl From ted@helios.ucsc.edu Tue Sep 28 04:28:39 EDT 1993 Article: 466 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!darkstar.UCSC.EDU!darkstar.UCSC.EDU!usenet From: ted@helios.ucsc.edu (Sync) Newsgroups: alt.sys.pdp8 Subject: decmate Date: 27 Sep 1993 15:10:40 GMT Organization: UCO/Lick Observatory Lines: 27 Distribution: ba Message-ID: <286vpgINNh8c@darkstar.UCSC.EDU> NNTP-Posting-Host: helios.ucsc.edu I don't know if this system is worth $75 or $750. It was in working condition when removed from service. The main unit is a cabinet on casters about 3' high, 1' wide and 30" or so deep. (Measurements are from memory that lacks a parity check.) - DECmate RX02-PA and VT100-like terminal - Printer, daisy wheel, LQP02 and manual Tractor feed and manual 4 extra print whhels 5 new & 3 used ribbons - 5 boxes of 8" disks includeing wordprocessor, accounting and tax software - 4 different DEC "operators manuals" - DECmate owners guide - DECmate word processing users notebook - DECmate word processing: the Basics V2 cassettes/Workbook 1 - DECmate word processing: the Basics V2 cassettes/Workbook 2 - DECmate word processing: the Basics V2 administrator guide & disk - DECmate system overview V2 & tapes - DIBOL-8 language reference manual - COS-310 system reference manual (the cassettes mentioned are audio training stuff) -ted- ----------------------------Univ Calif @ Santa Cruz---------------------------- ted@lick.ucsc.edu |"He has showed you, O man, what is good; and what does the W (408)459-2110 |Lord require of you but to do justice and to love kindness H (408)423-2444 |and to walk humbly with your God?" Micah 6:8 (RSV) From jones@pyrite Tue Sep 28 04:29:02 EDT 1993 Article: 467 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: decmate Sender: news@news.uiowa.edu (News) Message-ID: <1993Sep27.174720.26842@news.uiowa.edu> Date: Mon, 27 Sep 1993 17:47:20 GMT Distribution: na References: <286vncINNh7r@darkstar.UCSC.EDU> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 33 Reposted from: the comp.sys.dec.micro; please direct followups to the original author: >From article <286vncINNh7r@darkstar.UCSC.EDU>, by ted@helios.ucsc.edu (Sync): | I don't know if this system is worth $75 or $750. It was in working | condition when removed from service. The main unit is a cabinet on | casters about 3' high, 1' wide and 30" or so deep. | (Measurements are from memory that lacks a parity check.) | | - DECmate RX02-PA and VT100-like terminal | - Printer, daisy wheel, LQP02 and manual | Tractor feed and manual | 4 extra print whhels | 5 new & 3 used ribbons | - 5 boxes of 8" disks includeing wordprocessor, accounting and tax software | - 4 different DEC "operators manuals" | - DECmate owners guide | - DECmate word processing users notebook | - DECmate word processing: the Basics V2 cassettes/Workbook 1 | - DECmate word processing: the Basics V2 cassettes/Workbook 2 | - DECmate word processing: the Basics V2 administrator guide & disk | - DECmate system overview V2 & tapes | - DIBOL-8 language reference manual | - COS-310 system reference manual | (the cassettes mentioned are audio training stuff) | | -ted- | ------------------------Univ Calif @ Santa Cruz---------------------------- | ted@lick.ucsc.edu | W (408)459-2110 | H (408)423-2444 From secrist@kxovax.enet.dec.com Tue Sep 28 13:00:40 EDT 1993 Article: 468 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!caen!usenet.coe.montana.edu!decwrl!pa.dec.com!jac.nuo.dec.com!kxovax.enet.dec.com!secrist From: secrist@kxovax.enet.dec.com (Strong datatypes for weak minds.) Newsgroups: alt.sys.pdp8 Subject: Developing Magtape Date: 28 SEP 93 10:27:30 Organization: Digital Equipment Corporation Lines: 12 Message-ID: <289hmj$3mj@jac.nuo.dec.com> NNTP-Posting-Host: KXOVAX Somebody mentioned "TrichloroTrifloroEthane" and iron filings to develop magtage. Isn't that dry cleaning fluid ?! Regards, rcs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Richard C. Secrist "The superior man understands +-+-+-+-+-+-+-+ Digital Equipment Corp. what is right; the inferior man |d|i|g|i|t|a|l| secrist@kxovax.enet.dec.com understands what will sell." +-+-+-+-+-+-+-+tm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . From jones@cs.uiowa.edu Tue Sep 28 13:03:41 EDT 1993 Article: 469 of alt.sys.pdp8 Newsgroups: alt.folklore.computers,alt.sys.pdp8,comp.sys.dec,uiowa.comp.dec,uiowa.comp.misc,uiowa.forsale,uiowa.isca Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@cs.uiowa.edu Subject: Warehouse load of antiques Sender: news@news.uiowa.edu (News) Message-ID: <1993Sep28.152731.21923@news.uiowa.edu> Date: Tue, 28 Sep 1993 15:27:31 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 106 Xref: news.columbia.edu alt.folklore.computers:52360 alt.sys.pdp8:469 comp.sys.dec:16902 Last night, I went through a small warehouse in North Liberty Iowa to look at a load of old computers. Much of this stuff is of doubtful value, but some of it may be of value as antiques, and some of it may be a good base for serious hacking. Here's what I found (I'll give a bit of history at the end of the list). 1) A Charles River Universe 68 system, with lots of manuals and diskettes. This is a MC68000 based small timesharing system, running UNOS (a flavor of UNIX). The box is a bit bigger than an IBM PC (and heavier), with an 8" diskette drive for backups, an internal hard disk, and 4 serial RS232 ports. The diskette collection includes the original system disks from Charles River, a full backup of the root file system, and one or more backups of the user file system. Each of the backups seems to fill an entire box of 8" diskettes. I figure this might be a great box for a cash strapped UNIX hacker, and in terms of cash value, it might be the most valuable system in the warehouse. 2) A PDP-11/04 with a TFI disk controller, a CDC 9762 disk drive (top loading washing machine sized!), 4 disk packs and a big hulking dataproducts (chain) line printer. The CPU and disk controller are mounted in a desk pedistal, but with the top missing. There is a small stack of spare ribbons for the printer (17 inch wide ribbons!) I figure this might appeal to PDP-11 hackers, but you need space for those old disk drives! If someone wants it, they'll need a truck to haul away the peripherals. 3) A TRS 80 Model II system, with printer on a stand, 3 keyboards and a second monitor. This might appeal to a TRS 80 freak, but I figured the cash value was nil. 4) An IBM 5224 line printer and 2 IBM 5251 data display terminals. Also, a pile of IBM "twinax" cables to connect these to their host system. There's a good maintenance manual and parts catalog for the printer. If you have an IBM System 36, or something similar, you need these. If you don't, you probably have no use for these. 5) A Singer Programmatic Flexowriter 2201 and a Singer Friden Selectadata box to go with it. Together, these made one wonderful word processing system back before computers. There is one paper tape punch and two readers, and the thing can understand control codes on tape that make it switch between readers and the keyboard, allowing, for example, a form letters to be read from one tape reader while mailing addresses are read from the other reader and typed additions come from the keyboard. No manuals and no supplies. This is possibly a museum quality antique. Is there a museum of word processing hardware anywhere? This belongs there! 6) Two Burroughs L6000 accounting machines. These have paper tape readers for loading programs, and they have fixed head disks for main memory. The machines date from around 1969 or 1970, and they have a mixture of discrete component and RTL logic in them, with wire-wrapped backplanes. They're the size of a desk, with integral printer and keyboard, and the logic stacked vertically behind. The disk spins freely when you play with the fan belt, so these are probably in operational condition. These are museum pieces. Fixed head disks as main memory seem to have hung on longer than I thought in the area of accounting machines! 7) An NCR electromechanical accounting machine, from around 1964 to 1966. The machine is "programmable" by attaching a steel bar across the carriage. This bar has stops on it that control carry propagation and similar functions, so that the different digit positions in the very long accumulator can be used for different purposes. The machine has 4 or 5 "programming" bars. This is a museum piece. 8) A pile of old power supplies, dumb terminals, and electronics scrap. So: What should I tell this guy about the stuff? Most of it is too big to ship unless it is more valuable as museum pieces than I guess, and most of what I've called museum pieces are probably going to end up in the junkyard. A bit of history: The guy ran a collection agency. The NCR machine (item 7) was his first accounting machine. It proved inadequate as the business grew, so he bought the Burroughs machine (item 6). As time passed, it came time to retire it, so he got the PDP-11 system (item 2). That was eventually replaced by an IBM System 36, and the System 36 was sold (but not the peripherals (item 4)) when the guy retired. The Flexowriter (item 5) was used as a word processor by his company until computers took over that job. The Charles River machine (item 1) and the TRS 80 system (item 3) were repossessed, as was most of the electronics junk (item 8). The guy did say that conversion from the PDP-11 system to the IBM System 36 was a real pain! Finally, if you want some of this stuff, make the guy an offer. His name is Paul McKeen, (319) 337-2035 or cellular phone 331-1808. Keep in mind that he's unlikely to want to ship anything to anyone, he's likely to be willing to let you have most of the stuff free (particularly the museum pieces), just to get rid of it, if you can get to his warehouse to pick it up, and he wants to vacate the warehouse by this coming Friday. Doug Jones jones@cs.uiowa.edu From john@mercury.cs.uregina.ca Thu Sep 30 02:31:20 EDT 1993 Article: 470 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!uwm.edu!caen!usenet.coe.montana.edu!decwrl!tribune.usask.ca!sue!mercury.cs.uregina.ca!john From: john@mercury.cs.uregina.ca (John Rosloot) Subject: Qbus RL02 controller Sender: news@sue.cc.uregina.ca Message-ID: <1993Sep30.001355.3478965@sue.cc.uregina.ca> Date: Thu, 30 Sep 1993 00:13:55 GMT Organization: University of Regina Lines: 12 Does anyone know of companies (preferably in Canada) which repair old DEC boards? I have an M8013 RLV11 Disk Control Board which gives solid fault lights on all my RL02 drives. Also, is there some fatal incompatibility between this board and the Micro PDP 11/73 bus? This board first failed when I tried it in the '73. It had been running fine in an 11/23 beforehand. Of course, it may have been killed in transit by static or something; I wasn't particularly careful with it. I have transferred other devices between the '23 and '73 (a QD01 disk controller and an RX02 floppy controller) without problems. Still, I want to be sure that I don't get the board repaired only to have it blow up when I put it in the '73 again. Any help? John, no sig From korpela@mofo.ssl.berkeley.edu Thu Sep 30 16:17:37 EDT 1993 Article: 471 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!mofo.ssl.berkeley.edu!korpela From: korpela@mofo.ssl.berkeley.edu (Eric J. Korpela) Newsgroups: alt.folklore.computers,alt.sys.pdp8,comp.sys.tandy Subject: Re: Warehouse load of antique Date: 30 Sep 1993 16:45:40 GMT Organization: Cal Berkeley-- Space Sciences Lab Lines: 135 Distribution: world Message-ID: <28f2fk$3m9@agate.berkeley.edu> References: <7.9741.41.0N5524A7@cs.uiowa.edu> NNTP-Posting-Host: mofo.ssl.berkeley.edu Xref: news.columbia.edu alt.folklore.computers:52518 alt.sys.pdp8:471 comp.sys.tandy:5177 In article <7.9741.41.0N5524A7@cs.uiowa.edu> JONES@CS.UIOWA.EDU writes: > >1) A Charles River Universe 68 system >2) A PDP-11/04 with a TFI disk controller >3) A TRS 80 Model II system, with printer on a stand, 3 keyboards and > a second monitor. >4) An IBM 5224 line printer and 2 IBM 5251 data display terminals. >5) A Singer Programmatic Flexowriter 2201 and a Singer Friden Selectadata > box to go with it. >6) Two Burroughs L6000 accounting machines. >7) An NCR electromechanical accounting machine >8) A pile of old power supplies, dumb terminals, and electronics scrap. > Someone please go pick this stuff up. It's making me ill just thinking about the possibility of it being thrown away. Somebody call the Smithsonian. Stop the destruction of our history! If I could afford it I would make the trip to Iowa just to get the stuff. Eric {Sorry for the Xpost to a.s.pdp8 and c.s.tandy. Figured you guys might have museum connections. Full details follow} -begin-included-text------------------------------------------------------ Last night, I went through a small warehouse in North Liberty Iowa to look at a load of old computers. Much of this stuff is of doubtful value, but some of it may be of value as antiques, and some of it may be a good base for serious hacking. Here's what I found (I'll give a bit of history at the end of the list). 1) A Charles River Universe 68 system, with lots of manuals and diskettes. This is a MC68000 based small timesharing system, running UNOS (a flavor of UNIX). The box is a bit bigger than an IBM PC (and heavier), with an 8" diskette drive for backups, an internal hard disk, and 4 serial RS232 ports. The diskette collection includes the original system disks from Charles River, a full backup of the root file system, and one or more backups of the user file system. Each of the backups seems to fill an entire box of 8" diskettes. I figure this might be a great box for a cash strapped UNIX hacker, and in terms of cash value, it might be the most valuable system in the warehouse. 2) A PDP-11/04 with a TFI disk controller, a CDC 9762 disk drive (top loading washing machine sized!), 4 disk packs and a big hulking dataproducts (chain) line printer. The CPU and disk controller are mounted in a desk pedistal, but with the top missing. There is a small stack of spare ribbons for the printer (17 inch wide ribbons!) I figure this might appeal to PDP-11 hackers, but you need space for those old disk drives! If someone wants it, they'll need a truck to haul away the peripherals. 3) A TRS 80 Model II system, with printer on a stand, 3 keyboards and a second monitor. This might appeal to a TRS 80 freak, but I figured the cash value was nil. 4) An IBM 5224 line printer and 2 IBM 5251 data display terminals. Also, a pile of IBM "twinax" cables to connect these to their host system. There's a good maintenance manual and parts catalog for the printer. If you have an IBM System 36, or something similar, you need these. If you don't, you probably have no use for these. 5) A Singer Programmatic Flexowriter 2201 and a Singer Friden Selectadata box to go with it. Together, these made one wonderful word processing system back before computers. There is one paper tape punch and two readers, and the thing can understand control codes on tape that make it switch between readers and the keyboard, allowing, for example, a form letters to be read from one tape reader while mailing addresses are read from the other reader and typed additions come from the keyboard. No manuals and no supplies. This is possibly a museum quality antique. Is there a museum of word processing hardware anywhere? This belongs there! 6) Two Burroughs L6000 accounting machines. These have paper tape readers for loading programs, and they have fixed head disks for main memory. The machines date from around 1969 or 1970, and they have a mixture of discrete component and RTL logic in them, with wire-wrapped backplanes. They're the size of a desk, with integral printer and keyboard, and the logic stacked vertically behind. The disk spins freely when you play with the fan belt, so these are probably in operational condition. These are museum pieces. Fixed head disks as main memory seem to have hung on longer than I thought in the area of accounting machines! 7) An NCR electromechanical accounting machine, from around 1964 to 1966. The machine is "programmable" by attaching a steel bar across the carriage. This bar has stops on it that control carry propagation and similar functions, so that the different digit positions in the very long accumulator can be used for different purposes. The machine has 4 or 5 "programming" bars. This is a museum piece. 8) A pile of old power supplies, dumb terminals, and electronics scrap. So: What should I tell this guy about the stuff? Most of it is too big to ship unless it is more valuable as museum pieces than I guess, and most of what I've called museum pieces are probably going to end up in the junkyard. A bit of history: The guy ran a collection agency. The NCR machine (item 7) was his first accounting machine. It proved inadequate as the business grew, so he bought the Burroughs machine (item 6). As time passed, it came time to retire it, so he got the PDP-11 system (item 2). That was eventually replaced by an IBM System 36, and the System 36 was sold (but not the peripherals (item 4)) when the guy retired. The Flexowriter (item 5) was used as a word processor by his company until computers took over that job. The Charles River machine (item 1) and the TRS 80 system (item 3) were repossessed, as was most of the electronics junk (item 8). The guy did say that conversion from the PDP-11 system to the IBM System 36 was a real pain! Finally, if you want some of this stuff, make the guy an offer. His name is Paul McKeen, (319) 337-2035 or cellular phone 331-1808. Keep in mind that he's unlikely to want to ship anything to anyone, he's likely to be willing to let you have most of the stuff free (particularly the museum pieces), just to get rid of it, if you can get to his warehouse to pick it up, and he wants to vacate the warehouse by this coming Friday. Doug Jones jones@cs.uiowa.edu -end-included-text----------------------------------------------------------- -- Eric Korpela | The two most common things in the korpela@ssl.berkeley.edu | universe are Hydrogen and stupidity. | -Harlan Ellison From ivie@cc.usu.edu Thu Sep 30 16:18:02 EDT 1993 Article: 472 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu Newsgroups: alt.sys.pdp8 Subject: Re: Qbus RL02 controller Message-ID: <1993Sep30.094128.1271@cc.usu.edu> Date: 30 Sep 93 09:41:28 MDT References: <1993Sep30.001355.3478965@sue.cc.uregina.ca> Organization: Utah State University Lines: 17 In article <1993Sep30.001355.3478965@sue.cc.uregina.ca>, john@mercury.cs.uregina.ca (John Rosloot) writes: > Does anyone know of companies (preferably in Canada) which repair old > DEC boards? I have an M8013 RLV11 Disk Control Board which gives solid fault ^^^^^ > lights on all my RL02 drives. Also, is there some fatal incompatibility between > this board and the Micro PDP 11/73 bus? This board first failed when I tried The RLV11 is a two-board set that speak to each other over the CD Interconnect. If you take the board that the drives connect to and plug it into a slot in the Micro PDP backplane other than the first 3, you put +12 into a bunch of logic. I know, I did it. -- ----------------+------------------------------------------------------ Roger Ivie | Don't think of it as a 'new' computer, think of it as ivie@cc.usu.edu | 'obsolete-ready' From jollie@cs.uiowa.edu Fri Oct 1 00:40:53 EDT 1993 Article: 473 of alt.sys.pdp8 Newsgroups: alt.folklore.computers,alt.sys.pdp8,comp.sys.tandy Path: news.columbia.edu!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news.uiowa.edu!jollie From: jollie@hopper.cs.uiowa.edu (Jeffrey C. Ollie) Subject: Re: Warehouse load of antique Sender: news@news.uiowa.edu (News) Message-ID: In-Reply-To: korpela@mofo.ssl.berkeley.edu's message of 30 Sep 1993 16:45:40 GMT Date: Thu, 30 Sep 1993 22:03:54 GMT Reply-To: jollie@cs.uiowa.edu (Jeffrey C. Ollie) References: <7.9741.41.0N5524A7@cs.uiowa.edu> <28f2fk$3m9@agate.berkeley.edu> Nntp-Posting-Host: hopper.cs.uiowa.edu Organization: The University of Iowa, Iowa City, Iowa, USA Lines: 38 Xref: news.columbia.edu alt.folklore.computers:52533 alt.sys.pdp8:473 comp.sys.tandy:5178 >>"Eric" == Eric J Korpela writes: Eric> In article <7.9741.41.0N5524A7@cs.uiowa.edu> JONES@CS.UIOWA.EDU Eric> writes: Eric>> 1) A Charles River Universe 68 system Eric>> 2) A PDP-11/04 with a TFI disk controller Eric>> 3) A TRS 80 Model II system, with printer on a stand, Eric>> 3 keyboards and a second monitor. Eric>> 4) An IBM 5224 line printer and 2 IBM 5251 data display Eric>> terminals. Eric>> 5) A Singer Programmatic Flexowriter 2201 and a Singer Eric>> Friden Selectadata box to go with it. Eric>> 6) Two Burroughs L6000 accounting machines. Eric>> 7) An NCR electromechanical accounting machine Eric>> 8) A pile of old power supplies, dumb terminals, and Eric>> electronics scrap. Eric>> Eric> Someone please go pick this stuff up. It's making me ill just Eric> thinking about the possibility of it being thrown away. Eric> Somebody call the Smithsonian. Stop the destruction of our Eric> history! If I could afford it I would make the trip to Iowa Eric> just to get the stuff. I'm willing to do some of the legwork if someone wants some of this stuff. Don't know how much I can do for you, but I'm willing to help. Anyway, if you're interested in any of this stuff, let me know and we can arrange something. Jeff Ollie jollie@cs.uiowa.edu -- -- Jeffrey C. Ollie jollie@herky.cs.uiowa.edu "The Happy User"