[cctalk] Re: looking for DQ696 and RQDX3

[Aaron Jackson via cctalk]

Hi Nigel,

Toby Thain is currently without access to email but would like to speak
to you about an RQDX3. He asked me to email you on his behalf. Would you
be able to call him?

Cheers,
Aaron

Nigel Johnson Ham via cctalk  writes:

> Hi folk,
>
> I am still looking for a DQ696 to allow me to get ESDI drives going on
> both my microVAX and 11/73 since the Webster RQD11 controller failed I
> only have the one.  I'd also like to get old of an RQDX3 since I built
> a Gesswein emulator and have nothing to test it with :-)
>
> Any help appreciated,
>
> Nigel


-- 
https://aaronsplace.co.uk

Re: IEEE-488 on the PDP-11

[Aaron Jackson via cctalk]

> In my pile of DEC computer stuff I have a DEC qbus IBV11 IEEE-488
> controller board (M7954) with cable (BN11-A) that connects to the GPIB bus.
>
> It would be interesting to try this out, but I don't have the DEC
> 'Instrument Bus Subroutines' that work under RT-11. Does anyone have
> this package? Or know where it can be found?
>
> Doug

I recently wrote a driver for the IBV11 card under 2.11BSD. I have it
talking to my scope and logic analyser without issue.

https://github.com/AaronJackson/2.11BSD/pull/1/files

Not the cleanest code but my first try at writing a driver :-)

Cheers,
Aaron

Re: PDP-11/73 boot issues

[Aaron Jackson via cctalk]

> Pete Turnbull via cctalk writes:
>
>> On 21/09/2021 20:34, Chris Zach via cctalk wrote:
>>> Can an MXV11 be used in a 22 bit system? I thought it was an 18 bit
>>> device?
>>
>> MXV11-B is 22-bit.  MXV11-A is 18-bit but supposedly can be used in a 
>> 22-bit system if the RAM is disabled.
>
> Yeah this is a 22 bit card. Josh sent me an xxdp image which I could
> easily boot from my scsi2sd (thanks!).  Seems to be reporting an error
> with the CPU unfortunately:
>
> ]] .R ZKDJ??
> ]] ZKDJB2.BIC
> ]] 
> ]] ERROR WHILE TESTING BOARD FUNCTIONS
> ]] ERROR # =001166
> ]] ERROR PC =040662
> ]] 043632
>
> This happens regardless of whether W9 is installed or not (supposedly
> disables the LTC register on the CPU?)
>
> I'll see if I can borrow another CPU card form a friend this
> weekend. Unless anyone else has any ideas?  Another suggestion on IRC
> was to disable the PSU LTC and enable the LTC on MXV11 but will need to
> look up some details on how to do this.
>
> Thanks,
> Aaron

Probing the BEVENT line and it was 50hz etc, but then I realised it
wasn't actually the right voltage. Replaced a transistor and now it
boots!

Cheers,
Aaron

[no subject]

[Aaron Jackson via cctalk]

Subject: Re: PDP-11/73 boot issues
References: <87ilytoikj@carbon.nat.rhwyd.co.uk> 
 
<87fstxohuj@carbon.nat.rhwyd.co.uk> 
 
<21789e85-2aa4-3b61-db31-b21fd8c08...@dunnington.plus.com> 
<87czp1obv4@carbon.nat.rhwyd.co.uk>
User-agent: mu4e 0.9.18; emacs 27.2
In-reply-to: <87czp1obv4@carbon.nat.rhwyd.co.uk>


Aaron Jackson via cctalk writes:

> Pete Turnbull via cctalk writes:
>
>> On 21/09/2021 20:34, Chris Zach via cctalk wrote:
>>> Can an MXV11 be used in a 22 bit system? I thought it was an 18 bit
>>> device?
>>
>> MXV11-B is 22-bit.  MXV11-A is 18-bit but supposedly can be used in a 
>> 22-bit system if the RAM is disabled.
>
> Yeah this is a 22 bit card. Josh sent me an xxdp image which I could
> easily boot from my scsi2sd (thanks!).  Seems to be reporting an error
> with the CPU unfortunately:
>
> ]] .R ZKDJ??
> ]] ZKDJB2.BIC
> ]] 
> ]] ERROR WHILE TESTING BOARD FUNCTIONS
> ]] ERROR # =001166
> ]] ERROR PC =040662
> ]] 043632
>
> This happens regardless of whether W9 is installed or not (supposedly
> disables the LTC register on the CPU?)
>
> I'll see if I can borrow another CPU card form a friend this
> weekend. Unless anyone else has any ideas?  Another suggestion on IRC
> was to disable the PSU LTC and enable the LTC on MXV11 but will need to
> look up some details on how to do this.

Had a nice cycling trip this evening to pick up a spare 11/73
card. Unfortunately it did not fix my issues so I'll have to do some
more digging.

Has anyone disconnected the BEVENT line and used a signal generator to
provide the LTC? Curious to try this to figure out if mine is just being
noisy or something.

Thanks,
Aaron

Re: PDP-11/73 boot issues

[Aaron Jackson via cctalk]

Pete Turnbull via cctalk writes:

> On 21/09/2021 20:34, Chris Zach via cctalk wrote:
>> Can an MXV11 be used in a 22 bit system? I thought it was an 18 bit
>> device?
>
> MXV11-B is 22-bit.  MXV11-A is 18-bit but supposedly can be used in a 
> 22-bit system if the RAM is disabled.

Yeah this is a 22 bit card. Josh sent me an xxdp image which I could
easily boot from my scsi2sd (thanks!).  Seems to be reporting an error
with the CPU unfortunately:

]] .R ZKDJ??
]] ZKDJB2.BIC
]] 
]] ERROR WHILE TESTING BOARD FUNCTIONS
]] ERROR # =001166
]] ERROR PC =040662
]] 043632

This happens regardless of whether W9 is installed or not (supposedly
disables the LTC register on the CPU?)

I'll see if I can borrow another CPU card form a friend this
weekend. Unless anyone else has any ideas?  Another suggestion on IRC
was to disable the PSU LTC and enable the LTC on MXV11 but will need to
look up some details on how to do this.

Thanks,
Aaron

Re: PDP-11/73 boot issues

[Aaron Jackson via cctalk]

>
> This is an interesting amount of physical memory to report (1152K).  What
> memory board(s) do you have installed?
>
> Other than that, this output looks sane to me.  I'd suggest booting XXDP
> and running CPU, memory diagnostics from there.
>
> - Josh

Thanks, I forgot about XXDP. I have ran a memory test from the boot ROM
which came back ok.

The unusual amount of RAM comes from two MSV11-PL 512K cards, plus the
128K from MXV11-BF.

Thanks,
Aaron

PDP-11/73 boot issues

[Aaron Jackson via cctalk]

Hi all,

My PDP-11/73 has started misbehaving after several years of being very
stable. It is showing symptoms similar to when I've forgotten to enable
the LTC in the past, except this time, it is enable.

Power supply seems good - +5V, +12V, all seems there and appears to be
stable. I've probed the LTC going onto the backplane and I'm getting
50Hz. It looks a tad noisy, not sure if this is a problem. I will see if
I can get a picture of it, but it has very distinct rises and falls, so
hopefully that's ok. Looks to be about 50% duty cycle.

I've attempted several builds of the kernel, including the
out-of-the-box build from 2.11BSD distribution. I've also compiled a
shrunk down kernel without a bunch of devices I don't have, but it still
fails to work. I am using a SCSI2SD so it's easy for me to copy images
and test them in SIMH - they all boot fine in SIMH with a similar setup
(mscp, tmscp, 11/73, 1MB-ish RAM).

Does anyone have any ideas what might be causing this? I've run out of
ideas unfortunately. I'll stick a dump of the boot below, with debug
flag passed showing output from autoconfig.

I've also tried it without the tmscp card - just CPU, RAM and Emulex
UC07 in MSCP mode for scsi disk. I have tried it with less memory, and
I've tried removing the halt jumper from the 11/73 board (W5 if I
remember correctly)

Cheers,
Aaron

-
^C
BOOT>  DU 0

73Boot from ra(0,0,0) at 0172150
: ra(0,0,0)unix -D
Boot: bootdev=02400 bootcsr=0172150

2.11 BSD UNIX #116: Wed Dec 31 18:01:57 CST 1969 
r...@localhost.2bsd.com:/usr/src/sys/GENERIC

ra0: Ver 5 mod 13
ra0: RA81  size=1216601

phys mem  = 1179648
avail mem = 959040
user mem  = 307200


_hkprobe = 0
_hkattach = 143330
_hkVec = 0
hkintr = 120
_htprobe = 0
_htattach = 143550
_htVec = 0
htintr = 150
_raprobe = 0
_raattach = 34270
_raVec = 34200
raintr = 100
_rkprobe = 0
_rkattach = 144650
_rkVec = 0
rkintr = 130
_rlprobe = 0
_rlattach = 144770
_rlVec = 0
rlintr = 110
_tmprobe = 0
_tmattach = 143610
_tmVec = 0
tmintr = 160
_tmsprobe = 0
_tmsattach = 143740
_tmsVec = 143730
tmsintr = 200
_tsprobe = 0
_tsattach = 143660
_tsVec = 0
tsintr = 170
_xpprobe = 0
_xpattach = 0
_xpVec = 0
xpintr = 0
endvec = 1000
_conf_int = 16124
CGOOD = 14
CBAD = 24
_nextiv = 5500
trap = 4150
_version = 17400
KERN_NONSEP = 0
Grab 177440 = 36556hk ? csr 177440 vector 210 skipped:  No CSR.
Grab 172440 = 36556ht ? csr 172440 vector 224 skipped:  No CSR.
Grab 172150 = 0Grab 156 = 240Grab 154 = 100Stuff 14 @ 154
Stuff 340 @ 156
probe ra: return conf_int:Stuff 100 @ 154
Stuff 240 @ 156
ra ? csr 172150 vector 154 bad probe value 224.
Grab 177400 = 36556rk ? csr 177400 vector 220 skipped:  No CSR.
Grab 174400 = 36556rl ? csr 174400 vector 160 skipped:  No CSR.
Grab 172520 = 36556tm ? csr 172520 vector 224 skipped:  No CSR.
Grab 174500 = 0Grab 262 = 0Grab 260 = 0tms ? csr 174500 vector 260 interrupt 
vector already in use.
Grab 172520 = 36556ts ? csr 172520 vector 224 skipped:  No CSR.
xp ? csr 176700 vector 254 skipped:  No autoconfig routines.


At this point it is stuck no matter how long I wait.

Re: RL02 Tracking (Aaron Jackson)

[Aaron Jackson via cctalk]

>
> Aaron,
>
> One thing I would check is the motor bearings. What happens on electro
> mechanical assemblies left in store for years is that ball bearing
> grease lube dries out and hardens, resulting in lumpy rotation and
> increased friction that can be detected by rotating the spindle by
> hand. RLxx series drives were very reliable typically, but the head
> movement assy is pretty cheap and cheerful. Converting spindle to
> linear movement, minimum parts count, dc brush brush motor, means that
> all the bits need to be smooth in operation, with no stiction anywhere
> in it's travel.
>
> I would take the motor out and if it can't be stripped to clean the
> bearings, use a dab of light clock oil to relube. Also, check the
> brushes and clean / polish the commutator. Any other ball bearings
> in the path, same process. DC brush motors can be a nightmare for
> that sort of precision positioning application...
>
> Chris

Thanks Chris, I will look into trying to measure the wobble (if there is
any present) of the spindle. Might be a fun project to strip this down
anyway and see what's going on. Hopefully not too much more complicated
than a bicycle but we'll see...

Aaron



This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

Re: RL02 Tracking

[Aaron Jackson via cctalk]

On 22 December 2020 at 22:17 GMT, shad via cctalk wrote:
>> The ready lamp flashes not when the servo burst is >visible, but when the
> heads are just before it.
>> Why? Well, I probably set the gain too high on the read/write module.
>
> Hello,
> I'm sure you read the manual, however I add some explanation to be sure.
> The best head position is not where a servo track is at maximum amplitude
> (head is exactly centered to a servo track), but where you read two servo
> tracks with the same amplitude (so head is exactly between two servo
> tracks, in middle position).
> Comparative measurement of two servo tracks allow the servo control to
> understand the position of the head in respect to data track.
> If the best position for data track is not where servo have same amplitude
> probably the head is misaligned or the spring support of the head bent /
> deformed.
> To analyze head circuits you need a good oscilloscope, you should be able
> to see burst of servo tracks and data tracks too, with two channels you can
> understand if analog to digital threshold / pulses signal conversions do
> work as expected.
> Time ago I fixed an RL02 having a malfunctioning head amplifier circuit.
> The gain was too low. When I increased it rotating variable resistor, the
> circuit begun to ring (barely auto-oscillate), so was nearly unstable. Data
> and servo signals were corrupted, but this was visible only zooming on
> oscilloscope after careful trigger alignment.
> I don't remember exactly what I did, but some capacitors needed
> replacement, then I tuned head gain while loading a platter to the best
> position for operation, maybe slightly lower than manual recommendations.
> Then it worked perfectly.
>
> Andrea

Hi Andrea,

Thanks for this. My understanding is that the S1 and S2 servo bursts are
passed through a comparator and then integrated. When the head is
directly over the target track, S1 (becomes E1 after integration) is a
perfect saw tooth, while E2 'saw tooths' away from 0V.

After performing the amplitude adjustment, the potentiometer was very
close to max, and I was getting around 650mV from the cartridge, but the
noise floor was quite high. The manual also says that the outer guard
track should not have an amplitude greater than 2.5V. Presumably the
amplitude on the platter is higher the further out the track is, perhaps
due to the amount of space available given 40 sectors per track.

With this amplitude set as mentioned, loading the cartridge results in
this head unpredictable oscillating behaviour, but as I mentioned, the
ready light only comes on briefly, and only when the heads are before
the outer guard. Basically, as far as they could be off the platter
before being lifted by the ramp.

Reducing the amplitude slightly prevents this oscillating behaviour, but
the ready lamp does not come on at all. Increasing it to the very max
causes very extreme oscillation, sometimes aggressively unloading the
heads.

I happen to have three of the read/write modules, and they all exhibit
this behaviour. Not to say that caps don't need to be changed, but it
seems unlikely that all of them would need this.

I have a fairly decent scope and have been able to do some very nice
captures of the servo bursts. They are not perfectly sinusoidal but I
think close enough given the age of the heads.

I'll go through the caps at some point anyway to double check. Looking
at the schematic I'm guessing they are either ceramic or tants.

thanks again,
Aaron


This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

Re: RL02 Tracking

[Aaron Jackson via cctalk]

On 22 December 2020 at 10:33 GMT, Aaron Jackson via cctalk wrote:
> On 22 December 2020 at 08:01 GMT, Christian Corti via cctalk wrote:
>
>> On Mon, 21 Dec 2020, Aaron Jackson wrote:
>>> The status currently is that the heads will load, and the ready lamp
>>> flashes as the heads wobble back and forth very slightly, trying to lock
>>> onto the outer servo guard band. Probing TP2 of the read/write module, I
>>> can see the S1 servo burst flash (roughly in time with the ready
>>> lamp). If I disconnect power to the servo motor, I can manually move the
>>> head onto the outer guard band (less than a mm away) and monitoring the
>>> position signal (TP15 on the drive logic module) shows this to be close
>>> to 0. So, I'm very confused.
>>
>> I've had almost the identical problem with a RL02 drive from a friend. It
>> would start and load the heads, but the ready light would flicker or not
>> even come on. After a measuring session I discovered that if I manually
>> select the other head, everything would be fine. And if I disabled the
>> servo motor I could manually lock onto the track on side 0, but then side
>> 1 was out of alignment. So the alignment between the two heads was wrong
>> and I had then aligned one of the heads so that the two would lock onto
>> their corresponding track. The drive works fine since then.
>>
>
> That's very interesting to know. Thanks! I have already performed the
> head alignment and they looked well aligned when switching between the
> two heads, but I didn't have any luck getting it to lock onto the first
> track with the head select jumper in. I'll mess about with this some
> more, it is at least reassuring that someone elses drive has displayed
> similar behaviour.
>

Alright been playing around with that for an hour or so. I think I'm
beginning to understand what has happened.

The ready lamp flashes not when the servo burst is visible, but when the
heads are just before it. Why? Well, I probably set the gain too high on
the read/write module.

... Why did I set the gain too high?  Probably both my cartridges are
weak and to compensate for this, I set the read/write module's amplitude
too high during the "Read Signal Amplitude Adjustment" in Chapter 3 of
the tech manual.

I think having this amplitude too high amplifies the noise too much,
which makes the drive believe it's found the first track, but is
struggling to read the servo bursts because they're not actually there
there, hence the slight head oscillation.

Does this sound like a reasonable theory?

If so, I suppose now might be a reasonable time to ask the list if
anyone in the UK has a known *good* cartridge which they'd mind selling
me for a sensible price? I know there aren't too many of them floating
about the UK these days.

Thanks everyone who has given me some pointers so far

Aaron



This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

Re: RL02 Tracking

[Aaron Jackson via cctalk]

On 22 December 2020 at 08:01 GMT, Christian Corti via cctalk wrote:

> On Mon, 21 Dec 2020, Aaron Jackson wrote:
>> The status currently is that the heads will load, and the ready lamp
>> flashes as the heads wobble back and forth very slightly, trying to lock
>> onto the outer servo guard band. Probing TP2 of the read/write module, I
>> can see the S1 servo burst flash (roughly in time with the ready
>> lamp). If I disconnect power to the servo motor, I can manually move the
>> head onto the outer guard band (less than a mm away) and monitoring the
>> position signal (TP15 on the drive logic module) shows this to be close
>> to 0. So, I'm very confused.
>
> I've had almost the identical problem with a RL02 drive from a friend. It
> would start and load the heads, but the ready light would flicker or not
> even come on. After a measuring session I discovered that if I manually
> select the other head, everything would be fine. And if I disabled the
> servo motor I could manually lock onto the track on side 0, but then side
> 1 was out of alignment. So the alignment between the two heads was wrong
> and I had then aligned one of the heads so that the two would lock onto
> their corresponding track. The drive works fine since then.
>
> Christian


That's very interesting to know. Thanks! I have already performed the
head alignment and they looked well aligned when switching between the
two heads, but I didn't have any luck getting it to lock onto the first
track with the head select jumper in. I'll mess about with this some
more, it is at least reassuring that someone elses drive has displayed
similar behaviour.

thanks
Aaron


This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

Re: RL02 Tracking

[Aaron Jackson via cctalk]

>> > I've posted a few times over the years about RL02 drives and my
>> > difficulty getting them working (no luck so far!). I've spent the past
>> > few days working on one of them and have made some progress.
>> >
>> > The status currently is that the heads will load, and the ready lamp
>> > flashes as the heads wobble back and forth very slightly,
>> I dropped an RL02 cartridge, and needed to get it to load
>> one more time to get programs off it.
>> The ready lamp was a dim, slightly flickering glow.  I
>> figured the platter had been knocked off center.
>> I loosened the bolts at tapped it a bit until it looked
>> better centered.  It took a couple tries, but then the ready
>> light came on fully bright, and I was able to mount the disk
>> and read it.
>>
>> I don't know if that could be your problem.  If you get a
>> solid servo signal with the motor disconnected, then this is
>> not the same problem.
>>
>
> To add my two cents, I've also seen this behavior on RL02 packs that have
> been degaussed.  It might be worth your time to find someone with a known
> working RL02 drive (or known working RL02 pack) so you can confirm that
> your packs are good.

