WIP: CPS 1.5 on CPS2 hardware

[RoberMC]

.
这就是我理解你的意思

Guys keep up the good work. Me, and i am sure a lot of people, are following with interest your progress... even if what you write reads sometimes like chinese

[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);
}

Also, this bit of code brings back some details. FE0000 'cache' for Progear rings a bell. 7000 and 7080 offsets also, if i dig into mame a bit further. (there's a prio part there too, holds values like 2354 2345 mostly.)
Gotta go out now, too little time to check atm.

http://read.pudn.com/downloads158/sourc ... er.c__.htm

[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);
}

Also, this bit of code brings back some details. FE0000 'cache' for Progear rings a bell. 7000 and 7080 offsets also, if i dig into mame a bit further. (there's a prio part there too, holds values like 2354 2345 mostly.)
Gotta go out now, too little time to check atm.

http://read.pudn.com/downloads158/sourc ... er.c__.htm

Code: Select all

UINT16 *cps_state::cps2_objbase()
{
	int baseptr;
	baseptr = 0x7000;

	if (m_objram_bank & 1)
		baseptr ^= 0x0080;

//popmessage("%04x %d", cps2_port(machine, CPS2_OBJ_BASE), m_objram_bank & 1);

	if (baseptr == 0x7000)
		return m_objram1;
	else //if (baseptr == 0x7080)
		return m_objram2;
}

[leonardoliveira]

This might be of interest:

http://cgfm2.emuviews.com/txt/cps2tech.txt

I would trust this more than mame sources references wise as these notes came from his observations of the bus and hardware signals. He actually poked registers and saw what happened with the board before writing that. But it is "hardware notes" so it can be incomplete.

Just something to add to our mix here.

[Asure]

Code: Select all

   if (baseptr == 0x7000)
      return m_objram1;
   else //if (baseptr == 0x7080)
      return m_objram2;
}

Punisher has this at 9000 and 9080, so mame would _never_ return sprites unless this is changed (baseptr starts out with 7000 on reset) list end with ff00 (>8000)
Megaman has proper lists at 7000 7080 etc. and ends this with 8000.
Megaman still writes 9000 and 9080 into 800100, and if by magic (ahem) there appears a sprite list at 0x700000. There are no writes to 0x700000 ever.
The sprite handler seems to read and write to 900000-92ffff still, but the writes end up at 0x700000.
If you look at 0x400000, you can see 0x7000 is set there (in megaman this is set to 7000 807D 1234(prio?) 0000 0040 0010)
This is from a crypted copy of megaman still.

A real CPS2 game like ddtodd does not touch 900000-92ffff by reading/writing to it, everything goes to 700000, and sprite list is there, ending with 8000.
Yoda (charles) notes "The sprite generator registers are moved from 400000-40000F to FFFFF0-FFFFFF when the battery is dead."
Note that ddtodd writes 7080 there, and mame cheats by using a mirror function for "AM_RAM AM_SHARE("output")"

In short, i think we do not need to worry about the cps_a and cps_b chips (mirrors exist and work) at this stage, but about the setup of 400000 / fffff0 and the bank swap bit (M_RANGE(0x8040e0, 0x8040e1) AM_WRITE(cps2_objram_bank_w) )

I think we're almost there. If your ghouls has no sprites, and the sprite list is at 0x900000, that might be the issue.

[leonardoliveira]

I already have ghouls writing it's sprites to 708000. But an extra write is needed to toggle the latching effect. That's the only thing I am missing.

What is happening on Rockman and SSF2 is that they have the sprites list built at 9xxxxx area (to not need to tamper with the game engine code) and a routine on the interrupt handler copies it to the CPS2 sprites area. The code you shown a few posts ago. I looked it up and followed the code a bit. So, copying Capcom itself here might be a elegant solution.

I did not catch yet what causes the hardware to acknowledge the contents of the sprite table as valid and move it to the screen (latch).

[Asure]

Can you show me a shot ingame of ghouls at 400000-40ffff? Mem region viewer, dropdown, it's near the bottom of the list.
it should look something like this:
7080 807D 2355 0000 00xx 00yy

xx and yy are of importance. example 01 ff there shows no sprites..(seems to be some sprite position offset) (0xfffff8 and 0xfffffa on dead_cps2)

