When Multics was officially released as free software a couple of
years ago, there was a flurry of activity aimed at getting some sort
of emulator up and running to run it. Did anything ever come of that
or did folks just lose interest (or find out that the needed
GE/Honeywell hardware was too poorly-documented to write an emulator
Got a hard down situation and need to re-install/recreate the BBS system I
HDD makes swishy noises when shaken, haven't tried stirring yet.
I /guess/ a bootable MCA SCSI card would work too... ;)
I had the 160MB drive, but anything above 30 would work - i guess i'll just
have to use a SCSI Drive for the file storage area once i get an MCA SCSI
Gary G. Sparkes Jr.
Well, it's been a long time project, but I'm happy to finally announce a
more public initial release of TCP/IP for RSX-11M-PLUS.
This is the result of over 20 years of development. Needless to say,
I've been doing a lot of things over the years, and this code have been
through four reimplementations over the years.
What I now release is something that I believe is a nice and useful
piece of software. I am aware of the fact that most people do not use
these machines any longer, but if someone actually wants to talk to me
about support for this or other RSX software, let me know.
Also, feel free to spread this information to anyone who might be
So - what is in this release?
It is a complete implementation of ARP, IP, UDP, and TCP for
RSX-11M-PLUS. It has been tested on RSX-11M-PLUS V4.6, but should work
on any V4 release. There might be some small tweaks or fixes required,
but nothing major.
It do require a system with split I/D-space, or else at least the TCP
part will not fit.
For Unibus machines, it should be possible to run without any additional
software except what is in a base RSX distribution.
For Q-bus machines, DECnet is required for ethernet networking.
The TCP/IP stack can co-exist with DECnet.
Some utilities also utilize RMS for file access.
A bunch of tools, utilities and libraries are also included. These include:
. IFCONFIG network configuration tool.
. NETSTAT network information tool.
. DNS client
. FTP daemon
. FTP client
. HTTP server
. TELNET client (rudimentary)
. TFTP client
. TFTP server
. INET server that can do SINK, ECHO, DAYTIME, QUOTE, and IDENT
. NTP client
. LPR client that sits in the queue manager (rudimentary)
. FORTRAN-77 library
. BASIC+2 library
. PDP-11 C library
The implementation fulfills most of the requirements put forth in RFC
1122. There are a few limitations because of restrictions in the PDP-11,
but none of them should really cause any problems.
Documentation is still on the thin side, but example configs are also
provided, along with installation scripts.
A bunch of test programs and example programs are also included, as well
as the sources of all tools and libraries.
The TCP/IP stack itself only comes in binary form.
All tools are also included precompiled in the distribution, so an
installation only have to build the stack itself for your system, and
then you should be ready to go.
The API only have a slight resemblance to the Unix sockets API. However,
if someone sits down to write code to use TCP/IP under RSX, I'm sure
they will discover that it is extremely easy to use the libraries, or
the basic functions.
The TCP/IP implementation is mostly written as device drivers. This also
have some other interesting implications, such as it is possible to
access TCP as a normal file. You can, for instance do something similar
to the Unix netcat command by issuing the MCR command:
> PIP TI:=TC:"foo.com";4711
which would open a connection to foo.com, on port 4711, and any data
sent from that machine will be shown on the terminal.
The resources used by TCP/IP are modest. A memory area (size selectable
at generation/startup) is used internally. The amount of memory in the
private pool limits the amount of data that can be buffered. Normal pool
is used in a small quantity for each TCP port that is open.
People are welcome to play around with this, and make improvements.
Contributions of code is most welcome.
There are still lots of things to do. The programs marked as rudimentary
should be rewritten.
The most obvious thing still missing is a telnet daemon, which probably
is my next step.
However, the reason for now announcing the release is that it can
finally be distributed natively from an RSX host.
The main locations to download the TCP/IP for RSX are:
Madame.Update.UU.SE (anonymous ftp).
This is one of my development systems for this software. It runs under
E11, and if things are down, I blame E11. :-)
When connected, you are already in the right directory. There is both an
RL02 disk image there, which can be downloaded by anyone. If you happen
to have an RSX system which you are conneting from, you can also try
getting the BQTCP.TAP tape image. Such an image will not transport
cleanly to a non-RSX system, however. Sorry.
ftp.Update.UU.SE (anonymous ftp) - /pub/pdp11/rsx/tcpip
The disk image is normally duplicated to ftp.update.uu.se as well, so
the same file can be found there.
I hope some people will find this useful/amusing. :-)
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I've made tremendous progress on my 3B2 emulator. It's being
implemented under the SIMH simulator platform, which has been a huge
My WE32100 core is getting closer to being complete. I'd consider it
alpha quality right now, but it has enough instruction coverage to
pass the 3B2's power-on self tests and to (barely) run some of the 3B2
firmware mode tools.
Implementing the WE32100 core has been thanks to the processor manual
and assembly language manuals that are available on BitSavers, but
outside of the CPU, virtually all of my understanding of the 3B2's
architecture has come from studying the ROMs and the SYSVR3 source
code. I've also been helped by having remote access to a running 3B2
so I can assemble and disassemble code using the real AT&T tools.
Beyond that, I have found precious little documentation.
I'm at the point now where I'm pretty well stuck until I can find more
information. I understand large chunks of the memory map now and
should be able to do things like simulate the floppy and hard disk
controller, but there are large gaps in my understanding. There are
many undocumented registers that are used by the firmware, but don't
appear in the SYSV source code anywhere. What they mean and what
they're for is anybody's guess. I've just stubbed them out for now.
If anybody has access to schematics, architecture docs, or other
memory map information, I'd be eternally grateful if you could share
New hobby thing. ;)
Wildcat! 4 running on it, stock out of box config. If you don't see all the
menus except for help and send to sysop, wait till I validate users. When I
get back home i'll set it to give non-validated users more permissions,
Gary G. Sparkes Jr.
After stating that I expected TSX Plus to be available generally to the
collector community this week, I have had a number of folks request
access to TSX plus via private FTP.
Please be a bit patient and wait for me to post it to a new website I'm
in the process of creating. I now have full agreement from S&H to
generally release TSX Plus, COBOL, etc., to the collector community via
a simple download.
BTW: I have converted all of the original documentation, which was in HP
print file format to PDFs for easier and more general use.
Over time I will likely be able to release some of the utilities, etc.
that S&H used internally with TSX plus. Some time ago S&H gave me all
of their RL02 packs and a SMD drive with everything they had related to
the PDP-11 version of TSX. (They have a current version of TSX for X86
systems which is NOT free and is NOT part of this release).
Over time, there may be a project to scan the source listings and
recreate TSX Plus source code. (The source listings are available on
bitsavers.org (pdf/dec/pdp11/tsxPlus/listings/). Unfortunately, we are
missing the MACRO definitions in the source listings. Some of us are
working on that issue. (Note: All of the original PDP-11 source code was
accidentally lost by S&H).
I will also make available any software that other folks submit to me
related to TSX on my website.
Bickley Consulting West Inc.
"Black holes are where God is dividing by zero"
Does anyone happen to have documentation, schematics, or software for the
Quay 900? It's a system based on the Quay 90F/MPS single-board Z80
computer and two MPI double-sided 8-inch floppy drives.
The drives are MPI part no. 77618022, apparently a 9406 variant but not
listed in the drive manual on Bitsavers. I suspect the pinout is close to
the SA800/850 pinout (industry standard), but I was surprised to find that
none of the variants in the 9406 manual have a pinout similar to that.
> On Dec 17, 2014, at 7:35 AM, Al Kossow wrote:
> > I should have one, somewhere.. Bear or Earl probably have one as well.
> Apparently I don't have an XY472, or at least one doesn't show in
> inventory. I was totally ready to jump in and save the day, too!
I'll try to check tonight when I get home... spreadsheet says I have 8
Xylogics SMD controllers... have to see if any is an XY472.
Earl the Squirrel
I spent the last week trying to document some of my analyzers and ICEs. There
are tons of photos, firmware dumps and some new manuals on bitsavers under
appliedMicrosystems, biomation, hmi, futuredata, hp/te hp/64000 and hp/64700.
The HMI-200-68000 manual that arrived today had the 68K DOS software in the
binder, zipped and up now under bits/HuntsvilleMicrosystems
Has anyone ever noticed a pattern to the numbering on the underside of MMI PALs?
It would be nice not to have to lift the labels off them. The ones I indentified
Most are protected. Every once and a while I found one that wasn't.
I'd be interested in other AMC ICE firmware dumps to add to the archive. I've made
some progress identifying the buses and what the various chunks of firmware are for.
Next thing to do is trace the pinouts and see if the house-marked 6809 memory mapper
is a MC6829.
From looking at the manual, the HMI-200 is kind of interesting in that it can run
without a target. The Applied Microsystems units require a 'null target' board.