Re: PDP-12 Restoration at the RICM

[Jon Elson]

On 06/05/2016 09:54 AM, Michael Thompson wrote:

We fixed the RK05 disk this week. We replaced E3 (LM301A) and E1 (SN7404)
on the G938 Servo Preamp module. The COUNT PULSE FWD H and the COUNT PULSE
REV H signals from the G938 module are both working now. The drive will now
seek correctly using the jumpers described in the Maintenance Manual or
using seek-only instructions from the RK8-F controller.

We tried the OS/8 and LAPS-DIAL bootstraps, but the processor just halted.
The first page of core that was read from the pack contained a repeating
sequence of 2525-5252. Either the pack was used as a data-only pack, or
diagnostics were run on the pack.

2525 and 5252 sound VERY much like test patterns.

Jon

PDP-12 Restoration at the RICM

[Michael Thompson]

We fixed the RK05 disk this week. We replaced E3 (LM301A) and E1 (SN7404)
on the G938 Servo Preamp module. The COUNT PULSE FWD H and the COUNT PULSE
REV H signals from the G938 module are both working now. The drive will now
seek correctly using the jumpers described in the Maintenance Manual or
using seek-only instructions from the RK8-F controller.

We tried the OS/8 and LAPS-DIAL bootstraps, but the processor just halted.
The first page of core that was read from the pack contained a repeating
sequence of 2525-5252. Either the pack was used as a data-only pack, or
diagnostics were run on the pack. During the week I will use SIMH to make a
PDP-12 bootable OS/8 RK05 image. Next week we will use dumprest to make an
image of the disk pack, and then write OS/8 to the pack.

-- 
Michael Thompson

PDP-12 Restoration at the RICM

[Michael Thompson]

We are now working on the RK8F controller and RK05 drive. The RK8F has
special M7104 and M7105 boards so it will work in the DW8E Omnibus-Posibus
chassis.

The MAINDEC-08-DHRKA RK8E Diskless Control Test showed that a data-break to
address  worked, but did not work to address . After about 4 hours
of debugging we found a dirty connection on an M7102 board in the DW8E
chassis. This prevented one of the CA signals from the RK8F from being
driven onto the Posibus MA.

The DHRKA diag now passes, so much of the RK8K and the DW8E are working.

We bought a new NiCd battery pack for the RK05 and new weather strip to
replace the blower to card cage, and plenum to disk pack seals. There is
also a power supply problem that shows up after the RK05 had been powered
on for 10 minutes that we need to fix.

We have a disk pack that came with the PDP-12, but we don't know if it has
LAPS-DIAL or OS/12 installed. Maybe we will solve that mystery in a few
weeks.

-- 
Michael Thompson

PDP-12 Restoration at the RICM

[Michael Thompson]

As a final diagnostic on the PDP-12 we tried to run FOCAL-69, but it
started executing instructions in non existent memory. FOCAL initializes
lots of peripherals and then tries different instructions to determine what
processor it is running on. It executed what it thought was a TC01 DECtape
IOT, but DEC had recycled the 6762 instruction for the KF12 Automatic
Priority Interrupt controller. This caused the KF12 to execute a hardware
PUSH instruction to save the processor state and then jump into memory
field 2. Since we only have 8k of core it executed  instructions and
hung. Replacing the 6762 instruction at 4376 with a 7000 NOP let FOCAL
initialize and run OK.

-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM

[Mark Linimon]

On Tue, Dec 22, 2015 at 08:31:46PM -0500, Michael Thompson wrote:
> the [paper tape] reader does not always step correctly and does not
> read the tape correctly.

Ah, then you have restored it to as-shipped condition :-)

mcl

Re: PDP-12 Restoration at the RICM

[Kyle Owen]

On Thu, Dec 24, 2015 at 9:59 AM, Michael Thompson <
michael.99.thomp...@gmail.com> wrote:

>
> Kyle's SerialDisk is here: https://github.com/drovak/os8diskserver


I just pushed some changes earlier. Hopefully I didn't break too many
things! :) The system handler now has support for FRTS. Still need to add
support for older machines (I intend to add separate handlers but still
maintain compatibility with the same server).

Congrats on the great progress, Michael!

Kyle

Re: PDP-12 Restoration at the RICM

[Jon Elson]

On 12/24/2015 01:22 PM, Jay Jaeger wrote:

On 12/24/2015 9:59 AM, Michael Thompson wrote:


We have been able to fix all types of broken flip-chips. Sourcing the
components is sometimes a challenge. The Germanium transistors for the TU20
on the PDP-9 were hard to find.


I remember replacing a germanium (at least I think it was) transistor on
an SMS card with an ordinary silicon transistor in a 7094-II floating
point unit back around 1974.  Luckily, that worked fine, though for a
museum I imagine one would prefer to use the "real thing".  ;)


Yes, I overhauled an old HP digital frequency synthesizer 
that was all built out of PNP Germanium transistors (no 
ICs.)  I substituted the first one with a VHF Silicon 
transistor and did some tests on the bias, etc. and was 
pleased to find it was a total drop-in replacement.  I 
replaced over 10 of them in that unit, and they all worked 
flawlessly.


I can imagine some difficult circuits where you couldn't get 
away with this, maybe a magnetic read amp or a timing 
circuit or something, but I think in most cases a Silicon 
transistor will work well.


Jon

Re: PDP-12 Restoration at the RICM

[Jay Jaeger]

On 12/24/2015 9:59 AM, Michael Thompson wrote:

> 
> We have been able to fix all types of broken flip-chips. Sourcing the
> components is sometimes a challenge. The Germanium transistors for the TU20
> on the PDP-9 were hard to find.
> 

I remember replacing a germanium (at least I think it was) transistor on
an SMS card with an ordinary silicon transistor in a 7094-II floating
point unit back around 1974.  Luckily, that worked fine, though for a
museum I imagine one would prefer to use the "real thing".  ;)

> 
>>>
>>> We found that the maintenance prints that came with the system do not
>>> include ECO EM12-0055.
>>> Does anyone have a set of KW12 prints that include ECO EM12-0055?
>>
> 
> The prints that came with this PDP-12 are here:
> http://bitsavers.trailing-edge.com/pdf/dec/pdp12/maintenance/DEC-12-HR2B-D_PDP-12_Maintenance_Manual_Volume_2_Installation_and_Maintenance_Jun72.pdf

???  That document is not prints.  I suspect you meant:

http://bitsavers.trailing-edge.com/pdf/dec/pdp12/maintenance/DEC-12-HR1B-D_PDP-12_Maintenance_Manual_Volume_III_System_Drawings_Jun72.pdf

Which is the same revision as mine.  (I see that the 1969 edition is
also there, but under the name PDP12-MaintVol3_SchemsMar69.pdf).

> 
> Jay, we are interested in anything PDP-12 related that we don't have.
> 

Eventually I expect I will, over the next few years, scan in everything
that is not already on bitsavers, but it looks like your current needs
have been met.

> The PDP-12 is described here:
> http://www.ricomputermuseum.org/Home/equipment/dec-pdp-12
> 
> Details on the PDP-12 restoration process are here:
> http://www.ricomputermuseum.org/Home/equipment/dec-pdp-12/dec-pdp-12-restoration
> 

JRJ

Re: PDP-12 Restoration at the RICM

[Michael Thompson]

>
> Date: Tue, 22 Dec 2015 20:56:51 -0600
> From: Jay Jaeger <cu...@charter.net>
> Subject: Re: PDP-12 Restoration at the RICM
> Message-ID: <567a0d73.2010...@charter.net>
> Content-Type: text/plain; charset=utf-8
>
> I have an image of MAINDEC-12-D8CD-PB, and a listing as well
> (MDEC-12-D8CD-L in my inventory).  Let me know if you need them as well
> as the drawings (see below).  It is in an archive folder with a bunch of
> other interesting PDP-12/PDP-8 stuff.
>

I wrote a program to export a BIN formatted file from a LINCtape image so
we were able to make a BIN image of MAINDEC-12-D8CD. This runs OK, where
the D8CC does not.

Can you give me a pointer to the SerialDisk info?  Sounds interesting.
>

Kyle's SerialDisk is here: https://github.com/drovak/os8diskserver


> Hopefully you can actually fix the original M160 and M103 cards.
>

We have been able to fix all types of broken flip-chips. Sourcing the
components is sometimes a challenge. The Germanium transistors for the TU20
on the PDP-9 were hard to find.


> >
> > We found that the maintenance prints that came with the system do not
> > include ECO EM12-0055.
> > Does anyone have a set of KW12 prints that include ECO EM12-0055?
>

The prints that came with this PDP-12 are here:
http://bitsavers.trailing-edge.com/pdf/dec/pdp12/maintenance/DEC-12-HR2B-D_PDP-12_Maintenance_Manual_Volume_2_Installation_and_Maintenance_Jun72.pdf

Now that I looked in the ECO block I can see that they actually do
incorporate ECOs 55 and 57.

The machine wiring does not match the CLC page, so maybe there are more
recent ECOs in the machine and not in the prints.

We visited the RCS/RI crew last weekend and used their PDP-12 to format
some LINCtapes. At least we have some freshly formatted, known good,
LINCtapes for the TC12 debugging.

Jay, we are interested in anything PDP-12 related that we don't have.

The PDP-12 is described here:
http://www.ricomputermuseum.org/Home/equipment/dec-pdp-12

Details on the PDP-12 restoration process are here:
http://www.ricomputermuseum.org/Home/equipment/dec-pdp-12/dec-pdp-12-restoration

-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM

[Michael Thompson]

I used my PDP-8/e at home to test the RX8E controller and the RX01 floppies
that came with the PDP-12. Both worked OK.

We found a bad SP380 on a M7102 board in the DW8E the Omnibus expansion
chassis. This would not let the SKIP instructions work with the RX8E, RK05,
or PC8E. Once we replaced the SP380 we were able to boot OS/8 from an RX01
floppy. This may be the only PDP-12 to ever do that.

-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM (tony duell)

[David Gesswein]

On Tue, Oct 13, 2015 at 08:32:49PM -0400, Michael Thompson wrote:
> > What exactly do you mean by 'glitches'? Are these on a TTL level signal,
> > an analogue
> > output of the read amplifer, or what?
> >
> 
> You can see the logic analyzer trace of many of the TC12 signals here.
> 
> 
> The labels at the far left of the image include the backplane slot and pin
> number for the probe location. The signals were TTL level by the time the
> logic analyzer saw them.
> 
Have you hooked up a digital scope to the read amplifier and seen if the
analog waveform has problems when the glitches occur? Seeing both the analog 
and the digital output would help see where the signal is going wrong.

The other is if you have enough memory and channels in your test equipment 
you can trigger off a signal indicating that the block number was missed 
then look back to see how the block number was wrong. If you have it a 
trigger out from the logic analizer can trigger a digital scope to capture 
at the same time to see the head amplifier signal.

Re: PDP-12 Restoration at the RICM

[william degnan]

Did you ever speak with anyone at System Source (Bob) about their PDP 12?
Maybe they'd be interested in collaborating.  http://museum.syssrc.com/

On Tue, Oct 13, 2015 at 10:54 AM, Paul Koning 
wrote:

>
> > On Oct 12, 2015, at 9:16 PM, Rich Alderson
>  wrote:
> >
> > ...
> > The M tracks are longitudinally encoded (6-bit values chosen such that
> they
> > read the same as NRZ backwards and forwards for DECtape, 4-bit values for
> > LINCtape) to predefine blocks (cf. disk sectors) for data.
>
> More precisely: it's Manchester encoding, not NRZ.  The result is that
> mark track codes are complemented and reversed end for end if you read them
> in the opposite order.
>
> The code choices are such that this process (obverse complement) produces
> another code word with the right meaning for this spot of the tape in that
> direction.  So "in the data field of the block" reads the same in both
> directions.  But "block start" in one direction reads as "block end" in the
> other, which is just the result you want.
>
> The DECtape patent (3,387,293 -- on bitsavers among other places)
> describes this very nicely.
>
> paul
>
>


-- 
Bill

Re: PDP-12 Restoration at the RICM

[Paul Koning]

> On Oct 12, 2015, at 9:16 PM, Rich Alderson  
> wrote:
> 
> ...
> The M tracks are longitudinally encoded (6-bit values chosen such that they
> read the same as NRZ backwards and forwards for DECtape, 4-bit values for
> LINCtape) to predefine blocks (cf. disk sectors) for data.

More precisely: it's Manchester encoding, not NRZ.  The result is that mark 
track codes are complemented and reversed end for end if you read them in the 
opposite order.

The code choices are such that this process (obverse complement) produces 
another code word with the right meaning for this spot of the tape in that 
direction.  So "in the data field of the block" reads the same in both 
directions.  But "block start" in one direction reads as "block end" in the 
other, which is just the result you want.

The DECtape patent (3,387,293 -- on bitsavers among other places) describes 
this very nicely.

paul

RE: PDP-12 Restoration at the RICM

[Rich Alderson]

From: Paul Koning
Sent: Tuesday, October 13, 2015 7:55 AM

>> On Oct 12, 2015, at 9:16 PM, Rich Alderson >
>> wrote:

>> ...
>> The M tracks are longitudinally encoded (6-bit values chosen such that
>> they read the same as NRZ backwards and forwards for DECtape, 4-bit
>> values for LINCtape) to predefine blocks (cf. disk sectors) for data.

> More precisely: it's Manchester encoding, not NRZ.  The result is that
> mark track codes are complemented and reversed end for end if you read
> them in the opposite order.

OK, what I had readily to hand was the TC02 DECtape Control maintenance
manual (from the PDP-9 series, DEC-09-I3CD-D), where page 2-3 states:

Data is recorded by the Manchester method in which a prerecorded
timing track synchronizes read/write operations.  When writing on
the tape, the write amplifiers supply the maximum current in either
one direction or the other (non-return to zero, NRZ).

So yes, you're correct to observe that NRZ is not as important as Manchester
in a description of *reading* the data.  Thank you for the correction.

Rich

Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

RE: PDP-12 Restoration at the RICM (tony duell)

[Michael Thompson]

