Hollywood or Dust: Episode 5 – Fashionable

[Repairing the PSU from an SGI Iris Indigo R3000]


After replacing damaged diode CR111, it’s time to reassemble the PSU and give it a try. Reassembly is a bit easier than disassembly, but still very fiddly, especially getting all the spade connectors back where they are supposed to be. Needlenose pliers are needed, and some patience, and a willingness to poke fingers into the internals to get the plastic system-connector-plug back in its’ slot.

The crap semi-internal bolt I had to drill out in Episode 2 has been replaced by a proper steel hex-driven bolt, soooooo much better!

As this is a “smart” PSU, I cannot test it in isolation – it needs some output load before it will do anything, so let’s get it fitted back into the Indigo.

Barebones Power-Up

Fitting the PSU back into the case is very easy – it just slides in on rails into the top right of the case, as viewed from the front, then is held in place with a single screw at the back of the case.

Next step was to power-up the Indigo with just the CPU board, without the graphics board and drives installed, after unplugging everything else in the house, just to make sure the repaired PSU wasn’t dangerous and wouldn’t freak the mains power supply. Went well – fan spins, no burning smells, no sound of capacitors popping, and no smoke!


Next it was time to try it with the system-boards installed. Unfortunately, I had misplaced the SGI-special keyboard cable, in spite of having the actual keyboard to hand. No problem, let’s just try with a serial console instead… unfortunately, Indigo requires a rather special serial cable, which I had also misplaced.

The Indigo doesn’t have DE-9 or DB-25 serial connectors. Oh no, that would be far to straightforward. Instead it has mini-DIN sockets for that. This was fashionable for about 2 years in the early 90s in the UNIX workstation world – the actual cable I was looking for was my Sun serial-adaptor cable for a SPARCstation-2, which uses the same pinouts as a “proper” SGI one (which I don’t actually own). I keep dreaming that, like flared trousers, mini-DIN serial connectors will come back into fashion, “any day now, you’ll see!”

After hours of searching through boxes, bags, drawers, the top of cupboards, et al, et al, I found the darned cable on a bookshelf. Dang! Time to get my trusty P3 laptop computer out, to act as the console. Oh yes, I’ll need a null-modem serial convertor as well, which gives me an excuse to get ye olde serial breakout box into the project!


For those of you that don’t remember 15-pin D-shell Ethernet sockets, you need an external transceiver (formally: “Medium Attachment Unit”) to convert it to more common form such as RJ-45 or 10Base2. A widget like the CentreCOM 210T…

Let’s Go


Unfortunately, when trying the PSU for real, under load, the signs were not good. It couldn’t see the SCSI hard-disk drives, much like before, even though their LEDs were lit. It recognises the SCSI floppy-diskette drive, but that only needs the +5V rail. Sounds like the missing +12V output is still, well, missing. Mind you, at least you can hear the funky Indigo power-on sound in the video.

Time to probe the actual PSU output voltages.


On the SGI indigo, the HDDs are mounted on slide-in sleds, which breakout the SGI-custom backplane connector into a 50-pin IDC SCSI ribbon and a 4-pin molex connector. Armed with an empty drive-sled, I now have probe points to check both the +5V and +12V rails, via that molex connector on the sled.

Hmm, with the CPU board and both a SCSI HDD and SCSI FDD installed, the nominal +12V line is showing only 3.51V. With just the CPU and FDD drive installed, we have  2.38V. With just the CPU, we have 2.49V. What the heck! There is obviously some other fault with the PSU, not just the dead zener diode that was replaced. Just to be sure, I probed the other line in the molex connector (should be +5V), and hey presto! it shows 4.97V Рwhich proves I knew which line was which, no mistakes there.

More Repairs

One other person has noted that capacitor C127, next to oft-failing zener diode CR111, is directly linked in series with CR111. Although C127 is not showing obvious signs of damage, I thought I could just see a slight bulge in the top wrap-over plastic coat. Maybe C127 needs replacing too?

I was not completely convinced, but with time running out for RetroChallenge, it was at least worth a shot.

However, replacing a radial capacitor (when you can’t get at the legs) is way more tricky than working with axial components where you have full soldering-iron-access to all the important bits. Eventually, it was a case of ripping the damned thing out by force, then desoldering and removing the stumps.


One replacement 22uF 25V aluminium electrolytic capacitor later, and we have… no change at all, exactly the same behaviour as before. Shucks. There are obviously other things wrong with this PSU, things that only a complete re-cap and re-power-transistor are likely to resolve. Unfortunately, that is way beyond my capabilities. This particular RetroChallenge project is complete, but failed.

It appears that the only way to get this Indigo working again, is to obtain a fresh 25-year-old PSU. Time to give Magnificent Mr. Mapleson a call!


