Weird symptom number 2...

Korinel · October 2014

I got a new keyboard membrane for my Spectrum+ plugged it in and low and behold the weird left to right printing of the copyright message disappeared.

However the Spectrum is now too fast... (sigh) so whenever I press a key I get 4 key presses.

I slapped on every diagnostic tool I could get my hands on onto a ZXC3 ROM cartridge, and ran them all, all tests passed, keyboard, RAM, ROM, ULA, IRQ etc.

After about 5 minutes the Spectrum slows down and then hangs, roboots cause the machine to return back to the copyright message but it's not responsive. Although it would boot into the ZXC3, though even that will hang eventually.

If I leave the machine off for 10 minutes and reboot it boots and returns into it's whizzy mode.

Now when the Spectrum is in the hung mode where neither the joystick or the keyboard create any input, if I slap in my Jetpac ROM... I can play it... with both keyboard and Joystick... the speed of the game isn't quite correct but it does play properly. I reboot into basic.. and it's hung.

I'm wondering:

It could be the ROM. If the Spectrum ROM overheats I guess it can't run, when I play jetPac it doesn't use the ROM (except for interrupts).

It could be interrupt related, how do interrupts occur they must need a clock?

Any thoughts anyone?

DEATH · October 2014

I doubt it's the clock, if it could be sped up as you describe, accelerator circuits would have been made and sold years ago.

Sounds to me like your machine is simply getting too hot. See, the 7805 regulator will close down when it gets to a critical temperature, and that could cause the effect you describe.

Is it an issue 2 board or one of your others? Issue 2's seem to be more prone in my experience because the lump of metal they bolt the regulator chip onto is smaller than an issue 3+

Here's what you can try. Measure the output voltage of your power supply - the hole in the plug is negative. If you have more than about 12 volts, you are pushing the regulator hard, and much above 13 or so and it's going to get very hot. The solution in this case is fairly simple - assuming you don't have a spare 9V supply to hand, open the case up of the PSU and insert a few 3 Amp diodes in series with the +ve output. There will be a voltage drop of about 0.6V for each diode you have in place, and two or three in series will help a heck of a lot with the 7805 getting hot

Lots of people on here will help you with fitting the diodes, and there are other ways you can reduce the voltage output if necessary, just that a few diodes is the simplest (and cheapest) solution.

If your PSU is outputting below 12V, then we shall have to re-think the situation, but to be honest, if the machine is stable for 10 minutes from cold, and then goes wrong, it really does sound like a thermally induced fault.

Ideas anybody??

1024MAK · October 2014

Before we get to adding diodes, what happens if run with the top cover not fitted? If you have a fan, direct the air flow over the board and see if that makes any difference.

Also are the supply voltages okay during the "wild" times?

Myself, I suspect the ULA...

I think it is unlikely to be the ROM. Except for some configurations of Paul's ZXC3 cartridge, all ROM cartridges disable (but do not power down) the internal "BASIC" ROM. Whichever ROM cartridge is in use has to handle the interrupts.

The item that generates the interrupts is the ULA... Hence why I suspect it.

Do you have another ULA you could test with?

Mark

Korinel · October 2014

Thanks gents!

The board is an issue 6.

I swapped the ULA over with another machine and this one still has the fault and not the one I swapped with, this would imply it's not the ULA, however something could be wrong with the connections to the ULA...

Would it make sense to get my two issue 6 side by side and measure the voltages of each pin on the ULA and see if I see an obvious discrepancy?

I assume I just place the black probe on the heat sink, power it up and touch each IC pin with the red probe. The multimeter being set to measure volts and set to 20?

I measured all my power supplies I have and they are all the same, 12v ish, this would imply they are okay, I've also tried the supply with other machines and I don't get the same symptoms.

I could switch the 7805, could one of you gents let me now if this is a viable replacement: http://www.maplin.co.uk/p/ts7805cz-1a-positive-fixed-voltage-regulator-to220-case-ql31