>
> Date: Mon, 12 Oct 2015 18:29:11 +
> From: tony duell <a...@p850ug1.demon.co.uk>
> Subject: RE: PDP-12 Restoration at the RICM
>
> > We swapped the TU56 and TU55 drives between the PDP-12 and the PDP-8/I.
> We
>
> Does the TU55 work correctly on the 8/I ?
>

Yes, it works perfectly. It even worked OK after we put it back in the 8/I.


> > The TU55 behaved a little better than the TU56, and sometimes would
> > actually boot OS/8. We continued chasing the issue and found glitches on
> > data channel 3. We have swapped every module and cable that relates to
> data
>
> What exactly do you mean by 'glitches'? Are these on a TTL level signal,
> an analogue
> output of the read amplifer, or what?
>

You can see the logic analyzer trace of many of the TC12 signals here.
<https://4310b1a9-a-11c96037-s-sites.googlegroups.com/a/ricomputermuseum.org/home/Home/equipment/dec-pdp-12/dec-pdp-12-restoration/LINCtape_Track-3_Problem.jpg?attachauth=ANoY7crnX8o5yLYK_UhrFx_58_SY0L1ogEtncsO6od4NhnEtVA9JazEEolMQZqGO4o8Z5l_z2g8-Bba6EX1OkRVrjpjutMp_JDMRoWSoMRZk6PnpOdywwKqxjdnHEdFO3Roux9LqFkmKG7oqalE7c8EUL-2ecJb99ZQuUsPvbz7I1oZJPppz8zWCG0174_en4Hm5e2Aqc1vzjESaq6SdUyJ9EDKQIRP_uBsR8lw9sq2DYaIUJk1MxHv2K9YoiWaFgm3V0hfE6T3syLwKBtA6GaoNIv667JwhR0fgf6B-FTXrGeWow5TmVfA%3D=0>

The labels at the far left of the image include the backplane slot and pin
number for the probe location. The signals were TTL level by the time the
logic analyzer saw them.

Have you looked for glitches on the other data channels?
>

Tracks 1 & 2 look fine.  We swapped the probes for track 2 & 3 just to make
sure that it wasn't a logic analyzer problem. A 'scope connected to the
differential signals shows the same track 3 glitches. The glitches were
present with the TU55 and the TU56 tape drives. We used different control
and data cables for the TU55 and TU56. We swapped the G882 modules between
tracks, and from the TC01 in the PDP-8/I and did not see a change. We
swapped the W603 module in slot F16, the R107 in F12, and the W512 in F13.
The LTR WRITE ON L signal is inactive and stable. We tried several tapes,
including ones formatted and written by DEC and the glitches are present on
track 3.

-tony
>
-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM (tony duell)

[Jon Elson]

On 10/13/2015 07:32 PM, Michael Thompson wrote:


Tracks 1 & 2 look fine.  We swapped the probes for track 2 & 3 just to make
sure that it wasn't a logic analyzer problem. A 'scope connected to the
differential signals shows the same track 3 glitches. The glitches were
present with the TU55 and the TU56 tape drives. We used different control
and data cables for the TU55 and TU56. We swapped the G882 modules between
tracks, and from the TC01 in the PDP-8/I and did not see a change. We
swapped the W603 module in slot F16, the R107 in F12, and the W512 in F13.
The LTR WRITE ON L signal is inactive and stable. We tried several tapes,
including ones formatted and written by DEC and the glitches are present on
track 3.


OK, so the drive must have a head amplifier and a comparator 
(sometimes called a slicer in tape technology) to convert 
the amplified analog signal to a digital one.  Have you 
swapped the read amps and comparator cards?  (Sounds like 
yes, above.) Have you looked at the analog signals?  it is 
possible a defect in the tape head is causing the read 
signal to be different than what should be seen.  Looking at 
the amplified analog signal might give some hint at the 
behavior.  (Don't bother trying to look at the raw tape head 
signal, it will be really tiny.)  I'm not sure where the 
read amps and slicer are, whether they are in the control or 
the drive. (Seems like the read amp HAS to be in the drive, 
though, for noise immunity reasons.)


Jon

RE: PDP-12 Restoration at the RICM

[tony duell]

> We swapped the TU56 and TU55 drives between the PDP-12 and the PDP-8/I. We

Does the TU55 work correctly on the 8/I ? 

> The TU55 behaved a little better than the TU56, and sometimes would
> actually boot OS/8. We continued chasing the issue and found glitches on
> data channel 3. We have swapped every module and cable that relates to data

What exactly do you mean by 'glitches'? Are these on a TTL level signal, an 
analogue
output of the read amplifer, or what? 

Have you looked for glitches on the other data channels? 

> channel 3, but have not been able to fix the glitches. The glitches are
> there with both the TU55 and the TU56, so the problem is in the TC12
> controller.

IIRC this thing has 3 data channels, so is channel 3 on the outside of the 
head/tape?
Could it be some external interference that happens to be picked up most 
strongly
by that head winding?

-tony

Re: PDP-12 Restoration at the RICM

[Michael Thompson]

>
> Date: Sun, 11 Oct 2015 18:44:54 -0500
> From: Jay Jaeger <cu...@charter.net>
> Subject: Re: PDP-12 Restoration at the RICM
>
> Don't forget about the other more remote possibilities:  cables,
> backplane, bad wrap, supply voltages at the actual card(s) for the
> mis-behaving channel, etc.
>
> JRJ
>

We used different control and data cables for the TU55 and the TU56 drives
and observed the same track 3 bad behavior.

The backplane appears to be in good shape.

My scope had a little trouble looking at 10-15mV signals in differential
mode using the math functions, but we looked at the head signals going into
the track 3 amplifier, and they looked reasonable.

The power supply voltages at the cards are within spec. The track
amplifiers are supposed to be differential, so they should be fairly immune
to power supply noise. We plan to connect a lab supply to the backplane
near the track cards and adjust it slightly higher than the PDP-12 power
supply. That should clean up any 60Hz noise on the power. Maybe that will
help?

We have swapped everything else between the tracks, including the logic
analyzer probe, and the issue always stays with track 3. Maybe it is a
backplane wiring problem?

-- 
Michael Thompson

RE: PDP-12 Restoration at the RICM

[Rich Alderson]

From: tony duell
Sent: Monday, October 12, 2015 11:29 AM

>> We swapped the TU56 and TU55 drives between the PDP-12 and the PDP-8/I. We

> Does the TU55 work correctly on the 8/I ? 

>> The TU55 behaved a little better than the TU56, and sometimes would actually
>> boot OS/8. We continued chasing the issue and found glitches on data channel
>> 3. We have swapped every module and cable that relates to data

> What exactly do you mean by 'glitches'? Are these on a TTL level signal, an
> analogue output of the read amplifer, or what?

> Have you looked for glitches on the other data channels? 

>> channel 3, but have not been able to fix the glitches. The glitches are
>> there with both the TU55 and the TU56, so the problem is in the TC12
>> controller.

> IIRC this thing has 3 data channels, so is channel 3 on the outside of the
> head/tape?  Could it be some external interference that happens to be picked
> up most strongly by that head winding?

DECtape and LINCtape (same medium, wound opposite directions on the reel) are
10 tracks across.  These are pairwise connected serially to produce 5 signals,
called T (timing), M (mark), and 1, 2, and 3.  The T tracks are outermost, the
M tracks are next inward from the T tracks, and the tracks making up 1, 2, & 3
are non-adjacent:

T  M  1  2  3  1'  2'  3'  M'  T'

The M tracks are longitudinally encoded (6-bit values chosen such that they
read the same as NRZ backwards and forwards for DECtape, 4-bit values for
LINCtape) to predefine blocks (cf. disk sectors) for data.

So neither of the tracks which make up channel 3 is on the outside of the tape.

Rich


Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Re: PDP-12 Restoration at the RICM

[Michael Thompson]

We swapped the TU56 and TU55 drives between the PDP-12 and the PDP-8/I. We
found that the TU56 uses a double-sided paddle card for the control signals
and the TU55 uses a single-sided paddle-card. The TC12 tape controller in
the PDP-12 will work with either tape drive if you have the right cable. We
borrowed a control and data cable from the PDP-8/I. The TU56 in the PDP-12
was wired for +5V, but can use +10V or +5V. The TU55 needs just 50ma of
+10V, so we ran a wire from a +10V backplane pin to the TU55. After these
modifications the TU55 operated correctly in the PDP-12.

The TU55 behaved a little better than the TU56, and sometimes would
actually boot OS/8. We continued chasing the issue and found glitches on
data channel 3. We have swapped every module and cable that relates to data
channel 3, but have not been able to fix the glitches. The glitches are
there with both the TU55 and the TU56, so the problem is in the TC12
controller.

We put the TU56 back in the PDP-12, and the TU55 back in the PDP-8/I. The
TU56 behaves worse than the TU55, but that may be due to the timing
adjustments in the TU56. I have to make the same adjustments in my personal
TU56, so by next I will know how to adjust the TU56 in the PDP-12.

We are running out of things to try for debugging the TC12 controller in
the PDP-12. At this point we are really stumped as to why the TC12 doesn't
work correctly. We are going to try a few remaining ideas like running the
TC12 from a laboratory power supply.

We would welcome any ideas that you have.

On Sun, Aug 16, 2015 at 10:00 AM, Michael Thompson <
michael.99.thomp...@gmail.com> wrote:

> We did a lot more debugging on the TC12 LINCtape controller.
>
> We saw a 500ns glitch in the LMU MOTION signal that corresponded to a
> short slowdown in tape speed. We will investigate this next week.
>
> We entered the LINC instruction to check a single block (0707) in the left
> switches and a block number (0777-) in the right switches. When we
> pressed the DO key it should go to that block on the LINCtape. With large
> block numbers (07xx) and with the tape positioned half way through the tape
> it worked OK. With lower block numbers it sometimes could not find the
> block and searched back-and-forth on the tape. The logic analyzer showed
> that the block numbers were correct in a sequence of several blocks, and
> then it will read a bad block number. The TC12 would tell the TU55 to turn
> around, it would read a good block number, realize that it was going the
> wrong direction, and turn the tape around. It would then read a good block
> number, and then a bad block number, and turn around.
>
> At this point we don't think that we are working with bad tapes, but the
> problem might be in either the TU56 tape drive, or the TC12 LINCtape
> controller. We see bad behavior in both devices so we will do as Charles
> Lasner suggested and swap a TU55 and TU56 between the PDP-12 and the
> PDP-8/I. This will let us test the TU56 with a known good TC01 LINCtape
> controller, and test a known good TU55 with a questionable TC12 LINCtape
> controller.
>
> We ran the A-to-D converter test and were rewarded with a display on the
> VR14 that showed correct operation of the knobs and A-to-D converters.
>
> --
> Michael Thompson
>



-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM

[Christian Gauger-Cosgrove]

On 11 October 2015 at 10:42, Michael Thompson
 wrote:
> We are running out of things to try for debugging the TC12 controller in
> the PDP-12. At this point we are really stumped as to why the TC12 doesn't
> work correctly. We are going to try a few remaining ideas like running the
> TC12 from a laboratory power supply.
>
> We would welcome any ideas that you have.
>
I'm most assuredly not an expert, and have zero clue what I'm talking about...


But have you checked that the wire wrap on the backplane is all good?
Perhaps Some of the backplane wrap has gotten damaged and that's why
the TC12 isn't working correctly.


Cheers,
Christian
-- 
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.

Re: PDP-12 Restoration at the RICM

[Mike Ross]

I have no constructive input to share - except the strong memory of
the bloke who maintained my pdp-12s for 25 years before I collected
them saying that the TC12 was an "absolute bugger" and the hardest
part of the machine to troubleshoot! Good luck and don't feel bad
about having a hard time with it!

Mike

On Mon, Oct 12, 2015 at 3:42 AM, Michael Thompson
 wrote:
> We swapped the TU56 and TU55 drives between the PDP-12 and the PDP-8/I. We
> found that the TU56 uses a double-sided paddle card for the control signals
> and the TU55 uses a single-sided paddle-card. The TC12 tape controller in
> the PDP-12 will work with either tape drive if you have the right cable. We
> borrowed a control and data cable from the PDP-8/I. The TU56 in the PDP-12
> was wired for +5V, but can use +10V or +5V. The TU55 needs just 50ma of
> +10V, so we ran a wire from a +10V backplane pin to the TU55. After these
> modifications the TU55 operated correctly in the PDP-12.
>
> The TU55 behaved a little better than the TU56, and sometimes would
> actually boot OS/8. We continued chasing the issue and found glitches on
> data channel 3. We have swapped every module and cable that relates to data
> channel 3, but have not been able to fix the glitches. The glitches are
> there with both the TU55 and the TU56, so the problem is in the TC12
> controller.
>
> We put the TU56 back in the PDP-12, and the TU55 back in the PDP-8/I. The
> TU56 behaves worse than the TU55, but that may be due to the timing
> adjustments in the TU56. I have to make the same adjustments in my personal
> TU56, so by next I will know how to adjust the TU56 in the PDP-12.
>
> We are running out of things to try for debugging the TC12 controller in
> the PDP-12. At this point we are really stumped as to why the TC12 doesn't
> work correctly. We are going to try a few remaining ideas like running the
> TC12 from a laboratory power supply.
>
> We would welcome any ideas that you have.
>
> On Sun, Aug 16, 2015 at 10:00 AM, Michael Thompson <
> michael.99.thomp...@gmail.com> wrote:
>
>> We did a lot more debugging on the TC12 LINCtape controller.
>>
>> We saw a 500ns glitch in the LMU MOTION signal that corresponded to a
>> short slowdown in tape speed. We will investigate this next week.
>>
>> We entered the LINC instruction to check a single block (0707) in the left
>> switches and a block number (0777-) in the right switches. When we
>> pressed the DO key it should go to that block on the LINCtape. With large
>> block numbers (07xx) and with the tape positioned half way through the tape
>> it worked OK. With lower block numbers it sometimes could not find the
>> block and searched back-and-forth on the tape. The logic analyzer showed
>> that the block numbers were correct in a sequence of several blocks, and
>> then it will read a bad block number. The TC12 would tell the TU55 to turn
>> around, it would read a good block number, realize that it was going the
>> wrong direction, and turn the tape around. It would then read a good block
>> number, and then a bad block number, and turn around.
>>
>> At this point we don't think that we are working with bad tapes, but the
>> problem might be in either the TU56 tape drive, or the TC12 LINCtape
>> controller. We see bad behavior in both devices so we will do as Charles
>> Lasner suggested and swap a TU55 and TU56 between the PDP-12 and the
>> PDP-8/I. This will let us test the TU56 with a known good TC01 LINCtape
>> controller, and test a known good TU55 with a questionable TC12 LINCtape
>> controller.
>>
>> We ran the A-to-D converter test and were rewarded with a display on the
>> VR14 that showed correct operation of the knobs and A-to-D converters.
>>
>> --
>> Michael Thompson
>>
>
>
>
> --
> Michael Thompson



