Re: Epson PX-8 specifically TF-10 problem...

[Tony Duell via cctalk]

On Sun, Dec 10, 2017 at 2:06 AM, allison via cctalk
 wrote:


Assuming it's the same as the one I worked on some years ago...

>> How does it detect the presence of a disk?   and/or disk change?

It's a mechanical switch on the motor PCB. A similar switch detects
the write-protect hole.

>>
>>
> Functions normally save for the motor does not always turn on command
> but will if manually pushed.  All other functions are normal.
>
>
>>
>> Totally irrelevant to the matter at hand:
>> BTW, how close to "industry standard" is the interface to the drive
>> mechanism itself?   Would it be practical to replace the mechanism
>> with one of the 80 track (and also 2 sided?) Epson drives?  Either the
>> whole drive, if it is fairly "standard", or just the stepping
>> mechanism if there is another Epson drive similar enough?
>
> No its an oddball.  The read-wirite electronics are part of the
> intelligent mainboard that communicates
> with the pX-8 serially.  The only board that is part of the drive is the
> motor control.

Assuming it's the same motor as the one I worked on :

What is the voltage on the collector of Q18 (== emitters of
Q15...Q17) when the motor should run but doesn't? If it's
close to the supply rail then the problem is in the motor or
commutation circuitry, if it is low then the problem is in the
speed control or the motor is not being told to run.

With the motor running, look at the waveforms on :
Collectors of Q15...Q17 (drives to the motor windings)

Pin 1,15,16 of IC13 (TA7745) (drives to those transistors)

Pins 2...7 of IC13 (outputs of the hall sensorts that detect
the motor position).

In each case the 3 (or 6) signals should look much the same,
if one is different or missing then the problem is in the motor
commutation circuit.

-tony

Re: Revive 11/34

[Noel Chiappa via cctalk]

> From: Henk Gooijen

> the M7859 is sort of a UNIBUS device. The (front panel) console only
> communicates with the M7859.

Not quite; it does _mostly_ 'do its thing' over the UNIBUS, but there are
also two special lines carried across the DD11-P backplane to the CPU, 'Halt
Request' and 'Halt Grant' (which is why it has to be in the same backplane as
the CPU); more here:

  http://gunkies.org/wiki/KY11-LB_Programmer%27s_Console

> I cannot remember whether a demux for the displays is on the console
> PCB, or on the M7859.

I'm not sure exactly what you mean by 'demux', but... the interface between
the board and console is i) 3 bits of digit, and ii) 6 individual select
lines. Code in the micro on the M7859 sends one digit at a time down the 3
'digit' lines, along with the appropriate 'select' line.


> If you get 00 on the dsipaly and when halted it shows 173066 I
> presume it is looping.

Well, I haven't looked at the M9312 ROM code, but if it's anything like the
M9301 code (which I have dumped and disassembled), looping in the ROM at
173066 is not necessarily bad.

There is a listing of some of the ROM code on BitSavers:

  http://bitsavers.trailing-edge.com/pdf/dec/unibus/K-SP-M9312-0-5_Aug78.pdf

but it doesn't seem to cover the stuff at 173000 (which is where the CPU
starts running on power-on) - or maybe I just didn't study the listings
carefully enough.

> If it loops, it will repeatedly read from a device address which is
> most likely the CSR of the boot device.

Depends on the switch settings on the M9312. If it's set to boot, if the
device is there, yes; otherwise it would get a NXM fault. If it's set to go
into the console mode, it's probably trying to read characters (commands)
from the console.

Noel

LA30 restore complete

[Fritz Mueller via cctalk]

Got the last replacement components I needed for my LA30 restore today, 
and finished it up!  Here's a short video of the LA30 connected as 
console to my restored PDP-11/45:


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

Re: Epson PX-8 specifically TF-10 problem...

[Brent Hilpert via cctalk]

On 2017-Dec-09, at 6:06 PM, allison via cctalk wrote:
> On 12/09/2017 07:52 PM, Fred Cisin via cctalk wrote:
>> On Sat, 9 Dec 2017, allison via cctalk wrote:
>>> I have several Epson PX-8s and i used them.. They work well with the
>>> various wedges I have.
>>> I also Have a PF-10 which is the portable 3.5" 40 track two side floppy.
>>> The problem is it randomly does not turn the media unless I give it a
>>> push to get it turning.
>>> Things checked:
>>> * Batteries, NEW fully charge (Both).
>>> * internal Power supplies, current voltage and bridged with external
>>>supplies does not help.
>>> * media checked for binding, it does not.
>>>  When it turns it reads and writes correctly and at the correct speed.
>>>  It may do so without help for many tries then will stop required a
>>> manual push.
>>> At first glance I though there were motor bearing issues but have
>>> verified
>>> this is not so.   If I force motor on and restrain it I has good torque
>>> and no
>>> dead spots.  All signals in the motor control look good on the scope.
>>> Any thoughts?
>> 
>> How does it detect the presence of a disk?   and/or disk change?
>> 
>> 
> Functions normally save for the motor does not always turn on command
> but will if manually pushed.  All other functions are normal.

How about a problem with the current supply to the motor, such as low gain in 
the driver.
A progressive failure may be just on the edge of supplying enough current to 
keep it rotating, but not enough for startup torque.

Re: Epson PX-8 specifically TF-10 problem...

[allison via cctalk]

