Weird behaviour with simple BASIC program

[Bobbi]

I am in the process of testing out a 'new' BBC B. Machine works fine in general and games from the MMIO all seem to work.

However ... this simple BASIC program sometimes runs 'forever' but sometimes just stops at some random point ...

Code: Select all

10 I%=0
20 REPEAT
30 PRINTI%;" ';
40 I%=I%+1
50 UNTIL FALSE

For example running this earlier, it ground to a halt around 32,000 ... Hit Break, OLD and ran it again and it went further (until I got bored and hit ESC.)

Seems super weird.

[Bobbi]

I should add this is an issue 3 Beeb B with MMFS and DDFS installed (probably going to pull out DDFS, but haven't done it yet).

Things like Elite and Revs seem to run fine, so I think the hardware must be fine.

[FourthStone]

Apart from the typo in line 30, it runs fine in BeebEm, haven't got any real hardware out atm to test anything else.

Code: Select all

30 PRINTI%;" ";

[Bobbi]

I had some other odd results with code with REPEAT / UNTIL FALSE. It is not consistent or repeatable though. I am planning on yanking the DDFS ROM and testing some more. Right now I have a weird config with DDFS v1.54T and MMFS filing systems. When it does 'stop' though it is not a hard crash and there is no sign of memory corruption. Break resets and OLD brings back the program. Usually it terminates with a nonsense error message.

[Bobbi]

I have something that fails pretty consistently for me now. I don't think it is related but this reproducibly fails on my Beeb:

Line numbers omitted cos I am lazy:

Code: Select all

I%=0
REPEAT
IF I%MOD2 THEN PROCON ELSE PROCOFF
PROCWAIT
I%=I%+1
UNTIL FALSE
END
DEFPROCON
*MOTOR 1
ENDPROC
DEFPROCOFF
*MOTOR 0
ENDPROC
DEFPROCWAIT
LOCAL X
FOR X=1 TO 100:NEXT X
ENDPROC

If the delay in PROCWAIT is short, this fails quite fast. Either it just stops like nothing happens or it displays a nonsense error on the line after one of the *MOTOR calls. One time this was a Syntax Error, a few other times it was nonsense BASIC keywords. System is fine afterwards. Program is intact. Can run again, and fail again.

If I crank up the delay the failures seem to stop.

No idea what is going on. Even in cases where it is failing we are turning the relay on and off around 1 - 2Hz. Not super fast.

(I started doing this to test the mystery of why my Cassette Motor LED doesn't light up.)

Oh ... and also if you modify the code so it is two calls to *MOTOR 0 or two calls to *MOTOR 1 (ie: it doesn't toggle) then it runs fine, no error!

EDIT:

I managed to get some memory corruption running this code. A '@' character was inserted into the BASIC program before *MOTOR 0, which is probably a null where it should be a space $20.

I reduced the loop limit to FOR X=1 TO 10:NEXT X and it crashed pretty hard, writing garbage to the screen and locking up. Ctrl-Break recovered and OLD brought the program back.

My working theory is that there is some sort of short circuit which is why my cassette motor LED does not illuminate and maybe when I toggle the relay fast it leads to a lot of current draw, volts drop and things get flaky. I can't find my DVM or I would do some more testing tonight.

Machine otherwise runs fine so I think the issue is limited to the cassette relay. I can see it toggling back and forth so the transistor must be okay.

[BigEd]

Might be worth retitling the thread: what you have here is an unreliable machine, so it's time to start digging into hardware hypotheses.

As it was unreliable even running a Basic soak test, I'd probably be inclined not to look into the cassette motor relay question until later. Although it's possible you have a relatively straightforward power supply problem: the 5V supply is too low, or is noisy.

(It is interesting that a simple soak test showed up trouble when games didn't. Letting Elite run the attract loop forever is one test I've seen used.)

[Bobbi]

Maybe I should move this to a hardware channel ...

One thing that occurred to me is that the system is not grounded (earthed.) I wonder if that could cause issues.

[Bobbi]

I have had Elite running in attract mode the last hour or so and it is seems pretty rock solid.

I may need to get this machine on the bench with my scope and DVM. The issue looks to be related to power somehow from past experience with other machines ... I think toggling the tape relay too fast causes noise on the power rails and things go a bit flaky. I think I read somewhere that the Beeb somehow uses the BRK handler for handling runtime errors in BASIC, so maybe it is reading BRK ($00) spuriously when the power rails go bad. Speculation only.

First I am going to get a more respectable video cable rather than the taped-together lashup I have right now. Also I am going to fix the grounding ... I am using a travel adapter which doesn't connect the earth pin. Can't see how that could cause issues though.

[sweh]

You may want to ensure all the 5V and GND connectors are making good contact to the motherboard (there are multiple of them, to try and avoid voltage drop). If one of them is loose/broken then you might get inadequate voltage across the whole motherboard causing intermittent failures, especially when a high load like the cassette relay is being driven.

[Bobbi]

Hi Stephen,

I was thinking about that. I did yank them all off to remove the PSU when I did the 110VAC conversion. If one of them were loose it could cause weird symptoms.

Is there any documentation of expected behaviour if one of the three red/black pairs is not connected? I assume they all connect to the same 5V and GND plane so it's nothing as stark as the memory having no power or something

Elite attract mode is still running BTW.

[sweh]

Is there any documentation of expected behaviour if one of the three red/black pairs is not connected? I assume they all connect to the same 5V and GND plane so it's nothing as stark as the memory having no power or something

It's as you guessed; nothing obvious

[Bobbi]

I checked out the voltages and the +5V looks good at all 3 points and also the -5V looks good.

Machine is completely solid if I don't toggle the relay like crazy. It an early machine, Issue 3, if that makes a difference.

[MartinB]

The relay has a diode, D13, across the coil to suppress back-emf high voltage spikes from the latter during relay operation. If the diode has degraded or failed or is poorly connected, the 5v rail could experience transient perturbations which might upset other aspects of the machine. Just a thought given the apparent relay-triggered failures.

Edit : I’ve also just noticed your thread about the associated cassette LED having failed. A non-functioning relay diode could contribute to premature failure of any closely coupled semiconductor devices such as the LED.

[BigEd]

Elite attract mode is still running BTW.

OK, that's interesting: it doesn't mean you have a reliable machine, as you've already shown you don't. It means Elite attract mode isn't a good test for your particular machine's defect.

So, go back to a test which fails, check that it still does fail, and proceed with the hardware investigations.

(It might even be worth a new thread, where the head post can say what you've seen and what you've measured. Edit: which includes your observations about the relay, but I think you're still saying that your original programs are unreliable anyway?)

[1024MAK]

I’ve moved this topic into the 8-bit Acorn hardware section, but left a shadow topic in place in the original section.

There are some points worth making.

When a relay energises, a relatively large current flows for a short time to build the magnet field. This is substantially more current than any of the semiconductor chips draws when any of them change logic state (unless lots of pins of a 6522 VIA are connected to external devices that draw lots of current and they all change state at once). If the electrolytic capacitors in the PSU are on their way out, or there is a slightly poor connection in either the relevant +5V/VCC or the relevant 0V/GND connection, it’s possible that this is causing some voltage drop (reduced supply voltage) for a very short time. A meter will be too slow to show this, but a oscilloscope would show it.

The relay being operated will also cause electrical noise on the supply network. Especially if the electrolytic capacitors are degraded.

In the issue 4 and issue 7 boards, all three of the +5V/VCC supply points are linked together via PCB tracks. But the three red supply wires provide low impedance current paths.

Earlier issue boards (issue 1, 2 and 3) were designed for use with the older conventional PSU type (often called ‘linear’) that were used before the switch mode PSU (SMPSU) were made standard. There were at least two versions of this earlier PSU. One version used three 7805 voltage regulator chips. These are not recommended to be operated in parallel. Each of which is rated at 1A. So Acorn separated the circuitry into three groups, hence three red wires suppling +5V/VCC and three black wires for the 0V/GND. Although all the 0V/GND connections are linked via PCB tracks, the three black wires are still needed.

The -5V supply (purple wire) only supplies analogue circuitry, so you can ignore this for digital circuitry faults.

When a relay coil is disconnected from the supply voltage, the collapsing magnetic field induces a high voltage in an attempt to keep the current flowing (called back EMF). Hence why there is a diode in parallel with the relay coil. This clamps the voltage by providing a path for the current to flow. If the diode is faulty or there are poor connections (dry solder joints), the LED may die, as they don’t like reverse voltages above 5V. Sometimes the transistor that switches the relay coil will also die or be damaged. So it’s well worthwhile renewing the diode (D13, 1N4148), the LED (‘standard 5mm red LED) and the transistor (Q3, BC239 but any small signal general purpose NPN transistor with the same lead out will do) regardless.

Mark

[Bobbi]

Thanks for your comprehensive analysis!! I have to say it sounds about right to me. If the diode were bad (or has a dry joint) then there would be a big fat back EMF from the relay which could kill the LED. Also, that big fat back EMF could well cause a big hiccup on the power rails sufficient to crash the machine.

If it only happens when I whammy on the relay it is not a big deal I suppose -- I don't plan on using cassettes too much However I do plan to fix this in due course cos I am OCD about this kind of thing.

Right now I am verifying that the machine is 100% stable if I don't touch that damn relay. Konrad Zuse is spinning in his grave

[Bobbi]

Oh something else I should add ...

I yanked out the WE DDFS 1.54T ROM because I am not using it (I use MMFS) and I think having both raises the PAGE. I also reseated the BASIC ROM. A loose BASIC ROM would account for flakiness in BASIC but not when running machine code games.

Since I reseated the BASIC ROM everything seems to be stable (aside from the relay issue, which is unrelated.)

[MartinB]

Thanks for your comprehensive analysis!! I have to say it sounds about right to me. If the diode were bad (or has a dry joint) then there would be a big fat back EMF from the relay which could kill the LED. Also, that big fat back EMF could well cause a big hiccup on the power rails sufficient to crash the machine.

You’re welcome!

We’ll have to wait and see if it is that though, I was only guessing at the diode but the idea does does stand up to technical scrutiny.

[Bobbi]

After my little fixes (reseating the BASIC ROM, pulling DDFS) I am retesting the simple loop in the first post of this email.

So far, so good. Has been running an hour an a half and I% is up to 421,000 or so ....

[BigEd]

Hurrah!

[Bobbi]

Gonna leave it running a good while since I am paranoid now. Up 588,000 now.

[MartinB]

At whatever point you declare success and press Escape, but before you switch off, try one of your *MOTOR ditties again to confirm that you still have the (possible) relay-induced issue. If it doesn't fail, before you further celebrate, switch off and try again when the Beeb has fully cooled down.

[Bobbi]

Once it hits 1,000,000 I am going to repeat this test in Mode 0. Is Mode 7 right now.

[Bobbi]

1,100,000 and change after nearly 4 hours, and still going.

Hit Escape, MODE 0 and RUN again.

[Bobbi]

OK, ran to 1,000,000 in mode 0 without any incident. That is eight hours of soak testing. Going to call it case closed for the original problem.

The tape relay problem remains, but I will fight that battle another day.

[1024MAK]

So one problem was possibly poor or dirty connections on the BASIC ROM.
Honest, that’s never happened before

Mark

[Bobbi]

Going back to the relay / cassette motor LED problem ... I found this note in the Service Manual as a change from Issue 3 to Issue 4 (page 32):

The position of D13 was changed to put it in parallel with the relay coil rather than across the collector and emitter of the transistor (Q3).

So it seems the protection diode was incorrect. I guess I will mod the circuit to put the diode in parallel with the relay coil as intended, then replace the LED.

Looking at the circuit diagram it seems that in Issues 1 - 3 the diode was between the collector of Q3 and 0V (the emitter) rather than 5V (the other side of the relay.) I guess Cassette Relay LEDs die a lot on early issue machines!

[MartinB]

Good news in a way. I was confident that this had all the hallmarks of a relay diode issue but I’d missed the nuance of your machine being an Issue 3 where, as you have discovered, the diode is present but is not optimally positioned to suppress relay-induced back emf. It will be interesting to confirm when the diode is correctly fitted (maybe replace it anyway while you’re doing the job?) whether it has fixed the original program crashing problem - I strongly suspect it will.

[1024MAK]

Hmm, I hadn’t noticed that Acorn had dropped a clanger with this simple circuit

You really do learn something new every day

When I find my issue 3 board (It’s in storage somewhere, I just can’t remember which storage box it’s in ), I’ll have to check mine.

So as it turns out, most of the 8 bit computer manufacturers dropped clangers with at least one of their designs or with production issues or quality issues... [the list so far includes Acorn (multiple counts), Amstrad (multiple counts), Commodore, Memotech, Sinclair (multiple counts) and I’m sure there are others...].

Mark

[Bobbi]

Commodore certainly made some ooopsies! The Apple II (and and also the //e) seems relatively free of layout mistakes and likewise.