Replacing the CMOS Battery in the Acorn A7000+

 Last time, whilst I was waiting for some Game Gear parts to arrive, I decided to take a look at my A7000+. I learned that it was getting on a bit and was in a poor way. The CMOS battery had failed in a dramatic manner and leaked across the motherboard, we left the previous post with the battery removed and the board cleaned up for the next step, but before we do anything else, there are a couple of jobs that we need to take care of first.

Some of the gunk from the battery covered the legs of the IC's in the effected area, one of these IC's is the CMOS memory itself. Whilst I took care with cleaning this area up, trying not to break traces or legs etc, there still may be some damage in a different layer of the board. So I needed to make sure we had continuity between the CMOS memory and the battery terminals. We also need to make sure that the battery terminals have continuity with the power bus on the motherboard. This is the easiest thing to test, so we can start with this, simply use the multimeter to test the positive and negative terminals against any ground or + voltage connection on the motherboard itself.

The first test passed fine, so to test further I would need to test the battery terminals against the CMOS memory's VDD and Ground pins. The memory installed on my A7000+ is marked as an 8583T, when researching this product code, I discovered a datasheet from 1997, which would have been contemporary for this machine. The datasheet is available from here and gives us a wonderful amount of information on what this part does and most importantly, it gives us the pin out.

The IC is described as a clock/calendar with 8-bit RAM. This makes sense, because near to its location, there is a 24Mhz clock. Interestingly, this IC also has an I2C interface, so you could hook an Arduino or Pico or even an ATTiny85 to one of these... The datasheet also advises us that the IC has an operating voltage of 1 - 6 volts, this is useful information when it comes to replacing the old battery. And in there it gives us the pin out. We are going to be testing two specific pins here, pin 8 - VDD against the positive battery terminal and pin 4 - VSS against the negative battery terminal.

It passed the test fine, so I know I have a good connection from the battery to the motherboards power bus and from the battery to the CMOS memory. I also know that this is, at the very least, the system's real time, or RTC, clock with an operating voltage of between 1 and 6 volts. This is important because I know that the battery can be at least recharged by the motherboards power bus, if the battery and motherboard are compatible with regards to charging. I also now know that the battery is capable of providing power to the power lines for the CMOS memory, which means if the battery has a charge, it can provide power to this IC when the main power is off.

All I needed to do now is find out about the battery that I removed. Frustratingly there is almost no official information on the factory installed battery, and reading any information from my battery was out of the question due to the amount of corrosion present. I tried scraping some of it off, but it resulted in too much damage to the surface. 

Whilst I was going about these tests, a member of one of the Acorn groups I am in on Facebook asked if I could check the connectivity between the SoC and the CMOS memory. Basically to confirm which pins were used for I2C from the SOC to this IC. His reason for this was quite interesting, he had a Bush IBX board, which is the guts of a smart TV box from a few years back, Apparently, these are cut down versions of the A7000/7000+. Modifying them to have the same CMOS functionality is part of the process of getting them to run RISC OS, its quite an interesting process and if I get my hands on one of those boards, it will definitely be something I will try out. I saw the end result of his efforts posted in the group recently and he had managed to get RISC OS 3.71 installed and running on it, which I think is pretty cool.

One of the things I wanted to address with the battery was could I use a battery of a different voltage, and could I use a battery of a different type? The battery that is normally installed on these machines is a Varta 280H or sometimes 300H NiMh 1.2 volt rechargeable cell with a capacity between 250 - 300 mAh. This is the component that was physically soldered to the board. Here it is still attached to the board:

I know that the CMOS RAM has an operating voltage of between 1 and 6 volts, so I know I can replace the damaged battery with another one that is between this range with a similar capacity. The next thing I wanted to find out is if I could swap from using a NiMh battery to a LiPo. After doing a lot of searching I discovered that the first Li-Ion batteries went on sale in 1991, which was only six years before this machine was made. After asking a few questions here and there it became apparent that no, I couldn't use a LiPo due to the fact the motherboard has no way to recharge the battery. I would need to provide the electronics for such a battery to do this safely and ensure it would work with the existing logic.

Naturally, I chose to use a NiMh instead.

As a complete stroke of luck, I happened to have the exact battery I needed for this to work. I was stunned to the point that I needed to take a moment and have an energy drink - so far I have embarked on a project and I just happen to have all the things I need to do what I need to do without ordering things in. Surely something is going to go wrong soon? The only difference being that the replacement battery was physically completely different, in the AA format, but thats OK.

Checking the battery over made sure that it put out something in the region of 1.2 volts and I set myself to learning why a NiMh is the easiest choice for this application. It turns out, according to Wikipedia, that NiMh batteries can trickle charge when connected to a power source over time. However, they cannot be used as they are being charged, and it takes time for them to charge up. My battery was almost fully charged, I think it came out of a solar powered light that I took the solar panel out of and just kept the battery next to my keyboard, so it is pretty new with almost no charge cycles. I also learned why having a battery with a higher voltage would have been a bad solution.

