Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Womble

Pages: [1] 2 3 ... 12
1
ARCADE / Latest addition - Star Wars!!!
« on: February 29, 2020, 09:26:58 AM »
It's been ages since I added anything new, but couldn't resist this project. Picked up 9 months ago as a bit of a beater, the only thing in good condition was the side art.

Was faulty, had monitor collapse,  no sound, a broken controller and an unpleasant smell. The discovery of a mouse nest in the coinbox was a nice touch, thankfully no corpses included, just a whole lot of damage from the resistdents.

Some before shots....

















All metal work sandblasted, replated, or sanded back to bare metal and re-painted







All the PCBs were refurbished, the amplifone monitor scrubbed and rebuilt. The old dag coating was trashed, so I scraped off the 10% that was left and painted on a new coat.





The yoke controller was a total strip down to bare metal too, new springs, switches fitted and some new artwork.



All PCBs were cleaned, repaired and tested. The harness went through the dishwasher a few times and had all the chewed sections chopped out and repaired.



The cabinet itself was cleaned and the insides sanded until the cat lost interest in it. Then lots of filler, repaired edges, re-routed slots, a new panel in the roof to replace a piece of floor board, and  a new perspex canopy.



Finally rebuilt, looks and plays like new!!















The force is strong with this one.


2
ARCADE / Another Namco Pacland Repair Log
« on: January 05, 2016, 09:56:53 AM »
On the bench recently was another Namco Pacland PCB, am not a fan of the game personally but anyway. This one looked in good nick and had the usual mod to the power and video sockets.





There was the usual corrosion on the customs and some TTL chips, but the only real sign of abuse was this 74LS138 at 9D that had taken a hit hard enough to sheer the corner off the package.



On power up I got this, a video signal which was missing the sync component...



... as confirmed by poking the scope into the mod connection socket.



The sync signal traces through R23, and off to pin 13 (an output) on the 74LS386 at A5...



... a Fujitsu which hadn't been fitted properly...



... the input signal on pin 14 was busy and the output enable on pin 15 was low, so the output should not be floating. The IC was actually stone dead, with all buffer outputs floating. With floating outputs you can safely piggy back a working chip on top as the original chip is no longer connected internally to the legs, or the board. This lit up the sync pin and got me a stable image.



Stable but no signs of life...



... beyond some flickering of a few pixels, no sign of any watchdog activity. It's worth noting that the board did exactly the same with the CPU removed entirely.



The first stop was the custom #34  chip at A7, unusually for these all the pins on this were intact. It's still fragile so it was dropped into a machined pin socket to act as a chip carrier and reinstalled.



Next step was to see what the ROMs were doing, and their data lines looked nasty on the scope, so I moved on to the ROM control lines /CE (chip enable) and /OE (output enable). The /OE line for the first two ROMs (8B and 8D) came from pin 6 on an LS139 at 7D. Pin 6 and 7 are output pins, relying on the state of a couple of select line input pins called A1 and A2, and the state of the enable signal pin 1. This pin was held high, so the chips outputs were not driving the lines, and as it never changed state something was obviously wrong. If that pin is always high then the ROMs will never be selected and the CPU will never see a byte of data that they contain. As those two ROMs are the first ones in the address space, and the only ROMs that are hard wired into their address locations they have to be usable at boot.

The 74LS139 enable pin tracked back to pin 9 on the 74LS368 at 5A that I piggybacked earlier to get the sync working. This is an output pin that should reflect the state of the input at pin 10 (which was silent) and the another enable pin at pin 15 which was low (enabled). The input pin 10 tracked back to pin 32 on the 6809e CPU, which is the R/W pin, an control line pin used by the CPU to signal to the RAMs ICs whether to switch to read or write mode. As that line was stuck low the CPU was a write off as it could never control the RAM and ROM on this board. With a working 6809E installed the ROMs /CE lines were now busy, but not much else changed.

The ROM /OE pins at pin 22 were also wrong, tied low and ragged...





... tracked to pin 6 on the 74LS08 (not an LS32 as the schematic shows) at 10C...



...this is a quad AND gate, with each gate taking two inputs and if they are both the same then the output will match their state. On this IC input pins 1 and 2 were shorted together as a pair, and inputs 4 and 5 also, so they would always be the same. This is weird, with the inputs tied the AND gate is working as a buffer IC only, which seems pointless. Despite this I check the other PCB and it was the same, and of the other two AND gates on this chip the 3rd is tied in the same manner, and the 4th is unused. It seems an odd thing to do and all things being equal it would have made sense to use a non-inverting buffer IC at this location instead.

In reality this probably came down to cost, they didn't need a tri-state buffer (i.e. one that could be enabled, or disabled with another signal) so something like a 74LS07 would have fit the requirement exactly, except for one issue - cost. The cost of ICs varied day by day, which is why you rarely find a PCB with all the 74 series logic from a single manufacturer. They companies just bought them in huge batches from whoever had the best price on the day. The board designers wouldn't be able to predict future IC price fluctuations at the design stage so that can't be it, but it is still cost related. Even though the individual prices of parts wouldn't be know, it was known that it was cheaper to make a board with as small a number of different parts as possible. So by using a part used elsewhere on board, so in the bill of parts already, in a non-standard way, to save using another different part would have made sense.

As the tied inputs to the IC were transitioning healthily between logic levels, the fact the output was held low meant the chip was either faulty and was not driving the line, or the line shorted to ground upstream. Being a Fujitsu the first option was more likely, and with it replaced the /OE lines lit up again. At this point the board started to look like it was trying to boot, and it also started to reset regularly which was the watchdog doing its thing, giving a range of screen effects.







With ROMs now looking like they were at least being driven correctly I moved onto RAMs, a number of data lines were messy, low and spiky, so with all RAMs socketed it was simplest to take them all off the board and run them all through my EPROM burner. Of the 7 only 6 passed, the one at A10 was faulty. Swapping in one from my stock didn't change anything so I moved on to look at their control lines, /CE (chip enable), /OE (output enable) and /WR (write enable)

Write enable (/WE) was held high, while /CS and /OE looked busy and healthy.

The /WE signal tracked back to pin 11 on a 74LS32 at 5B, another Fujitsu with all its outputs dead.

Also pm three of the RAM ICs at 9M, 9N and 9P the address lines A7, A8, A9 and A10 were low weak and flickering. These traced to the outputs on a 74LS32 at 10J, yet another Fujitsu IC with all outputs dead

With working ICs piggy backed at 5B and 10J all the control and address lines were now functioning and at least looked pretty normal but there was no change to the fault on screen.

So I moved back to look at the data pins on the RAM as these are in and out signal pins, and a few looked pretty messed. These get their input from, and give their outputs to the banks of 74LS245s to the left of them. These have an output enable pin and a direction pin to determine which way they are passing data.



Of the bank of 74LS245s 8L, 8M, 8N and 8P all had floating direction signals on pin 1. The /DIR signals on all chips were common and tracked back to the Fujitsu LS08 at 9F which had dead floating outputs.


     
Of the remaining 74LS245 ICs, 8R and 8S had issues on their /OE pin (19), 8Rs was tied high (outputs disabled), and 8S had a tied-high twitching sawtooth input, which was logic high (i.e. chip output disabled) all the time despite the noise. Both these were fed from the 74LS08 at 10N which was dead.



The 245 at 8S had pin 19 connected to pin 11, and the inputs to that gate, pins 12 and 13 were normal logic levels and bore no sign of the twitching, but the twitchy signal was present on pin 1, an input to another gate, so it looked like the 74LS08 chip was shorted internally.

Piggy backing a working 08 did cause a change in the screen and got it looking much closer to what a working borad does during boot up self test, but as the output on the Ti 74LS08 chip was still driving the line, the piggy backer could not take full control, so the combined signal was not correct. That chip had to come off before I could make any progress.



It failed tests off board.



With that replaced things started to look a lot better, closer to what a successfully booting board does during the self tests.



At this point I finally got round to dumping ROMs, I should have done this much earlier but it is tedious and uninteresting work when there are more obvious problems to work on. All dumped and were read OK but from the IC labels they looked like mixed set. You can mix sets to an extent on this game, so get different game speed and graphics elements, but to save time working out what combinations were valid I just moved the lot to the working PCB and the board ran fine. In this set Pacman doesn't have the creepy long nose or the feather in his hat as on PCB1.

As the fluke was still on the bench I hooked it up.



The bus test completed ok meaning the CPU was free to drive all the lines connected directly to it, but the Short RAM test gave a RAM DCD error at 0x00000.



This means that it wrote a value to the the first location tested 0h0000 and got a different number back. It assumes that the RAM decoding is wrong and that it isn't reading and writing to the same place all the time. I gradually pulled all the socketed SRAMs until writes to 00000 failed to read back entirely...



... then swapped another RAM chip in to rule out any oddity of the RAM IC itself, the fault remained.

I went over the address bus lines again with the scope, while I had the Fluke set to continuously loop reads, and three lines stuck out as unhealthy looking, these buzzed back to the LS366 at 10F, a fairly uncommon chip, based on the enable inputs (both high) the chip should not be doing anything at all as it should have been in high impedance mode.



Couldn't find anywhere else the 3 lines went so I tracked back the /OE from pin 1 to a gate on the already piggy-backed 74LS368 at 5A. It was correctly inverting the input on that gate and I couldn't find where on the board that input was taken from so I dug out the schematics.

It turns out the 74LS366 outputs are also connected to the outputs of a 74LS365 at 10D, the pins were so oxidised my meter didn't register.



It's /OEs pin should have put the chip in output mode but some of the outputs looked tied high and twitchy. So either the 74LS365 was bad, or the 74LS366 was interfering, I desoldered the 74LS365 from 10D and it failed off board tests.



With a working 74LS365 on board it then booted through a pretty normal looking self test, but gave the error number 0 0 6 and reset.





(Camera wasnt fast enough to catch the two trailing zeros before it reset)

Pacland PCBs have inverted video while running their self test so and the results should be a ghost icon, followed by 3 numbers so the error is actually 9 0 0, so some sentience was back.

I put the Fluke RAM test on again and it got a lot further, giving a pattern error which would occur at random places throughout the address space so wasn't really tied to a single RAM chip, or a single 74ls245.



Decide to ignore RAM for the time being and see what the ROM tests show, even though I had confirmed the ROMs were OK off board I still didnt know if they were readable by a CPU on this board as there is a lot of control and bus logic involved. If I could rule out a lot of that it would prove a lot of the shared bus circuitry was also fine.

Using the Calcsig program on the PC I knew what the signature (a checksum) should be for the ROMs so it was a case of defining the ROM range and getting the fluke to compare my expected sig. Which it did for the first two ROMs in the stack.

RANGE      ROM      Sig
8000-BFFF    PL1_1.bin   48E7   ok
C000-FFFF    PL1_2.bin    E250   ok

The third one failed, which reading the MAME driver file more closely isn't surprising.

10000-13FFF    PL1_3.bin    A40A   FAIL - SIG was 43F4

The 6809E has a 16 bit address bus, which means it can only address 64KB of anything, RAM, ROM or IO. On systems with more RAM or ROM than the 64KB limit there has to be a paging system where a lump of this address space is considered shared, and blocks of RAM or ROM get swapped in and out by the main program as required.

Brace yourselves, we are going deep....

The MAME driver section defined this as the following..

3c00-3c00 Bank and ROM Selector      - i.e. when the correct 8 bit number is written to address 0x3c00 the paging is triggered.
   
Banked ROMs at 4000-5FFF      - the paged ROMs are readable in this address space.

Triggering the paging is easy enough with the fluke, you just write the magic number to address 3c00 and the new slice of ROM should appear magically between 4000 and 5FFF, but what are the magic numbers? Thankfully you can work that out from the schematic with a bit of effort.



The /CE (chip enable) pins of the 4 upper ROMs 8E, 8F, 8H and 8J all go back to a 74LS139 at 7D, one of the standard chips used for address decoding and from the truth table you can see what inputs it would need to give the output you want.