-- 

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

PDP-12 Restoration at the RICM

[Michael Thompson]

The Maintenance Manual-II describes the procedures for checking and
adjusting the TC12 timing. It needs a lot more notes about using the Auto
Restart speed settings. This facility allows you to put the processor in
Single Step and have the Continue button automatically pressed ad a
controllable rate. If the rate is set too high you will see the LTD ACIP
Delay activate twice and measure a delay that is more than twice real value.

Most of the delays are controlled by M307 One Shot flip-chips. These boards
have Fairchild 9601 ICs in them. We didn't have any spares, so we bought
some on eBay just in case...

The TC12 has extensive maintenance capabilities and will let the processor
simulate just about any condition in the TC12. With a short toggle-in
program we were able to check all of the basic timing signals LTT TP0 L,
LTT TP2 L, LTT TP3 L, and LTT TP4 L signals. We adjusted LTD XTLK H from
9.15 us to 9.5 us according to the written notes in the maintenance manual,
where the spec was 9 us. We adjusted LTD TTOK, LTD TAPE FAIL Delay, LTD
ACIP Delay, and the Mark Clock.

Unfortunately none of these adjustments made any difference, and the
LINCtapes still misbehave.


-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM

[Jay Jaeger]

On 8/17/2015 1:51 PM, Rich Alderson wrote:

 From: Jay Jaeger
 Sent: Sunday, August 16, 2015 3:18 PM
 
 On 8/16/2015 9:00 AM, Michael Thompson wrote:
 
 We did a lot more debugging on the TC12 LINCtape controller.
 
 Second gut hunch is that it would be hard to see how the drive could
 cause this UNLESS the TC12 uses one side of the redundant tape channels
 in one direction, and the other side in the other direction.
 
 Not possible.  The *drive* wire-ORs the redundant channels, before the
 data goes into (or after it comes out of) the controller.  *That's* the
 redundancy.  When reading in the reverse direction, only the mark tracks
 on a DECtape read the same way backwards as forwards; LINCtape uses a
 different set of markers.
 

Well, not exactly a wired or, per my TU56 manual, but yeah point taken.
 At least on the TU56 the head windings are connected in series,
resulting in the *analog* sum.  (A wired or didn't quite make sense to
me - it wouldn't really be redundant, so I looked it up).

But it brings me back to my original point - I don't see how this could
be the drive unless the block number in question always involves a
particular channel on the tape.

JRJ

RE: PDP-12 Restoration at the RICM

[Rich Alderson]

From: Jay Jaeger
Sent: Sunday, August 16, 2015 3:18 PM

On 8/16/2015 9:00 AM, Michael Thompson wrote:

 We did a lot more debugging on the TC12 LINCtape controller.

 Second gut hunch is that it would be hard to see how the drive could
 cause this UNLESS the TC12 uses one side of the redundant tape channels
 in one direction, and the other side in the other direction.

Not possible.  The *drive* wire-ORs the redundant channels, before the
data goes into (or after it comes out of) the controller.  *That's* the
redundancy.  When reading in the reverse direction, only the mark tracks
on a DECtape read the same way backwards as forwards; LINCtape uses a
different set of markers.

Rich

Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputermuseum.org

http://www.LivingComputerMuseum.org/

Re: PDP-12 Restoration at the RICM

[Michael Thompson]

We did a lot more debugging on the TC12 LINCtape controller.

We saw a 500ns glitch in the LMU MOTION signal that corresponded to a short
slowdown in tape speed. We will investigate this next week.

We entered the LINC instruction to check a single block (0707) in the left
switches and a block number (0777-) in the right switches. When we
pressed the DO key it should go to that block on the LINCtape. With large
block numbers (07xx) and with the tape positioned half way through the tape
it worked OK. With lower block numbers it sometimes could not find the
block and searched back-and-forth on the tape. The logic analyzer showed
that the block numbers were correct in a sequence of several blocks, and
then it will read a bad block number. The TC12 would tell the TU55 to turn
around, it would read a good block number, realize that it was going the
wrong direction, and turn the tape around. It would then read a good block
number, and then a bad block number, and turn around.

At this point we don't think that we are working with bad tapes, but the
problem might be in either the TU56 tape drive, or the TC12 LINCtape
controller. We see bad behavior in both devices so we will do as Charles
Lasner suggested and swap a TU55 and TU56 between the PDP-12 and the
PDP-8/I. This will let us test the TU56 with a known good TC01 LINCtape
controller, and test a known good TU55 with a questionable TC12 LINCtape
controller.

We ran the A-to-D converter test and were rewarded with a display on the
VR14 that showed correct operation of the knobs and A-to-D converters.

-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM

[Jay Jaeger]

On 8/16/2015 9:00 AM, Michael Thompson wrote:
 We did a lot more debugging on the TC12 LINCtape controller.
 
 We saw a 500ns glitch in the LMU MOTION signal that corresponded to a short
 slowdown in tape speed. We will investigate this next week.
 
 We entered the LINC instruction to check a single block (0707) in the left
 switches and a block number (0777-) in the right switches. When we
 pressed the DO key it should go to that block on the LINCtape. With large
 block numbers (07xx) and with the tape positioned half way through the tape
 it worked OK. With lower block numbers it sometimes could not find the
 block and searched back-and-forth on the tape. The logic analyzer showed
 that the block numbers were correct in a sequence of several blocks, and
 then it will read a bad block number. The TC12 would tell the TU55 to turn
 around, it would read a good block number, realize that it was going the
 wrong direction, and turn the tape around. It would then read a good block
 number, and then a bad block number, and turn around.
 

Just a gut hunch, based on the symptoms.  Could you have a bit pick or
drop in the block number in the TC12?  Given the behavior, one might bet
on a bit pick.  Perhaps intermittent.

Second gut hunch is that it would be hard to see how the drive could
cause this UNLESS the TC12 uses one side of the redundant tape channels
in one direction, and the other side in the other direction.

Will be interesting to hear what you really find.

JRJ

Re: PDP-12 Restoration at the RICM

[Michael Thompson]

When we first powered up the PDP-12 the main fuse for the VR12 display
blew. A replacement fuse did the same. We thought that the brown goo in the
bottom of the chassis had leaked from the high-voltage power supply, and
the high-voltage power supply is directly connected to the input, so that
was the first suspect.

We bench tested the high-voltage power supply using a Variac on the input.
With a 10VAC input there was no output at all. Increasing the input voltage
did not change the missing output voltage.

I hate to mention this but...

The two capacitors in the voltage-doubler circuit are connected in series
between the output lead and ground. We connected a current limited lab
power supply to the output lead and ground and slowly increased the voltage
while watching the current draw. With the voltage stable the current draw
was a few microamps. We increased the output voltage of the power supply to
the 64VDC max, disconnected the power supply, and measured the voltage
across the caps. It very slowly decreased, so maybe the caps were OK.

We reconnected the Variac to the input and with 10VAC the high-voltage
power supply had a 1000VDC output. We put 10x 500kOhm resistors in series
across the output and increased the Variac voltage. By measuring the
voltage across one resistor we could see that the output was more than
10,000VDC. The resistors started smoking so we knew that we had a lot of
high-voltage available.

So, once again the magic of reforming capacitors saves another piece of
equipment.

-- 
Michael Thompson

RE: PDP-12 Restoration at the RICM

[tony duell]

 
 We reconnected the Variac to the input and with 10VAC the high-voltage
 power supply had a 1000VDC output. We put 10x 500kOhm resistors in series
 across the output and increased the Variac voltage. By measuring the
 voltage across one resistor we could see that the output was more than
 10,000VDC. The resistors started smoking so we knew that we had a lot of
 high-voltage available.

Wait a second! Are you sure those capacitors are electrolytics, because I am 
almost sure
they are oil-filled paper types. I have never seen an electrolytic with a 
voltage rating of
5000V or so. And they would not be very high capacitance in that circuit.

I've worked on the VR14, and the EHT module in that is similar (transformer + 
voltage 
doubler. It's an oil-filled can, the capacitors are certainly not 
electrolytics. 

Incidentally the oil may well be polychlorinated biphenyl based, if you are 
worried about
such things (FWIW a friend who worked on _large_ transformers told me the amount
in a VR14 EHT can is not going to do me any harm unless I do something very 
silly with 
it. Just wash your hands well if you get any on them).


 So, once again the magic of reforming capacitors saves another piece of
 equipment.

You can't reform non-electrolytic capacitors. More likely they are leaky paper 
types and you
are drying them out.

-tony

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Dave G4UGM]

 -Original Message-
 From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck
 Guzis
 Sent: 15 June 2015 18:25
 To: gene...@classiccmp.org; discuss...@classiccmp.org:On-Topic and Off-
 Topic Posts
 Subject: Re: using new technology on old machines. Was: PDP-12 Restoration
 at the RICM
 
 On 06/14/2015 12:41 PM, Simon Claessen wrote:
  as long as it is done in a way that it can be restored to its
  original, i have no problems in using newer technology in older
  machines. we have a alix sbc build into our tek 4002a for
  demonstrational purpouses, all done without damaging or altering the
 original machine.
 
 I'm a bit more pragmatic.  Whatever it takes to get something running, I'll do
 it.  For me, that's the entire point of having the old stuff around.  
 Otherwise,
 a non-working box is scarcely better than any other piece of antique e-
 waste. 

I think so long as the machine isn't unique then I think this is a reasonable 
approach to take.

 If there's an accurate emulation available on modern hardware, I'll
 use that rather than play with some old, cranky piece of iron.
 

That can be fun to.

 Others may certainly have different opinions.
 

I think you have to be pragmatic. I have now finished my Baby Baby Video here:-

https://youtu.be/OGcAmrFoRrY

Its pretty much cycle accurate...

 --Chuck
 

Dave
G4UGM

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Jay Jaeger]

Not all EE's have the same education with regard to how semiconductors
function.  When I was in school I took a class in semiconductor physics
- an entire semester on how the wee beasties function - more than most EEs.

The prof., Henry Guckel, told an interesting story about an advanced IBM
computer he did some work on (not sure if it was the ACS or one of the
9x models).  The clock ran really fast, and they were had all kinds of
problems with propagation delays - for which their typical cure was to
add delay lines - to the point where it slowed down the machine so much
that they actually had to back off the clock some. He also didn't like
computer programmers very much.

Another related story: a pre-requisite for the class was a modern
physics class - which was horribly taught, by a prof. the physics
department.  During the 2nd class or so, Prof. Guckel noticed a lot of
deer in headlights looks, and stopped.  After commenting that the
material should have been largely review, he asked when and from whom we
had taken the modern physics class - and 3/4 of the class had taken the
class from the same prof. during the previous 12 months.  After
realizing that class had been a disaster, Prof. Guckel spent the next 4
lectures re-teaching most of that entire-semester class - and doing a
really good job of it - preparing his own notes and everything, before
proceeding through the rest of the class.  Really tough course.

On 7/13/2015 6:18 AM, Tor Arntsen wrote:

 
 I think I'm reasonably well into the pragmatic camp (ref. Chuck G.'s
 post). But one point about 555s and Arduinos is that I couldn't build
 a 555 more easily than I could build the MCU on an Arduino board (a
 more relevant comparision might be a 555 vs a Propeller chip) -
 they're all black boxes to me. Even a transistor, to some extent - I
 know exactly how it works, well, as much as any other EE anyway, but I
 couldn't build one. Or a vacuum tube..
 

Re: PDP-12 Restoration at the RICM

[Michael Thompson]

We spent a few more hours on the PDP-12 today...

With the machine just powered on the stack 0/1 regulator output was 20.04V.
With tune3 running in field 1 and testing field 0 the stack 0/1 regulator
output was 19.93.
No memory errors were reported.

When the voltage was adjust up to 22.5 and down to 19.96 we saw a few
failures.
We split the voltage range and adjusted the regulator output voltage to
21.3.
No errors were observed when testing field 0 or field 1.

We successfully loaded and ran 10 passes of:
MAINDEC-08-D1B1 Memory Address test.
MAINDEC-08-D1B2 Memory Address test.
MAINDEC-08-D07B-D Random ISZ test.

We ran these diags without errors
MAINDEC-12-D0GA-A_Tape_Quickie
MAINDEC-12-D8AB Relay Register Test

-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM

[Michael Thompson]

The LINK indicator light on the front panel of the PDP-12 failed two weeks
ago. The indicator light bulb failed, briefly shorted, and destroyed the
transistor that turns the indicator on. An new transistor and bulb, and all
is well.

We have been chasing a transient problem in the PDP-12 core memory for a
few weeks. We checked the timing last week, and it was OK. This time we
checked the core voltage and it was a little low. We increased the core
memory power supply voltage until the checkerboard starting working without
errors. Next time we will explore the high and low limits of the core
voltage to find a reasonable center voltage for both core stacks.

The next step is to run all of the processor diagnostics and make sure that
everything is works. If the diags run OK, it is time to fix the TU56 tape
drive and see if the drive and controller work.

We visited the RCS/RI crew today to look at their LINC-8 and both PDP-12s.
Both PDP-12s are earlier than ours. One has floating-point and an RK05. The
other has a really interesting RAM buffered AD converter.

-- 
Michael Thompson

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Alexander Schreiber]

