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.
![Very Happy :D](./images/smilies/icon_biggrin.gif)