Hollywood or Dust: Episode 4 – Vitamin E

[Repairing the PSU from an SGI Iris Indigo R3000]

The postman has delivered my replacement 1N5352 zener diode (actually three of them, I figure this might take a couple of tries, and I might need another one for a subsequent repair in another 25 years).

Vitamin E

However, before wielding the soldering iron, I am going to clean the internals of the PSU case and boards. As noted previously, there are some metal particles scattered around from previous grinding etc, as well as some concretised dust.

The toolset for such cleaning consists of a soft paintbrush for the bulk cobwebs, a medium-stiff toothbrush for the concretised dust, cotton buds for the hard-to-reach corners, and some physically strong moist wipes (with volatile moistness, not just water) to encourage lift-off.

When it comes to moist wipes, the local supermarket offers two choices: with cucumber extract or with vitamin E. No “bog-standard plain” ones. So I am going with vitamin E version, it seems just a bit more definite than the rather vague “cucumber extract”. As an extreme long-shot, vitamin E is a natural antioxidant in the human body, perhaps it will also help prevent rust in the PSU… ūüėČ

The Other Kind of Flat Head

Those toothbrushes aren’t ideal – these days getting a proper old-skool 1970s-style “flathead” toothbrush is not all that easy. These days there all kinds of wild-and-wacky¬† brushhead shapes and profiles – ergonomic for cleaning teeth (minus any snake oil of course), but for scrub-cleaning flat plastics, metal casings, and even the odd solder-pad, a good flathead plastic brush is easier and more effective, in my experience. But needs must, so I had to manage with the Junior Sparkie BRIGHT brushes.

Inversion Not Welcome Here

Next, I need to install and solder the replacement 1N5352 diode. When reinstalling electronic components in a PSU, it’s always good to have as many photographs of the original internals as possible, from a wide variety of angles. I had to refer back to an earlier photograph to make sure which way around the replacement 1N5352 diode needed to be – get it the wrong way round, and a possibly life-threatening explosion could result, as well as possibly blowing fuses and even damaging other equipment in the house, which would be even more unappreciated!

The photos are also useful for checking exactly which spade connector goes onto which lug, and so on, when reassembling the PSU.

A New Hope

When soldering-in the new 1N5352B zener diode, I deliberately arranged it to lie 2mm above the PCB, rather than flat against the PCB, as it was originally – if the reason the original diode blew is due to a PSU design issue, I want to avoid a second such diode-failure event from further damaging the PCB if possible – it’s had a hard enough life already.

Thanks to leaded solder, a bit of liquid flux, and the Metcal iron, installing the new 1N5352 diode was very quick, straightforward and easy. Not much to say here, so let’s look at the result:

Looks OK from here. Note that the vast majority of the discolouration and other damage on the PCB was caused by the original failing diode, not my soldering (which is not expert, but is also not that clumsy!).

Making the daring assumption that nothing else is wrong with the PSU internals, this “should” do the trick and result in a running SGI Indigo R3000… but I think I’ll wait until the house is empty (tomorrow) before risking tripping the mains power.

Hollywood or Dust: Episode 3 – Just Another Sucker On The Vine

[Repairing the PSU from an SGI Iris Indigo R3000]


After two weeks off from Retrochallenge due to other commitments, it is time to re-energise this project.

I need to remove the obviously-broken diode CR111 from the large PCB, (a) to see which exact model of diode it is, so I can order a replacement, and (b) to see what other damage, if any, lies underneath it, or nearby.


De-soldering components it not something I have much experience of, but armed with a Metcal 200 soldering station, I was hoping it would work out OK. After a bit of reading about desoldering, I figured I should get a solder-sucker too – a tool to remove freshly remelted solder.

There are two overall kinds of solder-sucker:

  • High-End, Expensive: all-in-one tool that provides an electric heater to melt the solder; and also incorporates a vacuum pump powered by an electric motor, to suck the melted solder away from the component concerned;
  • Cheap-And-Nasty: a spring-loaded vacuum pump that sucks only – you need to heat the solder with a separate soldering-iron.

No prizes for guessing which one I went for!

Pentax Digital Camera

This really is low-end – extremely thin metal body, plastic piston, etc. The whole thing weighs less than a pencil. It feels like it would bend in half if you just looked at it wrong.

More Hands, Please

Given my soldering skills are rather poor, this could have been an “opportunity” to really damage the PSU…

This counts double because using a separate non-integrated solder-sucker
can require you to use three hands simultaneously: one to hold the sucker (and poised thumb over the release button), one to hold the soldering-iron, and one to hold the expansively-populated board still whilst you do the necessary. I suppose on a small sparsely populated PCB you could use a vice or even a couple of books to fulfil the “holding” function, but with this particular beast of a PCB, that wouldn’t work too well.