On Mon, Jun 15, 2015 at 10:53:33PM +0200, Pontus Pihlgren wrote:
 On Mon, Jun 15, 2015 at 04:53:01PM +, tony duell wrote:
  
   I also think it is in the spirit of the computer - using what is available
   to fix a problem at hand. I think the arduino was overkill when an attiny
   (smaller, easier to hide) would probably serve just as well.
  
  Would you put plastic handles on a piecc of antique furniture? Would you 
  make the seatboard for an antique longcase clock from MDF? 
  Both are easily reversable, BTW.
 
 No but I would put an electric heater in a steam engine if it meant 
 restoration would progress faster.
 
 (yes, feel free to lecture me how big that heater would have to be...)

That has been done before for production purposes. I kid you not.

Happened in Switzerland during WW2. Due to the war, coal was a bit in short
supply, but Switzerland already back then had plenty of (hydro-) electric
power, including on the railway grid. So they converted a few steam
locomotives to steam-electric by replacing the firebox with electric
heaters. IIRC it was only a few locomotives and they were mostly used
for shunting work.

Kind regards,
Alex.
-- 
Opportunity is missed by most people because it is dressed in overalls and
 looks like work.  -- Thomas A. Edison

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Jarratt RMA]

(I would change the subject line, but I am not sure how to do it in my
ISP's web mail client)

As far as I know XH558 will be permanently stationed at Finningley after
this year's flying season is completed. The full details are here:
http://www.vulcantothesky.org/, including dates of flypasts and displays.

Regards

Rob

On 17 June 2015 at 12:16, Christian Gauger-Cosgrove 
captainkirk...@gmail.com wrote:

 On 17 June 2015 at 05:09, Huw Davies huw.dav...@kerberos.davies.net.au
 wrote:
  Funny I was discussing just this pair of planes last night - I last saw
 them fly in 1971 at RAF Shawbury. Of course they were both in active
 service then and I remember watching the Lightning do a supersonic pass
 with much joy.
 
 Off topic for a moment but, do you know perchance what's going to
 happen to XH558 at the end of this year? I've never had a chance to
 see a flying Vulcan, and it's too bad I won't ever get to see one (nor
 did I get to see the awesome display of both of he flight worthy
 Lancasters flying together last year...).


  Getting a little closer to the topic at hand, eventually parts will no
 longer be available for older computers so the decision will have to be
 made to either retire them or use more modern components to keep them
 going. Somewhat ironically the ones that can be maintained in ‘original'
 condition for longer may be the mechanical ones where replacement parts
 could be fabricated whereas valves and SSI TTL may not be able to be
 economically produced.
 
 The point you raise is comparable to the fact that we'vve basically
 flown the life out of the last Avro Vulcan, meanwhile here in my home
 town we're still managing to keep an Avro Lancaster flying after all
 these years.


 Also, I realize anyone can infer where I live based on the statements
 in this e-mail, hah.


 Cheers,
 Christian
 --
 Christian M. Gauger-Cosgrove
 STCKON08DS0
 Contact information available upon request.

Re: Windows and devices - was Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 17, 2015, at 10:50 , Toby Thain t...@telegraphics.com.au wrote:
 Here's a cute gotcha I hit this week:
 
 - Have a running Windows 8.1 machine with PS/2 keyboard.
 - Shut it down, start up with only USB keyboard.
 - Shut down and boot again with PS/2 keyboard atached.
 - Windows ignores it (although BIOS flashes lights normally, etc).
 - Registry change (found by google)  reboot brings it back to life.
 
 Can't imagine how many good keyboards were dumpster'd over that one.

Working in the GPS industry, I became all too familiar with how Windows can't 
tell the difference between a Microsoft Serial BallPoint and a 4800 baud NMEA 
stream.

-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Alexander Schreiber]

On Mon, Jun 15, 2015 at 10:14:18PM -0700, Mark J. Blair wrote:
 
  On Jun 15, 2015, at 21:59, tony duell a...@p850ug1.demon.co.uk wrote: Even
  though there are at least 4 different USB connectors
 
 Ok, you got me there! When I was working for a GPS startup, I used mini-B on
 everything I designed with USB (always devices, never hosts, and no need for
 USB OTG). Then we got bought by a cell phone company and now everything's a
 godawful mix of mini-B and micro-B, with OTG thrown in there, too. Grrr!

Well, micro-B is the better choice since it is designed for more plug
cycles than mini-b, designed to minimize wear on the socket and instead
wear out the (cheap, easy to replace) cable and it actually locks in the
socket, so is much less likely to slip out.

I'm cursing everytime some device comes with a mini-B connector these days
instead of micro-B.

  IMHO USB got round the problem of null-modem cables by making them
  impossible. Which to me is not an improvement. I guess USB is OK when it
  works (like plugging in a memory stick) but a right pain to debug when it
  doesn't. And having read the standard there is much I dislike about it.
 
 Maybe this isn't the best time or place for this particular rant, but in my
 opinion, Windows' implementation of USB is fundamentally broken. It's a
 mouse, you stupid computer! You shouldn't need to spend a minute or more
 installing a new device driver for it! And you shouldn't need to install the
 driver yet again if I poke it in a different hole than I did last time! Every
 other *** OS on the planet is smart enough to say Oh, a mouse! I know
 how to use those! within a handful of milliseconds!

Windows does what (haven't used a Windows box for a long time)? Now that
is retarded. I'm used to my systems (Linux, *BSD) just going oh, this is
a keyboard/mouse, no problem, I can handle this and stuff quietly works.

Kind regards,
   Alex.
-- 
Opportunity is missed by most people because it is dressed in overalls and
 looks like work.  -- Thomas A. Edison

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 16, 2015, at 06:46, tony duell a...@p850ug1.demon.co.uk wrote:
 
 Again, I wonder if the data retention time decreases as the number of bits
 per device increases. Intuitively it should. Mind you, any SD card is probably
 going to be more reliable than a real TU58 tape now :-)

I think that paper tape, used outdoors on a rainy day, is likely to be more 
reliable than a real TU58 tape. :)

-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[tony duell]

 
  I am of course counting all the transistors inside that chip.
 
 Well, that was obvious. But it raises an interesting point, today you
 can cram a whole computer in the footprint of the simplest DIP carrier.
 For the same price point and same reliablity. Is it then overkill if you
 choose to use thousands of those transistor over using just 10 ?

Is it as reliable, though? You will get no argument from me that the _same 
design_
is more reliable the more 'LSI' it is -- that is a processor as a single chip 
is more
reliable than the same design in TTL which in turn is more reliable than the 
same design
in discrete transistors. But when you compare different designs, I am not 
conviced. My 
experience is that I have had to replace many more LSI ICs than TTL and many 
more TTL chips
than transistors (power transistors, choppers, line output transistors 
excpeted!). I am not at all 
convinced that a microcontroller is as reliable as a 555 timer. After all, 
microcontrollers presumably
store their firmware in some kind of flash memory which is going to suffer from 
bit-rot. A 555
doesn't.

 Similar to Mark's example of using just the first bytes of an SD card
 with gigabytes of storage.

Again, I wonder if the data retention time decreases as the number of bits
per device increases. Intuitively it should. Mind you, any SD card is probably
going to be more reliable than a real TU58 tape now :-)

-tony

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Chris Elmquist]

Choosing the larger card is, IMO, the right answer because you don't
actually waste the space, you extend the life significantly because the
wear leveling will spread your 256K across the entire flash region.
The larger that region, the less often you re-write the same cells,
thereby extending the life of all the cells.

Chris

On Monday (06/15/2015 at 03:06PM -0700), Mark J. Blair wrote:
 
  On Jun 15, 2015, at 14:56 , Dave G4UGM dave.g4...@gmail.com wrote:
  
  A friend of mine refused to buy modern SD Cards because there was no way he
  was going to fill them. Trouble is that although smaller SD cards were
  available they were way more expensive (being discontinued and therefore
  rare and valuable).. He struggled with buying a larger card only to waste
  most of it, or buy a smaller one and waste his money
 
 
 I had that same mental hangup when thinking about how I might design an SD 
 card based TU58 emulator in the same form factor as a TU58 cartridge (still 
 on my to-do list, by the way). How was I going to implement the user 
 interface? It's not like there's much room for an LCD or buttons on the edge 
 of a TU58 cartridge. Then it finally hit me: SD cards are cheaper than TU58 
 cartridges ever were. So why not just use the first 256k, ignore the rest of 
 the card, and swap cards exactly the way one would swap TU58 cartridges, with 
 one image on each card? Yeah, 99% of the card is wasted, but they're 
 presently cheap and plentiful enough to ignore that.
 
 Ok, I might actually have the emulator read a file from a DOS filesystem 
 rather than using the first 256k of raw blocks. But it'll probably just be a 
 fixed filename with no controls to select a different one, and the 
 expectation that an entire (cheap, plentiful) SD card will be devoted to each 
 tape image. At least this way, other things can also be on the card, so it 
 doesn't need to be wasted if not needed.
 
 Your friend should understand that the larger card that he would be wasting 
 probably has less silicon in it than the older one with less capacity. The 
 cheapest card that is reliable, fast enough and large enough for his task is 
 the best one to get, even if it's much larger than he needs. Just one of the 
 weird parts of the Moore's Law curve!
 
 Hmm, this reminds me that back in the day, floppy disks were expensive. We 
 have it easy with cheap and plentiful SD cards nowadays. But maybe my 
 perspective is different as an employed adult rather than a teenager with 
 limited funds? Anyway, SD cards seem to be cheap enough to be nearly 
 disposable nowadays.
 
 -- 
 Mark J. Blair, NF6X n...@nf6x.net
 http://www.nf6x.net/

-- 
Chris Elmquist

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 16, 2015, at 07:36, Chris Elmquist chr...@pobox.com wrote:
 So, now you have to use a Type A to Type A cable to connect this box to
 your computer.
 
 That is just really, really messed up and I honestly tried to make it
 right but it was like pushing a rope.
 
 I hope my friends will visit me in prison.

Sounds to me like you are more of a victim than a perpetrator here. Isn't there 
some OSHA regulation against USB A to A cables? :)


-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Alexandre Souza]

Again, I wonder if the data retention time decreases as the number of bits
per device increases. Intuitively it should. Mind you, any SD card is 
probably

going to be more reliable than a real TU58 tape now :-)
I think that paper tape, used outdoors on a rainy day, is likely to be more 
reliable than a real TU58 tape. :)


   You got a thumbs-up! (In Brazil we call it Joinha) :)

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Chris Elmquist]

On Tuesday (06/16/2015 at 07:24AM -0700), Mark J. Blair wrote:
 
  On Jun 16, 2015, at 06:46, tony duell a...@p850ug1.demon.co.uk wrote:
  
  Again, I wonder if the data retention time decreases as the number of bits
  per device increases. Intuitively it should. Mind you, any SD card is 
  probably
  going to be more reliable than a real TU58 tape now :-)
 
 I think that paper tape, used outdoors on a rainy day, is likely to be more 
 reliable than a real TU58 tape. :)

I can vouch for that.

-- 
Chris Elmquist

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Chris Elmquist]

On Tuesday (06/16/2015 at 07:43AM -0700), Mark J. Blair wrote:
 
  On Jun 16, 2015, at 07:36, Chris Elmquist chr...@pobox.com wrote:
  So, now you have to use a Type A to Type A cable to connect this box to
  your computer.
  
  That is just really, really messed up and I honestly tried to make it
  right but it was like pushing a rope.
  
  I hope my friends will visit me in prison.
 
 Sounds to me like you are more of a victim than a perpetrator here. Isn't 
 there some OSHA regulation against USB A to A cables? :)

well, you know, it's a different world these days.  You go to these places
down dark alleys, surrounded by shady characters and you can buy them.

-- 
Chris Elmquist

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Chris Elmquist]

On Monday (06/15/2015 at 10:14PM -0700), Mark J. Blair wrote:
 
  On Jun 15, 2015, at 21:59, tony duell a...@p850ug1.demon.co.uk wrote:
  Even though there are at least 4 different USB connectors
 
 Ok, you got me there! When I was working for a GPS startup, I used mini-B on 
 everything I designed with USB (always devices, never hosts, and no need for 
 USB OTG). Then we got bought by a cell phone company and now everything's a 
 godawful mix of mini-B and micro-B, with OTG thrown in there, too. Grrr!

I'm going straight to hell because I recently participated in a customer
design where they wanted to change the USB function on a device we
designed for them from host mode to device mode but they didn't want to
change the connector on the box.

So, now you have to use a Type A to Type A cable to connect this box to
your computer.

That is just really, really messed up and I honestly tried to make it
right but it was like pushing a rope.

I hope my friends will visit me in prison.

Chris
-- 
Chris Elmquist

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Fred Cisin]

On Tue, 16 Jun 2015, tony duell wrote:

Actually, IIRC a USB A male-female cable violates the spec...


The spec forbids extending the cable further?


Or should the spec forbid absolutely any cable,
with absolutely any USB connector on either end?

RE: PDP-12 Restoration at the RICM

[Michael Thompson]

 Date: Mon, 15 Jun 2015 19:42:42 -0400
 From: Michael Thompson michael.99.thomp...@gmail.com
 To: cctech cct...@classiccmp.org

 The M452 creates a 220 Hz clock for the TTY transmitter and a 880 Hz clock
 for the TTY receiver.
 The M405 for the DP12-B serial port generated a clock that is 16x the baud
 rate which is then divided by an M216 module.

 Michael Thompson


Just to prolong this discussion...

The PDP-12 came to us with an M452 for the 110 baud TTY console and a
home-made adjustable baud rate module for the second serial port. The
adjustable baud rate generator was made by the original user of the system
in the early 80s, and is just a crystal, rotary switch and a Fairchild
4702. I ordered a replacement Intersil IM4702 so we can repair the module.
The original owner doesn't remember ever having an M405 for the second
serial port.

-- 
Michael Thompson

RE: PDP-12 Restoration at the RICM

[tony duell]

 The M452 creates a 110 Hz clock for the TTY transmitter and a 880 Hz clock
 for the TTY receiver.

Does it? The prints I have show the 2 outputs with a factor of 4 (not 8) in 
frequency.

 The M405 for the DP12-B serial port generated a clock that is 16x the baud
 rate which is then divided by an M216 module.

