2 Faulty Beebs

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 11:13 am

vanekp wrote:
JannievanZyl wrote:Ok, an update.


Eventually, I took all the major chips and plugged them into a working beeb. These all tested faulty: :shock:

- 1 x 6502 - completely dead
- 1 x 6502 - actually boots but then hangs with garbage on the screen
- 3 x 6522 VIAs dead (only 1 of the 4 is working)
- 1 x CRT Controller
- 1 x Video ULA
- 1 x System ROM

So, I suspect a huge power issue on the one system that blew the board and took most of the chips with it.
Sound a bit like someone reversed the polarity of the power on the mother board easy to do with the wires that come from the PSU.
Would for sure explain two very dead machines from the same source. (Who did their own recapping and got C9 the wrong way around in one of them.....)

Kazzie
Posts: 82
Joined: Sun Oct 15, 2017 7:10 pm
Location: North Wales
Contact:

Re: 2 Faulty Beebs

Post by Kazzie » Sun Feb 04, 2018 1:12 pm

JannievanZyl wrote:Yup, the ULA gives out all the correct frequencies and it does get through to the CPU but *only* while RST is active (i.e. you hold down the Break key, or at initial startup).

Read the service manual but where I'm stuck is what exactly happens during the 'reset cycle'. Clearly the CPU tries to do something (or the system does) which fails and it then all hangs with the clock to the CPU also stopping.

If you look at the attached portion of the circuit, it's effectively the output of the 8-input NAND gate (IC23) that stops the clock from getting to the CPU. Through the inverter (IC33) it keeps the one input of the OR gate (IC29) high, so effectively the clock stays high.
The output on pin 2 of IC33 will keep the output of the OR gate of IC29 (pins 8,9,10) high. This is the data input of the flip-flop on (pins 1-6 of) IC34, but note that the /Q output of the flip-flop is used. Thus the input to pin 13 of the IC29 OR gate (pins 11,12,13) is held LOW, and the input of pin 12 of IC29 will be fed to the 6502's PHI input.

From what I can see IC23/IC33 should be controlling whether the CPU's receiving a 2MHz clock or 1MHz.

Quoting from the service manual (Section 3.3):
The microprocessor is a 6502A and runs at either 1 or 2 MHz. Most processing is done at 2 MHz, including accesses to the RAM and ROM, but the processor slows down to 1 MHz when addressing slow devices, viz. the 1 MHz extension bus, the ADC, the two VIA's, the 6845 CRT controller, the ACIA, and the serial processor. Clock signals for the microprocessor are produced by a 16 MHz crystal oscillator (IC43) in conjunction with divider circuitry in part of the video processor (IC6) which produces 8, 4, 2 and 1 MHz signals. The 1 MHz signal coming directly from the video processor is only used for the Teletext generator chip, whilst a D-type flip-flop (half of IC34) divides the 2 MHz clock signal in order to produce the system 1 MHz clock (1 MHzE).
The BBC should have to switch between the 2MHz and 1MHzE clocks after reset to use the VIAs and CRT controller. As a result, I'm suspecting the 74LS74 flip-flops that glue the Video clock output to the processor.

I'd check the relevant D and Q (/Q) of ICs 30, 31 and 34 to check if the clock signals from the video processor are propagating through correctly, and IC29 which helps connect them.

Take a look at IC28 too. It's fed by IC23 and clock signals 1MHzE and PHI1, and resets the output of half of IC30 (on pin 1). If either of the 1MHzE or PHI1 inputs aren't getting there, when IC23 goes low it could result in IC28's output being stuck, resetting IC30 forcing pin 5 high, as well as making IC34 pin 6 low. That would kill the clock signal to the CPU (PHI IN), and unless 1MHzE or PHI1 release IC28, nothing else will happen.

PHI1 comes from the CPU, so (presumably) depends on PHI IN. 1MHzE, on the other hand, is independent of the CPU, derived from the Video clock by IC34. So you should definitely have a look there to check if it's working properly.
Pudsey - BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM (mid- restoration)

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 2:21 pm

Kazzie wrote: The BBC should have to switch between the 2MHz and 1MHzE clocks after reset to use the VIAs and CRT controller. As a result, I'm suspecting the 74LS74 flip-flops that glue the Video clock output to the processor.