Given the Spectrum passed all the diagnostic tests (which are I appreciate are not particularly thorough!) I have hope this is a minor issue and can be solved!

guesser · October 2014

Korinel wrote: »

I assume I just place the black probe on the heat sink, power it up and touch each IC pin with the red probe. The multimeter being set to measure volts and set to 20?

Unlikely to be remotely helpful since they are all signal lines and are things are obviously mostly working. The measurements of average voltage wouldn't tell you anything.

1024MAK · October 2014

Korinel wrote: »

Would it make sense to get my two issue 6 side by side and measure the voltages of each pin on the ULA and see if I see an obvious discrepancy?

Maybe. Multimeters are SLOW compared to the signals on most of the ULA pins, so the meter will show an average, not the actual voltage. If you are comparing, both machines must be doing the same thing (suggest leave at the copyright message).

Korinel wrote: »

I assume I just place the black probe on the heat sink, power it up and touch each IC pin with the red probe. The multimeter being set to measure volts and set to 20?

Yes.

The black probe needs to be connected to a part of the circuit that is 0V (also known as common or ground). The heat sink is such a place (as the metal tab of the 7805 regulator is electrically connected to 0V). Better if you have a croc clip, saves having to hold it.

Be very, very careful with the probe used on the pins. If you slip, you will cause a short between two pins. Sometimes there is no damage (the computer may crash). But short between a power supply or 0V/ground pin and a signal pin and you may kill one (or more) of the chips.

Korinel wrote: »

I could switch the 7805, could one of you gents let me now if this is a viable replacement: http://www.maplin.co.uk/p/ts7805cz-1a-positive-fixed-voltage-regulator-to220-case-ql31

You have lost the j off the end of the link... http://www.maplin.co.uk/p/ts7805cz-1a-positive-fixed-voltage-regulator-to220-case-ql31j
Yes, this 7805 is a suitable replacement. If you are going to a shop, Maplin is convenient . If buying online, Maplin is not the cheapest supplier.

Mark

Spirantho · October 2014

Have you changed the electrolytic capacitors? They're one of the first things to change when weirdness happens, especially where the symptom varies with time....

Korinel · October 2014

Spirantho wrote: »

Have you changed the electrolytic capacitors? They're one of the first things to change when weirdness happens, especially where the symptom varies with time....

Yes I changed all of them as one had exploded, had the issue before and had it after :/

I appear to be running out of options :(

Is there a way to test the capacitors in place?

1024MAK · October 2014

Well, unless this is actually a weird Z80 CPU fault or a weird RAM fault, the only other things that I can see being the cause are maybe TR3 or TR6 (both ZTX313).

TR3 is the clock amp (between the ULA and the Z80 CPU). Also if you renew it, while it is out of circuit, test R24 and R25 on the resistance range.

TR6 is the extra address decoding needed to stop the ULA from messing up the Z80 I/O port communications (this fixes a bug in all Spectrum ULA's). Also test the resistance of R27.

ZTX313 transistors can be replaced with BC547A, B or C types, or BC548A, B or C types, or BC549A, B or C types, (plus many others). But as the lead-out is different (opposite), they have to go the other way around on the board (the curved side of the transistor case to the flat part of the silk screen print and the flat side of the transistor case to the curved part of the silk screen print).

Mark

1024MAK · October 2014

Korinel wrote: »

Is there a way to test the capacitors in place?

For an exact value, no. For a indication, it depends on the circuit. For the Spectrum, it is not really possible to test the important electrolytic capacitors in circuit.

However, if you have a 'scope, you can investigate the voltage signals and this may indicate a problem. But I'm not convinced that it will show up your problem.

Having said that, a 'scope would show if the clock signal to the Z80 CPU was good or bad.

Mark

Spirantho · October 2014

This does sound like an interesting problem...!

For what it's worth I can fix it if you need me to, but I'd need to charge my usual ?30 fee and I suspect you want to fix this yourself... :)

What I would do though in this case would be to connect up the logic analyser and see if I can find anything squiffy with the clock and the /IOREQ lines....

Spirantho · November 2014

Sorry to reply to my own post... a little thought:

I have seen upper RAM chips fool the ULA into thinking lines of keys are held down. This would allow JetPac to work if it's only testing for certain keys. BASIC, however, would appear frozen.

My "testspec" ROM which can fit into a multiface has a little square at the top which constantly shows the ULA inputs. If I am right, then over time a white line will still start flickering in this box as the ULA data line is erroneously sent low. Eventually there will be a constant white line, and this line will be in the location of the dead RAM chip (i.e. if the line is in the far right column, it'll be the D0 RAM chip.

Can you burn an EPROM with my test ROM and fit it into a Multiface? If you want I can send you an EPROM with the correct program on.

balford · November 2014

It would be interesting to see if the interrupt rate is constant too. A test ROM that counts interrupts would show if there are too many or too little interrupts being received over time.

The zx-diagnostics test ROM I work on has such a test, but it's fairly brief and only happens for about 10 seconds or so at the end of the memory test.

I'll try and build a counter into that ROM's ULA test mode, sounds like it might be very useful in this case.

B

1024MAK · November 2014

Question: with Z80 code that runs on a suspect Speccy, how are we actually testing the timing/speed?
If there is a CPU clock variation all CPU cycles would be affected.
So it is better to compare to an external clock. But on a Spectrum there is only the 50Hz interrupt input. This then enables the CPU timing/speed to be checked. But both the CPU clock and the 50Hz interrupt are derived from the ULA internal clock circuit, which in turn comes from the 14MHz crystal...

Of course if the 14MHz crystal or the ULA's internal clock and divider circuits do strange things, it will mess up the video picture so should be detectable.

For a true timing test, a real external clock is needed.

Mark

Korinel · November 2014

Thanks for the replies all.

Thanks Spirantho for the offer of the repair, but yes I'm just doing this exercise to keep the kids entertained :)

With regard to the upper RAM theory, thinking about what you said, I suspect you are correct, the machine has not hung, it's just unable to read input from the keyboard and joystick.

I no longer have my Multiface :( the closest thing I have is the ZXC3, I can pop ROMs (or SNA/TZX) onto that and boot into it (which is how I normally run the diagnostic tools) would this be sufficient? I would love to use the Balford & Spirantho diagnostic ROMS are these available to download?

Other than that, we'll replace 7805, TR3, TR6 and see how it goes :)

As an aside the capacitor that leaked was C74, this is the one that sits by KB2 (which is what it leaked over) and TR5.

1024MAK · November 2014

I hope you cleaned all the leakage mess from the capacitor off the PCB.

You may have to desolder components to be able to complete the cleaning.

Slightly conductive contamination on a board can cause all manner of weird faults...

Mark

balford · November 2014

Korinel wrote: »

Thanks for the replies allI would love to use the Balford & Spirantho diagnostic ROMS are these available to download?

See my sig :)

B

Spirantho · November 2014

www.retroreview.com/iang/TestSpec4.zip

If you use it and need an explanation let me know. :) The box at the top centre should be all black except for ONE white line, which is the cassette input. If there are two white lines then a data line is held low when it shouldn't be, either by the ULA or a RAM chip.

Edit: You will also find the border interesting - it should keep changing colours. If it stops changing colour, then the CPU isn't running (or the I/O request to the ULA isn't getting executed) (Edit2) The changing colour is done by the IRQ, if that's of interest.

Korinel · November 2014

Thank-you gentlemen, both your tools highlighted something amiss :)
I'm not sure what the tests are telling me, perhaps you could enlighten me pretty please :) I also have no idea what to check/replace hardware wise now, any ideas?

balford - ZX-diagnostics

(As an aside, both the working and the faulty Spectrum+ had the same ROM checksum 7758 that was not detected as a 48K Spectrum.)

On my working Spectrum+ I ran the default five tests, all pass, I see the interrupt counter go from 0 - 0x2FF (ish) and then I receive the "pass".

