Pi1541 IO Adapter

Two weeks ago, there were exciting retro-news on the Lemon64 board: Gorack – aka. Steve White – released the first version of his Pi1541 that he had been working on for quite some time. “Pi1541 is a real-time, cycle exact, Commodore 1541 disk drive emulator that can run on a Raspberry Pi 3B (or 3B+).”

I was curious and wanted to give this a try, but I also wanted proper wiring. So I created my own version of an extension board for the Raspberry Pi. (Not a proper “HAT”, that would require an eeprom and other things.) I then ordered a small prototype batch because others were eager to try our new retro toy, too.

I received the PCBs on Friday after some unfortunate delay at the German customs and by now the first board is assembled and seems to be working fine!

There are two minor issues in revision 1 that I will address in revision 2:

  • The drill holes for the level shifter module should be a tiny bit wider. Regular pin headers only just fit and one has to be careful not to damage the board.
  • Maybe the wiring of the power LED is too simple. It will glow faintly even with only the C64 powered on, obviously drawing current through the bus.

Also in revision 2, I’m adding optional support for a TXS0108 level shifter module to be used instead of the simple, BSS138 based one. There has been some concern that multiple, additional devices attached to the IEC bus might damage the Raspberry Pi when using the simple level shifter.

This is what you need to fully assemble one of the revision 1 PCBs:

1 P1 2×20 pin female header
1-2 IEC1-2 6 pin DIN socket
5 SW1-5 right-angle push buttons
1 U1 4 channel level shifter module [China] [Germany]
1 SW6 push button (optional)
1 D1 3mm green LED
1 D2 3mm red LED
1 R1 resistor 330Ω
1 R2 resistor 220Ω
1   piezo speaker (optional)
4   M2.5 screws, 18mm
4   M2.5 nuts
4   distance rolls, 11mm

In addition, you’ll need a Raspberry Pi 3B or 3B+, a micro SD card, a good power supply, and a Commodore serial cable.

The KiCAD project and the Gerber files will be released soon.

Retro Repair, Addendum I

In my last post I repaired the mainboard of an old Commodore 64 I had retrieved from the attic. After replacing quite a few components, the board was working again for most practical purposes. One issue remained to be investigated though: under certain circumstances, some characters on the screen would change their color seemingly at random.

Random characters changing their color.

This was already visible in the diagnostics output but turned up again later in a graphics adventure I tried. Besides the VIC chip itself, the static color RAM U6 or the 4066 quad switch logic IC U16 seem likely causes for this problem.

The color RAM replaced.

So, once I had acquired replacements for these two, I desoldered them and swapped them out. Swapping U16 didn’t make a difference, but after I replaced the SRAM U6 the color errors were gone as far as I could tell! I still had the suspicion though, that the original color RAM might be alright after all and that it might be my cheap EPROM based PLA replacement  that was causing this problem through timing issues.

Detecting PLA glitches.

So I was wandering how to test the pseudo PLA further. When discussing this on Forum64 someone pointed me to a video by MindFlareRetro that features interesting information and a talk on the PLA as well as the problems caused by replacing it. In his talk, Eslapion suggests two options for detecting glitches caused by EPROM replaced PLAs: the Super Zaxxon game cartridge or a simple circuit based on a 74LS279 latch IC.

PLA test circuit on a breadboard.

I don’t own an Super Zaxxon cartridge and haven’t had the time yet to try and build my own replica. But the 74LS279 test circuit was easy enough to build. The /ROMH and /ROML lines are running directly from the PLA to the expansion port. As Eslapion explains in his talk, the C64 will use these lines when powered on to detect cartridges. But they shouldn’t change afterwards during normal operation.

Unfortunately, this was not what happened with my replacement PLA as you can see from the short video above. Soon after I switched on the C64 and reset the latch on the test circuit, the LED turned back on again. This clearly indicated that my EPROM PLA glitches quite frequently on those two lines and probably does the same with other signals it generates.

So, it was quite likely that the original color SRAM was not really broken but just having a harder time coping with the PLA glitches than its substitute. When I received a better PLA replacement later — a “PLAdvanced” — I was able to confirm this.

The PLAdvanced in place.

That device passes the PLA test circuit without any issues. And with the PLAdvanced in place, the original color RAM is working fine, too.

I might still build a Super Zaxxon replica later for further testing. Just for the fun.


First Retro Repair

Commodore 64 “breadbox”.

