Jun 162021

Whilst installing and carelessly adjusting my CF card in my A1200 with it switched on, I managed to short out some component on the motherboard via the shield which caused the machine to reboot and then come up with the following screen.


You can clearly see that blue is completely missing.


A healthy kickstart screen should look like this

I wasted no time getting to work after cursing myself for 30 minutes or so and feeling bad all night.

1st step was to figure out where the fault actually was, so I consulted the schematics to understand the design and get an idea of where to start.

I have clearly marked the important parts of the drawing by marking each of the 3 RGB colours over the signals. First of all, we have an AGA ( Advanced Graphics Architecture ) custom chip called LISA which generates the colour information internally amongst other things, this must be converted to analog via the video DAC which accepts 24 bits of colour information from LISA and then passes those analog signals directly to the 23pin D-SUB connector on the back of the A1200.


The same 3 RGB signals generated by the video DAC are passed to the Sony Encoder chip for composite signal and also RF out to a TV.

The issue was also reproduced on the composite out, this would confirm the encoder just gets its RGB signals from the DAC and to look elsewhere. Unlike the Amiga 600 design which uses no DAC but uses the same encoder to pass RGB to the 23pin D-SUB, the A600 video output design is similar to the video hybrid method used in the A500 for generating RGB.


Thankfully we have a similar problem here from RetroGameModz that I used as a reference which describes the troubleshooting process. I really liked his use of Protracker to trouble shoot the colour, this proved very useful.



In Protracker, I turned Red and Green signals to the absolute minimum and adjusted the slider for Blue and see no change at all.  So with my scope I verify the signals coming out of pins 25,26 and 26 of the video DAC.  These are labelled IOR,IOG and IOB respectively. I could see valid waveforms on both on IOG and IOR but a flat line ( low ) on IOB no matter where I positioned the blue slider in Protracker via setup from the main menu. This explains the lack of blue.

So either, the 8 bits for blue were stuck on the output of LISA or I had a bad video DAC.

I then attached my logic probe to 5v somewhere inside the machine and adjusted the slider in Protracker whilst probing R,G and B signals. To my relief my logic probe responded to each and every single one of the 24 bits coming out of LISA. So LISA was spitting out colour information but the DAC was obviously not going to deal with blue. I repeated the same measurement on IOB output of the video DAC this time with the logic probe which shows its held low regardless of the position of the slider, further confirming the lack of waveform there with the scope.


I wasted no time ordering some replacements.  3 x VP101-3BA manufactured by GPS/MITEL and some 44pin PLCC sockets.

So currently waiting for these to arrive from China, delivery time is 2 months.



And in preparation I couldn’t wait to remove the faulty component from the A1200.  First step was using a liberal amount of polyimide tape ( this stuff is expensive but will save you from grief ) to protect surrounding components from heat exposure, I applied some flux and then heat the chip to around 200 for 1 or 2 minutes, then raised it temp to 350 to finish off.






I had this cleaned up nicely. Now just waiting for the spare parts to arrive for a part 2.


References: Amiga 1200 Schematics.


Click to access A1200_R1.pdf

Mar 132021

Lately I’ve gone through all the faulty/untested PCBs I never looked at (tons of them…) to check if there was something that was worth a repair.I found this Sega System 16B motherboard :

I plugged in a Golden Axe (conversion) ROM board and powered up the set.Board booted up, game was playable with good graphics but sound was missing :

The audio hardware is made of Z80 CPU plus a Yamaha YM2151 for music (and a NEC uPD7759 for speeches) :

Looking at schematics the serial data from the YM2151 (pin 21) is sent to the YM3102 DAC (pin 4) which then routes the analog signal to the TL084 OP-AMP :

Probing with the oscilloscope revealed the YM2151 serial data were present on the input of the YM3012 (pin 4) but  the output (pin 11) tied to the OP-AMP was silent :

The DAC was likely fault so I replaced it :

This brought the sound back but it was faint and corrupted (except the speeches that was fine) :

The TL084 OP-AMP is the only part between the DAC and the final sound output :

It’s a well known prone to failure part so I went straight to replace it :

The sound was completely restored and board 100% working.End of job.



 Posted by at 4:10 pm

Passing Shot (Sega System 16B) repair log

 PCB Repair Logs  Comments Off on Passing Shot (Sega System 16B) repair log
Oct 122020

Got an original Passing Shot PCB for repair, as you may know it’s a tennis game released for System 16B hardware by Sega in 1988.

Board had its ‘FD1094’ battery-backed custom CPU module which was still alive since the board booted but sound was missing at all:

These are the times when an audio probe really comes in handy in diagnosing the fault helping you to figure out the nature of the lack of sound (if digital or analog).So I fired up this tool and started to listem to various points of the audio circuit :

For first I probed the outputs of the YM3812 DAC and I got sound from them, this meant the fault was in the analog circuit.Looking at schematics I followed the path, the sound was still present on the input of the volume potentiometer :

But then it was silent on the output which gives the signal to the Fujitsu MB3733 amplifier :

Schematics shows there is nothing between the output of the potentiometer and the input of the amplifier (apart from a 10uF electrolytic capacitor that was tested as good)

Metering the amplifier I found that pin 1 ( the input which takes the signal from the potentiometer) was almost shorted to pin 11 (+12V supply), there was only 12.4 Ohm of resistance :

