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