PET 3008 Repair -- next steps

[bozimmerman]

Bo,
I have no idea what the cycling would do, but can you post a screenshot? Do you get a full screen of garbage characters for a second before it turns to half spaces?
-Dave

Yes, there is a full screen of garbage, but it happens for less than a second, and usually while the monitor is doing a vertical sync dance. It's very very easy to miss. I've seen pets that give you a big proud garbage screen to stare at for a second before going to READY. This one zips by so fast it is more like a subliminal message.

After trying a few more cycles to get that picture, it occurred to me that I no longer get the "blank screen except for one garbage character" as I did only the first few times immediately after socketing the new 2114s. Is it possible something is damaging one of the video chips?

- Bo

 

[bozimmerman]

This week I swapped the logic probe I got for a more traditional one. It's easier to use and actually does the things dave_m talked about.

I did lots of poking around, looking for bad pin connections, signals that were stuck high, that sort of thing. Nothing so far, though I'm really sure now that the video memory is fine.

In fact, on one particular Bounce of the machine (maybe the 2nd or 3rd after it having been cold for a few hours) it booted to a happy READY prompt. I'm sure this means something -- some bit of functionality, instead of being Snapped into a broken state, was instead Fading into brokenness. On another few bounces, I got the clear screen with 1 or 2 garbage characters.

I'm determined to poke around randomly, forever, until I have some new guess on what to change.

- Bo

 

[dave_m]

I'm determined to poke around randomly, forever, until I have some new guess on what to change.

When you get a Ready screen, did you get a blinking cursor and did the system allow input from the keyboard?

From the screen shot you posted it looks the problem is close to a 128 byte address boundary. If it was exactly a 128 byte boundary (three screen lines plus 8 characters), I would suspect the upper screen counter chip F2 (4 bit counter), but since it is not quite on a boundary, I suspect the multiplexer part F3 (74LS157) that forms the upper Screen Address lines. See Schematic page 7. Piggy back a LS157 on F3 and look for a difference or look at the lines with a scope.
-Dave

 

[bozimmerman]

When you get a Ready screen, did you get a blinking cursor and did the system allow input from the keyboard?

Yes, for that session, it was fully functional. Weird, right?

From the screen shot you posted it looks the problem is close to a 128 byte address boundary. If it was exactly a 128 byte boundary (three screen lines plus 8 characters), I would suspect the upper screen counter chip F2 (4 bit counter), but since it is not quite on a boundary, I suspect the multiplexer part F3 (74LS157) that forms the upper Screen Address lines. See Schematic page 7. Piggy back a LS157 on F3 and look for a difference or look at the lines with a scope.
-Dave

I did have several spare 157s, so I tried this on ALL the 157s I saw, to no good effect. I ordered backups of most of the PET glue chips, just in case. I have a LOT of PETs, so you never know when they might be needed.

After that, I perused the web and came across this kernal EPROM: http://generalthomas.com/PET/petester.bin

I burnt that into a 2532 and dropped it in, and what do you know: it's perfect! Both the screen test and the memory test come back 100%! If you are unfamiliar with it, the chip cycles between two test screens. The first pokes every value into screen memory, sequentially, 4 times (to fill the screen). The second test screen shows a series of "g" and "b" characters related to the system RAM.

I suspect I should probably focus on the ROMs, then, right? Dammit, I read in every ROM previously and checked them against archives. Perhaps a socket problem?

- Bo

 

[dave_m]

I suspect I should probably focus on the ROMs, then, right? Dammit, I read in every ROM previously and checked them against archives. Perhaps a socket problem?

Bo,
Yes, this would indicate the PET addressing circuits, video RAM and lower RAM are all working. The pet tester code is curtesy of member Eudimorphodon and you found it on my Civil War website where I stashed some PET files. There is a version called pettest2.bin for 8032 machines that need the CRT controller initialized.

I would start with the Editor ROM 901447-29. And yes, it might be a bad solder joint or bad socket.
-Dave

 

[Eudimorphodon]

Yes, this would indicate the PET addressing circuits, video RAM and lower RAM are all working. The pet tester code is curtesy of member Eudimorphodon

Yeah, that's my ugly baby. (The thread in which I unleashed it on the world is on this forum, circa 2011 or so.) Believe me, I'm incredibly flattered every time someone finds it useful. So... a few comments.

1: The RAM test is pretty perfunctory and it's possible it won't detect certain stuck-bit conditions, but...

2: I would definitely check out the ROM sockets and the traces between them. The root cause of most of the problems I found in my old PET repair megathread were bad traces, including a bad trace between two of the ROM sockets.

On the Dynamic board PET most of the pins on the the ROM sockets are wired in parallel; I'd definitely second checking out the EDIT socket; check out the schematic and do a continuity test between every one of the parallel pins between D8 and D9 and the "SEL E" line that terminates on the 74154.

I forget at the moment exactly how many sockets/ROMs need to work to get something besides garbage on the screen. My PET had a bad solder joint at D6 which corrupted the contents of that ROM; "luckily" the CPU would encounter a "BRK" when it hit the bad area and jump to the debugger, which I was able to use to do some memory reads to diagnose the issue. Offhand I forget if the debugger was in the KERNEL ROM or in D7, might be worth looking at a memory map for cheap thrills. (But in either case the EDIT ROM will need to work.)

 

[bozimmerman]

Thanks .. I'll definitely look closer at those ROM connections, especially considering that the petester.bin did not work the very next time I turned on the machine. :/ The screen was full of "N"s and garbage this time.

 

[Eudimorphodon]

Huh... I only quickly skimmed the thread, did anyone mention the reset circuit? At one point I had a bad cap in that which would intermittently let it float and halt the machine. It would cause symptoms like that. Check the state of the reset line to the cpu when it's frozen.

 

[dave_m]

I forget at the moment exactly how many sockets/ROMs need to work to get something besides garbage on the screen.

Eudi,

From a reset, the vector is fetched from $FFFC (low byte) and $FFFD (Hi byte) and loaded into the program counter and execution starts in the kernel D9 ROM ($FXXX). After a few instructions, it jumps to a subroutine in the Editor D8 ROM ($EXXX) to clear the screen, returns to the D9 to check the diagnostic line in the User Port, and if the line is open (pulled up) jumps to a BASIC D7 ROM ($DXXX) to test the RAM and initialize BASIC or if the line has been grounded, to start the Machine Language Monitor also in D7.

 

[Eudimorphodon]

... jumps to a BASIC D7 ROM ($DXXX) to test the RAM and initialize BASIC or if the line has been grounded, to start the Machine Language Monitor also in D7.

Thanks Dave_M; I remember at the time noting it was lucky that the bad socket was far enough down that it let the machine language monitor start up. (It let me use the "M" command to dump sections of the lower ROMs and compare them visually to dumps of the same region done on V.I.C.E.; that made it pretty obvious the culprit was a stuck bit.)

I am serious about that RESET suggestion; when it was malfunctioning it would sometimes let the computer run for an indeterminate amount of time after a power cycle, which produced symptoms like a frozen READY prompt, a screen *half-full* of junk or with PETTESTER, a frozen partial RAM/SCREEN test. There are three capacitors near the 555 timer, a tantalum and two ceramic disks, and of course it was the third one I replaced that resolved it. (One of the ceramics, I forget which.)