Before I bought into the Ultimate II+L for my Commodore 64, my go-to for 1541 disk emulation was a Pi1541. And even though I no longer need the Pi1541, I still like to have it - not least as a backup and for occasional use with my test board.
There are many variants of the Pi1541, but the one I liked was the Pi1541 Zero with Epyx Fastload. This one:
 |
| My original Pi1541 hat |
As you can see, this hat (i.e. the board which sits on top of the Raspberry Pi) is a nice compact design, powered through the cartridge port and incorporating an Epyx Fastload cartridge. I have no need to daisy chain serial devices so this served me perfectly well and took up minimal real estate on my desk. I really like it.
So it was with some dismay that a few weeks ago, and for no obvious reason, it just died. Now, it may surprise you to learn, and it certainly surprised me experiencing it, that this is the second time this has happened. On both occasions the symptoms were identical: everything working perfectly for a good long while and then one day, switching the C64 on, it just booted to a black screen. Removing the cartridge restored the C64 to perfect working order. This problem, incidentally, followed the cartridge when tested in my other machine.
As previously described, this variation of the Pi1541 is two devices in one: it's a cartridge AND it's a Pi1541. Although present on the same board, they are separate, sharing only power and ground. Suspecting it was just the cartridge element of the design which was dead, I unplugged it from the cartridge port but kept it connected to the serial port on the C64 and powered it up via USB, thus bypassing the whole cartridge circuitry and sure enough, that worked just fine. So, I inferred, not unreasonably IMHO, that the C64 recognised the cartridge as present and that's why it didn't start up as normal, but when it tried to load the ROM from the cartridge, couldn't. For reasons. One must assume the necessary transfer of data from the ROM on the cartridge to the C64 RAM didn't take place and so there was nothing in RAM for the C64 to load, thus the black screen.
On the first occasion this happened, I took the path of least resistance and just bought another Pi1541 hat from the same place as my initial one. However, now that it's happened a second time and my replacement is toast, I really wanted to see what had gone wrong.
Now this is where things start to get a bit silly. Back in the day (the 70's, 80's and 90's) electronic stores were everywhere and I warrant I could have just popped out and bought what I needed locally for a few pence and job done. However, today we need to rely on China or, if you want to avoid counterfeits: Mouser and Digikey. You can either pay pennies and take the risk of counterfeit parts or you can pay a fortune (not least in shipping) but be reasonably assured of decent quality. I don't keep an inventory of every potential electronic part I might need for any random project, so every time something like this crops up, I have to buy the necessary parts in and this is ruinously expensive.
I can buy a new Pi1541 hat for around £25 GBP. And unless I spend around £33 GBP at Digikey for example, shipping alone is $18 USD (about £14 GBP). It just doesn't make much financial sense to repair these things which honestly, is a grim state of affairs.
That (fairly major) gripe aside, I was keen to get my dead Pi1541 hats working again so let's take a look at what we're dealing with component wise (and I'm only concentrating on the cartridge element of the hat pictured above, so ignoring the reset circuit and the Pi1541 stuff):
- 1 × Winbond W27C512-45Z EPROM
- 1 × GoldStar 74LS09 AND gate
- 1 × 330nF Ceramic Capacitor
- 1 × 0.1µF Ceramic Capacitor
- 1 × 120Ω resistor
and that's it. In total, that's about £3.50 GBP, net, worth of parts if I decided to replace everything and bought the lot from Digikey. Factor in £14 GBP shipping then 20% VAT and that tiny little list would cost £21 GBP. Sigh. It doesn't make sense to just buy on demand, you really need to wait until you have a big list of stuff and only then does it become cost effective. You can see why people take the risk on dodgy stuff from China.
Anyway, after a spot of probing with the multimeter, I couldn't see any obvious problems. No shorts for example. The 120Ω resistor tested fine in circuit. And with no visible issues on the capacitors I felt it extremely unlikely the problem lay with them. My suspicions started to fall on the EPROM. Now up until this point I had absolutely no way of testing an EPROM but I've been hankering for an excuse to buy the XGecu T48 Programmer for a while now and the moment had finally arrived. Now bear in mind, this cost me £59.99 GBP shipped and all the while the fact that I could buy a new Pi1541 hat for £25 haunted me. Again, this makes no financial sense but I'm supposed to be doing this for fun, not for my bank balance.
 |
| XGecu T48 (aka TL866-3G) Programmer |
I took my time desoldering the EPROM from the board, one of the pins was particularly stubborn but I got there in the end with no damage incurred. I've watched so many YouTube videos over the past few years about retro tech and programming chips, using the T48 programmer software was almost like second nature and it was with a mix of surprise and disappointment that the programmer was able to read the contents of the EPROM just fine. So yeah, that really just leaves the GoldStar 74LS09 as our culprit and so I soldered the EPROM back onto the board. Ideally I'd have put a socket on the PCB but unfortunately there's no room for one as the case I use for my Pi1541 doesn't have enough clearance.
Now I'm aware my new programmer can test logic chips, including the 74LS09, but it can't do anything with a chip still soldered onto a PCB (unless, I assume, I buy test clips). I suspect anybody who knows anything about electronics would know how to test a 74LS09, in situ, to see if it was failing. I am not one of those people. So I simply desoldered it from the hat and replaced it with a Texas Instruments variant from Digikey on a wing and a prayer. And guess what? That only went and fucking worked! So this Pi1541 has been resurrected and works perfectly again. Party! And it only cost me £100 GBP or so to do it.
Now this outcome kinda makes sense because regardless of how this chip actually works, the 74LS09 is connected to the EXROM, Input/Output (I/O) and ROML pins on the cartridge connector so it's clearly involved in data transfer from ROM on the Cartridge to RAM in the C64, so if that goes wrong... no data is transferred which would give the symptoms I'm seeing.
Feeling sure the exact same problem was afflicting my other busted Pi hat and now with a small stock of 74LS09 ICs at my disposal I was confident this would be a quick repair. But of course it wasn't.
No dear reader, this would not be a quick repair, coz that second busted Pi hat doesn't use a 74LS09 IC. Instead it uses a 74LS07 which is completely different (it's a Buffer, not an AND gate). And of course I didn't check that before making my order from Digikey, I just assumed they were the same. Because of course I did.
Honestly. FML.
So, in the months between buying my first Pi1541, and buying the replacement from the same place, the design was changed and I never noticed or thought to check. In fact, until doing this, I never gave the design much mind at all. There are lessons there. Anyway, infinite stupidity and rueful chagrin aside, because the symptoms are identical, I am pretty confident it is the 74LS07 (which appears to be doing the same job - whatever that is - as the 74LS09 on the older board) that's croaked, and will order new chips the next time I have another bunch of stuff to order with Digikey to test that theory. What none of this solves however, is why these chips ceased productive operation in the first place? (Edit from the future: it was NOT the 74LS07 - see update below).
Look, I'm a guy who can't even do simple stuff (like read) properly, if you think I know the correct answer to that question then you must be on crack.
 |
| A pair of dodgy chips? |
At a guess, and I stress that, guess, given the available evidence I simply think both these chips (pictured above after desoldering) are dodgy.
The date code on the 74LS09 appears to put it at 34 years old (26th week of 1990 if I'm reading that right). It's possible this was new old stock the seller bought in for these Pi1541 builds, it's also possible this has been pulled from old dead equipment and sold on. Its history is thus distinctly questionable.
As for the 74LS07? Well it appears to have been manufactured by Shenzhen honglifa Electronics Co.,Ltd in 2020 (if that's what the 20 in 20A8 means), and can be found in their current SL Series product listing, here. I've never heard of this company before, or their "HLF" trademark, so I've no idea if they're good, bad or indifferent. If however, it's a genuine new chip that failed after a couple of years of light use then I can draw conclusions. For all I know they could both be as fake as a three dollar bill but they both pass the acetone test, so whilst probably not fake, one of them, at least, is of questionable quality. Either way, I can say with some certainty that the builder and seller of the Pi1541 hats I bought definitely constructed these to a budget, but the actual price, it would seem, is longevity. Let's see if the Texas Instruments replacements I sourced fair any better over the next couple of years.
UPDATE
So yeah. There's a twist in the tail to this story. I eventually did buy new Texas Instruments 74LS07 chips, and fitted one in the space vacated by the HLF variant I removed above, and to my further dismay/surprise and just to try my patience, no dice. The Pi1541 hat still behaved exactly as before, causing the C64 to boot to a black screen. So much for my theorising right? And my apologies for casting negative aspersions on Shenzen honglifa Electronics Co., Ltd.
That could only mean it was the EPROM that was flaky on that hat which is funny, coz that had been my first thought for my other Pi1541. I tried to desolder this chip as neatly as I could but that wasn't playing ball either: the solder would just not lift out, either with the desolder gun, manual pump or braid. That shit was stuck in there, and so before I put so much heat into the PCB that I started lifting traces I just cut the legs of the damn thing to remove it. Now whilst that worked a treat, it did prevent me from testing it as it's now been subjected to a blitzkrieg. Et voilà:
 |
| One mangled EEPROM |
However, I did at least get to play with my new chip programmer - which I actually did need in the end so that outlay wasn't squandered - and with a brand new Atmel (acquired by Microchip Technology in 2016) branded AT27C512R-45PU duly installed, finally, this Pi1541 was working again too. Good grief, what a chore.
 |
| My second, fully repaired Pi1541 Hat |
So, of two Pi1541 hats, with exactly the same symptoms, I have two different (but at least connected) solutions based on something approaching logic. I may have gone about it in a long winded and ignorant way, but I at least got the desired result and now I've gone from having no working Pi1541s to having two, albeit at staggering financial cost.
If the same fault re-appears in future, and because I don't know how to test either the 74LS07/74LS09 or the EPROM on the PCB to find the culprit, I think simply cutting these chips off the board and replacing both at the same time is the way to go. Perhaps a future project I could look at is changing the 3D printed case design so it will accommodate both these chips in sockets - you can simply cut holes in the case to achieve that but it looks ugly. That's something I'll ponder.
I have a Raspberry Pi Zero 2* which I intend to use with this second hat, and I'm treating it to a nice black laser sintered case** (coz why not? Might as well throw more money at this bastard which must be the most expensive Pi1541 hat of all time by now) which I will show off below, when it eventually arrives. Naturally, I dislike the green LEDs on both boards so I'm going to take this opportunity to replace them with blue equivalents. But otherwise, this concludes the story, finally, of how I repaired two busted Pi1541s.
Thank you for getting this far through my ramblings. If you'd like to read more, in my next blog, here, I set about building my own ULTIMAX cartridge.
 |
| Laser sintered case for Pi1541. Top half, bottom half and spacers |
* The Pi1541 with Epyx Fastload was designed initially to be used with a Raspberry Pi Zero. On release of the Raspberry Pi Zero 2, new firmware was released to allow this hat to work with that. Consequently you must obtain the correct firmware for the Raspberry Pi variant you are using and crucially (and this really is crucial) research how to alter the "options.txt" and "config.txt" to allow smooth running for your variant. Settings are not standard and will very much depend on your hardware. For this reason I am NOT linking to files, or divulging my settings.
** If for any reason you have read this and are thinking of getting or building a Pi1541 with Epyx Fastload for yourself and printing a case, be aware that there are many different PCB designs kicking about and consequently, the PCBs all differ too. Crucially the PCBs are NOT the same dimensions and not every 3D case design will fit every PCB. I know the 3D print files I used will definitely fit both my Pi1541s but they may not fit yours so I am NOT providing a link to the files. It is up to you to find the correct case design for your PCB. I am aware that there are case designs which will accommodate a socket on the EPROM, however, as far as I can tell none of those will fit my Pi1541 PCBs and are all designed for a longer version of the hat.