For through-hole components, there is a trick that can help: deploy the sucker on the “lead” side, and apply the soldering iron to the “component” side of the PCB, and press them together to hold it all still whilst doing the deed. Like so…


For small blobs of solder or small leads in large holes, this works well. I know, I practiced on some scrap perfboard. For the largish blobs of solder holding thickly-leaded CR111 in place, this only really does half the job – it doesn’t suck the solder all the way through from the “other side”.

Thus I had to resort to the “standard” technique as documented all over YouTube: prepare the sucker in one hand, close to the joint, but not actually on the joint; apply the soldering iron to the joint until the solder melts; then very quickly remove the soldering iron, deploy the sucker and hit the release button.

And then the most important part: repeat, repeat, and repeat again until bored – you usually won’t get all the solder in one go.

The Result

I managed to remove the damaged diode without scorching the sucker nozzle, and without getting melted plastic or detrius on the iron tip. This is a testament to the Metcal iron – tip heats up extremely quickly, and maintains heat even in the face of plenty of melted solder which is doing it’s damnedest to solidify again.

Mind you, due to the odd minor slippage hear and there, there are one or two marks on the solder-mask on the back side of the board – but fortunately, nothing too serious (most of the solder-mask damage was already there due to the way the diode had originally failed).

So what do we have? Closer inspection shows CR111 is a 1N5352B 15V 5W Zener diode, as suspected. A replacement, rated for use up to 200C (well, better safe than sorry), has now been ordered, awaiting delivery.

Any Other Business

At least one other person repairing the slightly different R4000 Indigo PEC 4044B PSU has also had to replace the nearby electrolytic capacitor C127 (which on the 4044B is a 35V 120uF capacitor, but on the 4044A is a smaller 25V 22uF capacitor). C127 on my PSU appears to be completely undamaged, so I am going to leave it be for now.

Then there is the tiny ceramic capacitor right next to and alongside where CR111 used to be (see above pictures): that must have been subjected to a lot of heat when CR111 died, due to proximity, but it too appears to be working as best as I can tell (using a very rough-and-ready capacitor-testing method with both a digital multimeter and an analogue current-tester). In principle, due to the heat it must have endured, I perhaps should replace it anyway, but given that actually getting to it is also very difficult due to adjacent components on one side, I’m going to take the chance that it is still OK, at least until proven otherwise. It’s not liquid-electrolyte-based, after all.

Summary: digikey.co.uk are now at-bat. I wonder how big a box I will receive this time!

Hollywood or Dust: Episode 2 – Zarking Genius

[Repairing the PSU from an SGI Iris Indigo R3000]

More Investigation

In the last episode, I managed to extract one of the boards from the PSU and found it to be in superb condition. But what about the other, larger PCB? Although I could see parts of it “in-chassis”, I really needed to remove it to be able to inspect it fully, and to have any view at all of the non-component side.

Hey, removing the other, smaller board was pretty straightforward, so this should just take a jiffy, right?


Unscrewing the three screws that attached the board to its’ cylindrical standoffs was easy enough. The screws are crap, soft metal, perhaps aluminium? You have to be a bit careful not to knacker the screw-heads – gently, but firmly, does it!20170905_201207

However, in spite of doing so, the board would not move, neither slide-out nor lift, not even a bit. Dammit, there is another “attachment” that needs to be dealt with, on the outside of the chassis…

That darned hex-nut, and it’s location, is a royal pain. After 25 years, it has welded itself to the large solder-pad on the PCB.

I dug out my hex-driver sets, only to find that they were all Imperial rather than Metric, and this sucker needs a 4mm driver. A visit to the hardware store didn’t show up any as small as 4mm, not even rummaging through their behind-the-counter “special stash”. Fortunately, the local petrol-station has its’ own hardware tool shop, including precision tools, so I was able to pick up a set of hex-drivers that included a 4mm driver.

However, that didn’t actually help. This particular hex-bolt is sooooooo low-profile that any regular hex-driver just won’t grip it properly. The usual solution to that situation would be to apply a lot of downward pressure, but this damned bolt is made of some really cheap and nasty soft metal, and I nearly stripped it’s hexiness. Plenty of cursing ensued!

Given its’ location, getting even needlenose pliers or a needlenose wrench onto it just won’t fly – you can attach, but there just isn’t enough room to rotate it! There isn’t even enough room to saw-cut or file a straight slot into the head (to be able to get a flathead screwdriver to turn it).

All together now, loudly, with feeling: “Which zarking genius designed this damned arrangement?”