Recently, I retrieved a Commodore 64 “breadbox” version from my parent’s attic that was given to me by a friend in the early 90s. As I recall, it wasn’t fully functional even back then. It would halt as soon as a program tried to play any sound. But when I connected it now and powered it up, all I got was a black screen.

The broken ASSY NO. 250407.

I took it apart completely, even the keyboard, in order to give the case and all the mechanical parts a good cleaning. Then I went on to see what I could do to fix the “ASSY NO. 250407 REV.B” motherboard that I found inside.

Remove the SID first.

First thing I did was remove the MOS 6581 sound chip (aka. SID) at U18. It was likely to be fishy (see above), it was socketed on this board anyway, and a C64 will usually run just fine without it. And if it turned out to be fine after all it wouldn’t be in danger of getting damaged during the repair. But even without the SID nothing had changed, I still got a black screen.So I went on to check a few basics. I used a multimeter to make sure the power switch was working properly and I checked the 5V DC and 9V AC voltages at “the other end” of the PCB on the user port, as well as the 5V and 12V DC produced by the two additional power regulators. Everything was within the expected ranges.

The Basic, Kernal, and Character ROMs (from left to right).

After the board was powered on for a few minutes I tested if any of the ICs would get exceptionally warm or hot, simply by touching all of them with my finger. The graphics chip felt quite warm but actually not much more than expected. But the Kernal ROM chip U4 also felt hot which I wouldn’t have expected.

EEPROM in adapter board in socket U4.

So, this was my next guess then, the decision made easy by the fact that U4 was also already socketed. I soldered an adapter board that would allow me to replace the 2364 ROM — a MOS 901227-03 in this case — with a more modern 27C256 EEPROM I had in stock. After burning the the Kernal image to the chip I pulled out the original ROM, replaced it with the new contraption, and power everything up again: Just a black screen.

Schematics near the ROM chips.

I still felt that I should have a closer look at U4, so I set up my cheap Hantek 6022BE USB oscilloscope and examined the pins on that chip. The signals coming to the address pins and those on the data pins didn’t look suspicious: Somewhere between 0 and 4.5V, square(ish), and at frequency around 1Mhz. But the CS signal on pin 20 was obviously wrong, the voltage varied only roughly between 0 and 1.7V.

The notorious PAL.

This signal is coming from the PAL chip at U17. The PAL is a specialized logic chip that regulates access of all the other components to the address and data buses. And it is notoriously known to fail and die in these old machines.

Unfortunately, the PAL is much harder to replace properly than the ROM chips. It is obviously no longer being produced and its internal timing is critical. Still, at its core, it is a device that maps 16 input bits to 8 output bits. Just like a 64kb parallel ROM. So, there is a way to replace it with a different adapter board containing yet another EEPROM programmed with the right data. Reportedly, this solution is known to fail under certain circumstances and there are other, more complicated and expensive alternatives.

The replacement PLA.

But for me, it was just the right thing, because I had again everything in stock that I needed to build such a replacement PLA. So, I desoldered the original PLA, soldered an IC socket in its place, and installed the pseudo-PLA. Connect a display and power up the board:

A first sign of life.

Still not quite what I had hoped for but definitely a step forward! This now looked very much like a RAM problem and my Check64 diagnostic cartridge confirmed this. The “dead test” program signaled that U11 was defective. I did not have any replacement RAM chips in stock, however. Compatible DRAM chips are becoming increasingly hard to get. So I finally ordered five of those, thinking that I might need a few spares in case U11 wasn’t the only one.

First DRAM chip replaced.

Stupid mistake. After the DRAM chips arrived, I socketed and replaced U11 — only to be told by the cartridge that another one was broken, too. And then the next one and so on. In the end, I grudgingly had to place a new order for more Sanyo 4164 DRAMs as all 8 chips needed replacing. And while I was at it, I also ordered an assortment of logic chips that might also be at fault, just to be sure.

Bad RAM everywhere.

Thus, I had some time to spare while I waited for my second order to arrive. So I desoldered the remaining two ROMs, the Basic ROM U3 and the character ROM U5 in order to replace all 3 ROMs with a single Reprom64 adapter. I had those PCBs made in advance a while ago.


When I had finally replaced the remaining DRAM chips with “new” ones, the diagnostics cartridge finally diagnosed a healthy system. Healthy except for two remaining issues. For one, some random letters of the diagnostics output seemed to be colored wrong.

