• Please review our updated Terms and Rules here

Debugging a KIM-1 computer

Dwight Elvey

Veteran Member
Joined
Jun 21, 2003
Messages
4,991
Location
Santa Cruz
Hi
On a suggestion from another friend, I'm starting a new thread rather than
continuing an older thread started by another.
I've been debugging my KIM-1 and while doing so, hopefully helping others.
What does one do when it doesn't work?
One can check some obvious places like the clock signals, reset pulse,
interrupts and sync signal.
Beyond that there is little that one can do with the monitor code dead.
The problem could be any of the chips, from the simplest 7404 to one
of the RRIOT chips.
I've always said that one should write code and use an EPROM to test the
functions of the board.
Now I'm putting actions to these words.
First one needs to create a place to put an EPROM if there is no socket.
That is what I did for the KIM1. I have created a small board with a minimum
of parts on a prototype board.
Here is the schematic. I will post test in later messages.
It uses a 2764, 7404, 7402 and 7474.
Dwight
 

Attachments

  • Debug (1).jpg
    Debug (1).jpg
    68.5 KB · Views: 10
A little about the circuit.
It is designed to run with a minimal amount of the KIM computer working.
The processor has to be able to execute code and access the data but
and addresses.
The code I've written also expects the KIM's address decoder chip to
be functioning.
In order to work, the debug board uses both connectors for signals.
The expansion connector is mostly used but three signals are needed from
the application connector.
You'll need 2 ea 44 pin connectors.
The board disables the KIM's ROM and takes over boot. One typically
the sets the reset vector to $0C00 and assembles the code there.
( In other words the the reset vector need to be at $0FFC as the EPROM
will be seen at $0FFFC as well as $0FFC, being dual mapped.
In fact the EPROM will also be mirrored at every 1K if A15=1.
This can be useful if KIM's addresses decoder doesn't work.
There are 2 LEDs on the debug board.
One LED is on if it sees a access to the 1K space at $0C00 to $0FFF.
It is not a fool proof indicator but if lit generally indicates that code
is executing.
It can only be reset with the reset signal ( RS on the keyboard ).
The other LED is a status light. It can be turned on and off from
code.
A write to $1000 of the D0=1 will turn it on and a write with D0=0
will turn it off.
It provides a minimal feedback until KIM's 7 segment LEDs are found
to be functional.
It also is needed to verify that the 1K RAM at address 0 is functional.
The RAM is needed to be able to use the stack and any zero page address.
It can also be use to just blink to make sure a long running test is still
working.
I have written two test so far and will publish them soon on the next mail.
With each I'll have source and binary. The source will be in 1K chunks.
This is consistent with the 1K window of address into the KIM's memory.
Using the 2764 and switches, one can have up to 8 diagnostic codes on
one EPROM. One can use a larger EPROM with a few more wires to the switches
for more chunks. The 2764 was just chosen as a minimal size to be useful.
If anyone want to contribute code, that would be fine as well. I do hope it is
an open project. Those with working KIM's can write programs that are to
be run in the RAM space.
These can be tested without the debug board and I can write a simple loader
for those that need to use the debug board to get anything to run.
I already have a simple march test for the 2102 rams so anyone using the
debug board should be able to run in RAM after fixing any bad locations.
Please don't be shy.
I'd like this to be an open project.
Dwight
 
This is the first program. It is a simple program to test if the debug board
can take control of the KIM's operation.
One just powers on and pushes the RS button on the keypad.
If it is working, the light will turn on and off at about 3 second rate.
If not, either there is something loading the bus or the processor
is not functioning.

The source is in a file called FLASH.SEQ. It is a text file. It is written in
my assembler but I expect a clever person should be able to figure it out.
 

Attachments

  • FLASH.ZIP
    1 KB · Views: 2
This next file does a simple march test of the 2102 RAM. It is bigger than one would
expect because it doesn't get to use subroutines. The entire code runs in the
A, X, Y and SP registers
Load it into an empty 1K block of the EPROM. When on the debug board, use the
switches to select that 1K block.
Power up and push the RS.
When released, one of two things will happen.
The status light may come on steady. This would indicate
that 1K bytes of RAM has passed the test and should be ready to
use for subroutines and zero page instruction.
If the status light blinks, count the blinks. there will be 8 of them.
1 second blinks indicate that that bit is OK. A short blink would
indicate that that bit failed.
The blinks start at the LSB or D0 and blink until the MSB or D7.
After 7 blinks it turns the LED off.
One can rerun the test as often as one wants by using the RS button
to reset.
A failed bit indicates that one of the RAMs has failed, the write operation
failed for some reason, the read buffer failed or the read failed for some
reason.
Once the bit position is known, one can easily find the location in the schematic
to match the board.
Dwight
 

Attachments

  • RAMTEST.ZIP
    3.3 KB · Views: 1
It uses a 2764, 7404, 7402 and 7474.

Hi Dwight,
Good work. I had offered to replace the glue parts with a PAL, but you managed to whittle the design down to three glue parts. So replacing three 14 pin parts with a 20 pin PAL is probably not really necessary.

If Falter has not fixed his PROM burner, I can send him an EPROM when the code is finished. I have learned a lot about the KIM-1. I wish a had a KIM-1 to try some of this.
-Dave
 
I've been looking at the replacement of the 6530 with the 6532.
Not an easy task. I wish they'd tried to keep the pins similar. The
only ones that match are the data bus.
I also looked at flipping one end for end and it only made the problem more complicated
because of crossed wires.
There were a couple adapters made for arcade machines but because of addressing,
they were not compatible with the KIM-1.
There was a drawing for a mini-KIM but it has select problems and wouldn't work anyway.
I've made a couple of drawings that I'll post later that I believe solve the problems.
I'm using a M28C64 as a surface mount for the ROM. For the 6532, I have a jumper select
for the -002 and -003. I expect to make a EPROM adapter so that one can use a standard
EPROM programmer to program the EEPROM in place. With another jumper, the adapter
could easily be universal for either -002 and -003, as the 6532 already is.
I've cleaned it up so the glue logic is just a '04. It only uses 3 inverters.
The A4 problem had me stuck for a while but then I released that the addressing after
A4 was just for the RAM. The 6532 has 128 bytes and I only need 64.
I just shift A4 and up from the 6530 to A5 and up on the 6532. It skips chunks of
RAM but still gives the require 64 bytes.
I intend to build at least one adapter. The M28C64 is a surface mount as is my '04.
I can easily hide it in a stack of 4 machine pin sockets so the adapter only grows up,
not out.
Dwight
 
Here are two schematics for the adapter. The first one is mainly the signal
lines and the second mainly the control signals and the EEPROM.
Please take a look at these and see if I missed anything?
I recommend printing it out first.
Dwight
 

Attachments

  • adapt.jpg
    adapt.jpg
    71.4 KB · Views: 5
  • adapt1.jpg
    adapt1.jpg
    89.6 KB · Views: 5
Last edited:
Found an error on the second schematic.
I've fixed the drawing in post #7. It should be correct now.
Dwight
 
Last edited:
I've written the display test but I regret to say that it didn't
work as expected. My -002 chip looks dead. Baaa!
I changed the ports to the -003 chip and ran the code.
It looks to be working there. At least form an oscilloscope, I can see
all the ports wiggling as expected. I see the count on PB and the
strobes on PA.
At least it will do something on the display so I'm releasing it partially
tested.
It should display the numbers and rotate.
I've started work on my 6530 to 6532 adapter and hopefully it will be
ready when the 6532s come in that I ordered.
I should note that although the part I selected was a STmicro part,
for the EEPROM, the Atmel part should work fine.
The part is intended to be a SOIC if someone uses an external 28 pin dip,
you might want to straighten the address out for A8 and A9. I have them
to A9 and A12 for wiring convenience, since the EEPROM is intended to
be programmed in place. The scramble will cause all kinds of issues with
getting the program in the right place. Just a warning.
It shouldn't be an issue for programming in place.
Here is the binary for the debug board and the display test.
Next to write a key pad test but I think it can wait for my adapter and
the 6532.
Dwight
 

Attachments

  • DISPLAY.ZIP
    1.2 KB · Views: 2
Last edited:
I've written the display test but I regret to say that it didn't
work as expected. My -002 chip looks dead. Baaa!

So it turns out you will need adapter #1. Will you build adapter #2 for falter? I have a feeling he will need one too.

How do you intend to program the EEPROM in-place? Will you write a special program for the KIM-1 to transfer file from the audio cassette interface?
-Dave
 
So it turns out you will need adapter #1. Will you build adapter #2 for falter? I have a feeling he will need one too.

How do you intend to program the EEPROM in-place? Will you write a special program for the KIM-1 to transfer file from the audio cassette interface?
-Dave

I'm wiring the adapter point to point with 28 ga. wire. Not something I'd like to do
a second time. I'm willing to make some PC boards but not all the wire work.
By in place, I meant an adapter. I'd make a simple 28 pin adapter for the adapter
to use a regular programmer. Most any EPROM programmer has a 28C64 selection.
Doing it on the KIM would be a little more difficult but could be done. In this case,
the -002 is where the audio I/O is and the -003 is the code. No, audio isn't the way.
It could be done tough. The algorithm for programming these is simple enough.
It might be easier to do it with the serial port. One can create a simple RS232
interface. Even with 232 going away there are USB to 232 adapters that are easy
to find.
The audio method is possible but requires a lot of code working on the KIM to
run.
One can use the debug board. One block on the debug board can load itself into
RAM and then one would select the correct code on the switches for -002 or -003.
I think that would be about the easiest, don't you?
I like that. One needs to make the debug board anyway it can be the loader as
well!
I wonder if anyone has the firmware for the TIM?
Dwight
 
Last edited:
I'm putting out a request to see how many people would be interested
in a KIM repair kit. It would just be a set of bare boards. There is little
to put together so it shouldn't be too much for one to put together.
I expect to have two small boards that would stack under the 6532 and
one for the debug board. If I get enough interest, I'd be looking at $10
to $20 someplace. I know there are a lot of bad KIM-1s out there that
people would love to have working.
Is there any interest?
Dwight
 
Here are two schematics for the adapter. The first one is mainly the signal
lines and the second mainly the control signals and the EEPROM.
Please take a look at these and see if I missed anything?
I recommend printing it out first.
Dwight

Dwight,
I don't see the correct address decoding for RAM and I/O for replacing the two 6530 devices. I think A6 and A7 are decoded internally (mask layer) in the 6530s so you will have to map them with external decoding to form the right enables in the 6532. You are going to need a bit more decoding logic.

Take a look at the decoding necessary within the K5 chip select. All this is done in the mask layer address decoders in the -02 and -03 6530s. Leave it to Commodore to screw things up if one wants to replace 6530s.


K0 $0000 - $03FF 1024 bytes of RAM (8*6102)
K1 $0400 - $07FF free
K2 $0800 - $0BFF free
K3 $0C00 - $0FFF free
K4 $1000 - $13FF free
K5 $1400 - $16FF free
$1700 - $173F I/O, timer of 6530-003
$1740 - $177F I/O, timer of 6530-002
$1780 - $17BF 64 bytes RAM of 6530-003
$17C0 - $17FF 64 bytes RAM of 6530-002
K6 $1800 - $1BFF 1024 bytes ROM of 6530-003
K7 $1C00 - $1FFF 1024 bytes ROM of 6530-002


K0..K7 = output lines from 74145
 
I'm putting out a request to see how many people would be interested
in a KIM repair kit. It would just be a set of bare boards. There is little
to put together so it shouldn't be too much for one to put together.
I expect to have two small boards that would stack under the 6532 and
one for the debug board.

Dwight,
If the 6530 replacement were designed generic enough (which may not be easy due to the mask address decoder), there would be a use for it in other Commodore products besides the KIM-1. For instance, many of the early Commodore floppy disk drives like the model 4020, 4040 and others used 6530 devices which often fail.
-Dave
 
Oops, it is A8 and A9 that may not be decoded. I need
to change my wiring.
I'll confirm that.
Good catch.
Luckily I haven't finished that part of my hand wired adapter.
I'll move the wires and have another diagram.
Dwight
 
Last edited:
Oops, it is A8 and A9 that may not be decoded. I need
to change my wiring.
I'll confirm that.

Hi Dwight,
Yes, A8 and A9 too, but to me it looks like A6 and A7 also determines selection of both the correct 6530 and its I/O function. Very confusing. It seems the KIM-1 used 6530s with different 6530 mask address decoding.

It saved them some glue logic on the KIM-1, but left it a little difficult to replace them with the generic 6532.
-Dave
 
Your right Dave, I don't know how I got that part wrong. At least for my
wired up adapter, I can ignore A8 and A9 but I'll need to keep them for the main
unit.
I'll have to reevaluate what I'll do for decoding there. It may be two chips or
a 16L4 type device.
I need to think about it. As it is now, it is clearly wrong.
Dwight
 
Last edited:
Back
Top