Re: BBS software for the PDP 11
> From: Christian Corti > I have a similar setup with our 11/34. .. It's not the fastest system, > and the kernel uses overlays like crazy ;-) ... I still have to add the > cache and FPP boards and see how that improves the performance. The cache should help some, but the FPP, probably not (unless you are running some application which actually does a lot of floating point). Noel
Re: KDF 8189 processor board foobared (ebay warning)
> From: Jim Stephens > I just ran across a sale on epay by a guy who thought you could pull > the processor chip off the board and sell each in separate auctions. There are a lot of idiotz out there. I ran into one who'd removed a group of boards from (probably) an -11/40, and then scrapped away the rest of the machine (including an RK11-D backplane). I took _great_ pleasure in informing him that the stuff he'd scrapped had been worth several times what the boards he had 'saved' had been worth. Noel
Re: KDF 8189 processor board foobared (ebay warning)
> From: Jim Stephens > The fellow responded and as I had suspected had never seen anything > this old before and had thought that the parts were separable. > ... > Also he is going to hopefully share photos of the entire pile and I'll > try to help him market the parts in the most profitable way for him. This is good to hear. If he doesn't know about not trashing backplanes, etc (since most people save the boards, and trash everything else), please let him know about that too. I just lucked into a DH11 backplane, w/out boards. The boards are, however, easy to find on eBay, due to people following the 'save the boards' method... Noel
Re: FTGH clear-out at Mesa Electronics, Richmond, CA, USA
> From: Anders Nelson > Heavens, why are the bit positions in descending order right to left in > that PCM-12? Numbering bits in descending order from right to left (AKA increasing order from left to right) used to be the standard - IBM S/360, PDP-10, etc, etc all did it that way. Noel
KL10 backplane on eBay
Another eBait wonder: http://www.ebay.com/itm/182597510806 The listing says "Local pick-up only", and it's in Denver, Colorado. Someone should really save this (although the chances of finding all the boards to go with it is pretty slim). Noel
Re: KL10 backplane on eBay
> From: Warner Losh > Will it fit in a pickup truck? Should fit into most 4-wheeled transport devices (except a new Ford GT, those supposedly only have 2 cubic feet or so of storage :-). Noel
Re: FTGH clear-out at Mesa Electronics, Richmond, CA, USA
> From: Paul Koning > For some definition of "standard". ... other machines of that time or earlier > numbered bits according to the power of 2 they represent, i.e., the "current > standard". Well, the vast majority of computers 'back then' numbered bits (and byes) from left to right - which is why in numbers in TCP and IP, the bytes go from left to right (necessitating byte swaps on most current architectures before sending a packet out into the network). The majority of computers being attached to the network when TCP/IP was being defined used that byte order (I think PDP-11's were the only exception, but I'm too lazy to check a copy of HOSTS.TXT to make sure), and so that's what we're stuck with now. So, I can see, centuries in the future, the bytes in a word on the Internet (and it _is_ capitalized) still being in an order set by long-dead computers. Kind of like how rail gauge today still mimics the width of Roman carts (yes, I know the story is only half-true, but it's not wholly wrong). Noel
Re: RK11-D print set
> From: Marc Howard > Although I can find the RK11D users manual on the web there doesn't > appear to be print set (schematics) out there. Does this exist > somewhere under a non-obvious name? ??? I just did a quick Google for 'RK11-D" (note quotes), and it turned up: http://manx-docs.org/details.php/1,6224 http://www.mainecoon.com/classiccmp/RK11-RK05/ in the first two pages of results. Noel
G-series Flip Chips for trade
So I have some G-series Flip Chips that I don't have a use for, and I hope someone out there does. If so, I'd like to trade them for something I _do_ have a use for - e.g. M-series FCs. Alas, according to the "Spare Module Handbook", these seem to be pretty exotic, but maybe I'll luck out. They are (with the uses listed in the SMH given in brackets): G291Disc writer with power fail 2 x G295Series switch (DF32, RS64) G296Center tap selector (DF32, RS64) G8002 AC/DC low sensor (RS64) Any interest, email me personally, please, don't spam the list. Thanks! Noel
Re: Need captive panel screw for unibus mounting
> From: Marc Howard > I need (1) of the 8/32 x 1 3/8 captive screws that are at either end of > a unibus backplane to mount it to the chassis. You don't _have_ to use the special captive screws - quite a few of the backplanes I've got were mounted with ordinary screws. Noel
Re: More Executel phone system news
> From: Adrian Graham > Completely by chance one of the programme managers for STC at the time > found all my postings ... in a last ditch attempt to give his stash of > goodies away before he put them all in the local recycling. > This means that not only do I now have two unused units and spare parts > but I also have .. full documentation, a complete source dump AND the > entire 8" disk set Oh, that is _fantastic_ news. I'm so happy this was all saved. > Another downside is I now know what's making my machine loop at > startup. Hey, the problem would be there whether or not you knew the cause - knowing the cause is surely better than not knowing! > the ASTEC 8151 was a bit of an achilles heel because of the way it was > mounted upside down and only passively cooled Any way (i.e. room) to add a small fan to help with the cooling? Sounds like that's definitely indicated... Noel
Re: RC11 manuals / schematics online?
> From: Jay Jaeger > Fortunately, I do have some, and will scan them in Yesss! Thank you! > I will do the usual 400DPI / tiffs I've found that for engineering drawings, 600 dpi is better; the prints often contain very small writing (pin numbers, etc) which are sometimes hard to read at 400. (Especially since you may have the only set left in the world, it's very important to get the best possible image of them.) Noel
Re: RC11 manuals / schematics online?
> From: Steven Malikoff > I acquired an RC11 flip chip set Do you mean literally this (just the cards), or did you mean a complete RC11 (including the backplane)? The Flip Chips do turn up (the ones I put up a post about a few days back are RC11 chips), but the backplanes are rara aves indeed. Noel
Re: gobs of stuff today from recovering a unit of mine.
> From: Toby Thain > And a lot is as-new or perfectly okay. Ditto that. Both my ADF A4 page scanner and my A3 scanner (a professional grade Epson) came off eBay (the latter for a minimal amount of money - that pro scanner is a multi-$K unit, for which I think I paid the princely sum of $200), and I've been very pleased with them. In fact, units on eBait are so cheap, I tend to buy spare units (so if one dies, I don't have to deal with getting the software on a new model to work, learn how to use it, etc). I think my ADF spares were in the region of $25 each, at which is definitely feasible to pick up spares. (Note that gear on eBait tends to follow a curve where it eventually drops very low as it becomes so antique nobody wants it - but it's still perfectly functional - and then starts to go back up as it becomes rare. If you buy spare units at the inflection point, they are remarkably cheap.) Noel
Re: Electronic Systems TRS-80 Serial I/O Board?
> From: Brent Hilpert >> The trimpot on the board says to me that the clock is most likely a >> simple RC affair. > There's a 7493 (4-bit counter) on the board as well, which looks to > have connections to the dip switches beside it, in all likelihood the > baud rate divider and rate selection Yes; but the trim pot is also there because one has to set the basic clock to one of two values, depending on whether one wants the 150/.../2400 selections, or the 110/etc selections; one has to set it to 26 usec for the former, and 35.5 usec for the latter. So drift would have been an issue, but not initial component values... Noel
Electronic Systems TRS-80 Serial I/O Board?
> From: Brent Hilpert > I don't expect anyone was making boards like this expecting to get the > target timing from fixed/off-the-shelf component values Right, that comment was more directed to the discussion here about baud rate variation. > There are two trimpots on the board, they could be one for each of the > rate series and switch-selected No, the prints (1105_RevAH_EngrDrws_Jul76, page 71) shows there's only one RC circuit associated with the UART. I don't know what the second trim-pot does (I'm too lazy to look over the prints to find it :-). Noel
Re: Getting to NeXt Command prompt
> From: Eric Christopherson >> On Mon, Jun 19, 2017, william degnan via cctech wrote: >> [Command + ~] is a system reset. > Just out of curiosity: do you mean the shift key gets held down too? > If not, it would write it as Command + `. I found the syntax slightly confusing. If it's a single keystroke, I'd have written it as 'Command-`' (by analogy with Control-C, Alt-X, etc). Noel
DB11-A Bus Repeater Engineering Drawings
So, Paul A lent me a set of these (thanks Paul!) so I could scan them in (they are not currently available online). Howwever, there's a problem. The last page in the set contains the circuit diagram for the M7248 BBSY Repeater card (the heart of the whole device, since the DB11-A uses BBSY to decide which way to turn the repeater on) - and it's missing. (I have "Page 1 of 2" for the card, but not "2 of 2"). Does anyone else have a set of these prints? If not, we're not totally hosed: the card has only 7 IC's on it, so it _should_ be possible to re-create the drawing, working backward from the card, but it would be nicer to have the original drawing (which might e.g. have notes on it that would be useful). Noel
Re: DB11-A Bus Repeater Engineering Drawings
> From: Al Kossow Hey, thanks for all the effort to help... > which has the schematic > they have been there for over three years $@#&($^@(*$&^! That's what I get for trusting Google; I tried searching for '"DB11-A" prints' and '"DB11-A" drawings' and got nothing ... except for a Manx listing: http://manx-docs.org/details.php/1,9242 which said they weren't online. $@*(&$^@*!!! (Note: I am _not_ criticizing Manx, which is an incredibly valuable resource - it's just that that entry did dissuade me from further searching...) Well, lesson for the future: check Bitsavers manually, first... Noel
Re: Help identifying UNIBUS PDP-11 CPU upgrade
> From: Josh Dersch > I pulled the ... bootstrap boards from slot 3 ... The BOOT button > causes the RUN light to momentarily flash, but that's about it. That's not too surprising. The way booting works with the M9301 boot card (not sure if you know this already; if you do, apologies, and ignore) is that the 'BOOT' button simulates a power-fail/restart - i.e. it toggles the 'power OK' line (forget whether it's ACOK or DCOK). When the CPU 'powers up', and tries to fetch the power fail restart vector from 024/6, the M9301 steps on the bus address lines and modified the address to 773024/6, which is in the ROM on the M9301. The new PS/PC retrieved at that point then sends the CPU into the ROM. So, with no M9301 plugged in, it's not too surprising it doesn't do much. The DEC QBUS processor cards (not sure about the chips themselves) can be jumpered on power-up to i) halt, or ii) fetch a PS/PC from 024/6, or iii) jump to ROM. I've no idea if this board set has something similar (and if so, what it's set to do). > Ran the front panel cable to the connector on the CPU board and powered > it up. Now I'm confused. There is no cable from the front panel to the CPU in a standard 11/34? (There's one from the front panel to the backplane; another from the front panel to the M9301; and another from the programmer's front panel [if present] to the programmer's front panel board, the M7859; but that's it, that I know of.) Did you mean the console serial line cable? Noel
Re: Help identifying UNIBUS PDP-11 CPU upgrade
> From: Josh Dersch >> Now I'm confused. There is no cable from the front panel to the CPU in >> a standard 11/34? (There's one from the front panel to the backplane; >> another from the front panel to the M9301; and another from the >> programmer's front panel [if present] to the programmer's front panel >> board, the M7859 > Front panel to the CPU upgrade, not the original CPU. ... > there's a pair of connectors on the CPU board that look suspiciously > like those on the M7859. Right, that's what's confusing me. I can't work out what you could possibly be cabling to, on the new CPU board! Those two connectors on the M7859 are used only with the 11/34, not the 11/04 (the cable from the M7859 to the programmer's front panel must be there, with both); they are there for the micro-code single-stepping function on the 11/34, etc. (One cable carries uclock, the other uPC data.) Since the new CPU probably doesn't have that ability (on the LSI-11 and F-11 chipsets, the micro-word bus is accessible outside the chips, but AFAIK the same is not true of the J-11), I'm not at all sure what those two connectors might be. Perhaps they are serial lines using the 'new' DEC standard pinout, which also use 10-pin headers? Noel
Re: Help identifying UNIBUS PDP-11 CPU upgrade
> From: Noel Chiappa > (One cable carries uclock, the other uPC data.) Minor goof there; the low bits of the uPC are in one cable, along with the "Manual Clock Enable" and "Manual Clock" signals; the other cable carries the high bit/bits (depending on whether it's a KD11-E or KD11-EA) of the uPC. This is because... > From: Mattis Lind > Actually it should work with the 11/04. The 04 does have one 10 pin > connector on the board. Hi, thanks for catching that. I looked for a Berg header on an M7263 boards, and didn't see one, which is what misled me. It's actually just a group of bare pins (in the upper left hand corner of the M7263). I looked for the connection in the KD11-D engineering drawings, but it's not shown! E.g. on page 7 of the drawings (center bottom) you can see "Manual Clock Enable" and "Manual Clock" but they are shown as connected to backplane pins (DS1 and DU1). The connector is only described on page 1 (upper left hand corner). So that explains the odd division of signals between the two cables: the KD11-D in the -11/04 apparently has one less bit of uPC (smaller uprogram), so its signals can all fit in one cable. Just to create maximal confusion, in the KD11-EA, there's one more bit of uPC than in the KD11-E, along with some other signals (e.g. "FP11-A Attached") in the second cable: this is to allow support of the optional FP11-A floating point unit, which seems to have a bunch of private ucode, in an extension to the uaddress space. The KY11-LB, although it pre-dates the KD11-EA, will probably still show the uPC correctly with an FP11-A present, as it's apparently prepared to display up to 4 bits from the 'high' connector. Noel
Re: Help identifying UNIBUS PDP-11 CPU upgrade
> From: Jerry Weiss > So it would appear the upgrade board makes provisions for both > situations. I'm not sure that the two situations that the upgrade board supports are in fact different, from its point of view. (Assuming that the two situations you refer to are the two different consoles.) Yes, the _system_ supports two situations: i) the KY11-LA connecting directly to the backplane, and ii) the KY11-LB going via the M7859; but the DEC CPUs don't seem to draw any distinction between the two. Looking at the KY11-LA prints, the connector to the backplane cable (the one which is unused with the KY11-LB) carries signals like "Halt Request" and "Halt Grant", which are generated in the M7859 (which has its own direct backplane connection) when using the KY11-LB. So as far as the consoles are concerned, those signals come to the backplane via different paths, but as far as the CPU is concerned, it sees the same things through its backplane connection, no matter which is in use - so how would the upgrade board be any different? The _only_ cable(s) that ever connect(s) to the CPU board (in the KD11-D or KD11-E) are from the KY11-LB: those cables are the ones that carry the signals to support the microcode single-stepping. How would the upgrade board use these? One thing that might help untangle the function of those two headers on the upgrade board is to look and see what chip(s) they connect to. If they aren't EIA transmitters/receivers, yes, they aren't serial lines. (I only suggesgted that because I couldn't figure out what _else_ they could be.) Can that be done? Noel
Re: Help identifying UNIBUS PDP-11 CPU upgrade
> From: Josh Dersch > There's a 20-pin header on the CPU upgrade board which connects to the > front panel. ... the programmer's panel loses most of its functionality > .. but the HALT/SS and BOOT switches are functional with the cable > connected. ... With the 20-pin cable from the front panel disconnected, > the HALT and BOOT switches are non-functional. That's interesting. There aren't 'HALT' and 'BOOT' lines in that 20-conductor cable; the data sent across that cable is keyboard scan codes, which the 8008 on the KY11-B quad board has code to decode. So the upgrade board must have something to scan the KY11-B keyboard, and translate the scan codes... > If so, the one on the CPU doesn't appear to conflict with the M7856 I > already have in the /34. Hmm, maybe one of the undocumented jumpers/switches (forget which this card has) is an enable/disable for an on-board serial console? The other possibility which just came to mind (thinking about the fact, above, that apparently the upgrade board is prepared to replace the M7859 of the KY11-B, instead of leaving it in situ, and interacting with it over the backplane, the way the -11/04-34 do) is that that connector is for use with the KY11-LA - instead of plugging the cable that comes out of the KY11-LA into the backplane, it plugs into the replacement card instead? It would be very interesting to know what chips that 10-pin header is connected to! Noel
Re: tape baking
> From: Al Kossow > You need moving air, though. > I'm not sure how you do that well in a TK50 style cartridge. Hmm, maybe not? I start with the need for moving air - which I do not dispute, just wondering what the needed effect is. I don't think it can be removing out-gassed material, I think it has to be temperature leveling - making sure the heat from the heat source is spread evenly? So one probably doesn't need moving air inside the cartridge, _if_ its temperature is even? My _guess_ is that a TK50 cartridge left for a long time in a bath of a constant-temperature gas will probably eventually come to an even temperature internally; some parts will warm faster than others, but eventually it should 'soak' all the way through; no part will be able to _stay_ cooler. And without an internal heat source, no part should be able to come to a higher temp. I'm just wondering if there are internal (rubber) parts that won't like a temp that high? Noel
Re: M9301-YB ROM flaky
> From: Fritz Mueller > A question for Noel if he's listening here You rang? :-) > how did you obtain your YB listing I plugged one in, and ran a small program that dumped the contents to the serial port. > would you consider it reliable? Reasonably. If there was bit-rot in the board, I would not be able to tell, and I only have one, so I can't compare. And I suppose I should have done the dump twice, and compared the results, to make sure there wasn't an error across the serial line. > I see a few words with different values than the ones that Noel has > listed in his partial M9301-YB disassembly. Any chance you could send in some of the differences? I can take a look at further disassembly, to see if the old values look reasonable (and if the new ones are clearly confused). > would you think it reasonable to try blowing some replacement PROMs > based on that listing? Once we've done the preceding steps, yes. (Since I already have the more-or-less fully disassembled -YA code, doing the -YB should not be _too_ hard; they seem to have pretty much the same functionality.) > I have seen no other source for the YB contents online anywhere else. Ah. I was going to ask if there was source somewhere; even if it's only hardcopy, we can still check. > Anybody have any particular part recommends for the PROMs? The Engineering Drawings have a table of info. > I haven't been able to find engineering drawings for the M9301 online > so far As Mattis says, they are in the 11/04 drawings (MP00019). But I'm a bit puzzled why you didn't find them online; I have a page, "'Missing' Digital Equipment Corporation Field Maintenance Print Sets Online": http://ana-3.lcs.mit.edu/~jnc/tech/FMPSOnline.html specifically to deal with this, and indeed a search for "M9301 Field Maintenance Print Set" and "M9301 Engineering Drawings" turns up this page as the first entry for both searches? > I may also have a go at writing a program I can toggle in to read the > contents of my failing M9301 and dump them out over the console serial > to enable a systematic comparison Let me find the one I wrote, and upload it. Noel
Re: M9301-YB ROM flaky
> From: Noel Chiappa >> I may also have a go at writing a program I can toggle in to read the >> contents of my failing M9301 and dump them out over the console serial >> to enable a systematic comparison > Let me find the one I wrote, and upload it. Here you go: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tools/dumprom.s http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tools/dumprom.lda The source is in Unix .s format, and I also have it in DEC standard .LDA binary form; if you'd like something else (e.g. an octal dump) let me know, and I can easily do that. Noel
Re: M9301-YB ROM flaky
> From: Fritz Mueller > Even better news: I was subsequently able to dump the contents of my > M9301-YB, and found they do indeed exactly match the contents ... > posted in [the] M9301-YB disassembly. Excellent news! When I get as chance, I'l do more work on the disassembly (and note that the ROM contents have been verified between two different units). Noel
Re: M9301-YB ROM flaky
> From: William Degnan > what is the memory range That's in the disassembly page: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/ROMs/M9301-YB.mac 765000-765776 and 773000-773776 > can you post the ROM dump so I can compare on my end? Well, the contents are in that page too, but here's the output of my ROM dumper (URL posted further back in the thread): http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/ROMs/M9301-YB.txt if you just want to do a 'diff' (download the ROM dumper .LDA, run it, and compare its output). > call up same in PDPGUI and compare there I don't know what format PDPGUI uses; I don't use it (don't remember why). I wrote a bespoke PDP-11 console program that runs under Unix V6 (the same as we had BITD; when I wrote this code, I didn't have access to all the MIT sources, so I had to re-write it); that way I can either use it on my Windoze box - under Ersatz-11 - or on real PDP-11 hardware, going from one machine to another. Noel
Re: Repurposed Art (ahem...)
> From: Ed Groenenberg > Re-purposed art or vandalism? Given that the keyboard was at one point there (in the images), but has now apparently been sold separate, clearly the latter... Noel
Re: iMac ethernet connection quit - help?
> From: Mark Tapley > Next stop, I'll pull the cover off the machine and see whether I can > spot any spilled battery electrolyte from the old battery or anything > else suspicious looking on the logic board in that area It probably wouldn't hurt to clean that area with a Q-tip dipped in distilled water. (If you get noticeable grup on the Q-tip, repeat with a new Q-tip, otherwise you'll just be spreading the ook around.) Noel
Re: Repurposed Art (ahem...)
> From: Liam Proven > I confess to much trepidation at the hate for keyboard collectors, as I > am one. > ... > We're not _all_ evil, you know. Unfortunately, the percentage who _are_ willing to chop up original machines, leaving them non-functional (as in this case), is sufficiently high that the field's reputation is mud among many in the wider collector community. Whether this eventually exerts any influence on the field is an open question. My guess, sadly, is 'no': the world doesn't work that way any more. Noel
Re: In search of DEC DZ11 cabling/panel
> From: Fritz Mueller > I'm in need of cabling and a distribution panel for a DEC DZ11 serial > mux Here ya go: http://www.ebay.com/itm/321225351590 They'd probably take $30 each... The DZ11 originally shipped with the H317-E 16-port EIA Distribution Panel (which supported two separate DZ11 cards), but DEC later came out with the 8-port H3006; the former went into a 19" rack, the latter is for the later DEC EMI-limiting packaging, with the standard panel cutouts. The specified BC05W cables are standard 50-pin Berg/DuPont .100" connectors, but with a ground shield. You can probably get away with a standard 50 connector flat cable. Noel
Re: RK05 head alignment -- how difficult?
> From: Fritz Mueller > the heads are accumulating dust and oxide in places that are hard see > and get to Sorry, I don't follow this - where are you thinking of? > I'm looking for some advice/calibration from the community here. Hmm, we had to do this once BITD (we had a bad head crash, and had to replace the heads - I've still got the platter, used to have the heads somewhere), and my vague memory (it was ~35 years ago) is that it wasn't hard. But we had an alignment disk (which has specific non-standard patterns recorded on it, to make it easy to do the alignment - blocks of signals written at slight positive and negative offsets to the nominal track path, so one just moves the head until the two blocks have the same amplitude on a 'scope - the RK05 Maint Manual gives good pictures which show the process). How one would do the alignment without such a pack is not clear to me. I suppose one could use an existing pack,and adjust the alignment to produce the maximum signal output, and then hope the pack one is working with was written on a reasonably-well aligned drive... > From: Al Kossow > Sadly, Texsleeves are no longer made, they are the best. Yes, I'm bummed about that. What's the recommended replacement? Noel
Re: Computer History wiki accounts (Was: VAX expert 'needed')
So, back in December I put out a call for help on CH Wiki content: > looking at the list of 'wanted pages' on the Computer History' wiki: >http://gunkies.org/wiki/Special:WantedPages > the top page or so of entries are all about various Vaxen. > Is there a volunteer our there to sign up as an editor there .. > ... to start writing up VAX content? but although several people were interested, we had issues with Tore being not up to dealing with account creation. This has now been cleared; Tore has put up accounts for all the requests he could find, and he's also made me an 'admin' on the wiki, so I can create accounts. So if you would like to add/edit content there, please let me know, and I can create an account for you. (Send me the desired account name.) I'm also available for any other admin-type activities (e.g. merging duplicate articles). So, let's get rolling on more content! I've been hard at work on PDP-11 stuff, and that's in much better shape, but since that's all I'm into, everything else is in sad need! :-) I'd really like to see the Computer History wiki become a central repository for classic computer info. Right now, there are a lot of pages scattered all over the Web on various topics (I just found out about a PDP-6 one), but it's not organized, easy to find, etc, etc. I hope the CH wiki can become the first stop for all this information. Noel
Re: RK05 head alignment -- how difficult?
> From: Fritz Mueller > Perhaps it is time to find/train a younger apprentice :-) 'Yes, my master!' :-) > If anybody has a decent picture of a clean/fresh RK05 head, I would > appreciate seeing it Here ya go: http://gunkies.org/wiki/File:RK05Head.jpg That head (NOS) came out of a sealed plastic bag, so it should be in perfect condition. > in particular, what should the "wings" near the record/erase gap look > like when clean and intact? Not sure exactly what you're discussing here, but I took this image: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/jpg/RK05HeadRefl.jpg using reflected light; is that crucifix-shaped area of low reflection the thing you're speaking of? It's only visible in reflected light, not direct light; I'm not sure what it is, perhaps crystals oriented in a different direction from the rest of the head? > It doesn't look like anything you'd want to try and fly a head over. :-) > If there are reputable resources for fresh media that folks know about > I'd like to hear about that too! Given that there is no use for these things now, I would guess that there are no news ones, and the only hope would be NOS stuff - and I'd bet those are incredibly rare. Noel
Re: RK05 head alignment -- how difficult?
> is that crucifix-shaped area of low reflection the thing you're speaking > of? It's only visible in reflected light, not direct light; I'm not sure > what it is, perhaps crystals oriented in a different direction from the > rest of the head? Now that I look again, you can see it in the other photo (although it doesn't stand out the way it does in the reflected light one). As to what it is, my _guess_ is that the overall (ceramic part) of the head was made (probably a high-termperatur process) with a hole it, the magnetic head part is then inserted, and some sort of 'potting' sealant poured around it (perhaps epoxy?), after which the whole works is polished smooth (on the 'flying' surface). (And yes, the asymmetry of the little white blob - larger on one side than the other - is there in the actual head.) Noel
Computer History wiki - images needed!
So for those who aren't up to writing text, if images are 'your thing', we could definitely use you! E.g I have added a large number of PDP-11-related pages, but I'm mostly too lazy to do images, and there are dozens of pages which need them. Again, if you'd like an account, let me know, and I can set it up. Thanks! Noel
Honeywall mainframe CPU front panel ID?
So, I've been collecting images of 'Multics' 'front' panels from around the Internet, intending to do a gallery. (I should explain that, in common with mainframes of that era, a Multics system had a variety of different kinds of boxes - CPUs, memories, etc - but also others, intended to support the multi-CPU 'utility' concept. It was possible to take, say, a running 3-CPU system, split off a CPU, bring that up as a separate system, then later bring that down, and add it back to the running system! This was actually done at the MIT site, to allow development work in the evenings on the OS software.) The Multicians site has a nice picture of a Multics system with the some of the panels swung open (they're actually 'diagnostic' panels, so would normally be swung shut): http://www.multicians.org/mulimg/h6180-doors-open-big.jpg The CPU is the one in the center (the panel on the left is an IOM, 'I/O Multiplexor', one of the other kinds of box). So, anyway,I had this large collection of pictures, and asked: Tom Van Vleck, the maintainer of the Multicians Web site what the other (non-CPU) panels on offer might be, and his reaction was (roughly) 'some of the CPU panels there might not be Multics CPU panels'. (Honeywell had an entire line, the https://en.wikipedia.org/wiki/Honeywell_6000_series but most models in that line ran an OS called GECOS (later GCOS), not Multics. So possibly those CPU 'front' panels are from some other 6000 series CPU.) His reasoning was that they don't have the Appending Unit sections: to explain this, Multics used an extra box (the Appending Unit), inserted between the CPU and the memory, to implement the paging and segmentation of Multics, and most 6000-series CPUs did not have this. If you look at this image of what is probably the Multics CPU panel now at the LCM: http://ana-3.lcs.mit.edu/~jnc/tech/multics/jpg/_1020903.jpg it has an Appending Unit section at the top. (BTW, are there any pictures online of LCM panel? All I could find was the video, which is admittedly ultra-cool.) See the "APU Scroll" section (first full-width section), for the Appending Unit, at the top in this detailed shot: http://ana-3.lcs.mit.edu/~jnc/tech/multics/jpg/_1020899.jpg It's not an extra panel: the CPU panel on a Multics machine, although the same overall size, has a different configuration, with the APU sections. However, the suspect CPU panels don't have those sections; see an image of one here: http://ana-3.lcs.mit.edu/~jnc/tech/multics/jpg/multics_panel.jpg with detailed images here: http://ana-3.lcs.mit.edu/~jnc/tech/multics/jpg/multics_panel_cu1.jpg http://ana-3.lcs.mit.edu/~jnc/tech/multics/jpg/multics_panel_cu2.jpg http://ana-3.lcs.mit.edu/~jnc/tech/multics/jpg/multics_panel_cu3.jpg Which is not _definitive_ that they aren't from a Multics machine, but it certainly raises a big question mark. So, the question is, 'are they Multics panels, just for some reason without the APU section, or what'? So maybe these are from some other Honeywell Series 6000 CPU? If so, does anyone knows which Honeywell 6000 series machine (it pretty much has to be from one of them) they are from? Noel
Re: Honeywall mainframe CPU front panel ID?
> From: Ed Sharpe > from what I was told, many versions of machines by Big H were used to > run multics over the span of time. Yes, it appears from what I can find that there were basically three different Honeywell machines that ran Multics: - the 6180 - the one the LCM has the panel for - the Series 60 Level 68 - a re-packaging of the 6180, in shorter cabinets, a picture of which may be found in this publication (pg 5): http://archive.computerhistory.org/resources/text/Honeywell/Honeywell.MulticsSystem.1975.102646162.pdf - the DPS-8/M; you can see one of the latter here: http://www.vaxman.de/historic_computers/multics/multics.html > and the transistor 600 machines had a wildly diff. front panel! There's a picture of an artist's impression of the 645 here: http://www.multicians.org/645artist.html Oddly enough, that painting was on the wall right outside my office in Tech Sq! Now _that_ is a mainframe! :-) Noel
Re: Honeywall mainframe CPU front panel ID?
> From: Dave Wade >> All CPU's were upgradable on site to any other model. There wasn't >> really any difference between the models Yes and no, is my impression. I got the impression from my recent reading that the addition of the Appending Unit used to create the Multics segmented memory meant changes throughout the CPU, so that in any line (Multics/GCOS) a CPU could be field upgraded, but one couldn't upgrade from one line to the other. >> Later models also had virtual memory which I think used the MULTICs >> hardware No, I think GCOS had it's own. (The Multics one was complex, a lot more than GCOS needed.) >> so whilst its possible to say a panel is not from a multics box, I >> don't think its possible to say exactly which model it came from, and >> indeed as the CPU was upgradable the same panel could have been on >> multiple models Good point. > Actually looking at this manual:- > http://bitsavers.trailing-edge.com/pdf/honeywell/dps-8/58009853_DPS8_46_70_Reference_Man_Sep82.pdf > these are from the original hardware GE600/6000/L66/DPS300 machines. > The DPS8 had a redesigned panel... Thanks for that pointer! I don't know why I hadn't thought of looking for Honeywell CPU manuals, that should have been obvious!! Anyway,I found several with useful bits, especially this one: http://bitsavers.trailing-edge.com/pdf/honeywell/multics/AM81-04_maintPrcds_Nov86.pdf which does illustrate a number of the panels. From which it's pretty conclusive that these aren't Multics CPU panels (sigh). These two: http://bitsavers.trailing-edge.com/pdf/honeywell/multics/GB61-01B_OperatorsGde_Dec87.pdf http://bitsavers.trailing-edge.com/pdf/honeywell/multics/_58009997-040_MULTICS_Differences_Manual_DPS_8-70M_Aug83.pdf are also interesting in filling in the history. Noel
Re: Honeywall mainframe CPU front panel ID?
> From: Jim Stephens > I have a collection of photographs of some here, including my panel. Yes, I've had a look through all them, thanks for saving them! To say a bit more about what each one is (as best I can work out), let me start with the one labelled "The whole group" (which will allow me to name them all, for talking about the rest of the images). That shows (from left to right) one of these non-Multics 6000 series CPU panels, and then what seem to be 5 IOMs (Input/Output Multiplexors), of three different types. The first, second, and fourth all match. The third is identical to the one shown on the MIT Multics machine, here: http://www.multicians.org/mulimg/h6180-doors-open-big.jpg Alas, there don't seem to be any closeups of this panel, which is a real pity! Oh well. The fifth is similar to the set of three, except that it is missing the 'Configuration' sub-panel in the lower right corner. This is thought to be an IOM since there some closeups of it, which allow the labels to be read, and these seem to indicate that it's an IOM. As to the other three, although there are no closeups, since they match this one, they are thought to be IOMs also. I wish I knew why there were two different kinds of IOM panel, but I'd only be guessing - I haven't seen anything in the manuals so far. For the discussion below, I'll call them IA (the set of three), IB (the short one), and II (the one like the one on the MIT 6180). OK, so here's the rundown on the rest: - The first 6 show the 'short' IOM (type IB) - The next three seem to be the back of a Multics CPU panel - The next is the back of a type IA IOM - A non-Multics 6000 series CPU - The type II IOM - The next two are type IA IOMs - The type IB IOM - The whole group - A Multics CPU panel (this may be the one that went to the LCM?) - Another image of the back of that - The next four are details of the front of the Multics CPU - Then two more images of the back of it - The front of a non-Multics 6000 series CPU - The back of it - Finally, three detail images of the front I _think_ I have them all right - if not, apologies! Noel
Re: Looking for PDP-11/44 / BA11-A rack slides.
> From: Pontus Pihlgren pontus at Update.UU.SE > On Thu, Jul 27, 2017 at 06:06:05PM +0200, Mattis Lind wrote: > I am a bit curious about what the rest of the low cabinet was used > > for. I have an -11/44 which has a BA11-K mounted below the CPU. Noel
Re: Honeywall mainframe CPU front panel ID?
> From: Dave Wade > three generations so transistor (600?), TTL (6000, L66, DPS100/200/300) > and MOS (some of the DPS8) systems had different panels. I've never seen mention of a Multics DPS100/200/300 machine, so maybe they skipped Multics support in that generation? > From: Charles Anthony > I know that the IOMs evolved; starting with the GE era GIOC > (Generalized I/O Controller), IOM, IMU (Information Multiplexor Unit) They can't be IMU's (or anything later, I'm pretty sure); according to the Dec '87 Operator's Guide (GB61-01B), page 2-2, "All switch functions for an IMU are done via a console connected to ... a microprocessor in the IMU." So no big light/switch boards on them... Noel
Re: CPU meter Was: Honeywall mainframe CPU front panel ID?
> From: Charles Anthony > Gah. I saw a picture of one somewhere recently, but I can't remember > where. Are you thinking of this one: http://ana-3.lcs.mit.edu/~jnc/tech/jpg/SysConKAPanel.jpg Meter closeup here: http://ana-3.lcs.mit.edu/~jnc/tech/jpg/SysConMeter.jpg Noel
Re: CPU meter Was: Honeywall mainframe CPU front panel ID?
> From: Chuck Guzis > Nope, this wasn't a minicomputer. You're the first person I've heard call a KA10 a 'minicomputer'! :-) Noel
Re: Honeywall mainframe CPU front panel ID?
> From: Charles Anthony > Configuration+Panel+WHITE: > Hard to read the writing, but I think it is a SCU configuration panel. Good catch! I'm still trying to get confirmation (THVV couldn't help), but I think you may well be right. The picture of the MIT 6180: http://www.multicians.org/mulimg/h6180-doors-open-big.jpg shows one of them (on the left), and since we know we have panels we are certain are 6000-series IOM's, e.g.: http://ana-3.lcs.mit.edu/~jnc/tech/multics/jpg/22.32.14.jpg (which not only says 'IOM' in places, but has the switches the Multics Operator's Manual says an IOM would have). This other panel looks _totally_ different from that, but it's definitely a 6180 panel. So... what else could it be, if not an SCU? > Closer examination of the memory size switches should reveal if it is a > 256K or 4MW model. We'd need a better picture, alas. But if we had one, we could also read all the switch labels, and do the thing above - look for all the switches the Multics Operator's Manual says one would have, to confirm that it's an SCU... > Two Thirds Maintenance panel: > Can't make it out. See my message about those images: http://www.classiccmp.org/pipermail/cctalk/2017-July/036539.html The upper part is identical to the set of three IOMs, except that it is missing the 'Configuration' sub-panel in the lower right corner. Also, there some closeups of it allow the labels to be read, and these seem to indicate that it's an IOM. Why the 'Configuration' sub-panel isn't there, I have no idea. It doesn't look like it's simply been removed (it looks like there's no hole in the panel, there seems to be a blank black plate over the lower part). So maybe this was a cost-reduced version for use in simple configurations (one CPU, one memory, etc)? Noel
Re: Honeywall mainframe CPU front panel ID?
>> From: Charles Anthony >> Configuration+Panel+WHITE: >> Hard to read the writing, but I think it is a SCU configuration panel. > I'm still trying to get confirmation (THVV couldn't help), but I think > you may well be right. It _is_ an SCU; see: http://www.bitsavers.org/pdf/honeywell/multics/AM81-04_maintPrcds_Nov86.pdf page 3-4. Noel
Re: CPU meter Was: Honeywall mainframe CPU front panel ID?
> From: Pontus Pihlgren > I gather it's for a KA10. Yes, the MIT-DM machine.(MIT-AI had an MIT-built - I think - paging box that was mostly program-compatible with the one on MIT-DM, but had an extra bit of physical page number, so supported 4 'mobies' of physical memory instead of 2; I don't know who made MIT-ML's paging box.) > I the maker "system concepts"? Yes; more here about them: https://en.wikipedia.org/wiki/Systems_Concepts (This was one of the first things they built.) Noel
DEC terminal/PDP-8 aficionados needed
So Antonio donated a whole bunch of VAX articles to the Computer History wiki, with the result that many of the top items on the 'Wanted Pages' list: http://gunkies.org/wiki/Special:WantedPages are now DEC terminals, and PDP-8's. I know we have a few aficionados of those around - anyone up for helping to fill them in? As always, email me if you want/need an account, and I'll set it up. Just send me the account name you'd like (lots of people seem to prefer their old timesharing system login names :-), and the email address to associate with the accot. Noel
eBay: RL02 packs, UK
Lot of 6; UK only, I think http://www.ebay.com/itm/253056726492 Noel
Re: Sperry UTS 40 on Ebay - Statesboro, Georgia
> From: Al Kossow > For what it's worth, I've been seeing sellers cancel orders after the > fact a LOT this year. Any guesses as to what's going on? Noel
Re: 2.11BSD on two RL02 drives? Probably not, but...
> From: Guy Sotomayor Jr > Having several different Unibus board designs in various stages .. I can > tell you that producing a *reliable* Unibus board is *not* going to be > cheap. Why not? Just the size, gold-plated fingers, and transceiver chips, or is there more? Noel
Re: 2.11BSD on two RL02 drives? Probably not, but...
> From: Christian Corti > I don't like the idea of CF or SD at all. I'd pretty much prefer PATA > or SATA, because ... Real drives are also much more reliable than flash > drives, I found this interesting/troubling, because Dave Bridgham and I decided to use SD cards, after I initially suggested using IDE drives (That was in part because those where what I had lying around, and because one replaces a disk with a disk, no? - and in part because Brad Parker's RK11 emulator - the page for which appears to no longer be online, sadly - used an IDE drive.) But when Dave suggested using SD cards instead, I was immediately drawn to the idea of using a memory card, because I have suffered greatly over the years with disks failing from head crashes, etc (even IDE drives fail on occasion), and going with non-mechanical storage, which could not (almost by definition) have a mechanical failure attracted me greatly. But are SD cards really that unreliable? If they were, I'd have thought I'd have heard more about it - e.g. friends grousing about having lost things when an SD card failed. But I don't recall ever hearing such a story? (I'm not discussing their very long-term stability, that's different.) Noel
Re: 2.11BSD on two RL02 drives? Probably not, but...
> From: Paul Koning >> do industrial SD cards exist? > If you have a ready-made SD interface, these cards work nicely. If you > need to build one from scratch it gets tricky, because the interface is > fairly high speed serial (packet based) signaling, and the > initialization sequence before you can do any I/O is fairly convoluted. I'm not clear, reading this, if they use the standard SD-interface? If so, yes, it's non-trivial to interface to (as I previously mentioned, Dave and I wound up defining a uengine, and writing a uassembler to produce code for it, after Dave decided trying to do the init with a state machine was too much pain). > It is reasonably well documented in the SD standard, but still, it > takes a while to get all the code working. BTDT. Tell _us_ about it! :-) (Of course, that issue we had with noise, and the wierd latching inputs, made it even more painful...) Noel
Re: 2.11BSD on two RL02 drives? Probably not, but...
> From: Al Kossow > but it looks like they are going EOL Is that just this particular product (individual SD/etc products seem to go out all the time, as new and bigger ones come out), or industrial SD cards in general? I hope not that latter, that would blow a large hole in out strategy! (Although we are going to include RAM disks as well, using the on-board RAM, and suggest people configure their systems to do swapping/paging off the RAM disk, to avoid wasting writes on 'temporary' data - although of course the RAM disk should be faster, too.) Noel
2.11BSD on two RL02 drives? Probably not, but...
> From: Emanuel Stiebler > If I would do it again, it would be USB only with some sd-card slots. Exactly our plan (although the USB is left until after we get the SD running). > USB with 480MHz is fast enough I think our plan was to skip that speed, and go with the next one down, on the grounds that the analog part at that speed would be too tricky for us. > the old 3v3 level, spi-derivative is very simple to implement. The > 4-bit mode takes a little longer I think we're using the SPI at the moment, not the 4-bit (we discussed both, but I _think_ we went with the one-bit to start with), but I could be wrong - Dave will hopefully pipe up if I blew that one. IIRC our reasoning was that the SPI was the very simplest one to do, for an initial implementation; if we later need the speed, and go to the 4-bit, all the init/etc will already be working. (That's the general approach I prefer for prototyping - get the very simplest possible thing working, then add things. That seems to be better, overall; probably because i) the first stage is easier to debug, because you're dealing with the least complicated possible system, and ii) when adding things, you know the rest of the system is functioning, so any problems have to be in the piece you just added.) >> (Of course, that issue we had with noise, and the wierd latching >> inputs, made it even more painful...) > Did you wire-wrap this thing? Yes (for one card out of two - below), but that wasn't the problem. The problem is that we're using two cards (one to plug into the QBUS, and one with the FPGA on it - surprise, surprise, nobody makes an FPGA protyping card that plugs into a QBUS :-), and the two are connected with a cable; it was the cable that was causing the noise (cross-talk - we neglected to put a ground line between each pair of signal lines). Noel
Re: 2.11BSD on two RL02 drives? Probably not, but...
> From: Al Kossow > The issue would be things like the swap partition on a unix disk or > whatever the equivalent is under RSX Which is why, as I mentioned, that we're including the ability to have virtual disks which store their data in RAM, not on permanent storage - their contents won't last throught a power cycle, but for paging/swapping that's fine. Also, on Unix, /tmp, and pipes - both sources of lots of writes that don't need to be saved across power cycles - although the latter will require a tiny system tweak, to move it off the root partition. (It's like a one line change - refer to 'pipedev' instead of 'rootdev' in pipe(). And a tiny system call to set 'pipedev', and a command to call it. I'd rather do it that way, instead of just adding 'pipedev' to c.c, since one doesn't want to switch to the RAM disk until one has 'mkfs'd a file system on it.) > From: Warner Losh > had problems finding out just how fast Q-Bus can go Something like 700 nsec for a cycle (best case), so assuming 16-bit transfers, a max of a little over 20 Mbit/sec. Noel
Re: 2.11BSD on two RL02 drives? Probably not, but...
> From: Emanuel Stiebler >> on the grounds that the analog part at that speed would be too tricky >> for us. > No, it isn't. You _are_ talking to two people who are so clueless about analog that we didn't bother putting ground lines between each pair of signal lines in a cable... ;-) > You use container files in fat16, or simply 1:1 block mapping? Haven't gotten that far yet. Probably the latter. (Implementing FAT in Verilog no, I don't think so! :-) > your approach, but it leads to debugging of issues, you wouldn't have > on real boards ... Yes, but if we tried to go straight to PC boards, we'd almost certainly have had other issues, just different ones! (See above... :-) And this path allowed us to get rolling without having to go through the PC-board fab cycle... (including the complexity of doing boards with gold fingers). > From: Paul Koning > flash storage devices do wear leveling. The fact that you're writing to > the same block number doesn't mean you're actually writing to the same > spot on the physical flash memory. Yeah, but why 'waste' writes on swapping/paging activity, if there's a RAM-disk ready to hand? Noel
Re: 2.11BSD on two RL02 drives? Probably not, but...
> From: David Bridgham dab at froghouse.org > I'm going to have enough fun with trying to implement the USB stack in > the FPGA ISTR discussing putting a PDP-11 into the FPGA (there are Verilog PDP-11's available), so we could write our USB code in C (I'd use the Unix V6 compiler to compile it, of course :-). > From: Phil Blundell > I doubt you really need the hard gold fingers on a prototype board. Good point... > Not that I've ever actually built a Unibus card though so perhaps there > is some complexity or something especially hostile about the sockets > that I'm not realising. Nah, not that I can think of. > From: Emanuel Stiebler > From an old email from Tim Shoppa who tested some QBUS SCSI controllers: > ... > Here are the peak data rates measured I suspect the disk drive itself may be a big factor there. E.g. the PDP-11 Peripherals Handbook lists the RK05 speed as 11 usec/word, so about 1.5 Mbit/second. But I _know_ the UNIBUS is a lot faster than that; to verify that, look at the speed of non-cache PDP-11s (on which most instructions are memory-bandwidth - AKA UNIBUS bandwidth - limited). And even if not, the controller may have been engineered to not use more than a certain %-age of the bus, to avoid blowing the CPU out of the water when it starts running. The 'maximum bus bandwith' is a very tricky concept - how much do you leave for the CPU, how many DMA cycles do you do per bus acquisition, etc, etc. Noel
Re: pdp-8/e restoration.
> From: Ian S. King > Those keys are common across nearly all DEC machines prior to the ones > that started using plastic keys. XX2247 is the code. Someone on eBait is selling replicas for not wholly unreasonable amounts of money: http://www.ebay.com/itm/142118132040 Noel
Re: pdp-8/e restoration.
> From: Philipp Hachtmann
> The DEC stuff was designed quite wrong-insertion resistant.
> ...
> I did it. Once. It leads to impressive fireworks on many boards.
I managed to plug in an M9301 backwards, once. Luckily, most of the other
boards came through OK (I think I lost one chip on the CPU), but on the
M9301, I fried over half a dozen chips.
Just goes to show, they _try_ and make it hard to put them in wrong, but it's
still possible! :-)
Later on, they got smart - they gave up trying to prevent smart fools ('you
can't make anything fool-prof because...') like me from doing it, and instead
made it harmless to do - on the QBUS, many boards can take being plugged in
wrong, with no ill effects. I think I did that at least once, there.
Noel
Re: I want these computers from Myrtlebeach, NC - seller won't ship.
> From: Pete Lancashire > if the seller wont ship, will s/he take them to a pack and ship outfit ? It's even easier than that. I have used PakMail: https://www.pakmail.com/ a fair amount, and have been very pleased with their service and pricing; they generally offer a pick-up service where they pick the item up, pack it, and ship it. (I had them do that for a 6' 19" rack, from Arizona.) Noel
Re: Big format DEC drawings. BA08, BM8/L, PC08, DW08, RF08 etc
> From: Mattis Lind > I have some big format DEC drawings that is much bigger than the > standard 11x17 drawings that most others are. > ... > Since I cannot do this myself I need to go to a professional scanning > service and pay for it. The other option (which is what I did for the KT11-B drawings I have) is to take them to a copy place, which often (usually?) have a machine which can reduce large drawings (usually architectural drawings) to smaller size. I had mine reduced to 11"x17" (A3, I guess that is), which I could i) scan on my A3 scanner, and ii) work with more easily (to write: http://gunkies.org/wiki/KT11-B_Technical_Manual which I didn't quite complete, as I discovered the thing I had was not, in fact, a KT11-B, but rather a RK11-C) without chancing damaging the originals (whose paper is somewhat friable at this point). Noel
Re: RX02 *.DSK convert to PDP11GUI Image format
> From: Jerry Weiss > If there is an option to start at track 1 or skip the first 30 (?) > blocks, that might work. It's worse than that; there is 'logical' and 'physical' block order, and the two are quite different (blocks are scattered arount the disk in order to do rotational optimization). Details here: http://gunkies.org/wiki/RX0x_floppy_drive#Layout Noel
Re: copy of Kildall's "Computer Connections"
> From: Al Kossow > just sold for $1600 Well, it is from a limited edition of 20, it does not appear to be in print other than that, and this page: http://www.computerhistory.org/atchm/in-his-own-words-gary-kildall/ makes it sound like the family are unlikely to release it... Noel
Anyone need an M7389 card (for an LA30)?
Hi, all, just got one of these in a group of stuff, and I have no LA30, and thus no need for it. Anyone out there have an LA30? :-) Noel
eBay: Kickplate for H960
I don't know how common these are, but here's one: http://www.ebay.com/itm/192280586656 Noel
Re: eBay: Kickplate for H960
> Every H960 and H967 should have one. I think They came standard. When new, yes and when was the last time you bought a new H960? :-) Several of the ones I found came without kickplates; I figured others might be in the same boat. Noel
Re: Champaign, IL to Iowa City, Iowa and back trip
> On Aug 19, 2017, at 11:08 AM, Jon Elson wrote: > Currently $676, but I suspect will go higher. _Much_ higher. The TU56 alone is worth several US$K. I'd look for the whole thing to go for _at least_ US$3K. Noel
Re: DECstation 220. Another Impasse
> From: Rob Jarratt
> I have just written a new blog post
> the comparators are not producing valid output, the input signals are
> varying abave and below the reference voltage, but the outputs never
change.
Don't forget that when the output of chip A is wrong, that might be caused by
chip
B which it is driving... ('All digital circuits are made out of analog
components',
and all that...)
Noel
Re: PDP 8e green / lab version rack Ebay
> From: Anders Nelson > This is crazy, how is this auction not at $5k already at least? "Patience, grasshopper"! :-) With these big-budget, rare, items, the real action is always in the last few seconds. I remember a PDP-11/40 that went from, like $2K (don't recall the exact number, too lazy to look it up) to $10K in the last 10 seconds. > those last 15 seconds were a deusey! And who knows how high it might have gone if the seller did not have a feedback rating of 1!! :-) Noel
Re: IEEE publishes "In Search of the Original Fortran Compiler" - Paul McJones
> From: Tim Shoppa > IEEE Annals of the History of Computing just published (in past few > months) Paul McJones article "In Search of the Original Fortran Compiler". Congratulations to Paul and everyone who helped in this magnificant effort. To bad they couldn't find a copy of the original compiler, but they did get a lot of _really_ good stuff. And it seems like the 'Tome' has gone missing, too? Sigh... > You can read the IEEE-published version at > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7974703 > (I don't think you have to be an IEEE member to read this particular one.) You don't. Excellent item, I highly recommend it to everyone. Noel
Re: DEC ll/03 in 22 bit backplane
> From: Douglas Taylor > I think to do it I would need 2 boxes, one with a 16 bit backplane and > the other with a 22 bit backplane. You could do what I did in the box I have for running LSI-11's in: when I upgraded the backplane from Q18 to Q22, I put in a 4-switch DIP pack, and ran the extra address lines through that. So I can switch it back and forth between Q18 and Q22. I think my hack only works for LSI-11/2's (the dual with ones), not for the original LSI-11's (the quad width ones), because obviously those pins are now bussed together in all the lower slots, and so the switches only break the runs between the left-hand and right-hand slots in the top slot. If anyone wants a setup that can run an original LSI-11, you'd have to look at the prints and see if that CPU cards only picks up those signals in the left-hand slot (in which case that hack works); if it uses them on the right (or both) it'd be a bit more complicated. Noel
Re: DEC ll/03 in 22 bit backplane
> From: Jerry Weiss > The processor will probably halt due to non-existent memory address. No, it'll take a NXM trap (through 4); what happens then depends on what the trap handler is set to - if anything. > However, a P entered in ODT will attempt to continue the bootstrap. See above. I wouldn't bet on a 'P' doing anything useful. > If you have and cannot disable the LTC, it may work intermittently, > depending on whether LTC interrupt occurs before he OS bootstrap loads. > Its just a matter of timing. You could set the PS to 340 and the PC to the start of the bootstrap, and do a 'P' to start it running. (Using 'G' to start the bootstrap will clear the PS.) But I guess you've still got the NXM trap to contend with. If the bootstrap doesn't set the trap handler up, you could manually key in the vector (at 4) and a real simple trap handler (e.g. just dismiss, with an RTI), and you also might have to set up the SP. Noel
Re: Computers before Information Theory
> From: Brent Hilpert > I have wondered just how much influence the latent theory that was > around influenced the practical implementors of calculating machinery > ... > My impression is the implementors at the time arrived at stored-program > machines far more out of practical necessity than trying to enact, or > even being much aware of, the theory. I suspect we'll never know for sure, because there may have been subconcious stuff going on that even the people themselves were not aware of. E.g. it's common to hear that 'Babbage had no influence on modern computers'. But... Aiken was well aware of Babbage's work, and it's reasonable to think that he had it in the back of his mind when doing the SSEC. And Aiken and the SSEC were well known to the early computing pioneers, so there's a path from Babbage to modern computers. Similarly for Turing's work - Turing and von Neuman knew each other (their paths crossed on numerous occastions, starting at the IAS in the late 30's, when Turing went there), and there are numerous people who say he was very familiar with Turing's work. > When/what/who was the actual first assembler conceived or produced? A very good question indeed! Does anyone know? I have this bit set that one early computer assigned the opcodes to make sense as single characters; e.g. the ADD instruction would have had opcode 'A' (not in hex, this was before that). Alas, I can't find which one it was - it's not the Pilot ACE; I checked, and that was always programmed direcly in binary (by punching the program onto cards in binary, manually). > However even before the stored-program machines, the Colossus machines > (WWII) were more logic/symbol processors than numerical. Bit of both, really - they did statistical work on streams of characters. > Shannon was consulted during the design of SIGSALY, IIRC Turing was consulted, too - but I think more in a role of checking the work, rather than doing any himself. See "Enigma", pp. 246-248. > That whole era of Nyquist/Shannon looking at the nature of information, > Turing looking at highly abstract theory of symbol manipulation, and > the implementors of calculating machines, that all came together to > produce the modern computing and informatics world can be fascinating. There's an excellent book which covers some of this ground, "Turing's Cathedral", by George Dyson (son of Freeman). Noel
DEC H9xx rack parts needed
Hi, does anyone have any spare "pivot bushings" for the DEC H9xx series cabinets (H950, H960, etc)? (These are the short pieces with a conical top which fit over the hinge pins, at the bottom.) I need at least one to hang a back door which I have. If nobody has any, they'd be easy to machine, so I might look into having a run made by some local machinists. (I do have a lathe, but have little lathe experience, so machining one of those myself is probably out of my range.) If it's someone with a CNC lathe/etc, I could probably get more made for little more than materials cost. If none turn up in response to this, I'll ask on the list about interest before I set off to find a machinist. I could also use some more of the pins (particularly the kind with the hole drilled through them to take a roll pin), if anyone has any of those spare. Thanks! Noel
Re: DEC H9xx rack parts needed
> does anyone have any spare "pivot bushings" for the DEC H9xx series > cabinets (H950, H960, etc)? (These are the short pieces with a conical > top which fit over the hinge pins, at the bottom.) > ... > I could also use some more of the pins (particularly the kind with the > hole drilled through them to take a roll pin) Someone asked for an image of these; here: http://ana-3.lcs.mit.edu/~jnc/tech/jpg/H9xxPinBushing.jpg is one. The pin in the picture is the kind without the hole at one end, but they are otherwise identical. (Ignore the retaining ring on the pin; those are easy to get, my local hardware store has them.) Noel
Re: 40pin Berg connectors, the DEC alphabet, and pin numbering
> From: Charles Dickman > Is pin AA == pin 1 or pin 40 ? > ... > Did DEC have an accepted mapping between the alphabet and numbers? http://gunkies.org/wiki/DEC_asynchronous_serial_line_pinout Noel
Re: HP 9845 complete system on auction in Sweden
On Fri, Sep 22, 2017 at 7:14 AM, Torfinn Ingolfsen wrote: > Unfortunately, I don't have space for such a large system. I hope someone can take this system, to prevent its being scapped! Noel
Re: M8195 SLU died while in use
> From: Aaron Jackson > a PDP-11/73, M8192 CPU, two M8067 RAM, M7195 ... While playing in ODT, > the console completely stopped responding. > ... > The CPU shows 1000, which I believe is fine, and means it's in ODT. The > SLU card has . I've had a Google and I believe this means it can't > communicate with the CPU. > ... > Does anyone have any ideas? It was working and then it wasn't :( Hmm. Well, it's possible something just died. Dead boards are not un-common, I've found, but to have one die while it's being worked with is a bit of bad luck... Alas, I can imagine a zillion failures that could produce this symptom (from EIA driver chip, down to a bus transceiver chip on the CPU). OK, to start with, those LED values. When you say 1000 on the CPU, there's some ambiguity as to which direction you're reading them; so, which LED is on? From above the board (component side up), with the contact fingers at the bottom, the one on the left, or the one on the right? I'm going to assume the one on the right, which does indeed mean the CPU is claiming it's in ODT. While we're on the CPU, is it set to halt on power-up (power up mode 1) or try and start the ROM (power up mode 2)? I always set mine to halt, on the grounds that it's easy to start the ROM. I'm not familiar with the MXV11-B (M7195), and I couldn't turn up a manual online, but likely those LEDs are set by software (I can't imagine how one would turn on a "can't communicate with the CPU" bit in hardware ... unless it's a flop that's set on power-on, and cleared by the first bus cycle to the card)... Anyway, there are two approaches to solving this problem. So, one option (depending on your budget) is to buy spare boards so you can board-swap to localize the problem to one board. I would recommend getting the spare boards anyway since I would recommend always having a spare minimal set of boards (CPU, serial line) etc. Without a 'working' machine - at least to the point of running ODT - it's hard to do much poking into problems without a lot of pain (i.e. hard work with things like a logic analyzer or oscilloscope). Being able to board-swap to at least localize the problem to one board is a big help. So, start with another serial card (QBUS serial cards are pretty easy to find on eBay, and not too expensive), and swap out the MXV11-B, and hope the serial card you bought works. There are a ton of boards that can do this - M7940, M8017, M8028, M8043 (the first 3 single line, the last is a quad, but uses the same connector as the MXV11-B, unlike the first 3). (If that option is out, I can lend you a known working serial card.) If it's not the serial card, the next thing to buy is a spare CPU; -11/23's are not too expensive, you don't need a /73 to debug hardware issues. The other approach is to debug the hardware. You mention an oscilloscope; do you also have a logic analyzer? Some things (e.g. checking that when you type a character, the serial interface presents it to the CPU) are going to be hard with only an oscilloscope - although I suppose one could program one's computer to send a constant stream of characters (probably DEL) to the -11. I couldn't find a set of MXV11-B prints online - does anyone know of a set? Without that, if the problem is in the MXV11-B, finding it's going to be painful. Anyway, you could check on the QBUS to make sure the processor is actually cycling, trying to read the console input status register, waiting for the 'input character ready' bit to go on. So look at BSYNC and BRPLY, to see if they are hopping up and down. Oh, I guess there's a third option: send the CPU and MXV11-B to someone who has a working system, so they can board-swap and check them out. (I've done this for people...) Bottom line, though: if the fault is in the MXV11-B, unless we can find some prints for it, you're probably stuck with buying at least a replacement console serial card. Noel
Re: M8195 SLU died while in use
> one option ... is to buy spare boards so you can board-swap to localize > the problem to one board. > ... > start with another serial card Also, if you get a working serial card to use for a console, and you get a working system as a result, you can then use that ensenble to try and debug the MXV11-B (you'd have to reconfig its serial line to not be the console). You can then try all sorts of debugging steps, e.g. try doing deposits/reads of serial line registers on the MXV11-B to see if you can send/receive characters - and it that doesn't work, you can then try 'toggling' in a simple program to send characters in a stream, so you can look at the inputs/outputs of the EIA chips (those should be findable, even without prints) with a 'scope, to see if they are busted. Etc, etc. Noel
Re: M7195 SLU issue might actually be 12v rail
> From: Aaron Jackson > This is an 11/23+ chassis and the power supply seems very large, but > reasonably easy to trace. I thought I'd ask first if anyone has any > tips on how to debug this Err, exactly which power supply is this - an H786, or an H7861? If so, there are prints available for both (look for BA11-N and BA11-S), so no tracing needed. DEC also has excellent 'Technical Manuals' for both, which clearly explain how the circuitry works (although alas, the BA11-N Tech Manual is not [yet] online - I have a fiche copy, though). Noel
Re: M7195 SLU issue might actually be 12v rail
> DEC also has excellent 'Technical Manuals' for both, which clearly > explain how the circuitry works (although alas, the BA11-N Tech Manual > is not [yet] online Argh, my memory is failing me. The BA11-S technical info is in the "PDP-11/23B Mounting Box Technical Manual", EK-23BMB-TM-001 - which is also not online, and also available as fiche. I have found someone who has the BA11-N TM, and is apparently willing to scan things, so maybe we can get that one. Noel
Re: Manx?
> From: Rob Jarratt > I have just tried accessing Manx at manx-docs.org, but it seems to have > disappeared. Anyone know what has happened to it? It moved. Now at: https://vt100.net/manx/ Noel
Re: TU58 Serial port address
> From: systems_glitch > get a DLV11 and set it up as SLU0 for TU58 I think you meant SLU1, no? That's the standard for the TU58 (SLU0 is the console). Noel
Re: TU58 Serial port address
> From: Rod Smallwood > I do not know the correct addresses or vectors I need so I can't set > them. > ... > State like this for each and every jumper required Sorry, too busy to type all that out. Jumper it for 776500/300. Noel
Re: Aaron Nabil & pdp-8.org
> From: Vincent Slyngstad > Aaron's website seems to be working for me Anyone who still has access to it should down-load the entire thing promptly. Noel
Re: What's the matter with kids today (Was: The origin of the phrases
> From: Jack Harper > I HATE and LOATHE bloatware - e.g., so much MicroSoft stuff. Some of us consider contemporary Linux/etc bloatware. Noel
Re: Aaron Nabil & pdp-8.org
> From: Tomasz Rolak >> Anyone who still has access to it should down-load the entire thing promptly. > I am > wget -r -np -nc -U lynx -w 2 -l 0 http://pdp-8.org/ > right now. Did you get it all? Anyone else download it? Noel
Hallicrafters S-85
So I have a Hallicrafters S-85 receiver which was my wife's father's, and just arrived (he passed away, and they are cleaning out his basement): http://ana-3.lcs.mit.edu/~jnc/jpg/tech/HallicraftersF.jpg http://ana-3.lcs.mit.edu/~jnc/jpg/tech/HallicraftersB.jpg I'm not into radios at all, so I'd like to get it to a nice home, but I'm not connected to the antique/tube radio world, but I know some people here are, so I'll post this here; if someone can tell me where to post it (or is willing to do so for me), or if anyone here wants it, that would be great. (Replies to me only, please, unless they would be of general interest to the list.) Noel
Re: Hallicrafters S-85
> From: sandy hamlet > There are a couple of ham radio sites that you could post on. > ... > You probably don't want to ship the SX101 as it it is quite heavy. I don't think he wants to get rid of his, he was enquiring about getting one more (from me). :-) The unit has been spoken for, BTW. Noel
Re: Which Dec Emulation is the MOST useful and Versatile?
> From: Kip Koon > f I were to have to decide on just one model DEC PDP system to run in a > DEC Emulator, which one would be the most useful, versatile and has the > most software available for it? To echo what others have said, when you say 'emulator', do you mean hardware (the usual meaning of emulator), or software (which would be a simulator)? And if you mean hardware, are you going to emulate the bus as well? Having said that, I think you should ask yourself 'what do you want to do with it'? The thing is there are a lot of DEC machines which are 'interesting', and have a lot of software available for them: the -8, -10, 11, -15 and VAX (dunno if you consider that a 'PDP') are all in that category. > I hear a lot about the PDP-11. I found out that there were 16 major PDP > models at one time so I'm not too sure which one to pick. They aren't really that different; many of them are more 'the optimal technology to implement in' changed over the (fairly) long life of the architecture, so many of models are where an earlier one was replaced by a more cost-effective equivalent. E.g. for one 'class', the /20 (TTL SSI) was followed by the /05 (microcoded TTL SSI), and then the /04 (TTL MSI), and then the /03 (LSI); in another the /40 was followed by the /34 and then the /23. Etc. There are really only 3 kinds of -11: - Those without memory management (the /20, etc) - Those with 'simple' memory management (the /40, etc) - Those with 'complex' memory management (all the others) Simple software will run on all three; more complex (e.g. Unix) only on the latter two. > Back in the day when Bill Gates and company 1st started out > ... a B/W photo of a young Bill Gates bending over the operator at what > looked like a very small computer. Maybe it was just a terminal. I > don't remember. I understand they did software development on a DEC PDP > of some sort. The very earliest version of their BASIC was done on PDP-10's running TOPS-10 - first the one at Harvard, and then some commercial time-sharing system in the Boston area. > I have many projects in the works already so I decided to setup a > software emulation of just one of the DEC PDP models. OK, so it's going to be just running a simulator? > I have heard a lot about the PDP-11 which if the information I read is > correct was 16-bits. in the world... The PDP-11 is the model I hear the > most about. Well, for good reason, I think. It was at one point (1980), the best-selling computer, and really made the minicomputer (yes, I know the -8 was the first successful mini, but their size/computing power range was a lot smaller than the -11, and so it didn't have as widespread a utilization as with the -11). It's also the machine that Unix was developed on, so if you want to play around with the 'classic' early Unixes (e.g. Version 6), you'll be wanting to go with the -11. Finally, it is to me the finest architecture ever, in terms of elegance, and bang/buck - the power they squeezed into a 16-bit instruction is pretty mind-blowing. If you want to see a really elegant design, look at the -11. A lot of later architectures stole a lot of ideas from the -11. If you want to go the -11/V6 route, there are instructions for doing so here: http://gunkies.org/wiki/Running_Unix_v6_in_SIMH http://gunkies.org/wiki/Installing_UNIX_Sixth_Edition_on_Ersatz-11 and I have a very detailed page for doing so with the Ersatz-11 simulator (which is _very_ fast, and easy to work with), with a lot of useful pre-built disks, and tools, here: http://www.chiappa.net/~jnc/tech/V6Unix.html The other one I would point to as 'interesting' is the PDP-10, _especially_ if you run ITS on it. There's a very complete and detailed page here: https://www.cosmic.com/u/mirian/its/itsbuild.html for bringing it up under SIMH. There's also KLH10 as a simulator, which I know a lot of people like for running ITS; instructions here: http://its.victor.se/wiki/setup which has a lot of detail about how to get things running _on_ your ITS once you have it up. Please let us know what you decide... :-) Noel
Re: Which Dec Emulation is the MOST useful and Versatile?
> From: Kip Koon > I was initially thinking of a strictly software only solution Whatever you eventually do in the way of hardware, it might be a good idea to start with this. You can get familiar with whatever OS you decide to go with, and get used to its tools, get to know the instruction set of that machine, etc, etc. So then, if you do do a hardware project, it won't be such a big gulp, and you'll have the knowledge base covering all the above already there to draw on. > which still presents a problem for me and that is which PDP do I teach > myself and set up. Probably the way to answer that is, if you're going to build hardware at some point, a combination of 'what's out there that I can get to talk to', and 'how complicated a beast are we talking about'. For the first, there's a lot of QBUS stuff around, some UNIBUS, and basically zilch on the PDP-10 or PDP-15 front. For the second, most -11's (both QBUS and UNIBUS) are relatively simple and straightforward. Any kind of PDP-10 is pretty complex (depending on if you emulate the original busses, or not). > 3rd, and this is a big factor in the choice of DEC PDP computer to pick > for simulation or emulation and that is the small cash flow and itty > bitty storage space I have available to me. Noted. > The choice so far it seems is the PDP-11/70. If all you're doing is simulation (software), the -11/70 would be fine. It's no more work to set up than one of the other timesharing-capable models; it's only slightly more complicated than say, an -11/45, _from the programmer's point of view_ (there's a UNIBUS map as well as the usual memory mapping hardware), but if you're running an existing OS, that should not affect you. > Remember I still have no idea ... what boards and peripherals > a PDP-11/70 consists of. Hardware-wise, the -11/70 could be a complex project - it depends on exactly how much you try and emulate, a full emulation could be a very complex undertaking indeed. The thing is that while the /70 looks to the programmer a lot like one of the simpler models, the hardware is quite a lot more complicated: there is a cache, a separate memory bus, high-speed I/I controllers with their own special bus to the devices (MASSBUS), etc. It's basically an -11/45 with a bunch of extra stuff glued onto the sides of it to boost the performance; the board count went from 10 (w/o floating point, which adds an extra 4) to a minimum of of 16 (w/o FP), plus 4 for each high-speed I/O controller (up to 4). Now, if all you're doing is emulating the system, _without_ providing any of the busses, no problem; all that complexity is hidden inside the simulator. But once you start emulating real busses (i.e. to be able to plug in real hardware) - whole different kettle of fish. Noel
RK05/BA11 slides
So, you have an RK05 drive, but you're missing the slides to mount it? Your troubles are over (sort of :-). It turns out the slide DEC used was the General Devices 'Chassis Trak' C-230-S-122 (22") - and those are still available (e.g. from Newark). They're somewhat pricey - the -124 (24") is slightly cheaper, and can easily be modified to fit an H960, viz: http://ana-3.lcs.mit.edu/~jnc/tech/jpg/24InchSlide.jpg The one in the image actually came off an -11/05 in a 10-1/2" box; the 3-3/8" outer slide pair from the RK05 slides does in fact fit the inner slides (i.e. the part permanently fixed to the box) used on a lot of BA11 boxes. One hitch: the location of the safety latches (the 'buttons' on the inner slides that pop out through holes in the intermediate slides) is different on most of the BA11-K inners (on the three BA11-F's I've looked at, they do match), and so the latches don't work. (Unless of course you make the correct hole in the intermediates, or drill new holes in the inners that come with the slide set, to match the mounting holes on the BA11-K, and use them instead.) So, better than nothing, if you have BA11's (or similar) and don't have the outer slides, to mount them. Noel
Image de-warping tool, and Multics/GCOS panels
Hey all, I've been doing research on Multics front panels, which it turns out are slightly different from those on the Honeywell 6000 series machines which ran GCOS, and are often confused with them. So, I've put together a Web page about them: Multics and Related 6000 Series Front Panels http://ana-3.lcs.mit.edu/~jnc/tech/multics/MulticsPanels.html and I've taken some new images, so make sure the captions are all readable. I'm having an issue with the images, though: taking a picture of a flat, rectangular panel with a camera usually produces distortion (even with the lens set to the narrowest angle possible). Does anyone know of any freeware which will fix this? The image tool I normally use (ImagePals, sort of a poor man's Photoshop) does have a 'warp' function, but it requires setting up a grid of points, and is a pain to use: optimal would be something where you mark the 4 corners, and few intermediate edge points, and the image is automagically fixed. I did find this: http://guides.library.illinois.edu/c.php?g=347882&p=2345440 but it's even hairier than the warp function in my image tool; it's very powerful (and thus complex, sigh) and can straigten out badly warped old book pages. I'm hoping there's a simpler tool, for the simple case of distortion of rectangles by a lens - does anyone know of anything? Thanks! Noel
RE: RK05/BA11 slides
> From: "Rob Jarratt" > Thanks for this info Noel. Sure; I figured it would be useful to someone, glad to know it was. > So it sounds like I would need the C-230-S-124. ... My metalworking > abilities are limited. If you don't want to have to do any mods, the C-230-S-122 is a straight bolt-in, albeit $30 or so more than the -124, which requires.. > I am not clear from the picture you linked to, what the modification is? Drilling the two holes. Noel
RE: RK05/BA11 slides
> From: "Rob Jarratt" > I misread your email as suggesting that the 124 was more suitable than > the 122 No, it's just cheaper (at the moment), and can be made to work. > My H960 is not very accessible but I attempted to measure it front back > and it may be 25". Do you know where should the length be measured? You don't need to measure anything. The C-230-S-122 is the _exact_ part DEC used originally for mounting RK05's in H960's. Noel
Re: Which Dec Emulation is the MOST useful and Versatile?
> From: Kip Koon > I tend to get emulation and simulation a bit confused. You and me both! I think part of the problem is that there is no generally-agreed-upon definition of the two terms. I like this one a lot, though: https://stackoverflow.com/questions/1584617/simulator-or-emulator-what-is-the-difference Emulation is the process of mimicking the outwardly observable behavior to match an existing target. The internal state of the emulation mechanism does not have to accurately reflect the internal state of the target which it is emulating. Simulation, on the other hand, involves modeling the underlying state of the target. The end result of a good simulation is that the simulation model will emulate the target which it is simulating. Ideally, you should be able to look into the simulation and observe properties that you would also see if you looked into the original target. In practice, there may some shortcuts to the simulation for performance reasons -- that is, some internal aspects of the simulation may actually be an emulation. ... EDIT: Other responses have pointed out that the goal of an emulation is to able to substitute for the object it is emulating. That's an important point. A simulation's focus is more on the modelling of the internal state of the target - and the simulation does not necessarily lead to emulation. ... SPICE, for example, cannot substitue for an actual electronics circuit There's also the question of what's being emulated. Ersatz-11, for example, does a good job of looking like a PDP-11 - for the software. However, it does not like a PDP-11 for the hardware (although John used to sell boards you could plug into a PC, which provided a QBUS, IIRC). So is it a simulator or an emulator? Good question. About the only _generally-agreed_ example of the terminology I can think of are 'in-circuit emulators', which _exactly_ match the behaviour of a given chip. Noel
Anyone know who does 'decmuseum.org', PDP-5 pictures
Does anyone know who does this site: http://decmuseum.org/index.html I looked, and didn't see anything in the site itself, and doing a 'whois' didn't turn up anything useful. The site has some really nice PDP-5 photos which I was wondering if that person could/would put in the public domain, so I can use them for a PDP-5 article I'm working on for Wikipedia and the CHWiki. So I'd like to get in contact with them. Noel
