The C2N'terface

So, we're here, sorting out our micros, and I've hit a problem... 

I'd love to build a Raspberry Pi based 1541 emulator, but Pi's are currently unavailable due to the dreaded chip shortage, and I won't pay "scalper" prices, so that's out. What's needed is to connect my age-old trusty MP3 player to our VIC-20 (or C-64/128 , PET ... anything that wants a C2N plugged in!)

Now the PET, VIC and C64 don't really have an audio in, like a ZX81 or Spectrum. They expect a processed square wave pulse train. 

A bit of an internet search, followed by a good look at the schematic of a C2N, and a plan is hatched. 

Saving is easy ... what's needed is a simple voltage divider, a shade of filtration, and a capacitor to block any potential DC upsetting the record function of my MP3 player.

Playback not so easy ... we need to peak the signal with an op amp, and square it off with some buffers. 

Here's the original C2N diagram:

The signal comes from the record/play head at a very low level, and amplified by the first 3 op-amps, IC1-2, IC1-1, IC2-1. The signal is centered around 2.5V, as there's a voltage divider formed by R18&19. The last op-amp, IC2-2 starts to clip the waveform, as it's run out of headroom. IC3-1 & IC3-2 are inverters (even if they aren't shown as such, look at the waveforms) and square off our signal to +5V square wave.

Recording is the reverse, except the inverters directly drive the record/play head. 

There's motor drive and "sense" which detects the play key being depressed. 

So here's our MP3 player interface... 

Audio comes in at J2, is DC blocked (just in case), and passes through a level control pot RV1. It's given a bunch of amplification by our op-amp, and the output is already pretty much a square wave at this point, but it's followed by either 2 or 3 inverters. The absolute phase of the interface is defined by the jumper, JP1. There's some talk on the internet that this is important. I'm not convinced, but I'm already into an inverter IC, so it may as well be a hex one! The resultant square waves are sent to the computer. A crude level indicator is provided by U1D driving an LED. This should be flickering a bit during loading. A motor drive indicator LED is also provided, driven by another spare inverter! 

Saving is easy, a voltage divider is formed by R8 and R1, and a bit of filtering by C4, the output should be in the region of 640mV pk to pk. This is fed to the line level input of my mp3 recorder via a DC blocking capacitor, C1.

The sense line is held low, so the computer will always think the play key is down. 

A board is duly designed, and sent off for manufacture. 

... and arrives a few weeks later and is populated. There's a snafu on the original layout, which involved a couple of bodge wires. This has been sorted in the latest revision!

Both saving and loading to both a Tascam wav recorder, and to my aging Acer MP3 player work well... there's a tip to setting the volume level to achieve reliable loading. The LED should be *just* glowing when the carrier is present. Once it's set it can be left alone.

Using the audiotap programme for Windows (here) it's easy to convert downloaded .prg or .tap files to a .wav file for playback. MP3 also worked flawlessly at 256 kbps. I didn't try less. 

A few rounds of Llamasoft's Gridrunner were enjoyed :)

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!

Commodore 1541 Floppy Disc Drive repair.

I bought a Commodore 1541 floppy drive on eBay... not just any 1541 ... oh no... a broken one.

Apparently it was also used as a prop in a film.. http://www.computinghistory.org.uk/pages/50703/Bandersnatch/

Anyway, it doesn't work. No power.

Cursory checks to the input fuse show that's intact, so caution is thrown to the wind and mains applied... the over current trip on the bench pulls straight out (it's rated at 10A)

Checking the input fuse shows it to still be intact ..?

Ah well, in bits with it... 

Removing the main PCB allows access to the transformer etc .. 

... but what's that goop on the bottom of the PCB? 

It's waxy ... 

The mains power input couldn't be simpler. IEC Socket, fuse, switch, transformer... 

... the red seal on top of the socket looks  to have "burst" ... is that the source of our waxy goop, and excessive current draw?

Removal of the lower part of the case, and lifting the chassis out, shows more goop, right by the socket. 

The rivets securing the socket are drilled out, and it's removed.

Looks like the internal filter failed and got excessively hot at some stage, and melted the insulation. It measures a short circuit between live and neutral! A new filtered socket is obtained...

.. and duly fixed into position with some M3 fasteners. Finding a shorter socket is essential, there's just not enough room for one with tags. 

And powering up gives us the familiar sequence of LEDs, and a spinning disc. 😊

Now what's needed is a C64 or VIC20 to test it ... hmmmm ...