Thanks Jon, that's handy to know for the future but indeed solid servo
signals with the motor disconnected.

Presumably the servo bursts would not be visible if the cartridges had
been erased that way, since this is encoded in the data tracks
themselves. However, it does make me wonder if the cartridges have just
been exposed to some wild temperature fluctuations, since the signal
from either appears to be a little weak. I suppose the worst thing this
would lead to in my case is over compensating the read/write head
adjustment, which means actually good cartridges don't work. I'll try
and get hold of another cartridge from a friend once it's safe to do
so. Although, he hasn't attempted to get his RL02 drives working yet
so...

Cheers,
Aaron


This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

Re: RL02 Tracking

[Aaron Jackson via cctalk]

On 21 December 2020 at 19:08 GMT, Aaron Jackson via cctalk wrote:

> Supposedly if the main drive motor is bad it will emit noise and cause
> the tachometer (just a coil of wire on the head carriage) to produce
> spikes. Mine does look quite noisy but I'm not sure what's causing it. I
> would expect that if it was picking up noise, I'd be able to detect this
> with my oscilloscope probe by putting it close to the motor, but I
> can't. Any ideas?
>
> Also, thanks to pjustice on irc who suggested checking the spindle
> grounding button. Mine is very worn out but I've been able to apply some
> pressure to it from the under side which reduces the resistance of the
> spindle to ground, from 400 ohm to 0 ohm. This didn't make the situation
> any better though.

This signal appears to be normal and traces back to the seek control
ROM. The question is what causes this output to become high.  Presumably
the 'tachometer AC noise check' does not account for whatever the issue
is with my drive.

Will probe the rest of the ROM outputs tomorrow and continue to trace
backwards.

Aaron


This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

RL02 Tracking

[Aaron Jackson via cctalk]

Hi everyone

I've posted a few times over the years about RL02 drives and my
difficulty getting them working (no luck so far!). I've spent the past
few days working on one of them and have made some progress.

The status currently is that the heads will load, and the ready lamp
flashes as the heads wobble back and forth very slightly, trying to lock
onto the outer servo guard band. Probing TP2 of the read/write module, I
can see the S1 servo burst flash (roughly in time with the ready
lamp). If I disconnect power to the servo motor, I can manually move the
head onto the outer guard band (less than a mm away) and monitoring the
position signal (TP15 on the drive logic module) shows this to be close
to 0. So, I'm very confused.

I've worked through chapter 3 multiple times...

- voltage checks - all good
- sector transducer output check - all good
- sector pulse timing check - all good
- read signal amplitude check and adjustment - all good
- positioner radial alignment - required some tweeking but is good now
- head alignment - looks good to me
- spindle runout check - a little noisy but within spec
- position signal gain check - looked ok
- tachometer ac noise pickup check - this one didnt look so good

Supposedly if the main drive motor is bad it will emit noise and cause
the tachometer (just a coil of wire on the head carriage) to produce
spikes. Mine does look quite noisy but I'm not sure what's causing it. I
would expect that if it was picking up noise, I'd be able to detect this
with my oscilloscope probe by putting it close to the motor, but I
can't. Any ideas?

Also, thanks to pjustice on irc who suggested checking the spindle
grounding button. Mine is very worn out but I've been able to apply some
pressure to it from the under side which reduces the resistance of the
spindle to ground, from 400 ohm to 0 ohm. This didn't make the situation
any better though.

Still, the situation over all is much better now than it was last time I
looked at the drive (over two years ago now I think). Previously the
heads would attempt to load and then the fault lamp would come on
immediately. At least now it's trying to lock onto a track. I have the
same results with two cartridges (which is all I have!).

If anyone has any ideas I'd love to hear them!

Aaron

(Sorry, as usual, about the footer appended by my university.)


This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

Re: VAX 4000/300 start up / KA670 issues

[Aaron Jackson via cctalk]

Thanks Dave. It does indeed work. I've managed to boot into a NetBSD
miniroot with the Emulex UC07 and a scsi2sd, although everything is
quite a mess at the moment.

https://www.flickr.com/photos/158497991@N05/50341435063/
https://www.flickr.com/photos/158497991@N05/50342112766/

Very happy to have this machine running :)

Aaron


On 14 September 2020 at 16:33 BST, dave.g4...@gmail.com wrote:

> Aaron,
> I believe a UC07 should work in a 4000. The manual says :-
>
> http://www.bitsavers.org/pdf/emulex/UC0751001H_UC06_UC07_UC08_Host_Adapter_T
> echnical_Manual_Nov90.pdf
>
> CPU Compatibility
> The UC07/UC08 is compatible with the Q-Bus used on all DEC LSI-11 arid all
> DEC MicroVAX II, 3XXX, and 4XXX series computers.
>
> You should really use a -III but I think that the only difference is the
> shielding and cable termination. I would expect the disks to show up as DU2n
>
> http://www.bitsavers.org/pdf/dec/vax/4000/EK-337AA-TI-001_VAX_4000_Model_300
> _Technical_Information_Mar90.pdf
>
> page 1-12.
>
> You might need to tweak the q-Bus addresses.
>
> Dave
>
>> -Original Message-
>> From: Aaron Jackson 
>> Sent: 14 September 2020 15:03
>> To: dave.g4...@gmail.com
>> Cc: 'General Discussion: On-Topic and Off-Topic Posts'
>> 
>> Subject: Re: VAX 4000/300 start up / KA670 issues
>>
>> Hi Dave,
>>
>> In my ignorance I incorrectly assumed the DHQ11 was a SCSI controller
>> because it has compatible centronics sockets. Thinking about the name that
>> was obviously wrong!
>>
>> I have two Emulex UC07, one is spare and the other is in my PDP-11. If I
> install
>> this into the VAX Q22 bus do you think it will explode or work?
>>
>> Even if this did work it wouldn't be ideal but I'm not sure of any
> alternatives at
>> the moment.
>>
>> Thanks,
>> Aaron
>>
>>
>> On 14 September 2020 at 14:07 BST, dave.g4...@gmail.com wrote:
>>
>> > Aaron,
>> >
>> > Which SCSI card do you have? These systems are normally DSSI systems
>> > not SCSI You should be able to do SHOW DEVICE then BOOT 
>> >
>> > Dave
>> >
>> >> -Original Message-
>> >> From: cctalk  On Behalf Of Aaron
>> >> Jackson
>> > via
>> >> cctalk
>> >> Sent: 14 September 2020 13:36
>> >> To: Aaron Jackson ; General Discussion:
>> > On-
>> >> Topic and Off-Topic Posts 
>> >> Subject: Re: VAX 4000/300 start up / KA670 issues
>> >>
>> >> On 14 September 2020 at 00:17 BST, Aaron Jackson via cctalk wrote:
>> >>
>> >> > Hi
>> >> >
>> >> > I've had a VAX 4000/300 sitting around for the past couple of years.
>> >> > The second time I tried to switch it on there was a bit pop from
>> >> > the power supply. The 12v module of the H7874 PSU is completely
>> >> > dead and despite my best efforts I have not been able to fix it.
>> >> >
>> >> > Tonight I decided to remove that module and just use the PSU to
>> >> > provide the 5v, with -12 and 12v supplied from external supplies.
>> >> > Surprisingly this worked, as long as the 12v rails are up before
>> >> > you turn on the
>> >> > H7874 (so if you have a dead H7874 you might want to try this...).
>> >> >
>> >> > After some messing around with MMJ cables and various serial
>> >> > adapters, I finally got some stuff printing to a terminal (I have
>> >> > abbreviated this slightly because I don't want to type it out.
>> >> >
>> >> > ]] KA670-A V3.4, VMB 2.12
>> >> > ]] Performing normal system tests.
>> >> > ]] 66..65.. ... 51..
>> >> > ]] 50..49.. ... 35..
>> >> > ]] 34..33.. ... 19..
>> >> > ]] 18..17.. ... 11..
>> >> > ]]
>> >> > ]] ?5F 2 0F 44   07 ; SUBTEST_5F_0D, DE_SGEC.LIS
>> >> > ]] P1= P2= P3= P4=  P5=
>> ]]
>> >> > P6= P7= P8= P9=080A P10=0003 ]]
>> >> > r0=0054 r1=20084001 r2= r3=  r4= ]]
>> >> > r5=1FFC r6=C001 r7= r8=4000 EPC= ]]
>> 10..
>> >> > ]]
>> >> > ]] ?5C 2 06 FF  0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS
>> >> > ]] P1=0001 P2= P3= P4=  P5=
>> ]]
>> >> > P6= P7= P8=

Re: VAX 4000/300 start up / KA670 issues

[Aaron Jackson via cctalk]

> On 14/09/2020 15:02, Aaron Jackson via cctalk wrote:
>> Hi Dave,
>>
>> In my ignorance I incorrectly assumed the DHQ11 was a SCSI controller
>> because it has compatible centronics sockets. Thinking about the name
>> that was obviously wrong!
>
> For the future:
> http://www.bitsavers.org/pdf/dec/qbus/EK-DHQ11-UG-002.pdf :-)

:)

>
> I've not seen an octopus cable in a long time.
>
>> I have two Emulex UC07, one is spare and the other is in my PDP-11. If I
>> install this into the VAX Q22 bus do you think it will explode or work?
>
>
> The BA440 Qbus is 22 bits, so that should be fine shouldn't it? I've
> never tried that combination, so I don't know for sure, but I think the
> BA440 is QQCD (or whatever the designation is), no serpentine.

I was fairly sure it would be ok so plugged it in and managed to get
into the Emulex configuration menu very quickly. Next step, installing
NetBSD :)))

>
>
>> Even if this did work it wouldn't be ideal but I'm not sure of any
>> alternatives at the moment.
>
>
> KDB50 + RA drive? An RA7x would (almost certainly) fit in one of disk bays.
>
>
> You're supposed to use RF disks. I have an RF35 (or maybe two drives)
> here but I don't know their status. I *think* they're SCSI with an
> adapter board, and if so I could check the disk status at least.

I will look into this. thanks!

Aaron

>
>
> A further alternative would be an HSDx0 + BA350 + StorageWorks disks in
> caddies.
>
>
> Antonio


--
Dr Aaron S. Jackson
Computer Vision Laboratory
School of Computer Science, University of Nottingham

~~
I will be on leave every Monday and Tuesday until October 2020.
~~


This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

Re: VAX 4000/300 start up / KA670 issues

[Aaron Jackson via cctalk]

Hi Dave,

In my ignorance I incorrectly assumed the DHQ11 was a SCSI controller
because it has compatible centronics sockets. Thinking about the name
that was obviously wrong!

I have two Emulex UC07, one is spare and the other is in my PDP-11. If I
install this into the VAX Q22 bus do you think it will explode or work?

Even if this did work it wouldn't be ideal but I'm not sure of any
alternatives at the moment.

Thanks,
Aaron


On 14 September 2020 at 14:07 BST, dave.g4...@gmail.com wrote:

> Aaron,
>
> Which SCSI card do you have? These systems are normally DSSI systems not
> SCSI
> You should be able to do SHOW DEVICE then BOOT 
>
> Dave
>
>> -Original Message-
>> From: cctalk  On Behalf Of Aaron Jackson
> via
>> cctalk
>> Sent: 14 September 2020 13:36
>> To: Aaron Jackson ; General Discussion:
> On-
>> Topic and Off-Topic Posts 
>> Subject: Re: VAX 4000/300 start up / KA670 issues
>>
>> On 14 September 2020 at 00:17 BST, Aaron Jackson via cctalk wrote:
>>
>> > Hi
>> >
>> > I've had a VAX 4000/300 sitting around for the past couple of years.
>> > The second time I tried to switch it on there was a bit pop from the
>> > power supply. The 12v module of the H7874 PSU is completely dead and
>> > despite my best efforts I have not been able to fix it.
>> >
>> > Tonight I decided to remove that module and just use the PSU to
>> > provide the 5v, with -12 and 12v supplied from external supplies.
>> > Surprisingly this worked, as long as the 12v rails are up before you
>> > turn on the
>> > H7874 (so if you have a dead H7874 you might want to try this...).
>> >
>> > After some messing around with MMJ cables and various serial adapters,
>> > I finally got some stuff printing to a terminal (I have abbreviated
>> > this slightly because I don't want to type it out.
>> >
>> > ]] KA670-A V3.4, VMB 2.12
>> > ]] Performing normal system tests.
>> > ]] 66..65.. ... 51..
>> > ]] 50..49.. ... 35..
>> > ]] 34..33.. ... 19..
>> > ]] 18..17.. ... 11..
>> > ]]
>> > ]] ?5F 2 0F 44   07 ; SUBTEST_5F_0D, DE_SGEC.LIS
>> > ]] P1= P2= P3= P4=  P5= ]]
>> > P6= P7= P8= P9=080A P10=0003 ]]
>> > r0=0054 r1=20084001 r2= r3=  r4= ]]
>> > r5=1FFC r6=C001 r7= r8=4000 EPC= ]] 10..
>> > ]]
>> > ]] ?5C 2 06 FF  0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS
>> > ]] P1=0001 P2= P3= P4=  P5= ]]
>> > P6= P7= P8= P9=080A P10=0003 ]]
>> > r0=0054 r1=002E r2=005C r3=20140784  r4=2005FFF8 ]]
>> > r5=20060028 r6=20065224 r7=20004000 r8= EPC= ]]
>> > 09..08..07..05..04..03..
>> > ]] Normal operation not possible.
>> > ]]
>> > ]] >>>
>> >
>> > It allows me to type at this point but does not appear to do anything
>> > with the input.
>> >
>> > I've looked through the KA670 manual and found a listing of the error
>> > codes.
>> >
>> > 5F = SGEC (Second Generation Ethernet Controller) "loopback_type
>> > no_ram_tests"
>> >
>> > 5C = SHAC (Single Host Adapter Chip) "shac_number"
>> >
>> > I'm not sure if it is relevant but I removed the TOY battery when I
>> > got it to prevent it eating everything. I've not taken apart the
>> > console door thing but perhaps it was too late. The SGEC might refer
>> > to the ethernet controller installed on that door?
>> >
>> > If anyone is better at understanding these error messages I'd greatly
>> > appreciate any info you could give.
>> >
>> > Cheers,
>> > Aaron
>> >
>>
>> Never mind. I think these tests can be ignored, and I got rid of the SHAC
> one by
>> putting the terminator in the right place.
>>
>> The VAX does respond to my keyboard input... when I have the terminal set
> to
>> the right serial config.
>>
>> Need to figure out how to get it to boot from SCSI. It's picking up my
> QBUS
>> DHQ11 and DELQA cards fine.
>>
>> I intend to replace the 12v module in the PSU with two small 12v 240v
> boards
>> and tap into the power coming into the PSU. This seems like a reasonable
>> approach given the nature of the H7874 PSU.
>>
>> V

Re: VAX 4000/300 start up / KA670 issues

[Aaron Jackson via cctalk]

On 14 September 2020 at 00:17 BST, Aaron Jackson via cctalk wrote:

> Hi
>
> I've had a VAX 4000/300 sitting around for the past couple of years. The
> second time I tried to switch it on there was a bit pop from the power
> supply. The 12v module of the H7874 PSU is completely dead and despite
> my best efforts I have not been able to fix it.
>
> Tonight I decided to remove that module and just use the PSU to provide
> the 5v, with -12 and 12v supplied from external supplies. Surprisingly
> this worked, as long as the 12v rails are up before you turn on the
> H7874 (so if you have a dead H7874 you might want to try this...).
>
> After some messing around with MMJ cables and various serial adapters, I
> finally got some stuff printing to a terminal (I have abbreviated this
> slightly because I don't want to type it out.
>
> ]] KA670-A V3.4, VMB 2.12
> ]] Performing normal system tests.
> ]] 66..65.. ... 51..
> ]] 50..49.. ... 35..
> ]] 34..33.. ... 19..
> ]] 18..17.. ... 11..
> ]]
> ]] ?5F 2 0F 44   07 ; SUBTEST_5F_0D, DE_SGEC.LIS
> ]] P1= P2= P3= P4=  P5=
> ]] P6= P7= P8= P9=080A P10=0003
> ]] r0=0054 r1=20084001 r2= r3=  r4=
> ]] r5=1FFC r6=C001 r7= r8=4000 EPC=
> ]] 10..
> ]]
> ]] ?5C 2 06 FF  0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS
> ]] P1=0001 P2= P3= P4=  P5=
> ]] P6= P7= P8= P9=080A P10=0003
> ]] r0=0054 r1=002E r2=005C r3=20140784  r4=2005FFF8
> ]] r5=20060028 r6=20065224 r7=20004000 r8= EPC=
> ]] 09..08..07..05..04..03..
> ]] Normal operation not possible.
> ]]
> ]] >>>
>
> It allows me to type at this point but does not appear to do anything
> with the input.
>
> I've looked through the KA670 manual and found a listing of the error
> codes.
>
> 5F = SGEC (Second Generation Ethernet Controller) "loopback_type
> no_ram_tests"
>
> 5C = SHAC (Single Host Adapter Chip) "shac_number"
>
> I'm not sure if it is relevant but I removed the TOY battery when I got
> it to prevent it eating everything. I've not taken apart the console
> door thing but perhaps it was too late. The SGEC might refer to the
> ethernet controller installed on that door?
>
> If anyone is better at understanding these error messages I'd greatly
> appreciate any info you could give.
>
> Cheers,
> Aaron
>

Never mind. I think these tests can be ignored, and I got rid of the
SHAC one by putting the terminator in the right place.

The VAX does respond to my keyboard input... when I have the terminal
set to the right serial config.

Need to figure out how to get it to boot from SCSI. It's picking up my
QBUS DHQ11 and DELQA cards fine.

I intend to replace the 12v module in the PSU with two small 12v 240v
boards and tap into the power coming into the PSU. This seems like a
reasonable approach given the nature of the H7874 PSU.

Very happy the machine seems to be working!

Aaron


This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

VAX 4000/300 start up / KA670 issues

[Aaron Jackson via cctalk]

Hi

I've had a VAX 4000/300 sitting around for the past couple of years. The
second time I tried to switch it on there was a bit pop from the power
supply. The 12v module of the H7874 PSU is completely dead and despite
my best efforts I have not been able to fix it.

Tonight I decided to remove that module and just use the PSU to provide
the 5v, with -12 and 12v supplied from external supplies. Surprisingly
this worked, as long as the 12v rails are up before you turn on the
H7874 (so if you have a dead H7874 you might want to try this...).

After some messing around with MMJ cables and various serial adapters, I
finally got some stuff printing to a terminal (I have abbreviated this
slightly because I don't want to type it out.

]] KA670-A V3.4, VMB 2.12
]] Performing normal system tests.
]] 66..65.. ... 51..
]] 50..49.. ... 35..
]] 34..33.. ... 19..
]] 18..17.. ... 11..
]]
]] ?5F 2 0F 44   07 ; SUBTEST_5F_0D, DE_SGEC.LIS
]] P1= P2= P3= P4=  P5=
]] P6= P7= P8= P9=080A P10=0003
]] r0=0054 r1=20084001 r2= r3=  r4=
]] r5=1FFC r6=C001 r7= r8=4000 EPC=
]] 10..
]]
]] ?5C 2 06 FF  0001 00 ; SUBTEST_5C_06, DE_SHAC.LIS
]] P1=0001 P2= P3= P4=  P5=
]] P6= P7= P8= P9=080A P10=0003
]] r0=0054 r1=002E r2=005C r3=20140784  r4=2005FFF8
]] r5=20060028 r6=20065224 r7=20004000 r8= EPC=
]] 09..08..07..05..04..03..
]] Normal operation not possible.
]]
]] >>>

