TUHS

tuhs@tuhs.org

6420 discussions

Re: [pups] Duh - how do you format an RX50?

by pete＠dunnington.u-net.com

On Feb 9, 8:37, Jay Jaeger wrote: > Um, bzzzzt. Wrong. I have a floppy labeled: BL-FN7AP-MC CZFNAP0 M-11 > FORMTR RX50 . This is a formatter program for a Micro PDP-11. > > It is a *diagnostic* program (not a user program) for formatting these > beasties. Mine is for the -11, I would imagine that there is one for the > MicroVAX as well. > At 11:42 PM 2/8/2002 +0000, Pete Turnbull wrote: > >You can format them on a Rainbow, but not an -11 or VAX. Jay, I'd be very interested to know more about that. I never heard of it before, and I thought I had a pretty comprehensive collection of the PDP-11 (including microPDP-11) diagnostics. Was it standard issue with a particular model? Is there a date on it? -- Pete Peter Turnbull Network Manager University of York

22 years, 12 months

[pups] Duh - how do you format an RX50?

by Jonathan Engdahl

I can't believe I haven't figured this out yet. I bought an RX50, and installed it in my PDP-11/53 running 2.11BSD. It's nice having that empty hole in the front of the BA23 plugged, but I hope for even more. The drive seems alive: if I say "cp /dev/ra1a /dev/null", it starts groaning and ticking as if it were reading the floppy. But how do you format the floppies? I tried XXDP/ZRQCH0 (downloaded via VTserver), but it says the floppies are UNFORMATTABLE. That does that mean? -- Jonathan Engdahl Rockwell Automation Principal Research Engineer 1 Allen-Bradley Drive Advanced Technology Mayfield Heights, OH 44124 http://users.safeaccess.com/engdahl engdahl(a)safeaccess.com "The things which are seen are temporary, but the things which are not seen are eternal." II Cor. 4:18

22 years, 12 months

[pups] bootstrapping an RT-11 image via VTserver

by Jonathan Engdahl

I built an 11/23 with 256K RAM, a UDC11 disk controller, one 80 meg MFM hard drive. The hard drive formatter runs under RT-11. The assumption is that you have a working floppy from which you can boot RT-11. I want to devise a method to run the formatter via VTserver. I figured out how to do this for the RQDX3 and XXDP. You can run XXDP under E11, load the utility you want to run, then stop E11 and dump the entire 28K word memory image to a disk file. By hacking a header onto this memory image, you can turn it into a standalone that can be bootstrapped via VTserver, just like the disklabel, mkfs, and restor standlones. This is easy, because XXDP tells you what the restart address is when you load a program. The question: is is possible to restart RT11SJ in the same manner as XXDP? I read some of the manuals, and tried using ODT to restart RT-11 at various points pointed to by the vector table and fixed area. By starting at the trap 4 address I can get it to restart and live. However, this seems to make RT-11 forget that I had done a "GET" of the utility that I wanted to run. I tried restarting at the RMON address, but that crashes. One other experiment I've tried is to GET the utility then "START 1000", but that crashes too. If I GET then just type "START" it lives. What am I doing wrong? One assumption is that the utility only uses memory and TT: system calls -- no disk accesses or swapping. Is it possible to abuse RT-11 in this manner? The utilities I'm trying to run are the UDC11 OCT and UDCT utilities. I want to make it possible to reformat the hard drive on this single drive system without tearing it apart and moving pieces to another system. It is also possible to mess up the NVRAM on the UDC11 so that you cannot boot. If this happens, and you are lucky enough to have another running system (and I am), you can rejumper the CSR of the stuck board and fix it on the other system. Otherwise, you are in big trouble. I wonder if it would be possible to bootstrap a VM0: image into high RAM and boot from it? I realize there are other solutions. The standard answer to questions like this is "get more hardware". The reason for doing this is I want to invent a method that will work for a very minimal pile of hardware. And the whole point of that is to make it possible for people to get a PDP-11 running with minimal investment. -- Jonathan Engdahl Rockwell Automation Principal Research Engineer 1 Allen-Bradley Drive Advanced Technology Mayfield Heights, OH 44124, USA Mayfield Heights Labs engdahl(a)safeaccess.com 440-646-7326 http://users.safeaccess.com/engdahl/PDP-11.htm

23 years

Browse Unix src: the Unix Tree

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

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

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

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

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

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

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

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