10 May
2023
10 May
'23
10:53 p.m.
Odd fault on my Rev D KIM-1 popped up while writing code this afternoon
(initially I thought I had a bug in my paper tape transmitter) - between $0280
and $029f, the upper 5 bits are stuck at zero. The rest of the address range
seems fine. In particular, $0080-$009f, $0180-$019f and $0380-$039f work correctly.
This doesn't smell like a bad RAM chip to me or I would think there would be a
bad bit throughout the entire 1K, so I suspect this is a data bus problem but
I'm not sure where to start looking. Any guesses from the group?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- require "std_disclaimer.pl"; -----------------------------------------------
11 May
11 May
7:52 a.m.
On 5/11/23 00:53, Cameron Kaiser via cctalk wrote:
Odd fault on my Rev D KIM-1 popped up while writing
code this afternoon
(initially I thought I had a bug in my paper tape transmitter) - between $0280
and $029f, the upper 5 bits are stuck at zero. The rest of the address range
seems fine. In particular, $0080-$009f, $0180-$019f and $0380-$039f work correctly.
This doesn't smell like a bad RAM chip to me or I would think there would be a
bad bit throughout the entire 1K, so I suspect this is a data bus problem but
I'm not sure where to start looking. Any guesses from the group?
Maybe an I/O device is sending on the bus when it should not
be. Are there any devices that have a register range of
XX80 to XX9F?
That probably needs the XX to be something like FF for
proper operation, but if the gate that decodes that part of
the address has failed, this might be what you would see.
Jon
8:59 a.m.
Odd fault on
my Rev D KIM-1 popped up while writing code this afternoon
(initially I thought I had a bug in my paper tape transmitter) - between $0280
and $029f, the upper 5 bits are stuck at zero. The rest of the address range
seems fine. In particular, $0080-$009f, $0180-$019f and $0380-$039f work
correctly.
This doesn't smell like a bad RAM chip to me or I would think there would be a
bad bit throughout the entire 1K, so I suspect this is a data bus problem but
I'm not sure where to start looking. Any guesses from the group?
Maybe an I/O device is sending on the bus when it should not be. Are there any
devices that have a register range of XX80 to XX9F?
7:41 p.m.
I thought about this, but the KIM is a pretty simple
system. The only memory
mapped device in that range (really, on the entire unit) are the RIOTs, and
their RAM at $1780 is fine and does not echo.
The KIM only does address decoding for 8K and echoes the rest, so the same
fault is mapped at $2280, $4280, etc. I would think this would still suggest
data is the problem.
I suppose I could randomly replace the RAM and see what changes but again it
seems weird to have a fault so neatly aligned and only in a specific range.
With a simple step through program,
*=$0000
r=$0280
inc w
lda w
sta $f9
sta r
sta r+1
lda r
sta $fb
lda r+1
sta $fa
jsr $1f1f
jsr $1f6a
cmp #$12
bne *-8
jsr $1f1f
jsr $1f6a
cmp #$15
bne *-5
jmp $0000
w .byt 0
it's actually an artifact of the monitor that the upper 6 were clear. Actually,
the stuck bit is entirely bit 2 (i.e., it goes
0 1 2 3 4 5 6 7 8 9 a b c d e f
0 1 2 3 0 1 2 3 8 9 a b 8 9 a b
and the high nybble is OK). Now that sounds more like a bad RAM chip, but why
would it be *just* those addresses? Does that sound like a plausible failure mode?
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- God made the integers; all else is the work of Man. -- Kronecker -----------
10:47 p.m.
On 2023-May-11, at 7:41 PM, Cameron Kaiser via cctalk wrote:
it's actually an artifact of the monitor that the
upper 6 were clear. Actually,
the stuck bit is entirely bit 2 (i.e., it goes
0 1 2 3 4 5 6 7 8 9 a b c d e f
0 1 2 3 0 1 2 3 8 9 a b 8 9 a b
and the high nybble is OK). Now that sounds more like a bad RAM chip, but why
would it be *just* those addresses? Does that sound like a plausible failure mode?
So I take it the KIM1 uses 6102 1K*1 RAM chips.
(I'm seeing some modern redrawings, but is there no original schematic online?)
Any RAM chip internally has the bits organized in a matrix.
I haven't found a proper 6102 datasheet, but the most likely array size is obviously
32 * 32.
Your bad address range of xx80::xx9F is a span of 32 on base-32 boundaries.
So a failed internal driver or sense-amp for one row or column of one chip would produce
your fault.
That's a pretty plausible failure mode.
Don't know how much luck you'll have finding a 6102.
Cursorily it looks like it's just a CMOS version of the 2102, and pin-compatible, so
that might be an alternative.
The 2102 comes in low-power flavors (often but not always called 21L02).
It also comes in various speeds so you might have to watch that, something like a 21L02-3
might do.
12 May
12 May
5:05 a.m.
On May 11, 2023, at 10:41 PM, Cameron Kaiser via
cctalk <cctalk(a)classiccmp.org> wrote:
Yes, if they are small RAM chips. For example, in a 1k DRAM chip (and perhaps in slightly
larger sizes too) the row size could be 32, which means that the failure of one row on one
RAM chip would cause the failure of an aligned 32 byte range.
paul
I thought about this, but the KIM is a pretty
simple system. The only memory
mapped device in that range (really, on the entire unit) are the RIOTs, and
their RAM at $1780 is fine and does not echo.
The KIM only does address decoding for 8K and echoes the rest, so the same
fault is mapped at $2280, $4280, etc. I would think this would still suggest
data is the problem.
I suppose I could randomly replace the RAM and see what changes but again it
seems weird to have a fault so neatly aligned and only in a specific range.
...
and the high nybble is OK). Now that sounds more like a bad RAM chip, but why
would it be *just* those addresses? Does that sound like a plausible failure mode?
8:17 a.m.
Thanks for the suggestions, everyone. This board has NEC D2102AL-4 SRAMs on it,
so I ordered a couple MM2102AN-4s which look equivalent. I'll swap one in when
it arrives and see if that's the problem.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- I don't like losing anyways. -- Usain Bolt ---------------------------------
8:46 a.m.
On 5/11/23 21:41, Cameron Kaiser via cctalk wrote:
If the failure affects the EPROM monitor,then any results
you get from the monitor are suspect.
And, the c,d showing as 8,9 also fits the pattern of bad
locations reported earlier!
Jon
I thought
about this, but the KIM is a pretty simple system. The only memory
mapped device in that range (really, on the entire unit) are the RIOTs, and
their RAM at $1780 is fine and does not echo.
The KIM only does address decoding for 8K and echoes the rest, so the same
fault is mapped at $2280, $4280, etc. I would think this would still suggest
data is the problem.
I suppose I could randomly replace the RAM and see what changes but again it
seems weird to have a fault so neatly aligned and only in a specific range.
With a simple step through program,
*=$0000
r=$0280
inc w
lda w
sta $f9
sta r
sta r+1
lda r
sta $fb
lda r+1
sta $fa
jsr $1f1f
jsr $1f6a
cmp #$12
bne *-8
jsr $1f1f
jsr $1f6a
cmp #$15
bne *-5
jmp $0000
w .byt 0
it's actually an artifact of the monitor that the upper 6 were clear. Actually,
the stuck bit is entirely bit 2 (i.e., it goes
0 1 2 3 4 5 6 7 8 9 a b c d e f
0 1 2 3 0 1 2 3 8 9 a b 8 9 a b
and the high nybble is OK). Now that sounds more like a bad RAM chip, but why
would it be *just* those addresses? Does that sound like a plausible failure mode?
8:51 a.m.
If the failure affects the EPROM monitor,then any
results you get from the
monitor are suspect.
No, what I mean is, the appearance of the upper six bits being dead was because
of how the monitor shifts in data from the keypad. Since bit 2 was always zero,
it would look like everything above it was zero too because the bit shifts
carried the error forward. A direct brute-force step through showed the actual
issue and I should have just done that in the first place. The monitor works
properly everywhere else outside of those locations, including from the TTY.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- Ninety-nine percent of lawyers give the rest a bad name. -------------------
13 May
13 May
2:48 p.m.
It is unlikely that a 6 bits in a byte will fail, caused by a RAM, since each RAM chip is
only one bit, not a byte.
It is more likely that one of the ROM chips is being doubly decoded. Since these are
decoded as 1 K blocks, it is likely a problem with the address block decoder, the
74LS145.
Just my guess.
Dwight
________________________________
From: Cameron Kaiser via cctalk <cctalk(a)classiccmp.org>
Sent: Friday, May 12, 2023 8:51 AM
To: Jon Elson via cctalk <cctalk(a)classiccmp.org>
Cc: Cameron Kaiser <spectre(a)floodgap.com>
Subject: [cctalk] Re: KIM-1 stuck bits from $280 to $29f
If the failure affects the EPROM monitor,then any
results you get from the
monitor are suspect.
No, what I mean is, the appearance of the upper six bits being dead was because
of how the monitor shifts in data from the keypad. Since bit 2 was always zero,
it would look like everything above it was zero too because the bit shifts
carried the error forward. A direct brute-force step through showed the actual
issue and I should have just done that in the first place. The monitor works
properly everywhere else outside of those locations, including from the TTY.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com<http://www.floodgap.com> *
ckaiser(a)floodgap.com
-- Ninety-nine percent of lawyers give the rest a bad name. -------------------
585
days inactive
587
days old
9 comments
5 participants
participants (5)
-
Brent Hilpert -
Cameron Kaiser -
dwight -
Jon Elson -
Paul Koning