WIP: CPS 1.5 on CPS2 hardware

[KmanSweden]

I feel sooo stupid reading this.. Makes me angry that I can't contribute to this.

Good work guys.

[Asure]

After reading this whole thread several times again, jedpossum's comment on Super Street Fighter2 Turbo about it being designed to play identical as possible to the original Street Fighter 2 CE/Turbo, I looked how it draws it's sprites and it WAS ACTUALLY DRAWING it's sprites backwards. Because it has a CPS1 engine, that game might be a real source of information for this project.

As everyone can see on the pictures Asure's idea of drawing the sprites list upside down kind of almost work.

But for that to work I had to disable the code which detects the sprite list end. Also there's some issues with the data copy. I am not sure if it's due to my algorithm being crap or if it's because I have the sprite list end check disabled.

Another thing I just implemented was use the data the game writes to the CPS-A register 0x800100 as the toggle of odd/even for the sprites double buffer. Currently I only copy the sprite data from 0x900000 but I plan on implementing another branch of code to copy from 0x904000. I am not sure if that's really important

Well, at least I have some progress...

Great work Leo, good to see my idea seems to be solid!
Does the priority actually work, i.e. can you walk 'in front' or 'behind' enemies now? It's hard to tell from the screenshots if that part works as well

Without the buffered sprites, the framerate of the sprites drop in half, and you get about 1 pixel lag/smear for half a frame. i.e. a sprite of 1x1 pixels moving right, will be 2x1 pixel for half a frame.
Neocps1 had this effect in (some) of his videos as well

[leonardoliveira]

Here's the video for you to have a idea of how it is like:

[Asure]

Holy sh1t that looks perfect except for the end-of-list marker! You're on fire!

[leonardoliveira]

I might have an acceptable solution for the double buffering:

I am copying the value the game want to write to 0x800100 then I rotate it arithmetically eight bits to left. I use that as the source address for the sprites list copy so it reads from both buffers alternating as the game commands it to.
Because writing to 0x8040E0 swaps the CPS2 sprite RAM page around I can keep using 0x708000 (the board is supposed to draw from 0x700000) I only toggle 0x8040E0 after the sprites have been copied.

That made Daimakaimura sprites scroll as smooth as they're supposed to.

Edit: Youtube video

[Braintrash]

There is for sure a very nice progress.

[Asure]

Wow looks smooth as butter now leo!
The trashed sprite leftovers I think are only from the missing end-of-list marker I think

[leonardoliveira]

The problem is, if I draw sprites backwards, the game is filling the sprite memory with end of sprite marks. That fills the sprites queue in MAME resulting in no sprites being shown.

I don't know what is happening, but on the real board it doesn't boot. I believe it's trying to write to a memory area with no /DTACK signal and that stalls the CPU. It could also be another thing.

I don't think the real hardware has a "sprite queue" so it would not spend sprite slots with sprite list end marks. So if I can discover why it isn't booting on the real board I could test how the upside down sprite list would behave. I know it's not adequate for MAME as it makes MAME skip drawing the sprites.

That's happening because I'm trying my best at avoiding mod the actual game engine. For example I tried to mod the control input code and that broke a lot of things. Putting an automated "input translation" routine at the VBLANK code was a pretty time saving solution.

Now back to work.

[Asure]

Did you patch out the C board test, or change it to what MAME expects? It's right at the beginning, i forgot where exactly, but they read a 8001xx register and compare it. Not that i have the game booting here, but it might be a showstopper.

[leonardoliveira]

Did you patch out the C board test, or change it to what MAME expects? It's right at the beginning, i forgot where exactly, but they read a 8001xx register and compare it. Not that i have the game booting here, but it might be a showstopper.

Code: Select all

