WIP: CPS 1.5 on CPS2 hardware

[jedpossum]

Yep, just did the same thing. Format is the same sprites unless the cps1 game used a pal other than 0 on it.


Also, there should be a plane priority control in the memory like in SF2:HF at 0xFF804E.

[coolmod]

You know what I was thinking that might help? Compare the code on Rockman the power battle on the CPS1 vs the port on the CPS2? It could give some solutions!

[Layer]

First, he has to decrypt Rockman CPS-2 then.

[jedpossum]

You can use trace log and dasm on mame's debugger to get the code you want regardless if the rom is in encrypted or not. It's how I have that Q-Sound function from it.

Edit
Sometimes you just get lucky.
http://i.imgur.com/8kbSzED.png

[leonardoliveira]

First, he has to decrypt Rockman CPS-2 then.

Have a look on this file:
http://cps2.avalaunch.net/downloads/rmancp2jdl.zip

@jedpossum

Man, does that mean that all the writes to CPS-B sprite registers are meaningless on CPS2?

[jedpossum]

They're optional, I only see two games that used them SFA1 and SFA2.

[mikejmoffitt]

Following the theme of the thread, how far is SF Zero from being run on a regular CPS1 B board (as opposed to CPS Changer), as far as PAL selections and jumper configuration goes?

[jedpossum]

Following the theme of the thread, how far is SF Zero from being run on a regular CPS1 B board (as opposed to CPS Changer), as far as PAL selections and jumper configuration goes?

Well you have to redo how sprites work and remove the huge blank space in the graphic roms so it could fit on cps1 (Megaman Power Battle is the same way).

[leonardoliveira]

Because I am frustrated with the sprites thing, I started messing with the hardware again.

This is the CN3 from A-Board:


I am going to trace the signals from Z80 that are available at it. If banking is actually done on the B-Board it would need the memory bus enable, write and read signals from Z80 plus the whole address line bus and that would be enough to decode the target addresses for memory mapped I/O for YM and OKI control as I defined on the custom mame build.

It would be extremely pleasant if it's possible to hook the YM and OKI to the B-Board (even if it means making a whole new analog output circuitry for audio and bypass qsound completely) and not need to open the A-Board at all.

Edit: banking is indeed done at A-Board so nope this won't work. Stuff will need to sit at A-Board.

[jedpossum]

Not surprised this code was in SSF2Turbo. Since the game itself wants to treat inputs the same way as cps1 sf2 games.

Code: Select all

001D98: 41F9 0070 8FB0             lea     $708fb0.l, A0
001D9E: 43F9 0091 0000             lea     $910000.l, A1
001DA4: 3E3C 00C8                  move.w  #$c8, D7
001DA8: 20D9                       move.l  (A1)+, (A0)+
001DAA: 20D9                       move.l  (A1)+, (A0)+
001DAC: 51CF FFFA                  dbra    D7, $1da8
001DB0: 4E75                       rts

[leonardoliveira]

Not surprised this code was in SSF2Turbo. Since the game itself wants to treat inputs the same way as cps1 sf2 games.

Code: Select all

001D98: 41F9 0070 8FB0             lea     $708fb0.l, A0
001D9E: 43F9 0091 0000             lea     $910000.l, A1
001DA4: 3E3C 00C8                  move.w  #$c8, D7
001DA8: 20D9                       move.l  (A1)+, (A0)+
001DAA: 20D9                       move.l  (A1)+, (A0)+
001DAC: 51CF FFFA                  dbra    D7, $1da8
001DB0: 4E75                       rts

So they're putting the sprite tables on CPS1 video memory then moving it to CPS2 sprite memory later on? Probably so they don't need to tamper with the game code too much.

That is actually a sensible idea.

[mikejmoffitt]

Following the theme of the thread, how far is SF Zero from being run on a regular CPS1 B board (as opposed to CPS Changer), as far as PAL selections and jumper configuration goes?

Well you have to redo how sprites work and remove the huge blank space in the graphic roms so it could fit on cps1 (Megaman Power Battle is the same way).

Sorry, I was unclear - I meant the CPS Changer version, which is already CPS1. Unless the CPS Changer has additional hardware on its B-board equivelant, but I was under the impression the CPS Changer is almost entirely just a CPS1.

[leonardoliveira]

Following the theme of the thread, how far is SF Zero from being run on a regular CPS1 B board (as opposed to CPS Changer), as far as PAL selections and jumper configuration goes?

Well you have to redo how sprites work and remove the huge blank space in the graphic roms so it could fit on cps1 (Megaman Power Battle is the same way).

Sorry, I was unclear - I meant the CPS Changer version, which is already CPS1. Unless the CPS Changer has additional hardware on its B-board equivelant, but I was under the impression the CPS Changer is almost entirely just a CPS1.

It is. A CPS1 which does not take coins for credits. No Q-Sound, it has YM2151+OKI.

