I..Can..Almost..Touch..It.. - Torch Triple X - Part 9

And then I grabbed it firmly with both hands...

Ever since Part 8 of this series, I've been trying to get the Torch to accept the keydisk that would, in theory, lead to the system booting from the hard disk or BlueSCSI with a hard disk image. And it has steadfastly refused to do so.

What happens is that the system starts as expected:

Pale blue screen (red LED on the limpet board flashes as the RAM is checked too).

Pale blue.

A happy 'whooop' followed by a dark blue screen with the Caretaker version shown at the top

Someone to take care of me..

The hard disk starts loading and then...

"Gimme the key disk."

A demand to insert the keydisk, despite the keydisk already being in the drive. The drive stays silent and nothing happens. Initially, I had thought that some input from the keyboard would be required but no combination of key presses or button bashing would stir the drive into life. And this is where I've been stuck for over eight months.

My suspicion was that the OMTI board has a fault somewhere. I have tested every chip that I can, replaced those that I have stock of and checked the board for shorts or broken traces. So the only option I had left was to find another board. But these boards are the very definition of 'unobtanium'. 

** Sad face **

BUT..

Thanks to the most awesome Adrian at Binary Dinosaurs, I now have another OMTI 5200 disk controller board (on loan).

A brace of OMTIs Faulty on the right, working on the left. :)

First thing to try was to see if the OMTI would start when set as SCSI ID 0. My board would immediately come up with an error trap as soon as the memory test was done. And... success! Nothing happened except it said it couldn't find the drive - which is actually different to anything seen before. A good sign I think.

Oooh! Working as SCSI ID 0! Looks positive!

Next, it was time to try an actual floppy drive and, for the first attempt, I decided to use the drive that came with the Torch originally, which is the one I replaced the heads on. After re-wiring everything for power and data I put the super important and irreplaceable keydisk into the drive. Sadly, it didn't boot but most importantly, when the system reached the point of asking for the disk it actually tried to access the floppy drive. And then it reported 'Invalid key disc 7'. Woah! Progress. Sort of.

What's that you say? Invalid keydisk? You mean you actually looked for it?!

