Wardner (Bootleg) Repair Logs

From Arcade Otaku Wiki
Revision as of 03:53, 25 October 2016 by Asayuki (talk | contribs) (Typo)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Repairer: Asayuki

Date: 25/Oct/2016

Symptom: Locks up at boot with a "CRAM ERROR" message

This bootleg seemed to suffer from one of the most common issues in the world of arcades: bad RAM. The seller told me this board was broken and displayed a RAM error message, and yet the price wasn't as nice as a broken bootleg can be. This is not a game one finds for sale so easily, therefore I accepted the price and purchased it. There it is, before even turning it on.

An overview of the board just before the repair.

When I connected it to the monitor on the examination desk, I could just confirm what the seller said: the message "CRAM ERROR" was the only visible thing on the screen, written in scary red letters.

It must be an easy fix, right?

As the message was appearing consistently at every boot, I trusted it and went on searching for the chip to replace hoping in an easy fix. Sure, there was only one problem...

This photo shows what's under the bootleg patch boards. It looks almost identical to the real thing.

25 RAM chips scattered all over the place, including under the patch boards, and of course no help whatsoever from the internet! Good luck finding the right one! MAME documents this hardware in a still incomplete way, and unfortunately does not mention what all RAMs are called like. I mean, sure it knows of video ram, palette ram, sprite ram, etc. but doesn't mention the cryptic four letter codes used by the program ROM to describe them on screen. In order to avoid desoldering everything, I needed to dig deeper into the code to understand what "CRAM" was supposed to mean. Using MAME's font display feature, I translated the ascii for CRAM into the corresponding video codes required by the hardware to display that text on screen. No "CRAM" string was to be found in the code EPROMs either as ascii or as font-oriented video codes. ...my usual luck.

Thanks to MAME I made a list of RAM areas available to the system and with a little debugging effort made MAME stop execution during the test of said areas. I altered those areas on purpose to make the RAM test fail and see what message appeared on screen. I experienced SRAM error, FRAM error, MRAM error, etc. and of course also finally a CRAM error. Thanks to this, I now knew the address where the CRAM is available to the system and from MAME's memory map I could easily tell that it was the audio CPU RAM. Great, because it's obviously going to be located beside the audio CPU. Therefore desolder, socket, replace, fire up... CRAM ERROR. Because of course! *SIGH*

Provided the processor was good, there was only one possibility: the addressing logic had an issue somewhere. The RAM I was trying to debug was sitting on another bus, which means the main CPU needs to request access to the audio CPU bus in order to fiddle with its RAM, therefore I poked my scope to the BUSREQ# signal of the audio CPU. As suspected, no request ever came to the audio CPU to release the bus, which means the main Z80 was not even able to reach the target memory. I needed to dig deep into the addressing logic of the main CPU, and this is where things started to get funny.

The portion of schematic I have noted down properly while reverse-engineering the hardware.

As you can see from this schematic portion I reverse-engineered from the board, the main CPU differentiates addresses in a very fine way. The bottom of the memory, from 0000 to 6FFF is always mapped to the program rom, then there is a ram area at 7000-7FFF connected through buffering while the rest is banked in a very convoluted way. Also, as the addressing space is too crammed with stuff, the main CPU uses a ton of I/O accesses to communicate with the rest of the housekeeping circuitry around. Toaplan exploited every single bus feature the Z80 could offer; including wait states to keep everything in sync. Through this scheme, the main CPU can basically address every single RAM all around the board, thereby being able to provide quite some debug information before booting. That is the reason why the boot sequence takes so long. As most of those RAM devices are located in high speed circuit portions which are normally read and addressed in hardware, there was a need to arbitrate the main CPU access to the bus.

To this purpose, Toaplan resorted to a wait state circuitry around the main CPU that with every single CPU access to every single resource on the board (even dip switches and joystick ports!) tells the CPU to WAIT#, determines whether the resource can answer immediately or not and finally gives the CPU a go signal once the resource is ready. Furthermore, due to the way the board has been designed, the CPU accesses most of the resources using a 16bit data path. Wait... the main CPU is a Z80. How come 16bits? Because the designers were forced to use 16bits data paths due to how the graphics circuitry works. This board uses three custom chips which look a lot like predecessors of the T.T-2 used in Twin Cobra and Flying Shark (no wonder: Wardner has been released just a few months before them) which I already got to know intimately in another repair. Those customs always need to access the RAM as 16bit in order to provide all the nice hardware features and colour depth required for this game.

In order to facilitate debugging, and to protect themselves from piracy, Toaplan gave the main CPU the ability to read and write from any RAM around, plus they moved the sprite handling routines from the main CPU to a factory-programmed DSP chip: the TMS32010. This design approach requires the TMS32010 to be able to read from and write to the addressing space of the main CPU. It actually does read from and write "only" to both the main CPU RAM and the sprite RAM. This implicitly allows the protection code to talk to the main CPU and is made necessary by how the code is structured in order to be able to move sprites around. The TMS32010 could also theoretically access the audio CPU's RAM through the main system bus, and the audio CPU can indirectly talk to the rest of the system because its private RAM is shared with the rest of the board. ....an addressing mess, most of which is 16bit wide also because the DSP itself has a 16bit bus. Most RAM areas are made of two 8bit memories exactly due to this reason: so that the DSP and the graphics hardware can access 16 bits in one go.