It allows me to type at this point but does not appear to do anything
with the input.

I've looked through the KA670 manual and found a listing of the error
codes.

5F = SGEC (Second Generation Ethernet Controller) "loopback_type
no_ram_tests"

5C = SHAC (Single Host Adapter Chip) "shac_number"

I'm not sure if it is relevant but I removed the TOY battery when I got
it to prevent it eating everything. I've not taken apart the console
door thing but perhaps it was too late. The SGEC might refer to the
ethernet controller installed on that door?

If anyone is better at understanding these error messages I'd greatly
appreciate any info you could give.

Cheers,
Aaron

P.S. Apologies for the absurd footer appended by my university. You can
probably ignore it... The list does not accept mail from my personal
mail server for some reason.



This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

Re: VAXmate PSU fixed, but no video

[Aaron Jackson via cctalk]

>> 1.   If the EHT lead was not properly connected to the CRT anode, could
>> that cause problems?
>
> Possibly.  I have VT220 terminal which was making a smell of ozone when it was
> running which I should have done something about but never got around to.
> This could have been due to corona discharge around the CRT anode connection
> or around the flyback transformer but I never found out.  Eventually, it
> stopped working, drawing excess current from the 12V power supply.  The
> flyback transformer appears to have been damaged.

I recently decided to take another look at a VT220 I've got which
appears to have a bad FBT. Q202 switching transistor has been replaced
and is outputting a 14.7KHz signal but the flyback also seems to draw
too much current and causes the terminal to hiccup.

It appears to be a problem with the primary winding, which has an
inductance of 5.6uH, although has now increased to 6.4uH after smoking
again (I left it on while hiccuping to check that the transistor was
still switching)... If you have an LCR meter I'd be curious to know what
inductance you measure on the primary winding.

I did eventually notice a small crack in the plastic on the primary
winding side. I'm not sure if it is superficial but I suspect this is
where the smoke escaped.

>> 2.   Is there anything I can safely do with a bench power supply to
>> isolate the problem?
>> 3.   Any other suggestions for diagnosing the problem?
>
> One approach to testing flyback transformers seems to be to use a circuit
> that causes them to ring and observing whether the ringing is damped by
> shorted turns.  I've never got around to trying this myself.

If you want to check the secondary winding, there is a diode which has a
high forward bias voltage. If you pass 20v or so through the secondary
and look at it with a volt meter you should see the voltage drop. It
won't conduct at all if the voltage is too low.

>> 4.   There is an outline spec of the flyback transformer in the section
>> 4.4.3.2 of the VAXmate technical description, what chance of finding a
>> "modern" replacement?
>
> I wish you good luck with this.  I never had any luck locating one for my
> VT220 :-(

There were two VT220 designs (I think), using either an onboard or
offboard flyback. The part number of the onboard flyback is 16-26299-01,
and there are some available on eBay if you are feeling rich.

Cheers,
Aaron

(Sorry about the ridiculous footer that will appear below.)


This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

DEC VR290 Colour Monitor, free to good home (UK)

[Aaron Jackson via cctalk]

I have a DEC VR290 colour monitor for use with VAXstations. It was
working fine when I last powered it on (2-3 years ago), hooked up to a
3100 M76.

It's free to a good home (preferably a home with a VAX), absolutely
collection only. I'm in Nottingham UK. It's too heavy and large to ship
safely.

I have two video cables which are intended for use with it. I think they
are both for VAXstations of some kind, one might be for
DECstation. You've welcome to have them both with the monitor.

Please let me know if you are interested. If in the unlikely event there
is more than one person interested, it'll be mostly whoever picks it up
first but I will prioritise those who actually do have a suitable VAX to
use it with.

Also, if there are any documentation hoarders I have an entire book case
of VAX/VMS manuals (thick red binders). Full list is here, let me know
if you want any. aaronsplace dot co dot uk / dec-manuals.html

Cheers,
Aaron


This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.

Re: VT420 drawings

[Aaron Jackson via cctalk]

Awesome! thanks for sharing this.

Aaron

On 21 October 2019 at 14:37 BST, Mattis Lind via cctalk wrote:

> I got heaps of documentation from an ex-DEC field service engineer.
>
> Among them there were a VT420 print set. I didn't see any schematics for
> the VT420 on bitsavers so even though this one looks a bit strange it is
> better than nothing.
>
> http://storage.datormuseum.se/u/96935524/Datormusuem/DEC/VT420-engineering-drawings.pdf
>
> /Mattis

Re: Too many DEC binders

[Aaron Jackson via cctalk]

> Starting around the VMS 5.5 era, isn’t anything from then or later on
> the Condist documentation CD’s? And thus we don’t have to make a
> priority for scanning?

The stuff I have is mostly pre 4.5.

Aaron

Re: Too many DEC binders

[Aaron Jackson via cctalk]

I have done some test scans tonight. If anyone has any feedback, now
would be a good time to give it, before I spend many more hours
scanning.

http://aaronsplace.co.uk/private/myscans/

Thanks,
Aaron

Aaron Jackson writes:

> Many thanks to Matt Burke and Al Kassow, I have reduced my list of "need
> to scan" to 24 manuals. If anyone has any of these, please let me know
> so I can avoid scanning them.
>
>  AA-Y510B-TEGuide to VAX / VMS System Security
>  AI-Y517A-TEVAX / VMS User's Manual
>  AA-Z501C-TEVAX / VMS System Services Reference Manual
>  AA-H501B-TCDECnet/E Network Programming in BASIC-PLUS and BASIC-PLUS-2
>  AA-H503B-TCDECnet/E Network Programming in COBOL
>  AA-Z501C-TEVAX / VMS Run-Time Library Routines Reference Manual
>  AA-JF88A-TEVAX / VMS Release Notes, Version 4.5
>  AA-M269B-TCDECnet/E Release Notes
>  AA-K714A-TCDECnet/E Network Installation Guide
>  AA-L266A-TCDECnet/E Network Programming in FORTRAN
>  AA-L265A-TCDECnet/E Network Programming in MACRO-11
>  AA-Z601C-TEVAX / VMS I/O User's Reference Manual: Part II
>  AA-M539A-TEVAX / VMS Magnetic Tape User Guide
>  AA-D113C-TEVAX-11 SORT / MERGE User's Guide
>  AA-Z505C-TEPart II Run-Time Library Routines
>  AA-KX22A-TELAT / VMS Management Guide
>  AA-KX21A-TEVAX / VMS Supplemental Information, Version 4.7
>  AD-L034A-28VAX / VMS System Dispatch November 1985
>  AD-LO34A-31VAX / VMS System Dispatch May 1986
>  AD-L034A-27VAX / VMS System Dispatch September 1985
>  AD-L034A-29VAX / VMS System Dispatch January 1986
>  AD-L034A-30VAX / VMS System Dispatch March 1986
>  AD-L034A-26VAX / VMS System Dispatch July 1985
>  AD-L034A-32VAX / VMS System Dispatch July 1986
>
> http://aaronsplace.co.uk/dec-manuals.html This page has been updated to
> reflect what has already digitised.
>
> Thanks,
> Aaron
>
> Aaron Jackson via cctalk writes:
>
>> I have a full book case of DEC binders, each containing one or more
>> manuals. I went through the lot of it this evening and checked to see
>> what was on bitsavers. It seems an awful lot of it is not available. I
>> cannot bring myself to dispose of any of it until it is digitised, but
>> keeping hold of this much paper is not practical for me.
>>
>> I'm going to try to scan as much as I can. The full list of what I have
>> is available at the link below. It is mostly mid 1980's VAX/VMS
>> stuff.. If anyone would like one of the manuals for the cost of
>> shipping, I'd gladly send it over to you.
>>
>> http://aaronsplace.co.uk/dec-manuals.html
>>
>> *** If there is anything you consider a priority in terms of being
>> scanned, please let me know and I'll try to do it sooner, rather than
>> later.  ***
>>
>> Finally, I'd like to mention that these manuals came from a friend,
>> Marc, who passed away early last year. Marc used to be somewhat active
>> on this list (more so the #classiccmp IRC channel). A friend of Marc
>> will be participating in a walk for the Campaign Against Living
>> Miserably (CALM) charity. If anyone is willing to donate (even a small
>> amount), it would mean a lot to me. CALM is a charity supporting men who
>> suffer from depression - one of the leading killers of men under 45 in
>> the UK.
>>
>> https://www.justgiving.com/fundraising/losthourswalk2019inmemoryofmarc
>>
>> Many thanks,
>> Aaron

Re: Too many DEC binders

[Aaron Jackson via cctalk]

Many thanks to Matt Burke and Al Kassow, I have reduced my list of "need
to scan" to 24 manuals. If anyone has any of these, please let me know
so I can avoid scanning them.

 AA-Y510B-TEGuide to VAX / VMS System Security
 AI-Y517A-TEVAX / VMS User's Manual
 AA-Z501C-TEVAX / VMS System Services Reference Manual
 AA-H501B-TCDECnet/E Network Programming in BASIC-PLUS and BASIC-PLUS-2
 AA-H503B-TCDECnet/E Network Programming in COBOL
 AA-Z501C-TEVAX / VMS Run-Time Library Routines Reference Manual
 AA-JF88A-TEVAX / VMS Release Notes, Version 4.5
 AA-M269B-TCDECnet/E Release Notes
 AA-K714A-TCDECnet/E Network Installation Guide
 AA-L266A-TCDECnet/E Network Programming in FORTRAN
 AA-L265A-TCDECnet/E Network Programming in MACRO-11
 AA-Z601C-TEVAX / VMS I/O User's Reference Manual: Part II
 AA-M539A-TEVAX / VMS Magnetic Tape User Guide
 AA-D113C-TEVAX-11 SORT / MERGE User's Guide
 AA-Z505C-TEPart II Run-Time Library Routines
 AA-KX22A-TELAT / VMS Management Guide
 AA-KX21A-TEVAX / VMS Supplemental Information, Version 4.7
 AD-L034A-28VAX / VMS System Dispatch November 1985
 AD-LO34A-31VAX / VMS System Dispatch May 1986
 AD-L034A-27VAX / VMS System Dispatch September 1985
 AD-L034A-29VAX / VMS System Dispatch January 1986
 AD-L034A-30VAX / VMS System Dispatch March 1986
 AD-L034A-26VAX / VMS System Dispatch July 1985
 AD-L034A-32VAX / VMS System Dispatch July 1986

http://aaronsplace.co.uk/dec-manuals.html This page has been updated to
reflect what has already digitised.

Thanks,
Aaron

Aaron Jackson via cctalk writes:

> I have a full book case of DEC binders, each containing one or more
> manuals. I went through the lot of it this evening and checked to see
> what was on bitsavers. It seems an awful lot of it is not available. I
> cannot bring myself to dispose of any of it until it is digitised, but
> keeping hold of this much paper is not practical for me.
>
> I'm going to try to scan as much as I can. The full list of what I have
> is available at the link below. It is mostly mid 1980's VAX/VMS
> stuff.. If anyone would like one of the manuals for the cost of
> shipping, I'd gladly send it over to you.
>
> http://aaronsplace.co.uk/dec-manuals.html
>
> *** If there is anything you consider a priority in terms of being
> scanned, please let me know and I'll try to do it sooner, rather than
> later.  ***
>
> Finally, I'd like to mention that these manuals came from a friend,
> Marc, who passed away early last year. Marc used to be somewhat active
> on this list (more so the #classiccmp IRC channel). A friend of Marc
> will be participating in a walk for the Campaign Against Living
> Miserably (CALM) charity. If anyone is willing to donate (even a small
> amount), it would mean a lot to me. CALM is a charity supporting men who
> suffer from depression - one of the leading killers of men under 45 in
> the UK.
>
> https://www.justgiving.com/fundraising/losthourswalk2019inmemoryofmarc
>
> Many thanks,
> Aaron

Re: Too many DEC binders

[Aaron Jackson via cctalk]

> On 8/24/19 12:18 AM, Aaron Jackson via cctalk wrote:
>> I have a full book case of DEC binders, each containing one or more
>> manuals. I went through the lot of it this evening and checked to see
>> what was on bitsavers. It seems an awful lot of it is not available.
>
> here is a list of the manuals I have scanned but not pdf'ed

Thanks Al, that's 8 which I don't need to worry about then.

By the way, the first item on my list is on bitsavers but the filename
is incorrect. The order number is AA-Y513A-TE but the filename is
vax/vms/4.0/AA-Y512A-TE_VMS_4.0_Guide_To_VAXclusters_Sep84.pdf

Aaron.

Re: Too many DEC binders

[Aaron Jackson via cctalk]

> On 24/08/2019 08:18, Aaron Jackson via cctalk wrote:
>> I'm going to try to scan as much as I can. The full list of what I have
>> is available at the link below. It is mostly mid 1980's VAX/VMS
>> stuff.. If anyone would like one of the manuals for the cost of
>> shipping, I'd gladly send it over to you.
>>
>> http://aaronsplace.co.uk/dec-manuals.html
>>
> I seem to have PDFs for quite a lot of the manuals you have listed. I
> think I got these on a CD from a friend several years ago and I'd always
> assumed they were online somewhere. Maybe they were and have since
> disappeared. I'll get these uploaded once I've sorted out what's needed.
>
> From your list these are the ones which I don't have a PDF for:
>
> AA-D113C-TE VAX-11 SORT / MERGE User's Guide
> AA-H501B-TC DECnet/E Network Programming in BASIC-PLUS and BASIC-PLUS-2
> AA-H503B-TC DECnet/E Network Programming in COBOL
> AA-H504B-TC DECnet/E Guide to User Utilities
> AA-H505B-TC DECnet/E System Manager's Guide
> AA-J055D-TK Introduction to DECnet Phase IV
> AA-JF88A-TE VAX / VMS Release Notes, Version 4.5
> AA-K714A-TC DECnet/E Network Installation Guide
> AA-KX21A-TE VAX / VMS Supplemental Information, Version 4.7
> AA-KX22A-TE LAT / VMS Management Guide
> AA-L265A-TC DECnet/E Network Programming in MACRO-11
> AA-L266A-TC DECnet/E Network Programming in FORTRAN
> AA-M269B-TC DECnet/E Release Notes
> AA-M539A-TE VAX / VMS Magnetic Tape User Guide
> AA-Y510B-TE Guide to VAX / VMS System Security
> AA-Z104C-TE VAX / VMS Master Index
> AA-Z501C-TE VAX / VMS System Services Reference Manual
> AA-Z501C-TE VAX / VMS Run-Time Library Routines Reference Manual
> AA-Z505C-TE Part II Run-Time Library Routines
> AA-Z601C-TE VAX / VMS I/O User's Reference Manual: Part II
> AD-L034A-26 VAX / VMS System Dispatch July 1985
> AD-L034A-27 VAX / VMS System Dispatch September 1985
> AD-L034A-28 VAX / VMS System Dispatch November 1985
> AD-L034A-29 VAX / VMS System Dispatch January 1986
> AD-L034A-30 VAX / VMS System Dispatch March 1986
> AD-L034A-32 VAX / VMS System Dispatch July 1986
> AD-LO34A-31 VAX / VMS System Dispatch May 1986
> AI-T512B-TE Guide to Networking on VAX / VMS
> AI-Y516A-TE VAX / VMS Mini-Reference
> AI-Y517A-TE VAX / VMS User's Manual
>
> I'm not sure about these two though. I have a PDF for AI-Y502B-TE and
> AI-Y508B-TE with the same titles. Is the part number you listed correct?
>
> AI-T502B-TE Guide to Text Processing on VAX / VMS
> AI-T508B-TE Guide to VAX / VMS File Applications
>
>
> Matt

Hi Matt,

This certainly reduces the size of the problem quite a bit. Can we try
and get those online some how? I will check T502B-TE and T508B-TE
tonight. Perhaps they are slightly different versions... Y and T are
very close together though.

Thanks,
Aaron

Too many DEC binders

[Aaron Jackson via cctalk]

I have a full book case of DEC binders, each containing one or more
manuals. I went through the lot of it this evening and checked to see
what was on bitsavers. It seems an awful lot of it is not available. I
cannot bring myself to dispose of any of it until it is digitised, but
keeping hold of this much paper is not practical for me.

I'm going to try to scan as much as I can. The full list of what I have
is available at the link below. It is mostly mid 1980's VAX/VMS
stuff.. If anyone would like one of the manuals for the cost of
shipping, I'd gladly send it over to you.

http://aaronsplace.co.uk/dec-manuals.html

*** If there is anything you consider a priority in terms of being
scanned, please let me know and I'll try to do it sooner, rather than
later.  ***

Finally, I'd like to mention that these manuals came from a friend,
Marc, who passed away early last year. Marc used to be somewhat active
on this list (more so the #classiccmp IRC channel). A friend of Marc
will be participating in a walk for the Campaign Against Living
Miserably (CALM) charity. If anyone is willing to donate (even a small
amount), it would mean a lot to me. CALM is a charity supporting men who
suffer from depression - one of the leading killers of men under 45 in
the UK.

https://www.justgiving.com/fundraising/losthourswalk2019inmemoryofmarc

Many thanks,
Aaron

Re: VCF Southeast Photos

[Aaron Jackson via cctalk]

Very nice photos although I am confused by some. Some of them appear to
be moving but a lot of stuff stays still. What is happening??

This one for example:
https://photos.google.com/share/AF1QipMxQT03fXAj3rZSF8jUm5IrLnmLnVYTTP_hgiNtZ6z-0-pKjaFeKB3aw1ItxldqKA/photo/AF1QipPyuT8UHx84MIB-PxX5L04jePbF6tP80ojp73Iz?key=RjVnUU5qZ19haWNrbkkxMmF2bTFlMndiOFlkRWxB

Aaron

On  1 May 2019 at 21:10 BST, Jason T via cctalk wrote:

> Last weekend I made an unannounced visit out to Roswell, GA to visit
> our brothers-and-sisters-in-hoarding at the Vintage Computer Festival
> Southeast.  They were hosted by the new location of the Computer
> Museum of America, not yet open to the public.  The show was a solid
> representation of the hobby, with a wide range of micros, minis and
> workstations as well as a few calculators and computing ephemera.  On
> the museum side, I've never seen so many Crays in once place - and
> they're not even done yet!
>
> Here is my photo set:  https://photos.app.goo.gl/aiKGadREX511xeUt5
> (contains computers, computer collectors and one giant rabbit)
>
> Big thanks to Earl and the gang for putting on another great VCF and
> showing me that southern hospitality.
>
> More VCF Midwest news coming soon!
>
> -j


-- 
Aaron Jackson, Research Associate
Computer Vision Lab, University of Nottingham
http://aaronsplace.co.uk

Re: What do to with an Internet-connected PDP-11?

[Aaron Jackson via cctalk]

There is a TCP/IP stack available for RT-11, although I've never tried
it. It apparently works with both DEQNA and DELQA cards, and I suspect
you've got one or the other in your 11/23.

http://shop-pdp.net/rthtml/tcpip.php

It is possible, but also very painful, to view websites using the telnet
client "GET / HTTP/1.1" followed by two returns should give you a page.

I think it's more fun to do the opposite. My PDP-11/73 (in a 11/23+
chassis) is accessible via the web, when it's powered up.

http://catbert.rhwyd.co.uk

https://web.archive.org/web/20190420150036/http://catbert.rhwyd.co.uk/

So there's plenty of room to have fun :)

Aaron


Richard Cini via cctalk writes:

> All –
>
>
>
>  Over the last few months, I’ve built myself a nice little PDP-11/23 with a 
> SCSI interface/drive, extra SLUs and Ethernet. With the help of a few people, 
> I was able to get an Ethernet configuration running, which is kind of cool. 
> It’s been a great learning process getting this up and running. It’s a Q18 
> system, so memory is limited and I don’t think able to run BSD (I’m running 
> RT-11 right now).
>
>
>
> So, for playing around, what can I practically do with this? Is it even 
> possible to access any Web sites (unconventional browsing for sure; I’ve read 
> about telnetting to port 80)? I’m sure email is possible, as is FTP/Telnet 
> (I’ve used that inside my lab setup), but I don’t really know where to start 
> with that.
>
>
>
>  If anyone has any pointers/suggestions, I’d appreciate it.
>
>
>
>  Thanks!
>
>
>
> Rich


--
Aaron Jackson - M6PIU
Researcher at University of Nottingham
http://aaronsplace.co.uk/

Re: DELQA?

[Aaron Jackson via cctalk]

On 15 April 2019 at 07:35 BST, Ethan Dicks wrote:
> On Mon, Apr 15, 2019 at 1:16 AM Kevin McQuiggin (SFU) via cctalk
>  wrote:
>> Not in the UK, but Mitch Miller at Keyways Inc (keyways.com) has 
>> tested/working cards at reasonable prices.  I had the same issue on a recent 
>> MicroVAX II upgrade, I replaced a incompatible DEQNA with a DELQA.  I’ve 
>> bought near a dozen cards from him, honest dealer and experienced with DEC 
>> stuff.
>
> He's near me (about 90 minutes West).  I used to run into him at
> computer shows/hamvention in Dayton.  He is definitely experienced and
> trustworthy.  He has some stratospheric prices on some items, but
> those are typically the prices and items for businesses with immediate
> need and someone to stand behind the product.  I haven't purchased
> from him recently (since the Dayton Computer Shows ended) but I've
> heard from others that he can be accommodating to hobbyists where
> possible.
>
> -ethan

Thanks both, yes I have spoken to Mitch a few times in the past and he
does seem like a nice / genuine guy. I will keep Keyways in mind. The
main annoyance for me is paying import tax but perhaps it won't be too
bad.

I think I do have a DELQA card but it is in a VAX 4000/300 and riveted
to a quad width frame.

Aaron

DELQA?

[Aaron Jackson via cctalk]

Unsurprisingly the DEQNA card in my PDP-11/73 is quite unstable and
results in 2.11BSD panicing. Is there anything that can be done about
this? Other than unplugging it that is... I don't think there very much
broadcast traffic making its way to the PDP. It's usually when I'm
transferring files.

If not, does anyone have a DELQA card they would be willing to part with
(preferably in the UK) for a sensible price?

Thanks,
Aaron.

--
Aaron Jackson - M6PIU
Researcher at University of Nottingham
http://aaronsplace.co.uk/

Re: H786 power supply help wanted

[Aaron Jackson via cctalk]

Glad the 23 PSU seems to be working again.

My H7861 had a fault a couple of years ago where the 12V rail stopped
working. It turned out to be a dead 555 timer, totally
flat-lined. Perhaps it would be worth checking that in your H7861 if it
is the MJE15030 that is blowing. At least it's a nice power supply to
work on. :)

Aaron


Charles via cctalk writes:

> Update: I removed the H786 from the chassis, and set it up on the workbench 
> with loads on the +5 and +12.
> No output. 320V across the half-bridge, but no +12 Startup. Found I had 
> forgotten to put a cliplead to the primary of the startup transformer.
> Turned it on and it works... 5 and 12 volts into 1 ohm and 4.7 ohm 
> respectively. WTF.
>
> So I disconnected the PC supply, put the H786 back in, and it fired right up 
> (including the real-time clock) and I ran it for half an hour.
> Go figure. Ain’t classic computers fun sometimes...
>
>
> From: Paul Anderson
> Sent: Saturday, March 30, 2019 3:26 PM
> To: Charles ; General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: H786 power supply help wanted
>
>
> Hi Charles,
>
> The H786 was standard for the 11/23, BA11-N. The H7861 was for the 11/23+, 
> BA11-S and had afrw more amps of +5 volts.
>
> I would start by looking at the electronic caps.
>
> I have a few extras here but am pretty busy for the next week or so.
>
> Paul
>
> On Sat, Mar 30, 2019 at 2:25 PM Charles via cctalk  
> wrote:
>
>   I have a PDP-11/23+ and the power supply (H786) "last ran when parked" a
>   year or so ago. But there's no DC output at all today, and the fans are
>   running so there is AC power...
>   I also have the original H7861 that came with it, which had a blown chopper
>   transistor. I couldn't find anything else bad, so I replaced the transistor
>   and within a few seconds of running, it blew again. :(
>
>   So I need some help - I've never been good at fixing switching supplies, not
>   to mention the high-side hazards.
>   The simplest solution would be just to replace it with a working unit.
>   Anyone got one to sell, hopefully cheap? :)
>   If not, can anyone fix one or both of mine?
>
>   thanks!
>   Charles


--
Aaron Jackson - M6PIU
http://aaronsplace.co.uk/

Re: TU-58 support under Unix

[Aaron Jackson via cctalk]

TU-58 support wouldn't need to be in the kernel, it could easily run in
user space. Perhaps someone had written an application in user-space to
dump TU-58 tapes.

Aaron.


Bill Gunshannon via cctalk writes:

> Here's a question for someone who has been around long enough to
> remember.
>
> Why did none of the available PDP-11 Unixes support the TU-58?
> I have looked at Ultrix-11, V7M and BSD 2.11 (didn't try 2.9
> but I suspect if it isn't in 2.11 it wasn't in 2.9) and none
> of them had support for the TU-58.  Seems to me it would have
> been a rather simple device to handle as it ran over a serial
> line.
>
> bill


--
Aaron Jackson - M6PIU
http://aaronsplace.co.uk/

Re: Ultrix Tape: Block Size?

[Aaron Jackson via cctalk]

If it is anything like installing NetBSD, which I have done on a
VAXstation with a DLT4 drive, it should be 512 byte.

So, while I do not know for sure for Ultrix and MicroVAX, 512 is
probably a good starting point? Hopefully someone else will *actually*
know.

Aaron



Warren Toomey via cctalk writes:

> All, I received this request from Matthew who isn't subscribed to either
> the TUHS or cctalk lists. He knows how to read the lists archives. Many
> thanks for any help you can provide.
> Cheers, Warren
>
> - Forwarded message from Matthew Whitehead -
>
> Date: Mon, 15 Oct 2018 08:25:39 -0400
> From: Matthew Whitehead
> Subject: Ultrix Tape Blocks
>
>Warren,
>  I wonder if you can give me a referral. I want to install Ultrix-32
>on my MicroVAX II using the ancient TK-50 tape drive. I know the tape
>files are on your archive, but I need to know the block size for each
>of the many files; it can vary a lot.
>Who might be able to help me with this?
>Matthew Whitehead
>
> - End forwarded message -


--
Aaron Jackson - M6PIU
http://aaronsplace.co.uk/

Re: GCC for pdp11

[Aaron Jackson via cctalk]

Great news, Paul!

I'll try and give this a go this weekend.

Aaron


Paul Koning via cctalk writes:

> Gentlepeople,
>
> Once in a while people ask about GCC.  It has long had pdp11 support,
> but it hasn't received much attention.  Recently I've done some
> cleanup on it, and some more is in the pipeline.
>
> One notable new feature is that it can now produce proper DEC Macro-11
> syntax output.  It has long had a -mdec-asm switch, but that used to
> produce GNU output.  Now it produces DEC output (and -mgnu-asm is how
> you get output for "gas".)
>
> The optimizer is better, and a bunch of compiler failures are fixed.
> Undoubtedly there are more bugs to be worked on.
>
> Oh yes, for grins I told GCC to build not just a C compiler but a C++
> and Fortran compiler as well.  That seems to work (but I get an error
> building the libstdc++ library).  I now have C++ translations of the
> RSTS standard header files common.mac and kernel.mac, and the DECnet
> definitions in netdef.sml.  :-)
>
> If anyone wants to give this a try, the best way is to get the current
> code via Subversion (see gcc.gnu.org for details).  Alternatively, get
> a weekly snapshot; the DEC support is in the current latest, though
> some optimizer work will appear in the next one.
>
>   paul


--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: VAX 4000 PSU (H7874) Schematics

[Aaron Jackson via cctalk]

Hopefully you have changed the caps before the leak all over your board
:)


