KIM-1 memory issues?

[snuci]

Hi All,

I have Dwight Elvey's KIM-1 debug board and I have a Rev D KIM-1 that passed the CPU test but fails on the memory test. Oddly enough, the memory test pattern is short-long-short-long-short-long-short-long where "short" is a bad RAM chip and "long is a good RAM chip. I can replace the four RAM chips and retry but I am wondering if it may be a different IC?

Other tests complete with issues so I want to fix this first and move on.

ANy help is much appreciated.

 

[glitch]

I found the dead SRAM in my current KIM-1 with the big logic analyzer, I was able to observe the bad bit after a stack push/pop.

I forget, does the rev D board use two 2114s instead of eight 2102-equivalents? (I know some of the later revs do) If so, then it'd make sense that a single bad RAM chip would result in "four" dead RAM chips.

The data out of the SRAMs is buffered, at least on the 2102 version, and there *are* two 4-element packages responsible for that. I'm not familiar with the operation of Dwight's board (I remember it being discussed), but if the beep pattern indicates which RAM is bad in succession, then a defective buffer wouldn't make sense. I guess it's possible that something else is trying to drive the data bus too, and causing a conflict, which looks like bad RAM? Or it's four dead 2102-type SRAMs. I've had a bunch fail in various equipment.

 

[snuci]

The Rev D uses 8 x 2102-4's. From the docs, it uses two 74LS145 to buffer the memory but the U13 buffer does U5, U6, U7 and U8 memory while the U14 buffer does U9, U10, U11 and U12. If any one of those groups read bad, I would definitely blame the buffer but it's U5,U7,U9 and U11 with short blinks.

Can one piggyback 2102s to check them?

 

[glitch]

Can one piggyback 2102s to check them?

Not really, though I don't advise piggybacking any RAM as a diagnostic tool anyway. I'd wait for Dwight or someone who's really familiar with his diagnostic tool to reply, if you have no other way of checking things out.

 

[Dwight Elvey]

Hi
The test has no idea of the cause of the failure, it only responds to not being able to write and read a value into the RAM. It is clearly suspicious that something other than the RAM is at fault, showing alternating RAMS failing. The code does depend on the operation of the processor and that there is no other loads on the data buss that would block the write or read of the locations.
The fact that alternating RAMS are failing is actually an indication that all of the RAMs are indicating a failure. Since the code must run without depending on the RAM, the test is restricted to indicating the first failed pattern. Since the pattern uses a 55h and AAh. It would cause just such a pattern of alternating bits passing and failing if the read were a constant value. The likely components are the are not the RAMs themselves. It is likely some other element of the system.
Since it seems to be running the code of the EPROM, I'd suspect that it is not the diagnostic board at fault.
The first suspect might be the address decoder clip. I need to look at the diagram to see what we can look at as possible sources of the problem.
I'll get back as soon as I've had some time to examine the possible sources of the problem.
Dwight

 

[Dwight Elvey]