The only solution was to grind the head off the bolt, using a Dremmel fitted with a rather narrow-tip grinding head, being very careful not to wreck the underlying PCB…20170910_120302

Not too much scraped, considering the confined working-space, although some metal particles were scattered over the back of the board, which will thus need cleaning.

The remainder of the bolt (thread body still in the hole) still needed removing. Cue a naked junior-hacksaw blade and plenty of patience, to cut a slot in the barely-protruding top of the thread, to be able to get a small flat-head screwdriver onto it.

Even with the troublesome bolt removed, getting the board actually out of the chassis was still tricky, due to the 24-pin system-backplane connector. The fly leads to same are very short, and are very stiff thick wires. There isn’t enough room above the board to push that connector through its’ chassis-cutout without removing the board first, but you cannot do that as the connector is hard-attached to the board by such a short cable-harness. Time to pick yourself up by your bootstraps?

Also, that connector has active components attached to its’ backside, so using force wasn’t a sensible option.20170910_120353

A lot of wiggling back-and-forth, both pushing the connector from one side whilst simultaneously pulling from the other, all at the same time as pull-sliding the PCB out to make room, FINALLY got the danged thing out. Hooray!

Not Too Shabby

Most of this larger board and components looked in OK condition, albeit a little dusty in places.

Not too shabby, huh? Oh yes, spot the two huuuuuge capacitors lurking under the black plastic sheath – a reason for nervousness whilst trying to wrangle the board out of the chassis – those could give you a very major DC shock!

But Now, The Good News

But there was something a bit odd-looking in the middle of the board, next to the plug where the smaller board would attach.

The solder pads for component CR111 don’t look quite right, and is the PCB a bit discoloured there too? Time to take a look at the other side of the board underneath CR111…

WOW! The solder-mask on the underside of the board underneath CR111 looks like it has been heat-treated with a blow-torch!

These signs of damage are good news, I have likely found the reason why the PSU +12V rail is dead – CR111 has failed, and rather spectacularly.

Famous Critter

Now for a little aside… on the ‘net, there are a few reports of people repairing ITT PEC4044B PSUs as used in the R4000 Indigo, but absolutely none regarding repairing the different PEC4044A used in the R3000 Indigo. Comparing my pictures with pictures of the 4044B internals, and in spite of the specification differences, it appears that the two PSUs use the exact same PCBs, just fitted with different capacitors/resistors/etc. In particular,¬†http://forums.nekochan.net/viewtopic.php?f=3&t=16731963&p=7401329&hilit=Indigo+PSU#p7401329¬†shows what appears to be an identical fault to my 4044A, but on a 4044B, together with a mention that yet another person also found the same problem with CR111.

CR111 is famous!

OK, so three people out of several thousand isn’t what you would reasonably call compelling statistical evidence, but in 2017, its’ probably the best that can be achieved.

I’m guessing that CR111 in my PSU is also a 1N5352 15V zener diode, but before I dash off to digikey.co.uk, I will need to extract it from the PSU, to make sure.

Hollywood or Dust – Episode 1: Down the Rabbit-Hole

[Repairing the PSU from an SGI Iris Indigo R3000]

Oops, Retrochallenge 2017/10 has been running for a week already – better pull myself together and make an actual start on my project!

Peculiarly Special

The Iris Indigo has a slightly complex PSU history and situation. The original Indigo, based on the MIPS R3000 CPU, uses an ITT PEC4044A PSU – a custom job built especially for the R3K Indigo. This is not your father’s PSU, not by a long shot. You can’t just stick an AT, ATX or microATX PSU in there, this one has custom connectors/pinout/form-factor/everything…

Secondly, to power the R3000 version of the Indigo, it needs to be able to provide 25A at +5VDC, 6A at +12VDC, and 1A at -12VDC. You won’t find any even vaguely recent off-the-shelf PSU that can provide that much 5V current – it has been a long time since 3.3V (then 2.9V then 2.1V then 1.8V etc) became fashionable. And a hard requirement for a -12VDC rail is much less common than it used to be!

Thirdly, and most importantly, the PEC4044A PSU also contains the Indigo system audio loudspeaker. Yes, really!

Brothers but not Twins

The later R4000-based Indigo uses the same chassis, graphics boards, connectors, drive sleds, backplane (except for the contents of the “Model ID” EPROM chip), et al – but does not use the same PSU, due to the extra power consumed by the R4000 CPU. The ITT PEC4044B PSU in the R4000 Indigo needs to be able to supply an additional 5A on the +5VDC rail. The 4044B is the same size and shape and is fully pin-compatible with the 4044A.