On 12/09/2017 07:52 PM, Fred Cisin via cctalk wrote:
> On Sat, 9 Dec 2017, allison via cctalk wrote:
>> I have several Epson PX-8s and i used them.. They work well with the
>> various wedges I have.
>> I also Have a PF-10 which is the portable 3.5" 40 track two side floppy.
>> The problem is it randomly does not turn the media unless I give it a
>> push to get it turning.
>> Things checked:
>> * Batteries, NEW fully charge (Both).
>> * internal Power supplies, current voltage and bridged with external
>>    supplies does not help.
>> * media checked for binding, it does not.
>>  When it turns it reads and writes correctly and at the correct speed.
>>  It may do so without help for many tries then will stop required a
>> manual push.
>> At first glance I though there were motor bearing issues but have
>> verified
>> this is not so.   If I force motor on and restrain it I has good torque
>> and no
>> dead spots.  All signals in the motor control look good on the scope.
>> Any thoughts?
>
> How does it detect the presence of a disk?   and/or disk change?
>
>
Functions normally save for the motor does not always turn on command
but will if manually pushed.  All other functions are normal.


>
> Totally irrelevant to the matter at hand:
> BTW, how close to "industry standard" is the interface to the drive
> mechanism itself?   Would it be practical to replace the mechanism
> with one of the 80 track (and also 2 sided?) Epson drives?  Either the
> whole drive, if it is fairly "standard", or just the stepping
> mechanism if there is another Epson drive similar enough?

No its an oddball.  The read-wirite electronics are part of the
intelligent mainboard that communicates
with the pX-8 serially.  The only board that is part of the drive is the
motor control.

Its of the early 80s.   It would be nice to build a replacement with
more storage but the basic design
is a 68B03, 2732 and 765 with read/write amps and filter on that
board.    It would be easier to start
from scratch with an 8085 and a 37c65 but then that would require
figuring out the protocol and
patching the OS (CP/M-80 in Eprom) to accept the larger result.  If I
were to do that I'd do a solidstate
disk using CF or SD.  Its easier to do that using the PX-8 system bus
(parallel data, address and Z80 controls).

> Besides significant increase in capacity, it would simplify data
> interchange a bit.
> Although the track spacing is 67.5 tpi, instead of 135tpi, I wonder
> whether the track width is similarly different.
>

Its not unlike the 5.25" situation with track width as in the the higher
density drives
have narrower heads.  Not unlike Sa450 and FD33GFR.  I can read the
media with
a standard drive by double stepping but to create media I have to first
bulk
erase and then write only every other track or it has a poor error rate.

Allison

Re: Epson PX-8 specifically TF-10 problem...

[Fred Cisin via cctalk]

On Sat, 9 Dec 2017, allison via cctalk wrote:

I have several Epson PX-8s and i used them.. They work well with the
various wedges I have.
I also Have a PF-10 which is the portable 3.5" 40 track two side floppy.
The problem is it randomly does not turn the media unless I give it a
push to get it turning.
Things checked:
* Batteries, NEW fully charge (Both).
* internal Power supplies, current voltage and bridged with external
   supplies does not help.
* media checked for binding, it does not.
 When it turns it reads and writes correctly and at the correct speed.
 It may do so without help for many tries then will stop required a
manual push.
At first glance I though there were motor bearing issues but have verified
this is not so.   If I force motor on and restrain it I has good torque
and no
dead spots.  All signals in the motor control look good on the scope.
Any thoughts?


How does it detect the presence of a disk?   and/or disk change?



Totally irrelevant to the matter at hand:
BTW, how close to "industry standard" is the interface to the drive 
mechanism itself?   Would it be practical to replace the mechanism with 
one of the 80 track (and also 2 sided?) Epson drives?  Either the whole 
drive, if it is fairly "standard", or just the stepping mechanism if there 
is another Epson drive similar enough?
Besides significant increase in capacity, it would simplify data 
interchange a bit.
Although the track spacing is 67.5 tpi, instead of 135tpi, I wonder 
whether the track width is similarly different.


--
Grumpy Ol' Fred ci...@xenosoft.com

Epson PX-8 specifically TF-10 problem...

[allison via cctalk]

I have several Epson PX-8s and i used them.. They work well with the
various wedges I have.

I also Have a PF-10 which is the portable 3.5" 40 track two side floppy.

The problem is it randomly does not turn the media unless I give it a
push to get it turning.

Things checked:
* Batteries, NEW fully charge (Both).
* internal Power supplies, current voltage and bridged with external
   supplies does not help.
* media checked for binding, it does not.

 When it turns it reads and writes correctly and at the correct speed.
 It may do so without help for many tries then will stop required a
manual push.

At first glance I though there were motor bearing issues but have verified
this is not so.   If I force motor on and restrain it I has good torque
and no
dead spots.  All signals in the motor control look good on the scope.

Any thoughts?


Allison

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

Noel Chiappa via cctalk writes:

> > Aaron Jackson
>
> > if I try to dump using vtserver using a floppy which passed the
> > diagnostics, it fails.
>
> My copy of of the V7 standalone stuff (which I got from the VTServer
> directory) didn't include an RX driver. Where'd you manage to find one?
> (I need one for my own use, plus I want to look at the source, to help
> with this.)
>
>   Noel

I am using the version from here: https://github.com/sethm/vtserver/

It's likely that there is still an issue with reading the data, or the
floppy is still bad but some how managed to pass the test anyway.

Thanks,
Aaron.

Re: RX02 Difficulties

[Noel Chiappa via cctalk]

> Aaron Jackson

> if I try to dump using vtserver using a floppy which passed the
> diagnostics, it fails.

My copy of of the V7 standalone stuff (which I got from the VTServer
directory) didn't include an RX driver. Where'd you manage to find one?
(I need one for my own use, plus I want to look at the source, to help
with this.)

Noel

Re: RX02 Difficulties

[Jerry Weiss via cctalk]

