Strider Cps1

0 views

Skip to first unread message

Brayan Jacobsen

unread,

Aug 3, 2024, 4:41:20 PM8/3/24

to krafaltarmi

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

From there, just choose "CHARACTER" to access the tile viewer menu. Pick "OBJECT" for sprites, "SCROLL1" for the game's font, "SCROLL2" for the foreground tiles, and "SCROLL3" for background tiles.

The Amazon enemies have their left breasts exposed in the stored graphics. This is covered in the actual game with a separately-stored green leaf sprite. Add the code in strider.xml to check it out.

3232 tiles for a logo of "The Falcon", the name with which the game was first revealed in western gaming magazines. In an interview with game planner Kouichi "Isuke" Yotsui, he explained that this title was initially chosen because Capcom USA wasn't convinced with the Strider name until they changed their minds later.

These music tracks do not exist in the ROM, but have unique IDs and track names in the Output Test. They all point to Track 00, the Stage 1-1 music. A Stage 3 cutscene track and an ending credits track were eventually recorded for the Sega Genesis and Sharp X68000 ports. A time running out song was recorded for the Sharp X68000. The sharp X68000 would get an arrangement of the Genesis credits song for the Name Entry screen.