WIP: CPS 1.5 on CPS2 hardware
- undamned
- Please Continue...
- Posts: 92
- Joined: September 3rd, 2009, 9:24 pm
- Location: Phoenix
- eBay: undamned
- Initials: UND
Re: WIP: CPS 1.5 on CPS2 hardware
Nice, Leo! Very exciting!
-ud
-ud
"Sin and death's got the whole world gettin' illa, but I praise God for the Blood Spilla."
-
- Posts: 573
- Joined: April 17th, 2013, 5:16 pm
- Location: Netherlands
- eBay: asure_nl
Re: WIP: CPS 1.5 on CPS2 hardware
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:
Priority mask seems unused on cps2 at those addresses, i think it is combined or handled different:
Also, the CPS-A registers are different and need to be patched as well. (= no OBJjects..)
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.
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
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 *
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 */
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.
-
- Posts: 573
- Joined: April 17th, 2013, 5:16 pm
- Location: Netherlands
- eBay: asure_nl
Re: WIP: CPS 1.5 on CPS2 hardware
Probably missing this
Charles to the rescue:
Code: Select all
AM_RANGE(0x400000, 0x40000b) AM_RAM AM_SHARE("output") /* CPS2 object output */
But where does the sprite generator exist on cps-1..?The sprite generator registers are moved from 400000-40000F to FFFFF0-FFFFFF when the battery is dead.
- leonardoliveira
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: WIP: CPS 1.5 on CPS2 hardware
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.
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.
-
- Banned
- Posts: 83
- Joined: May 5th, 2012, 8:55 am
- Location: France
Re: WIP: CPS 1.5 on CPS2 hardware
good work dudes
- leonardoliveira
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: WIP: CPS 1.5 on CPS2 hardware
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:
For sake of reference, I did see another game, with known different memory map, just to see what this is about:
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.
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)
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)
Now, out to study a "sensible" way of "patching" the game.
-
- Posts: 573
- Joined: April 17th, 2013, 5:16 pm
- Location: Netherlands
- eBay: asure_nl
Re: WIP: CPS 1.5 on CPS2 hardware
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..
When the 'fix' is done, it jumps back to original area in rom. Plenty of space there
Time for dinner now
None of the cps-1 games do this..
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 sayA 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.
When the 'fix' is done, it jumps back to original area in rom. Plenty of space there
Time for dinner now
- leonardoliveira
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: WIP: CPS 1.5 on CPS2 hardware
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:
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:
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 wrote: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..
-
- Posts: 573
- Joined: April 17th, 2013, 5:16 pm
- Location: Netherlands
- eBay: asure_nl
Re: WIP: CPS 1.5 on CPS2 hardware
I figured there are no shortcuts :/
And, from Layer, early on in the topic:/*
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)
*/
Layer wrote: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.
-
- Please Continue...
- Posts: 22
- Joined: June 25th, 2015, 9:37 pm
- Location: WV
- Initials: JLH
Re: WIP: CPS 1.5 on CPS2 hardware
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.
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
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: WIP: CPS 1.5 on CPS2 hardware
This is what I have for now:
Inputs - 100%
Sound - 100%
sprites - 0%
Inputs - 100%
Sound - 100%
sprites - 0%
-
- Please Continue...
- Posts: 14
- Joined: June 16th, 2013, 8:21 pm
- Location:
Re: WIP: CPS 1.5 on CPS2 hardware
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
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: WIP: CPS 1.5 on CPS2 hardware
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
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
-
- Posts: 162
- Joined: March 6th, 2013, 5:38 pm
- Location: France
Re: WIP: CPS 1.5 on CPS2 hardware
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).
Now, the prob is solved.
Btw, Varth is interesting too, the Gfx are adressed lineary too (see the pal).
- leonardoliveira
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: WIP: CPS 1.5 on CPS2 hardware
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)
-
- Posts: 162
- Joined: March 6th, 2013, 5:38 pm
- Location: France
Re: WIP: CPS 1.5 on CPS2 hardware
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.
-
- Posts: 573
- Joined: April 17th, 2013, 5:16 pm
- Location: Netherlands
- eBay: asure_nl
Re: WIP: CPS 1.5 on CPS2 hardware
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.)
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.)
-
- Please Continue...
- Posts: 22
- Joined: June 25th, 2015, 9:37 pm
- Location: WV
- Initials: JLH
Re: WIP: CPS 1.5 on CPS2 hardware
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
Here is an example of just doing a player axis
-
- Posts: 162
- Joined: March 6th, 2013, 5:38 pm
- Location: France
Re: WIP: CPS 1.5 on CPS2 hardware
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.Asure wrote: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.)
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.
Last edited by Layer on June 29th, 2015, 11:58 pm, edited 1 time in total.
- leonardoliveira
- Please Continue...
- Posts: 692
- Joined: August 30th, 2012, 5:53 am
- Location: Brazil
- Initials: leo
Re: WIP: CPS 1.5 on CPS2 hardware
@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.
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.