Cbm 2001 Pet strange boot

[daver2]

This is the problem with the complexity of the code within the 'full' set of Commodore BASIC ROMs...

Dave

 

[Hugo Holden]

Hugo, the CPU was incorrectly executing in low RAM when it got the break instruction. In Message # 773 the M/L Monitor output shows the Program Counter at address $02C3. The other registers including the Stack Pointer seem OK. That area of RAM holds system parameters and probably has a lot of zeros.
But as to why it was executing in RAM??
-dave_m

Good observation, I guess the PC got sent there (vectored away as Daver2 described it). To get there though it could mean that the program code in the BASIC firmware is intermittently corrupting due to bad ROM's Or the firmware is ok, and something in the hardware corrupted the acquisition of the program code by the CPU, such as something interfering with the data bus, or improper ROM selection, sending the PC to low RAM memory where it acquired 00 there. Could there be defective DRAM in the stack area I wonder.

Although Dave_C78 says he doesn't think it is a ROM problem, because the fault happened with the Pettester, it was not proven by any stretch that the cause of the Pettester locking up is exactly the same fault that makes the PC fly away to the wrong address (the equivalent of the blue screen) it is likely, but as we have seen there can be multiple faults on the one board.

When it comes down to it, it has to be resolved approximately where the fault is. Is it in ROM as bad or intermittent code ? DRAM as corrupted data, seems less likely but what about the stack ? or the support hardware as a faulty/intermittent logic IC. Or worse the hardware interconnects, tracks & soldering ?

The only way I can think to solve it, is to eliminate the ROMs and firmware first with a set of known good ones. If necessary replace all the DRAM IC's with sockets and return to the computer only known good/tested DRAM IC's. Then wait to see if the fault reappears and then try to track it down with the scope, looking for things like borderline logic levels, glitches in the power supply etc.

One thing I found in my PET while testing it, which surprised me, is that it has a sensitive data bus DA0...DA7. What I mean by this is that occasionally attaching a scope probe to it (which only puts a signal glitch into it equivalent of asking it to charge a 10pF capacitor) occasionally this causes a lockup, by corrupting the the data. This means that it wouldn't take much of an abnormality in the IC's sharing this bus to corrupt it. Or even a poor quality power supply.

 

[Desperado]

I burned UD9.bin pettester on TMS2532JL eprom and i removed all other roms...
Pettester froze at this point and restarted from the beginning...

 

[Hugo Holden]

I'm not familiar with the Pettester program enough to interpret what this means. Daver2 , Dave_m & Nivag would know. It might mean there is faulty DRAM or not, or possibly another fault that stopped the program executing.

As I mentioned, we don't know 100% for sure that this is the same fault that causes BASIC to fail and the PC to vector to low RAM. If it was bad DRAM in the stack area in the case of BASIC failing, in theory that should not cause the Pettester to lock up, unless the program code in the pettester used the stack and relied on that part of DRAM working, but that would be unlikely, when its task is to check the entire DRAM for defects.

 

[Desperado]

I'm not familiar with the Pettester program enough to interpret what this means. Daver2 , Dave_m & Nivag would know. It might mean there is faulty DRAM or not, or possibly another fault that stopped the program executing.

As I mentioned, we don't know 100% for sure that this is the same fault that causes BASIC to fail and the PC to vector to low RAM. If it was bad DRAM in the stack area in the case of BASIC failing, in theory that should not cause the Pettester to lock up, unless the program code in the pettester used the stack and relied on that part of DRAM working, but that would be unlikely, when its task is to check the entire DRAM for defects.

Maybe bad ram buffers sir Holden???

 

[ajgriff]

In short there seem to be three possible options in terms of eliminating DRAMs and ROMs from the equation:

1. Hugo's blanket ROM and RAM replacement approach with the desoldering/soldering risks assocociated with socketing RAM chips.

2. Dave's methodical approach which might not succeed because of the apparent number of variables involved.

3. Buy a ROMulan RAMulator as discussed several times earlier in the thread.

