TUHS

tuhs@tuhs.org

47 participants
6502 discussions

by mirian＠cosmic.com

I've managed to boot the latest 4.3-Quasijarus0a on Bob Supnik's SIMH VAX emulator. SIMH emulates a MicroVAX 3000, which is one of the currently supported configurations in 4.3-Quasijarus. The way I did it was: First I installed NetBSD 1.5.2/vax on the VAX emulator. I used this to label and newfs the root/usr diskimage for 4.3-Q (it is important to use the -O option to newfs so that NetBSD will create a 4.3-style filesystem. (In all cases, I used RA90 disk images, which are nice and spacious and which both netbsd and 4.3-Q seem to work well with.) Then I restored the root and usr filesystems from the 4.3-Q distribution onto these diskimages, and used the /usr/mdec/installboot command in NetBSD to install the bootblock onto the root diskimage. I created an fstab for it, and also commented out everything in rc* having to do with the network (there's no network device support in SIMH VAX yet). I also commented out all gettys listed in /etc/ttys except for console. Speaking of console, it's important to use something which is as close to a VT-100 as possible. I've been using rxvt, which is pretty good. It seems to be important to disable the RL controller ("set rl disabled" in SIMH) when booting the GENERIC kernel. Otherwise, you get a page fault and panic on boot. (I haven't tracked the cause of this down yet). The GENERIC kernel also expects there to be images on ra0, ra1 and ra2 (which are rq0, rq1 and rq1 in SIMH, respectively). I can get the system to come up in multiuser mode, and I can log in as root. Unfortunately, though, after a few seconds, the system locks up with uda0: lost interrupt uba0: reset uda0 uda0: DMA burst size set to 4 ra0: uda0, unit 0, size = 2376153 sectors Typing ^E to get to the SIMH prompt, and single-stepping the emulator shows it is stuck in the idle loop. At this point, nothing short of shutting down SIMH has any effect. Any thoughts on what might be going wrong? The complete log is included below: --Mirian KA655-B V5.3, VMB 2.7 Performing normal system tests. 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25.. 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09.. 08..07..06..05..04..03.. Tests completed. >>>boot dua0: (BOOT/R5:0 DUA0) 2.. -DUA0 1..0.. loading boot Boot : /vmunix 327204+103384+130352 start 0x23a8 4.3 BSD Quasijarus UNIX #0: Sat Oct 2 22:15:38 CDT 1999 msokolov@luthien:/usr/src/sys/GENERIC real mem = 67076096 SYSPTSIZE limits number of buffers to 18 avail mem = 65240064 using 18 buffers containing 147456 bytes of memory MicroVAX 3000, ucode rev 6 uda0 at uba0 csr 172150 vec 774, ipl 15 uda0: version 3 model 3 uda0: DMA burst size set to 4 ra0 at uda0 slave 0: mydisk, size = 2376153 sectors ra1 at uda0 slave 1: no disk label: ra90, size = 2376153 sectors ra2 at uda0 slave 2: no disk label: ra90, size = 2376153 sectors ra3 at uda0 slave 3: floppy dz0 at uba0 csr 160100 didn't interrupt dz1 at uba0 csr 160110 didn't interrupt dz2 at uba0 csr 160120 didn't interrupt dz3 at uba0 csr 160130 didn't interrupt Changing root device to ra0a WARNING: todr too small -- CHECK AND RESET THE DATE! Automatic reboot in progress... Sun Aug 19 18:07:26 CDT 2001 /dev/ra0a: 429 files, 5504 used, 26548 free (52 frags, 3312 blocks, 0.0% fragmentation) /dev/rra0d: 2588 files, 21064 used, 968769 free (785 frags, 120998 blocks, 0..0% fragmentation) Sun Aug 19 18:07:58 CDT 2001 checking quotas: done. starting system logger preserving editor files clearing /tmp standard daemons: update cron. starting local daemons:. Sun Aug 19 18:08:01 CDT 2001 4.3 BSD UNIX (kryluk) (console) login: root Last login: Sun Aug 19 17:52:53 on console 4.3 BSD Quasijarus UNIX #0: Sat Oct 2 22:15:38 CDT 1999 Welcome to UNIX! erase ^?, kill ^U, intr ^C # uda0: lost interrupt uba0: reset uda0 uda0: DMA burst size set to 4 ra0: uda0, unit 0, size = 2376153 sectors

23 years, 3 months

Re: [TUHS] Re: Porting Unix v6 to i386

by P.A.Osborne

> >http://hp.openwatcom.org/ftp/zips/ for the binaries > >http://hp.openwatcom.org/ftp/docs/ for PDFs of the documentation > > Cool! Thanks. > Still, no source code => not much use for porting Unix, unless you > want to be limited to cross-compiling from DOS. (Making the Watcom > binaries run under v6 Unix seems very unlikely since they probably > use fancy 32-bit extenders that know all sorts of esoterica about > DOS memory management...) The reason I want the compiler is that it will generate standalone 16 bit code on a sensible platform. GCC doesnt produce 16 bit code as far as I am aware - so personally I thought it would be amusing (I must be mad) to use tools that run under DOS (well OS/2). > Someone else on the mailing list suggested using old versions of > Tanenbaum's Minix, which has a different set of compilers; again > the problem is, no compiler source code last time I looked at Minix. > > So far the only viable compiler suggestion seems to be the one > from Warner Losh who recommended bcc. (Or, port the PDP-11 compiler > yourself.) I think we are looking at this from different ends, let me try and explain: Initially we need to be able to compile the kernel/system so it runs, I feel that updating the code to ANSI C and using a modern compiler will do the job for that. Eventually it would be nice to be able to get v6-i86 (or whatever we call it) to boot itself and then be able to compile itself - at that point it becomes a complete project. It is however essentially two projects: 1. rewriting the OS so it boots as i86 2. (re)writing a compiler that will run native and be able to compile the OS on its own platform The second part is not essential by any means, but it could by the purists be considered the ultimate goal. Paul

23 years, 3 months

Re: [TUHS] So now that the source is finally out...

by John Holden

> > I'm fairly sure things like "=+" and so on were replaced with "+=" > > in the move from V6 to V7. > > I thought so too, but I checked, and there are some still in there. I think you'll find that the kernel code is clean, but a lot of the older utilities will show their earlier lineage (including the C compiler)

23 years, 3 months

Re: [TUHS] So now that the source is finally out...

by Ken Wellsch

> On Fri, Jan 25, 2002 at 03:27:25AM -0700, M. Warner Losh wrote: > > gcc can compile K&R, but the language has evolved some since the v7 > days. =*, =+, etc became *=, +=, etc. There are some other subtle > things too that I don't recall off the top of my head, but which vexed > the comp.lang.c news groups in the early 1980's. I'm fairly sure things like "=+" and so on were replaced with "+=" in the move from V6 to V7. I think structure assignments were added here too, and the much more obscure, being able to declare passed arguments in the function preamble as "register." I believe K&R reflects the C language as seen with V7... -- Ken

23 years, 3 months

RE: [TUHS] Re: Porting Unix v6 to i386

by Grant Maizels

Actually I have 8086 C compilers on my old Altos systems (486 and 586) running Xenix. The OS on the 486 is a very early version of Xenix which is really a slightly modified version of v7. If the machine still works (has not been turned on for a few years), I may be able to set it up so that it can be accessed through a terminal server off the internet so that it can be used to do compiles. I think that Microsoft may own the copyrights on these old compilers (not sure), but it would be nice if the source was publicy available (or even binaries). If the machine still works (has not been turned on for a few years), I may be able to set it up so that it can be accessed through a terminal server off the internet so that it can be used to do compiles. The 486 with v7 has an 8086, 512k memory, 12Meg hard disk. With the full V7 OS, including c (lex, yacc, ...) , troff, and some Microsoft add-ons (fortran, cobol, mutimate??) fits in 7 Meg. Grant Maizles P.S. The 486 and 586 names refer to the number of supported users which the machine can handle and the fact that it has a 8086 CPU. The configs were 486 5 Serial ports (1 for a printer) 586 6 Serial ports I had a customer with a 986 which had 10 serial ports. > -----Original Message----- > From: M. Warner Losh [mailto:imp@village.org] > Sent: Thursday, January 31, 2002 7:54 AM > To: mike(a)ducky.net > Cc: tuhs(a)minnie.tuhs.org > Subject: Re: [TUHS] Re: Porting Unix v6 to i386 > > > In message: <200201301952.g0UJq0E39966(a)ducky.net> > Mike Haertel <mike(a)ducky.net> writes: > : >Anyhow I have started gathering the tools (Watcom C compiler now > : >open source and free! www.openwatcom.org) > : > : They have announced that it *will be* open source and free, > : but so far as far as I can tell there is nothing available > : at openwatcom.org except a binary-only patch to upgrade > : the last commercial version 11 to 11.0c. > : > : So, it isn't yet. Right now it's just vaporware. > > The only compiler I know of that deals properly with generating 16-bit > x86 code is bcc, which the Elks folks use to build their kernel. This > is Bruce Evan's compiler with support for prototypes bolted on, iirc. > > http://www.cix.co.uk/~mayday/ > > It is a tad Linux centric, but I was able to get it to build with only > a few tweaks on FreeBSD. It is sufficient to build the elks tree, but > I've not tried it on anything else. > > Warner > _______________________________________________ > TUHS mailing list > TUHS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/tuhs >

23 years, 3 months

Re: [TUHS] Re: Porting Unix v6 to i386

by John Holden

I think that v7 would be far easier to port than v6. Although it's not much bigger than v6, the code is a lot cleaner, and there are less machine dependencies. One of the reasons for a lot of the changes between v6 and v7 was a conscious effort to make it more portable . The old assignment operators like '=+' changed to "+=". 'Unsigned' and 'long' data types are missing from v6 (and reflected in the kernel), so all integer calculations were 16 bits. Unsigned ops were done using 'char *'. v7 was ported to the Vax and the Interdata. ioctl is there, and the 'standard io' library. The file seek call in v6 had either block (512) or byte offsets, and v7 introduced lseek to replace it. Only 16 bits were used to store block numbers in inodes, so filesystem sizes were restricted (not a real problem since both v6 and v7 could run happily on a 2.5Mb RK05 disk, including swap space and c compiler). 'vi' ran under v7, but v6 only offered 'ed' (or variants like 'em') and 'qed' If you hadn't guessed, v7 is by far my favourite Unix variant. Lean, clean and without the latter clutter of supporting networking in the kernel.

23 years, 3 months

Re: [pups] solution for the disklabel

by pete＠dunnington.u-net.com

On Jan 30, 16:03, Johnny Billquist wrote: > On Wed, 30 Jan 2002, Pete Turnbull wrote: > > Maybe it wants a DEL character instead of backspace (backspace *is* ctrl-H, > > shown as ^H or ^h). Change it on the terminal by going into setup, or use > > stty on the BSD system to change the delete character (stty del '^h'). > > On a real VT100 you cannot get the delete key to generate a backspace. He > must be pressing the backspace key, or he's not using a VT100 at all, but > instead some emulator, which isn't doing things the VT100 way... Of course. I've spent too long using my VT420. A real VT102 has separate delete and backspace keys. Probably he's using some not-really-VT102 emulation in an xterm window or some emulator. -- Pete Peter Turnbull Network Manager University of York

23 years, 3 months

[pups] solution for the disklabel

by lothar felten

the pdp is running 2.11BSD ! the disk has now got a valid disklabel, i got it on the disk by setting all diskparameters without using d (display) and wrote it. after this i could use the display option. installation was no problem, but still i have some questions: my VT102 doesn´t do backspace, i only get ^H. i tried the terminal in ANSI and VT52 mode, no difference. i have some dec boards labeled M7513 does anyone know what this is? i found: M7513 - RQD - RQDXE Q BUS drive interface extension module it is a double height card and it has 3 50pin connectors. the RQDX3 has another connector, i suppose for RX50 floppydrive. can i hook up a 5,25" pc drive? maybe with modifications? --lothar

23 years, 3 months

Re: [pups] Problems booting PDP11/40 using vtserver

by John Holden

As I and other people mentioned in previous postings, it's likely that your 11/40 is missing memory management or EIS cpu options. In case the legend is missing from your system box (not uncommon), I have updated my web page :- http://www.psych.usyd.edu.au/pdp-11/11_40.html to show board numbers and locations

23 years, 3 months

Re: [TUHS] So now that the source is finally out...

by Ken Wellsch

On Sun, Jan 27, 2002 at 02:03:40PM -0500, norman(a)nose.cs.utoronto.ca wrote: > > > Ken Wellsch: > > I'm fairly sure things like "=+" and so on were replaced with "+=" > > in the move from V6 to V7. > > The V7 C compiler accepted =+, but it still accepted += as well; there was > a lot of code written the old way, and nobody wanted to be forced to convert > everything all at once. Apologies, typical of my terse replies - I was actually concerned with clearing up the possible misconception that "=+" was a "feature" of V7 rather than an "obsolete" holdover from V6. I suppose historic accuracy in this context is of little use, I don't know. I certainly can believe one can find such artifacts in the existing V7 code 8-) Cheers, -- Ken

