Re: pdp-8/e restoration.

[allison via cctalk]

On 8/16/17 9:38 AM, Ethan Dicks wrote:

On Tue, Aug 8, 2017 at 8:35 AM, allison via cctalk
 wrote:

Note: TU58 (variant of DC100 tape) to my knowledge was never used with PDP-8
in any flavor.  There is no reason why not other than no driver and it 8bit
only and the blocking is 512bytes.

I remember a lot of discussion in PDP-8 user group newsletters about
the TU-58 when it came out (due to cost, size, and convenience), but
one technical problem dominated the articles - how to generate a break
from various types of PDP-8 serial ports.  ISTR some of the talk was
around hacking the hardware to make it possible (jamming multiple
nulls into the transmit latches without waiting for the previous one
to complete, for one).

In the end, I think it never worked out to be a favorable peripheral
to go with, perhaps because floppies got cheaper and easier and older
machines declined in active use.

-ethan

it was odd and optimized for 16/32bit machines of the day.  The transfer
speed for a well buffered system was limited to about 25kbits/S average.
Without buffering or low response the rate was easily much less.  On the 
whole
I've limited TU-58 to physically small Qbus PDP11 systems as its 
painfully slow

but very portable (even RX02 is heavy).

For modern implementation it would be easier to take an Arduino or R-PI
and match the serial limitations of the PDP-8 with a more suitable protocol
and also handle 8/12bit more transparently.  That and large storage using
SD or microSD would be very cheap.  Over ten years ago I  went the route of
a simple serial using 8749 and a 128kx8 ram to store 6bit half words
in an block addressable form (256 6bit or 128 12bit words).   It didn't
try to emulate a popular PDP-8 storage so it was easy to get going. Today
I'd use Arduino and either battery backed up ram or SD.

The alternate to that in modern hardware is to emulate the DF32 using
three cycle data break.  The actual storage can be a pair of 8bit ram as a
12 bit wide memory wich is cheap and easy as cmos parts for 32K bytes
abound and larger to 1mb can be found easily.  A PDP-8 with 128K words
of very fast no latency "disk" would be a interesting.  The basic hardware
can be copied from the 3cycle databreak foundation module.  Most of the
PDP-8 OSs supported DF32 if only for swap.

Allison

Re: pdp-8/e restoration.

[Ethan Dicks via cctalk]

On Tue, Aug 8, 2017 at 8:35 AM, allison via cctalk
 wrote:
> Note: TU58 (variant of DC100 tape) to my knowledge was never used with PDP-8
> in any flavor.  There is no reason why not other than no driver and it 8bit
> only and the blocking is 512bytes.

I remember a lot of discussion in PDP-8 user group newsletters about
the TU-58 when it came out (due to cost, size, and convenience), but
one technical problem dominated the articles - how to generate a break
from various types of PDP-8 serial ports.  ISTR some of the talk was
around hacking the hardware to make it possible (jamming multiple
nulls into the transmit latches without waiting for the previous one
to complete, for one).

In the end, I think it never worked out to be a favorable peripheral
to go with, perhaps because floppies got cheaper and easier and older
machines declined in active use.

-ethan

Re: pdp-8/e restoration update.

[Michael Thompson via cctalk]

>
> Date: Fri, 11 Aug 2017 17:22:58 +0100
> From: Rod Smallwood 
> Subject: pdp-8/e restoration update.
>
> Hi List
>
> Well I think I've found why the RX01 is not responding.
>
> The device address (75) is not getting decoded on the controller because
> the CPU does not assert BUS I/O PAUSE L
>
> Which it should do I think when it sees an IO instruction.
>
> Do I have this right?
>
> Rod Smallwood
>

Yes, you have it right. Take a look at E7 pin 6 in the M8330 Timing
Generator. It is in section C2 on the prints. It decodes the instruction
6xxx, USER MODE H, and I/O TIME (1) and drives I/O PAUSE low.

-- 
Michael Thompson

Re: pdp-8/e restoration.

[Noel Chiappa via cctalk]

> From: Philipp Hachtmann

> The DEC stuff was designed quite wrong-insertion resistant.
> ...
> I did it. Once. It leads to impressive fireworks on many boards.

I managed to plug in an M9301 backwards, once. Luckily, most of the other
boards came through OK (I think I lost one chip on the CPU), but on the
M9301, I fried over half a dozen chips.