Bill Degnan writes:

> I have one or two mostly new 4000 supplies here, plus two working 4000's.
> Did not know until recently this was an issue, I guess I have been lucky.
> b
>
> On Fri, Jun 8, 2018 at 9:04 AM, Holm Tiffe via cctalk > wrote:
>
>> Aaron Jackson via cctalk wrote:
>>
>> > > On Thu, 7 Jun 2018, Aaron Jackson wrote:
>> > >> The VAX turns on and the status LED stays on F. The DC lamp does not
>> > >> illuminate on the PSU. 5V rail appears fine but there is nothing from
>> > >> the 12V rail. There were some *very* dodgy looking caps which I have
>> > >> replaced, and some *very* exploded MOSFETs, which I have also
>> > >> replaced.
>> > >
>> > > If that's all that you replaced, no wonder it still doesn't work ;-)
>> > > Usually shorted power transistors in SMPSUs also break one or more
>> fusable
>> > > resistors, maybe some diodes, maybe the driver IC or transistors.
>> > > So if you have anything that "exploded" in the power supply, be sure
>> there
>> > > is more work to be invested that replacing the obious parts.
>> > >
>> > > Christian
>> >
>> > Haha, okay, seems reasonable. I'll have to probe about a lot more
>> > then. Not giving up quite yet, even though everything I have read about
>> > this power supply has said that it is difficult to repair. So far, I
>> > would agree with such a statement.
>> >
>> > Thanks,
>> > Aaron.
>>
>> Difficult to repair? Probably since it is the worst switching PSU Desing
>> I ever meet, at least from seriveability and the mechanical point of view.
>>
>> I own an 4000/300 with an working again PSU (after some capacitor
>> changes) and I habe an PSU from a friend here..its works sometimes,
>> mostly not.
>>
>> Regards,
>>
>> Holm
>>
>> --
>>   Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,
>>  Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
>> i...@tsht.de Fax +49 3731 74200 Tel +49 3731 74222 Mobil: 0172 8790 741
>>
>>


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: VAX 4000 PSU (H7874) Schematics

[Aaron Jackson via cctalk]

Thanks Bill. I emailed him, some decent advice but mostly prices :)

Aaron


Bill Degnan writes:

> There is a guy named at Joel from global-itcorp.com who has experience with
> these, he may have an idea.  Tell him you spoke with Bill Degnan.
> b
>
> On Thu, Jun 7, 2018 at 3:49 PM, Aaron Jackson via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> I am trying to repair a VAX 4000 power supply. Does anyone have the
>> schematics? I can't find anything on BitSavers and I'm not completely
>> convinced it was even designed by DEC.
>>
>> The VAX turns on and the status LED stays on F. The DC lamp does not
>> illuminate on the PSU. 5V rail appears fine but there is nothing from
>> the 12V rail. There were some *very* dodgy looking caps which I have
>> replaced, and some *very* exploded MOSFETs, which I have also
>> replaced.
>>
>> If anyone has schematics, or know where I might find them, it would be
>> much appreciated.
>>
>> Thanks,
>> Aaron.
>>
>>


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: VAX 4000 PSU (H7874) Schematics

[Aaron Jackson via cctalk]

> On Thu, 7 Jun 2018, Aaron Jackson wrote:
>> The VAX turns on and the status LED stays on F. The DC lamp does not
>> illuminate on the PSU. 5V rail appears fine but there is nothing from
>> the 12V rail. There were some *very* dodgy looking caps which I have
>> replaced, and some *very* exploded MOSFETs, which I have also
>> replaced.
>
> If that's all that you replaced, no wonder it still doesn't work ;-)
> Usually shorted power transistors in SMPSUs also break one or more fusable 
> resistors, maybe some diodes, maybe the driver IC or transistors.
> So if you have anything that "exploded" in the power supply, be sure there 
> is more work to be invested that replacing the obious parts.
>
> Christian

Haha, okay, seems reasonable. I'll have to probe about a lot more
then. Not giving up quite yet, even though everything I have read about
this power supply has said that it is difficult to repair. So far, I
would agree with such a statement.

Thanks,
Aaron.

VAX 4000 PSU (H7874) Schematics

[Aaron Jackson via cctalk]

I am trying to repair a VAX 4000 power supply. Does anyone have the
schematics? I can't find anything on BitSavers and I'm not completely
convinced it was even designed by DEC.

The VAX turns on and the status LED stays on F. The DC lamp does not
illuminate on the PSU. 5V rail appears fine but there is nothing from
the 12V rail. There were some *very* dodgy looking caps which I have
replaced, and some *very* exploded MOSFETs, which I have also
replaced.

If anyone has schematics, or know where I might find them, it would be
much appreciated.

Thanks,
Aaron.

Re: RL Drive Terminators

[Aaron Jackson via cctalk]

> I see some company selling them on eBay for $122. Are they really worth
>
> anything like that? I have a couple sitting around here somewhere that I
>
> don't expect to ever use again. Just wondering if they are worth looking
>
> for to sell. In this hobby you can always use money for new (well, old
> actually)
>
> toys.
>
>
> bill

It's a bit disappointing to see them priced so highly. I don't think
I've seen one even listed in the UK. So if you are trying to sell them I
don't see why $100 or so wouldn't sell, at least eventually. I believe a
company in the UK gave me a price of around £70 ex VAT. I didn't want to
that much so I ended up building my own out of 2x40 perfboard, two pin
1x20 headers and a bunch of 82ohm resistors.

http://aaronsplace.co.uk/private/pics/IMG_1249.JPG

Aaron

Re: RL02 Question

[Aaron Jackson via cctalk]

> > From: Aaron Jackson
>
> > I have tried three controllers, two r/w modules and two servo
> > controllers. I'm beginning to think the drive is fine and there is a
> > problem with the RLV21 controller.
>
> Err, think you mean RLV12 QBUS controller board, right?

Woops, yes! I get mixed up with the RXV21.

> Anyway, you've already tried ("three controllers") swapping that out?

As in the logic controller inside the drive. I only have one RLV12
unfortunately. Although a friend has recently purchased one, so
hopefully I can test with that soon.

> If you have, perhaps there's a problem with a cable and/or the terminator?
>
>
> However, at this point, sub-system swapping is probably not going to be the
> best way to make progress. I think you're going to have to actually debug the
> problem; i.e. dive in and work out what's happening wrong, and why, and trace
> it back to the origin.
>
> Luckily, for this generation (and before), DEC produced wonderful technical
> manuals, which go into full detail of how the thing works. With that in hand,
> the investigative process is a lot easier; you don't have to work out how the
> thihg works by looking at the prints, it's all laid out in detail. And tech
> manuals for both the RL02 drive and RLV12 controller (EK-RLV12-TD-001) are
> available online, as are the prints (MP01282 for the RLV12).
>
> So, I'd sit down with the RLV12 tech man and read through the section on the
> drive<->controller bus (section 3.3). Then start looking at what the two are
> saying to each other on the bus, and figure out what's actually going wrong.
> From there, you'll know where the source of the problem is, and can chase it
> further.
>
> I know this sounds like it would be time-consuming, but when you think about
> the time/energy you've already put into swapping things around, chasing this
> problem, it won't be.
>
>   Noel

I have been studying the technical description manual, and the
schematics in quite some detail. I think it is time I hook up a logic
analyser to the cable between the RLV12 controller and the drive to try
and see what is going on during the initial seek. I have already checked
to see if there is a 4.1MHz clock signal (there is).

Thanks,
Aaron.

Re: RL02 Question

[Aaron Jackson via cctalk]

> On Sat, Mar 31, 2018 at 11:04 AM, Noel Chiappa via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> > From: Aaron Jackson
>>
>> > I have tried three controllers, two r/w modules and two servo
>> > controllers. I'm beginning to think the drive is fine and there is a
>> > problem with the RLV21 controller.
>>
>> Err, think you mean RLV12 QBUS controller board, right?
>>
>> Anyway, you've already tried ("three controllers") swapping that out?
>>
>> If you have, perhaps there's a problem with a cable and/or the terminator?
>>
>>
>> However, at this point, sub-system swapping is probably not going to be the
>> best way to make progress. I think you're going to have to actually debug
>> the
>> problem; i.e. dive in and work out what's happening wrong, and why, and
>> trace
>> it back to the origin.
>>
>> 
>
>
> I remember spending a great deal of time on my RL02 problem until I finally
> figured out the problem source was the backplane.  I have a UNIBUS system
> and I had a miswired DD11C.  I took a DD11B and removed the NPG jumper in
> slot 2 as an experiment.  It caused my RL02 to be functional, exposing the
> DD11C as the issue.
>
> I know that this will not help you directly, but given you have (probably)
> one working RL controller of the three I'd test the QBUS itself, power
> etc.  Perhaps this was already discussed I am just catching up to this
> thread.  I also assume this RL02 has been proven to work somewhere else
> with same cables.  If not I'd try that experiment too.
>
> Bill

Thanks for the tip Bill.

I have run out ideas for debugging on the drive - everything looks fine!
I have starting turning my eyes towards my RLV12 controller. A friend
has recently bought an RLV12, so I can test it with his in the near
future.

Although, studying the technical description manual, I am not seeing
that any communication, other than 4.1MHz clock, is required when
loading the heads. I have been assuming that all of this logic is
handled by the drive only.

Thanks again,
Aaron.

Re: RL02 Question

[Aaron Jackson via cctalk]

>>> It is also possible that a capacitor has deteriorated in the
>>> timeout one-shot
>> 
>> I was beginning to wonder if it was a capacitor
>
> FWIW, while restoring my 11/45 and its RK11-C, I found several failed 74LS123 
> dual one-shots in various places.
>
> Haven’t looked at the RL02 drawings yet, but it seems it was a popular part 
> in DEC designs; if you have one there it might be a more likely fail than the 
> associated small-value timing caps which tend to be fairly robust ceramics?
>
> They are pretty easy to diagnose with a chipclip and a logic analyzer.
>
>   —FritzM.

Hmm, thinking about this a bit more though...

I have tried three controllers, two r/w modules and two servo
controllers. I'm beginning to think the drive is fine and there is a
problem with the RLV21 controller. I measured the frequency of its
pulses and they seemed to be within spec.

Re: RL02 Question

[Aaron Jackson via cctalk]

>>> It is also possible that a capacitor has deteriorated in the
>>> timeout one-shot
>> 
>> I was beginning to wonder if it was a capacitor
>
> FWIW, while restoring my 11/45 and its RK11-C, I found several failed 74LS123 
> dual one-shots in various places.
>
> Haven’t looked at the RL02 drawings yet, but it seems it was a popular part 
> in DEC designs; if you have one there it might be a more likely fail than the 
> associated small-value timing caps which tend to be fairly robust ceramics?
>
> They are pretty easy to diagnose with a chipclip and a logic analyzer.
>
>   —FritzM.

Excellent to know about! Thanks

Re: RL02 Question

[Aaron Jackson via cctalk]

> On 03/30/2018 08:26 AM, Aaron Jackson via cctalk wrote:
>>
>> Is it possible (or even likely) that the carriage survo is a bit sticky?
>> I have a couple of these survos spare, but don't really want to mess
>> with the carriage unless I have to.
>>
>>
> It is also possible that a capacitor has deteriorated in the
> timeout one-shot and is timing out too fast.
>
> Jon