Red letters at random places.

There has been some discussion about this. There could be something wrong with the VIC, the static color RAM or the glue logic between. Or this could be a side effect of the pseudo-PLA I installed. But then I tried various other software, games, demos and the like and I couldn’t reproduce those color problems anywhere. So I’ll leave it at this for now.

The other remaining issue of course, is the defective and now missing 6581 sound chip. As it happens, there is an interesting option to replace the SID chip, the SwinSID originally developed by Swinkels. This device is based on an overclocked Atmel microcontroller that emulates most of the sound synthesis features of the original SID. What a great excuse for more tinkering!

Tolaemon did a great job of describing how to build your own “nano SwinSIDb“. While ready made Gerber files are available on his page, I felt like getting some more KiCAD practice myself. So I designed my own board based on the schematics and had it made and shipped from China.

A new SwinSID board.

There are a few minor issues with this first revision of the board, like accidentally mixed up jumper labels and a hard to solder footprint for the oscillator. I’ll share the KiCAD project once I get around to fixing those issues in revision 2. I couldn’t find a suitable 32Mhz oscillator that was specified for 5V, so I tried a XO53 that is actually supposed to run on 3.3V. It seems to be working fine so far! Neither the overclocked controller nor the oscillator are getting the least bit warm. And the sound the SwinSID produces sounds good to my ears at least.

Nano SwinSIDc assembled and installed.

All in all, this has been a lot of fun! A thrilling puzzle, many new and old things learned, the warm and fuzzy feeling of nostalgia and a sense of achievement when the silicon veteran was up an running again. My biggest problem now: I would love another puzzle of this kind and I have a bunch of spare parts left. But I don’t have another broken Commodore motherboard.





SyncFix64 v1.1

Following the first prototype of the LM1881 based SyncFix64 I made a few minor changes, improving the schematics and layout. Then I was ready to order the first batch of properly manufactured PCBs. The boards took a little over two weeks for production and shipping.

This was also my first try at ordering a v-cut PCB panel and I’m quite satisfied with the result considering the resulting low price per unit. I assembled one of the boards tonight and the device is working properly. So I assume the whole batch should be fine.

The project files for the updated version 1.1 of the SyncFix64 are available on Github and here is the list of required components:

C1,C2,C3 0805 100n
Q1,Q2 SOT-23 BSS138
R1 0805 100r
R2 0805 680k
R3 0805 10k
U1 SOIC-8 LM1881
U2 SOT-223-3 AMS1117-50
C4,C5 1206 22µF

Update: There are German assembly instructions available for download now.



Fixing WifiModem64 Version 1.0

As hinted at earlier, I made a couple of mistakes when designing version 1.0 of the WifiModem64 and they will be fixed in version 1.1.

Still, with some minor manual modifications, those first boards are still usable. In short, RTS must be connected to WeMos D7 instead of D8 for the ESP8266 to boot reliably and the WS2812 LED must be connected to WeMos D5 instead of D0 if you intend to use it.

These are the step-by-step instructions to get WifiModem64 V1.0 on line:

1. Re-route RTS

Take a sharp knife, small screw driver or some other suitable tool and carefully cut the old trace to WeMos D8, which is marked (1) in the image below. Use a multimeter to make sure there is no more connection between R6 and WeMos D8. Solder an insulated piece of jumper wire between R6 and WeMos D7.

2. Re-route RGB LED

Take your tool of choice from step 1 and carefully cut the old trace to WeMos D0, which is marked (2) in the image above. Use a multimeter to make sure there is no more connection between DATA_IN of the WS2812 and WeMos D0. Solder an insulated piece of jumper wire between DATA_IN and WeMos D5.

3. Power Safety

Either fit components D1 and F1 on the top side of the PCB (diode and fuse), or close solder bridge JP1 on the bottom side.

4. Power Source

Fit either a 3 pin male header to JP6 and use a jumper to select between internal and external power supply or use a matching toggle switch instead.

5. Level Shifter

Depending on whether you believe that the ESP8266 needs level shifters on the data lines (I actually don’t), either fit the components R1-R8 and Q1-Q4 to the bottom side of the PCB, or close the solder bridges JP2-JP5.

6. WeMos Headers

Solder 8 pin female headers to the top side of the PCB to hold the WeMos module(s).

7. User Port Connector

Bend the copper leads of a user port connector slightly inwards, slide the PCB in between and solder all 24 leads to their respective pads on the PCB.

