Building the XUM1541 USB to IEEE Serial interface

A while ago I repaired a 1541 Disc drive (here), and despite fixing the VIC-20 (here) I hadn't tested the drive. 

I had, however, seen a project called XUM1541 (details are here) which gives us a USB to IEEE serial.... 

So simple! 

An Arduino Pro Micro is pressed into service, but V8 of the firmware resisted many attempts to flash onto my Pro Micro... the webpage described hitting the Reset button just before running the avrdude command line.... but the Pro Micro doesn't have a reset button. I used a pair of tweezers to short out the RST line to GND on the Pro Micro, but still couldn't get it to work ...

After a lot of messing about, what you need to do is plug in your Pro Micro (into a windows machine), and open device manager. Expand on "Ports and LPT" , and you should see your board appear as "Arduino leonardo" .... this is where it goes wrong...  Now short out RST to GND Twice in quick succession. Your board should now appear as "Arduino Leonardo Bootloader" ... note THAT com port number and insert it into the command line. 

Now, short out RST and GND twice again and hit return on the command line within 8 seconds..... bingo! 

All the software and drivers can be found in this handy download https://github.com/r1me/TapeXUM/releases/download/1.0/xum-installer-x64.zip

Once everything is installed, it all works superbly... 

A simple box is printed out.. 

Software works great!

Now , I really need a real C64 to try it all out!

Lamp Limiter / Dim Bulb Tester

One piece of test gear I've never had is a lamp limiter or dim bulb tester. 

They're ideal for s-l-o-w-l-y awakening our vintage electronics up from years of slumber, without too much drama. 

I've been helping my neighbour, Steve, build a pub in his back garden, and while we were testing out some of the electrics, he donated a box of three incandescent 60w lamps to the cause. Ideal. You can't use LED lamps, and halogen lamps are far from ideal.

Here's the schematic.

It's a simple enough circuit. The live side of the mains is supplied via two 60w lamps (in series), each lamp can be switched out as required. This will limit the current and give us a (very) visible sign if there's any issue! 

I purchased a cheap energy monitor from eBay. With both lamps switched out it'll give similar functionality to the Hopi or Killawatt testers. 

I got it from eBay from eBay seller topwoodfly, and it arrived promptly. It has it's own current transformer, as you can see in the picture. 

https://www.ebay.co.uk/itm/394197388411

It's mounted in a box, along with the lamp holders and switches. 

I've put a change over switch on the input to the energy monitor, so we can measure the output voltage. I expect if the output voltage falls too low the energy monitor will stop functioning. I'm not expecting any miracles of accuracy here!

All wired up in a jolly shade of yellow, just to make fault finding on the unit as difficult as possible.

The neutral wire from the mains is passed straight from the input to the output, via the centre of the
current transformer. 

Here's the finished box, running off the bench variac at about 138V

There's a short circuit across the output, just for demonstration purposes!

I must say I'm actually quite impressed by the accuracy of the energy monitor!

Quite a useful addition to the workshop :)

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!