I was beginning to wonder if it was a capacitor. I ended up trying a
different carriage (and servo motor) with no improvement. I'll try to
figure out which cap it is and check it. Thanks!

Aaron

Re: RL02 Question

[Aaron Jackson via cctalk]

I think I have made some progress. I bought a new scope (TDS420A) and
now I can actually measure things. My old scope was far too slow. It
turns out the radial alignment was *very* off, so I have corrected
this. If I disable the seek timeout error, the heads load onto track 0
and the READY lamp is stable. This is as opposed to before, where the
READY lamp would flash while the heads try to remain locked onto
track. So, that's good. However, the drive will not accept commands
while the seek timeout error is disabled. And without SKTO the heads
don't load even make it to the outer guard track.

Since this is a timeout error, I am beginning to wonder if the heads are
failing load fast enough.

Is it possible (or even likely) that the carriage survo is a bit sticky?
I have a couple of these survos spare, but don't really want to mess
with the carriage unless I have to.

If anyone is interested, I have screen caps of some of the alignments
and checks from the manual here:

http://aaronsplace.co.uk/blog/2018-03-29-rl02-possible-problem.html

Thanks,
Aaron.



Aaron Jackson via cctalk writes:

> Sorry to keep bothering you all with RL02 questions. I think I am nearly
> there.
>
> It seems my head cleaning in a warm bath of isopropyl alcohol was a
> success. I bought a tested RL02 pack and loaded it - no bad sounds, I
> can extend the heads all the way. So that's good. I have supposedly a
> working RL02K pack, and seemingly good heads.
>
> After I load a pack however, it goes into fault mode. Checking through
> the test points on my scope, there is no survo burst data until I push
> the heads 3-5mm further forward. So it seems to me that the heads are
> not loading far enough into the pack.
>
> I loosened the head alignment screws to move the heads all the way
> forward, tightened them back up, and tried loading the pack again. It
> stopped again, 3-5mm short of track 0. So moving the heads forward
> didn't seem to make any difference.
>
> I have tried a different control board, and read/write amplifier board,
> with no success.
>
> Has anyone else experienced this? Is there some sensor which I am not
> seeing?
>
> Thanks,
> Aaron.


--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: RL02 Question

[Aaron Jackson via cctalk]

>> So, from what I can see, the drive should spin up correctly, but for
>> some reason it goes into fault mode. I am right in thinking that upon
>> load, the heads should continue moving forward until the first track is
>> found, right? I should not have to perform a seek manually from the PDP?
>> If this is not the case, perhaps there is something else wrong.
> I’m not an RL02 hardware expert at all, just a daily user back in the
> day. I’m reading this assuming that at all times the drive is
> correctly hooked up to an RLV12 in a running PDP with the correct
> cable and termination present on the drive? If it isn’t you’ll get a
> fault condition instead of ready after spin up.
>
> A
 No worries, your input has been valuable, so thank you.

 For anyone else who might have an idea:
>>> ON fault the heads are retracted and will not load till cleared.
>>> Least mine behaves that way.
>>>
>>> Most common problems are wrong drive address, cable issues, no terminator.
>>> Others include head lock not removed or the auto unlock style of
>>> headlock has
>>> the tab broken.
>>>
 It seems to be hooked up correctly. When it is in the weird flashing
 ready state, the boot loader says "Read error" or "Device error"
 randomly. The heads oscillate back and forth very slightly as if it is
 trying to align itself better on the first track, which doesn't exist
 because it hasn't moved far enough into the pack.
>>> IF in fault its resetting to retracted on every try.
>>> If not something else is wrong.
>>>
 I'm beginning to think the heads are bad which will be far too expensive
 so I may end up giving up.
>>> Heads are not that expensive... However you could have a wrong pack
>>> or one that has been erased and has no servo tracks. You must start with
>>> a known good pack and cleaned heads.
>>>
>>>
>>> Allison
>> Well, I replaced the DOWN head and adjusted the amplitude on the r/w
>> board. The drive now stays in READY without the FAULT lamp coming on, so
>> this is promising. The heads load onto the first track.
>>
>> Without any r/w operations, should the READY light flash? Mine is
>> flashing a little but not too rapidly. I am guessing this is while it
>> tries to keep the heads positioned over the track.
> Yes, normal read/write/seek activity causes that.
>
>> When I try to boot using the MXV11-BF boot roms, it says:
>>
> MXV-11 boot is not very chatty or informative.
>
>> ]] ?BOOTROM-F- DL 0 read error
>>
>> The alignment between the two heads looks okay also.
>>
>> Any ideas, anyone?
>
> Is the OS on it? IF RT-11 is it configured to boot from DL-nn?
> IF you have OS on floppy can your do a dir of the devices it knows of?
>

This occurred to me just after I last replied. Silly me. Ended up
booting into 2.11BSD to see if I could run disklabel on it. No such
luck. I'll try RT-11 later this week. If that doesn't work I'll boot
into XXDP over TU58 and give that ago.

Thanks very much for your help, Allison, and others.

Best,
Aaron.

Re: RL02 Question

[Aaron Jackson via cctalk]

 So, from what I can see, the drive should spin up correctly, but for
 some reason it goes into fault mode. I am right in thinking that upon
 load, the heads should continue moving forward until the first track is
 found, right? I should not have to perform a seek manually from the PDP?
 If this is not the case, perhaps there is something else wrong.
>>> I’m not an RL02 hardware expert at all, just a daily user back in the
>>> day. I’m reading this assuming that at all times the drive is
>>> correctly hooked up to an RLV12 in a running PDP with the correct
>>> cable and termination present on the drive? If it isn’t you’ll get a
>>> fault condition instead of ready after spin up.
>>>
>>> A
>> No worries, your input has been valuable, so thank you.
>>
>> For anyone else who might have an idea:
> ON fault the heads are retracted and will not load till cleared.
> Least mine behaves that way.
>
> Most common problems are wrong drive address, cable issues, no terminator.
> Others include head lock not removed or the auto unlock style of
> headlock has
> the tab broken.
>
>> It seems to be hooked up correctly. When it is in the weird flashing
>> ready state, the boot loader says "Read error" or "Device error"
>> randomly. The heads oscillate back and forth very slightly as if it is
>> trying to align itself better on the first track, which doesn't exist
>> because it hasn't moved far enough into the pack.
> IF in fault its resetting to retracted on every try.
> If not something else is wrong.
>
>> I'm beginning to think the heads are bad which will be far too expensive
>> so I may end up giving up.
>
> Heads are not that expensive... However you could have a wrong pack
> or one that has been erased and has no servo tracks. You must start with
> a known good pack and cleaned heads.
>
>
> Allison

Well, I replaced the DOWN head and adjusted the amplitude on the r/w
board. The drive now stays in READY without the FAULT lamp coming on, so
this is promising. The heads load onto the first track.

Without any r/w operations, should the READY light flash? Mine is
flashing a little but not too rapidly. I am guessing this is while it
tries to keep the heads positioned over the track.

When I try to boot using the MXV11-BF boot roms, it says:

]] ?BOOTROM-F- DL 0 read error

The alignment between the two heads looks okay also.

Any ideas, anyone?

Thanks,
Aaron.

Re: RL02 Question

[Aaron Jackson via cctalk]

> On 03/26/2018 04:08 PM, Aaron Jackson via cctalk wrote:
>>>> So, from what I can see, the drive should spin up correctly, but for
>>>> some reason it goes into fault mode. I am right in thinking that upon
>>>> load, the heads should continue moving forward until the first track is
>>>> found, right? I should not have to perform a seek manually from the PDP?
>>>> If this is not the case, perhaps there is something else wrong.
>>> I’m not an RL02 hardware expert at all, just a daily user back in the
>>> day. I’m reading this assuming that at all times the drive is
>>> correctly hooked up to an RLV12 in a running PDP with the correct
>>> cable and termination present on the drive? If it isn’t you’ll get a
>>> fault condition instead of ready after spin up.
>>>
>>> A
>> No worries, your input has been valuable, so thank you.
>>
>> For anyone else who might have an idea:
> ON fault the heads are retracted and will not load till cleared.
> Least mine behaves that way.
>
> Most common problems are wrong drive address, cable issues, no terminator.
> Others include head lock not removed or the auto unlock style of
> headlock has
> the tab broken.
>
>> It seems to be hooked up correctly. When it is in the weird flashing
>> ready state, the boot loader says "Read error" or "Device error"
>> randomly. The heads oscillate back and forth very slightly as if it is
>> trying to align itself better on the first track, which doesn't exist
>> because it hasn't moved far enough into the pack.
> IF in fault its resetting to retracted on every try.
> If not something else is wrong.
>
>> I'm beginning to think the heads are bad which will be far too expensive
>> so I may end up giving up.
>
> Heads are not that expensive... However you could have a wrong pack
> or one that has been erased and has no servo tracks. You must start with
> a known good pack and cleaned heads.
>
>
> Allison

Thanks for the suggestions, Allison.

Given that the pack was tested before it was shipped, I am beginning to
come to the conclusion that the heads are bad. I can see the servo burst
data if I push the heads on a few mm further into pack, but perhaps the
heads produce noise which confuse the logic upon load.

Heads are more expensive than what I'd like, from what I have seen on
eBay.

I believe I have a "working" (i.e. non-crashing) down head (as in the
one on top). If this is head 0 (anyone know?) then I might have a chance
of getting it working without spending anymore money. Let's see.

Thanks again,
Aaron.

Re: RL02 Question

[Aaron Jackson via cctalk]

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

No worries, your input has been valuable, so thank you.

For anyone else who might have an idea:

It seems to be hooked up correctly. When it is in the weird flashing
ready state, the boot loader says "Read error" or "Device error"
randomly. The heads oscillate back and forth very slightly as if it is
trying to align itself better on the first track, which doesn't exist
because it hasn't moved far enough into the pack.

I'm beginning to think the heads are bad which will be far too expensive
so I may end up giving up.

Thanks,
Aaron.

Re: RL02 Question

[Aaron Jackson via cctalk]

I have turned up the amplitude just a little higher than I think it
should be. Instead of going into fault mode after loading a pack, the
READY light flashes about quickly. With the scope hooked up I can see
that it hasn't managed to find the first track yet. Not really sure what
it thinks it is doing...



Aaron Jackson via cctalk writes:

> Hi Andrea,
>
> Thanks for your suggestions.
>
> Checking the amplified output from the r/w heads is one of the first
> things I did. The voltages are within normal range, but only after I
> push the head a bit further into the pack.
>
> Although, I did not set the jumper to try the other head (I suppose I
> was always looking at head 0), so I've just tried this now. There does
> indeed appear to be servo burst data coming from both heads once I've
> manually loaded them fully. So I am not sure if this is the problem. I'm
> really hoping that the pack is not bad since I paid for a tested pack.
>
> I also checked the sector transducer output last night. The individual
> waves (i.e. from trough to peak) seem to be twice as fast, but the
> timings between two peaks is correct.
>
> The survo busts are correctly aligned with the sector pulses.
>
> So, from what I can see, the drive should spin up correctly, but for
> some reason it goes into fault mode. I am right in thinking that upon
> load, the heads should continue moving forward until the first track is
> found, right? I should not have to perform a seek manually from the PDP?
> If this is not the case, perhaps there is something else wrong.
>
> Thanks again for your input,
> Aaron.
>
>
>
> shad via cctalk writes:
>
>> Hello,
>> I'm not an absolute expert, but I successfully fixed a couple of RL02 in
>> the past.
>> Adjustment to the head is only useful for azimuth, I think. The radial
>> position will be adjusted continuously using the servo tracks, so there's
>> no absolute position adjustment at all.
>> If the drive fails during spinup, I would check at least the following:
>> - the presence of spindle sector signal after digital conversion of pulses
>> from analog signal coming from the pickup.
>> - having disabled the servo linear motor (there's some jumper to setup,
>> check the maintenance manual), perform the motor spinup, then load slowly
>> the heads on the disk by hand, until you find the servo tracks.
>> - with an oscilloscope check the presence of analog signal of the servo
>> tracks on both heads, and it's digital counterpart after amplification and
>> threshold detection (expected level values in the manual). If you see
>> something strange, e.g missing or too short pulses, try to adjust the gain
>> with the trimmer on the head board
>> - enable again the servo, then load again
>>
>> My 2 cents.
>> Andrea


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: RL02 Question

[Aaron Jackson via cctalk]

Hi Andrea,

Thanks for your suggestions.

Checking the amplified output from the r/w heads is one of the first
things I did. The voltages are within normal range, but only after I
push the head a bit further into the pack.

Although, I did not set the jumper to try the other head (I suppose I
was always looking at head 0), so I've just tried this now. There does
indeed appear to be servo burst data coming from both heads once I've
manually loaded them fully. So I am not sure if this is the problem. I'm
really hoping that the pack is not bad since I paid for a tested pack.

I also checked the sector transducer output last night. The individual
waves (i.e. from trough to peak) seem to be twice as fast, but the
timings between two peaks is correct.

The survo busts are correctly aligned with the sector pulses.

So, from what I can see, the drive should spin up correctly, but for
some reason it goes into fault mode. I am right in thinking that upon
load, the heads should continue moving forward until the first track is
found, right? I should not have to perform a seek manually from the PDP?
If this is not the case, perhaps there is something else wrong.

Thanks again for your input,
Aaron.



shad via cctalk writes:

> Hello,
> I'm not an absolute expert, but I successfully fixed a couple of RL02 in
> the past.
> Adjustment to the head is only useful for azimuth, I think. The radial
> position will be adjusted continuously using the servo tracks, so there's
> no absolute position adjustment at all.
> If the drive fails during spinup, I would check at least the following:
> - the presence of spindle sector signal after digital conversion of pulses
> from analog signal coming from the pickup.
> - having disabled the servo linear motor (there's some jumper to setup,
> check the maintenance manual), perform the motor spinup, then load slowly
> the heads on the disk by hand, until you find the servo tracks.
> - with an oscilloscope check the presence of analog signal of the servo
> tracks on both heads, and it's digital counterpart after amplification and
> threshold detection (expected level values in the manual). If you see
> something strange, e.g missing or too short pulses, try to adjust the gain
> with the trimmer on the head board
> - enable again the servo, then load again
>
> My 2 cents.
> Andrea


--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

RL02 Question

[Aaron Jackson via cctalk]

Sorry to keep bothering you all with RL02 questions. I think I am nearly
there.

It seems my head cleaning in a warm bath of isopropyl alcohol was a
success. I bought a tested RL02 pack and loaded it - no bad sounds, I
can extend the heads all the way. So that's good. I have supposedly a
working RL02K pack, and seemingly good heads.

After I load a pack however, it goes into fault mode. Checking through
the test points on my scope, there is no survo burst data until I push
the heads 3-5mm further forward. So it seems to me that the heads are
not loading far enough into the pack.

I loosened the head alignment screws to move the heads all the way
forward, tightened them back up, and tried loading the pack again. It
stopped again, 3-5mm short of track 0. So moving the heads forward
didn't seem to make any difference.

I have tried a different control board, and read/write amplifier board,
with no success.

Has anyone else experienced this? Is there some sensor which I am not
seeing?

Thanks,
Aaron.

--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: Seeking RL02K cartridge

[Aaron Jackson via cctalk]

> > I am wondering if anyone would be willing to sell me an RL02K cartridge
> > for a sensible price?
>
> There are a bunch listed on eBait for not wholly unrealistic prices; I
> wouldn't buy a bunch there, but it you only need one, for testing... Not sure
> if any of the ones for sale there are the moment are in the UK, though. (I
> recall some a few months ago, so it's not impossible, and worth a check.)
>
>   Noel

Hi Noel,

I ended up ordering an RL02K-DC today from Lightning Systems in the
UK. I've bought stuff from them before, not overly expensive, but not
overly cheap either. At least I know that it has been tested and works.

I just *really* hope nothing goes wrong when I load it. If it does, I
will give up on RL02 completely. I don't want to be responsible for
crashing another pack, so this will be my last attempt. Given that I am
able to load a clean pack without any bad noises, just not able to read
it because of lost servo data on the first track, I think it might be
okay. I hope...

Thanks,
Aaron.

Re: Seeking RL02K cartridge

[Aaron Jackson via cctalk]

> Hi Aaron,
>   I have some extra RL02 packs and would be glad to lend you a pack for
> free if you like; maybe for keeps.  But you're probably not on the same
> continent as me, so shipping would probably be costly.  If you have no
> better offers, let me know and we'll work it out.  Can also put bits on it
> if it'd be advantageous to have something written on it beforehand.

Thanks for the offer Jake! Hopefully something in the UK turns up but if
not I may be in touch :)

Aaron

Re: Seeking RL02K cartridge

[Aaron Jackson via cctalk]

>>
>> I posted some pictures of the process here:
>>
>> http://aaronsplace.co.uk/blog/2018-02-19-repairing-crashed-RL02-heads.html
>>
> Looking at the pictures of the heads before and after I am struggling to see
> a difference. What am I looking for?
>
> Regards
>
> Rob

If you click on the image and load the full sized image, you should be
able to see some orange stuff from the coating on the platter on the
heads. There isn't a lot, but it was enough to crash when I loaded a
pack it seems.  Cleaning with IPA and swabs, without the heat, wasn't
enough to get it off.

Best,
Aaron

Seeking RL02K cartridge

[Aaron Jackson via cctalk]

Hi all,

Inspired by CuriousMarc's recent video, I cleaned and fixed my RL02
heads. Not with an ultrasonic cleaner unfortunately, but in a warm IPA
bath. It worked! Loading a crashed pack is obviously not a good idea,
although I cleaned the cartridge well, and figured with bad heads and a
bad pack, I might as well try it. The heads no longer crash and appear
clean after loading, but the cartridge, of course, cannot be read as the
first track has been destroyed from the initial crash. I think the crash
was cause by bad heads before I got the RL02 drive.

I posted some pictures of the process here:

http://aaronsplace.co.uk/blog/2018-02-19-repairing-crashed-RL02-heads.html

I am wondering if anyone would be willing to sell me an RL02K cartridge
for a sensible price?

After the cleaning I am guessing my alignment will be slightly off, but
from what I have read in the manual, this is will probably just result
in the read/write speed being reduced as the heads have to move slightly
when switching between either side of the platter. Am I right in
thinking this or completely wrong?

Thanks,
Aaron.

--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: A couple of RL02 questions

[Aaron Jackson via cctalk]

> I've got two RL02 units.  One is a parts unit and has an access plate for
> the door solenoid.  I can open it.  The other has no access plate nor is
> there a cutout for one.  How do I open this cover with the power off?  This
> is a newer unit as it has head lock screws on the bottom of the drive.

Unscrew the panel at the rear top. You can wiggle the cover open when
this is hinged up.

Re: Televideo 970

[Aaron Jackson via cctalk]

> 1) The EMI filter had gone open-circuit - it's one of those metal can types
> which is integrated with the IEC power input connector. Are these still
> obtainable anywhere? It seems like equipment these days just has the
> filtering directly on the PSU board, rather than as a separate module. I've
> just bypassed it for testing, but I don't want to leave it like that.

You can still get these. The hard part is finding one which will fit
properly unless you are willing to bodge it together a bit. Just search
for "C14 EMI" on eBay and you'll find hundreds of them. Maybe you've
seen them already and were just surprised by how small they have become :)

You can also just remove it, and (safely) wire in a fixed power cord.

Aaron.

