Reading Irem MASKROM’s

 General, Technical Info  Comments Off on Reading Irem MASKROM’s
Apr 022016

I got an M92 PCB here that uses MASKROM’s from SHARP.
These MASK’s in particular are pin compatible for either 27C020, 27C040 or 27C080 EPROM’s.
It is possible to determine which to dump these as from the markings on the chip. They all begin with the ID LH53#, where # is the identifier of the size.
“LH532” = 27C020 dump

“LH534” = 27C040 dump

“LH538” = 27C080 dump

The remaining letters/numbers of the markings are unique to the game and location on the PCB.

 Posted by at 10:55 am
Feb 172016

What this article is about: This isn’t a conversion “how-to”, there is too much missing information for this to be used as such. It won’t teach you how to make a conversion since this is Strider specific.

This is more aimed at providing some technical info on cps1 and documents the process & tools used to fix a poorly converted game.


A rather interesting post came up from system11 on The Dumping-Union. Binaries were included of the images dumped from the EPROMs on the boardset pictured below.

This came from someone non-technical and with good reputation who worked
at Capcom US arcade section (proveable), he bought it from Capcom directly
(claimed but I see no reason to disbelieve) and seemed shocked when I
complained about it being converted.  We’ve got a GAL on there which I
can’t read, a bunch of chip matches in wrong locations and an unknown code
ROM.  No jumpers have been moved.  Clearly converted from a SF2 variant.

No idea why this exists.

So what we have below is a 90629B-3 B board populated to run Strider on a 90632C-1 C board with the CPS-B-17 PPU. The only CPS1 game to use this specific PPU was Street Fighter II: The World Warrior however, being a popular game Capcom used many different variations of this PPU.


What makes this particular conversion interesting is that according to system11, the PCB was purchased from a Capcom source who purchased it in-house.

It was bought from xxxxxxxxxxx:

He bought it when the Capcom arcade unit in the same building was winding down as I understand it.  He claimed not to know it was a conversion when I received it, and honestly given his background I do believe him. Probably a half finished tech project by one of the engineers.

Nobody can claim that this is an official “Strider” system, at best it could be described as an “in-house” conversion, poorly done but the engineers who worked on this obviously had better and more important things to do with their time.

There are several code related issues which prevents the game from running properly especially after you die at certain checkpoints and also some other issues which I discovered myself.

So now it turns out that the game doesn’t actually work properly if you die in stage 2, does anyone have any ideas what I can do with this boardset?

Looks like it was a World Warrior to begin with – CPS-B-17, so I’m leaning towards ‘throw it away and sell the A board’.

Having a shitty month so far.

I decide I want to help out and fix the game. This makes for an interesting project as I have done several conversions in the past for myself & friends but I no longer own a complete CPS1 system. Testing would be difficult however, thanks to MAME I can do most of it via the debugger. I would send the new versions to system11 and he would test the changes on his PCB and report back.

The first step was to reproduce the problem in MAME. I’m using a very old & hacked up version of MAME (v1.50) which is fine for what I’m doing.

To do this I make some code changes to the cps1.c driver & cps1.c found in video. Changes are highlighted in red.

Note I am modifying the Japan resale version of the driver, the choice was arbitrary. You can see that I have run the USA version of the ROMs in this driver in the past 🙂

mame setup 1

After re-compiling the code and running the game for the first time it was evident that their was a problem. Nothing showed up on the screen until the game entered the attract mode. Normally the post shows some text related to the power up tests. Since the screen is black until attract mode is entered there is nothing to show here.

To see what is going on, I decide to disassemble the code via dasm in MAME which generates a 20Mb text file containing 68k code. A decent amount if you like reading through tonnes of code and have nothing else better to do.

dasm 1.

I also fire up the US Strider (USA, B-Board 89624B-2) and disassemble the code. The hack is based off this U.S version.

Combining both files side by side using WinMerge allows me to see the changes the hackers made to the original. There are a total of 52 differences. But even that wasn’t enough!


I need to create a small table which represents the difference between cps_b_17 & cps_b_01 registers. I also need to describe what each address register is for ( layer control, priority mask..etc ) These move between different PPUs. So why did Capcom do this ? Perhaps for security to stop operators from easily converting games who look to avoid purchasing conversion kits, sounds plausible.


According to MAME, cpsb registers start at a base address of 0x800140 and end at 0x80017f, this is true for all cpsb PPU variants. But the actual addresses for each register changes between PPUs.


For cpsb17, to get the address for the layer control I simply add 0x14 to the base address of 0x800140 which gives me 0x800154. 0x14 is taken directly from the table above in src\video\cps1.c.To get the first priority mask I add 0x12 to the base address of 0x800140. I go on until I have completed the column on the left. Similarly, I do the same for the cpsb_01 column until the table is complete.

