On 01/24/2015 12:28 AM, Cory Smelosky wrote:
Hey all,
Need to pick up a replacement NVRAM for my VLC...what're compatible ICs?
http://www.mouser.com/Search/ProductDetail.aspx?R=M48T02-150PC1virtualkey51…
work, or are Sun ones not compatible?
"Sun ones"...different models of Suns use different ones. I believe
the one you want is a DS12887A.
-Dave
--
Dave McGuire, AK4HZ/3
New Kensington, PA
I just thought I'd make yet an announcement.
(Maybe I should find a better forum for this?)
The last week I've been busy with FTP improvements and performance, and I've managed to improve this a lot.
Enough that it is worth sending information out that people should upgrade if they have installed this.
The FTP client and server have improved performance and some additional features. Along with this I also changed the protocol format for RSX special mode transfers. This is not backwards compatible, and due to an initial design miss, the old ftp client/server will not reliably detect this incompatibility, resulting in broken files if RSX mode is used between the old and new version. This will not be a problem going forward. If you run FTP from RSX to fetch the new package, use BLOCK mode instead of RSX mode, and fetch the disk image and not the tape image, and you'll be fine. Once upgraded, RSX mode is definitely the recommended mode for the future. For all kind of files.
TCP itself increased the receive buffer size, which also improves performance for everything that would be interested in higher throughput.
I've also gone over the distribution and installation scripts and fixed a few minor details.
As usual, the distribution is available from:
ftp://madame.update.uu.se/bqtcp.dsk
ftp://madame.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
The documentation is also available through ftp on Madame, or also at http://madame.update.uu.se/tcpipdoc
Johnny
All in all,
On 2015-01-16 04:47, Johnny Billquist wrote:
There have been lots of positive comments, and obviously some people
have even tested using the software.
Of course, a bug was also found. A really weird corner case with
severely loading the network stack and having a socket in listen state
programatically could trigger a corruption of kernel memory.
So I've cut a new release with the bug fixed.
While I'm at it I also realize that I forgot to mention that included in
the distribution is also a simple IRC client as well as a simple IRC robot.
I've also taken a little time to slightly improve the documentation, and
the documentation is now also available directly by ftp from
Madame.Update.UU.SE, so you do not need to get the whole distribution
and unpack it to just read something.
So - same as before. Disk image and tape image are available at
Madame.Update.UU.SE. Use anonymous ftp.
Disk image is also available at ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip.
The disk image is a virtual RL02 disk. Can be used with any emulator, or
also directly inside RSX if you have virtual devices available.
Happy hacking.
Johnny
On 2015-01-14 00:40, Johnny Billquist wrote:
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
Thanks. I didn't think it was the co-located server I was using but clearly it was!
On 20 January 2015 at 17:07, Brian Schenkenberger, VAXman- <system at tmesis.com> wrote:
Mark Wickens <mark at wickensonline.co.uk> writes:
>Could someone please try and ssh to port 12622 on hecnet.eu
>
>I'm having trouble with my Mikrotik setup and just want to see whether the
>issue is at the other end that I'm testing from (I doubt it but would like
>to rule it out).
I got there. It's requesting username/password which I do not have but it
did everything else ssh should do in its initial handshake.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Mark Wickens <mark at wickensonline.co.uk> writes:
Could someone please try and ssh to port 12622 on hecnet.eu
I'm having trouble with my Mikrotik setup and just want to see whether the
issue is at the other end that I'm testing from (I doubt it but would like
to rule it out).
I got there. It's requesting username/password which I do not have but it
did everything else ssh should do in its initial handshake.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Ah well that's *very* encouraging - must be the system at the other end then!!
That's a couple of hours of my life I'll never get back...
On 20 January 2015 at 16:59, Ian McLaughlin <ian at platinum.net> wrote:
I get password prompt, but you forgot to give out your SYSTEM password :)
Ian
On Jan 20, 2015, at 8:57 AM, Mark Wickens <mark at wickensonline.co.uk> wrote:
Could someone please try and ssh to port 12622 on hecnet.eu
I'm having trouble with my Mikrotik setup and just want to see whether the issue is at the other end that I'm testing from (I doubt it but would like to rule it out).
Thanks, Mark.
---
Filter service subscribers can train this email as spam or not-spam here
I get password prompt, but you forgot to give out your SYSTEM password :)
Ian
On Jan 20, 2015, at 8:57 AM, Mark Wickens <mark at wickensonline.co.uk> wrote:
Could someone please try and ssh to port 12622 on hecnet.eu
I'm having trouble with my Mikrotik setup and just want to see whether the issue is at the other end that I'm testing from (I doubt it but would like to rule it out).
Thanks, Mark.
---
Filter service subscribers can train this email as spam or not-spam here
Could someone please try and ssh to port 12622 on hecnet.eu
I'm having trouble with my Mikrotik setup and just want to see whether the issue is at the other end that I'm testing from (I doubt it but would like to rule it out).
Thanks, Mark.