http://dl.dropboxusercontent.com/u/6773 ... offset.png

[leonardoliveira]

About that, I have examples from when I was decrypting/making experiments with decrypted roms:







You will have sprites but without setting the stuff at 0x40000x/0xFFFFFx(on dead board) they will show at the wrong spot on the screen due to the XX/YY values being not set.

[Asure]

Try writing these words to 708000 - 708000E - 0 0 1800 0 0 1800 0
Just checked ddsom, ddtod they all do that. mmancp2u just writes zeroes there, but it does write.
The first 0x0F of the sprite list seems to be empty/used for something else on cps2. (On cps1 it seems to start at 0x00?)

From looking at megaman:
cps1: There appears to be a buffer 9000 and 9040 (800100 is toggled to 9000 / 9040 as the game runs each frame.). Sprite lists are indeed at 900000 and 904000.. games write to 904000.
Also cps1 has one hunk of 'gfxram' not a different area like cps2.

cps2: The sprite list sits at 708000 and 70000 (buffer) but is offset by 0x0f(?). The first set of 0xF is unclear to me what it is for. The games write to 708000.
It is setup once (7080 into 400000/FFFF0, and enforced with repeated writes of 7080 into 804100. In DDTODD at 0xAD6 there is a suspicious write to 8040e1 as well just before it!).

[Asure]