The amplifier was likely bad so I removed it :

And replaced it putting also some thermal silicon grease for a better heat dissipation :

I powered the board up again and the sound was back.No other issue found hence I could declare this board 100% fixed and working.


 Posted by at 3:51 pm
Apr 132020

Yet another Operation Wolf repair and this one gave me trouble.
First test we had watchdogging. All ROM’s checked out fine in the programmer and seeing nothing else obvious I removed the work RAM both of which failed.

Now on boot up I got a screen seemingly running game but all the screen was garbage.

Probing the data lines of the screen RAM show pretty much all of them across two RAM chips were dead. I desoldered and replaced them both.

Now I got a running game but the colours were messed up

There are two 74LS245’s attached to the data lines of the colour RAM at location IC78 & IC90. Probing these revealed stuck bits on IC78. Replacing this gave me perfect results on the colour test screen in test mode but dull colours in game. Other issues in-game showed me all the sprites were missing and the screen doesn’t scroll when entering a game.

Stupidly I chose to ignore the colour issue and concentrate on the other two (I will get back to this later).
The sprite and scrolling issue worried me because these areas are related to the PC080SN and PC0900J custom chips.

Paulcan69 sent me a scrapper PCB so I could rob the customs off it if needed so I started out by replacing the PC0900J.

Replacing this brought my sprites back but the scrolling issue was still present.
I didn’t enjoy replacing that IC so I started checking around to see if the scrolling issue could lie somewhere else.
I found nothing wrong so removed the PC080SN custom and replaced it with the spare but it made absolutely no difference. A lot of work time and effort for nothing.
I spent time over the course of the next few days looking into this but found nothing.
Eventually I got sick of looking at the washed out colours on screen and replaced IC90 to fix the last of the colour issues.
I couldn’t really believe it when this fixed my scrolling issue as well.
I still don’t understand why this chip caused the scrolling issue but I’m really glad it did.
All issue are now fixed on this board.

Onto the sound PCB.
The original sound PCB that came with this board was a complete write off. Every chip I pulled from this board was broken and both amps were also burning hot.
Among all the other boards that Paulcan69 had sent me he also kindly sent me a spare sound PCB for Muddymusic to have.
There was a sticker on this board saying “No Sound”.
On first test I found that the music played but the volume was really low. Turning the volume up to the maximum made the sound audible but not nearly enough.
I checked the resistance of the volume pot and found that if you move the pot off maximum setting then it read megaohms. I tried cleaning it but it didn’t work so I replaced it.
This made the sounds much better but like with most of the others I’ve repaired some of the samples were scrambled and didn’t stop playing when they should.

I quickly found another 74LS688 that was dead. Replacing this made the sounds stop when they should but the samples on channel A were scrambled.
Looking at the schematics shows where the sample data goes.

Using an audio probe I checked the output at pin 10 of the 5205. The sound was the same. This ruled out issues caused by bad caps and things like that.
Next I checked the 574 at IC33. Both the input and output looked good so moved onto the 74LS157 at IC 44.
Probing all the outputs with a logic probe showed pin 9 was stuck HIGH

Replacing this fixed all the samples.
That’s the last one fixed
Big thanks to Paulcan69 for the spares board. Without it this board would be scrap too.

 Posted by at 9:54 am

Operation Wolf repair log #4

 PCB Repair Logs, Repair Logs  Comments Off on Operation Wolf repair log #4
Apr 112020

Another Operation Wolf repair!
This one belongs to Frothmeister on UKVAC.

Again, we have a nice little fault label

So to start with there was no sound. I did a couple of signal checks to see if commands were being written to various IC’s but saw none of them so I just removed the RAM which of course failed.

Fitting a new RAM brought the sounds back but the samples were garbage

Samples are all stored in the 40 pin MASKROM.

I attempted to read the MASKROM as a 27C400 EPROM in my programmer but it gave me errors

As I had a scrap sound board here I swapped this ROM out and retested.
Samples were now restored but I had the same issue as in a previous repair where the sounds started playing and never stopped.

Time to check out the comparators.
I quickly found the comparator with a stuck output at location IC18

Replacing this fixed my faulty sample playback for this one but I found another by playing sample 2E.
Using the same technique I found another dead 688 at IC39.

To determine which channel the game uses for various samples I use the wonderful MAME debugger.
If you look at the memory map for the sound CPU in the MAME source you can see the addresses that get written to to set the START and STOP values.

Address ranges $B000 – $B006, $C000 – $C006, $D000 – $D006 & $E000 – $E006 are what we are concerned with so set some breakpoints in the debugger and fire up the Operation Wolf test menu (dont forget to set the debugger focus onto the sound CPU).
Play the sounds that cause issues and see which address gets written to.

Now look at the schematics

From here we need to work out with signal is address $C000.
A15 & A14 give us an address of $C000. the 74LS138 at location IC14 gives us the enable line for the channel. A15 enables the 138 itself and A14 selects the relevant output, in this case its input C which enables (active LOW) pin 11. This in turn enables IC54 which as you can see from the signal names is channel B.
Following the schematics further we find the 74LS688 comparators responsible for this

Probing the only output on those comparators (pin 19) and playing the sample shows me which one isn’t toggling. In this case it was IC39.

All fixed

 Posted by at 3:47 pm