Re: Extracting files off “unknown” 8 inch disks. Any thoughts…

[Jay Jaeger via cctalk]

> On Mar 22, 2017, at 23:08, Chuck Guzis via cctech  
> wrote:
> 
>> On 03/22/2017 08:39 PM, Terry Stewart via cctalk wrote:
>> 
>> Chuck, in the highly likely event of the formats NOT being common
>> CP/M or DOS ones (i.e. ones I could probably manage), I'll give these
>> guys your email (-:
> 
> Tez,
> 
> Here's what I would do in your situation.
> 
> If the disks are hard-sectored, forget it, unless you have the system
> that wrote them.
> 

Not necessarily.  For example, I have used a Catweasel board to recover hard 
sectored Data General floppies.  But it is certainly much harder, particularly 
if the format is not known in advance.


> If they're soft-sectored, dig through your pile of PC "tweeners" using
> Dave Dunfield's "TestFDC" and see if you can find one that does
> single-density.
> 
> Then hook your 8" drive to the PC and use his ImageDisk to grab a copy.
> 
> That way, you can tinker with the image to figure out what's going on.
> Failing that, you can pass the image to the list here and see if it
> rings any bells.
> 
> http://www.classiccmp.org/dunfield/img/index.htm
> 
> --Chuck
> 
> 

Re: LINCtape/DECtape Head Alignment

[Jay Jaeger via cctalk]

Curious:  How are you measuring the signal from the head?  Do you have
an honest to gosh differential probe, or are you using some other
technique?  (If you have a differential probe, then the TU56 manual
indicates that you should see 10mv-12mv (the addition of the two paired
heads together), so as a first guess I am guessing you are looking at
the coils one at a time.

The reason I ask is that the TU56 that I use most often has gotten a bit
cranky over the years.  Generally I can read and write, but I do
typically see some errors - unacceptably many, and it *seems* that the
longer the machine is on, it seems the more mark track errors I get when
running the ZTCC?? diagnostic (test 3).

I don't have a differential probe, and the A-B math function on my Rigol
DS2072 scope is not anywhere near fast enough (though maybe a firmware
patch which I have downloaded will help, but I doubt it will help
because their is a lot of HF noise on the signals when measuring
voltages this low).  However, if I apply a 50KHz low pass filter on the
signal on the scope, then sometimes I can see a 5mv per coil signal
using an ordinary probe.  I say sometimes because the scope seems to
have some firmware problems so it isn't consistent in its behavior.  (I
have downloaded a firmware update that *might* help).

I don't really doubt my heads at this point - certainly nothing is open
- I can measure each coil at about 1.5 ohms (3.0 ohms across both), but
it is something I would like to make sure I know how to do.

Also, have you degaussed your heads?  If so, how?  I ask because some of
my symptoms could point that way (I have yet, for example, to test with
a tape, have it get worse, then go back with the machine "cold" and see
if it gets better - and if it doesn't, that could point to demagnetized
heads.)

Thanks.

JRJ


On 12/26/2016 12:08 PM, Michael Thompson wrote:
> The RICM is working on the skew adjustment on a TU56 tape drive on a
> PDP-12. We only see a 5mV signal from the head, so when we flip the tape
> over we will only see 1mV. This is below the capabilities of my 'scope.
> 
> The DEC skew adjustment procedure talks about using a DEC amplifier to
> boost the head signal to several volts. We are planning to make an
> equivalent amplifier using a modern Op-amp. It would be really convenient
> to have one of the Amphenol 133-022-03 connectors from a G851 Relay module
> on our amplifier so it would plug directly into the head cable.
> 
> Does anyone have a DEC G851 module that we could remove the connector from?
> 

BCC:  Original poster

Re: LINCtape/DECtape Head Alignment

[Jay Jaeger via cctalk]

On 3/19/2017 1:07 PM, Michael Thompson via cctech wrote:
>>
>> Date: Sat, 18 Mar 2017 21:46:21 -0500
>> From: Jay Jaeger 
>> Subject: Re: LINCtape/DECtape Head Alignment
>>
>> Curious:  How are you measuring the signal from the head?  Do you have
>> an honest to gosh differential probe, or are you using some other
>> technique?  (If you have a differential probe, then the TU56 manual
>> indicates that you should see 10mv-12mv (the addition of the two paired
>> heads together), so as a first guess I am guessing you are looking at
>> the coils one at a time.
>>
> 
> We used the procedure in the TU56 maintenance manual, and used two G888
> modules to make the equivalent of the G500 described in the manual. The
> G888 modules really cleanup the high frequency noise mixed with the head
> signals.
> 

Actually, I finally found a way to measure the heads and do it
repeatably.  Fortunately, my scope can go down to 500uv/division
(5mv/division with the 10x probes).

First, updating to the latest software on my DS2072A helped - but just a
little.  Getting the settings just right - not all of them immediately
intuitive - helped more.

(BTW, if you do not have a DSO, they are WONDERFUL.  If you haven't seen
one of these things in action, go to the EEVBLOG on YouTube My normal
analog Tek scope now has a tear in its eye.  Poor thing - it served me
well.  I got my scope during a time when Rigol had a promotional
offering, so I got the decode features and a few other things that one
might normally pay extra for.  I got my from Saelig and they offered a
discount to match that offered by other vendors who join the EEVBlog
*forum*).

https://www.youtube.com/watch?v=_TSr9nFN1GU

Here is what I learned over the past couple of days:


1.  I set the bandwidth limit on the input to 20MHz.  So this limits the
bandwidth before it even gets to the Math processing and reduces the
sample rate.  Maybe this gives the 'scope more time to do other
processing?  Anyway, this made a VAST difference.  I can still see the
waveform without doing this, but it is attenuated and more quantized.

2.  At times I did not have the 10x multiplier on the input channels set
to match the probes, which meant my signal readouts were 10x off.  This
was another important mistake that lead to incorrect readings.  (D'oh)

3.  I then used the "Math" function on the scope and select a low
bandwidth filter, and set it to 50Khz (more or less matching the TU56
manual's 60Khz identification of the Tek module they used).  This gets
rid of almost all of the noise (I live less than 2 miles from a bunch of
TV and radio towers!)

This way, I reliably get decent signal readings off of the heads.

In fact, in this configuration, I could even set the Math to A-B and
sometimes see the wave as the manual offers intended, though it was
chock full of noise (unfortunately and understandably, the scope can't
do both low filter and A-B at the same time.)

(It might even be that I could use the scope to capture the data, and
then post process it, but what I have now is just fine.

It was helpful that I had reasonable confidence in the head to begin with.

JRJ

Re: DCC-116 E / DATA GENERAL NOVA 2/10 / Nixdorf 620 - Restoring and restarting

[Jay Jaeger via cctalk]

Typically not, since with no tape it should act like all the holes are punched, 
yes?

Sent from my iPad

> On Apr 1, 2017, at 18:04, Chuck Guzis via cctech  
> wrote:
> 
>> On 04/01/2017 01:45 PM, Al Kossow via cctalk wrote:
>> 
>> 
>>> On 4/1/17 12:33 PM, Dominique Carlier via cctalk wrote:
>>> strange machine, there is a tape reader inside the printer.
>> 
>> it is used to program vertical forms postioning. the format tape is
>> in a loop
> 
> 
> ...and whatever you do, don't lose the tape.  There will be
> "interesting" consequences the moment some program does a form feed
> (skip on channel 1)...
> 
> --Chuck

Re: Old manuals (Univac, IBM, Burroughs, Teletype)

[Jay Jaeger via cctalk]

> On Apr 5, 2017, at 02:00, Dave Babcock via cctech  
> wrote:
> 
> The simulator work could greatly benefit from the IBM 1620 & 1622 manuals and 
> system diagrams that you have.
> 

Connections to the console aside, the best materials for this would likely be 
the CE/FE instructional manuals.  Those were invaluable to me when I wrote my 
1410 cycle level simulator.  They are also a huge guide to interpreting the 
drawings, though I did not use the drawings to write my simulator.  You might 
reach out to others who actually have 1620 hardware directly.

Re: Remex Tape Reader - Pre-power up advice?

[Jay Jaeger via cctalk]

On 4/18/2017 3:17 AM, Christian Corti via cctech wrote:
> On Mon, 17 Apr 2017, Rod Smallwood wrote:
>> There are what appear to be 1976 date codes on some caps.
>>
>> If its that old then replace all and any electrolytic capacitors plus
>> any paper based caps.
>>
>> If they aint bad now they soon will be.
> 
> *shaking head*
> 
> Sorry, this is just a plain dumb answer. If they are good now, they
> probably will be good in 10 years, too. We never change any caps just
> because of their age.
> 
> I suggest: check for electrical safety, then plug it in and try it;
> after all, it's "just" a tape reader with a simple PSU, not a 50s era
> mainframe.
> It will just work, I guess. If there should be a problem with those "big
> caps", you'll see it. But it's much faster and easier to test them
> beforehand (i.e. short or no short) than to foolishly replace everything.
> 
> Christian
> 

While I also do not typically replace capacitors outright, I don't think
that the answer is "dumb".  It just comes from a different perspective -
typically from those who for one reason or another wish to maximize
reliability and don't care to deal with failures down the road, and for
whom preserving original components is not a priority.

But I also I don't think that just plugging the unit in and turning it
on (aka a "smoke test") right off the bat is necessarily prudent.  A
shorted input capacitor can easily take rectifiers with it (a capacitor
that needed reforming did that to a rectifier bridge on my PDP-12 at one
point), and a shorted output capacitor can take regulator components
with it.  Also, a shorted capacitor can generate enough steam to
explode, if it doesn't have a pressure relief plug, and that can be
messy, regardless.

So what I typically do is locate the larger capacitors in the supply,
and re-form them (I think so far I have only run into a couple that
needed replacement due to an unacceptably high ESR).  This spots shorted
units along the way, and one only need disconnect on lead to the
capacitor to accomplish the work.  Also, it allows one to bring the
capacitor up to its rated voltage, rather than just the in-circuit voltage.

JRJ

Re: Full immersion emulation

[Jay Jaeger via cctalk]

On 3/1/2017 2:29 PM, Paul Berger via cctalk wrote:

> I have been in rooms where they had a box of earplugs at the door, but
> that came later in my field service rep days we where told that the
> noise was at a "safe" level, however I do know of at least one person
> that is still in field service that now has hearing aids that are paid
> for by the company.

I suffer from tinnitus, likely due to too much time in computer rooms
with an IBM 1410, PDP-11s, Datacraft 6024, IBM 7094 II, IBM 360/65 MP,
Amdahl 470, IBM 3084 and IBM 3090 machines and peripherals in their
respective days.  And then there is the time I currently spend on my
collection.  No hearing aid yet, but I can certainly tell that my
hearing is not what it used to be, or even what it should be.

Re: Full immersion emulation

[Jay Jaeger via cctalk]

ROTFL.

On 3/3/2017 10:31 AM, Mark Linimon via cctalk wrote:
> On Thu, Mar 02, 2017 at 08:11:34AM -0800, Fred Cisin via cctalk wrote:
>> It hardly took any time at all to get those to the point where it would
>> accept, "LET THERE BE LIGHT"
> 
> "I'll ... have to think about it."
> 
> mcl
> 

Re: Rack-mounting a TU56

[Jay Jaeger via cctalk]

> 
> Speaking of which - I'll put out a call again for if anyone wants to get a 
> group purchase on the motor run caps for a TU55/56
> 

I need some.  I have been working on my system, and just discovered that
all four of my drives have leaking motor run capacitors.

I have found some online, but they are a bit too tall (probably
workable), and specified as 1/4" too large a diameter.

Four drives x 4 caps each == 16.

JRJ

Very Late RK07 battery pack location

[Jay Jaeger via cctalk]

I have a puzzlement.  I have two very late (apparently) model RK07
drives on my PDP-11/24.  As part of an overall search for corroded
battery packs, I went looking for them on the RK07.  But my drives don't
seem to match the Illustrated Parts Breakdown for either early or late
model RK07 drives.

I expected to find the batteries just forward of the logic card cage
area, but there is nothing there.  Also, BOTH of the ones in the IPB
(designated early and late) seem to have the CA transition bracket near
the very rear of the drive.  Mine is about 8 inches forward of the rear
just to the left of the center area between the power supply and logic
card cage areas.

I did see one reference online from the December 1994 DECUServe Journal
to the batteries being "in a clip holder under the center column of the
drive".  One might take that to mean in the center area between the
logic card cage and the power supply, forward of the circuit
breaker/power cord entry.

But before I tear into that, can anyone confirm that that is where they
should be located?

Thanks.

JRJ

Re: PDP-11: DR11-C to FPGA or 1284?

[Jay Jaeger via cctalk]

On 7/31/2017 12:52 PM, Fritz Mueller via cctalk wrote:

> 
>> On Jul 31, 2017, at 8:19 AM, Jay Jaeger  wrote:
>>
>> I have Ethernet shield for my Arduino Uno, and I use that and a simple
>> (in my case, perl,  program to talk to the final destination device.  I
>> have two cables, one for each direction, from the DR11-C (not using DMA)
>> to the Arduino.
> 
> Awesome -- it seemed likely somebody here would have done this sort of thing 
> already :-)
> 
> Jay, does your Arduino support TTL-level signaling, or did you have to use 
> some level-shifting chips?  How did you arrange the cabling/packaging?
> 
> I'm more familiar with FPGA platforms than Arduino, but this might give me a 
> good excuse to finally play around with Arduino a bit!
> 
>   --FritzM.
> 
> 

Others have already addressed the signal level issue.  Not a problem.
When I (recently) developed the Arduino version, I checked the current
sink/source current specs to make sure I wasn't going to blow anything up.

I have posted my code (and pinouts) on Google Drive at:

https://drive.google.com/open?id=0B2v4WRwISEQRUUxuNGhZRENvYjQ

Please read the readme files!  ALL of them (except maybe the PC Parallel
port one).

I would not mind comments/suggestions for improvement if delivered
gently, but the odds that I would actually change anything are pretty
small.  Of course, you can do what you want with your copy.  Some of
this code dates back to 1989.

Just today, while transferring an 18,000 block RT-11 logical disk (LD):)
file, I discovered that the Perl PC program that talks to the Arduino
can sometimes report the wrong checksum.  Most of the time it has been
right, but for that file it reported the wrong number, even though the
file did checksum right when I checked it when it got to the PC.  If
that one is wrong, then odds are its partner for sending files from the
PC is wrong, too.

The Arduino code and the PDP-11 code are probably the best places to
look to understand the protocol.  Basically it is a simple fully
interlocked handshake for each byte transfer.  Each block (fixed at 512
bytes) is preceded by a "flag byte".  The startup process has its own
special flag byte.

0x55  Initial Sync
0x22  Data block  (followed by 512 bytes of data)
0x00  EOF

(You can ignore the PC-ParallelPort folder unless you plan to use a PC
parallel port for transfers - it is a lot slower than using the Arduino,
and is old DeSmet C code.  But BE CAREFUL reading this code, because the
PC parallel port hardware *** INVERTS *** some of the signals.)

Re: Looking for info on The Digital Group Systems and Aeon Pulse Systems

[Jay Jaeger via cctalk]

Digital Group systems are not S100.  More to follow tomorrow.

Sent from my iPad

> On Aug 13, 2017, at 21:43, Ed via cctalk  wrote:
> 
> http://bytecollector.com/the_digital_group.htm
> 
> above is site  with great info!
> 
> thanks  ed#
> 
> 
> 
> In a message dated 8/13/2017 7:03:38 P.M. US Mountain Standard Time,  
> cctalk@classiccmp.org writes:
> 
> I  recently went to a hamfest and scored 2 complete systems  From what i  
> can
> tell its an S-100 based system.
> 
> The Digital Group with Aeon 8  inch drives
> 
> And a Pulse By Aeon with 8 inch drives.
> 
> Heres pics  of the unit
> http://imgur.com/a/G7mrn
> 
> It came with a ton of  disks,  and docs
> 
> Also trying to find out what these keyboards  are
> 
> http://imgur.com/a/y8ymG
> 
> Thanks for the help in  advance
> 

Re: In search of DEC DZ11 cabling/panel

[Jay Jaeger via cctalk]

I might be able to help, but won't be home until tomorrow.  I am sure I have 
something, but it might be Emulex, though hopefully the pinouts would match.

Sent from my iPad

> On Jul 22, 2017, at 16:29, Fritz Mueller via cctalk  
> wrote:
> 
> Hi folks,
> 
> I'm in need of cabling and a distribution panel for a DEC DZ11 serial mux 
> that I'd like to put in a PDP-11/45.  Before I embark on building something 
> up from scratch I thought I'd ping here and see if anybody had all or part of 
> this on hand and would be willing to work out a deal?  Hit me back if so!
> 
>cheers,
>  --FritzM.
> 

Re: In search of DEC DZ11 cabling/panel

[Jay Jaeger via cctalk]

Just for completeness on the thread, I have:

A BC05W-15 Cable  (I am not sure yet if this is real DEC or the two sets
of Emulex cables I have attached to a CP22 cabinet kit - would have to
check on that)

A BC06L-0J Jumper

An H317e  (I also have a separate plastic cover for an H317e)

An H7004C Filter

I also have a pair of Emulex CP22 cabinet kits, and the 19" mount that
has room for both.  I'd guess that these would be pin compatible with
their DEC counterparts, but I have not actually checked.

JRJ

On 7/23/2017 4:25 PM, Fritz Mueller via cctalk wrote:
> Update: have now tracked down an H317-E, from a list-member.  Thanks, all!
> 

Re: Oscilloscope Recommendation

[Jay Jaeger via cctalk]

> On Apr 29, 2017, at 12:53, Chuck Guzis via cctech  
> wrote:
> 
>> On 04/29/2017 10:28 AM, Michael Thompson via cctech wrote:
>> The RICM just received $1,000 to buy a new oscilloscope. I would like
>> a four channel. and color would also be nice. The bandwidth doesn't
>> need to be high because we usually work on ancient equipment.
> 
> The Rigol scopes have the features that you're looking for in your price
> range.  Dave on the YT EEVBlog has spent some time on them.
> 
> There have been some notable software bugs, but Rigol seems to be pretty
> diligent in eradicating them.
> 
> --Chuck

I have a Rigol DSO and absolutely love it.  Bought it from Saelig - they offer 
a nice discount to members of the EEVBLOG forum.   I have seen a couple of 
updates since I bought it.  Look for a sale where you can get some of the 
add-ons thrown in at no additional cost.

Re: RL02 to image file

[Jay Jaeger via cctalk]

On 6/1/2017 12:12 PM, Ethan Dicks wrote:
> On Thu, Jun 1, 2017 at 7:59 AM, Jay Jaeger via cctalk
> <cctalk@classiccmp.org> wrote:
>> I can.  I use a DR11 parallel port on an 11/24 to transfer the files.
> 
> Interesting.  I'd like to see how you tackled that (I can imagine
> wanting a couple of layers of integrity-checking, for one).
> 

It uses a simple 8 but parallel bus-like fully interlocked protocol,
byte by byte.  The send side raises a data available bit, the receiver
grabs it, then raises an acknowledge.  The sender then drops the
available, and then waits until the receiver drops the acknowledge.

The cable is less than 6 feet, and isn't even using properly twisted
pairs.

Transfers are 512 byte blocks (one can always pad the last block with
something), and each block starts with a "sync" byte, which prevents
losing (or adding) an entire byte - the protocol will lock up - there is
no recovery.  And I have never needed any.  I have yet to see a transfer
fail once it gets started.  Sometimes one does need to restart one end
or the other to get it going - I never bothered to look real hard at why
that happens.

One can check the integrity of the entire image however one chooses.  I
use a simple 16 bit CRC (sum -r), and wrote a MACRO program under RT-11
that will do the same for a file or a device.  Here again, I have never
had a bad checksum.  It just works.

Note that while transferring FROM a device that supports bad blocks
(e.g., RL01) is the same as any other device (with or without the bad
block table), one needs to be careful about transferring TO such a
device to make sure that one does not overwrite the factory bad block table.

>> Used to do it to a PC with an old serial port, but now I can do it with an 
>> Arduino and connect it to a PC via Ethernet
> 

Well the above was an error on my part.  I should have written "old
*parallel* port.

> Neat.  Any write-up of this or shared code to keep from re-inventing the 
> wheel?

I could do something about writing it up, I suppose, but it really is
pretty straight-forward.

A couple of PDP-11 MACRO programs, running under RT-11.

(The PC parallel port code was done in DeSmet C, originally on a
Netronics 8088 based true IBM PC "clone", now running under Windows 95,
and does not work with modern parallel ports, rendering it kind of useless.)

A couple of Arduino programs (I hate the term "sketches") that talk the
PDP-11.

A couple of perl programs that talk to the Arduino (which uses an
Ethernet shield).

And NONE of the code is up to snuff, by my standards.  In just about
every case, I have had a short term goal to accomplish, and stopped once
that was working well enough.  Things like:

- The PDP-11 halts before RT-11 can send out a full error message (it
really should loop on an error).
- Errors don't provide any data about what the program didn't like
- No time spent cleaning up code (in fact, this weekend I spotted a
coding error on the Arduino program that reads from the PDP-11, that
fortunately doesn't seem to have had any really bad effects).
- etc.

Jay

> 
> I was going to do a bunch of imaging with a basic machine and
> vtserver, but this sounds much, much faster.  I have piles of 8"
> floppies, RK05 packs and RL02 packs to copy off.  Not doing it at
> 1KB/sec is always an option.

I played with VTServer as well.  This is indeed much faster than a
serial port - and the Arduino version is a bit faster than the old PC
version. I have used it for all of the media you mention, and for RX02
floppies and RK07 packs as well, though these days I normally transfer
floppy images to the PC using a Catweasel bit cell board.

> 
> -ethan
> 

Re: RC11 manuals / schematics online?

[Jay Jaeger via cctalk]

On 6/11/2017 1:16 PM, Noel Chiappa via cctalk wrote:
> > From: Jay Jaeger
> 
> > Fortunately, I do have some, and will scan them in
> 
> Yesss! Thank you!
> 
> > I will do the usual 400DPI / tiffs 
> 
> I've found that for engineering drawings, 600 dpi is better; the prints often
> contain very small writing (pin numbers, etc) which are sometimes hard to read
> at 400.
> 
> (Especially since you may have the only set left in the world, it's very
> important to get the best possible image of them.)
> 
>   Noel
> 

Yes, I am doing the drawings at 600DPI, including the drawings that
reside inside a couple of the maintenance manuals (but 400DPI for the
text, etc.)

Re: RC11 manuals / schematics online?

[Jay Jaeger via cctalk]

On 6/8/2017 2:22 AM, Mattis Lind via cctech wrote:
> I happened to find a RS64 / RC11 combo (missing the PSU though). The
> previous owner was an ex DEC field engineer that himself got it in the
> beginning of the seventies. It is used but has the shipping lock on the
> motor axis.
> 
> Maybe the chances to get this working isn't that high especially since the
> donator told me about all sorts of problems that happened to them. As far
> as he remembered there were quite some problems with these RS64 and the
> PSUs.
> 
> http://i.imgur.com/jsgpF6v.jpg
> 
> Anyway. Does someone has an online scan for the RC11 controller manual
> and/or schematics?
> 
> /Mattis
> 

I have scanned my RC11 and RS64 manuals.  The text is generally 400dpi,
the drawings 600dpi (including drawings inside the maintenance manuals).

Like most stuff that I scan that is likely to be of interest to
bitsavers, I store it in the following directory tree which mimics what
they use.  My files can be found at:

https://drive.google.com/open?id=0B2v4WRwISEQRWWFFdVpCZWFTZEU

These particular scans are now in the (new) directories:

.../pdf/dec/disc   (For the RS64)
.../pdf/dec/unibus (For the RC11)

Note the drawing updates for the RS64 to take it from revision H to
revision K (and perhaps L - but that part was written over in ink on the
copy).

Also, note that manual

DEC-00-HRS64-E-D_RS64_disk_file_maintenance_manual

Has a page that was placed in the document by Professor Marleau of UW
(Wisconsin) Electrical Engineering.  It appears to be in regard to a
manual repair undertaken on the RS64 (which is the very same drive that
is in my collection).

Also perhaps noteworthy that this RS64's "twin" which resided in the UW
Computer Systems Lab was at one point "resurrected" by flipping the disk
upside down.

JRJ

Re: DEC MINC in center Germany -- Mincbasic and RT11 disk

[Jay Jaeger via cctalk]

Images for an RX02 MINC are available on bitsavers, at
http://bitsavers.informatik.uni-stuttgart.de/bits/DEC/pdp11/floppyimages/minc/rx02.
 Based on the "readme", it looks like I provided the RX02 images.

There are some additional MINC related RX01 images in the .../rx01
folder, as well.

Note that these images include a "dummy" track 0 so that they will work
under SimH.  You should skip track 0 when you load them onto a real
floppy.  As far as I know, DEC operating systems did not use track 0.
(Block 0 is on track 1).

I booted my copy of BA-H106D-BC (which is for an 11/03 based MINC) under
SimH, and it said:

sim> boot ry0

MINC BASIC/03 V2.0 System Distribution Disk

This disk can only be duplicated, not used.
Do you wish to duplicate this disk (Y or N) ?


JRJ


On 6/14/2017 2:40 AM, Paul Birkel via cctalk wrote:
> +1, please!
> 
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of jim stephens 
> via cctalk
> Sent: Wednesday, June 14, 2017 3:19 AM
> To: Jörg Hoppe via cctalk
> Subject: Re: DEC MINC in center Germany
> 
> 
> 
> On 6/10/2017 1:29 AM, Jörg Hoppe via cctalk wrote:
>> I like to point you to this DEC MINC-11:
>>
>> http://www.ebay.de/itm/112435553232
>>
>> Its a non-profit offer, we just need the space.
>>
>> best,
>> Joerg
> 
> Is it possible to get a copy of the Mincbasic and RT11 disk? willing to 
> pay to get it for our Mincs.
> 
> thanks
> Jim
> 
> 

Re: RC11 manuals / schematics online?

[Jay Jaeger via cctalk]

On 6/10/2017 10:02 AM, Mattis Lind via cctalk wrote:
> 2017-06-08 18:38 GMT+02:00 Paul Koning :
> 
> 
> Well. Nobody has posted any thing about RC11 schematics, unfortunately.
> Maybe someone has a paper copy that could be scanned? Or that I can borrow
> to scan?
> 
> With the RS64 and the RC11 it would be possible to run DOS/BATCH 11. Could
> be interesting to test it on the real hardware.
> 
> Are there any other RS64/RC11 owners out there that has them running? Jay
> Jaeger lists a RC11/RC64 as part of a PDP-11/20 system on his web site.
> 

Indeed, I do have such a beast.  Last I tried them, a few months back,
they were still running (the 11/20 and the RS64/RC11).  I *do* have
drawings and they look to be good contrast.  I will scan them in over
the next day or so.


JRJ

Re: RC11 manuals / schematics online?

[Jay Jaeger via cctalk]

On 6/10/2017 3:29 PM, Al Kossow via cctalk wrote:
> 
> 
> On 6/10/17 8:02 AM, Mattis Lind via cctalk wrote:
> 
>> Well. Nobody has posted any thing about RC11 schematics, unfortunately.
> 
> I checked my usual places and couldn't find it.

Fortunately, I do have some, and will scan them in, and send a link.
I will do the usual 400DPI / tiffs in a zip / PDF.

> 
> 
>> With the RS64 and the RC11 it would be possible to run DOS/BATCH 11.
> 
> DOS-11 runs on dectape, rf11, and rk11
> 

And, indeed, an RC11/RS64.  That is what is currently loaded on my disk,
hearkening back to when I first used the particular machine that is in
my collection.

Re: HP 2108A key

[Jay Jaeger via cctalk]

Well, I don't think you checked with *this* Jay.  ;)

Would the key from an HP 2112B likely work?  It looks very much like the
2108A, just a tad larger (more cards).I have an HP 2112B, and it has
its key.

See a photo at :

http://webpages.charter.net/thecomputercollection/hp/hp2112b.htm

The key is 1 1/2" long, and has the number 4T1427 stamped on it.

JRJ


On 9/19/2017 6:38 PM, Mike Loewen via cctalk wrote:
> 
>    Does anyone have a key for a HP 2108A?  This is one of the original
> 21MX M-series machines.  The key is NOT the same as for the E and
> F-series machines.
> 
>    I already checked with Jay.
> 
> 
> Mike Loewen    mloe...@cpumagic.scol.pa.us
> Old Technology    http://q7.neurotica.com/Oldtech/
> 

Re: HP 7970B Capstan?

[Jay Jaeger via cctalk]

On 9/7/2017 9:35 PM, Chuck Guzis via cctalk wrote:
> On 09/07/2017 07:18 PM, Jon Elson wrote:
> 
>> Ah, well, I can see why a 7 track tape won't read well on a 9-track drive!
> 
> I was a bit puzzled at why a tapemark would read as 135 (hex).  Sigh--at
> least the parity is correct. 
> 
> --Chuck
> 
> 

On an IBM 1410 (at least - but I suspect this was likely widely true),
tape marks were *always* EVEN parity, 0x0F (Bits 8421), even on an odd
parity tape.

Learned about this one day when all of a sudden all of our FORTRAN
compiles caused the machine to error stop, but the machine seemed OK
otherwise.  WTH??  So we called IBM, explained what was going on.  The
CE calmly opened the console panel, and turned on the Asterisk Insert
switch.  He explained about the tape mark, and the fact that the FORTRAN
compiler happened to write its intermediate files in odd parity.

With that switch off, the even parity tape mark read under odd parity
was placed into core that way - with even parity, which was an invalid
core character, which stopped the machine.  With that switch on, the
tape mark came into storage as an asterisk, and the machine was happy.
(In either case, the end-of-file latch was set, of course.  See IBM 1410
Principles of Operation, "Read or Write Tape with Word Marks" - in the
-3 version, it is pages 87 and 88.)

JRJ

Re: IBM 3330 Drive

[Jay Jaeger via cctalk]

The SHARE1 is on the plastic insert label designed for the purpose.  Usually it 
would be the IBM OS Volume Serial number.  The pack in the photo may have 
contained stuff that originated with the IBM SHARE user group, or perhaps the 
pack was used on a drive shared between two systems.  The painted on number is 
unusual, and may be a Julian date, from 2005, perhaps from a repair, though 
that would be pretty late for this kind of removable disk pack.

Packs like this were exposed every time the pack was mounted or dismounted from 
the drive, when the cover was pulled off with the drive door yet to be closed.  
Many such drives ran a set of brushes  over the pack surface as the drive spun 
up, before loading the heads.

Sent from my iPad



Sent from my iPad
> On Sep 1, 2017, at 02:25, Paul Birkel via cctech  
> wrote:
> 
> I'm afraid that I can't help.  But I notice that in the upper-band of the 
> glare there appears to be a lot of speckling of the oxide surface.  Is this 
> to be expected in a heavily-used disc-pack, or does it indicate surface 
> damage -- and if so then what are the likely causes?
> 
> Also, was it usual to place markings/labels on the lower-ring like this -- 
> both what appears to be one that is painted-on "NEWUC:2005.47" as well as the 
> (plastic covered?) insert "SHARE1"?
> 
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of AJ Palmgren 
> via cctalk
> Sent: Friday, September 01, 2017 3:08 AM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: IBM 3330 Drive
> 
> For reference, here is a picture of the disk pack that I am wanting to
> read.
> 
> http://bit.ly/2etUg30
> 
> I know, I got a bit nervous too when I saw the guy just holding it out
> exposed like that.  Let's hope he put it back in the canister very
> carefully and quickly.
> 
> Can anybody guess the correct model of disk pack from this single picture
> and angle?  (Sorry, it's all I have to go on right now).
> 
> Thanks!
> -AJ
> 
> 
> On Mon, Aug 28, 2017 at 11:16 AM, Tom Gardner via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> FWIW Paul Alan's Living Computer Museum has (or had) working PDP10's using
>> DEC’s RP06's > id=230824_doc=standard.php=43>  which are very similar to a
>> 3330-11 (they are Memorex 677's with a bolt on DEC controller).  They will
>> not mount a 3330 disk pack (3336) but they should mount a 3336-11 disk pack
>> and probably spin it up but DEC’s fixed sector size will be an issue.  I
>> seem to recall u could format IBM 3336-11 packs into the DEC format so u
>> might actually be able to scan a full track without reformatting
>> 
>> 
>> 
>> I know of no operational 3330 or PCM equivalents (e.g. Memorex 3670,
>> ISS/Itel 7330, etc); the Computer History Museum purports to have one,
>> Catalog Number L2006.1.5 > org/collections/catalog/L2006.1.5> , but it might be a -11.  It probably
>> would power up and u probably could get it to seek and read (u would need a
>> simple controller) but getting access from the museum would be a challenge.
>> 
>> 
>> 
>> Good luck.
>> 
>> 
>> 
>> Regards
>> 
>> 
>> 
>> Tom
>> 
>> 
>> 
>> -Original Message-
>> From: AJ Palmgren [mailto:microtechd...@gmail.com]
>> Sent: Sunday, August 27, 2017 9:42 PM
>> To: General Discussion: On-Topic and Off-Topic Posts
>> Subject: IBM 3330 Drive
>> 
>> 
>> 
>> Does anyone here have good technical experience with, or even better
>> ACCESS to, an IBM 3330 compatible hard drive unit?  (working or not).
>> 
>> 
>> 
>> I'm getting more daring with my projects to attempt to read ancient
>> magnetic flux transitions off of things, and I might have an opportunity to
>> read a disk pack for one of these beauties.
>> 
>> 
>> 
>> I'm certain there are MANY obstacles to overcome with what I'm suggesting,
>> and depending on what might be available, I'll tackle those one at a time
>> as I cross those bridges.  But for now, I'll just ask about the hardware.
>> 
>> 
>> 
>> --
>> 
>> 
>> 
>> Thanks,
>> 
>> AJ
>> 
>>  http://QICreader.com
>> 
>>  http://Point4iris.com
>> 
>>  http://MightyFrame.com
> 
> 
> -- 
> 
> Thanks,
> AJ Palmgren
> http://fb.me/SelmaTrainWreck
> https://www.facebook.com/profile.php?id=100010931314283
> https://www.linkedin.com/in/aj-palmgren-4a085516/
> 

Re: Cloning A Hard Disk Over The Network Using Ultrix

[Jay Jaeger via cctalk]

On 10/21/2017 5:40 AM, Rob Jarratt via cctech wrote:
> I have a couple of hard disks I want to make dd copies of. I have Ultrix
> running on my DECstation 5000/240 with the disk I want to clone attached to
> it. The trouble is that I don't have enough disk space on the machine to
> clone the disk and then grab the image using FTP. I have been trying to find
> a way to pipe the dd output over the network to a SIMH Ultrix machine that
> has plenty of disk space. I tried piping dd into rcp, but rcp doesn't seem
> to take input from standard input. I have looked at cpio, but that too
> appears not to accept input from standard input.
> 
>  
> 
> Unix is not my strong point. Are there any other ways I could pipe the dd
> output across the network to a machine that has enough disk space?
> 
>  
> 
> Thanks
> 
>  
> 
> Rob
> 
> 

One way would be to attach the drive to an x86 machine that supports the
disk drives, and use clonezilla.

Another way, which I have used, is to use perl or Python to do the job.
They are relatively small, so I just included mine here.

I had trouble with the perl version under Linux at some point, so now on
the Linux side, I use a Python version.  NOTE:  I am not very fluent in
Python.  Also, I don't use the Python server version.


#!/usr/bin/perl
#
#   Simple program for piping output (such as tar) from one system to 
another.
#   Contains client and server in the same script.
#
#   Usage: tcppipe [ -c server [-i file] ] | [ -s [-o file] ] [-p port]
#
#   The client reads standard input by default and sends it to "server" on
"port".
#   The server writes standard output by default.
#
#   Port defaults to 1025
#
#   JRJ  12/95
#

use Getopt::Std;
use Socket;

$debug=1;

$PROGRAM='tcppipe';
$VERSION='V1.0';
$PORT = 4097;

$MTU=65536;
$AF_INET=2;
$SOCK_STREAM=1;
$PF_INET=2;

$sockaddr='S n a4 x8';

#
#   Get and validate options.
#

getopts('c:si:o:p:') || usage();

if(($opt_c && $opt_s) || (!$opt_c && !$opt_s) ||
   ($opt_c && $opt_o) || ($opt_s && $opt_i)) {
usage();
}

if(!$opt_p) {
$opt_p = $PORT;
}

#
#   Call the client or server piece, as appropriate.
#

if($opt_c) {
return(pipe_client($opt_c,$opt_p,$opt_i));
}
else {
return(pipe_server($opt_p,$opt_o));
}

#
#   Client piece
#

sub pipe_client {
local($server,$client_port,$infile) = @_;

if($infile && ! -f $infile) {
die "$0: $infile is not a valid file.\n";
}

#
#   Open the file.  In binary, if you please...
#

if($infile) {
open(INFILE,$infile) || die "$0: Can't open file $infile: $!";
$fd = INFILE;
}
else {
$fd = STDIN;
}
binmode $fd;

if($debug) {
print "Server: $server \n";
}

#
#   Do some work to prepare the socket data structures
#
($pname, $paliases, $proto) = getprotobyname('tcp');
($hname, $haliases, $htype, $hlen, $hip) = gethostbyname($server);
if(!defined($hip)) {
die "$0: Unknown host: $server : $! ";
}
if($debug) {
@nip = unpack('C4',$hip);
print "Host address for $server: @nip \n";
}
$netaddr = pack($sockaddr, $AF_INET, $client_port, $hip);
socket(SERVER,$PF_INET,$SOCK_STREAM,$proto) ||
die "Can't create socket: $!";

#
#   Open the connection to the server.
#
connect(SERVER,$netaddr) || die "Can't connect to server: $!";
select(SERVER); $|=1; select(stdout);
if($debug) {
print "Connected to $server\n";
}

#
#   Server indicates it's name and version
#
$_=;
if($debug) {
print "Server: $_";
}
/^220 $PROGRAM $VERSION\n$/ ||
die "$0: Unexpected server response: $_";

#
#   Send the file.
#
while(read($fd,$buf,$MTU)) {
if($debug) {
print "Read in " . length($buf) . " bytes.\n";
}
print SERVER $buf ||
die "Can't send data to server: $!";
if($debug) {
print "Sent...\n";
}
}

#
#   All done
#
close(SERVER);
close($fd);
print "Transfer completed.\n";
exit 0;
}

#
#   Server piece
#
sub pipe_server {
local($server_port,$outfile) = @_;

#
#   Open the file.  In binary, if you please...
#

if($outfile) {
open(OUTFILE,">$outfile") || die "$0: Can't open file $infile: 
$!";
$fd = OUTFILE;
}
else {
$fd = STDOUT;
}
binmode $fd;

#
#   Do some work to prepare the 

Re: Which Dec Emulation is the MOST useful and Versatile?

[Jay Jaeger via cctalk]

On 10/28/2017 9:09 PM, Eric Smith wrote:
> IBM invented computer emulation and introduced it with System/360 in
> 1964. They defined it as using special-purpose hardware and/or microcode
> on a computer to simulate a different computer.
> 
> Anything you run on your x86 (or ARM, MIPS, SPARC, Alpha, etc) does not
> meet that definition, and is a simulator, since those processors have
> only general-purpose hardware and microcode.
> 
> Lots of people have other definitions of "emulator" which they've just
> pulled out of their a**, but since the System/360 architects invented
> it, I see no good reason to prefer anyone else's definition.
> 

Well, I can think of a few.   From spending some time today with the IBM
360 catalog of programs for Model 25 and above (GC20-1619-8), IBM was
not entirely consistent with their terminology.

First of all, a lot of the products/applications that they called
emulators were in fact a *combination* of software with some microcode
hardware assist.  But they chose to call those emulators as well.  In
some of those cases, the emulated application could run side-by-side
with other S/360 programs, and in some cases not.

The ones I have spend the most time investigating over the years are
360C-EU-736 and 360-EU-738 - the 1410/7010 emulators.  I actually
tracked down the source code for one of those at one point (though I
don't remember which of the two, and where I stuck it at present).   I
think it was on one of the 360 DOS distributions available for use under
Hercules.  What I found was that it was almost all software, but with
hardware assist for the move and compare instructions.

>From the description in the catalog:

"DESCRIPTION - The 1710[sic]/7010 Emulator program is a stand-alone
program which, with the 1410/7010 Compatibility Feature (No. 4478) [ed.
- the microcode assist] executes 1410/7010 programs on a System/360
Model 50.  The Emulator program is an interpreter simulator that uses
both standard System/360 instructions ans special instructions provided
by the Compatibility feature..."

Secondly, your preferred use of the terms emulator and simulator seems
to go rather against the grain of how those terms are commonly applied
in English in general.  In ordinary English, the term emulation is
typically applied to observed *behavior*, whereas simulation is
typically applied to a more fine-grained reproduction of how that
behavior comes to be.  That is what led me down the exact opposite path
that you have gone down.  It was absolutely not, as you say, pulled out
of anyone's a**.  I and many others came to whatever definitions we use
with a fair amount of thought.

Finally, this was IBM's use of these terms of art from a long long time
ago, and to borrow from your words, I "see no good reason" to be
particularly bound by them.

The reality is that without some kind of body which would provide
specific definitions, such as those in the legal and medical
professions, this discussion is endless and the waters sufficiently
muddy as to be opaque.

JRJ

Re: Which Dec Emulation is the MOST useful and Versatile?

[Jay Jaeger via cctalk]

On 10/27/2017 1:46 PM, ben via cctech wrote:
> On 10/27/2017 9:27 AM, Jay Jaeger via cctech wrote:
> 
> 
> With some FPGA venders you could get a TTL library components,
> so you could input older designs. You may have to dig around for them
> because that is not a NEW selling feature any more. Also logic
> cells don't have asynchronous  set and clear anymore.
> 
> Ben.
> 

I suppose, though writing a little HDL to provide the function of a TTL
gate isn't very hard.  As it turns out, the design I replicated from my
college days was actually DTL, rather than TTL.  The lab consisted of 4
19" racks with interconnecting, differentially driven cables.  Each rack
had a card cage, and interconnections were done using re-purposed IBM
unit-record plugboards.  The current project, the IBM 1410, was
originally designed using IBM SMS - discrete transistors.

Re: Old core memory system.

[Jay Jaeger via cctalk]

On 5/6/2018 1:19 PM, Paul Koning via cctalk wrote:
> 
> 
>> On May 5, 2018, at 2:32 PM, Chuck Guzis via cctalk  
>> wrote:
>>
>> On 05/05/2018 10:23 AM, Pete Lancashire via cctalk wrote:
>>> Core temp was a big issue even in commercial environments. You didn't see
>>> it temp but you would see core [driver] current.
>>
>> The early IBM 7000 series (7070, 7080, 7090) kept core in a
>> temperature-regulated oil bath.  Later versions used pre-heated air
>> (e.g. 7094 core).
>>
>> On the CDC 7600, hitting the same area of care repeatedly could cause it
>> to overheat and throw parity errors.   Circuitry to detect this would
>> slow-down repeated accesses.
>>
>> That was for CM.  I seem to recall someone telling me that there was no
>> such provision in PP core and a "jump to self" was sufficient to throw
>> an error--but that may be a shaggy-dog story.
> 
> The IBM 1620 had a core heater; I remember having to wait for core to warm up 
> after turning the machine on before it would start.
> 
> One of the old PDP-11 diagnostics is the "core heating test".  The 
> description said it would hammer a region of memory (physical area) to get it 
> to warm up, to see if there was enough margin for memory to remain reliable.
> 
> On CDC memory: The 6000 series PPs always access memory every cycle.  
> Whenever it doesn'thave anything better to do, the control logic uses the P 
> register (program counter) for address.  So there is no way in a PP to make 
> memory work any harder; it's always a cycle every microsecond (memory running 
> flat out) no matter what.  I'm not positive the 7000 series works the same, 
> but it would seem plausible that it does.
> 
> CM, on the other hand, is referenced only when requested.  So CM is normally 
> working less than PP memory.
> 
> Parity?  I know the 170 series had parity, didn't think the 7600 did.  The 
> 6000 series does not (except for ECS).  "Parity is for farmers" -- Seymour 
> Cray.
> 
>   paul
> 
> 

You can add the IBM 1410 to that list of machines with core heaters as
well - I checked the drawings.  100 watt heater, nominal 100 degrees F
with 86F under temp and 120F over temp.  I think the machine I worked
with back in the day even had a thermometer placed vertically in the stack.

I also worked one evening with some friends trying to fix a 7090 with
oil core (which I know was heated), and we set up an IBM 7094-II
(originally from White Sands Missle Range - WSMR) with air core (which I
believe was heated) in the basement of the U. Wisconsin computer science
building in 1974.  We also had an IBM 1410 down there (donated from
Oscar Mayer) whose core developed failures after some time in storage -
it was pretty cold, so we guessed that it was from the wires contracting
- not long enough for the enamel insulation to have degraded.

I would expect the 1401 would also be on the list.

JRJ

Re: Original CAD code in the wild?

[Jay Jaeger via cctalk]

On 5/20/2018 9:31 PM, Randy Dawson via cctalk wrote:
> For a while I have collected bits of legacy CAD, most recently Martin 
> Hepperle sent me what I believe is the last version of Hank Christianson's 
> MOVIE.BYU, a FORTRAN based 3D modeling and animation system.
> 
> I also have experimented with the original Berkley SPICE, also written in 
> FORTRAN.
> 
> 
> This weekend, I am reading "the Engineering Design Revolution", a 650 page 
> history of the CAD industry by David Weisberg, who was there and worked for 
> many of the companies in the beginning of the industry, I highly recommend 
> this for anyone interested in CAD:
> 
> 
> www.cadhistory.net
> 
> The Engineering Design Revolution
> www.cadhistory.net
> The Engineering Design Revolution. The People, Companies and Computer Systems 
> That Changed Forever the Practice of Engineering. By. David E. Weisberg
> 
> 
> 
> My question is, did any of the source code for these systems, Applicon, 
> Auto-Trol, Calma, ComputerVision, thousands of lines of primarily FORTRAN 
> ever make it out, where we could read and study this original body of 
> mathematical geometry done on computers?
> 
> 
> I know we are primarily a hardware group here, but where is the interest in 
> the software discussed?
> 
> 
> Randy
> 
> 
> 
> 

You can add Intergraph to that list, as well (their IGDS CAD software is
 survived bw www.bentley.com - a company that produced a PC version of
Intergraph's IGDS, and which almost got sued out of existence, forced to
merge, and then finally separated and survived).  [The Wiki on
MicroStation indicates that MicroStation was initially sold by
Intergraph.  That is not correct: it was initially a completely separate
company, and sold the software directly].  Intergraph itself is nothing
but a shell.

I still have an Intergraph IP2000 workstation (with software loaded),
install media (but not license keys to load it) and Intergraph disk
controllers, high speed concentrators (pre-Ethernet) and ethernet
controllers.

No source code, though.

JRJ

Re: Original CAD code in the wild?

[Jay Jaeger via cctalk]

On 5/22/2018 5:18 PM, John Foust via cctalk wrote:
> At 09:31 AM 5/22/2018, Jay Jaeger via cctalk wrote:
>> I still have an Intergraph IP2000 workstation (with software loaded),
>> install media (but not license keys to load it) and Intergraph disk
>> controllers, high speed concentrators (pre-Ethernet) and ethernet
>> controllers.
> 
> Did you get that from Nicolet or ETC?  I think I was once offered
> a workstation like that but I forget which Madison friend offered it.
> 
> - John
> 
> 

Neither.  Wisconsin DOT, Superior office (if I recall correctly), via
State of Wisconsin surplus.  Two huge screens along with, but I only
have one hooked up.  Haven't run it in years, though.

Re: OT- Thunderbird ugliness, Was: Eudora email client source code released

[Jay Jaeger via cctalk]

On 5/23/2018 9:28 AM, JP Hindin via cctalk wrote:

> 
> 
> On Tue, 22 May 2018, Jon Elson via cctalk wrote:
>> so I use Thunderbird on a Linux platform.  It is awfully slow.
>> Sometimes it takes 5 minutes to download 3 messages when I start it up.
>>
>> At home I use Thunderbird with standard Linux smtp and pop servers and
>> it works fine.
> 
> Apologies to hijack this one (I can't tell you how impressed I am with
> both the CHM's efforts and Qualcomm's release, I find these things
> really exciting for our hobby) - but I've been having real troubles with
> TBird in the last few years and my obstinacy has been holding me back.
> 
> I run Thunderbird on a 2016 MacBoook Pro (Sierra 10.12.6, 2.6GHz i7,
> 16GB RAM, internal SSD) where I'm pulling via IMAP from Google (their
> professional company service thingy), but maintain a local 24GB cache of
> eMail.
> 
> It's slower than molasses in january. Moving eMail around between
> 'folders' often has it sit and spin the beachball for 2-3 seconds -
> dozens of times a day. And I just can't work out why - I mean, yes, it's
> a lot of ruddy eMail, but it's a monster of a laptop and it should be
> pulling/moving on the SSD when it's getting stuck before it's even tried
> to send the move message to google.
> 

I use Thunderbird, and for the most part it has worked fine.  But I use
it in a somewhat unusual way.  My gmail address forwards to my normal
ISP address.  I retrieve mail from that using IMAP but I do *not* leave
it on the server.  Instead, I process the resulting inbox with filters,
and distribute the mail to a local folders inbox (named so it floats to
the top of the list) and other places (like Classic, for example, in
categories depending upon subject).

Retrieval is usually fast.  However, until I went to the method I use
now, the IMAP folder and message management made it painfully slow.

My mail profile folder is 10GB, roughly, consisting of 22036 files and
8198 directories.  I use the "Quick Folder Move" add on to make managing
the email in the inbox that is worthy of filing away relatively painless.

JRJ




> I _detest_ the gmail interface, I'd really prefer to continue using a
> client like this - but TBird just isn't getting any better.
> 
> What am I missing here? Are there better options? Is Thunderbird just
> not designed for large mail sets for people who actually work for a living?
> 
> Responses should probably be sent to me directly. And my thanks in
> advance for your opinions, my curmudgeonly behaviour is really eating up
> my time and I'm hoping there's a reasonable fix beyond "Suck it up and
> use gmail".
> 
> Cheers!
> 
>  - JP
> 

Re: Restoring a PC Server 500 P/390

[Jay Jaeger via cctalk]

On 5/26/2018 3:15 PM, Dave Wade via cctech wrote:
> Folks,
> 
>  
> 
> Well in case any one has the slightest bit of interest, I have now plugged
> the RAID card back in and after replacing on of the drive carriers I can get
> five of the six drives to spin up. Its now copying stuff to my Buffalo NAS
> but as its 10Mbit LAN its not terribly fast. I think the NAS isn't very fast
> either. It looks like zipping up the files and FTPing the ZIP files might be
> the quickest way to go.
> 
>  
> 
> Dave
> 
>  
> 
> From: Dave Wade  
> Sent: 18 May 2018 22:31
> To: 'Benjamin Huntsman' ; 'General
> Discussion: On-Topic and Off-Topic Posts' 
> Subject: RE: Restoring a PC Server 500 P/390
> 
>  
> 
> I thought I had captioned that picture. It's the original RAID controller
> which I am not using. If I plug it in it starts the disks in the RAID array
> which takes ages, and steals the hard disk BIOS vector which I need for the
> SCSI card that's running the system.
> 
> I didn't want to remove it fully as I need to label the cables feeding it.
> One feeds the top drive bays, and the other the bottom so if I ever need to
> put it back it I need to know which is which. 
> 
> If I get some free time I will have a go at starting the disks in it and
> repairing the RAID array, and perhaps copy the disks that are installed.
> 
>  
> 
> Dave
> 
>  
> 
>  
> 
> From: Benjamin Huntsman   > 
> Sent: 18 May 2018 21:49
> To: Dave Wade mailto:dave.g4...@gmail.com> >; General
> Discussion: On-Topic and Off-Topic Posts   >
> Subject: Re: Restoring a PC Server 500 P/390
> 
>  
> 
> I gotta ask, what's the deal with the dangling card?  That cracked me up!
> 
>  
> 
> Thanks for posting some pics!
> 
>  
> 
>   _  
> 
> From: cctalk   > on behalf of Dave Wade via cctalk
> mailto:cctalk@classiccmp.org> >
> Sent: Friday, May 18, 2018 1:46 PM
> To: 'Guy Sotomayor Jr'; 'General Discussion: On-Topic and Off-Topic Posts'
> Subject: RE: Restoring a PC Server 500 P/390 
> 
>  
> 
> 
> 
>> -Original Message-
>> From: Guy Sotomayor Jr mailto:g...@shiresoft.com> >
>> Sent: 15 May 2018 21:39
>> To: Dave Wade mailto:dave.g4...@gmail.com> >;
> General Discussion: On-Topic
>> and Off-Topic Posts mailto:cctalk@classiccmp.org>
>>
>> Subject: Re: Restoring a PC Server 500 P/390
>>
>>
>>
>>> On May 15, 2018, at 1:29 PM, Dave Wade via cctalk   >
>> wrote:
>>>
>>>
>>> That's, in effect, what I did. Whilst there were Microchannel IDE
> Controllers
>> I have never seen one. There are no IDE interfaces on the "Planar" so
> every
>> thing must be on the MCA bus.
>>> So I bought a BusLogic BT646 SCSI card on E-Bay. I also bought an
> Adaptec
>> card as a spare.  I think I struck lucky with the BT646. It is a simple
> SCSI/2 card,
>> no raid but it does have a BIOS with support for two bootable drives and a
>>> 4GB drive option.
>>> OS/2 has drivers for it so it works out of the box. The OS/2 boot disks
> find
>> the drive and install the proper drivers.
>>> To compensate for the slower "narrow" drives I bought a SCSI2SD card
> that
>> puts an SD card on the bus. OS/2 just sees it as a up two four drives
>> depending on how I configure it. At present I have two 4gb drives. The
> card
>> in it is 32gb so I can add 2 x 12gb drives or 1 x 24gb or some other mix.
> The CD
>> ROM sites on the same bus. I haven't tried the tape drive yet..
>>>
>>
> 
> 
> Well I found an XGA2 card in the pile of bits so now I have 1024x768 display
> resolution. I have swapped the CDROM for a SCSI DVD drive. 
> 
> I managed to boot MTS and there are a few pics here:-
> 
> https://flic.kr/s/aHsmc1pkB1 
> 
> 
>   
> 
>   P390
> 
> flic.kr
> 
> Explore this photo album by Dave G4UGM on Flickr!
> 
> 
> 
> 
> next job is to tidy up and re-assemble the case..
> 
> Dave
> 
>> Some time ago I acquired a PCI P/390 card (along with the various LIC
> files).  I
>> went down the same path as you to build a P/390 system with OS/2 but I
>> kept running into problems with OS/2 versions and supported hardware.
>>
>> I finally gave up and acquired a PCI based RS/6000 that I'll install AIX
> on and
>> have an R/390.  ;-)  I haven't had the time yet to make any progress on
> it.
>>
>> But it's good to know that you've managed to do this if I decide to go
> back
>> and attempt the PC route again.
>>
>> TTFN - Guy
> 
> 

I used Clonezilla to make an image of my PCI machien with a P/390E card
to a USB drive - but in your case that would, of course, require it to
recognize your RAID array (which it just might, if the BIOS recognizes it).

Re: Which Dec Emulation is the MOST useful and Versatile?

[Jay Jaeger via cctalk]

On 10/27/2017 3:54 AM, Dave Wade via cctech wrote:
> Kip,
>  I think "emulation" and "simulation" get used pretty much interchangeable.
> SIMH is touted a simulator, Hercules/390 as an emulator yet they are both
> programs that provide a "bare metal" machine via software on which an
> operating system can be installed. Neither make any attempt to reproduce the
> speed of the original CPU.
> 
> I am going to stick with "emulator" as I think of "simulation" as process
> whereby we can model some statistical or mathematical parameters e.g. how
> long the queues are in a supermarket, what time is high tide in Boston using
> only mathematics. Note this may involve a general purpose computer, or it
> may use specialist machines such as the Doodson-Lege Tidal Predictor 
> 
> http://www.ntslf.org/about-tides/doodson-machine
> 
> So to return to emulating other computers have at least  five different
> flavours...
> 
> 1. Functional Software Emulation where we match the functions but not the
> speed of operation using a program. SIMH and Hercules are such beasts
> For much work this is fine. Most software emulators take this approach.
> 
> 2. Cycle accurate Software Emulation/Simulation where we attempt to match
> both function and speed of the underlying hardware. This may be necessary
> for software which uses software loops to control say the speed of a UART. I
> If you want to use the simulator for historical research this may help. Some
> emulators can be switched to this mode when software needs it...
> 
> David Sharp's SSEM/Baby simulator is such a beast.
> http://www.davidsharp.com/baby/
> 
> 3. Behavioural  Hardware Emulation
> This is where we build a hardware implementation of a machine, but do not
> attempt to duplicate the exact detail of the logic or its speed of
> operation. Richard Stofer's IBM1130 in VHDL is such a project. 
> He doesn't have it available on the Web (I have a copy and have run it)
> There is a Flash video on the IBM1130.org site
> 
> 4. Cycle Accurate Behavioural Hardware Emulation 
> This is probably the most common approach to cycle accurate emulations.
> Because FPGA's typically run several times faster than the clock on legacy
> hardware, and they may contain high level function blocks, e.g. multipliers
> its often "relatively easy" to match the instruction times of a legacy CPU
> in an FPGA. 
> 
> My BabyBaby FPGA implementation of the SSEM FPGA is such a beast. It runs at
> the same speed as replica SSEM in MSI Manchester but internally it's a
> parallel implementation whereas the real Baby is a serial machine.
> https://hackaday.com/2016/01/06/babybaby-a-1948-computer-on-an-fpga/
> 
> 5. Gate Level Hardware Emulation
> It gate level hardware emulation we try and re-implement the hardware down
> to the logic gate level. This is hard because FPGA's are may not be designed
> to work this way, and gate level design will also have some dependencies on
> propagation delays, which on an FPGA will be much smaller than on any real
> hardware. A couple of examples of these are 
> 
> Laurence Wilkinson's IBM 360/30 http://www.ljw.me.uk/ibm360/
> Carl Claunch's IBM 1130 http://ibm1130.blogspot.co.uk/
> 
> I hope this doesn't muddy the water too much...
> Dave
>   

Well, the waters are sufficiently muddy that I figured little harm would
be dine if I throw my weeds in too...   ;)

I like that you have clearly given this some thought, and have developed
a kind of taxonomy, so your comments are valuable because they are not
just off-the cuff.

Looking online at Merriam-Webster, the conclusion one might reach is
that these are all simulators.  But emulation is also a term of art when
it comes to computers, so I don't think we should shackle ourselves to M-W.

I have generally used the term emulator for software that attempts to
provide some level of functionality (up to 100%) of the original machine
such that software (including operating systems) will operate, without
worrying about HOW that is done.  So, I would throw most, if not all, of
the SimH programs, and Hercules as well into that pot.  I would also put
the IBM 1401 and 1410 emulators that appeared on early model IBM
System/360 machines (which was done using software with microcode
assist) into that same bag, as well as the FLEX implementation of the
IBM mainframe architectures.  So, I am on the same page with you with
regards to #1.

I have generally used the term simulator for software that attempts to
replicate the actual operation of the original machine, regardless of
speed - I view speed as just one of several possible measures of the
accuracy/level of the simulation.  I have written an IBM 1410 simulator
that simulates the operation of the original machine at the machine
cycle level, based on the IBM CE instructional materials - but it pays
no attention at all to the absolute cycle time, only to the relative
cycle time (so that peripherals, such as tape drives, work in about the
same relative speed to the CPU as the 

Re: Spectre & Meltdown

[Jay Jaeger via cctalk]

A 6TB hard drive, available for about $130 (or less), would be
equivalent to about 60 of the 100GB BDXL disks, which seem to go for
about $6 each, so $360 for around 6TB.  And the hard disk will take less
time to read and write.  And the hard drive would take up less space.

JRJ

On 1/4/2018 7:50 PM, TeoZ via cctalk wrote:
> Hard drives NEVER keep up. Bragging about how many DVD's (90's
> technology) you can store on current HD means little to people who have
> ultra HD Blueray videos that take up to 100GB of space. Heck even a
> single game download can be 50GB these days.
> 
> And I wouldn't mind one of those old networked DVD changers (I think
> Sony sold them commercially) to play around with.
> 

Re: Which Operating System for my DCC-116 E / Entrex 480 / Nixdorf 620 / Data General Nova 1200 clone ?

[Jay Jaeger via cctalk]

On 10/4/2017 3:33 PM, Dominique Carlier via cctech wrote:
> Hi all
> 
> I start here another topic concerning my research about a new Operating
> System for my freshly restored DCC-116 E.
> 
> http://www.zeltrax.com/classiccmp_forum/second_boot/04.jpg
> http://www.zeltrax.com/classiccmp_forum/second_boot/02.jpg
> 
> I originally intended to install RDOS on my machine but it seems very
> difficult to find the files needed to make a system installation tape.
> 

FIRST:  If you have drawings for the DCC, please let me know.  I have
two of them (long in storage in the house, but they ran when I pulled
them from their Unitote/Regitel rack a couple of *decades* ago.

There is an RDOS - disk images, available at:

http://simh.trailing-edge.com/software.html

(Top entry in the list)  It is about a 2.5MB disk image.

I suggest that you might download SimH and that image, configure SimH as
a straight Nova (rather than a /3 or /4) and see if it runs that image
OK.  If so, there you go!

Beyond that, I *might* be able to help, but it will depend on what the
status of copyright is on what I have, and whether your system can even
run what I do have.  I am looking into the copyright part of it - that
may take a week or two.  (This is something I needed to to anyway).

In the meantime:

Do you have a way to *write* a tape image?  I have an AWS format image
of an RDOS starter system.   Note, however, that the label on the RDOS
starter image I have suggests it may  only be appropriate for a NOVA 3
or NOVA 4, so it might not run on your system.So, I'd have to take
some time to boot it and try and set up a system for a straight Nova.
As this would take several hours, I'm not keen on doing that unless you
know that one from SimH will not work for you.

I also have some OS and compiler DG floppy images, if you have a
DG-compatible floppy setup.  Several different operating systems there.
Same issue: one would have to see how many are compatible with a
straight Nova.  I have images of the floppies.

Diagnostics for DG systems are notoriously difficult to find.  I have a
few, in listing format.

JRJ

Re: Apollo Software

[Jay Jaeger via cctalk]

I wasn't aware of that.  I have a ton of Apollo QIC images.  Shall I put
them up on my Google Drive for you to grab?

On 1/21/2018 1:50 PM, Al Kossow via cctalk wrote:
> CHM has an agreement with HP to host Apollo and 68K HP 9000 software legally.
> 
> 
> On 1/21/18 11:42 AM, David Collins via cctalk wrote:
>> The HP Computer Museum would be happy to host copies of any Apollo software 
>> if it can be imaged..
> 
> 

Re: Apollo Software

[Jay Jaeger via cctalk]

A fair amount of Apollo software doc can be found at:

http://bitsavers.org/pdf/apollo/

I have other stuff that they probably don't have (yet),

I just fired off a note to Al Kossow, and I expect that QIC tape images
I have will end up on bitsavers.org/bits before too long.  Things like
Aegis SR 9.7, Domain/OS up to SR 10.4.1, Compilers, DPCE, NFS, Ethernet
card drivers, Omniback, and the like.

I also have the means to image 8" floppies of most any format (using my
Catweasel) though it has been a wee while since I have done so.

JRJ

On 1/21/2018 7:59 PM, Kevin Parker via cctalk wrote:
> Definitely interested here Bill - I've got 3 Apollos from a rescue  - have 
> the machines and  all the token ring gear but no manuals
> or software - as yet have to fire them up but anything Aegis related is of 
> interest to me.
> 
> 
> 
> 
> Kevin Parker
> P: 0418 815 527
> 
> 
> 
> 
> 
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Bill 
> Gunshannon via cctalk
> Sent: Monday, 22 January 2018 02:23
> To: General Discussion: On-Topic and Off-Topic Posts 
> Subject: Apollo Software
> 
> Is there any interest or value in copies of SR7.0  "Aegis"
> or should I just scratch them and add them to my other 8"
> disks?  (Yes, I used to have an Apollo in my house!!  Made a great heater 
> during those long cold winters.)
> 
> bill
> 
> 

Re: Apollo Software

[Jay Jaeger via cctalk]

OK.  Should have a link for you today or tomorrow.  I want to do an MD5
checsum of all of it because there are a lot of duplicates.

On 1/22/2018 10:57 AM, Al Kossow via cctalk wrote:
> sure thing.
> we got boxed of tapes and about 100 esdi disks from the support development 
> cluster I haven't
> had time to do anything with
> 
> also, i have lots of the last couple of revs of manuals up on bitsavers and 
> there is a functional
> Apollo emulator running in MAME
> 
> 
> 
> On 1/21/18 7:16 PM, Jay Jaeger via cctalk wrote:
>> I wasn't aware of that.  I have a ton of Apollo QIC images.  Shall I put
>> them up on my Google Drive for you to grab?
>>
>> On 1/21/2018 1:50 PM, Al Kossow via cctalk wrote:
>>> CHM has an agreement with HP to host Apollo and 68K HP 9000 software 
>>> legally.
>>>
>>>
>>> On 1/21/18 11:42 AM, David Collins via cctalk wrote:
>>>> The HP Computer Museum would be happy to host copies of any Apollo 
>>>> software if it can be imaged..
>>>
>>>
> 
> 

Re: Apollo Software

[Jay Jaeger via cctalk]

Al, the tape images have been uploaded to:

https://drive.google.com/open?id=1AbOOHQjssPPEterpJLCP6A3S50K97rp_

Which is a subdirectory (bits/Apollo) in

https://drive.google.com/open?id=0B2v4WRwISEQRWWFFdVpCZWFTZEU

Unfortunately, my Aegis SR9.7 had errors (I had forgotten that).

As the readme explains, I read each one twice where I could (once on an
actual Apollo, and a second time on Linux), and compared them, and then
took one set (SR10.2, I think), and installed them on the MESS (now
apparently subsumed within MAME - I did this work several years ago)
simulator to make sure the process actually worked.

JRJ

On 1/22/2018 10:57 AM, Al Kossow via cctalk wrote:
> sure thing.
> we got boxed of tapes and about 100 esdi disks from the support development 
> cluster I haven't
> had time to do anything with
> 
> also, i have lots of the last couple of revs of manuals up on bitsavers and 
> there is a functional
> Apollo emulator running in MAME
> 
> 
> 
> On 1/21/18 7:16 PM, Jay Jaeger via cctalk wrote:
>> I wasn't aware of that.  I have a ton of Apollo QIC images.  Shall I put
>> them up on my Google Drive for you to grab?
>>
>> On 1/21/2018 1:50 PM, Al Kossow via cctalk wrote:
>>> CHM has an agreement with HP to host Apollo and 68K HP 9000 software 
>>> legally.
>>>
>>>
>>> On 1/21/18 11:42 AM, David Collins via cctalk wrote:
>>>> The HP Computer Museum would be happy to host copies of any Apollo 
>>>> software if it can be imaged..
>>>
>>>
> 
> 

Re: Trouble installing 4.3 BSD+NFS Wisconsin Unix

[Jay Jaeger via cctalk]

No, at least not right now, but as someone who attended UW (long before
this distro was made), I find it interesting.

JRJ

On 2/5/2018 6:06 PM, Noel Chiappa via cctalk wrote:
> Can anyone help 'Darkstar' with this:
> 
>   http://gunkies.org/wiki/Talk:Installing_4.3_BSD%2BNFS_Wisconsin_Unix
> 
>   Noel
> 

Re: qd32 trouble

[Jay Jaeger via cctalk]

I *might* be able to help, *if* you also have a MicroVax you can plug
this controller into - eventually (months).  I have a pair of MicroVaxen
with Emulex QD32 SMD controllers in my collection.  (My inventory shows
them as QD325, but I expect that is a misnomer; my notes indicate QD32).

With those machines I also got an Emulex Diagnostic tape, VX9962004 Rev
J.  My notes indicate it has these diagnostics:

FQD01M MSCP Formatter:  QD01, QD32, SC03
FVD03M: UCxx Host Adapter Format
FVD32M MSCP Formatter: QD01, QD32, SC41, SC03
IQC02: DHV11 Option of CS02/H Diagnostic
IQT12: TS11 Compatible QT12/TC03 Diagnostic
IVC23E: CS23/CS04 Diagnostic

I have not used that tape in several years, though, I don't seem to have
made an image of that tape at this point (shame on me).  (Now on my ToDo
list - but it will probably be a couple of months).

On 2/20/2018 5:49 PM, Jacob Ritorto via cctalk wrote:
> Hi all,
>   Would anyone here be able to help me troubleshoot my qd32 controller?  I
> have a pdp11/73 that's mostly working, boots 2.11bsd from rl02 okay, but I
> need my big disk to work so I can load the rest of the distro.
>   I've been following the manual for the qd32 to enter the geometry of my
> real working Fuji m2333 (jumpered correctly according to the manuals), but
> when I load the special command into the qd32's SP register that's supposed
> to load the geometry table I entered in pdp11 memory to the qd32's novram,
> I get a bad status value from the qd32's SP register and it remains
> unresponsive when I try to store the geometry.  If I go ahead and try the
> built-in qd32 format command, it responds similarly.  When I pull in mkfs
> from tape (vtserver) and try anyway, despite the failures, to run mkfs on
> the m2333, I get an !online error from the standalone unix mkfs.  The disk
> does respond (the select light flashes and I can hear heads actuating), but
> without geometry and format, I'm obviously dead in the water.
> 
>   I understand that there used to exist some Emulex qd32/pdp11 diagnostics
> that could help the situation, but my previous attempts to find copies have
> come up short.
> 
>   Any suggestions on how to proceed?
> 
> thx
> jake
> 

Website Relocation

[Jay Jaeger via cctalk]

FYI, the service under which I have been hosting my website for many,
many years is going away.

So, webpages.charter.net/thecomputercollection

Has been relocated to

www.computercollection.net

(The content is unchanged for now).

This will also give me the freedom to eventually post lots more (and muc
better) photos, put up my manual database and other databases at some
point, and all sorts of cool things over time, but at present I am
focused on my capture of the IBM 1410 Automated Logic Diagrams (ALDs).

(BTW, the capture application (C#) is written, though still being
debugged/improved, and I have already captured one volume of drawings,
and am testing VHDL generation from the captured information.)

JRJ

Re: IBM junk

[Jay Jaeger via cctalk]

Wow.  It is rare to see anything related to the IBM 1410.  The two sales
models with the 1415 console (one with a 13xx disk, the other with two
729 tape drives) were mouth watering...

It was interesting to see the time clock (perhaps from S/N 00360?) as
well - complete with key.

Maybe they will sell me one?

JRJ

On 6/22/2018 5:34 PM, Donald via cctalk wrote:
> Collected stuff for over 10 years.  Moving from 2300 sq. ft. to 1400.  It
> had to go. Praise the computer gods I found someone that wanted it all.
> 
> 115 boxes of manuals and documents.
> 26 boxes of coffee mugs
> 73 703 boxes of stuff.
> 106 loose big items.
> 
> Filled the floor space of a 26' truck.
> 
> It can be viewed at http://www.ibmjunkman.com/junk/
> 
> Best viewed on a PC with decent speed connection.
> 
> Sample stuff: 360 Mod 20 panel, mod 30 panel, mod 65 panel, s/3 panel. Disk
> pack and HDA up the ying yang.3850 data carts, 2321 data cell, 7340
> Hypertape cartridge, a Russian equivalent, desktop chachki (tchotchke), 360
> mod 70 desktop model used in 1964 World's Fair,  etc, etc.
> 
> 

Re: 18 bit CPU; was: Speed now & then

[Jay Jaeger via cctalk]

> On Apr 15, 2018, at 09:44, Bill Gunshannon via cctalk  
> wrote:
> 
> 
> 
>> On 04/15/2018 02:28 AM, r.stricklin via cctalk wrote:
>>> On Apr 14, 2018, at 4:00 PM, Bill Gunshannon via cctech wrote:
>>> 
>>> I'm familiar with Univac's having worked on the 1100 many moons ago,
>>> But look at the line above my comment:
>>>  "you assume that a char is 8 bits, with a signed char having a range
>>> of +/-255".
>>> 
>>> An 8 bit signed char has the values -128 to +127, as I stated.  even a 9 bit
>>> signed char would not be +/-255 but -256 to +255.
>> Doesn't the 1100 use one's complement? -0 != 0, so AFAICT it's still +/-255.
>> 
> Can't remember that.  It's over 30 years since my 1100 days.
> 
> I do remember it wasn't an ASCII machine, however.  good ole Fielddata.
> 
> bill
> 

Yes, the Univac 1100 series were one’s complement (had brief experience as a 
student with 1108 and 1110 from 1969 to 1975)

Sent from my iPad

Re: RL02 Question

[Jay Jaeger via cctalk]

My inventory indicates that I have a pair of lower ("UP") heads, part
number 70-15637 for an RL02.  (I don't have any spare "DOWN" heads as
far as I can tell).  I think they might even be new old stock, as they
are marked "NEW" in my inventory.  So maybe we could work something out.
  You might suggest a price, and we can take it from there.  Once we get
agreement, I'll open up the box they are in (in my garage) and confirm
my inventory.

JRJ


On 3/27/2018 4:34 AM, Aaron Jackson via cctech wrote:
>> On 03/26/2018 04:08 PM, Aaron Jackson via cctalk wrote:
> So, from what I can see, the drive should spin up correctly, but for
> some reason it goes into fault mode. I am right in thinking that upon
> load, the heads should continue moving forward until the first track is
> found, right? I should not have to perform a seek manually from the PDP?
> If this is not the case, perhaps there is something else wrong.
 I’m not an RL02 hardware expert at all, just a daily user back in the
 day. I’m reading this assuming that at all times the drive is
 correctly hooked up to an RLV12 in a running PDP with the correct
 cable and termination present on the drive? If it isn’t you’ll get a
 fault condition instead of ready after spin up.

 A
>>> No worries, your input has been valuable, so thank you.
>>>
>>> For anyone else who might have an idea:
>> ON fault the heads are retracted and will not load till cleared.
>> Least mine behaves that way.
>>
>> Most common problems are wrong drive address, cable issues, no terminator.
>> Others include head lock not removed or the auto unlock style of
>> headlock has
>> the tab broken.
>>
>>> It seems to be hooked up correctly. When it is in the weird flashing
>>> ready state, the boot loader says "Read error" or "Device error"
>>> randomly. The heads oscillate back and forth very slightly as if it is
>>> trying to align itself better on the first track, which doesn't exist
>>> because it hasn't moved far enough into the pack.
>> IF in fault its resetting to retracted on every try.
>> If not something else is wrong.
>>
>>> I'm beginning to think the heads are bad which will be far too expensive
>>> so I may end up giving up.
>>
>> Heads are not that expensive... However you could have a wrong pack
>> or one that has been erased and has no servo tracks. You must start with
>> a known good pack and cleaned heads.
>>
>>
>> Allison
> 
> Thanks for the suggestions, Allison.
> 
> Given that the pack was tested before it was shipped, I am beginning to
> come to the conclusion that the heads are bad. I can see the servo burst
> data if I push the heads on a few mm further into pack, but perhaps the
> heads produce noise which confuse the logic upon load.
> 
> Heads are more expensive than what I'd like, from what I have seen on
> eBay.
> 
> I believe I have a "working" (i.e. non-crashing) down head (as in the
> one on top). If this is head 0 (anyone know?) then I might have a chance
> of getting it working without spending anymore money. Let's see.
> 
> Thanks again,
> Aaron.
> 

Re: Did anyone on the list get these tapes?

[Jay Jaeger via cctalk]

> On Mar 16, 2018, at 12:39, Josh Dersch via cctalk  
> wrote:
> 
> On Fri, Mar 16, 2018 at 9:07 AM, Glen Slick via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> On Fri, Mar 16, 2018, 8:51 AM Al Kossow via cctalk 
>> wrote:
>> 
>>> https://www.ebay.com/itm/1372243559202
>>> 
>>> basic.p11
>>> syslod.p11
>>> rdt.p11
>>> 
>>> all from mid 1971
>>> original RSTS?
>>> 
>>> hope the person who got these knows what they bought
>>> 
>> 
>> Extra digit in that link, try:
>> 
>> https://www.ebay.com/itm/372243559202
>> 
>>> 
>> 
> 
> The LCM+L bought them, we're going to image them when they arrive (and I'll
> be sure to send a copy your way).
> 
> - Josh

Ya!!!  I saw those and there were some tapes their that looked like my 
PDP-12 might enjoy then.  

Sent from my iPad

Re: DEC Field Guide > equivalent available for Data General?

[Jay Jaeger via cctalk]

On 3/21/2018 4:37 AM, Ulrich Tagge via cctech wrote:
> Hi all,
> 
> is there somewhere a list of DG modules which includes also 3rd
> party/OEM, ... like it is available for DEC?
> 
> Would be good to know what the following is:
> 
> 107-000621 02
> 107-000621 03/11
> 107-001632-00
> 107-0016320/02
> 107-000718-00
> 107-000181-04
> 107-000187-16
> 107-000187-15-30
> AB020116-00
> 107-000621-03
> 107-001768-02
> 107-001768-03
> 107-0017680-1E
> 107-00053905
> Zetaco SCZ-2
>>500-453-00 K
>>500-542-00 K
> 
> 
> Many Greetings
> Ulrich
> 

I have some DG spare parts catalogs, but the numbers in them are all the
005- part numbers, not the 107- board numbers.  To translate them, one
would have to look through sets of drawings.  So, if your boards have
the 005- number, I might be able to help you out.

For the most part, the numbers you have listed are newer than the boards
I have documented because I actually have them (I go up to 107-001410).

I have a 107-000187 and I also have it documented as a disk controller.

Your list has some duplication.  For example, all the numbers that start
out 107-001768 are for the same kind of board - just different
revisions.  Same for 107-000187, 107-001632 and 107-000621.

JRJ

Re: ARPANET Reaches the Royal Signals and Radar Establishment (RSRE, Malvern)

[Jay Jaeger via cctalk]

On 2/23/2018 11:45 AM, Paul Birkel via cctalk wrote:

> The following extract comes from a History of Programming Languages (HOPL)
> retrospective on the development of the Ada programming language written by
> the individual who was the government lead at DARPA for much of the time of
> its development (Colonel William A. Whitaker).  I found it humorous.
> Perhaps you will too.
> 
>  
> 
> -
> 
> The ARPANET connection was inaugurated during a visit to RSRE by Her Royal
> Highness Queen Elizabeth II.  Her Majesty sent a message of greetings to the
> members of the HOLWG from her net account, EIIR, by pressing a red velvet
> Royal carriage return.  Because the address list was long, it took about 45
> seconds for the confirmation to come back, 45 seconds of dead air.  Prince
> Philip remarked, joking respectfully, that it looked like she broke it.
> 
> -
> 
>  
> 
> I suspect that we've "all been there" at one time or another!
> 
> paul
> 
>  
> 
> 

Speaking of lonng response times

In the 1970s, during the development of a home-grown database system
where I used to work (developed shortly before I started there in the
mid 1970s) - that lasted over 40 years - on an IBM 360/65 MP, they were
used to having the nascent DBMS and/or the application crash, so they
got used to pressing Enter, waiting a minute or so, then heading down to
the computer room to pick up the core dump.

Well one day they got down to the computer room, but the DBMS was still
running, so they headed back upstairs (one floor up).  After about FIVE
MINUTES the application they were using to test came back with the
correct results.  Mixed emotions: yeah, it worked, but whoa, performance
was clearly going to be a problem.  ;)

By the time the thing was in production it had its own memory manager
instead of using the OS/360 GETMAIN SVC, KORMAN (or "Harvey" for short
;)).  Then it got its own task manager / threading to use instead of the
OS/360 task management - TASKMAN (they really should have called it
TAXMAN  ;)).  Then it got its own subsystem for loading the application
programs, aka content management - yup - KONMAN.  ;)  So, in the end, it
was almost an OS unto itself.  [I served as the DBA for 7 years during
that time.]

