Popeye tech info

 Technical Info  Comments Off on Popeye tech info
Apr 072017

I’ve been working with a Popeye PCB recently and I wanted to figure out the hardware so I thought it would be good to document what I found.

The PCB uses some fairly simple obfuscation for the CPU address lines utilising what the schematics refer to as a PLA device. Further investigation revealed that the devices used on the address bus here are actually 74LS367 at locations 6F and 6H. I originally believed the IC at location 6E to be the same but in the decoding routine that MAME uses, the new address value returned after swapping the bits gets XOR’d by 0x3F.

Checking further I found this chip is actually a 74LS368 (inverting line driver). If you notice on the video PCB there is another chip with its markings removed at location 5U.

This is a 74LS04 inverter and is needed because the lower 6 address bits are inverted from the CPU by the 74LS368 at location 6E so we need to return them to their intended state. Inverting them again allows the video and background RAM to be addressed properly.
All these so called PLA’s are actually regular TTL with their markings etched off.

The data lines are also scrambled and can be easily followed from the schematics.
The code in the program EPROM’s is scrambled to accommodate the above methods.

There are 2 additional IC’s also marked as PLA’s attached to the outputs of 3 x 74LS161 counters at location 3E and 4E. These have been identified as a 74LS365 at location 4E and a 74LS368 at location 3E and are part of the DMA circuit.

The hardware doesn’t use any other interrupts, only the NMI.
The NMI vector is the same for all Z80 program and starts at address $66 in ROM.
It is triggered essentially by the /VBLANK signal and during this time all the on screen background and sprites are updated.

The main RAM for Popeye lies at address $8800 – $8FFF and is a TMM2016 located at 7H on the CPU PCB.
The main RAM doesn’t appear to invert the lower 6 bits of the address bus so the actual locations written to in RAM will be different to what the program actually expects however this is not an issue as all the accesses will give the correct data. In the event of fault finding though this could potentially cause confusion.
DMA accesses to this RAM are all correct.
Access to this RAM is controlled via a 74LS139 at location 8F.
The first demultiplexor of this IC is enabled when address bit A15 is HIGH (address $8000). Output Y0 connects to select input B of the second multiplexor and address bit A11 is connected to select input A. Output Y1 (pin 11) is connected to the /CS pin of the RAM.
In order for Y1 to be active A15 and A11 need to be HIGH (address $8800).

There are two pull-up resistors used on this RAM connected to AD10 and AD11. These are present for when DMA accesses are happening as it only uses 9 bits. Without these resistors AD10 and AD11 would be floating during these times.

As we only write nibbles to the RAM section but need to preserve the nibble value we currently are not writing too there is a system in place to deal with that.

/CSBW is generated when we write to anywhere in address $C000 – $CFFF.
This signal clears the DMA access to background RAM and sets the 74LS157 chips to use the address bus instead of DMA.

When a write to the background RAM is initiated the 74LS174 at 8U gets clocked before the write enable for the RAM goes low. This latches the current RAM nibble not being written to, onto the outputs of 8U which lets the RAM get updated without losing data.
The delay for latching the RAM data before writing is achieved by a 74LS20 at 5D on the CPU board. One of these signals is the /WR but goes through a 74LS74 in order to create a delay of 1 clock cycle. This gives enough time to latches the RAM data before the write enable is active on the RAM itself.

There is a security ALU that sits at address $E000 – $E001 in the memory map. It can be both read from and written to. MAME has functional behaviour for this emulated in the driver.
The various modes of the ALU are selected by an IC labelled as ‘Selected Decoder’. This is actually a 74LS139.

I wanted to implement this chip into one of the 28 pin CPLD modules I have. Being an amateur in HDL programming I wasn’t too sure whether the design could be implemented into an unclocked CPLD design so I asked my friend Charles MacDonald for some advice on Verilog.
He kindly sent me a draft code based on the MAME implementation. I have adapted this to reflect the real hardware and it is now implemented and seems to be working. The programming file can be found in the download section if anyone ever feels the need to use it. I would still like to get hold of an original chip to study as although the code for this works with the titles that use it, all the behaviours of the chip are not fully documented that I know of.

Without this chip present Popeye will reset when starting a game. There may be other issues as well but I cannot pinpoint them.
There is an unprotected version of Popeye available in MAME which does away with the requirement for this security chip so there isn’t much need to use a reproduction of this chip.

UPDATED 10/03/2019 – Ace’ informed me of an error. 4E is actually a 74LS365 NOT a 74LS367 like originally stated.

 Posted by at 8:01 pm

Commodore 64 Game Killer cartridge

 Technical Info  Comments Off on Commodore 64 Game Killer cartridge
Dec 152016

Found this oddity on eBay not too long ago.

Its a crude device that attempts to disable collision detection for games that used hardware sprites.
It device itself wasn’t too successful but it was cheap and love my C64 so here it is.
I spend half an hour drawing up a schematic for the device and also dumped the ROM which is in the downloads section.

Cant imagine anyone ever needing to use the schematic for anything. Its very simple and any fault finding could be done in moments and who in the right mind would want to create more of these things but it was a small side project.

 Posted by at 1:26 pm

Rainbow Islands – Clock Circuits

 Technical Info  Comments Off on Rainbow Islands – Clock Circuits
Jun 242016

A short simple post on two of the clock circuits used on Rainbow Islands.
There are 3 x crystal oscillators on the Rainbow Islands PCB. This post will cover two of them. The third is used for selecting a chip enable line of some RAM in an elaborate way which I don’t fully understand right now.

First lets look at the X2 Oscillator which is 12MHz.

This is solely used as the clock for the C-Chip and simply goes though IC54, an inverter, into pin 20 of the C-Chip at 12Mhz. Easy!

Next up is X1. This supplies the clock signals for the Z80 and the 68000.

The 16MHz clock signal serves as the clock signal for a 4-bit binary counter at IC30. Output Q1 (pin 13) of this binary counter gives a 4MHz clock which is the clock signal for the Z80 sound CPU.
Output Q0 (pin 14) of this binary counter gives out the 8MHz clock for the main 68000 CPU.

Both of these clocks also feed into the custom PC060HA chip at IC45 on pin 14 (SCLK) and on pin 15 (MCLK).

That’s all there is to this one.

 Posted by at 1:00 pm

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.