On the faulty Spectrum+ I run the same tests the first four pass, however the interrupt fails to complete and the machine hangs at interrupt 0001.

Picture from the "faulty" Spectrum+

Spirantho -TestSpec4

Comparing the images produced by the working and the faulty Spectrum+ I see two differences:

1) On the working Spectrum+ the border is flickering with a very nice smooth multi colour border, however on the faulty Spectrum+ it is pure black and not flickering.

2) On the working Spectrum+ the inner picture has an additional "blob" on the top line in the centre, this is completely missing on the faulty Spectrum+.

Picture from the faulty Spectrum+:

Picture from the "working" Spectrum+

Spirantho · November 2014

Do you have a picture of the faulty Spectrum and its extra "blob"'?

Edit: do you mean the block at the top centre (the ULA input display block) isn't there at all on your dodgy one?
That means the ULA is getting logical low on all inputs all the time!

balford · November 2014

The counter hanging at 0001 indicates either that the CPU is no longer receiving interrupts, or some other problem has caused a hang.

I've added a new interrupt test mode to my diagnostics that should help with this further, if you download and burn the testrom.bin file, then start the suspect machine with the 'U' key held down, It'll enter a ULA test mode.

This should give you an incrementing counter as well as a live display of the bits read from the ULA (see here for more details).

