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.


Messages - Womble

Pages: [1] 2 3 ... 80
1
HARDWARE/SYSTEMS DISCUSSION / Re: Oric 1 power supply output
« on: January 07, 2019, 05:11:15 AM »
That's normal for linear power supplies when you are measuring without any load connected. When the Oric is connected it will drag the voltage down to around 9V, even then it isn't critical as it goes straight into a voltage regulator that converts it to 5V and dumps the rest of the energy as heat.

I'd take a look at the solder joints on the power input jack, they have often cracked over the years so the slightest movement can cause issues.

2
COLLECTORS CORNER / Re: Womble's Collection
« on: June 08, 2018, 01:20:35 AM »
De-cluttering episode 3 - more machines released back into the wild.

Sony HitBit 75A MSX
Amiga A600
Atari 130XE
Acorn A5000
Acorn RISC PC610

Am basically  now back to only Speccies, Atari STs and an A3000. Only 2 exceptions, a C64 (hanging on by the skin of it's teeth) and the Falcon.

3
GENERAL RETRO CHIT CHAT / Re: Amiga 500 revelation
« on: December 07, 2017, 03:13:13 AM »
Depends if the board is fully populated, if it is then the board will have 1MB onboard, and a real time clock (and a time bomb battery).

I guess is this is true then the board would have those areas unpopulated, 512KB was too expensive to give away at the time.

4
COLLECTORS CORNER / Re: Womble's Collection
« on: November 27, 2017, 08:46:47 PM »
Wow! You let all of those go? :(

Yes, it was getting out of hand, it's good to clear the decks. It got to the point where the room was a total bomb site.

Am down to just 2 vintage synths too :)

5
COLLECTORS CORNER / Re: Womble's Collection
« on: November 13, 2017, 02:26:35 AM »
Another big clear out, gotta love the 100% fee free weeks Ebay often has.

Am slowly collapsing the collection back to machines I actually have some connection to, which will likely be just the Speccy,  Atari ST, and the Acorn, with an honorary inclusion of a C64 and an A600 for good measure. The rest can go.

Out the door this time around.

Sinclair QL
Oric 1
Oric Atmos
Yamaha C5M MSX
Amiga A500
Amiga A1200
Enterprise 64
Acorn A3010
Acorn A3020
Acorn RISC PC

6
ARCADE / Re: Another Namco Pacland Repair Log
« on: January 06, 2016, 11:57:46 PM »
I should have realized your reply would have been as detailed as your repair logs. Thank you. Have some more kudos.

Would you have documented a Vindicator bonfire as well everything else? glad you didn't.

Hehe, yes I type too much I think. The bonfire would have remained undocumented, the restoration thread would have just languished forever. I have many repair attempts that went nowhere, where the board was too far gone or just put up too much of a fight to be viable. I keep the notes for the next time I meet the same board but they never see the light of day. They wouldn't make good readin'

but............................................   why............... to what end

Coz I enjoy it, same for playing with anything that features on this site, it is all pretty pointless when viewed from afar.  :D

Plus I release the boards back into the wild from time to time, people still pay fairly decent money for some original PCBs

7
ARCADE / Re: Another Namco Pacland Repair Log
« on: January 06, 2016, 10:45:12 AM »
It really depends on the board I'm afraid, this one was probably 5 hours all up at a guess. Working out the ROM paging system slowed it down a bit, and I probably didn't actually need to do that anyway. It would be a lot faster if I just bulk replaced the Fujitsu TTLs rather than work through them logically. As they are almost certain to be faulty already and a major risk to the future stability of the board they all need to go.

Some of the more involved repairs could probably push north of ten hours, it really depends how many clues the board gives and whether there is a path to follow or many dead ends. The Vindicators restoration is at the other end of the scale, the PCB repair for that was probably 4 hours all up due to the detective work and harness. The cabinet work would easily be 250 hours all up, possibly more. After the 3 year break I forced myself to devote all spare time until it was done, that or take it out the back and set fire to it Even then it took many months.

The write ups probably take an hour or two, I make very quick notes as I work on a board as very few of them are fixed in one session. Once the board is fixed I slot the photos into the notes and then re-write it properly.

The recent crop of repair logs is really just me getting round to finishing writing them up. I fixed Shinobi at the end of November but hadn't got round to the bit where I replaced the battery, so the write up was delayed. The first Pacland was around then too, and this one was a few weeks ago. I actually have a third Pacland that was a complete basket case and is now back running with the exception of a minor issue with the sprites that I still need to nail down.

I have no major projects in the offing, a few boards on the to-do pile still. Had been fighting with a Toki PCB in the last few days, have decided it is a write off, the video system is totally shot.

Next big cabinet restore should probably be the Paperboy I have, its in far better shape than Vindicators was, but it could use some TLC, there is also an empty Taito cab in the corner that was a Defender originally, not sure what I will do with that yet.

8
ARCADE / Re: Another Namco Pacland Repair Log
« on: January 05, 2016, 09:57:18 AM »
From the schematics its hard to see how the LS257 at 5J would cause the RAM failure codes in the main stack, as at this point I was getting errors of 2 0 0, 4 0 0  and 5 0 0 throughout the troubleshooting which relate to RAM 2, 4 and 5. I can only assume the LS257 hadn't died as cleanly as most Fujitsu TTLs do and that it was pumping junk data rather than disconnecting itself neatly from all its pins and going silent.

My comparator agreed it was not healthy...



... and as both were Fujitsu I desoldered them as a pair, 4J tested OK, but 5J failed, both were retired to the bin.



Swapping in two working ones fixed the board...



... at which point it gave the all clear signal of 0 0 0...



...and the game started up perfectly.



It was still a bit prone to crash at this point when the board was touched, so decided it was time to replace the remaining 5 piggybacked ICs I had left dotted about the board.It's not a good solution for stability, as I had upwards of 70 pins pressed against tarnished old pins using only their springiness for pressure, plus what remnants of the internals of the faulty chips would be still connected to the lines. With those all  desoldered and replaced the board was rock solid finally.

And in the naughty corner for this repair are....



... I suppose it would be quicker to just bulk replace Fujitsu TTLs on these boards, which I would if I was in a hurry but it is kinda fun to see it come back to life in stages. For boards I release back into the wild I will replace any remaining Fujitsu on them, on most boards it isn't necessary but these ones seem particularly prone to Fuji rot.

9
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.


10
ARCADE / Re: Sega Shinobi Repair Log
« on: January 04, 2016, 03:10:22 AM »
Thanks Juggler, there are a few more coming, have knocked over a few more fixes recently that are yet to get written up.

11
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.

12
ARCADE / Re: That other Terraforce PCB I mentioned
« on: December 16, 2015, 12:12:42 AM »
And now with a new GAL burnt using the file from Porchy's site the board is fixed and complete again.

 :)

13
ARCADE / Re: Terraforce Repair Log
« on: December 14, 2015, 11:45:26 AM »
Also, make sure you aren't programming the security bit or it can't verify.
May sound obvious but it does happen.
Failing that then I agree your programmer may just not like them

Hmm, you did make me wonder if that's where I had been going wrong, so I tried again tonight and made sure to deselect the security option, and it worked, and the programmed GAL also worked in the board. So I tried the operation again with the security bit set in the programming run, and it also worked. It does the write verify stage before applying the security so that couldn't be the reason it failed before. So something odd is going on, I am fairly sure I was using Lattice GAL16V8A ICs before when it was failing, but I can't be 100% sure now. I have a tray full of GALs and the burner claims to support a variety of types that I do have, but perhaps I hadn't used that exact make.

I have run off 3 working GALs now so I am a bit stumped as to what the issue was before. I'll have to try again after a system reboot, but as I can't guarantee getting back to this point again I ran off a copy of the video board GAL you have up in your archive to test that, so I can confirm that both files you have up for the bootleg board work perfectly on an original TerraForce PCB.

Your archive is a god send by the way, if the burner is now behaving and it is simply an issue of it having dodgy support for some GAL ICs then I should be able to verify a couple of untested ones you have there for other boards in the collection.

14
ARCADE / Re: Terraforce Repair Log
« on: December 14, 2015, 03:23:20 AM »
I was yes, but the burner kept giving me errors at the verify stage, am pretty sure the software is buggy for GALs, have tried a number of versions but the either always fail, or they crash entirely. Have tried a number of GAL chips too, so all I am left with is a fault with the burner or its application, sadly its long out of support.

15
ARCADE / Re: That other Terraforce PCB I mentioned
« on: December 12, 2015, 10:09:42 AM »
If the board was reset and I tried "Run UUT" again, it would usually refused to start multiple times and then would leap back into action on the 5th, 6th or 7th attempt. Once the board was running it would stay running until powered off, so I suspect there was something causing it to fail the boot up RAM/ROM tests most of the time, at which point the program is set to just halt. If whatever causes that halt doesn't trigger it, then the board will run happily for extended periods of time - a useful clue.

Poking around with the scope I started at the colour RAMs, since I had colour issues and the address space for the colour SRAMs is right next to the address space used by the CPU. Schematics here would be really useful but none seem to exist. The colour SRAMs were the known to be problematic TMM2015 chips and pin 3 (Address line 5)  was not behaving correctly, it was very weak, and spent a lot of time stuck high. This tracks to the pin 16 on the LS244 at H10 (which is the output for input on pin 4 which had a strong and normal looking signal) and also pin 17 on the 47LS374 which is the data input for flip flop 7 out of 8 on the chip.

By shorting pin 4 and pin 5 on the SRAM I was able to copy the data signal from pin 4 to pin 3, which annoyed the colour fault, the sea turned blue again and the ship on attract mode flipped back to silver. The data would clearly be wrong on A5 but some signal tells me more about the issue than a quiet line.

At that point I turned it all off, intending to take photos of the effect later, when I got back to it a couple of days later the board would no longer run at all, the best I could get out of it with the Fluke trying to Run UUT was the "RAM NG" message, but even then only on about 1 in 20 attempts.



I was fairly confident that something was interfering with that address line and causing the board's self test to fail, or the board to crash before it failed. Candidates were either one of the RAM ICs, or the 74LS244 at H10 (if it had lost the strength to pull the line low) or alternatively the input pin on the 74LS374 at H11 (if it was somehow tying the line high).



The fact I could inject rubbish onto the SRAM at that pin and get a response suggested it wasn't the RAM, the board can actually run quite happily with neither of the colour SRAMs on the board, so I knew they themselves were not causing the RAM test to fail, the issue was that something was interfering with the board's ability to test the 6264 RAMs that the CPU uses. It also suggested that the incorrect address line was being weakly driven, as a normal siganl could overcome it, which pointed to the 74LS244 at H10. So I desoldered that and tested it off the board, it passed.



The next on the list of likely candidates were the SRAM chips themselves, so I desoldered them and tested those, both passed off-board tests. This just left the 74LS374 At H11, which also passed off board tests.



So with all four ICs off the board...



...I decided to fire it up and see what it did. I knew the board would no longer output any video but I was expecting the board would be more active if the mysterious handbrake had been removed. Signs of life would be visible as activity on the buses with the scope, or sound effects if the board was now running.

On power up I got a black screen with the odd flash of colour at the very top, and then the theme tune started playing, accompanied by sound effects, which played through, went silent and then looped. This was the board running through attract mode normally. With a 68000 CPU on the board it would now run every single time I powered it up.

This proved that one of the 4 ICs I removed was the cause of the fault, but it was faulty in a way that the off board tests did not detect, either pull up ability, line driving ability or ability to run at speed, it's hard to tell. To rule out the SRAM I put them in the 1st PCB set and it ran fine, which left the one of both of the TTL ICs as culprits.

With the RAMs back on the board, and without the 74LS244 and the 74LS374...



... the game was clearly running.





Unable to prove conclusively which of the 244 or 374 was faulty I just replaced them both ...



...and the graphics system lit back up and the board was stable again, but all the original faults that were visible back when the Fluke could get the board to run were still there.





The attract mode was missing large portions of the graphics, the text was still in the background and some of the colours were still wrong, namely the ship and some of the objects in the background plane.

The most obvious was the lack of the scrolling foreground and all the missing character plane text.. I'd already run the EPROMs from this board through the tester when I was reading the set from the other PCB, all had passed except ROM 4 which showed up as totally shot. As it was not a critical ROM I had not bothered to replace it, leaving the socket empty, especially as there was obvious track damage under the socket anyway.



After dropping in ROM 4 I got a lattice of graphics fragments over the entire screen that that scrolled continuously downwards during the game-play sections of attract mode.



Poking around ROMs 4 and 4 with the scope showed that the /CE and /OE were common on each ROM, but not between them. All address lines and data lines looked busy but the /CE and /OE were permanently high on ROM5 and permanently low on ROM4, so ROM 4 chip was always active and ROM 5 was always shutdown. These lines tracked back to pins 4 and 5 on the 74LS138 at C9...



... and are outputs 1Y0 and 1Y1 on the first decoder of the pair, with pins 1,2 and 3 as the inputs. Pins 1 and 3 were tied together and to ground by the board and pin 2 was always low, but not a firm low, it wandered about a bit. With the pins 1 and 3 tied to ground it was clear that pin 2 had to be doing something otherwise the chip would be totally useless, and it was clearly not connected to what it should be. Sweeping across the working board I found that pin 2 should connect to pin 16 on the 74LS273 at H1, but on the faulty board it didn't. I could follow the path of the trace by eye across the board on both sides, and there is a very small area of track rot between the two ROMs, in much the same place as the previous broken track.





When those two pins were re-joined with some hookup wire, the cage effect vanished and was replaced by the scrolling rock clouds again.



At this point I decided to focus on the nasty looking tracks under ROM 4 and see what was actually disconnected...



... rather than approaching it from the symptoms backwards. Most tracks were actually OK but one track between pin 17 of the 74LS374 I replaced earlier and H11 this is the input pin for the gate whose output goes to A3, I had missed the inactivity earlier. Once that was joined up...



... all the previous colour faults...







...vanished









The game was getting pretty close to being perfect, all I was missing now was the text overlay (score, game over etc), and also the actual game title itself. I knew this was probably just another graphics plane issue as I could see the text actually hiding behind the background sometimes.



From PCB#1 I knew that all that lived in ROM 9 and even though ROM 9 was being drive correctly as far as I could tell with the scope, underneath the socket were some more nasty looking tracks and a totally corroded out via...





...this actually has nothing to do with ROM 9, it is just a track passing through the area. With the working board I quickly buzzed through to find that the via was part of a track that connected pin 5 of the PAL at J11 in the screen plane assembly area to pin 10 on the 74LS174 at F13, on this board there was no connection between those two points.

I tracked down which section the break was in by hoping from via to via and bridged the gap with another wire link on the back of the board...



... the text and the game title on the splash screen popped back out in front.





Game fixed, or so I thought, but while play testing in my cabinet I noticed some small graphics artifacts in the side scrolling level foreground elements, the stalactites were often just blocks at their tips...



...and areas of the wrecked buildings were more mangled than they should be.



As this was a very slight issue, affecting only a small section of the graphics and was a foreground issue in both cases this looked like an upper address line issue on either ROM 4 or 5. With the multi-meter I quickly found that pin 23 (A11) was not connected between the two ROMs, so ROM 4 had no signal on address line 11 leaving it floating.



When these were joined with another small length of hookup wire...



... the final issue vanished.





Board fixed, now I just need a way to clone the single PAL I have between the two boards.

Pages: [1] 2 3 ... 80