To enable ROM 8E only its /CE line should be low, all the others must be high. The other combination of possible outputs provide for each of the 4 ROMs to be chip selected in turn. There is a slight complication here in that the ROMs are 74LS128s with 16KB capacity or 128Kbits. The space defined for the paged ROMs is only 8KB or 1FFF (4000-5FFF=1FFF).

The board is actually treating each ROM as two banks, an upper and a lower bank, and it uses the upper address line (A13) to determine which half is selected with A13 being common across all ROMs.

So taking one step back from the 74LS139 we get to the 74LS174 at 6K and A13 connects to pin2 (output 6, called Q6 on the diagram above). To add to the confusion slightly the address bus inbound to the 74LS174 is the reverse of the input/output gate numbers on the the 74LS174.

So....   

D5 on bus = D1 / Q1 on the 74LS174
D4 on bus = D2 / Q2
D3 on bus = D3 / Q3
D2 on bus = D4 / Q4
D1 on bus = D5 / Q5
D0 on bus = D6 / Q6

To select the first bank in the first ROM the inputs A&B on the 74LS139 would have to be low, so Q4 and Q5 would need to be low outbound from the 74LS174, the inputs to Q4 and Q5 map back to bits D1 and D2 on the data bus inbound. A13 maps back to bit D0 on the address bus, which in binary counting would be on for every odd number and off for every even number.

So to select the first lump of the first ROM both Q4, Q5 and Q6 outputs from the 74LS174 need to be low, this would mean inputs A and B on the 74LS139 would be low meaning the output pins 9, 10 and 11 would be high and pin 12 would be low. The result being only ROM 8E would be selected while the others were disabled. The line A13 would independently define whether the upper 8KB or the lower 8KB would be read internal to the ROM and output on its data pins.

These three signals are D0, D1 and D2 on the data bus, so we just need the right binary number that flips those bits and the simplest numbers to do this are 0 through to 7 poked into address 3c000, and it worked perfectly. By splitting the ROMs I dumped earlier and running calcsig on the halves I got the sigs I was looking for, and one by one they checked out OK.

Banked ROMs at 4000-5FFF
Poke x at 3c00
00000000 0      Pages in ROM PL1-3 Lower   1785 Checks OK
00000001 1      Pages in ROM PL1-3 Upper   660  Checks OK
00000010 2      Pages in ROM PL1-4 Lower   42A8 Checks OK
00000011 3      Pages in ROM PL1-4 Upper   734B Checks OK   
00000100 4      Pages in ROM PL1-5 Lower   F5A6 Checks OK
00000101 5      Pages in ROM PL1-5 Upper   19FC Checks OK
00000110 6      Pages in ROM PL1-6 Lower   32FA Checks OK
00000111 7      Pages in ROM PL1-6 Upper   74   Checks OK
     ^^^=D2/D1/D0 relevant here.

The bits D3-D5 are used for other things according to the schematic, with interesting names such as SEASON1 and SEASON2, will have to try poking those once I have a working system to see what effect they have.

The fact I can read/write and successfully page in all the ROMs means a heck of a lot of the circuitry was working fine, so the issue must be more related to the RAM or the boot up process. I was still getting the 9 0 0 error code and according to a range of online repair sources boot codes 1-7 refer to the main RAM stack, and 9 relates to the "shared RAM", presumably between the main and audio CPU.

I started poking around closer to the audio system, and although the 74LS257s at 4J and 5J are busy any loss of connection internally would cause the actual output to be wrong.



Decided to piggy back, in theory a working chip would have no effect on another working chip (not always true), but as soon as I piggy backed onto 5J the board would report the error code 5 0 0 and freeze, something was going on with 5J. To confirm I tested the piggy backer chip again, it was fine and on re-piggy backing it did this...



... then fell down the rabbit hole again...



... and finally ended here.


3
ARCADE / Sega Shinobi Repair Log
« on: January 01, 2016, 05:19:51 AM »
Picked up a couple of dead Sega boards recently, the first out of the box was one of the massive double PCB System 16A board sets - Shinobi.





When powered up it gave this...



...which wasn't surprising as it was missing the main CPU.



Most Sega System 16A and 16B board games use Hitachi FD1094 encrypted CPU modules, which contain a suicide battery, a drop of RAM holding the encryption key and a Motorola 68000 CPU core. The main program code in the ROMs has to be encrypted with the same key as is held in the CPU module so that the 68K can actually run the code. When the battery dies, the key is lost and the game bricks. The decryption system was worked out many years later and decrypted ROMs are available which need a normal 10MHz 68000 CPU to be substituted for the encryption module.

The usual assumption is that the suicide battery ran out of juice and the CPU was pulled/binned/lost.

The only sign of abuse was a PAL on the video board which had been crushed into its socket...



...but had survived with all legs intact.

With that straightened out, and a standard CPU installed...



...all it needed were two replacement ROMs in the main CPU ROM set.



Am not sure if the silk screening on this board is wrong, or the IC locations that have made their way into the MAME info is confused, but one of the ROMs I was supposed to replace was at IC27, which is an 8464 SRAM chip soldered in, some where the info is messed up.

With a couple of 27c512 ROMs from my stash wiped and programmed with the decrypted code...



...the board fired right up, almost.



Spriteless!

I met a board that ran without sprites in the double repair log I did a couple of years back, which was pretty handy as the fault was partially the same and I could read where I had been.

I started off poking the banks of sprite RAM on the video board...



...three had a number of address lines with nasty looking signals, low twitching data lines and a /WE line that was tied low so the RAMs were always waiting for input on the i/O pins and never outputting anything at the right times, which is why the sprites were completely AWOL.

The holes in the address bus and the /WE issue were tracked to couple of 74LS157s at IC54 and IC62 with messed up outputs.



They looked nasty on the scope and the comparator agreed.



With those desoldered...



...and replaced the missing address lines lit up, and /WE was back in action, but there was no change on screen as the data I/O lines were still a mess low compressed transitions...





...which effectively means all data bits were set to 0 as the signals never reached the threshold to be considered a 1.

This was the same missing pull up fault on the 74ls374 bus data latches as found in the other repair log, except the cause is not actually a lack of pull up functionality, the data sheet I read stated that 374s are able drive a line to logic high without needing pull ups. Either way the issue is the same, the faulty latches take data in but can never pass it on.

There are three ICs that share the bus, the 74LS374s at IC63/IC71 and the 74LS244 line driver.



Its not uncommon for 244s to either cause damage when they fail, or be damaged by faults on their bus, so all three ICs were pulled...



...and all three were confirmed faulty. With those ICs replaced with working ones salvaged from scrap PCBs the sprite RAM I/O pins lit up again.





Progress but not a fix yet. I now had data being fed into the sprite RAMs and was now being written to the screen, but the data was either wrong, or was getting mangled somewhere.

The source of the sprite data is a bank of 8 ROMs on the video board...



...the data bus pins on these was a mess.



This is classic bus contention, where multiple ICs are trying to drive the lines at once, if both try to drive the line logic high you get a high, if they both want to drive low you get a low, but if they conflict you end up with a logic level somewhere in between. In this case there are four pairs trying to talk all at once so the resulting signal is a complete mess. The board should be able to turn the ROMs outputs on an off to ensure that only the right pair of ROMs has control of the bus at any given time, and this is usually achieved with an address decoder IC (usually a 74LS138 or 139). These take the most significant bits of the address bus and us them as signals to turn ROM's outputs on and off using their /OE (output enable pin). Looking for an LS138 or LS139 nearby found me this fella at IC32.



This is a dual decoder chip and all four output pins for the second decoder (pins 9/10/11 & 12) were constrained low and twitching. With all four pins firmly in logic low all four pairs of the sprite EPROMs had their outputs enabled and were trying to shout each other down, with the result being the mangled data written to screen.

Testing the 139 off the board gave no surprises either.



With a working LS139 dropped in the shouting match ceased and the corruption vanished.







That should be the end of it, but the next board out of the box was a dead Sega System 16B PCB, the PCB had the original label on it for Altered Beast and it too had an FD1094 CPU module on board. These usually still have their Sega part ID sticker on them which is useful as the code denotes the game and the version. Googling that code will usually take you straight to the decrypted set you need when evicting a dead FD1094. On any Sega system 16 board it is wise to start troubleshooting with the decrypted set and a normal 68000 CPU installed to rule out any suicide or partial suicide craziness.

The part number on that FD1094 was 317-0050...



...which is for the encrypted Shinobi Set 1.

Dumping one of the ROMs on the second board identified the ROM set as Wrestle War, the the board was a mix of a main board originally born as an Altered Beast, a Wrestle War ROM board and a CPU module from Shinobi - not surprising that it wasn't working. Even though the battery in these modules have been running since 1988 a small proportion are still hanging on to life, so I swapped back in the two original program ROMs, dropped in the CPU module...



...and it booted right up.



Clearly someone has been swapping bits around on these trying to get these two boards to work. Pretty happy to get a working FD1094 for Shinobi, my fetish for keeping things original means I prefer to have the suicide system and original CPUs intact. This means I have to replace the battery when I find one still alive, it is a bit of a faff but it keeps the board as close to 100% original condition as possible

Replacing the battery is fiddly and time consuming, any break in connection to the internal battery will instantly it the module, and you have to be careful of the tripwire they left for you. If you are too keen with the blade and you cut or nick the wire you risk bricking it too.

Basically with as wide a blade as possible you slowly lift and cut through glue around the edges...





...until the lid can be lifted.



The intent is to leave the top plate totally flat, if you bend it you will never get it to go back in place again.

Then it is a case of soldering a new battery in parallel with the old one, and cutting the old one out.

Test fit.



Leads fitted to new one and contact pin bent slightly to fit the case...



...and connections made in parallel to the old battery...



...allowing the old battery to be cut off, taking the lid and trip wire with it.



Smoke test time, the module goes back on the board and it is still working fine. If anything had gone wrong the module would be heading for the bin, there's no going back once they lose their RAM contents.





Still alive, and as the top plate is still totally flat it just drops back in place and the glue still has enough stick to hold it.



The date code on the old battery is for April 1987...



...a damn good innings for a standard watch cell, just over 10,501 days.

The new battery should be changed again in 10-15 years really, expecting another 30 would be pushing it a bit.

4
ARCADE / That other Terraforce PCB I mentioned
« on: December 12, 2015, 10:09:18 AM »
This was the board I decided was the least likely repair candidate of the two, which considering the shit-fight involved in fixing the first one was clearly going to be unlikely.



This too had signs that it had been someones repair project in the past. The CPU had been removed and replaced by a tatty looking, badly fitted CPU socket.



The soldering on the reverse was a mess, gloopy soldering, smears of solder splashes everywhere...



... and some of the socket pins were not visible through the board They had been pushed out of the plastic housing when the socket was forced down onto the board with only partially cleared plate through holes.



The PCB interconnects had their soldering touched up with is a tell tale sign that the previous repairer had absolutely no idea what they were doing.



This makes it hard to tell what's a good joint and what isn't, in reality you are more likely to make a good joint bad, than to somehow find an invisible bad joint and score a win.

Just to see what it would do in its original state I fitted a salvaged 16Mhz crystal, swapped in the known good ROM set, dropped in the sprite PAL and powered it up. All I got was black screen and no sound beyond the amplifier hum. While poking the various CPU bus lines I did get a few coloured lines on the screen for a fraction of a second, and some random bang and ping sound effects through the speaker.

As the fluke was set up already and I now knew the ROM checksums from the other board I hooked it up and went straight to sniff the RAM. This gave and instant Read/Write fail at 0x60000 the first location in the RAM space. Setting the test to loop constantly gave a blur of changing read back results.



The RAM was another pair of TMM2063 ICs which if not dead are likely to be flaky, so I removed them.



This board clearly wanted to be repaired as the desoldering was so easy that with a single pass the chips would literally fall out of the board.



The TMM2063s passed their off board tests, and I have no problem putting them back on the board in sockets when the repair is complete, but when troubleshooting they bring too much risk off adding craziness if they decide to play up or fail mid way through.

As desoldering was so easy going I took the CPU socket off to see what horrors lay beneath.

Turns out not much...



...especially after a good clean up.