Just goes to show, they _try_ and make it hard to put them in wrong, but it's
still possible! :-)

Later on, they got smart - they gave up trying to prevent smart fools ('you
can't make anything fool-prof because...') like me from doing it, and instead
made it harmless to do - on the QBUS, many boards can take being plugged in
wrong, with no ill effects. I think I did that at least once, there.

Noel

Re: pdp-8/e restoration.

[allison via cctalk]

Note: TU58 (variant of DC100 tape) to my knowledge was never used with PDP-8
in any flavor.  There is no reason why not other than no driver and it 
8bit only

and the blocking is 512bytes.

The 8bit part is solved by storing 2 words (12bit word) to 3 bytes (24bits).

It could be quite handy as a DECTape substitute.

As distribution it was the same as RX01 in size (256K max) and not cheaper.
it was more compact as a system loader typically used on VAX730 and PDT110.


On 8/8/17 1:09 AM, Ian S. King via cctalk wrote:

On Mon, Aug 7, 2017 at 5:28 PM, Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:



On 08/08/2017 00:01, Josh Dersch via cctalk wrote:


On 8/7/2017 3:50 PM, Rod Smallwood via cctalk wrote:



One other thing - I have a working TU58.
The two cassette drives in a box type with serial interface.
Now the pdp-8/e DECTapes were also called TU58.


The typical DECtapes used with the PDP-8 were TU56's, a completely
different (and much more rare) beast.

The M8650 is on the list of what you can connect it to.

So does the one substitute for the other and raise the possibility of
booting from tape?


No, they're not substitutes.  I'm not aware of any PDP-8 systems booting
and running from a TU58, but I suppose it's not impossible. Mostly the
problem with the TU58 at this point is that (a) the capstan rollers in your
drives are most likely tar, and (b) the rubber parts in the tape itself
have done the same, and (c) the tape itself probably isn't in great shape
either.

- Josh



Rod



Mmm senior confusion.

Its a working TU58 - Restored including fixing the roller problem.
Runs on a PC OK.

Just fixed the echo test problem.
RS232 on M8650 needed a jumper E-M on board or plug.


So now to check out that  rim loader stuff.
Its in C but I can get round that problem.


Rod

--
Wanted one pdp-8/i rocker switch leaver to copy.



For verily, LINCtape begat DECtape, and DECtape begat DECtape II.  LINCtape
and DECtape were legitimate backing store, DECtape II was a cheap way of
delivering software updates.

And since when is C a 'problem'?  :-)  -- Ian

Re: pdp-8/e restoration.

[Ian S. King via cctalk]

On Mon, Aug 7, 2017 at 5:28 PM, Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:

>
>
> On 08/08/2017 00:01, Josh Dersch via cctalk wrote:
>
>> On 8/7/2017 3:50 PM, Rod Smallwood via cctalk wrote:
>>
>>
>>>
>>> One other thing - I have a working TU58.
>>> The two cassette drives in a box type with serial interface.
>>> Now the pdp-8/e DECTapes were also called TU58.
>>>
>>
>> The typical DECtapes used with the PDP-8 were TU56's, a completely
>> different (and much more rare) beast.
>>
>> The M8650 is on the list of what you can connect it to.
>>> So does the one substitute for the other and raise the possibility of
>>> booting from tape?
>>>
>>
>> No, they're not substitutes.  I'm not aware of any PDP-8 systems booting
>> and running from a TU58, but I suppose it's not impossible. Mostly the
>> problem with the TU58 at this point is that (a) the capstan rollers in your
>> drives are most likely tar, and (b) the rubber parts in the tape itself
>> have done the same, and (c) the tape itself probably isn't in great shape
>> either.
>>
>> - Josh
>>
>>
>>> Rod
>>>
>>>
>> Mmm senior confusion.
>
> Its a working TU58 - Restored including fixing the roller problem.
> Runs on a PC OK.
>
> Just fixed the echo test problem.
> RS232 on M8650 needed a jumper E-M on board or plug.
>
>
> So now to check out that  rim loader stuff.
> Its in C but I can get round that problem.
>
>
> Rod
>
> --
> Wanted one pdp-8/i rocker switch leaver to copy.
>
>
For verily, LINCtape begat DECtape, and DECtape begat DECtape II.  LINCtape
and DECtape were legitimate backing store, DECtape II was a cheap way of
delivering software updates.

