TUHS

tuhs@tuhs.org

6 participants
6532 discussions

by Warren Toomey

All, With the freeing up of the Unix source, not only can I open up the Unix Archive to anonymous downloads, but I can now make my Unix Tree web site available anonymously: http://minnie.tuhs.org/UnixTree/ Here is where you will find unpacked versions of Unix source code, and a means of comparing files between different versions. Cheers, Warren P.S Thanks to the many people who have set up mirrors of the Unix Archive.

23 years, 5 months

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

by norman＠nose.cs.utoronto.ca

Greg Lehey: To repeat what I said earlier: the hardware-dependent code isn't very interesting, it's the kernel interfaces. Minix is not UNIX; BSD is. You'll find it easier to adapt a BSD driver to the Sixth or Seventh Edition than you will a Minix or Linux driver. It depends on approach, which depends in turn on intent. If the intent is to get a system up and running as quickly as possible, it would probably be best to shoehorn existing code into the existing old UNIX framework, and code from a current BSD system is probably easier to do that with than code from Minix (says someone who has looked at neither within living memory). If the intent is to learn about the innards of operating systems and how they interact with hardware, or about the specifics of old UNIXes or the OS aspects of Intel hardware, it is better to compare different descriptions of the hardware (whether abstract descriptions in books or pragmatic ones in code), write your own small test programs to be run on bare hardware or as special cases within some system that already runs there, and eventually write your own code or adopt code that you now understand thoroughly. Which of these you consider fun depends both on your goals and on your personal taste. Both are worthy of respect. In days long past, when I did a lot of work to make a research version of UNIX as robust as possible against hardware flaws (recover if possible, at least explain clearly what broke if not) and to port it to a few new VAXes of the time, I found the best hardware information to lie in the VAX/VMS source fiche. The UNIXes of the day tended either to crash on the slightest hardware error or to ignore the error and just misbehave until rebooted. Stealing code from them would have been easier, but it wouldn't have done what I wanted. Reading the VMS sources and treating them as a hardware reference manual did. Modern UNIXes doubtless do better, but the point is that different systems do different things with the hardware, and if your goal is understanding and not just function, you will gain more by looking in many places. An irrelevant but fun anecdote: it could be argued that the resulting code recovered too smoothly from errors. One day I discovered that one of our systems was running more slowly than usual, though it was otherwise OK; checking back on the paper console log, I discovered that several weeks earlier it had had a hard cache error, reported it and cheerfully turned off the bad half of the cache, and continued on its way. So I called Field Service and we scheduled a convenient time to run diagnostics--yes, the hardware really had failed--and replace the bad CPU board; but it would have been better to have noticed earlier. I watched the console logs more carefully after that. Norman Wilson Toronto ON

23 years, 5 months

Re: [pups] solution for the disklabel

by pete＠dunnington.u-net.com

On Jan 27, 23:42, lothar felten wrote: > 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. 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'). > i have some dec boards labeled M7513 > does anyone know what this > is? i found: > M7513 - RQD - RQDXE Q BUS drive > interface extension module That's exactly what it is. The BA23 box only supports one hard drive; the RQDXE is an adaptor for an RXDX2 or RXDX3 to permit use of additional drives with a distribution board in a second enclosure. One of the 50-pin connectors goes to the RQDX3, one to the distribution board in the BA23, and the third to a connector kit on the rear panel of the BA23. There's a different version for an RQDX1, called an RQDX1E. > the RQDX3 has another connector, i > suppose for RX50 floppydrive. An RQDX3 has only one connector, the 50-pin one to go to the distribution board. Are you looking at the right thing? Are you looking at a distribution board? That does have a 34-way connector for a floppy. > can i hook up a 5,25" pc drive? maybe > with modifications? Not an ordinary PC floppy, no. A TEAC FD55GFR is an 80-track double-sided drive (not HD, though) that will work as an RX33. Some other 80-track 5.25" drives may work, if you set the jumpers. -- Pete Peter Turnbull Network Manager University of York

23 years, 5 months

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

by Fred N. van Kempen

.. and I'm actually still alive, although only barely... :) I'll respond to Michael in email, and summarize here.. --f > -----Original Message----- > From: Warren Toomey [mailto:wkt@minnie.tuhs.org] > Sent: maandag 28 januari 2002 23:09 > To: Michael Werner > Cc: PUPS mailing list > Subject: Re: [pups] Problems booting PDP11/40 using vtserver > > > In article by Michael Werner: > > 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. > > So, my question: Does anybody know what's going wrong here? > > Thanks in advance - Michi > > I've passed the baton of Vtserver development over to Fred van Kempen. > However, which version of Vtserver are you using? > > Cheers, > Warren > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups > InterNetworking en Network Security Consultant MicroWalt Corporation (Netherlands), Korte Heul 95, 1403 ND BUSSUM Phone +31 (35) 6980059 FAX +31 (35) 6980215 http://WWW.MicroWalt.NL/ Dit bericht en eventuele bijlagen is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding aan derden is niet toegestaan. Er wordt geen verantwoordelijkheid genomen voor de juiste en volledige overbrenging van de inhoud van dit bericht, noch voor de tijdige ontvangst ervan.

23 years, 5 months

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

by P.A.Osborne

On Fri, Feb 01, 2002 at 02:43:53PM -0500, bwc(a)borf.com wrote: > Regarding the few comments in Ken's kernel--I always found the great--you > can get the Lyons' commentary which may be another reason for doing Sixth. My thoughts exactly funnily enough. Pondering just this over the weekend has left me wondering whether MiniUnix would be a better initial place to start - as its essentially V6, but without memory management or pipes. Which as a starting point for the experiment may be an easier place to start. Thoughts anyone? Also as a sideline, I don't know how the list owner of this list feels about this discussion potentially swamping the list. If this is an issue or other readers of the list are sick and tired of the current ruminations please feel free to let me know and I will create a mailing list on the list manager here at UKC. That way those of us who are regarded as sad, mad or just plain losers can take our mutterings somewhere else. :-) Paul

23 years, 5 months

booting 4.3-Quasijarus on SIMH VAX

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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 months

[pups] Problems booting PDP11/40 using vtserver

by Michael Werner

23 years, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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