test-drb

test-drb@ccmp.vtda.org

101090 discussions

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > However, the was one board that went into the CPU box, and then there > was a cable or two out from that to a separate memory box that held the > memory. So the memory cards themself was not in the CPU box Right, that's a product called the Megabox; details I can find online about it are thin, but it seems to include the Extended UNIBUS backplane the memory sits on, and the memory cards. (Google 'ABLE Enable Megabox' and it'll pop up a short Computerworld blurb about it.) > The machines that had more than 256K of memory, and were Unibus based, > and had the memory on the "unibus" actually had a special backplane for > the memory cards, where otherwise unused signals were used to do the > extra addressing bits. Standard Extended UNIBUS (a la 11/24 and 11/44), I think. > Which also means that all the memory cards had to sit in the same > backplane as the CPU. They could not be put in any other Unibus > backplane. Anyway, no, the memory did not have to be in the same backplane as the CPU; see the Megabox, where the memory was in that box. However, a caveat: there is some possibility there was more than one version of the ENABLE, in which case two seemingly contradictory statements about 'the' ENABLE might in fact both be correct. But until that's shown, let's assume there's only one kind... :-) The thing that I think did have to be on (in, actually - see below) the main UNIBUS was the ENABLE card. I think the logical configuration was like this (diagram semi-ripped off from Mike Muuss' email): Processor ---------- ENABLE ------------------------ Term. UNIBUS | | UNIBUS | EUB | | | |_ 11/44 style | memory |_ Devices (both DMA and non-DMA) I think all the devices - well, you could have put non-DMA devices on the section between the CPU and the ENABLE - all DMA devices at least, had to be on the second UNIBUS, because the ENABLE included a UNIBUS map, which was separate from the PARs used for CPU accesses, so I think that's pretty conclusive that the CPU and DMA devices did not share a UNIBUS. > and you'll get a new MMU which implements all the bits in the PAR > registers. .. > So, it also implies that the original MMU have to be removed. No. (And I can show you the code... :-) The original MMU was retained; the ENABLE included only a second set of PARS (full 16-bit wide), which were the ones normally used while the system was running; the PDRs in the CPU continued to be used as the _only_ PDRs in the system. The style of usage was to, using the CPU's PARs, statically map Kernel D space to one quadrant of UNIBUS address space, Kernel I to a second, User D to a third, and User I to the fourth. (You wanted to use Supervisor mode too? Thhhppptttt!) Those mappings would be on the segment between the CPU and ENABLE; once initially set up, those mappings (i.e. CPU PAR contents) were never changed. The PARs on the ENABLE card (which controlled which part of real memory various addresses on the first UNIBUS got mapped to) were the ones the operating system adjusted as the system was running. > And that is where you put the new card in. I don't think so. I'm kind of hazy on exactly how this was all wired up: there are the fingers on the card (which I think _might_ be the EUB used for the memory bus), the UNIBUS edge connector on the ENABLE card, and that over-the-back connector on the ENABLE card. Then there were 4 things that had to be connected up: the CPU UNIBUS, the memory EUB, the device UNIBUS, and an optional cache memory card ... but we have only three connectors. So whether the cache somehow hung off the EUB, or directly from the ENABLE via a custom backplane, or what, I'm not sure. > I don't know anything about the 11/45 extension this way. Like I said, > I only played with an 11/34 that had this. Anything you could do on the /34 could of course also be done on the /45 (since the ENABLE did not involve any mods to the CPU, it just interfaced to the UNIBUS). Although I have this bit set that perhaps it - or, one variant of the ENABLE (see comment above about more than one) - somehow used the fast memory slots in the 11/45 backplane (originally designed for special high-speed solid state memory) and that's how you got full advantage of the cache. (I have this distinct memory of running 'mips' on our /45 after it was upgraded and the result was '3'...) But probably something in my memory is flaky - it was a long time ago. > I probably should try to find the documentation for exact details here > then. I might be able to track down the machine, but I haven't seen it > in almost 20 years. If you could track down the documentation, that would be really good. The programming of the thing we can work out (in addition to my code for V6 Unix, there is code online for other versions of Unix which support it, e.g. BSD2.9). It's the physical installation details which are murky... Noel