And since when is C a 'problem'?  :-)  -- Ian

-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Principal Investigator, "Reflections on Early Computing and Social Change",
UW IRB #42619

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: pdp-8/e restoration.

[Ed via cctalk]

I did not  know of Kevin's  site..
Great  stuff there.
 
Ed#
 
 
In a message dated 8/7/2017 2:41:24 P.M. US Mountain Standard Time,  
cctalk@classiccmp.org writes:

On  07/08/2017 18:37, Rod Smallwood via cctalk wrote:

> So to-morrow  connect up a terminal that will do 110 baud and try an echo 
>  test.
> 
> Next part is interesting. There should be a way to fake  a reader / punch 
> and feed in tape images.

There is.  Look  on Kevin McQuiggin's site:
http://highgate.comm.sfu.ca/pdp8/

In the  section called "Software", about 1/3 of the way down, look for 
send.c or  better still new-send.c (I call it rsend, on my system).  You 
might  also find rim.c and the BIN loader useful.

They're also on my webpage,  with the corresponding  manpages:
http://www.dunnington.info/public/PDP-8/

That's the  easiest place to get the manpages for rim.c, send.c, rsend.c. 
Here's the  gist (top parts of the manpages):

rim - create RIM-format file from  ASCII addr/instr
rim is a very simple converter.  It  reads in a file containing two
columns of ASCII digits; the  first column is a list of addresses (in
octal) and the second  is a list of machine instructions (also octal).
Output is a  file suitable to feed to the RIM loader on a PDP-8.

send, rsend - send  a file in RIM or BIN format to a PDP-8
send and rsend are  utilities to transmit a RIM format or BIN format
file from a  UNIX (or other) host to a PDP-8 over a serial line.  The
PDP-8 should be running the RIM loader routine prior to  starting
either of these programs.
Input  should be a file in RIM format or BIN format.  Output goes  to
the host serial port, which should be connected via  appropriate cable
to the PDP-8.
send is a  simple version, with built-in serial port settings and a
fixed  delay between characters.  rsend is more sophisticated; it  can
be controlled by command-line options or environment  variables, and
can accept input on stdin.

On a Unix (or  Linux etc) machine you can pipe the output from rim to 
rsend, and if  you're using papertape images (of which there are load on 
the net), rsend  can strip the headers for you.

-- 
Pete
Pete  Turnbull

Re: pdp-8/e restoration.

[Josh Dersch via cctalk]

On 8/7/2017 3:50 PM, Rod Smallwood via cctalk wrote:




On 07/08/2017 22:52, Ian S. King via cctalk wrote:

On Mon, Aug 7, 2017 at 2:40 PM, Pete Turnbull via cctalk <
cctalk@classiccmp.org> wrote:


On 07/08/2017 18:37, Rod Smallwood via cctalk wrote:

So to-morrow connect up a terminal that will do 110 baud and try an 
echo

test.

Next part is interesting. There should be a way to fake a reader / 
punch

and feed in tape images.


There is.  Look on Kevin McQuiggin's site:
http://highgate.comm.sfu.ca/pdp8/

In the section called "Software", about 1/3 of the way down, look for
send.c or better still new-send.c (I call it rsend, on my system).  You
might also find rim.c and the BIN loader useful.

They're also on my webpage, with the corresponding manpages:
http://www.dunnington.info/public/PDP-8/

That's the easiest place to get the manpages for rim.c, send.c, 
rsend.c.

Here's the gist (top parts of the manpages):

rim - create RIM-format file from ASCII addr/instr
   rim is a very simple converter.  It reads in a file containing two
   columns of ASCII digits; the first column is a list of addresses (in
   octal) and the second is a list of machine instructions (also 
octal).

   Output is a file suitable to feed to the RIM loader on a PDP-8.

send, rsend - send a file in RIM or BIN format to a PDP-8
   send and rsend are utilities to transmit a RIM format or BIN format
   file from a UNIX (or other) host to a PDP-8 over a serial line.  The
   PDP-8 should be running the RIM loader routine prior to starting
   either of these programs.
   Input should be a file in RIM format or BIN format.  Output goes to
   the host serial port, which should be connected via appropriate 