So yes, in principle, I could buy a (slightly younger) R4000-Indigo PSU and fit it in the R3000 Indigo. Many people have done exactly that over the years. However, the “B” revision PSU is still truly ancient (so even “new” ones have been sitting on a shelf for approx 24 years), and are almost as expensive as the “A” revision PSU. My wallet would not approve, and the chances of getting an already-wilting replacement are just too high.

Getting Inside

Removing the side cover was not too difficult: undo two screws, flex the side that has shaped “spring-clips” formed into it, and (with some force) slide the two-sided cover up.

Inside there are two boards, connected at 90 degrees,with plenty of fly-lead connectors, a couple of humungous evil-looking black capacitors and a couple of old-school fuses.

Hmmm, two fuses. One for each major rail? Let’s check the fuses then, maybe this could be an easy fix! Unfortunately not – both fuses are fine, so it’s back to the grindstone. Shucks!

Removing the smaller secondary board is straightforward enough – unplug the speaker cable, disconnect all the other fly-leads, snip the cable-ties binding the cable-bundles to the smaller board/frame, and pull the board “up” (from original PSU orientation) – it simply unplugs from the primary board.

Good news! This board looks in superb condition, even after 25+ years – no leaking or bulging capacitors, no signs of corrosion (apart from on the two vertical heatsinks), no signs of trace damage and no obviously fried components. Just a little bit of dust. Almost as clean as a whistle!

Looks like more investigation will be needed…

Hollywood or Dust

As is often the case with hardware this old, my 1991 SGI IRIS Indigo R3000 will not start. Well, that’s not quite completely true…


When pressing the power-switch, the fan did not spin, neither of the two SCSI disk drives spun up, the screen remained resolutely blank, and the cute Indigo power-on tune did not play (yes, really: 1990s SGI machines have firmware that plays a short melody when the power-switch is pressed, before any attempt to boot an O/S).

However, signs of primitive life were there – the LED on the CPU board lit up yellow, indicating firmware power-on self-test is running, but it should then go green, which it just didn’t.

The LED on the external Ethernet AUI adaptor (remember those?) also wasn’t illuminating, which actually was rather a clue to the real problem, although not one I was aware of at the time.

Others have noted that on the R3000 Indigo, hot-replugging the CPU board can sometimes kick recalcitrant machines into life, so it was worth a try at this point… but didn’t make any difference. And no, it didn’t result in piles of smoke, either.

Inspection One:

Visual inspection of the CPU board (including checking for bent pins, blown or leaked capacitors, burned-out traces, and so on) revealed that it looked in fantastic shape. Multimeter also revealed that the on-board 3.6v IDPROM battery was good.

The graphics board also showed no sign of damage or rot. The backplane appeared likewise – no visually obvious problems there either.

Ripping Out:

Initially I thought that the SCSI disk drives might be suffering from stiction, so I removed them, installed them in an external powered SCSI enclosure, and tested that they spin-up when externally attached to my SPARCstation-10… they sure do.

With the drives powered externally and connected to the Indigo, they spin up, but the screen remains blank, but now the power-up tune does play, and the system might be trying to boot.

Second maneouver was to disconnect the keyboard, and use a serial-console instead: nope, no console messages there either. Not even corrupted, glitched characters. Nothing. This is another clue, although one that does not apply to all types of personal computer.

These Boots are Made for Running:

OK, so let’s remove the graphics board too. With just the CPU board in the chassis (drives in external enclosure, serial console), the system boots… Unfortunately, the ethernet still wasn’t working.

There is nothing left to remove, so now what?


As is inevitable when dealing with old SGI kit, I ended up relaying my difficulties to the Nekochan Forums, a very informal online site for discussing all-things-SGI. For retrocomputing enthusiasts, it’s well worth a look.

Armed with my description of the system behaviour, one of the hardware experts there spotted the problem straight away: there was no 12V power getting to the components.

AUI adaptors need +12V to function, as do the SCSI disk drives. Also, 90’s SGI on-board serial-ports like 12V power, although it seems they can hobble along with lesser voltage. Nothing else on the CPU board requires 12V.

So that explains the problems.

The Job at Hand:

The obvious solution, buying another Indigo PSU, is a bit of a reach, current prices are around ¬£200+. And even for new, unused, still-packaged units, it would still be 25 years old, and thus not necessarily “in good order”.

Thus it might be better (well, cheaper anyway) to attempt to repair the PSU. I’m not too keen to go poking around inside an ancient PSU with HTDC and 240V AC running through it, but needs must?

The Return of The Thin

I have recently acquired an old HP T5510 32/128 “thin client” device – a dedicated remote-graphical-terminal, manufactured in 2004 (not my pictures, I’ll get those up in due course):