Re: Passing of a valued member

[Aaron Jackson via cctalk]

Thank you Toby, for posting this, and for putting me in touch with Marc
in the first place.

I first met Marc in person at a talk at our university from Brian
Kernighan. While I nervously asked bwk to sign my copy of C, Marc had no
trouble initiating a conversation wit him. Marc managed to persuade bwk
to sign his 11/70 front panel, which he had brought along with him in
his backpack. "The good old days - Brian Kernighan"

Our friendship developed rapidly, and we have spoken every day until his
passing about a variety of topics - the main one of course being
PDP-11s. Marc helped me source my first PDP, he also picked it up and
delivered it to me. We had many fun times together, trying to fix
things, and unfortunately in some cases making things worse, for which I
blame the beer.

Marc was incredibly intelligent. I looked up to him, despite being a
similar age. It's hard for me to explain how much he meant to me, and
how much I am going to miss him. I know many others are feeling the same
way.

I miss you buddy.

Aaron.


Toby Thain via cctalk writes:

> To the list:
>
> It is with deep personal sadness that I write that young list member
> Marc Grenville-Cleave, of Dorset UK, has passed away. He was known
> personally to several list members.
>
> I did not have the pleasure of meeting him in person but as he was a
> longtime friend I wanted to write a brief celebration of his life and
> interests.
>
> Most relevant to this list, Marc was an avid DEC collector and PDP-11
> enthusiast and rescuer: http://marc.cleave.me.uk//pdp11/index.htm
> He was also the proud owner of a VAX-11/750, among other computers:
> http://marc.cleave.me.uk/collection.htm
>
> He was self-taught in many skills, including electronics, and had
> natural gifts as an engineer. Around the age of 14 he designed an 8-bit
> TTL CPU, which he called "Titan". You can read more here:
> http://marc.cleave.me.uk/cpu/ &
> https://github.com/bootnecklad/Titan-Specifications
> The machine was wire-wrapped and soldered with his trademark meticulous
> care, as you can see from the photos on the first site linked.
>
> Here is a picture of Marc with some of his favourite machines (Titan in
> the background): http://i.imgur.com/CCinlCS.jpeg
>
> Many people knew him on irc, as "bootnecklad" or "bnl", in the
> #classiccmp Freenode channel and elsewhere. His sense of humour was
> unique, sparkling and irreverent.
>
> Aside from his electronics and retrocomputing interests, he restored his
> beloved Range Rover Classic over a long period and finally got it
> roadworthy in 2016. He was a perfectionist in this project as in
> everything else.
>
> Most recently Marc was a Electronic and Computer Engineering student at
> the University of Nottingham.
>
> He will be painfully missed by very many people.
>
> --Toby


--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Seeking VT220 flyback

[Aaron Jackson via cctalk]

I asked a while back, but thought I'd try again. I'm looking for a
replacement flyback transformer for a VT220-F, part number 16-26299-01
by TAI HO. I've found a few online, a bit higher priced than I'd like,
especially after import tax. If you have one you'd be willing to sell,
please get in touch.

Thanks,
Aaron.


--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Searching for manual for ADAC 1664ATTL output pulse board

[Aaron Jackson via cctalk]

Does anyone have a copy of the manual for the ADAC 1664ATTL 64bit
parallel I/O Q-bus card?

Thanks,
Aaron.

Re: RL02 weirdness

[Aaron Jackson via cctalk]

> On 12/17/17 9:04 AM, Aaron Jackson via cctalk wrote:
>> I unloaded very quickly but I think the damage is done.
>>
>
> I KNOW the damage is done.
>
> NEVER attempt to load a pack if you haven't inspected it AND the heads
> first.

The pack was cleaned with lint-free kimwipes and 99.9% isopropyl alcohol
not too long ago.

> Was this combination ever known to work?

The heads had loaded many times (with this pack) without crashing before
I connected the heads to the correct headers on the R/W module
(i.e. up->up and down->down).

> You now need to throw that pack out, and thoroughly inspect and clean the 
> heads
> and any pack to attempt to use in the future.
>
> You also need to inspect the filter, purge the air filtration system if you 
> haven't done that already
> along with cleaning the filtered air path in the drive
> and run the spindle for a while before attempting to load the heads again.

I will check these things, thanks. The absolute filter is basically
brand new by the looks of it.

>> Why would the heads be installed this way? and why did it destroy my
>> platter when they are connected "correctly"?
>
> The only thing that comes to mind is the servo system is going to be extremely
> confused with the embedded servo information coming in the reverse direction.

It seems to me though that the servo information was wrong
before. Please see these:

http://aaronsplace.co.uk/private/pics/rl02/scope.jpg
http://aaronsplace.co.uk/private/pics/rl02/manual.png

This was from TP2 on the R/W module. S2 is wrong, which is why I noticed
that up was connected to down and down to up.

Thanks,
Aaron.

Re: RL02 weirdness

[Aaron Jackson via cctalk]

>> -Original Message-
>> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Aaron
>> Jackson via cctalk
>> Sent: 17 December 2017 17:56
>> To: Aaron Jackson <aa...@aaronsplace.co.uk>; General Discussion: On-Topic
>> and Off-Topic Posts <cctalk@classiccmp.org>
>> Subject: Re: RL02 weirdness
>>
>> >> I wonder if you fell into the 'trap for the unwary' here. The heads
>> >> are named by the direction they face. So the upper head, nearest the
>> >> top of the drive, is the 'down' had as it faces down onto the
>> >> platter. Similarly the lower head is the 'up' head. Yes, it confused
>> >> me at first,
>> >>
>> >
>> > I'm not sure, because the labels on the female connector says up or
>> > down, as does the circuit board. So I connected them so up->up and
>> > down->down, which resulted in this crash. So maybe the person who used
>> > it before me fell into the trap you mention, failed to get it to work,
>> > and then ended up with me in a none-working state?
>>
>> I just checked and it looks like they are in correctly. The head for the
> top-side
>> of the platter is labelled down, and the lower head is facing up. The only
>> thing I changed is connecting up->up and down->down.
>>
>> So, I'm not sure. I cleaned the packs well a while back - I'm just hoping
> there
>> wasn't something left over which caused the crash.
>>
>> Thanks,
>> Aaron.
>
> If these are the ones you got from may I may have put the leads back the
> wrong way round. :-(
> I suspect they have been bounced about so much in my car they may be out of
> alignment.
> I would see about checking the alignment before doing anything else...
>
> Dave


Hi Dave,

They are the ones from you but it's odd how the lower head didn't crash
the way you had it connected :) I will study the manual a bit more...

Thanks,
Aaron.

Re: RL02 weirdness

[Aaron Jackson via cctalk]

>> I wonder if you fell into the 'trap for the unwary' here. The heads are 
>> named by
>> the direction they face. So the upper head, nearest the top of the drive, is
>> the 'down' had as it faces down onto the platter. Similarly the lower
>> head is the
>> 'up' head. Yes, it confused me at first,
>>
>
> I'm not sure, because the labels on the female connector says up or
> down, as does the circuit board. So I connected them so up->up and
> down->down, which resulted in this crash. So maybe the person who used
> it before me fell into the trap you mention, failed to get it to work,
> and then ended up with me in a none-working state?

I just checked and it looks like they are in correctly. The head for the
top-side of the platter is labelled down, and the lower head is facing
up. The only thing I changed is connecting up->up and down->down.

So, I'm not sure. I cleaned the packs well a while back - I'm just
hoping there wasn't something left over which caused the crash.

Thanks,
Aaron.

Re: RL02 weirdness

[Aaron Jackson via cctalk]

> On Sun, Dec 17, 2017 at 5:04 PM, Aaron Jackson via cctalk
> <cctalk@classiccmp.org> wrote:
>> Now that I have my RX02 drive working I have started to take a look at
>> the RL02 drives again. I hooked a scope up to the sector transducer and
>> sector timing test points, and they look nicely aligned. So I moved on.
>>
>> Then I hooked up the scope to the TP1, TP2 and the sector timing TP and
>> compared it to the output in the RL02 tech manual. S1 was fine but S2
>> was offset in the wrong direction (probably need to see page 3-8 in the
>> manual to understand). I had a look at where the heads are connected to
>> at up was connected to down and down was connected to up.
>
> I wonder if you fell into the 'trap for the unwary' here. The heads are named 
> by
> the direction they face. So the upper head, nearest the top of the drive, is
> the 'down' had as it faces down onto the platter. Similarly the lower
> head is the
> 'up' head. Yes, it confused me at first,
>

I'm not sure, because the labels on the female connector says up or
down, as does the circuit board. So I connected them so up->up and
down->down, which resulted in this crash. So maybe the person who used
it before me fell into the trap you mention, failed to get it to work,
and then ended up with me in a none-working state?

>>
>> Without understanding the consequences I switched these and loaded a
>> pack. Unfortunately I heard a horrible sound and I now have a thin black
>> ring on the bottom side of my platter, which I am very upset about. :( I
>> unloaded very quickly but I think the damage is done.
>>
>> Why would the heads be installed this way? and why did it destroy my
>> platter when they are connected "correctly"?
>>
>> Does anyone understand what might have happened?
>>
>> Thanks, and sorry for destroying a pack :(
>
> My first worry is that you have damaged the heads as well as the pack.

Possibly, although I hope not. The head looks okay but perhaps the
damage is invisible.

>
> I am not sure why this caused a headcrash. It shouldn't have done.
>
> -tony

I have a second drive which I am willing to use for parts, but only if I
am certain it won't damage something else.

Thanks,
Aaron.

Re: RL02 weirdness

[Aaron Jackson via cctalk]

>> Does anyone understand what might have happened?
> Simple the heads are designed to fly and have a shape suited for that.
> Flip them over and they are wrong shape, they don't fly, they dig in
> oops!

Yes I understand that, but why didn't it damage my platter when they
were connected (electrically) the to the wrong sockets on the R/W
module? As in, down was plugged into the up header pins and up into the
down header pins.

Thanks,
Aaron.

RL02 weirdness

[Aaron Jackson via cctalk]

Now that I have my RX02 drive working I have started to take a look at
the RL02 drives again. I hooked a scope up to the sector transducer and
sector timing test points, and they look nicely aligned. So I moved on.

Then I hooked up the scope to the TP1, TP2 and the sector timing TP and
compared it to the output in the RL02 tech manual. S1 was fine but S2
was offset in the wrong direction (probably need to see page 3-8 in the
manual to understand). I had a look at where the heads are connected to
at up was connected to down and down was connected to up.

Without understanding the consequences I switched these and loaded a
pack. Unfortunately I heard a horrible sound and I now have a thin black
ring on the bottom side of my platter, which I am very upset about. :( I
unloaded very quickly but I think the damage is done.

Why would the heads be installed this way? and why did it destroy my
platter when they are connected "correctly"?

Does anyone understand what might have happened?

Thanks, and sorry for destroying a pack :(

Aaron.

Re: Vaxstation 4000 m60 and NetBSD

[Aaron Jackson via cctalk]

> 1.) It is not posible to switch the console from RS232 to the VGA
> Monitor and Keyboard. If i switch the S3 switch in down position i can
> only see the NetBSD Kernel decompression. After that i see nothing on
> VGA and RS232 console. The System starts up anyway. After some time it
> is possible to connect via LAN.

Very few frame buffers are supported in NetBSD - you will need to check
the hardware support list. Even if it is supported, you will only be
able to use it as a text-console. To put progress into perspective, I
think support for hardware assisted smooth scrolling has only just been
added.

>
> 2.) Is it posible to run the NetBSD X.Org on that sort of Vaxstation? If
> yes... Whats to do to get that running? I Think i have to fix my point 1
> first.

NetBSD includes the libraries to run X applications, but no Xserver, so
you can only display graphics over the network, nothing locally.

Hope that helps. I haven't played about with it for about a year so I
might have remembered some things wrong. I'm sure someone will correct
me if that's the case :)

Thanks,
Aaron.

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

Thanks for the tips! :)

Aaron.

allison via cctalk writes:

> If you have a system that can create/format SSSD (base RX01 media
> format) RT11 can
> reformat that as RX02. Of the top of my hear the command is INIT and
> you specify the
> drive and /double. It cannot format a blank disk but it can set a RX01
> format to
> double density.
>
> Note a RX02 on a PDP-11 will not boot RT11 if it has the RX01 boot drive
> in place, you must have
> the RX02 driver built into the boot.
>
> Whenever you have a disk fail its advisable to check the heads for crud
> buildup (on RX01, RX02,
> or RX33 and RX23) as sometimes the binder on the media goes to goo and
> coats the head. If
> that happens the next good disk can have the media gouged off. Been
> there done that. I
> always test new media (dir /bad) on drive 2 so if it fails the system
> still boots and likeliness
> of munging the boot media is lower.
>
> I use my S100 CP/M crate for format blanks for RX01 and using R11CPM I
> can copy files
> between the two system (sneakerware).
>
> To read a RX02 formatted disk you must have a RX02 or one of the
> functional equivalents like a DSD
> or Emulex. PCs cannot without a special board.
>
> A slick trick for Qbus 11s is install a RQDX2/3 and put a RX33 or RX23
> drive on that as the formats
> they use are PC readable at the base ODS. I managed to get a few RQDX3s
> just for that in the various
> Qbus 11s I have. Even if you do not have a MFM hard disk for the
> RQDX2/3 is a good choice for floppies
> and it can format media. It also can store more on the media.
>
>
> Allison
>
>
>
> On 12/16/2017 04:21 PM, Jerry Weiss via cctalk wrote:
>>  Glad to hear that you cleared that up.   
>>
>> For the other floppies.
>>
>> 1)  DUMP/TERM/RAD50/END:0 DY1: 
>>  If you share the listing that will give us some hints as to the OS on 
>> the floppies.
>>
>> 2) DIR/BAD DY1:
>> will do a bad block scan to see if can read all of the blocks on the 
>> media.  It
>> does not require an RT11 directory, despite the command name.  It uses
>> the utility DUP.SAV with the K option, not DIR.SAV  You will hear the 
>> floppy
>> reset if it sees a bad spot as it attempts a retry.  The number of 
>> retries
>> is configurable via a SET command.
>>
>> For files with an RT11 Directory, DIR/BAD/FILES will include the file 
>> name
>> of files affected by unreadable blocks.
>>
>> You can do the same with the RL02 Drives.
>>
>> Jerry
>>
>>> On Dec 16, 2017, at 2:28 PM, Aaron Jackson via cctalk 
>>> <cctalk@classiccmp.org> wrote:
>>>
>>> I just checked all of them in RT-11, out of 12 floppies, two of them
>>> were bad, or at least I am unable to perform dir in RT-11.
>>>
>>> My source of confusion comes from both A) not being able to boot from
>>> any of them, and B) not being able to dump them using vtserver. The ones
>>> labelled RT-11 don't actually have RT-11 on them, just some random
>>> files, and these were the ones I had tried to boot from.
>>>
>>> I'm not sure why vtserver doesn't seem to work though. I have Kermit in
>>> RT-11, is there a way to dump the other drive over this? I would like to
>>> put LSI Unix on one of the floppies, can this be done with Kermit too?
>>>
>>> While on the topic of vtserver, it also doesn't seem to like my RL02
>>> drive. If I try to write to it or dump a cartridge, it tells me that it
>>> was unable to read the labelsector. About the thing vtserver has done is
>>> launch itself over odt.
>>>
>>> RT-11 is unable to list the files on the RL02 drive, but maybe they are
>>> UNIX or maybe they are dead packs...
>>>
>>> Thanks,
>>> Aaron.
>>>
>>>
>>> systems_glitch via cctalk writes:
>>>
>>>> We've gotten around the formatting issue by formatting SSSD using ImageDisk
>>>> on a regular PC (with a floppy controller that supports single density/FM,
>>>> of course). If you want RX02 media there's an XXDP routine to upconvert
>>>> RX01s to RX02s.
>>>>
>>>> Thanks,
>>>> Jonathan
>>>>
>>>> On Sat, Dec 16, 2017 at 2:02 PM, Chuck Guzis via cctalk <
>>>> cctalk@classiccmp.org> wrote:
>>>>
>>>>> On 12/16/2017 10:43 AM, Fred Cisin via cctalk wrote:
>>>>>> On Sat, 16 Dec 2017, Aaron Jackson via cctalk wrote:
>>>>>>> Well, would you believe it. It was the disks after all. I can't believe
>>>>>>> they are all bad!
>>>>>> I can believe it.
>>>>>> Were they "bad"?
>>>>>> Or just not what they were labelled as being?
>>>>> I suspect that they weren't formatted to the 3740 spec (26/128 FM).
>>>>> ISTR that the RX02 doesn't have formatting abilities.
>>>>>
>>>>> The other possibility is that the disks were DS rather than SS
>>>>> (different index aperture position).
>>>>>
>>>>> --Chuck
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Aaron Jackson
>>> PhD Student, Computer Vision Laboratory, Uni of Nottingham
>>> http://aaronsplace.co.uk
>>
>>
>>


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

I just checked all of them in RT-11, out of 12 floppies, two of them
were bad, or at least I am unable to perform dir in RT-11.

My source of confusion comes from both A) not being able to boot from
any of them, and B) not being able to dump them using vtserver. The ones
labelled RT-11 don't actually have RT-11 on them, just some random
files, and these were the ones I had tried to boot from.

I'm not sure why vtserver doesn't seem to work though. I have Kermit in
RT-11, is there a way to dump the other drive over this? I would like to
put LSI Unix on one of the floppies, can this be done with Kermit too?

While on the topic of vtserver, it also doesn't seem to like my RL02
drive. If I try to write to it or dump a cartridge, it tells me that it
was unable to read the labelsector. About the thing vtserver has done is
launch itself over odt.

RT-11 is unable to list the files on the RL02 drive, but maybe they are
UNIX or maybe they are dead packs...

Thanks,
Aaron.


systems_glitch via cctalk writes:

> We've gotten around the formatting issue by formatting SSSD using ImageDisk
> on a regular PC (with a floppy controller that supports single density/FM,
> of course). If you want RX02 media there's an XXDP routine to upconvert
> RX01s to RX02s.
>
> Thanks,
> Jonathan
>
> On Sat, Dec 16, 2017 at 2:02 PM, Chuck Guzis via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> On 12/16/2017 10:43 AM, Fred Cisin via cctalk wrote:
>> > On Sat, 16 Dec 2017, Aaron Jackson via cctalk wrote:
>> >> Well, would you believe it. It was the disks after all. I can't believe
>> >> they are all bad!
>> >
>> > I can believe it.
>> > Were they "bad"?
>> > Or just not what they were labelled as being?
>>
>> I suspect that they weren't formatted to the 3740 spec (26/128 FM).
>> ISTR that the RX02 doesn't have formatting abilities.
>>
>> The other possibility is that the disks were DS rather than SS
>> (different index aperture position).
>>
>> --Chuck
>>
>>
>>


--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

> > From: Aaron Jackson
>
> > It was the disks after all.
>
> Well, I'm glad you got it working. Where'd you get a good floppy?
>
>   Noel

Friend popped over with an RX02 drive and a working RT-11 floppy. The
drive worked with my controller so I tried the disk in my own drive and
it booted up straight away.

He suggested it might be likely that all my drives were magnetically
erased before I got them. I think this is quite likely.

There is still one RX02 mystery though... VTserver will not dump the
working disk, despite the system being able to boot from it. It's double
density, so I am a bit surprised.

Thanks,
Aaron.

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

Well, would you believe it. It was the disks after all. I can't believe
they are all bad!

Just booted straight into RT-11.

