DECUS tape image archives/simulator refs
Tim Shoppa
the crowd!) some changes to the PDP-10 home page at
http://pdp-10.trailing-edge.com/
First of all, some tape images have been made available for some
of the DECUS 10- and 20- library entries. These tapes are *not*
complete, but I hope they are useful to those wanting to use
binaries under emulators. The tape images are directly accessible
through the new links, or through
ftp://ftp.trailing-edge.com/pub/lib10/
and
ftp://ftp.trailing-edge.com/pub/lib20/
.
Secondly, the references in the Emulator section have been
modernized for the 21st century to include a link to the TS10
project page and Bob Supnik's SIMH page. There's also a
mysterious reference added which indicates that there is very
solid chance that yet another emulator - promising to be more
full-featured and with nice things like NI20 networking - will
be available to the public soon.
As always, if you have any material which you would like to
be put into the public PDP-10 archives, please contact me via
E-mail and we'll figure out how to get it done.
Tim. (sho...@trailing-edge.com)
Zane H. Healy
> project page and Bob Supnik's SIMH page. There's also a
> mysterious reference added which indicates that there is very
> solid chance that yet another emulator - promising to be more
> full-featured and with nice things like NI20 networking - will
> be available to the public soon.
How about a nice juicy titbit like what it runs on?
Thanks for getting the DECUS images up, that'll be a big help! Can't wait
to get them downloaded and restored on my system!
BTW, one thing that would be really nice on the
http://pdp-10.trailing-edge.com/ page is a link to where you've got the
TOPS-10 V7.04 doc's. I keep having to go to DejaNews to find it. Oh, and
it's not just TS-10 that uses the .TAP files, simh uses them as well.
Zane
Arthur Krewat
>
> First of all, some tape images have been made available for some
> of the DECUS 10- and 20- library entries. These tapes are *not*
> complete, but I hope they are useful to those wanting to use
> binaries under emulators. The tape images are directly accessible
> through the new links, or through
>
> ftp://ftp.trailing-edge.com/pub/lib10/
Hey, what about:
http://pdp-10.trailing-edge.com/www/lib10/0126
:)
ALGOL is something I want very much...
besides that, THANK YOU for everything you've done to date.
aak
Tim Shoppa
>
>Tim Shoppa <sho...@trailing-edge.com> wrote:
>> project page and Bob Supnik's SIMH page. There's also a
>> mysterious reference added which indicates that there is very
>> solid chance that yet another emulator - promising to be more
>> full-featured and with nice things like NI20 networking - will
>> be available to the public soon.
>
>How about a nice juicy titbit like what it runs on?
If everything goes according to plan, the sources will be available, and
it's already known to work on several Unix-type platforms.
>Thanks for getting the DECUS images up, that'll be a big help!
Problem is, that they're not everything, so we are still dependendent on the
individual files that I've had available for the past couple of years.
I still have to either fix up the web server so that it knows how to serve
36-bit files, or simply put the binaries on the FTP machine. (It *is* handy
that several search engines have already indexed the ASCII DECUS files.)
And I know I ask this every couple of months, but maybe this time someone
who knows will listen: *Is* there a MIME type for 36-bit binaries?
>BTW, one thing that would be really nice on the
>http://pdp-10.trailing-edge.com/ page is a link to where you've got the
>TOPS-10 V7.04 doc's.
True, the "website full of text and html and PDF docs" is another half-baked
project of mine that is just waiting for me to get two or three hours of
uninterrupted time. When that time comes, it'll become a fully-baked
project :-)
Tim.
Neil Franklin
> >Thanks for getting the DECUS images up, that'll be a big help!
>
> I still have to either fix up the web server so that it knows how to serve
> 36-bit files, or simply put the binaries on the FTP machine. (It *is* handy
> that several search engines have already indexed the ASCII DECUS files.)
>
> And I know I ask this every couple of months, but maybe this time someone
Never noticed it up to now. Good you today just picked a day when I
have a bit of time free.
> who knows will listen: *Is* there a MIME type for 36-bit binaries?
No there is not. I just went and looked at the official standards
document (thats what the time got used for), RFC2045, at
http://www.faqs.org/rfcs/rfc2045.html
This sniplet says it all:
-------------
6. Content-Transfer-Encoding Header Field
Many media types which could be usefully transported via email are
represented, in their "natural" format, as 8bit character or binary
data.
..
It is necessary, therefore, to define a standard mechanism for
encoding such data into a 7bit short line format.
..
mechanism := "7bit" / "8bit" / "binary" /
"quoted-printable" / "base64" /
ietf-token / x-token
-------------
So MIME seems to have been invented as an n*8bit world only.
But we do have an possibility, as they left the back door open:
-------------
6.3. New Content-Transfer-Encodings
Implementors may, if necessary, define private Content-Transfer-
Encoding values, but must use an x-token, which is a name prefixed by
"X-", to indicate its non-standard status, e.g., "Content-Transfer-
Encoding: x-my-new-encoding".
-------------
So what about making such an extension, like when formats for storing
tape images in 8bit files got defined? Multiple possible implementations
come to mind:
1) send 36bit on 8bit channels as 2*36bit in 9*8bit. If there is a
single 36bit left over pad it with 4 or 36 zero bits. This seems to
be what FTP does in Image mode, if I get RFC354 right. Call this
version x-36bit (or x-6bit analog to 8bit for n*8bit data).
For mails this poses a problem because it will need to be additionally
base64-ed, making it one encoding in an other.
2) send 12/18/24/36bit data as n times 6bits each packed in one ASCII
char. Call this version x-6base64. This is more universal and already
mail compatible. But it is inefficient for HTTP/Web.
As coding for the latter one could use that used in base64, which
first does 3*8->4*6bit and then stuffs each 6bit into one ASCII.
The table for this from RFC2045:
-------------
Table 1: The Base64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
The encoded output stream must be represented in lines of no more
than 76 characters each.
-------------
4) define both 1) and 2) for HTTP/Web and Mail respectively, just like
there exist 8bit and base64 for n*8bit machines in these 2 circumstances.
3) no new encoding at all. Simply make an standard 36bit in 8bit
file format, like with (derived from?) the 36bit in 8bit tape
container formats and then use an normal 8bit web server.
This method would just use the file ending and resulting MIME
Content-Type: for controlling the whole process.
Note that in addition to an Content-Transfer-Encoding: we will any way
need additional Content-Type: entries for the typical files. Looking
at RFC2046 we will have to use application/* types. I suggest:
application/x-sixbit for SIXBIT text
text/* is not allowed for this, as that hast to be ASCII derived
application/x-sextet-stream for non-specified n*6bit binaries
analog to the official octet-stream for n*8bit
application/x-tops10-exe for TOPS-10 .EXE, TOPS-20 analog
same also for all other file types, object files, ...
this analog to some of the x- types on the SGI machine I looked at
There is also an RFC2048 which describes the procedure for having
types added as official extensions to MIME. So if we design a standard
we could even have it officially blessed.
--
Neil Franklin, ne...@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery
Rich Alderson
> And I know I ask this every couple of months, but maybe this time someone
> who knows will listen: *Is* there a MIME type for 36-bit binaries?
There's even a good 7-bit-safe way to encode them, at an expansion of 6 bits
per word: 6-bit bytes + 40 octal (and possibly ` for <space>) yields only
printable ASCII characters.
How do we get a MIME type enacted?
--
Rich Alderson alders...@panix.com
"You get what anybody gets. You get a lifetime." --Death, of the Endless
Tim Shoppa
> Tim Shoppa <sho...@trailing-edge.com> writes:
> > who knows will listen: *Is* there a MIME type for 36-bit binaries?
>
> document (thats what the time got used for), RFC2045, at
> 3) no new encoding at all. Simply make an standard 36bit in 8bit
> file format, like with (derived from?) the 36bit in 8bit tape
> container formats and then use an normal 8bit web server.
As much as I like tape images, this doesn't really solve the
problem. Creating a DUMPER or INTERCHANGE saveset for each
and every file seems to defeat the convenience.
As to the other solutions, I think any of them could work just
fine.
> There is also an RFC2048 which describes the procedure for having
> types added as official extensions to MIME. So if we design a standard
> we could even have it officially blessed.
And independently Rich Alderson asked:
> How do we get a MIME type enacted?
It seems pretty clear to me that if we ever get a 36-bit based
web browser up and going, that a MIME type will become a
necessity. My reading of RFC2048 says we can start a "x-"
(for experimental) MIME type all of our own, but we have some
convincing to do if we want it to become an official IETF-
approved MIME type:
Registration in the IETF tree requires approval
by the IESG and publication of the media type registration as some
form of RFC.
Tim.
Neil Franklin
> Neil Franklin wrote:
> > Tim Shoppa <sho...@trailing-edge.com> writes:
> > > who knows will listen: *Is* there a MIME type for 36-bit binaries?
> >
> > No there is not... I just went and looked at the official standards
> > [...]
> > 3) no new encoding at all. Simply make an standard 36bit in 8bit
> > file format, like with (derived from?) the 36bit in 8bit tape
> > container formats and then use an normal 8bit web server.
>
> As much as I like tape images, this doesn't really solve the
> problem. Creating a DUMPER or INTERCHANGE saveset for each
> and every file seems to defeat the convenience.
That version is definitely the mose user hostile.
> As to the other solutions, I think any of them could work just
> fine.
Technically I prefer the mixed 1+2, because it is the correct
approach. It is also on-the-fly without user work involved. But it
is of course the most programmer work. But there again, AFAIK that
is the PDP-10 way of life, to do it the proper way, not force the
users to sweat it out (like say Unix).
> > There is also an RFC2048 which describes the procedure for having
> > types added as official extensions to MIME. So if we design a standard
> > we could even have it officially blessed.
>
> And independently Rich Alderson asked:
>
> > How do we get a MIME type enacted?
>
> It seems pretty clear to me that if we ever get a 36-bit based
> web browser up and going, that a MIME type will become a
> necessity.
Or 2, one for web (8bit data channel) and one for mail (not quite
7bit data channel, ASCII 32-126).
> My reading of RFC2048 says we can start a "x-"
> (for experimental) MIME type all of our own,
Yes.
> but we have some
> convincing to do if we want it to become an official IETF-
> approved MIME type:
>
> Registration in the IETF tree requires approval
> by the IESG and publication of the media type registration as some
> form of RFC.
Writing an RFC anyone can do. Approval has the reputation of being
fairly easy if it is a sensibly worked out and clearly written
proposal with no "toxic" side effects on the standards. But even
without IESG approval one can use it as informal standard, just like
TAP and .TPC archives are.
Usual way is to implement something, test it, refine it, document it
as RFC, and then have it approved. The RFC stays valid even if it is
not made part of the recommended implementation.
Web server and browser on TOPS-n0 anyone? Particularly a browser in
256kWord may make porting existing Unix stuff impossible.
Of course we first need network connection for any of the above to
make sense.
Ben Franchuk
> Web server and browser on TOPS-n0 anyone? Particularly a browser in
> 256kWord may make porting existing Unix stuff impossible.
>
They have browsers in DOS. The question is there a high res graphic display
that was used with the 10? Ben.
Arthur Krewat
VT240's come to mind, but at a max if 19200 baud, you're pissing in the
wind :) Maybe an emulated one would work...
Wasn't the Foonly attached to some huge display they took photos of to
create animation?
Anything at this point is going to be simulated - why not just map an
X-window and create a dummy UNIBUS device - say 1024x768 at 24-bit color?
With the speed of today's processors, even a simulated UNIBUS device will
probably exceed the bandwidth of a real UNIBUS :)
Personally, I don't think anyone should waste their time getting a browser
working for TOPS-10 - if anything, maybe an FTP client - I've been thinking
about what it would take to get DECNET working...
aak
Kevin Handy
>
> VT240's come to mind, but at a max if 19200 baud, you're pissing in the
> wind :) Maybe an emulated one would work...
xterm has a TekTronics mode. You could always use that for simple
graphics.
> Wasn't the Foonly attached to some huge display they took photos of to
> create animation?
>
> Anything at this point is going to be simulated - why not just map an
> X-window and create a dummy UNIBUS device - say 1024x768 at 24-bit color?
> With the speed of today's processors, even a simulated UNIBUS device will
> probably exceed the bandwidth of a real UNIBUS :)
Is there the possibility getting a TCPIP stack to work and then
porting X11? I wouldn't think it would be any harder than creating a
fake unibus graphics device and then writing software to handle it.
This would also make the work useful to a real PDP-10.
It would probably require a working C compiler to use Xfree, or else
someone who wants to rewrite X11. You wouldn't need to drive a local
display, so you wouldn't need to do any device drivers/display
emulators, just the client code.
You would need a TCPIP stack to access the web anyway (a browser that
doesn't have anything to browse wouldn't be very interesting).
Neil Franklin
> Ben Franchuk wrote:
> >
> > Neil Franklin wrote:
> > >
> > > Tim Shoppa <sho...@trailing-edge.com> writes:
> >
> > > Web server and browser on TOPS-n0 anyone? Particularly a browser in
> > > 256kWord may make porting existing Unix stuff impossible.
> > >
> > They have browsers in DOS.
True. 256kW is about 1MByte. And the MS-DOS ones fit in 640k.
Arache on an 10, hmmm.
> > The question is there a high res graphic display
> > that was used with the 10? Ben.
>
> VT240's come to mind,
According to an book by the inventors of X, they originally had a
terminal called VS100. No clue what abilities it had, as all my web
searches only lead to some non-DEC minicomputer called VS100.
Anyone got any info on this terminal type? Details for emulating it.
Newsflash: Just went again on a web search (to find what mini that
was) and promptly found DECs VS100. It is/was the VAXstation 100
graphics display. but still no feature/ability listing or even
manual.
And yes, I also found the other VS100: Wang VS100 minicomputer.
> but at a max if 19200 baud, you're pissing in the
> wind :) Maybe an emulated one would work...
You do not need to emulate the slow speed, just the RS232 interface
and VT240/340 or GiGi/VK100 command sequences :-). Perhaps with an
fast/original speed flag for added realism.
One web site says something about VS100 having an 68000 in it and an
fiber optical link to the VAX/Unibus.
> Wasn't the Foonly attached to some huge display they took photos of to
> create animation?
Would that not have been an vector display film writer? At least the
pictures in Tron suggest this.
> Anything at this point is going to be simulated - why not just map an
> X-window and create a dummy UNIBUS device - say 1024x768 at 24-bit color?
Or even variable size, depending on what the user resizes it to. With
-geometry to set the initial size.
And no need for an Unibus device. Just make an set of escape sequences
behind an RS232 port. Special device would just be a little faster,
but limit browsing to one user, not allowing others comming in over
RS232/net.
OTOH the VS100 has an Unibus interface according to one website, so
one could implement that in an KS-10 emulator.
> With the speed of today's processors, even a simulated UNIBUS device will
> probably exceed the bandwidth of a real UNIBUS :)
Definitely.
> Personally, I don't think anyone should waste their time getting a browser
> working for TOPS-10
Hmm, hack value?
Or freeing from lousy OSes? Ever thought of an PC running simh or
TS-10 directly on an minimal OS that gets out of the way (say MS-DOS
or its clones) as ones daily mail/news/surf machine.
OK, I am getting carried away...
> I've been thinking
> about what it would take to get DECNET working...
Will probably need DECnet on the host, so that you have someone else
to talk to. OK, those with VAXen or Alphas with VMS have that.
--
Neil Franklin, ne...@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Intellectual Property is Intellectual Robbery
roperty is Intellectual Robbery
Zane H. Healy
> Arthur Krewat <kre...@bartek.dontspamme.net> writes:
>> Ben Franchuk wrote:
>> > They have browsers in DOS.
> True. 256kW is about 1MByte. And the MS-DOS ones fit in 640k.
> Arache on an 10, hmmm.
There is a Web Browser for the Commodore 64, however, it requires a UNIX
shell account in which you can run some kind of filter program, IIRC.
> One web site says something about VS100 having an 68000 in it and an
> fiber optical link to the VAX/Unibus.
I've found little data on the VS100, one of my VAX books mentions it
briefly, from what I understand it basically turned a VAX-11/780, and maybe
a VAX-11/750 into a single user workstation (ouch). I don't know if you
could hook more than one VS100 up to a system. So far I've not found any
pictures of the device (I'd love to know what it looked like). Basically
the only thing I've found is that a fiberoptic cable went between it and a
Interface card in the VAX.
Also I think thier were Unibus video cards available for the PDP-11, I know
there were at least two of them available for Q-Bus PDP-11's, and at least 2
others for Q-Bus VAXen. Finding PDP-11 graphics cards is rather hard
though.
>> Personally, I don't think anyone should waste their time getting a browser
>> working for TOPS-10
> Hmm, hack value?
For the fun of it :^) One of these days I'd like to get a minimal web
browser running on RT-11 (there is already a free TCP/IP stack).
Now my question is, why is everyone in this thread concerned with getting
graphics displayed? On OpenVMS my main web browser is 'lynx'.
>> I've been thinking
>> about what it would take to get DECNET working...
> Will probably need DECnet on the host, so that you have someone else
> to talk to. OK, those with VAXen or Alphas with VMS have that.
Actually, for those that are running either ts10 or simh on Linux, they can
run DECnet on that system, as there is a free DECnet implementation for
Linux. It works great talking to systems running OpenVMS, but last I
checked (probably a year or two ago) it was still having trouble talking to
PDP-11's, and no one had even considered using it to talk to a PDP-10 as far
as I know.
Perhaps another solution will be available once Tim finishes his VAX-11/780
emulation. Move data between the PDP-10 and the VAX using DECnet, and the
VAX and other systems using TCP/IP.
I've been looking into the DECnet side myself as I'd like to eventually be
able to use it. I'm seeing two *major* problems, one is a lack of
documentation (trying to figure out DECnet configuration without Doc's would
probably be a real nightmare), but the even bigger problem is the files on
the tape appear to be encrypted.
Zane
Jim Thomas
Neil> Arthur Krewat <kre...@bartek.dontspamme.net> writes:
>> Ben Franchuk wrote:
>> >
>> > Neil Franklin wrote:
>> > >
>> > > Tim Shoppa <sho...@trailing-edge.com> writes:
>> >
>> > > Web server and browser on TOPS-n0 anyone? Particularly a browser in
>> > > 256kWord may make porting existing Unix stuff impossible.
>> > >
>> > They have browsers in DOS.
>> > The question is there a high res graphic display
>> > that was used with the 10? Ben.
>>
>> VT240's come to mind,
Say what? The 4014 was 4096x4096 :-) That's higher resolution than
anything I have :-) Plus it had real vectors :-) Oh, you meant directly
connected? 2400 baud WAS "directly connected" back then :-)
Neil> ...
Neil> Or freeing from lousy OSes? Ever thought of an PC running simh or
Neil> TS-10 directly on an minimal OS that gets out of the way (say MS-DOS
Neil> or its clones) as ones daily mail/news/surf machine.
Neil> OK, I am getting carried away...
Like DJGPP :-)
Nothead
Christopher Stacy
Neil> According to an book by the inventors of X, they originally had a
Neil> terminal called VS100. No clue what abilities it had, as all my web
Neil> searches only lead to some non-DEC minicomputer called VS100.
Neil> Anyone got any info on this terminal type? Details for emulating it.
Neil> Newsflash: Just went again on a web search (to find what mini that
Neil> was) and promptly found DECs VS100. It is/was the VAXstation 100
Neil> graphics display. but still no feature/ability listing or even manual.
The VS100 was a Motorolla 68000 box doing 1280x1024 bitmapped display
onto a monochrome monitor. It was connected by a 1-Mbit fiber-optic
cable to a UNIBUS card on the host VAX-11/750.
Here's a source code file I found online for the driver:
http://hccc.ee.ccu.edu.tw/courses/com_prot/2001/HTML/S/vax%20uba%20vs.c.html
jmfb...@aol.com
Neil Franklin <ne...@franklin.ch.remove> wrote:
>Arthur Krewat <kre...@bartek.dontspamme.net> writes:
>> Personally, I don't think anyone should waste
>>their time getting a browser
>> working for TOPS-10
>
>Hmm, hack value?
A must for anybody who runs a PDP-10.
>
>Or freeing from lousy OSes? Ever thought of an PC running simh or
>TS-10 directly on an minimal OS that gets out of the way (say MS-DOS
>or its clones) as ones daily mail/news/surf machine.
>
>OK, I am getting carried away...
No!!!! You're going in the right direction. ;-)
>
>
>> I've been thinking
>> about what it would take to get DECNET working...
>
>Will probably need DECnet on the host, so that you have someone else
>to talk to. OK, those with VAXen or Alphas with VMS have that.
There may be a slight problem of DECnet Phases not talking to
each other. There were plans to not support communication to
Phase III DECnets. So, if you do more than think about it,
forget about the MCB stuff and concentrate on the Phase IV
stuff (which is the ethernet). You might have to have a CPU
dedicated to do the DECnet mumbo-jumbo. Also it would probably
be a good idea to use the KL as an end node rather than a router.
Bill wanted to finish the end node stuff on the KS but never
got any time to do that (I think I've got that straight...I could
never remember what the default (router or end-node) was.
/BAH
Subtract a hundred and four for e-mail.
jmfb...@aol.com
"Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
<snip>
>I've been looking into the DECnet side myself as I'd like to eventually be
>able to use it. I'm seeing two *major* problems, one is a lack of
>documentation (trying to figure out DECnet configuration
>without Doc's would
>probably be a real nightmare),
Or you could read the code.
> ...but the even bigger problem is the files on
>the tape appear to be encrypted.
What!!!!????!!!!! I didn't encrypt them.
Arthur Krewat
>
> There may be a slight problem of DECnet Phases not talking to
> each other. There were plans to not support communication to
> Phase III DECnets. So, if you do more than think about it,
> forget about the MCB stuff and concentrate on the Phase IV
> stuff (which is the ethernet). You might have to have a CPU
> dedicated to do the DECnet mumbo-jumbo. Also it would probably
> be a good idea to use the KL as an end node rather than a router.
> Bill wanted to finish the end node stuff on the KS but never
> got any time to do that (I think I've got that straight...I could
> never remember what the default (router or end-node) was.
>
End-node was the default for the VAX's I've done. Router was
be more complex, needing a different (and seemingly more expensive)
license PAK.
I would imagine that the end-node stuff was done for the KS, and if
anything the router stuff would not have been completed. Of course,
customers may have had other priorities... :)
aak
Frank da Cruz
Neil Franklin <ne...@franklin.ch.remove> wrote:
: Arthur Krewat <kre...@bartek.dontspamme.net> writes:
: > > The question is there a high res graphic display
: > > that was used with the 10? Ben.
: >
: > VT240's come to mind,
[Web browsers etc...]
I don't see what the point is of loading up the emulated PDP-10 with
all the modern commercial-grade mass-market junk. The authentic way
to do graphics on the -10 or -20 is with graphics software like
DISSPLA/TELL-A-GRAPH driving a Tektronix or other graphics terminal
(including maybe a GIGI or various VT terminals with Sixel capability),
a pen plotter, or a dot-matrix printer capable of graphics (e.g. the
Printronix P600, or maybe the LA34, LA50, or LA100).
Maybe there were some genuine, bus-attached, native graphics devices
on PDP-10s, like there were on some of the other PDP-x's and -xx's,
with light pens, etc.
If a TOPS-10 or TOPS-20 TCP/IP stack could be supplied with the emulator,
then you get the FTP, mail, Telnet and other TCP clients for free.
If might be interesting to try to port Lynx for Web browsing, but in
my experience C never mixed well with 36 bits.
- Frank
Arthur Krewat
>
> [Web browsers etc...]
>
> I don't see what the point is of loading up the emulated PDP-10 with
> all the modern commercial-grade mass-market junk.
Something ELSE we both agree on!
aak
Rich Alderson
> If a TOPS-10 or TOPS-20 TCP/IP stack could be supplied with the emulator,
> then you get the FTP, mail, Telnet and other TCP clients for free.
> If might be interesting to try to port Lynx for Web browsing, but in
> my experience C never mixed well with 36 bits.
There is a Tops-20 port of Lynx which works well enough.
Indeed, C has not, in the past, mixed well with 36 bits, though Dick Helliwell
managed to port Perl 4.036, X11R4, GNU Emacs, and the GNU utilities to Tops-20
using KCC.
Lars Brinkhoff is working on a port of GCC to Tops-20.
I wish *someone* could find a copy of the CMU Tops-10 TCP/IP implementation.
Frank da Cruz
Rich Alderson <alders...@panix.com> wrote:
: f...@watsun.cc.columbia.edu (Frank da Cruz) writes:
:
: > If a TOPS-10 or TOPS-20 TCP/IP stack could be supplied with the emulator,
: > then you get the FTP, mail, Telnet and other TCP clients for free.
: > If might be interesting to try to port Lynx for Web browsing, but in
: > my experience C never mixed well with 36 bits.
:
: There is a Tops-20 port of Lynx which works well enough.
Well, there you go!
: Indeed, C has not, in the past, mixed well with 36 bits, though Dick
: Helliwell managed to port Perl 4.036, X11R4, GNU Emacs, and the GNU
: utilities to Tops-20 using KCC.
:
I tried some of these on TOAD recently. I thought maybe I could gzip and
uuencode a 36-bit binary (i.e. KERMIT.EXE, to reduce the bootstrapping
burden) but no dice. I guess in this case it's not so much C and 36-bits
not agreeing, but the semantics of the programs themselves at runtime. They
only want to deal with 8-bit date bytes. Kind of like how PDP-10 programs
only want to deal with 7-bit date bytes (HRROI A, ASCIZ /..../).
I do think we need something like gzip/uuencode for encoding 36-bit binaries
in ASCII. I've done this sort of thing lots of times and would do it again
if I had the time...
- Frank
Timothy Stark
> I wish *someone* could find a copy of the CMU Tops-10 TCP/IP implementation.
Let us know that. We still am looking for that. :-)
-- Tim Stark
--
Timothy Stark <>< Inet: swo...@speakeasy.org
--------------------------------------------------------------------------
"For God so loved the world, that he gave his only begotten Son, that
whosoever believeth in him should not perish, but have everlasting life.
Amen." -- John 3:16 (King James Version Bible)
Tim Shoppa
>
>f...@watsun.cc.columbia.edu (Frank da Cruz) writes:
>
>> If a TOPS-10 or TOPS-20 TCP/IP stack could be supplied with the emulator,
>> then you get the FTP, mail, Telnet and other TCP clients for free.
>> If might be interesting to try to port Lynx for Web browsing, but in
>> my experience C never mixed well with 36 bits.
>
>There is a Tops-20 port of Lynx which works well enough.
*Very* interesting. Which C compiler was it built under, and where
are the Lynx sources that work under Tops-20 available from? I just
poked around lynx.browsers.org and didn't see anything promising...
Tim.
Zane H. Healy
> In article <j5387.230$4H4.2...@e3500-chi1.usenetserver.com>,
> "Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
>>able to use it. I'm seeing two *major* problems, one is a lack of
>>documentation (trying to figure out DECnet configuration
>>without Doc's would
>>probably be a real nightmare),
> Or you could read the code.
That could be a problem two, though a good learning experience :^)
>> ...but the even bigger problem is the files on
>>the tape appear to be encrypted.
> What!!!!????!!!!! I didn't encrypt them
Are you able to look at the files on Tim Shoppa's site? I can't remember.
The following URL points to what's on the DECnet tape.
http://pdp-10.trailing-edge.com/pdp-10/DECNET-10_V4_0_SUP_BB-X116C-BB.HTML
All the files except the *.KEY files and the *.EXE predate 7.03 by a few
months. The *.KEY files and the *.EXE files were obviously generated
for 7.04.
Question. Did a majority of the DECnet software run on a PDP-11 (the
frontend?), most of the files on the tape really look to be for RSX to me.
With the really odd part being the RSX11S.TSK file. This makes me suspect
something like a dedicated Front-End Network processor.
Zane
Ben Franchuk
> I tried some of these on TOAD recently. I thought maybe I could gzip and
> uuencode a 36-bit binary (i.e. KERMIT.EXE, to reduce the bootstrapping
> burden) but no dice. I guess in this case it's not so much C and 36-bits
> not agreeing, but the semantics of the programs themselves at runtime. They
> only want to deal with 8-bit date bytes. Kind of like how PDP-10 programs
> only want to deal with 7-bit date bytes (HRROI A, ASCIZ /..../).
I suspect the problem is 99% of the C programs assume 2 or 4 Bytes = 1 word
of data and use memory refernces rather than shifting to extract/store bytes.
Ben.
Neil Franklin
> Arthur Krewat wrote:
> >
> > VT240's come to mind, but at a max if 19200 baud, you're pissing in the
> > wind :) Maybe an emulated one would work...
>
> xterm has a TekTronics mode. You could always use that for simple
> graphics.
Vector....
That will require writing an browser from scratch.
> > Anything at this point is going to be simulated - why not just map an
> > X-window and create a dummy UNIBUS device - say 1024x768 at 24-bit color?
> > With the speed of today's processors, even a simulated UNIBUS device will
> > probably exceed the bandwidth of a real UNIBUS :)
>
> Is there the possibility getting a TCPIP stack to work and then
> porting X11? I wouldn't think it would be any harder than creating a
> fake unibus graphics device and then writing software to handle it.
Very hard. X is _large_ code.
> It would probably require a working C compiler to use Xfree, or else
That is in the works, gcc port.
> someone who wants to rewrite X11.
That is an awfully big piece of code to rewrite.
> You wouldn't need to drive a local
> display, so you wouldn't need to do any device drivers/display
> emulators, just the client code.
Client only would work for an emulator. But latest with an FPGA clone
you will want something native.
> You would need a TCPIP stack to access the web anyway (a browser that
> doesn't have anything to browse wouldn't be very interesting).
Simple user level SLIP or PPP (Internet over RS232) like in the MS-DOS
TCP/IP packages would be enough for that. Kernel level would of course
be better.
Neil Franklin
> Neil Franklin <ne...@franklin.ch.remove> wrote:
>
> > One web site says something about VS100 having an 68000 in it and an
> > fiber optical link to the VAX/Unibus.
>
> I've found little data on the VS100, one of my VAX books mentions it
> briefly, from what I understand it basically turned a VAX-11/780, and maybe
> a VAX-11/750 into a single user workstation (ouch). I don't know if you
> could hook more than one VS100 up to a system. So far I've not found any
IIRC Gordon Bell mentioned an 2 workstations on VAX system. I think
that would have been the VS100.
> pictures of the device (I'd love to know what it looked like). Basically
> the only thing I've found is that a fiberoptic cable went between it and a
> Interface card in the VAX.
That I have also found.
> >> Personally, I don't think anyone should waste their time getting a browser
> >> working for TOPS-10
>
> > Hmm, hack value?
>
> Now my question is, why is everyone in this thread concerned with getting
> graphics displayed? On OpenVMS my main web browser is 'lynx'.
You are right there.
But graphics are somewhat cooler :-). Definitely more impressive.
Neil Franklin
> In article <6ug0bjl...@chonsp.franklin.ch>,
> Neil Franklin <ne...@franklin.ch.remove> wrote:
> >
> >Or freeing from lousy OSes? Ever thought of an PC running simh or
> >TS-10 directly on an minimal OS that gets out of the way (say MS-DOS
> >or its clones) as ones daily mail/news/surf machine.
> >
> >OK, I am getting carried away...
>
> No!!!! You're going in the right direction. ;-)
Well then you will like my FPGA 10 even better. No PC or minimal OS,
just TOPS-10/20 directly on the raw hardware.
And I am following this thread as part of deciding what display
capabilities (Tek/Sixel/Regis/VS100/own) are going to go in, so
that mail/news/surf is possible.
And yes, that requires graphics. I am used to 1536x1152x32bit with
80x67 mail/newsreader and terminal windows and 640x1050 pixel web
browsers :-).
Inofficial target is to be doing that by 2004 when the PDP-6 has its
40th birthday, or even 2003 when KA-10 has its 36th.
John Sauter
"Maybe there were some genuine, bus-attached, native
graphics devices on PDP-10s, like there were on some
of the other PDP-x's and -xx's, with light pens, etc."
The PDP-6/KA10 system at Stanford had a bus-attached
Type 30 display that we ripped off the PDP-1. I believe
it used two 10-bit fields out of the DATAO to plot a
point. The Type 30 had a 1024 by 1024 resolution,
but only plotted white points of a few intensities.
There was a light pen on the PDP-1, but I never saw
it used on the PDP-6. It worked by setting Program
Flag 1 on the PDP-1, so it may not have been brought
with the display.
John Sauter (J_Sa...@Empire.Net)
jmfb...@aol.com
f...@watsun.cc.columbia.edu (Frank da Cruz) wrote:
>In article <6ug0bjl...@chonsp.franklin.ch>,
>Neil Franklin <ne...@franklin.ch.remove> wrote:
>: Arthur Krewat <kre...@bartek.dontspamme.net> writes:
>: ....
>: > > The question is there a high res graphic display
>: > > that was used with the 10? Ben.
>: >
>: > VT240's come to mind,
>:
>[Web browsers etc...]
>
>I don't see what the point is of loading up the emulated PDP-10 with
>all the modern commercial-grade mass-market junk. The authentic way
>to do graphics on the -10 or -20 is with graphics software like
>DISSPLA/TELL-A-GRAPH driving a Tektronix or other graphics terminal
>(including maybe a GIGI or various VT terminals with Sixel capability),
>a pen plotter, or a dot-matrix printer capable of graphics (e.g. the
>Printronix P600, or maybe the LA34, LA50, or LA100).
>
>Maybe there were some genuine, bus-attached, native graphics devices
>on PDP-10s, like there were on some of the other PDP-x's and -xx's,
>with light pens, etc.
There may be a driver on the Customer Supported Tape called
VBCSER.MAC or something like that. I never could reliably
remember all that hardware mumbo-jumbo. VBC-10 was the
display device...that's not quite right either. Look for
V?????.MAC on the tape.
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>jmfb...@aol.com wrote:
>>
>> There may be a slight problem of DECnet Phases not talking to
>> each other. There were plans to not support communication to
>> Phase III DECnets. So, if you do more than think about it,
>> forget about the MCB stuff and concentrate on the Phase IV
>> stuff (which is the ethernet). You might have to have a CPU
>> dedicated to do the DECnet mumbo-jumbo. Also it would probably
>> be a good idea to use the KL as an end node rather than a router.
>> Bill wanted to finish the end node stuff on the KS but never
>> got any time to do that (I think I've got that straight...I could
>> never remember what the default (router or end-node) was.
>>
>
>End-node was the default for the VAX's I've done. Router was
>be more complex, needing a different (and seemingly more expensive)
>license PAK.
The -10s didn't split up the packaging that way...Thank the god
of bits for that!
>
>I would imagine that the end-node stuff was done for the KS, and if
>anything the router stuff would not have been completed. Of course,
>customers may have had other priorities... :)
If we could get Bill to e-talk...he was the developer for that
part. hmmm....Carl was working on the same project...
Unfortunately, my virtual baseball bat doesn't reach that far
to give either of them incentive to type a few ASCII characters.
jmfb...@aol.com
"Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
>jmfb...@aol.com wrote:
>> In article <j5387.230$4H4.2...@e3500-chi1.usenetserver.com>,
>> "Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
>
>>>able to use it. I'm seeing two *major* problems, one is a lack of
>>>documentation (trying to figure out DECnet configuration
>>>without Doc's would
>>>probably be a real nightmare),
>
>> Or you could read the code.
>
>That could be a problem two, though a good learning experience :^)
Exactly!! <grin> There had to be a DECNET manual in the
notebooks, but I can't remember.
>
>>> ...but the even bigger problem is the files on
>>>the tape appear to be encrypted.
>
>> What!!!!????!!!!! I didn't encrypt them
>
>Are you able to look at the files on Tim Shoppa's site?
No, not yet. Somebody is helping to correct that problem.
> ...I can't remember.
>The following URL points to what's on the DECnet tape.
>
>http://pdp-10.trailing-edge.com/pdp-10/DECNET-10_V4_0_SUP_BB-X116C-BB.HTML
>
>All the files except the *.KEY files and the *.EXE predate 7.03 by a few
>months. The *.KEY files and the *.EXE files were obviously generated
>for 7.04.
This sounds really weird. From the date descriptions, I'd say that
those files were purely MCB. But the DECNET monitor tape that I
packaged had the monitor modules on them, too.
Did you see the write up about the language tapes and their
replacement for autopatch yesterday?
>
>Question. Did a majority of the DECnet software run on a PDP-11
The MCB was an -11.
> ...(the
>frontend?), most of the files on the tape really look to be for RSX to me.
>With the really odd part being the RSX11S.TSK file. This makes me suspect
>something like a dedicated Front-End Network processor.
That was for Phase II and Phase III DECnet. The ethernet came
with Phase IV and used that NI-20 thingie.
Neil Franklin
> Frank da Cruz wrote:
>
> > I tried some of these on TOAD recently. I thought maybe I could gzip and
> > uuencode a 36-bit binary (i.e. KERMIT.EXE, to reduce the bootstrapping
> > burden) but no dice. I guess in this case it's not so much C and 36-bits
> > not agreeing, but the semantics of the programs themselves at runtime. They
> > only want to deal with 8-bit date bytes. Kind of like how PDP-10 programs
> > only want to deal with 7-bit date bytes (HRROI A, ASCIZ /..../).
>
> I suspect the problem is 99% of the C programs assume 2 or 4 Bytes = 1 word
Using an 4*9=36 arrangement ist definitely C compatible. Simply treat
36 bit as 32bit with one extra (wasted) bit per char.
This will of course fail the minority of broken programs which assume
char 127 + 1 = -128 (this will overflow trap on some processors) or
assume union { int; char[4] } and that char[3] == 256*char[4] (this
will also fail on x86->PPC because of bit endianness). Particularly
Linux being on tens of different processors is weeding out some of the
worst abuses.
C is actually an surprisingly high level language. You just need to
see though the "machine independant assembler" user interpretation
and treat it as an proper Algol style language.
Writing to 5*7+1 bit files will be impossible (data may be 8bit), so
we will need an user-level converter. Given the flexible byte sizes I
would not be surprised if such already exists.
Totally non-36-aware things like Lynx will compile with KCC. That is
proof of the pudding.
And gcc is on its way, lcc would also be portable (written for doing so).
> of data and use memory refernces rather than shifting to extract/store bytes.
Most C code does not care for shifting or memory access. Most just
simply says, "variable n is char, get/put its data" and leave it to
the compiler to know how to handle different (word/byte) pointer
formats and access methods.
Arthur Krewat
>
> There may be a driver on the Customer Supported Tape called
> VBCSER.MAC or something like that. I never could reliably
> remember all that hardware mumbo-jumbo. VBC-10 was the
> display device...that's not quite right either. Look for
> V?????.MAC on the tape.
Yup, it's on the customer supported CUSP tape:
.type vbcser.mac
TITLE VBCSER - SERVICE ROUTINE FOR DEC VB10C (5.02 OR LATER) - V033
SUBTTL P. M. HURLEY/DAL 10 SEP 85
SEARCH F,S
aak
Frank da Cruz
Neil Franklin <ne...@franklin.ch.remove> wrote:
: ...
: Using an 4*9=36 arrangement ist definitely C compatible. Simply treat
: 36 bit as 32bit with one extra (wasted) bit per char.
:
: This will of course fail the minority of broken programs which assume
:
That's not broken. Unfortunately, that *is* the definition of char in C.
It's one of the worst things about C. To avoid this behavior, you have
to go out of your way to use unsigned char, which (a) is not support in
every C compiler, and (b) in ANSI compilers forces you to put hideous
casts everywhere in your program (e.g. if you want to handle 8-bit character
sets, which are required for almost every language on earth except English).
- Frank
Peter da Silva
>Arthur Krewat wrote:
>> VT240's come to mind, but at a max if 19200 baud, you're pissing in the
>> wind :) Maybe an emulated one would work...
>xterm has a TekTronics mode. You could always use that for simple
>graphics.
Or even not-so-simple graphics. That was one of the big uses of the -20
at Berkeley, driving Tektronix tubes in the graphics lab.
--
Rev. Peter da Silva, ULC. WWFD?
"Be conservative in what you generate, and liberal in what you accept"
-- Matthew 10:16 (l.trans)
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>jmfb...@aol.com wrote:
>>
>> There may be a driver on the Customer Supported Tape called
>> VBCSER.MAC or something like that. I never could reliably
>> remember all that hardware mumbo-jumbo. VBC-10 was the
>> display device...that's not quite right either. Look for
>> V?????.MAC on the tape.
>
>Yup, it's on the customer supported CUSP tape:
>
>TITLE VBCSER - SERVICE ROUTINE FOR DEC VB10C (5.02 OR LATER) - V033
>SUBTTL P. M. HURLEY/DAL 10 SEP 85
> SEARCH F,S
OK. Now note that it hadn't been converted for SMP. IOW, it
probably isn't reentrant.
jmfb...@aol.com
R.J.S. <n...@available.right.now> wrote:
>VB06C
>
>In Marlboro, there were 4. They were on Dick's system and used for
>doing the print sets and such. (All the "S. Foonley" pages!)
>(Dicks's system ran SUDS, the Stanford University Drawing System.)
>
>There really were a GT40, but had minimal code in the -11. They were
>connected thru a DL10 (hence the limit of 4), and the graphics engine
>got it's vector list from the -10 via the DL.
But these were different than those VBCs..weren't they?
And Dick's system ran TOPS-20 underneath the SUDS, didn't it?
<pins>
Peter da Silva
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>In article <6uhevxj...@chonsp.franklin.ch>,
>Neil Franklin <ne...@franklin.ch.remove> wrote:
>: This will of course fail the minority of broken programs which assume
>: char 127 + 1 = -128...
>That's not broken. Unfortunately, that *is* the definition of char in C.
Portable C code doesn't assume that char is either signed or unsigned.
ANSI trying to force the issue by picking one has... as they have done in
so many other cases... simply confused the issue.
If you want to perform arithmetic on a byte, convert it to int first, and
then mask it. If you want to operate on characters, then treat them as
opaque objects and use equality operators and is*() macros only.
This isn't a "C" issue. There are too many character sets still in use to
be able to even depend on things like contiguous letter ranges. The Univac
1100 family is still in production... 36-bit 1s-complement machines with
both 8-bit and a 6-bit character set (feilddata). IBM mainframes use an
8-bit character set in 32-bit words, but the character set is EBCDIC, not
ASCII. Writing portable code in FORTRAN or PL/I isn't any easier.
Frank da Cruz
Peter da Silva <pe...@taronga.com> wrote:
: In article <9jutno$qcr$1...@newsmaster.cc.columbia.edu>,
: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
: >In article <6uhevxj...@chonsp.franklin.ch>,
: >Neil Franklin <ne...@franklin.ch.remove> wrote:
: >: This will of course fail the minority of broken programs which assume
: >: char 127 + 1 = -128...
:
: >That's not broken. Unfortunately, that *is* the definition of char in C.
:
: Portable C code doesn't assume that char is either signed or unsigned.
No but ANSI C compilers assume they are signed. A few compilers have a
command-line switch to make them unsigned, but most do not.
: If you want to perform arithmetic on a byte, convert it to int first, and
: then mask it. If you want to operate on characters, then treat them as
: opaque objects and use equality operators and is*() macros only.
:
Right. You can't even use chars as array indices. An 8-bit character (such
as Latin-1 A-acute) is "promoted" to a negative integer and the program dumps
core, so you find yourself
unsigned char c, a[256];
...
if (a[((unsigned int)(((unsigned char)c) & 0xff) & 0xff)]) ...
It's incredibly annoying. How can a *character* have a *sign*? If you want
short-short ints, have a separate data type! (Yes I know you could work
around it other ways, like always convert chars to ints before using them,
etc.)
: This isn't a "C" issue. There are too many character sets still in use to
: be able to even depend on things like contiguous letter ranges.
:
Simple stuff like that is truly a relic of the past. Soon we'll all be using
UTF-8, where the whole model of character processing changes so radically you
won't believe it. There's no way to even know what a character *is* without
database lookups and sorting of combining sequences into canonical order
(a character is a base character followed by any number of combining
diacritics in no fixed order, until the next base character is encountered,
and the only way to tell whether a character is a base charcter or a combining
character is with a database lookup). No more sorting on binary values, no
more case conversion by simple computation, no more simple string comparisons.
That's not a complaint, of course, since we gain an awful lot by moving from
character-set Babel to a single universal character set that represents all
the world's scripts. Btw, in case this is news to you, take a look at:
http://www.columbia.edu/kermit/utf8.html
But the days of our little character-processing tricks like:
if (c >= 'A' && c <= 'Z')
c += 'a'-'A';
are definitely numbered. It truly is a good thing that computers have become
so much faster, because from now on, they will need to be!
- Frank
Zane H. Healy
>Exactly!! <grin> There had to be a DECNET manual in the
>notebooks, but I can't remember.
Now if someone would just scan in the notebooks there would be some very
happy people!
>>Are you able to look at the files on Tim Shoppa's site?
>
>No, not yet. Somebody is helping to correct that problem.
Cool, glad to hear you should be able to soon!
>>http://pdp-10.trailing-edge.com/pdp-10/DECNET-10_V4_0_SUP_BB-X116C-BB.HTML
>>
>>All the files except the *.KEY files and the *.EXE predate 7.03 by a few
>>months. The *.KEY files and the *.EXE files were obviously generated
>>for 7.04.
>
>This sounds really weird. From the date descriptions, I'd say that
>those files were purely MCB. But the DECNET monitor tape that I
>packaged had the monitor modules on them, too.
Please pardon the big list of files, here is the directory listing off of the
tape. I figure with this, you'll hopefully be able to say one way or
another what this tape is.
Read Density:1600 Parity:Odd 9-Track Write enabled
BACKUP reel number 1; start save set: 7.04 DECnet Distribution
by version 5A(622) at 10:57:27 on 10-Oct-88
written on MTB0:, on S/N 1026 at 1600 9TK; Blocking factor 4
under TOPS-10 system 704(33461): RL375A DEC10 Development
DECNET DIR 0 <055> 000000 6-Oct-88 DSKB: [10,7]
Total of 0 blocks in 1 file Checksum = 000000 on DSKB: [10,7]
CEX MAP 9 <455> 245415 12-Nov-85 [10,7,MCB]
CEX STB 2 <455> 075715 12-Nov-85
CEX TSK 11 <455> 411750 12-Nov-85
CEX KEY 41 <455> 237646 16-Sep-88
CEXCOM MAP 24 <455> 164231 12-Nov-85
CEXCOM STB 6 <455> 453271 12-Nov-85
CEXCOM TSK 13 <455> 525364 12-Nov-85
CEXCOM KEY 41 <455> 033553 16-Sep-88
CEXLIB M11 22 <455> 457610 29-Dec-82
CEXLLC M11 3 <455> 762234 30-Dec-82
DATML M11 22 <455> 077103 7-Dec-82
DCP MAP 6 <455> 453452 12-Nov-85
DCP STB 2 <455> 543730 12-Nov-85
DCP TSK 18 <455> 764400 12-Nov-85
DCP KEY 41 <455> 316603 16-Sep-88
DCPDLC M11 6 <455> 524551 30-Dec-82
DMC MAP 7 <455> 461751 12-Nov-85
DMC STB 2 <455> 562066 12-Nov-85
DMC TSK 18 <455> 027336 12-Nov-85
DMC KEY 41 <455> 144527 16-Sep-88
DMCDLC M11 6 <455> 750455 30-Dec-82
DMR MAP 2 <455> 060066 12-Nov-85
DMR STB 1 <455> 673106 12-Nov-85
DMR TSK 4 <455> 657614 12-Nov-85
DMR KEY 41 <455> 111336 16-Sep-88
DMRDLC M11 6 <455> 750455 30-Dec-82
DNMAC EXE 64 <455> 306650 1-Feb-83 30G(1063)-1
DTE MAP 6 <455> 124730 12-Nov-85
DTE STB 2 <455> 252566 12-Nov-85
DTE TSK 15 <455> 511564 12-Nov-85
DTE KEY 41 <455> 402073 16-Sep-88
DTEDLC M11 5 <455> 655136 30-Dec-82
DTEDMP SYS 4 <455> 713301 5-Oct-82
DTEMPS SYS 4 <455> 430522 5-Oct-82
DTEMPT SYS 20 <455> 776315 5-Oct-82
DTR MAP 2 <455> 260574 12-Nov-85
DTR STB 1 <455> 412040 12-Nov-85
DTR TSK 10 <455> 542723 12-Nov-85
DTR KEY 41 <455> 634407 16-Sep-88
DTRLLC M11 3 <455> 157367 30-Dec-82
INI MAP 3 <455> 522261 12-Nov-85
INI STB 1 <455> 557523 12-Nov-85
INI TSK 7 <455> 236715 12-Nov-85
INI KEY 41 <455> 464543 16-Sep-88
INILLC M11 3 <455> 775611 30-Dec-82
KDP MAP 6 <455> 222750 12-Nov-85
KDP STB 2 <455> 624516 12-Nov-85
KDP TSK 17 <455> 440526 12-Nov-85
KDP KEY 41 <455> 233403 16-Sep-88
KDPDDM M11 6 <455> 257144 30-Dec-82
MCBLIB M11 25 <455> 714137 30-Dec-82
MCBLIB OLB 30 <455> 040710 12-Nov-85
MCBSYS CTL 10 <455> 505024 8-Nov-85
MDT MAP 34 <455> 713757 12-Nov-85
MDT STB 8 <455> 174615 12-Nov-85
MDT TSK 24 <455> 075732 12-Nov-85
MDT KEY 41 <455> 463500 16-Sep-88
NDT MAP 3 <455> 453424 12-Nov-85
NDT STB 1 <455> 252540 12-Nov-85
NDT TSK 6 <455> 067024 12-Nov-85
NDT KEY 41 <455> 730140 16-Sep-88
NML MAP 19 <455> 040317 12-Nov-85
NML STB 4 <455> 741204 12-Nov-85
NML TSK 131 <455> 336041 12-Nov-85
NML KEY 141 <455> 255053 16-Sep-88
NMS MAP 19 <455> 541612 12-Nov-85
NMS STB 4 <455> 155614 12-Nov-85
NMS TSK 110 <455> 214165 12-Nov-85
NMS KEY 117 <455> 751565 16-Sep-88
NMTAB M11 4 <455> 571521 3-Jan-83
NMX MAP 8 <455> 304331 12-Nov-85
NMX STB 2 <455> 115554 12-Nov-85
NMX TSK 18 <455> 337477 12-Nov-85
NMX KEY 41 <455> 114627 16-Sep-88
NMXLLC M11 10 <455> 145052 4-Jan-83
NS1 MAP 4 <455> 654342 12-Nov-85
NS1 STB 1 <455> 312214 12-Nov-85
NS1 TSK 16 <455> 461104 12-Nov-85
NS1 KEY 41 <455> 406101 16-Sep-88
NS2 MAP 5 <455> 221056 12-Nov-85
NS2 STB 1 <455> 026407 12-Nov-85
NS2 TSK 15 <455> 275076 12-Nov-85
NS2 KEY 41 <455> 730214 16-Sep-88
NSP MAP 4 <455> 023516 12-Nov-85
NSP STB 1 <455> 042052 12-Nov-85
NSP TSK 16 <455> 741226 12-Nov-85
NSP KEY 41 <455> 315257 16-Sep-88
NSPLLC M11 6 <455> 526161 31-Dec-82
NSTAB M11 5 <455> 147321 31-Dec-82
RSX11S MAP 16 <455> 704071 23-Sep-80
RSX11S STB 7 <455> 264634 23-Sep-80
RSX11S TSK 126 <455> 675630 26-Oct-83
RSX11S KEY 137 <455> 471141 16-Sep-88
RSXLIB M11 32 <455> 113250 30-Dec-82
RSXMS STB 12 <455> 250137 5-Feb-79
RSXTKB MAP 27 <455> 440726 30-Apr-81
SC MAP 6 <455> 733763 12-Nov-85
SC STB 2 <455> 137007 12-Nov-85
SC TSK 19 <455> 214063 12-Nov-85
SC KEY 41 <455> 453071 16-Sep-88
SC1 MAP 3 <455> 171020 12-Nov-85
SC1 STB 1 <455> 522216 12-Nov-85
SC1 TSK 8 <455> 566655 12-Nov-85
SC1 KEY 41 <455> 002234 16-Sep-88
SCLLC M11 7 <455> 073413 31-Dec-82
SCX MAP 7 <455> 652655 12-Nov-85
SCX STB 2 <455> 622453 12-Nov-85
SCX TSK 17 <455> 520266 12-Nov-85
SCX KEY 41 <455> 420744 16-Sep-88
SCXLLC M11 4 <455> 532736 31-Dec-82
SYSLIB OLB 184 <455> 333212 8-Nov-78
TLI MAP 6 <455> 724056 12-Nov-85
TLI STB 2 <455> 513207 12-Nov-85
TLI TSK 15 <455> 237055 12-Nov-85
TLI KEY 41 <455> 701272 16-Sep-88
TOP MAP 3 <455> 136726 12-Nov-85
TOP STB 1 <455> 036201 12-Nov-85
TOP TSK 5 <455> 206015 12-Nov-85
TOP KEY 41 <455> 324671 16-Sep-88
TOPLLC M11 2 <455> 666707 31-Dec-82
XPE MAP 7 <455> 476033 12-Nov-85
XPE STB 2 <455> 721406 12-Nov-85
XPE TSK 18 <455> 323446 12-Nov-85
XPE KEY 41 <455> 357171 16-Sep-88
XPT MAP 8 <455> 577210 12-Nov-85
XPT STB 2 <455> 263463 12-Nov-85
XPT TSK 18 <455> 563733 12-Nov-85
XPT KEY 41 <455> 121563 16-Sep-88
XPTLLC M11 8 <455> 547040 31-Dec-82
Total of 2789 blocks in 129 files Checksum = 273146 on DSKB: [10,7,MCB]
NETGEN EXE 284 <455> 657673 1-Sep-88 4A(50) [10,7,NETGEN]
NETGEN MAC 69 <455> 357477 20-Sep-85
NGNCNF MAC 29 <455> 101474 20-Aug-85
NGNDAT MAC 25 <455> 455477 20-Aug-85
NGNDEV MAC 36 <455> 310200 20-Aug-85
NGNDIA MAC 36 <455> 604114 18-Sep-85
NGNFIN MAC 72 <455> 177007 2-Oct-85
NGNMAC MAC 11 <455> 326317 20-Aug-85
NGNPRM MAC 124 <455> 350647 20-Aug-85
NGNPRS MAC 46 <455> 641765 20-Aug-85
Total of 732 blocks in 10 files Checksum = 716340 on DSKB: [10,7,NETGEN]
NIPGEN MAC 95 <455> 740216 11-Nov-85 [10,7,NIPGEN]
NIPGEN EXE 48 <455> 440524 1-Sep-88 4(25)
Total of 143 blocks in 2 files Checksum = 575110 on DSKB: [10,7,NIPGEN]
NML EXE 560 <455> 765777 7-Apr-86 4(146) [10,7,NML]
Total of 560 blocks in 1 file Checksum = 765777 on DSKB: [10,7,NML]
TKB36 EXE 100 <455> 131430 1-Sep-88 3A(10) [10,7,TKB36]
Total of 100 blocks in 1 file Checksum = 131430 on DSKB: [10,7,TKB36]
VNP36 EXE 132 <455> 441611 1-Sep-88 3A(7) [10,7,VNP36]
Total of 132 blocks in 1 file Checksum = 441611 on DSKB: [10,7,VNP36]
Grand total of 4456 blocks in 145 files Checksum = 240150
BACKUP reel number 1; end save set: 7.04 DECnet Distribution
by version 5A(622) at 10:58:03 on 10-Oct-88
written on MTB0:, on S/N 1026 at 1600 9TK; Blocking factor 4
under TOPS-10 system 704(33461): RL375A DEC10 Development
>Did you see the write up about the language tapes and their
>replacement for autopatch yesterday?
About the Key files and TSU? What I didn't underestand is if a decryption
key was needed to decrypt the key files. It sounds like you had to, in the
form of matching key files (were these part of the original install of the
software).
>>Question. Did a majority of the DECnet software run on a PDP-11
>
>The MCB was an -11.
Are these the DN87's? (Yes, I've been doing more reading, this time the
decsystem-1080/1090 System Description).
Zane
Peter da Silva
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>In article <9k19gb$12l5$1...@citadel.in.taronga.com>,
>Peter da Silva <pe...@taronga.com> wrote:
>: In article <9jutno$qcr$1...@newsmaster.cc.columbia.edu>,
>: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>: >In article <6uhevxj...@chonsp.franklin.ch>,
>: >Neil Franklin <ne...@franklin.ch.remove> wrote:
>: >: This will of course fail the minority of broken programs which assume
>: >: char 127 + 1 = -128...
>: >That's not broken. Unfortunately, that *is* the definition of char in C.
>: Portable C code doesn't assume that char is either signed or unsigned.
>No but ANSI C compilers assume they are signed. A few compilers have a
>command-line switch to make them unsigned, but most do not.
That shouldn't matter to portable code, since before ANSI came along the
signdedness of characters was undefined (it was frequently signed on ASCII
sustems, and UNSIGNED on EBCDIC ones, in my experience).
>: If you want to perform arithmetic on a byte, convert it to int first, and
>: then mask it. If you want to operate on characters, then treat them as
>: opaque objects and use equality operators and is*() macros only.
>Right. You can't even use chars as array indices.
Actually you can. You just have to take advantage of the equivalence:
pointer[index] == *(pointer+offset)
So you have:
char *foo, fooarray = { ... };
Then in main, you have something like:
char c = LATIN_A;
if(c < 0) {
foo = &fooarray[128];
} else {
foo = fooarray;
}
Now you can do:
if (foo[c])
with impunity.
>Simple stuff like that is truly a relic of the past. Soon we'll all be using
>UTF-8, where the whole model of character processing changes so radically you
>won't believe it. There's no way to even know what a character *is* without
>database lookups and sorting of combining sequences into canonical order
>(a character is a base character followed by any number of combining
>diacritics in no fixed order, until the next base character is encountered,
>and the only way to tell whether a character is a base charcter or a combining
>character is with a database lookup). No more sorting on binary values, no
>more case conversion by simple computation, no more simple string comparisons.
Yeh, I know. The simplest solution I see for this is to do all the conversions
on input and output, and store stuff internally in 32-bit ints in ISO10646
format.
Frank da Cruz
: Yeh, I know. The simplest solution I see for this is to do all the
: conversions on input and output, and store stuff internally in 32-bit ints
: in ISO10646 format.
It's not even that easy because some sequences of base character plus
combining diacritic do not have precomposed equivalents. That's why you
see, e.g., the Linux i18n people avoiding the whole mess and restricting
themselves to precomposed Base Multilingual Plane characters.
Oh well, talk about a tangent...
- Frank
Dan Cross
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>Simple stuff like that is truly a relic of the past. Soon we'll all be using
>UTF-8, where the whole model of character processing changes so radically you
>won't believe it. There's no way to even know what a character *is* without
>database lookups and sorting of combining sequences into canonical order
>(a character is a base character followed by any number of combining
>diacritics in no fixed order, until the next base character is encountered,
>and the only way to tell whether a character is a base charcter or a combining
>character is with a database lookup). No more sorting on binary values, no
>more case conversion by simple computation, no more simple string comparisons.
Eh? Plan 9 has been using UTF-8 for years without major annoyances.
But part of the ease of use comes from having a good library to take
care of all the tedious details. I would point out, however, that
``simple'' string comparisons are just as easy with UTF-8 as they are
will any other ``normal'' character set, thus simply sorting based on
strcmp(3) et al is still possible; also that ``base character
detection'' can always be achieved with simple bit-masking procedures
(if ((ch & 0x7F) == 0) { /* I'm a base character. */ }). Finally
case conversion for ASCII still works via simple subtraction, as UTF-8
retains 7-bit ASCII as a subset. Case conversion in other languages
might not be achievable with a simple computation anyway.
http://plan9.bell-labs.com/plan9dist/
http://plan9.bell-labs.com/sys/doc/utf.html
http://plan9.bell-labs.com/magic/man2html/6/utf
>That's not a complaint, of course, since we gain an awful lot by moving from
>character-set Babel to a single universal character set that represents all
>the world's scripts. Btw, in case this is news to you, take a look at:
>
> http://www.columbia.edu/kermit/utf8.html
I'm impressed to see that I actually loaded the Cyrillic fonts on my
Unix installation. I'll have to boot into Plan 9 later and see how
well it displays that document.
>But the days of our little character-processing tricks like:
>
> if (c >= 'A' && c <= 'Z')
> c += 'a'-'A';
This is bad style anyway, and has been for many years. Why not just
do:
if (isupper(c)) {
c = tolower(c);
}
Which works for character sets other than ASCII and is implemented as
efficiently as possible by the system vendor?
>are definitely numbered. It truly is a good thing that computers have become
>so much faster, because from now on, they will need to be!
I submit that my example above is probably just as fast as your
example, if not faster, on just about any modern machine and compiler.
In particular, most systems implement isupper(3) as a macro that does a
table lookup. Compare to doing two comparisons and branches. tolower(3)
is also often a macro, hence just as efficient as `` 'a' - 'A' ''.
Best of all, this code will run unchanged on an IBM mainframe (EBCDIC
doesn't have contiguous character ranges, IIRC).
Oh the whole though, I agree that software is a lot less efficient
these days than it could be. But I'd venture that it's less efficient
becuase people are always re-inventing the wheel, instead of putting
all that energy into one or two really good libraries.
- Dan C.
Dan Cross
Dan Cross <cr...@augusta.math.psu.edu> wrote:
>(if ((ch & 0x7F) == 0) { /* I'm a base character. */ })
Err, re-reading this, it's a misnomer in that it leads one to assume
there is only one base character (and the C is completely wrong in
missing a negation). Please allow me the indulgence of following up to
myself to list the other base characters as well, and correct the C.
if (((ch & 0x80) == 0x00) ||
((ch & 0xE0) == 0xC0) ||
((ch & 0xF0) == 0xE0))
{
/* I'm a base character. */
}
Perhaps put another way:
if ((ch & 0xC0) != 0x80) {
/* I'm a base character. */
}
Sorry for the earlier brain-slip.
- Dan C.
Al Kossow
>
> Now if someone would just scan in the notebooks there would be some very
> happy people!
Eric is working on it. It is a BIG project.
Peter da Silva
>combining diacritic do not have precomposed equivalents.
I thought that was the important difference between 10646 and Unicode, all
glyphs in 10646 were complete, whereas Unicode used diacritics and other
things that annoyed people (like Han unification) to avoid that.
If 10646 gave that up to get the Unicode people in line... AUGH.
(and, yes, I know I was in favor of diacritics back then, but that was
when diacritics were being treated as separate glyphs with 0-offset
baselines)
Neil Franklin
> In article <9k19gb$12l5$1...@citadel.in.taronga.com>,
> Peter da Silva <pe...@taronga.com> wrote:
> : In article <9jutno$qcr$1...@newsmaster.cc.columbia.edu>,
> : Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
> : >In article <6uhevxj...@chonsp.franklin.ch>,
> : >Neil Franklin <ne...@franklin.ch.remove> wrote:
> : >: This will of course fail the minority of broken programs which assume
> : >: char 127 + 1 = -128...
> :
> : >That's not broken. Unfortunately, that *is* the definition of char in C.
> :
> : Portable C code doesn't assume that char is either signed or unsigned.
> :
> No but ANSI C compilers assume they are signed. A few compilers have a
> command-line switch to make them unsigned, but most do not.
My original point was: Is char even defined as 8bit in the C standard?
AFAIK it is defined as holding _at_least_ the 8bit range, dito short
min 16bit, long min 32bit and int the fastest thing that is minimally
short range.
Code that simply treads chars as 8bit small shorts is what I called broken.
> It's incredibly annoying. How can a *character* have a *sign*? If you want
> short-short ints, have a separate data type!
Exactly. Lucky enough most people do not use then as shortest possible
ints these days. Memory is not that expensive any more. :-)
> (Yes I know you could work
> around it other ways, like always convert chars to ints before using them,
> etc.)
Why would you do that? One does not compute on characters (apart from
such 'a'+13 == 'n' things, goodbye EBCDIC) and today holds computable
numbers in ints (one really _does_ have memory to burn these days).
> : This isn't a "C" issue. There are too many character sets still in use to
> : be able to even depend on things like contiguous letter ranges.
Assuming the programmer has ever heard of them, let allone that they
have non-contiguous letters (see above non-EBCDIC example). There
actually exists quite a few "ASCII is all the world" programs. But a
char = 4*9bit PDP-10 C compiler should even survive these. Thankfully
the percentage is dropping, due to ISO-8859 and Unicode.
> Simple stuff like that is truly a relic of the past. Soon we'll all be using
> UTF-8, where the whole model of character processing changes so radically you
> won't believe it.
Actually not that much. Simply regard UTF-8 as what it is: an ASCII
compatible (and compacter for alphabetic text) storage method for
32bit ISO10646. Expand to 32bit on read and compact to UTF-8 on store
(yes, read/nomodify/write can produce a different file). Between treat
wchar_t (yes that exists, but may only take Unicode, not full ISO10646)
as you new char.
> There's no way to even know what a character *is* without
> database lookups
Try displaying normal 7bit ASCII without table (font bitmap) lookup. :-)
Apart from that, AFAIK, ISO10646 explicitely allocates one value for
each valid character, i.e every valid dieresis form has its own single
32bit value.
> and sorting of combining sequences into canonical order
That problem already happens with ISO8859. All them diacritics in
160-254 need "inserting" into the right place in the alphabet (and
this is locale dependant!).
> (a character is a base character followed by any number of combining
> diacritics in no fixed order, until the next base character is encountered,
> and the only way to tell whether a character is a base charcter or a combining
> character is with a database lookup).
Huh? Where is that in ISO10646? Following base alphabetics with
separate diacritics (or diacritic <BS> char) was used in ISO646
ASCII (that is what all them '`~^ in ASCII are for).
> No more sorting on binary values, no
> more case conversion by simple computation, no more simple string comparisons.
Is already the case today with good C code. is*() is your friend. Not
to mention the variuos platforms i18n and locale stuff.
> http://www.columbia.edu/kermit/utf8.html
My browser (or font collection) failled the test badly. ISO8859-1
stuff appeared, the entire rest was just ????s. Bummer.
> are definitely numbered. It truly is a good thing that computers have become
> so much faster, because from now on, they will need to be!
Features cost power. And converting strings is not that expensive,
compared say to GUI or embedded document objects (OLE2, CORBA) stuff.
Frank da Cruz
:
: Eh? Plan 9 has been using UTF-8 for years without major annoyances.
:
Because (a) Plan 9 is based on approximately Unicode 2.0, and I do not
believe it handles composed charcters, and (b) it actually is not without
problems, which primarily involve the inclusion of 0x80-0x9F in the UTF-8
encoding range when these byte values are already meaningul as C1
controls.
: But part of the ease of use comes from having a good library to take
: care of all the tedious details. I would point out, however, that
: ``simple'' string comparisons are just as easy with UTF-8 as they are
: will any other ``normal'' character set, thus simply sorting based on
: strcmp(3) et al is still possible...
:
OK, you *can* sort UTF-8 strings by their binary value, but this kind
of sort won't please anybody, because it won't be in any order that's
related to the script and language (except in the degenerate case of
the UTF-8 stream containing only ASCII).
; ...also that ``base character
: detection'' can always be achieved with simple bit-masking procedures
: (if ((ch & 0x7F) == 0) { /* I'm a base character. */ }).
:
I don't think so. Each character in the incoming data stream has to be
looked up in the database to get its properties. Is it combining, is
it uppercase, etc. There's no way you can tell by looking at its value.
: Finally
: case conversion for ASCII still works via simple subtraction, as UTF-8
: retains 7-bit ASCII as a subset.
:
Sure, but only for ASCII, not for Latin-1, Latin-2, Greek, Cyrillic, or
anything else.
: Case conversion in other languages
: might not be achievable with a simple computation anyway.
:
Nope. Maybe a table lookup, but not computation.
: >But the days of our little character-processing tricks like:
: >
: > if (c >= 'A' && c <= 'Z')
: > c += 'a'-'A';
:
: This is bad style anyway, and has been for many years. Why not just
: do:
:
: if (isupper(c)) {
: c = tolower(c);
: }
:
Of course it's bad, but 30 years of programs are full of stuff like this.
: I submit that my example above is probably just as fast as your
: example, if not faster, on just about any modern machine and compiler.
: In particular, most systems implement isupper(3) ...
:
That's not what I meant. What I really meant was that character processing
will involve (on the input side):
. Decoding of UTF-8 into 32-bit ISO 10646 scalar values
. Looking up each result in the Unicode database to get its properties.
. When a base character is followed by one or more combining characters,
these must be sorted to ensure a canonical order.
. The result of the previous step is then converted (if necessary)
into one of several canonical normalization forms (precomposed,
decomposed, ...)
. If case conversion is required, it requires a database lookup to
see what the result (if any) will be.
That's just a piece of it; trust me, things are not going to be a lot
less simple than they were in the all-ASCII world. Suppose, for example,
there is a character A with Circumflex and Dot Below. This character
could be represented in lots of different ways: totally precomposed,
A followed by combining circumflex followed by combining dot below, or
A followed by combining dot below followed by combining circumflex, or
precomposed A-circumflex followed by combining dot below, etc etc. Now,
these must all compare the same, otherwise all sorts of terrible things
will happen. Comparing them caseless makes it even tougher.
- Frank
Frank da Cruz
: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
: >It's not even that easy because some sequences of base character plus
: >combining diacritic do not have precomposed equivalents.
:
: I thought that was the important difference between 10646 and Unicode, all
: glyphs in 10646 were complete, whereas Unicode used diacritics and other
: things that annoyed people (like Han unification) to avoid that.
No, ISO 10646 and Unicode have exactly the same repertoire. The only
difference between them is the text that surrounds them -- Unicode has
lots more, and also supplies the character properties database.
- Frank
Peter da Silva
I've lived forty years with a space in my last name. You know what that means
in a computerised world. The most terrible thing that could happen is that
more people have to deal with this kind of shit. I'll laugh.
If this gets people to fix their input methods so they're forced to maintain
a canonical form for funny spellings, I'm all for it.
As for me, I'm going to wait until someone comes to me with a real need to
store any character in anything but the canonical form... ever... before
I bother writing any software that makes allowances for it.
Peter da Silva
Here's a sort of accidental project that I've been doing over the past decade
or so:
http://www.taronga.com/~peter/io/quotes.html
I can't eat glass, and I don't have a wolf. :-<
Sam Weiner
Zane H. Healy <hea...@shell1.aracnet.com> wrote:
>jmfb...@aol.com wrote:
>>Zane H. Healy <hea...@shell1.aracnet.com> wrote:
>>> jmfb...@aol.com wrote:
>>>> "Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
>
>>Exactly!! <grin> There had to be a DECNET manual in the
>>notebooks, but I can't remember.
>
>Now if someone would just scan in the notebooks there would be some very
>happy people!
>
>>>Are you able to look at the files on Tim Shoppa's site?
>>
>>No, not yet. Somebody is helping to correct that problem.
>
>Cool, glad to hear you should be able to soon!
Tim has the TOPS-10 notebooks which were distributed
on tape towards the end. There are three tapes listed
as DOCA, DOCB, and DOCC for TOPS-10 7.04. Only the most
recent is really needed. There should be similar tapes
for TOPS-20 somewhere out there as well. The manuals
include most of what is needed for base OS operation
but do not include manuals for the languages and other
layered products.
>>>http://pdp-10.trailing-edge.com/pdp-10/DECNET-10_V4_0_SUP_BB-X116C-BB.HTML
>>>
>>>All the files except the *.KEY files and the *.EXE predate 7.03 by a few
>>>months. The *.KEY files and the *.EXE files were obviously generated
>>>for 7.04.
>>
>>This sounds really weird. From the date descriptions, I'd say that
>>those files were purely MCB. But the DECNET monitor tape that I
>>packaged had the monitor modules on them, too.
>
>Please pardon the big list of files, here is the directory listing off of the
>tape. I figure with this, you'll hopefully be able to say one way or
>another what this tape is.
>
> Read Density:1600 Parity:Odd 9-Track Write enabled
>
> BACKUP reel number 1; start save set: 7.04 DECnet Distribution
> by version 5A(622) at 10:57:27 on 10-Oct-88
> written on MTB0:, on S/N 1026 at 1600 9TK; Blocking factor 4
> under TOPS-10 system 704(33461): RL375A DEC10 Development
>
>DECNET DIR 0 <055> 000000 6-Oct-88 DSKB: [10,7]
> Total of 0 blocks in 1 file Checksum = 000000 on DSKB: [10,7]
>
>CEX MAP 9 <455> 245415 12-Nov-85 [10,7,MCB]
>CEX STB 2 <455> 075715 12-Nov-85
>CEX TSK 11 <455> 411750 12-Nov-85
>CEX KEY 41 <455> 237646 16-Sep-88
[snip...]
The above set of files are for the -11 based MCB as indicated
by the SFD. The .KEY files can be used to decrypt the
matching files using the APUTIL program from a TSU tape.
Unfortunately, the only TSU tapes I see on Tim's site are for
TOPS-20 7.0. The TSU manual which describes how to decrypt
stuff is in the DOC? tapes mentioned above.
>NETGEN EXE 284 <455> 657673 1-Sep-88 4A(50) [10,7,NETGEN]
>NIPGEN MAC 95 <455> 740216 11-Nov-85 [10,7,NIPGEN]
>NML EXE 560 <455> 765777 7-Apr-86 4(146) [10,7,NML]
>TKB36 EXE 100 <455> 131430 1-Sep-88 3A(10) [10,7,TKB36]
>VNP36 EXE 132 <455> 441611 1-Sep-88 3A(7) [10,7,VNP36]
[much snippage above]
The above sets of files are TOPS-10 based.
>>Did you see the write up about the language tapes and their
>>replacement for autopatch yesterday?
>
>About the Key files and TSU? What I didn't underestand is if a decryption
>key was needed to decrypt the key files. It sounds like you had to, in the
>form of matching key files (were these part of the original install of the
>software).
The .KEY files are used to decrypt the matching files. What I
don't see is the .VFY file used by APUTIL to drive the decrypt
processes. This could be a problem. There may have been another
decryption utility for installation. Of course, I'm not sure
why any of this matters unless you have a real -10 and the
proper -11 to match.
>>>Question. Did a majority of the DECnet software run on a PDP-11
>>
>>The MCB was an -11.
>
>Are these the DN87's? (Yes, I've been doing more reading, this time the
>decsystem-1080/1090 System Description).
I'd have to see if I can find some docs but as I recall,
there were at least a couple of -11 hardware bases which would
get different designations depending on the software loaded.
Hope this helps, Sam
jmfb...@aol.com
R.J.S. <n...@available.right.now> wrote:
>On Sun, 29 Jul 01 10:29:39 GMT, jmfb...@aol.com wrote:
>
>>But these were different than those VBCs..weren't they?
>
>
>>And Dick's system ran TOPS-20 underneath the SUDS, didn't it?
>
ROTFL. Smarty pants.
What did the -20 do when it got one of those?
jmfb...@aol.com
wei...@world.std.com (Sam Weiner) wrote:
>In article <fkY87.113368$Tx5.1...@e420r-chi1.usenetserver.com>,
>Zane H. Healy <hea...@shell1.aracnet.com> wrote:
>>jmfb...@aol.com wrote:
>>>Zane H. Healy <hea...@shell1.aracnet.com> wrote:
>>>> jmfb...@aol.com wrote:
>>>>> "Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
>>
>>>Exactly!! <grin> There had to be a DECNET manual in the
>>>notebooks, but I can't remember.
>>
>>Now if someone would just scan in the notebooks there would be some very
>>happy people!
>>
>>>>Are you able to look at the files on Tim Shoppa's site?
>>>
>>>No, not yet. Somebody is helping to correct that problem.
>>
>>Cool, glad to hear you should be able to soon!
>
>Tim has the TOPS-10 notebooks which were distributed
>on tape towards the end. There are three tapes listed
>as DOCA, DOCB, and DOCC for TOPS-10 7.04. Only the most
>recent is really needed. There should be similar tapes
>for TOPS-20 somewhere out there as well. The manuals
>include most of what is needed for base OS operation
>but do not include manuals for the languages and other
>layered products.
I bet it doesn't include any of the specs which is what these
guys need.
>
>>>>http://pdp-10.trailing-edge.com/pdp-10/DECNET-10_V4_0_SUP_BB-X116C-BB.H
TML
>>>>
>>>>All the files except the *.KEY files and the *.EXE predate 7.03 by a
few
>>>>months. The *.KEY files and the *.EXE files were obviously generated
>>>>for 7.04.
>>>
>>>This sounds really weird. From the date descriptions, I'd say that
>>>those files were purely MCB. But the DECNET monitor tape that I
>>>packaged had the monitor modules on them, too.
>>
>>Please pardon the big list of files, here is the directory listing off of
the
>>tape. I figure with this, you'll hopefully be able to say one way or
>>another what this tape is.
>>
>> Read Density:1600 Parity:Odd 9-Track Write enabled
>>
>> BACKUP reel number 1; start save set: 7.04 DECnet Distribution
>> by version 5A(622) at 10:57:27 on 10-Oct-88
>> written on MTB0:, on S/N 1026 at 1600 9TK; Blocking factor 4
>> under TOPS-10 system 704(33461): RL375A DEC10 Development
>>
>>DECNET DIR 0 <055> 000000 6-Oct-88 DSKB: [10,7]
>> Total of 0 blocks in 1 file Checksum = 000000 on DSKB: [10,7]
The fact that this file is zero blocks long tells me that
none of the tape building tools that I developed was used
to make the fucking tape.
You guys did it all by hand!!!!
>>
>>CEX MAP 9 <455> 245415 12-Nov-85 [10,7,MCB]
>>CEX STB 2 <455> 075715 12-Nov-85
>>CEX TSK 11 <455> 411750 12-Nov-85
>>CEX KEY 41 <455> 237646 16-Sep-88
>
>[snip...]
>
>The above set of files are for the -11 based MCB as indicated
>by the SFD. The .KEY files can be used to decrypt the
>matching files using the APUTIL program from a TSU tape.
>Unfortunately, the only TSU tapes I see on Tim's site are for
>TOPS-20 7.0. The TSU manual which describes how to decrypt
>stuff is in the DOC? tapes mentioned above.
>
>>NETGEN EXE 284 <455> 657673 1-Sep-88 4A(50) [10,7,NETGEN]
>>NIPGEN MAC 95 <455> 740216 11-Nov-85 [10,7,NIPGEN]
>>NML EXE 560 <455> 765777 7-Apr-86 4(146) [10,7,NML]
>>TKB36 EXE 100 <455> 131430 1-Sep-88 3A(10) [10,7,TKB36]
>>VNP36 EXE 132 <455> 441611 1-Sep-88 3A(7) [10,7,VNP36]
>
>[much snippage above]
>
>The above sets of files are TOPS-10 based.
And where the hell are the sources? Who the fuck redefined the
dammn packaging plan? Where is the BLISS36 used to build all
that stuff?
>
>>>Did you see the write up about the language tapes and their
>>>replacement for autopatch yesterday?
>>
>>About the Key files and TSU? What I didn't underestand is if a
decryption
>>key was needed to decrypt the key files. It sounds like you had to, in
the
>>form of matching key files (were these part of the original install of
the
>>software).
>
>The .KEY files are used to decrypt the matching files. What I
>don't see is the .VFY file used by APUTIL to drive the decrypt
>processes. This could be a problem. There may have been another
>decryption utility for installation. Of course, I'm not sure
>why any of this matters unless you have a real -10 and the
>proper -11 to match.
They may wish to rebuild it? They may wish to fix some bugs?
They may wish to do some development? You can't just ship
EXEs on the tape. Where are the monitor files?
jmfb...@aol.com
This directory should have a directory of the tape.
Without the tools I developed to make the MCB and set up the
areas for saving to tape, I can't tell you what is missing.
It certainly looks like the executable isn't there.
>
>NETGEN EXE 284 <455> 657673 1-Sep-88 4A(50) [10,7,NETGEN]
>NETGEN MAC 69 <455> 357477 20-Sep-85
>NGNCNF MAC 29 <455> 101474 20-Aug-85
>NGNDAT MAC 25 <455> 455477 20-Aug-85
>NGNDEV MAC 36 <455> 310200 20-Aug-85
>NGNDIA MAC 36 <455> 604114 18-Sep-85
>NGNFIN MAC 72 <455> 177007 2-Oct-85
>NGNMAC MAC 11 <455> 326317 20-Aug-85
>NGNPRM MAC 124 <455> 350647 20-Aug-85
>NGNPRS MAC 46 <455> 641765 20-Aug-85
> Total of 732 blocks in 10 files Checksum = 716340 on DSKB: [10,7,NETGEN]
I sure hope the control file is in CUSP.CTL.
>
>NIPGEN MAC 95 <455> 740216 11-Nov-85 [10,7,NIPGEN]
>NIPGEN EXE 48 <455> 440524 1-Sep-88 4(25)
> Total of 143 blocks in 2 files Checksum = 575110 on DSKB: [10,7,NIPGEN]
>
>NML EXE 560 <455> 765777 7-Apr-86 4(146) [10,7,NML]
> Total of 560 blocks in 1 file Checksum = 765777 on DSKB: [10,7,NML]
Where the fuck are these sources?
>
>TKB36 EXE 100 <455> 131430 1-Sep-88 3A(10) [10,7,TKB36]
> Total of 100 blocks in 1 file Checksum = 131430 on DSKB: [10,7,TKB36]
>
>VNP36 EXE 132 <455> 441611 1-Sep-88 3A(7) [10,7,VNP36]
> Total of 132 blocks in 1 file Checksum = 441611 on DSKB: [10,7,VNP36]
> Grand total of 4456 blocks in 145 files Checksum = 240150
>
> BACKUP reel number 1; end save set: 7.04 DECnet Distribution
> by version 5A(622) at 10:58:03 on 10-Oct-88
> written on MTB0:, on S/N 1026 at 1600 9TK; Blocking factor 4
> under TOPS-10 system 704(33461): RL375A DEC10 Development
This was not a distribution tape. Also note that you people
will have problems restoring this tape because the idiots
saved the files with a <455> protection. That 4 will invoke
the file daemon.
Sigh! All your restore instructions need to have a PROTECTION 055
or something.
Where are the monitor modules for DECnet? NCP also seems to be
missing. There may be another save set missing. Also note
that I think there were two NMLs. One to run on the MCB and
the other for the -10. I have no idea which NML this is.
That was another problem with the DECnet spec from up north.
They named everything the same name.
>
>>Did you see the write up about the language tapes and their
>>replacement for autopatch yesterday?
>
>About the Key files and TSU? What I didn't underestand is if a decryption
>key was needed to decrypt the key files. It sounds like you had to, in
the
>form of matching key files (were these part of the original install of the
>software).
Join the club. I don't understand why the decision was made to
do this. There were not going to be any more update tapes. There
wasn't going to be any maintenance. The product was at an end;
obfuscating the contents of these tapes ala VMS style was
ridiculous. I just don't understand why DPM didn't just wipe
the tapes and ship blanks. That would have destroyed everybody
else's work and satisfied his ego.
>
>>>Question. Did a majority of the DECnet software run on a PDP-11
>>
>>The MCB was an -11.
>
>Are these the DN87's?
No. (at least I don't think so.) MCBs cost a hell of lot
more than the 87s. The 87s could run the ANF-10 network
(module NETSER.MAC in the monitor).
> ... (Yes, I've been doing more reading, this time the
>decsystem-1080/1090 System Description).
I never heard of that one (or I've just suffered another brain
fart).
Frank da Cruz
: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
: >That's just a piece of it; trust me, things are not going to be a lot
:
: I've lived forty years with a space in my last name.
:
Me too (at least)!
: You know what that means
: in a computerised world. The most terrible thing that could happen is that
: more people have to deal with this kind of shit. I'll laugh.
:
Right, of course internationalization is a good thing. It'll be painful but
it needs doing. A few decisions along the way could have been better. For
example, putting combining diacritics after the base character rather than
before it wreaks havoc with realtime communications software -- you never
know that you have a whole character until the next one comes -- but what if
it doesn't, or it's unavoidably delayed?
The business about UTF-8 using C1 controls is serious. Those who think Plan 9
has solved all problems should try telnetting to it from a Unicode enabled
VT320 emulator and reading/sending some email in Russian.
> Here's a sort of accidental project that I've been doing over the past
> decade or so:
http://www.taronga.com/~peter/io/quotes.html
> I can't eat glass, and I don't have a wolf. :-<
>
Cool, now convert it to UTF-8, add:
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
at the top, and then you can have entries in Greek, Cyrillic, Hebrew,
Thai, etc. How to convert to UTF-8:
1. Download C-Kermit: http://www.columbia.edu/kermit/ckermit.html
2. Tell it to "translate file.html latin1 utf8 newfile.html"
To bring this around full-circle, I think internationalization would have
been surprisingly difficult on our 36-bit machines, which is ironic
considering their variable byte size. The fact is that so much software
and systems services were hardwired to 7-bit bytes would probably have been
a show stopper. (Heck, we could never even finish converting all that
TOPS-10 software to TOPS-20...)
- Frank
Peter da Silva
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>: I've lived forty years with a space in my last name.
>Me too (at least)!
Yeh, that's why I said "You know what that means...".
>Right, of course internationalization is a good thing. It'll be painful but
>it needs doing. A few decisions along the way could have been better. For
>example, putting combining diacritics after the base character rather than
>before it wreaks havoc with realtime communications software -- you never
>know that you have a whole character until the next one comes -- but what if
>it doesn't, or it's unavoidably delayed?
Actually, it doesn't. Realtime comm software generally sends fixed-length
or binary-delimited (length or bound characters) packets around, with
meta-information like text strings in formatted fields. What it causes
problems for is simple rendering of streamed text, like telnet.
Tim Shoppa
>
>>>>http://pdp-10.trailing-edge.com/pdp-10/DECNET-10_V4_0_SUP_BB-X116C-BB.HTML
>
>This was not a distribution tape.
Speaking as the guy who read in that tape, I can tell you that it
is an "official" DEC tape. Note, however, that the printed label reads
"DECNET-10 V4.0 SUP", so it is reasonable to suppose that this was
a "supplement" tape, and may not have everything.
>And where the hell are the sources? Who the fuck redefined the
>dammn packaging plan? Where is the BLISS36 used to build all
>that stuff?
I can only read in and make available tapes that folks care to share with
me. I'm quite certain that the real tapes we want are happily rotting away
in somebody's basement because they don't know how to or don't want to
preserve them. If you can pull any strings among folks who may have
such tapes, we will be *forever* grateful!
Was there any discussion of software preservation at the 36-bit part of
"DECWORLD 2001" that was discussed here? I would've been there to plead for
tapes myself, if someone had told me it was happening... maybe the preservation
of software just isn't important enough compared to swapping old stories?
(Wasn't TCMHC there to help out with this?) Were the DECWORLD 2001
participants even made aware that some of us are struggling to save this old
software?
Tim.
Frank da Cruz
: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
: >: I've lived forty years with a space in my last name.
:
: >Me too (at least)!
:
: Yeh, that's why I said "You know what that means...".
At least we don't have accents in our names!
: >Right, of course internationalization is a good thing. It'll be painful but
: >it needs doing. A few decisions along the way could have been better. For
: >example, putting combining diacritics after the base character rather than
: >before it wreaks havoc with realtime communications software -- you never
: >know that you have a whole character until the next one comes -- but what if
: >it doesn't, or it's unavoidably delayed?
:
: Actually, it doesn't. Realtime comm software generally sends fixed-length
: or binary-delimited (length or bound characters) packets around, with
: meta-information like text strings in formatted fields. What it causes
: problems for is simple rendering of streamed text, like telnet.
:
Or HTML. The web server just sends a stream of bytes; it doesn't know about
character sets. The web browser just gets a stream of bytes. How does it
know when it's safe to display a character, e.g. on a slow connection. Of
course the dumb way is to wait until the server closes the connection, but
users like it better if the page fills up in realtime.
Again, not a big deal, we'll live with it.
- Frank
Al Kossow
> "DECWORLD 2001" that was discussed here?
Eric and I brought the subject up at the 36 bit dinner. Neither of us have
been contacted by anyone since. My feeling when the subject was brought up
was a collective "oh well.." by the participants when we said that Compaq
no longer had any 36 bit software.
> I would've been there to plead for
> tapes myself, if someone had told me it was happening... maybe the preservation
> of software just isn't important enough compared to swapping old stories?
Again, Eric and I talked to the people that came that we could. My reaction
afterwards was that for the most part, people either weren't willing to admit
that they have the software, or they flat out said that they didn't.
> (Wasn't TCMHC there to help out with this?) Were the DECWORLD 2001
> participants even made aware that some of us are struggling to save this old
> software?
There was nothing official said. The only statement made was in the conference
introduction when John said the museum was interested in the historical
preservation of artifacts, included documentation and software.
Eric had his GT40 on display, and I made a small sign there requesting that
people contact us about archiving, but nothing has come of it.
Dan Cross
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>The business about UTF-8 using C1 controls is serious. Those who think Plan 9
>has solved all problems should try telnetting to it from a Unicode enabled
>VT320 emulator and reading/sending some email in Russian.
That's a fundamental abuse of the system (Plan 9). Plan 9 just isn't
meant to be used that way; it's a given that the user interacts with
the system through a terminal with a bitmapped display. You don't
telnet to it, you start up a terminal or drawterm and connect from
there. You'd have no trouble reading or sending email in Russian,
Japanese, or any number of other languages that way.
Your example is kind of like saying that your toaster sucks because
you can't bake bread in it. :-)
- Dan C.
Frank da Cruz
Dan Cross <cr...@augusta.math.psu.edu> wrote:
: In article <9k3rr7$iin$1...@newsmaster.cc.columbia.edu>,
If you're saying that Plan 9 doesn't have a Telnet server, nor allow login
from a serial port, like UNIX, then I suppose you're right, but I would be
surprised if it were true. These are the original UNIX people after all,
not Bill Gates.
Anyway, the problem I mentioned is not specific to Plan 9; it applies to
any platform at all that you can make a Telnet connection to.
- Frank
R.J.S.@not.a.net
>In article <5659mt84eeqmuc270...@4ax.com>,
> R.J.S. <n...@available.right.now> wrote:
>>Swap read error.
>
>ROTFL. Smarty pants.
Sorry, it wasn't meant to be "smart", but that part of memory seem to
be lost right now.
I think the -20 killed the process.
At least it wasn't an "AR/ARX parrty error". That stopped the system.
Side story:
Once I caused the message "Undetected AR/ARX parity error" to come
out on the console of 1026 every few minutes. After a while, I went
into the machine room to see Steve Jablonsky, JoeF, and Rufes (from
Field Sabotage) reading the console, and about to crash the system to
run diags (this was at 2 PM or so.) So I had to fess up, to keep them
from halting the system.
They were rather pissed, but the rest of us had a good laugh.
Dan Cross
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>If you're saying that Plan 9 doesn't have a Telnet server, nor allow login
>from a serial port, like UNIX, then I suppose you're right, but I would be
>surprised if it were true. These are the original UNIX people after all,
>not Bill Gates.
Well, there is a telnet server, but that's not the prefered method for
logging in. In particular, there is no tty driver nor support for
cursor addressed terminals. You can't even Del (^C) out of an errant
process under Plan 9 without the window system (rio, 8.5) to handle the
keystroke processing and note generation. One thing about Bell Labs is
that even back in the Unix days (say, mid 1980's on) they were using
bitmapped terminals (the blit, etc) in prefernce to, eg, the VT series.
The original Unix people didn't really do TCP/IP for a long time;
prefering, instead, their own datakit network. That's not to say they
didn't make use of TCP/IP, but telnet is somewhat of an anachronism for
them. These days, they just look for reliable byte-stream connections
that they run the 9P file system protocol over. The heavy reliance on
TCP/IP and so on in the Unix world is more from the Berkeley camp, I
believe.
To my knowledge, there is no way to ``login'' via a serial port in the
way that Unix allows (ie, getty prompting for a login and invoking
/bin/login). There are ways to start ppp connections and so forth, but
that's somewhat different.
>Anyway, the problem I mentioned is not specific to Plan 9; it applies to
>any platform at all that you can make a Telnet connection to.
No, I understand what you're saying now and see what you mean. I'm
afraid I misinterpreted you earlier and we were talking at
cross-purposes; I was refering simply to being able to sort UTF-8
numerically and find the byte sequences starting runes, while you were
refering to the much deeper issue of what those runes mean and wether
the sorting actually makes sense. Yes, these issues are valid and not
specific to Plan 9.
- Dan C.
Tim Shoppa
>> (Wasn't TCMHC there to help out with this?) Were the DECWORLD 2001
>> participants even made aware that some of us are struggling to save this old
>> software?
>
>There was nothing official said. The only statement made was in the conference
>introduction when John said the museum was interested in the historical
>preservation of artifacts, included documentation and software.
>
>Eric had his GT40 on display, and I made a small sign there requesting that
>people contact us about archiving, but nothing has come of it.
Thanks, it's good to know that a good attempt was made by you and Eric!
Tim.
Tim Shoppa
says...
>Side story:
>
>Once I caused the message "Undetected AR/ARX parity error" to come
>out on the console of 1026 every few minutes.
Is it possible that this originated the phrase "There are no undetected
errors that we know of?" :-)
Tim.
Zane H. Healy
>>CEX MAP 9 <455> 245415 12-Nov-85 [10,7,MCB]
>>CEX STB 2 <455> 075715 12-Nov-85
>>CEX TSK 11 <455> 411750 12-Nov-85
>>CEX KEY 41 <455> 237646 16-Sep-88
> [snip...]
> The above set of files are for the -11 based MCB as indicated
> by the SFD. The .KEY files can be used to decrypt the
All I can say at this point is... Oh, Blush! How could I be so
blind <shakes head in bemusement>. Many thanks!
Zane
Zane H. Healy
> In article <fkY87.113368$Tx5.1...@e420r-chi1.usenetserver.com>,
> "Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
>>DECNET DIR 0 <055> 000000 6-Oct-88 DSKB: [10,7]
>> Total of 0 blocks in 1 file Checksum = 000000 on DSKB: [10,7]
> This directory should have a directory of the tape.
Despite the fact it shows up as zero size here it contained the directory
listing I included.
>>>The MCB was an -11.
>>
>>Are these the DN87's?
> No. (at least I don't think so.) MCBs cost a hell of lot
> more than the 87s. The 87s could run the ANF-10 network
> (module NETSER.MAC in the monitor).
OK, I wasn't sure if it was a MCB or not. It could also apparently do
DECnet Phase II and Phase III.
>> ... (Yes, I've been doing more reading, this time the
>>decsystem-1080/1090 System Description).
> I never heard of that one (or I've just suffered another brain
> fart).
It's one of the manuals that, I think Eric Smith, has scanned in. It's an
Adobe Acrobat file on http://www.36bit.org
Zane
Zane H. Healy
> In article <9k3p21$cj2$1...@bob.news.rcn.net>, jmfb...@aol.com says...
>>
>>>>>http://pdp-10.trailing-edge.com/pdp-10/DECNET-10_V4_0_SUP_BB-X116C-BB.HTML
>>
>>This was not a distribution tape.
> Speaking as the guy who read in that tape, I can tell you that it
> is an "official" DEC tape. Note, however, that the printed label reads
> "DECNET-10 V4.0 SUP", so it is reasonable to suppose that this was
> a "supplement" tape, and may not have everything.
OK, with that and a couple other kicks in the brain, plus a bunch of good
info I think I know how to catagorize it. My thanks to everyone that's
helped to figure out what this is.
>>And where the hell are the sources? Who the fuck redefined the
>>dammn packaging plan? Where is the BLISS36 used to build all
>>that stuff?
> I can only read in and make available tapes that folks care to share with
> me. I'm quite certain that the real tapes we want are happily rotting away
> in somebody's basement because they don't know how to or don't want to
> preserve them. If you can pull any strings among folks who may have
> such tapes, we will be *forever* grateful!
I don't think *anyone* has a complaint with you Tim, you've done a great
job! BTW, thank you for making the ISO images available, I'd never gotten
around to ordering the PDP-10 one, I'll be burning a copy of it ASAP.
Zane
Peter da Silva
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>Or HTML. The web server just sends a stream of bytes; it doesn't know about
>character sets. The web browser just gets a stream of bytes. How does it
>know when it's safe to display a character, e.g. on a slow connection.
There are so many related problems that web clients have to deal with (not
only embedded images, but incomplete tables, scroll bars, etc) that this one
is lost in the noise. Either waiting for the next base character before
displaying the current glyph, or displaying the current glyph and rewriting
it if it's changed, are quite adequate solutions.
Frank da Cruz
Dan Cross <cr...@augusta.math.psu.edu> wrote (of Plan 9):
: ...
: Well, there is a telnet server, but that's not the prefered method for
: logging in. In particular, there is no tty driver nor support for
: cursor addressed terminals. You can't even Del (^C) out of an errant
: process under Plan 9 without the window system (rio, 8.5) to handle the
: keystroke processing and note generation. One thing about Bell Labs is
: that even back in the Unix days (say, mid 1980's on) they were using
: bitmapped terminals (the blit, etc) in prefernce to, eg, the VT series.
Sure, but there always has to be a nonproprietary cross-platform plain-text
way for the user of one computer to access the "shell" of another computer
to use its features -- file management, etc. UNIX, VMS, TOPS-xx, and all
traditional OS's supply this (even IBM mainframes can be accessed remotely
using an ASCII terminal given the appropriate front end or a linemode
Telnet server). Once you start *requiring* X or Blit or 3270 protocols or
some Microsoft TLA to get simple remote access to a computer, you've
discarded a fundamental and time-honored principal.
Now I realize that is precisely Microsoft's goal -- to allow access to
Microsoft platforms and data only from other Microsoft platforms or
applications. The rest of us need to be careful not to fall into this kind
of thinking. To this day, plain text and not some godawful GUI glop is
the "lingua franca" of computing (character-set issues aside for the
moment), and terminal access a`la Telnet (rlogin, ssh, direct dialup, etc)
is the sine qua non of cross-platform interoperability.
Everything else changes and will keep changing faster than anybody can keep
up with, and those who are foolish enough to record important information
only in the fashionable format-du-jour are doomed to lose it. It's not for
nothing that we're still exchanging email and netnews as plain text. Even
on comp.os.plan9 :-)
- Frank
Dan Cross
>way for the user of one computer to access the "shell" of another computer
>to use its features -- file management, etc. UNIX, VMS, TOPS-xx, and all
>traditional OS's supply this (even IBM mainframes can be accessed remotely
>using an ASCII terminal given the appropriate front end or a linemode
>Telnet server). Once you start *requiring* X or Blit or 3270 protocols or
>some Microsoft TLA to get simple remote access to a computer, you've
>discarded a fundamental and time-honored principal.
(Heh, tell it to Rob Pike. :-)
Well sure, and Plan 9 does support telnet and SSH, among others (which
still require a lot of glop to get to a shell, btw. All that TCP, IP,
Ethernet or, God forbid, ATM stuff underneath, say, SSH is non-trivial
to implement. telnet itself with all the option negotiation stuff can
be pretty tough to implement). But that doesn't mean that those
protocols should be the prefered means of access. In Plan 9, they're
very minimalistic.
Sometimes it's best to recognize that time honored principles are very
admirable, and have a place, but it's not necessarily the primary place.
In the Plan 9 world, you can use telnet, but you end up with a very
low-function terminal. If you use a bitmapped display, you are then
able to exploit the system much more effectively.
btw- an aside; the ubiquitous use of a single file system protocol (9P)
and per-process computable namespaces in Plan 9 has done away with
massive amounts of complexity that were inherent in the Unix way of
doing things.
>Now I realize that is precisely Microsoft's goal -- to allow access to
>Microsoft platforms and data only from other Microsoft platforms or
>applications. The rest of us need to be careful not to fall into this kind
>of thinking. To this day, plain text and not some godawful GUI glop is
>the "lingua franca" of computing (character-set issues aside for the
>moment), and terminal access a`la Telnet (rlogin, ssh, direct dialup, etc)
>is the sine qua non of cross-platform interoperability.
No disagreement here.
>Everything else changes and will keep changing faster than anybody can keep
>up with, and those who are foolish enough to record important information
>only in the fashionable format-du-jour are doomed to lose it. It's not for
>nothing that we're still exchanging email and netnews as plain text. Even
>on comp.os.plan9 :-)
Well, one of the time honored principles of Plan 9 (and, indeed, Unix)
is to use text as a standard, LCD format for the exchange of portable
data. Plan 9 exploits this very well indeed (doing away, even, with
the DBM and CBT file formats that were in Unix; nearly everything in
Plan 9 is just straight up UTF-8 encoded text. In fact, most devices
and services implement a filesystem interface that speaks UTF-8).
btw, notice that sometimes one sees UTF-8 in comp.os.plan9. :-)
- Dan C.
(ps- Frank, you realize that coming from North of 36th street you're
untrustable. ;-)
Jim Thomas
/BAH> Also note that you people
/BAH> will have problems restoring this tape because the idiots
/BAH> saved the files with a <455> protection. That 4 will invoke
/BAH> the file daemon.
? At least in 6.03 if FILDAE was not running there was no problem.
Was it automatically started up later if a 4xx protection was encountered?
Nothead
those who know me have no need of my name
>In article <9k1i7c$fhr$1...@newsmaster.cc.columbia.edu>,
>Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>>Soon we'll all be using UTF-8, where the whole model of character
>>processing changes so radically you won't believe it.
>Yeh, I know. The simplest solution I see for this is to do all the conversions
>on input and output, and store stuff internally in 32-bit ints in ISO10646
>format.
natually. utf is a transport mechanism for ucs, it shouldn't be used
internally.
jmfb...@aol.com
MACRO-10 always says that "No errors detected". That message
always made Jim chuckle. It's also a fine test to weed out
the newbie. Those who understand the real meaning of the
message have great potential.
jmfb...@aol.com
R.J.S.@not.a.net wrote:
>On Mon, 30 Jul 01 08:13:32 GMT, jmfb...@aol.com wrote:
>
>>In article <5659mt84eeqmuc270...@4ax.com>,
>> R.J.S. <n...@available.right.now> wrote:
>>>Swap read error.
>>
>>ROTFL. Smarty pants.
>
>Sorry, it wasn't meant to be "smart", but that part of memory seem to
>be lost right now.
Oh, it was _your_ swap read error. I hadn't read it that way.
That's even funnier <GRIN>.
>
>I think the -20 killed the process.
>
>At least it wasn't an "AR/ARX parrty error". That stopped the system.
>
>Side story:
>
>Once I caused the message "Undetected AR/ARX parity error" to come
>out on the console of 1026 every few minutes. After a while, I went
>into the machine room to see Steve Jablonsky, JoeF, and Rufes (from
>Field Sabotage) reading the console, and about to crash the system to
>run diags (this was at 2 PM or so.) So I had to fess up, to keep them
>from halting the system.
And how did you do that? It took some doing to fool Jablonsky.
>
>They were rather pissed, but the rest of us had a good laugh.
Once in a great while, I'd have a system crasher. To verify
that I had really caused the crash, I'd do a SEND ALL message
telling everybody to close their files, then do a SEND ALL
countdown, then try the program that crashed the system.
Then I'd get to write TW a love note with pointers to the
program and how to run it. For some reason, the bugs I'd
uncover were always in his balliwack.
I had less pissed off people doing that than if I'd just tried
it with no warning.
jmfb...@aol.com
>> In article <9k3p21$cj2$1...@bob.news.rcn.net>, jmfb...@aol.com says...
>> I can only read in and make available tapes that folks care to share
with
>> me. I'm quite certain that the real tapes we want are happily rotting
away
>> in somebody's basement because they don't know how to or don't want to
>> preserve them. If you can pull any strings among folks who may have
>> such tapes, we will be *forever* grateful!
>
>I don't think *anyone* has a complaint with you Tim, you've done a great
>job! BTW, thank you for making the ISO images available, I'd never gotten
>around to ordering the PDP-10 one, I'll be burning a copy of it ASAP.
Oh, shit! Tim, I wasn't swearing at you. I was having a royal
hissy fit because of the fact that everything, I tried to prevent,
happened. Now that I've calmed down a scintilla, note that the
dates of the MCB files coincide with the 7.03 ship. That was
probably the main thing that set me off. The idiots didn't
package software rebuilt for 7.04. I'm getting more and more
suspicious of that whole release.
I also remembered that, even if I hadn't become too sick to work,
I wouldn't have been able to do anything about the quality of
that ship anyway. I was mostly swearing at myself for being
so stupid.
jmfb...@aol.com
"Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
>jmfb...@aol.com wrote:
>> In article <fkY87.113368$Tx5.1...@e420r-chi1.usenetserver.com>,
>> "Zane H. Healy" <hea...@shell1.aracnet.com> wrote:
>>>DECNET DIR 0 <055> 000000 6-Oct-88 DSKB: [10,7]
>>> Total of 0 blocks in 1 file Checksum = 000000 on DSKB: [10,7]
>
>> This directory should have a directory of the tape.
Well, that's something good. It still means that they did not
use the packaging tools that I developed. Those tools made
sure that there were blocks (even though the checksum of the
directory would never be correct).
>
>Despite the fact it shows up as zero size here it contained the directory
>listing I included.
>
>>>>The MCB was an -11.
>>>
>>>Are these the DN87's?
>
>> No. (at least I don't think so.) MCBs cost a hell of lot
>> more than the 87s. The 87s could run the ANF-10 network
>> (module NETSER.MAC in the monitor).
>
>OK, I wasn't sure if it was a MCB or not. It could also apparently do
>DECnet Phase II and Phase III.
IIRC, Phase II was for the -20. By the time the MCB got funded
for the -10, we were able to skip Phase II and go right to implementing
Phase III.
jmfb...@aol.com
Jim Thomas <tho...@atlas.cfht.hawaii.edu> wrote:
>>>>>> "/BAH" == jmfbahciv <jmfb...@aol.com> writes:
>
> /BAH> Also note that you people
> /BAH> will have problems restoring this tape because the idiots
> /BAH> saved the files with a <455> protection. That 4 will invoke
> /BAH> the file daemon.
>
>? At least in 6.03 if FILDAE was not running there was no problem.
There still shouldn't be for all the monitors after 6.03. However,
if the FILDAE wasn't running, the protection assumptions would
always err to the "more protected" side.
>Was it automatically started up later if a 4xx protection was encountered?
Not automatically. However, if the FILDAE PID existed (established
by running at least once/system load) and the FILDAE wasn't receiving
IPCF messages (remember there's been a ton of QUASAR crashing problems
with the emulator), then the people who are new to playing with
TOPS-10 might not be able to figure out how to get at files after
a protection error was generated. Also, if these files were copied
to SYS: with the same protection, an ACCESS.USR would have to be
in SYS: if the file daemon was running. And I never tested
SYS: file daemon quirks.
jmfb...@aol.com
Tim Shoppa <sho...@trailing-edge.com> wrote:
>In article <9k3p21$cj2$1...@bob.news.rcn.net>, jmfb...@aol.com says...
>>
>>>>>http://pdp-10.trailing-edge.com/pdp-10/DECNET-10_V4_0_SUP_BB-X116C-BB.
HTML
>>
>>This was not a distribution tape.
>
>Speaking as the guy who read in that tape, I can tell you that it
>is an "official" DEC tape.
Yea, Yea. I know. I was speaking from the other end. I wrote
the damned packaging plan. I'm not pissed at you, Tim. Just
so bloody frustrated at idiocy...mostly mine. I completely
underestimated the intent of destruction of the group's leadership.
I knew they were destroying people; I had no idea that they
had the balls to zero the bits.
> ... Note, however, that the printed label reads
>"DECNET-10 V4.0 SUP", so it is reasonable to suppose that this was
>a "supplement" tape, and may not have everything.
AFAICT, it's a supplement to the stuff shipped as part of the
7.03 product.
>
>>And where the hell are the sources? Who the fuck redefined the
>>dammn packaging plan? Where is the BLISS36 used to build all
>>that stuff?
>
>I can only read in and make available tapes that folks care to share with
>me.
Yes. I'm now remembering where those tapes came from. If I can
stay pissed, I'll be working on correcting it all. I just get so
damned tired of cleaning up their messes.
> ...I'm quite certain that the real tapes we want are happily rotting away
>in somebody's basement because they don't know how to or don't want to
>preserve them. If you can pull any strings among folks who may have
>such tapes, we will be *forever* grateful!
Most of the problem lies with the fact that everything that was
archived within the company is just gone despite the contract
with the archive people. We didn't bring home copies of stuff
because there were two places where the bits were permanently
stored, archives and SDC. Besides it was a tad against one's
contract to privately keep all this stuff.
>
>Was there any discussion of software preservation at the 36-bit part of
>"DECWORLD 2001" that was discussed here? I would've been there to plead
for
>tapes myself, if someone had told me it was happening... maybe the
preservation
>of software just isn't important enough compared to swapping old stories?
>(Wasn't TCMHC there to help out with this?) Were the DECWORLD 2001
>participants even made aware that some of us are struggling to save this
old
>software?
WEll, if the TCMHC is that museum that Bell tinkers with, I wouldn't
give them anything that smelled of 36-bits.
Brian {Hamilton Kelly}
> In article <9k3tu...@drn.newsguy.com>,
> Tim Shoppa <sho...@trailing-edge.com> wrote:
>
> > ...I'm quite certain that the real tapes we want are happily rotting away
> >in somebody's basement because they don't know how to or don't want to
> >preserve them. If you can pull any strings among folks who may have
> >such tapes, we will be *forever* grateful!
>
> Most of the problem lies with the fact that everything that was
> archived within the company is just gone despite the contract
> with the archive people. We didn't bring home copies of stuff
> because there were two places where the bits were permanently
> stored, archives and SDC. Besides it was a tad against one's
> contract to privately keep all this stuff.
It sounds as if you've got a variation on what happened with the Elliott
903/905/920B/920C source code. After GEC bought the real-time side of
Elliotts (via the MECSL conglomerate) from the short time that the 900
series was under the aegis of ICL (along with the 4100 & 803/805 series),
most development stopped.
There were one or two new pieces of software (one idea in particular was
brilliant, where the assembler output on paper-tape was wound up
front-end-first, so that when the linker read it in, the symbol table
came first), but mostly development was moribund.
Eventually, the Elliott Computer Users Association got them to agree to
release the sources to the membership, for cataloguing, and with a view
to permitting user-driven development.
The problem was, no one really knew where the sources were. Large
swathes of them were found (this is all on paper tape or printout, OK?)
in series of tea chests stored in a bike shed (i.e. virtually "outside")
at Borehamwood.
I was the poor schmuck that sorted through this lot; it didn't exactly
improve the preservation when mice got into a storeroom and nibbled some
of the tapes whilst they were under my "jurisdiction" (although luckily
every single one of those tapes was a duplicate; phew)
--
Brian {Hamilton Kelly} b...@dsl.co.uk
"We have gone from a world of concentrated knowledge and wisdom to one of
distributed ignorance. And we know and understand less while being incr-
easingly capable." Prof. Peter Cochrane, formerly of BT Labs
Al Kossow
>
> I was the poor schmuck that sorted through this lot; it didn't exactly
> improve the preservation when mice got into a storeroom and nibbled some
> of the tapes whilst they were under my "jurisdiction" (although luckily
> every single one of those tapes was a duplicate; phew)
>
Does it still exist today?
Brian {Hamilton Kelly}
I don't know: I've had no involvement with the 900 series since 1981.
Last I heard, Terry Froggatt was "doing things" with the Algol 60
compiler sources, as was Don Hunter.
After cataloguing, I shipped everything back to the ECUA secretariat
(which by that time was the GECCUA secretariat).
Michael L. Umbricht
Tim Shoppa wrote:
>
> me. I'm quite certain that the real tapes we want are happily rotting away
> in somebody's basement because they don't know how to or don't want to
Tim, and this is said with all due respect and the most sincere
appreciation for your preservation efforts, I am even _more_ certain
that this is NOT true :)
You see, the Retro-Computing Society of RI has been quietly plotting and
scheming a most significant acquisition. We had planned to hold off on
the public announcement 'till we had the goods in hand, but at this
point it is a done deal. Since you asked, we'll give you a preview of
our good fortune - we have struck the Mother Load.
RCS is preparing to take delivery of an extensive collection of original
(ie. DIGITAL labeled) media containing TOPS-10, DECnet and related
software. There are DECtapes, 9-track reels, RP06 packs and RX01's.
From what I have personally seen it appears to be a _complete_ series of
distribution releases, w/ updates, et al dating back to about 1985,
maybe as early as '82.
RCS will soon have the whole lot of it, and for those who are unfamiliar
with our group: rest assured that we have both the means and a strong
commitment to fully preserve each and every bit of it.
But wait, it gets even better: it's unlikely that we will find even one
iota of rot in the bunch. The reel-to-reel tapes, for instance, were
pulled from a climate controlled, archival quality, offsite storage
facility only 1 month ago! The remainder of the media is currently in
an air-conditioned, HEPA-filtered machine room where it has been safely
stored since the day it was delivered by DEC.
The first batch of DECtapes and 9-trk reels are en route to Providence
and will be hand delivered within the hour. Watch this space for an
initial inventory. The rest of the hual will arrive over the next
couple of weekends, and we'll be posting periodic updates here as we
accession the items into our collection.
And yes, of course, we will make the contents fully available.
> preserve them. If you can pull any strings among folks who may have
> such tapes, we will be *forever* grateful!
Is this close to what you had in mind ;)
-mikeu
Michael Umbricht
The Retro-Computing Society of RI
http://www.osfn.org/rcs/
Arthur Krewat
>
> RCS is preparing to take delivery of an extensive collection of original
> (ie. DIGITAL labeled) media containing TOPS-10, DECnet and related
> software. There are DECtapes, 9-track reels, RP06 packs and RX01's.
> From what I have personally seen it appears to be a _complete_ series of
> distribution releases, w/ updates, et al dating back to about 1985,
> maybe as early as '82.
Do you have the ability to read DECtapes? I have a person who is in possesion
of a "box full of DECtapes" that came from a KA10 long ago (LIRICS).
> RCS will soon have the whole lot of it, and for those who are unfamiliar
> with our group: rest assured that we have both the means and a strong
> commitment to fully preserve each and every bit of it.
I'm willing to do a mirror!
> But wait, it gets even better: it's unlikely that we will find even one
> iota of rot in the bunch. The reel-to-reel tapes, for instance, were
> pulled from a climate controlled, archival quality, offsite storage
> facility only 1 month ago! The remainder of the media is currently in
> an air-conditioned, HEPA-filtered machine room where it has been safely
> stored since the day it was delivered by DEC.
I had a collection of tapes from circa '84 to '89 and each one was NOT
in a climate-controlled atmosphere. They cycled between 20 degrees F and
120 degrees F each year for about 14 years. I was able to read each
and every one on a sun3 with 1600BPI tape drive. Clean the heads? Yes,
between each pass, since they got a little gunky on each pass :)
aak
Michael L. Umbricht
>
> The first batch of DECtapes and 9-trk reels are en route to Providence
> and will be hand delivered within the hour. Watch this space for an
> initial inventory.
Here's the list of magtape that just arrived:
P014DECT01 1986 BB-BT99H-BB TOPS-10 703A ATPCH TP14 16MT9
P014DECT02 1986 BB-BT99H-BB TOPS-10 703A ATPCH TP14 16MT9
P018DECT01 1988 BB-JR93D-BB TOPS-10 T03A TP 1-17 16MT9
P018DECT02 1988 BB-BT99L-BB TOPS-10 703A ATPCH TP18 16MT9
P019DECT01 1988 BB-JR93E-BB TOPS-10 703A ATPCH TP 1-18
P019DECT02 1988 BB-BT99M-BB TOPS-10 703A ATPCH TP19 16MT9
P020DECT01 1988 BB-JR93F-BB TOPS-10 704 ATPCH TP 1-19 16M
P020DECT02 1988 BB-BT99N-BB TOPS-10 704 ATPCH TP20 16MT9
P021DECT01 1989 BB-JR93G-BB TOPS-10 704 ATPCH TP 1-20
P021DECT02 1989 BB-BT99O-BB TOPS-10 704 ATPCH TP#21 16MT9
P022DECT01 1989 BB-JR93H-BB TOPS-10 704 ATPCH TP 1-21
P022DECT02 1989 BB-BT99P-BB TOPS-10 704 ATPCH TP#22
P023DECT01 1989 BB-JR93I-BB TOPS-10 704 ATPCH TP 1-22
P023DECT02 1989 BB-BT99Q-BB TOPS-10 704 ATPCH TP#23
P024DECT01 1989 BB-JR93J-BB TOPS-10 704 ATPCH TP 1-23
P024DECT02 1990 BB-BT99R-BB TOPS-10 704 ATPCH TP#24
P025DECT01 1990 BB-BT99S-BB TOPS-10 704 TSU01 TP 1 OF 3
P025DECT02 1990 BB-JR93K-BB TOPS-10 704 TSU01 TP 2 OF 3
P025DECT03 1990 BB-PBDEA-BB TOPS-10 704 TSU01 TP 3 OF 3
Zane H. Healy
> Here's the list of magtape that just arrived:
> P014DECT01 1986 BB-BT99H-BB TOPS-10 703A ATPCH TP14 16MT9
> P014DECT02 1986 BB-BT99H-BB TOPS-10 703A ATPCH TP14 16MT9
> P018DECT01 1988 BB-JR93D-BB TOPS-10 T03A TP 1-17 16MT9
> P018DECT02 1988 BB-BT99L-BB TOPS-10 703A ATPCH TP18 16MT9
> P019DECT01 1988 BB-JR93E-BB TOPS-10 703A ATPCH TP 1-18
> P019DECT02 1988 BB-BT99M-BB TOPS-10 703A ATPCH TP19 16MT9
> P020DECT01 1988 BB-JR93F-BB TOPS-10 704 ATPCH TP 1-19 16M
> P020DECT02 1988 BB-BT99N-BB TOPS-10 704 ATPCH TP20 16MT9
> P021DECT01 1989 BB-JR93G-BB TOPS-10 704 ATPCH TP 1-20
> P021DECT02 1989 BB-BT99O-BB TOPS-10 704 ATPCH TP#21 16MT9
> P022DECT01 1989 BB-JR93H-BB TOPS-10 704 ATPCH TP 1-21
> P022DECT02 1989 BB-BT99P-BB TOPS-10 704 ATPCH TP#22
> P023DECT01 1989 BB-JR93I-BB TOPS-10 704 ATPCH TP 1-22
> P023DECT02 1989 BB-BT99Q-BB TOPS-10 704 ATPCH TP#23
> P024DECT01 1989 BB-JR93J-BB TOPS-10 704 ATPCH TP 1-23
> P024DECT02 1990 BB-BT99R-BB TOPS-10 704 ATPCH TP#24
> P025DECT01 1990 BB-BT99S-BB TOPS-10 704 TSU01 TP 1 OF 3
> P025DECT02 1990 BB-JR93K-BB TOPS-10 704 TSU01 TP 2 OF 3
> P025DECT03 1990 BB-PBDEA-BB TOPS-10 704 TSU01 TP 3 OF 3
Well, the good news is these are pretty much all tapes that aren't already
available. Though I think the first two are covered in one tape that is
available. The bad news is, these are just patches (of course that might
also be good news at some point).
I for one can't wait to see what else you've turned up! Congrats!
Zane
Michael L. Umbricht
>
> "Michael L. Umbricht" wrote:
> >
> > RCS is preparing to take delivery of an extensive collection of original
> > (ie. DIGITAL labeled) media containing TOPS-10, DECnet and related
> > software. There are DECtapes, 9-track reels, RP06 packs and RX01's.
>
> of a "box full of DECtapes" that came from a KA10 long ago (LIRICS).
Does LINCtape count :) Let me check around with the other RCS members.
I configured a system this morning to read the 9-track tapes. The first
batch should be online in just a few days.
-mikeu
Michael L. Umbricht
>
> In alt.sys.pdp10 Michael L. Umbricht <mi...@osfn.org> wrote:
> > Here's the list of magtape that just arrived:
>
Thank you.
Here's the inventory of some of the DECtape:
MAINDEC-10-DDZEC-F-UB 4/28/77 MASSBUS ROTATING MEMORY DIAGNOSTIC CUSP DECTAPE C1975,76
MAINDEC-10-DHZAA-D-UB 09/07/77 PDP-10 MEMORY DIAGNOSTIC C1975,77
MAINDEC-10-DDZGA-F-UB 02/17/78 PDP-10 COMMUNICATIONS CUSP DL10/DC10 C1975,76
AL-7397O-DD NR DGZBBO0 KL10 SYS CUSP #2 C1976,79
DEC-10-OTMAA-B-UB TOPS-10 RSX20F AUX DT C1977,78
DEC-10-OTMAA-B-UB TOPS-10 RSX20F AUX DT C1977,78
DEC-10-OTMAA-E-UB TOPS-10 RSX20F DT C1977,78
DEC-10-OTMAA-E-UB TOPS-10 RSX20F DT C1977,78
AL-J331A-BB TOPS-10 RSX20F AUX DT V12-40 C1979
AL-J189A-BB TOPS-10 V13-41 RSX20F AUX DT C1979
AL-J190B-BB TOPS-10 V14-17 RSX20F DT C1980
AL-X454B-BB TOPS-10 RSX20F V15-15 DT-A C1985
AL-X455B-BB TOPS-10 RSX20F V15-15 DT-B C1985
AL-EV71A-BB TOPS-10 RSX20F V15-15 DT-C C1985
AL-X454C-BB TOPS-10 RSX20F V15-50 DT-A C1986
AL-X455C-BB TOPS-10 RSX20F V15-50 DT-B C1986
AL-EV71B-BB TOPS-10 RSX20F V15-50 DT-C C1986
AL-X454D-BB TOPS-10 RSX20F V15-50 DT-A C1986
Keith F. Lynch
> From what I have personally seen it appears to be a _complete_
> series of distribution releases, w/ updates, et al dating back
> to about 1985, maybe as early as '82.
Good luck. Tapes are only guaranteed readable for three years.
> Michael Umbricht
> The Retro-Computing Society of RI
> http://www.osfn.org/rcs/
But do you have the old (pre-1981) HUMAN-NETS archives? I've been
looking for them for years. Thanks.
--
Keith F. Lynch - k...@keithlynch.net - http://keithlynch.net/
I always welcome replies to my e-mail, postings, and web pages, but
unsolicited bulk e-mail sent to thousands of randomly collected
addresses is not acceptable, and I do complain to the spammer's ISP.
Arthur Krewat
>
> Michael L. Umbricht <mi...@shrimp.osfn.org> wrote:
> > From what I have personally seen it appears to be a _complete_
> > series of distribution releases, w/ updates, et al dating back
> > to about 1985, maybe as early as '82.
>
> Good luck. Tapes are only guaranteed readable for three years.
I have read tapes that date back almost 20 years, and the only
thing I had to do was to make sure I cleaned the head on each pass.
I have a VMS distribution on magtape from around '78, and it read
fine on the first past, and the second, the third, the fourth,
etc. etc.
In general, magtapes last a long time - as long as you have a good
tape drive to read them with.
aak
Ken McMonigal
>
> VB06C
>
> In Marlboro, there were 4. They were on Dick's system and used for
> doing the print sets and such. (All the "S. Foonley" pages!)
> (Dicks's system ran SUDS, the Stanford University Drawing System.)
>
> There really were a GT40, but had minimal code in the -11. They were
> connected thru a DL10 (hence the limit of 4), and the graphics engine
> got it's vector list from the -10 via the DL.
>
> On Fri, 27 Jul 2001 23:02:32 -0400, John Sauter <J_Sa...@Empire.Net>
> wrote:
>
> >Frank da Cruz wrote (excerpted):
> >"Maybe there were some genuine, bus-attached, native
> >graphics devices on PDP-10s, like there were on some
> >of the other PDP-x's and -xx's, with light pens, etc."
> >
> >The PDP-6/KA10 system at Stanford had a bus-attached
> >Type 30 display that we ripped off the PDP-1. I believe
> >it used two 10-bit fields out of the DATAO to plot a
> >point. The Type 30 had a 1024 by 1024 resolution,
> >but only plotted white points of a few intensities.
> >There was a light pen on the PDP-1, but I never saw
> >it used on the PDP-6. It worked by setting Program
> >Flag 1 on the PDP-1, so it may not have been brought
> >with the display.
> > John Sauter (J_Sa...@Empire.Net)
At Case, while we had a number of VT02's to a PDP-8 to
a DA-10 interface to the KA10 bus, we also had a LDS-I
(Line Drawing System from Evans & Sutherland, presumably)
display processor dually-ported to MD-10 memory bus & KA10 bus.
The LDS-I then drove its' displays. (Most treasured
application - our little friends, the shooting spaceships)
-------
The Algol compiler used at Case Institute of Technology, after finding
25 errors in the source (e.g., like you spelled BEGIN as BEGNI), would
print: "At this point, we suggest you try re-reading the manual." - Univac
1108
Zane H. Healy
> I have read tapes that date back almost 20 years, and the only
> thing I had to do was to make sure I cleaned the head on each pass.
I've read 9-Track tapes that were over 20 years old, of course this was in a
production environment, and they'd spent their entire life in a tape vault.
> In general, magtapes last a long time - as long as you have a good
> tape drive to read them with.
9-Track's might, but it's good to remember that others such as 8mm's and
4mm's won't. Personally I won't trust either of those past a couple years.
If you read the one government report that was available online a few years
ago, 9-Track and DLT are the two best types of tape to store your data to.
However, the oldest DLT's I've used are 6-7 years old so I really can't say
based on personal experience.
Zane
Arthur Krewat
>
> In alt.sys.pdp10 Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
> > I have read tapes that date back almost 20 years, and the only
> > thing I had to do was to make sure I cleaned the head on each pass.
>
> I've read 9-Track tapes that were over 20 years old, of course this was in a
> production environment, and they'd spent their entire life in a tape vault.
My personal backup tapes were written on 18 years ago and they were NOT stored in
a nice environment. The only problem I had with them was sometimes the tape
came loose on the reel, causing my CDC 9-track (TU80-style) to fault.
The tapes themselves are at least 23 years old.
Friends have magtapes in their closets, and I've been very successful
reading them. One of them had a read error but the drive retried two
times and the data came off (probably dirt on the head).
> > In general, magtapes last a long time - as long as you have a good
> > tape drive to read them with.
>
> 9-Track's might, but it's good to remember that others such as 8mm's and
> 4mm's won't. Personally I won't trust either of those past a couple years.
> If you read the one government report that was available online a few years
> ago, 9-Track and DLT are the two best types of tape to store your data to.
> However, the oldest DLT's I've used are 6-7 years old so I really can't say
> based on personal experience.
4mm tapes stink, I've had some very good experiences with 5GB Exabyte 8mm's,
they still read after many years.
Of course DLT's are great, look at how wide the tape is (1"?). Plus,
they were made by DEC to begin with :)
aak
Michael L. Umbricht
>
> "Keith F. Lynch" wrote:
> >
> > Michael L. Umbricht <mi...@shrimp.osfn.org> wrote:
> > > From what I have personally seen it appears to be a _complete_
> > > series of distribution releases, w/ updates, et al dating back
> > > to about 1985, maybe as early as '82.
> >
> > Good luck. Tapes are only guaranteed readable for three years.
Thanks, but we didn't need any luck. The first 6 tapes (the earliest
from this batch, dating to 1986 and '88) have been read, verified, and
read a second time without errors or diffs.
> I have read tapes that date back almost 20 years, and the only
> thing I had to do was to make sure I cleaned the head on each pass.
Yes, a bottle of alcohol (not for me! for the heads) and a quantity of
lint-free lens cloth and Q-tips must be kept close at hand.
BTW, RCS frequently reads pdp-12 LINCtapes from _more_ than 20 years
ago, with no trouble.
-mikeu
John Sauter
At Case, while we had a number of VT02's to a PDP-8 to
a DA-10 interface to the KA10 bus, we also had a LDS-I
(Line Drawing System from Evans & Sutherland, presumably)
display processor dually-ported to MD-10 memory bus & KA10 bus. The
LDS-I then drove its' displays. (Most treasured
application - our little friends, the shooting spaceships)
[John Sauter]
At SAIL Phil Petit wrote PDP-6 Spacewar for the Type 30.
Phil was also the author of FAIL, a 1-pass assembler,
and creator of the name Foonly. When he was testing
his assembler he had it read from the teletype and
typed "FOO FOO FOONLY WAS A BASTARD." As far as I
know that was the first use of the word Foonly.
There was a story that Evans had suggested the name
LDS-1 to Sutherland. Sutherland agreed, not knowing
that LDS is the abbreviation for Latter Day Saints,
the Mormons.
John Sauter (J_Sa...@Empire.Net)
Bob Supnik
<kre...@bartek.dontspamme.net> wrote:
>"Michael L. Umbricht" wrote:
<snip>
>Do you have the ability to read DECtapes? I have a person who is in possesion
>of a "box full of DECtapes" that came from a KA10 long ago (LIRICS).
If you have DECtapes that need to be transcribed, Dave Gesswein
(pdp8.net) has a setup that works. He successfully transcribed the
PDP-15 DECtapes that were used to resurrect the PDP-15 Advanced
Monitor System, and OS/8 DECtapes as well. His setup is a TD8E - the
entirely software driven "cheap" DECtape controller - which is ideal
for coping with format differences among various DECtape standards.
/Bob Supnik
Alexandre Pechtchanski
wrote:
[ snip ]
>BTW, RCS frequently reads pdp-12 LINCtapes from _more_ than 20 years
>ago, with no trouble.
LINCtapes as well as DECtapes (was there actually any difference?) are almost
indestructible. I remember successfully reading DECtape with a hope (1/4", as
in paper filing) punched through.
--
[ When replying, remove *'s from address ]
Alexandre Pechtchanski, Systems Manager, RUH, NY