> 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
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
> 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 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
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 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
> 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:
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
> 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 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
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 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
> 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://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
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