So for 110 baud (which you say you have), the M405 is running at 1760Hz? I do
not believe that for one moment!

-tony

RE: PDP-12 Restoration at the RICM

[Michael Thompson]

 Date: Mon, 15 Jun 2015 05:01:36 +
 From: tony duell a...@p850ug1.demon.co.uk
 Subject: RE: PDP-12 Restoration at the RICM (tony duell)
 
  Tony, thank you for your offer to supply replacement M452 Variable Clock
  modules for the console. We already have one jumpered for 110 baud for
 the
  Teletype. The other two M452 modules should be jumpered for 9600 baud and
  38400 baud. The second serial port uses a M405 Crystal Clock module with
 a

 Do you want 3 separate modules, or one switchable, or what?

  different pinout and clock outputs than the M452. We don't have any of
  these modules, so the three that we need should be jumpered for 110 baud,
  9600 baud, and 38400 baud. The shipping address for the RICM is on the
 WWW
  page.

 Hang on. I thought the M405 was just a crystal oscillator without a
 divider. Are
 you sure there is no extra division on other modules? 110Hz is very slow
 for
 a crystal oscillator, after all.

 -tony


The M452 creates a 110 Hz clock for the TTY transmitter and a 880 Hz clock
for the TTY receiver.
The M405 for the DP12-B serial port generated a clock that is 16x the baud
rate which is then divided by an M216 module.

Michael Thompson

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Pontus Pihlgren]

On Tue, Jun 16, 2015 at 04:32:23AM +, tony duell wrote:
 
 Oh come on. You yourself said you are here to learn. This module
 is hardly complicatated.

Well, you got me there :)

/P

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Pontus Pihlgren]

On Tue, Jun 16, 2015 at 04:28:16AM +, tony duell wrote:
 
 I am of course counting all the transistors inside that chip.

Well, that was obvious. But it raises an interesting point, today you 
can cram a whole computer in the footprint of the simplest DIP carrier. 
For the same price point and same reliablity. Is it then overkill if you 
choose to use thousands of those transistor over using just 10 ?

Similar to Mark's example of using just the first bytes of an SD card 
with gigabytes of storage.

 This is one of my main dislikes with USB. It is so complicated that you 
 have to use a microcontroller. Unlike any of the more sane interfaces that
 you can implement with simple logic if you want to.

I completely agree, I detest USB for various reasons. However consider 
this:

As I said, I have used the Teensy to interface an old 11/70 front panel 
with simh. One possibility I've considered is to let the Teensy present 
itself as USB mass storage when first attached to a PC. On this mass 
storage I would put a special version of simh and 11/70 system images. 
When this version of simh is run, it will instruct the Teensy to present 
itself as the front panel interface instead.

So, I can bring my 11/70 front panel to any friend with a suitable 
computer and show him/her the ropes :)

Admittedly, the Teensy doesn't have enough storage for this, but it 
shows the flexibilty of USB coupled with a microcontroller.

/P

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Johnny Billquist]

While I agree that as long as things can be restored it's not a real 
problem, I'm surprised that not more people consider it a serious overkill.


We're talking about putting in a rather complex computer to generate a 
baud rate. Are people really that handicapped when it comes to building 
hardware nowadays? Are people aware how easy baud generators are?
We're essentially talking about a clock, which can be found as a 
component (various oscillators), and then dividing it. There used to be 
chips around which did that part, and I would expect it to not be that 
hard to find some if you looked today. Many UARTs even comes with a 
clock divider built in.


And that is it. When I build various Z80 systems, I usually had a Z80 
CTC included, which I used for generating the baud rates.


Johnny

On 2015-06-15 02:52, Joe Lenox wrote:

I also think it is in the spirit of the computer - using what is available
to fix a problem at hand. I think the arduino was overkill when an attiny
(smaller, easier to hide) would probably serve just as well.

If you have the ttl logic bits lying around and know how to use them, fine.
Still would probably need debugging.
On Jun 14, 2015 2:41 PM, Simon Claessen sim...@dds.nl wrote:


as long as it is done in a way that it can be restored to its original, i
have no problems in using newer technology in older machines. we have a
alix sbc build into our tek 4002a for demonstrational purpouses, all done
without damaging or altering the original machine.

On 14-06-15 17:25, tony duell wrote:



  The ripple on the power supplies is still going lower as we put more run

time on the system. The power supplies are now within spec.



Capacitors reforming naturally?

  Warren made an Arduino based programmable baud rate generator that works

for both serial ports. After some debugging, it works nicely.



I am sorry, but I find that obscene!. To use more components than the
rest of the machine
(probably) just for the baud rate clock is ridiculous. IMHO if you are
going to modify a
vintage machine, particularly one as rare as a PDP12, you should use the
components
that were available at the time. It's not as if a programmable buad rate
generator is hard
to make from TTL either. In fact given the Arduino thing needed 'some
debugging' it might
well have taken less time to do it in hardware.

-tony



--
Met vriendelijke Groet,

Simon Claessen
drukknop.nl




--
Johnny Billquist  || I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip - B. Idol

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Pontus Pihlgren]

On Mon, Jun 15, 2015 at 11:52:28AM +0200, Johnny Billquist wrote:
 
 We're talking about putting in a rather complex computer to generate
 a baud rate. Are people really that handicapped when it comes to
 building hardware nowadays?

Speaking for myself, yes.

I have a Teensy 2.0 lying at my desk, it's Arduino compatible. I have 
the development environemnt set up, a small solderless breadboard and 
proper power supply. I could probably whip up the C-code for a flicking 
pin on and off in the correct pace in very little time.

Now, if the alternative is reading up on crystals, oscillators, dividers 
and related support chips, figure out where to buy and then wait for the 
parts to ship, which option do you think I will choose?


Of course, I think it's overkill and anachronistic and I'd rather use 
the Teensy for something else, so I'd probably read up and do it right 
too.

/P

Re: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 14, 2015, at 06:53, Michael Thompson michael.99.thomp...@gmail.com 
 wrote:
 
 Dave Tumey sent us a new rubber hammer for the Teletype. This is the part
 that pushes the print drum against the ribbon and paper to print. These are
 newly molded parts that have not been available for decades. Works very
 nicely.

I should order one, too. I'm presently using the rubber tubing over the hammer 
kludge.

 The donor dropped off the work table that goes in front of the PDP-12. We
 need to loosen the rusted feet so it will fit under the front panel.

That sounds like a good excuse for more pictures!

-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

RE: PDP-12 Restoration at the RICM (tony duell)

[tony duell]

 Tony, thank you for your offer to supply replacement M452 Variable Clock
 modules for the console. We already have one jumpered for 110 baud for the
 Teletype. The other two M452 modules should be jumpered for 9600 baud and
 38400 baud. The second serial port uses a M405 Crystal Clock module with a

Do you want 3 separate modules, or one switchable, or what?

 different pinout and clock outputs than the M452. We don't have any of
 these modules, so the three that we need should be jumpered for 110 baud,
 9600 baud, and 38400 baud. The shipping address for the RICM is on the WWW
 page.

Hang on. I thought the M405 was just a crystal oscillator without a divider. Are
you sure there is no extra division on other modules? 110Hz is very slow for
a crystal oscillator, after all.

-tony

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Pontus Pihlgren]

Indeed, you use what is at hand and what you are comfortable with.

/P


On Sun, Jun 14, 2015 at 09:41:42PM +0200, Simon Claessen wrote:
 as long as it is done in a way that it can be restored to its
 original, i have no problems in using newer technology in older
 machines. we have a alix sbc build into our tek 4002a for
 demonstrational purpouses, all done without damaging or altering the
 original machine.
 
 On 14-06-15 17:25, tony duell wrote:
 
 The ripple on the power supplies is still going lower as we put more run
 time on the system. The power supplies are now within spec.
 
 Capacitors reforming naturally?
 
 Warren made an Arduino based programmable baud rate generator that works
 for both serial ports. After some debugging, it works nicely.
 
 I am sorry, but I find that obscene!. To use more components than the rest 
 of the machine
 (probably) just for the baud rate clock is ridiculous. IMHO if you are going 
 to modify a
 vintage machine, particularly one as rare as a PDP12, you should use the 
 components
 that were available at the time. It's not as if a programmable buad rate 
 generator is hard
 to make from TTL either. In fact given the Arduino thing needed 'some 
 debugging' it might
 well have taken less time to do it in hardware.
 
 -tony
 
 
 -- 
 Met vriendelijke Groet,
 
 Simon Claessen
 drukknop.nl

using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Simon Claessen]

as long as it is done in a way that it can be restored to its original, i have no problems in using newer technology in older machines. we have a alix sbc build into our tek 4002a 
for demonstrational purpouses, all done without damaging or altering the original machine.


On 14-06-15 17:25, tony duell wrote:



The ripple on the power supplies is still going lower as we put more run
time on the system. The power supplies are now within spec.


Capacitors reforming naturally?


Warren made an Arduino based programmable baud rate generator that works
for both serial ports. After some debugging, it works nicely.


I am sorry, but I find that obscene!. To use more components than the rest of 
the machine
(probably) just for the baud rate clock is ridiculous. IMHO if you are going to 
modify a
vintage machine, particularly one as rare as a PDP12, you should use the 
components
that were available at the time. It's not as if a programmable buad rate 
generator is hard
to make from TTL either. In fact given the Arduino thing needed 'some 
debugging' it might
well have taken less time to do it in hardware.

-tony



--
Met vriendelijke Groet,

Simon Claessen
drukknop.nl

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Joe Lenox]

I also think it is in the spirit of the computer - using what is available
to fix a problem at hand. I think the arduino was overkill when an attiny
(smaller, easier to hide) would probably serve just as well.

If you have the ttl logic bits lying around and know how to use them, fine.
Still would probably need debugging.
On Jun 14, 2015 2:41 PM, Simon Claessen sim...@dds.nl wrote:

 as long as it is done in a way that it can be restored to its original, i
 have no problems in using newer technology in older machines. we have a
 alix sbc build into our tek 4002a for demonstrational purpouses, all done
 without damaging or altering the original machine.

 On 14-06-15 17:25, tony duell wrote:


  The ripple on the power supplies is still going lower as we put more run
 time on the system. The power supplies are now within spec.


 Capacitors reforming naturally?

  Warren made an Arduino based programmable baud rate generator that works
 for both serial ports. After some debugging, it works nicely.


 I am sorry, but I find that obscene!. To use more components than the
 rest of the machine
 (probably) just for the baud rate clock is ridiculous. IMHO if you are
 going to modify a
 vintage machine, particularly one as rare as a PDP12, you should use the
 components
 that were available at the time. It's not as if a programmable buad rate
 generator is hard
 to make from TTL either. In fact given the Arduino thing needed 'some
 debugging' it might
 well have taken less time to do it in hardware.

 -tony


 --
 Met vriendelijke Groet,

 Simon Claessen
 drukknop.nl

RE: PDP-12 Restoration at the RICM (tony duell)

[Michael Thompson]

 Date: Sun, 14 Jun 2015 15:25:08 +
 From: tony duell a...@p850ug1.demon.co.uk
 To: General Discussion: On-Topic Posts cct...@classiccmp.org
 Subject: RE: PDP-12 Restoration at the RICM

  Warren made an Arduino based programmable baud rate generator that works
  for both serial ports. After some debugging, it works nicely.

 I am sorry, but I find that obscene!. To use more components than the rest
 of the machine
 (probably) just for the baud rate clock is ridiculous. IMHO if you are
 going to modify a
 vintage machine, particularly one as rare as a PDP12, you should use the
 components
 that were available at the time. It's not as if a programmable buad rate
 generator is hard
 to make from TTL either. In fact given the Arduino thing needed 'some
 debugging' it might
 well have taken less time to do it in hardware.

 -tony


Tony, thank you for your offer to supply replacement M452 Variable Clock
modules for the console. We already have one jumpered for 110 baud for the
Teletype. The other two M452 modules should be jumpered for 9600 baud and
38400 baud. The second serial port uses a M405 Crystal Clock module with a
different pinout and clock outputs than the M452. We don't have any of
these modules, so the three that we need should be jumpered for 110 baud,
9600 baud, and 38400 baud. The shipping address for the RICM is on the WWW
page.

-- 
Michael Thompson

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Dave G4UGM]

I don't think it is over kill. If you want over kill try this:-

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

and FPGA implementation of the Baby or SSEM which had 32x32 bits of RAM. The 
implementation uses around 1% of the Spartan 3E 1200K gates, and that includes 
the logic to generate the VGA which is around 50% of the circuit. I expect to 
get it on a 100K gate chip but that’s still over-kill.

I am also aware how HARD baud rate generator chips are. Firstly you need to 
know the multiplier, and then you need a crystal that can easily be divided. I 
looked on E-Bay UK and the cheapest dedicated baud rate generator was 10x the 
price of a Arduino Nano. Then I would need a crystal and the other bits to make 
the generator. I would expect the chip count on a dedicated baud rate generator 
board to exceed that of the Nano. Of course it is not original, but an 
authentic board would only use SSI TTL and where would one find that easily.

I personally think it is an appropriate cludge that allows de-bugging to 
continue and gives you time to work out what the best long term solution would 
be.

Dave

 -Original Message-
 From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Johnny
 Billquist
 Sent: 15 June 2015 10:52
 To: cctalk@classiccmp.org
 Subject: Re: using new technology on old machines. Was: PDP-12 Restoration
 at the RICM
 
 While I agree that as long as things can be restored it's not a real problem, 
 I'm
 surprised that not more people consider it a serious overkill.
 
 We're talking about putting in a rather complex computer to generate a baud
 rate. Are people really that handicapped when it comes to building hardware
 nowadays? Are people aware how easy baud generators are?
 We're essentially talking about a clock, which can be found as a component
 (various oscillators), and then dividing it. There used to be chips around
 which did that part, and I would expect it to not be that hard to find some if
 you looked today. Many UARTs even comes with a clock divider built in.
 
 And that is it. When I build various Z80 systems, I usually had a Z80 CTC
 included, which I used for generating the baud rates.
 
   Johnny
 
 On 2015-06-15 02:52, Joe Lenox wrote:
  I also think it is in the spirit of the computer - using what is
  available to fix a problem at hand. I think the arduino was overkill
  when an attiny (smaller, easier to hide) would probably serve just as well.
 
  If you have the ttl logic bits lying around and know how to use them, fine.
  Still would probably need debugging.
  On Jun 14, 2015 2:41 PM, Simon Claessen sim...@dds.nl wrote:
 
  as long as it is done in a way that it can be restored to its
  original, i have no problems in using newer technology in older
  machines. we have a alix sbc build into our tek 4002a for
  demonstrational purpouses, all done without damaging or altering the
 original machine.
 
  On 14-06-15 17:25, tony duell wrote:
 
 