Starting out under OS/360 MVT, it survived moves and garnered
enhancements under MVS, MVS/SP, MVS/XA, MVS/ESA, OS/390 and finally z/OS
before it was finally retired.

Re: Manual for Documation TM200 punched card reader

[Jay Jaeger via cctalk]

The information on my Documation card reader interface have now been
uploaded, and is available at:

https://drive.google.com/drive/folders/13KyRN4NuHIlTlBhoHiWZWmIfLwQbP5jn?usp=sharing

On 9/24/2018 5:58 PM, Jay Jaeger via cctalk wrote:
> FYI, I have a design for a RS-232 interface to the Documation M series
> interface, based on a PIC 16F877.  The design is in turn based on one
> that does not use a PIC, that Al Kossow shared with me some time back -
> and is designed to work with the same software on the PC side (at least
> if I recall correctly - I did this back in 2013).  [I seem to recall
> that when I was testing it, I just used a terminal emulator of some
> sort, so PC side software would be easy.]
> 
> The board design is in KiCAD.The "firmware" for the PIC is in C,
> developed using MPLABX (freely available).
> 
> So, if anyone wants the materials, say so, and I will share a link, and
> scan in my interface connector pinouts, etc., and put up a folder on my
> Google Drive.
> 
> I also still have *ONE* *UNPOPULATED* board (approx. 4.25" x 2.5") that
> I would be willing to part with for $10 US + S  As I recall, there is
> one missing pull-up resistor that is wrong on the schematic (and thus
> missing on the board, too), from pin 1 of the PIC to VCC, and is easy to
> deal with, and that the LED labels on the silk screen are flipped around
> on the board vs. the schematic [which can be dealt with easily in
> software, so that the LEDs match the silk screen.]  The design includes
> an in-circuit  programming header.
> 
> Unfortunately, the pinouts I used for the 40 pin connector on the PC
> board to the card reader are NOT the same as what the Computer History
> Museum has, and it makes wiring the cable a bit of a pain, because the
> signal and signal return lines are not next to each other on the
> connector, but should be so using a twisted pair cable.
> 
> JRJ
> 
> 
> 