> On Dec 9, 2017, at 1:25 PM, Aaron Jackson  wrote:
> 
> Thanks Jerry. That was very helpful. Found a stray piece of metal lying
> across the board next to an AND gate, which is slightly
> disconcerting. Possibly a stray wire clipping. Both drives pass the
> diagnostics.
> 
> It's strange though, if I try to dump using vtserver using a floppy
> which passed the diagnostics, it fails. So, not sure. Will have to
> investigate a bit more.
> 
> Thanks again,
> Aaron.

Glad it all worked out.   I can’t advise on the VTServer issue as 
I have not used it.  Perhaps others can advise further.

Have fun!

Jerry

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

> On Dec 8, 2017, at 5:17 PM, Aaron Jackson  wrote:
>>
 On Dec 8, 2017, at 12:53 PM, Aaron Jackson via cctalk 
  wrote:

> On Fri, Dec 8, 2017 at 3:03 PM, Aaron Jackson  
> wrote:
>>
>> Manual says it should be S1=off, S2=on for RX211 and RXV21
>
> In the photo, I think S1 is on and S2 is off. Check them with an
> ohmmeter if in doubt!
>
> -tony

 Yes - you are right. I switched them back to how they were when I got
 the drive. I think one of the switches was half down because XXDP
 actually does something now.

 Most of the tests now look something like this:

 CZRXFB0 DVC FTL ERR  00034 ON UNIT 00 TST 031 SUB 000 PC: 003476
 SECTOR ADR - LGC TST
 SECTOR ADDRESS ERROR
  EXPECTED SECTOR=18.
TARGET SECTOR=17.

 I suppose these should match?

 Starting to think I might need to confuse myself with my logic analyzer
 and the RX02 control board.

 Thanks,
 Aaron.
>>>
>>> To isolate the problem further, try to see if any of the errors follow
>>> the media  as you move them between drives.
>>>
>>> If the same errors occur on both drives, regardless of media then the
>>> RX02 system board or perhaps the Qbus controller are at fault.
>>> The field maintenance prints should allow you to trace the fault down
>>> a bit further,  with or w/o a logic analyzer.
>>>
>>> How many different types of errors do you see?
>>>
>>> Jerry
>>
>> Thanks for the info Jerry.
>>
>> I get read errors, data errors, density errors, sector addressing
>> errors. Probably every kind of error xxdp can give :)
>>
>> Please see this link if you are interested:
>>
>> https://aaronsplace.co.uk/private/o/48859c14f6a619a5316d6af37d60579c.txt
>>
>> I will take a proper look through the field manuals tomorrow, and also
>> try what you suggested with trying the same media in both drives.
>>
>> Thanks,
>> Aaron.
>
>
>  When you have many errors it can be hard to separate the primary fault(s) 
> from the knock-on errors.
>  The M7745/M7744 or Media Errors dominate the entries.
>
> 1) Try to verify the media is a DEC 8 Inch formatted RX02 or RX01 if you do 
> not know the source of the
>  the disks.   The disk should have only 1 hole punched for index  on the 
> media itself.   Even if it is
>  a DEC Brand, there’s still possibility that the media has been exposed 
> to strong magnetic fields.
>
>  I have not seen much natural  bit-rot on my floppy media, but YMMV.   If 
> could find someone local
>  with RX02 drives to confirm your media, that would also help rule out 
> some things.
>
>   Many third party drives and controllers that were DEC compatible also 
> had the ability to do a
>   low level format of media, something the native RX02 did not.  So if 
> the media type is correct, but
>   the format is not, they may be salvageable (with complete loss of 
> original data).
>
> 2) Check the connections between the drives and controllers. Gently clean 
> contacts, especially anything
> gold plated.  Getting clean signals from the floppies is critical if the 
> RW electronics are to function.
>
> 3) Try and contrast to the other drive as previously covered.
>
> This will help rule out a few things and provide some better direction.
>
>
> Jerry

Thanks Jerry. That was very helpful. Found a stray piece of metal lying
across the board next to an AND gate, which is slightly
disconcerting. Possibly a stray wire clipping. Both drives pass the
diagnostics.

It's strange though, if I try to dump using vtserver using a floppy
which passed the diagnostics, it fails. So, not sure. Will have to
investigate a bit more.

Thanks again,
Aaron.

Revive 11/34

[John Welch via cctalk]

I am reviving an 11/34. Cards are:

Back/Fans [M8266]  Front of machine where keypad is.

  [M8265]

  [M9312] [M7859]

  [M7762]

  [OPEN]  [M7860]

  [M7840]

  Bus grant in third from front slot

  [M9302] [M7856]
The 7856 is hooked to a cable/null modem (i think)/PC running 
XP


When I first powered on the programmers console said '7' and I powered 
off, then back on, and now it says '5'


Any suggestions as to what to try first?  I may have the bus grant in 
backwards.  I have other boards I can try.


Sincerely,
John Welch
:qw

Re: Revive 11/34

[John Welch via cctalk]

I also have an 11/04 that I went and drug out.  It is configured like this:

11/04:
   AAA BBB CCC DDD EEE FFF 
(Rear/Fans/Power Supply) 1 [M7263] (Front/Keypad/DC ON)
 2 [M7847] 
 3 [M7859] 
 4 [M7847] 
 5 GNT 
 6 [M7762] 
 7 [M7840] 
 8 [DILOG] 
 9   {nothing} 
   AAA BBB CCC DDD EEE FFF 
I am thinking I could put a M9203/M7856 into slot 9, and find a M9312 
for slot 3 and maybe this would fire up.  Any suggestions?



On 12/8/2017 3:50 PM, Jerry Weiss wrote:

On Dec 8, 2017, at 2:25 PM, John Welch via cctech  wrote:

I am reviving an 11/34. Cards are:

Back/Fans [M8266]  Front of machine where keypad is.

   [M8265]

   [M9312] [M7859]

   [M7762]

   [OPEN]  [M7860]

   [M7840]

   Bus grant in third from front slot

   [M9302] [M7856]
The 7856 is hooked to a cable/null modem (i think)/PC running XP

When I first powered on the programmers console said '7' and I powered off, 
then back on, and now it says '5'

Any suggestions as to what to try first?  I may have the bus grant in 
backwards.  I have other boards I can try.

Sincerely,
John Welch
:qw


1) The G727A bus grant card is keyed (somewhat). It should be in Row D 
(fourth from the back)
  It won’t seat evenly if reversed. At least that is what my scraped 
knuckles remember.

  You can temporarily pull it out to finish the check out.  There’s nothing 
past the
   M7840 that requires DMA.

2) Check the baud rate, stop bits and parity settings on both the Hyperterminal 
and the M785 to make sure they match.
  
3)  Are you seeing a single 7 or 5 on  KY11-LB Programmer Console or on the Hyperterminal?
  
  An other status led’s lit on the KY11-LB?


4) I don’t see any memory listed…  Do you have any M7847’s?

5) Grab a copy of EK-11034-UG-001 PDP-11-34 System User’s Manual for more info.


Jerry



--
Sincerely,
John Welch
281-353-4706 Home
713-725-7017 Cell
:qw

Re: Revive 11/34

[JCWelch via cctalk]

I added an M9302 in Slot9-AB and then moved the M7856 from the 11/34 to 
Slot9-CDEF of the 11/04.  I put a random M9312 in Slot3-AB I turned on the 
11/04.

I have six ‘0’ digits.  I push ctrl+hlt and the display shows 173066.  Looks 
like things are moving.

The ultimate goal is to hook this unit to an RL02, possibility an RX02, a 
console, and then image some RL02 disks.

I need to determine the console line settings and what M9312 with what boot 
ROMs makes sense.  Off to the ranch to see if I can dig a VT100 out of a barn.

Sent from my iPad

On Dec 9, 2017, at 5:07 AM, Henk Gooijen  wrote:

Ahh, that M9203 in slot 9, positions A – B, sounds more familiar (or is it 
M9302?)
The M7856 is often in slot 9 position C – F, when used as console.
Interesting, the 11/04 also has that M7840 installed. Could you pull that board 
(uhmmm, you did), and have a look at the texts in the etch? The “older” boards 
(UNIBUS, and many QBUS too) had a function identificaltion in the etch. Like 
the M7856, which says (IIRC) “SLU & RTC”. Maybe the identification in the Field 
Guide is wrong …
 
Before powering up the 11/04, I would do a thorough mechanical check of it, as 
many times described here … for example: loose screws in the box (took out my 
11/35 arghh, working on a repair!), cables not properly seated, dust and other 
things that should not be there. Just an overal inspection. You could makes 
notes of where the boards are placed and take a picture. Then remove the boards 
(observe ESD guide lines), turn on the power and check the voltages from the 
regulators. Easiest way to do that is removing the bottom cover.  Then you can 
check the voltages on the connection points at the rear end of the 
backplane(s). If needed, adjust the output voltage(s).
Turn off, and wait (measure!) that all voltages have dropped to near zero. 
Install the boards again, connect a terminal and proceed …
 
Back to the 11/34A.
I haven’t turned on my 11/34 for some time, so I forgot whether the 7-segment 
display has 6 or 7 digits.
But what I do know is that they are always all 6 (or 7) on. If that is not the 
case, there is definitely something wrong.
 
Van: cctech  namens John Welch via cctech 

Verzonden: Saturday, December 9, 2017 12:49:01 AM
Aan: Jerry Weiss; cct...@classiccmp.org
Onderwerp: Re: Revive 11/34
 
I also have an 11/04 that I went and drug out.  It is configured like this:

11/04:
   AAA BBB CCC DDD EEE FFF 
(Rear/Fans/Power Supply) 1 [M7263] (Front/Keypad/DC ON)
 2 [M7847] 
 3 [M7859] 
 4 [M7847] 
 5 GNT 
 6 [M7762] 
 7 [M7840] 
 8 [DILOG] 
 9   {nothing} 
   AAA BBB CCC DDD EEE FFF 
I am thinking I could put a M9203/M7856 into slot 9, and find a M9312 
for slot 3 and maybe this would fire up.  Any suggestions?


On 12/8/2017 3:50 PM, Jerry Weiss wrote:
> On Dec 8, 2017, at 2:25 PM, John Welch via cctech  
> wrote:
>> I am reviving an 11/34. Cards are:
>>
>> Back/Fans [M8266]  Front of machine where keypad is.
>>
>>[M8265]
>>
>>[M9312] [M7859]
>>
>>[M7762]
>>
>>[OPEN]  [M7860]
>>
>>[M7840]
>>
>>Bus grant in third from front slot
>>
>>[M9302] [M7856]
>> The 7856 is hooked to a cable/null modem (i think)/PC running 
>> XP
>>
>> When I first powered on the programmers console said '7' and I powered off, 
>> then back on, and now it says '5'
>>
>> Any suggestions as to what to try first?  I may have the bus grant in 
>> backwards.  I have other boards I can try.
>>
>> Sincerely,
>> John Welch
>> :qw
>
> 1) The G727A bus grant card is keyed (somewhat). It should be in Row D 
> (fourth from the back)
>   It won’t seat evenly if reversed. At least that is what my scraped 
> knuckles remember.
>
>   You can temporarily pull it out to finish the check out.  There’s 
> nothing past the
>M7840 that requires DMA.
>
> 2) Check the baud rate, stop bits and parity settings on both the 
> Hyperterminal and the M785 to make sure they match.
>   
> 3)  Are you seeing a single 7 or 5 on  KY11-LB Programmer Console or on the 
> Hyperterminal?
>   
>   An other status led’s lit on the KY11-LB?
>
> 4) I don’t see any memory listed…  Do you have any M7847’s?
>
> 5) Grab a copy of EK-11034-UG-001 PDP-11-34 System User’s Manual for more 
> info.

