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.
North Andover, MA
This email has been checked for viruses by Avast antivirus software.
> 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:
will save at least some other people...
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.
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.
> 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
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.
> 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?)
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?)
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?
Gtalk/Jabber:aloha at blastpuppy.com
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.
> 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... ;-)
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
>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
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.
202025452377 777777777777 E 102.
and it gets:
202025452400000000000000 E 102.
The emulator should not have rounded in this case; but I cannot figure out
I've abstracted the instruction out of the emulator and embedded it in a
standalone test harness that runs the 47 tests.
Any insights, suggestions for algorithms, reading material would be greatly
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
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