A Good Day(ish).

Last weekend I went on road-trip to pick up some stuff from a very nice chap near London. It was a couple of hours drive to get there from the sunlit uplands of the Midlands but before I tell you what I was picking up, let me regale you with my tale of woe from the day. That way, you can decide if it was worth the trip or not.

On the way down the motorway (M5) my clutch pedal started to stick down. Not all the way, but far enough that the normal clutch travel - biting point etc - was within an inch or so of movement just above the floor. Not great but driveable. I soon managed to hook my foot underneath the pedal and pull it back up into the normal position. Sometimes the clutch would be completely normal for a bit, sometimes it would immediately stick down again. Not a major issue on the motorway as I managed a healthy steady speed.

I reached the destination, did the pickup and then set off again. With about 60 miles to go to home, the clutch pedal went flat to the floor. And I mean FLAT. No chance of getting underneath it, no way to change gear. I had to pull over to the hard-shoulder and get my hand under the pedal to pull it back up. I had some minimal clutch control again and continued.

Then it happened again..

And again..

After struggling for an hour I made it to one of the busiest local roundabouts imaginable but only a few miles from home. I needed to keep moving as, by now, the clutch was down on the floor and the only way I could keep moving was to crash the gearstick from one gear to another (not first - no chance of getting it into first). On the approach to said roundabout I was saying the desperate motorists prayer, "Don't stop, don't f***ing stop." to the traffic in front of me. You can probably see where this is going.

I had to stop. 

Car immediately stalled. Reach down and try to pull the clutch pedal up, no luck. Try to re-start the engine but it's in gear so won't start (it's a push button start). I flick the hazard lights on, into neutral, restart the engine and keep trying to get it into second while the engine in running but I couldn't take the handbrake off as I'd roll back into the cars behind me, and as soon as I engaged the gear with the handbrake on, the car stalled. 

Many people stopped to check if I was OK. Several offered to help... No. Wait. Not one single person offered to help or even stopped. Not one. After the initial queue of annoyed motorists tutted and tooted their way past me there was a bit of a gap in the traffic and I managed to get the car started and, most importantly, moving.

via GIPHY

Cue the last few miles with me being in third gear all the way, no gear changes and no stopping. Not a fun few miles. But I made it home in one piece with my pickup.

Was it worth it? Here's the list:

Amiga A2000 with unknown amount of memory and Buddha IDE card, 2 x floppy drives and CD-ROM drive

Amiga A1200 with 68030 25Mhz accelerator and 8 meg

Amiga A1200 with 68040 40Mhz accelerator and 32 meg (accelerator not working)

4 x Amiga mice (condition unknown)

Goliath power supply for the '040 A1200

Video digitiser

Colour splitter for the video digitiser

Cheetah Bug joystick

CD32 controller (original Commodore)

Misc disks and software

Hell, yeah it was worth it. :)

Multiple mice. All four now working.

68040 Card - not working...yet.

A2000 Battery - Removed shortly after this was taken

The 68040 accelerator was something I wanted to look at immediately. I had no idea what the RAM size was at this point (spoiler?). A quick examination of the board revealed some worrying burn marks on one side.

Burn, baby burn.

It's not any prettier close up..

So I removed the capacitor to give me a clear run at cleaning this up. And it cleaned up fine. I was worried there'd be some serious damage to the board but, after a generous dose of IPA and several cotton buds, it looked almost new. Very, very strange. I replaced the capacitor with a new one (47uf at 16v is about the only surface mount cap value I have!) and continued inspecting the board. 

Cleanup complete - cap removed

New cap installed

Battery. Gah. Battery begone.

No battery here (anymore). No battery damage either - phew!

The only other thing I found was that one of the PLCC chips had ridden up slightly out of its socket. A careful push down and it clipped nicely back into its socket.

I decide at this point I should probably renew the thermal gunk holding the heatsinks onto the 68040 processor. These chips run hotter than the '020 and '030 and some cooling is absolutely required although it doesn't normally need to be too extreme.

Cleaning the processor was a bit of a pain but with IPA and a bit of elbow grease I got it looking almost new and ready for some new thermal tape (due to arrive tomorrow).

In need of a clean.

That's better - ready for new thermal tape