I can check the existing work and have something to guide me a long the way by using this table. I normally write all of these details on a white board.

Since the original game uses the CPS_B_01 PPU I have put them both side by side in the table above. So if I need to change the palette control I substitute 0x800170 (cpsb01 ) for 0x80014a (cpsb17).

I now have what I need to start working on the code but to make editing simple I dump the two rom regions and combine them into one file using the MAME debugger and edit the driver to accept the single binary file. I do this to make editing and testing the binary straight forward.

Changes in red are made by adding comments to the two lines and adding the line in green.

Later I’ll split the single binary into two files once I’m happy with the results so that they can be burned to the EPROMs.

mame setup 2

Using the cpsb table I begin by searching for $800170 in the right hand column of WinMerge, I repeat this process for each register in the table. This is just my process of checking existing work. Note that there are no differences at 0x074CC4, $800170 is the palette control register used by the cpsb01 PPU but the hackers missed that. It should be $80014a for the new PPU.


Cross referencing the table, I change 170 to 14a in strider17.bin using a hex editor. This fixed the post and the power up tests are now visible.


The game also had an issue with the sky not showing up at all, this was only reproduced in MAME & not on the real PCB. I try to find out why.

no stars

The bits for the layer enables are written to address 0xFF0C74 ( 0xFF8000 – 0x738C ) in DRAM before being written to the layer control ( 0x800154 ). The value written here is the old value for the cpsb01 chip. 0x138e is coming from a location in ROM pointed at by A1 ( 0xB616 ).

stars fix 1

Here is the location in ROM that needs to be changed to 0x139a.

stars fix 2

Changing it fixed my sky. Although the old value still worked on system11’s PCB, it still wasn’t correct. My changes never broke the sky on the PCB, so I’m happy with the change although it made no difference.

stars fix 3

The sky is still missing in stage 1 & during the intro after you press start. But it’s not related to the problem found above.

stars fix 5

To get the sky to show up correctly I had to tweak the enable masks in MAME.  Street Fighter II: World Warrior is the only game that uses the CPS_B_17 PPU and not all the layer enables are used in the game, hence MAME only defines some of them which explains our missing sky in this instance. I could have left it alone as none of my changes require any alterations on the game EPROMs. It’s just nice to prove that missing stars has nothing to do with the PCB itself.

I create a new CPS_B_17 entry just for Strider as I don’t want to break Street Fighter. I then change the 4th layer enable mask from 0x00 to 0x04. I tried other values at first but 0x4 worked correctly. I also modify the config table to use the above new entry.

stars fix 6

Recompiling MAME and running the game brings the stary sky back. So now I can move on to more important stuff.

stars fixed

One of the complaints regarding bugs reported by system11 suggests that if you die at a certain checkpoint in stage 2 then the entire background disappears.  I reproduce this issue by playing the game.

stage 2 bug

I know from looking at the screen that this is a layer enable problem.  First I create a small table with the old enables for the cpsb01 board on the left and the cpsb17 masks on the right. The hackers have already done most of the work for me so I just go through all the differences for the layer enables which I found in WinMerge and make a note of them on my whiteboard to create the table below.

enable bits

I then create a bunch of watch points which are invoked when specific layer enable bits are written to the DRAM address 0xFF0C74. The value stored here is used later on and written to the layer control register at 0x800154.

stage 2 bug d

I play the game until I die and the debugger is invoked when the data written to 0xFF0C74 equals 0x138e. This needs to change to 0x139a to bring back the correct background.

The value 0x138e is read from A1 ( 0xb5e4 ) and that is the offset where I need to make the permanent change to the file.

stage 2 fix 1

But first, I want to see if overwriting 0xFF0C74 with 0x139a via MAME will bring back the correct background temporarily ( until I die at the same checkpoint of course ).

The changes worked as you can see below. So I’m definitely on the right track here.

stage 2 fix 2

Here is another issue in Stage 2, the background completely disappears after dying ( next screenshot ).  The debugger is invoked when it writes 0x138c to our DRAM address. This value comes from A1 which is hard coded at offset 0xB66C in the rom, i’ll change that value to 0x1392  later.

stage 2 wolves fix

And here is the result if I resume program execution.

stage 2 wolves

And the temporary fix by writing 0x1392 to DRAM: 0xFF0C74 which is later written to the layer control.

stage 2 wolves fix 2

Continuing on in stage 2 brings me close to the end of the level where I head up towards the large airship. Dying triggers the debugger on watch-point 3 as the layer enable value of 0x138C is written. This value will later be changed to 0x1392 at offset 0xB6B2 in the rom.

stage 2 airship

If I resume execution you can clearly see that the background is missing as Hiryu appears to be magically hovering in the sky.