000578: 4E70                       reset
00057A: 13FC 0080 0080 0030        move.b  #$80, $800030.l
000582: 4E71                          nop
000584: 4E71                          nop
000586: 4E71                          nop
000588: 4E71                          nop
00058A: 4E71                          nop
00058C: 4E71                          nop
00058E: 4E71                          nop
000590: 13FC 0000 0080 0030  move.b  #$0, $800030.l   ; toggle cloin lock
000598: 3439 0080 014E          move.w  $80014e.l, D2       ; load CPS-B-xx version registe
00059E: 0242 FC3F                  andi.w  #$fc3f, D2
0005A2: 0C42 0C00                  cmpi.w  #$c00, D2                ; compare with 0x0C00
0005A6: 6600 0102                  bne     $6aa
0006AA: 60FE                          bra     $6aa                          ; freeze program

I patched the checking code out.

[VectorGlow]

Fascinating thread, well done to those who have put a lot of work into this. Very impressive.

[undamned]

Keep up the nice work guys! Playing Punisher, Cadillacs, and more on CPS2 will be amazing!
-ud

[Alpha1]

I just wanted to say "YOU GUYS RULE"

[Asure]

Just a quick update, i've got a few other projects and real life eating away at my time so have been unable to debug with real hardware for now. I'm restoring a Naomi into NNC as well, and busy days at work leave me ending up drained, and not feeling like i want to spend more time behind my pc right now
Also i discoverd both 'Stitchers' and 'Mr. Robot' tv series.. I would highly recommend both of these, in fact, everyone should go watch Mr. Robot

Anyway, for the game not booting with the sound cpu program, i guess we could copy how a 'real' cps2 game starts up. They seem to delay a bit on the 68k side. Running with a normal cps2 sound program instead of the Punisher sound prog could rule out a problem with the 68k side or z80 side early on. Also the ZN2 sound test programs Leo made do not seem to suffer from this issue. It's just a matter of no time on my side .. sorry

Also, for fixing the end of sprite data, we could just offset the write 16 bytes in the original code, and add 0000 8000 0000 0000 at the start just once. When the sprite table is copied to cps2 style and flipped, there will be and end marker at the end. It would require a mod in the original code though.

[leosmendes]

Good Work

[monouchi]

Awesome work and I am saying like kmansweden that I wish I could help.

[jedpossum]

Been awhile, since I posted fixing my pc and procrastination. But.
While messing around with the SFA3 Sample version. I got this to show it's face

If you look back a few pages ago when I said there was dip switches on cps2 those zeroes line up with that input test.

So I just traced back on what wrote those zeroes.

Code: Select all

00159C: 2039 0080 40B0             move.l  $8040b0.l, D0
0015A2: 4680                       not.l   D0
0015A4: 2B40 01C0                  move.l  D0, ($1c0,A5)
0015A8: 4E75                       rts

So that kludge to make XM:CotA run is actually looking for dip switch inputs.
Enabling them adds a ton of debug data and access to tools for SFA3 sample at least.

[leonardoliveira]

I was complaining to mess/mame developers about the pullup resistors on all Capcom boards and how kludges would be unnecessary if they implemented "open bus defaults to '1' " instead of the current behavior where open bus defaults to '0'. But hey turns out it helps to show these "details".

So basically, the kludge is the debug dip switches address?

For example, when I was modifying Punisher inputs for CPS2 I found out that the game checks unused bits on the coinage/start buttons input address and if they're 0 it enables all the hidden debugging stuff you made a cheatcode to enable...

It's possible that all other CPS1 games have similar checks to detect being run on the development hardware and enable debugging features.

[jedpossum]

Yeah the kludge_r is the dip switch address 0x8040B0.

The debug enable switch on SFA3 Sample is the very last one.
Makes the Dipswitch inputs appear in input test as well gives the more detailed qsound test as well access to the secret menu.
Here I have the Hit Box and Enable switch on


Most games has the debug stuff removed completely just lucky enough to find a beta with it still.

[Layer]

Nice finds

Btw, it seems MegaMan Power Battle Sample Ver. has no debug secret menu.