Sunday, 22 June 2025

Corn Cob LED Bulb Repairs

I like things nice and bright when I am working. I have a three way light fitting in the workshop ceiling, and had been using standard candle bulbs.

I was looking around in .....checks jungle website history..... 2021 and found these listed as "LED Corn Bulbs 26W 200W Equivalent".

They looked like they would do the job, so I ordered the pack of three bulbs.

And wow, they are bright.

The corn cob bulbs sort of fitted with the flowery light shades left there by the previous owner. Bit of a hint of Day of the Triffids. But the important bit was the workshop was lit up like an operating theatre.

Those are on about 18 hours a day, 365 days a year, and they lasted about two years before the first one failed.

Not bad, I'll take that for about £5 a bulb. At the time, I just ordered another pack of three and replaced the dead one.

I am sure you know I am not the sort of person who throws anything away, so I had kept the dead bulb "in case they came in handy one day".

They are made from a series of surface mount LEDs, and I couldn't see any that had gone black, which would indicate an bad LED. With LED bulbs like that, you know it's probably bad electrolytic capacitors. But you also know they are sealed, and you can never get them back together again, so no way to repair them.

Out of curiosity, I decided to have a go at taking the dead one apart.

(I might have taken pictures at the time, but I can't find them now, so this is another one I took apart later.)

I cut into metal bayonet cap, but realised afterwards that it would have actually unscrewed.

And within, was something wrapped in yellow tape.

And there were the capacitors that were probably the issue.

There didn't seem any point in fixing that as the bayonet cap was mangled, but I ordered some replacements (2.2µF 400V and 6.8µF 400V) and eagerly awaited the next one failing.


A month or two later, the second one failed, and I much more carefully attempted to unscrew the cap, and got it off in one piece.

I replaced the failed electrolytic caps, taped it back up, screwed it back together and it worked, so put it back into the pile to use next time, and I still had one more new one.


Much time passed, and after another year, two more had failed, and I replaced those with the other new one and the repaired one.


Another year or so passed, and about a month ago, one more failed, but it was the one facing away from the desk where I worked, so I just left that as I was busy with other things.


Finally, the last of the new ones went, leaving only the one I had repaired, so time to repair the rest.

I started with the two recent failed ones (as I had yet to find the two which had failed about 2 years ago).

The first one I opened was not a good start, the wires fell off the LEDs.

They were soldered all the way at the top.

Little change of getting the wires back in those holes, and also no way to solder from the top.

I did not look like the clear plastic cover would come off. Later on, I did try cutting a hole in it, but the board was damaged where the wires had come off.

When I unwrapped the board, the wrapping was flaking off the capacitors and came away with the yellow tape.

Maybe I will have better luck with the second one?

This is not going well is it? There is also something else wrong that you can just see on this picture

On both of these, the wrapping had started to come off the capacitors, but I was able to read the values from the remnants and they were the same as the previous one.

I tested those and found the values all low (2.14µF for a 6.8µF cap), but the ESR was off the scale. >20Ω not seen that before.

I fitted the replacements to one, but when I was checking it over, I noticed the IC.

Bang. That doesn't look good. Big hole in the chip.

Oh well. Never mind, I have the board from the one where the LED connection broke.......

Oh dear, that has gone bang as well, and also seems to have a hole in the current sense resistor.

Zero out of two. Not a great start.


Later on, I found the other two bulbs that had failed a couple of years ago.

I wonder if those will be any better?

I carefully unscrewed and unwrapped those.

The capacitors looked in better condition here, with the wrappings intact.

The other one seemed a slightly different design with a pair of current sense resistors in parallel.

The driver chips looked intact, so I removed the caps.

These were a little better, but still off the scale on ESR.

Looking at the pile of dead caps now, I see that the larger caps were all 6.8µF 400V, the smaller ones were not all the same, I have one 1µF 400V, one 3.3µF 250V and the reset were 2.2µF 400V.

The replacement 3.3µF would have had too wide a lead pitch, so I went for the 2.2µF 400V for the smaller caps and 6.8µF 400V for the larger ones.

I used some nice Nichicons. These are 105C rated for 10,000 hours (that's about 2 years at 18 hours a day).

The larger cap is mounted with the leads bent. I tried to raise it up away from the IC to match the height of the other cap.

I rewrapped those in capton tape and closed them back up.

I did think about using glue or threadlock, but they seem to lock well enough and can be fitted and removed from the holders without unscrewing.

I tested those and both worked, so I put those back in service.


Not bad, two out of four this time, that's a 50% success rate. I might be able to resurrect one more of them if I get some replacement chips.

"and the other one"

Sorry?

"remember the first one"

Oh, OK, good point, I fixed that, so that's actually three out of five. 60% success rate. Better.

"no, the actual first one."

Oh, great, the one I couldn't fix because I cut the cap off. Now we're back to three out of six. 50% success rate. You're not really helping here.

"yeah but the board on that one...."

Oh yeah, thank you for reminding me.

I searched around and found the bits of that. The LED section was fine, and the chip on the board was intact. I replaced the capacitors and wired that to the bayonet cap from the one with the blown chip and snapped LED wires.

OK, better, that's now four out of six. I would like to see anyone repair incandescent bulbs like that.

I wrote the date on for reference, so I knew which ones were which.


Those should last me another couple of years.

I did actually order another set of these yesterday, since I know I can keep them running and I like the style.

There seemed to be quite a variation in the design.

I noticed on that last one that it appeared to be missing the flyback diode

I did think about stealing one from the other board, but the BP2861 datasheet I looked up didn't show it as being required, and it appears to work fine without.

The ones with the blown chips both had those diodes, so it is not as though they had helped.

They have followed that reference design, but have used a wirewound resistor on the "live" input (it could be live or neutral, depends which way you put the bulb in the holder). 

They have also added a mov across the input.

The transformer on there is being used as an inductor, so winding insulation is not an issue as it would be with something like a 5V USB supply.

The metal case of the bulb is not earthed, no surprise there. It is isolated by the screw on part of the base.

It shouldn't be in contact with anything. If the insulated wrapping were to break down, it might end up live, but you wouldn't be anywhere near touching it unless you were reaching to the far back of the bulb holder and had left the light switched on.

Worse case the wrapping would break down and it would short in two separate places, that should cause the fusible resistor to blow (assuming it is actually fusible....), and very worse case would trip the lighting RCD.

Either way, it seems these should be OK to keep using. Nothing in there that would make me nervous to reuse them. (but obviously, use common sense, don't follow my advice on anything like this, consult a qualified electrician and only buy quality bulbs from a reputable supplier).


I noticed some were missing the R1 resistor to pin 2, which is shown as not connected on the BP2861, but does appear in the datasheet for the BP2866 which some of the other boards have.

None of these datasheets seem to have suggested value or any information about how to calculate them.

There were also some boards had two current sense resistors in parallel.

There is no consistency, it seems like they just grabbed whatever looked about the right sort of thing and jammed it in there. That's just the way these things are unfortunately.

At some point in the future when this round of replacement caps have failed, or more chips have blown, I will do another batch of repairs.

In the mean time, I have three bulbs in use, one spare repaired unit and an assortment of spare parts.

  • One good LED module
  • One LED module with broken connections
  • Two controller boards with blown chips
  • One slightly mangled bayonet cap

The Bright Power (or Bright Power clone) chips they use is the sort of thing you can find on ebay and Ali express, but not at Digi-Key or RS or anywhere like that. I suppose I could order some chips and they would probably work again.

I would be tempted to design a new PCB that would slot into the case better, I could mount the caps closer to the top which is facing down the way I have them mounted, so should be a little less hot.

I would need to find a suitable driver chip from a reputable manufacturer with a properly specified datasheet, but there seem to be an ever increasing number of options there.


Advertisements

I normally work on old computers, or new things for old computers, such as these:

ZX80, ZX81, Commodore PET and Jupiter Ace compatible computer kits

https://www.tindie.com/stores/tynemouth/

Patreon

You can support me via Patreon, and get access to advance previews of blog posts and behind the scenes updates. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

Sunday, 15 June 2025

A ZX81 game on a ZX81 emulator on a Jupiter Ace emulator on a Windows emulator

When I started working on ZX81 BASIC for the Minstrel 4th, I had a fairly clear idea of what I wanted to get working, and also what I did not expect to work.

As is often the case, my target was to get 3D Monster Maze working. I knew that would require slow mode, and that was going to be a challenge, but I thought that should be achievable.

I knew that games that use various high resolution graphics techniques on the ZX81 were not going to work. The display was generated in a such a different way, it was not going to be transparent, if even possible at all.

When I got it working, I went through the list of games I expected to work, and they all did, with one exception, Tut-Tut. I did not understand that, it _should_ have worked.

It's sequel, Minoss Knossos worked fine, and many similar games also worked, but Tut-Tut didn't.

What would happen is the text of the title screen would start to appear, and then the screen would be overwritten with a repeating pattern and it would just lock up.

I needed to debug what was going on to try to find a solution, either:

  1. Fix the ROM code so the original game could run unmodified
  2. Produce a custom build of Tut-Tut that would run

Ideally option 1, but option 2 if necessary.

A great option for debugging things like this is the EightyOne emulator. This can emulate the ZX80, ZX81, ZX Spectrum, Jupiter Ace and many variants and similar systems.

I had been able to use it to debug the ZX80 BASIC for Minstrel 4th.

That is running with the hardware set for a 48K + 3K Jupiter Ace, and the 8K Ace ROM replaced with the new one ZX80 for Minstrel 4th ROM.

The ZX81 version wouldn't work directly for a couple of reasons.

The Ace ROM is 8K, so it is easy to swap that for another 8K ROM.

The original ZX80 ROM is 4K, so that left 4K for the new display code and LOAD and SAVE functions, which was more than enough space.

The original ZX81 BASIC ROM is already 8K, and I needed to add some functions. I was making use of the extra 5K ROM I had cheated out of the Jupiter Ace memory map for the Minstrel 4th.

The 5K is in an area where the Font RAM is write-only, so nothing would happen when you read it, and also an area where the base 1K of RAM is mirrored 3 times, and I don't think I found anything which needed the mirrored versions.

That fitted quite neatly, if you write to $2800-2FFF, the font RAM is written. If you read from $2800-2FFF, you get the extra ROM.

That is understandably not supported in EightyOne. To get around that, I tried an alternative build of the ZX81 8K ROM by taking out the trigonometry functions that take a lot of space and were not required for 10 PRINT style programs.

That left enough space to add the new display routines in to gap where the trig routines were.

I tried that, but it didn't work. I wasn't sure why, at the time I think I had seen it going into the floating point number routines and assumed I had cut out something it needed.

By that point, I had the full 8K + 5K ROM working on real hardware, so I didn't spend any more time on the trig-delete version.

But now I need to do some debugging, so time to revisit this.

The EightyOne project is open source, so I thought I could add in support for the extra ROM space.

My results vary with building open source projects, so lets see how I get on with this one.

Oh, OK, it's built using Borland C++ Builder. Wow, that used to be my job for a couple of years, Delphi and C++ Builder, but I don't think I have touched either for about 20 years.

The project documentation was excellent. There is a lot to do to setup the build environment and various dependencies, but it covered all the steps in detail, and it all worked.

The project successfully complied first time. Very impressed. Credit to Paul Farrow for that.

Now that I had it building, time to adapt the code. Adding the 5K was slightly complicated by the way the memory is arranged, there is a 64K array covering the whole address space and the ROM is loaded into it, and optionally it can be made writeable.

On the Jupiter Ace, the various disparate sections of ROM and RAM are all part of this same memory array, but I need to have writes going to font RAM, and reads coming from the ROM for the overlapping section.

The easiest option seemed to be creating a separate array for the font RAM, as that is only used in the memory write routine and screen draw routines, so it was easy enough to change those.

With that change and the code rebuilt, I was able to start testing, I got the initial banner, but then the screen went off.

The banner routine is in the extra ROM, so that is apparently working. It took me a while to figure this one out. Looking at the memory monitor, I saw that it had written some extra characters after the last line. I had miscounted and it was copying an extra line. (I think I had it correct originally, but it got set one off when I was trying to optimise that code).

It shouldn't make any difference, and indeed it does not on the Minstrel 4th hardware, as this is running fine on that.

The Ace has a requirement that the byte directly after screen RAM, $2700, should be 0. The Ace hardware uses this as a sort of null terminator. (it is also used by the optional colour hardware to control a latch if a value > $7F is written there, which was was happening here)

The Minstrel 4th does not care about that byte, so does not check it.

When I fixed that, I got a K prompt, and it was apparently working until I tried to type a line of code.

Slightly odd, it sort of rolled up like it does on the ZX80 and then locked up? I wouldn't expect the Ace to do that, it should always generate a stable display.

It took me a while of debugging and trawling through code to find it, but I finally spotted some code in the emulator which detected the start of a SAVE, when it hit certain addresses it would start recording, and would duly stop drawing the screen to make sure that went as planned.

The code in those locations in the ZX81 ROM was actually part of the floating point number parser, so when it hit that point, the emulator would think a SAVE was happening and start to process that, including stopping the display and jumping over some code.

I temporarily commented out that checks and that fixed it.

That is probably why the trig-delete version of the ROM was failing previously.

OK, next is LOADing files. I expected this was going to be tricky, as it was designed to load Jupiter Ace files, although it did support ZX81 .P files in ZX81 mode.

I wonder if it will just work?

Can't hurt to try.

It did not initially work, but I tried turning off turbo load and auto load and playing it in real time.

No way.

Well I'll go to the foot of our stairs.

So that is the unmodified ZX81 version of 3D Monster Maze running on ZX81 BASIC for the Minstrel 4th running on a Jupiter Ace emulator running on a Windows 7 emulator running on a Linux PC.

Very impressive that the emulator will do that without any idea that anyone would ever had a need to load a .P file into a Jupiter Ace.

Time to give Tut-Tut a go.

Ah, I guess that is good. It does the same thing as the real Minstrel 4th hardware. The number of letters it prints before locking up seem related to how fast it runs, I found a line in the Z88DK code which might explain that - from gen_tv_field.asm "ZX80 (and ZX81 in FAST mode) trick to try to keep the display stable. This subroutine should be called in theory after every 1475ms".

It starts to print the credits screen, that should say "ZX81KEYBOARDADVENTURES", then it gets overwritten by a repeating pattern.

Then it just locks up.

I didn't know why this happens, it's sequel Minoss Knossoss works fine, and that is also built using Z88DK.

Right, now I can debug this. Wish me luck.

Many thanks to David @ZX81KeyboardAdventures for help with this and supplying the source code so I could see what was going on and build test versions.

Or at least I could if I could get the compiler for it (Z88DK) to build......... I try not to say anything negative, so I will just repeat how well documented the EightyOne code was and how setting up the build environment and all the dependencies for EightyOne worked first time.....

Anyway, I finally gave up and downloaded a Z88DK Windows pre-built binaries package.

I was then able to build versions of Tut-Tut and Minoss to try to see what the trigger was.

It didn't take long. It was printf. That was not used in the later game, but was one of the first things in Tut-Tut.

I got it down to a test program with just a main function with a single printf and then a while loop and it broke in the same way as the full game had.

That simple program was almost 4K - there was a lot of library code along with the printf.

I stepped through the code, trying to see what was the problem.

Then I spotted it. The code was reassigning the IY register for it's own use.

On the ZX81, this is set to $4000, the base of RAM, and used to simplify access to the system variables which are stored there.

One such access was in the display routine.

BIT     7,(IY+$3B)

This is doing a test of bit 7 of the CDFLAG variable at $403B.

That is fine as long as IY stays at $4000 as it normally does, but the code used by printf was changing it, so that line was actually testing bit 7 of the wrong bit of memory (sorry, the wrong byte of memory).

Based on that, it was thinking it was in FAST mode, rather than SLOW mode.

That meant it would go on to the display routine, and not POP the saved registers off the stack.

Next time around the loop it would again test the wrong location, and leave another 12 bytes on the stack.

And so the stack would go downwards through all of RAM, with a repeating pattern of 12 bytes (4 register pairs and two return addresses).

I should have recognised that, seems obvious now.

I replaced that with two instructions that did the same thing, but with a hard coded address and so no reliance on IY (and in 5 bytes and 21 cycles instead of 4 bytes and 20)

LD      A,($403B)

BIT     7,A

Let's see if that helps.

No way.

You're kidding me.

That was it.

That was what was causing the problem.

I have expanded one of the flowcharts from the previous post.

The test in the IRQ handler (right) was working correctly, and pushing the registers onto the stack each frame, but the test in the display routine (left) was looking in the wrong place and going down the wrong path and not poping the registers back off the stack. So the stack just kept growing and growing until it had taken over the world. (Well, until it filled all the RAM.)

Side note: the screen looks a little grey, that is because it is running in inverse video mode. In ZX81 mode, it is non-inverse, so has a bright white background.

The Jupiter Ace is meant to be white on black.

So the choice is yours.

Well, it would be if I were to publish this. It would be nice to add the Minstrel 4th option to the official build of EightyOne, and maybe the Minstrel 2 and 3 as well, although I don't know how much use that would be other than to a couple of people working on the ROMs.

But that's not the end, the final thing to test the full experience, loading Tut-Tut from the ZX81 tape into a Minstrel 4th?

OK, here goes.

After a little fiddling with the levels, I got it loading, the countdown helps to see it start moving.

Almost there.

Great, that's working nicely.

A ZX81 game, loaded from tape into ZX81 BASIC for Minstrel 4th.

More updates

I have tweaked a few more things. I had previously displayed the "mists of time" screen whenever FAST mode was enabled, but I have now changed that to only when it is activated using the "FAST" command.

That should be less obtrusive in the short bursts when processing a line of code being added, but still be there to cover the big gaps like generating the maze in 3D Monster Maze or drawing the map in Perilous Swamp.

By the way, when it says "TO START PRESS ANY KEY"....

It actually means "PRESS ANY KEY EXCEPT SPACE BECAUSE THAT IS BREAK AND IT WILL STOP THE GAME", but I guess they didn't have enough space to fit that all in.

Still, it allows you to have a look at the game in BASIC, something I spent a long time doing back in the day.

And since it is BASIC, you can just start it again with RUN.

You might think the player (the X in the top left) is trapped there, but in this game, you can move diagonally.

Still didn't help me rescue the Princess though. Maybe next time.

Another issue I was able to track down with the debugging environment was an occasional glitch, where the LOADING .... box is not display, just the countdown.

That was due to drawing that before switching to FAST mode, so occasionally the screen would be redrawn after the LOADING box had been drawn.

That has also been fixed. It only seemed to happen in NTSC mode. I wouldn't recommend using the ZX80 or ZX81 ROMs in NTSC mode anyway. The timing is different, and most software will be expecting the PAL 50Hz timing.

The big delay at the end of the display routine was tweaked to make it match 100% PAL ZX81 speed - at least according to the CLCKFREQ program I have been using, does anyone have any suggestions for other benchmarks I could use to double check?

However in NTSC mode this delay makes it run about 1/3 the speed of a ZX81.

For reference, a real ZX81 in NTSC mode (i.e. a TS1000) reports about 1/2 the speed of a ZX81.

This is just in SLOW mode, FAST mode performance is identical.

On the ZX81, there was a jumper that set a bit on the keyboard / tape input port. The software would read that and adjust the screen timing accordingly. There is no PAL/NTSC jumper on the Jupiter Ace.

There was an NTSC version, but that had either a different PCB or a modified PCB to rearrange the counter logic to change the framerate. Because of that, there is no easy way for the software running on the Minstrel 4th to know which framerate is selected to adjust the delay. Maybe it could count frames and clock cycles to detect and adjust it's delay accordingly?

I have updated the ROM to V1.4, If anyone is interested in testing this, I have posted the ROM on my Patreon. It is still experimental, but seems to be working.


Adverts

This Minstrel 4th (with the updated ROM including ZX81 BASIC) is available as a kit or built and tested, from my Tindie store.

It is now also available from Z80kits.com, home of the RC2014. 


There you can get a bundle with the Minstrel 4th, RC2014 backplane and whatever modules you wan to go with it.


Patreon

You can support me via Patreon, and get access to advance previews of development logs on new projects and behind the scenes updates. New releases like this will be notified to Patreon first, if you want to be sure to get the latest things. This also includes access to my Patreon only Discord server for even more regular updates.