Because the battery installed on the motherboard would be trickle charging, it would take quite a long time for it to be available to the CMOS memory. If, for example, we had five of them connected together for 6 volts, it would take a lot longer for them to charge completely. Which means that the battery would not be available to the CMOS memory for a lot longer than it would take to charge a 1.2 volt battery.

This means that when you power off the machine, you lose your clock. You would need to reset the clock each time your turned on the machine and save that to CMOS until your battery pack had fully charged.

So keeping it broadly the same as the original part is the best course of action here. All I need to do is connect the AA battery to the relevant terminals and we are golden. But, before we do, lets address one of the design oversights with this board - the battery placement.

NiMh batteries like to leak, pretty much every AA battery I have come across in the last couple of weeks likes to leak, and when they do it can be a disaster. So connecting this battery directory to the board is a bad idea. So lets add a lead with a connector to the board, so we can move the battery away from it, reducing the ability to cause damage in the future.

We are going to solder a lead into the battery terminals that were exposed after removing the damaged part. The top two are marked as positive, red - you dont need to connect both of these to positive, one will do. But if you want you can fly a connection over between the two. Use the square pad to help you keep track of what you are doing. The single terminal on the opposite side is for negative, black. To keep things neat, you might want to poke the wires through the top of the board and solder from below.

Once soldered, we have a connector that takes us all the way to the edge of the motherboard:

Now that part is sorted, I need to take care of a battery holder or retainer. I had a go at making my own with some perf boards and some spare battery terminals that I was hoping to use on the Game Gear, but I wasnt happy with the result, so will keep that for prototyping. Instead, when looking through a box of potential stuff, I found some fairy lights that were powered by two AA batteries in a little enclosure. This was perfect for what I needed.

Removing the switch and single spring terminal gave me the basis to create a single AA battery holder. This also had a switch installed, which was also removed. The unused side of the battery enclosure was used to run a wire down to the double terminal. An opposing connector was added to the newly installed leads and I once again tested the output voltage to make sure it was OK. With the length of wire between the two new leads, I have quite a lot of flexibility when it comes to hiding this box in the case.

Now, what I really wanted to do was plug it straight in and see if it worked. But - this machine hadn't been turned on for a few years, and there had been damage to the board that I needed to clean up. Plus, I didn't know if having a completely wiped CMOS memory was a good thing at this point or what hitting it with 1.2 volts was going to do to it beyond the control of the motherboard. I also didn't just want to plug the PSU in and fire the mains up either without checking to make sure that the PSU was putting out the correct voltages etc - there was still a bit of testing to do, but as of right now I have almost achieved my goal...

But what I can do is install the battery holder in the chassis somewhere out of the way. 

Using a single command strip, the battery case is held in its new spot, tucked away from anything it might hurt if a battery might go pop in the future. I think using a closed battery case will also help prevent any potential damage in the future.

Next up, we need to get started on testing the power supply and see if this is going to cause an explosion with my new battery...

Looking at the Acorn A7000+ in 2022

 Back in 2010, I made a little post about my Acorn A7000+, where I mentioned my past experiences with the machine and its OS.

The other day, I thought to myself that I should get it down and get it powered on again in order to try some things out with DNS. Before pumping mains electricity through it, I thought it would be a great idea for me to take a look inside it because it hadn't been powered on for about four years.

And I am glad I did.

During that four year break, the CMOS battery attached to the board decided to leak and its contents were deposited on the board itself. This requires me to replace the battery and repair the damaged area, This is the story of how I achieved this.

The A7000 and the A7000+ are very compact machines for their period. Despite the outward appearance of the case, which is only really that large due to Acorn recognising that a CD drive would be used at some point, the system itself is quite small and has a remarkably low profile. I am not sure if Acorn had different hardware options in mind when they designed the board etc, but I do know that this design made its way in to a lot of set top boxes.

The low profile is achieved, in part, due to the use of passive cooling - no heatsink or fan is on the CPU here, which is in stark contrast to the time in which this article was written. At the present time, heatsinks and fans can be quite large, and water cooling solutions are becoming more popular. When this machine was made, not having a fan was still something that happened - but more and more systems were getting fans installed at the factory.

The CPU in the A7000+, the machine I have, is probably better being described as being an SoC. I found the datasheet for it here. The main areas it controls are as follows:

This makes the layout on the motherboard quite clean and uncluttered and allows for it to be as small as it is.

This model also provides two methods for expansion in the form of a backplane connector for a hardware format named "podule" by Acorn and a standard internal network connector that is compatible with past Archimedes models. Sadly, Acorn didn't think that networking was going to be such a big deal for their ecosystem, in my opinion, at least. I think it has always remained an after thought.

For the backplane connector, I dont really remember much being commercially available for it at the time. However, these days there are quite a lot of things that are available to buy or to build yourself, including USB interfaces and GoTek interfaces. Sadly, due to the design of the board, you cannot use a CD drive and the backplane interface at the same time. I think this was an oversight and the main reason why I didn't see many expansions for it. These machines were intended to be used in schools, and schools were always going to go for media rich CD ROM based software over an expansion card.

The network cards were useful though, a lot of them at the time supported both Ethernet and BNC, which was really useful. But they were expensive, and to the best of my knowledge still are. The one I have now is just Ethernet, but works perfectly well on my network.

