• Please review our updated Terms and Rules here
  • Exhibitor application for VCF West 2022 is now open! If you are interested in exhibiting, please fill out the form here.

Cbm 2001 Pet strange boot

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
7,263
Location
UK - Worcester
I have checked myself, and the firmware for UD9 that has been burnt looks correct to me also.

Based on that we are looking at the CPU -> ADDRESS BUFFERS -> ROM (UD9) -> DATA BUS -> CPU interface, along with the UD9 address decoding - and any potential bus contention.

Assuming the CPU address bus through the address bus buffers to the UD9 ROM has been checked out - then these should be OK.

The data bus from the ROMs goes straight back to the CPU. With the two PIAs and VIA removed, these should be out of the equation. The only other devices that could cause data bus contention would be buffers E9 and E10. There is some logic on schematic sheet 1 that controls the direction of these buffers - so that could be faulty (or one/both of E9/E10). In this instance, I would expect to see evidence of bus contention on the data bus.

It would be good if we could see initial signs of activity on UD9 pin 20 immediately following a reset to demonstrate that the CPU is trying to read the restart vector from the ROM.

I am not sure whether we have any other ROMs in place (other than my test firmware in UD9). If so, perhaps better to remove them. I have seen a faulty ROM disturb the data bus before now.

That is my "train of thought" for what it's worth. Enjoy!

Enjoy.

Dave
 

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
2,421
Location
Australia
The data bus from the ROMs goes straight back to the CPU. With the two PIAs and VIA removed, these should be out of the equation. The only other devices that could cause data bus contention would be buffers E9 and E10. There is some logic on schematic sheet 1 that controls the direction of these buffers - so that could be faulty (or one/both of E9/E10). In this instance, I would expect to see evidence of bus contention on the data bus.

Dave

Yes, I think the R/W control line from the CPU pin 34 via A10 pin 3&4 and A5 pin 4 & 6 to E9 &E10 (data read & write buffers) needs to be scoped. Also A4 pin 9 & 8.

A5 is driven by A4 (which had a catastrophic failure with its inputs shorted presumably due to an accidental short as it is not a common failure mode for TTL IC inputs) so it could well be that the IC A5 sustained damage from that event too. In addition, it was one of the other A4 gates that is used as an inverter to make sure that only E9 or E10 are in operation at any one time for a R/W, so it could explain it if E9 and E10 sustained damage too. If it did this could stop the CPU executing code.

The address buffers B3 & C3 are very easy to check that their inputs and outputs match on the scope.
 
Last edited:

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
2,421
Location
Australia
exactly ... we had reached a point where it was possible to see the basic screen, it stopped after a few seconds or minutes but at least you could see it :( Probably there was some component or ic that was failing and now it is definitely broken :(
I don't think that is likely what happened.

The failure that happened in IC A4, with pins 1 & 2 shorted inside the IC, does not happen as a spontaneous failure mode in a TTL IC. I have never seen it, nor has Daver2. It requires significant energy to melt the B-E junctions of the input transistor in the gate's input circuit. That also does not happen even if those input pins are accidentally shorted to +5V or ground. The only obvious way it could happen would be if there was a transient accidental short from the input to the output of the +5v regulator that runs the IC's in this section of the board. This also would account for the failure in the 74154 at the same time. Also I think the other IC's in this region of the pcb could be damaged, this includes possibly A5, the data buffers E9 & E10 and any other IC that runs from the rear 5V regulator is now a suspect for damage in my opinion.
 

Desperado

Veteran Member
Joined
Nov 25, 2017
Messages
2,159
It would be good if we could see initial signs of activity on UD9 pin 20 immediately following a reset to demonstrate that the CPU is trying to read the restart vector from the ROM.
With Nop inserted i can see this signal on UD9 pin 20:
 

Desperado

Veteran Member
Joined
Nov 25, 2017
Messages
2,159
I checked also UB3 and UC3 inputs and i have correct waveforms ( NOP inserted):
 

Attachments

  • Schermata 2022-06-22 alle 20.04.28.png
    Schermata 2022-06-22 alle 20.04.28.png
    31.4 KB · Views: 5

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
2,421
Location
Australia
I checked also UB3 and UC3 inputs and i have correct waveforms ( NOP inserted):
Good.

Did you check that the inputs and outputs of UB3 and UC3 match up, and that you also have the same output signals at the ROM sockets ?

Once that is done I would suggest checking the R/W system, the associated gates and the data buffers. I mentioned in #1603: I think the R/W control line from the CPU pin 34 via A10 pin 3&4 and A5 pin 4 & 6 to E9 &E10 (data read & write buffers) needs to be scoped. Also A4 pin 9 & 8.

Then Daver2 will likely have more things for you to test.
 

Nivag Swerdna

Experienced Member
Joined
Jul 17, 2020
Messages
378
Location
London, UK
It is true that the outputs of B3 and C3 do drive the memory expansion connector but they also drive the address bus across the board.

It might not be obvious but B3 and C3 are just buffers that help the 6502 drive the various downstream devices (including those beyond the expansion connector)

With a NOP adapter in place you should be able to measure both sides of the buffers and get the same results.

Further you should be able to follow the address bus all the way to D9 and measure A0..A11 on that device... Again the values should match both sides of the corresponding buffer and ultimately the address pin on the 6502 itself.

You need to be rigorous in your approach... For each pin write down the frequency you see.

If you have a short or a break in the address bus it should show up if you are methodical.
 

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
7,263
Location
UK - Worcester
Just got back from my business trip...

If you go back to post #1,584 I asked you to measure the frequencies.

ScottishColin was kind enough to test his machine and post the frequencies that he observed from his machine (1,591).

You have the correct equipment to perform the test now, so why are you now saying that you didn’t perform the test that was asked?

Dave
 

Desperado

Veteran Member
Joined
Nov 25, 2017
Messages
2,159
Just got back from my business trip...

If you go back to post #1,584 I asked you to measure the frequencies.

ScottishColin was kind enough to test his machine and post the frequencies that he observed from his machine (1,591).

You have the correct equipment to perform the test now, so why are you now saying that you didn’t perform the test that was asked?

Dave
Welcome back Dave!
Ok tomorrow i'll check all frequencies like suggest! Thanks to @ScottishColin ! I among the many posts I had unfortunately forgotten ...
Goodnight :)
 

Desperado

Veteran Member
Joined
Nov 25, 2017
Messages
2,159
Good evening, so this is:
Address line Pin Frequency on UD9

A0 PIN8 250Khz OK

A1 PIN7 125Khz OK

A2 PIN6 62.5Khz OK

A3 PIN5 31.25Khz OK

A4 PIN4 15.63Khz OK

A5 PIN3 7.813Khz OK

A6 PIN2 3.096Khz FREQ CHANGES

A7 PIN1 1.953Khz OK

A8 PIN23 976.6Hz OK

A9 PIN22 488.3Hz OK

A10 PIN19 244.3Hz OK

A11 PIN18 122.1Hz OK
 

daver2

Veteran Member
Joined
Jun 19, 2012
Messages
7,263
Location
UK - Worcester
Are you reading the frequency from your inbuilt frequency meter or the oscilloscope trace?

How is the frequency changing on A6 / UD9 pin 2?

Are the other address pins indicating a stable frequency?

Can you post a video from the oscilloscope for A5, A6 and A7?

Dave
 
Top