CPS-2 system specs?

Talk about anything else you want

Moderator: BigEvilCorporation

Post Reply
ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

CPS-2 system specs?

Post by ammianus » Thu Jan 17, 2013 2:43 am

Does anyone know what are the details of the specs for the CPS-2 arcade game system?

I mostly just want to know in comparison to the Sega consoles.

From wikipedia they only have some info:
http://en.wikipedia.org/wiki/CP_System_II
CPU:
Primary: Motorola 68000 @ 16 MHz
Sound CPU: Z80 @ 8 MHz
Sound Chips: Q-Sound @ 4 MHz

Display:
Color Palette: 32 bit
Total On Screen Colors: 4096
Colors per tile: 16 (4 bits per pixel)
Sprites: 900 (16x16 pixels)
Scroll Faces: 3
Resolution: 384 x 224
Maximum Rom Capacity: 322 Megabits
The one that is glaringly obvious to me is how much RAM? I would also be very curious to know how its video processing worked.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Thu Jan 17, 2013 8:32 am

Z80 seems to have 8KB
There are a pair of 8KB, 64KB SRAMs and 512KB DRAMs. I could not identify a 68K most chips are Capcom labeled.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Re: CPS-2 system specs?

Post by Charles MacDonald » Thu Jan 17, 2013 9:13 pm

The one that is glaringly obvious to me is how much RAM? I would also be very curious to know how its video processing worked.
I'll start with CPS-1 first since it and CPS-2 are almost the same:

It has 64K of work RAM for the 68000, and 192K of video RAM to store name tables for the three background layers, a sprite attribute table, and the palette table. All graphics for background tiles and sprites are stored in ROM. There is one custom chip for sprites and another for backgrounds.

Backgrounds come in three sizes, an 8x8 layer, 16x16 layer, and 32x32 layer. Priority is determined by a set of the pixel colors within a given tile, I forget the relationship but it's something like colors 1-7 have one priority and 8-15 have another. This allows a single tile to have pixels where some appear in front of a sprite and others behind it. There are no special scrolling functions other than a X and Y scroll register but they can be adjusted line by line if needed using a raster interrupt.

When the video chips access video RAM they have to halt the 68000 as they share a common bus. This slows down the effective CPU speed from 16 MHz down to something like 11 or 12 MHz on average. To minimize these interruptions, the background chip reads enough data for a row of tiles at once and caches it internally, so it isn't halting the 68000 for every tile that is displayed. I don't know of the sprite chip does something similar, but I suspect not.

This has some implications when you use raster effects to change the horizontal or vertical scroll mid-frame, since you may be specifying a scroll location outside of what was cached. This is why the vertical scroll effects in games like Marvel Vs Capcom on CPS-2 look a little odd. In my tests I never determined if the entire width of a row was cached or just an area relative to the displayable area. Magic Sword uses some rather large horizontal displacements on each scanline when you use magic, so maybe it is the entire width.

To prevent arcade operators from doing ROM swaps to change games, the background chip is located on the ROM board, or even on a sub-board attached to the ROM board in later games. They all operate in the same way but put the video registers at different locations. Later games had battery backed RAM connected to the chip that defined the register locations, such that when the battery died the chip was unusable. In reality the locations return to a default location when the battery dies, and you can patch the ROMs to use the moved registers on a 'dead' video chip. They went on to do the same thing for sprite video registers in CPS-2, which also defaulted (allowing creation of those "Phoenix" ROMs that work on battery-less boards).

The background chip can also read data out of a ROM to generate two scrolling starfield layers. This is a real throwback to the past as older games (I think Bosconian, games of that era) typically had dedicated hardware to generate a starfield. Not many games use it, though I know Strider does. CPS-2 has no physical ROM socket to hold the starfield data, but it uses the same background chip so the starfield layers exist but can't be used in a meaningful way.

Sprites are rendered to a frame-buffer, which is what gives CPS-1 a huge sprite drawing capacity. I think the upper limit is 1024 sprites, but because there's overhead per sprite processed that figure of 900 may be more accurate (like how Neo Geo can handle 512 sprites but has a hard limit of 381 due to timing constraints). It's double buffered so there's plenty of time for the sprite chip to render a lot of sprites. Like the background chip, the sprite chip reads parameters out of the 192K video RAM.

The video has a weird thing where you can assign a 4-bit intensity per color (which is 4:4:4 RGB for 4096 colors) The intensity is signed, so you can adjust the global brightness below normal in 8 steps or above normal in 8 steps. This frequently manifests itself as games having graphics that are black and then 'blacker than black' which looks a little weird. It also allows for very smooth palette fades.

The palette is stored in dedicated RAM but is updated by DMA from the 192K video RAM once per frame. This means real-time changes of the palette in video RAM don't affect the display. It prevents the visual distortion (flicker) you get when changing the palette and allows games to change the palette whenever they want, even outside of V-Blank. But it also prevents raster effects that manipulate the palette from working.

CPS-2 is identical to CPS-1, except that accessing the sprite RAM now goes to real dedicated sprite RAM because part of the sprite functionality is tied into the security they added for that system. For example the CPS Changer version of Street Fighter Zero is a CPS-2 game ported back to CPS-1 hardware. I never found any major changes between the two in my tests, but CPS-2 games seem to have larger sprites so they may have increased the speed at which sprites are rendered. That's just a guess, though.

As for any remaining trivia, some CPS-1 games had ROM boards which had unpopulated locations for a 2nd YM2151 and Z80. No games actually had these parts installed. Maybe this is what Capcom considered before making the QSound upgrade, or this was going to be a lower-cost sound upgrade in parallel with the QSound games.

Hope this is what you wanted to hear. :D
Last edited by Charles MacDonald on Sat Jan 19, 2013 5:33 am, edited 1 time in total.

ammianus
Very interested
Posts: 124
Joined: Sun Jan 29, 2012 2:10 pm
Location: North America
Contact:

Post by ammianus » Fri Jan 18, 2013 1:33 am

That's awesome information, thanks for all that!

pau05
Newbie
Posts: 1
Joined: Mon Apr 08, 2013 12:38 pm

Post by pau05 » Mon Apr 08, 2013 2:01 pm

I agree that CPS-2 is identical to CPS-1 and all information here are facts.

bhamadicharef
Newbie
Posts: 1
Joined: Tue Oct 30, 2018 4:37 am

Re: CPS-2 system specs?

Post by bhamadicharef » Tue Sep 10, 2019 7:24 am

Hi

Porting the Capcom CPS1 onto MiSTer is one of the current interest of many of us, however
even from the MAME source code there are still some areas which are unclear about how it
all work from the schematics. I would invite knowledgeable members from this forum to
join some of the discussion on the Atari-Forum in the MiSTer section ...

Best regards

Post Reply