[Asure]

I think the answer to sprites should be found in MAME. It displays sprites, so it knows how they work.
For example, cps1 uses PAL mappers in video/cps1.c so the memory region is known:

Code: Select all

#define mapper_DM620    { 0x8000, 0x2000, 0x2000, 0 }, mapper_DM620_table
	{ GFXTYPE_SCROLL3, 0x8000, 0xbfff, 1 },
	{ GFXTYPE_SPRITES, 0x2000, 0x3fff, 2 },
	{ GFXTYPE_STARS | GFXTYPE_SPRITES | GFXTYPE_SCROLL1 | GFXTYPE_SCROLL2 | GFXTYPE_SCROLL3, 0x00000, 0x1ffff, 0 },

For CPS2 it does this:

#define mapper_cps2 { 0x20000, 0x20000, 0, 0 }, mapper_cps2_table
static const struct gfx_range mapper_cps2_table[] =
{
/* type start end bank */
{ GFXTYPE_SCROLL1 | GFXTYPE_SCROLL2 | GFXTYPE_SCROLL3, 0x00000, 0x1ffff, 1 }, // 20000-3ffff physical
{ 0 }
};
So where's the sprites going? And why is this at 20000-3ffff physical?
It seems to me CPS2 has a table of sprites, which "should" be at m_cps2_buffered_obj. At least that is where MAME looks for the last sprite. Then we have this bit defining the base:

When it's setting up stuff, there are values 7000, 7080 and 807d going to registers. When i look for those in MAME, they appear to be some unknowns, and OBJ_BASE related. There is also some deactivated code in there:

Code: Select all

if (    (m_output[CPS2_OBJ_BASE /2] != 0x7080 && m_output[CPS2_OBJ_BASE /2] != 0x7000) ||
		m_output[CPS2_OBJ_UK1 /2] != 0x807d ||
		(m_output[CPS2_OBJ_UK2 /2] != 0x0000 && m_output[CPS2_OBJ_UK2 /2] != 0x1101 && m_output[CPS2_OBJ_UK2 /2] != 0x0001))
	popmessage("base %04x uk1 %04x uk2 %04x",
			m_output[CPS2_OBJ_BASE /2],
			m_output[CPS2_OBJ_UK1 /2],
			m_output[CPS2_OBJ_UK2 /2]);
if (0 && machine().input().code_pressed(KEYCODE_Z))
	popmessage("order: %d (%d) %d (%d) %d (%d) %d (%d)",l0,l0pri,l1,l1pri,l2,l2pri,l3,l3pri);

For giggles i activated it. But the input key trigger fails (probably works on an earlier mame version.)
It does print some info, but at boot this is empty. There is also some code near that that cleans up cps1 sprites..

[Asure]

I think the answer to sprites should be found in MAME. It displays sprites, so it knows how they work.
For example, cps1 uses PAL mappers in video/cps1.c so the memory region is known:

Code: Select all

#define mapper_DM620    { 0x8000, 0x2000, 0x2000, 0 }, mapper_DM620_table
	{ GFXTYPE_SCROLL3, 0x8000, 0xbfff, 1 },
	{ GFXTYPE_SPRITES, 0x2000, 0x3fff, 2 },
	{ GFXTYPE_STARS | GFXTYPE_SPRITES | GFXTYPE_SCROLL1 | GFXTYPE_SCROLL2 | GFXTYPE_SCROLL3, 0x00000, 0x1ffff, 0 },

For CPS2 it does this:

#define mapper_cps2 { 0x20000, 0x20000, 0, 0 }, mapper_cps2_table
static const struct gfx_range mapper_cps2_table[] =
{
/* type start end bank */
{ GFXTYPE_SCROLL1 | GFXTYPE_SCROLL2 | GFXTYPE_SCROLL3, 0x00000, 0x1ffff, 1 }, // 20000-3ffff physical
{ 0 }
};
So where's the sprites going? And why is this at 20000-3ffff physical?
It seems to me CPS2 has a table of sprites, which "should" be at m_cps2_buffered_obj. At least that is where MAME looks for the last sprite. Then we have this bit defining the base:

When it's setting up stuff, there are values 7000, 7080 and 807d going to registers. When i look for those in MAME, they appear to be some unknowns, and OBJ_BASE related. There is also some deactivated code in there:

Code: Select all

if (    (m_output[CPS2_OBJ_BASE /2] != 0x7080 && m_output[CPS2_OBJ_BASE /2] != 0x7000) ||
		m_output[CPS2_OBJ_UK1 /2] != 0x807d ||
		(m_output[CPS2_OBJ_UK2 /2] != 0x0000 && m_output[CPS2_OBJ_UK2 /2] != 0x1101 && m_output[CPS2_OBJ_UK2 /2] != 0x0001))
	popmessage("base %04x uk1 %04x uk2 %04x",
			m_output[CPS2_OBJ_BASE /2],
			m_output[CPS2_OBJ_UK1 /2],
			m_output[CPS2_OBJ_UK2 /2]);