This should tell us whether interrupts are missing or too numerous (FAIL should appear beside the counter) or whether the machine is hanging entirely (shouldn't be able to use keys 1 and 2 to generate tones and border etc.).

By the way, unless you're running on the Diagnostics Board hardware originated by Winston, the ROM checksum test will always fail as you've seen (as the test ROM can't page itself out to test).

B

Korinel · November 2014

Spirantho wrote: »

Do you have a picture of the faulty Spectrum and its extra "blob"'?

Edit: do you mean the block at the top centre (the ULA input display block) isn't there at all on your dodgy one?
That means the ULA is getting logical low on all inputs all the time!

Yes, I updated the post above with a new picture.

Once when I had finished taking the photo I had a brief flash of yellow and the ULA blob appeared, exactly as the "working" Spectrum but it had been on for several minutes before that happened and the border immediately went back to black.

Spirantho · November 2014

Korinel wrote: »

Yes, I updated the post above with a new picture.

Once when I had finished taking the photo I had a brief flash of yellow and the ULA blob appeared, exactly as the "working" Spectrum but it had been on for several minutes before that happened and the border immediately went back to black.

So it looks like any I/O requests are being given a data bus full of zeroes (which would give a black border).
Have you changed TR6 already? If this is an Issue 6 you may want to check the RAM controller chip too....

Korinel · November 2014

balford wrote: »

The counter hanging at 0001 indicates either that the CPU is no longer receiving interrupts, or some other problem has caused a hang.

I've added a new interrupt test mode to my diagnostics that should help with this further, if you download and burn the testrom.bin file, then start the suspect machine with the 'U' key held down, It'll enter a ULA test mode.

This should give you an incrementing counter as well as a live display of the bits read from the ULA (see here for more details).

This should tell us whether interrupts are missing (the counter should change to FAIL) or whether the machine is hanging entirely (shouldn't be able to use keys 1 and 2 to generate tones and border etc.).

By the way, unless you're running on the Diagnostics Board hardware originated by Winston, the ROM checksum test will always fail as you've seen (as the test ROM can't page itself out to test).

B

Thanks again :) I ran the new version of the ULA/Interrupt tests.

Again comparing the two machines, the 1,2,3 tests are the same on both Spectrums and the interrupt counter now increments, however there's one huge difference, the faulty one is churning through the full 0xFFFF interrupts in about 6 seconds. In the same time on the working Spectrum it churns through roughly 0x100.

So if my maths is correct, I guess we should have 50 interrupts a second * 6 seconds = 300 interrupts, which is 0x112 which is roughly what I saw on the working Spectrum.

So the faulty Spectrum is interrupting 239 times faster than it should be!

Korinel · November 2014

Spirantho wrote: »

So it looks like any I/O requests are being given a data bus full of zeroes (which would give a black border).
Have you changed TR6 already? If this is an Issue 6 you may want to check the RAM controller chip too....

No I've not changed TR6 yet and it is indeed a Series 6, the RAM controller chip that would be IC 27?

If I look at the Issue 6 schematic I can see it's connected to IOREQL (via R27)on the ULA, so if this failed I assume the ULA thinks that it needs to request an interrupt by some phantom hardware and so the ULA prompts the ROM to deal with it... and this is done 50 times a second until the ROM can't cope?

Spirantho · November 2014

Certainly TR6 would be my next candidate to check, as it's easier to replace that than a DIP-40 chip. :) If TR6 doesn't help, though, that chip will have to come out (can't remember if it's IC27 - it's the one with CF70001 or PCF1306P or ZX8401 or whatever on it).

balford · November 2014

That result with the rapidly increasing interrupt counter shows that interrupts are being triggered much more often than they should be.

This would account for the increased speed when typing (as the BASIC ROM's interrupt routine is being fired much more often than it should be, affecting the duration specified by the REPDEL/REPPER system variables).

It would also explain why the copyright text appears to draw slowly at times (as the interrupt routine is being called much more often, there's minimal time left to carry out tasks like drawing text etc.

Interrupts are generated directly by the ULA and are not influenced by TR6 (this only corrects overly aggressive IO contention - you can run a Speccy without it and you won't notice a difference until you plug in a peripheral). Same goes for IC27 - this merely replaces the RAM multiplexing and selection logic present on earlier issues. I would imagine a faulty ZX8401 would show up as a failed memory test.

I'd examine the traces between pin 12 of the ULA and pin 16 of the CPU - check for any shorts to adjacent traces. I think this line is picking up noise somewhere along its path :)

B

Korinel · November 2014

balford wrote: »

I'd examine the traces between pin 12 of the ULA and pin 16 of the CPU - check for any shorts to adjacent traces. I think this line is picking up noise somewhere along its path :)
B

You Sir are a gem :)

I found what I hope is the issue, this is the track you mentioned above that has been lifted :( and it's right next to the first capacitor we changed :(
Could you suggest how best for me to repair my cock up?

balford · November 2014

Cool, at least we've found the problem :)

Hard to see whether the track is still intact, but shifted up into the trace above. If this is the case, you can carefully reposition the track using the tip of a jeweller's screwdriver, and then secure using a blob of superglue.

If the track is broken, you can either make a point to point repair using some insulated wire on the underside of the PCB (easier) or by using a small strand of wire on the topside to recreate the track.

If you're using the strand of wire approach, tin it with some solder first, form it to the approximate shape of the section of track being replaced, then hold it in place with the point of the aforementioned screwdriver while tacking it down to each end of the trace with the soldering iron.

B

Korinel · November 2014

Sob sob...

So I did the screwdriver trick and both tracks moved really nicely back to their correct positions, I popped on a dollop of superglue to keep them in place. Then for good measure I cut with a scalpel either side of the tracks to make doubly sure there was no short. I air dusted to make sure any of the dried superglue with potential contaminant didn't land on something it should.

"edit": I plugged it in and now there appears to be no interrupts as neither the keyboard or joystick get a response, however twice I did get interrupts but it was the same really fast case I had before.

So next on my blame queue, both of which you can see in the above picture:

The capacitor C79 is sitting on top of the track quite tightly (this was the first capacitor my boy swapped) its insulated but would this this cause an issue?

R26 is very close to the lifted track and is part of the interrupt circuit, could this have got too hot during the desolder/solder and caused this issue?

I notice the interrupt line also goes to the edge connector I followed it there and couldn't find any issue, I assume this is okay as the RAM turbo works?

Simon_Carr · November 2014

Just a quick observation from your photo, but there seems to be very little solder on the positive pin for D9. Probably nothing to do with your other issues, but it is probably worth checking!

Weird symptom number 2...

Comments