• Please review our updated Terms and Rules here

KIM-1 Repairs continue

Wait a second... So you're saying you pulled and replaced those 40p DIPs and didn't socket them?
 
Yeah that doesn't look great, looks worse in the photo than real life, but it has continuity and is not shorting to the pins on either side...
 
My concern was that the parts for U2 and U3 had either:

1. Been inserted in the wrong position or.
2. Been inserted the wrong way around.

It is a stupid idea for the components to be ordered U1, U3 and U2 and for U2 and U3 to be physically installed the opposite way round to U1.

You can't take anything for granted, and it pays to check absolutely everything when you get a machine, or you have changed something, BEFORE applying power!

Your devices look OK though.

You need the ROMs in both U2 and U3 working, but only the RAM in U2. You should be able to get away with faulty RAM in U3 (it is available for the user to use).

The I/O ports have to work on U2 as well.

I see that the CPU is soldered in, so a NOP generator is out of the question.

Thanks for providing a photograph of the solder side of the PCB. Unfortunately, you are absolutely going to have to clean up that soldering though! It is a shame that you practiced on a KIM-1. I hope you have learnt your lesson...

I can now see what is socketed, so I will have a think. I think we can disable all of the onboard devices and force the data bus to $EA (NOP) with resistors as a test. Let me have a look at the schematics...

Why didn't you put sockets on if you changed something?

Dave
 
Yeah that doesn't look great, looks worse in the photo than real life, but it has continuity and is not shorting to the pins on either side...

That's not the point. You're putting the socket in for the next time you have to pull that
chip, because the pads, traces, and hole plating are not going to survive a second round.
 
My concern was that the parts for U2 and U3 had either:

1. Been inserted in the wrong position or.
2. Been inserted the wrong way around.

It is a stupid idea for the components to be ordered U1, U3 and U2 and for U2 and U3 to be physically installed the opposite way round to U1.

You can't take anything for granted, and it pays to check absolutely everything when you get a machine, or you have changed something, BEFORE applying power!

Your devices look OK though.

You need the ROMs in both U2 and U3 working, but only the RAM in U2. You should be able to get away with faulty RAM in U3 (it is available for the user to use).

The I/O ports have to work on U2 as well.

I see that the CPU is soldered in, so a NOP generator is out of the question.

Thanks for providing a photograph of the solder side of the PCB. Unfortunately, you are absolutely going to have to clean up that soldering though! It is a shame that you practiced on a KIM-1. I hope you have learnt your lesson...

I can now see what is socketed, so I will have a think. I think we can disable all of the onboard devices and force the data bus to $EA (NOP) with resistors as a test. Let me have a look at the schematics...

Why didn't you put sockets on if you changed something?

Dave
Youthful overconfidence. Plus at the time KIM-1s weren't going for much money at all. I had one before this that I never even powered up.. sold it for a couple hundred to buy something else, then caught this one for $100. At the time they weren't fetching much money and I didn't realize how fragile they were with soldering/desoldering, nor did I have the right tools. Now they sell for $3K+. Oops. Anyway, lesson learned.

I agree not ordering the U1-U3 thing is goofy. I suspect maybe they were ordered that way originally and then someone thought. Oh, if I make U2 the -002 and U3 the -003 that'll make it easier for ordering replacements or something. That, and the schematic showing them in proper order has really caused me grief.

Would a logic analyzer help here? Would that at least tell us what 'code' the CPU is trying to run?
 
It is a stupid idea for the components to be ordered U1, U3 and U2 and for U2 and U3 to be physically installed the opposite way round to U1.

You're suggesting that it was someone's "idea". It wasn't. The guys who were producing those
mask parts were not the same guys as laying out the KIM PCB, and all they were doing was assigning
a suffix so they could keep straight which part had which mask, not concerning themselves with what
the component designation on the PCB might be. Totally unrelated subjects, so inappropriate to call
it "stupid", because it wasn't a thing. That the numbers worked out that way was, in all likelyhood,
pure coincidence.
 
