RAMBO 3 – Taito

Just taken a random pick from my “to be repaired” stash, an original TAITO B-SYSTEM arcade board.


The sticker il no more readable, but the eproms labels are marked B93. According on the lists found over the internet this should be a RAMBO 3 board.

The usual visual inspection don’t reveal anything strange, the board is good condition so i’m ready for the smoke test. Jamma harness connected and power feeded, finger crossed and …


I’m greeted with this amazing “hello kitty-ish” pink screen! I think John Rambo shouldn’t be proud of! So before i’ll found him in front of my door knocking and armed, i must hurry and fix the board as soon as possible. 🙂

I powered off the board and i checked if some ICs were getting hot, but everything seems to be ok, but we know for sure that almost one “guy” shouldn’t do the right job on the board. Now i’m ready for a second run and powered on the board constantly checking it. The board seem stone dead, and in this condition the right thing is starting troubleshooting the main CPU looking for good control signals, time passes and no signs of life come from the board. I try to feed a credit to the board and surprisingly i was greeted with the right sound effect! This is a good news so probably the board is playing blind, i checked the dip switches and i tried to activate the attact demo sound, i did a power cycle of the board, the usual pink screen came out but now music and sound effetcs seems to be played in the right way.

So the issue must involve the graphic section of the board. My one cent bet is for the palette RAM, so i put my finger over it, it’s marked IC41 and it is a 2Kb 6116 compatible SRAM, the one with the yellow border below:


Its data and address lines are directly connected to the TAITO Custom IC marked TC0260DAR, the one light blue bordered, the palette generator chip i think, unfortunately no information neither schematics or pinout can be found on the net about this “guy”.

By the way according to the technical specifications the palette RAM on a B-SYSTEM board shoud be 8Kb, a 6264 standard SRAM, but on Rambo 3 board only a 2Kb palette RAM is present, allowing this way a less color depth.

Here’s a brief summary taken from wikipedia:

68000 main RAM: 32 KB
68000 video RAM: 46 KB
(8 KB palette, 36 KB tilemaps, 2 KB scrolling)
Video resolution:
320×224 to 512×256 pixels
Color palette depth:
4096 (12-bit RGB), or 32,768 (15-bit RGB)

Looking at this picture we can see the extra unused pins on the left of the palette RAM @IC41 allowing the fitting of a 8Kb palette SRAM as expected by the “standard” base design.


I made a quick shot on the MAME source at:


… here we can found the Rambo 3 address map:

static ADDRESS_MAP_START (rambo3_map, AS_PROGRAM, 16, taitob_state)
 AM_RANGE(0x000000, 0x07ffff) AM_ROM
 AM_RANGE(0x200000, 0x200001) AM_READNOP AM_DEVWRITE8("tc0140syt", tc0140syt_device, master_port_w, 0xff00)
 AM_RANGE(0x200002, 0x200003) AM_DEVREADWRITE8("tc0140syt", tc0140syt_device, master_comm_r, master_comm_w, 0xff00)
 TC0180VCU_MEMRW( 0x400000 )
 AM_RANGE(0x600000, 0x60000f) AM_DEVREADWRITE8("tc0220ioc", tc0220ioc_device, read, write, 0xff00)
 AM_RANGE(0x600010, 0x600011) AM_READ(tracky1_lo_r) /*player 1*/
 AM_RANGE(0x600012, 0x600013) AM_READ(tracky1_hi_r)
 AM_RANGE(0x600014, 0x600015) AM_READ(trackx1_lo_r)
 AM_RANGE(0x600016, 0x600017) AM_READ(trackx1_hi_r)
 AM_RANGE(0x600018, 0x600019) AM_READ(tracky2_lo_r) /*player 2*/
 AM_RANGE(0x60001a, 0x60001b) AM_READ(tracky2_hi_r)
 AM_RANGE(0x60001c, 0x60001d) AM_READ(trackx2_lo_r)
 AM_RANGE(0x60001e, 0x60001f) AM_READ(trackx2_hi_r)
 AM_RANGE(0x800000, 0x803fff) AM_RAM /* Main RAM */
 AM_RANGE(0xa00000, 0xa01fff) AM_RAM_DEVWRITE("palette", palette_device, write) AM_SHARE("palette")

as we can see, according to the MAME source, 8Kb for the palette RAM at range (0xa00000, 0xa01fff) are addressed, exactly 0x1fff hex bytes or 8192 bytes. Maybe should be something wrong here … it needs further investigations.

… but let’s take a step backward and bring the focus back to our not working board and its issue.

Probing the palette RAM address lines with the scope reveals they seems to be in good working order and an apparent regular activity seems to be present, also the control signals seems to be in good shape, but when i checked the data signals i think that something wrong were going on, too poor activity for a palette RAM.

This suspect is enough for me, and i start to replace it, i removed the old ram, i tried my best for a neat job …


… and fitted the proper IC socket.


before proceding, i tested the old RAM on the IC tester, and as you can see it was damaged! The RAM data bus miss the test … Yeah!


I replaced the palette RAM, and fed power to the board again, and …


GOTCHA! It worked! So i could proceed fixing minor issues over the PCB as these damaged, loosen or totally missed capacitors, one 1000uF cap on the 12v rail in the audio section:


and two 220uF caps like this …


Both replaced with their equivalent ones in a bloody-red color! Much better!


I think also John Rambo should be proud of them … and now he’s ready to kill all the enemies!


Board fixed. Another case closed! 🙂


This is one of my favourite arcade games ever!

I’ve got this GOLDEN AXE PCB a SEGA System16b board on the bench from a friend of mine, Daniele,  for a repair. The board boot fine, the game starts in the right way, but there is no audio at all.

This should be a quick fix, i think. This is the picture of the board :


The PCB is in very good conditions and no scratches were found on the solder side. So it’s the time to get hands  dirty and take a deeper look at the audio section of the board.

First of all i noticed the C18 cap is missing, but according to the System16b schematics i found on the net, the missing cap shouldn’t be involved in the issue, the board il totally silent.


We can look at the missing cap on the red circle, this picture is taken from the sega System16b schematics:


… and this one is taken from the IC datasheet:


For a first quick and dirty test of the audio power amp, a Fujitsu-MB3735, i used an old school method and an absolute high-tech probe … a finger! : )
Adding some interference and extra capacitance the amp should oscillate abnormally and should reply with the classic “hum” noise. This will tell us that the amp may do it’s job, and it seems working.

So we can take a deeper look at the audio chain of the board:


So we can go backward through the audio circuit in the preamp section a quad op-amp marked NEC uPC804C, it’s an equivalent of a better known TL084. Probing it with the scope i found that it was totally silent both inputs and outputs. The inputs are feeded by a Yamaha YM3012 DAC, a digital analog converter, obviusly all the output stages were silent but there is an apparently activity on its inputs. The serial data input pattern looked at the scope seem to be too regular, it should change in some way when differents sounds were played. The input pins of the DAC are connected to the output pins of the FM sound generator chip, a Yamaha YM2151. They are a classic audio ICs tandem, found on several arcade boards.

Also the NEC uPD7751 ADPCM Decoder was silent too …

My suspect is that the CPU in some way should misdriving the sound generators ICs. Before probing around address and data lines on the PCB, we can notice that on the SEGA System16b boards the audio CPU, a classic Zilog Z80, is mounted on a socket so we can easily test if the culprit relies on it by simply swapping it. Using a good Z80 didn’t solve the audio issue, and testing the mounted Z80 reveals it was good, so we need further investigations.

It’s time to take a look at the CPU signals, the clock signal was good, CPU control signals (RESET, HALT, WAIT, …) seemed to be healty, system control signals reveals the CPU is stucked in a READ state no WRITE activity on the RAM, this should be strange in a good working mode. So i started poking with the scope over the address and data lines, it reveals a lot of activity and the displayed patterns seemed to be the usual ones.

But when pinned the probe on the D3 line …


… The yellow pattern is a good D0 line, the green pattern is (inverted for a better reading) the D3 line and it is stuck high. Checking and beeping around the D3 signal for continuity traces testing between CPU, 6116 SRAM, an the FM chip reveals they were all ok. The test points are the ones with the red dot on the upper image of the audio section.

So only few IC remain to test on the shared data bus, the EPROMs. They are placed on a daughter board attached to the mainboard with four connectors. I started from the Z80 sound EPROM a standard 27c256 marked EPR12390, according to the datasheet the D3 signal should be on PIN 15.


The digital multimeter reported no continuity between CPU and EPROM on D3, maybe they can be wired in a different way so i check D3 on the CPU against all the pins of the EPROM data bus, but no audible beep can be heard. I checked the whole data bus and it was ok and only D3 was missing. So this should be the culprit, a broken trace, maybe on the connector, between EPROM and CPU data bus on D3 signal.

I pulled out the EPROM for further investingation and i spotted this:


… so i lifted the pin, reseated the EPROM on the socket and ready for the “smoke test” … and it worked! I was greeted with the usual Golden Axe audio effects and voices, and the well known music theme.

The damaged pin prevent the CPU bootstrapping and executing the right program code, probably leaving it in a endless loop of trash bits with wrong data.

It’s time to replace the missing C18 cap to completely fix the board. Despite of the lenght of this post, it was a few minutes easy fix.


Now, Daniele should be happy! : )
Case Closed.

By continuing to use the site, you agree to the use of cookies. MORE INFORMATION

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

To make this site work properly, we sometimes place small data files called cookies on your device. Most big websites do this too. A cookie is a small text file that a website saves on your computer or mobile device when you visit the site. It enables the website to remember your actions and preferences (such as login, language, font size and other display preferences) over a period of time, so you don’t have to keep re-entering them whenever you come back to the site or browse from one page to another.

How do we use cookies?
to remember users' actions, to identify the user login also with third-party cookies (facebook, twitter, google+, etc...) for social related tools, to enhance the performance of the website, they are session cookies, and third-party ones are used for google analytics tools. The cookies will not be used for any purpose other than the one stated.

How to control cookies:
You can control and/or delete cookies as you wish – for details, see aboutcookies.org. You can delete all cookies that are already on your computer and you can set most browsers to prevent them from being placed. If you do this, however, you may have to manually adjust some preferences every time you visit a site and some services and functionalities may not work.