stage 2 airship 2

Fixed temporarily by writing 0x1392 to DRAM: 0xFF0C74.

stage 2 airship 3

Finally this brings us to the large airship at the end of level. Dying triggers the debugger as the layer enable value of 0x138e is written. This value will later be changed to 0x139a at offset 0xB6F8.

stage 2 largeairship

Resuming execution shows a stary sky instead of the correct background.

stage 2 largeairship 2

Fixed temporarily by writing 0x139a to DRAM: 0xFF0C74.

stage 2 largeairship 3

This concludes the fix as far as stage 2 goes, I couldn’t see anymore problems in this stage.

I still want to fix the issues in attract mode. So let us take a look at the two issues I found. First issue was the missing dinosaur, it only showed up briefly before it explodes. The second issue was the missing satellite.

With my watchpoints set the debugger pops up when the layer enable bits equals 0x12ce. This needs to change to 0x12da, this is done at file offset 0xB81A which is held by A1 in the debug window.

dinosaur fix 1

I’m quite confident at this stage that my temporary changes will work so I don’t bother with those, I edit the binary, restart the game and our dinosaur appears behind Hiryu in the attract mode.

dinosaur fix 2

The other issue is the missing satellite. The fix needs the value 0xb5a instead of 0xb4e at offset 0xb9aa.

sat fix 1

Editing the binary at the said location fixes the issue.

sat fix 2

I still need to play through stages 3,4 & 5 to make sure there are no more surprises. Having my watch-points set and dying as often as I can will ensure that I cover all the bases ( hopefully ). There’s no difference to the process as documented above so I’ll just leave it at that.

I could have used a more shotgun approach and used a search and replace tool but then I run the risk of changing something I shouldn’t and breaking the game.

Once I’m happy with the changes the binary is split into two 512kb, word swapped and sent to system11 for testing on his PCB.


Jan 032016

Contra / Gryzor shares almost the same hardware specs with Combat School / Boot Camp, Fast Lane, Flak Attack / MX5000, Haunted Castle / Akumajô Dracula and Trick Trap / Labyrinth Runner.

But among these titles, it is the only game that offers a stereo output thru a 4-pin connector on the board (labeled CN2).

First, you have to select stereo by plugging a connector on CN4 (and put switch 4 of DIPSW3 to off).


The thing is that all the boards I’ve seen still delivers mono sound when you plug this connector (originally brought by Konami and present on the board) on the stereo plug. Why ? Because it doesn’t have the good wiring…

As shown on the picture above, this connector originally comes with pin #1 wired to #2 and pin #3 wired to #4. In that way and plugged on the stereo connector (CN4), it mixes channel 1 and channel 2 from the YM3012 DAC to the LA4445 amp which results a mono output.

To separate the channels, you have to simply modify the connector by wiring pin #1 to #3 and pin #2 to #4.
Now plug it on CN4 and enjoy stereo sound out of CN2. 🙂

There are other Konami games that use the same connector to choose mono or stereo. I’m not sure about the wiring for every game. To my knowledge they are:

– Jackal / Top Gunner
Devil World / Dark Adventure
– Gradius II / Vulcan Venture

– Ajax

Lightning Fighters / Trigon (stereo works without modification of the connector)
– Parodius
(stereo works without modification of the connector)
Surprise Attack (that game seems to have a mono sound design, despite the stereo connector present on the board)

ps. If anybody knows if the original wiring on these boards allows to deliver stereo sound or any other board that is using this connector, I would be glad to know and add it here.

ABI ICT-24 Digital IC Tester tech info

 Technical Info  Comments Off on ABI ICT-24 Digital IC Tester tech info
Jan 012016

I recently found one of these devices and being a lover of test equipment I decided to see what it was all about.

There is very little information about these online. The only official mention I can find about them is on ABI’s website and it just makes a passing reference to it stating it was the first IC tester device they made.
All other information comes from Equites who has had one of these for a number of years now. He has dumped the ROM’s from his unit and they are available in the downloads section.

So, I got my unit and powered it up to make sure it worked. Once I had confirmed that I opened it up.

I could see straight away that I have a different firmware version, mine being 6-0-12 and the version Equites has was 5-9-12. I’m still not sure what the difference between the two is.
So I dumped these EPROM’s (available in the downloads section too) and created a schematic for the unit.
The device is a Z80 based system with a couple of EPROM’s, a RAM chip, a keyboard/display interface chip and three PPI chips to control IO reading/writing.

Once I had drawn it out I derived the following memory map
$0000-$3fff – ROM1
$4000-$7fff – ROM2
$8000-$87ff – RAM

8255 (IC1)
$c000 – PORTA
$c001 – PORTB
$c002 – PORTC
$c003 – Control