With the addition of a VGA monitor, USB keyboard and mouse, and an Ethernet cable, this device can connect to remote RDP and Citrix services. Well, it could – the onboard WinCE 4.2 software is so old that it really won’t connect to any even vaguely recent RDP/Citrix server…

The device was manufactured in 2004, and by 2009, with the release of Windows Server 2008R2, the world had moved on. WinCE 4.2 cannot handle SSL certificates with anything later than SHA1 and 1024-bit RSA, and cipher suites that were deprecated or withdrawn between 2010 and 2014. WinCE 4.2 also cannot support RDP Network-Level-Authentication. All of which means that connecting to even a 8-year-old Windows 2008R2 RDP service, or an equivalently aged Citrix service, just won’t fly.

This is a real pity, as the hardware is well capable of doing so, but HP abandoned the T5510 (and it’s sister models) from a software perspective rather too soon. WinCE 5.0, 6.0 or 7? No chance. The situation is even worse since 2015, when HP split into separate companies: HP (consumer) and HPE (business/enterprise), at which point the maintenance resources for the old thin clients disappeared, or got lost in the chaos.

Which leads into a possible rejuvenation project: install a super-slimmed down custom Linux onto the onboard flash card, with FreeRDP 2.0 installed (yes, it needs to be the very recent “beta” 2.0 build, otherwise the same problems as with WinCE 4.2 crop up).

From an initial perusal of “Linux-From-Scratch“, it looks like this might be rather more work than I had anticipated…

Cherryside Addendum #1 – Others Bodges

Although Retrochallenge 04/2017 finished a few weeks ago, I have carried on with my project, making some improvements to my PS/2 keyboard interface for the 68HC11 microcontroller.

Expanded-Mode Compatible

In particular, I now have the hardware interface working using only PORTA (pins 3 and 7, using the pulse-accumulator for the input-clock and the bidirectional-capable pin PA3 for the serial-data-line). This frees up PORTC so that the interface can be used both in single-chip mode and now also in expanded mode (eg: when PORTB/PORTC are needed for the external address-/data-bus). The actual circuit is identical, apart from which 68hc11 pins are used, but the program required changes.

However, this took rather longer than expected: the PORTA pins have so many “alternate option” functions that figuring out the necessary control-register settings, and debugging them, is rather more complex than the¬†for PORTC (where there was only one control-register setting needed). The Motorola 68HC11 E-series reference manuals are a bit tricksy when describing¬†all the alternative PORTA pin-modes and how they interact, esp things like what happens if you configure PA3 direction to be¬†output, but configure the PA3 function to be¬†input-capture, and then perform programmed writes¬†to the PORTA data register… the darned PA3 pin can be used for multiple different purposes at the very same time, but figuring out how the different purposes interact can be a bit challenging unless you are used to it.

An Old IBM Firmware Bodge

As previously noted, this interface and program work fine with one of my Cherry PS/2 keyboards, but not with the other: with the large kiddy-coloured keyboard attached, the program just sees a continuous sequence of 0xAA byte values, at half-second intervals, even when keys are pressed/released: no actual scancodes are being received.cherries1

After spending much wasted time messing about with different-strength pull-up resistors (just a desperate hunch) and a separate higher-current voltage-regulator for the keyboard, I stumbled across https://www.cs.cmu.edu/~jmcm/info/key2.txt, which describes a not-uncommon but also not-universal “alternative” behaviour of some AT and PS/2 keyboards:

When the AT keyboard is first reset it’s supposed to send an AA if its
self-test passed or FD or FC if it failed. But before it does this, it
sends a continual stream of AAs with the parity incorrect. Once the
computer sends an FE to indicate that there is a parity error, the keyboard
stops sending bad AAs and sends a correct AA or an FD or FC. This sounds
like someone made a quick fix in the keyboard firmware for mis-matched reset
timing (the keyboard always finishes resetting before the computer so the
computer could miss the AA/FD/FC).

Aha! So the kiddy Cherry keyboard is reproducing an old IBM “bodge” behaviour (that predates the original 1987 PS/2 keyboard). Sheesh.


To get this particular keyboard working (and several others too, I suspect), I am going to have to implement full bidirectional communications and flow-control, parity-checking and response parsing, which will require a rather larger program. Fortunately, I am confident enough with the initialisation code, interrupt-handler and bi-partisan circular-buffer code that those can now be moved into on-chip EEPROM, thus freeing up some of the 280 bytes of usable on-chip RAM for more program code…

It often turns out this way, as other Retrochallengers have noticed: there is always room for improvement!

With a Cherry on the Side – Lessons Learned (Dijkstra be Damned)