11 years, 6 months

strange number corruption on pdp11/34

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > but now that the problem has been isolated and removed, I'm inclined to > just enjoy the pdp11 :) I'd really recommend fixing at least one more board set - otherwise, when the next failure happens, you'll have _no_ working board sets... Noel

11 years, 6 months

VCF East exhibits update

by evan＠snarc.net

We're up to 25 exhibitors for VCF East so far: http://www.vintage.org/2015/east/exhibit.php We'll definitely exceed 30, as we did last year for East 9.1 (33). How high will it go? 35? 37? Will we somehow squeeze in 40, which would be the most of any VCF ever? If you're thinking about exhibiting, then do not wait. Register now while there is space.

11 years, 6 months

thread on tools

by useddec＠gmail.com

I can't seem to find the thread on precision screwdrivers and other tools. I might have mistakenly deleted it. I planned on reviewing it to buy some new tools and now I'm stuck. Can someone please get me in the send me a copy of it? Thanks, Paul

11 years, 6 months

Seeking an ECL monitor (preferably for a dimple-top Sun base) and Sun 3 Keyboard and Mouse

by ian.finder＠gmail.com

> Trying to get my 3/50 restored... If anyone has these available I would like to purchase them from you. > > Understand it might be a long shot. > > I'm in Seattle, WA > > Thanks, > > - Ian > > -- > Ian Finder > (206) 395-MIPS > ian.finder at gmail.com

11 years, 6 months

new-old-tech news

by hilpert＠cs.ubc.ca

Not my thing really, but of interest to some here I expect (pardon if I missed it and it's already been mentioned on the list): "Remodelled ZX Spectrum production set to begin" http://www.bbc.com/news/uk-england-nottinghamshire-30810148 Also, not especially computers, but: "Why can't we let go of our old tech?" http://www.bbc.com/news/technology-30879638

11 years, 6 months

UNIBUS PDP-11 memory expander card

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto > I just happen to have one in my hand as we speak. I'll photograph it... Hmm. That photo (here: http://ana-3.lcs.mit.edu/~jnc/jpg/PDP11s/AbleENABLE.jpg if anyone wants to see it) shows a very different card than the one in the brochure. That one's a hex card, with an over-the-back connector: this one's quad, no OTB connector. This looks more like a QNIVERTER? Does it say 'ENABLE' on it anywhere? (Which would imply there was more than one variant... which would be interesting, because I have this bit set that the one we had at MIT was not like the one described here: http://gopher.quux.org:70/Archives/usenet-a-news/FA.unix-wizards/81.07.09_u… because I'm pretty sure that on ours, the DMA devices were on the far side of the ENABLE - which makes sense, because ours had separate PARs and UNIBUS map registers, which make no sense in that configuration - unless Mike [blessings, wherever you are] made a mistake in drawing that up.) Noel

11 years, 6 months

strange number corruption on pdp11/34

by jnc＠mercury.lcs.mit.edu

> From: John Wilson > The *ability* to accept the FPP (and/or cache -- M8268 I think?) Yup, M8268. > And you need the right over-the-top connector (hazy memory says H882 or > H8822 for either or both option but I may have made those up). There are two: if one has only an FPP (M8268) _or_ a cache (M8268) one needs a single OTB connector, H8821 (they both go in the same slot, if one has only one of the two). If one has _both_ the FPP _and_ cache, one needs a double OTB connector, H8822. > Better to reduce the variables and leave the FPP off for now. Indeed! > From: Jacob Ritorto > I ended up ... mix-and-matching 8265 and 8266 boards from the old and > new sets to make a system that doesn't bus error and doesn't print > weird zeroes. Let me make sure I get this. You have two M8265's, A and B, and two M8266's, C and D. You're saying that _only_ the combination AC works; that AD, BC and BD all fail? In other words, only A and C work, and both B and D are bad? > thank you all again for the insights and interest! Hey, that's what we're here for! > If anyone is really interested in debugging these "bus error / > zero-inducing" cpu boards to find out what on earth was causing the > problem, I'd be happy to loan them out. Nah, I've got enough of my own stuff to work on... :-) But if you decide you have no use for dead cards, and want to sell/trade, please let me know! > Heck, I might even try to do what we were talking about initially and > write up some little math tests if you're really curious. Well, I'm mildly curious, but _iff_ you want to repair them, you need to do some of that, to try and figure out what the bug(s) are. (And of course there's that busted M7265/M7266 set, too!) Since you have 3 sets, and only one works, you might want to get a second set working before that set dies on you, too... :-) Noel

