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...