Heatsinks will be reused so they get the
same cleaning treatment

But I couldn't just leave it. I had to see if it would now work. After wrestling it into the A1200 with wooden feet (more on that next time) I tentatively switched it on with the heatsinks resting on top of the CPU and the fan resting on top of that. I wouldn't be keeping it on for long or doing anything strenuous, I just needed to see if it worked. A 40Mhz 68040 Amiga is a rare beast these days.

Did it work?

What's that? A 68040 you say?

Oh, yes. :)

More Amiga next time.

Fix it 'til it's broke - The Third

After dealing with a broken Agnus 8375, it was time to turn my attention back to the A500+ board that was still not working.

A500+ Board from HELL

Initially, I had some very odd symptoms. The board would almost appear to boot (with a floppy drive connected). It would run through the sequence of black screen, grey screen, white screen but then no initial Kickstart screen. With a floppy drive connected the drive would show activity as if it was loading data but the screen would stay white. So something weird was going on..

First thing, I tried swapping the main custom chips, just in case one had gone faulty or was starting to fail. This made no difference. In fact, all of the custom chips worked perfectly in the Rev 6 A500 board I have (except Agnus - Rev 6 and Rev 8 Agnii are NOT pin compatible). But then I realised that the A500+ board was no longer getting to the white screen. Now, it would start at black, then dark grey then it would stop. Hmmm.

Given that this is an A500+, the board has had some previous repair, including sockets for U12 and U13. I tried swapping those chips with known working spares. No difference. In fact, things got even worse. Now the board was stuck on a black screen. Doh.

This was beginning to get a bit annoying. I had DiagROM, so hooked up the serial output to see what was happening. The initial test the DiagROM performs is very limited due to only a tiny amount of RAM being available for actual use, but it was showing errors right from the start. 

Well, that doesn't look good.

Then, in a potential case of the Baader-Meinhof phenomenon, Adrian from Adrians's Digital Basement uploaded a video where he had an A500 board (Rev 6) with a potential RAM error and he was using DiagROM to try and solve the issue. As it turned out, his video showed that he did have some dodgy RAM chips but, in my experience, Amiga RAM is pretty hardy and in all the A500+ boards I had previously repaired, I have NEVER had a RAM fault. 

In any case, I went ahead and de-soldered the RAM from my board for two reasons. Firstly, it meant I could put it in a socket, and second, it meant I could test the chips in a handy RAM expansion board that uses four of the same RAM chips with the Rev 6 board along with the excellent Amiga Test Kit from Kier Fraser. Several people on Twitter were convinced that my issues was almost certainly a similar issue to Adrian's i.e. dodgy RAM chips. 

Removing the RAM proved to be a right pain in the behind. Although the battery damage to the RAM was very limited, the solder on many of the legs had reacted with the battery chemicals meaning the solder was dull and would not flow. I managed to damage several traces due to my growing frustration and impatience. Fortunately, the repairs were fairly straightforward and more an annoyance than a major problem.

Spot the damaged traces...doh.

Repairs following my impatience.

Once the sockets were installed and the testing was complete, I was able to see that all of the RAM chips were completely fine. The issues were NOT caused by the RAM. Gah.

Sockets galore

Handy test unit. :)

By this point, several days had gone by and the board was taking up a lot of time. I was convinced that there must be a dodgy trace somewhere so I had generated a multi-tab spreadsheet (everyone loves a spreadsheet) with pin to pin connection details, listing each pin of the major chips and what they were connected to. The 84 pins of Agnus were 'Not Fun'(R). But this also showed no issues with the traces other than previous minor repairs.

One of the comments I had on Twitter came from the most excellent Jan Beta who noted that old and crusty sockets were a major source of problems on previous Amiga boards he had worked on. I took notice of this and decided to solder several chips directly to the board. The chips that received this treatment were:

• U12
• U13
• Gary
• CPU
• Even CIA
• U36 
• U37 
• U15 
• U42

Some of these would normally be soldered to the board anyway but had had sockets fitted as part of previous repairs.

Sadly, this made virtually no difference. What I did notice was that the intermittent RAM fault had disappeared. Interesting... But DiagROM would still get through the memory test and then crash.

Argh! Crashu!

Back to the broken trace theory.

No broken traces.