[A Project to interface a PS/2 keyboard to a 68hc11 microcontroller]This RetroChallenge project reached its’ target – decoding, reading, and reporting PS/2 keyboard scancodes with¬†a 68HC11 microcontroller using only internal resources (no external memory, no external I/O device controllers, no external logic, etc).

I had picked a rather minimal project because I knew April would be an extremely busy time at work (end of financial year, and all that stuff), and in spite of the low bar, it was still a challenge to complete it in time.

And now I guess it time to review the lessons learned:


For someone who’s current employ involves x86/x64 CPUs, massively multi-layered software stacks, incorrigible black-box hardware, truly awful scripting languages, software-patches that break the very systems they are supposed to fix, bait-and-switch online software-subscription services, and so on: RetroChallenge is very therapeutic. Such fun playing with things at a much lower level! And from a simpler, happier technological time.

RetroChallenge also provides a great opportunity to build electronic systems using blu-tack, gaffer-tape, cardboard boxes and random bits of plastic off-cut. What more could you want?


In spite of being determined to avoid lazy-oops issues on this project, I once again got distracted at just the wrong moments and suffered a number of Doh! RTFM! problems, of which I am wholly 100% to blame. Redmond-induced premature senility?

Good Programming Practice – as in: “I needed the practice!”

In spite of the minimal objectives, the project was a very useful exercise in “compacted assembly programming”, getting the program code and data to fit in 280 bytes of on-chip RAM and 76 bytes of on-chip EEPROM. That includes all the MCU initialisation, the command-processor, serial-I/O routines, the PS/2 keyboard interface, the deserializer state-machine, binary-to-hex-ASCII conversion routines, and an implementation of an asynchronous-reader/writer circular-buffer (so an interrupt-service routine can be asynchronously adding bytes to the buffer at the same time as the main program is removing bytes from the buffer, without collision or overrun). For those of you with even more time to waste, the source code for the project programs can be found at http://shelldozer.im/cherryside/src.

As always with 8-bit accumulator-oriented CPUs, there is a trade-off between code-size and speed (although not at all as complex as the trade-offs would be with modern 64-bit CPUs). For instance, on the 68HC11, choices have to be made between a memory-load followed by sequence of 4 shift instructions to maneouver a data-bit into the right position, versus using bitwise AND with a branch and a load-constant instruction: on the 68HC11, using X-indexed memory addressing, the former takes 6 bytes and 12 cycles, whereas the latter takes 8 bytes and 11 cycles. In an ISR needing to be fired at 30KHz on a 2MHz CPU (with minimum 12-cycle interrupt latency), saving even a single cycle might well be needed, but when RAM is so constrained, saving 2 bytes would be a better choice as long as the ISR can complete quickly enough. Similar applies to eg: using explicit load+bitop+branch versus using the BRCLR (branch if bit clear) instruction. The 68HC11 instruction-set is full of these kind of trade-offs…

Dijkstra be Damned

I am also unnecessarily proud of my hand-constructed tail-merging. For an inveterate high-level-language programmer, being able to optimise a function by jumping directly into the middle of another function (and thus subsequently borrowing the latters’ “return-from-subroutine” instruction), is highly intoxicating. A function with no return and no save, but that returns after saving anyway. Cool!

As opposed to my previous 68HC11 project, I was much more familiar with 68HC11 programming this time around. Although sometimes painful, the best practice you can get is to have to implement a program in a very small amount of memory and/or with hard real-time constraints – to actually have to do it.

Debugging with LEDs

…yet again proved to be fantastically useful: being able to illuminate or toggle an LED when a particular state crops up, even within an interrupt-service-routine, turned out to be a sanity-saver at times. For anyone else considering messing about with MCUs, I would not hestitate to recommend putting at least a pair of program-controllable “debug” LEDs into the system – it makes an enormous difference.


Although I have already previously noted how rather fantastic the 68HC11 is, and therefore was expecting it this time around, I was still delighted and surprised at how cleverly put together this family of MCUs is. Quite apart from the incredible timing subsystem, and the built-in devices, and so on, this time around I have noticed something else: although I do not recommend doing so, it appears you can get away with seriously abusing the 68HC11E series – floating inputs, inverted supply voltage, cross-shorted driven pins, and so on, without any detectable damage. Maybe I have shortened the lifetime of this particular MCU chip, but it sure doesn’t look like it, and given that this particular chip was recovered from a beaten-up trashed car radio, it had already had a hard life even before I got my hands on it 3 years ago.

Domestic Plumbers

You really do have to be careful with Internet-sourced advice: some of it, nomatter how logical and sensible it seems at first glance, is just complete rubbish. Some of the tips and advice could even cause the magic smoke to make a run for it. On the other hand, the Motorola documentation isn’t always quite up to snuff either. The situation is very like that when dealing with domestic plumbers: when you find a good one, hang on to them, because they can be few and far between.

