test-drb March 2016

test-drb@ccmp.vtda.org

189 participants
229 discussions

by dave＠mitton.com

Guys, still trying to clean out my basement... recently I've gathered a bunch of PC cards from over the years. and some of my old text and data books. Still working on listing some more and some various kits of PC software. I'm not assuming this is worth much, just rather pass it on, than dispose. I've put a list (so far) of the stuff on this web page. I have photos of the PC cards if interested. http://dave.mitton.com/computer_clearance.html Dave Mitton, North Andover, MA --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

8 years, 1 month

PDP-11/04-34 Programmer's Console manual error

by jnc＠mercury.lcs.mit.edu

> From: J?rg Hoppe > this is something every '34 owner must go through. Urrr, hadn't thought of that! Sigh. I wonder if it'd been mentioned here before, and I'd missed it because it was before I joined? Luckily, having that cable in backwards doesn't harm anything... Well, hopefully this: http://gunkies.org/wiki/KY11-LB_Programmer's_Console will save at least some other people... Noel

8 years, 1 month

PDP-11/04-34 Programmer's Console manual error

by jnc＠mercury.lcs.mit.edu

So, something I just found out the hard way, while debugging another 'situation' with a PDP-11/04: The KY11-LB Programmer's Console maintainence manual contains a major error, in describing the configuration of the 20-conductor flat cable that connectors the front panel and the UNIBUS interface module (M7859). This is covered in Chapter 9, "Installation", which includes two figures, Figures 9-4 and 9-5. Those figures show the 20-conductor flat cable with the red edge stripe toward the outer edge of the front panel PCB (correct), and also toward the outer edge of the M7859 (WRONG). On the M7859, the red stripe edge needs to be oriented _away_ from the outer edge of the board. If it is plugged in as shown in these figures, the machine will not operate: the four 'RUN/SR DISP/BUS ERR/MAINT' lights will be on, but nothing else, and it will not respond to any keys. Fortunately, plugging the cable in reversed does not damage anything; simply reverse the cable. Noel

8 years, 1 month

Z8-02 demo PCB (was Re: Running a Z8-02 MPD on a breadboard)

by spacewar＠gmail.com

On Tue, May 12, 2015 at 1:41 AM, Eric Smith <spacewar at gmail.com> wrote: > I designed a simple QUIP adapter for use with solderless breadboards, > and wired up a Z8-02 MPD along with a 28C16 EEPROM for the program > memory, a 62256 static RAM, address latch, and decoder. I programmed a > copy of the Z8671 Basic/Debug interpreter into the EEPROM. To my > amazement, it worked the first time. > > Photos: > https://www.flickr.com/photos/22368471 at N04/sets/72157652653732622 I had a PCB made of basically the same circuit, with a TLC7705 voltage supervisor/reset circuit added, and a stuff option for an actual RS-232 port. I've added photos to the album linked above. Unlike the solderless breadboard version, it did not work the first time, and I haven't yet figured out what's wrong with it. The reset circuit seems to work correctly. I should have added a bus connector for I/O expansion. I was in a hurry and it had to be under 100mm square to get the boards made inexpensively. Rather than soldering in the exceedingly rare 3M QUIP socket, I soldered down four 16-position single in line machined-pin sockets, and plugged the QUIP socket into those.

8 years, 1 month

AT&T Uverse IPv6 vs. Mac OS X 10.(old)

by jnc＠mercury.lcs.mit.edu

> From: Jerry Weiss > Disabling IPV6 was the cure. I was _extremely_ amused to hear that. (Backstory: I'm a long-time detractor of IPv6 - I've always thought it's a rolling ball of digestive byproduct, to be blunt. In fact, if I had still been on the IESG when it came around, I'd have canned it. Unfortunately, I'd resigned a while before [for unrelated reasons], something that in hindsight I've greatly regretted, since it removed my ability to can IPv6. So to hear that IPv6 is _still_, all these years later, not that crucial to useful functionality, is very satisfactory to me - it says my assessment was right on the nose. Long may IPv6 fail to be successful! The single biggest/most expensive IT failure of all time?) Noel

8 years, 1 month

OT RE: AT&T Uverse IPv6 vs. Mac OS X 10.(old)

by jwest＠classiccmp.org

