WIP: CPS 1.5 on CPS2 hardware

[undamned]

Nice, Leo! Very exciting!
-ud

[Asure]

So, as for Punisher, i now have 99.9% inputs working (just TEST button missing) and i'm looking at the priority / control registers for the B21.

Registers differ:

Code: Select all

             CPS1    CPS2
Base         800140  804140
ctrl  0x26   800166  804166
mask0 0x28   800168  804168*
mask1 0x2a   80016a  80416a*
mask2 0x2c   80016c  80416c*
mask3 0x2e   80016e  80416e*
palet 0x30   800170  804170

Priority mask seems unused on cps2 at those addresses, i think it is combined or handled different:

Code: Select all

 804166 : ---- ---- ---- --0- : BG0 enable (1= on, 0= off)
          ---- ---- ---- -1-- : BG1 enable (1= on, 0= off)
          ---- ---- ---- 2--- : BG2 enable (1= on, 0= off)
          ---- ---- ---s ---- : Starfield 1 enable (1=on, 0=off)
          ---- ---- --s- ---- : Starfield 2 enable (1=on, 0=off)
          --aa bbcc dd-- ---- : Priority related *

Also, the CPS-A registers are different and need to be patched as well. (= no OBJjects..)

Code: Select all

CPS1

	AM_RANGE(0x800100, 0x80013f) AM_WRITE(cps1_cps_a_w) AM_SHARE("cps_a_regs")  /* CPS-A custom */
	AM_RANGE(0x800140, 0x80017f) AM_READWRITE(cps1_cps_b_r, cps1_cps_b_w) AM_SHARE("cps_b_regs")    /* CPS-B custom

CPS2
	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 */

Anyway i patched all access to CPS-A into 804100 range, but i am still not seeing any objects
I'm sure i missed none, i have watchpoints set and all access is correct at this point for cps2 style registers.
Probably still some things left to correct at this point

i checked a few games, most of them are just writing 12CE into 804166 the whole time, but Punisher writes something else.

[Asure]

Probably missing this

Code: Select all

AM_RANGE(0x400000, 0x40000b) AM_RAM AM_SHARE("output")                                                      /* CPS2 object output */

Charles to the rescue:

The sprite generator registers are moved from 400000-40000F to FFFFF0-FFFFFF when the battery is dead.

But where does the sprite generator exist on cps-1..?

[leonardoliveira]

Actually, CPS2 is just a CPS1 with extra stuff added on the sprites hardware.

I have a hitch but it has to do with the second sprite layer CPS2 adds. I mean the CPS1 games could set the ranges for their graphics (see the first 10 bytes on the A chip registers) freely and not bother with it but CPS2 has an extra sprite generator piggybacked on top of the one on CPS-A/B chips (SPA and CIF on B board and SPB on A board, which actually sits between the video RAM and the CPS-B chip). That would probably cause some restrictions on the memory ranges that are actually usable.

So, I have this silly theory that all we're missing is init the SPA/SPB chips registers so they don't get in the way.


Daimakaimura has the layers around the 0x900000 area. Particular interest into 0x920000. I that's the address it puts OBJ RAM at.

[neocps1]

good work dudes

[leonardoliveira]

The writes at CPS-A registers 0x00-0x0B tell the video hardware which part of the video memory address ranges to expect writes from the CPU:

Code: Select all

Daimakaimura CPS-A boot write values:

800122 -> 000E	set video control
800100 -> 9200	set OBJ memory memory base address
800102 -> 9000	set SCROLL1 memory memory base address
800104 -> 9040	set SCROLL2 memory memory base address
800106 -> 9080	set SCROLL3 memory memory base address
80010C -> FFC0	set SCROLL1 X
80010E -> 0000	set starfield 2 Y (why?)
80010A -> 9105	set palette memory base address

Ingame CPS-A write values: (while in service mode)

80010A -> 9100  palette memory base address
800122 -> 400E	video control
800102 -> 9000	SCROLL1 memory memory base address
800104 -> 9040	SCROLL2 memory memory base address
800106 -> 9080	SCROLL3 memory memory base address
800100 -> 9200	OBJ memory memory base address
80010C -> 0000	SCROLL1 X
80010E -> 0000	starfield 2 Y
800110 -> 0000	SCROLL2 X
800112 -> 0000	SCROLL2 Y
800114 -> 0000	SCROLL3 X
800116 -> 0000	SCROLL3 Y

