test-drb June 2015

test-drb@ccmp.vtda.org

165 participants
285 discussions

by rodsmallwood52＠btinternet.com

Hi Guys I am off to Friedrichshafen for a few days and will be back on 1-JUL-2015. The next two batches of front panels will be: 8/e Type A 1. Old switch position markings (1 and 6 vertical) 2. Line around switch Area 3. Vertical lines between groups of three lamps 4. Holes for switch shaft and lock predrilled 8/e Type B 1. New switch position markings (1 and 6 angled) 2. Line around switch Area 3. Vertical lines between groups of three lamps 4. Holes for switch shaft and lock predrilled Price as before $95.00 + $15.00 Shipping Rod Smallwood

9 years, 6 months

What are the differences between the DEC RP11-C and RP11-E controllers?

by p.gebhardt＠ymail.com

Hi list, the subject sais it all: While seeking for information on the RP11-C on the web (I saved a RP03 from being scrapped 3 years ago), I came across a hint, that there was also a RP11-E controller. At least using google, there is practically not a single information/document on the RP11-E other than its existence in the past. Is the difference maybe just a different input voltage specification (110V vs. 220V)? Who knows anything on the difference between the C- and the E-type, Google doesn't? :) I'd be happy on any hints. Kind regards, Pierre ------------------------------------------------------------------------------- Pierre's collection of classic computers moved to: http://www.digitalheritage.de

9 years, 6 months

[Simh] [HECnet] Announcing TCP/IP for RSX-11M-PLUS

by bqt＠softjar.se

Aw, chucks. After reading the other day about someone who was talking about VMS and the wish for DHCP, I actually decided that it was time that BQTCP/IP also got DHCP. So, without further ado - I cut a new release. One bugfix for a bug in the TCP state machine, which could get stuck, but otherwise the big reason is that DHCP is now implemented. Read the documentation, or ask me questions. The IPGEN procedure will create installation files for use with DHCP, but if you are upgrading >from a previous version, you might want to make comparisons with the new command files, and merge any new stuff in, if you want to use DHCP. If you don't care about DHCP, then nothing needs to change in the current configs. DHCP tries to be clever, and handle some different options, but there are parts that I do not use myself, that I have not tested, or sometimes implemented. In such cases you might see some messages on the console. Pass such information on to me, and I can improve things. DHCP is written in PDP-11 C. If you do not have that compiler, you will not be able to recompile the code. Sources are provided, along with a binary that runs, and do not depend on any shared libraries. The DHCP code also makes use of some functions and interfaces to the IP stack and the interface drivers that others might find useful to reference to if they are interested in doing low level stuff with TCP/IP. (Such as reading/writing interface configs and routing tables.) 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 I hope people will find this latest release useful, and my next project right now is telnet (this time really...). Johnny On 2015-06-08 19:03, Johnny Billquist wrote: > About three months since I last announced anything. There have been > various development since, and I figured I should encourage people who > are using BQTCP/IP for RSX to upgrade to the latest release. > > A short list of changes: > ICMP: > . ICMP packets accidentally lost the source IP address informaton when > returning information to a program. - Fixed. > > TCP: > . User timers on TCP sockets could erroneously stop. - Fixed. > . User timers now reset on completed reads, so that you do > not get a timeout if you are constantly completing reads. > . Sockets in Fin-Wait-2 could sometimes get stuck in that state. > - Fixed. > . If a TCP session got an RST, it could get into a bad state. - Fixed. > . Added the ability to send URGENT data in TCP. (Receive ignores any > URGENT flags.) > . Added a special I/O function to read from TCP without formatting. > > DNS: > . Improved stability of DNS client daemon code. > > FTP: > . FTP client and server performance improved. > . FTP server logging added. > . Improvements in FTP server and client for handling files with implicit > CFLF. > . Implemented primitive handling of Unix file paths implemented in FTP > server. This allows most web browsers to access FTP repositories > under RSX. > > I also did some performance testing using FTP. > > FTP from a modern Unix system of BQTCP.DSK in binary mode to both RSX > and 2.11BSD, running under simh on the same physical machine: > 2.11BSD: 210s > RSX: 141s > > From RSX (E11) to the same machines: > 2.11BSD: 240s > RSX: 137s > > I honestly do not know why transfer from RSX to 2.11BSD took longer than > from Unix, but transfer from RSX to RSX was faster compared to Unix to > RSX. I would have expected both to be slower or faster. But the numbers > are interesting, and show that the RSX TCP implementation is doing > fairly well, even through it goes through the DECnet ethernet driver, as > compared to 2.11BSD which runs TCP/IP more "native". > > 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 > > I hope people will find this latest release useful, and my next project > right now is telnet. > > Johnny > > 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 >>> >> >> > > _______________________________________________ > Simh mailing list > Simh at trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh

9 years, 6 months

organizing a trip to Cuba

by COURYHOUSE＠aol.com

whenever I see video from there is to full of 50s cars! Neat! Ed# In a message dated 6/23/2015 4:24:37 A.M. US Mountain Standard Time, billdegnan at gmail.com writes: I don't know, but there could be some WOW stuff there. I have to admit, the day I heard Barak Obama said the US was going to free up restrictions with Cuba I thought about the cars....and the COMPUTERS!...UNIVAC? IBM 701? Anything could be there. On Tue, Jun 23, 2015 at 6:46 AM, Paul Birkel <pbirkel at gmail.com> wrote: > I wonder to what Soviet equipment they would have upgraded? > > On Mon, Jun 22, 2015 at 5:06 PM, william degnan <billdegnan at gmail.com> > wrote: > > > > > > http://millennialmainframer.com/2014/12/ibm-still-waiting-cuba-pay-mainfram… > > > > Who's up for it? > > > > B > > >

9 years, 6 months

A 10-Second Trick Lowers High Blood Sugar, REVERSES High Blood Glucose-Without A Doctor!

by dr_dave＠determinationbig.com

A 10-Second Trick Lowers High Blood Sugar, REVERSES High Blood Glucose-Without A Doctor! http://www.determinationbig.com/e5d86Noe3z3NMMVKyxFMyKnnvMMhk0jmt725/little Update Preferences- http://www.determinationbig.com/form/bact86ljqeI37MMVKyxFMyKnnvMMhk0jmt5ha

9 years, 6 months

HP 2113e Battery resistor

by marc.verdiell＠gmail.com

And I opened the pack up, and you are 100% right! It's just a plastic shell containing 10 big C-size cells, 3.5 A.hr each, indeed from the time period it must be NiCd! Now if I can find similar cells I will be able to reconstruct the pack inside the same shell. It will even look like the original. Thanks again. Marc ------------------------------ "J. David Bryan" <jdbryan at acm.org> said > On this machine the battery connectors are just two pronged, + and -, > so no thermistor connection apparently. That marks it as an "A-version" power supply. > I just need to find new small 12V lead batteries that fit. Note that the "A" supply used a 12 Volt nickel-cadmium battery pack (per page IXA-1 of the M/E/F-Series ERD), and the charger is a constant-current supply. The pack is not broken down in the parts list but presumably would have contained ten 1.2-Volt cells. The "B" supply used a 14 Volt lead-acid battery pack (ERD IXB-5), so seven 2.0-Volt cells, and the charger is a constant-voltage supply. If you use lead-acid batteries with the "A" power supply, you may wind up overcharging them and shortening their life. -- Dave ------------------------------

9 years, 6 months

M68K Prog Ref Man (4th Ed)

by jnc＠mercury.lcs.mit.edu

I have a spare copy of this if anyone wants it (1984 edition). Noel

9 years, 6 months

6 historic tech items that were rescued from the trash

by lbickley＠bickleywest.com

Thought this article from Infoworld would encourage all of us whose goal is rescuing vintage computers from scrap heaps: http://www.infoworld.com/article/2937725/computer-hardware/6-historic-tech-… Lyle -- Lyle Bickley Bickley Consulting West Inc. http://bickleywest.com "Black holes are where God is dividing by zero"

9 years, 6 months

X11 expertise on ancient HW sought... (4-plane visual (overlay) via X-server on MS-WIndows)

by lists＠y42.org

