PET 8032 - No Chirp, No Cursor

[daver2]

I assume there is still no activity on the processors /IRQ signal then?

Dave

 

[KevinO]

Gee how we love inconsistent results! Is there something I should do to try to determine what is causing this diag line to be pulled low? A bad PIA does NOT cause it, but a good one does! I can recheck my soldering on the PIA socket, just to make sure.

 

[KevinO]

My bad...my page had not refreshed, so I hadn't seen the in between response. Dave, Pin 4 /IRQ is high on CPU. Since that line of reasoning had me completely confused, I went another route. I went ahead and burned the PETTESTER ROM and popped it in. Interesting behavior. Still using the RAM/ROM replacement board, If I leave the 8032's RAM switched out, I get a battery of tests that run. ROMs seem to all test good. RAM tests good, of course, because it's testing the RAM on the replacement board. But if I switch the 8032's RAM back in, I get only the static screen below, with nothing changing. I'm looking through the manual, trying to understand what I'm seeing, but I'm not there yet. Heading to bed for tonight, and I will tackle it again tomorrow.

 

[daver2]

First off, DIAG is wired to UB12 pin 9 (PA7) and it is also wired to the sounder logic. I wonder if both problems are connected?

Anyhow, measure the logic level of UB12 pin 9. It should be HIGH.

Secondly, I would suggest fitting a reset button (a normally open pushbutton) between pins 1 and 2 of UD16 (the reset NE555 timer). Power up the PET, start video recording the screen and press/release the reset button. The video will capture the tests as they run. Unfortunately, the delay between tests is fairly short in version 4 of my firmware. It is much longer in version 5. The first test should output all of the video characters to the screen and read them back. Check on the video that they all look correct. The test firmware verifies that it can correctly readback the values that were written - but that is still no indication that they all appear correctly. I don't think you will have a problem - but it always pays to check.

The RAM test that is failing attempts to write $00 into address $0000, $01 into address $0001, ..., $FF into address $00FF and then reads the value back. It repeats this test for page 1 ($00 to address $0100, ..., $FF to address $01FF). A 'good' test is represented by a 'g' character. A 'bad' test is represented by a 'b' character. The 'bad' character that was read is then displayed instead of a '.'.

What this tells be is that the only memory cell in page 0 ($0000 to $00FF) that is working is address $0000. All of the other addresses ($0001 to $00FF) all return $00 (character '@'). In page 1 ($0100 to $01FF) the only memory cell that is working is address $0101. All other addresses return $01 (character 'a'). Let me think about how this pattern could be manifest...

With the Tynemouth card simulating the RAM - I am assuming my test program is identifying the ROM checksums correctly. What happens if you press the keyboard keys (one at a time) when the ROM checksums are being displayed? You should observe a single '1' bit being set in the KEYBOARD keymap on the test screen.

Dave

 

[KevinO]

First off, DIAG is wired to UB12 pin 9 (PA7) and it is also wired to the sounder logic. I wonder if both problems are connected?

Anyhow, measure the logic level of UB12 pin 9. It should be HIGH.

Dave, thank you for your continued help! Yes, UB12 pin 9 is HIGH.

Secondly, I would suggest fitting a reset button (a normally open pushbutton) between pins 1 and 2 of UD16 (the reset NE555 timer). Power up the PET, start video recording the screen and press/release the reset button. The video will capture the tests as they run. Unfortunately, the delay between tests is fairly short in version 4 of my firmware. It is much longer in version 5. The first test should output all of the video characters to the screen and read them back. Check on the video that they all look correct. The test firmware verifies that it can correctly readback the values that were written - but that is still no indication that they all appear correctly. I don't think you will have a problem - but it always pays to check.

Reset button is wired up. If the Tynemouth board is simulating both RAM and ROM, it goes directly to the monitor (shown previously), as in the photo below.


NOTE: I believe I made a mistake in what I reported last night in Post #23. The static screen I reported was when I removed the Tynemouth board and put the stock CPU back in place. I wonder why that should be different?

With the Tynemouth board back in place, and I switch the 8032's ROMS back in, the option ROM runs. I took a short video and I see the following 4 screens, captured from the video.









The KBD should be all 00's, right? And keypresses make no change.

Was that a coherent response?

Kevin