23 years, 3 months

Re: [pups] 2.11BSD disklabel-programm

by lothar felten

about the pdp-11/83: swapping cpu and memoryboard does work, but the performance stays the same: none, because i still don´t have any system by now. there is a small difference: the run led stays off all the time, but the system ODT works fine. i suppose this is a problem of passing the signals, but this is only a vague guess. when i boot the TK50 2.11BSD tape, i can get the disklabel program loaded. it asks: Disk? when i try to access the disks, the system hangs. when i access rl(0,0) (RL02 disk drive0) the system just hangs, no response. when i access ra(0,0) (RD54 disk drive0) i get a "menu": d(isplay) D(efault) m(odify) w(rite) q(uit)? i can enter D, then it should write the defaults to the disk. after this i get: d(isplay) D(efault) m(odify) w(rite) q(uit)? i enter d (to see what the program did), and i get: type:MSCP disk:RD54 flags: bytes/sector:512 sectors/track:17 tr (it stops right after tr) i suppose the program is asking the controller about drive parameters, and that´s where it fails. i can wait for hours, i´ll get no response. i can use all the menu, except d=display. i thought that maybe one of the controlles is broken and causes trouble on the qbus (maybe the RL02 controller). is there a way to check all this stuff? i do have some "winchester" controllers for PC/ISA, i could check the disks on a linux pc, no problem, but i don´t want to overwrite something "digital"-specific that i could not restore. those RD54-disks are regular ST506-mfm, right? maybe i should "downsize" the system to the basic elements i need to get it running maybe there really is a bus problem. i´d try this configuration: mem - cpu - rqdx3 - tqk50 (top-bottom) would this be ok? or, instead of using RD54 disks, should i try to use the rl02 as "pair" (one swap, one systemdisk)? i think step by step checking the hardware is the only thing i can do to get the pdp up and running. have a nice weekend -- lothar btw: does anyone know a good book/link about system-architecture, specially harvard- architecture ?

23 years, 3 months

[pups] Problems booting PDP11/40 using vtserver

by Michael Werner

Hi there, I have my PDP11/40 connected to a MicroVAX 2 (running NetBSD/vax 1.5.2) via serial line and want to boot a 2.9BSD or 2.11BSD using the vtserver software. When I toggle in vtserver's boot code, the first file is being loaded correctly by the PDP. Then, following the instructions in vtserver documentation, the serial line should be used as a serial console - and some text should appear! And this is the problem: I don't get any output. When manually sending characters from the PDP, there is no problem. I've set the serial line characteristics to: Speed 2400, Character Size 8, Modem Control enabled, and RTS/CTS flow control disabled. (I've changed these characteristics in many ways with stty, but still no success...) Using a break-out-box, I switched RTS/CTS and DTR/CTS flow control on and off, forced the CTS line to be on, etc., but it still didn't work. After successfully loading the bootloader via vtserver, the PDP's CPU goes into an endless loop. So, my question: Does anybody know what's going wrong here? Thanks in advance - Michi

23 years, 3 months

[pups] PDP 11/04

by P.M.Williams

I'm looking for someone in the UK that may have spares for a PDP- 11-04 (KY11-LA). This computer is still in daily use in the University of Sheffield but currently has some problems with the power regulator (H777) Any help would be greatly appreciated.