(loops over)

For sake of reference, I did see another game, with known different memory map, just to see what this is about:

Code: Select all

Final Fight CPS-A boot write values:

800122 -> 000E	set video control
800100 -> 9000	set OBJ memory memory base address
800102 -> 9080	set SCROLL1 memory memory base address
800104 -> 90C0	set SCROLL2 memory memory base address
800106 -> 9100	set SCROLL3 memory memory base address
80010C -> FFC0	set SCROLL1 X
80010E -> 0000	set starfield 2 Y (why?)
80010A -> 9140	set palette memory base address

Ingame CPS-A write values: (blank screen, while in service mode)

800100 -> 9000  OBJ memory memory base address
80010A -> 9140	palette memory base address
80010C -> 0000	SCROLL1 X
800110 -> FFC0	SCROLL2 X
800114 -> FFC0	SCROLL3 X
800118 -> 0000	starfield1 X
800118 -> 0000	starfield1 X (yep, two writes)
80010E -> 0000	SCROLL1 Y
800112 -> 0300	SCROLL2 Y
800116 -> 0700	SCROLL3 Y
80011A -> 0100	starfield1 Y
80011E -> 0100	starfield2 Y
800120 -> 0000	rowscroll matrix offset
800122 -> 000E	video control
(loops over)

A spoiler would be look the way SF Zero for CPS changer set up it's video memory, because it's a CPS1 game using CPS2 memory map.

Now, out to study a "sensible" way of "patching" the game.

[Asure]

We're missing some init of the sprite handler at least. This is from a CPS2 game (phoenix ver)



None of the cps-1 games do this..

A spoiler would be look the way SF Zero for CPS changer set up it's video memory, because it's a CPS1 game using CPS2 memory map.

Now, out to study a "sensible" way of "patching" the game.

For the input fixes on punisher, i just replaced the load to D0 with JMP mysub, and located mysub in a new 27C4096 'puniconv.06' so to say
When the 'fix' is done, it jumps back to original area in rom. Plenty of space there

Time for dinner now

[leonardoliveira]

I kept all the original code on my daimakaimura inputs.

Follow what the code does with the data it reads. It masks against some value? Does it rotate bits? Change the masking/NOP out the bit rotations/change the compare it does down there. Problem solved, no need to hook extra code.

Edit:

We're missing some init of the sprite handler at least. This is from a CPS2 game (phoenix ver)


None of the cps-1 games do this..

That is the init for the CPS2 specific sprites hardware. Set the CPS2 specific sprites layer X/Y placement and crashes the board when it's suicided. (you will learn about that when you try to load it on your real hardware. that's one of the things I often have to fix on the CPS2 sets before releasing them)

[Asure]

I figured there are no shortcuts :/

/*
I don't know if CPS2 ROM boards use PALs as well; since all games seem to be
well behaved, I'll just assume that there is no strong checking of gfx type.
(sprites are not listed here because they are addressed linearly by the CPS2
sprite code)
*/

And, from Layer, early on in the topic:

First, you should try comparing SF Zero CPS Changer with Zero CPS-2 to get some points to compare. Btw, in Zero CPS Changer, the Gfx are already lineary adressed as CPS-2 games too.

[jedpossum]

There is more than just SFZ cps changer to look at. There is also the Megaman Power Battle 1 versions on CPS1 and CPS2.

There are PALs only for the BG layers though. I just copied my gfx to other parts of gfx roms to make the backgrounds visible Hyper Fighting and fixed the code that wanted add since I didn't feel like building version of mame.

[leonardoliveira]

This is what I have for now:

Inputs - 100%
Sound - 100%

sprites - 0%

[zebow2002]

This has to be the most awesome thread I have followed in the last few years. I'm also a proud cps2 multikit owner and this would make it even more

[leonardoliveira]

