> From: Dave Horsfall <dave(a)horsfall.org>
> What, as opposed to spelling creat() with an "e"?
Actually, that one never bothered me at all!
I tended to be more annoyed by _extra_ characters; e.g. the fact that 'change
directory' was (in standard V6) "chdir" (as opposed to just plain "cd") I
found far more irritating! Why make that one _five_ characters, when most
common commands are two?! (cc, ld, mv, rm, cp, etc, etc, etc...)
Noel
Norman Wilson writes today:
>> ...
>> -- Dennis, in one of his retrospective papers (possibly that
>> in the 1984 all-UNIX BLTJ issue, but I don't have it handy at
>> the moment) remarked about ch becoming chdir but couldn't
>> remember why that happened.
>> ...
The reference below contains on page 5 this comment by Dennis:
>> (Incidentally, chdir was spelled ch; why this was expanded when we
>> went to the PDP-11 I don't remember)
@String{…
[View More]pub-PH = "Pren{\-}tice-Hall"}
@String{pub-PH:adr = "Upper Saddle River, NJ 07458, USA"}
@Book{ATT:AUS86-2,
author = "AT{\&T}",
key = "ATT",
title = "{AT}{\&T UNIX} System Readings and Applications",
volume = "II",
publisher = pub-PH,
address = pub-PH:adr,
pages = "xii + 324",
year = "1986",
ISBN = "0-13-939845-7",
ISBN-13 = "978-0-13-939845-2",
LCCN = "QA76.76.O63 U553 1986",
bibdate = "Sat Oct 28 08:25:58 2000",
bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib",
acknowledgement = ack-nhfb,
xxnote = "NB: special form AT{\&T} required to get correct
alpha-style labels.",
}
That chapter of that book comes from this paper:
@String{j-ATT-BELL-LAB-TECH-J = "AT\&T Bell Laboratories Technical Journal"}
@Article{Ritchie:1984:EUT,
author = "Dennis M. Ritchie",
title = "Evolution of the {UNIX} time-sharing system",
journal = j-ATT-BELL-LAB-TECH-J,
volume = "63",
number = "8 part 2",
pages = "1577--1593",
month = oct,
year = "1984",
CODEN = "ABLJER",
DOI = "http://dx.doi.org/10.1002/j.1538-7305.1984.tb00054.x"
ISSN = "0748-612X",
ISSN-L = "0748-612X",
bibdate = "Fri Nov 12 09:17:39 2010",
bibsource = "Compendex database;
http://www.math.utah.edu/pub/tex/bib/bstj1980.bib",
abstract = "This paper presents a brief history of the early
development of the UNIX operating system. It
concentrates on the evolution of the file system, the
process-control mechanism, and the idea of pipelined
commands. Some attention is paid to social conditions
during the development of the system.",
acknowledgement = ack-nhfb,
fjournal = "AT\&T Bell Laboratories Technical Journal",
topic = "computer systems programming",
}
Incidentally, on modern systems with tcsh and csh, I use both chdir
and cd; the long form does the bare directory change, whereas the
short form is an alias that also updates the shell prompt string and
the terminal window title.
I also have a personal alias "xd" (eXchange Directory) that is short
for the tcsh & bash sequence "pushd !*; cd .", allowing easy jumping
back and forth between pairs of directories, with updating of prompts
and window titles.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
[View Less]
> From: Jason Stevens
> has anyone ever tried to compile any of the old C compilers with a
> 'modern' C compiler?
> ...
> How did any of this compile? How did this stuff run without clobbering
> each-other?
As Ron Natalie said, the early kernels are absolutely littered with all sorts
of stuff that, by today's standards, are totally unacceptable. Using a
variable declared as an int as a pointer, using a variable declared as a
'foo' pointer as a 'bar' …
[View More]pointer, yadda-yadda.
I ran (tripped, actually :-) across several of these while trying to get my
pipe-splicing code to work. (I used Version 6 since i) I am _totally_
familiar with it, and ii) it's what I had running.)
For example, I tried to be all nice and modern and declared my pointer
variables to be the correct type. The problem is that Unix generated unique
ID's to sleep on with code like "sleep(p+1, PPIPE)", and the value generated
by "p+1" depends on what type "p" is declared as - and if you look in pipe.c,
you'll see it's often declared as an int pointer. So when _I_ wrote
"sleep((p + 1), PPIPE)", with "p" declared as a "stuct file pointer", I got
the wrong number.
I can only speculate as to why they wrote code like this. I think part of it
is, as Brantley Coile points out, historical artifacts due to the evolution
of C from (originally) BCPL. That may have gotten them used to writing code
in a certain way - I don't know. I also expect the modern mindset (of being
really strict about types, and formal about coverting data from one to
another) was still evolving back then - partly because they often didn't
_have_ the tools (e.g. casts) to do it right. Another possibility is that
they were using line editors, and maintaining more extensive source is a pain
with an editor like that. Why write "struct file *p" wnen you can just write
"*p"? And of course everyone was so space-concious back then, with those tiny
disks (an RK05 pack is, after all, only 2.5MB - only slightly larger than a
3.5" floppy!) every byte counted.
I have to say, though, that it's really kind of jarring to read this stuff.
I have so much respect for their overall structure (the way the kernel is
broken down into sub-systems, and the sub-systems into routines), how they
managed to get a very powerful (by anyone's standards, even today's) OS into
such a small amount of code... And the _logic_ of any given routine is
usually quite nice, too: clear and efficient. And I love their commenting
style - no cluttering up the code with comments unless there's something that
really needs elucidation, just a short header to say, at a high level, what
the routine does (and sometimes how and why).
So when I see these funky declarations (e.g. "int *p" for something that's
_only_ going to be used to point to a "struct file"), I just cringe - even
though I sort of understand (see above) why it's like that. It's probably the
thing I would most change, if I could.
Noel
[View Less]
Noel Chiappa:
> I tended to be more annoyed by _extra_ characters; e.g. the fact that
> 'change directory' was (in standard V6) "chdir" (as opposed to just
> plain "cd") I found far more irritating! Why make that one _five_
> characters, when most common commands are two?! (cc, ld, mv, rm, cp,
> etc, etc, etc...)
In the earliest systems, e.g. that on the PDP-7, the change-directory
command was just `ch'.
Two vague memories about the change:
-- Dennis, in one of his …
[View More]retrospective papers (possibly that
in the 1984 all-UNIX BLTJ issue, but I don't have it handy at
the moment) remarked about ch becoming chdir but couldn't
remember why that happened.
-- Someone else, possibly Tom Duff, once suggested to me that
in the earliest systems, the working directory was the only
thing that could be changed: no chown, no chmod. Hence just
ch for chdir. I don't know offhand whether that's true, but
it makes a good story.
Personally I'd rather have to type chdir and leav off th
trailing e on many other words than creat if it let me off
dealing with pieces of key system infrastructure that insist
on printing colour-change ANSI escape sequences (with, so far
as I can tell, no way to disable them) and give important files
names beginning with - so that grep pattern * produces an error.
But that happens in Linux, not UNIX.
Norman Wilson
Toronto ON
[View Less]
Thanks for clearing that the whole members out of nowhere thing.
I had thought (ha ha) that since I don't have a working fork, I could just
rebuild CC as a native
executable, and then just call apout for each stage, but I never realized
how interdependent
they all are, at least C0 to C1.
It's crazy to think of how much this stuff cost once upon a time.
And now we live in the era of javascript pdp-11's
http://pdp11.aiju.de/
-----Original Message-----
From: Brantley Coile
To: Jason Stevens
…
[View More]Cc: tuhs(a)minnie.tuhs.org
Sent: 10/27/14 9:03 PM
Subject: Re: [TUHS] speaking of early C compilers
Early C allowed you to use the '->' operator with any scaler. See early
C reference manuals. This is the reason there is one operator to access
a member of a structure using a pointer and another, '.', to access a
member in a static structure. The B language had no types, everything
was a word, and dmr evolved C from B. At first it made sense to use the
'->' operator to mean add a constant to whatever is on the left and use
as an l-value.
You will also find that member names share a single name space. The
simple symbol table had an bit in each entry to delineate members from
normal variables. You could only use the same member name in two
different structs if the members had the same offsets. In other words,
it was legal to add a member name to the symbol table that was already
there if the value of the symbol was the same as the existing entry.
Dennis' compilers kept some backward compatibility even after the
language evolved away from them.
This really shows the value of evolving software instead of thinking one
has all the answers going into development. If one follows the
development of C one sees the insights learned as they went. The study
of these early Unix systems have a great deal to teach that will be
valuable in the post Moore's law age. Much of the worlds software will
need to a re-evolution.
By the way, did you notice the compiler overwrites itself? We used to
have to work in tiny spaces. Four megabytes was four million dollars.
Sent from my iPad
> On Oct 27, 2014, at 6:42 AM, Jason Stevens
<jsteve(a)superglobalmegacorp.com> wrote:
>
> has anyone ever tried to compile any of the old C compilers with a
'modern'
> C compiler?
>
> I tried a few from the 80's (Microsoft/Borland) and there is a bunch
of
> weird stuff where integers suddenly become structs, structures
reference
> fields that aren't in that struct,
>
> c01.c
> register int t1;
> ....
> t1->type = UNSIGN;
>
>
> And my favorite which is closing a bunch of file handles for the heck
of it,
> and redirecting stdin/out/err from within the program instead of just
> opening the file and using fread/fwrite..
>
> c00.c
> if (freopen(argv[2], "w", stdout)==NULL ||
> (sbufp=fopen(argv[3],"w"))==NULL)
>
>
> How did any of this compile? How did this stuff run without
clobbering
> each-other?
>
> I don't know why but I started to look at this stuff with some half
hearted
> attempt at getting Apout running on Windows. Naturally there is no
fork, so
> when a child process dies, the whole thing crashes out. I guess I
could
> simulate a fork with threads and containing all the cpu variables to a
> structure for each thread, but that sounds like a lot of work for a
limited
> audience.
>
> But there really is some weird stuff in v7's c compiler.
> _______________________________________________
> TUHS mailing list
> TUHS(a)minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
[View Less]
> From: random832(a)fastmail.us
> Did casting not exist back then?
No, not in the early V6 compiler. It was only added as of the Typesetter
compiler. (I think if you look in those 'Recent C Changes' things I sent in
recently {Oct 17}, you'll find mention of it.)
Noel
Have you looked at http://real-votrax.no-ip.org/
they have a votrax hooked up, and yes it'll use your phonemes that speak
generates.
It just likes things to be upper case though.
So..
hello
!p
,h,e0,l,o0,o1,-1
works more like
H E0 L O0 O1 PA1
I wonder if anyone's generated wav's for each of the phonemes, then you
could hook up a line printer or something that'll read it as a pipe and just
play the wav's as needed..
It is rough 1970's speech synthesis, but I had one of those Intellivoice
…
[View More]things as a kid, so I kinda like it.
-----Original Message-----
From: Mark Longridge
To: tuhs
Sent: 10/13/14 8:57 AM
Subject: [TUHS] Getting Unix v5 to talk
Thanks to the efforts of Jonathan Gevaryahu I have managed
to get the Unix v5 speak utility to compile and execute.
All this was done using the simh emulator emulating a
PDP-11/70.
Jonathan managed extract enough of speak.c to reconstruct it
to the point it could be compiled with v5 cc. I believe it
was necessary to look at speak.o to accomplish this.
Jonathan also states that there are more interesting things
that could possibly be recovered from v6doc.tar.gz
One can look at speak.c source here:
http://www.maxhost.org/other/speak.c
Now had we have speak compiled we can go a bit further:
cat speak.v - | speak -v null
generates speak.m from ascii file speak.v
speak speak.m
computer
!p (prints out phonetics for working word)
which outputs:
,k,a0,m,p,E2,U1,t,er,-1
ctrl-d exits
Looking at speak.c we can see that it opens /dev/vs.
Fortunately we have the file /usr/sys/dmr/vs.c to look at
so this could be compiled into the kernel although I haven't
done this as yet.
speak.c looks like Unix v5 era code. My understanding is that
Unix v5 appeared in June 1974 and the comments say 'Copyright 1974'
so it seems plausible.
I'm intrigued by the possibility of getting Unix v5 to talk.
Mark
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
[View Less]
> From: "Engel, Michael" <M.Engel(a)leedsbeckett.ac.uk>
> The machine has a Multibus FD controller with its own 8085 CPU and a
> uPD765, connected to a Toshiba 5.25" DD floppy drive (720 kB, 80
> tracks, 9 sectors of 512 bytes), the model identifier is DDF5-30C-34I
> ... I couldn't find any information on that drive online, so I hesitate
> to simply connect a more modern drive due to possible pinout differences.
> ...
> I also found out …
[View More]a bit more on the SMD disk controller. It seems to be
> an OEM variant of the Micro Computer Technology MCT-4300 controller.
> The only place I could find this mentioned was in a catalog of Multibus
> boards on archive.org.
> ...
> So, if you happen to have any information on the Codata floppy
> controller, the Toshiba floppy or the MCT-4300 SMD disk controller, I
> would be happy to hear from you...
I don't, but can I suggest the Classic Computers mailing list:
http://www.classiccmp.org/mailman/listinfo/cctalk
They seem to have an extremely deep well of knowledge, and perhaps someone
there can help? (I'd rate the odds very high on the floppy drive.)
Noel
[View Less]
Hi,
it's time for an update on our progress with the Codata machine.
The serial interface problem was not caused by a defective transceiver
chip (which I found out after buying a couple…), but by an extreme
amount of noise on the (quite long and old) serial cable we used to
connect the machine to the PC acting as a terminal. Using a USB
to serial adapter and a short 9-to-25-pin adapter cable solved this
problem. Well, try the obvious things first (using a scope helped).
The second CPU board …
[View More]also works, so we could build a complete
second machine with our spare boards if we have another multibus
backplane...
We could get the machine up and booting from the first 8" hard disk
last Friday. Luckily, an old version of Kermit was installed and we
were able to transmit a large part of the root file system from single
user more - especially the Unix kernels, driver sources, the build
directories for the kernel, include files and the build directory for
the standalone boot floppies. All with a speed of 500 bytes/s (9600
bps serial line minus kermit overhead). cksum was used to confirm
that the files were transferred correctly (this was the only checksumming
tool that was available on the Codata, I didn't want to mount the fs
read-write and compile software before completing the backup).
I had to shut the machine down on Friday evening (security policy
that kicks you out of the building here), since I didn't want to leave
it running unattended over the weekend. Unfortunately, the disk
seems to have developed a bad sector in the autoconfiguration
region (the system seems to be quite modern in this respect).
The kernel can be booted successfully, but it refuses to mount the
root fs, complaining about a timeout. There seems to be a complete
root file system on the second disk (the firmware is able to read files
from the disk, but it doesn't offer a feature to list directories…), but the
kernel on the second disk also is hardwired to mount its root fs from the
first disk. Trying to connect disk 2 as disk 1 resulted in a non-booting
system...
The good news is that both root file systems seem to be reasonably
intact so far, I can read text files from the boot monitor. So our next
step to backup the rest of the system is to build an emergency boot
floppy. At the moment, however, the Codata refuses to talk to its
floppy drive. The machine has a Multibus FD controller with its own
8085 CPU and a uPD765, connected to a Toshiba 5.25" DD floppy
drive (720 kB, 80 tracks, 9 sectors of 512 bytes), the model identifier
is DDF5-30C-34I (printed on the motor assembly). I couldn't find
any information on that drive online, so I hesitate to simply
connect a more modern drive due to possible pinout differences.
I also found out a bit more on the SMD disk controller. It seems to
be an OEM variant of the Micro Computer Technology MCT-4300
controller. The only place I could find this mentioned was in a
catalog of Multibus boards on archive.org. It has its own driver
(cd.c), there is a separate one for the Interphase 2180 and an
additional one for the Codata MFM controller.
So, if you happen to have any information on the Codata floppy
controller, the Toshiba floppy or the MCT-4300 SMD disk controller,
I would be happy to hear from you...
-- Michael
[View Less]
> From: Greg 'groggy' Lehey <grog(a)lemis.com>
> This is really an identifier issues
Probably actually a function of the relocatable object format / linker on the
machines in question, which in most (all?) cases predated C itself.
> it's documented in K&R 1st edition, page 179:
Oooh, good piece of detective work!
Noel
Hi folks,
I've been looking at Unix v5 cc limitations.
It seems like early cc could only use variable and function names up
to 8 characters.
This limitation occurs in v5, v6 and v7.
But when using the nm utility to print out the name list I see
function test1234() listed as:
000044T _test123
That seems to suggest that only the first 7 characters are
significant, but when looking at other sources they stated that one
can use up to 8 characters.
I hacked up a short program to test this:
…
[View More]main()
{
test1234();
test1235();
}
test1234()
{
printf ("\nWorking");
}
test1235()
{
printf ("\nAlso working");
}
This generated:
Multiply defined: test5.o;_test123
So it would seem that function names can only be 7 characters in
length. I am not sure if limitations of early cc were documented
anywhere. When I backported unirubik to v5 it compiled the longer
functions without any problem.
Did anyone document these sorts of limitations of early cc? Does
anyone remember when cc started to use function names longer than 7
characters?
Mark
[View Less]
> From: Mark Longridge <cubexyz(a)gmail.com>
> It seems like early cc could only use variable and function names up to
> 8 characters.
> This limitation occurs in v5, v6 and v7.
> ...
> That seems to suggest that only the first 7 characters are significant,
> but when looking at other sources they stated that one can use up to 8
> characters.
The a.out symbol tables use 8-character fields to hold symbol names. However,
C …
[View More]automagically and unavoidably prepends an _ to all externals (I forget
about automatics, registers, etc - too tired to check right now), making the
limit for C names 7 characters.
> I am not sure if limitations of early cc were documented anywhere.
I remember reading the above.
Other limits... well, you need to remember that C was still changing in that
period, so limits were a moving target.
> When I backported unirubik to v5 it compiled the longer functions
> without any problem.
ISTR that C truncated external names longer than 7 characters. Probably the
ones in that program were all unique within 7, so you won.
> Did anyone document these sorts of limitations of early cc?
I seem to recall at least one document from that period (I think pertaining
to the so-called 'Typesetter C') about 'changes to C'.
Also, I have started a note with a list of 'issues with C when you're
backporting V7 and later code to V6', I'll see if I can dig them out tomorrow.
Noel
[View Less]
Afternoon,
# /etc/mkfs /dev/rrp1g 145673
isize = 65488
m/n = 3 500
write error: 2
# file rp0g
rp0g: block special (0/6)
# file rp1g
rp1g: block special (0/14)
# file rp0a
rp0a: block special (0/0)
# file rp1a
rp1a: block special (0/8)
# file rrp0a
rrp0a: character special (4/0)
# file rrp1a
rrp1a: character special (4/8)
# file rrp0g
rrp0g: character special (4/6)
# file rrp1g
rrp1g: character special (4/14)
DESCRIPTION
Files with minor device numbers 0 through 7 refer to …
[View More]various
portions of drive 0; minor devices 8 through 15 refer to
drive 1, etc.
The origin and size of the pseudo-disks on each drive are as
follows:
What am I forgetting? I have an image attached, I have modified hp.c to
have NHP as 2.
Is it conflict between rp.c and hp.c? (I patched hp.c to have NHP 2 after
patching NURP in rp.c to be 2).
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
[View Less]
> From: jnc(a)mercury.lcs.mit.edu (Noel Chiappa)
>> Did anyone document these sorts of limitations of early cc?
> I seem to recall at least one document from that period (I think
> pertaining to the so-called 'Typesetter C') about 'changes to C'.
> ...
> I'll see if I can dig them out tomorrow.
OK, there are three documents which sort of fall into this class. First,
there is something titled "New C Compiler Features", no date, available here:
http:/…
[View More]/minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/doc/cdoc/news…
no date, but it appears to describe an early version of the so-called
'Typesetter C', mentioned in other documents, so this would be circa 1976 or
so.
There is a second document, untitled, no date, which I have not been able to
locate online at all. I scanned my hard-copy, available here:
http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements1.jpg
..
http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements5.jpg
>From the content, it seems to be from shortly after the previous one, so say,
circa 1977.
Sorry about the poor readability (it looked fine on the monitor of the
machine my scanner is attached to); fudging with contrast would probably make
it more readable. When I get the MIT V6 Unix tapes read (they have been sent
off to a specialist in reading old tapes, results soon, I hope) I might be
able to get more info (e.g. date/filename), and machine-readable source.
Finally, there is "Recent Changes to C", from November 15, 1978, available
here:
http://cm.bell-labs.com/cm/cs/who/dmr/cchanges.pdf
which documents a few final bits.
There is of course also Dennis M. Ritchie, "The Development of the C
Language", available here:
http://cm.bell-labs.com/who/dmr/chist.html
which is a good, interesting history of C.
> Also, I have started a note with a list of 'issues with C when you're
> backporting V7 and later code to V6'
I found several documents which are bits and pieces of this.
http://ana-3.lcs.mit.edu/~jnc/history/unix/C_Backport.txthttp://ana-3.lcs.mit.edu/~jnc/history/unix/V6_C.txt
Too busy to really clean them up at the moment.
Noel
[View Less]
Back in the 80s in my University days I was using ISPS (Instruction Set Processor Simulator if I remember correctly ) a software tool To simulate CPU. It ran on a Vax with BSD 4.2. I have been unable to find any reference to It on the Internet . Do someone on this list know anything offerte this software ?
Thanks
Luca
> From: Mark Longridge
> Fortunately we have the file /usr/sys/dmr/vs.c to look at so this could
> be compiled into the kernel although I haven't done this as yet.
The vs.c seems to be a Votrax speech synthesizer hooked up to a DC11
interface. Do any of the simulators support the DC11? If not, adding the
driver won't do you much good.
Noel
PS: I seem to recall the DSSR group on the 4th floor at LCS actually had one
of these, back in the day. The sound quality was pretty …
[View More]marginal, as I recall!
[View Less]
Thanks to the efforts of Jonathan Gevaryahu I have managed
to get the Unix v5 speak utility to compile and execute.
All this was done using the simh emulator emulating a
PDP-11/70.
Jonathan managed extract enough of speak.c to reconstruct it
to the point it could be compiled with v5 cc. I believe it
was necessary to look at speak.o to accomplish this.
Jonathan also states that there are more interesting things
that could possibly be recovered from v6doc.tar.gz
One can look at speak.c source …
[View More]here:
http://www.maxhost.org/other/speak.c
Now had we have speak compiled we can go a bit further:
cat speak.v - | speak -v null
generates speak.m from ascii file speak.v
speak speak.m
computer
!p (prints out phonetics for working word)
which outputs:
,k,a0,m,p,E2,U1,t,er,-1
ctrl-d exits
Looking at speak.c we can see that it opens /dev/vs.
Fortunately we have the file /usr/sys/dmr/vs.c to look at
so this could be compiled into the kernel although I haven't
done this as yet.
speak.c looks like Unix v5 era code. My understanding is that
Unix v5 appeared in June 1974 and the comments say 'Copyright 1974'
so it seems plausible.
I'm intrigued by the possibility of getting Unix v5 to talk.
Mark
[View Less]
Hi,
after carefully examining the power supply and checking the generated
voltages, we were convinced that this wouldn't kill our Multibus boards.
Maybe some of you are interested in our progress, so I though I would
send you an update.
After reconnecting the Multibus backplane, we started the system with
only a CPU board and a memory board. On one of our CPU boards
the smaller (P2) Multibus connector is masked with tape, I'll have to dig
deeper to find out what is deactivated by this…
One …
[View More]of our two CPU boards is currently non functional (the one without
the masking take, this doesn't say a thing on the console UART, will bring
in the scope in Monday to check for details). The other one brings up the
monitor startup message and prompt on a connected serial terminal
(emulator) - however, we are unable to get any characters echoed back.
The serial cable is working, we tried all sorts of handshake configurations.
If we get any characters back (the system is running at 9600 baud, I tried
all combinations of 7/8 bit, none/even/odd/mark/space parity and 1/2 stop
bits), these are garbled and contain mostly "1" bits (0xfc, 0xfe, 0xff or
similar).
The UART itself seems to work (exchanged it with the one from the non
working board - same result), so now I suspect the AM26LS32 RS423
driver to be the culprit.
I uploaded some pictures to
http://s1372.photobucket.com/user/michaelengel/library/Codata?sort=3&page=1
- there you can see that this machine is far from being in any sort of
original condition. Nevertheless, it's great to see it come alive again!
Btw., current versions of MAME/MESS include a rudimentary Codata
simulator. This doesn't do very much so far, but it can successfully run
the firmware ROM code (picture also uploaded to photobucket).
Best wishes,
Michael
[View Less]
On 2014-10-07 03:00, norman(a)oclsc.org (Norman Wilson) wrote:
>
> The 11/70 service manual is all good, but it's definitely not enough.
> Ideally, you should have access to the full drawings, the service manual
> for the CPU, the service manual for the memory subsystem, I seem to
> remember that the FP11 has its own service manual, and I think the
> massbus interface also has its own documentation set.
> Also, the memory system consists of both the …
[View More]Unibus map, the cache and
> memory bus system, and they you have separate documentation for the
> memory boxes (either MJ11 or MK11 box).
>
> It might be worth while to contact the Living Computer Museum.
> I forget whether they have an 11/70 running or just an 11/45,
> but I do know that they collect all the documentation they can
> get for old computers--I saw the room where they store it.
> Whenever they need to use it, or there's some other need to
> access it, they try to make time to scan it, so the precious
> copy can stay in the archive room.
LCM have atleast one 11/70 running. Although they are not really doing
anything fun on it. I hope to maybe help them with that next time I'm
there. I can't remember seeing any 11/45 running, but I'm pretty sure
there are some in their storage if nothing else...
I'm not going to try dragging a lot of documentation from Sweden to
Seattle, though (I'm not even in Sweden myself lots of the time). On the
other hand, I know they have plenty of documentation, so I would hope
they (and/or CHM) already have most of it.
> Since their goal is to have ancient computers actually
> running, they are certainly interested in having all the
> documents (even if you can't get the wood, as Warren might
> remark at this point), including full engineering drawings.
>
> It's also a neat place to visit if you have some free time in
> Seattle. I'm disappointed to have figured out that, although
> I'll be in Seattle for a conference in about a month, I won't
> be able to visit LCM while they're open unless I skip some
> conference sessions ... or unless I can convince them to open
> up specially. Anyone else on this list planning to attend
> LISA and interested in visiting a museum of old running
> computers?
I know of the place, and have known Rich Alderson for a long time.
It is a fun place, and I could see myself working there, if I just had
the right offer. Don't expect that to happen, though...
I'll be there for different reasons in about a month from now. But my
weekends are free... :-)
Johnny
[View Less]
Also, I had this e-mail sent to me from Jacob who is a long-time TUHS
person. Again, he has questions I don't know the answers to. Anybody?
Cheers, Warren
----- Forwarded message from Jacob Ritorto -----
Greetings Warren,
 It's been decades since we last corresponded and I'm delighted to
see that you're still active in the pdp11 unix community! I've found
some free time and have been kicking around the idea of repairing
the11/45 I scored some years ago (11/45 system number …
[View More]273 from Stanford
University) and installing 2.9bsd on it. You helped me out years ago
when I had an 11/34 and I managed to do it back then, so I have some
hope this time around too, though there are some more serious hurdles
now. Glad to see that a lot of the license trolling finally appears
to be settled and we can have unfettered access to all the good stuff!
Â
 Any pointers to who
has parts and troubleshooting knowledge would be a big help.
 Softwarewise, I was also thinking I'd like to get my Fuji160 disks
working on the machine. Has work like this been done already, or
would you have pointers as to how to go about it?
  Also, has anyone written a miniature httpd for any of the ancient
bsds?
thanks
jake
----- End forwarded message -----
[View Less]
The 11/70 service manual is all good, but it's definitely not enough.
Ideally, you should have access to the full drawings, the service manual
for the CPU, the service manual for the memory subsystem, I seem to
remember that the FP11 has its own service manual, and I think the
massbus interface also has its own documentation set.
Also, the memory system consists of both the Unibus map, the cache and
memory bus system, and they you have separate documentation for the
memory …
[View More]boxes (either MJ11 or MK11 box).
It might be worth while to contact the Living Computer Museum.
I forget whether they have an 11/70 running or just an 11/45,
but I do know that they collect all the documentation they can
get for old computers--I saw the room where they store it.
Whenever they need to use it, or there's some other need to
access it, they try to make time to scan it, so the precious
copy can stay in the archive room.
Since their goal is to have ancient computers actually
running, they are certainly interested in having all the
documents (even if you can't get the wood, as Warren might
remark at this point), including full engineering drawings.
It's also a neat place to visit if you have some free time in
Seattle. I'm disappointed to have figured out that, although
I'll be in Seattle for a conference in about a month, I won't
be able to visit LCM while they're open unless I skip some
conference sessions ... or unless I can convince them to open
up specially. Anyone else on this list planning to attend
LISA and interested in visiting a museum of old running
computers?
Norman Wilson
Toronto ON
[View Less]
On 2014-10-05 03:00, Dave Horsfall<dave(a)horsfall.org> wrote:
>
> On Sat, 4 Oct 2014, Noel Chiappa wrote:
>
>> >Anyone seriously working on bringing old hardware back to life needs to
>> >get in touch with the Classic Computer Talk list:
> Is John Dodson on this list? He has an 11/70 in his house.
No idea. I occasionally scan cctalk, but most of the time don't bother.
Too much noise and irrelevant or ignorant posts. However, unfortunately
I don't have …
[View More]any better suggestions where to go if you are trying to
restore old hardware and don't have enough knowledge.
And yes, I keep lots of different PDP-8, PDP-11 and VAXen running,
including 11/70 systems.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
[View Less]
On Sun, Oct 5, 2014, at 13:47, Jacob Ritorto wrote:
> awesome, man, thanks. If I fork tinyhttpd on github, mind if I use 'em?
> I'll attribute to you of course If ok, any license preference? I
> usually
> use MIT..
tinyhttpd itself is not mine and appears to be under the GPL.
On Sat, Oct 4, 2014, at 12:37, Jacob Ritorto wrote:
> nice. may i see your difffs?
>
> On Sat, Oct 4, 2014 at 4:06 AM, <random832(a)fastmail.us> wrote:
> >
> > Seeing this question, I figured "it can't be that hard", and managed to
> > get tinyhttpd http://tinyhttpd.sourceforge.net/ to compile on 2.11BSD.
> > Mostly just required K&R-ification, though I also had to fix some bugs
> > in the way it uses buffers to get it to work at all. Normal …
[View More]GET requests
> > work; The whole CGI thing I disabled because I couldn't get it to work
> > reliably even on modern linux.
> >
> > Not actually tested, though - I couldn't get simh to emulate a network
> > device.
Sure.
Security note: the httpd itself doesn't appear to do anything about e.g.
".." in pathnames, and I didn't do anything about that.
[View Less]
Some guy on eBay has a flock of RL02 drives available (in New York, USA) for a
pretty reasonable price:
http://www.ebay.com/itm/261288230510
I just bought a flock of them, and they are in very good condition. They were
only recently withdrawn from service (at the FAA, so they were professionally
maintained up until they went), and were properly prepared for moving (heads
immobilized, _and_ the motor was locked down - very rare to see that last
step, as is involves finding the right machine …
[View More]screws - or having saved them).
They are late-production ones, too (looked, but couldn't find a date) - they
have the anti-RFI/EMI 'finger' strips (the kind that make a pressure-loaded
contact with the incoming connector shell), which I personally had never seen
on any RL0x drives.
Alas, they have no packs or terminators available, nor cables or slides (any
more :-). But other than that, recommended.
Noel
[View Less]