Re: Manual for Documation TM200 punched card reader

[Jay Jaeger via cctalk]

FYI, I have a design for a RS-232 interface to the Documation M series
interface, based on a PIC 16F877.  The design is in turn based on one
that does not use a PIC, that Al Kossow shared with me some time back -
and is designed to work with the same software on the PC side (at least
if I recall correctly - I did this back in 2013).  [I seem to recall
that when I was testing it, I just used a terminal emulator of some
sort, so PC side software would be easy.]

The board design is in KiCAD.The "firmware" for the PIC is in C,
developed using MPLABX (freely available).

So, if anyone wants the materials, say so, and I will share a link, and
scan in my interface connector pinouts, etc., and put up a folder on my
Google Drive.

I also still have *ONE* *UNPOPULATED* board (approx. 4.25" x 2.5") that
I would be willing to part with for $10 US + S  As I recall, there is
one missing pull-up resistor that is wrong on the schematic (and thus
missing on the board, too), from pin 1 of the PIC to VCC, and is easy to
deal with, and that the LED labels on the silk screen are flipped around
on the board vs. the schematic [which can be dealt with easily in
software, so that the LEDs match the silk screen.]  The design includes
an in-circuit  programming header.

Unfortunately, the pinouts I used for the 40 pin connector on the PC
board to the card reader are NOT the same as what the Computer History
Museum has, and it makes wiring the cable a bit of a pain, because the
signal and signal return lines are not next to each other on the
connector, but should be so using a twisted pair cable.