The RAM test that is failing attempts to write $00 into address $0000, $01 into address $0001, ..., $FF into address $00FF and then reads the value back. It repeats this test for page 1 ($00 to address $0100, ..., $FF to address $01FF). A 'good' test is represented by a 'g' character. A 'bad' test is represented by a 'b' character. The 'bad' character that was read is then displayed instead of a '.'.

What this tells be is that the only memory cell in page 0 ($0000 to $00FF) that is working is address $0000. All of the other addresses ($0001 to $00FF) all return $00 (character '@'). In page 1 ($0100 to $01FF) the only memory cell that is working is address $0101. All other addresses return $01 (character 'a'). Let me think about how this pattern could be manifest...

With the Tynemouth card simulating the RAM - I am assuming my test program is identifying the ROM checksums correctly. What happens if you press the keyboard keys (one at a time) when the ROM checksums are being displayed? You should observe a single '1' bit being set in the KEYBOARD keymap on the test screen.

Dave

 

[daver2]

The VDU test looks good.

The RAM and ROM tests look good. The ROMs are obviously BASIC 4 (as they should be). We can't test the EDIT ROM of course - as my PETTESTER is in its place. Again, this issue will (hopefully) be fixed in version 5 by plugging the EDIT ROM into one of the 'spare' ROM sockets.

There is definitely something wrong with either the UB12 PIA, the UB12 socket/soldering or something decoding the address for UB12.

Yes, you are correct, the kbd byte values should all be 00.

Just out of interest, can you disconnect the keyboard cable from the main logic board - just to rule out a complete keyboard failure... A long shot...

Dave

 

[KevinO]

Thanks Dave.

Removing the keyboard connector makes no difference. Still all FF's.

That PIA works fine in my good 8032, so it almost has to be something with the socket, which I installed. I'm usually pretty confident of my soldering, but I certainly could have made a mistake. I'll start tracing all that out next. That will have to be tomorrow. That's all I had time for today.

 

[Hugo Holden]

Thanks Dave.

Removing the keyboard connector makes no difference. Still all FF's.

That PIA works fine in my good 8032, so it almost has to be something with the socket, which I installed. I'm usually pretty confident of my soldering, but I certainly could have made a mistake. I'll start tracing all that out next. That will have to be tomorrow. That's all I had time for today.

Apart from defective soldering, it is always possible that the socket itself is damaged and has lost spring tension on one or more of its pins and has a defective connection.

It is interesting that the missing cursor effect is also caused by the keyboard PIA IC being absent from its socket. Since your PIA IC is ok in your other computer, but not in this one, perhaps it is not being powered properly and acting like its "not there". So the best thing to do initially is to check the power supply & ground pins on the actual IC body, with the meter.

 

[dave_m]

It is interesting that the missing cursor effect is also caused by the keyboard PIA IC being absent from its socket.

You are correct, this PIA chip is initialized to generate an interrupt request (/IRQ) on pin 37 when it sees a high transition on its CB1 input (pin 18). The interrupt handler routine then scans the keyboard and blinks the cursor among other tasks.

 

[KevinO]

Apart from defective soldering, it is always possible that the socket itself is damaged and has lost spring tension on one or more of its pins and has a defective connection.

It is interesting that the missing cursor effect is also caused by the keyboard PIA IC being absent from its socket. Since your PIA IC is ok in your other computer, but not in this one, perhaps it is not being powered properly and acting like its "not there". So the best thing to do initially is to check the power supply & ground pins on the actual IC body, with the meter.

Ok, so I checked the input power on UB12 pins 1 and 20, measured directly on the IC, and I get a perfect 5.03v.