RE: Revive 11/34

[Henk Gooijen via cctalk]

Ahh, that M9203 in slot 9, positions A – B, sounds more familiar (or is it 
M9302?)

The M7856 is often in slot 9 position C – F, when used as console.

Interesting, the 11/04 also has that M7840 installed. Could you pull that board 
(uhmmm, you did), and have a look at the texts in the etch? The “older” boards 
(UNIBUS, and many QBUS too) had a function identificaltion in the etch. Like 
the M7856, which says (IIRC) “SLU & RTC”. Maybe the identification in the Field 
Guide is wrong …



Before powering up the 11/04, I would do a thorough mechanical check of it, as 
many times described here … for example: loose screws in the box (took out my 
11/35 arghh, working on a repair!), cables not properly seated, dust and other 
things that should not be there. Just an overal inspection. You could makes 
notes of where the boards are placed and take a picture. Then remove the boards 
(observe ESD guide lines), turn on the power and check the voltages from the 
regulators. Easiest way to do that is removing the bottom cover.  Then you can 
check the voltages on the connection points at the rear end of the 
backplane(s). If needed, adjust the output voltage(s).

Turn off, and wait (measure!) that all voltages have dropped to near zero. 
Install the boards again, connect a terminal and proceed …



Back to the 11/34A.

I haven’t turned on my 11/34 for some time, so I forgot whether the 7-segment 
display has 6 or 7 digits.

But what I do know is that they are always all 6 (or 7) on. If that is not the 
case, there is definitely something wrong.




Van: cctech  namens John Welch via cctech 

Verzonden: Saturday, December 9, 2017 12:49:01 AM
Aan: Jerry Weiss; cct...@classiccmp.org
Onderwerp: Re: Revive 11/34

I also have an 11/04 that I went and drug out.  It is configured like this:

11/04:
   AAA BBB CCC DDD EEE FFF 
(Rear/Fans/Power Supply) 1 [M7263] (Front/Keypad/DC ON)
 2 [M7847] 
 3 [M7859] 
 4 [M7847] 
 5 GNT 
 6 [M7762] 
 7 [M7840] 
 8 [DILOG] 
 9   {nothing} 
   AAA BBB CCC DDD EEE FFF 
I am thinking I could put a M9203/M7856 into slot 9, and find a M9312
for slot 3 and maybe this would fire up.  Any suggestions?


On 12/8/2017 3:50 PM, Jerry Weiss wrote:
> On Dec 8, 2017, at 2:25 PM, John Welch via cctech  
> wrote:
>> I am reviving an 11/34. Cards are:
>>
>> Back/Fans [M8266]  Front of machine where keypad is.
>>
>>[M8265]
>>
>>[M9312] [M7859]
>>
>>[M7762]
>>
>>[OPEN]  [M7860]
>>
>>[M7840]
>>
>>Bus grant in third from front slot
>>
>>[M9302] [M7856]
>> The 7856 is hooked to a cable/null modem (i think)/PC running 
>> XP
>>
>> When I first powered on the programmers console said '7' and I powered off, 
>> then back on, and now it says '5'
>>
>> Any suggestions as to what to try first?  I may have the bus grant in 
>> backwards.  I have other boards I can try.
>>
>> Sincerely,
>> John Welch
>> :qw
>
> 1) The G727A bus grant card is keyed (somewhat). It should be in Row D 
> (fourth from the back)
>   It won’t seat evenly if reversed. At least that is what my scraped 
> knuckles remember.
>
>   You can temporarily pull it out to finish the check out.  There’s 
> nothing past the
>M7840 that requires DMA.
>
> 2) Check the baud rate, stop bits and parity settings on both the 
> Hyperterminal and the M785 to make sure they match.
>
> 3)  Are you seeing a single 7 or 5 on  KY11-LB Programmer Console or on the 
> Hyperterminal?
>
>   An other status led’s lit on the KY11-LB?
>
> 4) I don’t see any memory listed…  Do you have any M7847’s?
>
> 5) Grab a copy of EK-11034-UG-001 PDP-11-34 System User’s Manual for more 
> info.
>
>
> Jerry
>

--
Sincerely,
John Welch
281-353-4706 Home
713-725-7017 Cell
:qw

Fwd: Re: Revive 11/34

[John Welch via cctalk]

Update:

This is the map of the machine:


   AAA BBB CCC DDD EEE FFF 
(Rear/Fans/Power Supply) 1 [M8266] (Front/Keypad/DC ON)
 2 [M8265] 
 3 [M9312] [M7859] 
 4 [M7891] 
 5 [M7762] 
 6 [M7860] 
 7 [M7840] 
 8 GNT 
 9 [M9302] [M7856] 
   AAA BBB CCC DDD EEE FFF 

Reseating the ribbon cable on the M7859 changed the display.  I have 
replaced the M7840 with a G7273.


Now when I power on it says (dim)0, (bright)0, blank, (dim)0, blank, blank.

I have reseated the M7859, I don't think I have another one.

Maybe I should hit it with a vacuum.

I had forgotten about needing to cut a wire for DMA.  Can you give me a 
refresher on how to tell which slots are cut?  I remember having to turn 
the chassis over and looking for a particular wire but that was >15 
years ago.