At some point during all the pulling, pushing, removing, installing two things happened. One, I managed to put it a RAM chip upside down. I have to tell you now that they get bloody hot when that happens. It took me several minutes to realise where the HOT smell was coming from. But the RAM chip in question survived - told you the Amiga RAM was pretty hardy.

RAM the correct way round now..

Two, it broke my 2.04 ROM. By this point I had reached the stage where the 2.04 ROM would show a black screen but the 1.3 ROM would show an immediate green screen. The reason for the black screen on the 2.04 ROM was because it was dead. Completely. Dangnabit.

But the green screen was another clue that this was down to RAM not working properly. Perhaps the Agnus chip wasn't sitting right in the socket. After a careful removal I could see that several of the spring pins in the 'economy' socket I had were bent right into the socket. Perhaps this was the issue. So I fitted another brand new socket.

Damaged socket pins?

Third time's a charm.. no wait..
Third time's a pain in the 

Annnd after all that. No difference. Green screen on the 1.3 ROM and an inevitable crash of DiagROM.

I had had enough at this point. I think I had spent the best part of 20 or 30 hours trying to make the damn thing work. Even DiagROM had stopped working properly and would only display a line of garbage at startup now.

One last ditch effort. I removed the gaggle of chips in the 'data path' i.e. U10, U11, U12 and U13 and fitted brand new sockets. Sadly, I had no 20 pin sockets, but I did have plenty of 24 pin sockets. So, given that this board is staying with me, I decided to just remove the four pins from the end of the socket and solder them on to the board. Providing the chips are inserted fully to the right there is no issue. Of course, if I accidentally put a chip in to the left I will almost certainly kill it but at least they are fairly standard logic chips, if a bit harder to come by these days due to the apocalyptic state of the world...

Shiny sockets

Following this I tried booting it up to see if I could get DiagROM back to where it was with the serial output. 

I nearly fell off my chair. The machine booted flawlessly into DiagROM. 

What. The. Heck.

I was so stunned I forgot to take a picture of DiagROM working. But it worked. I put the ROM back to a normal kickstart, attached a floppy drive with an ATK disk and tried it again.

Standby for action!

Memory! All alone in the moonlight...

So it works. Here's my theory on what was wrong. I think the original problem was that the sockets on the board had corroded/oxidised over the time it's been sat in the box. When I took the sockets off and soldered chips directly to the board (specifically around U10 - U13) I suspect I bridged one or more pins or tracks without realising. Once I took them back off the board and put the sockets on this was cured. And the brand new sockets cured the original issue.

My gut told me it wasn't a RAM fault. I should've listened harder to Jan Beta. :)

Fix it 'til it's broke - Part Deux

I decided that I was going to look at my collection of three floppy drives that have been sat in a box for a long while. They generally work but as no-one uses floppy drives any more I thought I'd explore the art of 'calibrating' a floppy drive, safe in the knowledge that it wouldn't matter too much if I borked one of them doing so. But this is not the subject of this post (next time).

So, break out the spare A500+ motherboard and get that floppy drive plugged in. Annndd... green screen. To be fair, Agnus' socket was busted so that was the first job to sort out. I didn't have any more PLCC sockets so had to order some for a few quid from everyone's favourite, eBay. I won't go into too much detail about the socket replacement other than to say the old one had gone brittle anyway and broke off quite easily.

It's broke.

With a new socket installed I put Agnus back in and tried again. No change so I decided to try and improve the contact of the pins on the chip by gently manipulating the bottom of the legs to push them out slightly. This would, in theory, increase the pressure of the pins into the socket. But, tragedy struck. As I gently pushed pin 81 I noticed it moved far too easily. And then, it fell off.

Oh. 

Arghhhh!!

Pin 81 is HSYNC_ and, as the name suggests, is somewhat important for making sure that Agnus can provide the relevant data at the right time to give a coherent display. 

So, this is it. Agnus is toast. And these particular Agni are the 8375 version, used in the A500+. They are getting more difficult to get at sensible prices (a couple of years ago I bought a complete, non-working A500+ motherboard with chips for a tenner - now just the 8375 Agnus will set you back over £100, if you can find one). 