I'd check the relevant D and Q (/Q) of ICs 30, 31 and 34 to check if the clock signals from the video processor are propagating through correctly, and IC29 which helps connect them.

Take a look at IC28 too. It's fed by IC23 and clock signals 1MHzE and PHI1, and resets the output of half of IC30 (on pin 1). If either of the 1MHzE or PHI1 inputs aren't getting there, when IC23 goes low it could result in IC28's output being stuck, resetting IC30 forcing pin 5 high, as well as making IC34 pin 6 low. That would kill the clock signal to the CPU (PHI IN), and unless 1MHzE or PHI1 release IC28, nothing else will happen.

PHI1 comes from the CPU, so (presumably) depends on PHI IN. 1MHzE, on the other hand, is independent of the CPU, derived from the Video clock by IC34. So you should definitely have a look there to check if it's working properly.
Thanks Kazzie,

I've been sniffing around those flip-flops for a while and have replaced 30 and 34 (I initially thought they pulled the clock output of the ULA down). I can measure that they work fine, definitely IC30.

IC34 produces an output when I force /RST (via Break) on it's pin-4 and the clock then appears on the CPU. So I'm sure the flip-flops are all working but they might be getting their knickers in a knot as per your explanation.

I'm going to try and trace and figure out this switching between 1 and 2MHz works.

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 2:51 pm

A question: I don't think you have said, but which issue PCB does this Beeb have?

In relation to the CPU clock, maybe rigging it so that it only works at 1MHz may help with the fault finding.
Assuming the Beeb started off as a model B, cut or desolder the wire link bridging S19. Then connect the middle pin of S19 to 0V/GND. S19 feeds pin 3 of IC23 (74LS30), which should result in the CPU always running at 1MHz.
See photo:-
IMG_6461.JPG
Photo showing S19
The complex arrangement of IC29, IC30, IC31 and IC34 is because switching between a 2MHz clock and a 1MHz is tricky, as the CPU clock edges have to align with the correct timing.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 2:56 pm

Below is an extract from the service manual that may help:
3.1 Processor + clock circuitry + reset circuitry
The microprocessor is a 6502A and runs at either 1 or 2 MHz. Most processing is done at 2 MHz, including accesses to the RAM and ROM, but the processor slows down to 1 MHz when addressing slow devices, viz. the 1 MHz extension bus, the ADC, the two VIA’s, the 6845 CRT controller, the ACIA, and the serial processor. Clock signals for the microprocessor are produced by a 16 MHz crystal oscillator (IC43) in conjunction with divider circuitry in part of the video processor (IC6) which produces 8, 4, 2 and 1 MHz signals. The 1 MHz signal coming directly from the video processor is only used for the Teletext generator chip, whilst a D-type flip-flop (half of IC34) divides the 2 MHz clock signal in order to produce the system 1 MHz clock (1 MHzE). A 2 MHz signal of suitable phase is produced at the output of another D-type (half of IC31) which remembers when a 1 MHz cycle has been requested. At the appropriate time, as governed by the 2 MHz clock, one of the 2 MHz clock cycles is masked off by the D-type (half of IC34) and when this happens the D-type that remembered that a request had been made, is cleared. Depending on the phase relationship between the 1 and 2 MHz clocks at the time of the request, the delay on the 2 MHzE clock is different as illustrated by the diagrams below.
Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 4:02 pm

1024MAK wrote:A question: I don't think you have said, but which issue PCB does this Beeb have?

Mark
Thanks Mark, this is an Issue 7.

Will definitely try and get it all on 1MHz.

But here's another question, please.....(think I'm losing my marbles here :) )

On a working beeb, if I look at the address bus it shows normal activity until I press Break and the the bus stops. This is what one would expect, right? The CPU is halted at this point.

BUT....on the faulty one, the bus is dead UNTIL I press Break, then there's continued activity, i.e. while RST is active on the CPU.

Is there anything else that can control the address bus as measure on the CPU?

I'm pretty sure it's inactivity on the address bus that inhibits the clock via IC24 and IC23. No activity on the add bus results in no clock select via all the flip-flops.

I saw this "inverse add bus activity" on the input of IC 24 and then checked on the CPU where I also see it.

So, who's controlling the add bus while the CPU is in reset state?

