• Please review our updated Terms and Rules here

PET 3032 Repair - Pointers Needed

Moonferret

Experienced Member
Joined
Jun 20, 2003
Messages
488
Location
Northwest (UK)
Hi Folks!

Been working on this PET on and off for the past few months but I'm a bit stuck and could do with a few pointers. So far, the following work has been done..

Transistor replaced in the CRT
New 2114 VRAM chips
RAM has been tested OK
Capacitor replaced on the 555 reset circuit
CPU / 6522 checked ok
74LS04 replaced near clock crystal
New set of ROMs burnt
Pettester ROM has been used and runs ok

I've gotten to the point when the machine powers up, you briefly see scrambled characters before the screen is cleared but no BASIC signon message or cursor is displayed. It would seem that its starting ok but is getting stuck after it has cleared the screen. Little unsure how to proceed from here. Possibly an issue with the address lines / decoder?

Cheers,
Dave
 
My 4032 (there was a huge thread ages ago... the one where I wrote the first rudimentary version of PETTESTER, now succeeded by much better ones written by much smarter people than I) had similar symptoms; the PETTESTER would verify the video RAM and first K of memory were all right but it wouldn't make it to BASIC. The difference was in my case instead of just getting stuck on the black screen it would drop to the debugger. Problem turned out to be a broken data line trace.

I'd say check all the lines on your ROM sockets by continuity testing them against D9; they're all wired in parallel to that one except for line 20. (You know socket D9 works because the PETTESTER does.) On mine there was a broken trace between... I think it was D6 and D5? In any case, it was dumb luck that the part of the BASIC ROMs containing the debugger wasn't corrupted allowing the machine to jump to it when it hit an illegal instruction. If you have a break higher up that could explain it wedging at the black screen.
 
Little unsure how to proceed from here. Possibly an issue with the address lines / decoder?

Eudimorphodon has given you an excellent first step in finding the problem. If the problem is not in the ROM wiring, then the next step may be to use a NOP Generator which will continually exercise all addresses in the 64K memory space. With that you should be able to find any addressing problem of open/shorted address line, bad address decoder, etc.

A NOP Generator may be built using two 40 pin sockets to isolate the data bus between the board and the CPU. The upper socket will be jumpered to a fixed pattern of $EA (NOP instruction). The CPU will run forever executing NOPs.

Search 'NOP Generator' and find MikeS' description of the building the socket adapter.
 
Search 'NOP Generator' and find MikeS' description of the building the socket adapter.
For several reasons I prefer to use the 6502 socket instead of one of the EPROM sockets; here's an example (in German, but straightforward, and translates well):

http://home.germany.net/nils.eilers/nopgen.htm

You really only need one socket (unless you want to connect to the 6502 directly - not recommended).
 
Yes, check the sockets and the traces between them. In my experience, problems can occur with these.

Tez
 
Thanks guys. I've checked the data bus & address bus connections between the ROMs and CPU and all seem ok. One thing I have noticed (Wasn't originally like this) is that the address bus & data bus seem to go dead after the screen is cleared. Using a logic probe, its possible to see some activity briefly after the reset but then nothing.

I've also tried swapping over the 6520s and replaced the 6522.
 
Still the same result. After the screen is cleared, the address bus and data bus go high and there is no more activity. I've now replaced all the sockets on the board along with all the 74LS244 chips.

With the pettester ROM installed, it performs fine and I can monitor the address/data bus
 
What types of EPROMs are you using? 2532 for all except for a 2716 in the D8 $E000 Edit ROM socket?

Also note that as Eudimorphodon mentioned, PETTEST does not exercise any ROM space other than a little of the D9 $F000 space. One of the other ROM chip selects may be bad. The NOP Generator will allow you to see pulsing at all the address decoder outputs (chip selects).
 
Hrm.