As standard, the A7000+ came with 8MB of RAM from the factory soldered to the board. It also had one memory expansion slot for a SIMM - anyone remember them? They were the bane of PC owners lives, tantalising us with their ever lowering prices. Always knowing that we would have to buy two of them at a time. However, the A7000+ didn't have that drawback, you just needed one to increase the available memory, and could support up to 128 MB, it also supported EDO RAM as well as FPM. This was a pretty big deal back then, EDO was the fast RAM that the cool gamers would have in their systems.

When it came to storage, it came with a 3.5" floppy drive as standard - the mere thought of not having one of these was pure ridiculous, and an IDE hard disc. I think there were various SKU's offering different amounts of HDD space and expanded memory, as well as with a CD drive option. Mine had come from a school, and still has the factory HDD, but the CD drive currently installed is mine (it just happens to be the first ever CD burner I ever owned...). One of the interesting things about RISC OS, at least up to 4.02, is that you have to tell the OS if you have a particular type of drive installed. It doesnt seem to be able to auto-detect them in the same way that a lot of contemporary x86 based desktops would have been able to.

Other than the network port, the A7000+ also has one DB9 RS-232 serial port and one printer port. It also has a PS/2 port for the keyboard and mouse separately. Another one of the oddities with RISC OS is its dependency on having a three button mouse. Annoyingly, the context menu appears on a middle click in this OS as opposed to a right click in Windows. At the time, PS/2 mice with a scroll wheel were still not ubiquitous. Whilst we cannot imagine a mouse not having a wheel now, there were still a lot of places that didn't automatically get wheel mice as soon as they became available, these places include offices and schools who typically only replaced mice as they broke. So if you didn't have an Acorn mouse, or it broke and you couldn't get a replacement, you might have been in quite a pickle. It happened to me when I was testing the machine out later on.

One really quirky feature of RISC OS that, quite frankly, annoys me, is that you need to define a monitor configuration in order to take best advantage of its video capabilities. To this day, I am not really quite sure why you have to do this, naturally all of the relevant Acorn monitors are supported and I have seen them in action. So I know how wonderful the OS can look, and at the time this has to have been the best looking OS on the market. You do get a stock 640x480 mode, but you cant change any visual settings. So lets see if we can change that.

Back to the problem at hand, I need to deal with the battery and the damage it might have caused. Opening up the case reveals that the leak has been largely localised to one specific area, covering the case and the board. So I needed to dig the board out from there to start working on the problem. As this meant taking the whole machine apart, I decided to test out the PSU at the same time and replace a bunch of missing screws etc.

With the drive chassis and the drive cables removed, I was able to extract the motherboard from the case. As we are dealing with a battery leak, I am using white vinegar. According to Google and "people on Facebook", this neutralises the acid from the battery and stops further damage? I am willing to believe it without checking it for myself, you can almost see it working at times. I sprayed some vinegar on the effected area in the case and set it to one side whilst I took a look at the motherboard. You can see in the picture that it is localised to one specific area, which is really quite lucky. Also, you can see that the silicon looks amazing for a device this old. This specific area holds the CMOS memory and the Super IO controller for the floppy drive. The battery was here to provide power to the CMOS memory.

After looking at the affected area under a microscope, I realised that the damage may simply be superficial at this stage - which would be very lucky for me. So after carefully cleaning the area with some vinegar and a toothbrush, I was able to remove most of the gunk caused by the leaky battery. With that done, I was able to heat up the iron and remove the battery itself from the board.

I think the quality of the product helped a lot when it came to cleaning up the mess, that and being able to catch it at this stage. After cleaning up from the removal of the battery with some IPA I was left with a nice, clean set of holes for attaching a replacement. Looking at the battery itself, it looks as it one side of it failed, and its guts spilled out.

The negative side was covered in the same crust that was on the motherboard, but the positive side looked almost as if it were brand new. Obviously, the negative side was the one pointing at the rest of the motherboard. There was no chance life would let that one pass by :).

Now that I have removed the cause of the damage, and the superficial damage, I need to replace the battery with an equivalent that is less likely to leak. I should also mount this battery somewhere that, if it does leak, then it would be less likely to cause any damage to any part of the machine. But this post is getting a bit long, so I think a part two is in order.

Repairing the Sega Game Gear - Part 1

The other day I was talking to one of my friends about a drop in screen replacement kit I have for the Atari Lynx 2, something that I hope to cover in a future post, and mentioned how amazing that handheld was. I got around to showing some of the contemporary handhelds that were around at the time, including the Sega Game gear.

Sega were my all time favourite console makers, and when they backed out of the hardware business I almost cried. I have so many good childhood memories playing the Master System and Megadrive. I never had the chance to own a Game Gear back in the day, and to be honest I wasnt to bothered by that fact, I was never in the position where I would be on a long trip that would mean I needed to entertain myself by playing a video game for two hours. Plus, it was the 90's - you were supposed to annoy your parents back then :)