[also posted to comp.graphics.x today] Hello Folks, I'm trying to get an application that currently uses a local display on an ancient DEC Alpha workstation with a (for the time) mid-to-high-end graphics controller (ZLX-E2) to instead use an X-server running under MS-Windows. The application is complaining that it cannot find a "4/5-bit visual". It almost certainly wants to use this visual for an overlay, as the application displays moving objects superimposed on a map. On the original hardware, xdpyinfo tells me: > [...] > supported pixmap formats: > [...] > depth 4, bits_per_pixel 8, scanline_pad 32 > [...] > screen #0: > [...] > depths (4): 8, 12, 24, 4 > [...] > number of visuals: 21 > [lots of other visuals here, but no 4-plane except for the following] > visual: > visual id: 0x36 > class: PseudoColor > depth: 4 planes > available colormap entries: 16 > red, green, blue masks: 0x0, 0x0, 0x0 > significant bits in color specification: 4 bits and "xprop -root" tells me: > [...] > SERVER_OVERLAY_VISUALS(SERVER_OVERLAY_VISUALS) = 0x36, 0x1, 0x0, 0x1 As you can see, there seems to be exactly one overlay, whose visual id (0x36) corresponds to the single 4-plane visual listed by xdpyinfo. When I use the above commands to retrieve the capabilities of the MS-Windows X-server (Exceed, in this case), xdpyinfo does not list a 4-plane visual at all. "xprop" lists lots of overlays, 24 in total, all of them 8-plane visuals. The MS-Windows box is running Windows-7 (64bit) and has a Nvidia Quadro 400 GPU. I used the "Nvidia Control Panel" to set "Enable overlay" to "on" in the "Manage 3D settings" section. Also, in the Exceed X-server configuration I enabled "OpenGL", and within that enabled "Overlay Support" and "GLX 1.3 Support". I conclude that the MS-Windows SW/HW system (X-server, MS-Win GPU driver, GPU) cannot offer 4-plane visuals. However, I don't know what system component(s) is/are the cause the problem. I have tested VcXsrv, Reflection-X, Exceed (with 3D option), X-Win32 and even the ancient DEC Pathworks X-server eXcursion with no success. I'm working on getting an evaluation copy of PTC's MKSTools X/Server. Of the X-servers I've tested, Exceed seems to offer the most configuration parameters. I'm not even sure the Quadro 400 can handle 4bpp "visuals", or whatever MS-Windows calls them. In fact, I wonder if any modern hardware offers 4bpp capability. On my Linux box with a GeForce GT 430 I don't have any 4-plane visuals, and xprop doesn't mention any overlays either. I'm somewhat confused about where overlays fit into the X scheme. I have seen lots of references to overlays in an OpenGL context, however the Alpha seems not to have any OpenGL capability: GLX is not in the list of extentions printed by xdpyinfo. Can someone clear this up for me? Am I correct to assume that the GPU must support 4bpp in order for it even to be possible for the X-server to propagate a 4-plane visual to a client? If yes, how can I determine if a GPU supports 4bpp? Nvidia is very sparing with the information in their specs for the Quadro 400 GPU. Assuming I can find a GPU that supports/offers 4bpp, does anyone know an X-server product/project that can provide 4-plane overlays? thanks, Rob

9 years, 6 months

UNIBUS extension card/cable sets Was: Looking for info on National Semiconductor RAM board (VAX 11/730)

by jnc＠mercury.lcs.mit.edu

> From: tony duell > a 'Unibus Out', you can plug a Unibus cable in there to link to an > expansion box. The official way involved special dual-height cards at > each end with 3 40-way Berg-type cables linking them. So I'm trying to look into this (BC11 cables being unobtainium these days, at least at prices which are less their weight in gold). I see 'three' different kinds of 'UNIBUS to cables' cards listed: M9014 UNIBUS to 3 H854s M9015 3 H854s to UNIBUS M9031 UNIBUS to 3 3M cables for 11/74 M9042 UNIBUS to 3 H854, Dual I assume the M9014/M9015 are a pair, one used at the start of the cable, and one at the end? Does anyone know the difference between these three, and is my guess about the M9014/M9015 being a pair correct? (I did look for documentation to answer these, but couldn't find any - although maybe I didn't look in the right places.) Noel

9 years, 6 months

← Newer
1
...
7
8
9
10
11
12
13
...
29
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb June 2015