cable

   to the PDP-8.
   send is a simple version, with built-in serial port settings and a
   fixed delay between characters.  rsend is more sophisticated; it can
   be controlled by command-line options or environment variables, and
   can accept input on stdin.

On a Unix (or Linux etc) machine you can pipe the output from rim to
rsend, and if you're using papertape images (of which there are load 
on the

net), rsend can strip the headers for you.

--
Pete
Pete Turnbull


Once upon a time I wrote a Python program to stand in for an ASR-33,
providing both a terminal session and a papertape image reader/punch.
N.B.: much PDP-8 software likes 7E1, but PTR/PTP is 8N1.  ISTR that even
when I fiddled with SLU settings, I couldn't get away from 7E1 for 
some of

the diagnostics.  Of course, I've slept since then.  -- Ian


Thank you that's interesting.
So far to-day I hooked up a three wire RS232 connection to an old 
Compaq notebook and ran msk315 (kermit)

Next SET BAUD 110
Then toggle in the print test on the 8/e.
Yup prints the character set on the notebook
Then echo test - nope.
The M8650 probably needs DTR or whatever.
Three wires was a bit cheeky I guess
In the hardware docs for the 8/e there's a load of info about the 8650.
I'll go read that.


Three wires should be enough, no DTR necessary.  Double-check your 
wiring and the jumpering on the M8650.




One other thing - I have a working TU58.
The two cassette drives in a box type with serial interface.
Now the pdp-8/e DECTapes were also called TU58.


The typical DECtapes used with the PDP-8 were TU56's, a completely 
different (and much more rare) beast.



The M8650 is on the list of what you can connect it to.
So does the one substitute for the other and raise the possibility of 
booting from tape?


No, they're not substitutes.  I'm not aware of any PDP-8 systems booting 
and running from a TU58, but I suppose it's not impossible. Mostly the 
problem with the TU58 at this point is that (a) the capstan rollers in 
your drives are most likely tar, and (b) the rubber parts in the tape 
itself have done the same, and (c) the tape itself probably isn't in 
great shape either.


- Josh



Rod

Re: pdp-8/e restoration.

[Rod Smallwood via cctalk]

On 07/08/2017 22:52, Ian S. King via cctalk wrote:

On Mon, Aug 7, 2017 at 2:40 PM, Pete Turnbull via cctalk <
cctalk@classiccmp.org> wrote:


On 07/08/2017 18:37, Rod Smallwood via cctalk wrote:

So to-morrow connect up a terminal that will do 110 baud and try an echo

test.

Next part is interesting. There should be a way to fake a reader / punch
and feed in tape images.


There is.  Look on Kevin McQuiggin's site:
http://highgate.comm.sfu.ca/pdp8/

In the section called "Software", about 1/3 of the way down, look for
send.c or better still new-send.c (I call it rsend, on my system).  You
might also find rim.c and the BIN loader useful.

They're also on my webpage, with the corresponding manpages:
http://www.dunnington.info/public/PDP-8/

That's the easiest place to get the manpages for rim.c, send.c, rsend.c.
Here's the gist (top parts of the manpages):

rim - create RIM-format file from ASCII addr/instr
   rim is a very simple converter.  It reads in a file containing two
   columns of ASCII digits; the first column is a list of addresses (in
   octal) and the second is a list of machine instructions (also octal).
   Output is a file suitable to feed to the RIM loader on a PDP-8.

send, rsend - send a file in RIM or BIN format to a PDP-8
   send and rsend are utilities to transmit a RIM format or BIN format
   file from a UNIX (or other) host to a PDP-8 over a serial line.  The
   PDP-8 should be running the RIM loader routine prior to starting
   either of these programs.
   Input should be a file in RIM format or BIN format.  Output goes to
   the host serial port, which should be connected via appropriate cable
   to the PDP-8.
   send is a simple version, with built-in serial port settings and a
   fixed delay between characters.  rsend is more sophisticated; it can
   be controlled by command-line options or environment variables, and
   can accept input on stdin.

On a Unix (or Linux etc) machine you can pipe the output from rim to
rsend, and if you're using papertape images (of which there are load on the
net), rsend can strip the headers for you.

--
Pete
Pete Turnbull