The ripple on the power supplies is still going lower as we put
  more run
  time on the system. The power supplies are now within spec.
 
 
  Capacitors reforming naturally?
 
Warren made an Arduino based programmable baud rate generator
 that
  works
  for both serial ports. After some debugging, it works nicely.
 
 
  I am sorry, but I find that obscene!. To use more components than
  the rest of the machine
  (probably) just for the baud rate clock is ridiculous. IMHO if you
  are going to modify a vintage machine, particularly one as rare as a
  PDP12, you should use the components that were available at the
  time. It's not as if a programmable buad rate generator is hard to
  make from TTL either. In fact given the Arduino thing needed 'some
  debugging' it might well have taken less time to do it in hardware.
 
  -tony
 
 
  --
  Met vriendelijke Groet,
 
  Simon Claessen
  drukknop.nl
 
 
 
 --
 Johnny Billquist  || I'm on a bus
||  on a psychedelic trip
 email: b...@softjar.se ||  Reading murder books
 pdp is alive! ||  tryin' to stay hip - B. Idol

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mouse]

 We're talking about putting in a rather complex computer to generate
 a baud rate.  Are people really that handicapped when it comes to
 building hardware nowadays?

Speaking as someone who didn't do that, but might well have - it's not
a question of handicapped; it's a question of convenience, ease of
use, and suchlike.

Yes, I know how to build a BRG in hardware.  I've even done it, more or
less.  But if I want something fast, and I have a small SOC handy, I
may well use it: it's a lot easier to change the generated frequency in
more-or-less arbitrary ways (ie, other than just picking a different
tap off a divider chain), and it's quite possible the SOC is at readier
hand than the oscillator and divider.

Of course, if it's going to be there for more than the short term, I
probably will replace it once I've settled on a frequency.  But
initially?  Sure, I'll go with the complex way, for convenience and
flexibility.

I'm also likely to fire up a calculator program on a desktop computer
to add two five-digit numbers rather than reaching for pencil and paper
or a dedicated calculator.  Even though I'm hardly incapable of using
either of the latter.

When the more powerful tool is handy and its use carries no sigificant
downside, I see nothing wrong with overkill.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Chris Osborn]

On Jun 15, 2015, at 3:06 AM, Pontus Pihlgren pon...@update.uu.se wrote:

 On Mon, Jun 15, 2015 at 11:52:28AM +0200, Johnny Billquist wrote:
 
 We're talking about putting in a rather complex computer to generate
 a baud rate. Are people really that handicapped when it comes to
 building hardware nowadays?
 
 Speaking for myself, yes.
 
 I have a Teensy 2.0 lying at my desk, it's Arduino compatible. I have 
 the development environemnt set up, a small solderless breadboard and 
 proper power supply. I could probably whip up the C-code for a flicking 
 pin on and off in the correct pace in very little time.
 
 Now, if the alternative is reading up on crystals, oscillators, dividers 
 and related support chips, figure out where to buy and then wait for the 
 parts to ship, which option do you think I will choose?


Agreed. I really love the modern microcontrollers like the Arduino and tiny 
embedded computers with GPIO like the Raspberry Pi or Galileo because they make 
it so incredibly easy to turn a hardware problem into a software problem. And 
writing software is super easy, even if you’re not an expert. You can just keep 
trying another solution over and over and all you have to do is push a few keys 
on your keyboard.

--
Follow me on twitter: @FozzTexx
Check out my blog: http://insentricity.com

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[tony duell]

  Why not do it properly first time? What is the rush in bringing up a 
  classic computer? And for a test,
  use the TTL pulse generator you have on your bench.
 
 I don't have one. I have a lot of test equipment, but mostly for RF work. If 
 I needed to generate TTL pulses, I'd 
 probably pull out a microcontroller development board of some sort, because 
 that's what I have sitting around.

And you don't have any NPN transistors around? With one you could buffer the 
output of your sig-gen to 
TTL levels.

 
 No, I have neither 2N3904s nor NE555s in my spares. I could replace an M1 
 Carbine trigger spring on the spot, 

Amazing Those are about the most common components around. I think I buy 
2N3904s in lots of 1000, I use
so many of them

[...]

 capabilities, so not everybody will do things the same way that you do. 
 Should I criticize you for not having SAE 

FWIW I do have Bristol spline keys here. Needs for working on IBM and Friden 
machines for a start.

FWIW, this is not the miltary or firearms list, so I wouldn't expect people to 
necessarily have the 
equipment and spares for such things (if you do, fine). It is the classiccmp 
list, where some people, including
your good self restore the actual old machines. And yes, I think it is is 
reasonable to assume they will
have access to common (very common) electronic components.

-tony

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[tony duell]

 
  I am very worried that people would rather use a microcontroller than change
  a couple of passives. Can't anyone read a schematic and think
 
 Nope. I didn't know this hobby required a degree in electrical
 engineering.

Well it had better not. I don't have one

 By your criteria a lot of the rare stuf behind me would be in the
 dumpster because no-one qualified was arround.

Oh come on. You yourself said you are here to learn. This module
is hardly complicatated. OK, it is not obvious what some of the 
waveforms are (which is a good reason to put that board on the
bench -- it will run on its own -- and probe it with a 'scope. Being
an oscillator, all the waveforms are repetitive so _any_ 'scope
will do), but it is farily clear that it is an RC oscillator and that 
the time constant of a particular RC network is going to have 
an effect on the output frequency. So you change the capacitor
and probe with the 'scope again. And so on.

-tony


/P

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 15, 2015, at 21:28, tony duell a...@p850ug1.demon.co.uk wrote:
 As am I. I've learnt a heck of a lot since I started (there is a common myth
 that there is something magic about a processor. This hobby has taught
 me to understand quite a few at the gate level). And the day I stop learning
 is the day I am in a pine box.

In my opinion, the magic is inside the transistor. Once you bottle enough magic 
to make a good transistor, the rest is pretty straightforward. :)

 As an aside, I am not overly enamoured by the RPi. I think there are 
 possibly better alternatives like the Beagleboards (?) which I need to
 investigte.

Shockingly, I agree with you! The RPi is neat for what it is, but I have a 
mental hangup on openness, which the Beaglebone Black has more of (i.e., I 
think I could buy the main chip on it from DigiKey, unlike the Broadcom chip on 
the RPi. Not that I'm eager to route my own SDRAM bus... that's actually kind 
of hard, particularly with the open-source PCB tools I use for home projects). 
The BeagleBone also has lots more delicious IOs. 

 This is one of my main dislikes with USB. It is so complicated that you 
 have to use a microcontroller. Unlike any of the more sane interfaces that
 you can implement with simple logic if you want to.

I have a love/hate relationship with USB. I liked moving away from having to 
figure out which way the danged plugs were wired at both ends for any given 
pair of devices. But on the other hand, a UART is dirt simple to implement, and 
I still use them for debug ports even on vastly complex FPGA-based stuff. I 
don't see async serial dying off any time soon.

-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[tony duell]

 
  Unfortunately I believe you. Use at least a thousand times more components 
  than
  you need to.
 
 Actually it's just two, a Teensy and a usb cable. (Sorry, I couldn't
 resist).

I am of course counting all the transistors inside that chip.

 How do you suggest I learn? I believe you had a father that got you of
 to a good start and perhaps you even took a few classes.

My father was a chemist. He knew enough electronics to teach me things
like ohm's law, but certainly not digital electronics. And I have never done
any classes in electronics.

I learnt by : 

1) Reading every darn book I could find on electronics from the 1920s onwards

2) Experimenting. Soldering up circuits and finding out why they didn't work. 
Some
of the better educational kits like the Philips EE series helped in my younger 
days,
but alas you won't find those now.

3)Getting a minicomputer and investigating it. That means reading the printset, 
cliping
on a logic analyser, etc. 

 Certainly no excuse, but one of the main reasons I'm in this hobby is to
 learn! And boy have I learned a lot since I got started. I'm not at your

As am I. I've learnt a heck of a lot since I started (there is a common myth
that there is something magic about a processor. This hobby has taught
me to understand quite a few at the gate level). And the day I stop learning
is the day I am in a pine box.

 level yet.. but perhaps in a few years I'll be a tenth of the way there :)

 It might please you to hear that the Teensy I'm talking about is in a
 socket on a perfboard together with a handfull of 74165 and 74374 which
 I've wirewrapped in proper wirewrapping sockets. It will become a USB
 interface for my 11/70 front panel. The Teensy was the simplest/cheapest
 way to get a usb interface with lots of I/O pins. (Why usb? to get a
 connection to simh on one of those newfangled Pi-things)

As an aside, I am not overly enamoured by the RPi. I think there are 
possibly better alternatives like the Beagleboards (?) which I need to
investigte.

This is one of my main dislikes with USB. It is so complicated that you 
have to use a microcontroller. Unlike any of the more sane interfaces that
you can implement with simple logic if you want to.

-tony

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[tony duell]

  I am very worried that people would rather use a microcontroller than change
  a couple of passives. Can't anyone read a schematic and think
 
 The exact same argument could be made for somebody using an NE555 instead of 
 discrete transistors to blink an 
 LED, or discrete transistors instead of vacuum tubes to blink a neon glow 
 lamp. For that matter, I might call

Err, to blink a neon glow lamp you use _one_ resistor and _one_ capacitor and 
make use of the difference between
striking and maintaining voltages.

But that is not the point. The original design for this M452 baud rate clock is 
an RC oscillator. One that can
run at any reasonable frequency. When restoring a machine you should keep as 
much of the original design 
as possible. If you want to do a reversable change you should still change as 
little as possible. Since it 
appears you can change the buad rate just by changing a couple of passive 
components that's what
IMHO you should do.

-tony

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 15, 2015, at 21:59, tony duell a...@p850ug1.demon.co.uk wrote:
 Even though there are at least 4 different USB connectors

Ok, you got me there! When I was working for a GPS startup, I used mini-B on 
everything I designed with USB (always devices, never hosts, and no need for 
USB OTG). Then we got bought by a cell phone company and now everything's a 
godawful mix of mini-B and micro-B, with OTG thrown in there, too. Grrr!


 
 IMHO USB got round the problem of null-modem cables by making them 
 impossible. Which to me is 
 not an improvement. I guess USB is OK when it works (like plugging in a 
 memory stick) but a right pain
 to debug when it doesn't. And having read the standard there is much I 
 dislike about it.

Maybe this isn't the best time or place for this particular rant, but in my 
opinion, Windows' implementation of USB is fundamentally broken. It's a mouse, 
you stupid computer! You shouldn't need to spend a minute or more installing a 
new device driver for it! And you shouldn't need to install the driver yet 
again if I poke it in a different hole than I did last time! Every other 
*** OS on the planet is smart enough to say Oh, a mouse! I know how to use 
those! within a handful of milliseconds!

(Take deep, cleansing breaths, Mark.)

Ok, I feel better now. :)


-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 15, 2015, at 09:53 , tony duell a...@p850ug1.demon.co.uk wrote:
 
 
 I also think it is in the spirit of the computer - using what is available
 to fix a problem at hand. I think the arduino was overkill when an attiny
 (smaller, easier to hide) would probably serve just as well.
 
 Would you put plastic handles on a piecc of antique furniture? Would you 
 make the seatboard for an antique longcase clock from MDF? 
 Both are easily reversable, BTW.

Sure! Temporarily and reversibly, of course, and I'd hope to replace them with 
proper stuff when possible. But to bring up an old computer system right now, 
I'll kludge in what I have available to get it running. In that respect, an 
Arduino-based baud rate generator could be considered test equipment rather 
than a component.

 If you have the ttl logic bits lying around and know how to use them, fine.
 Still would probably need debugging.
 
 FWIW I have made programmable dividers on a couple of occasions recently
 (one was a 100/120 flash-per-second stroboscope, the other was the transmitter
 half of a modem to talk to TDDs). Both of them worked first time. I guess 
 it's just
 what I am used to.

Exactly. And for somebody who doesn't already have a full stock of TTL parts on 
hand, a different solution may present itself. I play with gear from WWII 
military radios up through thoroughly modern electronics. When I work on a WWII 
radio, it might be considered cheating to poke at it with my Fluke multimeter, 
Tek DSO, HP spectrum analyzer or HP synthesized signal generator (the latter 
two of which are slaved to my GPS-disciplined frequency standard), but those 
are the tools I have on hand, so those are the tools that I use.

-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[tony duell]

 
  Would you put plastic handles on a piecc of antique furniture? Would you
  make the seatboard for an antique longcase clock from MDF?
  Both are easily reversable, BTW.
 
 Sure! Temporarily and reversibly, of course, and I'd hope to replace them 
 with proper stuff when possible. But 
 to bring up an old computer system right now, I'll kludge in what I have 
 available to get it running. In that 
 respect, an Arduino-based baud rate generator could be considered test 
 equipment rather than a component.

Ah, 'there's not the time to do it properly, but there is the time to do it 
again'.