After posting my woes on twitter, several people suggested using a Dremel (other rotary tools are available) to remove the outer casing above the broken pin and see if a replacement leg could be soldered to whatever was left of the original pin. Given that the chip was broken, I had nothing to lose. A helpful YouTube video from _C64 Customs_ also gave some useful info on what to do - although it isn't specifically about this type of chip. So, I threw caution to the wind. If it didn't work I'd still just have a broken Agnus.

Break out the generic rotary tool from the defunct UK high street electronics supplier. I used the narrowest, pointy milling tool in the box and carefully pinned down Agnus with some insulating tape. 

Grinding away the casing took only a few minutes but I really took my time, allowing the tool to touch the chip very gently and then checking how much material had been removed. Eventually I had managed to expose the part of the original leg in the casing. I carefully cleaned it with IPA and a cotton bud. It was the most terrifying thing I've ever done to a vintage computer chip.

Prior to attempting to solder anything to the exposed leg, I tinned it with a little solder. I still had the original part of the leg that had fallen off so I decided to try and re-use it. It was a bit tricky to get it to stay in place so I used a piece of insulating tape to hold it. This worked pretty well and allowed a good solid blob of solder to flow between the leg and the chip resulting in what looked like to be a good solid repair.

Hole drilled, leg held in place...

Close up of the horror.

Repair complete. Phew!

Close up - a clean is required

Will it work?

There was a big hole in the chip now, even though the leg was repaired. I did not want to leave it like this so I took some epoxy and filled in the hole. It ended up a slightly bigger 'blob' than I had hoped but I was careful to make sure that the epoxy did not interfere with the socket. These sockets are tight.

Agnus pimple

Don't squeeze it! It'll spread!

Epoxy cured - ready for testing

Incidentally, it's worth noting that Fat Agnus (the original version was just 'Agnus') was the absolute largest chip that CBM/MOS could manufacture in the late 1980s. It took the original DIP Agnus and combined various additional bits and pieces - it's all about that cost reduction - including, in further updates, the ability to address chip memory up to 1Mb i.e. memory that can be directly accessed by the custom chips. Hence, Fat Agnus. The 8375 model here is the last ECS version and it can address 2Mb of memory and so is unofficially known as 'Fatter Agnus' or 'Obese Agnus'. 

Now I have a slightly lumpy looking Agnus but I'm actually quite pleased with it. The repair seems pretty sturdy and, other than the pimple, looks almost new. So, to test. Well, first, I put it into the faulty motherboard and the behaviour of that board didn't change. This was a good sign as I would have expected either an unstable image or a green screen if I'd damaged other parts of Agnus. But I have been having trouble fixing that board - another future post - so I threw caution to the wind (again) and carefully removed it from the faulty board and put it into my 'daily driver' A500+ which has the most excellent A500++ re-made board, in purple. 

Agnus' final resting place.

And...

The most excellent FrogFind by Action Retro

AGNUS IS ALIVE! Yes! And it will stay in there as I really don't want to tempt fate by trying to remove it again from a really, really tight socket.

Phew!

Pin. Pin. Pin. Pin.

Pinouts. Lots of pinouts. Or at least I thought I should properly document the pinouts of the UD-80. This will be the last post on this for a little while as I still have lots of other stuff to look at, including a TV with a faulty SCART input...

First up, SCART.

RGB Cable - 6-pin DIN to SCART

The socket is a 6 pin DIN (240 degrees) socket arranged in the following order:

UD80   Pin            Pin  SCART

GND    1: ---------- : 18  GND

CSYNC  2: ---------- : 20  SYNC (via 470R resistor & 10uf cap)

RED    3: ---------- : 15  RED

GREEN  4: ---------- : 11  GREEN

BLUE   5: ---------- : 7   BLUE

+5V    6: ---------- : 16  RGB BLANKING

Diagram below:

What a lovely diagram.

One key thing here is that I'm not convinced I've got the RGB in the right order. But I would point out that the PX-8 and UD-80 are monochrome, so what difference does it make? :) At least I'm fairly sure that GREEN is in the right place at least...

The CSYNC signal was measuring 5v which is TTL level and a bit over the top for the SCART standard. Sticking the resistor in there, when it's connected to the 75 ohm impedance TV connector, means the output is a much more standard 520mV (thanks to the video by Voultar where he describes the issues with old equipment - see here for that video). The capacitor de-couples any DC bias in the signal.

