Image Map Image Map
Page 1 of 4 1234 LastLast
Results 1 to 10 of 40

Thread: Debugging a KIM-1 computer

  1. #1

    Default Debugging a KIM-1 computer

    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
    Attached Images Attached Images

  2. #2

    Default

    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

  3. #3

    Default

    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.
    Attached Files Attached Files

  4. #4

    Default

    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
    Attached Files Attached Files

  5. #5
    Join Date
    Feb 2009
    Location
    Southern California, USA
    Posts
    2,774

    Default

    Quote Originally Posted by Dwight Elvey View Post
    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

  6. #6

    Default

    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

  7. #7

    Default

    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
    Attached Images Attached Images
    Last edited by Dwight Elvey; November 11th, 2016 at 09:22 PM.

  8. #8

    Default

    Found an error on the second schematic.
    I've fixed the drawing in post #7. It should be correct now.
    Dwight
    Last edited by Dwight Elvey; November 11th, 2016 at 09:23 PM.

  9. #9

    Default

    Dwight,

    It may be time for me to dust off the old KIM-1. Thanks for doing this project.
    Current Wish List: 1. IBM 7531 Industrial Series PC 2. NEC MultiSync XL (JC-2001) Monitor 3. MicroSolutions MatchPoint AND/OR UniDOS card 4. Compaq 14" VGA CRT Monitor (the one that came with the SystemPro). 5. Stacker HW CoProcessor Board MCA BUS. If you have any of the above for sale please PM me. Thank you!

  10. #10

    Default

    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
    Attached Files Attached Files
    Last edited by Dwight Elvey; November 12th, 2016 at 05:29 PM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •