• Please review our updated Terms and Rules here

Cbm 2001 Pet strange boot

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
 
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:
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.
 
Thanks so much!
Now, to summarize, what configuration should I set and what test should I do?
 
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:
 
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: 6
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.
 
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 ?
Hugo i checked UB3 and UC3 inputs but not outputs because outputs goes to expansion connector :(
 
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.
 
In what sense? Did you measure the frequencies? what were they? I think you really need to post a picture for EACH one in turn.
I haven t measures frequencies but i saw correct wave forma in every pin Nivag, did i take picture for each pin?
 
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
 
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 :)
 
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
 
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
 
Back
Top