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.

Components

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)
J2 USB_B
Q1,Q2,Q3,Q4 BSS138

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!

 

 

 

Making a XU1541 Cable

I have been documenting interesting software and programming related findings in my own private Wiki for a few years now. This turned out to be really useful in many cases, especially on topics that I would run into only very infrequently. Most of these notes would not be of any interest to anybody else but me, while a few of them might be worth offering to a wider audience. All it would take would be some nice presentation and a little effort to write things down in whole sentences. Or so I thought.

IMG_4934b.JPG

The finished XU1541 adapter.

When I began tinkering with electronics again, I soon decided this would be a great excuse to start my own blog, sharing my progress. After my initial enthusiasm had worn off, I soon realized that I had somewhat underestimated this project. It takes a good deal of time and effort to write things down in whole sentences and to present them nicely. As a result, there are a few projects that I finished this year that I failed to put up here so far. Most likely, I have forgotten a lot of interesting details by now. But I’ll try and summarize what I do remember.

Continue reading

Making a XA1541 Cable

As you might have read in my previous post, I retrieved  my old Commodore hardware from the attic and found it still working. Even most of the 5 1/4″ floppy disks that I inserted into one of the squeaking 1541 drives seemed still readable. So, I decided this might be the last chance to save those very early lines of code from oblivion that I had written so many years ago. Not that it was really worth it, it’s mostly a matter of principle to not let a single bit of code get lost if I can help it. To convert what was still readable to d64 disk images, I first needed to make a suitable adapter cable.

The XA1541 seemed like a good choice to start. It’s an adapter to connect the Commodore 1541 disk drive to the parallel port of a PC. While there are other solutions, the XA1541 seemed easy enough to build and reported to work with most (all?) parallel ports found in today’s PCs. If there is a parallel port to be found at all. We’ll cover that in a later post on making a XU1541 cable, though.

Also, there are excellent instructions by Stefan Uhlmann on how to make one of these. The page is available in German only but very well illustrated.

All that is needed are two connectors (obviously), a length of shielded wire, four resistors, and four transistors to drive the interface. Just as Stefan suggested, I wanted to fit the active components onto a small piece of prototyping board inside the D-sub casing of the parallel port connector. The first step is to cut the board so that it will fit into the casing while still leaving as much room for the components as possible.

xa-1541-step1

Fitting the board into the connector's casing.

The board fits smoothly between the two rows of the D-sub connector, and the connector is then soldered directly onto the board. The lead-wire spacing of the connector does not match that of the prototyping board, but that doesn’t matter. Only the four left most leads 14-17 of the connector, marked with a green box in the picture, must not be shorted. The other leads 18-25 on this side get all connected to GND anyway.

Solder the d-sub connector to the board.

Do not shorten pins 14 - 17.

Next, I placed the four resistors and transistors on the board and fixed their wires with soldering points.

It really helped and saved time to have Stefan’s images as a guideline. Since I placed the components exactly where Stefan did, all I needed to do then was to spread solder onto the copper side of the board until the shiny pattern looked like the one on Stefan’s picture.

Finally, the the leads from the shielded wire are attached and everything gets stuffed into the D-sub connector’s casing. The DIN connector fitting into the Commodore IEC serial bus is soldered to the other end of the cable and we’re all done.

The XA1541 is ready to connect our trusty 1541 drive to our PC. Using a great piece of code called OpenCBM (formerly known as cbm4linux) we are now able to access the data from the 5 1/4 inch disks.

Prologue

My soldering iron, my collection of spare electronic components and related tools had been stored away in the basement for years. Way back, I really enjoyed tinkering with those, but when I decided to go for the software engineering aspects of computer science I somewhat lost interest. So many things to try and so little time to spare. Also, I have been lacking the room to set up a suitable work space.

My old soldering iron.

As with many other IT people of my age,  my first “real” computer was a second-hand Commodore 64 that my parents bought for me in the mid-eighties. I absolutely loved that machine and spent countless hours in front of it, teaching myself it’s Basic and Assembler dialects. Even though I bricked the C64 a few years later, trying to install a self-designed relay card and replaced it with a C128, I could not bear parting from the Commodore hardware. So I stored the computer and it’s peripherals in card board boxes in the attic many years ago.

Spring 2009: By chance I stumbled across Ben Heckendorn’s blog where he describes how he created his Commodore 64 original hardware laptop. I really admired his work and I really wanted such a portable for myself! Ben integrated a 1541-III DTV into his construction to replace the traditional 1541 floppy disk drive, which of course would not have fit into the laptop. Using the 1541-III connected to the normal serial bus of the C64, it allows you to mount and read d64 disk images from ordinary MMC or SD memory cards. Awesome!

Googling around, I discovered that by now there are actually several different solutions that offer this feature. There are the afore mentioned “cousins” 1541-III DTV and 1541-DTV, both based on PIC micro-controllers. The design has later been ported by Lars Pontoppidan to an AVR micro-controller, which he called the MMC2IEC. The MMC2IEC hardware and firmware has been extended and improved by a bunch of other people and evolved into the SD2IEC. Finally, there is the 1541 Ultimate that reportedly does a good job of fully emulating the original 1541. As a result, it should be able to support even copy protected games and other software that comes with their own fast-loader routines. Unfortunately, the 1541 Ultimate is also rather expensive.

C64 start screen

AntaBaka has done a great job of collecting and summarizing the evolution of the SD2IEC on his page, which is available in German only, though. It was when I read that page that I decided I wanted to build one of those SD2IEC myself. It would be a nice project to play around with the AVR micro-controllers that I kept reading about for some time on sites like Hack-a-Day and Makezine. And it would be a great excuse to dig out the old stuff I had hidden in basements and attics.

I also liked the idea of trying to save my old Basic and Assembler programs from oblivion, petty as they might be. My old discs had been been stored in the attic along with the hardware. They had to endure extreme heat in summer and cold temperature in winter for about 15 years. Would there be anything left to save? Or would even the disk drives be decayed and broken by now? To cut at least that long story short: my trusty old C128 was working fine when I pulled it from it’s card box. And the two 1541 were happily loading the randomly chosen disks I tried them with.

So, the first step would be to get the data from those discs and store it in d64 disk images on my PC’s hard drive. There are a bunch of different cables and adapters that can be used to accomplish this. The xu1541 appealed most to me because it is “legacy free” (what irony!), bridging between the USB port and the Commodore IEC serial port. Also, it is based on an AVR micro-controller.

But at first, I was a little afraid I could be wanting more than I could handle. So I decided to revive my tinkering in electronics with the simpler design of the xa1541 adapter which connects the 1541 disk drive to the parallel port of the PC. We’ll here about that another day.