As a very satisfied user of the ROMulan RAMulator, option three is my favourite. It has the advantage of being capable of helping with future PETs as well.

Alan

 

[daver2]

I was ‘hoping’ that Eudi’s original PETTESTER was going to get burnt into the 2532 EPROM, not mine or Nivag’s.

The problem with my PETTESTER is that the page 0/1 test is fairly “quick and dirty”. It can PASS, only to cause problems later on. This may be what you are experiencing...

The PETTESTER (at the ROM checksum and MARCH-C level) is using the hardware stack to store subroutine return addresses. A DRAM fault could send the CPU to anywhere...

This is why I am trying to improve my initial page 0/1 RAM test in Version 5. Unfortunately, to do anything ‘real’ with the 6502 CPU, you have to use Page 0 in some way, shape or form.

This is why I am recommending that Eudi’s original code is used in UD9 - because it uses no RAM at all and, therefore, shouldn’t be able to escape from the ROM. No Page 0/1 RAM is used and no subroutines. The only thing it does do is to store characters onto the screen and read/write from/to page 0/1 RAM. I suppose (technically) that this means that DRAM is written to / read from - but it is not used to store ‘critical data’ (such as subroutine return addresses).

We could simplify the code even more if we wanted to...

Dave

 

[Hugo Holden]

In short there seem to be three possible options in terms of eliminating DRAMs and ROMs from the equation:

1. Hugo's blanket ROM and RAM replacement approach with the desoldering/soldering risks assocociated with socketing RAM chips.

2. Dave's methodical approach which might not succeed because of the apparent number of variables involved.

3. Buy a ROMulan RAMulator as discussed several times earlier in the thread.

As a very satisfied user of the ROMulan RAMulator, option three is my favourite. It has the advantage of being capable of helping with future PETs as well.

Alan

I assume that the Romulan-Ramulator works by only using the RAM it carries itself and not any of the PET's DRAM to run its code ? If that is the case it does seem to be the ideal tool to find his fault and I agree with 3. But from what Daver2 said Eudi's UD9 tester should work.

My thinking overall, based on probabilities is that there is a faulty DRAM IC. One reason is, at least in my experience, these IC's are much less reliable than ROM's or 74LS TTL logic IC's . Usually, even in a batch of new ones, one or two don't work and nearly every board I have had (in other computers) with DRAM on it, has had 1 or two that have failed. In addition it would be good to have the DRAM in sockets in case of later failure, but as you mentioned there are risks to the pcb tracks and pads which are inversely proportional to the de-soldering skills and experience of the operator and to the quality of the equipment they have.

 

[ajgriff]

Yes the board has its own selectable (or not) RAM and user configurable ROM images. Dave's PETTester V4 and VOSSI utilities are built-in. There are a couple of similar boards available elsewhere but I've no experience of using them. Cost and availability are also factors to be considered of course.

Alan

 

[Hugo Holden]

Yes the board has its own selectable (or not) RAM and user configurable ROM images. Dave's PETTester V4 and VOSSI utilities are built-in. There are a couple of similar boards available elsewhere but I've no experience of using them. Cost and availability are also factors to be considered of course.

Alan

I was wondering, even with a Romulating Ramulator, what if the CPU received an IRQ, say from the keyboard or I/O device elsewhere, perhaps malfunctioning, and saved the existing PC address in DRAM, later when it returned from the interrupt service routine, it could malfunction if the DRAM data storing the address was defective, sending the PC to no man's land ? Can the Romulan Ramulator prevent an event like that ? I guess it could if it disabled the IRQ which I guess it would, but if it did, wouldn't that disable the keyboard ?

Apparently an "internal clock" update can activate the interrupt , but I have not figured out yet, how & where that is.

 

[daver2]

Yes - if you map the RAM and/or ROM internally.

The IRQ vector is stored in the top of the Kernel ROM ($Fxxx) along with the NMI and RESET vectors. A 'misbehaving' Kernel ROM could cause a random crash if the vector become corrupt. Map the Kernal ROM internally and the problem should go away.

