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