On 12/8/2017 3:17 PM, Henk Gooijen wrote:
>
>
>
>
>
> Van: John Welch via cctech
> Verzonden: vrijdag 8 december 2017 21:25
> Aan: cct...@classiccmp.org
> Onderwerp: Revive 11/34
>
>
>
> I am reviving an 11/34. Cards are:
>
> Back/Fans [M8266]  Front of machine where keypad is.
>
>    [M8265]
>
>    [M9312] [M7859]
>
>    [M7762]
>
>    [OPEN]  [M7860]
>
>    [M7840]
>
>    Bus grant in third from front slot
>
>    [M9302] [M7856]
> The 7856 is hooked to a cable/null modem (i think)/PC running
> XP
>
> When I first powered on the programmers console said '7' and I powered
> off, then back on, and now it says '5'
>
> Any suggestions as to what to try first?  I may have the bus grant in
> backwards.  I have other boards I can try.
>
> Sincerely,
> John Welch
> :qw
>
>
>
>
>
> It is not completely clear (to me) how the modules are installed in the
>
> backplane. Standing in front of the 11/34 processor box (looking at the
>
> console), slot number 1 is at the right side. Each slot has 6 positions.
>
> Position A is at the rear side, followed by B thru F. Position F is
>
> thus at the front side.
>
> There is no confusion about the first 4 slots.
>
>
>
> Slot 1 and 2 hold the 11/34A processor boards, with M8266 in slot 1,
>
> and M8265 in slot 2.
>
> Slot 3, positions A and B has the M9312 bootstrap/terminator board,
>
> and slot3, positions C thru F has the M7859 KY11-LB programmer's console
>
> interface board.
>
> Slot 4 holds the RL11 interface. This module does "DMA", so the NPR
>
> jumper must be cut (open) on the backplane.
>
> Slot 5 has an SPC in positions C thru F. I had to look it up; it is the
>
> DR11-C.
>
>
>
> We are up to slot 6. Now things get "interesting" ... is that M7840 a 
typo?

>
> The field guide says that this is a KE11-B Extended Arithmetic Element.
>
> I do not know that board, is it "hex" or "quad"?
>
> Not sure that board belongs there ... and if it is quad, I assume it has
>
> to be in positions C thru F. I would suggest to pull this module, and
>
> check the NPR wire presence on the backplane. You need a G727A or G7273
>
> in this slot when the M7840 is removed.
>
>
>
> If you are not skipping slots (see below), we are now at slot 7. There
>
> is probably a G727A grant continuity card (aka "knockle buster") in
>
> position D. That would be OK, but if the NPR jumper is cut on the
>
> backplane, you would need a G7273 continuity and NPR card in positions
>
> C - D. It is easy to have the G727 put in wrong. The 4 copper "jumper"
>
> traces should be facing the next higher-numbered slot.
>
>
>
> Then you say that the next slot has the M9202 (in position A - B) and
>
> the M7856 (SLU and RTC) in positions C thru F.
> The M9202 connects two system units (backplanes). So, what is the next
>
> backplane?  Or do you have the M9202 in slot 8 and slot 9, positions
>
> A - B?  I have never seen that ...
>
>
>
> I am missing one slot. The 11/34 backplane has 9 slots.
>
>
>
> When you power up the system, the display should show 6 octal numbers.
>
> If only one digit shows a number (7 or 5 or whatever), there is an
>
> issue with the console itself, or the M7859. The 6 digits of the display
>
> are multiplexed. Maybe the connection cable between the console and the
>
> M7859 - damaged/knicked? It is worth checking out the simpler things 
first.

>
>
>
> Henk.

--
Sincerely,
John Welch
281-353-4706 Home
713-725-7017 Cell
:qw

Re: Re; Revive 11/34

[Jerry Weiss via cctalk]

> On Dec 9, 2017, at 8:23 AM, Noel Chiappa via cctalk  
> wrote:
> 
> 
>> From: Jerry Weiss
> 
> And the same for Jerry...
> 
>> It won't seat evenly if reversed. At least that is what my scraped
>> knuckles remember. 
> 
> Nope, they go in quite fine the wrong way around; I just checked.
> 
> Make sure they are in the right connector (D) and the right way around; I
> haven't checked to see if damage is likely to result on an error - does
> anyone know offhand?

Yup, they insert reversed.

I remember the limited keying resulted in a offset that you could sense if
you had any feeling left in those fingers.  If both edges aren’t flush
with the connector, its backwards.

RE: Revive 11/34

[Henk Gooijen via cctalk]

AFAICR (…), the M7859 is sort of a UNIBUS device. The (front panel) console 
only communicates with the M7859.

The  M7859 writes/read to/from memory using the UNIBUS. Have a look at the 
schematics of the console.

I cannot remember whether a demux for the displays is on the console PCB, or on 
the M7859.

I also have a few dead M7859’s too. Of one I know that one of the two 4-bit 
memory chips is faulty, the others

I never investigated.



If you get 00 on the dsipaly and when halted it shows 173066 I presume it 
is looping. You can use the

front panel to single step. If it loops, it will repeatedly read from a device 
address which is most likely the

CSR of the boot device. 173066 is an address of the boot PROMs on the M9312.

So, your 11/04 seems fine so far …


Van: cctalk  namens Noel Chiappa via cctalk 

Verzonden: Saturday, December 9, 2017 5:15:18 PM
Aan: cctalk@classiccmp.org
CC: j...@mercury.lcs.mit.edu
Onderwerp: Re: Revive 11/34

> From: John Welch

> Can you give me a refresher on how to tell which slots are cut? I
> remember having to turn the chassis over and looking for a particular
> wire

Yeah; you can use the G7273 as a 'crib', since it has the NPG jumper on it.
That jumper goes from CA1 to CB1: component side, third connector (counting
from the A connector), first and second pins (again counting from the A
connector end). A lot of the slots will still have their jumpers in, which
is how you can confirm you're looking at the right pins; look for slots
without them.