/Going to pour a glass of red wine now....... :)

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 4:25 pm

Depends on which bit of the address bus you are monitoring.

The 6845 CRTC generates addresses for the DRAM, even when the there is no TV picture information to display. It is this action which refreshes the DRAM. This means that the DRAM address bus will be active even if the CPU is in RESET.

However, the OS ROM has to write the correct values to the 6845 CRTC to set up the correct screen parameters. I'm not sure what the default power on values and settings are.

On the CPU side (the CPU address bus), should not have changing values with the CPU in RESET. It may well still have a value, but it should be static.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 4:32 pm

1024MAK wrote: Depends on which bit of the address bus you are monitoring.
I see this on all 16 bits.

I first noticed this on the input of IC24 (A5-A9) so checked the CPU and see it on the whole bus.
1024MAK wrote: The 6845 CRTC generates addresses for the DRAM, even when the there is no TV picture information to display. It is this action which refreshes the DRAM. This means that the DRAM address bus will be active even if the CPU is in RESET.
This is what I also thought but I don't see the same behaviour on the working one. While in reset, the bus is completely static on the CPU pins.
1024MAK wrote: On the CPU side (the CPU address bus), should not have changing values with the CPU in RESET. It may well still have a value, but it should be static.
My thinking as well. But *something* is changing the address lines.
1024MAK wrote: Set to 1MHz only via J19......
Mark
Did this and can confirm the CPU only gets 1MHz. But still only when reset is pressed.

I've tested it before but going to swap the CRTC again.

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 4:56 pm

Unplugged the CRTC and still get the address bus activity when the CPU is in reset.

At this point there's not much left on the board in the state where I get this bus activity in CPU reset.

Just to confirm, from what I've read the system will still generate a banner in this state, correct?
beeb-5.jpg

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 5:13 pm

Erm, what you got is a very strange fault :shock:

What happens on the CPU address pins (well the socket pins) if you power up without a CPU?

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 5:24 pm

1024MAK wrote:Erm, what you got is a very strange fault :shock:

What happens on the CPU address pins (well the socket pins) if you power up without a CPU?