Then it was time to try the floppy drive from the Cifer. This is still a standard 5 1/4 inch floppy drive but with a simpler mechanism. I changed the ID of the drive to '2' (I'd already established any floppy drive needs to be ID 2) and plugged it it. And I got exactly the same as for the Epson floppy drive with the error 'Invalid key disc 7'.

GAH!

I had had an idea that I should be able to use a Gotek to handle the keydisk so I reached for the unit that had been in the Cifer and copied the floppy disk image files on to its USB memory stick. Another re-wiring session and I was ready to go. The advantage of the Gotek is that I have a small OLED display on the front and so I can see the track that is being accessed changing as the system accesses different parts of the disk. But there is a problem. The Gotek has jumpers to select unit ID 0 or 1 but not ID 2. Hmmm.

A bit of digging lead me to a website with a helpful diagram of the pinout of the Shuggart disk standard.

Floppy connections - I'm only into the bit at the top (Image from richardloxley.com)

This showed that pin 14 on the floppy connector, when grounded, would trigger unit ID 2 (or Drive C on the diagram). So I soldered a wire to pin 14 and, as luck would have it, there was a small pin connector on the other end which I connected to the ground pin of the 'Motor On' jumper. 

Wire soldered to pin 14 then connected to the ground side of the MO pin. Hey Presto! ID2!

This mod worked perfectly, and when the system started and got to the point of the keydisk check, I could see the different tracks being accessed. Sadly, I got an error box again. This time it said 'Invalid key disc 9'. Darnit. 

So, back to basics. I wondered if the key disk wasn't being recognised because I actually had the wrong disk image on the BlueSCSI. So, I tried two things. First, I created a blank image of about 50Mb and tried that, the idea being that the serial number wouldn't be on a blank image so maybe I would get to the point where it demanded an OS i.e. the floppies for Unix. But no, with the Cifer floppy drive re-installed, I still got 'Key disc error 7'.

Second, I tried re-dumping the hard disk using the excellent 'initiator mode' on the BlueSCSI. This requires two jumpers to be set on the board and the bluescsi.ini file to include 'Initiatiormode=1'. With fresh new disk image in hand, I tried again but, again, got the same error, 'Key disc error 7'. 

Then I wondered if the key disk was starting to have issues so I tried capturing it again using the (also awesome) Greaseweazle. I was surprised to see that the whole disk appeared red. Not just a couple of bad tracks, the whole disk was red as if there was nothing on it. And the I saw it... The arm that loads the heads has stopped working properly and was very effectively holding the top head away from the disk. Without the pressure from the top head, the bottom head was making no contact either, hence the apparent failure to read it. I tried again, this time I physically held the bar down while it read the disk. And it read perfectly!

Now I began to wonder what would happen if I turned the Torch on while holding the faulty arm in the floppy drive away from the head. So I tried it, and guess what...

It only went and bloody well booted!!

YYYAAAAASSSS!!!!!

I may have said several choice words at this point. The picture is genuinely the first time that this machine has booted in the 21st century. But I can't stand there holding faulty floppy drive mechanisms every time I want to boot. I must get the Gotek working properly. 

Now, I won't bore you with my efforts to try and get the system to boot with a Gotek for the key disk. Suffice it to say that I tried converting the newly captured .scp file to multiple disk image formats. And guess what... none of them worked. I tried them all and I even managed to get a custom definition into the Greaseweazle config specifically for the Torch but, no dice.

The only one that I hadn't tried was the default 'HFE' format that the HXC floppy emulator will happily export and import. So my final attempt, using the last (anywhere near relevant) file format was using the key disk in HFE format.

And that bloomin' well worked immediately! Aaarrrghhh!!!

But this is great news as it means that I don't have to have the bulky floppy drive in use when I first turn the Torch on, I can just use the Gotek. Nice!

Gotek display

So. Now what?

Well, the keydisk has been put back into storage and locked away. There are multiple copies of the keydisk image across a few of my devices so I should not lose it now, no matter what. If I feel inclined soon I might just try and create a new floppy from the HFE image. Maybe.

And why don't we see what the Torch does when it's finished booting up? 

Oh.

Not much.

No icons on screen. The kernel window has some useful information but once it's closed there's nothing else there. Right clicking doesn't do anything (this was 1985 for goodness sake - no context menus here..) and there's no menu at the top. Very odd.

So, I suspect that this machine is either not booting correctly, or is actually doing something in the background like a good 1980's workstation. If it's not finishing booting correctly it could be because it's not a fan of the BlueSCSI but I doubt that as it has worked flawlessly so far. Hmmm.

I have another Torch disk image that I genuinely cannot remember where it came from. It has the word 'portable' in the filename which will become important later. So, I copied it over to the BlueSCSI and tried again. Almost straight away I got a 'Icon file corrupted' error. I clicked the little box and it disappeared but the immediately re-appeared and I clicked it again. This wasn't looking good. But then, just like before, it just booted!

This time, underneath the Kernel window, a terminal had opened up and was waiting for a login. So I chose the most logical name for a Unix user - 'root'. And it let me in with no password! Awesome!

It's a Unix system! I know this!

There's still a lot of stuff to do. Here's my list:

• It sometimes boots in low res with a dark grey screen and sometimes in hi-res with a white screen - possible memory issue?
• The main image I dumped boots but no icons appear and there's no apparent way to do anything - may need to reinstall Unix. Eek.
• I tried re-formatting the drive image using the disk utility on the keydisk and re-installing but the formatted image does not work as expected - possible BlueSCSI foibles? Or dodgy disk handling program?
• Tried reinstalling Unix 'over the top' of the existing image and the initial boot disk image runs but then data gets copied to it and it runs out of space before it can continue - why would it do that?
• Even the portable image that ends up at terminal window still has no icons. Why is that?

In the meantime I solved the 'icon file corrupted error' on the 'portable' image but I did this by 'reinstalling Caretaker' from the key disk. This clears the error but has the side effect of tying the image to the keydisk which then makes it not so portable...(sorry Nigel.)

I also managed to work out the fault on my original OMTI board. By means of a simple chip swap session, the second chip I tried turned out to be faulty. It's the 20506-2 which is the memory buffer/controller for the board. There may or may not be a replacement chip on the way from a far away land.. 

What a last few days! Special thanks to Adrian (binarydinosaurs.co.uk) for all his help and especially for trusting me with his working OMTI 5200 controller. I could not have done this without his help. Check out his website!

More Torch shenanigans next time. 

A Festival of Retro Stuff in 2025. RetroFest '25!

Years ago, one of my colleagues came into the little office I occupied with another colleague and excitedly told me he'd just got some great concert tickets.

"I'm going to Manic Street Preachers at the NEC!" he said.

"Wow, great! I'm going to the NEC soon, too." I replied.

"What are you seeing?" came the logical question.

"Oh. Bear in the Big Blue House..."

Bear!

The reason I tell this story is because the Crashed offspring have left or are getting ready to leave home so I no longer have to admit to anyone that my weekend would consist of being entertained by an 8-foot Disney bear who has a mouse and a teddy for friends. And not forgetting Luna of course. (The highlight of the trip was buying a pair of 'Bearnoculas' so Crashed Jr1 could see the stage properly. 😊 )

Instead, I can tell people that I went to Swindon to spend my Saturday in a huge room filled with lots of old computers. Yay!

RetroFest '25 is the first event (of many I hope) at the STEAM centre in Swindon. In case you hadn't guessed STEAM is a railway museum which looks great although, this time, I didn't go in to the museum itself. 

The event took place in a single large room off to the right of the museum entrance. A goody bag was handed to me as I walked in. Mrs Crashed got one too, so that was double swag for me. 😊  If you are into your retro computers then you would recognise a fair few of the attendees, if not by sight, certainly by name.

Binary Dinosaurs (https://binarydinosaurs.co.uk) was my first port of call. I wanted to say hello as Adrian had been a big help in my efforts with the Torch XXX and it was good to meet finally. He had several rare machines on display including the Jupiter Ace and Lambda IQ8300.

The Ace is an oddity from the 1980's as it actually uses 'Forth' as it's built in language rather than BASIC. No doubt the team behind it felt that BASIC was not the way to go(to) - see what I did there? - and that we were all really maths nerds at heart. It failed and, as per the info on Adrian's site, the company went under a year or so after release.

I have to be honest that I'd never heard of the Lambda computer at all. It is basically a clone of the ZX81 with a slightly better keyboard. 

On the picture you can also see the Laser 200 with a current status of 'cursed'. 😄 This one is still not working despite Adrian's best efforts!

And, last but not least, the Commodore P500, a MOS 6509 machine that disappeared quickly as the sales of the Commodore 64 accelerated far in excess of Commodore's expectations. A super rare and interesting piece of Commodore history (and an early sign of CBMs potential for management idiocy...).

Old (but gold) computers

Lisa. A computer priced as if made of gold.
(c$31,000 when released!!)

CPT 8250

The display of the CPT also features a subtle Easter egg for anyone who follows Usagi Electric on YouTube. I wonder if he ever realised what an impact a programming error might have on us retro nerds?

'hellorld'

Next I managed to get a demo of a prototype unit that interfaces into a CPC46x machine over at the Flamelily table (https://shop.flamelily.co.uk/). This little unit allows disk images to be used simply with the Amstrad. Other than my lack of experience using disk commands on the CPC machines (it was noisy too and my middle aged ears struggled to hear a couple of instructions) it looked great and I can't wait for the final product to be available as my CPC is one machine that has not had much love recently.

My arm trying to type on the CPC.

By this point it was getting very busy so I didn't get too many more opportunities to talk at length with anyone but I did see several familiar faces and a familiar hat. I said 'Hi' on the way past.  

Lee from "Lee Smith's Workshop",
and Yawning Angel Retro from
er..."Yawning Angel Retro" 

I did manage to get a demo of the Prestel and Micronet setup which was very interesting. As the flyer said, "Online shopping before the internet". The history is really, really interesting and shows how the UK was at the cutting edge of online services, even before the French minitel. I guess we just weren't ready for it ("But your kids are gonna love it" - Marty McFly, November 1955).

Micronet, Prestel et al.
I always wanted to get on to Micronet...

One thing I did notice as we wandered around was that there were rather a lot of Sony TV/monitor units. I assume because they were a very handy size of CRT. And I completely agree. I have a six inch Sony TV that is really handy for plugging composite into. Mine is certainly missing some of the inputs of the ones in use at the show, but it's a Trinitron and it's aweswome. I digress..

Some more photos of the excellent exhibits:

Commodore Max - A precusor to the more successful 
Commodore 64

Atari 2600 (heavy sixer?) with CompuMate attachments.
A membrane keyboard is supplied with the cartridge that has
BASIC, Music Composer and Magic Easel 
(source: Wikipedia)

A barrel load of EPROM readers/writers and other cool
stuff including a couple of Newbrains (top right).
I actually have a DataMan S4 next to my bed (true story).

A Torch Unicorn - effectively a hard disk
for the BBC Micro. My Torch Triple X comes
from the same stable (ya think?)

A more 'modern' Atari. Still about 30 years old!

VT2500 Terminal. A classic.

The Grand-daddy of them all. The Altair 8800.
This one has a cool perspex case so you can see all the S100
bus goodness. Nice.

Various early games consoles including (L-R):
Philips G7000, Philips G7400, and Creativision.

That's a lot of calculators. I think one of these 
models got me through GCSE maths...

Commodore SX64. The screen quality really
is quite something given its age!

Bright and crisp. A great CRT display.

Time to get (Psion) organised. I have some of
these in the garage with loads of programs.

Very 80's. A Vectrex vector based games system and an
Apple Macintosh. Special appearance by the Amiga 600
sneaking into the side there.

'Swag' from the show, including the
BluesSCSI v2 I bought from Flamelily.

I had a great time at the show. Next year I might head over for the Sunday when things might be a little bit less busy than the Saturday. But it was well worth a visit and, most importantly, I got to meet Binary Dinosaur who is lending me something precious that might give me an exciting update on the Torch XXX. Watch this space! (And the PCBWay pens are awesome!)

Haven't We Been Here Before? Cifer RAM Shenanigans

You'd think that after showing the Cifer some love it would appreciate not being in a skip and show a bit of gratitude. Sadly, it didn't for a couple of reasons. First, the RAM failed again. Second, it is not a corporeal being no matter how much I try to anthropomorphise it (but I know he's mocking me).

Garbage! Argh!

This is absolutely the same type of fault it had when it first arrived and, also more recently, when I tried to get him back up and running after he'd been lying on his side with his guts hanging out for about six months...

So, back into the depths. I removed the bottom cover, then the 68K board, the graphics board and the auxiliary board to reveal the main 'motherboard'. Thinking that it could be one of the other boards that had a RAM problem, I tried switching it on with just the main board installed but I still got the garbage on screen. This means that it is absolutely one (or more) of the eight RAM chips on this board. Darnit.

The offending RAM on the bottom right. Not an MT chip
in sight though.

Out came the homemade RAM tester and every chip was tested. You can imagine how annoyed I was that every chip tested OK. Does this mean there's something else that has gone wrong? I hope not..

Digging through my Box'o'Bits(R), I found a couple of spare RAM chips that were not MT (I still don't know where they came from - some rotten *** sold them to me I think) with the idea to replace one chip at a time to see if all of those chips really were working.

With the 'new' chip in hand I replaced the first chip. No change. So I took the first chip and used it to replace the second. No change. Then I took the second chip and replaced the third and...

It's alive! (Again - but for how long?)

..that was it! The third chip I took out was faulty. Just to be sure I marked it and re-installed it and, sure enough, the garbage returned. Why the RAM tester did not highlight this chip as faulty I don't know. I thought I might have to go back and re-write the tester 'c' program that was installed on the Arduino clone that is the heart of the DRAM tester. The original version of the program is now, sadly, lost to a hard disk failure many years ago but I do have the code it was based on (or more accurately 'shamelessly copied from'). The big disadvantage of my tester, other than it seems to think a faulty chip is OK, is that it's really, really slow. It typically takes about 50 seconds to check one chip. Multiply that up and even testing a relatively small number of DRAMs can take some considerable time. 

While wondering if there was any way to improve the code that I technically no longer had, I stumbled across a YouTube video on a channel called 'Trevor Makes'. In this video he described exactly the issue that I had with the RAM from the Cifer i.e. my quick and dirty tester showed it as OK but, once installed, it was clearly faulty. His version of the DRAM tester takes a different approach and uses the 'March C-' algorithm to quickly check a DRAM.

I don't pretend to understand much about the March C- algorithm. A quick Google just highlighted the most basic of explanations - which comes down to "it's fast" - and a lot of technical documentation with odd notation that is clearly logic based. Suffice it to say that it's fast, and it carries out tests that cover all fault conditions on the chip (as per Trevor's video - code on his github page).

Anyway, I decided to re-configure my current DRAM tester as it was clearly giving false positive results - could it also be giving false negatives? (Foreshadowing...ooooh!)

I shan't bore you with the details of re-wiring a circuit board. It's not a great spectator sport but, suffice it to say, I did it and I double checked it. Then I triple checked it. All connections were as per the diagram on the github page so all that was left to do was to reprogram the Nano clone that formed the brains of the outfit. And that was a where things went a bit wonky.

Programming an Arduino of whatever vintage/provenance can be done using the official Arduino software and this was what I had previously used with my DIY tester. This particular project though, is built using Platformio with Visual Studio Code. I'm reasonably familiar with VSC but I'd never used it for programming any type of embedded system before. Fortunately, Trevor Makes has a video for that too and, after a little bit of head scratching (I had to change the default platform to 'oldnano'), I managed to get the code compiled and on to the tester.

First test, I put the faulty chip into the socket and plugged it in. Red LED lit almost instantly. OK so far. Then I put a known working DRAM chip into the tester (the MT4264 - don't judge me). The red LED lit almost instantly. Oh. That was unexpected. So then I went and got my small collection of working DRAMs. Every single one came up as faulty almost instantly. Something was not right.

I decided to check the address lines that were being used on the DRAM and I immediately found the problem. The lines A0 and A1, which connected to the D0(RX0) and D1(TX1) on the Nano, were both being held high. All the other address lines were showing the expected typical activity. So why are these two lines being held high? The answer was in the primary purpose of the pins i.e. RX0 and TX1. These pins are connected to the Nano's UART and, to use them for any other purpose than serial connections, requires that the serial device is disabled in the code. I am not an expert in programming C++ or Arduino, rather I am an enthusiastic amateur, so I have no idea if the switching off of the serial device was included in Trevor Makes' code.  I knew I could at least try adding the code that Google's AI helpfully suggested, which would definitely switch the serial off in the 'initialisation' part of the code. And this, I duly did.

Additional lines of code circled red.

Another build cycle with the revised code was completed and after uploading the update firmware to the nano, I put the working MT RAM chip into the socket and switched the tester on. The first thing I saw is that all four LEDs on the Nano board itself lit up. This matched Trevor Makes' video which I took as a good sign. And then after a second or so the green LED lit up. Yes! This DRAM is, according to this new code, working. 

The light is green, the trap is clean.

I set about testing the latest dead DRAM from the Cifer. Bear in mind that the old version of the tester said that this chip was fine and dandy but if it was in the Cifer, it would not boot. Within a second, the tester told me what I already knew. This DRAM was dead - the red LED lit up. Excellent. I tested all of my remaining known working DRAMs and they all came up green so I could fairly confident that this is now working as expected.

This version of the tester has a couple of major advantages over the old version. First, it's fast. It really is. A 4164 1 bit 64k RAM is tested in just over a second, while a 41256 1 bit 256k RAM takes about 4 seconds and it's intelligent enough to know which type is inserted (4164 or 41256). Secondly, there are two distinct modes that this test can use. There's the standard test mode which I'd been using up to that point, but there's also a timing test. By switching one of the Nano pins to ground, the firmware copies a checkerboard pattern into the chip and then cycles round, reading the data back in a loop. With a strategically connected two channel oscilloscope it's possible to calculate the access speed of the RAM - handy to check if second hand chips have been 'altered' to make them seem better than they actually are.

Just on a hunch, I pulled out a big batch of 'failed' Hitachi RAM from the 68K board in the Cifer. Out of 15 alleged failed chips, 13 chips tested OK. I need to validate this somehow and it might end up with my taking a couple of the apparently working chips and throwing them into the Cifer to see if they really are OK. 

13no DRAM chips tested OK. Hmmm.

But now, with a vastly improved DRAM tester, I can go and check every RAM chip that is in the Cifer. RAM appears on the main board, the auxiliary board and the graphics board, and so there's plenty to go at. 

While I was at it, I 3D printed a new version of the rather basic case. My latest filament is Amiga beige but it'll do. I also added an 'on/off' switch since I also decided to add a fixed USB cable to drive the tester. Very handy. The power switch is the one at the bottom and the 'mode' switch is at the top. These were the only switches I could find in my Box'o'Bits(R) but they work fine.

"New case, who 'dis?"

Interestingly, I checked the 8 RAM chips on the Cifer graphics board (Tetronix 4010 emulation) and, would you believe it, one of the chips tested faulty. The auxiliary board has 32 RAM chips so that will have to wait until I have a little more spare time. 

Last act of defiance - adding an MT RAM chip
back IN to a vintage computer. Sue me.

So many RAM chips, so little time...

And there you go. I'm very pleased with the updated DRAM tester and even more pleased I didn't throw away all those chips that the old tester claimed were faulty. Nice.

DARK IN HERE, ISN'T IT? - Death, The Light Fantastic

Darnit. I thought that quote was 'Quiet in here....' but there you go. I've been quite quiet recently, mostly because this thing called 'real life' has the audacity to get in the way of generating high quality, vintage computer related, web published articles. As Crashed Jr (an avid gamer) once said, "I went outside once. The graphics were amazing but the game-play was shit." A regular modern day philosopher (and I know he shamelessly pinched that from somewhere on the internet).

Anyway, what's happening? A few updates:

Torch Triple X

I received several more replacement chips to try swapping on the OMTI disk controller board but to no avail. I've said before that I don't like throwing parts at a problem but this one is so annoying I couldn't stop myself. Sadly, the new parts - a Z8 Romless microcontroller and a floppy drive controller chip made no difference. 

You can see which chips I have replaced or managed to test off the board from the pic below. There's not a lot left to try other than the two PLCC socketed OMTI chips. If they're faulty, then the board is completely toast. 

Green - chip replaced
Orange - chip removed and tested OK

Just in case that it was actually the floppy drive causing the issues I also tried hooking up a Gotek to the OMTI board, but no joy. The unit sits there with no interaction shown on the OLED display at all. Nothing, nada, nil, zip, zilch etc, although with a real drive I have noticed that the floppy drive light does pulse almost imperceptibly and regularly so perhaps all is not lost.

To try and analyse the SCSI activity the most excellent Adrian at Binary Dinosaurs lent me a 16 channel logic analyser as he too has a Torch Triple X. I have certainly learnt a lot about SCSI in general while poking away at some of the trace files I have pulled off but I have not yet managed to get the one SCSI decoder that is available (which takes the analyser output and translates it in to more readily readable SCSI commands) to work - yet.

There was a another glimmer of hope recently when I realised that the BlueSCSI that is currently working fine with the TripleX also supports floppy drive images i.e. it can pretend to be a floppy controller on the SCSI bus. However, the issue we have with the Torch is that it expects the hard disk to be on SCSI ID 0, LUN 0 i.e. the first sub-address on SCSI address 0. But then it also expects the floppy drive to be on SCSI ID 0, LUN 2. 

Gratuitous floppy shot.

The current BlueSCSI software favours only LUN 0 on each SCSI ID although it is possible to 'force' the filenames of the disk images to be the LUNs. But, as described by the BlueSCSI chaps on BlueSky, it's a bit of a hack. Changing a simple parameter in the .ini file activates the option as well as another parameter for an option to use 'quirks' related specifically to OMTI disk controllers. But sadly, at the moment, this is not working and no matter the various configurations I've tried, the key disk remains resolutely unseen. 

That's not the end of the BlueSCSI floppy though as another chap popped up on the VCF forums who also has a Torch Triple X (or at least the motherboard for one). He is looking at the code for BlueSCSI v2 - avaialble on github - to see if he can update/modify/patch the current code to specifically cater for the Torch. If I had the knowledge and capability I would be pitching in with this but, given my limited exposure to coding in anything but BASIC or Python, I'd just be peering over everyone's shoulder asking "What's that bit do?".

Cifer

Ah, the Cifer. After repairing another broken logic chip on the keyboard and another failed RAM chip, everything seemed to be back to normal. But, guess what. In the spirit of vintage hardware keeping everyone on their toes, it's failed again. 

Working. Now, not working. :(

It basically keeps munching through RAM chips. I had it running CP/M and left it on for a while as I was doing something else. When I came back to it, the screen had locked up but was still displaying everything normally. So I switched it off and back on (ha, the more things change, the more they stay the same) and rather disappointingly, the display appeared blank. Closer inspection showed that it was on, but very faint and showing garbage. Yep, another RAM fault. 

Suspicious power supply. Are you responsible for killing
all my RAM chips? Well? Speak up!

I do have suspicions about the power supply. It's the only thing I can think of that would keep blowing up the RAM although I do still need to work out exactly which chip is affected. If it's in the same position as the last one then I might drag all the boards out to check for unexpected shorts etc. I have been considering a Meanwell supply to replace original but I'm not sure if that's feasible although the current supply is a very similar form factor. We shall see..

Christmas (very seasonal..)

Not necessarily retro but an interesting project fell into my lap around Christmas. For 'reasons' I ended up with two rolls of remote controlled LEDs (from Menkind). Now, being a bit of a tinkerer there was no way I was just going to let them live happy lives with their built in controller and IR remote. One roll would be sacrificed to the great gods of tinkering. 

First things first, what sort of LEDs do they use?

Hmmm. Are these WS2811/WS2812 LEDs I see before me?

Dunno. They're too bloody small but they 
look like they could be.

A small section was cut off for experimentation purposes. One Raspberry Pi and three dupont connecting wires later and:

Ohh! Pretty!

Looks like we have a successful test. :)

For a long time I've always wanted to have a go at the DIY Christmas decoration that was highlighted by the RasPi guys several years ago. Fortunately, the article for that is still up here. In fact, it was 10 years ago! Holy cow. 

Anyway, here's some pictures of me setting it up:

Designing the scrolly message.

First few strips mounted.

Original wire connections - but later changed!

All strips mounted, awaiting wire connections.

The board was a piece of hardboard, about A3 size, from Hobbycraft. I cut the LEDs into strips of 12 LEDs and mounted 8 strips (so 12x8). My handy staple gun fired staples that just straddled the rubbery LED strip making it really easy to fix to the board, along with the adhesive on the back.

Initially, I tried to use some offcut mains cable to join the stretches of LEDs but the wires were too stiff so that hour or so I spent soldering them onto alternate ends of the strips was a bit of wasted time. But no matter, I found some thinner core wire that was much more appropriate and easier to handle. 

For power I used the end of a broken micro-USB cable i.e. I chopped the knackered end off and then wired up the +5v and ground to the end of the first LED strip. I also attached a second connection to the ground so I could plug in to the ground pin on the RasPi GPIO. As I'm using a relatively short section of LEDs (no more than 96) I can get away with connecting the ground but there would not be enough to power the LEDs from the Pi. So by attaching the USB plug I can either use a chunky power bank or simple USB charger plug.

With power and ground connected I just needed to connect up the data pin. I basically copied the original article so I'll let you go and read the details over there.

Once it was all connected up and power applied I ran the AdaFruit LED test program and....

Rainbow!

Rainbow! But with the colours slightly changed!

...it just worked! Nice!

So then I shamelessly blagged the code from the original article and loaded up the included test .png. I did have to make a couple of tweaks to the code to match exactly the LEDs I had. For some reason, my LEDs did not like the RGB order in the code, which meant the colours were all wrong. But it was an easy fix in the code and only took a couple of minutes of pondering to work out what was wrong.

And the results are:

This would definitely benefit from some sort of diffuser in front of the LEDs. If I can be bothered before this Christmas (only 298 days to go!), I might even 3D print something to put each LED in it's own compartment to make it even clearer. We shall see.

Sadly, it looks like the LEDs I used are no longer available if you fancy a go at doing this yourself. But there are later versions with 2m strips for £10 and I think they use SMD5050 LEDs (mine were two 5m reels for £12 each with WS2812 LEDs) which might work. YMMV. All the details of the project are in the original article. But some handy hints I found with this LED strip:

1) The clear rubber needs to be removed from the contacts before you can solder to them. They need to be clean so make sure you get it all off.

2) On the subject of contacts, make sure when you cut the strips, cut in the middle of the contacts that appear between the LEDs! It doesn't matter too much if it's not exactly in the middle but you could end up with one strip that's dead easy to solder wires to, and one that isn't. Ask me how I know.

3) The board I used was this one from Hobbycraft.

Merry Christmas!

Xbox Controller (Again)

Repaired Crashed Jr's Xbox controller AGAIN. That boy (also known as 'the cable slayer') could break a cast iron skillet..

Once again the joysticks in the unit failed and, once again, I had the joy of stripping it down and taking the old joysticks out. I've done it so many times now, it only takes about half an hour and that's including making sure that the damaged traces from previous repairs, don't get dislodged.

Someone's been in here before. 
Oh, yes. It was me...

Bodge wire to fix a previously damaged
trace - these things sink a lot of heat!

No bodges, but more super hot fun.

Normal service will be resumed soon! I hope...