There are a number of possible failure points. The first is actually the diagnostic board. In order to boot, it takes over the boot operation. It does this by bringing the "Decode Enable" line high. This is one of the wires that goes from the debug board to pin K of the Application Connector. This disables U4 on the KIM, by pulling pin 12 of U4 high. The debug board is suppose to boot and then allow the debug board to run at an address as is decoded by U4. It does this by a write to the debug board that trips a flip flop on the debug board. ( I'll need to check which chip this is ). The code should then be executing from an address decoded by U4. I'm not sure if the code will still seem to work if U4 fails to take over the address. I'll need to examine the code to see if it could do so. So the first possibility is that the Debug board is not bringing U4-12 low to allow it to decode on board addresses. This includes the RAM.
The other possibility is that U4 is failing to enable the RAMs that run on the address bank K0.
I'm not sure what type of test gear you have? This would make a difference as to what we might do next.
Dwight

 

[Dwight Elvey]

Ok, I was looking at the code it may be able to run at FC00. This would be with either a dead U4 or a failure of the debug board to bring U4-12 to zero. I have to dig up the schematics and look to see how the release circuit works but I recall it used a 74LS74. The reset pin would cause it to go to one state and a read of the address would cause it to change state, bringing U4-12 to 0.
The code is dual mapped. Still the Error light routine is executed with a jump to 0D00h. I don't know how it could get there if the code continued to run at FC00h. It should reach the point that is would reach the error condition and then attempt to jump to 0D00h from some place between 0C00h and 0D00h. if it were trying to continue to run at FC00h the processor's addresses would go to 0D00h and then just execute until it reached FC00h again where it would just loop back to 0D00h without executing the error routine.
At least that is my thinking.
Now that I've convinced myself that the debug board could not run the error routine without U4 decoding K3 ( 0C00-0FFF ), lets look at what else might be the problem.
I'm looking at the schematic:

http://www.classiccmp.org/cini/pdf/Rockwell/Rockwell KIM-1.pdf

It shows that U15 and U16 are needed for the RAM to be working. Some of the stages of U16 are need to create the two phases of clock 2. The debug board also needs these two clocks. U15 is not needed for the debug board.
So, without using a scope or logic probe, I would put the possible likely failure points, in desending order as:
U15
U16
U4
one of U13 or U14 enable pins stuck high
one of the RAMs holding the R/W or CS*
The 6502 addressing ( not to likely as it seems to be working )

A logic probe or scope could look at these to see what was more likely. Remember that when you reach a failing point it is not easy to determine if it is a failing output or a failing input that is holding a line in a particular state. Usually it is the driving side but it still could be a stuck input.
Dwight

 

[snuci]

Hi Dwight,

Thanks for the reply. It is definitely not the debug board. It works great on two other KIM-1s.

The first CPU test works. I have it socketed and tried an extra just in case. I also get failures on any subsequent test. Originally this KIM-1 had a switch and some wires that I removed. It did not work properly with the switch but it did work better but not properly either. I think I will do some deep inspection of traces to see if any were cut first. I'll then take a look at what you suggest later tonight. Thanks again.

Santo

 

[Dwight Elvey]

Hi Dwight,

Thanks for the reply. It is definitely not the debug board. It works great on two other KIM-1s.

The first CPU test works. I have it socketed and tried an extra just in case. I also get failures on any subsequent test. Originally this KIM-1 had a switch and some wires that I removed. It did not work properly with the switch but it did work better but not properly either. I think I will do some deep inspection of traces to see if any were cut first. I'll then take a look at what you suggest later tonight. Thanks again.

Santo

After the first two test, the later test require working RAM. The 6502 is almost a lump of silicon without zero page RAM. When I first started, I didn't think I'd be able to make the RAM test work without some RAM. The test uses all of the CPU's registers, including the stack pointer for holding data.
Follow the R/W path from processor to RAM as well as the K0 path from the address decoder.
Dwight

 

[snuci]

Hi Dwight.

I found a missing trace! It was between pin1 of U4 and pin 1 of U16. I couldn't see it until I desoldered the 7404 and replaced it and noticed some discoloration where the trace used to be.I checked against another KIM-1 and sure enough, it was missing. The memory test now displays 2 long, 1 short, 4 long.

I am a bit confused if memory at U9 is bad or everything else is bad BUT U9.

DBINSTR.TXT says short is bad as noted, "A 1 second blink indicates a good bit and a short blink indicates a failed bit."
RAMTEST.SEQ says short is good as noted, "A short blink means that bit is good. A long blink indicated that bit bad. The long blink is about 1 second. The short one is clearly short."

One of them is right and I am inclined to think that RAMTEST.SEQ is right if it's the code.

Can you clarify? I did the display test and it failed the first time but then worked a second time so we are getting somewhere, I think.

 

[snuci]

I am a bit confused if memory at U9 is bad or everything else is bad BUT U9.

I took a shot at it being one bad RAM and presto, fully working KIM-1! I do have one segment display not lighting up but I can replace that later.

It's really good to know you can't get past the memory test/repair before checking the other items. I was worried that it was in REALLY bad shape. This one is not i the greatest conditon and went through some hard labor in it's lifetime.

Now I have one more that doesn't power up (Rev E). When I press RESET the Access light goes out. I'll try to figure that one out myself first.

Thanks again Dwight!

 

[Dwight Elvey]

Hi Dwight.

I found a missing trace! It was between pin1 of U4 and pin 1 of U16. I couldn't see it until I desoldered the 7404 and replaced it and noticed some discoloration where the trace used to be.I checked against another KIM-1 and sure enough, it was missing. The memory test now displays 2 long, 1 short, 4 long.

I am a bit confused if memory at U9 is bad or everything else is bad BUT U9.

DBINSTR.TXT says short is bad as noted, "A 1 second blink indicates a good bit and a short blink indicates a failed bit."
RAMTEST.SEQ says short is good as noted, "A short blink means that bit is good. A long blink indicated that bit bad. The long blink is about 1 second. The short one is clearly short."

One of them is right and I am inclined to think that RAMTEST.SEQ is right if it's the code.

Can you clarify? I did the display test and it failed the first time but then worked a second time so we are getting somewhere, I think.

I believe the TXT file is correct. I recall checking it several times to make sure I got it right in the instructions. The text in the SEQ file is just a comment. It is more likely to be wrong. It may have been the original intention but, when looking at the result, I'd changed the code without fixing the comment. At least that is my guess.
You can short the Dout of U7 to ground and see what it does. You should see it fail two instead of just one. Use care to not use +5V instead of ground or you'll be fixing 2 RAMs.
It is possible that they cut the trace to use a larger off board RAM. The fact that it is failing a RAM bit now may have been just that the part is old. The 2102s were always failing.
Dwight

 

[Dwight Elvey]

Your total blinks are 7 instead of 8. Could you have missed one?
Dwight

 

[snuci]

Your total blinks are 7 instead of 8. Could you have missed one?
Dwight

You are right. I missed entering one in my description. Two long, one short, five long for a total of 8.

One question. What switches should I set to bypass the debug board and just use it for power only? While I have it connected, I use it for just normal power.

 

[Dwight Elvey]

I think it is stated in the documents but I forget? It still has K3 decode the EPROM on the debug board. That is always hard wired. There should be a note two places that you can run a couple games. With these you boot the KIM's monitor and enter the address of the game located on the debug board EPROM. These do not boot to the debug board so in a sense, these are what you want. It is just that the debug board is still wired to K3 that is unused in the memory map any way. From one of these, you can run anything that would normally run on a KIM-1 or even load from a cassette.
Dwight

 

[Dwight Elvey]

I took a shot at it being one bad RAM and presto, fully working KIM-1! I do have one segment display not lighting up but I can replace that later.

It's really good to know you can't get past the memory test/repair before checking the other items. I was worried that it was in REALLY bad shape. This one is not i the greatest conditon and went through some hard labor in it's lifetime.

Now I have one more that doesn't power up (Rev E). When I press RESET the Access light goes out. I'll try to figure that one out myself first.

Thanks again Dwight!

It is either the CPU has failed, it is getting a constant interrupt or something is loading an address or data line.
Good hunting.
Dwight

 

[snuci]

Thanks for the posts. Seems kind of simple now that you point out how to run the KIM-1 normally with the debug board. I should have put 2 + 2 together.

As for the bad KIM-1, I tried replacing the CPU already. No luck. I'll keep at it. I do have a scope so I may have to break that out and compare a working KIM-1 against the bad one.

 

[Dwight Elvey]

Thanks for the posts. Seems kind of simple now that you point out how to run the KIM-1 normally with the debug board. I should have put 2 + 2 together.

As for the bad KIM-1, I tried replacing the CPU already. No luck. I'll keep at it. I do have a scope so I may have to break that out and compare a working KIM-1 against the bad one.

Don't forget to check for a clock. Just run around the pins on the cpu and look for something unusual.
Dwight