• Please review our updated Terms and Rules here

CBM PET 710 WITH BASIC PROBLEMS

So, the CPU pin 3 pulsing indicates that it is alive (halleluiah)!

But it is not executing code out of any of our expected EPROMs.

So, check U31 pins 7, 9, 10, 11, 12, 13, 14 and 15 and look for activity. This should tell us what the CPU is executing and (more importantly) from where.

However, if the CPU has vectored off to somewhere - there is no guarantee that it will do the same thing the next time you press the reset button!

This is the nature of this type of fault.

Dave
 
daver2 said:
So, check U31 pins 7, 9, 10, 11, 12, 13, 14 and 15 and look for activity. This should tell us what the CPU is executing and (more importantly) from where.
Click to expand...
I always have to take these measurements when A0 pulsates, right?

You have a p.m Dave
 
daver2 said:
That implies to me that the CPU is executing something, but not what we are expecting.
Click to expand...

Yes. If the pulsing on the kernel ROM's /G disappears that means the CPU, whatever it's doing, is now no longer in the address range E000-EFFF. *If* it were executing the code on the NOP ROM it would never leave this range once it was finished with RESET.

Perhaps it would be worth moving the oscilloscope trigger from the kernel EPROM's /G to the CPU's PHI1 input clock; if you're iffy about clamping a pin directly on the CPU it looks like you can get it from U57 pin 4. This will give you a heartbeat for looking at the various signals that's not dependent on decode...

Desperado said:
U31:
Click to expand...

Forgive me, I'm blind, apparently . Where/what part is U31?
 
Can you check U31 pins 4, 5 and 6 in this mode please.

U31 may not actually be enabled (hence all of the output signals will be HIGH).

Dave
 
Desperado said:
74s138n ic
Click to expand...

Oh, the master decode page.


daver2 said:
U31 may not actually be enabled (hence all of the output signals will be HIGH).
Click to expand...

If all of U31's outputs are high maybe the next thing to look at would be U25 pins 6, 12, 11, 10, and 9. If *any* of them are low my money is on pin 12.

daver2 said:
However, if the CPU has vectored off to somewhere - there is no guarantee that it will do the same thing the next time you press the reset button!
Click to expand...

I'm kind of wondering if we look in the address lines we're going to find it constantly banging away in the $01xx range. That's were it would be constantly detouring if it were stuck in a BRK loop. Maybe when we're seeing the pulsing it's the CPU getting further into reset before crashing (IE, executing the phantom "push it to the stack" portion of reset), and then going hog wild bouncing around there.
 
Hmm,

Can I ask you to post ALL of the pins on U31 please.

Something is not making sense. Post #590 implies that at least one output should be present from U31...

Dave
 
Now pin 5 is HIGH - thus disabling U31...

This situation is no good either...

After you report something, are you then 'fiddling' about with the machine - thus disturbing both it and our testing?

Dave
 
daver2 said:
Now pin 5 is HIGH - thus disabling U31...

This situation is no good either...

After you report something, are you then 'fiddling' about with the machine - thus disturbing both it and our testing?

Dave
Click to expand...
I'm not doing anything..it probably changes state every now and then.. :(
 
Just checking...

So, it is almost as though the machine is just lurching about...

See if you can see any activity on the output pins of U31 after you poke RESET.

Put the probe on each U31 output and poke RESET a few times to see if there is any activity.

The output pins are defined in post #586.

This is the 'suck it and see' methodology...

Dave
 
daver2 said:
Just checking...

So, it is almost as though the machine is just lurching about...

See if you can see any activity on the output pins of U31 after you poke RESET.

Put the probe on each U31 output and poke RESET a few times to see if there is any activity.

The output pins are defined in post #586.

This is the 'suck it and see' methodology...

Dave
Click to expand...
Now U31 pin 7 is pulsing....
 
daver2 said:
Now pin 5 is HIGH - thus disabling U31...
Click to expand...

So far as I can tell the only "normal" way for pin on U31 pin 5 to go high is if the mapping register controlling P0-3 on the CPU gets set to a page other than 15. (there is apparently another conditional based on the state of reset? That part of the circuitry for /SYSIOGEN is confusing.) According to the datasheet the bottom 4 bits of $00 and $01 should always be ones until/unless something changes them with a write to those addresses. *If* that were to happen then presumably the CPU is rampaging around DRAM (or an empty unmapped page) instead of where the I/O and memory are.

If you see pin 5 high again you could measure P0 - P3 on the CPU to see what they're reading to ensure that's why it's high, but that won't explain how it ended up in that state. Again, there's nothing on the NOP EPROM that would tell it to do this. To me this reads like either the CPU is simply malfunctioning internally or something *very weird* is happening in the microseconds after RESET goes high that's causing it to read a random reset vector instead of the "00 E0" is should be getting, and from there it's executing god knows what from whatever area it lands in.

FWIW, I was fooling with the emulator last night and I *kind* of replicated this; I loaded a kernel ROM image that was solid "FF"'s (to see what would happen if it got FFFF as a reset vector) and upon reset it plowed into the zero page RAM and started executing the semi-random garbage VICE populated it with. When I looked in the debugger I found it spinning in a loop of BRKs in an unpopulated memory page because one of the garbage instructions it had executed had reset the execution page register.


Desperado said:
Now U31 pin 7 is pulsing....
Click to expand...

Okay, is A0 *also* pulsing? Pin 7 is /G on the kernel EPROM.
 
You must log in or register to reply here.
Back
Top