> I also have an 11/04 that I went and drug out.

Yeah, the M7263 is the KD11-D CPU, the M7847's are MS11-E's (one of them will
be useful as a first-stage debug for the 11/34, once you've verified, in the
-11/04, that they work - the M7891 MS11-L is rare and valuable, I'd rather not
use that until everything up to that point in the -11/34 is known working -
you could try pulling the two M7847's from the -11/04 and try plugging in the
M7891, to verify that it's sort of OK).

> I am thinking I could put a M9203/M7856 into slot 9, and find a M9312
> for slot 3 and maybe this would fire up. Any suggestions?

As always, first pull all the boards and check the power supply (if it's been
a long time since it was last powered on, re-form the electrolytics in the
power supply first, before powering it on), then put in the _minimal_ set of
boards and get those working.


> I added an M9302 in Slot9-AB and then moved the M7856 from the 11/34 to
> Slot9-CDEF of the 11/04. I put a random M9312 in Slot3-AB I turned on
> the 11/04.
> I have six '0' digits. I push ctrl+hlt and the display shows 173066.
> Looks like things are moving.

Yup, that's working. Now you have a working machine, you can board-swap in
from the -11/34 to check other boards out. Major, major help!!

The first thing I'd try would be the M7859, KY11-LB, from the -11/34 over
here. If it doesn't work in the -11/04 (with only that board changed), i)
you've isolated the problem, and ii) you can probably use the one from the
-11/04 to get the -11/34 working (unless there's something _else_ broken in
the -11/34 as well).

NOTE: Don't plug the good one from the -11/04 into the -11/34 - or do
anything else with the -11/34 - until you've checked the voltages in the
-11/34!!!

If the M7859, KY11-LB from the -11/34 _does_ work in the -11/04, time to keep
looking. The console itself is so dumb it's unlikely to be the problem, but
you never know; might we worth swapping. I'm having a hard time seeing what
problems in the /34 CPU, etc could cause the symptoms you're seeing - are
they still there with only the absolute minimal board set?

Noel

Re: Revive 11/34

[Noel Chiappa via cctalk]

> From: John Welch 

> Can you give me a refresher on how to tell which slots are cut? I
> remember having to turn the chassis over and looking for a particular
> wire

Yeah; you can use the G7273 as a 'crib', since it has the NPG jumper on it.
That jumper goes from CA1 to CB1: component side, third connector (counting
from the A connector), first and second pins (again counting from the A
connector end). A lot of the slots will still have their jumpers in, which
is how you can confirm you're looking at the right pins; look for slots
without them.


> I also have an 11/04 that I went and drug out.

Yeah, the M7263 is the KD11-D CPU, the M7847's are MS11-E's (one of them will
be useful as a first-stage debug for the 11/34, once you've verified, in the
-11/04, that they work - the M7891 MS11-L is rare and valuable, I'd rather not
use that until everything up to that point in the -11/34 is known working -
you could try pulling the two M7847's from the -11/04 and try plugging in the
M7891, to verify that it's sort of OK).

> I am thinking I could put a M9203/M7856 into slot 9, and find a M9312
> for slot 3 and maybe this would fire up. Any suggestions?

As always, first pull all the boards and check the power supply (if it's been
a long time since it was last powered on, re-form the electrolytics in the
power supply first, before powering it on), then put in the _minimal_ set of
boards and get those working.


> I added an M9302 in Slot9-AB and then moved the M7856 from the 11/34 to
> Slot9-CDEF of the 11/04. I put a random M9312 in Slot3-AB I turned on
> the 11/04.
> I have six '0' digits. I push ctrl+hlt and the display shows 173066.
> Looks like things are moving.

Yup, that's working. Now you have a working machine, you can board-swap in
from the -11/34 to check other boards out. Major, major help!!

The first thing I'd try would be the M7859, KY11-LB, from the -11/34 over
here. If it doesn't work in the -11/04 (with only that board changed), i)
you've isolated the problem, and ii) you can probably use the one from the
-11/04 to get the -11/34 working (unless there's something _else_ broken in
the -11/34 as well).

NOTE: Don't plug the good one from the -11/04 into the -11/34 - or do
anything else with the -11/34 - until you've checked the voltages in the
-11/34!!!

If the M7859, KY11-LB from the -11/34 _does_ work in the -11/04, time to keep
looking. The console itself is so dumb it's unlikely to be the problem, but
you never know; might we worth swapping. I'm having a hard time seeing what
problems in the /34 CPU, etc could cause the symptoms you're seeing - are
they still there with only the absolute minimal board set?

Noel

Re; Revive 11/34

[Noel Chiappa via cctalk]

> From: Henk Gooijen

A few comments to you about Henk's points:

> Standing in front of the 11/34 processor box (looking at the console),
> slot number 1 is at the right side.

That's for the 10-1/2" box; the 5-1/4" is different. Which is this?

> Each slot has 6 positions. Position A is at the rear side, followed by
> B thru F. Position F is thus at the front side.

I prefer to say that connector A is at the right, when facing the component
side of a hex-wide card which has the handles at the top, and the contact
fingers at the bottom.

(Make doubly sure you never plug a card in backwards! It will almost
certainly kill the card. In theory they are keyed so you can't, but idiots
like me have been known to do it! :-)

> The 4 copper "jumper" traces should be facing the next higher-numbered
> slot.

I.e. on the so-called 'solder' side of the card, not the 'component' side.
(All the cards face the same way.)

> When you power up the system, the display should show 6 octal numbers.
> If only one digit shows a number (7 or 5 or whatever), there is an
> issue with the console itself, or the M7859.

The M7859's are, for some reason, particularly prone to failures. About half
the ones I've seen weren't working at first. There's no one chip that seems
to be the usual suspect, I've seen several different failure modes.


> From: Jerry Weiss

And the same for Jerry...

> It won't seat evenly if reversed. At least that is what my scraped
> knuckles remember. 

Nope, they go in quite fine the wrong way around; I just checked.

Make sure they are in the right connector (D) and the right way around; I
haven't checked to see if damage is likely to result on an error - does
anyone know offhand?

> Check the cable orientation. 

Note that one DEC manual (the KY11-LB Maintenance Manual) shows the wrong
orientation! See here:

  http://gunkies.org/wiki/KY11-LB_Programmer%27s_Console

at "Cable Connection and Documentation Error" for more.

> I believe the cabling for the M7859 is a little different between the two

The /34 has two narrow 'maintainence' cables, the /04 only one. But you can
ignore these if you're not using the maintenance mode on the front console,
and only plug in the wide cable.

Noel

Revive 11/34

[Noel Chiappa via cctalk]

> From: John Welch

> Any suggestions as to what to try first? 

I would _definitely_ start by pulling _all_ the cards you can, to get down to
the simplest possible configuration. Once that works, start adding things
back in, one at a time.

If that configuration doesn't work, first try the obvious things (clean and
re-seat, check voltages, etc). If that doesn't get it running, it's time for
a oscilloscope or logic analyzer. (We can help you through that.)

So I'd start with the CPU (M8266/M8265), front-terminator/bootstrap ROM
(M9312), the front console card (M7859), and rear-terminator (M9302) (which
you need for grant turnaround, see next paragraph). That's it.

IIRC, the /34 will complain if the bus grant chain is not complete (I really
need to look at the prints/ucode to understand why this is so - other -11's
will run basic functionality fine with an interrupted grant chain), so plug in
grant jumpers in every unused slot. Also, check the backplane, to see which
slots have had their NPG jumpers pulled, and either i) use a G7273 jumper (the
dual boards which contain an NPG jumper as well as the BR jumpers) in those
slots, or replace the jumpers.