Once upon a time I wrote a Python program to stand in for an ASR-33,
providing both a terminal session and a papertape image reader/punch.
N.B.: much PDP-8 software likes 7E1, but PTR/PTP is 8N1.  ISTR that even
when I fiddled with SLU settings, I couldn't get away from 7E1 for some of
the diagnostics.  Of course, I've slept since then.  -- Ian


Thank you that's interesting.
So far to-day I hooked up a three wire RS232 connection to an old Compaq 
notebook and ran msk315 (kermit)

Next SET BAUD 110
Then toggle in the print test on the 8/e.
Yup prints the character set on the notebook
Then echo test - nope.
The M8650 probably needs DTR or whatever.
Three wires was a bit cheeky I guess
In the hardware docs for the 8/e there's a load of info about the 8650.
I'll go read that.

One other thing - I have a working TU58.
The two cassette drives in a box type with serial interface.
Now the pdp-8/e DECTapes were also called TU58.
The M8650 is on the list of what you can connect it to.
So does the one substitute for the other and raise the possibility of 
booting from tape?


Rod

--
Wanted one pdp-8/i rocker switch leaver to copy.

Re: pdp-8/e restoration.

[Ian S. King via cctalk]

On Mon, Aug 7, 2017 at 2:40 PM, Pete Turnbull via cctalk <
cctalk@classiccmp.org> wrote:

> On 07/08/2017 18:37, Rod Smallwood via cctalk wrote:
>
> So to-morrow connect up a terminal that will do 110 baud and try an echo
>> test.
>>
>> Next part is interesting. There should be a way to fake a reader / punch
>> and feed in tape images.
>>
>
> There is.  Look on Kevin McQuiggin's site:
> http://highgate.comm.sfu.ca/pdp8/
>
> In the section called "Software", about 1/3 of the way down, look for
> send.c or better still new-send.c (I call it rsend, on my system).  You
> might also find rim.c and the BIN loader useful.
>
> They're also on my webpage, with the corresponding manpages:
> http://www.dunnington.info/public/PDP-8/
>
> That's the easiest place to get the manpages for rim.c, send.c, rsend.c.
> Here's the gist (top parts of the manpages):
>
> rim - create RIM-format file from ASCII addr/instr
>   rim is a very simple converter.  It reads in a file containing two
>   columns of ASCII digits; the first column is a list of addresses (in
>   octal) and the second is a list of machine instructions (also octal).
>   Output is a file suitable to feed to the RIM loader on a PDP-8.
>
> send, rsend - send a file in RIM or BIN format to a PDP-8
>   send and rsend are utilities to transmit a RIM format or BIN format
>   file from a UNIX (or other) host to a PDP-8 over a serial line.  The
>   PDP-8 should be running the RIM loader routine prior to starting
>   either of these programs.
>   Input should be a file in RIM format or BIN format.  Output goes to
>   the host serial port, which should be connected via appropriate cable
>   to the PDP-8.
>   send is a simple version, with built-in serial port settings and a
>   fixed delay between characters.  rsend is more sophisticated; it can
>   be controlled by command-line options or environment variables, and
>   can accept input on stdin.
>
> On a Unix (or Linux etc) machine you can pipe the output from rim to
> rsend, and if you're using papertape images (of which there are load on the
> net), rsend can strip the headers for you.
>
> --
> Pete
> Pete Turnbull
>

Once upon a time I wrote a Python program to stand in for an ASR-33,
providing both a terminal session and a papertape image reader/punch.
N.B.: much PDP-8 software likes 7E1, but PTR/PTP is 8N1.  ISTR that even
when I fiddled with SLU settings, I couldn't get away from 7E1 for some of
the diagnostics.  Of course, I've slept since then.  -- Ian

-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Principal Investigator, "Reflections on Early Computing and Social Change",
UW IRB #42619

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: pdp-8/e restoration.

[Pete Turnbull via cctalk]

On 07/08/2017 18:37, Rod Smallwood via cctalk wrote:

So to-morrow connect up a terminal that will do 110 baud and try an echo 
test.


Next part is interesting. There should be a way to fake a reader / punch 
and feed in tape images.


There is.  Look on Kevin McQuiggin's site:
http://highgate.comm.sfu.ca/pdp8/