I have two of these devices, both are in pretty good condition for the age, however one of them got put away in its case with batteries still in its compartments, and I think anyone who has dealt with vintage electronics like this knows how bad this can be. So in this post, I am going to go through the process of taking a look at how bad this is and how I cleaned up the mess. Hopefully at the end, we will have a fully working Game Gear again.

This article is being written as I deal with the issue, so as I find things I will be documenting it with just some slight editing.

Getting straight into this, we can see from the rear that there is obviously a problem. The tell tale signs of battery leakage are present around the battery compartment doors. Normally when you see things like this, you need to think about how the corrosion has affected the circuit board close to the batteries, however for this device I know it was stored vertically. So there is a very good chance that there is no further internal damage. I will need to have a quick check anyway, just to be sure.

Opening both of the battery compartments reveals that four of the six batteries are leaking badly. It is a really good example of why you should use good quality batteries if you are going to leave them in a device for a long period. The Duracell batteries appear to be perfectly fine at this point, and the Hyundai are the ones that have failed. If I remember correctly, the Hyundai cells were the ones you could buy cheaply from Poundland at the time, you could get something like twenty of them at a time for just one pound.

We can see that there is some significant corrosion on the battery terminals, we have lost the springs on some of them, they have been left behind on the batteries that were removed. This happens from time to time in this type of situation. We can also see that some of the leakage has gone down through the battery compartment into the main housing of the device

For a comparison, this is what it should look like. The terminal springs on these devices are pretty large, I guess that needs to be the case as Sega assumed this would get quite a few bangs and knocks as it was being used and they didn't want six AA batteries getting loose easily. I am not sure what the foam padding is for, given that it is behind the battery compartment. But it could be the case that it is there to help when batteries leak? I guess we will find out when we get a look on the inside.

One bad thing I noticed is that there is corrosion around the headphone socket. This is at the top of the unit, and whilst I know it was stored vertically, I cannot remember the orientation i.e. was it stored upside down or right side up.

Given the potential damage here, this isnt just going to be a case of cleaning up the obvious problems and calling it quits as I hoped it might be - I am going to have to open this up and take a look at what is going on. The first thing I will do here though is clean up the cosmetic damage on the battery compartment doors.

The best way to deal with leaks and the stains they make like this is to use white vinegar. Just a cotton bud soaked in vinegar with some slight pressure and carefully start removing the stains. It should clean up pretty quickly and with little effort. You can use isopropyl alcohol to do this as well, however it will require more effort to get the stains up. If you use vinegar, you are going to want to clean the surfaces you have worked on when you are done, otherwise your device will smell like vinegar. Also, its an acid, so you dont really want it hanging around on the plastics of your device for no reason.

Getting into the Game Gear is relatively easy if you have the correct tools. The majority of the screws can be removed with a PH00 bit. However, there is one odd one out inside the cartridge slot, thankfully this can be opened up with a 4.5 security star bit - the same type of bit used in Nintendo consoles and cartridges. If you dont have one of these, you can pick them up really easily on Ebay or Amazon.

With all the screws removed, you will be able to open up the case, be careful though - there are cables attaching the two sides together. There is also an RF shield in there that hinges over a round piece of plastic. Both of these things need to be in mind when you are taking apart the case and putting it back together. For my purposes, I am going to disconnect the cables to make it easier to see what is going on.

Doing so was a good idea, I can see some of the battery leakage has gotten down to the one of the board connectors and some of the EXT port. However, this seems to be the extent of the damage so far on this half of the device.

We also get a chance to see how handhelds were backlit in those days. In this shot, we can see the cartridge slot and integrated heatsink in the middle of the board, above that is another shield with a high voltage warning. Under here is a literal light bulb - a fluorescent tube to be exact. The sort of thing you used to get in your kitchen or in an office. This is what would provide the backlight for the screen and the reason why these early handhelds would eat your batteries. This is also the reason why these devices would get hot if you used them for too long. I dont know much about displays from back in those days, so I have zero clue as to whether you could get a colour screen that lit itself in the way you can now. If you could, I would imagine that it would have pushed the price up a lot. This is the same way the Lynx was backlit as well. Everything else looks pretty clean in here, so all I need to do is clean up that connector with some vinegar.

After some work with a cotton wool bud and a cheap toothbrush, most of the marks from the connector have been removed. Thankfully, there doesnt seem to be any sign of corrosion in the connector itself - but even if there had been and the connector was completely ruined, this is something we could have replaced from the parts we have in the works shop. So for now, we can set this part to one side and get cracking on what I think is the badly damaged half.

This is the area I am most concerned about, it seems like the device was stored vertically upside down. To start cleaning this part up, I need to remove it from the case itself, to do this I need to remove the RF shield first, then extract the damaged board. According to the Game Gear Service manual, this is the amplifier board. This is responsible for providing all sound operations for the device itself, for the speakers and for the headphones. Right now, I know that this is the only piece of circuitry that is damaged, so if it doesnt work after cleaning, I can simply replace it with the same part from another Game Gear.

This is a close up of the headphone socket showing the corrosion. Looking directly down the connector, it seems like the interior is clean, so we might be lucky here, a good squirt of contact cleaner in here should be enough to deal with any gunk that may be lodge in there.