Last night and this morning I traced every line of UB12 with an ohmmeter, and made sure that I had zero ohms continuity from each pin to the next accessible endpoint. (what I mean by this is that I didn't trace out every fork in the road, so to speak, but just from UB12 to whatever pin on the next most obvious IC on the schematic). Everything checks ok.

Aware that I could still have 2 pins shorted, I removed the brand new socket at UB12 that I had just replaced a couple days ago, and replaced it AGAIN with another brand new socket. Here's a photo just for fun, in defense of my soldering skills. Not that anybody questioned my soldering, but we work with all skill levels here, and you can't help but wonder if someone's not using an old 100w Radio Shack soldering gun to do IC work!

 

[Hugo Holden]

One problem, soldering IC sockets, is that sometimes the sockets can be old and have been in storage. The surface of the pins to be soldered have oxidized. Initially at least they were bright Tin plated in most cases, to help 60:40 tin-lead solder flow onto them. It requires higher temperatures and a very good quality flux in the solder to break down the oxides on the pin's surface properly, depending on the age. But also you don't want to apply too much heat for too long to the pcb tracks & holes.

Once an IC has been removed from a pcb, the cleared holes are already solder coated, so on the application of new solder it flows quickly and immediately into the hole even at relatively low soldering temperatures.

When fitting new sockets (or through hole components for that matter), especially if they have been in storage require a technique to make sure the socket pin (or component wire) gets a proper coating of solder, before the solder flows into the hole around the pin or wire.

When the pin is not properly coated with solder, there is a surface tension like effect, and voids form in the solder around the pin or wire, seen as small holes and dimples appear around the pin, which I think I can see on your photo.

The way to avoid this and create a good bond to the pin, is to heat the pin with the soldering iron tip only on one face of the pin's flat faces initially and apply the solder to the heated socket pin projecting above the pcb hole on its opposite flat face to where the iron is applied. Good quality solder too like Ersin multicore or Loctite equivalent in the USA. Unfortunately there are some terrible cloned solders out there, and whatever you do avoid Lead free solder.

When the coat has adhered to the pin, then more solder is applied and it then easily passes down into the hole.

In other words the soldering iron's tip must heat the pin directly on the opposite side of the pin to where the solder is applied.

The contour of the solder around the pin & hole, if all is good, adopts the form of a join I labelled in the photo as good.

(it is one of those old soldering rules; "heat the work with the iron and apply solder to the work not the iron's tip, don't apply the solder to the iron's tip directly".......except at times to help keep it clean and coated with solder.

Often though, this problem is never seen with new sockets and pcb assembly with bright shiny new IC socket pins and component wires that are very easy to coat with solder , even at low range temperatures, so the placement of the iron's tip onto the pin first is not as critical and the solder flows rapidly onto the pin & into the hole. It is all about the condition of the tin plated surfaces or the components wire surfaces, before the soldering is done.

Your pins probably are all connected though if you have sounded them out with a meter and it is sometimes difficult inspecting soldering from a photo, so what I am seeing on your photo could be shadow artifacts or residual flux, so I could be wrong that some of it looks a little suspect.

 

[KevinO]

Ok, now THIS is interesting. There's NO 02 clock signal on Pin 25 UB12 or UB15. It goes into Pin 1 of UD15 from the CPU, but doesn't come out. I have dozens of different TTL chips here. Do you think I'd have a 7417? Of course not! Gonna have to order. I'd hate to pull one from a working machine.

 

[Hugo Holden]

Ok, now THIS is interesting. There's NO 02 clock signal on Pin 25 UB12 or UB15. It goes into Pin 1 of UD15 from the CPU, but doesn't come out. I have dozens of different TTL chips here. Do you think I'd have a 7417? Of course not! Gonna have to order. I'd hate to pull one from a working machine.

I don't have the schematic handy, but there is a small trap to fall into when examining TTL's IC's with open collector outputs, like the 7417 and deciding if they might be defective. There will appear to be no output, if the pullup system (often a resistor but sometimes it can be another IC's input pin current) on the output of the buffer has failed. So if the output is sitting low, it is always worth stringing the output via a 1k resistor or similar to +5v, to see if the buffer is actually working.

 

[KevinO]

I don't have the schematic handy, but there is a small trap to fall into when examining TTL's IC's with open collector outputs, like the 7417 and deciding if they might be defective. There will appear to be no output, if the pullup system (often a resistor but sometimes it can be another IC's input pin current) on the output of the buffer has failed. So if the output is sitting low, it is always worth stringing the output via a 1k resistor or similar to +5v, to see if the buffer is actually working.

Understood. In fact, I think I learned that at the beginning of this very project about the behavior of open collector outputs. Anyway, the Pullup is good, but there's no signal at the output.

So I substituted a 7407, which looks like it should work, and for the first time ever I have a cursor and the keyboard works! That's WITH the Tynemouth board installed and the RAM switched in. Looking like I've definitely still got bad RAM.

 

[Hugo Holden]