if (0 && machine().input().code_pressed(KEYCODE_Z))
	popmessage("order: %d (%d) %d (%d) %d (%d) %d (%d)",l0,l0pri,l1,l1pri,l2,l2pri,l3,l3pri);

For giggles i activated it. But the input key trigger fails (probably works on an earlier mame version.)
It does print some info, but at boot this is empty. There is also some code near that that cleans up cps1 sprites..

Edit: Also, what does "AM" mean besides the rom version? (I've seen show & test and also dumped mmancp2ur1 hehe) but never AM..

[leonardoliveira]

Rockman has all CPS-A and B writes mapped to 0800100 region. The only "special" thing I see it doing is write to "008040E0-008040E1 range once every frame.

So I took a dump ( ) of the memory map and I saw this "crap":

008040E0-008040E1 = 102: driver_data::cps2_objram_bank_w [offset=008040E0]

So, looks like it uses that register pair to cause the sprite hardware to snapshot the sprite memory area on the CPU and update the screen with data for the next frame.

Rockman also write to 804040 but that's eeprom stuffs.

Now this makes me wonder, don't scroll need the writes on CPS-A and B to work? could it be that writes to 800100 and 804100 reach the same spot on CPS2 ?

100000000000000100000000 (800100)
100000000100000100000000 (804100)
So, by ignoring 1 bit on the address you can make it so that writes to 800x00 and 804x00 reach the same spot on the hardware registers.

[Layer]

It seems you should be right, now, then.

Code: Select all

AM_RANGE(0x8040e0, 0x8040e1) AM_WRITE(cps2_objram_bank_w) /* bit 0 = Object ram bank swap */

[Asure]

Now this makes me wonder, don't scroll need the writes on CPS-A and B to work? could it be that writes to 800100 and 804100 reach the same spot on CPS2 ?

100000000000000100000000 (800100)
100000000100000100000000 (804100)
So, by ignoring 1 bit on the address you can make it so that writes to 800x00 and 804x00 reach the same spot on the hardware registers.

Yes, 800100 and 804100 are the same in hardware. After i changed all the writes in rom i noticed nothing changed in the visible memory ranges..i went back to cps2.c to look at the memory map:

The point is already demonstrated by MAME itself, as it display some gfx with only the little mods done to skip ram tests

Code: Select all

	AM_RANGE(0x800100, 0x80013f) AM_WRITE(cps1_cps_a_w) AM_SHARE("cps_a_regs")                              /* mirror (sfa) */
	AM_RANGE(0x800140, 0x80017f) AM_READWRITE(cps1_cps_b_r, cps1_cps_b_w) AM_SHARE("cps_b_regs")            /* mirror (sfa) */
	and
	AM_RANGE(0x804100, 0x80413f) AM_WRITE(cps1_cps_a_w) AM_SHARE("cps_a_regs")                          /* CPS-A custom */
	AM_RANGE(0x804140, 0x80417f) AM_READWRITE(cps1_cps_b_r, cps1_cps_b_w)                                       /* CPS-B custom */

One bit of 8040e0-e1 is set at boot (toggles a few times, stays at 1) and the other one is indeed trigerred each frame.

Im not sure if the hardware has indeed two OBJ layers or which games use them at the same time. Looks more like some sort of workaround for games which started development on the cps1, then got moved into cps2 hardware. But by doing it this way, they did not depend on hardware availability. If cps2 was delayed, they could use cps1.5 with very little delay to release the same game.

[leonardoliveira]

There's another thing I've just realized. It might be important:

0000 0100 0000 FF00 <- Rockman CPS1 use this to mark the end of a sprite list.
0000 8000 0000 0000 <- Rockman CPS2 use this to mark the end of a sprite list.

Another interesting difference is that the graphics rom is placed at 0x800000 address of the graphics bus for the CPS2 version so if you look the sprites list all codes are added that much on the pointer addresses.

Daimakaimura did not have a marker but it had 0000 0180 0000 0000 for all empty spots. I have returned all obj writes to 0x920000 and put code to copy that to CPS2 obj region during the interrupt. I also have it toggling 0x8040e0 0/1 like the CPS2 games do. No sprites still. One thing is missing.


Finally I did a test on Marvel vs Capcom, removing the writes to 0x8040e0 made sprites disappear.
Must be that write coupled with something else which make the sprites hardware latch and process the sprites list.

Writes to the scroll layers memory take immediate effect so if you poke the layers regions and play around with the values you actually see changes on the screen. Sprites have some sort of latching mechanism.

[Asure]

From video/cps1.c

Code: Select all

void cps_state::cps2_objram_latch()
{
	cps2_set_sprite_priorities();
	memcpy(m_cps2_buffered_obj, cps2_objbase(), m_cps2_obj_size);
}