Apparently I don't know how to turn on the sprites layer on CPS2. So doesn't the game (as it's a CPS1 game) and that's part of the problem.

I tried changing the sprite writes to the CPS2 dedicated OBJ memory and I can see (at the debugger) all the sprite writes reaching the OBJ memory but I simply can't get them to have any effect on the screen.

@neocps1: Man, when you were researching this, did you follow a similar path? There were similar issues on your work?

I picked Daimakaimura/Ghouls'n Ghosts particularly because it has no OKI ADPCM data, it also happens to use the CPS-B-01 "B-chip" which matches 1:1 with the CPS-B-21 used on the CPS2 (when on default battery less mode). I wasn't expecting it to be this hard... lol

[Layer]

You can see on his preview youtube vids of SF2CE that there were layers issues, some were missing and some were hiding the charas sprites.

Now, the prob is solved.

Btw, Varth is interesting too, the Gfx are adressed lineary too (see the pal).

[leonardoliveira]

So, the game put data on the sprite list memory (OBJ) then pulses a register to cause the graphics chip to latch it?(by latch, I mean copy the objects list to the real screen memory)

[Layer]

Maybe you have no sprites and missing scroll 1 coz you patched pal ctrl, layer ctrl and priority masks to $804XXX CPS-2 custom B regs.

[Asure]

804xxx is where they are 'supposed' to be on cps2. At least, that is an assumption made by looking at the cps2 games.
It could be a side effect of MAME since the emulator expects to be running a cps-2 game with linear addressing. There are still many points where mame falls short of the 'real thing' so to say.

Even if they are mapped at 8041xx there is still a mirror of these at base 0x800140 set up in the mame source, which i expect to exist on real hardware as well.
I made a few tests with hardcoded layer prio values (12CE, 12DE and so on) but sprites never became visible, so there is something else we are missing.

PALCTRL (800170/804170) is a decent hint though, as bit 0 controls page 0 which is sprites.
There is a mystery bit. CTRL (800166/804166) bit 0 is documented as 'possible rowscroll' in the source, but if you compare it against PALCTRL then bit 0 might be referring to the sprite layer.
Still, this seems odd, as the CPS2 games write 3F there, and 68000 uses LSB, so the last four bits are 3/2/1/0 = 1/1/1/1 = F. (Punisher writes 3F there too.)

[jedpossum]

You have to write Sprites into obj ram which is at 0x700000 and 0x708000 to get anything visible I remember thinking about doing hitboxes on my training mode hacks, but decided against it looking for space and no real good way to display them.

Here is an example of just doing a player axis

[Layer]

804xxx is where they are 'supposed' to be on cps2. At least, that is an assumption made by looking at the cps2 games.
It could be a side effect of MAME since the emulator expects to be running a cps-2 game with linear addressing. There are still many points where mame falls short of the 'real thing' so to say.

Even if they are mapped at 8041xx there is still a mirror of these at base 0x800140 set up in the mame source, which i expect to exist on real hardware as well.
I made a few tests with hardcoded layer prio values (12CE, 12DE and so on) but sprites never became visible, so there is something else we are missing.

PALCTRL (800170/804170) is a decent hint though, as bit 0 controls page 0 which is sprites.
There is a mystery bit. CTRL (800166/804166) bit 0 is documented as 'possible rowscroll' in the source, but if you compare it against PALCTRL then bit 0 might be referring to the sprite layer.
Still, this seems odd, as the CPS2 games write 3F there, and 68000 uses LSB, so the last four bits are 3/2/1/0 = 1/1/1/1 = F. (Punisher writes 3F there too.)

Mame video driver says that a few games boot with 0F pal value instead of 3F but that doesn't change the game, if you apply 3F instead of 0F at start up, you'll get a black screen instead of boot up checks and game version before the disclaimer... all erased, that's all.

Btw, you should take a look at SF Alpha CPS-2 decrypted 03 rom (03 CPS-2 program rom is equivalent to 23 rom for CPS-1), it still has unchanged mapping for layer ctrl and ctrl pal like CPS-1 games : $800166 (which appears 3 times), $800170 (3 times too)... and $804166 & $804170 which appear only 1 time (with 3F value before $804170) I guess for CPS-2 start up.

[leonardoliveira]

@Layer:
All scroll layers were active on my video:

scroll 3 (background)
scroll 2 (playfield)
scroll 1 (HUD)

Sprites missing.

Unless I am missing something, you could tell me about.

@jedpossum:

I have writes going to CPS2 objects area (0x708000) and writes there have no effect at all. There's RAM at that area and it holds the sprites data (it can be seen on the debugger) but there's no effect on the screen.

I tried a emulator which has screenshots function (nebula) and I could not see any sprites. (can disable all layers to see stuff underneath)

Edit: Nebula actually says "0 sprites active" so the game is not writing correctly to the control registers.