23 years, 3 months

Porting Unix v6 to i386

by Sven Dehmlow

Hi, The last few weeks I've thought a lot about porting Unix v6 to the PC. Here are my "results": 1. If you really want to do it, don't do it from scratch. Porting Unix 1:1 maybe the usual way but integrating your code step by step into another Unix or Unix-a-like operating system will surely become much easier as you can test the result in every stage of development. Another benefit is of course that with a little bit of luck you don't have to rewrite all the machine dependent stuff as it might already exist in the other os. If you want to do things this way ELKS (the Linux kernel subset for the 8088) might be a good candidate as it is very simple and by this very easy to understand. Also there is a big Linux/ELKS community which might help you with some problems. 2.Another question is if it is really necessary to port when so many good emulators for the PDP11 exist. Of course a ported Unix is faster than one running on a simulator but is fastness really so important in times where multi-processor machines exist that make your 1.5Ghz machine look like a fool? Also wouldn't a user who needs a professional fast Unix (or a-like) take the newest Linux or one of the BSDs instead of Unix v6? The main reason for porting is from my point of view to get access to the i86's hardware. But for reaching this aim a port isn't necessary. You can either develop the emulated machine further so that it has additional devices (and interupts, etc. for them) or you can try to give the os on the emulated machine direct access to the real machine. This may sound a little bit strange and unusual but will save much code in the emulator as you don't have to code for each device twice (one time in the emulator and one time in the os). Of course the os you're running your emulator on must give you the chance to get direct access to the real hardware, but I found a DOS port from Bob Supniks J-11 emulator so that is not a real problem. Currently I'm working on the latter idea (on the emulator which gives you direct access to the hardware), but in fact I haven't written a line of code yet as I'm still searching for the best way to integrate the interesting parts of PC's memory into PDP11's memory. The idea is to put the interesting parts of PC's memory behind PDP11's memory and to change some lines in Unix that for example malloc doesn't get the idea to give this pieces of memory away to user programs. Putting the PC's memory before the memory space of the PDP11 would as far as I can see make more changes especially in the code relevant for booting necessary. Other things like for example PC's interupts will surely make much less trouble. Suggestions, ideas, opinions, etc. are very welcome. If someone feels the urge to help me with this project it would be very kind if he would let me know ;-) BTW: if someone has patches to the v6 or ported programs it would be very kind if he would send them to me. If I get enough stuff I'll make something like a new Unix v6 distribution. Sven