JRJ



On 9/22/2018 10:53 PM, Ethan Dicks via cctech wrote:
> On Sat, Sep 22, 2018 at 10:34 AM, Guy Dunphy via cctalk
>  wrote:
>> By coincidence, today I started evaluation of a punched/optical card reader.
>> Model TM200, made by Documation Inc.
>>
>> Pics here: http://everist.org/pics/TM200/
>>
>> The immediately obvious problems:
>> * Mains input connector is one of those old round locking type. Not sure if 
>> I have any of these.
> 
> I have an M200 and I just had to look up in the docs (on bitsavers)
> that my unit requires a Hubbel
> 7484 for the power cable.  Yours is different but it's likely to be
> some sort of Hubbel product.
> 
> 
>> * Hose from vacuum pump to pickup heel is hardened. Needs replacement.
>> * Plastic elbow fitting for vacuum to pickup heel is broken in half. Make 
>> new one.
>> * Plastic mount for status display lights is cracking around brass nut 
>> inserts.
>> * Four rubber transport rollers have de-vulcanised, melted, and flowed gunk. 
>> Urrgh, what a mess.
> 
> Hmm... I probably need to look into mine for similar things.
> 
>> * Ouch, that interface connector.
> 
> Fortunately, my M200 came with a factory add-on board that's an RS-232
> interface to the upstream host.
> 
>> I wonder where I'm going to find some card stacks for testing it? If I get 
>> that far.
> 
> An old co-worker buddy of mine gave me a box of his punchcards when he
> was in school in 1970.  He's really on me to read them.  I don't want
> to put his in first and have roller goo or something else ruin them so
> I have a bit of exploration to do.
> 
> I'll be interested to hear how your saga unfolds because I'm expecting
> all of that and more on mine.
> 
> -ethan
> 

Re: 8-Update

[Jay Jaeger via cctalk]

Typically the files on Thingiverse are .STL format, which is portable 3D
model.  One feeds it into a slicer program (there are several to choose
from) to produce GCode that uses the specifications of one's particular
printer so that the right GCode gets spit out.