Mark
Thank God nothing happens without a CPU! [-o< Otherwise I would've sprinkled holy water on the thing. :)

After I saw removing the CRTC still gave add bus activity while in reset, I pulled the CPU and measured on the ROM pins. But saw no activity.

I'll do it again but try and measure on the CPU socket pins.

Kazzie
Posts: 82
Joined: Sun Oct 15, 2017 7:10 pm
Location: North Wales
Contact:

Re: 2 Faulty Beebs

Post by Kazzie » Sun Feb 04, 2018 5:28 pm

Also useful reading (from 8bs.com/inbbc/html):
The 1MHz system clock is actually generated by externally dividing the 2MHz signal by 2 using a D-flip-flop (half of IC34); the 1MHz signal out of the video ULA is only used for driving ICs 5 and 15. Two more D-type flip-flops (IC30) and an OR gate are used to generate the 2MHz clock for the CPU, which has a specific waveform requirement. Requests for a 1MHz processor cycle from the address decoding are fed via an inverter (1/6th of IC33) to a D-flip-flop (half of IC31) which latches the request for a 1MHz cycle. At the appropriate time, as governed by the 2MHz clock, one of the 2MHz clock cycles is masked off by a D-flip-flop (half of IC34). When this happens the D flip-flop that latched the request is cleared, to re-enable the 2MHz CPU clock at the next appropriate clock phase.
(I can't guarantee all the following is correct, but it made sense to me as I wrote it.)

On that basis, when the system is reset, /RST on IC34 pin 4 presets that flip-flop, so output /Q on pin 6 is low. This in turn presets IC31 on pin 10, so IC31 pin 8 (/Q) is also low. The output of IC33 (pin 2) will be high unless a request for 1MHz operation comes through, so (through IC29) the D input to IC34 (pin 2) will be high.IC34 pin 6 will remain low for the time being, so the output of IC29 (feeding the CPU's PHI IN) will only depend on the 2MHz clock coming from IC30.

This state of affairs will change when a request for 1MHz is made, and IC23 pin 8 goes from low to high. IC33 and IC29 will invert immediately (except gate delays) such that D input to IC34 (pin 2) is now low. When IC34 pin 3 next sees a rising clock pulse (from the 2MHz clock on IC30 pin 5) this change will propagate through to IC34 pin 6, which will go high. It will remain high, so the CPU's PHI IN won't drop low at the next down transition of the 2MHz clock.

IC34 pin 6 also controls the preset for IC31 (through pin 10). When this goes high, the state of the flip-flip can change. It is clocked by the 1MHzE clock signal, and the Data input is from IC33 pin 2 (which is already low). When 1MHzE rises and IC34 flips, both of IC29's inputs (pins 9 and 10) will be low, so the data input for IC34 (pin 2) will be low. It isn't long since the last rising edge of the 2MHz clock, so this won't happen for a while.

Let's go back and look at the other branch coming out of IC23 pin 8: IC28. To summarise this gate, the output on pin 8 will be high unless PHI1, 1MHzE, and IC23 pin 8 are ALL high, at which point it will output low. So when IC28 goes high, IC 23 won't necessarily change at once. (PHI1 will only be high when the CPU's PHI IN is low.) The change will only happen when it's correctly synchronised with the other clock signals. At this point, IC30 pin 1 will reset the output of the flip-flop, and Q (pin 5) will fall low. Note that this is also the clock input for IC34 on pin 3, so we're almost ready for a rising clock edge there!

IC23's output will only stay low until the 1MHzE input changes again. At this point, the CLEAR on IC30 pin 1 will be removed, and its Q on pin 5 will start showing a 2MHz clock signal again. (In the meantime we'll have missed one clock pulse, so dropping to 1MHz.) When that clock signal arrives, it advances IC34 's low on pin 2 through to pin 5 (/Q), presetting IC31's flip-flop, with its /Q going low.

If the request for a 1MHz clock through IC28 remains, D (pin 2) on IC34 will remain high because of IC33, and we'll clear IC30 again one clock cycle later, continuing to drop half the clock pulses (and lengthen some with IC34 to make a balanced 1MHz clock signal).

Hopefully this will help you compare your Beeb's behaviour to what should be happening.
Pudsey - BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM (mid- restoration)

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 5:30 pm

Confirmed, with no CPU the add bus lines jump to about 1.5V and stay static.

So, it really looks like activating RST on the CPU generates activity on the address lines. I've tested this CPU in a working beeb.

Am I going nuts? :?

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 5:33 pm

JannievanZyl wrote:Unplugged the CRTC and still get the address bus activity when the CPU is in reset.

At this point there's not much left on the board in the state where I get this bus activity in CPU reset.

Just to confirm, from what I've read the system will still generate a banner in this state, correct?
Yes, with all the following chips removed: both 6522 VIAs, D7002 ADC, the FDC chips, the speech system chips (if fitted), the serial ULA, and the 6850 (68A50) if socketed and all the ROMs except for the OS ROM, in a working machine, it should start up and display the Language? prompt. You may need to reinstate link S9 if IC78 (FDC chip) has been removed.

I presume you know that the video ULA chip needs a heatsink.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 5:38 pm

JannievanZyl wrote:Confirmed, with no CPU the add bus lines jump to about 1.5V and stay static.

So, it really looks like activating RST on the CPU generates activity on the address lines. I've tested this CPU in a working beeb.

Am I going nuts? :?
No!

Either the CPU is faulty, or more likely, there is a fault with the reset circuit, such that it is doing the inverse of what it should do!

Monitor the reset (/RST) pin (40) on the CPU and compare to pin 3 of IC16 (NE555) (top left corner of the PCB).

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 5:42 pm

Kazzie wrote:Also useful reading (from 8bs.com/inbbc/html):

(I can't guarantee all the following is correct, but it made sense to me as I wrote it.).........

Hopefully this will help you compare your Beeb's behaviour to what should be happening.
Thanks Kazzie

Will carefully go through this and trace.

But to just confirm, the way I read it is that the problem lies before this circuitry, specifically with the output of IC23, pin-8 which is static in the faulty system. This seems to drive everything southwards, including the flip-flops and IC28.

And this output is static because it's inputs are driven by IC24 which - in turn - is quiet as its inputs (basically the address bus) are static.

So; No address bus activity -> no output on the latch -> no output on the 8-input NAND gate and thus no clock to the CPU being enabled.

But when I press Break, it all comes alive.

I've also tried Mark's test to set the system to only run at 1MHz and got the same symptoms. Not sure if that affects the circuitry you described?

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 5:44 pm

1024MAK wrote:
JannievanZyl wrote:Confirmed, with no CPU the add bus lines jump to about 1.5V and stay static.

So, it really looks like activating RST on the CPU generates activity on the address lines. I've tested this CPU in a working beeb.

Am I going nuts? :?
No!

Either the CPU is faulty, or more likely, there is a fault with the reset circuit, such that it is doing the inverse of what it should do!

Monitor the reset (/RST) pin (40) on the CPU and compare to pin 3 of IC16 (NE555) (top left corner of the PCB).

Mark
I've checked the reset circuit a few times but I'd better go and do it again. You know how it is with confirmation bias when you see what you expect to see......

I've tested this CPU in a working system.
Last edited by JannievanZyl on Sun Feb 04, 2018 5:56 pm, edited 1 time in total.

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 5:47 pm

1024MAK wrote:
JannievanZyl wrote:Unplugged the CRTC and still get the address bus activity when the CPU is in reset.

At this point there's not much left on the board in the state where I get this bus activity in CPU reset.

Just to confirm, from what I've read the system will still generate a banner in this state, correct?
Yes, with all the following chips removed: both 6522 VIAs, D7002 ADC, the FDC chips, the speech system chips (if fitted), the serial ULA, and the 6850 (68A50) if socketed and all the ROMs except for the OS ROM, it a working machine should start up and display the Language? prompt. You may need to reinstate link S9 if IC78 (FDC chip) has been removed.
Yup, I followed that script (not sure who the author is - got the link here somewhere. I did make S9 though I had no idea what it does.
1024MAK wrote: I presume you know that the video ULA chip needs a heatsink.
Mark
Both the Issue 7's I've got have no heatsink but both Issue 4's do. I've asked about it before (when I noticed the difference) and someone said the later ones do not need it.

Should I fit one in any case?

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 5:48 pm

In this thread, there are details of a fault on the reset circuit.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 5:52 pm

1024MAK wrote:In this thread, there are details of a fault on the reset circuit.

Mark
Just measured again. Pin-40 of the CPU is high unless I push reset which makes it go low.

This is definitely correct, right?

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 5:59 pm

Pin 40 (/RST) low resets the CPU. For normal CPU operation, it should be high.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 6:09 pm

1024MAK wrote:Pin 40 (/RST) low resets the CPU. For normal CPU operation, it should be high.

Mark
Yup, that's what I get.

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 6:11 pm

JannievanZyl wrote:
1024MAK wrote: I presume you know that the video ULA chip needs a heatsink.
Mark
Both the Issue 7's I've got have no heatsink but both Issue 4's do. I've asked about it before (when I noticed the difference) and someone said the later ones do not need it.

Should I fit one in any case?
Sorry, had not noticed that the chip you have is a Ferranti -8 version. All the earlier Ferranti chips need a heatsink. VTI chips don't need a heatsink. Background here and info on which ones need a heatsink here.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
hoglet
Posts: 7113
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: 2 Faulty Beebs

Post by hoglet » Sun Feb 04, 2018 6:23 pm

In my recent bout of 6502 bus protocol analysis, I've been doing lots of captures that start with reset held down. I'm fairly sure I've seen cases of the 6502 "chattering" when reset is asserted, depending on what state the 6502 when this happens.

If it's important, I could try to confirm this tomorrow.

Dave

Kazzie
Posts: 82
Joined: Sun Oct 15, 2017 7:10 pm
Location: North Wales
Contact:

Re: 2 Faulty Beebs

Post by Kazzie » Sun Feb 04, 2018 6:38 pm

JannievanZyl wrote:
Kazzie wrote:Also useful reading (from 8bs.com/inbbc/html):

(I can't guarantee all the following is correct, but it made sense to me as I wrote it.).........

Hopefully this will help you compare your Beeb's behaviour to what should be happening.
Thanks Kazzie

Will carefully go through this and trace.

But to just confirm, the way I read it is that the problem lies before this circuitry, specifically with the output of IC23, pin-8 which is static in the faulty system. This seems to drive everything southwards, including the flip-flops and IC28.

And this output is static because it's inputs are driven by IC24 which - in turn - is quiet as its inputs (basically the address bus) are static.

So; No address bus activity -> no output on the latch -> no output on the 8-input NAND gate and thus no clock to the CPU being enabled.

But when I press Break, it all comes alive.

I've also tried Mark's test to set the system to only run at 1MHz and got the same symptoms. Not sure if that affects the circuitry you described?

If IC23's output is static, the system should be stuck in either 1MHz or 2MHz mode. (Mark's suggestion of breaking S19 leaves pin 3 of IC23 floating. Assuming it floats down, it forces IC23 to request 1MHz mode continuously.)

Reading back through the thread, I don't think you've described which side of this fence the clock circuitry is sitting when it's locked up. Could you check what is on the following when you're not holding reset/break, when you get the chance? (High, Low, or Clock.) I'll check if it seems in a working state (based on what I wrote in my previous post).

IC23 pin 8
IC28 pin 8
IC28 pin 13
IC29 pin 8
IC29 pin 11
IC30 pin 11
IC30 pin 12
IC31 pin 8
IC33 pin 2
IC34 pin 4
IC34 pin 9

Thanks.
Pudsey - BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM (mid- restoration)

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 6:40 pm

hoglet wrote:In my recent bout of 6502 bus protocol analysis, I've been doing lots of captures that start with reset held down. I'm fairly sure I've seen cases of the 6502 "chattering" when reset is asserted, depending on what state the 6502 when this happens.

If it's important, I could try to confirm this tomorrow.

Dave
That would be cool, if possible Dave.

Not just because I'm seriously doubting my sanity at this point, but it's interesting info to know in general.

I've repaired a wack of different 6502 systems but first time I noticed this. And it only seems to happen on the faulty system, not working ones. So there's another underlying explanation, I think.

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 6:45 pm

Thinking about this a bit more. I wonder if the 6502 needs a valid clock input in order to correctly reset. The Z80 CPU does need a valid clock input in order to reset. If a Z80 has no clock signal, the address bus, control bus and data bus pins end up in undefined states (that may not confirm to the normal logic).

And of course, the NMOS 6502 does have some internal parts that are dynamic (like the registers).

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 6:49 pm

Kazzie wrote: Reading back through the thread, I don't think you've described which side of this fence the clock circuitry is sitting when it's locked up. Could you check what is on the following when you're not holding reset/break, when you get the chance? (High, Low, or Clock.) I'll check if it seems in a working state (based on what I wrote in my previous post).
Thanks.
Thanks Kazzie,

Here they are:

IC23 pin 8 - H
IC28 pin 8 - H
IC28 pin 13 - L
IC29 pin 8 - L
IC29 pin 11 - H
IC30 pin 11 - C - 8MHz
IC30 pin 12 - C - 2MHz
IC31 pin 8 - L
IC33 pin 2 - L
IC34 pin 4 - H
IC34 pin 9 - C - 1MHz

User avatar
1024MAK
Posts: 7416
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: 2 Faulty Beebs

Post by 1024MAK » Sun Feb 04, 2018 6:52 pm

Kazzie wrote:If IC23's output is static, the system should be stuck in either 1MHz or 2MHz mode. (Mark's suggestion of breaking S19 leaves pin 3 of IC23 floating. Assuming it floats down, it forces IC23 to request 1MHz mode continuously.)
I suggested the middle pin of S19 (and therefore IC23 pin 3) be connected to 0V/GND (in this post), as most floating TTL inputs will float to a logic high.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

JannievanZyl
Posts: 151
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: 2 Faulty Beebs

Post by JannievanZyl » Sun Feb 04, 2018 6:53 pm

1024MAK wrote:Thinking about this a bit more. I wonder if the 6502 needs a valid clock input in order to correctly reset. The Z80 CPU does need a valid clock input in order to reset. If a Z80 has no clock signal, the address bus, control bus and data bus pins end up in undefined states (that may not confirm to the normal logic).

And of course, the NMOS 6502 does have some internal parts that are dynamic (like the registers).

Mark
There is clock while /RST is low, so reset and clock appears at the same time.

Clock only stops when reset is released but that might be what you describe; as soon as the CPU comes out of reset, clock is missing.

Post Reply