However things look a lot worse when it comes to the volume wheel. Here you can see that there is a rather large amount of corrosion, it appears to have built up between the board and the potentiometer itself, to such an extent that the volume wheel seems to be pulling away from the board. We can also see quite a lot of corrosion around the component marked L1. According to the Game Gear service manual, this is a line filter, but looking at the symbol used for it, it is basically an inductor.

After giving everything a clean with some vinegar and a toothbrush, we have most of the corrosion away from the board itself. The only thing that still looks like a problem is the volume wheel. Whilst I was able to get a lot of the corrosion away from it, there still seems to be a lot underneath. I gave it a blast of Deoxit spray, but this didn't seem to do anything visibly. I think the only way to get any further with getting rid of the corrosion here would be to take the wheel off the board and remove it this way

Now, this leaves us with the problem I initial started this job for, the battery terminals. The corroded ones need to be removed and replaced. Doing this is fairly easy, however this is why the title of this article is "part 1" as I will need to order some replacements to complete the job. Most of the damaged terminals can simply be pulled out of the case, however one set of them are soldered directly to what looks like the power supply board. Looking at the service manual, I believe this to be what is called the DC - DC converter circuit board. It has a sticky shield that helps keep it in place, in my good Game Gear, this is also where the foam I mentioned earlier should be found - and I am glad this piece is here. If it wasnt, then there would be a very good chance I would be cleaning corrosion away from a lot more that the places I have been working on so far. To replace the terminals, the whole board needs to come out, this means removing the two retaining screws and carefully easing the black shield from the case. There is no other sign of corrosion on the board itself, so I dont need to get in there with anything to clean it. However I do need to desolder the terminals and remove that shield.

The tabs that seem to hold the battery terminals in place are marked M21 and M22. From looking at how the black shield that formally held the foam in place is fixed to them, it makes more sense to remove them first and then separate them from the shield.

You only need to remove the solder on the horizontal joints, the round pads next to them seem to be just test pads, they dont hold the terminals into place. Thankfully, it doesnt require too much work with the soldering iron to get these parts out, but a solder pump will make this job a lot easier. You could try some solder wick, but I have never had much luck with that in places like this.

Once removed, you will be left with a lovely, gunky shield to which the battery terminals are adhered to. I had hoped that a liberal wash with some IPA would remove all the gunk from the shield, but it refused to move. This is a testament to the level of engineering that went into these devices - capacitors that are designed to fail (another story...) and foam that will deteriorate. 

To get the gunk off, I ended up having to use a hobby knife to carefully scrape it away, I want to keep the shield intact if I can - its there for a reason. You can use the hobby knife to carefully to get in behind the battery terminals and carefully remove them from the shield. Once that is done, you are free to give it a really good clean. One thing to note here is that IPA wasnt very helpful in cleaning this up, instead I had to use some dedicated sticker remover to really make a difference, I guess Sega really put a lot of effort into making this stuff sticky as opposed to lasting for decades? But then again, how long did anyone really expect an 8-bit handheld from the start of the 90's to be that popular?

Which brings us to the stunning conclusion of this article. I have achieved everything I didn't know I needed to do, but ultimately not the one thing I set out to do, which was clean up those battery terminals. Instead, I now plan to buy in some replacement terminals and replace them before putting the whole thing back together and checking to see if it works or not. To be honest, right now I am not entirely convinced that the amplifier/sound board is going to work. Whilst I was able to remove a lot of the corrosion from the volume wheel, I just dont like the look of it. So I am mentally preparing myself to replace this entire unit as well.

I have also taken a good look at all the capacitors on the rest of the boards, whilst I cant see any that look like they need replacing, there is one thing that most people who know what they are doing with the Game Gear say - you will always need to replace the capacitors. Probably the best thing to do here is to take my component tester and see if I can test some of these in situ to see if they are still in good working order. If they are not, then it may be a good idea to get them replaced whilst I have this thing open...

Flashing The ATTiny85 Bootloader

 Recently, I have been looking at the ATTiny85 for use in some tiny projects that I have been thinking about recently. This is an extremely small and versatile microcontroller that can be used in a number of different settings where space or size is a consideration.

You can typically see these used in the Digispark USB Development boards made by Digistump, it is a very distinctive board that you may have seen quite a lot. There are also a number of different ATTiny85 based development boards available on Amazon and eBay, the version I initially got for myself was from Amazon here.

One of the really cool things about the ATTiny85 is the fact that the microcontroller itself is so tiny, as of writing this article I have seen them in two packages, SOP-8 and a DIP-8. It is also possible to buy development boards that have a DIP-8 socket, so that you can provide your own ATTiny85. These are really useful, as it allows you to program your microcontroller before using it in your build.

example of an ATTiny85 development board with DIP-8 socket

When you compare the price of the ATTiny85 itself against the price of a development board, you can see that the boards themselves, even without the microcontroller, cost a lot more. You can pick up 10 ATTiny85's from AliExpress for just under £5 - which is roughly the cost of one development board when you factor in how much shipping could be.