Thanks all for your help anyway. Time to play.

Aaron.



Aaron Jackson via cctalk writes:

> Hi everyone,
>
> I originally posted this on VCFed (which was new to me) but the
> moderation queue has had me waiting for about 3 days, so I thought I'd
> ask here as well, the usual of gurus. :)
>
> I was recently sent an RXV21 controller so I could test out my RX02
> drive. When I power up the PDP-11 or reset the machine I get the nice
> clunking sound which I have been told is normal. I expect I wouldn't
> hear this if the ribbon cable was in the wrong way.
>
> To test, I tried to use VTserver to dump the contents of a disk, but it
> immediately threw an error. I soon realised there are two DIP switches
> on the logic board of the RX02 drive which had to be adjusted to work
> with the RXV21. So, I had some progress. Output of VTserver almost
> looked promising but then it hangs, as below:
>
> ]] Tape record n from device xx is written as xx(0,0,n)
> ]] Disk drive xx is written as xx(0,0,0)
> ]]
> ]] Enter name of input record/device: rx(0,0,0)
> ]] Enter name of output record/device: vt(0,0,1)
> ]]
> ]] Opened copy.out read-write
> ]]
>
> So, following some advice I booted via TU58em into XXDP and ran the
> diagnostics:
>
> ]] DR>STA
> ]]
> ]] CHANGE HW (L)  ? N
> ]]
> ]] CHANGE SW (L)  ? N
> ]]
> ]] CZRXFB0 SYS FTL ERR  00040 ON UNIT 00 TST 011 SUB 000 PC: 003476
> ]]  CSR BITS - LGC TST
> ]]   AC LOW FATAL ERROR
> ]]   REG ACTUAL=00
> ]]   REG EXPECT=00
> ]]
> ]]   POSSIBLE FAILING "FRU'S":
> ]] INTERFACE - M8029
> ]]
> ]]   UNIT#0 RXCSR=00 RXESR=00 CMD=00 ->
> ]]  ->NO PWR, CABLED BACKWARDS, STRAPPED RX01, PDP-8
> ]]  DROP UNIT#0 FROM TEST
> ]]
> ]] PASS ABRTD THS UNIT
> ]] CZRXFB0 SYS FTL ERR  00040 ON UNIT 01 TST 011 SUB 000 PC: 003476
> ]]  CSR BITS - LGC TST
> ]]   AC LOW FATAL ERROR
> ]]   REG ACTUAL=00
> ]]   REG EXPECT=00
> ]]
> ]]   POSSIBLE FAILING "FRU'S":
> ]] INTERFACE - M8029
> ]]
> ]]   UNIT#1 RXCSR=00 RXESR=00 CMD=00 ->
> ]]  ->NO PWR, CABLED BACKWARDS, STRAPPED RX01, PDP-8
> ]]  DROP UNIT#1 FROM TEST
> ]]
> ]] PASS ABRTD THS UNIT
> ]] CZRXFB0 EOP1
> ]] 2 TOTAL ERRS
>
> So, the possible errors according to XXDP:
>
> - Bad power - I get 25v, 5v and -5v. The motors are spinning, not
>   convinced it is this?
>
> - Cable backwards - I don't think I'd be hearing that clunk.
>
> - Strapped RX01 - I don't know what this means
>
> - PDP8 - eh?
>
> If anyone has any suggestions it would be great to hear them.
>
> Thanks,
> Aaron.


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

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

[Aaron Jackson via cctalk]

> On Dec 8, 2017, at 5:17 PM, Aaron Jackson <aa...@aaronsplace.co.uk> wrote:
>>
>>>> On Dec 8, 2017, at 12:53 PM, Aaron Jackson via cctalk 
>>>> <cctalk@classiccmp.org> wrote:
>>>>
>>>>> On Fri, Dec 8, 2017 at 3:03 PM, Aaron Jackson <aa...@aaronsplace.co.uk> 
>>>>> 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.

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

>> On Dec 8, 2017, at 12:53 PM, Aaron Jackson via cctalk 
>> <cctalk@classiccmp.org> wrote:
>> 
>>> On Fri, Dec 8, 2017 at 3:03 PM, Aaron Jackson <aa...@aaronsplace.co.uk> 
>>> 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.

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

> > From: Aaron Jackson
>
> > Most of the tests now look something like this:
> > ...
> >  SECTOR ADDRESS ERROR
> >   EXPECTED SECTOR=18.
> > TARGET SECTOR=17.
>
> I wonder if there's a problem with the floppy you are using?
>
> Remember, the RX0x drives can't hard reformat the floppies (as in, write the
> sector headers), so if the floopy has a problem, you can't fix it with the
> RX02.
>
>   Noel

Possibly, but I ran the same test on about 4 floppies and failed in the
same way. I bought a box of 13 floppy disks a while ago off eBay, so
unless the box was kept on top of a magnet or something, I'd expect at
least one of them to work.

Some of them have quite interesting names:

  Rutherford Appleton Laboratory Software

and

  Code from Neutron Divider

So I am quite interested to see what's on them.

Thanks,
Aaron.

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

> 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.

Re: RX02 Difficulties

[Aaron Jackson via cctalk]

> On Fri, Dec 8, 2017 at 2:45 PM, Aaron Jackson via cctalk
> <cctalk@classiccmp.org> wrote:
>
>> - Strapped RX01 - I don't know what this means
>>
>> - PDP8 - eh?
>
> No idea as to the fault (heck, it's not in front of me with a logic analyser
> to hand), but I think I can explain that.
>
> There is a pair of DIP switches on the controller board (the upper board
> in the RX02 itself, the one that hinges up). Three of the 4 settings are
> used : RX02 (which is the one you want, it is an RX02 drive to link
> to an RX211 or RXV21 interface), RX01 (turns the drive into a single-
> density-only RX01-a-like to link to an RX11 or RXV11) and 'PDP8' which
> is used to link to an RX8e for Omnibus PDP8 machines. The switch
> settings are in one of the manuals, you should check them.
>
> -tony

I think I have this set correctly, can be seen in this photo, unless I
misunderstand the colouring. Originally it was the other way around and
VTserver would throw an error instead of hang. I can try it again, with
the originally settings, under xxdp and see what happens.

http://aaronsplace.co.uk/private/pics/rx02insides/logic.jpg

Manual says it should be S1=off, S2=on for RX211 and RXV21

RX02 Difficulties

[Aaron Jackson via cctalk]

Hi everyone,

I originally posted this on VCFed (which was new to me) but the
moderation queue has had me waiting for about 3 days, so I thought I'd
ask here as well, the usual of gurus. :)

I was recently sent an RXV21 controller so I could test out my RX02
drive. When I power up the PDP-11 or reset the machine I get the nice
clunking sound which I have been told is normal. I expect I wouldn't
hear this if the ribbon cable was in the wrong way.

To test, I tried to use VTserver to dump the contents of a disk, but it
immediately threw an error. I soon realised there are two DIP switches
on the logic board of the RX02 drive which had to be adjusted to work
with the RXV21. So, I had some progress. Output of VTserver almost
looked promising but then it hangs, as below:

]] Tape record n from device xx is written as xx(0,0,n)
]] Disk drive xx is written as xx(0,0,0)
]]
]] Enter name of input record/device: rx(0,0,0)
]] Enter name of output record/device: vt(0,0,1)
]]
]] Opened copy.out read-write
]]

So, following some advice I booted via TU58em into XXDP and ran the
diagnostics:

]] DR>STA
]]
]] CHANGE HW (L)  ? N
]]
]] CHANGE SW (L)  ? N
]]
]] CZRXFB0 SYS FTL ERR  00040 ON UNIT 00 TST 011 SUB 000 PC: 003476
]]  CSR BITS - LGC TST
]]   AC LOW FATAL ERROR
]]   REG ACTUAL=00
]]   REG EXPECT=00
]]
]]   POSSIBLE FAILING "FRU'S":
]] INTERFACE - M8029
]]
]]   UNIT#0 RXCSR=00 RXESR=00 CMD=00 ->
]]  ->NO PWR, CABLED BACKWARDS, STRAPPED RX01, PDP-8
]]  DROP UNIT#0 FROM TEST
]]
]] PASS ABRTD THS UNIT
]] CZRXFB0 SYS FTL ERR  00040 ON UNIT 01 TST 011 SUB 000 PC: 003476
]]  CSR BITS - LGC TST
]]   AC LOW FATAL ERROR
]]   REG ACTUAL=00
]]   REG EXPECT=00
]]
]]   POSSIBLE FAILING "FRU'S":
]] INTERFACE - M8029
]]
]]   UNIT#1 RXCSR=00 RXESR=00 CMD=00 ->
]]  ->NO PWR, CABLED BACKWARDS, STRAPPED RX01, PDP-8
]]  DROP UNIT#1 FROM TEST
]]
]] PASS ABRTD THS UNIT
]] CZRXFB0 EOP1
]] 2 TOTAL ERRS

So, the possible errors according to XXDP:

- Bad power - I get 25v, 5v and -5v. The motors are spinning, not
  convinced it is this?

- Cable backwards - I don't think I'd be hearing that clunk.

- Strapped RX01 - I don't know what this means

- PDP8 - eh?

If anyone has any suggestions it would be great to hear them.

Thanks,
Aaron.

Re: VAX Q-bus identical to PDP-11 Q-bus?

[Aaron Jackson via cctalk]

Thanks Glen and Jerry.

I think that settled that debate! haha

Thanks,
Aaron.


Glen Slick writes:

> An M5976 KZQSA is not MSCP compatible so it wouldn't do any good with a
> PDP-11 system. It's really only useful for RRD4x SCSI CD-ROM drives with
> VMS on a VAX 4000.
>
> On Dec 6, 2017 9:47 AM, "Aaron Jackson via cctech" 
> wrote:
>
> I'm looking after a VAX 4000 for a friend, which has a SCSI Q-bus card
> (M5976). If the card did not have the large metal face, would it work in
> a Q-bus PDP-11? We are not going to potentially ruin a card by trying
> this, but I am interested to know if this is the case.
>
> Thanks,
>
> Aaron.


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

VAX Q-bus identical to PDP-11 Q-bus?

[Aaron Jackson via cctalk]

I'm looking after a VAX 4000 for a friend, which has a SCSI Q-bus card
(M5976). If the card did not have the large metal face, would it work in
a Q-bus PDP-11? We are not going to potentially ruin a card by trying
this, but I am interested to know if this is the case.

Thanks,

Aaron.

Any difference between VAX Q-bus and PDP-11 Q-bus cards?

[Aaron Jackson via cctalk]

I'm looking after a VAX 4000 for a friend, which has a SCSI Q-bus card
(M5976). If the card did not have the large metal face, would it work in
a Q-bus PDP-11? We are not going to potentially ruin a card by trying
this, but I am interested to know if this is the case.

Thanks,

Aaron.

Re: MXV21 with RX02

[Aaron Jackson via cctalk]

Never mind. The manual is not particularly clear. It is for a Shugart
drive, which can read/write to RX02 floppies, but does not work with an
RX02 drive.

Ah well!

Thanks,
Aaron.


Aaron Jackson writes:

> Hi all,
>
> I was given an MTI MXV21 controller which is apparently compatible with
> the RX02 drive. The card has a 50 pin header, but the RX02 drive has a
> 40 pin ribbon cable. Does anyone know what am I missing here?
>
> I don't see anything about this in the manual:
>
>   
> http://bitsavers.informatik.uni-stuttgart.de/pdf/microTechnology/MXV21_floppyCtlr.pdf
>
> Thanks,
> Aaron.


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

MXV21 with RX02

[Aaron Jackson via cctalk]

Hi all,

I was given an MTI MXV21 controller which is apparently compatible with
the RX02 drive. The card has a 50 pin header, but the RX02 drive has a
40 pin ribbon cable. Does anyone know what am I missing here?

I don't see anything about this in the manual:

http://bitsavers.informatik.uni-stuttgart.de/pdf/microTechnology/MXV21_floppyCtlr.pdf

Thanks,
Aaron.

Re: Sync on Green RGB video

[Aaron Jackson via cctalk]

You might be surprised how many LCD monitors support SoG. I have several
iiyama LCD panels which work fine with a 3100.

Aaron.


Douglas Taylor via cctech writes:

> I have a couple of vaxes that output 'unique' video, Alpha 3000 300,
> Alpha 3000 400, Vax 4000 VLC, and Vax Station 3100 M76.
>
> The Alpha and VLC each have a 3W3 type of connector and the 3100 has a
> 15 pin DEC designed connector.
>
> What does it take to connect these to inexpensive, modern VGA light
> weight monitors?
>
> Doug

Re: RL02 Spinup fails

[Aaron Jackson via cctalk]

>>
> Could elaborate a bit on this part of your earlier message.
>
>> I managed to boot into XXDP today using tu58em and ran the RLV12
>> controller test. It seems though that the version of XXDP I loaded does
>> not support the 22bit address (17774400) and defaults to the 16bit
>> address (174400) so it just shows errors for everything.
>
> VRLBCO expects 16 bit addresses for hardware setup.  Most of the
> XXDP diagnostic programs understand the 16 bit address for IO page
> type devices.
>
> Separately, if this diagnostic itself is not able to use 22 bit memory
> on an 11/73 with 1MB ram, then you may have other issues.  It
> should not be tossing errors.  The fact that XXDP cannot boot
> into extended addressing (XXDPXM) is not a good sign either.

I can try - it's not throwing errors as such but the tests are
failing. For example, here is output for one of the tests.

] ROUTINE TRACE SEQ:
]  034314
]  017252
] INIT STATE TEST
] OPER: GET STAT
] RESULT:CNTLR HUNG
] BUS ADD=174400 DRV=0
]RLCSRLDARLBARLMP CYLHD
] OP INIT = 000104  03  00  0
] OP DONE = 00  00  00  0 000   1
]
] CZRL1 HDR ERR  10002 ON UNIT 00 TST 009 SUB 000 PC: 020074

It's saying the controller has hung, but address 174400 is just RAM so I
don't expect it to get anything interesting back.

Maybe telling a bit about the system will help. Here are the cards in
the order that I have them. There were originally more but I have
removed them as they are not necessary for getting RL02 drives working.

- M8192 CPU (PDP-11/73)
- M7185 Multifunction (boot, serial, 128K RAM)
- M8067-LA (512K RAM)
- M8067-LA (512K RAM)
- M8061 (RLV12 controller)

The M7185 has its own RAM. I'm not sure where this appears on the
system, there may even be some kind of conflict with the proceeding RAM
cards?  There is not much documentation online for this card. I have no
idea how to start the boot loader. A friend dumped the ROMs for me and I
compared them to someone elses dumps and they seemed okay. I've read
about people making a minor modification to this card to disable the
on-board RAM.

The RLV12 has its jumpers in the default configuration, so 22bit
addressing. I can query the controller's registers at
17774400..17774410. The CSR usually has something interesting in which I
can decode and it always makes sense, and matches the current drive
state, for example whether the pack is loaded or not on the least
significant bit.  I'm not sure what is going on with the MPR. I perform
a get status as described in Appendix C3 of the RL02 technical
manual. If I am decoding the contents correctly it says things like the
cover is open and that the drive type is an RL01. For example, at one
point the contents was 167:

 w h w s s w v d d h c h b s s s
 d c l k p g c s t s o o h t t t
 e e   t e e   e   c b a
 0 0 0 0 0 0 0 0 0 1 1 1 0 1 1 1

- ST A,B,C are status bits, being 1,1,1 means "Spin down"
- BH is brushes home, but I don't think this drive has brushes
- HO is heads out
- CO is cover open... the cover is closed unless it's referring to the
 logic cover.
- HS is head select. 1 indicates the lower head
- DT is drive type, 0 indicates RL01, but it is an RL02.
- DSE is drive select error
- VC is volume check
- WGE is write gate error
- SPE is spin error, either too slow or too fast
- SKT is seek time out
- WL is write lock, the status of the write lock button on the front
- HCE is head current error
- WDE write data error

So there seems to be something wrong somewhere but I have no idea where.

Thanks,

Aaron.

Re: RL02 Spinup fails

[Aaron Jackson via cctalk]

> Aaron,
>
> Do not underestimate the need for termination, even with a very short 
> external cable.
> When you factor in the internal cables runs,  crosstalk or signal reflections 
> which interfere
> with operation may still be present, especially when data transfers start.
>
> If you have access to another bootable drive (8inch floppy?), suggest you 
> load the
> XXDP+ diagnostics for RL Drives.
>
> Jerry

Hi Jerry, thanks for the information.

I had built several terminators, but being terrible at geometry I always
did something wrong. I have now fixed one of the terminators I built. I
had pins 1 and 40 mixed up, the rest of the terminator is basically a
mirror copy.

Unfortunately I still have the same error.

I have an RX02 drive but no controller yet, so I'll have to continue
investigating in the dark.

Thanks,
Aaron.

Re: RL02 Spinup fails

[Aaron Jackson via cctalk]

It sounds silly but I don't actually have access to a Windows machine,
but PD11GUI looks nice.

I managed to boot into XXDP today using tu58em and ran the RLV12
controller test. It seems though that the version of XXDP I loaded does
not support the 22bit address (17774400) and defaults to the 16bit
address (174400) so it just shows errors for everything.

VTserver does seem to default to the 22bit address, and I can tell this
because the error for vtserver (as included in my previous email) shows
the output of the CSR (142205). I've also checked this value manually
from ODT and it comes out the same after trying to read.

b 1 1 0 0 0 1 0 0 1 0 0 0 0 1 0 1 = o 142205

>From what I can tell, this decodes to, from right to left:

0 Drive ready, yes
1-3   Command function code (0,1,0 = get status)
4-5   Extended address bits. I don't know what this means.
6 Interrupt enable, no.
7 Controller ready, when this gets cleared it runs the cmd in 1-3.
8-9   Indicates the current drive. I've only one connected, hence 0.
10-13 Error Code (0,0,0,1 = operation incomplete)
14Drive Error, yes unfortunately.
15Composite Error, indicates one or more error bits are set.

The RL02 technical manual says to figure out why a drive error occurred,
I can execute a get status command (?) and then perform an MPR read
(?). So while I don't know how to do that, the error could be one of the
following (apparently)

- spin error. I assume it's not this because the ready light is on?
- seek time out. Maybe this?
- write lock. Only set when the drive is write protected.
- current head error. Set when write current is detected while reading.
- write data error. Set when no transitions are detected during writing.

So, pretty confused.

Thanks,

Aaron.










william degnan via cctech writes:

> I have successfully built a rl02  disk using pdpgui on a windows XP laptop,
> the newer version works on window 10.  All you need other than the software
> is a serial card like a m7800.  Pdpgui acts as a gui.  Do you have a m9312
> rom/terminator card with a terminal console rom?
>
> Bill Degnan
> twitter: billdeg
> vintagecomputer.net
> On Nov 11, 2017 7:04 AM, "Aaron Jackson via cctech" 
> wrote:
>
>> Well, some progress.
>>
>> It seems that a terminator is not required so long as the cable is VERY
>> short. The controller RLV12 controller appears to have a few termination
>> resistors on it anyway. There is no fault light appearing and the drives
>> spin up fine. Mine cable is less than 20cm and the PDP is sitting just
>> on top of the drive.
>>
>> I can see that the drive is communicating because the lsb of the csr
>> changes flips between 0 and 1 when I load and unload the drive.
>>
>> I wanted to try and dump the disks using vtserver, but when I run the
>> copy program I end up with the following
>>
>> ]] Enter name of input record/device: rl(0,0,0)
>> ]]
>> ]] Can't get rl(0,0,0) sts
>> ]] rl(0,0,0) err cy=0, hd=0, sc=2, rlcs=142205, rlmp=0
>> ]] rl(0,0,0) error reading labelsector
>> ]] Enter name of input record/device:
>>
>> The same happened on both packs - they have both been cleaned and look
>> as though they are in good condition. The heads have been cleaned too.
>>
>> Given that the drive appears to be communicating with the PDP-11, where
>> might this problem come from?
>>
>> Thanks,
>>
>> Aaron.
>>
>> Aaron Jackson via cctech writes:
>>
>> > Hi everyone,
>> >
>> > I have managed to hook up an RL02 drive to my PDP-11 (thanks to Dave
>> > Wade for the drives) . This took me longer than I thought it would - I
>> > tried with a flat ribbon cable with a DIY terminator going straight into
>> > board , but couldn't get it to work. Removed the terminator, and the
>> > fault light turned off. So that's positive.
>> >
>> > I tried to load a cartridge, which I had cleaned, inspected and
>> > generally appears to be in good condition. It started to spin up and I
>> > could hear it getting faster, but after 30-40 seconds the fault light
>> > returns. I made a short video demonstrating this:
>> >
>> >  https://www.youtube.com/watch?v=japwBBodO8U
>> >
>> > According to the manual the fault light can appear for the following
>> > reasons:
>> >
>> > - Drive select error... Surely this would come on at the start?
>> > - Seek time out error... I'd have to hear the heads move first
>> > - Write current in heads during sector time error... Same as above
>> > - Loss of system clock... The fault light would be on from the start.
>> > - Write protect error... I don't think it got that far
>> > - Write data error... Same as above
>> > - Spin error... Is this the only remaining fault?
>> >
>> > So could the only cause be a spin error? I am wondering if the belt is
>> > slipping or something like that?
>> >
>> > Can anyone offer some advice?
>> >
>> > Thanks,
>> >
>> > Aaron.
>>
>>
>> --
>> Aaron Jackson
>> PhD Student, Computer Vision Laboratory, Uni of Nottingham
>> http://aaronsplace.co.uk
>>


--

Re: Computing Pioneer Dies

[Aaron Jackson via cctalk]

A few years back I wanted to study at Manchester uni, primarily so I
could apply to be a demonstrator for the SSEM.

Sad news.


Dave Wade via cctalk writes:

> https://www.theguardian.com/global/2017/nov/08/geoff-tootill-obituary
>
>  
>
> Dave Wade
>
> G4UGM & EA7KAE
>
>  


-- 
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: List Problems?

[Aaron Jackson via cctalk]

>> -Original Message-
>> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Tomasz
>> Rola via cctalk
>> Sent: 07 November 2017 18:26
>> To: General Discussion: On-Topic and Off-Topic Posts 
>> Cc: Zane Healy 
>> Subject: Re: List Problems?
>>
>> On Sun, Nov 05, 2017 at 09:46:18AM -0800, Zane Healy via cctalk wrote:
>> > I know around the 20th I wasn’t the only one having problems.  Are
>> > there still issues?
>>
>> I have had some issues during Oct 21st-22nd (Sat + Sun). Emails from US-based
>> mailing lists stopped coming. On top of that, www.classiccmp.org was not
>> responding. On later Sunday afternoon (I was
>> GMT+2, now I am GMT+1) everything looked normal again and mute lists
>> all came back either around this time or (I think) during next day or two.
>>
>> No idea what could have been the cause of this or how widespread it was. I
>> have not spotted anything in the news, and maybe I will have some time to
>> spare on thinking more about this puzzle, or maybe not - given that is solved
>> itself and chances are, very few were affected.
>>
>
>
> This has happened to me too, twice in recent weeks, and not just to me, to a 
> friend here in the UK too. By "this" I mean, no emails from the list and 
> www.classiccmp.org not responding.
>
> Regards
>
> Rob

If better hosting is required and there was a donation button, I'd be
happy to click it. I'm sure many other list members would be too.

Aaron.

Re: RL02 Spinup fails

[Aaron Jackson via cctalk]

william degnan writes:

> On Sun, Nov 5, 2017 at 12:43 PM, Aaron Jackson via cctech <
> cct...@classiccmp.org> wrote:
>
>> Hi everyone,
>>
>> I have managed to hook up an RL02 drive to my PDP-11 (thanks to Dave
>> Wade for the drives) . This took me longer than I thought it would - I
>> tried with a flat ribbon cable with a DIY terminator going straight into
>> board , but couldn't get it to work. Removed the terminator, and the
>> fault light turned off. So that's positive.
>>
>> I tried to load a cartridge, which I had cleaned, inspected and
>> generally appears to be in good condition. It started to spin up and I
>> could hear it getting faster, but after 30-40 seconds the fault light
>> returns. I made a short video demonstrating this:
>>
>>  https://www.youtube.com/watch?v=japwBBodO8U
>>
>> According to the manual the fault light can appear for the following
>> reasons:
>>
>> - Drive select error... Surely this would come on at the start?
>> - Seek time out error... I'd have to hear the heads move first
>> - Write current in heads during sector time error... Same as above
>> - Loss of system clock... The fault light would be on from the start.
>> - Write protect error... I don't think it got that far
>> - Write data error... Same as above
>> - Spin error... Is this the only remaining fault?
>>
>> So could the only cause be a spin error? I am wondering if the belt is
>> slipping or something like that?
>>
>> Can anyone offer some advice?
>>
>> Thanks,
>>
>> Aaron.
>>
>
>
> At that point, for the time it takes the drive to be ready from a load
> should be about 15 seconds.For you the Fault light comes on instead.
> If I turn on my drives but leave the computer (11/40) off, the fault light
> comes on immediately.  If I then turn on the computer the fault light will
> turn off, although I may have to press load first and if so it will turn
> off after a few seconds.It's independent of the LOAD/READY lights
>
> based on this informal comparison I'd venture you have a drive issue.  I am
> not 100% sure what your termination situation is.  I have two drives, one
> terminated but it's with a DEC terminator on the bottom port of drive 1.
> The cable comes from the computer into drive 0.  I have a cable going from
> drive 0 port 1 to drive 1 port 1.
>
> Bill

The only thing I can think of with the terminator is that by using the
bulkhead connectors on the back you would end up with something like
this:


|--- logic board
  pdp11   rl02  |
[]--+
|
  terminator ---|

but I built my terminator directly onto the end of a ribbon cable, and I
realised that it is actually slightly different. More like this:


  pdp11
 +-+
 | |
  logicterminator
  board

I wouldn't thought it would matter but maybe timing is very sensitive. I
can imagine something like this causing an issue with 10base2 networking
for example.

Thanks for the information.

Aaron.

Re: RL02 Spinup fails

[Aaron Jackson via cctalk]

This can probably be ignored. I since realised it's almost definitely an
issue with my terminator. Although, it doesn't matter how many times I
build a terminator, it won't work. I based my terminator off Mark
Blair's RL02 to USB project:

https://github.com/NF6X/RL02-USB/blob/master/pcbs/RL02-USB-terminator/RL02-USB-terminator.pdf

Aaron.

Aaron Jackson via cctalk writes:

> Hi everyone,
>
> I have managed to hook up an RL02 drive to my PDP-11 (thanks to Dave
> Wade for the drives) . This took me longer than I thought it would - I
> tried with a flat ribbon cable with a DIY terminator going straight into
> board , but couldn't get it to work. Removed the terminator, and the
> fault light turned off. So that's positive.
>
> I tried to load a cartridge, which I had cleaned, inspected and
> generally appears to be in good condition. It started to spin up and I
> could hear it getting faster, but after 30-40 seconds the fault light
> returns. I made a short video demonstrating this:
>
>  https://www.youtube.com/watch?v=japwBBodO8U
>
> According to the manual the fault light can appear for the following
> reasons:
>
> - Drive select error... Surely this would come on at the start?
> - Seek time out error... I'd have to hear the heads move first
> - Write current in heads during sector time error... Same as above
> - Loss of system clock... The fault light would be on from the start.
> - Write protect error... I don't think it got that far
> - Write data error... Same as above
> - Spin error... Is this the only remaining fault?
>
> So could the only cause be a spin error? I am wondering if the belt is
> slipping or something like that?
>
> Can anyone offer some advice?
>
> Thanks,
>
> Aaron.


--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

RL02 Spinup fails

[Aaron Jackson via cctalk]

Hi everyone,

I have managed to hook up an RL02 drive to my PDP-11 (thanks to Dave
Wade for the drives) . This took me longer than I thought it would - I
tried with a flat ribbon cable with a DIY terminator going straight into
board , but couldn't get it to work. Removed the terminator, and the
fault light turned off. So that's positive.

I tried to load a cartridge, which I had cleaned, inspected and
generally appears to be in good condition. It started to spin up and I
could hear it getting faster, but after 30-40 seconds the fault light
returns. I made a short video demonstrating this:

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

According to the manual the fault light can appear for the following
reasons:

- Drive select error... Surely this would come on at the start?
- Seek time out error... I'd have to hear the heads move first
- Write current in heads during sector time error... Same as above
- Loss of system clock... The fault light would be on from the start.
- Write protect error... I don't think it got that far
- Write data error... Same as above
- Spin error... Is this the only remaining fault?

So could the only cause be a spin error? I am wondering if the belt is
slipping or something like that?

Can anyone offer some advice?

Thanks,

Aaron.

Re: H7861 PSU issues

[Aaron Jackson via cctalk]

Thanks! It was very satisfying and not the worst thing to go wrong
for a beginner. 

I was also quite surprised that such a simple component would die,
and what I find more confusing is that it died while I was using
the machine.

Aaron.

Noel Chiappa via cctalk  wrote:

> > From: Aaron Jackson
> 
> > Picked up a few 555s and sockets and now it works!
> 
> Congratulations!
> 
> It's odd that a 555 failed, but sometimes there's no rhyme or reason to what
> fails. E.g. I was fixing some broken M7859's (KY11-LB Programmer's Console),
> and on one of them a 7493 (4-bit counter) had died. That's not one of the
> 'problem' 74xx chips, like ISTR the 7474 being?
> 
>   Noel

Re: H7861 PSU issues

[Aaron Jackson via cctalk]

Picked up a few 555s and sockets and now it works! I am very
happy. Going from not knowing how switch mode power supplies work, to
watching some YouTube videos, and then finally being able to debug the
problem and fix it was a lot of fun.

I wonder what will die next.

Thanks,

Aaron.


Rob Jarratt writes:

> I had a dead 555 on a completely different PSU, so it could be worth
> checking. I socketed it when I replaced it so it was easy to replace again.
>
> Also, just because a capacitor doesn't appear swollen or show signs of
> leakage, it seems that this doesn't necessarily mean that it doesn't need
> replacing. In yet another PSU that I repaired recently, replacing the
> capacitors fixed it, although in the end I think the one that really fixed
> it was showing signs of leakage. On a lot of caps that I replace they show
> no leakage signs, but I do see a bit of a deposit on the negative terminal,
> I am not sure if this is a sign of any kind of problem.
>
> Regards
>
> Rob
>
>> -Original Message-
>> From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Aaron
>> Jackson via cctech
>> Sent: 31 October 2017 21:26
>> To: cct...@classiccmp.org
>> Subject: Re: H7861 PSU issues
>>
>> Just had another look after watching a video about how switch mode power
>> supplies work On the small control board connecting to J4, there are
> two
>> D44Q1 transistors. As expected, there is about 65KHz going into the base
> of the
>> transistor for the 5V side. However, there is no signal going into the
> base of the
>> transistor for the 12V side, from pin 3 of the 555. So, it looks like the
> problem is
>> coming from around here. I measured the suspicious components around the
>> 555 and they seem fine.
>>
>> How likely is it that the 555 is dead? There is 10v going into pin 8,
> which I
>> believe is correct.
>>
>> Thanks,
>>
>> Aaron.
>>
>>
>>
>>
>>
>> Aaron Jackson writes:
>>
>> > Hi everyone,
>> >
>> > I've been trying to figure out what is wrong with the 12V rail on my
>> > H7861 (BA11-S) power supply. It's showing about 4.2V. The 5V rail is
>> > spot on.
>> >
>> > Page 39 of the following schematics is the main part board of the PSU.
>> > http://bitsavers.org/pdf/dec/qbus/MP01233_BA11-S_schem_Mar81.pdf
>> >
>> > Going into the collector of Q3 is about 80V coming straight from T2 (I
>> > think I measured it at about 100Hz), but the emitter is putting out
>> > the 4.2V, which is the same as the base voltage and output voltage. I
>> > tried replacing this transistor because the hFE was about 80 and a
>> > good one was about 120. Unfortunately it didn't do anything.
>> >
>> > None of the capacitors look swollen and I don't see any leakage. There
>> > is a smaller board which I think goes into J4. The 12V side seems to
>> > have a 555 timer and adjusting the pot doesn't change the voltage at
>> > all.
>> >
>> > My understanding of switchmode power supplies is very poor. Does
>> > anyone have some pointers on what to check or what might be the possible
>> cause?
>> >
>> > Hopefully I can get my PDP up and running again... Only got about 20
>> > minutes use out of it.
>> >
>> > Thanks!
>> >
>> > Aaron.
>>
>>
>> --
>> Aaron Jackson
>> PhD Student, Computer Vision Laboratory, Uni of Nottingham
>> http://aaronsplace.co.uk


--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

Re: H7861 PSU issues

[Aaron Jackson via cctalk]

That's good to know. I'll head over to Maplin after work and pick up
some timers and sockets.

I removed one of the suspicious ceramic caps and tested it and it came
out fine. The other cap is shared with the other oscillator so I assume
it is fine. 

Thanks!

Aaron.

Rob Jarratt via cctech  wrote:

> I had a dead 555 on a completely different PSU, so it could be worth
> checking. I socketed it when I replaced it so it was easy to replace again.
> 
> Also, just because a capacitor doesn't appear swollen or show signs of
> leakage, it seems that this doesn't necessarily mean that it doesn't need
> replacing. In yet another PSU that I repaired recently, replacing the
> capacitors fixed it, although in the end I think the one that really fixed
> it was showing signs of leakage. On a lot of caps that I replace they show
> no leakage signs, but I do see a bit of a deposit on the negative terminal,
> I am not sure if this is a sign of any kind of problem.
> 
> Regards
> 
> Rob
> 
> > -Original Message-
> > From: cctech [mailto:cctech-boun...@classiccmp.org] On Behalf Of Aaron
> > Jackson via cctech
> > Sent: 31 October 2017 21:26
> > To: cct...@classiccmp.org
> > Subject: Re: H7861 PSU issues
> > 
> > Just had another look after watching a video about how switch mode power
> > supplies work On the small control board connecting to J4, there are
> two
> > D44Q1 transistors. As expected, there is about 65KHz going into the base
> of the
> > transistor for the 5V side. However, there is no signal going into the
> base of the
> > transistor for the 12V side, from pin 3 of the 555. So, it looks like the
> problem is
> > coming from around here. I measured the suspicious components around the
> > 555 and they seem fine.
> > 
> > How likely is it that the 555 is dead? There is 10v going into pin 8,
> which I
> > believe is correct.
> > 
> > Thanks,
> > 
> > Aaron.
> > 
> > 
> > 
> > 
> > 
> > Aaron Jackson writes:
> > 
> > > Hi everyone,
> > >
> > > I've been trying to figure out what is wrong with the 12V rail on my
> > > H7861 (BA11-S) power supply. It's showing about 4.2V. The 5V rail is
> > > spot on.
> > >
> > > Page 39 of the following schematics is the main part board of the PSU.
> > > http://bitsavers.org/pdf/dec/qbus/MP01233_BA11-S_schem_Mar81.pdf
> > >
> > > Going into the collector of Q3 is about 80V coming straight from T2 (I
> > > think I measured it at about 100Hz), but the emitter is putting out
> > > the 4.2V, which is the same as the base voltage and output voltage. I
> > > tried replacing this transistor because the hFE was about 80 and a
> > > good one was about 120. Unfortunately it didn't do anything.
> > >
> > > None of the capacitors look swollen and I don't see any leakage. There
> > > is a smaller board which I think goes into J4. The 12V side seems to
> > > have a 555 timer and adjusting the pot doesn't change the voltage at
> > > all.
> > >
> > > My understanding of switchmode power supplies is very poor. Does
> > > anyone have some pointers on what to check or what might be the possible
> > cause?
> > >
> > > Hopefully I can get my PDP up and running again... Only got about 20
> > > minutes use out of it.
> > >
> > > Thanks!
> > >
> > > Aaron.
> > 
> > 
> > --
> > Aaron Jackson
> > PhD Student, Computer Vision Laboratory, Uni of Nottingham
> > http://aaronsplace.co.uk

Re: H7861 PSU issues

[Aaron Jackson via cctalk]

Just had another look after watching a video about how switch mode power
supplies work On the small control board connecting to J4, there are
two D44Q1 transistors. As expected, there is about 65KHz going into the
base of the transistor for the 5V side. However, there is no signal
going into the base of the transistor for the 12V side, from pin 3 of
the 555. So, it looks like the problem is coming from around here. I
measured the suspicious components around the 555 and they seem fine.

How likely is it that the 555 is dead? There is 10v going into pin 8,
which I believe is correct.

Thanks,

Aaron.





Aaron Jackson writes:

> Hi everyone,
>
> I've been trying to figure out what is wrong with the 12V rail on my
> H7861 (BA11-S) power supply. It's showing about 4.2V. The 5V rail is
> spot on.
>
> Page 39 of the following schematics is the main part board of the PSU.
> http://bitsavers.org/pdf/dec/qbus/MP01233_BA11-S_schem_Mar81.pdf
>
> Going into the collector of Q3 is about 80V coming straight from T2 (I
> think I measured it at about 100Hz), but the emitter is putting out the
> 4.2V, which is the same as the base voltage and output voltage. I tried
> replacing this transistor because the hFE was about 80 and a good one
> was about 120. Unfortunately it didn't do anything.
>
> None of the capacitors look swollen and I don't see any leakage. There
> is a smaller board which I think goes into J4. The 12V side seems to
> have a 555 timer and adjusting the pot doesn't change the voltage at
> all.
>
> My understanding of switchmode power supplies is very poor. Does anyone
> have some pointers on what to check or what might be the possible cause?
>
> Hopefully I can get my PDP up and running again... Only got about 20
> minutes use out of it.
>
> Thanks!
>
> Aaron.


--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk

H7861 PSU issues

[Aaron Jackson via cctalk]

Hi everyone,

I've been trying to figure out what is wrong with the 12V rail on my
H7861 (BA11-S) power supply. It's showing about 4.2V. The 5V rail is
spot on.

Page 39 of the following schematics is the main part board of the PSU.
http://bitsavers.org/pdf/dec/qbus/MP01233_BA11-S_schem_Mar81.pdf

Going into the collector of Q3 is about 80V coming straight from T2 (I
think I measured it at about 100Hz), but the emitter is putting out the
4.2V, which is the same as the base voltage and output voltage. I tried
replacing this transistor because the hFE was about 80 and a good one
was about 120. Unfortunately it didn't do anything.

None of the capacitors look swollen and I don't see any leakage. There
is a smaller board which I think goes into J4. The 12V side seems to
have a 555 timer and adjusting the pot doesn't change the voltage at
all.

My understanding of switchmode power supplies is very poor. Does anyone
have some pointers on what to check or what might be the possible cause?

Hopefully I can get my PDP up and running again... Only got about 20
minutes use out of it.

Thanks!

Aaron.