In the section called "Software", about 1/3 of the way down, look for 
send.c or better still new-send.c (I call it rsend, on my system).  You 
might also find rim.c and the BIN loader useful.


They're also on my webpage, with the corresponding manpages:
http://www.dunnington.info/public/PDP-8/

That's the easiest place to get the manpages for rim.c, send.c, rsend.c. 
Here's the gist (top parts of the manpages):


rim - create RIM-format file from ASCII addr/instr
  rim is a very simple converter.  It reads in a file containing two
  columns of ASCII digits; the first column is a list of addresses (in
  octal) and the second is a list of machine instructions (also octal).
  Output is a file suitable to feed to the RIM loader on a PDP-8.

send, rsend - send a file in RIM or BIN format to a PDP-8
  send and rsend are utilities to transmit a RIM format or BIN format
  file from a UNIX (or other) host to a PDP-8 over a serial line.  The
  PDP-8 should be running the RIM loader routine prior to starting
  either of these programs.
  Input should be a file in RIM format or BIN format.  Output goes to
  the host serial port, which should be connected via appropriate cable
  to the PDP-8.
  send is a simple version, with built-in serial port settings and a
  fixed delay between characters.  rsend is more sophisticated; it can
  be controlled by command-line options or environment variables, and
  can accept input on stdin.

On a Unix (or Linux etc) machine you can pipe the output from rim to 
rsend, and if you're using papertape images (of which there are load on 
the net), rsend can strip the headers for you.


--
Pete
Pete Turnbull

Re: pdp-8/e restoration.

[Rod Smallwood via cctalk]

On 07/08/2017 17:05, Philipp Hachtmann via cctalk wrote:

On 04.08.2017 09:24, Rod Smallwood via cctalk wrote:

Hi List

Hi Rod!

  I looks like I have at last got a KK8-E CPU set to continue 
getting my 8/e back running again.

It looks that you have one more set stored in my facility in Hannover!!!
I became feeling more and more bad about that. Then I forgot it again. 
Then I felt even more bad by not remembering WHOSE boards those are 
(because there is no "Rod Smallwood" written nowhere on the packet).

Now I have connected that again!

The system has a working rebuilt PSU with all of the caps reformed or 
replaced. Voltages are good.

Wow, I never did that. I always made a smoke test.


There's 16k of core at the back with a terminator at the end.

Not bad.

Power up and all the lamps come on either bright or dim (off) except 
the RUN light.

Sounds not so wrong.

2. Are there any tests like resistance I can do on the CPU board set 
before inserting them in the correct front slots?
There are no "correct" slots. Not for *any* of the boards. You can mix 
it up completely. Even the front panel could be omitted, doubled, or 
put into an expansion box.
BUT.. There actually IS a DEC recommended order, yes... And having the 
terminator board somehow at the end of the Omnibus seems to be a good 
idea.


3. In the event the CPU set does not even do a simple write to and 
read from memory. Where do I start to look?
At the schematics? Front panel (!), timing generator, major state 
registers.


The DEC stuff was designed quite wrong-insertion resistant. But:
There is just one MAJOR fault you HAVE TO AVOID: NEVER NEVER NEVER 
plug in the middle board of an RK8E controller upside down!!


I did it. Once. It leads to impressive fireworks on many boards.

Regards
Philipp


Its now running just fine.
Count test runs.
The second set of 4k core is in and checks out.
Async. board has just gone in and is running.
I'm getting output RS232 on my BOB  when the print test is toggled in 
and run.
So to-morrow connect up a terminal that will do 110 baud and try an echo 
test.


Next part is interesting. There should be a way to fake a reader / punch 
and feed in tape images.


Rod

--
Wanted one pdp-8/i rocker switch leaver to copy.

Re: pdp-8/e restoration.

[Philipp Hachtmann via cctalk]

On 04.08.2017 09:24, Rod Smallwood via cctalk wrote:

Hi List

Hi Rod!

  I looks like I have at last got a KK8-E CPU set to continue 
getting my 8/e back running again.

It looks that you have one more set stored in my facility in Hannover!!!
I became feeling more and more bad about that. Then I forgot it again. 
Then I felt even more bad by not remembering WHOSE boards those are 
(because there is no "Rod Smallwood" written nowhere on the packet).

Now I have connected that again!

The system has a working rebuilt PSU with all of the caps reformed or 
replaced. Voltages are good.