However, this comes with one drawback - the microcontrollers you buy at these prices from these locations will quite often come with no bootloader installed. So even if you follow all the instructions on how to use one of these with the Arduino IDE, for example, you will keep getting a message telling you that the "USB device connected is not working", or something very similar.

Annoyingly, even if you have a socketed development board, you still wont be able to install the bootloader, regardless of having it connected via USB.

So, you may have found this article because you are interested in flashing the bootloader on to an ATTiny85 - or you may be here because you have bought some cheap ATTiny85's from AliExpress and they are not recognised by Windows. This is what happened to me, and these are the steps I took in order to get them into a useable state. You may have also bricked your ATTiny85 and you need to reinstall the bootloader, these steps will also help you to get back into a working state.

To get this done, I used the following:

• A Windows 10 PC, 64 bit.
• An Arduino Uno R3
• A breadboard
• Some jumper wires
• A 100nF ceramic capacitor (code 104)
• a 10nf electrolytic capacitor
• A DIP-8 socketed ATTiny85 development board
• A DIP-8 ATTiny85
• The Arduino IDE

To get started, we are going to need to install the drivers for the ATTiny85 so that we can use it over a USB connection. This is going to be our primary means of communicating with this microntroller for the purposes of uploading sketches to it. Thankfully, we can make use of the drivers provided by Digistump, the latest release can be downloaded from their GitHub. Of the available downloads, we are specifically looking for the AVR release of the drivers, this is important for later on in the process.

There is also a second way of installing the drivers using Zadig, which is a little more complex. I dont really want to go into it too much here, but during this process, you will actually download the files you need to install the driver using Zadig instead.

Next, we need to get the Arduino IDE open and connected to our Uno. This is for a couple of reasons, firstly, we need to change the verbosity of the compile and upload process shown in the console window. To do this, open up the preferences by going to File, then Preferences.

Under the Settings tab, you will find something called "Show verbose output during", with two checkboxes for compilation and upload. Tick both and click OK to save.

Now, we need to make sure that the IDE is setup for the Uno. For most people who are used to doing this they can skip this step. For new users, go to Tools - Board: - Arduino AVR Board - Arduino Uno. Then set the port under Tools - Port. Quite often, the port you need to use is clearly marked as the one used by the Uno:

the Uno I used was clearly visible in the list of ports

If yours doesnt show up like this then just disconnect your board and take a note of what ports are available. When you plug your board back in you will count one extra port. This is the port that your board will be using.

You can also check your available ports in the Device Manager, but this pretty much does the same as checking in the Arduino IDE. As you can see in my example, COM10 is clearly labelled as an Arduino Uno. However, depending on what type of Uno you have, you might see something different.

We now need to do the important bit, under Tools - Programmer, we need to select AVR ISP. 

ISP, or In System Programming, is the method by which we are going to write the bootloader to our ATTiny85 further along.

Whilst we are in the Arduino IDE, we can configure it now for use with the ATTiny85 and development boards based on it. 

Unfortunately, this controller/board is not available from the boards manager by default. So we need to provide a URL for an additional board manager. Thankfully, Digistump have provided just such a resource for us to use. To configure this, we need to add the URL from Digistump to our Arduino IDE preferences, these can be found in File - Preferences. Under the Settings tab, there is a text box where we can add our additional board manager URL, you can add as many of these types of URL as you like of you click the little button next to the text box. The URL we need to enter is:

http://digistump.com/package_digistump_index.json

Once entered, click on OK. Now head on over to the Boards Manager, in the search box type in Digistump. This will bring back all of the boards from Digistump that we just added via the URL, we are specifically looking for the Digistump AVR Boards option, this should be at the top of the list, but this is the one that we need to install.

Doing this will configure the Arduino IDE for use with our chip later on in this guide. It will also install all of the example sketches, which we will also want later on.

Once this is done, we need to verify that our connection to the board is working. We also need to verify that the board is working as well. To accomplish this, we can simply upload the Blink sketch. If everything works and Blink is executing, then the setup for this portion is complete.

We need to grab some important information from within the the write and compilation output in the console window. We are specifically looking for a reference to avrdude.exe and its configuration file. To find this, take a look down the log for Blink.hex - assuming that you uploaded the Blink sketch. Once you have found it, you will see the path for avrdude, for example the path for me was as follows:

C:\Users\rsain\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17

Next up is the electronics, we need to set up some connections from our Uno to a breadboard according to this image:

note the electrolytic connected across reset and ground

A couple of things to note here:

You can use crocodile clips to create the connection from the negative leg of the electrolytic capacitor to the ground rail. It makes things easier, as opposed to trying to stuff legs into single holes.

If you have the electrolytic capacitor installed as above, you wont be able to upload any sketches, it will cause the programmer to fail. This was an issue I ran into when trying to test my Uno was working, you can emulate this yourself, as far as I know it isnt damaging the Uno, it is just keeping it in a reset loop.

The ceramic capacitor is the 104, 100nf mentioned in the parts list above. It goes across the input voltage, however you may be able to get away with not using this, but it is something I did not try out myself as pretty much every diagram that explained this type of configuration used this capacitor.