Whoever desoldered the original CPU did a very good job but whoever soldered in the 64 pin socket did a horrible job, so I guess that someone guessed the fault must be a dead CPU, and took it off the board only to find it worked elsewhere and then gave up. So it ended up in someones scrap bin until someone else tried to fix it at a later date.

With no signs of track damage and the socket off the board I could straighten all the socket pins, realign the two pins that had been pushed out of the socket housing, give it a good clean up...



...and reinstall it, I am totally out of 64 pin IC sockets and they are hard to find these days in anything other than SDIP format. I also removed and tidied up the resistor network nearby as this was fitted at a strange angle and badly soldered.



With a pair of 28 pin sockets for the RAM and the known good 6264 RAMs from PCB #1  on board I put the fluke back on, and got the same result - constant read/write errors and a blur of changing readback results.



The issues clearly weren't related to the TMM2063s. If I wrote FFFF to 0x60000 and tried to read it back, I did get FFFF back, same with 0x5555, but With the test on continuous read loop it was a blur of random results. When I stopped the loop I did get FFFF back most of the time when doing it manually (ie much slower than the Fluke). I moved onto the chip select system with the scope, which is controlled by a nearby 74LS138. With the HP logic comparator connected  to that IC as well as the fluke running its loop test I could look for any misbehaving address decoding that would have the effect of sending reads to the wrong block of address space giving read backs from ROM rather than RAM. It reported no weird behaviour compared to a known good 74LS138 it had on board.

Time to buzz out the buses, and it didn't take long to find a fault, the A3 line only connected ROMs 6 and 7 to the CPU, but not the RAM or ROMS 1,2,3 or 8. As I had photos of what was under the RAM and the CPU socket I could recheck that I hadn't missed any damage. As the bus lines seem to take a U shaped path from the CPU, up the right-hand 3 ROMs, across the two RAMs and back down through the right hand ROMs I had to have an open track between the 7 and 8 ROM sockets. I think at the right angle you can just see a dark dot on the trace as it goes under the silk screening which is probably the rot spot. Am fairly sure this board got wet and water stayed under a number of IC sockets longer than elsewhere causing corrosion.



With nothing driving the A3 input across a number of ICs it was left floating and can wander about voltage wise depending on what the rest of the IC is doing. So sometimes it was a valid logic status and other times not, so the actual address being written to in the RAM would change over time, giving the random read-back failures, but ones that were hard to catch doing manual read/writes.

After fitting some hookup wire between these ROM sockets ...



...I hooked the fluke up and re-ran the tests. All read/writes to RAM were now stable, the board even passed the "Long RAM Test" which is designed to flush out even the weirdest decoding issues.



It could also calculate the correct signature from the entire set 6 CPU ROMs, proving the CPU buses were all working fine.



This should mean the board would at least boot and do something, except it didn't, it was still stone dead.

With scope data lines on ROMs were still mashed, the most likely cause for the widespread nasty signals was that the CPU had simply crashed, this can leave the bus pins in weird states that look like something horrible has happened external to the CPU. There isn't much directly on the buses outside the RAM, ROMs, CPU some LS244s and the LS347 at B4 that caused problems on the other board.



It had active inputs but vague outputs on a number of gates, so I took it off the board. The PCB can run without this as it just disconnects a large lump of the spite graphics system. With the IC removed the board still gave a black screen but started to produce a cacophony of sound effects and long sections of background music. It started playing the theme tune early on and it sounded like it was playing blind, but the effects and music were just random, its junk data going to the sound CPU that it is interpreting as instructions to play music track X or sound effect Y, at least the sound system seems to be working. The 74LS374 tested OK on my EPROM reader by I am not over confident in it, it is possibly a coincidence that a degree of life returned when it was removed but possibly not.

Another change was that every so often the screen would now flash up blue zig zag patterns, clearly it was still crashing, but something had changed.



As I was sttill looking for something nasty on the main CPU buses, and with the constant shifting sand of faults on PCB#1  fresh in my mind, I hooked up the Fluke and re-ran the RAM and ROM tests, which it still passed, but with a CPU in the socket the board stayed resolutely dead.

You can actually use the CPU in the Fluke pod as a normal CPU and get it to try to run the board with the "Run UUT" button, UUT being "Unit Under Test". I had had no luck with a real 68000 CPU but the fluke is easier to reset rapidly as you don't need to constantly flick the power to reset the board. I tried to reset the board and issued the Run UUT command with a start address of 0x0 and the first 3 times I got no response, but on the fourth time it booted up and the board ran and stayed running.

The board had weird faults while running, there were B's everywhere...







the ship in the intro was a golden colour rather than silver...



... the sea was the same colour as the land...



...and there were blocky halos around some features.



Also the priority system has the text behind the foreground so you see it in the distance between the trees on the forest level in attract mode.

5
ARCADE / Terraforce Repair Log
« on: November 29, 2015, 12:43:33 AM »
Felixthedog brought this board round a few months ago to test it in my cabinet as it wouldn't fire up properly at his house. It was missing some key parts and showed signs of being someones repair project / parts board before.



A couple of 74LS257s that decode the dip switches had been removed and replaced with (now empty) sockets, a decoupling capacitor that I am pretty sure was not original (the second board set doesn't have one) had taken a beating...



...the amplifier chip had been pinched from the back board...



...and there was a chip missing from the top board leaving an empty original 20 pin IC socket.



The last bit was the biggest concern, very few ICs on old boards were socketed, and 20 pin usually means a PAL chip. These are configurable logic ICs that take the place of what would be dozens of logic ICs if discrete chips had been used. This means they are highly specific to the board (or board family) and usually cannot be easily replaced. Even though they are programmable it is usually a one way process due to the security bit being set. This usually means a programmed chip cannot be read successfully, so you cannot read the config out of a good one to program another one. Your only hope is that they forgot to set the security bit that day in the factory, which is not very likely. I did fire the board up in my cab and it did precisely nothing, with that chip missing the board was a no hoper unless a donor board could be found so I didn't investigate it any further.

Fast forward 3 months and Felixthedog  had sourced a donor PCB, another faulty PCB set but one that was complete. Initially that board set looked like a better repair candidate but not for long. This one had been someones repair project and they had made a mess in a number of areas. They had re-soldered all the PCB connectors and then over tightened bolts holding the board together. The soldering was messy and with the stress on the boards some of the pins had been forced through which tears the plate through holes, meaning a lot of the joints would be unreliable. The board also showed signs it had been wet at one stage, with corrosion and track damage under a number of the ROMs, and the ROM legs oxidised to the point that a number couldn't be read, ut it did have the PAL chip that was missing from the other board.

Swapping the PAL into the original board...



... and dropping in a couple of 74LS257s ...



...resulted in not much, basically a stone dead board. Oscilloscope time, hitting up the 68000 CPU showed I had clock, and that /HALT and /RESET were both high, so the board should be running. At the exact instant of power up the board did give a burst of activity on the CPU address lines at the ROMs but then went quiet, a good sign that the CPU is crashing, probably because it has no working RAM, or because the program code in the ROMs is corrupted. The main system RAM was a pair of Toshiba TMM2063 ICs with the shiny black tops...



...which are almost always dead on faulty boards, but as the ROMs were socketed I ran them all through the EPROM reader to check I wasn't looking for a hardware solution to a software problem. All the ROMs checked out and the output from the RAMs looked suspect.

On some data IO pins the signal looked healthy(ish)...



...but on others there was just a ragged mess...





...and while poking around with the scope the screen did spring to life...



... and on reboot, I did briefly get this...



...once, before it returned to being dead.

Which kinda suggests I was in the right area, the fact this board can barely even get this far isn't that surprising, the RAM/ROM check is itself a computer program running on the CPU, so if all the ROMs are dead then the test code isn't there, and if all the RAM is bad there is no space for the code to execute in. In this case the RAM is clearly almost totally dead.

The desoldering gods were not on my side that day, normally I like to get a chip off intact so I can test it off the board, but this was hard going, so I cut them off and removed the legs individually.







With two sockets fitted (about the only time I use sockets is for RAM and ROM) and two scrap board RAM ICs fitted I got.... a stone dead board again - the exact opposite of what was expecting.

Going back to basics I found I now had no clock at all at the CPU, until I touched the 16Mhz crystal. It was only hanging on by one leg, the other had rusted through, it showed signs that someone had tried to solder it back on, trouble is you can't solder rust so it was barely making a connection.



With no spare crystals of the right frequency I robbed the one from the other board set...



...and fired the board up.



Progress, shame about the colours, and the background, and the sprites, oh and it crashed a lot, sometimes instantly, other times mid-way through the attract mode cycle, or after a few seconds if you tried to coin up.

The colour fault was down to a totally dead TMM2015 SRAM chip of the pair that form the colour RAM. This had activity on its address bus but its data pins were floating, which means you can piggy back another IC on top without any issues. It is as if the original chip isn't electrically there so it acts solely as an adapter. With a scrap TMM2015 chip from my stock piggy backed full colour was restored.



Not wanting to do any more desoldering I left the piggy back in place for later and moved on. The constant crashing was the main problem still, the graphics issues were secondary and were unlikely to be involved in the stability issues.

I had initially suspected bad contacts between the boards as being the cause for the lock ups, mainly because when it crashed it would not recover when the power was flipped off and back on, it would just power back up in the same wedged state.

After some poking around it turned out that pulling it apart and putting together just enforced enough of a delay between powering down and powering up for it to boot properly, it stopped me powering it back up too soon. This pointed towards the system RAM again as that is the only place the state could be stored temporarily, and as I had put a pair of mismatched junker SRAM chips it was possible they were not playing nicely together. Swapping in another combination, also junkers, cured the crashiness and also brought all the sprites back. These fly around the screen so rapidly its almost impossible to photograph them against a black background as the camera takes too long to focus on the bright spots.



It's unusual that the main system RAM has anything to do with the sprites on boards with separate graphics subsystems but this one seems to be an exception. It's lucky that the board was so crash-happy, if it had run fine just with mashed sprites I doubt I would have found my way back to the main system RAM as a suspect for that.

With every issue so far being SRAM related it was pretty easy to find the next issue, what turned out to be the foreground SRAM had a dead IC in the pair, and it responded to the piggybacking trick.



Lighting up the missing data lines.







Looks like progress to me, so it was desoldered and a socket fitted.







The one remaining issue was the overlaid band of pixels on the right hand side of the screen, my guess was that this part of the mangled the character layer as the text on the screen would glitch from time to time.



The culprit again was another pair of SRAM chips at E12 &  E13...



...with the scope showing bus contention on the data pins, basically one chip has lost the ability to keep quiet and let other chips on the bus talk, so the two chips fight each other, giving the half way data levels. It could also be the ROM but as I had a second board I could swap the ROM, the chances both ROMs would have faults on the /OE pin were unlikely so RAM it was, at least one of them was going to be bad.



I picked the wrong one of the pair to desolder first...



...with just the bad one left on the board I was greeted with this...



...with the game running in the background and a wall of crap in the character plane on top.

With the bad SRAM chip replaced I got this, graphical perfection!





All the controls worked and the game could be coined up and played, in silence, amplifier time.

I had planned to pinch the amp chip from the other board set but the amp type was pretty common (handy to have a second board to check what it should be, there don't appear to be any schematics for this board out in the wild), so I found a replacement MB3730 on a scrap rusted out Midnight Resistance PCB.



Whoever removed the original amplifier IC had done a very good job of desoldering the original...



... so it was just a case of bending the legs, applying a drop of heatsink compoundt, bolting it down and soldering it in.



On power up there was still no sound, for about 30 seconds after which there was a massive pop in the speakers and the theme tune started to blast out. Whether the delay was the amplifier IC or the capacitors waking up after a long hibernation I can't tell, but it only did it once and the music and sound effects were fine, sadly the amplifier chip was not. It was getting roasting hot within 30 seconds of being powered on, which usually means it is oscillating. A voodoo blend of noise on the PSU, PCB layout, stray RF interference and component health can result in the amplifier oscillating, the first sign usually being a burning smell even though the audio may be fine. I had to assume that the PCB layout was correct and that it didn't do it from new, although it is possible that it was the cause of the original amplifier chip's demise. Logically the place to start were the capacitors, specifically the 470uF one between 12V and ground which is there to clean up the 12V power rail.



The ESR reading was about twice what a good cap should be, but ESR isnt major issue in this case. Anyway, a capacitor swap was easy enough, and it had no effect at all on the overheating problem. Decoupling for amplifiers power rails is usually achieved with a pair of capacitors, a very large electrolytic and a very small mylar capacitor. The large electrolytic provides power rail stability and mops up the low frequency noise, the small mylar mops up the high frequency noise. Digging up the datasheet for the MB3730 showed the recommended circuit for the IC with a 2200uF electrolytic and a 0.1uF mylar cap on the power rail. The PCB had no provision for the 0.1uF anywhere so I fitted one on the underside of the PCB across the 470uF capacitor.



Problem solved, the MB3730 would now only get warm and not overheat. So I swapped it into my cabinet for a game and blasted through the first level and called the board fixed!

Or not, the following day I had planned to find the right stand-offs for it and bolt it together finally, except on power up for another game I was greeted with this.


6
HARDWARE/SYSTEMS DISCUSSION / Atari Mega ST4 Repairlog
« on: January 01, 2015, 09:45:36 AM »
I doubt there were many of these under the Christmas trees this year, but under mine was this, an Atari Mega ST4!!





I have an unhealthy number of the Atari ST line from the original 520ST with external floppy and PSU upto their last gasp in the form of the Falcon 030, but I had never seen a Mega in the flesh before. It is basically the same machine as the STFM but with the addition of a blitter chip as standard, an internal expansion port for upgrade cards and a lot more RAM than most STFMs ever saw. Mega STs originally came in 2MB and 4MB versions, and despite the press at the time stating Atari would not release a 1MB machine it seems they eventually did so the line up runs from the base Mega ST, to the ST2 and this one, an ST4. Apparently the Mega name proved to be problematic for Atari when they tried to call the hard drive for the range the Mega Drive, for some reason Sega took exception to this and threatened legal action. Atari backed down and renamed the HDD range to the somewhat less inspiring Megafile.

The unit was bought untested presumed faulty by the seller as it had been in storage for 15 years, and at some stage it had been modded to give it a DB9 video output socket instead of the odd 13 pin socket that only Atari and Kenwood used.



The rear blanking plate that covers the expansion module slot was missing and a large phono socket was fitted on the shielding. Initial hopes that this might be something exotic didn't last long, the original Atari 13 pin DIN socket carried video and audio, but the DB9 probably wouldn't, so I expected this would be the missing audio output tapped off the board.

It was missing the keyboard cable, but it did come with the original batteries for the internal system clock, best before 11/87 according to the data stamp.



Possibly somewhat past their best but the damage could have been a lot worse. One terminal was welded to the battery and took some persuading to let go.



As I knew this was coming I bought a new 13 pin DIN socket from eBay as I am awash with Atari monitors and wanted to put this back to the way it was born, my only concern was how much damage had been caused by whoever did the conversion.

Once the lid was off and the shielding removed I could get a look at the patient.



Initially it looked like the mod was done without making too much mess...





...and the DB9 was mounted fairly neatly with a single screw through the rear shielding so it could use the original case hole rather than a new hole being hacked through the plastic.



Sadly underneath was a different story...



... oh the horror.

Still, the pin configuration of the new DIN 13 was correct for the board.



With the old mod removed...





... and a load of isoprop applied to clean off the old burnt flux it looked a lot better.





Only a couple of plate through holes that were actually used had been ruined, so the socket was easily fitted plus a single length of hookup wire and a small length of component leg soldered to a track so it would join to its pin.



Back the way nature intended!





A few other issues were fixed too, the connection of the lead to the battery compartment had been badly soldered and was about to give way, and a large capacitor was loose due to a poorly soldered joint.





Also someone had also been at the cart connector shielding with some pliers which was pretty ugly, plus the remains of a past resident had to go.



The sheilding was sorted out with a mini-vice to get a long straight squeeze on it.



Pretty effective!



Finally some solder and wire remnants on the inside of the cartridge connector were removed.



Time to fire it up...



... hmm dead, just a white blank screen.

Most of the time anyway, once it did give me a load of corruption on the screen.



A quick probe of the 68000 CPU showed it was getting clock, and that /RESET was toggling correctly when the system booted and was going high after a brief stint low, /HALT on the other hand was held low and only slightly twitched on boot. On a Mega the /RESET and /HALT lines come from a 74LS07 buffer chip at U2.



Pin 1 and 3 are the inputs to two buffer gates and are tied together giving a common input. The output from the gate across pins 1 and 2 goes to /RESET while the gate on pins 3 and 4 goes to /HALT. Some research online showed that U2 is a very common cause of Mega STs failing to boot as the other gates on the chip are used for the MIDI sockets so any external violence on the MIDI lines can damage this chip as not all lines are opto-isolated. The joined input pins to the two gates were being fed from the reset delay chip at U1 (the other common failure apparently) and were going high at the correct time, so that section looked like it was behaving.



The problem I have with the /HALT line on a 68000 is that it is both an input and an output, a multi CPU system can instruct a 68000 to halt by pulling that pin low, but the 68000 can also use the pin to signal to the outside world that it has encountered a bus error and has halted itself. Its hard to tell which is which from the outside, but as U2 was a known common failure I desoldered it.



In fact I had to cut off half the legs as one side of the chip just would not desolder, half the pins were missing their stumps on the solder side too which meant I could not waggle the legs while desoldering.



A known good 07 was soldered in place and the system rebooted. Still no change, /HALT was still staying low so it seemed something on the bus was causing the CPU to halt itself.

Likely candidates included the DRAM, the TOS ROMs or the glue logic itself. The glue logic is a large custom chip and probably fairly robust, the TOS ROMs are a pair of Atari Mask ROMs of unusual pinout so a pain to test...



...and the machine has a lot of RAM, 32 DRAM chips that share the busses.



The TOS ROMs were the easiest place to start, but as these are mask ROMs and do not share a pinout with any EPROM, would have to make an adapter to verify them. Except I wouldn't, I had assumed the Mega machines had a their own TOS versions but they don't, they take the standard TOS used in early STs, the only variation is whether they are a  6 ROM set or a set of 2 larger mask ROMs. A quick dig in my 520STFM revealed it had the exact same pair of ROMs, even down to the Atari part number on the silk screen. So I swapped the unknown ROMs from the Mega into the STFM and powered it up, and was greeted by the white screen of death. Swapping the known good STFM ROMs into the Mega and connecting everything up gave me a system that would finally boot to the little green desktop.



It's Alive!

The next problem was that without the keyboard cable I had no way to get the machine to do anything after boot. The mouse sockets are underneath the keyboard and with no way to connect the keyboard to the main unit I was lacking both a keyboard and a mouse. More research showed that the cable required is just a straight through 6 pin RJ12 cable that is used on some phones. To add confusion to the matter 6 pin RJ12 sockets don't necessarily have 6 pins, some have 4 but are in a connector the right size for 6. This is usually indicated by "6P4C", or "6P6C" for 6 pin 6 core cables. As the Atari keyboard pinout has pins 1 and 2 joined together and pins 5 and 6 likewise a 4 core "6 pin" would work fine. The local hardware store was happy to sell me a 30cm 6P4C phone cable for the princely sum of $5, it even came in the slightly yellowed Atari colour. Shame it wasn't quite right, this was a cross over cable where pin 1 goes to pin 4 and pin 2 to pin 3 etc etc. With the keyboard PCB out of its case and connected to the Mega with the power off I could tell that the power to the 74LS244 on the keyboard was reverse polarity, the 5V rail was connected to the ground pin and the ground rail was connected to the 5v pin, it really would not like that.

With a lot of force  I was able to pull one of the RJ12 connectors off and by drilling some small holes in the connector I could insert needles to lift the contact blades again. This allowed me to re-crimp it with the connector reversed, turning a cross over into a straight through cable.



With it connected up I now had a working keyboard and mouse and could test the system.

Which didn't get me very far, the floppy drive was dead, despite the system recognising it has a drive on boot it is unable to read any disks you give it, the heads are constantly searching blindly for the tracks and getting nowhere. After a stint of head cleaning and looking for anything obvious I admitted defeat. Finding a replacement drive is easy enough, but getting one that will take the Atari style fascia and huge eject button is not.



This one was one of the older style double thickness drives and seemed rather Atari specific...



... after a bit more research it seems it is a Chinon D357, a very similar to the drive model used in early Amiga 500s but not close enough to transfer the bezel and button as the front mechanism is different, possibly they were custom orders based on the aesthetics required.

How about this as a donor?



It contains another Chinon drive, slightly different model and the bezel and button are actually different on the inside but it fits perfectly, right down to the slanted LED that fits into the slot for it on the Mega's case upper.

Once fitted the system could finally load disks, so it was given the Psygnosis Test and left to play the Shadow of the Beast theme tune for a while to prove I finally had a fully working machine.



One remaining issue was that it was filthy.









Bath time!



The case upper and base were fairly straight forward, the real work on these restoration gigs is the keyboard. The photos probably don't show how manky this was, but this shot does, and that was only after the casing had been done, the keyboard was another matter.



Very unpleasant...





... everything was pretty well stuck down with what might be old cigarette smoke residue...







...whatever it was warm water and Jif chewed through it.

The keyboard on the Mega is of a higher quality than that on the ST which has the feel of typing on bubble wrap. This one uses Cherry micro-switches for each key instead of a rubber domed contact, and although it isn't up to the clicky key quality you get on high end PC keyboards it is a great improvement, except when it comes to dis-assembly. The micro-switches are pushed through the metal plate and clip into place, and the PCB is soldered on from underneath so to get the key bed into the sink I would have to unsolder about 200 solder joints to break up the main assembly, I decided to pass on that opportunity and clean it intact. I used a very slightly wet brush to give it good going over a number of times which did the trick. It and the gutted mouse were left outside to dry in the warm...



...while the keys spent the night air drying somewhere a bit safer inside.



Time for the best bit, some re-assembly.





One thing that annoys me with gear that someone else has been in before is they always seem to have cocked up the screws, either putting the originals back in the wrong places, or losing the originals and substituting something completely random. Spot the odd one out...



...I suppose this could have been worse. I was able to find a screw in my scrap box that's an identical match to the originals so the monster one was retired.



Looking good!

Still has the original protective sticker on the name badge.







Will see if I can track down a blanking plate I think to cover the hole up.

Keyboard rebuild time!



The complicated keys go on first while there are no other keys in the way, with a drop of lithium grease on the sliding parts to stop things sticking or squeaking.









What an improvement a good clean makes!



Another test...



Shadow of the Beast!



...and it was paired with an Atari Megafile 30 hard drive for that no-expense spared 1988 luxury feel.





A full 4MB present and correct too, it's a shame that SYSINFO doesn't know it is a Mega ST, I guess electronically it is just the same as a regular ST, just one with a blitter and a lot of RAM :)

Restoration complete!

7
HARDWARE/SYSTEMS DISCUSSION / Amiga 1200 Repair Log
« on: August 08, 2014, 11:59:48 AM »
A bit of a break from Arcadia but much the same kind of work involved...

My regular search for interesting faulty stuff on eBay threw up a gem last week, a faulty Amiga 1200 unit.







WTF? - a 130MB 3.5" HDD bodged inside instead of the correct 2.5" HDD on an official caddy? It was held in place by two strips of bent metal and was resting on the motherboard on a bit of roughly cut plastic sheeting. The PC style molex connector power leads were bodged onto the inside of the power connector. All in all pretty nasty.



So, to get a baseline test it was stripped back to a bare bones A1200 to rule out hard drive faults and accelerator card issues.



Sadly it was still dead, no signs of life on the screen, even the noise from the HDD when it was still installed was just the standard HDD spin up and head noises, no signs it was being used by the system.

So I checked the voltage levels first then went back to the board inspection and quickly found the prime candidate for the fault.



Pin 13, i.e. the third pin in from the left is missing all the solder, this is what happens if you touch up old solder joints without using flux, the solder gets sticky and clingy and you end up dragging it away from the joint on the iron. Pin 12 isn't much better but it is still attached, pin 13 is just resting on the pad, which may work for a while until oxide built up at the touch point.

As soon as I applied the slightest pressure to this pin the system booted to the "insert disk" screen.



So the joint and all others on the two messy 74LS245 chips were tidied up to complete the fix.

With the hard drive reattached it booted into workbench happily.



Heres the official caddy and drive from a 1200 and the one they had crammed in.



Both my 2.5" HDD and the 3.5HDD are pretty loud, the current draw from the 3.5" drive causes some image instability when it is accessing data, which is a design flaw on the board that I could rectify, but with a CF card the current draw will be minimal so the problem will likely vanish anyway.

Anyway - a quick reassemble and time for a full test...



...with the title of choice for all my 8 and 16 bit repairs when possible...



...Treasure Island Dizzy!!



All in all a damn fine eBay score!!

8
ARCADE / Yet another TMNT Repair Log
« on: June 12, 2014, 01:45:08 PM »
Would you ever guess this is my favorite PCB to work on?

Had Arcade-Inferno's TMNT PCB on the bench this week. It was said to be working but had vertical lines across the screen so came south for some TLC.



A quick eyeball showed a couple of issues, the 1000uF 16v capacitor for the 12v rail feeding the amp was ripped off the board leaving just the leg stumps. These caps are usually knackered even if they are still there as they stick up so high they get knocked or wrenched to one side.



There was also a spot of corrosion on the tracks near the mask ROMs H27 and K27.



The board booted up, made an loud angry buzzing noise for 3 seconds, passed the self tests...





...and progressed to the game.







Yup - jail bars!

I flipped dip-switch 3, bank 3 to put the board into self test and rebooted. After a long think it came back flagging the H27 mask ROM as bad, which I promptly forgot to photograph. As this ROM is right by the corrosion spot I was fairly confident that this would be the fault, but with the multimeter set to continuity mode I could prove that pin 28, which was the most affected by the track corrosion, was still connected to everything it should be connected to, as were the other pins served by the other tracks that looked suspect.

A usual suspect for lines through sprites or graphics on Konami boards are the mask ROMs themselves, these chips are not ROMs that are programmed but are ROMs that are manufactured with the data structure built in. They are etched, as all ICs are, using light masks to expose certain sections of the silicon, while masking others off - hence the name. They are possibly sensitive to static and as they are mounted on the board edges they are likely to get zapped by static laden fingers, on other Konami PCBs that have mask ROMs on the edge as well as more towards the middle of the board, it always seems to be ones at the edge that die, potentially they are getting zapped.

If an address bus pin is damaged the data they output is always the wrong section of the data, and if a data bus pin is damaged you get missing bits in the bytes being sent out, which causes lines to appear in the graphic. People usually assume that when talking about 0s and 1s representing data that a zero is the default state, and a one is generated as required, when in fact it is the other way round. A ROM when completely blank contains all ones, and data and address lines are at logic high (ie 1) when resting. The zeros are slotted in by pulling the bits to ground, ie logic low. The white lines across the screen suggested that the offending bit was always set to one and was not able to be pulled low.

A quick scoot around the mask ROMs H27 and K27 with the scope showed there were no data pins that were tied high, or floating, so the mask ROMs looked like they were still ok.



Pressing hard on the 120 pin surface mount custom chips didn't have any effect either, this can annoy faults due to bad joints upstream of the custom chips, but it isn't guaranteed. If you have 119 legs firmly soldered in place and one loose the chip is so firmly attached that the bad leg doesn't move. Also if it has been loose for a long time oxide will have formed on the pad and the underside of the pin further reducing the likely hood of a good contact being made.

So I ran a plastic pin gently along the feet of the chip and the fault vanished as soon as pressure was applied to pin 26. The fault would stay clear for a while then would suddenly reappear. This behaviour can be due to the connection failing after a while, or because the data is held in RAM upstream while it is in use. If the data gets out of the chip while the leg is making good contact then the RAM buffer holds good data without the erroneous bit set to 1 that causes the lines. The leg contact may fail as soon as pressure is removed but the fault only reappears once the RAM is flushed and the ROMs are accessed again as the board cycles through attract mode and needs to re-use the RAM space.

This is next to impossible to see with the naked eye, even catching a shot of it is hard, I have about a dozen photos of this chip and only on this one has the flash caught at just the right angle to see that pin 26 has cracked free from the board underneath it.



Some flux and micro soldering of the affected pin (and its any neighbours and other suspect legs) cured the fault entirely.



The photo looks a bit messy, its a combination of the extreme shine of the new solder and the fact I hadn't cleaned the flux off yet.

The noise on first power up is the amp chip "motorboating", due to the missing smoothing capacitor on the 12V rail. This is there to ensure the 12v supply is smooth and free from interference. Without it the amp briefly oscillates as the 12v rail sags and recovers from the inrush current drawn by the stone cold amp waking up.



Fitting a 1000uF 25v capacitor from a road kill TV cured the issue, and will protect the amp chip from RF that can cause them to oscilate permanently while they cook themselves to death.

I also scraped back the corrosion on the tracks to bare copper and put a drop or laquer on the area to prevent further rot from taking hold.

Another common fault on TMNTs are the 74LS253 multiplexor chips that detect the control inputs (and dip-switch settings) and provide the data stream relating to control input activity for all players so I quickly tested those too. As with all arcade boards (well probably all, all I have ever met), the default state for any control line is logic high, ie a 1. When a switch is pressed, or a joystick directional switch is closed, this line is connected to ground (with a resistor in path to prevent a direct short on the power supply). The 3P and 4P input connector are as follows, and have all the inputs for the players (including coin and service) as well as system ground.

1   COIN SWITCH
2   (UNUSED)
3   P3 LEFT
4   P3 RIGHT
5   P3 UP
6   P3 DOWN
7   P3 JUMP
8   P3 ATTACK
9   (UNUSED)
10  (UNUSED)
11  P3 SERVICE
12  (UNUSED)
13  (UNUSED)
14  GND
15  GND

With the board set to test mode you can progress through to the input testing section.



I have a length of wire with a spike probe on either end for tests like this. With one probe on the GND you can connect each pin to ground in turn, if the test program notices the state change on all inputs (i.e. left, right, jump etc etc) then the multiplexor logic is working fine. In this case all inputs were working happily.

An interesting (well to me anyway) side note, this is probably one of the earlier TMNT boards, as it has one of the old style ceramic capped TTL chips...



...and also the factory mod bodge wire (that I assume was to fit an external reset button) that seems to be fitted to almost all TMNTs I find isn't present.



The capacitor at this location is usually replaced with a diode and a wire link to an unused edge connector pin.

Anyway - board fixed!

Turtles!!!




9
ARCADE / Another TMNT Repair Log
« on: June 01, 2014, 11:57:15 PM »
Hi RCMers, another TMNT repair fresh from the bench.

Had Waterex's TMNT PCB on the bench this weekend, he'd found in the bottom of a TMNT cabinet he bought that was running a Simpsons PCB.



The fault was described as it giving a white screen which flashed regularly, which is what the board was doing when I got it, but it wasn't quite what I expected. The board would boot with a burst of a chugging (aka motorboating) noise from the speaker, give a white screen which would be stable for 5 seconds, it would then flash (PCB resetting), remain stable for another 5 seconds and then reset. Rinse and repeat ad nauseam.

Normally when you get a TMNT board doing this the flashes are very rapid, half a second apart with a regular ticking in the speaker. That is classic watchdog behavior of a board unable to even boot up, the watchdog timer expires during a period of inactivity on the buses, indicating the CPU has crashed, so the reset signal is sent to repeat the whole process over and over again. In this case, the long pause on this board meant it wasn't crashing and was actually running the power on self test, reporting it had found a fault, then rebooting itself. The only issue was that it was doing it blind, where the test results should have been was only a white screen.



A quick eyeball of the board detected a few things, the factory-fitted bodge wire had been cut, this looks like an aftermarket bodge but every TMNT I have ever seen, except one, has this done to it. Its not completely clear from the schematics what this achives, potentially it allows an external reset switch to be fitted to an unused pin on the JAMMA edge connector.



The board had the usual physical damage to the 1000uF 16V decoupling/filter cap on the amplifiers 12v rail, this stands up so tall it is usually knocked over or torn off altogether. Even if it looks fine you usually fine one of the legs is torn off inside as it had been wrenched over. When straightened up the ripped off leg slides back inside and it looks fine, but they are usually ruined. Flexing the cap gave a popping noise from the amplifier output so it was clearly knackered as its connection internally was not stable.



Knowing the board was playing blind the first point of call was the palette Static RAMs (a pair of TMM2018 45nsec SRAMs )at PCB locations F23 and F24).



These contain the colour information for anything on screen, no data output from these, or the wrong data, can lead to complete white out.

Poking the scope at the data bus pins showed this...



...technically not "floating" and noisy enough that the logic probe detects activity (demonstrates why a scope is infinitely better than a logic probe for actually seeing what is going on) the pins are active, but it is putting out junk that doesn't represent data at all.

The total white out is due to there being no data input into the colour logic, so the colour inputs are always high downstream, a trick to nudge the system is to inject junk data onto one of the data lines. Bridging D0 with the next door address line put rubbish into the system and the screen lit up.



The scraps of graphics all over the place is totally normal, all TMNTs do this as the RAM test routine seems to use gfx ROM data, on a working board the palette data should hide this.

So, F22 and F23 are flagged as bad, pretty much expected, however these tests cannot be taken literally, the "BAD" result really only means "I tried to write XX to RAM address location Y, but when I tried to read back from Y I didn't get XX", there's a lot else that can go wrong aside from the RAM chips themselves, by far the most common on Konami boards of this era is the control logic or track damage.

A poke around the /CS (chip select) /OE (output enable) and /W (write enable) control pins that drive the SRAMs showed that the chips were in a valid state, ie /CS was low (chip active), /OE was low (outputs active on the bus) and /W was high (chip in read mode), therefore the output pin should have been active, or at least high or low. The control lines were all static which initially looked suspicious, so I did a quick backtrack up the control logic looking for any issues in the TTL but found nothing amiss, the 74LS157s that drive the address bus on the SRAMs were all active, the control line logic tracks back to a 74LS32 at H11, a 74LS04 at H18, and then onto a 74LS138 at H25 (all Fujitsus) but everything looked fine.

The only remaining candidate for the fault was the SRAM chips themselves, which based on the manufacturer (Motorola) and previous TMNT repairs would not have been where I would have guessed.

One trick that is common with logic faults is the piggybacking of known good chips onto suspect ones. This risks destroying the new chip if the old chip is faulty in certain ways, in this case the old chip's outputs were effectively unhooked from the bus and the chip did not appear to the shorted, so piggybacking is a valid approach.

Piggybacking a NOS Toshiba TMM2018 on F22...



...got me this...



Adding another to do the same on F23...



gave a full bill of health...



...and the game started.

Hmmm, something not quite right here, no logo...



...and no character sprites.



Unsurprisingly, the sprite RAM is another MCM2018N45, at G8, which apparently passed the RAM/ROM tests according to the output. These quick tests are often very basic and in some cases may outright lie, in this case I doubt the board even tries to test this chip as its outputs were just as stuffed (i.e. completely) as the palette RAM pair.

Another chip from my stock piggybacked...



... and everything was restored.





To make it permanent the old chips were desoldered, and sockets with new chips installed.



Desoldering on Konami boards can be a pain, my desoldering station needs an overhaul an I could not get the holes to fully clear. As I had no doubt the original SRAM chips were dead I ended up cutting the legs off and removing them one by one, brutal but it saves the PCB the torture of constant heat cycling.





Final fixes to the reinstall bodge wire, and the amp capacitor



Board fixed!

I also put the board through the full mask ROM tests and verified the 3P and 4P inputs were all working, a common fault is the death of some of the input multiplexor chips which take the player control inputs.

This board is a bit of a rarity in the fact that it didn't have a single Fujitsu TTL fault, and a complete set of three dead Motorola 2018 SRAMs, usually its a tonne of bad logic and everything else is mostly OK.

10
ARCADE / Double Bubble Bobble Repair Log
« on: May 26, 2014, 11:08:22 AM »
Got an exciting parcel in the mail recently, a box of interesting faulty boards to replace the uninteresting ones on my too dull pile that I have been getting rid of.

Two Bubble Bobbles, a TMNT, and a Black Tiger, all originals of course!! Unfortunately the box arrived looking like this.



The cardboard looked like it had got very wet at one stage and been dropped, or kicked hard. Not sure if the strapping was there when it was posted or if someone had taken pity on it on the way, but the stoved-in end was torn completely open on two sides and it was held together with the strap. Inside the boards were well packaged but am surprised the box made it.

All the boards except one were physically fine, and of course the one to take the brunt of the force had to be one of the Bubble Bobbles, on opening the bubble warp I was greeted with a shower of plastic and something metal pinged out onto the floor, the lid of a RAM chip, not a good sign.



Amazingly the board looked mostly OK.



The power connectors were battered and manky, but they usually are as people solder directly to them rather than using the correct connector.

The board had signs of previous rework as one of the Z80s was socketed and a lot of the TTL logic had been replaced previously, but it was all pretty neatly done.



The shower of plastic was from the 60 way IDC connector on the video board, it has been smashed inwards bending a lot of the pins and shattering the socket housing as well as the ribbon cable plug itself.





The chip lid was from a nearby chip in an area otherwise untouched.



Aside from these the board had the usual physicals faults form a hard life, broken PCB standoffs and mashed decoupling capacitors in every corner.



Despite the violence none of these faults looked like a reason not to power it up I plugged in my harness and flicked the switch, I was expecting to see a boot up fault and at least a colour fault due to the smashed RAM chip. It is one of three that sit in the colour palette section with each chip handling either Red, Green or Blue data.

Amazingly it booted up flawlessly.





Whatever the original fault was, it was gone. I suspect it would have been fixed by re-seating the ribbon cable and all the socketed chips as oxide builds up on the metal to metal contacts making the resistance higher and higher until the connection is lost. Re-seating everything scrapes this layer away and the contact is remade. A violently applied boot to the ribbon cable connections would achieve much the same effect.

I tried the second board at this stage, but finding that a lot more faulty I returned to fix this one up properly. Removing the smashed 60 was IDC was a pain in the rear, as although the board is beautifully made with large robust plate through holes, the IDC connector pins are chunky and all 60 have to be completely cleared of solder before it would shift. This took about 45 minutes and many many passes of adding new solder and re-clearing with the desoldering iron.



Then I had to repeat the whole process again on the scrap donor board to get a usable 60 way connector to install, a rusted out Tecmo World Cup 90 PCB valiantly gave up its connector.
It turns out 60 way connectors are uncommon in arcade land, most boards use 50 way which you can still buy at Jaycar new, 60 ways are much harder to find in quantities of 1 for non-silly prices.

So the salvaged connector and ribbon cable were installed...



...and I moved on to the smashed RAM. I was amazed this chip was still in working order...



...I was tempted to glue the top back on and leave it, but the grey potting compound had crumbled away to dust and without the environmental seal I was not sure how long it would last before things started to oxidise.

Sadly it died on the operating table and literally fell apart as I started to desolder it, the only thing holding it together was the PCB it was on, even the underside of the chip was shattered.



Thankfully the board underneath was fine.

I could have dropped in any old 6116 variant RAM but this is Bubble Bobble and I like my repairs to be practically invisible once I am done. So I went through my scrap boards to find as close a match as possible.

Pretty good match?



The smashed 220uF 16v decoupling caps were replaced, and I will probably replace all the PCB stand offs with proper machined metal PCB mounts as fitting such an iconic board.

Went for a final power up test, only to find the sound would just cut out after a few seconds to a few minutes. Re-seating the other end of the ribbon cable chased that issue away. Potentially bad connections were all that was wrong with this one originally, will have to keep an eye on it before it is released back into the wild.

Actually one potential fault might have been that it wouldn't coin up, that is actually an easy one to fix. Factory fresh these PCBs were designed to use the signal from a coin counter to trigger a coin up, if you don't have a pulse coming in from a coin counter the PCB will not coin up, unless you set a jumper that doesnt exist. This board had no jumper set and it would only coin up using the service switch - odd. Original Bubble Bobble boards have two unpopulated jumper pads, marked JPA and JPB for this purpose, fitting a link on JPA enables coin-up in the normal manner.



The other board already had this done, but I think my method is neater...



One down, one to go!

PCB set 2 was undamaged by the brutality of shipping...





...but was significantly more faulty, when hooked up on the test bench all it did was this.



A close inspection of the board showed no signs of damage and the voltages were fine, but glossy TMM2016 SRAM chips...



...are not uncommon failures so I pointed the scope at its data bus pins.





The signals were a mess, this actually looks like bus contention when multiple devices are talking on the bus at once and the signals are fighting/cancelling each other out. As opposed to the data bus which shows nice transitions between logic low and logic high levels.



With boardsets that are comprised of multiple PCBs its very useful to know which board contains the fault, or faults. Simplest way to test this is to patch in a known board if you have one. So I cabled up my BB board set so my CPU board was paired with video board from the faulty set...



...by moving the power feeds...



...and ribbon cable across.



Which got me this, a hybrid working BB board set.



So the video board on this set was fine, only the CPU board had the fault(s).

So I desoldered the 2016 SRAM chip...


(desolder in process)

...and tested it in my EPROM tester - it passed the read write tests.

This is good, but its not 100% conclusive as the chip is only tested for its ability to read write, not its ability it to behave on a shared data bus in a complex system such as this. For that reason I fitted a socket and dropped in another TMM2016 from my stock. On powering up I got this, slightly different, but mostly no change...



...putting the original SRAM chip back in resulted in exactly the same again. The fault had changed very slightly and was staying changed which suggested I had annoyed something but very close to the fault.

Moving on with the scope I started to workout where the buses run and came across the 74LS245 at IC54. These are bus transceivers that control the flow of data by latching bidirectionally, either A side to B side, or B side to A side depending on the direction (DIR) pin logic level. There is also a chip enable pin that selects whether the chip is active or completely dormant on the wires. The chip was set to be active and the DIR pin was very actively switching between the two direction states. However there was only activity on the A side of the chip.



The B side was totally silent, often logic high and twitching...



...but sometimes dropping to be halfway between the two voltage levels or fading out to nothing.

So the 245 was desoldered...



... and tested on my EPROM reader.



Fitting a brand new 74LS245 and flipping the power got me this...



... the A and B side of the 245 were now highly active but the RAM chip data bus still looked borked. So I swapped out the original TMM2016 chip again (the reason I fitted the socket) with the one from my stock and flipped the switch.





One fully working Japanese version of Bubble Bobble :)

Clearly the original TMM2016 has lost the ability to behave when it is not the sole occupant on the buses and was always blasting data even when it was told to be quiet. I admit I do love board repairs where the board is left as untouched as possible by only removing parts that actually are faulty rather than re-fitting parts that checked out when removed.

The brown coat hanger that had been fitted to enable coin-up was replaced with a neat wire link and the game was given a thorough play test to confirm a full fix.

So now there are three original Bubble Bobble PCBs in the Womble house, sheer extravagance :)

11
HARDWARE/SYSTEMS DISCUSSION / Dragon 64 Repair Log
« on: May 04, 2014, 08:04:08 AM »
As part of my current drive to de-clutter and clear the decks I finally got round to looking at this beastie...



...which had been sat on the floor for well over a year, possibly two.

I bought it as faulty (my favorite feature) for a very small amount of cash for a D64 (which are pretty rare) and here it has sat. Dragon Data went bust not long after the D64 was released, so am not sure if this is a very early one, or a very late one.



I has taken me so long because the power supply it wants is weird, it expects 8.5VAC and 28VAC (yep AC) in via a 9 pin D connector on the rear.



I did look into the schematics and it seems that the 28VAC is not something I could ignore as it is used to generate the +12V and the -12V and I seem to remember this was used in the video generation circuit. On some systems you can possibly ignore the highest voltage power supply if all it is doing is providing 12V for the RS232 port.

Getting a transformer to provide these very non-standard voltages seemed extremely unlikely but something occurred to me, a transformer with taps for 30v and 9v is not hard to find. These all seem to be rated at 240V input, to get the 30V and 9V output, but if you take the input as 220V the figures shift downwards a notch and you get pretty much what this thing wants. It probably isn't that critical anyway as the voltages go straight into an internal power supply board that feeds into voltage regulators so there is almost certainly a lot of headroom, and the mains may or may not be 220V anyway as it varies somewhat.

The end result was I didn't bother, mainly because i found an original Dragon 32 PSU on eBay in the UK for a tenner and picked it up the last time I was over.



Next step - video, this only produces composite video or RF, take it or leave it, no RGB option, which is surprising really. The neatest option seemed to be to take one of those AV-micro USB leads that every camera comes with, and no one ever uses, to make up a proper lead.



Putting them all together got me this ...



...it starts off all red, then within a few seconds the green sections turn green.

I had had the lid off before...



...and  was very confident this would be a DRAM error, as it had already had one of the 8 DRAM chips replaced in the past.



This has 8 64kbit chips, each chip contributing a single bit to every single byte, so the loss of one chip will break every single byte the machine tries to deal with. The result of this will be a wedged machine as it literally cannot do anything. This is bad for faults but not bad for troubleshooting as each chip has its own data line. I was hoping that the scope would show one with no activity on its output, but all were buzzing away and looked healthy.

So I hooked up the Fluke 9010A and my 6509 pod to the CPU socket to do a full test on the buses, followed by RAM tests, expecting to see one bit per read/write stuck high or low.





The bus test passed which proved there were no stuck data, address or control lines on the system, so just to confirm the fault was still the same I hit the "Run UUT" button ...



... which uses a reference CPU in the Fluke Pod to attempt to run the board. I was expecting to get the same screen of rubbish, but ...



...it lives, the fault was a dead CPU, pretty uncommon.

The 6809 pod for the Fluke is unusual compared to other pods as the reference CPU is external, as the 6809 came in both 6809 and 6809E formats, so the pod user provides the reference CPU in a ZIF socket and some dip switches to configure it for the right type...



...dropping the reference 6809E CPU into the board socket proved there was nothing else going on and the board could live without life support.



As an end note - it turns out that the pattern I was getting initially...



...is exactly what a Dragon will put out when its CPU socket is completely...



..empty!

12
FOR SALE / WANTED / Smash TV PCB and JAMMA Adaptor for sale
« on: February 10, 2014, 12:38:30 AM »
Hi All

Am having a major sell off, the only board that is probably worth international shipping is my mint original Smash TV PCB and the JAMMA adaptor that lets you use the two joysticks on a standard 2P JAMMA cabinet to control the player 1 as it needs two sticks.

Am after AU$250 for it, which with the recent plunge in the AU$ against the pound makes it about 125 quid. Postage is likely to be between 10 and 20.

Any interest, let me know.

Cheers

David

13
ARCADE / Ms. Pac-Man Bootleg Repair Log
« on: December 18, 2013, 10:55:38 PM »
A mate of mine picked up a faulty Ms Pac-Man PCB recently as I had offered to teach him how to fix arcade boards, his wife had fallen in love with a MsPac machine when in the US so this was a worthy first repair candidate. The following repair log is written as if I did all the fixin', mainly because its too hard to work out who did what and when, but basically he did most of the soldering/desoldering and scoping, I did the steering, and buggered around with some vintage synths in the background.



Physical inspection of the board threw up a few issues, it seemed there were two chips missing based on the empty sockets...





...the amp chip had suffered some bodgery in its past...



...a resistor was snapped in two...



...and there were some signs of work around a 74LS74 which I expertly failed to photograph. It had a dodgy looking leg and there was traces of burnt flux which you can see on the photo of the entire board to the left of the side-by-side blue capacitors in the bottom right.

So with the eyeballing over it was time to power it up, which required a harness. Being a bootleg means you have to take all online pinouts with a pinch of salt until you are sure they make sense for the board you have. The official MsPac and most bootlegs follow the standard Pac-Man 44 pin pinout, but this one had a 38 pin edge connector. It iss easy to verify whether a pinout is correct enough to avoid damage by confirming where the power rails connect to, whether the 5v pins connect to the 5V legs on the ICs, and the same with ground. Once I had verified the pinouts I made up basic harness with just 5V, ground, and video outputs. to get things going. The board did nothing, absolutely stone dead, which was how it was described by the last owner.

A scoot around the board proved the voltages were correct and in the right places, the CPU reset was high, but there was no clock signal on the Z80 CPU. This was the prime suspect fault as without clock signal a CPU will do precisely nothing. But as the board was filthy I decided to give it a bath, which meant removing the ROMs, so I may as well read them while they are off the board.



The ROMs all read ok but came back as completely unknown...



but this board uses 4 27c64 chips, rather than the 8 27c32 (or 25c32) chips that a standard MsPac uses. So each of my ROM dumps contained two of the original ROMs back to back which is why they were unknown to MAME, the MAME version of this game has 8 4KB files, rather than 4 8KB files. So I split the files in to the right portions...



...and all were recognised as a known version. So the ROMs were all intact and I knew which version I had too.



Meanwhile, the board got a good scrub...



....and was left in the sun for a couple of hours to bake dry.

Next step was to investigate the empty sockets, one was a socket soldered on top of the video colour PROM, which thankfully looked intact and undamaged.



The other empty socket took some guess work, based on the only decent resolution photo of a similar bootleg board I could fine, it seemed that the socket probably should contain an 74LS02. I could have attempted to work it out from the schematics of the original board, based on the assumption that bootleggers rarely did anything clever to the circuit design so even if the board looks very different to an original it rarely is at the circuit level. I didn't have an LS02s handy so I moved on as the lack of the CPU clock was the main concern.

To track down the missing clock it always makes sense to start at the crystal itself, have met quite a few boards with dead, or missing crystals, but this board had a rough sine wave signal coming out of the crystal, which was present all the way through the downstream 74LS367 gates. The signal does snake through this chips individual gates with the output of one being fed back into another on the same chip so I resorted to the schematic for the official PCB at this point to sanity check what I was seeing. If it was a complete match I knew I could probably rely on the schematics for the rest of the board, if it wasn't a match I would have to draw it out on paper and see if it made sense. In this case it was a direct match. This next bit gets hard to describe without the relevant section of schematic itself, so here it is with some colour coding I have added.



The big chip on the right is the Z80 and the input pin at top left marked yellow is the clock input pin. This connects to the striped diagram bus, which has absolutely no relevance to the PCB itself, it is purely an aid to drawing the schematic to keep them readable. The signal coming off this diagram bus is marked 1H, so you have to follow the diagram bus until you find where the signal 1H joins it, which I have also marked in yellow. I have labelled the crystal and all the individual gates on the LS368 chip too as they form the majority of the first stage clock system. The green dots are where I could see a healthy clock signal, which was on all gates except for the gate that feeds the Z80 clock chip, which I have marked in red. It had no input, so I had no output on this gate which is fine, except the input should be the opposite of the output and both were low, if the input is low then the output of this gate should be high.

The lack of input  to this gate suggested the issue was the sourer of the 1H signal, which was the Q output on the manky looking 74LS74 chip that the schematic says is at location 8C. As this was a bootleg PCB the location IDs on the schematic are meaningless, but the circuit was identically connected up for everything I was looking at. The fact both input and output were low on this 367 gate suggested either the clock input pin on the Z80 was stuck low tying the gate output low, or the 368 gate was bad, or the pullup resistor on the CPU clock line (marked with blue dot) was bad, or shorted. This resistor should have been a 220 Ohm but it measured 32 Ohms on the board. The Z80 was easy to rule out, putting it in another Z80 based board proved it was fine, also when the Z80 was removed from the PCB the clock line was not released which it would be if the Z80 was cause of the short. This left the pull up resistor itself. Without a pull-up somewhere on a line it will never reach logic high. The resistor is there to pull a line to 5V, to a logic "high", but you can't connect it directly to the 5V on the PSU as the PSU will accept this as a challenge and happily deliver 5 Amps into the line until the weakest part of the circuit nominates itself as the fuse and vapourises. So the pull up is a current limiting resistor that safely gets a line to logic high without allowing too much current to drain through the path. Once you have the logic high, a TTL gate can connect it to ground to create a logic low as required. Once the connection to ground is released the line will spring back to logic high. A logic high is effectively the default condition in  standard TTL so you need pullups in a lot of places. Some chips have internal pull ups, 74LS368s do not, so the output needed that pull up to achieve the correct logic high that it should have when the gate input is both low, and the chip enable pin (tied to ground by the board) is low, i.e. chip enabled.
 
Some poking around brought me back to the prime suspect, the 74LS74 (which is a dual flip flop, both of which I have marked orange o, its SET inputs (marked PRE) also require a pull up, and they share the exact same pullup resistor. So if the 74LS74 was shorted internally it would negate this pullup, shut down the clock output and kill the clock input line to the Z80 in one hit. It wasn't conclusive but as the 74LS74 was a bit mangled looking it was the main suspect, so it was removed.



Once the solder was removed the state of the chip became clear...



...someone else had been here before.

With the bad 74LS74 off the board the pullup resistor now read 220Ohms again proving the theory, the chip was shorted internally. A new 74LS74 soldered in its place the clock system lit up end to end and the board made its first attempt to boot giving a screen covered with flickering lines and in an awesome fluke, a trio of superimposed MsPacs





Eventually the flickering lines would cease and the MsPacs would remain frozen on screen until I rebooted.



It would do this consistently, only when a spare 74LS02 was installed in the other socket would it start the correct boot process, starting with the crosshatch and progressing to the RAM tests..



These would get to a certain point and the board would and lock up solid needing a power cycle to try again. It would do this over and over again, but on one rare occasion the board dispensed with the RAM tests and actually started to run the game the instant the power was applied. Appart from some flickering bands of colour striped corruption and violent flickering that the camera didn't really capture...



The board seemed to be running happily, MsPac would drift into the left corner, eat the power pill and sit there until the ghosts came calling. Which is what the board should do with no control inputs. However on power down it was back to the usual behavior of going through the RAM tests and crashing. At this point I fixed the snapped resistor but it changed nothing, I didn't think it would. I managed to get it to jump into the game one more time but it took about thirty power cycles and seems to be a pure fluke.

As it was jamming mid-way through the RAM tests the most likely candidate for this actually was the RAM. Looking at the MAME driver this board has a whopping 3KB of RAM laid out in the Z80 address space as follows.

4000-43ff Video RAM      1KB
4400-47ff Color RAM      1KB
4c00-4fff System RAM      1KB

So I decided to fire up the Fluke to have a good poke around, and for some reason to take no photos of the event at all. With the Fluke and a Z80 pod I could could run in-depth tests each of the 1K blocks in turn, the system RAM and video RAM were fine, but the colour RAM gave read write errors.

Each of the 1KB blocks is provided by 2 2114 chips each providing 4 bits of each byte, with their /CS pins tied  together so they can be selected as a pair.



The six chips are therefore divided into 3 pairs, and according to some online doco the colour chips on an original Ms Pac are ICs 4L and 4P, which are controlled by the output pin 11 on a 74LS139 at 5L. So fishing around for the nearest 74LS139 on the board I found one which had an output pin 11 that was tied to the /CS on the upper most pair of 2114s in the stack of 6 - result!

As each chip contributes 4 bits to the byte I could work out which of the colour RAM pair was bad by jamming the data outputs with a metal probe while reading from at a single location in that 1KB with the Fluke. I programmed in FF (which is all bits in the byte set high, or 1111 in one chip, and 1111 in the other, or 255 in decimal) into a byte location within the colour RAM range, then read it back. The main fault exhibited itself by the fact the second F in the FF byte I read back was constantly flickering on the Fluke as the bad chip kept thrashing around and changing its mind about what it held. I could therefore poke each chip and see which one annoyed the stable first F, this was the good one, so the one that was the cause of the fault was the other one, which was the second one down in the stack.



Desoldered it...



Fitted a new one ...



and fired it up.

The game now progressed all the way through the health checks and booted to the game every time.





Next step was sound, the original amp chip looked knackered but I added the wires in the harness to give 12V and connect the speaker and powered up the board - silence, no hiss, power-on pop or crackle on adjusting the volume. This was not unexpected as the amp chip had all sorts of weird work done on it, some legs were pulled clean out of the board, there were capacitors with only one leg connected and the ominous completely missing pin.

I tracked back the audio to the output section of the board, which was on completely the other side of the board and injected the signal from there into an external amplifier and got the sounds of a healthy MsPac game coming through. So the board was making sound, it just was missing a working amp.

The simplest first thing to try was to rebuilt it as it probably once was, so the amp chip was desoldered, tidied up, refitted and an attempt made to make a connection to the remains of the missing pin....



...by filing down enough of the plastic case to get to the metal stump to solder to...



...again this produced silence.  The weird thing about this amp section is that according to the data sheet the capacitors that look original are the wrong rating, majorly wrong. It expects 47uF and 100uF support capacitors, yet the ones on board were all 6.8uF. The datasheet did potentially explain why the amp had been buggered about with so much. The chip on board is the WR variant which has the pinout reversed from a normal HA1366 chip, so possibly someone was troubleshooting this with the pinouts for the more normal amp chip and was pulling legs to try and connect things as they thought they should be connected, and snapping off pin 8 (or pin 3 as they though) in the process.

I replaced the capacitors on board with the correct rating support caps the datasheet specifies...



and the amp started to show some signs of life, by getting slightly warm on power on. The loooong legs on the caps in the above photo was because I really thought they would only be required long enough to confirm the amp chip was knackered. The total silence was tracked down to a break in the audio output pin track, when buzzing through I must have been a fraction of a mm out with the probe and it buzzed through as connected when it wasn't. Fixing this up restored the sound but it was quite distorted at times so I was not confident the amp was in good health.

This PCB was actually quite well designed considering it is a bootleg, the amplifier section can take either the HA1366WR chip or the more common MB3712 chip, each with their own set of leg holes. There was also through holes to provide each option with its own support capacitors. So I picked up some NOS MB3712 on the forum (thanks for that RocK-Ozla) and re built the amp section up for that chip option. This fixed the sound up beautifully, all distortion gone.



The final part of the repair was to fit the control lines to the harness and give this board a play test for the first time in probably many many years, decades perhaps. Once these were fitted the board was transferred to my JAMMA cabinet for some uncomfortable play on my horizontal screen. The penultimate fault became clear here, the display was majorly affected by the audio, the screen geometry would wobble when the board was coined up and shimmer majorly during any music. The only logical cause for this was the old axial capacitors on the 12V power rail input and the audio output. These were replaced ( as can be seen in the previous photo ) and another nice feature of the board became evident, the board has through holes for both axial and radial caps in these locations so this could be done very neatly.

At this stage the game was considered fixed and my mate carried it off to install in his newly acquired (for this game) vertical cabinet, I expect that would be the end of it but the final fault raised its head. The game powered up ok in his cabinet, but the screen blacks were grey and fuzzy, it would temporarily lose sync on coin up and when a game was started the screen would really struggle to hold sync and most bizarre of all the game would start to slow down, the audio would drop in tone, break up and the game would then crash and reset. The cab wiring and monitor had been proven with a Raiden DX PCB some days before so the only logical option was either a voltage issue or a grounding one. So I headed over with a multimeter and a point to point probe I made up some years ago, basically just a length of wire with a spiked probe on each end. The voltages checked out fine, which left grounding as the only logical cause, and it was. The PCB has a ground plane on both sides of the board but it doesn't join them together anywhere itself. It expects the cabinet wiring to do so, which it didn't, and neither did the harness, so the board had two grounds that were floating with respect to each other, so no surprise crazy stuff was going on. My test bench wiring uses very chunky ampy wires on the power and ground feed which are so fat it connects to 4 JAMMA pins in one joint which explains why it worked fine on my bench and in my cab. By joining the upper and lower ground planes together with my spike probes while the game was running the screen would snap to attention, the blacks would instantly flick to full black, the game would coin up and run perfectly. All it took was for an small addition of solder to the harness to join a solder-side ground pin to a parts-side ground pin and the fault was cured.

Game fixed, would love to know when this one last worked, could be twenty years ago I guess.




14
ARCADE / Sega Shinobi (System 16A) Double Repair Log
« on: December 01, 2013, 10:50:23 PM »
Hi folks, it's been a while but finally got round to polishing this one off.

Apologies in advance - this one is a monster, have had to split over three posts to avoid the 20,000 character limit  :o

I advise you to make tea before attemping this one....

At some point way back in 2011 I picked up a dead Shinobi board on eBay, according to my notes the seller said it had worked until recently, but then developed graphics issues. However when hooked up to my test bench via a System 16 - JAMMA harness it was completely dead, no video, no sound, no life. A quick scoot around with the scope showed that the lower board was completely powered off. Despite the 3 50 way ribbon cable interconnects between the boards the power supply to this lower board is via an external connector which through a combination of broken connector latches and badly re-soldered joints on both boards was no longer connecting the two PCBs





Someone had re-soldered this at some point but hadn't pressed the connector back hard up against the board and made a hash of the soldering, so the bad joints just broke again leaving the connector loose. A complete desolder and a proper re-solder on both boards fixed the issue. Even with the broken latches it can be fully engaged, its just a bit more of a faff.

The old faults as described by the seller were back, slight corruption on the title screen giving a blocky pattern around the ninja's neck...



... corruption on the building frontages, a Fisher Price colour scheme, plus a nice snow effect on the ground...





...and the bonus stage was almost completely red - nice!



Also when the main character was on the upper level of the 1st stage and jumped, all the foregrounds vanished until he landed again. Basically the background was drawn infront of the foreground and some of the sprites.



First thing to fix was the obvious damage, a number of decoupling caps had taken a beating and had legs wrenched out...



... or were completely missing, torn off the board.



Replacing those had no effect but they are there to increase the power stability of the board and if too many are missing or damaged it can make the board glitchy.

The board was pretty heavily populated with Fujitsu TTLs, and a load of 74LS157s which always seem to be the flakiest ones, so I went round them all with the logic probe looking for floating outputs. All of the above faults above, with the exception of the jumping background fault were caused by a single bad 74LS157 at IC40 which was sporting a number of missing outputs. It got desoldered...



... and replaced, which fixed up the graphics nicely.





The jumping background fault that still remained was one of those problem faults that are highly specific and only happen at certain times, which makes them very hard to find as most of the time the board is doing the right thing, and when it is doing the wrong thing it is fairly minor. Also the problem with dual PCB board sets is you always have the nagging suspicion that the board you are working on isn't where the fault lies, so you end up constantly flipping the board set over and never really getting anywhere. I went over both boards but found nothing obvious, half the issue was this effect only occurred for about 3 seconds every minute so I really needed another board set to narrow down which PCB contained this fault or I would be wasting hours watching the attract mode loop trying to catch the fault.

As it happened I did have another System 16A Shinobi board set that once belonged to "Leftjumpleft1P" in my scrap pile. Judging by the aborted repair log I had on it the PCB has been here since at least March 2010, it came in a parcel of faulty boards, some I was able to fix, others were wrecks. I had pretty much written this one off as a complete basket-case but it had never fitted in any of the parcels I sent back to him, so it had remained here in a corner.

Even though ideally I needed a complete working set to completely fix my PCB, what I actually had was my almost perfect Shinobi set which I could use to divide and hopefully conquer the basket case set. If I was able to get the other CPU board working I would see whether I still had the mysterious jumping background fault when paired with my video board. If I did then the fault was likely to be on my video board, and if the fault was gone then it would suggest it was my CPU board that held the fault.

I probably should not use the terms CPU and Video board, which are used so often for dual PCB sets, as they don't really apply to Sega System16A systems. A lot of the video processing happens on what is referred to as the CPU board and the CPU subsystem is not complete without the video board.

So I hooked my probably 99% OK video board to the other CPU board and fired it up. I got a black screen and the constant clicking in the speaker which is the watchdog system trying endlessly to get the board to boot. This was exactly what it was doing 2 years ago when Jump1Left sent it to me. The repair log I started was just a text file full of locations of suspect chips and notes that large sections of the CPU board were stone dead, along with a long list of damage to the video board. This board set had clearly seen some real violence it its past, probably someone plugging it in to a JAMMA harness and leaving it to fry.

When I originally received it the board had a standard 68000 CPU on it, but the ROMs were the original ones containing the encrypted code for the missing FD109 encrypted CPU block. I had burnt the unencrypted set for the board when it arrived so that was no longer an issue. I went back over the CPU board with the logic comparator and had tested all the Fujitsu TTLs present, only finding one bad 74ls30 at IC56 and a dodgy looking 74ls244 at IC33 using the scope. The problem was still that so much of the board was shut down that a large number of chips had no active input signals, so the chance of false negatives was high.

Now I at least knew the fault was somewhere on this CPU board so I pretty much started from the beginning.

The decoupling cap that had been torn off at C27...



...was replaced with a new 470uF 16V, it had minimal chance of causing the boot issue but again it is there for board stability.

Going over the board again with the comparator I found the 74LS161s at IC51 and IC63 had floating outputs so these were replaced with salvaged chips...



...I thought I had found a broken track under IC63, but there was no break, just oxidation under the lacquer. I scraped it back to the copper and put some fresh lacquer on the area before the new chip went in. None of this had any effect on the board's failure to boot. Also the four LS253s that take the control inputs from the edge connector were all flagged as bad but these would not cause the inability to boot so I ignored them and moved on.

Faced with an uphill battle I decided to wheel out the big gun, the Fluke 9010 and the 68000 Pod.



The Bus Test function gave me the following fault...



...which translates to the fact that the /HALT line and the /RESET line were causing problems. Poking round these areas of the board with the scope gave no clues so I told it to ignore all the errors and carry on. To my surprise it booted!



It doesn't look like much but the large yellow bar was flashing, and after a few seconds it changed to this...



...which looks worse, and then this...



... and then it repeated, this is actually the attract mode running. The flashing bar is the flashing "Insert Coin" area of the screen and the final image above is actually the wreckage of the high score table.

It is missing most of the actual data it is supposed to be displaying and the colours are missing blue but it was successfully running the program code.

When I disconnected the Fluke and put the old 68000 CPU back on the board it continued to do the same, happily running attract mode, very odd. Until the next day when it was back to the black screen and constant watchdog resetting. The culprit for all of this was the CPU socket. It's a machined pin socket so it should be bullet proof, but whether through dirt or oxidisation the CPU was not making good contact on all its pins. So I cleaned the CPU pins, bent them outwards slightly and reseated the CPU a final time to chase the fault away. The missing blue seems to come and go and wasn't a bad connection on the edge connector.



Clearly the board is very unwell but as a lot of it was running I could rule out a lot of the board and focus on the bits that were still doing very little. By pulling ROMs I was hoping to find areas where the loss of a ROM didn't introduce any new faults, or crash the board, and he fault remained unchanged when the three ROMs at IC93/94/95 were removed.



Pulling these ROMs on the working CPU board caused the background graphics to be missing so I figured I was in the right area. One obvious fault in that area was that of the pair of 2016 SRAMs at IC96 and IC97...



... the output pins on IC96 were a mess on the scope, almost like a city skyline, a classic sign of bus contention when more than one chip is talking on the bus at once and the signals are fighting each other. This chip did pass the off board tests in the EPROM reader but clearly it cannot operate on a shared bus as when I put a known good SRAM chip in its place I got this...





...background data, the board was slowly waking up.

Further poking around revealed that the collection of LS153s...



...nearby had a fair number of floating input pins. The silent inputs all traced back to a 74LS174 at IC102, pins 10, 12 and 15 outputs were all floating....



...oddly enough, so were the inputs to those gates, which went to outputs on a second 74LS174 at IC103.

These outputs were fed by inputs that again were floating, which were fed by outputs of other gates on the same chip, again floating outputs. After hoping through 3 gates I got back to the first input to the 174s and found a healthy signal. Both 74LS174s were completely shot, and had died in the Fujitsu way, despite being SGS brand. Which explained why I hadn't found them with the logic comparator beforehand as I usually only bother the brute force method with Fujitsu chips due to the way they tend to fail.

Once these two were replaced...



... I had foreground text and sprites...







...even if the colours were still pretty unwell.

At this stage I knew I wasn't missing a colour channel on the output as I had white sections of graphics and to get white you need Red, Green and Blue channels to be working. So I focused on what I was assuming was the final stage of the video assembly in the bottom right corner of the CPU board.

I poked the scope at the Fujitsu 74LS125 at IC77



and its outputs looked fairly mangled so I dug up a spare on a scrap board to test the one at IC77 and it came back as having timing issues so the spare got soldered onto the board.



Nothing improved so I moved on, the original one may not have been an issue anyway but its a Fujitsu so I am never too bothered about retiring one prematurely.

At this stage I decided to put the board into test mode to see what it could tell me now I had video output and working text. The problem was that the service mode button did not work, the game would also not coin up so I couldn't even start a game for a play test. This was all down to the four Fujitsu 74LS253s lined up along the width of the the board by the edge connector, ICs 5,6,7 and 8. Replacing those brought back the ability for the board to register buttons and switch inputs.

Once into test mode I stepped through the tests and got the following report...



... which is a bit bizarre as IC90 is not a RAM chip at all, its a 74HC273. The SRAM chips are IC96 and 97 so unless that is a rather stylised "6" it is a typo in the main code. Either way, IC97 is a SRAM chip and it was reported as bad. This is the remaining chip from the pair that I replaced one of earlier, so I removed it and dropped it a known good one - no change. Its outputs looked fine on the scope but I noticed I could short out the data bus pins on that chip and have no effect at all on the screen. The address bus is shared so any shorts there caused the screen to go nuts. Clearly the data was leaving the chip, and presumably arriving too, so the egress path from this area to the downstream colour processing was not working correctly. As is fairly common on data buses there was a paired HC273 IC90 and an LS245 at IC98.



The 273 was an NEC chip while the 245 was a Fujitsu, guess which was the prime suspect?



The Fuj!

I actually replaced both IC98 and IC101 as they are a matched pair and often seem to be damaged as a pair too. The result was this...





Assuming it was finally fixed I hooked it up for a test play in my cab, the dip switches had always been set so attract mode sound was off so this was the first time I had heard it and it wasn't good. The sounds were horribly distorted, very over-driven and clipped, everything was present but everything was loud and mangled. I have met this fault a few times on boards and after checking the caps in the amp section you are really only left with two options, the main amp chip, or most likely the op-amp chip (often a dual or a quad op-amp) just upstream. It is usually actually the op-amp or in this case a pair of quad op-amp TL084s at IC2 and IC3.



I have had limited success pulling op-amps off scrap boards as often they are in bad shape too. Luckily op-amps are one of the few chips that are still commonly used today and therefore one of the few useful chips for arcade repair that Jaycar still sell, for the princely sum of $2.45 each. I could have got ten for that price if I was prepared to wait, but I only needed two and needed them now. So in went some sockets and the two new chips.



The sockets were mainly because I wanted to check if both the original chips were bad, the new pair was always going to be used as a pair but if one of the originals was OK I would have kept it. As it turned out both originals were bad so both were binned.

So finally I had two Shinobi CPU boards in apparent working order, the vanishing foreground issue when the sprite jumps was evident with both boards when paired with my video board, so it is highly likely that that fault lies on the video board, otherwise both CPU boards would have to have the exact same fault - pretty unlikely. So I could be fairly sure I had two perfect CPU boards, and of the video boards, one had a minor fault, and one still had major issues.

15
ARCADE / Arcade Schematics - Recent Find!
« on: September 17, 2013, 02:06:51 AM »
Some gems in here - previously unknowns like Operation Thunderbolt!!

Grab them while they are hot, these sites have a habit of vanishing, especially when their archive folders suddenly generate a load of traffic!

http://antelopearcade.com/files/?dir...e%20Schematics

Pages: [1] 2 3 ... 12