TSIA -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Robert Johnson Sent: Monday, March 28, 2016 1:36 PM To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Cc: jnc at mercury.lcs.mit.edu Subject: Re: AT&T Uverse IPv6 vs. Mac OS X 10.(old) > > On Mar 28, 2016, at 7:32 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote: > >> From: Jerry Weiss > >> Disabling IPV6 was the cure. > > I was _extremely_ amused to hear that. > > (Backstory: I'm a long-time detractor of IPv6 - I've always thought > it's a rolling ball of digestive byproduct, to be blunt. In fact, if I > had still been on the IESG when it came around, I'd have canned it. > Unfortunately, I'd resigned a while before [for unrelated reasons], > something that in hindsight I've greatly regretted, since it removed > my ability to can IPv6. So to hear that IPv6 is _still_, all these > years later, not that crucial to useful functionality, is very > satisfactory to me - it says my assessment was right on the nose. Long > may IPv6 fail to be successful! The single biggest/most expensive IT > failure of all time?) > > Noel So, I?m curious what your objections to v6 are (I know there are some very good technical objections, because v6 is unlike v4 enough to be a breaking change from a programatic point of view) - or rather, how would you solve the shortage of IP addresses? Robert Johnson -- Gtalk/Jabber:aloha at blastpuppy.com AIM:AlohaWulf Yahoo:AlohaWulf Skype:AlohaWolf Telephone:+1-562-286-4255 C*NET: 18219881 Email:aloha at blastpuppy.com Email:alohawolf at gmail.com -- "Follow the path of the unsafe, independent thinker. Expose your ideas to the danger of controversy. Speak your mind and fear less the label of "crackpot" than the stigma of conformity." - Thomas J. Watson Sr.

8 years, 1 month

Mainframe floating point math implementation.

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > the missing piece of the rounding algorithim has been identified: > Only round if the mantissa was shifted more then 71 bits. Wow. I'm really impressed that they implemented that in hardware, back then! Then again, they threw so many gates at the Multics CPU, I guess they figured a few more wouldn't matter... ;-) Noel

8 years, 1 month

Mainframe floating point math implementation.

by charles.unix.pro＠gmail.com

The Multics distribution includes ISOLTS, a surprisingly complete and pedantic processor test program. It is unhappy with our emulated floating point. This should be the floating point used by the GE 6xx series and the Honeywell DPS8 and 6000 series. There is one particular failure that I am driven to seeking help for. If the intricacies of mainframe floating point math h/w do not interest you, time to delete this message and move on. For add and subtract operations, the operand with the smaller has its mantissa shifted right and the exponent incremented adjusted until the exponents match. >From the DPS8M assembly language manual: "The mantissas are aligned by shifting the mantissa of the operand having the algebraically smaller exponent to the right the number of places equal to the absolute value of the difference in the two exponents. Bits shifted beyond the bit position equivalent to AQ71 are lost." Sadly, ISOLTS complains about our implementation. It does helpfully provide what it says are the correct answers. Examination of the answers reveals the it is not the case that the shifted bits are lost; the shift mantissas are rounded according to rules that I can't quite characterize. ISOLTS runs many operands through the UFA (Unnormalized Floating Add) instruction; the current state of my rounding algorithm passes the first 46 tests; fails on the 47th. Everytime I try a different approach, it fails on an earlier test. The best rule that I have is: if the shifted mantissa is all ones and at least one of the bits shifted out was a one, the set the mantissa to 0. Test #47 adds: 700000000000700000000000 E 31. to 202025452400000000000000 E 102. ISOLTS expects 202025452377 777777777777 E 102. and it gets: 202025452400000000000000 E 102. The emulator should not have rounded in this case; but I cannot figure out the rule. I've abstracted the instruction out of the emulator and embedded it in a standalone test harness that runs the 47 tests. https://sourceforge.net/projects/dps8m/files/drop/Charles/ufa47.c Any insights, suggestions for algorithms, reading material would be greatly appreciated. -- Charles

8 years, 1 month

R: RE: RSX-11 trouble

by supervinx＠libero.it

Thanks! I've to dig it, since my RSX experience amounts to two hours. The IND should have worked before, since there are a lot of user generated .CMD files.

8 years, 1 month

PDP-12 Restoration at the RICM

by michael.99.thompson＠gmail.com

We are now working on the RK8F controller and RK05 drive. The RK8F has special M7104 and M7105 boards so it will work in the DW8E Omnibus-Posibus chassis. The MAINDEC-08-DHRKA RK8E Diskless Control Test showed that a data-break to address 0000 worked, but did not work to address 7777. After about 4 hours of debugging we found a dirty connection on an M7102 board in the DW8E chassis. This prevented one of the CA signals from the RK8F from being driven onto the Posibus MA. The DHRKA diag now passes, so much of the RK8K and the DW8E are working. We bought a new NiCd battery pack for the RK05 and new weather strip to replace the blower to card cage, and plenum to disk pack seals. There is also a power supply problem that shows up after the RK05 had been powered on for 10 minutes that we need to fix. We have a disk pack that came with the PDP-12, but we don't know if it has LAPS-DIAL or OS/12 installed. Maybe we will solve that mystery in a few weeks. -- Michael Thompson

8 years, 1 month

← Newer
1
2
3
4
5
6
7
8
9
...
23
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 March 2016