> > 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)
> 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
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
>
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.
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
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
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
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
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 ?
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
