Mending the Micros - The VIC-20

To create some more interesting content, and explore an avenue of electronics repair I miss, I've been on eBay, and spent some money on some 80's micro-computers. Not just any 80's micro's... oh no, broken ones. 

I was hooked on computers when I was a teen. Ever since my Dad borrowed a Sinclair ZX80 from a colleague of his and I sat there ... typing away on it's membrane keyboard, learning Basic as I went. A couple of years later, one Christmas, the family got an Oric-1 (the 48K model) with colour and sound! As software was somewhat limited, a Sinclair Spectrum followed, and then the mighty Commodore 64. The hours I spent writing stuff in both Basic and assembler... 

If you don't subscribe to me on youTube, you'll have missed the first part of "Mending the micros", where I fix a down-at-heal ZX81, and give it a little more memory. It's here .. https://youtu.be/RDEty5WAtZs

In the spirit of utterly giving myself far too much to do, the Vic-20 is going to be available here, written in my own inimitable style, and in glorious high-definition on youTube here https://youtu.be/u37iBSqEdU8

The machine comes in it's original box, with a manual, a power supply, and the "earlier" type of
datasette, the C2N.

It's an early machine, that uses a two-pin plug to supply 9VAC from the small external transformer. If you have a VIC-20 or a C64 with the later type of DIN plug supply, it's important to verify it's operation, or better still, replace it, as they supply both 9VAC, and 5VDC, and the 5VDC commonly rises above maximum limits, and does damage to the machine. 

The machine is disassembled, and given a cursory check over. It looks good, except for the heatsink
which is bolted to the bridge rectifier has worked lose. It's removed, and given some new heatsink compound before refitting the heatsink and securing the screw with a dab of thread lock.

The modulator is connected to the 5-pin output socket, the machine switched on and the trusty workshop TV tuned in... 

OK, a screen full of jumbled characters. Each of the socketed IC's is removed, pins checked and re-seated. No change, unsurprisingly! 

The reset line and 6502 clocks are checked... all fine.

At this point, I decided that booting the VIC-20 dead-test cartridge would be a good idea... except for I don't have one! Thankfully, there is a great open-source project called the VIC-20 Hyper-expander, and it can be found at Sven's site here : http://tech.guitarsite.de/vic-20_hyper_expander.html 

The firmware set one, has dead-test in it. Excellent. A single PCB is ordered from EBay...

 

and is duly populated...

 ... and an EPROM blown with dead-test (and others) on it. 

The cartridge's dip switches are set for dead-test, and inserted. The machine is powered on... and ... ugh ... same.

Interestingly, when the cartridge's reset switch is pressed, nothing changes on screen. The reset line is again checked for operation, and, the reset line is asserted when the reset switch is depressed. Hmmm..

Some tea is consumed, and some reading up on the VIC-20's start up procedure... video 

Once the 6502 is reset, it looks to address $FFFC and starts to run code. This address is in the kernal ROM. The kernal then checks to see if a certain pattern of bytes is present on the cartridge slot, indicating a cartridge is present, and if so, jumps to $A000 (the cartridge) and runs code there, if not it runs BASIC..  So, if the fault is present with or without a cartridge, is my kernal ROM bad?

I hatch a plan. My kernal is a 901486-07, and a .bin image is available here :  http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/vic20/index.html 

The TL866II plus is pressed into service, and a 27C64 EPROM is blown. There's a slight issue. The 27C64 has 4 more pins, and (obv.) a slightly different pin out. 

Thankfully a neat adaptor PCB is available form the wonderful myretrostore.co.uk. 

My EPROM is installed into the adaptor.... 

... and powered up ... ugh, no difference. Back to some tea and thinking. 

After reading up on VIC-20 video memory here : http://tinyvga.com/6561, it appears the VIC-20 moves it's video RAM around, depending on how much memory expansion is fitted. This isn't good news. If my video RAM were to be faulty, plugging in the hyper expander should, at the very least, alter the fault. It doesn't. Damn. This points to a faulty VIC 6561, not ideal. Despite this, I decide to check every other eventuality first. The RAM chips are scoped up. They are 2114 SRAM's. They are wired in pars, to give 1KB per pair (except UE1, which is always 512 bytes of colour RAM, regardless of expansion). 

Scoping along the IC's shows UC5, UD5, UC6 and UD6 have their CE (or CS) lines permanently high

