16 Jan
2016
16 Jan
'16
12:44 p.m.
I am not sure this fits in with the current topics of this list on the grounds it
involves
real old hardware, but anyway..
I am currently trying to restore a VAX11/730. I got this about 20 years ago and
dismantled it to get it home. For various reasons I never put it back together, I
am doing that -- slowly -- now.
It's the version in the half-height rack with an R80 at the bottom, then the 11/730
CPU box, and a TS05 on top. I know I am going to have problems with the storage
devices, for the moment I am jsut trying to get the CPU running. I've remounted it
in the rack, got all the ribbon cables in place, tested the PSU, etc. Minor PSU problems
(leaky transistor) but now fine.
Powering up gives the expected ROM> prompt on the terminal. Of course all you can
do at that prompt is load the microcode from the TU58, so that is what I am trying to
get working. And getting nowhere!
Firstly the TU58 controller is not passing the self-test. I am pretty sure the 8155
RAM/IO
chip is dead. I have removed this and fitted a DIP socket.
The rollers were of course dead. I have made hubs and fitted an O-ring of a suitable
size. This may not work correctly, but it does seem to move the tape. I have a couple
of tape cartridges, the Console microocode tape, and amazingly the belt seems good
in them. The motor does get the tape whizzing past the heads.
I tried an 8155 borrowed from another device. The controller then passes the self-test
(the LED comes on and stays on) but all I get is DD1: Read Error messages and the tape
often runs off the spool (rethreading it is something I've got quite good at!).
I tried a RS232 analyser between the TU58 and the VAX. Very odd. Either my RS232 anaylser
drops 00 bytes or the TU58 sets short result packets. The meaningful bytes (response code,
etc)
are there, but things like the sequence number are not. Odd...
With the 8155 removed, I can pull port pins (on the socket) high and low to start the
motor, select drive, track, direction, etc.
I've done that and put a LogicDart on the output of the comparator in the read
amplifier.
According to the manual, the tape is recorded at 800bpi and runs at 30ips. So I get that
a bit should take around 41us. And a bit starts with a rising edge, the position of the
falling
edge (recorded at 1/4 or 3/4 of the bit time) determines whether it's a 0 or 1.
Well, sometimes that's what I see on the LogicDart. Sometimes I see a 1:1 square wave
with
a period of 40-odd us.
Does anyone have any sensible ideas as to what to try next. At the moment I have no idea
if
it's the tape, heads, roller or what....
-tony
16 Jan
16 Jan
2:22 p.m.
On 1/16/16 12:44 PM, tony duell wrote:
Does anyone have any sensible ideas as to what to try
next. At the moment I have no idea if
it's the tape, heads, roller or what....
This might not be what you want, but I boot my 11/730 from a tu58
emulator running on a linux box. I used a little ttl<->rs232 converter
board. It works well and is reliable.
If nothing more, it will let you load the microcode so you can check out
the cpu.
That R80, however. mmm. Those are cranky. And noisy. At first I put a
UDA50 in to boot off more modern disks. But that took 2 slots so I
switched to a unibus scsi card. That allowed me to get a slot back for
memory.
The fun thing about emulated tu58 is that it was easy to make a new boot
tape with PUTR and put a unix loader which knows how to boot over
ethernet. These days I tend to boot new kernels over ethernet with that.
just a thought.
ps: tu58 controller boards are easy to find. I have at least 4-5 of
them. The rollers are the issue, when they turn to goo.
-brad
3:15 p.m.
Does anyone
have any sensible ideas as to what to try next. At the moment I have no idea if
it's the tape, heads, roller or what....
This might not be what you want, but I boot my 11/730 from a tu58
emulator running on a linux box. I used a little ttl<->rs232 converter
board. It works well and is reliable. If nothing more, it will let you load the microcode so
you can check out
the cpu.
True, but it is one more thing I have to set up and debug.
That R80, however. mmm. Those are cranky. And noisy.
At first I put a
Mine might be worse than most....
I took it apart 20 years ago (no not the HDA) to (a) get it out of the rack -- it's
heavy and (b) to repair some damage to the casing. Never did the latter, I didn't
really have the tools at the time. And you guessed it, I can't find all the bits now.
Fortunately I have the main bits -- the casing, the HDA, the PSU, the spindle motor,
the 4 main PCBs, etc. What I am missing are all the nuts and bolts (and being UNC
they are not easy to get over here), some of the internal cables (trivial to make IDC
ribbon cables), the motor belt (ouch!, it's different on 50Hz models) and the hardest
to make, the brackets for the gas struts. I have the gas struts but not the brackets,
clevis pins, etc to fix them to the bottom case and logic chassis. Making those will
be 'fun'. They may still turn up of course...
UDA50 in to boot off more modern disks. But that took
2 slots so I
I do not want a Unibus expansion cabinet, I want to put everything in the CPU box.
Which means I really want to keep that R80 on the Integrated Disk Controller (I do
not want to try running from RL02s!). This, alas, means I am not going to have
ethernet since AFAIK you can't run the cable through that odd cable tray thing on
the 11/730. And a UDA50 is out!
In any case, what would I link a UDA50 to? RA8x's are going to be as bad as the R80
(very similar design). RA90s, well, I met those in 'real use' in the 1990's.
No thanks!
[...]
ps: tu58 controller boards are easy to find. I have
at least 4-5 of
them. The rollers are the issue, when they turn to goo.
The controller is also not hard to fix. I have the printset, there is nothing I don't
understand about it.
Yes, my rollers have turned to goo. I've tried suitably-sized O-rings on home-made
metal hubs. The tape seems to move at the right speed, given the data rate is right
some of the time (and when it isn't, I don't think it's the roller slipping)
-tony
3:39 p.m.
On Jan 16, 2016, at 12:15, tony duell <ard at p850ug1.demon.co.uk> wrote:
I had considered that, or one of the TU58 emulators
that use SD cards or
similar but (a) I am trying to restore this VAX, not make a machine that runs
VAX software and is not original and (b) I do have this moral objection to
using more components to load the microcode than in the rest of the machine.
I am in that same camp. I am presently using TU58 emulation to make progress on the rest
of the system, but I do plan to try to get my original drive and tapes working in the
future. Even if I immediately unplug it and plug an emulator back in, because I thoroughly
distrust the tape cartridge design and I am not confident that any of my tapes are any
good. I would like to make an SD card based emulator that clicks into place in one of the
tape slots and the plugs into the console I place if the original drive, so it can be as
unobtrusive and standalone as possible.
AFAIK the TU58 interface (at least on the 11/730) can run at RS232 levels, you
don't need a level shifter board.
Correct. Regular RS232 levels. There is at least one really short timeout in the console
code that can cause trouble with some emulators running on some platforms, but I managed
to hack around that in tu58em running on a Mac. I put together hardware to use a RasPi
instead so the 730 doesn't need to be tethered to a laptop, but I haven't gotten
that working yet.
This, alas, means I am not going to have
ethernet since AFAIK you can't run the cable through that odd cable tray thing on
the 11/730.
I have Ethernet in my 730, though I don't have it working yet. My experience is that
trying to route the round AUI cable through the bottom tray with the ribbon cables is
doomed to failure, but the cable can instead be routed over the top of the cards, through
openings in the power supply area, then along the folding gantry along with the power
cables. I haven't gotten networking up and running on my VAX yet, and I don't yet
know what combination of hardware, software and operator ignorance is causing it to not
work. I'm still pretty happy that I can boot VMS from either the R80 or RL02.
3:51 p.m.
I had considered that, or one of the TU58
emulators that use SD cards or
similar but (a) I am trying to restore this VAX, not make a machine that runs
VAX software and is not original and (b) I do have this moral objection to
using more components to load the microcode than in the rest of the machine.
I am in that same camp. I am presently using TU58 emulation to make progress on the
rest of the system, but I do plan to try to get my original drive and tapes working in
the
future. Even if I immediately unplug it and plug an emulator back in, because I
thoroughly
distrust the tape cartridge design and I am not confident that any of my tapes are any
good. I would like to make an SD card based emulator that clicks into place in one of
the tape slots and the plugs into the console I place
if the original drive, so it can be as
unobtrusive and standalone as possible.
Even so it's not how the machine was designed to boot.... I really do want to get it
back
as DEC intended if at all possible. Even if I have to make a formatter for blank tape
cartridges or something.
[...]
I put together hardware to use a RasPi instead so the
730 doesn't need to be tethered
to a laptop, but I haven't gotten that working yet.
'Haven't gotten that working yet' :-). That's how I feel about doing
something like this
(quite apart from the 'moral' aspects) I am having to do battle with things that
may or
may not work, may or may not be well documented (at least the TU58 is well documented)
and am likely to spend a lot of time getting nowhere.
I have Ethernet in my 730, though I don't have it
working yet. My experience is that trying to
route the round AUI cable through the bottom tray with the ribbon cables is doomed to
failure,
but the cable can instead be routed over the top of the cards, through openings in the
power
supply area, then along the folding gantry along with the power cables. I haven't
gotten
networking up and running on my VAX yet, and I don't yet know what combination of
hardware,
software and operator ignorance is causing it to not work. I'm still pretty happy
that I can
boot VMS from either the R80 or RL02.
That's not a bad idea.... I do have a DELUA somewhere I think. Might be worth trying
it in place
of 1M of RAM. But let's get the CPU working first....
I have the RL brought out to the connector panel, but no drives hooked up to that. I have
a
TS05 magtape to go on top of the rack. It needs a rebuild too. The door is smashed and
mostly missing, the rubber (?) pads that lock the supply spool are dead, etc. Spent the
morning
making a reasonable substitute for the Cipher reel hight setting tool.
-tony
2:59 p.m.
Some comments inline. Mostly is maybe obvious...
2016-01-16 18:44 GMT+01:00 tony duell <ard at p850ug1.demon.co.uk>:
Powering up gives the expected ROM> prompt on the terminal. Of course all
you can
do at that prompt is load the microcode from the TU58, so that is what I
am trying to
get working. And getting nowhere!
And you don't want to use a TU58 emulator? (Or you enjoy waiting for the
TU58 loading the microcode :-)
I tried an 8155 borrowed from another device. The controller then passes
the self-test
(the LED comes on and stays on) but all I get is DD1: Read Error messages
and the tape
often runs off the spool (rethreading it is something I've got quite good
at!).
If it run the tape off spool the system seems to be unable to detect
EOT/BOT markers on the tape.
and since the TU58 is only relying on the read signal for this there has to
be some problem with how the tape is read.
I tried a RS232 analyser between the TU58 and the VAX.
Very odd. Either my
RS232 anaylser
drops 00 bytes or the TU58 sets short result packets. The meaningful bytes
(response code, etc)
are there, but things like the sequence number are not. Odd...
Indeed, very odd. Since it now passes the self test I assume that the
firmware is OK so it has to be something else. How can it miss sending
bytes? Could there some problems with the interrupts? The RST 5.5 and RST
6.5 signals from the UART to the CPU. Or is there a subtle problem with the
CPU itself in this respect. A logic analyzer on the bus and the interrupt
signals would probably tell some. The 8085 code in the ROM would be easy to
disassemble. If this isn't already done. I think I remember seeing a
disassembly somewhere?
I've done that and put a LogicDart on the output
of the comparator in the
read amplifier.
According to the manual, the tape is recorded at 800bpi and runs at 30ips.
So I get that
a bit should take around 41us. And a bit starts with a rising edge, the
position of the falling
edge (recorded at 1/4 or 3/4 of the bit time) determines whether it's a 0
or 1.
Well, sometimes that's what I see on the LogicDart. Sometimes I see a 1:1
square wave with
a period of 40-odd us.
Does anyone have any sensible ideas as to what to try next. At the moment
I have no idea if
it's the tape, heads, roller or what....
The indication of the strange read signal probably explain why it runs off
the spool. Does both TU58 drives behave the same? If they do it would of
course point towards the TU58 controller. A scope probe on the previous
amplifier stages show what kind of signal? It is not some kind of fault
with the tape write circuitry? So that this is somehow enabled due to a
logic fault?
Does the "Tacho" signal show the correct speed?
You don't happen to have another TU58 controller to try with just to verify
things. I have quite many of those actually.
So no real answers since I always cheated when it comes to TU58: I use an
emulator...
/Mattis
-tony
3:26 p.m.
Powering up gives the expected ROM> prompt on the terminal. Of course all
you can
do at that prompt is load the microcode from the TU58, so that is what I
am trying to
get working. And getting nowhere!
And you don't want to use a TU58 emulator? (Or you enjoy waiting for the
TU58 loading the microcode :-) If it run the tape off spool the system seems to be
unable to detect
EOT/BOT markers on the tape.
Sure.
and since the TU58 is only relying on the read signal
for this there has to
be some problem with how the tape is read.
Agreed.
I tried a
RS232 analyser between the TU58 and the VAX. Very odd. Either my
RS232 anaylser
drops 00 bytes or the TU58 sets short result packets. The meaningful bytes
(response code, etc)
are there, but things like the sequence number are not. Odd...
Indeed, very odd. Since it now passes the self test I assume that the
firmware is OK so it has to be something else. How can it miss sending bytes? Could there some problems with the interrupts?
The RST 5.5 and RST
6.5 signals from the UART to the CPU. Or is there a subtle problem with the
CPU itself in this respect. A logic analyzer on the bus and the interrupt
signals would probably tell some. The 8085 code in the ROM would be easy to
That I might well try. But at the moment I want to find out why the read signal
looks so odd.... It's always possble my seral comms tester doesn't do what I
expect and that the TU58 has no problems here.
disassemble. If this isn't already done. I think I
remember seeing a
disassembly somewhere?
Yes, I have it. I think it's on bitsavers.
[...]
The indication of the strange read signal probably
explain why it runs off
the spool. Does both TU58 drives behave the same? If they do it would of
Yes.
And yes both drives do exactly the same thing. Of course if it is a roller problem
then they would in that I have replaced both roller with indentical ones that I made.
course point towards the TU58 controller. A scope
probe on the previous
amplifier stages show what kind of signal? It is not some kind of fault
with the tape write circuitry? So that this is somehow enabled due to a
logic fault?
No, I checked the write circuitry is all disabled before I put a tape in. The write
protect switch disables the write circuitry in hardware, I have made sure this works
too (and the cartridges are, of course, write protected).
Does the "Tacho" signal show the correct
speed?
Yes. Or at least the tacho loop is locking, the tacho signal looks nice on the
LogicDart and it doubles in speed when I flip the appropriate signal. Given the
data rate is sometimes correct and the Tacho signal doens't change I think it's
working.
You don't happen to have another TU58 controller
to try with just to verify
things. I have quite many of those actually.
I guess I could try the one from the 11/44 drives.
-tony
4:47 p.m.
Of course all you can do at that prompt is load the
microcode from
the TU58, so that is what I am trying to get working. And getting
nowhere!
And you don't want to use a TU58 emulator?
4:52 p.m.
I can certainly understand that. But a TU58 emulator could be a useful
diagnostic tool. Personally, I would try to get it working from the
Agreed. But a diagnostic tool is only useful if you can trust it. I suspect that if
I tried to set up a TU58 emulator I would have problems due to my lack of
programming knowledge and thus would be wondering if my problems were
due to the emulator or the VAX CPU..
Similarly, it could be a useful diagnostic tool to
connect the real
TU58 hardware to a known-working (presumably slightly more modern)
machine to see if it's willing to work that way.
Yes. Does such a program exist? Something that will let me send commands
to the TU58 and see what it sends back? Again I could write one, but then
again I want to be sure that when it doesn't work it's a real problem with the
TU58
I've read and re-read the TU58 ROM source listings and AFAIK there is no way
it could send the result packets my serial comms analyser thinks it is sending. No
logical fault could cause it to drop the bytes it seems not to be sending. My guess is
that said analyser is not doing what I expect! See what I mean about diagnostic tools
that are unreliable...
-tony
8:41 p.m.
tony duell wrote:
Similarly, it
could be a useful diagnostic tool to connect the real
TU58 hardware to a known-working (presumably slightly more modern)
machine to see if it's willing to work that way.
Yes. Does such a program exist? Something that will let me send commands
to the TU58 and see what it sends back? Again I could write one, but then
again I want to be sure that when it doesn't work it's a real problem with the
TU58
9:05 a.m.
tony duell wrote:
While the TU-58
tape will not have an RT-11 file
structure, you can at least read each raw block
and display the contents:
Actually I believe the VAX11/730 console tape is an
RT11 file system (for all there is no PDP11 involved).
9:19 a.m.
On a VAX, there is an application (named EXCHANGE if I remember
correctly) which reads and writes the first partition of any RT-11 disk
Err, yes... This implies I have a working VAX. Until I repair ths TU58 and get
it to load the CPU microcode, I don't.
Sure...
If you have a PDP-11 system with a serial DL port,
don't forget that
it must also be set at the same speed as the TU-58 tape drive. While
it seems unlikely that you have not made sure with the VAX and the
TU-58 tape that they both have the same baud rate, check just in case.
Now I am confused.... I suspect it's 'near enough' but not spot on. The
TU58 is running at 38400 baud, which I understand is correct for the
VAX11/730 internal drive. In any case it's the unit that was inside my VAX
CPU when I got it and there is no reason to assume the controller board
was swapped out, The rate is set by wire-wrapped links on the TU58
controller board and those are right. I've also checked the frequency at
the clock pins of the UART chip.
But while the printset for the 11/730 CPU claims a 38400 baud rate clock
(acutally 16 times that at the input to the serial chip, of course), I can't for
the life of me work out how the 10MHz CPU clock oscillator is divided down
to give this. I get it running at around 39kbps. I guess as it's async it will
work, but....
I do not think this is the problem. I am sure the VAX console processor and
the TU58 are communicating.
-tony
16 Jan
16 Jan
7:18 p.m.
On 1/16/2016 12:26 PM, tony duell wrote:
No, I don't want to use a TU58 emulator for the
same reason that I am restoring this
VAX and not running a VAX emulator. I want to keep the old hardware running. The
original machine loaded its microcode off tape so that's what I want it to do.
the emulator will let you verify your serial link. If you don't use the
emulator for anything else that is one time you should use it.
Moral objections have nothing to do with getting as many tools on a
problem as you can.
I believe
so. The ROM reads out identcally to the one in the standalone TU58
(alas with bad rollers so I can't use that to check against) for my 11/44. It would
be a very odd coincidence if both ROMs had failed in the same way.
Powering up gives the expected ROM> prompt on the
terminal. Of course all
you can
do at that prompt is load the microcode from the TU58, so that is what I
am trying to
get working. And getting nowhere!
And you don't want to use a TU58 emulator? (Or you enjoy waiting for the
TU58 loading the microcode :-) If it run the tape off spool the system seems to
be unable to detect
EOT/BOT markers on the tape.
Sure.
and since the TU58 is only relying on the read
signal for this there has to
be some problem with how the tape is read.
Agreed.
I tried a
RS232 analyser between the TU58 and the VAX. Very odd. Either my
RS232 anaylser
drops 00 bytes or the TU58 sets short result packets. The meaningful bytes
(response code, etc)
are there, but things like the sequence number are not. Odd...
Indeed, very odd. Since it now passes the self test I assume that the
firmware is OK so it has to be something else. How can it miss sending bytes? Could there some problems with the
interrupts? The RST 5.5 and RST
6.5 signals from the UART to the CPU. Or is there a subtle problem with the
CPU itself in this respect. A logic analyzer on the bus and the interrupt
signals would probably tell some. The 8085 code in the ROM would be easy to
That I
might well try. But at the moment I want to find out why the read signal
looks so odd.... It's always possble my seral comms tester doesn't do what I
expect and that the TU58 has no problems here.
disassemble. If this isn't already done. I
think I remember seeing a
disassembly somewhere?
Yes, I have it. I think it's on bitsavers.
[...]
The indication of the strange read signal
probably explain why it runs off
the spool. Does both TU58 drives behave the same? If they do it would of
Yes.
And yes both drives do exactly the same thing. Of course if it is a roller problem
then they would in that I have replaced both roller with indentical ones that I made.
course point towards the TU58 controller. A scope
probe on the previous
amplifier stages show what kind of signal? It is not some kind of fault
with the tape write circuitry? So that this is somehow enabled due to a
logic fault?
No, I checked the write circuitry is all disabled before I put a tape
in. The write
protect switch disables the write circuitry in hardware, I have made sure this works
too (and the cartridges are, of course, write protected).
Does the "Tacho" signal show the
correct speed?
Yes. Or at least the tacho loop is locking, the tacho signal looks
nice on the
LogicDart and it doubles in speed when I flip the appropriate signal. Given the
data rate is sometimes correct and the Tacho signal doens't change I think it's
working.
You don't happen to have another TU58
controller to try with just to verify
things. I have quite many of those actually.
I guess I could try the one from the
11/44 drives.
-tony
17 Jan
17 Jan
2:09 a.m.
Moral objections have nothing to do with getting as
many tools on a
problem as you can.
True. But if you don't have said tools set up and working, you may find
(or at least I will find) that when somethng doesn't work you are not sure
if the problem is a genuine fault or misuse/misunderstanding of the tool.
If I had a TU58 emulator set up and working then I would try it, As it is, I
could set one up (but on what, my linux box and VAX are in totally separate
rooms) find it doesn't work and get nowhere.
-tony
16 Jan
16 Jan
3:27 p.m.
On 01/16/2016 11:44 AM, tony duell wrote:
So I get that
a bit should take around 41us. And a bit starts with a rising edge, the position of the
falling
edge (recorded at 1/4 or 3/4 of the bit time) determines whether it's a 0 or 1.
No, not correct for 800 BPI (NRZI). That is somewhat how
1600/3200 PE tape works.
Well, sometimes that's what I see on the LogicDart. Sometimes I see a 1:1 square wave
with
a period of 40-odd us.
800 BPI (NRZI) only has transitions on a data track when
there is a 1 recorded. There will always be at least one 1
recorded in any byte, as the odd parity track will have a 1
for an all-zero data byte. So, a track that has all 1's in
consecutive bytes will have your ~40us square wave. When
the head is porperly aligned for skew, there will be a skew
test point that should have an approximate square wave.
When the skew is bad, this will have a wave with stepped
sides, showing where individual bits came in with a time skew.
If a track has a run of zeroes, then that data track will
have no transitions in it for that interval.
At the end of the data block, there will be a 2
character-time gap, then the CRC and LRCC will be recorded.
The CRC is computed with a shift register with XOR gates,
the LRCC is produced by just clearing the NRZI register. it
is a longitudinal parity of all the 1's in that data track.
If a track has an odd number of 1's in it (including the
CRC) then there will be a transition in that bit of the LRCC.
Jon
3:31 p.m.
800 BPI (NRZI) only has transitions on a data track
when
As I understand it the TU58 is not NRZI.
According to the manual (and I see this sometimes) a 'bit cell'
starts with a +ve magnetic flux transition (OK, that is meaningless,
it really means there is a +ve edge at the output of the read
comparator at the start of every bit cell).
There is a -ve edge somewhere in the bit cell. If it is before
the halfway time it's one state of bit (I forget which), if it's
after then it's the other. They are recorded at the 1/4 and
3/4 times respectively to allow for some errors.
So an exact half way transition is meaningless.
When I say I see it 'sometimes' I can't know exactly which bit of the
tape I am reading each time I sample the signals. So it's very possible
the read circuits are behaving consistently and the tape is the problem.
-tony
3090
days inactive
3091
days old
17 comments
8 participants
participants (8)
-
ard＠p850ug1.demon.co.uk -
brad＠heeltoe.com -
elson＠pico-systems.com -
jhfinedp3k＠compsys.to -
jws＠jwsss.com -
mattislind＠gmail.com -
mouse＠Rodents-Montreal.ORG -
nf6x＠nf6x.net