And thats it, you dont need to do anything more than this to get writing to the chip. The final part we need to concentrate on is getting the bootloader to write to the microcontroller and creating the command needed to write it, along with some configuration.

The file needed to write to the chip can be found here, this is the GitHub repo for Micronucleus. Its a good idea to download the entire repo, or if you have Git installed, grab it on to your machine. We are specifically looking for a file called  t85_default.hex which can be found in micronucleus/firmware/releases/

This repo also contains the relevant .cfg files you need to install the drivers via Zadig.

To get started on the command we need to execute to get the hex file written to our chip, I am going to use the PowerShell Integrated Script Environment. This is quite a good tool for putting together complex PowerShell commands by providing a scripting window as well as a PowerShell terminal in one place. This is part of the official PowerShell release from Microsoft, so should be available to you from the Start menu.

On first opening the ISE, you will see something like this:

To give a very brief explanation of how the ISE works, the top section is the script window. Here you can write and execute PowerShell scripts using the standard play and stop buttons that you will find in most IDE's. One cool thing about the ISE is that you can select a portion of your script and choose to just run that instead of everything at once - this can be very useful when trying to find breaks.

from left to right - run, run selection, stop

The bottom window is a regular PowerShell terminal. You will see the results of any script you execute here. You can also enter commands directly into the terminal and execute them if you want to.

Thats pretty much as I want to go into the ISE for now, I think it is a very useful tool to have and is awesome when you are creating PowerShell scripts. Now, we need to prepare a couple of things before we start building the command. Firstly, I am going to copy the t85_default.hex file I got from the Micronucleus Git repo above to C:\temp. This is just to make our command a little shorter.

The last bit of preparation is to navigate to the location where the avrdude executable is found - this is why we needed to download the AVR specific version of the Digispark ATTiny85 drivers earlier on. Again, this is to make the command a little shorter. To do this, we can use the PowerShell terminal in the ISE that we have open. We captured this location a little while earlier, so in the terminal we simply do this: 

Listing the contents of this location will provide you with two folders. The bin folder holds the avrdude executable and the etc folder holds its configuration file. If you navigate to bin, you will be able to test that avrdude is available to you. Despite the fact that I already knew that avrdude was available for use by virtue of the fact that I had already used it via the Arduino IDE, I went ahead and executed it in the PowerShell terminal anyway and got the following:

If you are following along with this article and you can see this, then you are doing fine at this point. If you are getting an error message then close the ISE and open it again as an admin.

Now we know that avrdude is available to use via PowerShell, we can go ahead and start putting our command together. We are going to build that in the script window and I will go over it line by line trying to explain what is happening.

Because this command is going to be quite long, I am going to break it down into a couple of lines. You can do this in PowerShell to any command by putting a backtick "`" before starting a new line. You are going to see this at the end of almost every line we go through here.

The first line is simple, we are just going to execute avrdude:

For the next line, we will use the -C flag. This allows us to provide the current execution of avrdude the location of an external configuration file that we want to use. This is an important step - we need to use the config file that has been set up by the Arduino IDE because we know that this one works. We dont need to create a new one.

On the third line, we are going to configure avrdude to write to our ATTiny85. The first flag I set is -v, this provides a verbose output, I always enable such a thing when I am doing something like this. I recommend it. Next is -P, this is where we provide the port number to use whilst writing to the chip. Choose the one that has been working for you in the Arduino IDE. However, please note that you wont be able to write anything to the chip if you already have an open connection to this serial port, and an open connection can be the serial monitor in the Arduino IDE itself. Next, we are going to set the programmer with the -c flag and set this to avrisp and the baud rate using the -b flag. Finally we set the product with the -p flag with attiny85:

The final thing we need to do with our command is configure the memory options we need to get everything written to the chip, and put it in a usable state. All memory operations are set with the -U flag, read/write, target and expected format. 

Naturally, the aim of this process is to write a hex file to a microcontroller and the first memory operation on this line reflects this. However, I also discovered that we also need to write the fuses on the chip as well in order for us to be able to use it. I actually did a little bit of reading to find out some more on these fuses. They are not fuses in the sense that most of us would think of them, they are not components inside the chip that are designed to fail if something happens. Instead, these are actually bytes that store flags to enable and disable individual features of the chip itself.

So if you were like me, and you were wondering how you can write a fuse to a chip, what we are actually doing is writing something to a location in memory on the chip to configure its hardware.

The first section of line 4 specifies that the type of memory we want to use is flash, w indicates that we wish to write to this memory. The full path to the hex file we downloaded earlier is provided here, the i at the end indicates that this is in the intel hex format.

After this, we have three separate write operations to memory. This is where the fuses are written, the memory type here is instead fuse. Instead of a path to a filename, we see instead a value in hex, and because of this the source format has been set to m.

This setting is for immediate mode, it means that avrdude will either provide input from the keyboard to be written to memory or from the command line. The hex value we see in the command is the location in memory that we need to write to. All the process wants to do is set that location to either on or off, writing to it sets it to on.

And thats it, everything we need to get our chip flashed is ready to go. 