8255 (IC2)
$c004 – PORTA
$c005 – PORTB
$c006 – PORTC
$c007 – Control

8255 (IC3)
$c008 – PORTA
$c009 – PORTB
$c00a – PORTC
$c00b – Control

8279 (IC8)
$c00c – Data
$c00d – Control

IC1 – Controls the /OE lines to all the IO buffers
IC2 – Controls the inputs the the IO buffers
IC3 – Controls the reading from the ZIF sockets

The ROM’s, RAM, 8279 and 8522 chips enable lines are controlled via 74LS139 decoder chip.

The version number of the firmware can be displayed by keying in “005” on the keypad.
On my version it displays “6-0-12” which matches the labels on the EPROM’s.
Interestingly the “6-0” is stored as data in the ROM while the “-12” is hardcoded as instructions starting at $11cd.
The first 2 digits, in my case “6-0” represent the software version.
The remaining digits are the options installed. Mine as options 1 and 2 installed.
Option 1 is for memory devices
Option 2 is for interface devices

The unit does a power on self test which displays a fault code between 0 and 6. These may be explained in the manual which I don’t currently have so I took apart the disassembled code to see what they meant.

Fault 0:
One of the IO’s is tied to GND.
The software tristates all the IO pins via IC1 (8522) and reads them back via IC3 (8522). They are held at logic HIGH via a pull up resistor network. If any pins are low this will result in FAULT 0.

Fault 1:
One of the IO’s on PORTA is tied to VCC.
The software sets all of the IO pins on PORTA to logic LOW and reads the states back. If any pins are found to be logic HIGH on PORTA then this will result in FAULT 1.

Fault 2:
One of the IO’s on PORTB is tied to VCC.
The software sets all of the IO pins on PORTB to logic LOW and reads the states back. If any pins are found to be logic HIGH on PORTB then this will result in FAULT 2.

Fault 3:
One of the IO’s on PORTC is tied to VCC.
The software sets all of the IO pins on PORTC to logic LOW and reads the states back. If any pins are found to be logic HIGH on PORTC then this will result in FAULT 3.
NOTE: The 2 uppermost bits on PORTC are not used for reading back IO lines.

Fault 4:
Fault with the program RAM.

Fault 5:
Fault with display RAM.
RAM should be 0x0. If it is not then FAULT 5 with be displayed.

Fault 6:
Fault with display RAM.
RAM should be filled with alternating 0x55 0xAA. If these values are not correct then FAULT 6 is displayed.

Equites supplied me with some additional pictures and a manual for these units and apparently there is a rebranded RS version too.
That’s about it. I have commented a lot of the code and learnt a great deal about how it works.
Its a very robust unit and no doubt it will get some use despite having other methods available to test. Its much more appropriate to have in a garage workshop.

If anyone can offer any further information about this (or feels the need to emulate it) then please get in touch.
Thanks to Equites for his information and scans.

 Posted by at 1:14 pm
Nov 222015

This is the first in hopefully a series of posts regarding the Rainbow Islands hardware.
I have no time frame in mind for releasing these posts and I will do them when I have any particular section covered.

First up is the reset/watchdog circuit.


Here we have the circuit that I have drawn out.
On power up the MB3771 power supply monitor chip will keep the CPU in a reset condition by asserting a low signal to pin 4 of IC2 (74LS08 AND gate).
At the same time the master reset pin of the 74393 4-bit binary counter is held high thanks to the inverting buffer at IC3.
Note, jumper JP1 can be used to disable the watchdog although I couldn’t find a resistor tying it high which would mean if the trace was cut on JP1 the MR pin would be floating. Maybe I just cant see it.

Once the MB3771 is happy it asserts a high signal from pin 8 which will allow the 68000 CPU to run and the watchdog timer to begin.
The watchdog clock is taken from the VBLANK signal and directly clocks the first binary counter at pin 1 which in turn clocks the secondary binary counter via output pin 6.
If the master reset pin in not activated within a certain time then the counters will count up and initiate a reset.

The watchdog reset signal is achieved by writing any value to an address between $3c0000 – $3dffff.
The memory map for the watchdog is determined by the PAL20L8 device B22-07 @ IC7.
Output pin 21 is the pin concerned with this function. Here are the equations for it.

!WD = 1ACK & !A23 & !A22 & A21 & A20 & A19 & A18 & !A17 & !AS
# 1ACK & !A23 & !A22 & A21 & A20 & A19 & !A18 & A16 & !AS
# 1ACK & !A23 & !A22 & A21 & A20 & A19 & A17 & !A16 & !AS

This output goes to a 74LS138 decoder/demultiplexer. Output pin 13 is the watchdog reset output.

That’s pretty much it. Simple and nothing much out of the ordinary.

 Posted by at 1:19 pm