Wow, I never did that. I always made a smoke test.


There's 16k of core at the back with a terminator at the end.

Not bad.

Power up and all the lamps come on either bright or dim (off) except the 
RUN light.

Sounds not so wrong.

2. Are there any tests like resistance I can do on the CPU board set 
before inserting them in the correct front slots?
There are no "correct" slots. Not for *any* of the boards. You can mix 
it up completely. Even the front panel could be omitted, doubled, or put 
into an expansion box.
BUT.. There actually IS a DEC recommended order, yes... And having the 
terminator board somehow at the end of the Omnibus seems to be a good idea.


3. In the event the CPU set does not even do a simple write to and read 
from memory. Where do I start to look?

At the schematics? Front panel (!), timing generator, major state registers.

The DEC stuff was designed quite wrong-insertion resistant. But:
There is just one MAJOR fault you HAVE TO AVOID: NEVER NEVER NEVER plug 
in the middle board of an RK8E controller upside down!!


I did it. Once. It leads to impressive fireworks on many boards.

Regards
Philipp

Re: pdp-8/e restoration.

[Philipp Hachtmann via cctalk]

On 04.08.2017 17:23, Doug Ingraham via cctalk wrote:

On Fri, Aug 4, 2017 at 1:24 AM, Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:


1. Should the run light glow dimly?



Without looking at the schematics I can't tell you if they bothered to put
the resistor in there to make
it glow dimly but I can tell you that it isn't necessary for the run lamp.
The reason to make it glow
dimly when off is to reduce the filament thermal shock when turning on and
off.  This makes the bulbs
last a lot longer.  The run lamp does not flicker in operation so not
necessary on that one.


At least for the "normal" bulbs, the resistor is there. I once refitted 
a whole front panel with bulbs and resistors (which have to be removed 
when using anything LED related).

Re: pdp-8/e restoration.

[Rod Smallwood via cctalk]

On 06/08/2017 18:10, Noel Chiappa via cctalk wrote:

 > From: Ian S. King

 > Those keys are common across nearly all DEC machines prior to the ones
 > that started using plastic keys. XX2247 is the code.

Someone on eBait is selling replicas for not wholly unreasonable amounts of
money:

   http://www.ebay.com/itm/142118132040

Noel

Thank you Noel..
Rod

--
Wanted one pdp-8/i rocker switch leaver to copy.

Re: pdp-8/e restoration.

[Noel Chiappa via cctalk]

> From: Ian S. King

> Those keys are common across nearly all DEC machines prior to the ones
> that started using plastic keys. XX2247 is the code. 

Someone on eBait is selling replicas for not wholly unreasonable amounts of
money:

  http://www.ebay.com/itm/142118132040

Noel

RE: pdp-8/e restoration.

[Bill Gunshannon via cctalk]

I have found that metal PS/2 keys work as well, if your are not insistant
on historical purity.  I, personally, have always prefered functionality over
appearance.

bill



From: cctalk [cctalk-boun...@classiccmp.org] on behalf of Ian S. King via 
cctalk [cctalk@classiccmp.org]
Sent: Sunday, August 6, 2017 2:00 AM
To: Rod Smallwood; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: pdp-8/e restoration.

Those keys are common across nearly all DEC machines prior to the ones that
started using plastic keys.  XX2247 is the code.  -- Ian

On Sat, Aug 5, 2017 at 10:29 PM, Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:

> Hi List!
>
>   Movin right along.
>
>  Programmers console now properly attached to light screening bar.
>
> Front panel and bezel on. Needs a bit more work.
>
> Not as secure or as straight as I would like.
>
> Then there's the key lock problem.
>
> Its in the off position and of course I don't have the key.
>
> So I cant fit that just now.
>
> Took power supply out. Changed mains cable as it was only a foot long.
>
> Soldered to the circuit breaker was a factory standard would you believe.
>
> Power supply back in. Connect up. Power on. Load address , press CLEAR
> and CONT.
>
> Test program still in core. Started right up.
>
> To-days task get the serial I/O going.
>
> Rod in Restore Mode
>
>
> .--
> Wanted one pdp-8/i rocker switch leaver to copy.
>
>


--
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School <http://ischool.uw.edu>
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Principal Investigator, "Reflections on Early Computing and Social Change",
UW IRB #42619