(there's some noise there, however) ... this is not expected activity. Tracing back the schematic , these lines are fed from a 3 to 8 line decoder, a 74LS138, it's pulled out and tested. Its BAD! 

Is the VIC OK after all? After about an hour searching through all the 74 series logic I have accumulated over the years, and not finding a single 73LS138, one gets ordered! (According to my gaffer, the Germans have a word for not ever having the right chip in stock.  Fockingneinenchippenblasten. He assures me his German is excellent.). While I wait for the new chip to turn up, a socket's fitted, because that's the polite thing to do. 

A brand new 74LS138 is fitted, and no difference, until I realise I'd desoldered the wrong chip. Replacing the correct IC, and there's no difference in the fault. Damn. 

It looking more and more like the video RAM is not being addressed correctly, and that's under the control of the VIC. A brand new, old stock VIC 6561 is procured, and fitted ... and ... the fault remains. Dammit.

Suspicion is turned to the other two IC's related to the 3-8 line decoder, UC 2 & UC3 (74LS04 inverter and 74LS02 NOR) , but both test perfectly once removed. 

Could it be the RAM? It's a possibility. Now my DiagnoSys IC tester only does DRAM, not the 2114 SRAM used in the VIC, so a cunning plan is needed, and, thankfully Carsten Skjerk has beat me to the idea of using an Arduino to do the testing, so his project is implemented using an Arduino Nano. The details can be found here  https://github.com/skjerk/Arduino-2114-SRAM-tester

I elected to remove all of the RAM, test it all, and add chip sockets (it's the polite thing to do) 

The RAM all tests good, until I get to UE5 , one of the chips with the dodgy chip select line...

Gotcha! Some 2114 RAM is ordered... 

and duly arrives, and is tested prior to fitting.

A "new" 2114 is installed in UE5.. and it's switched on... a similar, but slightly different pattern of garbage appears on the screen.

UE5 was definitely faulty, but what about it's partner UD5? It passes in the tester... out of sheer desperation, I pull it from it's socket and fit a replacement IC... 

Bingo ...

So why does my tester pass it? 

I slept on that issue. The chip tester permanently shorts the CE pin to ground , and yet we'd had an issue with the CE logic ... was that why? No....

After doing some further testing, it turns out that my fault UD5 is intolerant to a slightly low voltage. The VIC's 5V rail is around 4.85V... the tester's is 5.1V ... I ran a load of tests and found that the IC starts showing errors at around 4.9V ... but here's the weird bit ... starts working correctly again around 4.75V!! By the time the voltage falls to 4.3V, it stops working again, unsurprisingly. Make a mental note to one day create a tester with a variable supply. 

So with the electronic refurbishment completed, the case is stripped down, and once the long and suffering Mrs Doz is out for the evening, it's sneaked into the dishwasher, along with the keyboard key caps. 

It comes out like a new one !

Meanwhile, the C2N datasette unit is given some attention. 

The cassette door is removed by very carefully bending the two sides in with a screwdriver. Carful with the door opening spring. It's probably best to remove it. 

The tape path is given a clean, using IPA on the heads, and capstan, and Rubber roller restorer on the pinch roller. 

The chassis is held into the case by three screws, this allows easy access to the tape counter belt, and the small take up idler. The belt is replaced, and the idler cleaned. 

After the case comes out of the dishwasher, it's placed in the sun to bleach the yellowing on the case for a few days, it comes out well... 

Meanwhile a suitable belt turns up from ebay to replace the main drive belt.

Replacement is best achieved by loosening the screw which adjusts the amount of end float the capstan flywheel has, and sliding the belt under.

The C2N is reassembled, remembering to re-fit the door spring, making sure it sits in the groove on the door. 

The VIC's motherboard is re-united with the case, and the LED and keyboard refitted

And the computer is tested .. 

Hardly taxing !

Time for a bit of retro entertainment! 

Now, you may have noticed the diagnostic ROM in the Hyperexpander wasn't working (which really would have helped!) .. and, infact the Hyperexpander wasn't really doing it's thing at all. Regardless of the settings on the dip switches, I couldn't select more than the basic 3K expansion. 

The Hyperexpander was scrutinised, and, yep... I'd stuck the High RAM chip in the EPROM hole... a rookie error. Having put this right, the Hyperexpander was re-installed. No change. The two 74LS148 chip select decoders were removed, and sure enough the low RAM one tested faulty. Having replaced that (and socketed both!) the cartridge was tested again. No change ... 

I suspected the RAM IC's may be faulty. So I built a 62256 RAM tester, in a similar fashion to the 4112 tester above (I'll detail this in a separate project) Both chips tested fine. Damn.

Everything on the hyperexpander is tested. Everything. It's all good... so the fault's in the VIC itself? It would have been easy to prove if I had another VIC-20 to test the cartridge in, but I don't... 

Back to the schematic. 

I turn my attention to what memory select lines appear at the cartridge slot.. The 3K expansion is controlled by the RAM lines, so we can safely ignore those. The other control lines, that don't appear to be functioning are BLK1,2,3 and 5. These are switched on the cartridge. They all go back to UC5, which is new. It's tested anyway, and is innocent. This IC is connected to one of the 6522's ... they're swapped over, the fault remains... The BLK1 line is traced from pin 14 of UC5 back to pin 10 of the expansion port.... except it appear on pin 10 & 11 ... removing UC5 shows there's a short circuit between pins 13 & 14 on UC5, 73LS138. A close look at the print around pin 14 shows it had lifted slightly. The socket is removed, and the print repaired. 

The short sill exists! Careful examination of the PCB, and a tiny solder bridge across two vias becomes apparent! The solder looks original ... has this fault existed since it was made? . Aggghhh .. the short is cleared. 

Bingo ... 

The motherboard is placed back in the case, and just tested before reassembly. It's dead. Wait ... whaaattt?

There's nothing on the power socket (9V AC). Sure enough the fuse in the transformer has let go! It's replaced and operation is restored... this thing hates me. 

Once it's all reassembled, the EPROM is switched in, as well as RAM. Excellent, we have everything working. About time... 

Another saved from landfill!

62256 SRAM Tester

If you've been my youTube channels lately, and following the VIC-20 story, you'll know I built a Hyper-expander. You may have also noticed that it didn't really get used much in the repair video. There's a reason for this.... 

It didn't work.. 

Even once the VIC-20 was repaired, nothing I did would get the VIC to recognise more than the 3K extension. The EPROM wouldn't load at all. 

Investigation required. 

The cartridge was pulled apart , the EPROM checked, and the two 74LS148 gates. I wish I'd socketed everything! The EPROM and the two decoders proved innocent.  

That leaves the 62256 RAM IC's. 

So, how to check them?

I could pull the ZX81 apart, and test them in there, but we can't access the full 32K.

SO, inspired by the 2114 tester I constructed for the 2114 SRAM during the VIC repair (https://github.com/skjerk/Arduino-2114-SRAM-tester) I decided to have a look for an Arduino based tester, whilst there is a version for an arduino Mega, I don't have one to hand. The issue is, a normal Uno (or any ATMega328 based Arduino) doesn't quite have enough pins. We need 15 outputs for the address bus, and 8 for the Data bus. Two 74HC590 counters are fielded in to drive the address bus from just two pins (clock and reset).

Here's the theory of operation. The Arduino resets the two counter IC's to 0, by pulsing D3. A pattern of data is generated sequentially between 0b00000000 to 0b11111111 and written to the first address. It's then read back, and compared with the written pattern. If all is well, then the address is incremented by pulsing D2 and the procedure is repeated. If the pattern is not read back correctly, the fail LED is lit, and a message with the error written to the serial interface, but the test will run until all addresses have had all patterns written and read back. It takes quite a while to run.

While the test is running, both PASS and FAIL LEDs are illuminated. The green LED I added to pin 2 of U2 (via a 1K resistor) to provide some indication that the test is running, if no terminal is connected. 

Normal running looks like this on the serial interface.

62256 SRAM Tester by Doz.    

Running test pattern 00000000

Running test pattern 00000001

Running test pattern 00000010

Running test pattern 00000011

Running test pattern 00000100

Running test pattern 00000101

Running test pattern 00000110

Running test pattern 00000111

...

Running test pattern 11111110

Running test pattern 11111111

All tests complete 

PASS

Hit reset to re-run

a failure looks like this:

ERROR at 0x5A64 - Got: 01100001 Expected: 01100010

The code can be found, as usual, on my github page.  https://github.com/andydoswell/platformio/tree/main/Projects/62256%20test 

Please note this is a PlatformIO framework project. You can probably clone the git, and pull main.cpp out of the SRC folder, and rename it .ino , and it'll probably run on the Arduino IDE, although I haven't tried it. 

To cut a long story short the RAMs were innocent, the fault was back in the VIC-20 itself, but at least we have a device to test them now!

The future?

Dear reader,

You may have noticed that over the last few months I've been rather active on YouTube. I'd neglected the YouTube channel to be honest. It takes a lot of effort to make a video, it's not just the filming, but the editing, rendering, uploading, dealing with the odd copyright hassle, etc etc.

I find it much easier to take a few photos and write. 

Back just before Christmas time, there was a slight change in my career. It involves me being in front of a camera, presenting technical stuff, as well as my engineering duties. This didn't initially sit well with me, so I thought I'd get some practice in and rejuvenate the existing "Doz' Television Workshop" YouTube channel. 

Well, it's gone all a bit better than expected. Each video I've done on Doz' Television Workshop has gained me subscribers (and lost the odd one or two along the way), and I get way more "views" than I do hits on this website. This has soaked up a lot of my time. 

So, what's the future?

I don't want to neglect the website. It's like an old friend, I thoroughly enjoy writing, and I don't want it to just become a list of my YouTube videos, and indeed, from now on, I won't just post up links to videos. If you want to watch my videos, just hit the subscribe button, if you don't, that's fine.

I think this site has a future with design projects (and, in fact there's a few in drafts), that may have accompanying videos, maybe not so much the repair and restoration projects. 

I have really enjoyed channels like Noel's retro lab, ojnoj. Irish Vintage TV and Radio, Shango066. These videos tend to be longer than many, I find myself absorbed by them. It's a community I want to be a part of. In the day job, our marketing dept. tell me my videos should be "around 10 mins" ... well, I can't see that happening here! There's just no way I can do an in-depth diagnosis & repair in just a few minutes, and I won't try. To be honest, it's something the website doesn't convey. The actual length of time it takes to do these things.  

This isn't about money. This website carries a few adverts, and, in it's entire lifetime hasn't earned me £130 in revenue. My YouTube channel can't be monetised (as yet), I simply don't have enough subscribers. Let's face it, I'm never going to retire on this. 

This isn't about my ego. Yes, I get a kick out of someone watching my video, but it's in the hope they found it educational, or at least entertaining. It's about sharing.

Let me have your comments. 

Yours Aye,

Doz.

The return of Ian's Leak Stereo 20 and Varislope 2

Ian's had some problems with the Leak gear I did a year or so ago...

Here's a couple of videos of the repairs. 

Solar lighthouse garden ornament - A design that could never work.

About 12 months ago, the long and suffering Mrs Doz bought me a solar powered garden ornament, in the shape of a lighthouse. 

It's got a white 5mm LED, which is situated inside a rotating silver reflector. Quite a nice touch, and more effective than just a simple flashing LED... except it never worked properly. 

There's a push button switch on the lamp housing, which switches the unit on. After dark, the LED illuminates. Once. 

The following day nothing happened. 

It's not worked since. 

So I disassembled the lamp house to see what the fault was. It consists of two parts, the top part consisting of the solar panels, a charging circuit and LED driver, and a lower part with the motor and it's gearbox, and a 600mAH, AA NiMH cell. 

I popped the cover off the motor unit in an attempt to find out what the problem is.... and spot it straight away. The motor is connected via the push button switch, straight across the battery. As soon as it's switched on it will start turning, and eventually discharge the battery. The solar cells aren't big enough to keep the battery charged up enough. What a silly design. 

I was hoping that the LED driver in the top would be able to provide a suitable switched supply to the motor in a similar way to the LED, but alas no, it's got a small flyback converter to provide ~2.1V to drive the LED. 

So, a plan is hatched... 

A separate solar cell, and battery connected by a wire to the motor unit. 

Recently we had to replace another solar light in the garden, after it was damaged over winter. This has yielded a nice solar panel and it's fitted with a single AA NiMH cell, excellent. The battery is tested, and looks to be in reasonable condition. The control electronics in this enclosure are removed (again, it's a flyback converter)

So we need a circuit to charge the battery during the day, and switch on the motor at night. 

The solar cell charges the battery via D1, a BAT43 small signal Schottky diode (a strange choice, but it's rated to 200mA, which is more than the charging current capable of being delivered by the solar cell, and it'll have lower forward voltage drop than a normal silicon diode), which prevents the battery discharging into the solar cell at night. When the cell goes dark, Q1 loses it's base bias via R1 &R2, and switches off, which causes the voltage at it's collector to rise. This in turn switches on the base of Q2, which causes it to conduct and switches on the motor. 

After a bit of experimentation on some breadboard to get the values of R1 & R2 right (this effects the threshold where the unit switches the motor on), it's built up on a bit of perfboard, and fitted inside the enclosure.

After sealing everything up with some liquid rubber, it's taken outside ...

Now just to wait for nightfall...

Further experiments & improvements to the Arduino Geiger Counter

My dad recently returned from a small socially-distant holiday to Cornwall.

"I've bought you a gift, saw this and thought you'd like it!"
"The chap in the shop said it might be a bit radioactive" *

It's a "Radio Compass" from an aircraft. This is used to display a heading to a terrestrial radio beacon. This one's old. Old enough to have a Radium-266 dial. Waving the geiger counter near it proves the point, end-stopping the meter on both the SBM-19 and SBM-20 tubes. It does show a potential limitation in my counter though.. let's investigate....

The original project is here

The count rate appears to be being limited to a shade less than 1000 CPM. by something. It could be the tubes are saturated. It could the arduino is not capable of counting that quickly. It could be the high voltage supply is incapable of delivering that amount of current when the tube is at a high pulse rate, and the HT is falling between counts.

After poking round the high voltage supply, I think we can conclude it's not that ... 

There IS a delay in the tick function of the sketch, and also digitalWrite is notoriously slow.

After modifying the sketch , there's no detectable change, even with that delay removed, which IS still blocking the sketch. 

Looking closer on how I can get the loop to run faster, I'm unnecessarily updating the LCD every cycle, and reading the battery every 5mS ...

 ... this is moved into a non blocking loop counter, to update every ~3 seconds or so ..  

Oh that's fixed it ! I'm now getting a reading of ~30,000 CPM maximum from my radium dial... 

I also needed to tweak the meter movement routine a shade to compensate for the faster loop speed.

The new sketch can be found on my git as usual https://github.com/andydoswell/geiger_counter

*The chap in the shop also told my dad the chap he bought it from had a stack of them under his bed... I'd hate to see what his dose rate is like! 

Garmin HUD & ESP 32 stand-alone module.

A couple of years ago I upgraded my mobile phone, and was dismayed to find Garmin no longer supported my much-beloved HUD (Heads up display), rendering it redundant. It was only 7 years old at the time... is that acceptable product life expectancy? Gutted. 

I seem to remember reading somewhere that the same display was built into BWM cars ... are BMW owners in the same situation?

It featured in my Mini speedo video here. 

Thankfully, someone had reverse engineered the bluetooth serial protocol used to control the device. 

The original work was carried out by gabonator (here), Frank Huebenthal and subsequently by skyforcetw (here). Stunning work. Skyforcetw had even written an android app to interface Google maps to the Garmin HUD, excellent. Except nothing I could do would persuade it to run. 

So I tried skyforcetw's arduino library, and attempted to load it into an ESP32, and tried to modify it for SerialBT. After a lot of debugging and chopping of code from Frank Huebenthal's work, I finally started to get some meaningful information displayed on the HUD. 

So, after this success, a plan was hatched. I just want some meaningful info displayed. I'm not particularly interested (nor capable of) writing something for my phone to run , so I'm thinking about a simple speed display, and maybe some other info.. 

So a UBlox GPS module (this one's an M7, but it will work fine with the cheaper M6)  is hooked up to the ESP32's Serial 2 port on pins 16 & 17, and to the 3V3 and GND pins. 

I recycled my sketch from way back, which was used to configure the GPS receiver in run-time (you can, therefore, use the slightly cheaper module without the battery) and then set about working out why I couldn't get the GarminHud library to run. It turns out that SerialBT's write command isn't quite implemented correctly, so I modified the SendHud function to utilise print instead, which worked.

Version 2 of gabinator and Frank Huebenthal library features a "Down" arrow, which would allow me to implement a GPS compass using the direction arrow function. A gps clock is implemented, a speedometer (in mph, but easily changed to Km/h or knots should the need arise)  and a display of the number of satellites in view (and a warning of no GPS lock) 

There's a slight issue when drawing an "up" arrow. Whatever is written next to the direction display is ignored! This slight bug is overcome by simply writing anything other than "up" twice! 

The sketch (and the required GPS library) can be found on my github here.

The unit is mounted in a box, along with a simple 7805 power supply, and trialled. 

Here's a video of the unit in action. 

... another saved from landfill!