- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
CBM Pet 4032 DOA
- Thread starter mjnurney
- Start date
Heh. I was right!
I wonder what your PET does after you leave it on for an hour. Mine usually comes to life in about 5 minutes depending how warm the room is.
Your PET is stuck cycling between $FFFB and $FFFF, based on that. $FFFB is NMI, so you're stuck with /NMI asserted, CPU pin 6 low. Does this always happen, or just when you ground the diagnostic line?
Oh, and $FFFF is IRQ, so that may be normal. Seems spurious though, considering you don't see any other addresses.
NMI should always be high (except I think the diagnostic line uses that, don't recall).
If pin 6 on the CPU is indeed always high, you may have a bad CPU, if it really is reading $FFFB. Of course, you may have shorted address lines somewhere causing it to be $FFFB when it's not supposed to be. Weird coincidence either way.
If pin 6 on the CPU is indeed always high, you may have a bad CPU, if it really is reading $FFFB. Of course, you may have shorted address lines somewhere causing it to be $FFFB when it's not supposed to be. Weird coincidence either way.
Well, at this point I'd say it's just as likely to be a problem in the other ROMs as much as the KERNAL. I'm not an expert mind you. I would think the monitor would work with a bad BASIC ROM, but on the other hand, I know Commodore used a lot of the BASIC ROM for a lot of non-BASIC things.
But, hopefully the NOP test finds you something.
But, hopefully the NOP test finds you something.
I've seen some people work out when the machines are crashing by whats appearing on screen - the garbage screen that is . clever stuff
i have had READY. at some point but no Commodore bytes free.
for some reason i think its ROM related , either faulty roms or smoother reason.
i have had READY. at some point but no Commodore bytes free.
for some reason i think its ROM related , either faulty roms or smoother reason.
dave_m
Veteran Member
not sure my probe would pick that up would it ? but its low
ive just built a nop generator and removed all roms - how do I use it? follow the address lines to the rom socket and see if the pulse is the same on cpu vs socket?
ive just built a nop generator and removed all roms - how do I use it? follow the address lines to the rom socket and see if the pulse is the same on cpu vs socket?
Your probe should pick that up. If you're not seeing it, that means the ROM hasn't executed far enough to start the IRQ service.
With the NOP generator, you should see regular pulsing as the address counts from $0000 to $FFFF round and round. The lower bits should pulse faster than the higher bits (each one twice as slow as the next lower one). Check each ROM socket, as well as any address decoding logic, and the RAM chips. Basically follow each address line throughout the schematic.
With the NOP generator, you should see regular pulsing as the address counts from $0000 to $FFFF round and round. The lower bits should pulse faster than the higher bits (each one twice as slow as the next lower one). Check each ROM socket, as well as any address decoding logic, and the RAM chips. Basically follow each address line throughout the schematic.
dave_m
Veteran Member
KC,
Actually the address appears to be $DFFF. In BASIC 4 that in unused memory and the data bus should read $AA according to the disassembly.
You're correct. I mangled a bit or two.
$AA is TAX, which means the PC (and address bus) should increment to $E000, which it isn't, potentially due to a new (too early) IRQ. But it could only logically (in this case) end up there if the IRQ vector points to $DFFF. What is the normal location of the IRQ vector? This sounds more and more like stuck address lines.
$AA is TAX, which means the PC (and address bus) should increment to $E000, which it isn't, potentially due to a new (too early) IRQ. But it could only logically (in this case) end up there if the IRQ vector points to $DFFF. What is the normal location of the IRQ vector? This sounds more and more like stuck address lines.
all address look good to me.
cpu -
A0-A11 look same from cpu to sockets
d7-high
d6-high
d5-high
d4-low
d3-high
d2-low
d1-high
d0-low
rom sockets say
d7-high/low pulse
d6-high/low fast pulse
d5-high/low fast pulse
d4-high/low fast pulse
d3-high/low fast pulse
d2-high/low fast pulse
d1-high/low fast pulse
d0-high/low fast pulse
anyway all D0-7 buzz out to the rom sockets with no shorts , so they must be correct to cpu.
oh well.
cpu -
A0-A11 look same from cpu to sockets
d7-high
d6-high
d5-high
d4-low
d3-high
d2-low
d1-high
d0-low
rom sockets say
d7-high/low pulse
d6-high/low fast pulse
d5-high/low fast pulse
d4-high/low fast pulse
d3-high/low fast pulse
d2-high/low fast pulse
d1-high/low fast pulse
d0-high/low fast pulse
anyway all D0-7 buzz out to the rom sockets with no shorts , so they must be correct to cpu.
oh well.
Last edited:
dave_m
Veteran Member
I hope this is this looking with scope? Logic probe not good enough to tell differences in pulses.
I don't understand. Why difference in data lines from ROM sockets to CPU??
What does this mean? Did you buzz from one data line all others or at least to adjacent pins?
Logic probes not good enough Dave,I just did a quick test to see if anything was obviously wrong. I have a logic analyser to try that I've just bought ...let see what that says
Okay I've been using the logic analyser today.
CPU address match exactly , wave shape and duration match on each pin to the UD8 rom socket
I'll go thru the other rom sockets too but I'm pretty sure they are good.
Ill check at the buffers too, select lines to check too
Okay I've been using the logic analyser today.
CPU address match exactly , wave shape and duration match on each pin to the UD8 rom socket
I'll go thru the other rom sockets too but I'm pretty sure they are good.
Ill check at the buffers too, select lines to check too
Attachments
Last edited:
I may of found a fault - I'm sure i had SEL lines working before but some are missing now.
UD6 & UD12 the NOP generator should have then active i believe .
the other pic is how it should look.
okay thats solved - i need BA11 selected too on the kernel rom socket its now as the other pic is , but something is not right here. UD6 sel has a functioning SEL line but UD12 still has high sel iine for some reason, I've never checked that one before as its not required for booting.
update :
here goes.
With the petester rom , all addresses are good and working. with the NOP in same again (with no roms fitted) however with the eprom kernel in and power on - I'm getting continuity on the following addresses.
UD6
9-D0
10-D1
12-GND
13-D3
14-D4
15-D5
20-Sel f
now is this normal with power on ? , with the power off i don't get any continuity at all on those lines?
I can only image that this PET is cursed
And I've just noticed - someones nicked C6 capacitor on the ram line..... ?? who's had that? this thing has been used for 25 years!
UD6 & UD12 the NOP generator should have then active i believe .
the other pic is how it should look.
okay thats solved - i need BA11 selected too on the kernel rom socket its now as the other pic is , but something is not right here. UD6 sel has a functioning SEL line but UD12 still has high sel iine for some reason, I've never checked that one before as its not required for booting.
update :
here goes.
With the petester rom , all addresses are good and working. with the NOP in same again (with no roms fitted) however with the eprom kernel in and power on - I'm getting continuity on the following addresses.
UD6
9-D0
10-D1
12-GND
13-D3
14-D4
15-D5
20-Sel f
now is this normal with power on ? , with the power off i don't get any continuity at all on those lines?
I can only image that this PET is cursed
And I've just noticed - someones nicked C6 capacitor on the ram line..... ?? who's had that? this thing has been used for 25 years!
Attachments
Last edited: