Commodore 64 Power Supply 902503-02, part 1.

In my Commodore 64 Power Supply magic post, I talked about the internal power supply and how not everything that you see when you quickly glance is as obvious as it seems. Yet again I’m faced with a similar situation. I needed an external power supply for one of the machines that I purchased recently, and I didn’t want to pay almost the equivalent of half of the cost of the computer for a new power supply. I searched eBay and come across a “faulty, for parts” unit. Perfect for me, as I’ve got a small “lab” at home and I’m able to troubleshoot and hopefully fix it. It was the 902503-02 part number, that as opposed to some of the “newer” version is not “potted” and can be opened and inspected. Before the auction was over I was “researching” the power supply. My “research” started with googling “902503-02 schematic diagram”. The result brings a few similarly looking diagrams, but here is one of the first hits that I found:

902503-02_PSU_baseline

Well, to me it doesn’t look like the original schematic diagram, it’s more of a reverse engineered diagram that someone has created looking at the real circuit of the power supply. We know roughly what to expect on the basis of what I covered in my previous post – two separate outputs: one is unregulated 9V AC, and regulated 5V DC. And at first glance, it sort of looks ok but in reality, this “diagram” is seriously misleading! Here is what I’ve noticed:

902503-02_PSU_errors

Let’s do the “simple” ones first: the diodes have some strange part numbers, in fact, those should be marked 1N5400. The “ground” symbol from the transformer goes nowhere, as there is only one of them. One of the outputs is marked 7.5A … 7.5A!!?? This should be corrected to 7.5VA – alternatively, the entire thing could be just marked 5V/1.5A. But the biggest and a major mistake is the “transistor” marked SK3052P. Yes, it’s a 3 legged device in a “TO-3P package” that looks like a transistor, but it would be impossible to create a 5V regulator based on a single transistor and a resistor. In fact, the “SK” in the part number is a logo for a Japanese company called “Sanken”, the full part number is “SI-3052P” – a 5V at 2A linear voltage regulator integrated circuit. So the author has done the following “mind shortcut”:

3052p

This is very unfortunate “shortcut” as I’ve seen a few posts on C64 forums where people are referring to that regulator as “transistor”! Well now you know it’s not, and the SI-3052P provides a few important functions: it regulates the output voltage at 5V DC independent of the load and it has a built-in overcurrent protection that will “kick in” when the load exceeds around 2.4A. Based on this new information and after “inspecting” one of those power supplies, I’ve re-created the diagram adding a few more details:

902503-02_PSU_my_v1.0

here is full resolution picture

Let me quickly describe what happens: mains voltage is supplied to the primary winding of our power transformer, notice the “protective earth” pin is somehow connected to the transformer (looks like it goes in the layer between the primary and secondary winding) but it doesn’t extend to the output and is not connected to the computer at all. There are two secondary windings:

  • Pin 9 and 11: provides 9V AC that goes directly to the output. Its protected by a 3A fuse F1, I’ve marked the voltage rating of the fuse (250V) but this is not as important on the secondary side, what is important is to know if this fuse is a “slow” or “fast” acting fuse. Unfortunately, the fuse itself doesn’t have any markings saying what type of fuse it is. Inspecting it physically and considering its function I think it’s a “fast” acting fuse. You may ask why do we need this fuse, isn’t there another fuse inside the C64 that is on the 9V AC power rail. It’s true but the fuse here inside the power supply is supposed to protect the transformer form accidental shortcuts on the output before the power supply is even plugged into the computer.
  • Pin 7 and 8: provides 18V AC with a “center” tab on pin 6. This center pin allows the use of two diodes in a full wave rectifier configuration, saving cost by not having to use a 4 diode full bridge rectifier configuration. Next follows a large smoothing filter capacitor C1. This part of the circuit is protected by 5A fuse F2, yet again there is no marking on the fuse, but considering it has to withstand a larger than standard operating conditions initial charging current of the smoothing capacitor and a clearly different physical appearance I deduct it’s the “slow” acting fuse type.

The unregulated voltage from C1 is regulated using U1, the SI-3052P integrated circuit. On the output of U1 we see an additional small electrolytic capacitor C2, that is recommended by the manufacturer to prevent oscillation. There is one more component, the 300 Ohm resistor R1, it’s used to “raise” the output voltage a bit over the nominal 5V to compensate for the losses on the long wires between the power supply and the computer. This is actually very surprising, as looking at the U1 datasheet, we see Note 3: “The output voltage may not be adjusted by raising the ground voltage (using a diode or resistor)”. This is related to the built-in “foldback overcurrent protection circuit” that will be affected if pin 3 of U1 is not at “ground level”. Looks like the engineers designing the power supply ignored the note. When I get a chance I will try to test and compare the behavior of the power supply in a fault condition, with and without that resistor.

Quick comment on the construction of the power supply. The diodes and fuses are soldered directly to the transformer “pins” (with the help of some additional internally unconnected pins 10 and 12). The rest of the components are mounted on a small printed circuit board (PCB). The transformer and the PCB are marked “Billion”, and I assume this is “contract” manufacturer Billion Electric Co., Ltd. of Taiwan, that Commodore tasked with the creation of this power supply.

Lastly, one should note this is a linear power supply, cheap but very inefficient. At full load (C64 plus accessories plugged into the expansion port drawing in total around 1.4), the input voltage on U1 is over 10V, so to “drop” the voltage to 5V on the output the linear regulator has to dissipate close to 8W of power (voltage on input minus voltage on output multiplied by current). U1 and its heatsink get extremely hot, and as we know, hot semiconductors don’t last long…

In part 2, I will cover the restoration/repair of my eBay purchased power supply, I will share some test results and implement few improvements… stay tuned.

Commodore 64 Power Supply magic.

Note:

At the beginning of this post, I cover some basic power supply stuff, so if you already know a lot skip to the later part where I cover the more interesting 12V DC rail.

Not as obvious as it seems.

While browsing “SAMS Commodore 64 Troubleshooting & Repair Guide” I came across the block diagram of the internal power supply system. It was interesting to me for a number of reasons. First, I’m “into” Commodore restorations those days so this generic knowledge is useful, also I hoping to develop a DC only power supply (so that you could run the C64 off of a 12V car power socket). As a reminder this is the block diagram that I’m talking about, from the book:

sams_guide_c64-powersupply_1

Something wasn’t right here… notice the diode on the +9V supply line. My background is electronics, but even though let’s just say I haven’t “practiced” for a while, the direction of that diode makes no sense, it wouldn’t work. Let’s look at the detail diagram from the C64 service manual:

PDU_ServiceManual_Path

Looks familiar? I’ve highlighted the section that I’m wondering about. Seem like the authors of the troubleshooting guide have made a mistake when creating the block diagram, in fact, the diode CR6 (1N4001) has nothing to do with the unregulated +9V power supply line. Since we are already discussing details of the power supply diagram let’s analyze all sections and how each of the power rails is generated one by one:

9V AC

PDU_ServiceManual_9VAC

The 9V AC power is supplied from the external power supply, passes via a common mode choke filter and a fuse. It is then used to generate all other rails plus is made available on the user port pins 10 and 11. Important to note is that the 9V AC rail is also used to generate the 60Hz/50Hz signal for the hardware real time clock built into the CIA chip. This is one of the reasons we can’t replace the external power supply with a modern DC switch mode alternative.

5V DC (+digital)

PDU_ServiceManual_5VDC_digi

Just like the 9V AC, the 5V DC is supplied from the external power supply, it’s filtered and used directly to power majority of the “chips” on-board. Important: since there are no additional components onboard of the c64 handling the 5V DC digital rail, you’re at the mercy of the quality of the external power supply – and we know those old original power supplies are failing a lot. Typically they fail with an over-voltage condition, resulting in “fried” memory and other components, so always check the condition of the external power supply before you use it for the first time.

5V DC CAN (Clock and ANalog ??)

PDU_ServiceManual_5VDC

You may ask yourself why do we need another 5V DC rail, we already have one from the external power supply. Separate, locally generated power is needed for the sensitive video and clock circuits of the computer. The configuration is “textbook” implementation of the 7805 regulator IC. The 9V AC is rectified using bridge rectifier CR4, smoothed using large electrolytic capacitor C19, decoupling capacitor C95 before getting into the regulator. Regulator output is decoupled with C102 and C103.

12V DC

Now we come to the interesting part of my article.

PDU_ServiceManual_12VDC_0

At first glance, you see the 7812 regulator, some bypass components around it (c59, C57, C89, C88) and fed from the 9VAC. But look closely and you see 3 extra components that are not instantly recognized by most: diodes CR6, CR5 and capacitor C90. What are those for? When I first noticed those I came to the conclusion that it must be used to boost the unregulated voltage coming out of the bridge rectifier CR4 and smoothing capacitor C19 to a level required for correct operation of the 7812 regulator – that is typically around 14.6V DC. What I could see from the diagram was:

  • clamper that consists of capacitor C90 and diode CR6, one should note that in our case this is a “biased clamper” type, as the anode of diode CR6 is not connected to ground but to the 9V unregulated dc supply.
  • peak detector (aka half-wave rectifier) that consists of diode CR5, followed by a smoothing capacitor C88.

Ignoring the fact that we are dealing with “biased clamper”, this combination of clamper and rectifier is a typical example of the voltage doubler.