8. Optional Components

Depending on whether you intend to use them, fit any of the optional components:

  • baud rate reset switch SW1
  • C64 reset switch SW2
  • micro USB connector J2 for external power
  • LED1 and C1 for the RGB status LED
  • WeMos OLED display on U2

Please note that firmware support for the RGB LED and the OLED display is still being developed!

9. Flash Firmware

Make sure the WeMos D1 mini is NOT connected to your C64 before flashing the firmware. Then there are two options. If you’d like to compile the firmware yourself:

  1. Install the Arduino IDE
  2. Install Arduino Core for ESP8266
  3. Fetch the WifiModem64 project
  4. Open, compile, and upload WifiModem64.ino

If you’d rather flash my pre-compiled binary:

  1. Download and extract the archive
  2. Follow the instructions to upload to the ESP8266

10. Initial Setup

Follow Alwyz’s instructions for the initial setup of the modem if you want to use it at 9600 baud.


To save you from the need to open the actual schematics when soldering components to the board, here is the relevant part of the BOM:

D1 B5819WS (0805)
J1 C64 User Port Connector
U2 WeMos_D1_mini_OLED_Shield
R1,R2,R3,R4,R5,R6,R7,R8 10k (0805)
U1 WeMos_mini
LED1 WS2812B
C1 100n
F1 0.5A (1206)
Q1,Q2,Q3,Q4 BSS138

SyncFix64 Prototype

After the encouraging results of my first attempt to fix the composite signal from a C64, so that the cheap TFT monitor could display it, I shared the idea on Forum64 to double-check and get some feedback. Consensus seems to be that the circuit at least won’t hurt the video source. Since, in addition to that, it seems to be working for me, I decided to design a board for it in KiCAD.

The goal was to make it so small that it would fit inside the display’s case alongside the display controller, so I went for all surface mount components. To get immediate results, I created a single sided layout and etched the board myself using the toner transfer method.

Soldering the components to the finished board proved a little challenging, cramped as it was, without a solder mask layer. But it turned out fine and it fits inside the case easily. The display had two separate input lines to begin with, so now I’ve got one fixed for my old C64 and a second “regular” one to choose from.

Update: The KiCAD project including schematics and a preliminary board layout is available on Github now.



Cheap Displays for Old Hardware

A couple of months ago I dug out my old Commodore hardware again and started tinkering with it – the goal being to finally try out a bunch of mods, hacks, and builds that I missed back in the day. To start with, I bought a cheap TFT display for around 13€ to connect to the C64 and C128.

It was meant to sit on my work bench to e.g. quickly test a naked C64 board. It wouldn’t matter if the video quality wasn’t great. But after I made the necessary adapter cable and hooked everything up, I was a little disappointed to find out that the display wouldn’t show anything other than a black screen interrupted by an occasional flicker. I verified that the display itself was working by connecting it to a Raspberry Pi and I double-checked the cable I had made.

Doing a little research, I learned that the video signal produced by the C64 is actually not that great and that problems with modern displays are quite common. I got curious and used my (also very cheap) Hantek 6022 oscilloscope to take a look. The first thing that caught my eye was that the Commodore signal looked rather weak when compared to that from a RasPi.

C64 Composite Video

C64 Composite Video

Raspberry Pi Composite Video

Raspberry Pi Composite Video

So I thought if I amplified the signal, maybe I would get the TFT to display it. I did a little search on how to do this and stumbled across Raphaël Assénat’s page where he describes a problem very similar to mine. The interesting part is that his first impulse too, was to amplify the signal. But later he found out that the signal strength didn’t seem to matter much, it was the unorthodox v-sync sequence produced by the Commodore that confused his display. So he added a LM1881 sync stripper and an AVR micro controller to replace that sequence. Unfortunately, that contraption is very sparsely documented.

C64 Composite and VSync

CH1: C64 Composite, CH2: LM1881 VSync Out

Since he mentions that just “removing” the sync sequence already resulted in a somewhat stable display and that amplification might not be necessary after all, I figured I might just try to get away without the AVR and the amplifier and  I came up with this reduced circuit:

To my great delight and surprise, this yielded instant results! I hadn’t really hoped that this simple improvised circuit would be enough to make my display cooperate.

Of course, there are a few issues and to-dos left:

  1. Ask a few people who actually know this stuff for their opinion and for some advice on the actual components and their values.
  2. Make sure this does not damage the video source in any way.
  3. Revise the circuit accordingly.
  4. Make a nice board with proper wiring and real connectors.