On 12/17/2018 3:26 PM, Zane Healy via cctalk wrote:
> Are the files “platform independent”?  I know very little about 3D printing, 
> but have been tempted to get a printer for a while now.  Though I’m worried 
> about what my kids wanting to use it. :-)
> 
> Zane
> 
> 
> 
> 
> On Dec 17, 2018, at 1:12 PM, Torfinn Ingolfsen via cctalk 
>  wrote:
>>
>>
>> FWIW, the easiest way to find out if somebody has made (or has tried
>> to make) replacement parts for anything that can be 3D-printed is to
>> go to thingiverse.com with your web browser.
>> And then search for whatever thing you need (search terms / words are
>> a separate subject, try as wide or as many as have time for.
>> When you find a part, look at pictures, comments, makes and so on to
>> try to figure out if this is a working part or just something somebody
>> has mad a 3D model of, and never tested.
>> Some relevant examples:
>> https://www.thingiverse.com/thing:360853  PDP-8 Panel Switch Toggle
>> https://www.thingiverse.com/thing:386762  DEC RL-02 Spindle Ground Brush
>> https://www.thingiverse.com/thing:2454690  PDP Stand - Mount
>>
>> HTH
>> On Sun, Dec 16, 2018 at 10:35 PM Al Kossow via cctalk
>>  wrote:
>>>
>>>
>>>
>>> On 12/15/18 11:36 PM, Rod G8DGR via cctalk wrote:
>>>
 However I began to think would it be possible to create a close copy of an 
  8/e out of  modern parts.
>>>
>>> Redoing the CPU in obtanium TTL would be desirable.
>>>
>>>
>>
>>
>> -- 
>> mvh
>> Torfinn
> 
> 

Re: Original PDP-11/10 [was: Re: Origin of 'Straight 8' name]

[Jay Jaeger via cctalk]

On 12/21/2018 3:07 PM, Paul Koning via cctalk wrote:
> 
> 
>> On Dec 21, 2018, at 3:06 PM, Bill Degnan via cctalk  
>> wrote:
>>
>>>
>>>
>>>
>>> My _guess_ is that that probably happened because there is no formal
>>> 'model'
>>> for that first one (unlike the first -11, which got re-named the -11/20
>>> BITD), and people recently picked that to disambiguate them from all the
>>> other -8's.
>>>
>>>
>>>
>> The original PDP 11 was sold in two model options, although the numbers did
>> not appear on the faceplace, very clearly the model options were called PDP
>> 11/10 and PDP 11/20.  These are just as legitimate and well defined as the
>> 11/05 vs. 11/10 (later version) that followed it except for the one fact of
>> the front plate.  The fact that the name does not appear on the front panel
>> has caused every DEC historian to miss this factoid.  Read the first
>> brochure, don't take my word for it.
>> http://vintagecomputer.net/browse_thread.cfm?id=593
>>
>> Momentum prevents change I get it, but it's clear that the model 11/20 and
>> 11/10 existed from day one.  The problem is that DEC re-used the 11/10
>> model name again a few years later, the other cause for neglecting the
>> original 11/10 model.
>>
>> Bill
> 
> Wow.
> 
> Did that V1 11/10 ever ship?  Do any still exist?
> 
> I'm curious about that 1 kW read-only memory.  What technology is that 
> memory?  At that size and that date I suspect core rope, but that would be 
> pretty expensive (due to the labor involved).
> 
>   paul
> 
> 

It shows up in the pdp11 handbook 1969 inside/1970 on the spine, and
pdp11 handbook 2nd edition (also 1969/1970), but has been displaced by
the latter 11/10 variant by 1972.

Perhaps, since the *only* difference was the memory configuration (near
as I can tell), there may have been so few orders (maybe even none?)
that they just dropped it.  Or maybe a marketing / design team
communication misstep.

The pdp11 handbook from 1969/1970 identifies the memory attributed to
the 11/10 only as read-only core memory with an access time of 500ns
(same as the RAM core).  It describes the tiny RAM for the 11/10 of 256
words has having a 2us cycle time vs. 1.2us for the 11/20.

The handbook also indicates that an 11/20 could do an NPR transfer every
1.2us but an 11/10 could do one ever 1.0us (probably assuming ROM cycle
times).

As a guess, they may never have sold any (or delivered 11/20's to those
who ordered 11/10's).

Re: Original PDP-11/10 [was: Re: Origin of 'Straight 8' name]

[Jay Jaeger via cctalk]

On 12/21/2018 4:00 PM, Bill Degnan wrote:
> 
> 
> On Fri, Dec 21, 2018 at 4:47 PM Jay Jaeger via cctalk
> mailto:cctalk@classiccmp.org>> wrote:
> 
> On 12/21/2018 3:07 PM, Paul Koning via cctalk wrote:
> >
> >
> >> On Dec 21, 2018, at 3:06 PM, Bill Degnan via cctalk
> mailto:cctalk@classiccmp.org>> wrote:
> >>
> >>>
> >>>
> >>>
> >>> My _guess_ is that that probably happened because there is no formal
> >>> 'model'
> >>> for that first one (unlike the first -11, which got re-named the
> -11/20
> >>> BITD), and people recently picked that to disambiguate them from
> all the
> >>> other -8's.
> >>>
> >>>
> >>>
> >> The original PDP 11 was sold in two model options, although the
> numbers did
> >> not appear on the faceplace, very clearly the model options were
> called PDP
> >> 11/10 and PDP 11/20.  These are just as legitimate and well
> defined as the
> >> 11/05 vs. 11/10 (later version) that followed it except for the
> one fact of
> >> the front plate.  The fact that the name does not appear on the
> front panel
> >> has caused every DEC historian to miss this factoid.  Read the first
> >> brochure, don't take my word for it.
> >> http://vintagecomputer.net/browse_thread.cfm?id=593
> >>
> >> Momentum prevents change I get it, but it's clear that the model
> 11/20 and
> >> 11/10 existed from day one.  The problem is that DEC re-used the
> 11/10
> >> model name again a few years later, the other cause for
> neglecting the
> >> original 11/10 model.
> >>
> >> Bill
> >
> > Wow.
> >
> > Did that V1 11/10 ever ship?  Do any still exist?
> >
> > I'm curious about that 1 kW read-only memory.  What technology is
> that memory?  At that size and that date I suspect core rope, but
> that would be pretty expensive (due to the labor involved).
> >
> >       paul
> >
> >
> 
> It shows up in the pdp11 handbook 1969 inside/1970 on the spine, and
> pdp11 handbook 2nd edition (also 1969/1970), but has been displaced by
> the latter 11/10 variant by 1972.
> 
> Perhaps, since the *only* difference was the memory configuration (near
> as I can tell), there may have been so few orders (maybe even none?)
> that they just dropped it.  Or maybe a marketing / design team
> communication misstep.
> 
> The pdp11 handbook from 1969/1970 identifies the memory attributed to
> the 11/10 only as read-only core memory with an access time of 500ns
> (same as the RAM core).  It describes the tiny RAM for the 11/10 of 256
> words has having a 2us cycle time vs. 1.2us for the 11/20.
> 
> The handbook also indicates that an 11/20 could do an NPR transfer every
> 1.2us but an 11/10 could do one ever 1.0us (probably assuming ROM cycle
> times).
> 
> As a guess, they may never have sold any (or delivered 11/20's to those
> who ordered 11/10's).
> 
> 
> When you consider the differences between the 11/35 and 11/40 were
> simply option choices and the later 11/10 11/05, I can see no reason why
> the "original 11/10 11/20 is any different other than the front plate
> being "PDP-11" for the later pairing.  I am unaware of any 11/10's still
> around but I am also unaware of any Rolm 1601's that still exist, does
> not mean it was not a real Ruggednova model.  etc.
> 
> Basically it's being inconsistent to not acknowledge the original 11/10.
> 
> We could say that the PDP 11 models were
> 11/20
> 11/45
> 11/40
> 11/10
> 
> ... and ignore the original 11/10, plus the 11/35 and 11/05. 
> 
> I will still sleep well at night regardless what officialdom decides. :-)
> 
> Bill

Unless, of course, none of them found their way into customers' hands.

Re: Researching IBM rare equipment from 50s to 80s

[Jay Jaeger via cctalk]

On 12/14/2018 4:41 AM, Peter Van Peborgh via cctech wrote:
> Fellow geeks of more mature vintage,
> 
> Do any of you guys know whether it is possible to find out to whom any IBM
> equipment was sold back in the day? (Still chasing IBM 2321 Data Cell - I
> never learn!)
> 
> Many thanks,
> 
> peter
> 

Well, if your intention is to actually find one, can't help.

I do know that Wisconsin DOT had one back in the day, on an IBM 360/50,
but it was gone before I started work there.  I think that I have a
large negative of the beastie lying around somewhere.  No, it is not
stuffed anywhere.  Indeed the building that formerly housed it (and was
home for me during my career) was razed just this year.

In general, even if IBM still had such records, I am sure that they
would not release them, and doubt that they would be indexed in fine
detail such that you could find customers of any particular machine type
(unless they fed them to Watson ;) ).  Leased units would have been
turned back into IBM.  Purchased units would have been mostly traded in
and scrapped.

A Google Search found these instances of customer units (there may well
be more - I stopped after a few pages)

http://www.columbia.edu/cu/computinghistory/datacell.html

https://www.facebook.com/HealthManagementTechnology/photos/ibm-2321-data-cell-drive/132475567020/

https://commons.wikimedia.org/wiki/File:IBM2321DataCellAtUMich.jpg




JRJ

Re: DG Nova 4 for pickup on Lon Gisland

[Jay Jaeger via cctalk]

On 12/18/2018 3:35 PM, Al Kossow via cctech wrote:
> 
> 
> On 12/18/18 12:38 PM, William Donzelli via cctalk wrote:
> 
>>> Unfortunately I got no docs or media with this machine. And it appears
>>> all that is up on bitsavers are tape images?
> 
> Everything DG related on bitsavers has been on hold for a while until the
> licensing situation with EMC worked itself through.
> 
> 
> 

I have a fair amount of DG software floppies (and have imaged them), but
have also been advised (by another party) to hold off making them
available owing to licensing issues.  Shame, really.  Hopefully it will
all get worked out.

But, here is a quick list:

(DGDSDD is double-sided dual density, DGFHS is DG hard sectored, MT is
mag tape (9 track))

KINDID  MACHINE CONTENTSCOMMENT ChecksumChecksum 2  
FILENAMEMFG
SERIAL  TRAYDATEAVAILABILI  ERRORS  PREVIOUS_C

MT  CC0028  NOVA"RDOS ""STARTER"""  12/30/88 NOVA 3/4, 1 Extra
file @ end  rdos_starter_881230.aws Memorex 35CWA1  Rack 
East Wall
8/7/2000?   

MT  CC0029  NOVA"RDOS66 ""STARTER TAPE"""   12/31/88 NOVA 4/X, Last
file BADrdos_66_starter_881230.aws  Memorex 27JHA9  
Rack East Wall
8/7/2000Y   

MT  CC0030  NOVARDOS 6.6 NOVA 4/x FDUMP Reel 1 of 2 12/31/88
rdos_66_fdump_1_of_2_881231.aws Memorex 35JWA9  Rack East Wall  8/7/2000


MT  CC0031  NOVARDOS 6.6 NOVA 4/x FDUMP Reel 2 of 2 12/31/88
rdos_66_fdump_2_of_2_881231.aws Wabash  87623#1511  Rack East Wall  
8/7/2000



KINDID  MACHINE CONTENTSCOMMENT ChecksumChecksum 2  
FILENAMEMFG
SERIAL  TRAYDATEAVAILABILI  ERRORS  PREVIOUS_C

DGDSDD  DGF1229 Nova 4  NOVA 4/X BASICGEN.  DUMP FORMAT 12/30/88
DGF1229.DMK DG  F64 12/30/1988  All 
Tracks 16 x 512 2464 Sectors

DGDSDD  DGF1230 Nova 4  NOVA 4/X $LIB $SPL $OLIB $WP DUMP FORMAT
12/28/88DGF1230.DMK DG  F64 
12/28/1988  All Tracks 16 x 512 2464 Sectors

DGFHS   1001NOVANOVA DOS Starter DK W/O Mag Tape072-02-02
(Copy)  dg1001.img  DG  F50 


DGFHS   1002NOVANOVA DOS Starter DK Rev. 3.00   072-02-04   
dg1002.img  DG  F50 

DGFHS   1003NOVANOVA DOS Starter DK Rev. 3.00   072-02-04 (Copy)

dg1003.img  DG  F50 4/20/1979   

DGFHS   1004NOVANOVA DOS SYSGEN Diskette: W/O Mag Tape
072-03-01   dg1004.img  DG  F50 


DGFHS   1005NOVANOVA DOS SYSGEN Diskette: W/O Mag Tape  072-03-02
(Copy)  dg1005.img  DG  F50 


DGFHS   1006NOVANOVA DOS UTILITY Diskette W/O Mag Tape
072-04-01   dg1006.img  DG  F50 


DGFHS   1007NOVANOVA DOS UTILITY Diskette W/O Mag Tape  072-04-02
(Copy)  dg1007.img  DG  F50 


DGFHS   1008NOVANOVA DOS UTILITIES DK Rev. 3.00 072-04-04   
dg1008.img  DG  F50 

DGFHS   1009NOVANOVA DOS UTILITIES DK   072-04-?? (Copy, Revision
not shown)  dg1009.img  DG  F50 
4/20/1979   

DGFHS   1010NOVARTOS Mag Tape Support   072-06-01 (RTOS DOS Support
not Mag?dg1010.img  DG  F50 


DGFHS   1011NOVANOVA DOS Starter Diskette With Mag Tape
072-09-00   dg1011.img  DG  F50 


DGFHS   1012NOVACMSP (Communications Mux Software Pkg?)
072-18-00   dg1012.img  DG  F50 


DGFHS   1013NOVAMicroNOVA Starter DK Rev. 3.00  072-35-03   
dg1013.img  DG  F50 

DGFHS   1014NOVADOS Update 2 for Rev 3.00   072-000241-01   
dg1014.img  DG  F50 

DGFHS   1015NOVANOVA RTOS   072-40-00   
dg1015.img  DG  F51 

DGFHS   1016NOVANOVA RTOS on Diskette   "072-40-02 (Rev 6)
""3100"""   dg1016.img  DG  F51 


DGFHS   1017NOVARTOS Rev. 6.20  072-40-03   
dg1017.img  DG  F51 

DGFHS   1018NOVARTOS Update 1 ON 

IBM SMS Data Capture - IBM 1410 update

[Jay Jaeger via cctalk]

I have finished the 3rd phase of my IBM 1410 SMS computer
reverse-engineering project. The first phase was writing a software
machine-cycle simulator - almost 20 years ago, in part to verify I had
usable software. The 2nd phase was writing code and setting up a
database to do the 3rd phase - capturing data from IBM Automated Logic
Diagrams (ALDs).

The ALDs comprise 752 pages from 9 of the 11 total volumes of system
schematics/engineering drawings, volumes II-X. (Volume I is the power
supply and volume XI is additional memory).

It took me roughly 375 hours of time (probably more like 450 - not all
time was captured) to capture the data into a database that contains
10,565 ALD logic blocks, 1281 "DOT functions" where outputs of gates
joined as a "Wired OR", with 4222 distinct signal names appearing as
12,398 entries on the 752 pages, and over 32,700 individual connections.

The sheets (as reprints from scanned originals) stacked up are 2" high.
The second photo is one of them (with marks I made during data capture)
is pictured here. The third photo is a screenshot of that page in the
application I developed. (The numbers at the bottom, which do not appear
on the original sheet, are a gate number on a given SMS card, the number
of inputs to that block, and the number of outputs from the block. The
little "A" characters appearing between columns represent "DOT functions."

I ran a regression in Excel to estimate the time for capturing a given
sheet, which ended up as:

Time (in minutes per page) = -7.1 +
1.00 * # ALD blocks on the page (the rectangles) +
0.50 * distinct signals coming from / going to other sheet(s) +
2.24 * # "DOT Functions" on the page +
0.15 * # of connections to/from ALD blocks on the page +
0.39 * # of edge connection locations (at the bottom)

Most of the residuals - the difference between the actual value recorded
and what the equation would calculate - were under 25%.

The "DOT Function" coefficient is probably correlated to the overall
complexity of the page - "DOT Functions" themselves were easy to enter.

The next step is to clean up some things in the application and tune the
database to perform better, at which point I expect to make the
application available via some online GIT repository so it can be used
for other SMS machines (IBM 1620, IBM 1401, IBM 7000 series and the like).

Then it will be on to synthesis of sections of the machine (CPU, memory,
console) for which I have drawings and some kind of stand-in for parts I
don't have drawings for (1414 I/O Synchronizers, tape drives, etc.).

The photos referenced can be found at the public facebook post at:

https://www.facebook.com/jay.jaeger.3/posts/2100428726685075

Re: PDP-8/e

[Jay Jaeger via cctalk]

I did that sort of thing for my PDP-8/L, where the reader run drove the
RS-232 "CTS" control signal and wrote a "C" program to do simple TTY
emulation in DeSmet C back in the day.

That code would not run in Windows of course, but it wouldn't be all
that difficult for someone with a C programming background to move it to
Windows under gnucc, or even Microsoft C++ or C#.

On 12/8/2018 1:10 AM, Rod G8DGR via cctalk wrote:
> I’m sure that would work  but I only have an 8650  110 baud only card
> Rod
> 
> 
> Sent from Mail for Windows 110 baud 
> 
> From: Bob Rosenbloom via cctalk
> Sent: 08 December 2018 03:41
> To: cctalk@classiccmp.org
> Subject: Re: PDP-8/e
> 
> On 12/7/2018 7:01 PM, Pete Turnbull via cctalk wrote:
>> On 07/12/2018 17:44, Jon Elson via cctalk wrote:
>>> On 12/07/2018 11:22 AM, systems_glitch via cctalk wrote:
 Indeed, unless you need character pacing.


>>> Actually, with the correct settings of the serial port (xon/xoff or 
>>> CTS pin) the serial port driver should do this, too, so cat would work.
>>
>> A PDP-8/E doesn't have a CTS pin and the loaders don't support 
>> XON/XOFF, though.
>>
> The PDP-8 needs to control the serial CTS function. This was called 
> reader-run when using a Teletype machine. FOCAL won't load without it.
> You can modify the serial card (mine was an M8655) to support the 
> function. Here's what I did:
> 
> Cleaned up from Aaron Nabil's and Lyle Bickley's write up.
> 
>   Hack the M8655 to support reader-run by mapping it to RS-232 hardware 
> flow control.
> 
> 1. Cut the trace leading from Pin 1 of E54 (a 7400).  This is the input 
> that clears the Reader Run FF when a new character starts to come in.
> 
> 2. Jumper from Pin 1/E54 to Pin 3/E38, a spare gate on a 7400 that we 
> are going to use an inverter.
> 
> 3. Tie Pin 1 and Pin 2 of E38 together, and run them to Pin 20 of E19, 
> the UART.
>      This supplies the signal to the reader-run FF that tells it that 
> it's got an incoming character and to de-assert the reader-run line.
>      Normally this is tied to the current loop receiver, we've just 
> moved it to the UART so any received data will clear the FF.
> 
> 4. Cut a ground traces on 4 of E50, a 1488 RS-232 transmitter. This is 
> what would normally supply the continuously asserted RTS (and DTR) signal.
> 
> 5. Jumper from pin 7 of E39, a 7474 flip-flop to pins 4 of E50. E39 is 
> the "reader-run flip-flop".  Now RTS follows the reader run signal.
> 
> Bob
> 

Re: early PDP-11/45 info sought

[Jay Jaeger via cctalk]

I think I can help some.  I have a PDP-11/45 From U. Wisc. ECE that
claims to be S/N 1525 .

*  I do NOT have an actual wire list, it seems, but I will hunt a bit
more tomorrow or Tuesday.

*  I DO have earlier PDP-11/45 CPU drawings, but no ECO info


Here is what I have for drawings:

B-DD-11/45-0-AJ  Basic Assy (PDP11/45)  5/72  [Not CPU Cards]
   D-CS-5409684-0-1-H 11/45 Console Board 3/72
   B-DD-KB11-A-0-AA 16 Bit Processor  May-72  [NOT CPU HERE]
  B-DD-DL11-0-K
  B-DD-KW11-0-*
  B-DD-BM873-0-F
  B-DD-KT11-C-B
  D-IC-11/45-0-1-H Power System Configuration
  K-WL-7009540-0-2 Wire List (small - only 6 pages)
  B-DD-861-0-L
  B-DD-H7420-0-E
  B-DD-H744-0-R
  B-DD-H745-0-R
  B-DD-H746-0-E
  E-CS-H754-0-1-T
   A-AL-11/45-0-3-B  Accessory List
   D-AR-11/45-0-4-C  (Rack Configurations)
   C-PL-11/45-0-4-D Arrangement Parts List
   B-DD-M9301-0-D

B-DD-KT11-C-B
[NOTE:  Use KT11-C Only with KB11-A & FP11-B,
Use KT11-CD Only with KB11-D & FP11-C]
   [M8107, M8108]


KB11-A Engineering Drawings  [PDP-11/45 CPU]
   KB11-A-0-AA Dated May 72
   [M8100, M8101, M8102, M8103, ROM Control Listings for M8103,
M8104, M8105, M8106, M8109, M8116, M930, M9202]
   NO wire list

(Curiously, I also have KB11-C, 11/70 drawings.)

B-DD-MF11-U-B 16K Core [M8293, G235, G114, H217, M7259 (Parity Control)]
B-DD-MS11-B-B MOS Memory [M8110, G401]
B-DD-MS11-C-B Bipolar Memory [M8110, M8111]
B-DD-MS11-C-C Bipolar Memory (ECO MS11C-3)  Mentions M8120

B-DD-FB11-0-A FP11-B Floating Point Processor  March 72
   [M8114, M8115, M8112, M8812 ROM Control Listings, M8813]

B-TC-FP11-C-6 FP11-C (Print Set MP00038)  December 75
   [M8126, M8127, M8128, M8129]

DEC-11-HFPAA-C-D  FP11 Floating Point Processor Maintenance Manual
DEC-11-FP11C-MM-001 FP11-C Floating Point Processor Maintenance Manual
EK-KT11C-MM-005  KT11-C, CD Memory Management Unit Maintenance Manual
EK-MS11A-MM-006  MS11-A,B,C memory System Maintenance Manual

PDP-11 Systems Course Training Drawings
PDP-11/45, 11/70 Maintenance Course handout book

And some diagnostic listings for the 11/40 and 11/45.

I have not looked through my fiche for ECO info, though I am not
hopeful, but will look tomorrow.  Most of my fiche are too modern.

Let me know what you want me to scan - should be able to get to it later
this week.

JRJ


On 1/27/2019 6:40 PM, Fritz Mueller via cctalk wrote:
> Those reading through the recent "PDP-11/45 RSTS/E boot problem" thread here 
> will know that I've gotten to some corners of my 11/45 CPU now that don't 
> match up with the commonly available engineering drawings.
> 
> My /45 is an early serial number (#152).  So far I've verified hardware 
> differences on at least my M8100 and M8105 cards and spares, relating to 
> parity error abort handling.  I would really like to track down any of the 
> following resources:
> 
> - PDP 11/45 system engineering drawings *earlier* than those currently 
> available on bitsavers (Jun '74)
> 
> - Any PDP 11/45 backplane wire list (what looks to be a wire list in the 
> currently available engineering drawings is actually only a breakdown of the 
> power harness.)
> 
> - PDP 11/45 ECO information, particularly the following:
> 
> M8100  3
> M8103  5
> M8105  5
> M8106  7, 8, 00012, 00012A
> M8110  8
> 
> KB11-A 00015
> 
> Bitsavers seems to have a DEC-O-LOG for M8105, but this does not contain 
> specifics on cuts and jumps for ECO 5, referring only to the associated 
> "kit".  DEC-O-LOGs for the other processor boards are missing.
> 
> If anybody thinks they might have any of this info squirreled away anywhere, 
> I'd really love to find out more about it!
> 
> Parts of the ECO's are pretty easy to figure, just by comparing the state of 
> my existing boards to the '74 drawings.  But other parts not so much...
> 
> thanks much,
>   --FritzM.
> 
> 
> 

Re: Apollo Ethernet EPROM mystery

[Jay Jaeger via cctalk]

My DN3000 has a 3C505 that I got off of eBay in 2012.  It does *not*
have a boot ROM, just the firmware EEPROMS - National NMC27C64N.  Works
fine, if I recall correctly.  I expect I would have tested it as soon as
I got it, and I did an assign an IP address to it.  Unfortunately, my
"lab notes" are eluding me at present -- they may be offsite from a
recent remodel.  But I am almost positive I tested it.

My Apollo manual on the adapter, 009741-00, "Unpacking and Installing
the EtherController-AT" is offsite (5 miles, accessible if needs be).

I just dumped the firmware: U15 and U16.  From looking at the
information online on the 3C505 at Bitsavers, those would be required
even in an Apollo -- but only for the on-board processor - the Apollo
itself would presumably not even be aware of them, so unless the MAME
folks are trying to simulate the processor on the adapter, they would
not need these ROMS.

Still, let me know if you want me to post the firmware onto my Google drive.

I also came across the following in my files, dated in 2012, which
indicates, as another post here pointed out, that the Apollo Boot ROM is
only needed for diskless boot.  That rings true - the manual I cited
above would confirm that, if needs be.

===

-


Installing an Ethernet Controller in an Apollo DN4000
and
Living to Tell About It


April 20, 1992

Mark C. DiVecchio
Silogic Systems
9888 Carroll Center Road Suite 113
San Diego, CA 92126

email   ...!ucsd!celit!silogic!markd
ma...@silogic.uucp

Table of Contents


1.0 Environment. . . . . . . .  4

2.0 3C505. .  4

3.0 Run the Jumper Program . .  4

4.0 Test tcp/ip. . . . . . . .  6

5.0 Shut Down the Node . . . .  6

6.0 Installation of the Ethernet Card. . . . . .  6

7.0 Test the Ethernet Card . .  6

8.0 Boot the Node. . . . . . .  6

9.0 Edit These Files . . . . .  7
9.1 /etc/hosts . . . .  7
9.2 /etc/hosts.equiv .  7
9.3 /etc/networks. . .  8
9.4 /etc/rc. . . . . .  8
9.5 /etc/rc.local. . .  9

10.0 Check Files . . . . . .   10
10.1 /etc/inetd.config . . . . . . . .   10

11.0 Edit /etc/daemons . . .   11

12.0 Reboot the Node . . . .   11

13.0 Check It Out. . . . . .   11

14.0 Edit /etc/hosts files .   12

15.0 Test tcp/ip . . . . . .   13

16.0 tcpst Utility . . . . .   14
16.1 tcpst Options .   14
16.2 tcpst Listing .   14

17.0 Acknowledgements. . . .   17

1.0 Environment

Our shop is running an Apollo Token Ring (ATR) with one DN4000, 2 DN3010
and 2 DN3000.  The DN4000 and two of the DN3010 are running SR10.3.  The
remaining two DN3000 are running SR10.1.

We also have an Ethernet connecting a Sun IPX, a PC running ESIX Unix
4.0.3 and three PC's running NCSA Telnet.

We wanted to install a gateway so that every machine on the ATR could
have access to every machine on the Ethernet.  The ESIX Unix box has all
our modems connected to it.  We were already running tcp/ip over the ATR
and Ethernet separately.  There is no need to boot anything diskless
over Ethernet.

2.0 3C505

Buy a 3Com 3C505 Ethernet card.  This is just a generic off the shelf
card.  I will not have a diskless boot ROM on it.  If you have need to
boot diskless, you will have to buy the card from Apollo.

3.0 Run the Jumper Program

Run /systest/ssr_util/jumpers and set the jumpers on the card.  See
Figure 1.

The jumper program shows two selections for jumper settings.  They are
actually both the same.  Select DIX if you use thick cable, BNC for thin
cable.

This sets up the card with :
DMA Channel 6
I/O Base 300h
Interrupt 10
Memory Address : Unit 0 Address 8

4.0 Test tcp/ip

Make sure that tcp/ip is up and running by pinging each host on the ATR.

% ping m07

PING m07: 56 data bytes
64 bytes from 198.8.6.54: icmp_seq=0. time=17. ms
64 bytes from 198.8.6.54: icmp_seq=1. time=10. ms
64 bytes from 198.8.6.54: icmp_seq=2. time=11. ms

m07 PING Statistics
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 10/12/17

5.0 Shut Down the Node

Shut down the node and turn off the power.  Put the service/normal
switch into the service position.

6.0 Installation of the Ethernet Card

Install the card into any slot. Power on the node.

I did not find it necessary to tell CONFIG that I have installed the
3C505.  If you do run CONFIG, set up the machine to have two network
controllers, the Ring and the Ethernet card.  Select the Ring as the
primary network.  When I did this, the boot diagnostics had trouble
finding the card even though everything worked fine.  Try whatever
works.

I decided not to tell CONFIG about the card so the machine would still
automatically boot.  I had no problems with this.

7.0 Test the Ethernet Card

Press RETURN a few times until you get the '>' MD prompt.  Type RE and
RETURN a few 

Re: IBM 360 Model 50 information?

[Jay Jaeger via cctalk]

On 3/31/2019 4:08 PM, Noel Chiappa via cctalk wrote:
> > From: William Donzelli
> 
> > It is very likely IBM does not have the information anymore - at least
> > not in the archives. ... they simply did not keep much from that era.
> > It was probably disposed of back when IBM was in trouble 30 years ago.
> 
> Which emphasizes that it's important to make the point to IBM that we
> wouldn't be asking for IBM to supply the information; rather, this is about
> being able to reproduce info that IBM itself may no longer have.
> 

Been there, done that.  Came to a dead end after about a year of emails
and even a phone call or two.

> Is anyone up for tackling IBM? If so, and we need support, I can ask my
> Master, Jerry Saltzer, if anyone he knew at IBM is still there - he used to
> have a lot of influence inside IBM (he's the person who got FS killed, I was
> informed). But that was a long time ago...
> 
> > From: Jay Jaeger
> 
> > I suspect, but do not know of course, that the reasons that the owners
> > would not part with their copies was ... concern over their value
> > becoming diminished by having scanned copies around.
> 
> One easy way to test that is to have Al ask the person with the ALD's if
> they'd be OK with having that stuff scanned if we got an OK from IBM.
> 
>   Noel
> 

Based on my experience, they will not ever give such an OK.

Re: Yes there is a PDP 10 front panel and Kenbak on Ebay

[Jay Jaeger via cctalk]

On 4/4/2019 9:33 AM, Noel Chiappa via cctalk wrote:
> > From: Al Kossow
> 
> > because it's $125 lower than the last one that sold.
> > https://www.ebay.com/itm/113190860596
> 
> Wow - somebody got a real deal! Looks like the seller listed it as
> a BiN with a low (for what it was) price; bet they're kicking themselves
> now, seeing what this one is going for, that they didn't go the auction
> route.
> 
>   Noel
> 

These are very different.  That older one was really just a case - it
had no lights, perhaps no actual switches (I am guessing not), and
certainly no circuit boards.  This one has that stuff (and I see that
the price has gotten to an amount I once bid on a CDC-160 [and lost.]

JRJ

Re: IBM 360 Model 50 information?

[Jay Jaeger via cctalk]

On 3/30/2019 12:35 PM, Noel Chiappa via cctalk wrote:
> > From: Al Kossow
> 
> > Decades later, people are still afraid to release them. I tried to get
> > 2065 ALDs from someone that had them and they wouldn't give them to me.
> 
> Sounds like it's time to have someone high up at the CHM talk to someone
> at IBM to get an OK; if you only ask for permission, not for IBM to cough
> up the info themselves, that might be doable.
> 
> I'd try and get a blanket OK for anything more than 20 years old, i) that
> should be long enough that they'd be OK with it, ii) a moving thing like
> that would mean you wouldn't have to go back again.
> 
>   Noel
> 

My experience with IBM legal (who were actually quite communicative when
I approached them) on that front with IBM 1410 manuals suggests to me
that they will not ever give explicit permission, because nobody at IBM
will ever by confident that they won't end up giving away some trade
secret or other.  Even when they know the risk is nonexistant, it isn't
possible to get anyone to sign off on it.  So instead we (meaning the
collective community) are left with a situation where IBM's failure to
send a cease and desist letter of some sort becomes a kind of tacit
permission.

I suspect, but do not know of course, that the reasons that the owners
would not part with their copies was concern over losing them or concern
over their value becoming diminished by having scanned copies around.

JRJ

Re: H786 power supply help wanted

[Jay Jaeger via cctalk]

On 3/30/2019 2:25 PM, Charles via cctalk wrote:

> I have a PDP-11/23+ and the power supply (H786) "last ran when parked" a
> year or so ago. But there's no DC output at all today, and the fans are
> running so there is AC power...
> I also have the original H7861 that came with it, which had a blown
> chopper transistor. I couldn't find anything else bad, so I replaced the
> transistor and within a few seconds of running, it blew again. :(
> 
> So I need some help - I've never been good at fixing switching supplies,
> not to mention the high-side hazards.
> The simplest solution would be just to replace it with a working unit.
> Anyone got one to sell, hopefully cheap? :)
> If not, can anyone fix one or both of mine?
> 
> thanks!
> Charles
> 

Sorry, no spares (and certainly no tested spares.  ;) ).

My playbook for these sorts of things goes like this.  Others will
undoubtedly chime in with probably better advice.

1.  Is anything obviously burned / overheated / fuses blow?  Note those,
and what feeds them.

2.  Check the semiconductors - often I will lift one leg of a diode
or two legs of a transistor to make sure I get a good test.
It's a pain, but usually worth it.  Sometimes, depending on
what the schematic looks like, I'll test without lifting as many
/ any legs.

3.  Specialized regulators / op-amps, etc., require checking their
voltage while running.  Not usually easy to test them.

4.  Check the capacitors, especially input and output for excessive
leakage.  I often will reform input and output caps just
because.   Check their ESR, at least with one of the
cheap component testers out there.

I use one of these for testing, as well as an ohmmeter, etc.

https://www.ebay.com/itm/All-in-1-LCR-Component-Tester-Transistor-Diode-CapacitanceESR-Meter-InductanceBH/183706764001

I also use a "Blue ESR Meter" of late, as well:

https://anatekinstruments.com/products/anatek-blue-esr-meter-full-kit-for-self-assembly-besr_kit

But before I had these, I just used an ohmmeter to test each
semiconductor junction, and monitored voltage while reforming capacitors
to get an idea of their ESR.

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

On 2/18/2019 3:38 PM, Paul Koning via cctalk wrote:
> 
> 
>> On Feb 18, 2019, at 4:16 PM, Fred Cisin via cctalk  
>> wrote:
>>
>> On Mon, 18 Feb 2019, Liam Proven via cctalk wrote:
>>> Well that is the thing, of course. I had that with one old IDE disk,
>>> too. It made a terrible ear-piercing high whine that I associate with
>>> a failing disk... but it passed every diagnostic I could throw at it,
>>> so I used it for non-critical stuff and in testbed machines.
>>
>> One of the moxt common causes of a terrible ear-piercing high whine is the 
>> spindle contact.  Many old drives had a springy piece that rubbed against 
>> the end of the spindle.  
> 
> Then again, I remember our college RS64 (drive for the RC11) which developed 
> a bad motor bearing.  Since the platter is mounted directly on the motor 
> spindle that was a problem.  And it was not under contract, so replacing the 
> motor would have set back the department a substantial sum.  So the DEC FS 
> engineer removed the motor and carried it to Appleton Electric Motor Co., 
> which pulled the old bearing, pressed on a replacement, and handed it back.  
> Jim reinstalled the motor, all was well.  Didn't even lose any data bits.
> 
>   paul
> 

Nice of the FE to do that.

The Univ. of Wisconsin CS Department had one of those, but the platter
went bad.  They just flipped the platter upside down and got more use
out of it.

The Univ. of Wisconsin ECE Department also had one - the two machines
were nearly twins.  I *have* *that* one - and it still ran when I tried
it a year or so ago.

Re: IBM 3174 C 6.4 Microcode Disks?

[Jay Jaeger via cctalk]

On 2/15/2019 10:22 AM, Jay Jaeger via cctech wrote:
> On 2/14/2019 9:28 PM, Kevin Monceaux via cctalk wrote:
>> Classic Computer Fans,
>>
>> I posted this to the IBM-Legacy-Hercules mailing list.  I just realized it
>> probably wouldn't hurt to post it here too.
>>
>> I'm finally in possession of a box that hopefully is capable or can be made
>> capable of connecting a real terminal to Hercules.  It's a 3174 11L.  It was
>> retired last year where I work.  I finally got the okay to save it from
>> being sent to a scrapper.  I love the build quality of older IBM gear,
>> except when I'm trying to move such gear.  Between the 3174 and a 9406-520 I
>> also acquired, I pulled or strained something in my left arm moving them
>> into place.
>>
>> It's currently wired to run on 220v.  I think I've seen mentioned somewhere
>> that it can be changed to run on 110v.  If that's the case, does anyone have
>> a pointer to documentation on what's involved?
>>
>> It has dual floppy drives.  At least one drive is a 2.4MB drive.  But, all
>> the microcode disks I have are at level B 4.6.  Does anyone know where I can
>> get a set of C 6.4 control and control extension disks.  From what I've
>> heard those are what's needed to enable an attached terminal to connect to
>> other systems via telnet.
>>
>> It has a token ring card.  I will probably be able to get the MAU it was
>> connected to, and possibly the router that acted as a token ring to Ethernet
>> bridge.
>>
>> I'm not sure how much memory it has.  Does anyone have any tips on
>> determining the amount of memory it has, and/or identifying its boards?
>> These are the numbers on its boards:
>>
>> 9210
>> 9351
>> 9052 z2
>> 9053
>> 9501
>>
>> Plus the boards for coax connections.
>>
>>
>>
> 
> I have some 3174 floppy disks, but I don't know what - they are not in
> my inventory.  I will put it on my queue to look at them - but it may be
> a couple of weeks.  I don't hold out much hope, but I will look.
> 

Well, it turns out my floppies are for *3274* rather than 3174.  But,
that said, if anyone needs any of them, let me know: just shipping cost.

Here is a sample:

3274 Disks
IBM Diskette 2 256 Bytes/Sector


DateName

8/09/83 A13 FEAT DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30
8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30
[Customized]
8/10/83 A23 SYST DISK CONFIG SUPPORT D REL 60.0 VALIDATION NUMBER 30
[Customized]
6/18/84 A22 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33
6/30/84 A12 FEAT DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33
6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33
6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33
6/30/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33
7/01/84 A22 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR
HIGHER
7/01/84 A12 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR
HIGHER
7/12/84 A23 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33
7/12/84 A22 SYST DISK CONFIG SUPPORT D REL 63.0 VALIDATION NUMBER 33
7/18/84 A23 LANGUAGE DISKETTE - RELEASE C FOR CONFIG D AT REL 63.0 OR
HIGHER
6/11/85 B22 18.33 LANGUAGE DISKETTE FOR CONFIG D AT REL 64.0 OR HIGHER
6/11/85 A12 21.30 SYSTEM - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR
HIGHER
6/18/85 A12 19.40 FEATURE - CONFIG SUPPORT D REL 64.1 VALIDATION 34 OR
HIGHER
6/24/86 B23 17.17 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER
6/24/86 B12 17.08 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER
6/24/86 B12 17.05 LANGUAGE DISKETTE FOR CONFIG D AT REL 65.0 OR HIGHER

--- KYB DEF UTILILTY REL G FOR LOAD 3290 D41.00, 3179-G D25.00 OR
HIGHER


(And about 150 more, in a similar date range)

Re: BASIC for HP 1000, 21xx series

[Jay Jaeger via cctalk]

I have completed my survey of my HP tapes.  There is quite a lot of
overlap with Jeff Moffat, but some of mine appear to be different than
any up on bitsavers.

In general, the paper tapes for these systems on bitsavers can be found at:

http://bitsavers.org/bits/HP/paperTapes/

MY tapes are *** NOT *** there (at least not yet - unless/until Al
decides to copy them up now.  ;))

Mine (along with a PDF describing what they are) can be found at:


https://drive.google.com/open?id=0B2v4WRwISEQRWWFFdVpCZWFTZEU

under:

bits/HP/paperTapes/JayJ


As I mentioned yesterday, I have not tried any of these tapes, aside
from few diagnostics - not even under SimH.

But they were imaged from HP original tapes I got when I procured my HP
2114, and I am guessing fit the descriptions in "A Pocket Guide to
Hewlett-Packard Computers" which I bought for a course (U. Wisc. CS 436)
that used an HP 2114 paper tape system back in the day.  Today I
translated a couple of C programs that I had written back in 1996 to
check my images (absolute binary and relocatable) and verified these
images with a perl version of those programs.

The following manual, on bitsavers, should be pretty close, but I didn't
see, for example, the assembler operating instructions in there.

http://bitsavers.org/pdf/hp/21xx/5951-4423_A_Pocket_Guide_To_The_2100_Computer_Sep72.pdf

I have software (and hardware) manuals for my system, but have not
scanned them in.  Maybe someday, but probably not soon.


The operating procedures for BASIC are likely to be as described in my
pocket handbook:

0.  Make sure the binary loader is loaded starting at address 017700.
These systems have a way to protect that loader, which is really nice.

1.  Place the BASIC binary tape in the tape reader
2.  Set the switch register to 017700
3.  Load Address
4.  Set Loader switch to Enabled (HP 2114 Loader Enable to On)
5.  PRESET
6.  RUN
7.  At halt, the T Register should contain 202077
7b.  Set the loader swich to PROTECTED (HP 2114 Loader enable to NORMAL)
8.  Set the Switch register to the startin address:  000100
9.  Load Address
10.  Run

It should respond with "READY".


On 2/24/2019 11:11 PM, Jay Jaeger via cctech wrote:
> I have a set of actual HP paper tapes I acquired with my HP 2114B a
> number of year ago, including BASIC, FORTRAN and ALGOL.  I'd have to
> look at the manuals to find out if/which required DOS.  I have not run
> any of these images except for some of the diagnostics.
> 
> I seem to recall that at least one of the tapes had problems, but I
> don't remember which one.   I'll have to look at my notes / files tomorrow.
> 
> I found what I *think* are the files and also some from Jeff Moffat
> (http://rikers.org/hp2100/jeff/) - those I'd prefer you got from him.
> 
> Here are mine, and I will upload them tomorrow.
> 
> JRJ
> 
> 
> KIND  ID  MACHINE CONTENTSCOMMENT ChecksumChecksum 2  
> FILENAMEMFG
> SERIALTRAYDATEAVAILABILI  ERRORS  PREVIOUS_C
> 
> PTHP 2114BDiagnostic Config   
> HP  HP6 
> 
> PT2-60001 HP 2114BInput Output Control Rev. A 
> HP  HP1 
> 
> PT20002-60001 HP 2114BBCS Debug Routine Rev. B
> HP  HP1 
> 
> PT20005-60001 HP 2114BBCS Tape Reader Drvr D.01 Rev. A
> HP  HP1   
>   
> 
> PT20017-60001 HP 2114BBCS TTY Drvr D.00 Rev. B
> HP  HP1 
> 
> PT20018-60001 HP 2114BBCS Relocating Loader Rev. E
> HP  HP1 
> 
> PT20021-60001 HP 2114BPrepare Control System Rev. B   
> HP  HP1 
> 
> PT20100-60001 HP 2114BSymbolic Editor Rev. B  
> HP  HP1 
> 
> PT20306-60001 HP 2114B8K SIO Tape Rdr Drvr Rev. A 
> HP  HP1 
> 
> PT20313-60001 HP 2114B8K SIO Sys Dump Rev. B  
> HP  HP2 
> 
> PT20392-60001 HP 2114BBASIC Rev. A
> HP  HP2 
> 
> PT20392-60002 HP 2114BPrepare BASIC System Rev. A 
> HP  HP2 
> 
> PT20512-60001 HP 2114B2115/14 High Mem Checkbd Test Rev. A
> HP  

Re: PDP-11/60 manuals needed

[Jay Jaeger via cctalk]

On 2/27/2019 1:37 PM, Noel Chiappa via cctalk wrote:
> Hi, does anyone have any PDP-11/60 manuals? I went to do articles on the
> -11/60 and its CPU (KD11-K), but there isn't much online.
> 
> Bitsavers has EK-KD11K-TD-PRE, but it only covers the maintenance features,
> not the whole CPU; there is a tech manual - KD11K-TM-001 (I have it in fiche,
> but my fiche reader has a burned out bulb which I have not yet been able to
> replace, so it doesn't do me much good). There is a user manual for the
> FP11-E, which has a certain amount of useful details, but it refers to the
> technical manual, which is not there. And there's EK-11060-SV-01, which covers
> the cabinet and power supply.
> 
> So if anyone has the general -11/60 manual, or the KD11-K tech manual, those
> would be super useful. The FP11-E tech manual would be nice to have, but isn't
> as important as the others.
> 
> Thanks (I hope!)!
> 
>Noel
> 

I have EK-11060-OP-003: "PDP-11/60 installation and operation manual"
and an update EK-11060-OP-C1.

Of course this is not the real technical manual that explains the
processor in detail, but it has the self-test error halts, boot
procedure, etc., which I expect would be handy.

I don't see this manual on bitsavers, so let me know and I will scan it
in and stick it on my Google drive in a day or two or three where you
and Al could snag the scan.

I also have a spare processor handbook, EB-06498-20/77, but it is in a
box in the garage, so I'd rather wait a week or two for warmer weather
to dig it out.  

JRJ

Re: BASIC for HP 1000, 21xx series

[Jay Jaeger via cctalk]

I have a set of actual HP paper tapes I acquired with my HP 2114B a
number of year ago, including BASIC, FORTRAN and ALGOL.  I'd have to
look at the manuals to find out if/which required DOS.  I have not run
any of these images except for some of the diagnostics.

I seem to recall that at least one of the tapes had problems, but I
don't remember which one.   I'll have to look at my notes / files tomorrow.

I found what I *think* are the files and also some from Jeff Moffat
(http://rikers.org/hp2100/jeff/) - those I'd prefer you got from him.

Here are mine, and I will upload them tomorrow.

JRJ


KINDID  MACHINE CONTENTSCOMMENT ChecksumChecksum 2  
FILENAMEMFG
SERIAL  TRAYDATEAVAILABILI  ERRORS  PREVIOUS_C

PT  HP 2114BDiagnostic Config   
HP  HP6 

PT  2-60001 HP 2114BInput Output Control Rev. A 
HP  HP1 

PT  20002-60001 HP 2114BBCS Debug Routine Rev. B
HP  HP1 

PT  20005-60001 HP 2114BBCS Tape Reader Drvr D.01 Rev. A
HP  HP1 

PT  20017-60001 HP 2114BBCS TTY Drvr D.00 Rev. B
HP  HP1 

PT  20018-60001 HP 2114BBCS Relocating Loader Rev. E
HP  HP1 

PT  20021-60001 HP 2114BPrepare Control System Rev. B   
HP  HP1 

PT  20100-60001 HP 2114BSymbolic Editor Rev. B  
HP  HP1 

PT  20306-60001 HP 2114B8K SIO Tape Rdr Drvr Rev. A 
HP  HP1 

PT  20313-60001 HP 2114B8K SIO Sys Dump Rev. B  
HP  HP2 

PT  20392-60001 HP 2114BBASIC Rev. A
HP  HP2 

PT  20392-60002 HP 2114BPrepare BASIC System Rev. A 
HP  HP2 

PT  20512-60001 HP 2114B2115/14 High Mem Checkbd Test Rev. A
HP  HP2 

PT  20524-60001 HP 2114B2114B DMA Gen. Diag. Rev. A 
HP  HP2 

PT  20548-60001 HP 2114BFTN Compiler Pass 1 Rev. A  
HP  HP2 

PT  20548-60002 HP 2114BFTN Compiler Pass 2 Rev. A  
HP  HP2 

PT  20985-60001 HP 2114BDOS TTY Drvr (DVROO) Rev A  
HP  HP2 

PT  20987-60001 HP 2114BDOS PUN Tape Rdr Drvr (DVR01) Rev A 
HP  HP3 

PT  24031-60001 HP 2114BEXT. Assembler Non Eau Rev. A   
HP  HP3 

PT  24044-60001 HP 2114BALGOL Compiler Rev. A   
HP  HP3 

PT  24109-60001 HP 2114BCross-Ref Symb Table Gen Rev. A 
HP  HP3 

PT  24125-60001 HP 2114B8K SIO TTY Drvr (LP-Compat) Rev A   
HP  HP3 

PT  24146-60001 HP 2114BBCS Relocatable Library
(Non-EAU) Rev A HP  HP3 

PT  24149-60001 HP 2114BBCS FORTRAN IV Library Rev A
HP  HP3 

PT  24150-60001 HP 2114BRTE/DOS Reloc. Library (Non
EAU) Rev B  HP  HP4 


PT  24152-60001 HP 2114BRTE/DOS FORTRAN IV Library Rev A
HP  HP4 

PT  24153-60001 HP 2114BRTE/DOS HP FORTRAN Formatter Rev A  
HP  HP4 

PT  24154-60001 HP 2114B  

Re: Need some PDP-11 paper tapes

[Jay Jaeger via cctalk]

On 3/4/2019 3:56 PM, ED SHARPE via cctalk wrote:
> I  would  love to have  focal 11 on paper  tape  too if  anyone can punch one 
> up!  thx  ed#
> 

I have FOCAL-GT on paper tape - but no duplicates.  I'd expect that is
for a GT-11.


All of the other FOCAL tapes I have are for 8's/12's.

Re: PDP-11/60 manuals needed

[Jay Jaeger via cctalk]

The PDP-11/60 manuals described below have been scanned, and are
available on my Google Drive using this link:

https://drive.google.com/open?id=0B2v4WRwISEQRWWFFdVpCZWFTZEU

Under ./pdf/dec/1160

Enjoy.



On 2/28/2019 1:19 PM, Noel Chiappa via cctech wrote:
> > From: Jay Jaeger
> 
> > I have EK-11060-OP-003: "PDP-11/60 installation and operation manual"
> > and an update EK-11060-OP-C1.
> 
> Yeah, that's the one I referred to as "the general -11/60 manual"; generally,
> there's one such for all the -11 models, but the exact name varies from model
> to model (unlike, say, the CPU tech manuals, the name for which is pretty
> predictable).
> 
> > let me know and I will scan it in and stick it on my Google drive in a
> > day or two or three
> 
> That would be great; thanks very much! No rush at all...
> 
> > I also have a spare processor handbook, EB-06498-20/77
> 
> We do have that one, thanks.
> 
> BTW, looking a little more closely at the cabinet/power-supply manual
> (pg. 1-7), the KD11-K TM might _only_ be available on fiche. If so, that'll be
> the first time I've ever seen that. Oddly enough, further down the page, the
> FP11-E TM seems to be available in printed form (EK-FP11E-TM).
> 
> 
> > From: Ethan Dicks 
> 
> > I've seen Tech Manuals printed as 2-up on C-sized paper
> 
> Yeah, generally things from the -11/20 era are like that (e.g. the RK11-C
> manual). Nothing later than that that I've ever seen, though.
> 
> >>> I have the two BA11 cabinets for an 11/60, the PSUs, and the front
> >>> panel (I'm missing the rack).
> 
> > "the rack" is just the outer box with rails (not an H960 - whatever the
> > designation is for the odd 11/60 cabinet).
> 
> I think it's the H9500 low-boy corporate cabinet, per Chapter 5 in
> the cabinet/power manual.
> 
> > The backplanes are in the BA11s. I seem to have both MOS and core
> > memory and, I am fairly sure, an RK611, along with the CPU. I need to
> > take a module inventory.
> 
> You seem to have most of the crucial bits, although you might be missing
> the power harness.
> 
> Do you have the optional WCS module (M7870)? There are also ROM modules, and
> a diagnostic module, that can go in that slot - only one of the three at a
> time, though.
> 
>   Noel
> 

Re: Need some PDP-11 paper tapes

[Jay Jaeger via cctalk]

On 3/1/2019 12:50 PM, Rich Gopstein via cctalk wrote:
> I just picked up a Remex paper tape reader from eBay and will be
> interfacing it to my PiDP-11/Simh PDP-11 simulator shortly.
> 
> I've been looking for an affordable punch, but haven't found one yet.  In
> the meantime, does anyone know where I could get paper tapes with the
> absolute loader and standalone basic?
> 
> I don't need originals, so if anyone has a punch and is willing to punch
> them for me, that would be great!  I'd be happy to pay whatever is
> reasonable.  If you have any other PDP-11 tapes too, that would be helpful.
> 
> Thanks.
> 
> Rich
> 

I have some duplicates of what you have asked for, so I could probably
accommodate you.  But not all that many, so they aren't free.   I
*believe* (but would have to double check) that these are all actual
Digital paper tapes I got with various machines, which increases the price.

I'd be willing to let them go for $20 each: feel free to pick and
choose.  If I have any that are just copies and not originals, those I
would let go for $5 each.  Plus shipping (they ought to all fit in one
small flat-rate box, assuming you are in the US).

If others can punch copies for you, so much the better.  (I have punches
that worked when I first got them, but they need work.  Same goes for my
readers, unfortunately).

Some of the items below (PAL, EDT, LINK) might be pretty useless without
a paper tape punch.  ;)

I have a few others (IOX).  I have FPP (floating point package) - but no
duplicates.

See
http://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/DEC-11-XPTSA-B-D%20PDP-11%20Paper%20Tape%20Software%20Handbook.pdf

(Surprised that wasn't on the CHM bitsavers site...)

JRJ



KINDID  MACHINE CONTENTSCOMMENT ChecksumChecksum 2  
FILENAMEMFG
SERIAL  TRAYDATEAVAILABILI  ERRORS  PREVIOUS_C


BASIC V007A

PT  DEC-11-AJPB-PB  PDP-11  PDP-11 BASIC V007A  SA=16104 RA=0   

Digital 55  11/5/1970   


BASIC V008A

PT  DEC-11-LBSUA-A-PB   PDP-11  BASIC.LDA V008A SINGLE USER BASIC
REPLACES: DEC-11-AJPB-PBDigital 44  
12/1/1972   



Absolute loader

PT  DEC-11-UABLA-A-PO   PDP-11  PDP-11 ABSOLUTE LOADER  REPLACES:
DEC-11-L2PC-P0  uabla-a.rim Digital 62  
5/5/1977


Absolute loader (no switch register)

PT  DEC-11-UABLB-A-PO   PDP-11  ABSOLUTE LOADER VB07.00 NON-SWITCH
REGISTER VERSIONDigital 36  
12/5/1975   



PAL-11A V007A

PT  DEC-11-UPLAA-A-PB   PDP-11  PAL-11A.LDA V007A   REPLACES: 
DEC-11-ASXB-PB
SA=1516 RA=1516 Digital 39  11/3/1975   


PAL-11S V003A

PT  DEC-11-UPLSA-A-PL   PDP-11  PAL-11S.LDA V003A   REPLACES: 
DEC-11-ASQA-PL
SA=2066 RA=2066 Digital 42  12/1/1972   




EDIT-11 V005A

PT  DEC-11-UEDPA-A-PB   PDP-11  ED-11 V005A REPLACES: 
DEC-11-E1PA-PB
Digital 39  11/10/1975  



LINK-11S  V002A  (SA 22714)

PT  DEC-11-ULKSA-A-PL   PDP-11  LINK-11S.LDA V002A  REPLACES:
DEC-11-ZLQA-PL  Digital 41  12/1/1972   




ODT-11  V005A

PT  DEC-11-UODPA-A-PB   PDP-11  ODT-11.LDA V005A RE-ENTER=13032 
REPLACES:
DEC-11-O1PA-PB SA=13026 RA=.30  Digital 44  
12/1/1972   


DUMPTT  V001A

PT  DEC-11-Y1PA-PB  PDP-11  DUMPTT V001ASA=LOAD ADDRESS RA=LOAD
ADDRESS Digital 43  11/10/1969  


DUMPAB V001A

PT  DEC-11-Y2PA-PO  PDP-11  DUMPAB V001ASA=XX7500 RA=XX7500 

Digital 44  11/10/1969  

Re: IBM 3174 C 6.4 Microcode Disks?

[Jay Jaeger via cctalk]

Al, that was actually a quote from a message I wrote - I am the one with
the 3274 floppies.

Let me know what you are looking for.

I am not at all familiar with what makes a "set", though I suppose I
could just send the latest version I can find with each of the different
sorts (SYST - which I took to be System, FEAT which I could to be
Feature, and LANGUAGE that match your model.

I found this in the IBM announcement letter:

"One Feature Diskette and two System Diskettes are shipped with each 3274.

For Models 31A, 31C, 31D, or 51C that are upgraded to Configuration
Support D, a Language Diskette is also shipped. "

If your 3274 does not have configuration support D, these might not
work?   Or maybe it was just a matter of needing to install the right
Configuration support for the attached devices? I dunno (shrugs shoulders).

Looking at the manuals on bitsavers, none of them mention this higher
level of configuration support.  I did find mention of it in an IBM
announcement letter online, at

https://www.argecy.com/3274

And it says this:

"Configuration Support D (#9124): (Models 31A, 31C, 31D, 51C) Provides
support for all 3270 functions included in Configuration Support C plus
support for:"

And

"Configuration Support: The Configuration support required for the 3274
must be determined before ordering special features or attaching certain
terminals. Refer to the 3274 Control Storage Requirements Tables under
"Special Feature" Extended Function Store (EFS) for a detailed listing
of the functions supports by each option. Field Installation: Yes.
(Configuration Support D #9124 is field installation only for Models
31A, 31C, and 31D.) Customer Setup: Yes. Limitations: Certain functions
require host software support in order to be utilized. Refer to host
programming support descriptions to determine the levels of software
required."

So, unless yours is a 31A, 31C, 31D or 51C maybe these won't work?

Let me know.

JRJ

On 2/20/2019 12:42 PM, Al Kossow via cctalk wrote:
> 
> 
> On 2/19/19 7:39 PM, Jim Stefanik via cctalk wrote:
> 
>> Well, it turns out my floppies are for *3274* rather than 3174.  But, 
>> that said, if anyone needs any of them, let me know: just shipping cost. 
> 
> I can use them. I ended up with one w/o media
> 
> 
> 

Re: Thinking about PDP11 PC05 Emulation

[Jay Jaeger via cctalk]

On 3/11/2019 4:37 PM, allison via cctech wrote:
> On 03/11/2019 02:11 PM, Jay Jaeger via cctech wrote:
>> I have several PDP-11's in my collection (among other things), and not
>> enough PC05 tape readers (or enough room) to go around.  But most if not
>> all of my machines have M7810 PC11 interfaces, and I have one I could
>> move from machine to machine as needed.  Moving a PC05 around would be a
>> lot more work, and not every rack has room.  ;)
>>
>> So, I took a look at what it might take to interface with an M7810 (or,
>> down the road, a PDP-8/L or PDP-12.  It looks like the emulator would
>> have to accept as input just 3 lines (Initialize  L, IOP2(1)/Select,
>> IOP4(1)/Read) [It would not need the redundant Initialize H, IOP1(1),
>> Qualify or Skip], and would have to drive 11 lines into the pullups on
>> the M7810 (8 Data lines, IO Bus INT L/Reader Done L, Outtape/Error and
>> RDR RUN L/RDR Busy L).
>>
>> So, a total of 14 interface lines. (The 8 or 12 would take a few more
>> lines).
>>
>> The pullups average about 470 ohms (1 is 1K, 1 is 220, the rest are
>> 470), so at 5V the output has to sink a bit over 10ma, and all total
>> 120ma.
>>
>> An Arduino Uno with an Ethernet shield would have 20 minus 5 lines
>> available, in theory, but if one wants serial I/O as well for debugging,
>> that sucks up 2 more lines - so only 13 available.  And sinking 120ma
>> would be a bit much though I could likely sprinkle inputs among the
>> outputs to make it work so as to stay within the recommended sink
>> limits, and at least initially have it never run out of tape, and tie
>> Error down.
>>
>> http://playground.arduino.cc/Main/ArduinoPinCurrentLimitations
>>
>> So, I am thinking about an Arduino Mega, as it has more output groupings
>> to sprinkle the sink current around, and 5V interface capability, and
>> more pins to eventually support my PDP-8/L and PDP-12.
>>
>> (I could do it with a PIC - did that for a Documation card reader to PC
>> interface, but I am really tired of fighting Microchip's IDE.)
>>
>> BUT - it also occurs to me someone may have already done something like
>> this?  Any leads / ideas?
>>
>> JRJ
> The Uno or Nano is more than adequate.
> 
> To do the data you need 8 bits but you can bit bang them out using two
> lines on a nano to
> a 74ls164.  The rest you use transistors (open collector) to do high
> current (though 5V,
> 1K pullup is only 5ma) and I'd do that to make the IO more rugged and
> ESD proof.  That
> covers the strobes and control lines.  Just using two lines to get the 8
> data lines via a 164
> frees enogh pins for there to be surplus IO lines.
> 
> Then I can load the Uno (or nano) via USB or Serial  or use 4lines to
> interface a
> uSD loaded with tapes ( MCLK, MSI, MSO). 
> 
> With 32K of program space the RIM and BIN load can be part of the
> standard code base.
> 
> Then a library and software tool to load up the uSD or SD as usb to
> SD/uSD socket adapters
> are common.  It would be great to be able to get a file with all the
> common tapes on it.
> for loading into a 8 via a loader device.
> 
> I've not done this for PDP-8 or 11 but I can easily envision it.  The
> Arduinos are
> often fast enough if not faster than the host so speed is not an issue.
> 
> Allison
> 

My plan is actually to use an Arduino Ethernet shield to load files
(which uses 4 pins off of the Uno).

As I believe I mentioned, I can stay within the Uno's or Mega's current
sink limits by sprinkling outputs and inputs together in the various I/O
banks.  But unless I add additional hardware as you suggested, I am
short an I/O pin unless I punt on out of tape (and have it never report
that condition).

I am trying to avoid having to add additional hardware, even
transistors, if I can, as that makes it easier to replicate for others.

JRJ

Re: Thinking about PDP11 PC05 Emulation

[Jay Jaeger via cctalk]

On 3/11/2019 5:15 PM, Brent Hilpert via cctalk wrote:
> On 2019-Mar-11, at 2:37 PM, allison via cctech wrote:
>> On 03/11/2019 02:11 PM, Jay Jaeger via cctech wrote:
>>> I have several PDP-11's in my collection (among other things), and not
>>> enough PC05 tape readers (or enough room) to go around.  But most if not
>>> all of my machines have M7810 PC11 interfaces, and I have one I could
>>> move from machine to machine as needed.  Moving a PC05 around would be a
>>> lot more work, and not every rack has room.  ;)
>>>
>>> So, I took a look at what it might take to interface with an M7810 (or,
>>> down the road, a PDP-8/L or PDP-12.  It looks like the emulator would
>>> have to accept as input just 3 lines (Initialize  L, IOP2(1)/Select,
>>> IOP4(1)/Read) [It would not need the redundant Initialize H, IOP1(1),
>>> Qualify or Skip], and would have to drive 11 lines into the pullups on
>>> the M7810 (8 Data lines, IO Bus INT L/Reader Done L, Outtape/Error and
>>> RDR RUN L/RDR Busy L).
>>>
>>> So, a total of 14 interface lines. (The 8 or 12 would take a few more
>>> lines).
> 
> . . . 
> 
>>> BUT - it also occurs to me someone may have already done something like
>>> this?  Any leads / ideas?
> 
> . . .
>> To do the data you need 8 bits but you can bit bang them out using two
>> lines on a nano to
>> a 74ls164.  The rest you use transistors (open collector) to do high
>> current (though 5V,
>> 1K pullup is only 5ma) and I'd do that to make the IO more rugged and
>> ESD proof.  That
>> covers the strobes and control lines.  Just using two lines to get the 8
>> data lines via a 164
>> frees enogh pins for there to be surplus IO lines.
> 
> . . .
> 
> I've used an RPi for tasks like this in much the same way as Allison is 
> describing -
> reduce the number of I/O pins needed on the modern microcontroller by 
> serialising
> the legacy-device parallel data lines with a simple TTL shift register.
> 2-4 pins (CLK,LATCH,DIN,DOUT, depending on app) from the microcontroller
> can be translated to 8,16,32 or as many data lines as you need.
> 
> 

I had thought about an RPi as well.  But the RPi is it is 3.3v,
requiring additional hardware, which I'd like to avoid.  A 5V Arduino
(or a PIC, for that matter) should be able to drive the interface card's
inputs on its own.

Re: 1983 UBC PDP-11 Unix tools distribution

[Jay Jaeger via cctalk]

I have a tape with the label

"UNIX USERS GRUOP NEW RELEASE TAPE"
"091377"

(That last part is almost certainly the date).

The tape is in tp format.  I don't see anything that looks to match in
the bitsavers archive.

Al, shall I upload the image for you to snag?

JRJ

On 3/7/2019 12:08 PM, Al Kossow via cctalk wrote:
> 
> 
> On 3/7/19 7:28 AM, Warner Losh wrote:
>>
>>
>> Makes me wonder if there are other must have tapes from back in the day that 
>> we may or may
>> not have copies of...
>>
> 
> I'm sure there are.
> Usenix threw out the copies of their tapes that were given back to them to 
> preserve.
> 
> 
> 

Re: Fujitsi 2444AC 9-track tape drive/PDP-11

[Jay Jaeger via cctalk]

On 3/20/2019 9:56 AM, Jon Elson via cctalk wrote:
> On 03/19/2019 09:51 PM, W2HX via cctalk wrote:
>> The pertec-to-SD project sounds very cool. Keep me in mind if you need
>> testers/buyers.
>>
>>
> Yes, me too!  I still have a working 92185 (Keystone) drive, and could
> be interested if your design is not too expensive.
> 
> Thanks,
> 
> Jon
> 

Me Three.  I have a couple of Pertec drives.

Re: Opening old DEC files

[Jay Jaeger via cctalk]

On 3/21/2019 2:50 PM, Curt Vendel via cctalk wrote:
> I have many DEC files that I’ve recovered from old VMS backups to a PC.
> 
> Many are Word-11, ALL-IN-1 WPS and VMS Mail MAI files.
> 
> They don’t open well in programs like the Windows Text editors 
> 
> Is there a program on Windows that can open these files and recognize all of 
> the formatting and control commands so they can be properly viewed?
> 
> 
> 
> 
> 

Perhaps restore them onto a SimH VMS instance, and use that to print the
document files and mail the mail to yourself?

Re: Fujitsi 2444AC 9-track tape drive/PDP-11

[Jay Jaeger via cctalk]

On 3/21/2019 11:40 AM, Christian Corti via cctalk wrote:
> On Thu, 21 Mar 2019, Jay Jaeger wrote:
>> On 3/20/2019 9:56 AM, Jon Elson via cctalk wrote:
>>> On 03/19/2019 09:51 PM, W2HX via cctalk wrote:
 The pertec-to-SD project sounds very cool. Keep me in mind if you need
 testers/buyers.


>>> Yes, me too!  I still have a working 92185 (Keystone) drive, and could
>>> be interested if your design is not too expensive.
>>
>> Me Three.  I have a couple of Pertec drives.
> 
> I have a couple of unformatted drives and could use some formatters with
> Pertec interface...
> 
> Christian
> 

I have some Pertec formatters - but shipping over the pond would be
prohibitive?  They are in unknown condition, and likely need work.  I'd
have to look up their capabilities - I seem to recall at least one of
them was for a 7 track drive (or maybe 7/9 drive).  A couple of them
hosted a mouse one year, but were subsequently cleaned up:

BOX CATEGORYROOMLOCATIONDESCRIPTION Type
SERIAL_NUMBER   Replacement
NOTES   Inventory

Pertec Formatter #1 UNITGarage  Slot 14 Pertec Formatter F649-72
UNIT
Mouse entered, but cleaned  9/18/2012

Pertec Formatter #2 UNITGarage  Slot 14 Pertec Formatter F649-40
UNIT
Mouse entered, but cleaned  9/18/2012

Pertec Formatter #3 UNITGarage  Slot 14 Pertec Formatter F649-72
UNIT
Cleaned 9/18/2012

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

On 2/7/2019 11:47 AM, Noel Chiappa via cctalk wrote:
> 
> The interesting point is that when V6 first copies the text in from the file
> holding the command (using readi(), Lions 6221 for anyone who's masochistic
> enough to try and actually follow this :-), it reads it in starting from the
> bottom, one disk block at a time (since in V6, files are not stored
> contiguously).
> 

I remember when Lions first showed up.  I have a copy of a copy made
back in the day.

JRJ

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

On 2/13/2019 1:43 AM, Fritz Mueller via cctalk wrote:
> SUCCESS!!
> 
> Put the M795 out on an extender, loaded 16 in RKBAR, and had a look 
> around with a logic probe.  Narrowed it down to E34 (a 7430 8-input NAND).  
> Pulled, socketed, replaced, and off she goes!
> 
> I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.
> 
> *THAT* was a really fun and rewarding hunt :-)  First message in the thread 
> was back on Dec 30, 2018.  Lots of debugging and failed DRAM repairs, then 
> the final long assault to this single, failed gate...
> 
> Thanks to all here for the help and resources, and particular shout-outs for 
> Noel and Paul who gave generously of their time and attention working through 
> the densest bits, both on and off the list.
> 
> I predict a long happy weekend and a big power bill at the end of the month 
> :-)
> 
> cheers,
>   --FritzM.
> 
> 

Congratulations.As another poster mentioned, it has been fascinating
to watch and learn, day by day, as you worked on the problem with Noel
and Paul's help.

And I learned a little bit more about my 11/45 (that it indeed had had a
processor field upgrade), which I had not looked at very closely before.

Maybe that story about FE's using Unix as a test to confirm operation
even when diagnostics said the machine was OK was not so much just a
legend?

Re: IBM 3174 C 6.4 Microcode Disks?

[Jay Jaeger via cctalk]

On 2/14/2019 9:28 PM, Kevin Monceaux via cctalk wrote:
> Classic Computer Fans,
> 
> I posted this to the IBM-Legacy-Hercules mailing list.  I just realized it
> probably wouldn't hurt to post it here too.
> 
> I'm finally in possession of a box that hopefully is capable or can be made
> capable of connecting a real terminal to Hercules.  It's a 3174 11L.  It was
> retired last year where I work.  I finally got the okay to save it from
> being sent to a scrapper.  I love the build quality of older IBM gear,
> except when I'm trying to move such gear.  Between the 3174 and a 9406-520 I
> also acquired, I pulled or strained something in my left arm moving them
> into place.
> 
> It's currently wired to run on 220v.  I think I've seen mentioned somewhere
> that it can be changed to run on 110v.  If that's the case, does anyone have
> a pointer to documentation on what's involved?
> 
> It has dual floppy drives.  At least one drive is a 2.4MB drive.  But, all
> the microcode disks I have are at level B 4.6.  Does anyone know where I can
> get a set of C 6.4 control and control extension disks.  From what I've
> heard those are what's needed to enable an attached terminal to connect to
> other systems via telnet.
> 
> It has a token ring card.  I will probably be able to get the MAU it was
> connected to, and possibly the router that acted as a token ring to Ethernet
> bridge.
> 
> I'm not sure how much memory it has.  Does anyone have any tips on
> determining the amount of memory it has, and/or identifying its boards?
> These are the numbers on its boards:
> 
> 9210
> 9351
> 9052 z2
> 9053
> 9501
> 
> Plus the boards for coax connections.
> 
> 
> 

I have some 3174 floppy disks, but I don't know what - they are not in
my inventory.  I will put it on my queue to look at them - but it may be
a couple of weeks.  I don't hold out much hope, but I will look.

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

On 2/5/2019 12:03 PM, Fritz Mueller via cctalk wrote:
>> Perhaps compile [test programs] under SimH and do a block-level diff of the 
>> image with what is currently in use, and transfer just those blocks?
> 
> I did experiment with this a little way back.  I wrote a small standalone 
> code that dumps a CRC of every sector over the console; I can run this both 
> under SIMH and on the real machine, then diff to find the changed sectors.
> 
> Unfortunately, when I tried to apply this, it seemed that SIMH's write single 
> sector wasn't working correctly for me (though "write all sectors to end" 
> seemed to work okay).  It ended up being much more tedious than I had thought 
> to do it this way; in the end I concluded I'd be better off writing some 
> different software specifically for this purpose, but I haven't gotten back 
> to it yet.
> 
> FWIW, I maintain a Windows VM (on a MacOS X host) for the sole purpose of 
> running PDP11GUI, and I use an USA19H USB serial dongle connected through to 
> the VM as a serial interface.  I don't know if something about this setup is 
> particularly detrimental to PDP11GUI transfer performance?  It takes me >3hrs 
> to write a 2.5mb pack this way (at 9600 baud), or a little over 1hr to read 
> one back.  Do others see similar throughput with these tools?
> 
>   --FritzM.
> 
> 

At 9600 bps, and allowing for 10 bit characters (8 data bits, 1 start, 1
stop), that is 960 cps, and 2.5MB RK05 should take under an hour (2400
s).  Round that up to an hour, say, for handshaking overhead, etc.  That
is consistent with your read time.

To get to three hours we would need a pause for each write of:

7200 = 200 (tracks) x 12 (sectors/trk) x 2 (sides) x n seconds/block

And n would be 1.5 seconds / sector for the write time.  That seems
excessive.

Perhaps it is doing read after write verify for each block written?   If
so, can you turn that verify off?  (When I do my transfers over a DR11,
I run a separate checksum step afterwards, and the transfer programs
also report their checksums).

Re: early PDP-11/45 info sought

[Jay Jaeger via cctalk]

On 1/27/2019 11:01 PM, Fritz Mueller via cctalk wrote:
> Hi Jay,
> 
>> On Jan 27, 2019, at 7:07 PM, Jay Jaeger  wrote:
>>
>> I think I can help some... I DO have earlier PDP-11/45 CPU drawings...
> 
> Man, this list is the absolute best!
> 
> The '72 KB11-A drawings would be most immediately useful.  If you only have 
> time for a subset of pages, I would find the schematics for M8100, M8103, 
> M8105, and M8106 particularly interesting.  
> 
> It would also be interesting to compare the M8103 ROM listings between the 
> '72 and '74 drawing sets and see whether they snuck in any microcode 
> changes/fixes.

Will start scanning today.

> 
> I do have KT11-C and FP11-B in my system, but haven't checked their 
> provenance yet.  To the extent that I've had to repair these, anyway, they've 
> matched the drawings that I do have.
> 
>> I have a PDP-11/45 From U. Wisc. ECE that claims to be S/N 1525
> 
> Wow, another <2000 11/45!  Do you have yours up and running?  Do have its ECO 
> history?  I found one other oddity during my restore that seems related to 
> early 11/45's -- no +15V to pin CU1 in SPC slots 26-28, which keeps any EIA 
> DL11 from working correctly in those slots (though the contemporary 20ma 
> DL11-A would work).  I have a feeling this might have been addressed in a 
> later ECO.  It would be interesting to check this on your backplane?
> 

My 11/45 has not been on for a log time.  Some time ago I had it on,
it could sometimes boot RT-11, but failed MUL diagnostics - but I was
not confident that the diagnostic itself was correct.

I will see if I can check on the +15V issue (hopefully without having to
turn the thing on) - I don't have a real TTY for it to talk to, so it
isn't something I would have noticed.

> Thanks for taking a look through your library, and for the generous offer to 
> take the time to do some scans.
> 
>cheers,
>  --FritzM.
> 
> 
> 

Not a problem.  Fortunately, when I migrated to my new PC this winter, I
had the foresight to test my scanner - which did NOT work because the
TWAIN drivers for it (a Ricoh IS300e) would no longer install, and
installed a virtualbox VM running Windows 7 to talk with it.

JRJ

Oh Darn (Re: early PDP-11/45 info sought)

[Jay Jaeger via cctalk]

Dang it - the dates fooled me.  (blush)  Sorry to get your hopes up,
Fritz.

Here is some more accurate information:

The first set:
   The first page (the directory) is actually 6/76 in the revisions
   block.  It is *later* than the one on bitsavers.

   Interesting, though:  it actually shows TWO directories.  One column
   is labeled 11/45-1 and the second 11/45-2. It looks like the 2nd
   column is for a later CPU, KB11-D.

   This set appears to be mostly index pages and chassis/power supply.
   The one on Bitsavers includes the KB11-A drawings, which I have as
   a separate document (complete with cover).

The KT11-C is actually 12/75
   It is *later* than the one on bitsavers.

The KB11-A is actually 4/76

The FP11-B is 7/72 rather than 3/72
   THIS IN FACT IS THE ONE ALREADY ON BITSAVERS:
   There is a name and "stamp" on the first page that
   is quite recognizable, and the dates on my scan
   match.
   So, I won't rescan it.  ;)

The FP11-C is 12/75 as noted  [And is not currently on bitsavers]

I will still scan them in except for the one (and the other manuals Noel
identified).

Apologies for the confusion.  I was using the date in the date block on
the bottom right of the first page - I didn't notice the revisions block
on the bottom left.  8(

JRJ



On 1/27/2019 9:07 PM, Jay Jaeger via cctech wrote:
> I think I can help some.  I have a PDP-11/45 From U. Wisc. ECE that
> claims to be S/N 1525 .
> 
> *  I do NOT have an actual wire list, it seems, but I will hunt a bit
> more tomorrow or Tuesday.
> 
> *  I DO have earlier PDP-11/45 CPU drawings, but no ECO info
> 
> 
> Here is what I have for drawings:
> 
> B-DD-11/45-0-AJ  Basic Assy (PDP11/45)  5/72  [Not CPU Cards]
>D-CS-5409684-0-1-H 11/45 Console Board 3/72
>B-DD-KB11-A-0-AA 16 Bit Processor  May-72  [NOT CPU HERE]
>   B-DD-DL11-0-K
>   B-DD-KW11-0-*
>   B-DD-BM873-0-F
>   B-DD-KT11-C-B
>   D-IC-11/45-0-1-H Power System Configuration
>   K-WL-7009540-0-2 Wire List (small - only 6 pages)
>   B-DD-861-0-L
>   B-DD-H7420-0-E
>   B-DD-H744-0-R
>   B-DD-H745-0-R
>   B-DD-H746-0-E
>   E-CS-H754-0-1-T
>A-AL-11/45-0-3-B  Accessory List
>D-AR-11/45-0-4-C  (Rack Configurations)
>C-PL-11/45-0-4-D Arrangement Parts List
>B-DD-M9301-0-D
> 
> B-DD-KT11-C-B
> [NOTE:  Use KT11-C Only with KB11-A & FP11-B,
> Use KT11-CD Only with KB11-D & FP11-C]
>[M8107, M8108]
> 
> 
> KB11-A Engineering Drawings  [PDP-11/45 CPU]
>KB11-A-0-AA Dated May 72
>[M8100, M8101, M8102, M8103, ROM Control Listings for M8103,
> M8104, M8105, M8106, M8109, M8116, M930, M9202]
>NO wire list
> 
> (Curiously, I also have KB11-C, 11/70 drawings.)
> 
> B-DD-MF11-U-B 16K Core [M8293, G235, G114, H217, M7259 (Parity Control)]
> B-DD-MS11-B-B MOS Memory [M8110, G401]
> B-DD-MS11-C-B Bipolar Memory [M8110, M8111]
> B-DD-MS11-C-C Bipolar Memory (ECO MS11C-3)  Mentions M8120
> 
> B-DD-FB11-0-A FP11-B Floating Point Processor  March 72
>[M8114, M8115, M8112, M8812 ROM Control Listings, M8813]
> 
> B-TC-FP11-C-6 FP11-C (Print Set MP00038)  December 75
>[M8126, M8127, M8128, M8129]
> 
> DEC-11-HFPAA-C-D  FP11 Floating Point Processor Maintenance Manual
> DEC-11-FP11C-MM-001 FP11-C Floating Point Processor Maintenance Manual
> EK-KT11C-MM-005  KT11-C, CD Memory Management Unit Maintenance Manual
> EK-MS11A-MM-006  MS11-A,B,C memory System Maintenance Manual
> 
> PDP-11 Systems Course Training Drawings
> PDP-11/45, 11/70 Maintenance Course handout book
> 
> And some diagnostic listings for the 11/40 and 11/45.
> 
> I have not looked through my fiche for ECO info, though I am not
> hopeful, but will look tomorrow.  Most of my fiche are too modern.
> 
> Let me know what you want me to scan - should be able to get to it later
> this week.
> 
> JRJ
> 
> 
> On 1/27/2019 6:40 PM, Fritz Mueller via cctalk wrote:
>> Those reading through the recent "PDP-11/45 RSTS/E boot problem" thread here 
>> will know that I've gotten to some corners of my 11/45 CPU now that don't 
>> match up with the commonly available engineering drawings.
>>
>> My /45 is an early serial number (#152).  So far I've verified hardware 
>> differences on at least my M8100 and M8105 cards and spares, relating to 
>> parity error abort handling.  I would really like to track down any of the 
>> following resources:
>>
>> - PDP 11/45 system engineering drawings *earlier* than those currently 
>> available on bitsavers (Jun '74)
>>
>> - Any PDP 11/45 backplane wire list (what looks to be a wire list in the 
>> currently available engineering drawings is actually only a breakdown of the 
>> power harness.)
>>
>> - PDP 11/45 ECO information, particularly the following:
>>
>> M8100  3
>> M8103  5
>> M8105  5
>> M8106  7, 8, 00012, 00012A
>> M8110  8
>>
>> KB11-A 00015
>>
>> Bitsavers seems to have a DEC-O-LOG for M8105, but this does not contain 
>> specifics on cuts and jumps for 

Re: early PDP-11/45 info sought

[Jay Jaeger via cctalk]

On 1/27/2019 9:07 PM, Jay Jaeger via cctech wrote:
> 
> Let me know what you want me to scan - should be able to get to it later
> this week.
> 
> JRJ
> 
> 
> On 1/27/2019 6:40 PM, Fritz Mueller via cctalk wrote:
>> Those reading through the recent "PDP-11/45 RSTS/E boot problem" thread here 
>> will know that I've gotten to some corners of my 11/45 CPU now that don't 
>> match up with the commonly available engineering drawings.
>>
>> My /45 is an early serial number (#152).  So far I've verified hardware 
>> differences on at least my M8100 and M8105 cards and spares, relating to 
>> parity error abort handling.  I would really like to track down any of the 
>> following resources:
>>
>> - PDP 11/45 system engineering drawings *earlier* than those currently 
>> available on bitsavers (Jun '74)
>>
>> - Any PDP 11/45 backplane wire list (what looks to be a wire list in the 
>> currently available engineering drawings is actually only a breakdown of the 
>> power harness.)
>>
>> - PDP 11/45 ECO information, particularly the following:
>>


The first batch of scanning is done.  600dpi, CCITT Group 4 except for
the cover pages which are LZW.

You will find them in my Google Drive at

https://drive.google.com/open?id=0B2v4WRwISEQRWWFFdVpCZWFTZEU

In subfolder pdf/dec/pdp11/1145

Note that the FP11-B material is already on bitsavers (this is generally
where I put my contributions for them to snag...)

Memories (and perhaps FP11-C) tomorrow, I hope, then on to the manuals
that Noel suggested.

Re: early PDP-11/45 info sought

[Jay Jaeger via cctalk]

OK, my scanning of PDP-11/45 materials is done, at least for now.

Materials can be found on my Google Drive at:

https://drive.google.com/open?id=0B2v4WRwISEQRWWFFdVpCZWFTZEU

In sub folders pdf/dec/pdp11/1145 and .../memory

Everything is both directories is new EXCEPT for

   PDP11_FP11-B_Floating-Point_Processor_Engineering_Drawings

Which I had contributed back to bitsavers back in 2016.

On to reviewing fiche...

Enjoy!

On 1/29/2019 11:46 AM, Noel Chiappa via cctalk wrote:
> From: Jay Jaeger
> 
> > Here is what I have for drawings:
> 
> Wow. You have some very desirable stuff there! Let me point at a couple
> of things of particular interest:
> 
> > B-TC-FP11-C-6 FP11-C (Print Set MP00038)  December 75
> > [M8126, M8127, M8128, M8129]
> 
> AFAIK, prints for the FP11-C are not available online:
> 
>   http://manx-docs.org/details.php/1,9306
> 
> so those of us with an FP11-C would be particularly grateful if you could
> scan those and make them available.
> 
> > EK-KT11C-MM-005  KT11-C, CD Memory Management Unit Maintenance Manual
> 
> Not available online; the earlier DEC-11-HKTCA-C-D KT11-C Memory Management
> Unit Maintenance Manual is available online, but doesn't cover the -CD. This
> one is in the fiche set, but it's a pain to work with (especially since my
> fiche reader burned out its bulb recently :-), so it's a 'nice to have',
> scan-wise.
> 
> > EK-MS11A-MM-006  MS11-A,B,C memory System Maintenance Manual
> 
> Agaih, not available online, but in the fiche. Ditto 'nice to have'.
> 
> Of course, anything you've got that's not online should be scanned
> 'eventually' (I have several of those myself, sigh).
> 
>   Noel
> 

Re: early PDP-11/45 info sought

[Jay Jaeger via cctalk]

I have completed my transcription of what I felt would be the most
salient entries and information in those entries of the PDP-11/45
DEC-O-Logs.

Curiously, there were no entries at all for the KB11-D.

The transcripts are available on my Google Drive at

https://drive.google.com/open?id=0B2v4WRwISEQRWWFFdVpCZWFTZEU

under pdf/dec/fieldService/dec-o-log

Of course, they won't be 100% accurate, but I did take special care to
note areas where I had trouble making stuff out, and over signal names
and FCO cuts/adds where available.

Note/offer:  If someone has a good way to scan fiche, I could send (one
at a time) my JAN86 and JUL86 fiche sets (9 fiche) off to that someone
to scan/print.

On 1/27/2019 6:40 PM, Fritz Mueller via cctalk wrote:
> Those reading through the recent "PDP-11/45 RSTS/E boot problem" thread here 
> will know that I've gotten to some corners of my 11/45 CPU now that don't 
> match up with the commonly available engineering drawings.
> 
> My /45 is an early serial number (#152).  So far I've verified hardware 
> differences on at least my M8100 and M8105 cards and spares, relating to 
> parity error abort handling.  I would really like to track down any of the 
> following resources:
> 
> - PDP 11/45 system engineering drawings *earlier* than those currently 
> available on bitsavers (Jun '74)
> 
> - Any PDP 11/45 backplane wire list (what looks to be a wire list in the 
> currently available engineering drawings is actually only a breakdown of the 
> power harness.)
> 
> - PDP 11/45 ECO information, particularly the following:
> 
> M8100  3
> M8103  5
> M8105  5
> M8106  7, 8, 00012, 00012A
> M8110  8
> 
> KB11-A 00015
> 
> Bitsavers seems to have a DEC-O-LOG for M8105, but this does not contain 
> specifics on cuts and jumps for ECO 5, referring only to the associated 
> "kit".  DEC-O-LOGs for the other processor boards are missing.
> 
> If anybody thinks they might have any of this info squirreled away anywhere, 
> I'd really love to find out more about it!
> 
> Parts of the ECO's are pretty easy to figure, just by comparing the state of 
> my existing boards to the '74 drawings.  But other parts not so much...
> 
> thanks much,
>   --FritzM.
> 
> 
> 

Re: early PDP-11/45 info sought

[Jay Jaeger via cctalk]

On 1/31/2019 12:02 PM, Fritz Mueller via cctalk wrote:


> 
> I don't actually have anything that uses the M8110; I am mostly interested in 
> that one to understand how it co-evolved with the parity changes in the CPU 
> (sometimes its easier to understand if you can see both sides).
> 
>cheers (and thanks again!),
>  --FritzM.
> 

Well, the short answer is the same: it seems to have been an absolute
mess.  So bad DEC eventually threw in the towel on it, apparently, and
moved on and created the M8120.  Perhaps foreshadowing the mess that
MITS had with its first 4K dynamic memory board.  ;)

So, if you have one in there, you don't want it in any memory you will
be addressing.  I'd probably pull it, or at least put it way up high
with a gap before it.

The parity change in the CPU was to change parity errors from vectoring
thru location 4 to vector through 114.

My 1972 and 1973 11/45 processor handbooks do not mention location 114,
just location 4.

My 1976 pdp11/04/05/10/35/40/45 identify 114 as the vector for memory
system errors.  So software (and diagnostics) from sometime after 1973
would presumably expect that.

Re: More facets of hard disk recovery (SA1000, RD53) and emulation

[Jay Jaeger via cctalk]

Are these bare boards you would sell, or populated?  (I would guess the
former, yes?)

Price (for both the MFM reader and the SA1000 adapter)?

JRJ

On 2/1/2019 7:37 PM, David Gesswein via cctech wrote:
> I have made a SA1000 adapter board for my MFM reader emulator. I did a
> small run which seems to work so if you are interested email me to get
> in on the next order. Prices may get a little better if I get enough
> orders. 
> 
> http://www.pdp8online.com/mfm/
> http://www.pdp8online.com/mfm/sa1000/sa1000_usage.shtml
> 
> I have used it for reading Shugart SA1004 and Quantum Q2040 drives.
> Another has used it to replace drive in a TRS-80 Model II 8 Meg drive unit.
> 
> Some other items that may be of interest:
> 
> Dealing with stuck head problem with Quantum Q2040 drives
> http://www.pdp8online.com/q2040/q2040.shtml
> 
> Using a DAC to pull the head servo to recover otherwise unreadable data
> from DEC RD53 drive. Also procedure tried for Q2040 but data had been erased
> so not successful.
> http://www.pdp8online.com/mfm/head_servo/
> 
> 

Re: early PDP-11/45 info sought

[Jay Jaeger via cctalk]

On 1/27/2019 6:40 PM, Fritz Mueller via cctalk wrote:

> Those reading through the recent "PDP-11/45 RSTS/E boot problem" thread here 
> will know that I've gotten to some corners of my 11/45 CPU now that don't 
> match up with the commonly available engineering drawings.
> 
> My /45 is an early serial number (#152).  So far I've verified hardware 
> differences on at least my M8100 and M8105 cards and spares, relating to 
> parity error abort handling.  I would really like to track down any of the 
> following resources:
> 
> - PDP 11/45 system engineering drawings *earlier* than those currently 
> available on bitsavers (Jun '74)
> 
> - Any PDP 11/45 backplane wire list (what looks to be a wire list in the 
> currently available engineering drawings is actually only a breakdown of the 
> power harness.)
> 
> - PDP 11/45 ECO information, particularly the following:
> 
> M8100  3
> M8103  5
> M8105  5
> M8106  7, 8, 00012, 00012A
> M8110  8
> 
> KB11-A 00015
> 
> Bitsavers seems to have a DEC-O-LOG for M8105, but this does not contain 
> specifics on cuts and jumps for ECO 5, referring only to the associated 
> "kit".  DEC-O-LOGs for the other processor boards are missing.
> 
> If anybody thinks they might have any of this info squirreled away anywhere, 
> I'd really love to find out more about it!
> 
> Parts of the ECO's are pretty easy to figure, just by comparing the state of 
> my existing boards to the '74 drawings.  But other parts not so much...
> 
> thanks much,
>   --FritzM.
> 
> 

I am working on transcribing some DEC-O-Logs - more than are on
bitsavers that relate to the KB11-A and its cards.

In the process, I came across KB11A-B0008 - which indicates that NPG,
PA, PB, LTC, ACLO, DCO and +15V are ALL missing in slots 26-28.  That
FCO was dated SEP-72, and specifically mentions the DL11. I think you
had mentioned that issue in another post.

Also, I have at least two sets of DEC-O-Logs.  (JAN 86 and JUL 86) that
cover the 11/45.  I would be happy to loan a set out to someone who
promised to scan or print/scan a set.

I hope to be done transcribing later today.

NOTE:  The M8110 looks like a mess - lots of ECOs that culminate in
replacing with an M8120.  You might not want to use it, and just use
other MS11s.

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

On 2/4/2019 11:34 AM, Fritz Mueller via cctech wrote:
> 
>> On Feb 4, 2019, at 9:13 AM, Jay Jaeger  wrote:
>>
>> If he hasn't already, if Fritz has more than one memory board, he might
>> try swapping them to see if that changes anything.
> 
> I only have an 128kw MS11-L here to work with, unfortunately.  Its been 
> through a bunch of recent troubleshooting (tracking down and replacing failed 
> DRAMs).  I *think* its pretty solid at this point (also passing some of the 
> hairier DEC diagnostics) but...
> 
> I'd be happy to try out a different memory board if anybody was interested in 
> sending out a loaner?  (I'm in the SF Bay area).
> 

Well it turns out I have a couple of spares, but maybe someone closer
would be easier (Madison, WI  53711)

I have an MS11-LB, 64Kw, M7891-BB and two MS11-LD, 128Kw, M7891-DB and
an M7891-D?

So, two of these are newer revisions (rather than M7891-xA) - I have no
idea what the difference is.  On that last one I probably didn't record
where it was D, DB or DA

I also have quite a few RK05 packs and would be willing to sell one (and
I have boxes to ship boards and packs in).  The ones I am most willing
to part with would need their open/close springs removed, as they are
broken and dangerous to the platter in their current condition, but are
otherwise fine.  I would just remove the spring.

$20 for a pack is what I usually price them at, plus shipping.  (PayPal,
preferably)


The board would be a loan (with compensation for time spent if it is bad
*and* gets fixed) ;).



Let me know - might take me a couple of days to hunt the board down and
remove the spring and re-test the pack and pack everything up and ship
it.  (in my 11/34 which runs @rkunix V6 just fine.  ;))

JRJ

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

> 
> Yeah, it may come to that. One issue we've been having is doing specialized
> test programmes; trying to run the C compiler fails. I don't know about the
> assembler, though. And as Fritz mentioned, it takes hours to load a new disk
> image. I think we've come up with a way around that, though; produce binary
> of stand-alone tests elsewhere (I've often/always got a v6 running on
> Ersatz-11 here), and load them into the /45's main memory with PDP11GUI.
> 
>   Noel

Perhaps compile it under SimH and do a block-level diff of the image
with what is currently in use, and transfer just those blocks?
(Presumably would be the superblock, bitmap, directory and actual
program blocks).

For my setup I use a DR11 to transfer data, using an Arduino with
Ethernet as a go-between my PC and the PDP-11.

Re: PDP-11/45 RSTS/E boot problem

[Jay Jaeger via cctalk]

On 2/4/2019 10:20 AM, Jon Elson via cctalk wrote:
> On 02/04/2019 04:28 AM, Noel Chiappa via cctalk wrote:
>>
>> First oddity - the problem is dependent on the location of the command
>> in main
>> memory! If Fritz says "sleep 360 &", to run a trivial command in the
>> background, and _then_ says 'ls' - it works (so we know the binary of
>> 'ls' on
>> disk is OK)! We _think_ this is because the process executing the 'sleep'
>> takes up a chunk of main memory, and thus changes the location of the
>> process
>> executing the 'ls'.
>>
>>
> OK, the classic Heisenbug.  Is this truly a fault given by the memory
> management system, or some other kind of fault (Unibus timeout or memory
> parity error)?  If really related to MMU, then maybe there is a bad bit
> in the MMU that is causing it to reference the wrong segment entry or
> somehow thinking the setting of that segment entry is invalid.  Does the
> MMU classify what the error condition was, or just assume the trap
> handler can figure it out be looking at the registers?
> 
> Anyway, is it possible to borrow an MMU from somebody else?  I can
> easily imagine that the diags can't test every possible bit combination
> while the diags are ALSO running in memory.
> So, a somewhat cryptic bug could go undetected.
> 
> If this fault could be caused by memory, then it may be a
> pattern-sensitive error, and ls is just the perfect pattern to trip it up.
> 
> Jon
> 

If he hasn't already, if Fritz has more than one memory board, he might
try swapping them to see if that changes anything.

The issue I'd see with the MMU swapout idea would be finding one that
would be ECO-compatible with the rest of the processor.

This sort of situation, where DEC diagnostics run OK but UNIX has issues
was reported to be not all that uncommon - to the point where the urban
legend was that some DEC FE's would fire up Unix V6 as a sort of system
exerciser.

Other things I might be tempted to try in order to coax more information
out of the situation:

1.  Run the DEC system exerciser, if that has not already been done.
2.  Make a copy of ls, and see if the copy also fails
(different location on disk would mess with timing just a bit).
3.  Use SimH to build a pack image with an instance of ls that is not
pure text (no -n or -i flag)
4.  Use SimH to build an ls that does/does not start the data segment
for ls at 0 (has / does not have the -i flag) [I have not looked to
see how ls would normally be built.]
5.  Use SimH to gen a pack image with a kernel that is a not split I/D

JRJ

Re: "arx-149" computer. .. what Is?

[Jay Jaeger via cctalk]

On 4/14/2019 12:59 PM, Al Kossow via cctalk wrote:
> On 4/14/19 12:16 AM, ED SHARPE via cctalk wrote:
>> "arx-149"   computer. .. what Is?thanks ed#
>>
> 
> targeting computer for the illudium q-36 explosive space modulator
> 
> 
> 

Dying ROTFL.  ;)  (:  :)  (:

Re: Interesting article in Spectrum about IBM's System/360

[Jay Jaeger via cctalk]

On 4/12/2019 1:15 PM, Eric Smith via cctalk wrote:
> The article says:
> 
> Poughkeepsie’s engineers were close to completing work on a set of four
>> computers known as the 8000s that were compatible with the 7000s.
> 
> 
> AFAICT, that is totally wrong. The 8000 series was completely INCOMPATIBLE
> with any of the 7000 series machines. In fact, most of the 7000 series
> machines weren't even compatible with each other, though the 7040 and 7044
> had partial compatibility with the 7090 and 7094.
> 
> There are some 8000 documents on Bitsavers so you can see for yourself.
> http://bitsavers.trailing-edge.com/pdf/ibm/8000/
> 

Furthermore, like the 8000 series would have been, the 7000 series (and
the 700 series, and the 1400 series, for that matter) was more of a
series of *technology* rather than a series of compatible computers.

The 7000 series used SMS ECL (current mode), at least in a lot of
places, whereas the 1400 series were essentially RTL with some DTL
sprinkled in on the 1410.

For example, the IBM 7010 was an IBM 1410 done up in 7000 series
technology (and was a compatible super-set of the 1410 and, via  a
toggle switch, the 1401).  It had no architectural relationship with the
7090/7094, nor did the 7070 or 7080, near as I can tell.

>From "The Genesis of the Mainframe" by Bob O. Evans (an extract from a
longer memoirs document, which was not itself published, to my knowledge)

https://researcher.watson.ibm.com/researcher/files/us-bbfinkel/bob_o_evans_mainframe.pdf

"Flush with the success of the 1401 and the 1410 in process — I was not
willing to abandon those winners to join the 8000 series plan, which did
not sit right with me in the first place because the 8103, 8104, 8108
and the 8112 were architecturally incompatible and I was certain
compatibility was fundamentally important."

"By May 1961 I concluded the 8000 series would be a serious blunder, in
part because of the lack of compatibility within the systems family. I
did not buy Dr. Brooks’ arguments that recompilation would be acceptable
to make it possible for the programming from all the dissimilar
architectures of existing products to work effectively on the dissimilar
architectures of the 8000 series. There were other important reasons to
scrap the 8000 series plan including technology choice. Jerrier Haddad
backed my decision; the 8000 Series plan was killed."

My experience with a couple of magazine authors during my career tells
me that many of them do not understand much of what they are writing,
and errors like this 7000/8000 thing are common.


Another half truth in the article reads:  "The power of compatibility
was demonstrated in the fall of 1960, when IBM introduced the more
powerful 1410 to replace the 1401. Software and peripheral equipment for
the 1401 worked with the newer machine. "

That was only true to the extent that the 1410 included a 1401
compatibility mode switch, which literally changed the logic so that it
became a (somewhat faster) 1401.  In its normal 1410 position, it could
not run 1401 programs, and vice/versa.

JRJ

Thinking about PDP11 PC05 Emulation

[Jay Jaeger via cctalk]

I have several PDP-11's in my collection (among other things), and not
enough PC05 tape readers (or enough room) to go around.  But most if not
all of my machines have M7810 PC11 interfaces, and I have one I could
move from machine to machine as needed.  Moving a PC05 around would be a
lot more work, and not every rack has room.  ;)

So, I took a look at what it might take to interface with an M7810 (or,
down the road, a PDP-8/L or PDP-12.  It looks like the emulator would
have to accept as input just 3 lines (Initialize  L, IOP2(1)/Select,
IOP4(1)/Read) [It would not need the redundant Initialize H, IOP1(1),
Qualify or Skip], and would have to drive 11 lines into the pullups on
the M7810 (8 Data lines, IO Bus INT L/Reader Done L, Outtape/Error and
RDR RUN L/RDR Busy L).

So, a total of 14 interface lines. (The 8 or 12 would take a few more
lines).

The pullups average about 470 ohms (1 is 1K, 1 is 220, the rest are
470), so at 5V the output has to sink a bit over 10ma, and all total
120ma.

An Arduino Uno with an Ethernet shield would have 20 minus 5 lines
available, in theory, but if one wants serial I/O as well for debugging,
that sucks up 2 more lines - so only 13 available.  And sinking 120ma
would be a bit much though I could likely sprinkle inputs among the
outputs to make it work so as to stay within the recommended sink
limits, and at least initially have it never run out of tape, and tie
Error down.

http://playground.arduino.cc/Main/ArduinoPinCurrentLimitations

So, I am thinking about an Arduino Mega, as it has more output groupings
to sprinkle the sink current around, and 5V interface capability, and
more pins to eventually support my PDP-8/L and PDP-12.

(I could do it with a PIC - did that for a Documation card reader to PC
interface, but I am really tired of fighting Microchip's IDE.)

BUT - it also occurs to me someone may have already done something like
this?  Any leads / ideas?

JRJ

Re: Thinking about PDP11 PC05 Emulation

[Jay Jaeger via cctalk]

Hi, Henk.

Cool - so sort of the complement of what I am considering doing - your
interface allows connection of a real device to a simulated hardware
processor.

Your thorough documentation will be helpful in confirming the signals I
plan to use.

JRJ

On 3/11/2019 1:39 PM, Henk Gooijen wrote:
> Hi Jay,
> 
> Have a look at www.pdp-11.nl/peripherals/tape/pc05-simh-pc.html
> 
> 
> If you are interested I can tell you more …
> 
>  
> 
> I can read and punch tape. PC05 + interface (PIC 18F4550) connects using
> RX/TX to USB to PC.
> 
> Reading one character at a time works fine (speed some 20 char/sec,
> so-called start-stop mode).
> 
> Reading in “streaming mode” is probably some 300 char/sec, but I get
> unexplained “out-of-paper” state sometimes, and reading stops (of course).
> 
>  
> 
> To read from the PC05 reader you need IOP2, IOP4, and INT*. Maybe BUSY*
> is needed, not sure about that.
> 
> INITIALIZE* is good to have as well. A few other signals (for example
> IOP1) needs to be connected to an appropriate level. And 8 data inputs,
> which need a pull-up resistor. Note that the data from the reader is
> inverted.
> 
>  
> 
> To punch you only need IOP4 (IIRC) and of course 8 data outputs.
> 
> As you know, reader and punch are two completely isolated devices.
> 
>  
> 
> Greetz,
> 
> Henk
> 
>  
> 
>  
> 
> 
> *Van:* cctech  namens Jay Jaeger via
> cctech 
> *Verzonden:* Monday, March 11, 2019 7:11:46 PM
> *Aan:* General Discussion: On-Topic Posts
> *Onderwerp:* Thinking about PDP11 PC05 Emulation
>  
> I have several PDP-11's in my collection (among other things), and not
> enough PC05 tape readers (or enough room) to go around.  But most if not
> all of my machines have M7810 PC11 interfaces, and I have one I could
> move from machine to machine as needed.  Moving a PC05 around would be a
> lot more work, and not every rack has room.  ;)
> 
> So, I took a look at what it might take to interface with an M7810 (or,
> down the road, a PDP-8/L or PDP-12.  It looks like the emulator would
> have to accept as input just 3 lines (Initialize  L, IOP2(1)/Select,
> IOP4(1)/Read) [It would not need the redundant Initialize H, IOP1(1),
> Qualify or Skip], and would have to drive 11 lines into the pullups on
> the M7810 (8 Data lines, IO Bus INT L/Reader Done L, Outtape/Error and
> RDR RUN L/RDR Busy L).
> 
> So, a total of 14 interface lines. (The 8 or 12 would take a few more
> lines).
> 
> The pullups average about 470 ohms (1 is 1K, 1 is 220, the rest are
> 470), so at 5V the output has to sink a bit over 10ma, and all total
> 120ma.
> 
> An Arduino Uno with an Ethernet shield would have 20 minus 5 lines
> available, in theory, but if one wants serial I/O as well for debugging,
> that sucks up 2 more lines - so only 13 available.  And sinking 120ma
> would be a bit much though I could likely sprinkle inputs among the
> outputs to make it work so as to stay within the recommended sink
> limits, and at least initially have it never run out of tape, and tie
> Error down.
> 
> http://playground.arduino.cc/Main/ArduinoPinCurrentLimitations
> 
> So, I am thinking about an Arduino Mega, as it has more output groupings
> to sprinkle the sink current around, and 5V interface capability, and
> more pins to eventually support my PDP-8/L and PDP-12.
> 
> (I could do it with a PIC - did that for a Documation card reader to PC
> interface, but I am really tired of fighting Microchip's IDE.)
> 
> BUT - it also occurs to me someone may have already done something like
> this?  Any leads / ideas?
> 
> JRJ

Re: Thinking about PDP11 PC05 Emulation

[Jay Jaeger via cctalk]

On 3/11/2019 1:17 PM, William Donzelli wrote:
>> BUT - it also occurs to me someone may have already done something like
>> this?  Any leads / ideas?
> 
> Get an old BlackBox ABCD switch that can handle true 25 pin serial ports?
> 
> It seems like every year at VCFMW there are a few in the free pile.
> 
> --
> Will
> 

That might be fine if the machines were right next to each other.  Some
of mine are not so close.

An emulator would also be really convenient to use, and avoid wearing
out paper tapes.

JRJ

Re: TU58FS

[Jay Jaeger via cctalk]

On 5/23/2019 10:07 PM, Rod Smallwood via cctalk wrote:
> Hi
> 
>     It does not have to be done using TU58.
> 
> If you would be so kind as to explain the bit about SIMH and dd.
> 
> What to do is good.. How even better.
> 
> If I can get  a bootable OS image onto the SCSI drive with what I have
> available then that's all I  need.
> 
> Rod Smallwood
> 

The idea would be to use another machine (say, a PC running Linux) to
copy an image that runs under SimH configured for the same disk
controller and geometry to copy that image to the disk.

Re: 11/93 rebuild

[Jay Jaeger via cctalk]

On 5/29/2019 4:01 PM, Noel Chiappa via cctalk wrote:
> 
> > Most of the PDP11 SCSI Controllers could build two or more PDP11 disks
> > out of one physical device. That is what I meant with partition in this
> > case .. There is some logical information on the device, you simply
> > don't get the entire raw device on the pdp as you possibly think.
> 
> That's a good point, and perhaps there's no existing way to write a SCSI disk
> from a Windoze box in a way that the PDP11 SCSI controllers can grok. I don't
> know enough about how they work to answer that.
> 

Perhaps one could use Win32DiskImager to write a block level image onto
a SCSI disk, yes?  (i.e., no Windows partition, just a bunch of blocks).

JRJ