Here's one I made earlier:

GAAAH!!

And here's one where I put the SCART plug screw on before I re-soldered the plug back on:

Remembered this time...

And, of course, I must not forget the patented DIN plug 'Maximum Assistance Super Hold' (MASH) device i.e. a potatoe:

Hmmmm. Potatoes....

One of the best things to hold the DIN plug so the pins stay in place and don't fall out while you're trying to solder the plug. An excellent tip there. As you can see I did the 8 pin and the 6 pin DIN plugs for the UD-80 with this particular MASH.

Does it work? Of course.

WordStar. You youngsters don't know you're
born. 

A whole 2k free on the A: drive!

Rather interestingly, there is some slight distortion towards the bottom of the screen that looked similar to the composite interference. I suspect this may be related to the UD-80 rather than any issue with my cable but I might investigate at some point.

Next up, the UD-80 connection itself.

UD-80 Serial Cable - 8-pin DIN to 8-pin Mini-DIN

The socket on the front of the UD-80 is an 8-pin 270 degree DIN socket. It can accommodate a 5-pin 180 degree plug since only pins 1 to 5 are actually used. The pins are arranged as follows:

    UD80  Pin            Pin  PX-8 RS232

  GROUND  2: ---------- : 1   GROUND

 DATA IN  1: ---------- : 2   DATA OUT

DATA OUT  3: ---------- : 3   DATA IN

     CTS  5: ---------- : 4   DTR

     DTR  4: ---------- : 5   CTS

     N/C  6:            : 6   N/C

     N/C  7:            : 7   N/C

     N/C  8:            : 8   N/C

The PX-8 can, apparently, use either the RS232 or Serial ports with the UD-80. Everything I have done so far has been with the RS232 port.

UD-80 Operation

The UD-80 replicates and extends the display of the PX-8 from an 8 line LCD display to an 80 or 40 column display with 24 lines via a composite or RGB output (see above for info on RGB). The UD-80 comes with a built-in extension for WordStar to allow the use of the additional screen real-estate. Other applications need to be specifically modified to make use of the additional screen space so they are likely to be few and far between.

This brief 'start-up' guide is based on an PX-8 with no batteries installed and, as such, a lot of the steps taken here would, in the day, only have been required once, particularly if the RAMDisk was fitted (I have one but it's broken. :( ).

Step 1 - Plug in the UD-80 to PX-8 interface cable.

Step 2 - Plug in either composite or RGB monitor according to taste.

Step 3 - Switch on the PX-8 which should default to the start menu.

Step 4 - Switch on the UD-80 which should display a UD-80 banner at the top of the monitor screen.

Step 5 - Run CONFIG.COM and configure 3 blocks of User BIOS space (run the program, select 'B' then press '3' and enter, then ESC twice to get back to the menu).

Step 6 - From the menu or from the CP/M prompt run FILINK.COM

Step 7 - Press 'R' to receive files and then 'Enter' when prompted for a filename.

Step 8 - Press the button on the front of the UD-80. A 'Transmitting...' message should appear and FILINK should indicate it is receiving UD80-DRV.COM and the WSX.COM.

Step 9 - When the downloads in FILINK have completed quit back to the menu and run the UD80-DRV.COM file that will be shown in the A: drive.

Step 10 - Switch the UD-80 off then on again to reset to 'normal' mode. A message should appear indicating that the driver is resident and can be cleared by a 'Reset'.

At this point anything that is typed on the PX-8 will appear on the monitor connected to the UD-80. In the event that the PX-8 manages to get back to it's default menu just press 'Esc' to return to the CP/M prompt and the UD-80 will spring back into life. Note that some 'garbage' appears at the top of the screen when the PX-8 returns to the menu with the UD-80 driver active.

Note garbage at the top from the PX-8 menu

During the use of this device I did have some situations where the UD-80 and PX-8 got out of step. A quick switch off and back on of the UD-80 normally resolved things (the more things change, the more they stay the same...).

So, there you go. A slightly dull but informative post for anyone with an Oval Automation UD-80 serial display adaptor for the Epson PX-8. I promise I'll stop going on about it now.