Last edited:
>>> Would a logic analyzer help here? Would that at least tell us what 'code' the CPU is trying to run?

A resounding YES!

I just snagged an HP 1651A logic analyser from work. It was in the junk pile. It is now in the dining room awaiting test...

Dave
 
>>> Would a logic analyzer help here? Would that at least tell us what 'code' the CPU is trying to run?

A resounding YES!

I just snagged an HP 1651A logic analyser from work. It was in the junk pile. It is now in the dining room awaiting test...

Dave
I asked because I watched some videos of using one the other day and was like.. why didn't I get one of those to start with. Ok.. ordered.
 
You're suggesting that it was someone's "idea". It wasn't. The guys who were producing those
mask parts were not the same guys as laying out the KIM PCB, and all they were doing was assigning
a suffix so they could keep straight which part had which mask, not concerning themselves with what
the component designation on the PCB might be. Totally unrelated subjects, so inappropriate to call
it "stupid", because it wasn't a thing.

You are correct in that the -nnn identifier is the ROM mask content. So the fact that someone decided you use U2 for the -002 part and U3 for the -003 part is inspired.

However, the concept of laying out the parts on a PCB in a non-logical ordering (when there was plenty of experience available to the contrary) was not sensible.

The same could be said for putting the U2 and U3 parts in the PCB the opposite way around to (say) U1.

I worked in an industry at the time where there were guidelines that all parts follow a logical numbering and are in the same (or a logical) orientation.

Now, there are exceptions, and a start-up company may favour getting something out of the door as cheaply as possible to be the goal as opposed to a product that had an expected long life etc.

Dave
 
Would a logic analyzer help here? Would that at least tell us what 'code' the CPU is trying to run?
Sure, but it's about 100x overkill for what you're doing. I've got a lot of test gear, including
an array of LAs, and they wouldn't be what I'd reach for first in a case like this.

Though I did recently pick up an old Tek (1230?) that came with a 6502 pod, and in that
series the pods were completely self-contained - no additional software needed - which
is a rarity in that world. It's a real problem that in hunting down uP support for analyzers
it's extremely rare to get the whole package - almost invariably you find the pod on ebay
(or elsewhere) and the docs and software (e.g. target disassembler) are nowhere to be
found.

Btw, anyone who's into that stuff and has any of those support materials is strongly
encouraged to join the logic analyzers group on groups.io where we're archiving and
exchanging it.
 
You are correct in that the -nnn identifier is the ROM mask content. So the fact that someone decided you use U2 for the -002 part and U3 for the -003 part is inspired.

See my edit. Unless someone who was there at the time pops up and says otherwise,
I'd tend to strongly favour "coincidence" rather than "inspired".

However, the concept of laying out the parts on a PCB in a non-logical ordering (when there was plenty of experience available to the contrary) was not sensible.