Why not do it properly first time? What is the rush in bringing up a classic 
computer? And for a test,
use the TTL pulse generator you have on your bench. Or even an NE555 astable 
(yes, with a decent capacitor
it is stable enough for a baud rate generator, I've used it). Heck, I've worked 
on machines that used a 
2 transistor astable multivibrator for the baud clock. Surely you have 2N3904s 
in the spares box?

Incidentally, if certain horologists heard you would use MDF in an antique 
clock, you would be
going home with a pendulum rod shoved where the sun don't shine ;-)

  If you have the ttl logic bits lying around and know how to use them, fine.
  Still would probably need debugging.
 
  FWIW I have made programmable dividers on a couple of occasions recently
  (one was a 100/120 flash-per-second stroboscope, the other was the 
  transmitter
  half of a modem to talk to TDDs). Both of them worked first time. I guess 
  it's just
  what I am used to.
 
 Exactly. And for somebody who doesn't already have a full stock of TTL parts 
 on hand, a different solution may 

'Full stock of TTL parts' ??? You make it sound like I am suggesting using 
lookahead carry generators,
parallel multipliers, Excess 3 to 1-of-n decoders and the like (all of which 
exist(ed) in TTL). No, I am suggesting
using some very common counter and gate ICs.

How are you going to fix a TTL-based machine like your 11/730 without spares 
and without knowing
what the ICs do?

 present itself. I play with gear from WWII military radios up through 
 thoroughly modern electronics. When I 
 work on a WWII radio, it might be considered cheating to poke at it with my 
 Fluke multimeter, Tek DSO, HP 
 spectrum analyzer or HP synthesized signal generator (the latter two of which 
 are slaved to my GPS-disciplined 
 frequency standard), but those are the tools I have on hand, so those are the 
 tools that I use.

It is cheating :-)

More seriously, tools are one thing. And had it been suggested that as a quick 
fix you took the TTL output
from a sig-gen or took the output and clipped it to TTL with a transistor 
buffer then that would IMHO be
reasonable (even if said sig-gen contained many times the number of components 
of the rest of the machine). 
But to make a custom solution that is over-complicated IMHO is the wrong way to 
do it. 

You might well inject your HP sig-gen into the mixer (first detector) stage of 
your WW2 radio to get it going
if the local oscillator had failed, or if you didn't have the right crystal, or 
whatever. But I hope you wouldn't
replace the valve (tube) based local oscillator in such a set with a digital 
synthesiser as a permanent 'repair'

-tony

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[tony duell]

 I also think it is in the spirit of the computer - using what is available
 to fix a problem at hand. I think the arduino was overkill when an attiny
 (smaller, easier to hide) would probably serve just as well.

Would you put plastic handles on a piecc of antique furniture? Would you 
make the seatboard for an antique longcase clock from MDF? 
Both are easily reversable, BTW.

 If you have the ttl logic bits lying around and know how to use them, fine.
 Still would probably need debugging.

FWIW I have made programmable dividers on a couple of occasions recently
(one was a 100/120 flash-per-second stroboscope, the other was the transmitter
half of a modem to talk to TDDs). Both of them worked first time. I guess it's 
just
what I am used to.

-tony

RE: FPGA tricks - Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Dave G4UGM]

 -Original Message-
 From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of ben
 Sent: 15 June 2015 17:18
 To: cctalk@classiccmp.org
 Subject: Re: FPGA tricks - Re: using new technology on old machines. Was:
 PDP-12 Restoration at the RICM
 
 On 6/15/2015 9:08 AM, Toby Thain wrote:
  On 2015-06-15 9:35 AM, Dave G4UGM wrote:
  I don't think it is over kill. If you want over kill try this:-
 
  https://www.youtube.com/watch?v=ALXax3Gydl8
 
  and FPGA implementation of the Baby or SSEM which had 32x32 bits of
  RAM. The implementation uses around 1% of the Spartan 3E 1200K gates,
  and that includes the logic to generate the VGA which is around 50% of
  the circuit. I expect to get it on a 100K gate chip but that’s still
  over-kill.
 
 
  Speaking of VGA, you might like this:
 
  http://www.fpgarelated.com/showarticle/42.php
 
  --Toby
 
 
 But alas the software does *not* support the older chips.

How old is old? I managed to get a copy of ISE10.1 downloaded, installed and 
running without phoning, ringing or otherwise jumping through hoops. That 
supports the Spartan 2 which has been obsolete for some time..  If you want to 
play with some Spartan 2 chips contact me off-line.

 You want to make a mod 5 years down the road, sorry we do not support
 that model any more. TTL needs to  be stock piled now for the next +50
 years.
 I finally got 18 bit FPGA computer (DE1) design I like, that is early 70's 
 speed.
 1.5 us core. What I am having problems is finding a good book on Operating
 Systems from that Era that is online, any one know a good book? I have
 software that I need to write.
 Ben.
 
 
 
 

Re: FPGA tricks - Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[ben]

On 6/15/2015 10:57 AM, Dave G4UGM wrote:

But alas the software does *not* support the older chips.

How old is old? I managed to get a copy of ISE10.1 downloaded,
installed and running without phoning, ringing or otherwise jumping
through hoops. That supports the Spartan 2 which has been obsolete
for some time..  If you want to play with some Spartan 2 chips
contact me off-line.


I use the other brand. I also program it in ADHL, that I can understand. 
I also use crash and burn debugging with paper listings,

Ben.

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[tony duell]

  We're talking about putting in a rather complex computer to generate
  a baud rate. Are people really that handicapped when it comes to
  building hardware nowadays?
 
 Speaking for myself, yes.

Unfortunately I believe you. Use at least a thousand times more components than
you need to.

 Now, if the alternative is reading up on crystals, oscillators, dividers
 and related support chips, figure out where to buy and then wait for the
 parts to ship, which option do you think I will choose?

In general this worries me if you are restoring a vintage minicomputer. How on
earth can you hope to fix a TTL-built CPU without knowing the common TTL chips
and without having a few on-hand?

-tony

Re: FPGA tricks - Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[ben]

On 6/15/2015 11:33 AM, Paul Koning wrote:



On Jun 15, 2015, at 1:28 PM, ben bfranc...@jetnet.ab.ca wrote:

On 6/15/2015 10:57 AM, Dave G4UGM wrote:

But alas the software does *not* support the older chips.

How old is old? I managed to get a copy of ISE10.1 downloaded,
installed and running without phoning, ringing or otherwise
jumping through hoops. That supports the Spartan 2 which has been
obsolete for some time..  If you want to play with some Spartan 2
chips contact me off-line.


I use the other brand. I also program it in ADHL, that I can
understand. I also use crash and burn debugging with paper
listings, Ben.


What’s ADHL?  I know VHDL and haven’t yet learned Verilog.  I once
used an old proprietary CPLD language with Lattice (Lattice-HDL???).
Very primitive and not particularly easy to use, not to mention too
limited for anything beyond little CPLDs.


That was Altera's programing language. Since I have the hardware here
I have no need to move to anything else. Mind you the hardware docs
are sparse, a few datasheets on the major chips.


VHDL and Verilog have the benefit of being standards, and at least
for VHDL there are open source tools available (ghdl) that work
well.


As soon as you get real hardware, every brand is different.

The nice thing about standards is that there are so many of them to 
choose from



paul

Ben.

Re: FPGA tricks - Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 15, 2015, at 09:18, ben bfranc...@jetnet.ab.ca wrote:
 But alas the software does *not* support the older chips.
 You want to make a mod 5 years down the road, sorry we do not
 support that model any more. TTL needs to  be stock piled
 now for the next +50 years.

Good point. Just as TTL needs to be stockpiled, I think we should be in a habit 
of archiving virtual machines containing development software installed in a 
compatible operating system, so the software can still hopefully be used long 
after the original machines are obsolete. Much like we often use SIMH now for 
maintenance tasks to help bring up old machines that no longer live in an 
ecosystem of similar machines.

-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 15, 2015, at 11:54 , tony duell a...@p850ug1.demon.co.uk wrote:
 Why not do it properly first time? What is the rush in bringing up a classic 
 computer? And for a test,
 use the TTL pulse generator you have on your bench.

I don't have one. I have a lot of test equipment, but mostly for RF work. If I 
needed to generate TTL pulses, I'd probably pull out a microcontroller 
development board of some sort, because that's what I have sitting around.

 Or even an NE555 astable (yes, with a decent capacitor
 it is stable enough for a baud rate generator, I've used it). Heck, I've 
 worked on machines that used a 
 2 transistor astable multivibrator for the baud clock. Surely you have 
 2N3904s in the spares box?

No, I have neither 2N3904s nor NE555s in my spares. I could replace an M1 
Carbine trigger spring on the spot, or a HMMWV taillamp housing, or most of the 
tubes in a 1950s US military vehicular radio, or an AR15 recoil buffer, or an 
Enfield Mk. 2 firing pin, or countless other things. I could test a diesel 
engine injector for pop-off pressure and slobber, or pull diagnostic codes from 
an M923's antilock air brake system, or check a transmitter for spurs up to 2.9 
GHz, or measure a TTL clock frequency to within 50 parts per trillion absolute 
accuracy. But I don't have a TTL signal generator. Not everybody has the same 
junkbox, background, interests, equipment or capabilities, so not everybody 
will do things the same way that you do. Should I criticize you for not having 
SAE grade 8 hardware on hand, or Bristo wrenches for working on a Collins PTO, 
or spare Packard connectors for a post-Korean vintage US military vehicle, or 
the right kind of grease for an M1 Garand bolt, or the special screwdriver for 
the tiny little center-drilled screws in a telephone patch plug, or an M1 
carbine gas piston plug wrench, all of which I have on hand? (No, I shouldn't, 
and I wouldn't.)


 Incidentally, if certain horologists heard you would use MDF in an antique 
 clock, you would be
 going home with a pendulum rod shoved where the sun don't shine ;-)

Well, maybe I'd educate them that Underwood and Remington Rand didn't just make 
typewriters before they got that pendulum rod in very far. ;)


-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 15, 2015, at 12:15 , tony duell a...@p850ug1.demon.co.uk wrote:
 
 I am very worried that people would rather use a microcontroller than change
 a couple of passives. Can't anyone read a schematic and think

The exact same argument could be made for somebody using an NE555 instead of 
discrete transistors to blink an LED, or discrete transistors instead of vacuum 
tubes to blink a neon glow lamp. For that matter, I might call somebody a 
slacker for blinking an LED with an NE555 instead of an LM3909. But LM3909s are 
no longer manufacturer or stocked. An NE555 only costs $.50 vs. about $1 for an 
ATtiny, but these days, folks under the age of 40 are a lot more likely to have 
an ATtiny (or more likely, an ATmega on an Arduino board) sitting on their 
desktop.


-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Pontus Pihlgren]

On Mon, Jun 15, 2015 at 04:55:57PM +, tony duell wrote:
 
 Unfortunately I believe you. Use at least a thousand times more components 
 than
 you need to.

Actually it's just two, a Teensy and a usb cable. (Sorry, I couldn't 
resist).

 
 In general this worries me if you are restoring a vintage 
 minicomputer. How on earth can you hope to fix a TTL-built CPU without 
 knowing the common TTL chips and without having a few on-hand?

How do you suggest I learn? I believe you had a father that got you of 
to a good start and perhaps you even took a few classes.

My father was great but knew very little about electronics. And TTL on 
the minicomputer level was way out of fashion when I went to school.

Certainly no excuse, but one of the main reasons I'm in this hobby is to 
learn! And boy have I learned a lot since I got started. I'm not at your 
level yet.. but perhaps in a few years I'll be a tenth of the way there :)

It might please you to hear that the Teensy I'm talking about is in a 
socket on a perfboard together with a handfull of 74165 and 74374 which 
I've wirewrapped in proper wirewrapping sockets. It will become a USB 
interface for my 11/70 front panel. The Teensy was the simplest/cheapest 
way to get a usb interface with lots of I/O pins. (Why usb? to get a 
connection to simh on one of those newfangled Pi-things)

Cheers,
Pontus.

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[tony duell]

 We're talking about putting in a rather complex computer to generate a
 baud rate. Are people really that handicapped when it comes to building
 hardware nowadays? Are people aware how easy baud generators are?

I've jsut turned up the M452 schematic. Has anyone else looked at it?

It's a expletive RC transistorised oscillator driving a /4 divider chain. 
Are you seriously telling me you don't have a junk box full of random R's and
C's and you can't change the timing components to get whatever rate you want
out of it? 

I am very worried that people would rather use a microcontroller than change
a couple of passives. Can't anyone read a schematic and think

-tony

RE: PDP-12 Restoration at the RICM (tony duell)

[tony duell]

 Tony, thank you for your offer to supply replacement M452 Variable Clock
 modules for the console. We already have one jumpered for 110 baud for the
 Teletype. The other two M452 modules should be jumpered for 9600 baud and
 38400 baud. The second serial port uses a M405 Crystal Clock module with a
 different pinout and clock outputs than the M452. We don't have any of
 these modules, so the three that we need should be jumpered for 110 baud,
 9600 baud, and 38400 baud. The shipping address for the RICM is on the WWW
 page.

I am happy to design and build (at least as prototypes) these boards for you. I 
will
give my time and components free of charge. All I ask is that you cover 
reasonable
travelling and accomodation expenses for me to install and test these modules.

-tony

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Pontus Pihlgren]

On Mon, Jun 15, 2015 at 04:53:01PM +, tony duell wrote:
 
  I also think it is in the spirit of the computer - using what is available
  to fix a problem at hand. I think the arduino was overkill when an attiny
  (smaller, easier to hide) would probably serve just as well.
 
 Would you put plastic handles on a piecc of antique furniture? Would you 
 make the seatboard for an antique longcase clock from MDF? 
 Both are easily reversable, BTW.

No but I would put an electric heater in a steam engine if it meant 
restoration would progress faster.

(yes, feel free to lecture me how big that heater would have to be...)

/P

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Pontus Pihlgren]

On Mon, Jun 15, 2015 at 01:59:11PM -0700, Mark J. Blair wrote:
 
 Big. VERY big. :)

 And one more thing (until the next thing comes to mind): I consider 
 this to be an enjoyable and level-headed debate, just in case anybody 
 gets the mistaken impression that I'm trying to come down hard on Tony 
 at all.

So far I feel we've been civil :) I too hope I'm not coming of to 
harsch.. I feel a bit cranky because its 25 degrees celsius in my 
workshop :/

Speaking of steam engines and boilers. I saw a 1918 Bucyrus steam shovel 
this weekend. Mostly rust, but under slooow restoration.