Likewise for any return address stored on the hardware stack (in the range $0100 to $01FF). If page 0 ($0000 to $00FF) and page 1 - hardware stack - ($0100 to $01FF) is mapped internally, this should also be avoided.

Dave

 

[Desperado]

Yes - if you map the RAM and/or ROM internally.

The IRQ vector is stored in the top of the Kernel ROM ($Fxxx) along with the NMI and RESET vectors. A 'misbehaving' Kernel ROM could cause a random crash if the vector become corrupt. Map the Kernal ROM internally and the problem should go away.

Likewise for any return address stored on the hardware stack (in the range $0100 to $01FF). If page 0 ($0000 to $00FF) and page 1 - hardware stack - ($0100 to $01FF) is mapped internally, this should also be avoided.

Dave

Maybe time to change every ram ics???

 

[daver2]

It won't fix your problem...

Eudi's PETTESTER ROM won't run in UD9 - that tells me there is a high priority that the DRAM has nothing to do with your problem (unless there is some other interaction via the power rails or some other mechanism that I haven't thought about.

Dave

 

[Desperado]

It won't fix your problem...

Eudi's PETTESTER ROM won't run in UD9 - that tells me there is a high priority that the DRAM has nothing to do with your problem (unless there is some other interaction via the power rails or some other mechanism that I haven't thought about.

Dave

Can i change ram buffers???

 

[Hugo Holden]

It won't fix your problem...

Eudi's PETTESTER ROM won't run in UD9 - that tells me there is a high priority that the DRAM has nothing to do with your problem (unless there is some other interaction via the power rails or some other mechanism that I haven't thought about.

Dave

I think it is worth as we mentioned before , re-checking all the power supply rails on the scope for noise, not just for DC level on the meter.

So Dave_C78, attach the scope to the power supply rails, with the two channel scope you can check two at a time, connect the scope earth clip to the main ground , negative of the large 4700uF electrolytic on the pcb works. First check the DC level, then switch the scope to AC coupling and wind up the scope gain to inspect the noise transients. Have the scope back on DC coupling again to monitor their levels, especially the two 5V supplies at the time of the fault. Sometimes voltage regulator IC's can go into oscillation if the capacitors around them are degraded.

It is awkward that the 4116's are not in sockets, because by now you could have swapped them out and at least excluded them from the investigation, but as Daver2 says, they are probably ok.


Daver2 ... Since say with a keyboard interrupt the CPU will go to the IRQ vector in the Kernal ROM, where does Eudi's Tester ROM send it after that ? I would think it would still, like the original ROM, go to page 0 or page 1 to store the current PC address so it could return from the interrupt later ? If this were true then bad DRAM could still cause the fault. But I don't know exactly what the Eudi ROM does with the interrupt, to avoid using the DRAM, would it have to have some other RAM to store the return address ? Maybe the only way to fully test the DRAM, especially page 0 & page 1, is to have some additional RAM, I wonder if hijacking some of the 2114 video RAM could work without upsetting the Apple Cart even if it corrupted the screen display. Adding a RAM IC to a spare ROM socket might work if it was hardware adapted to be able to write to as well using the R/W control line.

 

[Hugo Holden]

Maybe bad ram buffers sir Holden???

I'm not sure about this, I guess anything is possible, but the buffer IC's are probably, on average, more reliable than the actual DRAM IC's. Though it would not hurt to scope the signals around them and make sure there are no anomalous logic levels especially on the R/W control lines.

 

[Hugo Holden]

Dave_c78, don't un-solder any of the 4116 DRAM's yet. I am working on an idea to try to determine definitely, one way or the other, if the page 0 and page 1 memory locations looked after by the DRAM are defective, or not.

It just might take a day or three to see if the idea works.

 

[Desperado]

Dave_c78, don't un-solder any of the 4116 DRAM's yet. I am working on an idea to try to determine definitely, one way or the other, if the page 0 and page 1 memory locations looked after by the DRAM are defective, or not.

It just might take a day or three to see if the idea works.

Ok thank you very much Hugo

 

[daver2]

>>> Daver2 ... Since say with a keyboard interrupt the CPU will go to the IRQ vector in the Kernal ROM, where does Eudi's Tester ROM send it after that ? I would think it would still, like the original ROM, go to page 0 or page 1 to store the current PC address so it could return from the interrupt later ? If this were true then bad DRAM could still cause the fault. But I don't know exactly what the Eudi ROM does with the interrupt, to avoid using the DRAM, would it have to have some other RAM to store the return address ? Maybe the only way to fully test the DRAM, especially page 0 & page 1, is to have some additional RAM, I wonder if hijacking some of the 2114 video RAM could work without upsetting the Apple Cart even if it corrupted the screen display. Adding a RAM IC to a spare ROM socket might work if it was hardware adapted to be able to write to as well using the R/W control line.

On a power-up / RESET condition, all devices that could generate a maskable interrupt (i.e. the PIAs and VIA) inhibit their interrupt generation. The interrupt line is an 'open collector' signal pulled up to +5V via a resistor. This is wired to the maskable interrupt line of the 6502 CPU (/IRQ). On a power-up / RESET condition, the 6502 CPU sets the I (interrupt disable) bit in the status register. As a result, any /IRQ will be ignored anyway.

Just to make doubly-sure, Eudi's code and the Kernel ROM code (that executes before my PETTESTER code) invokes the SEI (set interrupt disable flag) instruction.

As a result, (a) nothing should generate a maskable interrupt and (b) if anything did, it shouldn't be responded to by the 6502 CPU.

The non-maskable interrupt (/NMI) is another question altogether. This pin is pulled high (via a resistor) on the PET and is not used (unless someone has modified the PET or has an add-on that uses it). These will cause all of the PETTESTERs to fail, as the NMI will be vectored 'somewhere'...

The same is true of the BRK (break) instruction ($00). This actually invokes the IRQ vector (but sets the 'B' bit in the status register to distinguish it from a hardware interrupt). In this case, the Commodore PET ROMs will invoke TIM (the machine code monitor) - but the PETTESTERs will crash.

I did think about adding some sort of support for IRQ and NMI vectors to trap them. Again, the problem is that different variants of the Commodore Kernal ROMs invoke the EDIT ROM at different addresses - and this is a pain to support all variants of initialise, NMI and IRQ vectors...

Dave

 

[Hugo Holden]

Ok thank you very much Hugo

It may take me a while, with the test I was thinking of.

But I think the best thing you can do right now, is lift one leg of resistors, R41 and R42 and cross connect them (cross them over) So that the selection of /CAS0 and /CAS1 are swapped. This electrically switches(swaps) the two 8 IC banks of 4116 DRAMs. So if the page 0 and page 1 DRAM locations are faulty in one bank, probably they will unlikely be in the other bank of 8 DRAM chips.

After this, soak test the PET
with Eudi's tester or with the usual BASIC ROM set back in, and see if the problem returns, or has gone away.

If the problem is gone, you could then run Daver2's PETTESTER (in UD8) and see if it can find the defective DRAM, now located in the high order 4116 RAM bank.


I was also thinking that one aspect of the fault, where the CPU jumps away to the wrong address, is that it doesn't happen right away and is intermittent.

Unlike static RAMs, the DRAMs lose their memory if they are not constantly refreshed. From what I can see with the 4116 this is mainly achieved by strobing the /RAS0 control line from the output of the 74LS08 G1 in the PET. It could be worth checking that gate's output and the /Q outputs of both the 74S74 flip flops that drive that gate. One of those flip flops, H1 pin 4, has its preset input , pin 4, and data input pin 2, tied to the /INIT line. The init line can assume a borderline logic level if there is a copy UF10 ROM in place.

What ROM do you have in place for UF10, is it the original MOS Rom, or a copy ? A copy (a 2716 ) can affect the /INIT line.