No, because that's not how it's usually done. You start with the schematic, and there
it's reasonable to use a reasonably numbered component assignment order. But once
the design is passed to layout, different considerations apply and that ordering may
not be maintained. If you have a large/dense board with a really high parts count there's
an argument to be made for reordering to make the PCB layout more rational (at the
schematic's expense), but that isn't always justified.

The same could be said for putting the U2 and U3 parts in the PCB the opposite way around to (say) U1.

You'll get no argument from me on that point - there has to be a REALLY GOOD reason
to start flipping parts around rather than maintaining consistent orientation.
 
This has been along time since this was posted. I've not put any more debug kits together since I made 10 kits and sold them.
...
I don't know if the debug board schematic on this thread is correct ( it has been a long time).

In case anyone is planning to build one of Dwight's debug boards, may I suggest that
you wait few days? I have a couple of KIMs to validate, and when I found his design
package on Hans Otten's site - and saw what a train wreck the apparently-reverse-
engineered schematic was - I redrew it with all of the "assumed stuff" shown. I've
built a board using "artisanal techniques" and will test it shortly. I don't want to let
the drawing out, though, until I've validated it by running the hardware.
 
I'm always confused about which tool is best for which job. Whenever I watch vintage computer repair videos they usually use a scope. However the few I've seen using a logic analyser look much more... er... logical to me, since you can make out the actual data. In one video the software was showing the hexidecimal opcodes and such the CPU was working on, which tells you a lot more about what the thing is actually doing. Unless I'm misunderstanding, which is likely. Why wouldn't that be a typical tool to reach for?
 
I'm always confused about which tool is best for which job. Whenever I watch vintage computer repair videos they usually use a scope. However the few I've seen using a logic analyser look much more... er... logical to me, since you can make out the actual data. In one video the software was showing the hexidecimal opcodes and such the CPU was working on, which tells you a lot more about what the thing is actually doing. Unless I'm misunderstanding, which is likely. Why wouldn't that be a typical tool to reach for?

The scope is almost always your number one go-to tool, because it lets you see
what's going on in real time and in the analog domain, which means you're more
like to spot something amiss - something that just doesn't look right - that's going
to lead you to the source of the problem.

Analyzers are brilliant tools, but they take a lot more setup and (obviously) won't
let you see what's going on in real time. To be more precise, an analyzer lets you
see what happened. I don't know what the youtube vids (and there are about a
million times more bad ones than good - in any field) showed you, but the way it
works is that the analyzer captures data in real time, then stops when it hits a
trigger word, or sequence, or signal, or whatever. Then you get to look back over
the recent history (depending on your acquisition memory depth, resolution, and
other settings) to figure out, cycle by cycle, what led up to the trigger event.
That can be a lot of work, and even more work if you don't have the disassembly
pod or software that turns that big bucket o' hex dump into instructions that you
can derive actual meaning from. Even just hooking up the analyzer to the target
can be a pile of work if you don't have the right pod, CPU clip/interposer. Scope:
One probe you can move around with. Analyzer: Nearly 40 connections to the
target.

So I'm not saying that you shouldn't get an analyzer - they're super to have. But
don't put it ahead of getting a decent scope.
 
Last edited:
Also, regarding the 74125s, I have gone over the truth tables for these and probed them in action. I understand that if the A and C pins are LO, the output will also be LO. If C is LO and A is HI, I get a HI on the output pin. If C is HI, the output is switched off. Through multiple power ups I have seen different situations - all gates operational, or some are turned off on either or both chips. I am assuming, since I've observed the gates fully utilized and conforming with the truth table when they are working, that that would clear the 125s as a potential issue? ie. that the randomness of which gates are operational is just based on what garbage code the CPU tries to execute on power up/reset.

One other note, if I understood the manual correctly, the system should NOT be trying to run code until Reset is pressed, correct? On mine, it is always doing something on power up.
 
The scope is almost always your number one go-to tool, because it lets you see
what's going on in real time and in the analog domain, which means you're more
like to spot something amiss - something that just doesn't look right - that's going
to lead you to the source of the problem.

Analyzers are brilliant tools, but they take a lot more setup and (obviously) won't
let you see what's going on in real time. To be more precise, an analyzer lets you
see what happened. I don't know what the youtube vids (and there are about a
million times more bad ones than good - in any field) showed you, but the way it
works is that the analyzer captures data in real time, then stops when it hits a
trigger word, or sequence, or signal, or whatever. Then you get to look back over
the recent history (depending on your acquistion memory depth, resolution, and
other settings) to figure out, cycle by cycle, what led up to the trigger event.
That can be a lot of work, and even more work if you don't have the disassembly
pod or software that turns that big bucket o' hex dump into instructions that you
can derive actual meaning from. Even just hooking up the analyzer to the target
can be a pile of work if you don't have the right pod, CPU clip/interposer. Scope:
One probe you can move around with. Analyzer: Nearly 40 connections to the
target.

So I'm not saying that you shouldn't get an analyzer - they're super to have. But
don't put it ahead of getting a decent scope.
Thank you for that concise and understandable explanation. That really helps. Yes I was looking at some analysers online and just the physical connection of them seemed tricky, they mostly seem to come with jumper wires that have female ends.. no idea how you 'clip' those onto the relevant leads. Maybe I'd better master the scope first.