The one other avenue I could suggest, maybe? I wonder if something could be pulling down and *holding down* the IRQ line? (Even if the 6520 isn't present?) The first thing my old PETTESTER ROM did was disable interrupts; I don't know if the new one does as well, but if it does perhaps that's why it works while BASIC ends up wedged as soon as it enables interrupts? I seem to recall from reading a disassembly/map of the BASIC ROMS that IRQs are disabled when the PET first fires up and aren't enabled until it's written some initialization data into the I/O chips, but... I could be misremembering? It's been a while.

It might be worth hitting the IRQ and NMI lines with an oscilloscope and see if they look stuck or floating.
 
Out of curiosity I did some digging, and according to the first reference I could find the 6502 actually already has the maskable interrupt disabled after a reset. I still don't know what the behavior might be if that line were stuck, but... maybe that could cause a halt like you're describing when BASIC gets to enabling the maskable irq? (I'm sure someone here knows off the top of their head.)
 
6502 KIL Instruction

6502 KIL Instruction

Out of curiosity I did some digging, and according to the first reference I could find the 6502 actually already has the maskable interrupt disabled after a reset. I still don't know what the behavior might be if that line were stuck, but... maybe that could cause a halt like you're describing when BASIC gets to enabling the maskable irq?
Hi Eudi,
No, a stuck Interrupt Request line (IRQ) would cause the program to keep going back to the interrupt handler, but the machine would soldier on (I think an instruction from the main program will be executed between every interrupt).

I think what is happening when all activity stops is that, due to some problem caused by reading a bad ROM or a bad data line, a KIL instruction is read during instruction fetch and the CPU is hung up until a RESET is provided. KIL is an illegal instruction with an opcode of $02,12,22,32,42,52,62,72,92,B2,D2 or F2. Here is a blurb on this issue:

There are many “KIL” opcodes, i.e. opcodes that stop the CPU, so that it can only recover using a RESET, and not even an IRQ or an NMI.

In order to understand this, let’s look at the different states an instruction can be in. After the instruction fetch, the CPU is in cycle T1. It will feed the opcode and the cycle number into the PLA and cause the rest of the CPU to carry out whatever has to be done in this cycle, according to the PLA. Then it will shift the T bitfield left by one, so the T2 line will be “1″, then line T3 and so on. There are seven T lines total, T1 to T7. At the end of each instruction, the PLA causes the T bitfield to reset, so that the next instruction starts with T1=1 again.

But what happens if T does not get reset? This can happen if in all seven states of T, no line fires that actually belongs to an instruction that ends at this cycle. T gets shifted left until state T7, in which another shift left will just shift the 1 bit out of T – all bits of T will be zero then, so no PLA line can fire any more.

All interrupt and NMI requests are always delayed until the current instruction is finished, i.e. until T gets reset. But since T never gets reset, all interrupts and NMIs are effectively disabled.

ref: http://www.pagetable.com/?p=39
 
Last edited:
I think what is happening when all activity stops is that, due to some problem caused by reading a bad ROM or a bad data line, a KIL instruction is read during instruction fetch and the CPU is hung up until a RESET is provided. KIL is an illegal instruction with an opcode of $02,12,22,32,42,52,62,72,92,B2,D2 or F2. Here is a blurb on this issue:

Thanks Dave_m, it's always good to be educated. :) My theory mostly revolved around wondering what might happen if the interrupt line were being held down before the machine were "ready" to take interrupts, but since the ROM doesn't *enable* interrupts until it is indeed ready, well, yeah, scratch that. (Assuming your description of the behavior is right even if it didn't manage to execute *any* of the main program the data/address bus should at least look very busy running the interrupt handler.) I also didn't know about there being "kil" opcodes on the 6502; since what happened in my case was a randomly corrupted ROM caused a hop to the debugger I assumed that most invalid opcodes on the 6502 would translate into a "brk"... which was a silly thing to think, looking back.

I would definitely second that the OP check out the chip select lines for the ROMs and make sure they're doing their thing. After all, only one of them needs to work for PETTESTER to RUN. The other possiblity to look out for: I'm looking at the code and it appears to me that the RAM test in PETTESTER, at least the version I wrote, wouldn't notice if you had a stuck address line leading to the RAM bank. (Seriously, it's not a particularly good test, it has a number of failure modes it won't catch.) A stuck address line 0-11 would potentially break BASIC badly when it started using the zero page and stack. Check the address lines leading to the multiplexers in row E and make sure that they're all complete/cycling, concentrating on BA0-11.

(If I were to sit down and rewrite PETTESTER myself right now I think what I'd do is try to implement a "walking" display of all 255 characters that would write them to RAM, copy them to the display, pause for a moment, and then do it again offsetting by one. That would test every bit pattern in both RAM and VRAM...)
 
I'm looking at the code and it appears to me that the RAM test in PETTESTER, at least the version I wrote, wouldn't notice if you had a stuck address line leading to the RAM bank.

That's a great point. For instance a shorted A15 would cause the CPU to execute instructions in the RAM area which would certainly find a KIL instruction.

Your PETTEST RAM test is the only EPROM based test we have and we are grateful to have it. I only added an initialization routine in PETTEST2 for the 6545 CRTC. You did a great job writing code that did not rely on having any known good RAM.

Some additions I was thinking of is adding memory reads of the SELECT signals (SEL0, SEL1,...SELF) to allow a logic probe to see activity and verify the chip selects are working; adding a BEEP to check the 6522 on the 4000 and 8000 PETs; and sending information out the USER Port in case the CRT is not functioning. Once it was verified that zero page RAM was good, a stack pointer could be set up and routines could be added to perform ROM sum checks, etc.
 
Your PETTEST RAM test is the only EPROM based test we have and we are grateful to have it. I only added an initialization routine in PETTEST2 for the 6545 CRTC. You did a great job writing code that did not rely on having any known good RAM.

I'll tell you, after going years without writing any assembly language software for *any* CPU it was a bit of a trial by fire to code something that didn't need RAM on a CPU with only three registers. ;)

I was working on a fix for the RAM test that would test two bit patterns instead of one before Real Life made me all busy. (Right now it only tests a single 01010101 pattern, obviously it would be informative to test the opposite 10101010 as well.) If I were *clever* it seems that could be used to reveal a stuck address line. If the logic went like this:
Loop 1: Fill the whole 1k block with the first byte.
Loop 2: Test for first byte. If it passes, write the second byte.
Loop 3: Test for the second byte.

The "test, then write" step should catch a stuck address line because the page-duplicating effect of a stuck address line would mean that the test would discover bytes that had been already changed as it worked its way through memory. (And the pattern of bad blocks that would produce on the screen should reveal which line is stuck.) Maybe I should finish banging that out.

EDIT: Hrm. Yeah, actually I have a source file that tests both, but I don't know if it ever went out in the wild. Unfortunately it *doesn't* use the logic I just outlined above so it won't catch an address line mixup. Bah. Why didn't I have this brainstorm earlier? The code should actually be more compact for the one that reveals more.
 
Last edited:
Hi Guys,

Sorry for the lack updates. Had to clear the workbench* for other projects. I've built the NOP generator and so far the address bus & ROM selects seem to be doing their thing correctly. As for the IRQ, nothing unusual there and with the 6522 and 6520s removed, there shouldn't be anything to generate an interrupt request

Cheers,
Dave

* Otherwise known as the kitchen table :)
 
Some additions I was thinking of is adding memory reads of the SELECT signals (SEL0, SEL1,...SELF) to allow a logic probe to see activity and verify the chip selects are working; adding a BEEP to check the 6522 on the 4000 and 8000 PETs; and sending information out the USER Port in case the CRT is not functioning. Once it was verified that zero page RAM was good, a stack pointer could be set up and routines could be added to perform ROM sum checks, etc.
Checksums of the ROMs would also be a nice addition...
 
I've built the NOP generator and so far the address bus & ROM selects seem to be doing their thing correctly.

If the chip selects at the ROM sockets are pulsing, it's starting to look like a bad EPROM. What type of EPROMs have you used and did you perform a VERIFY after programming? Note that you must use a 2716 (2KB) in the $E000 socket without any adapter.
 
Yep, the EPROMs were 2532's + 2716. Verified ok. Also got two original ROM sets, one of which was tested good about 6 months ago. All of them are BASIC 2 so I might try burning a set of BASIC 4 EPROMs just to see if it gets any further.
 
Since you said you verified all the traces/sockets for the ROMs are good (they're connected to the upstream end starting from the socket the PETTESTER goes in, which is why it's possible for it to work while BASIC might not) then... I'm wondering about RAM again. So you hit all the address lines going to the DRAM multiplexers? Is it possible one of them could be bad, perhaps, and inducing "crossed pages" downstream of it?

The beauty of the Static/Dynamic Board PETs is they *really* aren't very picky about anything other than RAM and ROM working. It'll happily boot to BASIC with all the I/O chips pulled out. (Obviously the keyboard, et al won't work, but you'll get a prompt.) I can't imagine BASIC really "hanging" on something (other than perhaps a stuck interrupt, which we ruled out) other than bad RAM if your sockets and address decoding hardware is good.
 
Back
Top