Thanks in advance
Andrea
--
First make sure all the power supplly voltages ae there. It's common
for the PS to fail. Seconds if you see two (or more) blinking cursors
that indicates a likely monitor problem and that will smear the
characters making them garbled.
For the life of me I rarely have seen a Z80 fail, but I see people
test them every time. Must be the sockets.
I'd look at the reset circuit. Make sure all the clock signals are
present. before desoldering anything. I've seen way too much
hardware trashed by soldering damage and substitution of bad
componenets into the system where good were.
Another source of failure on old equipment is the sockets themselves.
Allison
> If the reset button has no effect, the problem might be the circuit that
> generates the reset signal to the CPU. Sorry I don't have a Kaypro
> schematic.
Hi Bill,
thanks for your advice. Unfortunately I have only very basic knowledge
of electronics, plus I don't have an oscilloscope or else, just a small
tester, so it's not going to be easy for me... but was able to find the
computer schematics and if you or anyone else would like to give a look
at them here you can find the images:
<http://myretrocomputing.altervista.org/kaypro_II_cpu.png>
<http://myretrocomputing.altervista.org/kaypro_II_io.png>
<http://myretrocomputing.altervista.org/kapyro_II_crt.png>
The only thing I was able to check about the reset is that pressing the
button drops the voltage on pin 26 of Z80 CPU to 0Volt and this should
be correct.
I've checked some more TTL ICs and they *seem* to be fine, I still have
to verify the following ones that I coulnd't find a replacement yet:
74SL290
74LS243
74LS241
74LS293
8216 Quad bidirectional MUX
8116 Dual programmable baud rate generator
FDC9216 Data separator
1793 FDC controller
Is there any of them that could be likely the faulty one?
Again, thanks for help.
Andrea
--
> First make sure all the power supplly voltages ae there. It's common
> for the PS to fail.
First of all, thanks for your help.
The PSU is fine, all voltages are present.
> Seconds if you see two (or more) blinking cursors
> that indicates a likely monitor problem and that will smear the
> characters making them garbled.
I've uploaded an image of the screen. Here you are:
<http://myretrocomputing.altervista.org/kaypro_screen.jpg>
> For the life of me I rarely have seen a Z80 fail, but I see people
> test them every time. Must be the sockets.
>
> I'd look at the reset circuit. Make sure all the clock signals are
> present. before desoldering anything.
Unfortunately I can't test clock signals due to lack of both hardware
and knowledge, I am going the hard way desoldering ICs. I've already
done some damage in the past on other stuff so I've learned the lesson.
I am confident I can handle it now without making mistakes with the
solder machine.
> Another source of failure on old equipment is the sockets themselves.
This is something I haven't checked yet, thanks for the advice.
Regards
Andrea
--
> I am trying to repair a non working Kaypro II, board model 81-240-n,
> boot eprom 81-232-n.
> The computer powers up, but the screen gets filled with garbled
> characters that keep blinking in a dual pattern, always the same, the
> reset button has no effect, drives lights stay on. Nothing more happens.
That is usually what is stored in memory, but not cleared
(by the running software) on power up.
> I've already succesfully tested the Z80 chips (CPU, PIOs, SIO) on
> another Z80 based computer and they all work, RAM ICs (4264) and video
> RAM(2114) seem to be all fine. Same goes for chargen and boot eproms.
> Meanwhile I am desoldering some TTL ICs that I can test on other
> equipents, so to make sure they are fine.
> Does anyone familiar with this computer can give me any hints or
> suggestion on what could be the faulty component?
As far as I know, the least likely cause is a bad IC.
It just happens so rarely, except possibly ones that have
outside connections (I/O ports) that it should be the last
thing to check. Other than bad contacts on sockets
and connectors, maybe most likely are electrolytic
capacitors. The power supply voltage may be right,
but have a lot of ripple. Measure the power supply
outputs with an AC voltmeter.
An AC voltmeter can tell you if there is a changing
signal on a pin. A running system should have AC
signals on the data bus and most of the lines of the
address bus. You can trace those through buffers and
to RAM and ROM chips. Measure all the pins on the Z80,
and be sure that it is supposed to run in that state.
Check for pins like hold or wait interrupt inputs.
It is a little easier with a scope, but it is possible
with an AC voltmeter and a little luck. Bad solder
joints are also possible, but removing all the soldered
in ICs and testing them is not likely to help.
TTL is very tough, unless you really stress it.
(I knew someone once with a wire wrapped 8080 board,
where one of the pins went through the electrical tape
on the power line fuse. That is one of the few ways
to kill TTL. Vcc above about 7 volts also, but that
will kill most of the board, not just one or two ICs.)
-- glen
There is a circuit in there (I forget the details) that configures
a 2048 byte memory into a 24 (actually 25) by 80 memory. This is
the video storage. It leaves a few bytes unused. Your symptoms
sound to me as if something could be wrong with that decoder.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
><no....@no.uce.bellatlantic.net> wrote:
>
>> First make sure all the power supplly voltages ae there. It's common
>> for the PS to fail.
>
>First of all, thanks for your help.
>The PSU is fine, all voltages are present.
>
>> Seconds if you see two (or more) blinking cursors
>> that indicates a likely monitor problem and that will smear the
>> characters making them garbled.
>
>I've uploaded an image of the screen. Here you are:
>
><http://myretrocomputing.altervista.org/kaypro_screen.jpg>
This is good as the monitor is working and most of the video logic
too. It most of the video logic were brioken you would not see that.
>
>> For the life of me I rarely have seen a Z80 fail, but I see people
>> test them every time. Must be the sockets.
>>
>> I'd look at the reset circuit. Make sure all the clock signals are
>> present. before desoldering anything.
>
>Unfortunately I can't test clock signals due to lack of both hardware
>and knowledge, I am going the hard way desoldering ICs. I've already
>done some damage in the past on other stuff so I've learned the lesson.
>I am confident I can handle it now without making mistakes with the
>solder machine.
A handy test tool if you can find or make one is a logic level probe.
It lights a let if logic is 1 another for logic 0 and if there are
pulses a oneshot gets fired to light a third led. RS and otehr used
to sell them and they are handy for looking in there. Typically cheap
20-50$.
Allison
> There is a circuit in there (I forget the details) that configures
> a 2048 byte memory into a 24 (actually 25) by 80 memory. This is
> the video storage. It leaves a few bytes unused. Your symptoms
> sound to me as if something could be wrong with that decoder.
I would say more likely that memory was never cleared.
Static RAM has a fairly high tendency to power up to
the same value each time. DRAM is somewhat less likely
to do that, but it may still be possible.
-- glen
Does the screen always display the same text? If so, is it possible
that the memory being displayed is actually in the ROM and not RAM?
Maybe a bad address line somewhere?
Bill H
> Does the screen always display the same text?
Yes, it does.
> If so, is it possible
> that the memory being displayed is actually in the ROM and not RAM?
What I am going to say is surely questionable, due to my lack of
electronics knowledge, but I have my explaination for this behaviour.
Since video ram is static unless it get cleared by the system it will
always send the same output on screen. I can change the display output
by moving the 2114 ICs on the board, but for a fixed configuration I get
always the same output.
Andrea
--
> Other than bad contacts on sockets
> and connectors, maybe most likely are electrolytic
> capacitors.
There are just 2 small electrolytics capacitors and I've already
replaced them without any luck. Yesterday I also heatened all big ICs
sockets pins so to "refresh" the welds. Nothing changed yet. I will do
this also for the small ICs later.
>The power supply voltage may be right,
> but have a lot of ripple. Measure the power supply
> outputs with an AC voltmeter.
>
> An AC voltmeter can tell you if there is a changing
> signal on a pin. A running system should have AC
> signals on the data bus and most of the lines of the
> address bus. You can trace those through buffers and
> to RAM and ROM chips. Measure all the pins on the Z80,
> and be sure that it is supposed to run in that state.
> Check for pins like hold or wait interrupt inputs.
> It is a little easier with a scope, but it is possible
> with an AC voltmeter and a little luck.
I am not sure I understand how to make this. As I've already said, I
have only very basic knowledge of electronics, so this sounds somewhat
arcane to me. I have a digital tester (multimeter?) that can test AC
too, after the check I noticed this strange behavior: at power up
sometimes on the address bus pins (1-5, 30-40) I get 1.6V, while on
clock pin (6) I get 0V. After pressing the reset button address bus pins
go to about 6V while clock goes 8.8V. Sometimes instead at power up I
get 2.4V on the address bus pins and 8.8V on clock. If I press the reset
none of these values change. I guess this is not normal... is it?
Andrea
--
I think it's admirable that you are working to repair this Kaypro.
But, the problem is that there is no clear "symptom" to guide your
repair process. And it's very difficult to unsolder one chip after
another without damaging the circuit board. So in my somewhat informed
opinion, I don't think chip-by-chip external testing will result in a
repair except by pure luck.
I don't have the schematics in front of me, but typically this kind of
design has a bunch of logic chips which display memory contents in
video; and then there's the Z80 side which runs the programs and
keyboard and all that. Those two sets of electronics share the RAM
memory.
Now, the video side is working - you have a display of memory
contents, the video display is stable. The specifics of what is
displayed is random and happenstance - if it changes when you change
RAM chips, that's not informative. But you can in principle consider
the video display logic as "OK". (So you need to know what chips are
part of the "video display" because you don't have to test them.)
But, the Z80 is not running, or not running for very long, or is
running but crashing. No "logic probe" work will easily determine what
it is doing or why. A logic probe is not an oscilloscope, it will not
show you timing and sequence of logic signals. that's what an
oscilloscope does. It will show if some connection changes state. But
without knowledge of what it "should" be doing, that information is
not useful.
It's hard to say from this point "here is what you should do". The
problem is you don't have any equipment and you don't have much
digital circuit knowledge. But that is what it takes to diagnose the
problems and find what is at fault. The "test each chip" method can
work if the problem is a failed chip. But it could be a broken PC
board, or a component like a capacitor or resistor, or a "cold solder
joint" that does not make a good connection. And you can create
problems by burning up a circuit trace, since the chips are not
socketed.
Again, it's commendable you are working on this Kaypro. But the Kaypro
does not "care" about your intentions. There is some problem on it,
which may be signifigant like a bad logic chip, or subtle like bad
timing, or maybe a ROM which has scrambled its code from age. To fix
it, someone with knowledge and an oscilloscope or logic analyzer and
the schematics has to sit down with it and start looking at signals.
It seems to me, you have an opportunity and a choice. You can learn
more about digital logic and microprocessor logic - old books are for
sale or can be borrowed from a library. You can acquire an
oscilloscope (any hamfest will have them). Then you can start looking
at the Kaypro and understand what's going on. Or, you can improve your
soldering skills, test each chip, and hope you get lucky and not only
find the problem but avoid creating another one.
Some people may decide these remarks are unfair or discouraging.
Again, these are chips on a board. The board and chips don't care
about intentions or hopes. They do what they do. They perform in a
certain way, by theory and design. Then, in the real world, they
perform in different ways because of a bad connection, or a component
like a capacitor changes value, or once in awhile due to a failure of
a logic gate. And in the real world, THINGS FAIL. This is not Star
Trek where computers are found running after 100, 200 years.
So, if you can learn these things, get this equipment, you'll have
more opportunities to keep other Kaypro's and other microcomputers of
the era running. For they will ALL FAIL IN TIME.
Herb Johnson
retrotechnology.com
> Does the screen always display the same text? If so, is it possible
> that the memory being displayed is actually in the ROM and not RAM?
> Maybe a bad address line somewhere?
SRAM has a fairly high chance of powering up to the same
value each time. Maybe not exactly, but close.
I don't know specifically the kaypro, but it was fairly
common to have dedicated SRAM display memory with a mux
so that the processor could read/write to it. I believe
that is what others have suggested.
Not so much later as DRAM became more popular, putting the
display in main memory, with alternating between processor
and display. (DRAM was fast enough relative to processor
speeds of the time.) That is still done on many boards
with built-in display logic.
-- glen
>On Sep 12, 7:34 am, myem...@fattimie.i (andrea) wrote:
>>
>> What I am going to say is surely questionable, due to my lack of
>> electronics knowledge, but I have my explaination for this behaviour.
>> Since video ram is static unless it get cleared by the system it will
>> always send the same output on screen. I can change the display output
>> by moving the 2114 ICs on the board, but for a fixed configuration I get
>> always the same output.
>>
>> Andrea
>
>I think it's admirable that you are working to repair this Kaypro.
>But, the problem is that there is no clear "symptom" to guide your
>repair process. And it's very difficult to unsolder one chip after
>another without damaging the circuit board. So in my somewhat informed
>opinion, I don't think chip-by-chip external testing will result in a
>repair except by pure luck.
I would agree having worked on a few.
>
>I don't have the schematics in front of me, but typically this kind of
>design has a bunch of logic chips which display memory contents in
>video; and then there's the Z80 side which runs the programs and
>keyboard and all that. Those two sets of electronics share the RAM
>memory.
Not the case for a kaypro. Kaypro has a seperate video ram and
applications (processor ram). However if the Z80 is doing nothing
the video ram with never be updated.
>
>Now, the video side is working - you have a display of memory
>contents, the video display is stable. The specifics of what is
>displayed is random and happenstance - if it changes when you change
>RAM chips, that's not informative. But you can in principle consider
>the video display logic as "OK". (So you need to know what chips are
>part of the "video display" because you don't have to test them.)
Also since the 6845 has to be programmed to get to that state (does
not power up to that by default) the Z80 must be doing something
and either getting lost or cant talk to the display ram to update it.
>But, the Z80 is not running, or not running for very long, or is
>running but crashing. No "logic probe" work will easily determine what
>it is doing or why. A logic probe is not an oscilloscope, it will not
>show you timing and sequence of logic signals. that's what an
>oscilloscope does. It will show if some connection changes state. But
>without knowledge of what it "should" be doing, that information is
>not useful.
I disagree. A scope is the tool for hunting for logic that is sorta
there. A logic probe is for those signals that are present or absent.
The likelyhood of the latter in a known design that did work at one
time is very high. So the likely circuit fault is maybe only one gate
that has died.
>It's hard to say from this point "here is what you should do". The
>problem is you don't have any equipment and you don't have much
>digital circuit knowledge. But that is what it takes to diagnose the
>problems and find what is at fault. The "test each chip" method can
>work if the problem is a failed chip. But it could be a broken PC
>board, or a component like a capacitor or resistor, or a "cold solder
>joint" that does not make a good connection. And you can create
>problems by burning up a circuit trace, since the chips are not
>socketed.
Clearly there is a should do. One is know how the system operates and
methodically proceed from that understanding to see what is being done
by the z80 if anything (it is setting up the 6845) and what is not
happening and then focusing on the logic that leads to that.
What does operate:
Power suppply.
Monitor (you have a stable display)
Video logic (it starts up and the 6845 is being programmed to
put out the required timing to drive the monitor.
The above says the Z80 does start up and so something.
Do thing happen like the drive lights change?
Do the drives home to track 00
Does it appear to read a floppy?
Do the light on the kayboard light, caps lock chage state?
Does anything come out of the serial ports?
Is there a manual out there with a page of troubleshooting hints?
>
>Again, it's commendable you are working on this Kaypro. But the Kaypro
>does not "care" about your intentions. There is some problem on it,
>which may be signifigant like a bad logic chip, or subtle like bad
>timing, or maybe a ROM which has scrambled its code from age. To fix
>it, someone with knowledge and an oscilloscope or logic analyzer and
>the schematics has to sit down with it and start looking at signals.
Likely faults in once working equipment is a component failure.
Possible candidates are bad eproms, or a TTL that has a dead gate.
Other possible candidates is soemone tried to mod or update it and
did something wrong like install the wrong rom, or initially installed
it upside down.
All it takes is one gate failing to "disconnect" the Z80 from the
video ram and the screen will never clear or otherwise update.
>It seems to me, you have an opportunity and a choice. You can learn
>more about digital logic and microprocessor logic - old books are for
>sale or can be borrowed from a library. You can acquire an
>oscilloscope (any hamfest will have them). Then you can start looking
>at the Kaypro and understand what's going on. Or, you can improve your
>soldering skills, test each chip, and hope you get lucky and not only
>find the problem but avoid creating another one.
Also the schematics and other inforamtion about the kaypro CPU board.
There is nothing super magical on it. Though later baords did have a
gate array or two that can fail. My expereince with many dozens of
machines and board is all it takes is a 74LS00 that developed a stuck
input or open output on one of the gates n the package to kill a
system. In short a part that failed with time or some side effect of
mishandling in it's life before being inserted in the board.
>Some people may decide these remarks are unfair or discouraging.
>Again, these are chips on a board. The board and chips don't care
>about intentions or hopes. They do what they do. They perform in a
>certain way, by theory and design. Then, in the real world, they
>perform in different ways because of a bad connection, or a component
>like a capacitor changes value, or once in awhile due to a failure of
>a logic gate. And in the real world, THINGS FAIL. This is not Star
>Trek where computers are found running after 100, 200 years.
>
>So, if you can learn these things, get this equipment, you'll have
>more opportunities to keep other Kaypro's and other microcomputers of
>the era running. For they will ALL FAIL IN TIME.
;) It's an aquired skill for some and for others its' magic and the
skill eludes them. Troubleshooting is a mystery novel, you know the
ending and the victums but what happens in between isprocess,
knowledge and interpreting the clues that are there.
Allison
>
>Herb Johnson
>retrotechnology.com
> Does anyone familiar with this computer can give me any hints or
> suggestion on what could be the faulty component?
Andrea -
I am more familiar with the BigBoard that the Kaypro is based on
(having built up several dozen of them in the early 1980's). I
believe the Kaypro II also works the same way, as does the Xerox 820.
With the BB the system initializes the DRAM, then copies the ROM to
DRAM and performs a bankswap. If this doesn't happen properly the
processor jumps to essentially junk code and crashes and you will see
the flashing screen.
Your problem is most likely with the DRAM, or refresh circuitry
(largely built around a 74164) Since you've swapped the DRAM, I'd
take a look at the power supply stability and DRAM support IC's
(74157, 8216, 74164).
There was a test rom for the big board that ran entirely out of the
video memory (which as SRAM was much more likely to be working). I
may still have a copy. It might help in the Kaypro as well. If you
don't get anywhere let me know and I'll try and dig out a copy and
burn it for you. It was 2716 based.
As another try you might swap the 20mhz crystal for a lower value, say
12-16mhz. It is not critical, but "underclocking" might let you get
the system working.
- Gary
You said that the disk drive light stays on, could the issue be in the
drives themselves, causing the system to hang? can they be unplugged
from the motherboard to see what effect that has?
Bill H
Most of that may not easily apply to the kaypro. the clock derivation
for video, serial and CPu are different.
Allison
>
>- Gary
On Kaypros the drive select always stays on, it may change from drive
to drive B but on is always on with my two (a 4/84 and a K2).
If the drive was unavaiable or broke it would give a clear screen and
error message. This never clears the screen if I remember an earlier
message correctly.
Allison
>Bill H
> You said that the disk drive light stays on, could the issue be in the
> drives themselves, causing the system to hang? can they be unplugged
> from the motherboard to see what effect that has?
Yes they can, but nothing changes if I unplug them.
> I think it's admirable that you are working to repair this Kaypro.
> But, the problem is that there is no clear "symptom" to guide your
> repair process. And it's very difficult to unsolder one chip after
> another without damaging the circuit board. So in my somewhat informed
> opinion, I don't think chip-by-chip external testing will result in a
> repair except by pure luck.
Herb, that's the way I've repaired most of my failed stuff untill now.
This is for sure the worst case ever, since usually it's just a
ROM/EPROM, a leaking capacitor, a failing RAM, burst tantalium
capacitor, a voltage regulator, a bent IC pin, an inverted connector, a
track that does not make good connection... pretty basic and simple
things that I could check and swap without having deep knowledge of how
computers operate at the CPU signals level. Anyway you are right, this
is not for sure the best way to repair computers. With the Kaypro when I
first powered the computer I thought it was a case of failing eprom and
after replacing all of them and seeing I didn't fix it I had a feeling
it was going to be a harder job, harder than expected.
> It seems to me, you have an opportunity and a choice. You can learn
> more about digital logic and microprocessor logic - old books are for
> sale or can be borrowed from a library. You can acquire an
> oscilloscope (any hamfest will have them). Then you can start looking
> at the Kaypro and understand what's going on. Or, you can improve your
> soldering skills, test each chip, and hope you get lucky and not only
> find the problem but avoid creating another one.
> So, if you can learn these things, get this equipment, you'll have
> more opportunities to keep other Kaypro's and other microcomputers of
> the era running. For they will ALL FAIL IN TIME.
I completely agreee with you, I should go that way.
> Your problem is most likely with the DRAM, or refresh circuitry
> (largely built around a 74164) Since you've swapped the DRAM, I'd
> take a look at the power supply stability and DRAM support IC's
> (74157, 8216, 74164).
Thanks for this advice.
By the way, yesterday I could show the schematics to a person that has
far much better knowledge of those old computers than me and he told me
basically the same things that were said by the various posters of this
thread. In short, it could be anything. So I will finish my plan of
swapping the last 5 or so chips then, if I get no positive feedback, I
will start to learn how old computer circuitry operate and to find an
oscilloscope for this purpose.
no.s...@ wrote:
> Herb Johnson posted
> >I don't have the schematics in front of me, but typically this kind of
> >design has a bunch of logic chips which display memory contents in
> >video;
>
> Not the case for a kaypro. Kaypro has a seperate video ram and
> applications (processor ram). However if the Z80 is doing nothing
> the video ram with never be updated.
This illustrates the different ways these microcomputers can produce
video. A reading of the schematic and the technical documentation
provide guidance as to which circuits can be ignored, which ones to
check. When you've read a lot of schematics, these things start to add
up.
> >Now, the video side is working...and stable...- you have a display of memory
> Also since the 6845 has to be programmed to get to that state (does
> not power up to that by default) the Z80 must be doing something
> and either getting lost or cant talk to the display ram to update it.
Again, more knowledge about the 6845 leads to understanding and more
clues.
> > No "logic probe" work will easily determine what
> >it is doing or why. A logic probe is not an oscilloscope, it will not
> >show you timing and sequence of logic signals.
> I disagree. A scope is the tool for hunting for logic that is sorta
> there. A logic probe is for those signals that are present or absent.
> The likelyhood of the latter in a known design that did work at one
> time is very high. So the likely circuit fault is maybe only one gate
> that has died.
This is a matter of taste and of experience. An experienced person
like Allison knows to look for "bad logic", rather than check for
logic activity. One can use the oscillscope as a logic probe. Allison
could probably diagnose with an LED and resistor to ground if
necessary!
> >It's hard to say from this point "here is what you should do". The
> >problem is you don't have any equipment and you don't have much
> >digital circuit knowledge....
> Clearly there is a should do. One is know how the system operates and
> methodically proceed from that understanding to see what is being done..
We are not in disagreement. Allison goes on to diagnose based on the
information given (a stable video display) and her better knowledge of
the Kaypro and what the circuit is doing. She also offers more actions
to be taken to yield more clues; and possible failures.
I declined to do this because I was making a larger point. But one can
also do what you (Andrea) has done; ask for help, get some feedback,
act on it, show results, ask for more help.....Nothing wrong with
that, but as I said: it's a learning opportunity if you invest in
learning more about these devices and circuits. Allison suggests that,
as a practical matter, problems are often a failed part at one point:
> My expereince with many dozens of
> machines and board is all it takes is a ... part that failed with time
> or some side effect of
> mishandling in it's life before being inserted in the board.
>
[Regarding repairs and diagnosis...]
> ;) It's an acquired skill for some and for others its' magic and the
> skill eludes them. Troubleshooting is a mystery novel, you know the
> ending and the victims but what happens in between is process,
> knowledge and interpreting the clues that are there.
>
> Allison
Actually, I'd say it's more like a mystery novel YOU ARE WRITING. It's
based on "true facts" but the facts are not apparent. Even the ending
and victims are not clear. Many enjoy reading detective novels because
they enjoy the process and interpretation, or they have a sense of
justice. Likewise, many enjoy repair and diagnosis for the challenge,
or to return equipment to good use.
Andrea replies later that swapping chips "is not the best way to
repair computers". There's nothing wrong with doing that. BUT, it goes
faster when you know which chips to swap, and why. And, if there are
any computers where one can learn how they work down to the chip, it's
computers which first ran CP/M!
I'm glad Andrea got some encouragements, as well as some specific
"where to go's". The advice and points apply in general, at least...in
the CP/M zone...
Herb Johnson
be de be de be de be de...
retrotechnology.com
>no.s...@ wrote:
>> Also since the 6845 has to be programmed to get to that state (does
>> not power up to that by default) the Z80 must be doing something
>> and either getting lost or cant talk to the display ram to update it.
>Again, more knowledge about the 6845 leads to understanding and more
>clues.
But:
If you look at the shematics:
http://myretrocomputing.altervista.org/kapyro_II_crt.png
there is *no* 6845-IC to be programmed.
A simple oszillator at the upper left corner and a chain of
TTL-dividers make the video-Timing.
The CPU has a seperate oszillator:
http://myretrocomputing.altervista.org/kaypro_II_cpu.png
yours, Holger
>Herb Johnson <herbrj...@gmail.com> writes:
>
>>no.s...@ wrote:
>
>>> Also since the 6845 has to be programmed to get to that state (does
>>> not power up to that by default) the Z80 must be doing something
>>> and either getting lost or cant talk to the display ram to update it.
>
>>Again, more knowledge about the 6845 leads to understanding and more
>>clues.
>
>But:
>
>If you look at the shematics:
>
> http://myretrocomputing.altervista.org/kapyro_II_crt.png
>
>there is *no* 6845-IC to be programmed.
Rats, Thats one of the difernce between the II and the 2.
The 4/84 dioes use the 6845.
>
>A simple oszillator at the upper left corner and a chain of
>TTL-dividers make the video-Timing.
>
>The CPU has a seperate oszillator:
>
>http://myretrocomputing.altervista.org/kaypro_II_cpu.png
Even this we have more information. The divider chain of the Video
is working so we know there is clock there. However that doent mean
the CPU clock or some part of the logic on that page is fully there.
Allison
>
>yours, Holger
Since you are probably measuring with a DC voltmeter, it is difficult to
make anything out of the values you read, but the values are suspect.
> Seeing either 0 volts or 8.8 volts on the clock is probably wrong. The
> clock should be a square wave between 0 and ~5 volts. 0 volts could mean
> the oscillator is not running. 8.8 volts adds that the 5 volt power supply
> is may not be correct.
>
> Since you are probably measuring with a DC voltmeter, it is difficult to
> make anything out of the values you read, but the values are suspect.
I am using another voltmeter and I now I find 10.2V or 0V. Of course, I
am using it in the AC mode, as suggested by Glen, so I guess now the 10V
value is fine, PSU is ok.
Andrea
--
> Seeing either 0 volts or 8.8 volts on the clock is probably wrong. The
> clock should be a square wave between 0 and ~5 volts. 0 volts could mean
> the oscillator is not running. 8.8 volts adds that the 5 volt power supply
> is may not be correct.
If it measures the average of the absolute value of the AC
coupled input and displays RMS you could get up to about 8V.
> Since you are probably measuring with a DC voltmeter, it is difficult to
> make anything out of the values you read, but the values are suspect.
The usual electronic voltmeter is AC coupled (a capacitor) in AC
mode, so it will indicate a changing signal (large reading) or
static signal (close to zero). In DC mode it will give the
average value. Both are useful for such debugging.
-- glen
> Most of that may not easily apply to the kaypro. the clock derivation
> for video, serial and CPu are different.
This reminds me of the C64, which included the schematic in the box.
It takes just a few seconds to see what they did in the design:
The display logic is in one corner, (triangle in the matrix sense),
the processor logic in the other, and a PLL in the middle.
It seems that originally they had separate clocks for the two, but
there was enough leakage that was visible in the display, especially
if they are close to the ratio of integers. With the PLL they are
phase locked, so no patterns slowly crawling on the screen.
-- glen
As an engineer, I find it odd to use either an AC or a DC voltmeter,
to look at logical signals. Seems to me different meters would display
different results, based on their response to megahertz-speed digital
signals. For sure, even if the AC meter "says" 8 volts" there is NOT
an 8-volt signal there.
But now I'm curious. Do people REALLY use DC or AC voltmeters to look
at TTL type logic and microprocessors? And get consistent results?
That they can explain simply to someone else less knowledgeable?
Expalin them to me, maybe I know too much.
Herb Johnson
retrotechnology.com
I suspect they just don't have a scope, or are ignorant about
electricity. If they have to use a DC voltmeter to check clock
amplitude, I suggest a diode driving a small capacitor (say 0.001
uF, at a guess) and measure what shows up there. That should be a
fairly reliable 5V dc.
> But now I'm curious. Do people REALLY use DC or AC voltmeters to look
> at TTL type logic and microprocessors? And get consistent results?
> That they can explain simply to someone else less knowledgeable?
> Expalin them to me, maybe I know too much.
The OP indicated he had a DVM but not a scope.
The processor either is or isn't running, and you can
tell that with a DVM. Some of the address lines should
be changing. With a scope that is about all you are
likely to learn, anyway.
For debugging a new design, a scope with multiple inputs,
at least such that you can trigger off one signal and
monitor another, would help. That allows one to find
possible setup/hold violations for example.
In this case, the design is already known to work.
While some timing problems might be left, most should have
been resolved. (Except possibly for capacitor drift.)
If the clock is running and the processor isn't, measuring
the AC and DC voltage on all the inputs should track down
why it isn't running.
A scope would be nice, though.
-- glen
I have the benefit of many years of troubleshooting electrical and
electronic gear, from tubes and relays into the earliest of "solid state".
So do many of the group's participants. What was not considered, or at
least mentioned to date, is that measuring expected DC levels in AC mode
will show higher levels due to circuit and measurement equipment
capacitance, approaching 200% if ripple is excessive.
In my years of "shooting bugs" on micros I found probably more than 90% of
problems using a Tektronix Logic Probe. Realize of course that this was
relatively low frequency clocking (typically less than 12 MHz.), but
transitions of address, data, and control lines were clearly indicated by
alternate flashes of the HIGH/LOW LEDs, and data/status could be captured
using the optional TRIGGER input of the logic probe to sync a transition to
a desired clocking input.
In Andrea's case, a cheap used 'scope would be both an boon to her
understanding, as well as a useful tool to determine what's happening on the
power supply side (excessive AC ripple or unregulated output?), ADDRESS line
transitions (showing that the processor is functioning, and that required
address lines are functional), DATA line transitions (showing that one or
more data lines aren't stuck), and CONTROL line status (giving an indication
of what mode the processor should be in during an operation).
As mentioned by others previously, you have to know what you're looking for
before you can determine what ain't happening!
My 2 cents... here's a nickel, keep the change!
I took 2 DVMs and 3 analog voltmeters and used them to measure a 2.5 MHz 5
volt peak to peak square wave.
I measured AC volts.
The two DVMs and one analog meter read basically 0.
One analog meter read full scale on any range. Obviously its accuracy for
high frequencies is questionable.
One analog meter read 2.5 volts. (Triplett 630)
Either my meters are toast, or trying to make any sense of readings from
that kind of signal is questionable at best.
Andrea could learn much more using an oscilloscope.
>The OP indicated he had a DVM but not a scope.
^^
If not in italy, "Andrea" sounds female to me (as a german :-)
>The processor either is or isn't running, and you can
>tell that with a DVM. Some of the address lines should
>be changing. With a scope that is about all you are
>likely to learn, anyway.
I'd look on the M1-signalof the Z80.
And: Once I repaired a PC, where the RESET-'push-button'
was stuck in the closed position...
So: what is the state of the control-signals of the Z80?
Yours, Holger
> If not in italy, "Andrea" sounds female to me (as a german :-)
Andrea's a gender neutral name.
--
http://www.munted.org.uk
Fearsome grindings.
I'd say all you can see is whether a line is static or has changes of
level. In many cases this can tell you a lot and if a voltmeter is all
you have (or is all you have in your shirt pocket right now) it's that
or nothing.
I'm coming into this real late, but wanted to ask if you got your Kaypro
running yet?
Did anyone mention this one?
The most common problem I recall dealing with was the power supply
connector. They were simply crimped on, and after a while corrossion
between the wires and connector would cause problems.
Soldering the pins to the wires usually cured all kinds of woes.
Richard Lamb
> Did anyone mention this one?
>
> The most common problem I recall dealing with was the power supply
> connector. They were simply crimped on, and after a while corrossion
> between the wires and connector would cause problems.
> Soldering the pins to the wires usually cured all kinds of woes.
I did... several years ago, in answer to someone else.
I am aware of corrosion, since I live near the Atlantic Ocean.
One symptom of corrosion is when a computer do not work when it is wet, but
run without any problem when it is dry...
I have a file dealing with corrosion, if someone is interested.
Yours Sincerely,
Mr. Emmanuel Roche, France
> I'm coming into this real late, but wanted to ask if you got your Kaypro
> running yet?
Not yet, at the moment I am waiting to get somebody with an oscilloscope
to check it, that's the most reasonable thing to do at this point.
--
Check the power connector to the main board.
Solder it of it's not already.
After 20-25 years, it's going to nead it anyway.
Worth a try?
> Check the power connector to the main board.
> Solder it of it's not already.
> After 20-25 years, it's going to nead it anyway.
>
> Worth a try?
Yes, of course. But voltages were present on the board when I checked
them. Since yesterday I'm far from home so I can't do actually anything
to the kaypro, but if I will eventually succeed in repairing it I will
let the newsgroup know.
Hi Andrea
You mentioned that you'd replaced the EPROMs. Does that mean that
you can program EPROMs?
If so, there is another method of trouble shooting. One writes small
bits
of code the test things. This assumes that the CPU, address bus/data
bus and
the decoding for the EPROMs are working.
I've used this method in the pass when nothing seemed to give an
obvious
indication of failure ( I do have a scope and know how to use it ).
One should start really small. Assume that the RAM doesn't work.
First
experimental programs should be all in registers.
First program might just be a jump to it self. One can look at the
address
lines to see if things are running as expected.
Work up from there. Simple RAM test and I/O test. Once you find a
reliable
output method, you can use that a status for other experiments.
I've not looked at the schematic but I assume that if it has DRAM, it
uses
the Z80's refresh. One can write a program that writes something to
DRAM and then waits some time to ensure that it isn't lost ( 2 or 3
seconds
are usually enough ). This would check that the refresh was working.
Each experiment may lead to the next experiment.
If you can't get it working with a minimal program, try removing
parts
from the buses that are not needed for minimal operation. Things like
bus buffers and then address decoders.
Use some imagination. Read how the Z80 talks to the bus so you
understand
what to expect.
It isn't hopeless but will take some work. A lot will be learned
along the way.
Dwight
> Hi Andrea
> You mentioned that you'd replaced the EPROMs. Does that mean that
> you can program EPROMs?
Yes, I can...
> If so, there is another method of trouble shooting.
[snip]
> It isn't hopeless but will take some work. A lot will be learned
> along the way.
Dwight, thanks for your interesting suggestions, but unfortunately I am
not into microprocessors programming, anyway I think that on line I can
find some resources that will help me to go down your path. It would be
interesting, indeed.
Andrea,
Maybe a dumb question, but...
Did you perform a visual inspection of the mainboard with a magnifying
glass? Cracked traces/solder, debris shorting adjacent traces, black
corrosion on IC pins/sockets, blown caps, etc? Sometimes you need a
magnifying glass to find these.
-J
>
> --
>
> http://myretrocomputing.altervista.org