I started “poking” around my Commodore with an oscilloscope (all captures are with 5V / division setting).

9_all

Higher resolution picture here. (btw one day I will learn how to implement a proper gallery in my posts).

Looking at the oscilloscope we see the AC supply entering C90 (bottom right). The amplitude is around 12V, but we can’t fail to notice we only see the positive half of the “AC” signal. This is due to the fact that we are measuring this in reference to the power supply ground, so one of the diodes of CR4 bridge rectifier is forming a half-wave rectifier.

The output from C90 can be seen in the top right and is “shifted” from the ground by the level of “biasing” voltage, in our case, it’s around 10V DC.

Finally, we can see what happens after our supply goes through the half-wave rectifier CR5 and smoothing capacitor C88. Note the output DC voltage that is present on C88 is over 20V. That means that C88 must be rated at 25V minimum. I mention that as I’ve seen people commenting that when “re-capping” capacitors on board of the Commodore you can stick to 16V rated electrolytic capacitors – as you can see this is not true.

All this “complications” mean that it’s not easy to replace the external power supply with a simpler DC switching power supply. Without modifying the internals of your Commodore you will need both DC 5V digital rail and separate 9V AC rail.

Final thoughts.

I hope this was informative. Note that what I described above is what I think is happening, and I’m around 95% sure, but feel free to comment if you think I’m wrong and I will fix it.

I’m working on more Commodore related “material”, so more will follow.

“Pi1541” in 30min with (almost) no soldering.

I need to test my Commodore 64 but I have no floppy drive, cassette deck or cartridge…

This was the dilemma I had one evening after repairing my newly acquired Commodore 64 machine – yes I will write a blog entry about it and link it here later. I really wanted to load a game and test the famous SID chip for it’s sound quality. So off to Google looking for quick solution. There are plenty of those floating around, most are semi-commercial, and pretty complicated and/or expensive, not something you can implement “tonight”. Than I came across the Pi1541 by Steve White. According to his post “Pi1541 is a real-time, cycle exact, Commodore 1541 disk drive emulator that can run on a Raspberry Pi 3B (or 3B+). The software is free and I have endeavored to make the hardware as simple and inexpensive as possible“. Wow, amazing work Steve! Plus he released it all to public for free, including schematic diagram of the “cable” and the source code of his software.

If you follow his post, in his setup instructions you will get to step six where you need to create the cable. There are two versions, simple and more complex. Most of us need the simple version, if fact when you read the instructions you will soon realize the that you can make a “super simple” version of the simple one as there are quite a few “optional” components. So to make the task easy I’ve created a new modified diagram of the “super simple Pi1541 cable”:

mypi1541_v1.0

Full size image here

Yep, that’s it, one component – the 4 channel logic level converter, Steve suggests the Sparkfun part number, but places like eBay, Amazon, Banggood are full of alternatives. All you need is one based on MOS-FET transistors (you will see 4 of the 3 legged tiny transistors on the board) and you’re good to go.

If you want to know what the logic converter does, it’s simple: you can connect to each other 4 digital lines of signals that are not compatible from the logic level point of view – the raspberry pi uses 0V/3.3V voltage to it’s logic “0” and “1” and the Commodore uses 0V/5V voltage. Each pair of HV1/LV1, HV2/LV2, HV3/LV3, HV4/LV4 handles one line, you can imagine that for each pair HV1 pin and the LV1 are “connected” to each other, so if we send a 3.3V “signal” into LV1, it will come out of HV1 as 5V “signal” (note: this conversion works in both directions). The remaining connections are related to power, so you feed “ground” to the GND pins (note: GND pin on the LV side is directly connected to GND on the HV side), you feed the low supply voltage to “LV” pin and the high supply voltage to “HV” pin.

I had one of the Sparkfun parts in my drawer so I decided to go ahead and build the simplified version of the cable, here is what I’ve done:

Step 1.

You need to somehow get the signals out of the Commodore and into the logic converter:

Option A: Get a DIN 6 plug and solder 5 wires onto it, this is what I’ve done:

pi1

“But you promised no soldering”, okay….

Option B: you could “sacrifice” a spare serial cable that you use to connect the original 1541 drive to your Commodore 64, cut it half use one half for your cable and give the there half to one of your friends so they can create a cable for themselves 🙂

Step 2.

You need to somehow connect the cable to the logic level converter, again many options, I soldered a pin header to the logic converter, “crimped” the connectors and used a 6 way plastic plug like this:

pi2

pi3

“But you promised no soldering”, okay….

Option B. You could simply twist the cable into the holes of the logic converter, here is an example of how I would do it if I didn’t know how to solder (example shows different logic converter as I don’t have the 4 channel one handy that doesn’t have pins soldered already):