/P

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 15, 2015, at 14:56 , Dave G4UGM dave.g4...@gmail.com wrote:
 
 A friend of mine refused to buy modern SD Cards because there was no way he
 was going to fill them. Trouble is that although smaller SD cards were
 available they were way more expensive (being discontinued and therefore
 rare and valuable).. He struggled with buying a larger card only to waste
 most of it, or buy a smaller one and waste his money


I had that same mental hangup when thinking about how I might design an SD card 
based TU58 emulator in the same form factor as a TU58 cartridge (still on my 
to-do list, by the way). How was I going to implement the user interface? It's 
not like there's much room for an LCD or buttons on the edge of a TU58 
cartridge. Then it finally hit me: SD cards are cheaper than TU58 cartridges 
ever were. So why not just use the first 256k, ignore the rest of the card, and 
swap cards exactly the way one would swap TU58 cartridges, with one image on 
each card? Yeah, 99% of the card is wasted, but they're presently cheap and 
plentiful enough to ignore that.

Ok, I might actually have the emulator read a file from a DOS filesystem rather 
than using the first 256k of raw blocks. But it'll probably just be a fixed 
filename with no controls to select a different one, and the expectation that 
an entire (cheap, plentiful) SD card will be devoted to each tape image. At 
least this way, other things can also be on the card, so it doesn't need to be 
wasted if not needed.

Your friend should understand that the larger card that he would be wasting 
probably has less silicon in it than the older one with less capacity. The 
cheapest card that is reliable, fast enough and large enough for his task is 
the best one to get, even if it's much larger than he needs. Just one of the 
weird parts of the Moore's Law curve!

Hmm, this reminds me that back in the day, floppy disks were expensive. We have 
it easy with cheap and plentiful SD cards nowadays. But maybe my perspective is 
different as an employed adult rather than a teenager with limited funds? 
Anyway, SD cards seem to be cheap enough to be nearly disposable nowadays.

-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

RE: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Dave G4UGM]

A friend of mine refused to buy modern SD Cards because there was no way he
was going to fill them. Trouble is that although smaller SD cards were
available they were way more expensive (being discontinued and therefore
rare and valuable).. He struggled with buying a larger card only to waste
most of it, or buy a smaller one and waste his money

Dave Wade
G4UGM

 -Original Message-
 From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Mark J.
 Blair
 Sent: 15 June 2015 21:56
 To: General Discussion: On-Topic and Off-Topic Posts
 Subject: Re: using new technology on old machines. Was: PDP-12 Restoration
 at the RICM
 
 
  On Jun 15, 2015, at 13:46 , Pontus Pihlgren pon...@update.uu.se
 wrote:
 
  On Mon, Jun 15, 2015 at 04:55:57PM +, tony duell wrote:
 
  Unfortunately I believe you. Use at least a thousand times more
  components than you need to.
 
  Actually it's just two, a Teensy and a usb cable. (Sorry, I couldn't
  resist).
 
 LOL! I must admit that I used to scorn those durned kids using Arduinos to
do
 the job of a 555. But then I pulled my head out of my ass and realized
that
 times change, nowadays a microcontroller is as cheap and common
 component as a 555 was when I was a snotty kid, and the new-fangled
 maker movement with its Arduinos and serial-controlled addressable LEDs
 and conductive thread is keeping younger people designing things and
 making them instead of just being dumb consumers. It's all good stuff! And
 once I got a better idea of how much it costs to keep an engineer
breathing
 for an hour, I also realized that it often makes more sense to overkill
the heck
 out of a task with a $20 micro board than it would to spend even a half
hour
 longer doing it the right way.
 
 --
 Mark J. Blair, NF6X n...@nf6x.net
 http://www.nf6x.net/

Re: using new technology on old machines. Was: PDP-12 Restoration at the RICM

[Mark J. Blair]

 On Jun 15, 2015, at 14:27 , Robert Jarratt robert.jarr...@ntlworld.com 
 wrote:
 This particular thread has all the hallmarks of one that *could* descend
 into a flame war. Thank you for avoiding that!

I think we're doing ok. The same folks having a spirited debate in this thread 
are carrying on just fine together in other threads at the same time, so I 
don't think the fangs are being exposed. :)


-- 
Mark J. Blair, NF6X n...@nf6x.net
http://www.nf6x.net/

Re: PDP-12 Restoration at the RICM

[Chuck Guzis]

I'll add that if the Rubber Renue treatment is ineffective, you can have 
your platen rebuilt by JJ Short:


http://www.jjshort.com/typewriter-platen-repair.php

--Chuck

Re: PDP-12 Restoration at the RICM

[Chuck Guzis]

On 06/02/2015 05:09 AM, Michael Thompson wrote:


I sent him an email and asked about the hammer, and a source for paper and
ribbons.
The platen is hard as a rock, so we will need to do something about that
too.



There's some stuff called Rubber Renue sold for just that purpose. 
Basically, it's a mixture of methyl salicylate (oil of wintergreen) and 
xylol.  You brush it on and give it time (hours) to soak in.  Repeat if 
necessary.


http://www.mgchemicals.com/products/cleaners/specialty-cleaners/rubber-renue-408a/

I can attest to its working and the nice minty odor...


--Chuck

Re: PDP-12 Restoration at the RICM

[Cory Heisterkamp]

I'll add that I've had several platens and power rolls rebuilt by JJ Short and 
the service was top notch. -C

On Jun 4, 2015, at 5:07 PM, Chuck Guzis wrote:

 I'll add that if the Rubber Renue treatment is ineffective, you can have your 
 platen rebuilt by JJ Short:
 
 http://www.jjshort.com/typewriter-platen-repair.php
 
 --Chuck
 

RE: PDP-12 Restoration at the RICM

[Michael Thompson]

 Date: Mon, 1 Jun 2015 09:33:26 +0100
 From: Robert Jarratt robert.jarr...@ntlworld.com
 Subject: RE: PDP-12 Restoration at the RICM

 Yes, the new rubber hammers are available from David Tumey. I think he
 wants
 about $7 for 10 of them. I have a supply of them here in the UK for anyone
 that needs any.

 Regards

 Rob


Thanks Rob.

I sent him an email and asked about the hammer, and a source for paper and
ribbons.
The platen is hard as a rock, so we will need to do something about that
too.

-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM

[Cory Heisterkamp]

Michael,

Sounds like you're making some real progress. Next time you're near the ASR33, 
check the rubber hammer for the print cylinder. These have a tendency to self 
destruct and in doing so, destroy the cylinder itself...and they can go at 
anytime. There's a fellow on the Greenkeys that has tooled up and is producing 
replacements; same profile as the original and easy to install. Cheap 
insurance, really. -C


On May 31, 2015, at 8:08 AM, Michael Thompson wrote:

 We spent some time on the console Teletype that came with the PDP-12. The
 platen was nearly impossible to move, so the Line Feed did not work. We
 removed the platen, and found that the plastic in the bearing area had
 swollen and was binding. We sanded, cleaned, and lubricate the bearing
 surface and the platen now turns freely. On reassembly we found that none
 of the Control Characters like Line Feed or Bell would work in Local Mode. We
 fiddled for quite a while, but did not find a problem. We speculated that
 something got bent when it could not move the binding platen.
 
 We found a bad SN7474 E13 on the M706 Teletype Receiver flip-chip from the
 PDP-12. We will repair and test it next week.
 
 We borrowed the M706 Teletype receiver from the PDP-8/I and connected the
 Teletype to the PDP-12. We loaded and ran a toggle-in program that echos
 the keyboard to the printer. We were a little surprised when everything in
 the Teletype worked OK. We were even more surprised when the Teletype now
 worked correctly in local mode.
 
 We borrowed the console cable from the PDP-8/I and connected my laptop to
 the PDP-12. The terminal emulator worked correctly and echoed characters to
 the PDP-12 and back.
 
 We toggled in the RIM loader and then loaded the LBAA BIN loader from my
 laptop. We ran the BIN loader and loaded and ran the PDP-8/I Instruction
 Test #1. It actually works OK!
 
 We tried twice to load MAINDEC-8I-D02B-D Instruction Test #2, but failed
 both times. Running that diagnostic and others will be the project for next
 week.
 
 Al Kossow posted LOTS of PDP-12 manuals to Bitsavers. One manual includes
 the allowable ripple for the power supplies. They allow 3,000mV of ripple
 on the -30V supply for the core memory, so I guess that the 180mV that we
 measured two weeks ago is OK.
 
 On Mon, May 25, 2015 at 8:07 PM, Michael Thompson 
 michael.99.thomp...@gmail.com wrote:
 
 Today we pulled all of the M113 flip-chips and tested them because SN7474
 and SN7400 ICs seem to be a problem in these early DEC systems. The ones in
 slots J33 and K30 were bad. Replacing them fixed the problem with the JMP
 instruction. We did some more testing with the toggle-in programs and found
 that ISZ cleared the AC. Replacing the M119 in slot H28 fixed that. All of
 the toggle-in tests pass, so the processor is substantially functional.
 
 Core memory in field 1 with addresses X5XX didn't work. We replaced the
 G221 in slot D10 to fix that.
 
 We tried the ASR33 Teletype that came with the system. The mechanics were
 sticky from not being used for 30 years, but we got most of it free and
 working. We could send characters to the Teletype, but could not receive
 anything. The M706 receiver failed in the board tester. The spare is also
 broken, so we need to fix both.
 
 
 
 
 -- 
 Michael Thompson

Re: PDP-12 Restoration at the RICM

[Michael Thompson]

We spent some time on the console Teletype that came with the PDP-12. The
platen was nearly impossible to move, so the Line Feed did not work. We
removed the platen, and found that the plastic in the bearing area had
swollen and was binding. We sanded, cleaned, and lubricate the bearing
surface and the platen now turns freely. On reassembly we found that none
of the Control Characters like Line Feed or Bell would work in Local Mode. We
fiddled for quite a while, but did not find a problem. We speculated that
something got bent when it could not move the binding platen.

We found a bad SN7474 E13 on the M706 Teletype Receiver flip-chip from the
PDP-12. We will repair and test it next week.

We borrowed the M706 Teletype receiver from the PDP-8/I and connected the
Teletype to the PDP-12. We loaded and ran a toggle-in program that echos
the keyboard to the printer. We were a little surprised when everything in
the Teletype worked OK. We were even more surprised when the Teletype now
worked correctly in local mode.

We borrowed the console cable from the PDP-8/I and connected my laptop to
the PDP-12. The terminal emulator worked correctly and echoed characters to
the PDP-12 and back.

We toggled in the RIM loader and then loaded the LBAA BIN loader from my
laptop. We ran the BIN loader and loaded and ran the PDP-8/I Instruction
Test #1. It actually works OK!

We tried twice to load MAINDEC-8I-D02B-D Instruction Test #2, but failed
both times. Running that diagnostic and others will be the project for next
week.

Al Kossow posted LOTS of PDP-12 manuals to Bitsavers. One manual includes
the allowable ripple for the power supplies. They allow 3,000mV of ripple
on the -30V supply for the core memory, so I guess that the 180mV that we
measured two weeks ago is OK.

On Mon, May 25, 2015 at 8:07 PM, Michael Thompson 
michael.99.thomp...@gmail.com wrote:

 Today we pulled all of the M113 flip-chips and tested them because SN7474
 and SN7400 ICs seem to be a problem in these early DEC systems. The ones in
 slots J33 and K30 were bad. Replacing them fixed the problem with the JMP
 instruction. We did some more testing with the toggle-in programs and found
 that ISZ cleared the AC. Replacing the M119 in slot H28 fixed that. All of
 the toggle-in tests pass, so the processor is substantially functional.

 Core memory in field 1 with addresses X5XX didn't work. We replaced the
 G221 in slot D10 to fix that.

 We tried the ASR33 Teletype that came with the system. The mechanics were
 sticky from not being used for 30 years, but we got most of it free and
 working. We could send characters to the Teletype, but could not receive
 anything. The M706 receiver failed in the board tester. The spare is also
 broken, so we need to fix both.




-- 
Michael Thompson

Re: PDP-12 Restoration at the RICM

[Jay Jaeger]

If you haven't yet found one, I have spares for the switch cover - I
have an entire console and the backplanes (with the cards) whose machine
was disassembled out from underneath them.

JRJ

On 5/10/2015 9:45 AM, Michael Thompson wrote:
 Sorry, I sent the message before I was finished.
 
 The CRT in the VR14 has severe screen rot. Hopefully we can find a
 replacement CRT, or get some help with removing the outer layer of glass.
 One of the lime green switches on the front panel has broken pivots. Anyone
 have a spare?
 
 On Sun, May 10, 2015 at 10:42 AM, Michael Thompson 
 michael.99.thomp...@gmail.com wrote:
 
 The RICM is restoring a PDP-12. This system was manufactured in December
 of 1972, so it is very late in the life of the PDP-12. The Priority
 Interrupt and the Data Multiplexer are hardwired in two extra columns in
 the processor chassis. These options were in separate chassis in earlier
 models. It came with an Omnibus expansion chassis that connects to the
 Posibus from the PDP-12. The LP01, RK05, and PC04 controllers are in the
 Omnibus chassis. The VR14 and TU56 controllers are in the processor
 chassis. We got the LP01 too.

 The donor did a great job of preserving the machine, and has all of the
 original documentation and software. The processor and RK8-F prints are
 newer than what I can find on the Web, so I will scan them and send the
 PDFs to Bitsavers.

 Yesterday we reformed the caps in the power supply and powered it on for
 the first time in 24 years. It is going to need some debugging, but it does
 show some signs of life.

 The CRT in the VR14


 --
 Michael Thompson

 
 
 

Re: PDP-12 Restoration at the RICM

[Pete Turnbull]

On 26/05/2015 03:02, Ethan Dicks wrote:

On Mon, May 25, 2015 at 8:07 PM, Michael Thompson
michael.99.thomp...@gmail.com wrote:

Today we pulled all of the M113 flip-chips and tested them



Do you have any writeups on Warren's FLIP-CHIP tester?


I'd be very interested too, especially since I'm about to try to 
resurrect a PDP-8/L and then possibly another PDP-12.


--
Pete

Pete Turnbull