jws at jwsss.com
Sat Jan 16 18:18:01 CST 2016
On 1/16/2016 12:26 PM, tony duell wrote:
>>> 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.
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.
>> 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
> 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
> 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
>> 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.
More information about the cctalk