Make sure that your breadboard, chip are connected to the Uno and that you are connected via USB, then just press play from within the ISE and boom, the write process will get underway. That is as long as you can execute scripts on your system... If you have never done anything with PowerShell on your machine before, then the execution of unsigned scripts may be disabled and we need to change this in order to run our script. Basically, any scripts you create yourself will be unsigned unless you sign them yourself. Most of us will never need to sign a script, especially when we are working on things like this at home, so it is easier to change the execution policy.

We can do this by running set-executionpolicy remotesigned on the terminal, this will cause a window to pop up asking you to change the execution policy, click on the Yes button. This will allow you to run unsigned scripts locally, but signed scripts from the Internet.

Now when you run your script, it will execute, hopefully without errors. I cannot preempt all the problems and errors you may encounter. If you have been following along and have not encountered any errors so far, then I would suggest checking over the PowerShell script as this is likely to be where your issue could be. If anyone reading this does encounter a problem and they are not sure about what to do, I would gladly try and help out.

One issue you might encounter is not being connected to the correct COM port, or not being connected at all. The error you get for this is a little esoteric to say the least, however if you get this screen, then double check your connection:

Once the process is underway, you will get a lot of information about the current status of the chip written to the screen. You will see each memory operation that we specified in the PowerShell command get executed against our chip along with its status. The following snippet shows our hex file being written to the chip itself:

And that is it, our chip is now flashed and ready for use. We can try a quick test out here to prove it by uploading the Blink sketch to it. I did this by plugging the chip back in to my development board and opened the start sketch for the ATTiny85, you can get this from File - Examples - DigiSpark_Examples - Start. 

One curious thing about the ATTiny85 is that it shouldn't be plugged in when you want to upload a sketch to it. Instead, you click the upload button and wait until the programmer asks you to connect the device, you will see this down in the console window. Once connected, you will see the sketch get uploaded and, fingers crossed, your development board will have a built in LED that starts blinking.

If you see this, you have just proven that the process you have undertaken flashes a blank ATTiny85 with its bootloader.

If your development board doesnt have a built in LED, instead bring bring one of the pins up high and low with a delay then bring it low. You can measure it with your meter against ground, you should see it go from zero to around 5 volts as the delay changes it status.

And there we have it, a method by which you can buy super cheap ATTiny85's from places like AliExpress and get them usable nice and fast. One thing I did to make my life easier was to build a very basic device that would allow me to do this even faster in the future. With a bit of stripboard and a couple of components, I built myself a little circuit that allows you to flash an ATTiny85 using the process above. It is nothing fancy at all, it just replicates what I had on the breadboard, but it means that all I need to do is wire it up and connect it to an Uno to get going, plus I was a little bored one day.

the chip in this diagram should be socketed, but there was no asset to represent this

This is a very simplistic design, but it helps remove the annoyance of having to connect the electrolytic capacitor to the Uno itself.

IC1 represents our ATTiny85, the application I use to generate these images doesnt have anything for an 8 pin socket, so a bit of imagination is required here. Naturally, this is where our chip goes.

C2 removes the the electrolytic capacitor we had connected across ground and reset on the Uno itself. Now we just need to connect two cables back to the Uno. The bottom connection goes to reset on the Uno and the upper connection goes to ground on the Uno.

The connections for J1 are just the same as they were on the breadboard. Starting from the top we have:

• Vin
• Pin 13 on the Uno
• Pin 12 on the Uno
• Pin 11 on the Uno

There is only one connection from J2, the top connection is connected to pin 10 on the Uno.

This allows me to have something that is purely dedicated to flashing the bootloader on to an ATTiny85 whenever I need to. Naturally, I could have made the connections a little more intuitive, and there is a way you could use the same board for uploading sketches to the chip - but I want this to do one thing and one thing only, and that is to flash the bootloader. I also want it to be a process I have to think about, so that I dont wipe out a bootloader on a chip I have a working project on, it needs to be an intentional move to stop me from messing up.

If you go ahead and create something like this for yourself, make sure that you cut the tracks under the socket for IC1. This is stripboard, so everything is connected on one axis. Whilst this is very useful, you will need to cut those tracks for the build to work.

This is what mine ended up looking like:

Just a point to make here about the build, those header sockets I am using there are the round type instead of the square type. They seem to be a lot easier to work with, especially when you are trying to squeeze jumper wires on to small builds. They are quite often cheaper as well:

Now that I am able to write the bootloader to my chips, I can get on with experimenting with them and hopefully using some in a couple of projects that I have in mind. If anyone has tried the process I have described above out, and encountered a problem that they cant get passed, I will gladly try to help out in the comments, or by even adding a new section or two to this article.

Also, it may be the case that Micronucleus is not the only bootlader that can be written to these chips. Recently, I have been reading about this really interesting project called V-USB...

Here are the links and resources I used to get this mini-project done:

Digistump GitHub:

https://github.com/digistump/DigistumpArduino/releases

Micronucleus GitHub:

https://github.com/micronucleus/micronucleus

Arduino IDE downloads:

https://www.arduino.cc/en/software

Zadig:

https://zadig.akeo.ie/