One particularly good resource for the “behind the scenes” 68HC11 explanations is Mosaic Industries. For example, the 25mA-per-I/O-pin maximum current rating is not only about avoiding pin-damage, there is another more significant reason: voltage droop.

Technological Arts

Again previously noted, a minimal but still very capable 68HC11 SBC only really needs to provide an oscillator crystal, an RS-232 level-shifter, a LVI/voltage-regulator, and a very small handful of capacitors and resistors. You don’t even need an external PROM/EEPROM programmer device: the 68HC11 can program EEPROM “in-circuit”, off its’ own 5V supply. Yes, even external parallel EEPROM. The SBC I used in this project is the Adapt-11 from Technological Arts in Canada. Amazingly, although having been listed as a “legacy” product for several years, the Adapt-11 is still available from them. If you want an SBC that is a little like an old-skool 8-bit alternative to a RasPi (and is even smaller than the big Pi), you might want to visit Technological Arts online.

1980s IBM Hardware Designers

…should not generally be trusted, the PS/2 low-level interface is slightly wierd, rather more needlessly inconvenient than it could have been. I suppose at the time, it was cheap, but there is a difference between “complex” and “complicated”, and the PS/2 keyboard might just have fallen on the wrong side.


Given how satisfactory the end result of this project was, there are a few follow-up mini-projects that spring to mind: (1) getting bidirectional communication going properly, so I can turn the keyboard LEDs on and off and set the typematic-repeat rate; (2) extending the program to perform full decode-to-ASCII of ASCII-ish keys, and to provide a state-machine to handle meta-keys which need to have both press and release tracked (L-ctrl, R-ctrl, L-shift, R-shift) and those that don’t (caps-lock, scroll-lock, num-lock). Maybe next RetroChallenge?

With a Cherry On The Side ‚Äď Episode Nine (Squinting Backwards)

[A Project to interface a PS/2 keyboard to a 68hc11 microcontroller]

The Starting Situation

By the previous episode, I was getting the right number of clock-pulses per PS/2 key event, but not all the scancodes received seemed correct, eg:

Key Detected Scancode Expected Scancode Comment
Q 0xA8 0x15 wrong
W 0xB8 0x1D wrong
E 0x24 0x24 correct!
R 0xB4 0x2D wrong
T 0x34 0x2C wrong
Y 0xAC 0x35 wrong
K 0x42 0x42 correct!
space 0x94 0x29 wrong
Insert 0x0E 0x07 0xE0 0x70 swapped nibbles
F1 0xA0 0x05 wrong
F2 0xD0 0x0B wrong

At first, I assumed that sampling the data-line precisely when the clock-line went low might be unwise, perhaps there is some signal skew between the clock and data-lines? There are many, many ‘net posts stating that you should delay a short while after the clock falls before sampling the data-line; but that isn’t the way all the clocked-data interfaces I have seen work – the clock is supposed to indicate the approximate center of the data-bit, not the leading or trailing edge of it.

Also, the above results were occurring absolutely every time, 100% reliably, which likely precludes a diagnosis of hitting data-line edges exactly when they are transitioning. Something else is up.

Squinting at the results table, and wondering why a couple of scancodes were correct, one other had nibbles swapped, but the others all seemed way off-beam, I came to the conclusion that I should write the detected/expected codes out by hand, in binary, on paper, and squint at those instead.

The Light Dawns

Oh, the bits are the the right value, but in reversed order. Doh!

One quick program-edit later, to have the ISR store the bits of each recieved octet in reverse order, and I am now detecting all the right scancodes for all 83 keys on the compact Cherry keyboard!

Even the 8-byte monstrosity that the “Pause” key produces: 0xE1,0x14,0x77,0xE1,0xF0,0x14,0xF0,0x77

And all using my original interface circuit, which in spite of all the previous doubts, works just fine.

Bingo, Bongo

That seems like a wrap, all over, the fat lady has sung. I’m calling the project a success as I have managed to achieve what I set out to do. However, I have not had quite so much luck with a couple of other PS/2 keyboards: the big kiddy-coloured “fumble-board” and a Dell keyboard: both of those always generate an 0x55 scancode approximately once per second, whether keys are being pressed or not, and pressing keys does not change that.

I am guessing that those much younger keyboards require some kind of initialisation command to be sent, or (wild guess, handwaving) that they have strong internal pullups (4K7 or lower) that have a metastable reaction to my overcurrent-elimination circuit.

For now, the job is done, and has been quite an education. Next post will be a wrap-up of lessons learned, experiences experienced, and the mistakes I won’t be making in future!