Hi Dwight
The machine is in fact equipped with three connectors, a DB25 for RS-232
communication, a DB9 male for the keyboard and a third connector,
another DB9, female this time, not sure but I think it was to connect a
card reader.
Do you think the serial I/O channel B can share its resource for the
RS-232 and the keyboard at the same time?
Clearly the problem is around the SIO B, not the SIO itself because I
tested this IC by replacing it with another identical SIO with exactly
the same result.
As said below, the "OPTIONAL RAM BANK 0.1: FAILED" is not the problem,
the machine can start without this memory extension board. It was the
case when the machine worked by the past, it was also the case when I
was able to enter the page setup some weeks ago, when the failure was
still intermittent and not permanent.
Note that once the default parameters are loaded into the non-volatile
memory and manually completed, after a reset, some FAILEDs are replaced
by "??????", which can be considered as "assumed as absent ".
I will continue to check and repair the eventually damaged solder/tracks
(battery leakage), this is what I have been doing for 2 weeks now, and
I'm going to try a suggestion from Chuck : Put an external "loopback"
connector to the RS-232 DB25 which is linked to the SIO channel B, just
to see if this has any impact on the diagnosis.
If not there is no result, I always would like to induce to the
self-test program that the channel B is OK by injecting something (but
what ?) to the SIO (perhaps by acting on this pin 30 which is W/RDYB,
something like "channel B Ready to write" right ?) in the idea to force
a positive diagnosis in the self-test.
Dominique
On 18/10/2017 06:44, dwight via cctalk wrote:
By the way, how is the terminal and keyboard connected to the computer?
Is it by RS232?
If so, it might be through SIO B. If this is the case, it might be the problem.
Also, the RAM failure may be the issue as well. You have something that is
intermittent there. Bad RAM can cause programs to misbehave as well. Just
because it passes some times doesn't mean it is good enough to run programs.
Dwight
________________________________
From: cctalk <cctalk-boun...@classiccmp.org> on behalf of dwight via cctalk
<cctalk@classiccmp.org>
Sent: Tuesday, October 17, 2017 4:08:46 PM
To: Dominique Carlier; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette
subsystem : Restoration
Since you know the pinout of the SIO chip, you might first look to see if where
the rx and tx pins go. This may require some hunting with an ohm meter. I'd
suspect they go to a RS232 level shifter.
You may also have to write some code to run the serial chip and any possible
external loopback. As I recall these chips may have an internal loopback.
If you have a working logic analyzer, you can trigger on the select pin to the
SIO and look to see what address the SIO is located at. That will allow you to
create some debug code.
I'm not saying this is easy. Still, this is the way I'd attack the problem as a
start.
You have to realize, there is not much more we can do for you.
Creating a ROM with a diagnostic looping program is about the only practical
way to deal with a machine with no documentation.
I fixed an old mini once without schematics but it was all DTL and TTL and
there were signal names at the card edges.
You have a Z80 computer. If you can program EPROMs you have a chance, otherwise
it is unlikely that your current easter egg hunting method is likely to be very
fruitful. You have already gone through most all of the likely failure items.
From here you will likely have to begin to troubleshoot.
Dwight
________________________________
From: cctalk <cctalk-boun...@classiccmp.org> on behalf of Dominique Carlier via
cctalk <cctalk@classiccmp.org>
Sent: Tuesday, October 17, 2017 1:59:47 PM
To: Chuck Guzis; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: The SPERRY UNIVAC UTS 40 system + 8406 double-sided diskette
subsystem : Restoration
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
