> From: Mike Stein
> I don't think I can scan the print set; IIRC the pages were longer
> than 14".
How much longer? My A3 scanner will take up to 17". I'd be happy to scan them
for you (and return them afterwards) if you send them to me.
(BTW, this offer is open to everyone/anyone - although if I get 23 sets of
prints, please don't expect instant service! Please contact me first.)
Noel
Someone on #classiccmp showed pictures of a DDR SDRAM module with
piggybacked TSOP memory chips. I've never heard of doing this with
surface-mounted devices.
http://imgur.com/a/CGk8h
--
David Griffith
dave at 661.org
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
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
interested, anywhere.
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.
. PING
. TRACEROUTE
. 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
--
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
One of my DECserver 90M PSUs got dropped and stopped working as a result,
possibly because it got pulled by the cable. That sounds like the kind of
damage that might be repairable. I tried to open the enclosure and I found a
hole under one of the labels, expecting it to be a screw hole, but it isn't.
I am guessing you just have to pry the halves apart, but without knowing
where the clips are inside it is easy just to break the thing.
Does anyone know how you open these PSUs?
Thanks
Rob
PS Yes I know these PSUs are notoriously unreliable, and that you can make a
PSU with a DIN plug and a wall wart, but I would still like the original to
work if possible.
We did a lot more debugging on the TC12 LINCtape controller.
We saw a 500ns glitch in the LMU MOTION signal that corresponded to a short
slowdown in tape speed. We will investigate this next week.
We entered the LINC instruction to check a single block (0707) in the left
switches and a block number (0777-0000) in the right switches. When we
pressed the DO key it should go to that block on the LINCtape. With large
block numbers (07xx) and with the tape positioned half way through the tape
it worked OK. With lower block numbers it sometimes could not find the
block and searched back-and-forth on the tape. The logic analyzer showed
that the block numbers were correct in a sequence of several blocks, and
then it will read a bad block number. The TC12 would tell the TU55 to turn
around, it would read a good block number, realize that it was going the
wrong direction, and turn the tape around. It would then read a good block
number, and then a bad block number, and turn around.
At this point we don't think that we are working with bad tapes, but the
problem might be in either the TU56 tape drive, or the TC12 LINCtape
controller. We see bad behavior in both devices so we will do as Charles
Lasner suggested and swap a TU55 and TU56 between the PDP-12 and the
PDP-8/I. This will let us test the TU56 with a known good TC01 LINCtape
controller, and test a known good TU55 with a questionable TC12 LINCtape
controller.
We ran the A-to-D converter test and were rewarded with a display on the
VR14 that showed correct operation of the knobs and A-to-D converters.
--
Michael Thompson
Hi All,
we have a 1039 in our space with the user guide, but without any service
docs. Our specimen does not react to buttons except the reset and test
buttons. the four statusleds light up on a reset and after a second the
center two leds start blinking in sequence. paper and pens are loaded as
per the user guide.
anyone with documentation on this thing?
--
Met vriendelijke Groet,
Simon Claessen
drukknop.nl
Thinking I had an easy solution to the missing outer slide, I ordered a $40
pair of new heavy-duty rack slides from eBay. Beautiful pieces and
ball-bearing slides, decent quality hardware too. Only had to drill a couple
of holes in them so they'd match the drive chassis, mounted everything up,
and then discovered that they were 1/4" too narrow, no matter how I arranged
the brackets, and the drive wouldn't slide between the rack rails. Crap!
So I bought two 24" pieces of 2 x 2 x 1/8" angle iron at the local steel
place for a whopping $1.40, drilled four holes in each, sanded off the
scale/surface rust, bolted them to the rack and slid the drive right in. You
can't even see the "homemade" part unless you're really looking, too.
Should've done that to start with. If I ever need to service the drive, I'll
just slide it back out and set it on the bench...
http://s1181.photobucket.com/user/DrCharlesMorris/media/PDP-8/P09-29-15_19.…http://s1181.photobucket.com/user/DrCharlesMorris/media/PDP-8/P09-29-15_19.…
However, if anyone should stumble over a set of stock RX sliding rails I'd
be interested for the sake of originality ;)
Jay, let me know exactly what measurements you would need. There's a pretty
good view of the inside rail on the second pic.
thanks
Charles
> From: Liam Proven
I am _very much_ in sympathy with the complaints here; I too feel that modern
computers are too complex, etc. (Although some of it, like the entire computer
turning into a single chip, were/are inevitable/unavoidable.)
I like the functionality of modern system, but I feel they are _more complex
than they need to be_ to generate that level of functionality.
However, one thing I am going to quibble with:
> This is a nice explanatory quote:
> The main reasons TempleOS is simple and beautiful are because it's
> ring-0-only .. Linux wants to be a secure, multi-user mainframe. ...
> It was simple, open and hackable. It was not networked. ... It was
^^^^^^^^^^^^^
> simple and unsecure. If you don't have malware and you don't have
> bugs, protection just slows things down and makes the code complicated.
Note the part I highlighted. If you want to have a system that's
network-capable, which is pretty much mandatory for a _really_ usable system
in this day and age, i) that means Web-capable, and ii) if it's Web-capable
today, it has to be able to handle what I dub 'active content' (JavaScript,
etc) - i.e. content coming off the network which contains code, which runs in
the local machine.
To paraphrase a certain well-known SF work, IMO active content is probably the
worst idea since humans' fore-fathers crawled out of the mud. It's
_potentially_ a giant, gaping security hole - one that in today's OS's is
responsible for a huge share of security issues. (There _is_ a way to have
systems which aren't as vulnerable, but it means having military-grade
security on everyone's machine - and no, I don't mean crypto; probably not
likely, alas.) I mourn the early days of the Web, when there was no active
content - just text, images, etc, etc. But no, they had to add all sorts of
flashy eye candy - and did so in a way that makes basically all modern
machines horribly insecure. But let me dispense with the soap box...
Anyway, the inevitable consequence is that if you want a networked machine,
it's _not_ going to be simple. Alas.
You're basically sharing the machine with _lots_ of other people -
effectively, every Tom, Dick and Jane out there in the Internet. In other
words, you need everything one normally saw/sees in a time-sharing machine.
(And I'm not talking about wimpy ones like Unix/Linux. I mean industrial
strength ones like Multics.)
Noel
>> Not sure why you have VARCHARs for primary keys, why not use the
>> conventional auto-increment int so you can dispense with
>> the LastGeneratedArtifactID table.
>>
> Because my artifact ID's are not always just numbers. In some cases
> they may already be marked on an artifact (though typically not for
> manuals - but this is just the first of a set of such projects, and they
> *are* marked on many of my computer boards).
You can still force the artifact ID VARCHARS to be unique, and index them as
well, of course. There are at least a couple of reasons to have primary
keys that are independent of the "visible" key. First, if the user-visible
key ever changes (what if the inventory tag falls off and is lost?), that
will break all the links that refer to that record (or else you'll need
extra code to handle this). Also, there have been many times when some
aspect of a key that's directly tied to an external bit of information needs
to change format - numeric to character, or length change, or... This too
will break things.
> No, I don't need made up primary keys. The other tables have the keys
> they need to guarantee uniqueness - in some cases the PK is made of up
> two or more columns. I seriously dislike the current fad of inventing
> such keys when they are not needed.
I too used to develop new databases this way, figuring that since a certain
bit of information is guaranteed to be unique (or that I want to guarantee
its uniqueness), I'd use that for the primary key. After getting bitten
more times than not, I now almost always create an auto-number key whose
only purpose may be for internal linkage.
(I recently developed a project using Zoho Creator, which was a learning
experience to say the least. It's worth noting that an explicit ID field is
part of *every* data table that you can create there - there's no way around
it. And, it turned out that it was pretty darn helpful a lot of the time,
too.)
>> Another thing, although MySQL is fine but for this I think SQLite might
>> be a better choice of db. Its access methods are all in-process ie. no
>> external
>> dbms service to bother with, just a library to link in and the physical
>> database is a disk file (.s3db extension). It has a much 'lighter' db
>> footprint.
>>
> As I mentioned in another response, I truly dislike SQLite, based on my
> experience with it on my Garmin GPS.
I'm still not sure why - my experience has been very good. What bad
experiences have you had?
~~
Mark Moulding
Hi all --
I've been working on getting a Xerox 1186 workstation up and running
again, using the floppy images on Bitsavers. I have the "Medley"
Interlisp-D software installed (after writing out and installing from
~25 floppies) and running and I'm attempting to load in the related
libraries and software (another 10-20 floppies or so). Some of these
libraries have dependencies on various font files, which I do not seem
to have and haven't been able to track down. I see vague references in
the documentation to a floppy disk set labeled "Display Fonts" but these
do not appear to be on Bitsavers.
From writing out a few floppies and looking at their contents on the
1186, I do not believe that these have any relationship to the Viewpoint
Font disks (though if anyone knows differently, do let me know).
Anyone out there have any experience with this? Anyone happen to have
these floppies and/or images of them?
Thanks as always,
Josh