• Please review our updated Terms and Rules here

Cbm 2001 Pet strange boot

I think that we have a known hardware problem that would need to be eliminated/solved before the CPU could properly execute code. The fact that pin 30 of the CPU's data line was reported by Desperado as being stuck low. It could be a good idea to find the cause of that first.. Or at least check that again, with the current Kernal ROM program running, which in theory should show pulses on all the data lines as they strobe between 00 and FF in the process of writing to $8000, in case it was a bad measurement beforehand. But obviously it is equally important to check the address lines and the outputs of UD2 again.
 
That's exactly where we are heading...

If this very simple program isn't running correctly, then there is something fairly fundamental that needs to be addressed.

If this does run, then we stand a chance of finding what is wrong.

My concern over pin 30 is that the CPU was not executing known code, so the random code it was executing could have had pin 30 low all the time without this being a fault.

If this very simple firmware isn't working, I think we will concentrate on pin 30 as our source of trouble and investigate that.

Dave
 
No. You’re guessing again!

Actually, this is normal behaviour (on power up) for a PET (as you should know by now) until the CPU actually writes some ‘valid’ data to the video RAM.

At the moment, we can’t see the CPU executing valid instructions - so this is the root cause of your problem.

If it was the video RAM, we would see /SELF being activated (as the CPU executes instructions out of the EPROM) and we will see valid writes to the video RAM via /SEL8.

The CAUSE is the CPU not executing valid instructions. The EFFECT is the video RAM retaining its random power-up values (and hence displaying garbage).

Dave
 
Last edited:
No. You’re guessing again!

Actually, this is normal behaviour (on power up) for a PET (as you should know by now) until the CPU actually writes some ‘valid’ data to the video RAM.

At the moment, we can’t see the CPU executing valid instructions - so this is the root cause of your problem.

If it was the video RAM, we would see /SELF being activated (as the CPU executes instructions out of the EPROM) and we will see valid writes to the video RAM via /SEL8.

The CAUSE is the CPU not executing valid instructions. The EFFECT is the video RAM retaining its random power-up values (and hence displaying garbage).

Dave
Ok thanks!!
 
I'm thinking about offering a repair service for your board... Send me a message if you are interested and I will reply with terms.
Thank you very much for your help but being you in the UK it would not be convenient for me unfortunately ... also these attempts help me to learn a lot about these computers!
 
But what signals?

Please post which output pins of UD2 have activity and which are low.

Can I also ask that you post the ROM image that you are now using? Put your UD9 EPROM into the EPROM programmer, load the contents of the EPROM into the programmers memory, save it to a binary file and upload the resulting binary file as an attachment to your VCFED post.

If the EPROM is not correct again, this test will fail.

Depending on what output pin state we have on UD2 will depend on where we go next (assuming the EPROM contents are correct of course).

Dave
 
Last edited:
But what signals?

Please post which output pins of UD2 have activity and which are low.

Can I also ask that you post the ROM image that you are now using? Put your UD9 EPROM into the EPROM programmer, load the contents of the EPROM into the programmers memory, save it to a binary file and upload the resulting binary file as an attachment to your VCFED post.

If the EPROM is not correct again, this test will fail.

Depending on what output pin state we have on UD2 will depend on where we go next (assuming the EPROM contents are correct of course).

Dave
Can i try all UD2 output with logic probe to see state?
 
So it’s basically doing the same thing as before, the CPU appears to be executing code out of the lower 4K of memory (UD2 pin 1) with no visible means of getting there from the ROM.

I assume if you check the CPU SYNC pin that it is pulsing away? Can you check this pin and post the state please?

I will check the binary file you uploaded tomorrow morning. I have a few jobs to do and then I am going out this evening.

Dave
 
I am really desperate now!!
I re turned on the Pet, i checked Cpu pin 7 and it is LOW, so i checked again UD2 pin 1 and now it is also LOW!!!
I can't understand this.... :(
 
I am really desperate now!!
I re turned on the Pet, i checked Cpu pin 7 and it is LOW, so i checked again UD2 pin 1 and now it is also LOW!!!
I can't understand this.... :(
I can, the CPU is not executing the ROM program correctly, it is executing cr*p - hence it can do different things at different times...

Have you tried replacing the CPU :)? You never know, it might work... If not we know what it isn't...

We have to now look carefully at the address bus from the CPU to the ROM, the chip selection logic for UD9 and the data bus from the ROM to the CPU.

One of these paths is messing up...

Dave
 
Back
Top