Understood. In fact, I think I learned that at the beginning of this very project about the behavior of open collector outputs. Anyway, the Pullup is good, but there's no signal at the output.

So I substituted a 7407, which looks like it should work, and for the first time ever I have a cursor and the keyboard works! That's WITH the Tynemouth board installed and the RAM switched in. Looking like I've definitely still got bad RAM.

Great progress !

 

[KevinO]

Great progress !

Thanks. Couldn't do these repairs without you folks. I have basic troubleshooting skills, but talking to people who know what the various circuits should be doing and when is invaluable.

Next, I will have to start replacing RAM.

Oh, and I still have no chirp. I could use some help figuring out what generates that signal.

 

[KevinO]

Update...fixed the chirp! 6522 at UB15 was bad! Wow, we're really stacking up the bad chips here. BOTH 8520s, the EDIT ROM, UB15, and the 7417 UD15 (replaced with a 7407 and seems to be working fine). Next....RAM. But not tonight.

 

[Hugo Holden]

I made a system to check the dynamic RAMs in the Dynamic PET. The ROM plugs into a spare socket and a "hardware Adapter" dynamically disables the lower 1k or 2k of Dram and substitutes in SRAM.

The ROM program (in the article) might be of some use as it has three programs operating in the high cassette buffer area (moved there from a 4th ROM program), that are useful for diagnosing individual defective DRAM IC's, they write checkerboard patterns and any any value byte you want to the whole memory from 0400h to 7FFFh in the 32k PET.. Though it was intended to help when the DRAMs are soldered in, so that only defective ones end up getting un-soldered. Though you can just do it with POKEs & PEEKs, but it is better to check nearly all the memory.

One thing (though I'm not sure about this for your PET model's RAM setup) since all of the DRAM's are only 1 bit (in the case of my PET at least) every one of them contributes to the Byte value. If one IC in the lower 16k is defective (non responsive or output stuck) the computer cannot boot and a black screen results. If one of the IC's in the upper bank is defective, in the case of being non responsive the computer will boot and report half the expected RAM amount, or if the output is stuck it inhibits the IC in the same column in the lower bank and again it won't boot.

By inspecting the values of the returned bytes (provided another memory is supporting the OS) it is fairly easy to figure out which particular DRAM IC's are defective.

www.worldphaco.com/uploads/DRAM%20MEMORY%20TEST%20SYSTEM%20FOR%20THE%20DYNAMIC%20PET%20COMPUTER.pdf

 

[daver2]

See what happens when I go to bed!

Have you run my PETTESTER DRAM test program - this runs after the counter counts down to zero.

Dave

 

[KevinO]

I made a system to check the dynamic RAMs in the Dynamic PET. The ROM plugs into a spare socket and a "hardware Adapter" dynamically disables the lower 1k or 2k of Dram and substitutes in SRAM.

The ROM program (in the article) might be of some use as it has three programs operating in the high cassette buffer area (moved there from a 4th ROM program), that are useful for diagnosing individual defective DRAM IC's, they write checkerboard patterns and any any value byte you want to the whole memory from 0400h to 7FFFh in the 32k PET.. Though it was intended to help when the DRAMs are soldered in, so that only defective ones end up getting un-soldered. Though you can just do it with POKEs & PEEKs, but it is better to check nearly all the memory.

One thing (though I'm not sure about this for your PET model's RAM setup) since all of the DRAM's are only 1 bit (in the case of my PET at least) every one of them contributes to the Byte value. If one IC in the lower 16k is defective (non responsive or output stuck) the computer cannot boot and a black screen results. If one of the IC's in the upper bank is defective, in the case of being non responsive the computer will boot and report half the expected RAM amount, or if the output is stuck it inhibits the IC in the same column in the lower bank and again it won't boot.

By inspecting the values of the returned bytes (provided another memory is supporting the OS) it is fairly easy to figure out which particular DRAM IC's are defective.

www.worldphaco.com/uploads/DRAM%20MEMORY%20TEST%20SYSTEM%20FOR%20THE%20DYNAMIC%20PET%20COMPUTER.pdf

Interesting. I'll have to read up on this. I have to imagine I've got RAM bad in the lower 16K. Which IS the lower 16K anyway? I'm not even sure. I'm sure the information is out there somewhere, but I don't know it offhand.