Given that Wardner is the first Toaplan game to implement a DSP design on board, but is also the only one to do it with a Z80 as a main CPU, it seems obvious that they should really have used a Motorola 68000 as a main processor instead (which they did, starting from their very next board: Flying Shark...). Be it cost reasons, be it the 68000 being still totally obscure to their programmers, be it tight deadlines, be it stubborness... Wardner ended up being a uselessly complicated hybrid 8/16 bit system. As their next two products testify, Toaplan regretted their decision.

In a nutshell, I was getting fed up. I decided to proceed in a different way and quickly rule out most of the logic mess without reverse engineering all the details of it. But for that I needed a tool I was lacking in my arsenal: a logic comparator. Of course HP's logic comparators are a pain to find on the internet, and the prices start from around 350 euros. Add to that the need for all those pesky reference chip boards and the fact that it's 30 years old hardware bound to fail anytime soon. No way! I preferred to design one myself, Asayuki style of course!

My brand new logic comparator

Thanks to the comparator, I managed to find an issue on one of the ports of an OR gate. Although the part itself was good, I was seeing discrepancies with respect to the reference IC because of the parasitic inductance and capacitance of my comparator's probe. That sounded very funny, because it shouldn't be happening if the signal is properly driven. By tracing back the signal that was driving that input pin I found out that it was the CPU's IORQ# and it was very low in amplitude: about 1V. Replacing the CPU didn't help, which meant there was a heavy load on that line. A short search by desoldering here and there highlighted a 74LS08 that had low impedance in the input pin to both ground and VCC.

The gate guilty of causing the CRAM ERROR message

Bingo! I replaced the part, fired up the board and this time the screen stayed black. No error message whatsoever, no nothing. By scoping the Z80 I saw it was completely stuck, with the WAIT# line low. Now the defect moved to the wait state generation logic. Another logic mess which was reaching out to the entire board. So... back to reverse-engineering.

The signal which was required to tame the waitstate logic and let the CPU resume executing is coming from a 74LS133 (a NAND gate with a whopping 13 inputs!), whose inputs were "helped" by further AND and OR gates all over the place. There was no other way to proceed but to trace each and every input back to the logic that was driving it, and check if that was the circuitry that was getting stuck: a daunting process that was bound to take a very long amount of time on top of the time I had already invested so far. Luckily, so to speak, I stumbled almost immediately on the right signal, which brought me to a huge shift register bank organized using 11 (!!) 74LS299. A closer look to them highlighted an issue that slipped through the first visual inspection...

The fault caused by the one who has tried to repair this board before me

As it turned out, this board suffered a failed repair attempt based on guesstimation and a profit-driven trial and error approach. The person who did this is the kind of guy nobody would ever want to entrust an arcade repair with!

The pins you can see cut in the photo are the output enables of this shift register chain. The main processor uses them to write and read from and to the various graphics RAMs, therefore the boot process cannot proceed without them. The wait state logic waits forever for the shifting to be complete, because the outputs are always disabled. As a result, the CPU got stuck as soon as it tried addressing the memories in that area. Thank God, repairing the damage solved the issue. The board went through the long sequence of boot tests without problems and greeted me with a working attract mode, complete with sound. Just out of curiousity, I tried swapping back in the LS08 I had replaced before, and the CRAM ERROR came back as I witnessed it the first time around. This confirmed that whoever attempted the repair didn't have the slightest clue. He just started cutting here and there hoping in a lucky shot. A careful look all around the board didn't highlight any other cut pins, so I tought it was over.

The game finaly boots and works as intended

I played a couple of credits and ended up noticing that the picture looked dull and flat, as if there were not enough colors on the display. Also, the audio sometimes went silent due to a loose joint under the output capacitor of the power amp. A quick comparison with MAME confirmed my suspects: I had a video DAC issue. Fortunately Toaplan had put a gird & colour bars pattern generator into their code, so I flipped dipswitch 1 bit 3 and rebooted the board.

The issue with the colour DAC

There! Definitive and very helpful proof. This issue was extremely easy to fix but also extremely funny. This board's video DAC is the usual weighted resistor thing, with 5 bits per channel for a total of 15bpp. As bootleggers need to save money, they always use 5% resistors of the most common values: 220, 470, 1k, 2.2k and 4.7k. In a nutshell bootleg DACs are non-linear and the response is different from channel to channel, which explains why the greyscale in the photo looks reddish. Fair enough, but the resistors were fine yet some of the green coulour bit weren't output correctly. While fearing an issue in the DAC driving logic, I had a closer look at the PCB to see if all channels were identical and using the same resistor weights. That's when I figured the real issue out: the green channel had two of the resistors properly connected to the output, while the other three ended up on a common net that was completely isolated: no trace, no wire, no nothing. They actually forgot to route that node up to the green channel! ROFL! The solder joints looked so original that some of them were even cracked and about to go loose, and this means that this board always displayed dull and flat ever since and nobody ever cared. Beautiful! Solution? Well...

My patch was quick, easy and straight to the point. ...literally!

Toaplan wanted to deliver a cutting edge 16bit platform, but failed. The bootleggers wanted to create a 1:1 copy and failed. The guy who attempted the repair before me also failed big time. And considering all the time I have invested into this, I also failed. Picard's facepalm is not enough to describe all this. But Wardner is a nice little game and deserved to be saved. After all, I replaced just one component... *grin*

Stage clear
Lucky bonus