I _think_ the machine will be OK without any memory, but I don't have a
running 11/34 to test that on. (Only my /04 is running at the moment.) I can
plug my /34 cards in and try it, if that will help. But maybe someone else
knows. So maybe you'd have to add a memory card, but that would _definitely_
be the biggest configuration I'd try until the basic machine is working.

You can examine the MMU registers in the CPU to check that the bus/console etc
are working - first read, then write. And IIRC the CPU general registers are
accessible from the bus too - I know they are in the -11/04 (which uses the
same front console).

Noel

RE: IBM 3270 controller emulation

[Dave Wade via cctalk]

Folks,

The tn3270 support in Hercules emulates channel attached 3270's not bi-sync so 
may not be a good source of info. On a local 3270 controller each screen has a 
unique channel-controller-device address.
On a bi-sync device only the line going to the device, additional addressing is 
required using poll/select sequences...

The total reference book is the Datastreams Programmers Reference.

http://www.bitsavers.org/pdf/ibm/3270/GA23-0059-4_3270_Data_Stream_Programmers_Reference_Dec88.pdf

This covers most of what you want to know. Chapter 9 covers the differences 
encountered in a bi-sync environment.

If you need to understand the lower level bi-sync and the poll-select 
protocols, which I think may be what is blocking you at present try this:-

http://www.euclideanspace.com/coms/protocol/bi_sync/dlc/index.htm

its not wonderful but it may help. Looking at the chapter on 3270's in the VM 
sysgen might help explain the addressing (it might not)...

http://www.bitsavers.org/pdf/ibm/370/VM_370/Release_6/GC20-1801-10_VM370_Sysgen_Rel_6_Jan80.pdf

Dave

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Guy
> Sotomayor Jr via cctalk
> Sent: 09 December 2017 01:38
> To: Charles Anthony ; General Discussion: On-
> Topic and Off-Topic Posts 
> Subject: Re: IBM 3270 controller emulation
> 
> It might be worthwhile to look at the source for hercules (370, 390, z/series)
> emulator since that includes support for 3270 terminals through tn3270.  It’s
> pretty good since I can use actual 327x CUT terminals connected to a 3174
> controller which connects to hercules emulating the mainframe.
> 
> TTFN - Guy
> 
> > On Dec 8, 2017, at 5:22 PM, Charles Anthony via cctalk
>  wrote:
> >
> > I am trying to wire 3270 support into the DPS8/M emulator.
> >
> > Multics supports 3270 via a bisync connection to the 3270 controller.
> > Multics sends commands to the Front End Network processor, which
> > (originally) passed the commands down the bisync line to the 3270.
> >
> > I have a running Multics and running 3270 display emulators using
> > tn3270
> > (3270 over telnet), so I need to write the code that maps the Multics
> > commands into 3270 controller commands (and vice versa) and manages
> > the telnet connections to the 3270 display emulators and maps the
> > tn3270 traffic into 3270 controllers.
> >
> > I don't need to actually implement the bisync communications; the
> > controller emulator will be running inside the FNP emulator, but I
> > need to express controller responses to Multics in the bisync format,
> > as Multics is expecting that the responses arrived over a bisync connection.
> >
> > The problem is that I have no idea how the 3270 controllers worked;
> > I've looked through the bitsavers collection; those documents are
> > largely concerned with the displays and tend to treat the controllers
> > as 'black boxes' that just do the right thing.
> >
> > So I am seeking pointers to documentation that will give me a better
> > grasp of the controller functionality and/or discussions with someone
> > who knows how they work.
> >
> > Thanks,
> > -- Charles