11 years, 6 months

strange number corruption on pdp11/34

by jacob.ritorto＠gmail.com

Hi, I'm getting all zeroes nearly any time there's supposed to be a large number output to my terminal. Does this sound familiar to anyone? This happened last night on rsx and is also happening today on xxdp. example xxdp testing rl02: DRSSM-G2 CZRLK-B-0 CZRLK PERFORMS RANDOM OPERATIONS OF GET STATUS, SEEK, READ, AND WRITE UNIT IS RL01,RL02 RSTRT ADR 000000 DR>START CHANGE HW (L) ? Y # UNITS (D) ? 1 UNIT 0 RL11 (L) Y ? Y BUS ADDRESS (O) 0 ? VECTOR (O) 0 ? DRIVE (O) 0 ? DRIVE TYPE = RL01 (L) Y ? N BR LEVEL (O) 0 ? CHANGE SW (L) ? N NXT TST MAY ZERO LD UNIT. DOIT ANYWAY?Y TESTING STARTED CZRLK HRD ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 DR ERR TIME: 00:00:00 RLCS: 000000 DRIVE: 0 DRIVE TYPE = RL00 >> FUNCTION: WRITE BEFORE ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 AT ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 DR ERR ADDR = CYL: 000. SUR: 0 SECT: 00. STATUS WAS: 000000 LST POS: 000000 DR ERR - RECOVERED CZRLK HRD ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 DR ERR TIME: 00:00:00 RLCS: 000000 DRIVE: 0 DRIVE TYPE = RL00 >> FUNCTION: WRITE BEFORE ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 AT ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 DR ERR ADDR = CYL: 000. SUR: 0 SECT: 00. STATUS WAS: 000000 LST POS: 000000 DR ERR - RECOVERED CZRLK HRD ERR 00000 ON UNIT 00 TST 000 SUB 000 PC: 000000 GARBLED DATA - CAN'T CHECK IT TIME: 00:00:00 RLCS: 000000 DRIVE: 0 DRIVE TYPE = RL00 >> FUNCTION: READ BEFORE ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 AT ERR (RLCS): 000000 (RLBA): 000000 (RLDA): 000000 (RLMP): 000000 DR ERR ADDR = CYL: 000. SUR: 0 SECT: 00. XFER SIZE = 00000. WORDS 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000 000000

11 years, 6 months

new-old-tech news

by kspt.tor＠gmail.com

On 28 January 2015 at 13:05, Brent Hilpert <hilpert at cs.ubc.ca> wrote: > Not my thing really, but of interest to some here I expect (pardon if I missed it and it's already been mentioned on the list): > "Remodelled ZX Spectrum production set to begin" > http://www.bbc.com/news/uk-england-nottinghamshire-30810148 It'll be interesting to see if that works at all. > Also, not especially computers, but: > "Why can't we let go of our old tech?" > http://www.bbc.com/news/technology-30879638 Aah, old arcade games.. and pinball machines. There's something about that mechanical/physical aspect I think. The point in time when I lost interest in pinball machines was when they changed the number displays >from mechanical to electronical. Suddenly the pinball machines lost their appeal for me. Some important part of the experience was gone. -Tor

11 years, 6 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb