Hi,
I'm running above image with the p11 emulator, and the root partition
is almost full.
I tried to clean it up, but I cannot find where the space is used.
df says:
--------
# df
Filesystem 1K-blocks Used Avail Capacity Mounted on
root 7816 7030 786 10% /
--------
but looking at files, I only see 2MB+ in use:
--------
# du -s /
2702
--------
This persists over reboots, so it doesn't seem to be a large deleted
file which is still in use.
Where is the missing space?
regards,
chris
> Warren, maybe you know a PUPS volunteer in the USA that has appropriate
> equipment and experience to do this job? This would also reduce shipping
> efforts and cost for Mr. McKusick. (And risk of damage of the tapes, as
> it would avoid shipping across the "big pond".)
I've just sent some mail to Tim Shoppa, asking if he would be willing
to read the tapes for us.
Cheers,
Warren
Hi,
I've been lurking here for a week or two, reading the
archives on porting v7 to x86, etc.
On a lark, I downloaded the v7 sources and started to
"upgrade" them so the userland can build and run on top
of modern OS kernels such as Linux. The bulk of libc
is the same (warts and all), with the "sys" layer replaced
with modern syscalls.
Perhaps it is a bit "sacrilegious", but I believe it makes
the code more accessible for experimentation, and it
should solve the "how do we get a PDP-11 compiler"
problem: we use the original hosted on top of a modern
kernel as a cross-compiler.
Check it out and let me know what you think. Most of
the libraries have been upgraded, with a handful of the
simpler command-line utilities.
http://www.southern-storm.com.au/v7upgrade.html
Cheers,
Rhys.
I've started porting some of the old UNIX programs to Mac OS X. I've
got about 1/2 the games, that should be ok, but I also have other things
like crypt and makekey. I'd like to make these available in binary
form, but I don't want the men in black knocking at my door either...
Any thoughts?
On a side note, I simply can not believe how easy it is to compile this
old code under Mac OS X. for some of it, it's proving easier than
porting Linux code ( if you've only known how long I worked on linux's
fortune, and the old one just compiled no fuss, no problems ).
Also, if your wandering why ... that's easy, because I can.
Thanks.
- Derrik
firebug(a)apk.net
http://junior.apk.net/~firebug
---------------------------------------------------------------------------------------------------
The number of UNIX installations has grown to 10, with more expected.
-- The Unix Programmer's Manual, 2nd Edition, June 1972
Hello,
I ám still have a working Dec pdp11-23. It runs on CTS-300 with 10 Mb Harddisk and a Tape drive for back-ups
I think the programm is writen in dibol.
I f you want more information about this system please reply by email
If anyone can help me with the following questions.
Can i connect an windows/dos sytem to the pdp11-23 and run the program.
Is it possible to copy the program and run it on a Windows/Dos based machine.
Hope to hear from sombody,
Pieter Visser
The Netherlands
e-mail p.visser(a)tip.nl
handy +31-(0)6-53630275
phone +31-(0)165-313597
work +31-(0)76-5022800
fax +31-(0)76-5022090
On Fri, Feb 01, 2002 at 10:24:30AM +0000, P.A.Osborne wrote:
> 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).
support for PDP-11 was added to gcc a few months ago. I don't think
it's been well tested, but support exists in current versions of
binutils and gcc.
http://pdp11.nocrew.org/
there's also support for the m68hc11/12 which are 16-bit.
it seems like support for 80{,1,2}86 in gcc should be possible; it just
hasn't been done yet.
another compiler that might be worth looking at is SDCC
http://sdcc.sourceforge.net/ which is currently targeted towards 8-bit
MCUs.
of course bootstrapping via the original K&R compiler would be the
"classic" way to do it, though. ;)
--
Aaron J. Grier | "Not your ordinary poofy goof." | agrier(a)poofygoof.com
"[...] I generally haven't found IDM guys to be very good
live acts, most of them just sit down at their laptop and
tweak reaktor." -- Brandon Daniel
Aaron J. Grier wrote :-
> support for PDP-11 was added to gcc a few months ago.
It's been around since 1991 as a patch, but it didn't keep up with the newer
versions of gcc
Hi -
> From: David W Talmage <talmage(a)cmf.nrl.navy.mil>
> I thought that I'd read in the FM that they do. I see now that I was
> mistaken,perhaps delusional. I see now that <sys/stat.h> contains the gospel:
>
> #define S_IFIFO 0010000 /* named pipe (fifo) - Not used by 2.11BSD */
:)
Adding FIFOs to the kernel would make an interesting project though -
perhaps when I become inspired/motivated I'll give it a try.
> Sounds like I'm in for some deep hacking if I continue with this. Will
> overlays help me here?
Overlays will help if the code comes out to more than 64KB. Alas,
overlays will _not_ help the dataspace requirements. The last time
I looked at 'screen' I saw things like "char buf[32768];' sprinkled
thru the code. So you might be in for some serious hacking to trim
back the sizes of arrays/buffers/etc. It probably would also be
a good idea to 'string'ify the program (there are tools to assist
doing this - take a look at how sendmail and lint are built).
> I wonder if setitimer() will fare any better. alarm() is obsolete.
The gospel according to /usr/src/lib/libc/gen/alarm.c says:
/*
* Backwards compatible alarm.
*/
#include <sys/time.h>
#include <unistd.h>
unsigned int
alarm(secs)
unsigned int secs;
{
struct itimerval it, oitv;
register struct itimerval *itp = ⁢
timerclear(&itp->it_interval);
itp->it_value.tv_sec = secs;
itp->it_value.tv_usec = 0;
if (setitimer(ITIMER_REAL, itp, &oitv) < 0)
return (-1);
if (oitv.it_value.tv_usec)
oitv.it_value.tv_sec++;
return (oitv.it_value.tv_sec);
}
<g>
> I'll send a progress report if I decide to continue this project. Thanks for
> your help, Mr. Schultz.
What I think you're seeing is the race condition that fork() has -
there is no guarantee which process (parent or child) runs first.
The test program does the fork() and the child runs to completion
before the parent enters the select(). At that point the parent
will wait until the alarm goes off.
One thing you might try is create two separate programs. One would
create the socket and wait for the other program to connect and send
a string. If that works it shows that the UNIX domainsockets are
working as expected and that the fork() race is indeed the problem.
IF the client/server tests fail then there is something wrong in the
UNIX domain socket handling that needs to be addressed.
Good Luck!
Cheers,
Steven Schultz
Hi!
> From: David W Talmage <talmage(a)cmf.nrl.navy.mil>
> Would someone please advise me about fifos and sockets in 2.11BSD?
Ok ;)
Don't use fifos - they don't exist (as you probably have found
out by now :))
> I'm having
> trouble porting screen 3.9.9, the multiplexing terminal emulator, to 2.11BSD
fifos and sockets are just the tip of the iceberg when it comes
to 'screen'. Eons ago (when screen was a fairly new program) I made
an attempt at porting it and ran into the address space problems - seems
that screen wants to use lots of large buffers, has lots of strings
(all the help, etc) and so on.
> because of them. I'm running Mr. Schultz's 2.11BSD with all patches up to
> #442 on Mr. Brandt's p11 emulator version 2.9. FWIW, I have INET in my kernel
> but I've ifconfig-ed only lo0.
Thanks for the "ownership" label but I think of it more as being
a 'steward' and coordinator than anything else
p11 2.9? Wow, I've an old patched/hacked 2.5 because I can't seem
to find p11's home now - begemot.org doesn't mention anything about
"p11".
> The fifo test portion of the configure script fails when writing to the fifo.
> The write() returns -1 and sets errno == 79, "Inappropriate file type or
Right, FIFOs don't exist. One of those things I never could find
the need or time for ;)
> format". This happens when I run the test as root, as I must in order to use
> mknod() to create the fifo. See fifotest.c, below.
If 2.11's mknod can create fifos that is _news_ to me. I don't recall
seeing (or adding) that capability.
> screen can use sockets instead of fifos. That portion of the configure script
> fails as well. It fails in that it does not return from the select() on the
> socket until the alarm goes off. See socketstest.c, below.
Now that is very strange. Unix domain sockets do work (syslogd
uses them for example) so I'm at a loss to explain why the test
program isn't working.
One thing I did do is after running "./a.out&" was do an immediate
'ps'. That should see 2 a.out processes due to the 'fork()' call.
I only say one. This tells me that the alarm was started (obviously
since alarm(5) is the first thing executed) but the child process
raced thru and exited before the parent got to the select() call.
With the child exited the select() will block until interrupted by
the alarm() call.
Steven Schultz
sms(a)2bsd.com
Would someone please advise me about fifos and sockets in 2.11BSD? I'm having
trouble porting screen 3.9.9, the multiplexing terminal emulator, to 2.11BSD
because of them. I'm running Mr. Schultz's 2.11BSD with all patches up to
#442 on Mr. Brandt's p11 emulator version 2.9. FWIW, I have INET in my kernel
but I've ifconfig-ed only lo0.
screen's configure complains that it finds no usable fifo or socket.
The fifo test portion of the configure script fails when writing to the fifo.
The write() returns -1 and sets errno == 79, "Inappropriate file type or
format". This happens when I run the test as root, as I must in order to use
mknod() to create the fifo. See fifotest.c, below.
screen can use sockets instead of fifos. That portion of the configure script
fails as well. It fails in that it does not return from the select() on the
socket until the alarm goes off. See socketstest.c, below.
/* fifotest.c */
#include "confdefs.h"
#include <sys/errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
/*
#ifndef O_NONBLOCK
#define O_NONBLOCK O_NDELAY
#endif
#ifndef S_IFIFO
#define S_IFIFO 0010000
#endif
*/
char *fin = "/tmp/conftest254";
main()
{
struct stat stb;
int f;
(void)alarm(5);
#ifdef POSIX
if (mkfifo(fin, 0777)) {
#else
if (mknod(fin, S_IFIFO|0777, 0)) {
#endif
printf("mknod failed\n");
perror("mknod");
exit(1);
}
if (stat(fin, &stb) || (stb.st_mode & S_IFIFO) != S_IFIFO) {
printf("stat failed\n");
exit(1);
}
close(0);
#ifdef __386BSD__
/*
* The next test fails under 386BSD, but screen works using fifos.
* Fifos in O_RDWR mode are only used for the BROKEN_PIPE case and for
* the select() configuration test.
*/
exit(0);
#endif
if (open(fin, O_RDONLY | O_NONBLOCK)) {
printf("open #1 failed\n");
exit(1);
}
if (fork() == 0)
{
printf("f0\n");
close(0);
if (open(fin, O_WRONLY | O_NONBLOCK)) {
printf("f0 open #2 failed\n");
exit(1);
}
close(0);
if (open(fin, O_WRONLY | O_NONBLOCK)) {
printf("f0 open #3 failed\n");
exit(1);
}
if (write(0, "TEST", 4) == -1) { /* FAILS HERE */
printf("f0 write failed %d\n", errno);
perror("write");
exit(1);
}
exit(0);
}
printf("f1\n");
f = 1;
if (select(1, &f, 0, 0, 0) == -1) {
printf("f1 select failed\n");
exit(1);
}
exit(0);
}
/* socketstest.c */
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <fcntl.h>
char *son = "/tmp/conftest254";
main()
{
int s1, s2, s3, l;
struct sockaddr_un a;
(void)alarm(5);
if ((s1 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
perror("socket");
exit(1);
}
a.sun_family = AF_UNIX;
strcpy(a.sun_path, son);
(void) unlink(son);
if (bind(s1, (struct sockaddr *) &a, strlen(son)+2) == -1) {
perror("bind");
exit(1);
}
if (listen(s1, 2)) {
perror("listen");
exit(1);
}
if (fork() == 0)
{
if ((s2 = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
perror("f0 socket");
kill(getppid(), 3);
}
(void)connect(s2, (struct sockaddr *)&a, strlen(son) + 2);
if (write(s2, "HELLO", 5) == -1) {
perror("f0 write");
kill(getppid(), 3);
}
exit(0);
}
l = sizeof(a);
if (close(0) == -1) {
perror("close");
}
if (accept(s1, &a, &l)) {
perror("accept");
exit(1);
}
l = 1;
if (select(1, &l, 0, 0, 0) == -1) { /* DOESN'T RETURN BEFORE SIG_ALARM */
perror("select");
exit(1);
}
exit(0);
}
--
David Talmage (talmage(a)cmf.nrl.navy.mil)
ITT Industries, Advanced Engineering & Sciences,
Advanced Technology Group
Hi.
I plan to do a BSD exhibition at the VCFE. Main focus is
4.3BSD{,-Tahoe,-Reno} on VAXen. But I want to show 4.4BSD-Lite on HP300,
SPARC and PMAX too. I have the 4.4BSD-Lite HP300 binaries, but nothing
for SPARC and PMAX. Are there any binaries still around? I don't want to
struggle with a SPARC and PMAX bootstrap...
Ahh, and 4.2BSD-Reno for HP300 is missing too...
--
tschüß,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
On Feb 10, 17:23, Jay Jaeger wrote:
> Rats. So it would seem. Forgot about that angle. Useful program --
just
> not for floppies.
>
> Oh well.
>
> (Hmm. I wonder how "bzzzzt"s taste when you have to eat them with your
> hat?) I suspect that they kind of tingle, eh?
As far as I remember, yes. I've tried it a few times myself :-)
--
Pete Peter Turnbull
Network Manager
University of York
On Feb 8, 8:31, Bill Gunshannon wrote:
> RX50's came pre-formatted from DEC. There was never a way to
> format them on PDP's or VAX as far as I knew. I do think it is
> possible to create them using PUTR and an old PC with a proper
> floppy controller and a 1.2M floppy drive configured the right
> way.
You can format them on a Rainbow, but not an -11 or VAX.
> My understanding is they are 80 track, 96 tpi format but spin
> at the slow spead of normal 5.25 disks and not the higher speed
> used by IBM HD disks.
Very similar low-level format to IBM floppies, except that, as Bill says,
they're 80-track. The spec is 80-track, 96 tpi, single-side, double
density (not HD), 10 sectors per track, 512 bytes/sector. DEC squeeze the
extra sector in by shortening some of the gaps; even so the timing is a
little tight and the drive speed has to be better-than-averagely accurate.
It doesn't matter whether you write them at 300 rpm or 360, so long as the
controller adjusts its data rate accordingly (250kbps or 300kbps). Which
is what a PC does (uses 250kbps for 300rpm and 300kbps for 360 rpm).
However, many HD-capable drives use pin 2 on the interface not only to
change the speed but change the write current. Some such drives have
jumpers to set the correct values.
> As a curious note, I actually had (and may still have in the
> attic somewhere) a real shugart 80 track 5.25 drive that would
> have been the equivalent of an RX50, so it was not only DEC who
> used that format. I had them on a TRS-80 and NewDOS-80 and
> DOSPlus had no problems formatting and using the drive. This
> was long before my first PDP, but I now wonder if they would
> have been able to read and write (and maybe even format!) RX50's.
If the controller it was attached to can write MFM (double-density), then
it would work. Drives of that type were very common before PCs took over.
In fact you can fudge one to look like half of an RX50 (a real RX50 plays
funny tricks with the SideSelect and Track00 signals, and some DEC
controllers use that to recognise an RX50).
--
Pete Peter Turnbull
Network Manager
University of York
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.
Jay, I just checked on that. It's not an RX50 formatter, it's the XXDP V2
formatting and diagnostics routines for an RXDX3. IIRC it will format RD5x
hard drives, and RX33, but not an RX50. Can you get a directory listing of
the disk?
--
Pete Peter Turnbull
Network Manager
University of York
On Feb 9, 12:14, Bill Gunshannon wrote:
> On Sat, 9 Feb 2002, 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.
> I guess this constitutes the last straw for this myth. Or was it merely
> a business decision intended to promote the sale of pre-formatted RX-50
> diskettes. (A practice not uncommon in those days. For example, at one
> place where I worked we were responsible for maintaining Terak Micros, a
> LSI-11 based system. Any time we reported a floppy problem the first
> question was, "Are you using Terak brand diskettes??" Of course,
everyone
> at that time knew there were only 3 manufacturers of platens and
everybody
> else just supplied labels!!)
>
> Other arguments: I have an Andromeda Disk Controller. I know one of the
> supported floppy formats is RX50. I'll bet the their formatting program
> won't care what drive is there and will happily format diskettes for use
> in this and other RX-50's.
I expect it would. It's not hard to write a formatter program. I wrote
one for my Acorn Archimedes, and an RX50 copier program as well.
> I wonder if there is anyone who could be contacted about releasing it??
> Maybe even the VMS version, too. Or even, the source?? Somehow, I doubt
> that Compaq still sells many pre-formatted RX50's.
I seem to recall that DEC let people copy XXDP between machines without too
much excitement.
> And while we're on the subject, what about this supposed problem using
> anything put certain kinds of diskettes?? I used my 80 track 96tpi drive
> all the time with the same diskettes I used in my other SS/SD, DS/SD
drives
> all the time and never had a problem. Is this perhaps another myth
intended
> to foster the sale of pre-formatted diskettes??
So long as they're labelled SD or DD and not HD, they have the right
coercivity. Some people argue that the fineness of the emulsion may be a
factor, but actually you'd have to be incredibly unlucky to have a flaw on
a disk that would allow it to be perfect for SD but not DD. Some people
have likewise argued that the disk head gap is only about half as wide for
80-track as it is for 40-track, but that's irrelevant: even if the gap is a
third of the track pitch, thats around 1/300", the resulting bit density
(300 bpi) on the radius of the disk is still much coarser than the bit
density around the circumference (about 3300 bpi for single density).
I do have a few very old S/S floppies with flaws on the second side, and
which therefore aren't good to use as D/S (I value my data!) but I have
hundreds more sold as S/S that are work fine as D/S. They just weren't
certified that way; they probably just weren't tested, in the days when
lots of disks didn't need to be.
--
Pete Peter Turnbull
Network Manager
University of York
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
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
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
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.
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
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
.. 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.
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