Also for this to ever run on real hardware, we need the keepalive.. (just watched this one: https://youtu.be/2q_qXGIj-jg?t=1432)

[leonardoliveira]

Actually no, we don't need the keep alive because all the keep-alive does is prevent the encryption from disabling itself.
If that was a issue, the decrypted games would not work because each game has a unique/different keep-alive instruction.


We're not running it encrypted so we don't need to worry about kicking the encryption watchdog.

[Asure]

Some notes for now.

CPS1 ends the sprite list with FF00 (example 0000 0100 0000 FF00)
CPS2 ends the sprite list with 8000 (example 0000 8000)

Megaman CPS1 starts the list at offset 0x0. It writes into 904000, the list gets copied (overwrite) to 9000 on latch.
Register at 800100 is 'abused' by writing 9040 then 9000

Megaman CPS2 starts the list at offset 0x20. It has all sorts of patching, and holds some magic numbers in ram(ff8000) but in the end the list is written to 704000, and copied to 700000 on latch.
Register at 400000 gets 9000 copied into it constantly. There is no 'toggle' of this register like i would expect (sprite list at 704000 needs to get copied to 700000)
I'm not sure if the 0x8040e0 - 0x8040e1 area is in this same chip . If it is, we can at least conclude that the CPS-A registers are being less used on CPS2.

Mame ensures the sprite stuff is drawn with the latch. The latch is toggled constantly. (byte 0 / 1 written to 8040E1)

Code: Select all

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

The game itself seems to use RAM at FF8060(latch,0/1) and FF8061 (00/FF) to signal if the sprite list is to be drawn. (latch toggle at 0x1188, A5 holds FF8000 + 60 = FF8060)
It also ensures the first 0x1F of the list remains filled with zeroes (see routine at 0x1439a) but i'm not sure why.

Leo: If you have the latch toggling in place/ported (8040e1 byte 0/1), and the prio stuff set up (0x400004, example word 1234) then mame should copy the sprites to screen as far as i can tell.
If not, offset the list 0x1F and fill the first 0x1F with zeroes . The code can be ripped from Megaman. (see 0x1188, 0x14392, or set watchpoint for FF8060,2,rw)

[Asure]

So, more analyzing of Megaman and Punisher today.

Punisher writes sprites to 900000 and 904000. Depending on the frame, it seems to push the list to 900000, and write 904000 to the 800100 cps-a register.
Then, it does the same a frame later, but pushes to 904000, and writes 9000 to 800100. This allows the sprites and animations to flow smoothly, as you do not see the writes in real time.
(It updates the list at 9000 as 9040 is visible, and 9040 as 9000 is visible, and so on.)

Megaman does not do this. It writes the list to 708000 all the time, and uses 8040e1 (0/1) to toggle. Register fffff0 is set to 7000 all frames. 800100 stays at 9000, but the sprite list is never pushed there.
Probably a remnant of the cps-1 code/setup. The two different "sprite handlers" can be seen below. (A5=FFFF8000 on both, -2478,A5 is read/poked into 800100 by the main loop of punisher.)



A5 is a pointer to ram at 0xffff8000 which the games use as a notepad. You can see punisher pushes 9000 or 9040 into ram depending on the state. This is later shuffled back into 800100. See the 'main loop' below:


Megaman writes the value of FF8060 into the 'latch' which magically copies stuff from 708000 to 700000. (It also clears out the first 0x1F of the list for some reason.)

And no, i still have no sprites for now. Might even be that the sprite format is different between cps1/cps2 or some oddball thing i don't get
Maybe neocps1 or others can shed some light onto this

[jedpossum]

One mistake, That's a byte being read from 0xFF8060 not the value 0xFF8060. Which is doing the flipping.

[Asure]

The more i'm looking at this, there might need to be a specific point/time when the system expects to be able to write to 8040e1.
Megaman (leo's decrypted set he posted before) has a second pointer in scratch ram at ff8061 ($61,A5) which it checks.
This byte is toggled from 00 to FF. Only when it is 00, a list of sprites is put into $708000.
You can see the check at 0x14006 in rom, if the value is FF the whole sprite part is skipped and the code jumps to 0x142e6.

If the value is zero, the code runs up to 0x142DC where eori.b #$1, ($60,A5) XOR's the value of FF8060, and st ($61,A5) sets FF8061 to 0xFF

Code: Select all

0142DC: eori.b  #$1, ($60,A5)
0142E2: st      ($61,A5)

Basically, this would mean we've filled the sprite list, and we do not want to do it again until 'condition x' occurs.
In this case we can see by the instruction at 0x14006, we will do another run once we find a zeroed byte at FF8061

The $61,A5 is set to zero at 0x122E in rom (you can see the CLR.B in the screenshot, check main loop for megaman.)
Why it is done exactly there, and at that point, i don't know. I'm learning 68000 each day, and my only run in with asm was back in the day on my C64.


Edit: There's A lot of differences from megaman cps1/cps2 as you can see..

[Asure]

Figured out what's wrong (but no solution yet). Sprite list data from cps1 -> cps2 differs or is wrong.
I have punisher code displaying sprites from Dungeons & Dragons.

Leo you have PM

Edit:
I compared the sprite lists between both megamans, and for the title screen, the list is below.
Mame has this for 'varth', there's a hint to look at it in the topic:
"Note that there are several known cases (nemo, cawing, 3wonders, varth, etc.) where 16x16 tiles are used for BOTH sprites and scroll2."


Guess we need to know where/how the ID's are mapped to data and compare the sprite data for some known sprite.
If anybody can shed some light on the tile id -> rom stuff

[jedpossum]

Figured out what's wrong (but no solution yet). Sprite list data from cps1 -> cps2 differs or is wrong.
I have punisher code displaying sprites from Dungeons & Dragons.

Leo you have PM

That makes no sense unless you didn't convert the graphics.

Edit: IIRC but I might have Width and Height wrong order.
Sprite format(CPS2) XXXX BBYY LLLL WHPP
X = X postion
B = Bank
Y = Y Position
L = Location
W = Tiles(Width)
H = Tiles
P = Palette and Flip

[Asure]

Yes i loaded DDSOM gfx roms in my driver Then manually added one entry on the sprite list. I get a proper sprite displayed. Sprite format must be off, bank layout might work different, or something else.
We need to figure out how sprites map to actual eprom / gfx area. (e.g. we need details like id 8027 = sprite at $F7BC00 in gfx. bogus example btw.)
Then we can compare data for two exact same megaman sprites and see how it differs between the two.

[jedpossum]

I don't have Punisher but the title screen seems like a good place to start cause the giant logo usually is a sprite.

Edit: You really shouldn't need to switch the banks. Since, none of the gfx roms on cps1 went past 4 megabytes(0x10000 in 16x16 tiles) unless Capcom did a conversion and left the first 4 megabytes as blank to show it had more room.

[Asure]

Manual sprite entry into 0x700000 works fine with proper values.
Sprites are there, they are just transparant and probably in the wrong screen positions as x/y offset might not be taken into account.

More soon. Sleep needed!