pi4
First strip a wire about 1cm (0.4inch) and twist it.
pi5
Feed the cable through the hole and twist on the outside of the converter board
pi6
Once you got all 6 wires done, push the pins through (you may have to experiment with different size of wire to get a tight fit)

 

Step 3.

Option A. Now we need to deal with the connections from the logic converter to the raspberry pi. In my case I had the pins already soldered on my logic converter so I crimped another 7 connections between the logic converter and raspberry pi:

pi9

But, but….

Option B. Since raspberry pi comes with pin headers soldered in already you have no choice you need to “source” the raspberry pi side connectors from somewhere – a good source would be and old computer case that has cables for DISK LED, POWER LED, RESET, BUZZER etc. This will give you the “plug” on the raspberry pi side, on the logic level converter side use the “twist” method mentioned above. Wire everything as per the simplified diagram.

Step 4.

Tidy up. I secured my headers and the converter PCB with some paper tape

pi10

And finally I placed the pi and the converter cable in a raspberry pi case:

pi11

Now the only other thing left is to prepare the SD card.

Step 5.

To prepare the SD card, just follow Steve’s instructions. You should end up with SD card structured like this:

/
/bootcode.bin
/config.txt
/dos1541
/fixup.dat
/kernel.img
/options.txt
/start.elf
/1541/
/1541/fb64
/1541/Games/mygamefile1.d64

The first file in the 1541 folder should the the “file browser” file compatible with your platform, in my case I’m using Commodore 64 so I only left the “fb64” file in that folder. This file needs to be the first file in that folder so that when you boot your Commdore and issue the famous <LOAD “*”,8> command the file browser will start and let you “browse” the content of your virtual 1541 disk. To keep the file first I added the Games folder and placed all my games files inside it.

Step 6.

Donate or support Steve via PayPal/Patreon to reward his hard work 🙂

Using Cisco Hyperflex API with Python

Introduction to Hyperflex (HX) API.

Note: All code related to this post is hosted on GitHub

Cisco publishes a pretty extensive documentation related to the HX API. Head to the HX API Documentation page hosted on Cisco’s DevNet. You can also point your browser at the controller VM to access the “live” API documentation build into the system, the url is https://controller_IP/apiexplorer.

Start accessing the API.

To start using the API you must first log into the system by obtaining an access token that will later be used to authenticate any further requests. As per the documentation on the AAA we must issue a POST request to the https://<controller_IP/aaa/v1/auth?grant_type=password&#8217; url. The “body” of our request should look like this:

{
"username": "string",
"password": "string",
"client_id": "string",
"client_secret": "string",
"redirect_uri": "string"
}

Most of the parameters for the request are self-explanatory like the “username” or the “password”, but what are “client_id”, “client_secret” and “redirect_uri”. Unfortunately the documentation fails to mention those parameters (as of 2018-January). First I tried some random values but those were not accepted the the API. Luckily the Hyperflex own built in GUI uses the same API with the help of “Developer mode” inside the Chrome browser I was able to determine the correct values:

{
"username": "string",
"password": "string",
"client_id": "HxGuiClient",
"client_secret": "Sunnyvale",
"redirect_uri": "http://controller_IP"
}

Now that we know what parameters have to be used, let’s start writing our code:

import requests
import json

# suppress the unverified request messages (when using self-signed certificates)
requests.packages.urllib3.disable_warnings()

def get_auth_token():

        url = 'https://10.1.1.11/aaa/v1/auth?grant_type=password'
        headers={'content-type':'application/json'}

        payload = {
                "username": "local/root",
                "password": "*******",
                "client_id": "HxGuiClient",
                "client_secret": "Sunnyvale",
                "redirect_uri": "http://10.1.1.11"
        }

        try:
                response = requests.post(url,headers=headers,data=json.dumps(payload),verify=False,timeout=4)
                if response.status_code == 201:
                        if  response.json().get('access_token'):
                                print "Got token ok"
                                return response.json()
                print "Failed get a token "
                print response.content
                return None
        except Exception as e:
                print "Post for token failed \n"+str(e)
                return None


if __name__ == '__main__':

        token = get_auth_token()
        if token:
                print json.dumps(token)
        exit()

Getting the authentication token is a start, now we can progress to something more useful, like getting data out of the system.

to be continued…

First blog post…

Decided it’s time to document some of the work I do. Mainly for myself. I’ve been working on many projects, mostly around technology, but I’ve left little notes and found myself in a situation where I had to re-do things almost from “zero” as I didn’t have notes that I could re-use. So here it is, my first post.

I intend to mainly blog. I will post notes on interesting projects, pictures etc. Leave a comment if you find anything useful here.