Archivist, Voices From the Rwanda Tribunal <http://tribunalvoices.org>
Value Sensitive Design Research Lab <http://vsdesign.org>

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: pdp-8/e restoration the next step.

[Jon Elson via cctalk]

On 08/04/2017 05:31 PM, Rod Smallwood via cctalk wrote:

Hi Guys

Thanks for the info so far. Well I have moved on. 
I now have the minimum configuration.


Programmers console, M8300,M8310,M8320,M8330,M849 and 4k 
of core memory.


The M8320 is at the far end of the bus.

Well much as I feared I cant write to memory using Load 
Address , set data to 0001, lift DEP.


Then set address to  again and press EXAM. I should 
see the contents of MD with the selector switch set to MD. 
I don't.


I have checked the correct bus signals go low when the DEP 
switch is lifted.


This is so fundamental somebody must have come across it 
before.


OK, try reading a few locations and see if you can find a 
non-zero one.  If so, go back and read it again.  If it 
still reads the same value, that is a GOOD sign.  it means 
the write-back after a read worked.  If the 2nd read comes 
up zero, it means the write-back failed.  This would tell 
you that the write function of the memory is bad, but the 
read function is OK.


If some portion of the memory CAN read/write, then that 
indicates that either some decode logic or some select 
drivers are not working.  If nothing works, then it could be 
a configuration issue (the plugged-in memory module is not 
set at address zero, for instance) .  But, eventually, you 
would have to trace it through the prints.  Fortunately, the 
PDP-8 is not a terribly complex CPU.


Jon

Re: pdp-8/e restoration.

[Ian S. King via cctalk]

Yes, the 8/e has the 'keep-alive current'.  The lamps are driven by an 8V
line that runs from the power supply to the programmer's panel.  -- Ian

On Fri, Aug 4, 2017 at 8:23 AM, Doug Ingraham via cctalk <
cctalk@classiccmp.org> wrote:

> On Fri, Aug 4, 2017 at 1:24 AM, Rod Smallwood via cctalk <
> cctalk@classiccmp.org> wrote:
>
> > 1. Should the run light glow dimly?
> >
>
> Without looking at the schematics I can't tell you if they bothered to put
> the resistor in there to make
> it glow dimly but I can tell you that it isn't necessary for the run lamp.
> The reason to make it glow
> dimly when off is to reduce the filament thermal shock when turning on and
> off.  This makes the bulbs
> last a lot longer.  The run lamp does not flicker in operation so not
> necessary on that one.
>
> --
> Doug Ingraham
> PDP-8 SN 1175
>



-- 
Ian S. King, MSIS, MSCS, Ph.D. Candidate
The Information School 
Dissertation: "Why the Conversation Mattered: Constructing a Sociotechnical
Narrative Through a Design Lens

Archivist, Voices From the Rwanda Tribunal 
Value Sensitive Design Research Lab 

University of Washington

There is an old Vulcan saying: "Only Nixon could go to China."

Re: pdp-8/e restoration.

[Doug Ingraham via cctalk]

On Fri, Aug 4, 2017 at 1:24 AM, Rod Smallwood via cctalk <
cctalk@classiccmp.org> wrote:

> 1. Should the run light glow dimly?
>

Without looking at the schematics I can't tell you if they bothered to put
the resistor in there to make
it glow dimly but I can tell you that it isn't necessary for the run lamp.
The reason to make it glow
dimly when off is to reduce the filament thermal shock when turning on and
off.  This makes the bulbs
last a lot longer.  The run lamp does not flicker in operation so not
necessary on that one.

-- 
Doug Ingraham
PDP-8 SN 1175

Re: pdp-8/e restoration.

[Jon Elson via cctalk]

On 08/04/2017 02:24 AM, Rod Smallwood via cctalk wrote:



Programmers console is in its slot. Bad bulbs (not LEDs)  have been 
replaced


Power up and all the lamps come on either bright or dim (off) except 
the RUN light.


So questions:

1. Should the run light glow dimly?

Probably all lights should glow very dimly.  DEC put a resistor across 
the transistor to put a slight warming current through the bulb.  This 
reduces shock to the filament every time it is turned on.
(This info is from other DEC machines, not PDP-8, but I'm pretty sure 
they would do the same there.)


Jon