Thanks for your response Chuck,
As described in the topic, just after the Power On, the machine runs a
self-test which is called "POC TEST" on the UTS range of Sperry Univac.
During this test, the machine checks the status of the RAM, the ROMs,
the Counter Timer, and the various communication interfaces.
Everything is OK except the ninth line which says: "SERIAL I / O CHANNEL
B: FAILED"
(ignore the FAILED next to "OPTIONAL RAM BANK 0,1", the machine can
start without this board)
http://www.zeltrax.com/classiccmp_forum/uts40_screen03.jpg
This channel B error completely freezes the machine, it does not load
the default settings, I no longer have access to the setup page, in this
situation the keyboard remains without effects.
When the POC test is successful, it loads the default settings in non
volatile RAM:
http://www.zeltrax.com/classiccmp_forum/uts40_screen01.jpg
And I can access the setup page:
http://www.zeltrax.com/classiccmp_forum/uts40_screen02.jpg
The few times I was able to go into the setup page (CHANNEL B: PASSED),
I rushed to try to encode (with the dead keyboard) the data to declare
the subsystem and finally return to the CP/M mode. And I had twice the
case where without warning hop! Blank screen, automatic reset, self-test
(POC) -> SERIAL I / O CHANNEL B: FAILED (again).
Maybe we have there some interesting information about the problem, the
intermittent nature of this failure, could this give information about
the type of component in fault?
But note that since weeks now the problem has become permanent, I have
never been able to return to this famous setup page and the "serial I/O
channel B" is now always marked as 'FAILED'.
So I have no way to try anything using the terminal at this point.
It is possible that the breakdown is in fact very simple (dry solder dry
or attacked solder by the acid of the battery), but I would like to
avoiding to rework all the solders, and maybe to finally find that the
problem was at the level of an IC, I would try to locate the components
linked to this problem. I look at the SIO, try to discover what is after
just after, see how I can eventually act on the pin 30 (W/RDYB) of that IC :
http://www.sbprojects.net/projects/izabella/assets/images/sio1.jpg
And try to understand why this SIO no longer considers the channel B as
'READY'
This kind of things ...
There are probably programmable loop-back circuitry used by the POC test
program (in the ROM of the program cartridge).To ignore the negative
diagnostic I would like to induce to the self-test program that the
channel B is OK, what should I inject to the SIO (perhaps on this pin
30) to force a positive diagnosis?
It would be interesting, just to see if in that way I can take control
again on the machine, and check that the rest is working.
And yes, the SIO is working (as the CPU, the counter timer and the DMA
controller) because I replaced these IC by another ones with the same
faulty result.
http://www.zeltrax.com/classiccmp_forum/sio_issue_01.jpg
Thanks for your help ;-)
Dominique
On 17/10/2017 20:22, Chuck Guzis via cctalk wrote:
On 10/17/2017 10:50 AM, Dominique Carlier via cctalk wrote:
Hi Chuck,
Yes I understand well. But the fact that the machines Z80 based were all
equipped with this famous serial I/O channel A and B, I therefore
thought that the principle of verification of these channels would
probably be the same on this type of architecture (Z80+PIO+CTC+SIO).
Therefore, there should be probably more people able to give me some
useful information.
Perhaps, but we don't know exactly what surrounds the Z80 SIO, or
exactly what the diagnostic is complaining about. Does your SIO have
anything other than line drivers or receivers on its external interface?
Some systems have programmable loop-back circuitry to enable the
terminal to function to talk to itself and verify functionality.
If you ignore the diagnostic message and feed the terminal some serial
data, do the inputs on the SIO wiggle appropriately in response? In
other words, is the data getting from the connector to the SIO chip?
Troubleshooting is slow, methodical work.
The SIO/DART chip itself is very simple--and most likely not the cause
of the diagnostic failure. But writing your own diagnostic software can
verify that.
At least that's what I think from a few thousand km away.
--Chuck
