• Please review our updated Terms and Rules here

Cbm 2001 Pet strange boot

They look OK.

It is now probably worth looking at the data bus signals on pins 26 to 33 (inclusive) o the 6502 CPU. we are looking for 'clean' signals - and nothing like UD2 pin 9!

Again, make sure you get the oscilloscope to trigger and try selecting different timebase settings to look at the overview of what is going on and then zoom in to look in detail at individual signals.

After that, I would remove the NOP generator - with Eudi's PETTESTER in the Kernal ROM socket (UD9). Make sure you have SYNC pulses on the CPU (indicating that the CPU is executing instructions) and then look at the output pins of UD2 again to see which ones are active - and which ones are permanently HIGH.

Dave
 
It is now probably worth looking at the data bus signals on pins 26 to 33 (inclusive) o the 6502 CPU. we are looking for 'clean' signals - and nothing like UD2 pin 9!
i am desperate!!! i can't see any waveform signal in these pins!!!!!
 
Sorry, I meant the PET data bus not the CPU data bus (i.e. the pins of the CPU socket not the pins of the CPU chip itself). If these are not conveniently available, find the equivalent points on the data bus buffers.

Sorry, still not a CPU fault! Will you purge this completely from your mind please...

Dave
 
You know I have never actually dedicated many brain cycles to the implementation of a NOP adapter but I guess on reflection there are essentially two ways of doing it...

1. Force the data bus to EA
2. Disconnect the data pins at the CPU and force these to EA. The data bus itself is now isolated from the CPU.

My implementations have opted for type 2. I.e. the CPU sees EA but the data bus sees tri-state Z from the CPU.

Never considered the implications of difference!

Type 2 is IMHO better since you cannot contend with errant writers in the data bus

.... Update....

In fact type 1 would cause problems since as the address bus counts the various readable devices present themselves and their data on the data bus.

seems like there really only is one way of doing it after all!
 
Last edited:
Correct.

As the NOP generator cycles through all of the memory addresses - an opcode read (memory read) is performed and the result discarded in favour of replacing it with NOP/$EA.

This means we can observe the actual state of the data bus itself and check for any bus contention occurring as a result of incorrect address decoding etc.

Dave
 
They don’t look that strange. I am guessing the ‘strange line’ is when the data bus is not being driven and it is floating.

I am just seeing a ‘snapshot’ of what you are seeing.

OK, can you remove the NOP generator and complete the latter steps identified back in post #1,403.

Dave
 
They don’t look that strange. I am guessing the ‘strange line’ is when the data bus is not being driven and it is floating.

I am just seeing a ‘snapshot’ of what you are seeing.

OK, can you remove the NOP generator and complete the latter steps identified back in post #1,403.

Dave
UD2 pin 3 to 17 ??
 
Correct.

As the NOP generator cycles through all of the memory addresses - an opcode read (memory read) is performed and the result discarded in favour of replacing it with NOP/$EA.

This means we can observe the actual state of the data bus itself and check for any bus contention occurring as a result of incorrect address decoding etc.

Dave

Using the NOP in my PET (with a perfectly normal working board) I had also observed these periods in the data bus signal where the voltage had appeared to assume an intermediate logic value.

I did not observe that slow ramp effect leading to it though (but possibly the lower rate time-base setting I had obscured it). It looked more to me (at a glance) like two outputs were contending, two devices driving the data line at the same time , for brief periods.

But it is more likely it just represented a period where the bus was floating, since there should not have been any real contention, assuming all the address decoding was working normally.
 
UD2:
1: HIGH
2: HIGH
3: HIGH
4: NO SIGNAL
5: HIGH
6: HIGH
7: HIGH
8 HIGH
9: HIGH
10: HIGH
11: HIGH
12: LOW
13: HIGH
14: HIGH
15: HIGH
16: HIGH
17: LOW
 
Is this using your logic probe or scope? Please use your scope.

We are looking for narrow low-going pulses.

Pin 4 with NO SIGNAL is also wrong.

Pin 17 would be good - this is selecting the ROM at $Fxxx.

I would also expect to see ‘blips’ of pulses on pins 1 and 9 also. All of the other pins should be HIGH.

Dave
 
Is this using your logic probe or scope? Please use your scope.

We are looking for narrow low-going pulses.

Pin 4 with NO SIGNAL is also wrong.

Pin 17 would be good - this is selecting the ROM at $Fxxx.

I would also expect to see ‘blips’ of pulses on pins 1 and 9 also. All of the other pins should be HIGH.

Dave
Good morning, today it is a very hot day in Milan :(
I tried with scope and with logic probe but i can't see any waveform signal in these pins!
Also on pin 4 i have NO SIGNAL (with logic probe no high, no low and no pulse), with scope horizontal signal without voltages :(
 
The scope will indicate a 'voltage' for UD2 pin 4 - what is it?

"How" have you tried to detect pulses on UD2 pins 1 and 9? How have you setup the scope for this task?

Again, you have to know what to expect in order to configure the test equipment to see something.

Dave
 
Back
Top