Image Map Image Map
Page 9 of 13 FirstFirst ... 5678910111213 LastLast
Results 81 to 90 of 128

Thread: Imsai 8080 cannot examine to RAM adress...

  1. #81


    I am NOT reading random data. I only see FFs on the data lines at the CPU, and the 8212 and at both 8216's
    Addressing does work, when using examine next or deposit next, addresses increment correctly.
    I just tried depositing using C0 but still no change. Both buffers still show FFs.
    I looked at DIEN (not) on both 8216's (B8,B9) both are low, and DBIN on the CPU is high.
    Just checked out A2 and A3 using probe, good MPU and Bad MPU have same signals on all pins.

  2. #82


    Earlier, you said you were reading random values. I guess it was not what I meant. FF is not random. When you do a write the data has to go onto the cpu side of the buffers.
    I'll try to describe the actions.
    First, when you load enter an address, the front panel board writes a JUMP instruction to the CPU over the cable ( not through the bus ). It then sequences the two address bytes of the cable. All of the other operations, the CPU is doing a NOP instruction. Any data transferred to the data bus has to go through that same cable, either, writing or reading. The CPU increment the address for each operation because that is all it knows to do.
    The front panel sees the address that the CPU wrote to the address lines on the S100 bus but anything to do with address is controlled by the CPU, not the front panel. When there is any increment, it is just the CPU doing a NOP instruction.
    To write or read data, the CPU is held waiting for an instruction until the write or read completes. What we don't know is, that was the data not written to the s100 buss or was the data not being read from the data bus. We can't tell from the front panel which was which because we don't directly see the data bus. We only see what is on the CPU's data lines. When nothing is happening the lines go high from the pullup resistors and the bus drivers are suppose to be in the input mode to the CPU to overdrive the pullup resistors if the data bus has a 0. When an operation, like incrementing the address, the signals from the front panel have to momentarily isolate the S100 data bus and force the data signal on the cable to zero for the CPU to read as an instruction. When done, it is suppose to go back to having the bus buffer go back to reading the S100 data bus. This action of sending the NOP happens really fast. You will not see the actions of doing the bus transfers, on a meter, because they will be really quick. So, the actual write of the S100 bus does not involve the CPU, other than the static address driven to the S100 bus. The display that you see as a static signal should be the value on the S100 bus, driven through the buffers. The buffers need to be turned around to do the write. This happens really fast so the static levels of the DBIN and DIEN are not part of the write. The DBIN has to change momentarily to transfer the switch data to the bus.
    It is possible that we are not seeing the data S100 data bus but just seeing the pullup resistors. At this point we need to do an experiment to see what is happening with the bus data. With the memory board removed, we should be able to drive the data in and see the result when we look at the data lights at any memory location. You can drive, low, any of the DI pins of the S100 bus and see that value immediately on the data LEDs. You can do this with a wire to ground a DI pin. This will tell us if the bus buffer is working. Since the DIEN and the DBIN are the same as the working CPU we should see it work.
    You didn't mention the CS pin of the bus buffers. Please check it? It should be low when you are doing nothing as we should be seeing the DI signals to the front panel data LEDs. It should only go high when we are sending a NOP or a JUMP+Address for the CPU to execute.
    Anyway run that experiment first and then we can go from there.

  3. #83


    This one is be very difficult, to figure out. Here is a snapshot of one of the data pins, when I have the system in Run mode. It looks like it tries to go low, but it does seems to get pulled right back up.
    I check the CS lines, they looked good.


  4. #84


    I applied a jumper wire on pin 50 (GND) and another jumper wire on pin 42 (DI2) it did drive the bit 2 low.


  5. #85


    I don't know, it doesn't look that bad. I don't even know what instructions are being run and which source is driving the bus. I other words, it is not useful information. Also, is the little 1 arrow on the left 0 volts? If so, it looks fine but adds little to understanding what is wrong. Did you run the experiment that I asked for and what were the results? It is important to diagnosing the problem.
    You did a static check of the other signals, DIEN and DBIN and gave back a report of low and high. What is the level of the CS pin ( not running ). The words, looked good are not High or Low. I'm on the other end of the line. I have no idea what good means to you. And, I need to know if the data lights follows the pulling the DI S100 bus pins to low.

  6. #86


    Just uploaded the Jumper test a few minutes ago. Did you see that one? CS were both low, in wait mode.
    Last edited by Novell2NT; February 22nd, 2020 at 06:18 PM.

  7. #87


    So, the problem is not the read, it is the write. I'll look at the schematic tomorrow morning. I've got some resting to do. We'll do some more test then.

  8. #88


    8216 buffer - CS(NOT) stays low all the time. DIEN (NOT) only seems to go High, when I hit Reset. However, that is the same as on my good MPU board.

  9. #89


    Quote Originally Posted by Novell2NT View Post
    8216 buffer - CS(NOT) stays low all the time. DIEN (NOT) only seems to go High, when I hit Reset. However, that is the same as on my good MPU board.
    DIEN* can be driven by two sources. One is from the 8080 processor from its WR* signal. The other is from the front panel. Remember what I said about the processor, it only does two things, JUMP and NOP. Neither of these things is a write. That means the front panel must control all the operations of a write. It does this by two things. One is the MWRITE signal to the bus that goes to the RAM. The other is the SSWDSB* signal. The SSWDSB* signal need to get to the DIEN* signal of the bus buffers. The MWRITE signal shouldn't be an issue as it is only controlled by the front panel board and PWR* from the processor. It is possible that there is a constant PWR* but that can be checked by measuring PWR* on the bus, pin 77. It normally should be high since the CPU doesn't stop in the write state. That can be checked with a static meter.
    If that is bad, it is in the B4 or B3 broken.
    The more likely error is the front panel control of DIEN* is broken some place. This is A2 or A3 ( as I said earlier as likely failure points ). To get A2 pin 6 to go high, for a write, pin 5 must go low. It can go low from two sources. The one you see from reset is from the A2 pin 4 path. The write is done on the A2 pin 5 path.
    It sounds like either there is a broken trace from A2 Pin 5 to bus pin 53 or A2 is not working correctly. As I'd stated earlier, A2 and A3 are the most likely sources of not being able to do the write and read to the bus. We confirmed that we can do a read with the pulling DI bus pin low. That means our failure is the write.
    Last edited by Dwight Elvey; February 23rd, 2020 at 08:54 AM.

  10. #90


    MWRT pin 68 - STAYs LOW ALWAYS. Both MPU Boards. Even though this stays Low, the Good MPU board deposits correctly. The Bad MPU does not.
    SSWDSB pin 53 - STAYs HIGH. Both MPU Boards. This should always stay High.
    PWR - pin 77 - STAYs HIGH both MPU Boards

    A2 pin 5, comes from SSWDSB and stays HIGH ALWAYS, both Boards. The SSWDSB would disable the input buffers, so we do not want it to go Low.
    A2 pin 4, comes from A3 pin 4 - Only goes Low during Reset, otherwise is STAYs HIGH

    The only time that I saw SSWDSB or MWRITE or PWR or A2 pin 4, do anything else, is when I had the A9 Front Panel cable removed.

    I would really like to see some kind of write or read signal appear on the S100 bus or the MPU, when I do an Examine Next or a Deposit Next.


Posting Permissions

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