Since i have a few days off, I think I'm really going to put some effort into learning how to set this scope up to be useful for what I'm doing. As mentioned it's a rigol 1102e. I wouldn't mind learning how to check some basics like seeing that the clock signal is correct, what's going on with chip enable, etc, and anything else it might tell me in this situation that might be useful. I just don't yet understand how to get it dialed in for what I want to do, or how/why to set triggers certain ways, etc.
 
Thank you for that concise and understandable explanation. That really helps. Yes I was looking at some analysers online and just the physical connection of them seemed tricky, they mostly seem to come with jumper wires that have female ends.. no idea how you 'clip' those onto the relevant leads. Maybe I'd better master the scope first.

Target connections vary. If your target has test headers on the board, you can push those wire
connectors onto them. Or you can push them into EZ-Hook or similar grabbers. Analyzers often
have those "flying leads" assembled into headers in groups of 8 with clock and grounds to speed
target connection. Or a 40p DIP clip you can glom directly onto your CPU.

Since i have a few days off, I think I'm really going to put some effort into learning how to set this scope up to be useful for what I'm doing. As mentioned it's a rigol 1102e. I wouldn't mind learning how to check some basics like seeing that the clock signal is correct, what's going on with chip enable, etc, and anything else it might tell me in this situation that might be useful. I just don't yet understand how to get it dialed in for what I want to do, or how/why to set triggers certain ways, etc.

I haven't played with any of those Rigols, so I don't have an opinion of them - it looks like it's
modeled on the older little Tek "digital phosphor" scopes, and I have one of those, but we've
never really managed to become friends. Being an old fart, I'm hopelessly married to my Tek
465B, though one of these days I'm going to upgrade to the trophy wife of my dreams, a 2465B -
I just can't give up on analog scopes. But I do have an HP DSO and others on my bench.

Put down the logic probe and figure out how to use that thing and you'll never look back.

Btw, I'm just outside Calgary.
 
I agree, the oscilloscope is the best tool to have for exactly the reasons that @circa77 states. The oscilloscope shows you what is going on in the analogue domain.

You start with the basics, power supply, clock and reset circuitry. If any of these are at issue - you HAVE to fix them FIRST before doing anything else. Hence, in your other thread, I have suggested learning at least the basics have how power supplies work and how to use a multimeter and oscilloscope to look at the operation of the unit. It is better than poking around with a multimeter...

Incidentally (to answer one of your questions above) the KIM-1 can start to execute code on a power up. It can also sit there like a dead duck. It can also start at some random location and execute rubbish. This is why you need a 'good' RESET pulse to start off with. On machines without a power-on reset (and there are some out there) the CPU can (basically) just do what it likes UNTIL the human presses the RESET button. Sometimes there is just sufficient capacitance around to make the CPU reset - but it is not an engineering design feature (it is art)...

If everything is actually working 'correctly' but the machine doesn't run - then (on the PET with a socketed 6502) we would introduce a NOP generator and start checking the address bus, address bus buffers and address decoding logic. But of course, if you have a soldered in CPU, that is not really an option.

I am considering using the signal DECEN (on P2/K) by pulling it HIGH with a resistor to disable all of the devices on the KIM-1 (RAM and both 6530's). I am hoping then that we can apply some pull-up and pull-down resistors to the CPU data bus to simulate a NOP instruction. This should (hopefully) get the CPU fully operational so you can use the oscilloscope to check the address and data bus to look for open circuits and (hopefully) short circuits.

If that doesn't work, then the next best thing is to use a logic analyser to look at the instruction stream (and the address) following a reset. We have done this a number of times on faulty Tektronix 4051 and 4052 machines.

One of the problems with logic analysers is that they operate in the digital domain. If you have rubbish signals, then the logic analyser converts them into nice digital edges... I would generally use the oscilloscope and logic analyser together at work - the oscilloscope to look in the analogue domain and the logic analyser to look in the digital domain.

@circa77 - You should be free of moderation now.

Dave
 
Back
Top