23 years, 3 months

[pups] Problems booting PDP11/40 using vtserver

by Michael Werner

23 years, 3 months

So now that the source is finally out...

by Rob Becker

who is going to port 7th edition to the i386? (: Rob Becker

23 years, 3 months

Re: [pups] Problems booting PDP11/40 using vtserver

by John Holden

> I have my PDP11/40 connected to a MicroVAX 2 (running NetBSD/vax > 1.5.2) via serial line and want to boot a 2.9BSD or 2.11BSD using the > vtserver software. 2.11BSD won't work on a PDP11/40, although 2.9BSD should. If the secondary boot loaded, you should get a prompt '40Boot' for your processor. You haven't said how much memory you have. Also, the 11/40 has several cpu options, and the memory management and line time clock options are required for Unix to work. Check that there is a register at 772340. If it is not there, then the memory management options isn't installed. PS The only flow control settyings that will work is XON/XOFF. The DL style interfaces used on all PDP11 consoles, have no useful silo, and interupts for each character input or output. None of the kernels I know support the dataset signals, other than some will assert DTR on open.

23 years, 3 months

Re: [TUHS] So now that the source is finally out...

by norman＠nose.cs.utoronto.ca

Ken Wellsch: I'm fairly sure things like "=+" and so on were replaced with "+=" in the move from V6 to V7. I think structure assignments were added here too, and the much more obscure, being able to declare passed arguments in the function preamble as "register." I believe K&R reflects the C language as seen with V7... The V7 C compiler accepted =+, but it still accepted += as well; there was a lot of code written the old way, and nobody wanted to be forced to convert everything all at once. Similarly, the V7 compiler complained about implicit conversions between pointers of different types, or between ints and pointers, but they were treated as warnings, not fatal errors; you could still compile old code and just ignore the compiler's fussing. I recall that when I arrived at Bell Labs in 1984, it was apparently not long after the research group's C compiler had been changed to treat all the obsolete stuff as errors; certainly there was still code in /usr/src that hadn't been updated, and all of it had been recompiled recently to run on the VAX. A modern C compiler would choke even on some of the stuff that was legal in those days. Recently I recompiled tbl with lcc, and had a grand time cleaning out all the ideas we all thought were clever in the late 1970s but most of us would never think of doing now. For those with the virgin source handy, take a look at subroutine `point' and the way it is used and abused. Norman Wilson

23 years, 3 months

Re: [TUHS] So now that the source is finally out...

by Carl Lowenstein

> From: "P.A.Osborne" <P.A.Osborne(a)ukc.ac.uk> > To: "M. Warner Losh" <imp(a)village.org> > Cc: tuhs(a)minnie.tuhs.org > Subject: Re: [TUHS] So now that the source is finally out... > Date: Fri, 25 Jan 2002 11:16:37 +0000 > > On Fri, Jan 25, 2002 at 03:27:25AM -0700, M. Warner Losh wrote: > > Real as in 286 or as in 8088 :-). > > > > gcc can compile K&R, but the language has evolved some since the v7 > > days. =*, =+, etc became *=, +=, etc. There are some other subtle > > things too that I don't recall off the top of my head, but which vexed > > the comp.lang.c news groups in the early 1980's. > > That makes things a challenge. Still the source of the kernel is > around 10K lines IIRC and going through it in stages doesnt make life > too painfull. Doesn't one of the C beautifiers do that for you (rewrite =+ etc.) Either GNU indent or Berkeley? cb. carl -- carl lowenstein marine physical lab u.c. san diego clowenstein(a)ucsd.edu

23 years, 3 months

[pups] Unix Archive now available anonymously

by Warren Toomey

All, With the new Caldera license, the Unix Archive is now available to you anonymously. You can throw away those passwords now. The list of Archive mirrors is at: http://www.tuhs.org/archive_sites.html and if you can become a mirror, please read http://www.tuhs.org/mirroring.html and send me some e-mail when you are ready to be added to the list. I can tell you that up to now, 2,830 people obtained a SCO Ancient UNIX license, of which 250 had to pay the US$100 to get it. I'll turn off the CGI script which allows you to obtain a SCO license now .... You know this means that Net/2, 4.xBSD and 2.11BSD are all freely available now :) Cheers, Warren

23 years, 3 months

4.4BSD and the MicroVax 3400

by Rob Becker

Anyone here know if 4.4BSD supports the MicroVax 3400 series of machines? One was given to me by my school (clearing out old equipment) and I would like to get some pure BSD goodness on it again. Also, anyone know if it's possible to make tapes under VMS? Thanks in advance, Rob Becker

23 years, 3 months

Re: [TUHS] 4.4BSD and the MicroVax 3400

by msokolov＠ivan.Harhan.ORG

Rob Becker <becker(a)ab.edu> wrote: > Anyone here know if 4.4BSD supports the MicroVax 3400 series of machines? > > [...] > > get some pure BSD goodness on it again. For VAXen you don't want 4.4BSD, you want 4.3BSD-Quasijarus, especially if you want pure. Unfortunately, I haven't got the KA640 (3300/3400) support in there, just KA650 (3500/3600) and KA655 (3800/3900). It would be trivial to add, though, it just needs to be taught to look at the SIE in addition to the SID, recognise the KA640, and don't try to touch the non-existent B-cache. This wouldn't give you support for the on-board DSSI and Ethernet, but it'll run with your Q-bus devices. MS

23 years, 3 months

[pups] Re: Caldera license

by Warren Toomey

In article by Milo Velimirovic: > Warren, > The license didn't survive the digestification process on the list -- > Would you be kind enough to send me a copy of the ancient-source.pdf > directly or a URL to it? > > Thanks, > Milo Here it is, Warren http://www.tuhs.org/Archive/Caldera-license.pdf

23 years, 3 months

[pups] Ancient UNIX now under a BSD license

by Warren Toomey

All, Amazing news. I have been negotiating with Caldera to release the Ancient UNIX under a BSD-style license. Well, they got it done faster than I expected. See attached license. I'll start removing the username/password stuff on the Unix Archive soon. Warren

23 years, 3 months

Re: [pups] 2.11BSD disklabel-programm

by pete＠dunnington.u-net.com

On Jan 20, 18:45, Jochen Kunz wrote: > > Ahhhhh! My PDP 11 has this M8192 board with FPU but without ROMs... > I thought that this is the "original" 11/73 CPU. But on this PDP is > nothing "original". The BA23 was a MV II, the CPU was EPayed, the RAM > board was given to me by a friend. (Many PC/XTs had to donate there RAM > chips to fill it.) About the best use I can think of for a PC/XT :-) > I found the console SLU at the scrap yard, the Dilog > ESDI controller was EPayd (in England BTW ;-) ) ... and I am still > looking for a ROM card... If you can find an MRV11-D (to put MXV11-B ROMs into) or an MVX11-B, that would be the best option (and the only ones DEC supported). However, it should be possible to put the code from MXV11-B ROMs into several 24-pin 2Kx8 EPROMs (2716 or equivalent), and put the EPROMs into a BDV11. However, you'd want to modify the BDV11 for 22-bit operation (that's ECO 005). > > The BA23 was only rated for one hard disk and either a TK50 or an > RX50, > I know. I once saw a MV II with a second RD54 in an external case. There > was a real mess of wiring to get it and the internal RD54 work together > on one RQDX3. Puting the TK50 out of the BA23 and mounting the second > RD54 in the BA23 would have been much simpler. But not the DEC way of > live. ;-) Because old hard drives take a lot of current. The PSU and wiring loom won't take a full backplane and two hard drives. I did one of mine a different way. I have a BA11-N with the backplane modified to be 22-bit. In it is an RQDX2 (or an RQDX3, depending on what's been shuffled around this month), with a 50-way ribbon cable going to a DEC box (used to be a TKZ50) which has a PSU, a hard drive, and an RX50. In the box is also a small PCB I made to do the job of the distribution board found in a BA123. Also in the BA11-N backplane is a modified BDV11, with a pair of 28-pin EPROM sockets which normally hold microPDP-11/23 boot ROMs. -- Pete Peter Turnbull Network Manager University of York

23 years, 4 months

Jump to page:

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

1996

1995

1994

1993

1992

1991

1990

TUHS