Do you have any thoughts or advice on this? I would love to hear in the comments!


The Modular WifiModem64

I’ve been playing with the ESP8266 since late 2014 and it was love on first sight: so many possible uses for such a small device at such a low price tag. And very early on I thought: wouldn’t it be great to build a WiFi “modem” from this? That shouldn’t be too hard. But I didn’t find the time to pursue the idea then. When I remembered again this summer, I was not surprised but still excited to find that others had had the same idea and hadn’t been as lazy as me.

Alwyz’s instructions on how to build such a device couldn’t be easier! I followed them and it worked like a charm. For the next months, my setup then looked like variations of this:

I wanted something tidier that would still be inexpensive and stay true to the easy-to-assemble spirit of the original version. So I decided to go with the WeMos D1 Mini variant of the ESP8266 modules. It is easily available and for a price as low as $2.60. It is supported by the Arduino IDE, allowing to flash the firmware with no equipment other than a PC and a micro USB cable. This is the board I’ve come up with:

The minimal setup is quite easy:

  1. Solder the User Port connector and the female pin headers.
  2. Close a hand full of solder bridges.
  3. Program the WeMos module and plug it in.

The board offers a bunch of optional extras that aren’t strictly required but may be freely combined to upgrade the device:

  • An OLED display can be plugged into the second WeMos slot.
  • A WS2812B RGB LED can be fitted and used as an extended status indicator.
  • There are pads for a diode and fuse to protect the C64.
  • Alternatively, external power can be supplied through an optional USB connector.
  • Additional components may be fitted for level shifting between 5V and 3.3V. (Personally I don’t think they are needed and the ESP8266 can cope with the 5V. But this way the board is “one size fits all”.)
  • There are pads for a reset switch and a second one to interact with the modem.
  • Potentially, other shields like the LED Matrix could be added instead of the OLED.

Somewhat unfortunately, I made a last minute change to the board layout before I ordered, hoping to make it more compatible with other WeMos shields. I missed the fact that with this wiring a pull-down resistor is required for the ESP to boot. I patched the resistor to the bottom side of my first build but still the ESP needs a second try from time to time. So I might reconsider this in a future revision.

KiCAD and Arduino sources will follow when I find the time to do some cleaning up.

SD2IEC Revisited

When I discovered the MMC2IEC / SD2IEC project by chance back in 2009, it made me dig up again my soldering iron and electronic components after many years of disuse. I built myself one of those devices on a prototyping board and had a lot of fun doing so. It was the first time that I got involved with micro controllers and I learned a lot in the process.

Now, many years and projects later, I was looking for an excuse to try out KiCAD and to learn how to design my own boards using it. I had already ordered a small PCB I found on the net as a proof-of-concept to see if the Gerber files I produce would result in working boards. When they turned out just as expected I was eager to create something myself. This was the perfect opportunity to revisit the subject and make myself a brand new SD2IEC.

I wanted the design to be based on Shadowolf’s latest version but also make my own additions and changes:

  • The board should be able to tap into the cassette port of the C64 for power supply.
  • It should be board for external use with proper connectors just like my first build.
  • All components should be cheap to buy from Chinese suppliers.

So, this is the first prototype of what I came up with. I call it the “SD2IEC pluggable”:

On one side, it plugs into the cassette port, but all lines are traced across the board to the other side. This should allow the use of a datasette without unplugging the device. I haven’t tried it yet because I currently don’t have a datasette available. IEC and SD connectors are facing left as is the USB connector serving as an optional external power source. It is currently mini rather than micro USB because that was what I had in stock.

There are pin headers for the ISP, for connecting alternate LEDs, for I2C devices (like displays) and for optional buttons or switches. Also optionally, additional components can be fitted that should hopefully allow turning this board into a TAPuino using the right firmware. But I did not yet have time to try this either.

I just assembled the first board, flashed the latest SD2IEC firmware, and it seems to be working great! There are a few issues in version 0.9 that I’m planning to resolve in the next revision:

  • Pin 5 of the USB connector needs to be connected to GND, too.
  • Change footprint of D3 to accommodate MELF packages.
  • Maybe replace the mini USB connector with a micro USB one.
  • Add a reset button.

The KiCAD project files are available on Github in case you’d like to make your own pluggable SD2IEC. If you do, I would love to hear about it in the comments!