gaiden: scroll info/issue

[jwestfall69]

Hi

I've been working on porting a diag over to ninja gaiden hardware and want to report a few inconsistencies between hardware and mame.

I was originally working on a tile viewer for txt/bg/fg tiles and using mame to get stuff lined up in a table view

ie:

however when running this same code on hardware both bg/fg tiles are offset down quite a bit

txt layer seems ok

I wrote a couple tests to allow writing values to the scroll registers to see what happens

mame:
https://github.com/user-attachments/assets/cb4e590e-321f-4795-a380-c20a21f23e27

hardware:
https://github.com/user-attachments/assets/8ea8d2b6-0d90-4961-bed7-c0dea5a9a1b4

In both videos I zero out both of the bg y scroll/offset registers, then test setting bit 0 on both registers. Aside from the obvious difference in the bg tile location, there is a difference in what setting the bits does.

On hardware setting either of the bits causes the bg tile to move up 1 pixel.
In mame setting the bit in the offset y register cause the bg tile to go down 1 pixel, and setting it on the scroll y register the bg tile to go up 1 pixel.

Additional info from testing on hardware:

• both y scroll/offset registers appear to be masked with 0x1ff
• the x scroll register appears to be masked with 0x3ff
• the word at 0x7a300 acting like a x offset shifting the tile to the left by the value (also masked at 0x3ff)

I'm still messing around figuring out what 0x7a310 is, but it looks like the lower 3 bits are related to the tile size that gets used on the tile layer
0x3 = 8x8
0x4 = 16x16
0x6 = 16x32 (tall, same 16x16 tile doubled up)

here is a copy of the test rom

mad-gaiden-scroll-1.zip

[jwestfall69]

I also poked around at the words at

0x7a000
0x7a002
0x7a004
0x7a006

I had a bg +fg tile and sprite on my test screen and messed with the values to see what effect it had. The bg/fg/sprite were all shifted down about the same as noted in my previous comment. I'm unclear if this is something with mame or perhaps I'm not initializing something on hardware thats causing difference. Just weird that txt layer isn't off too. Anyways

0x7a000 no effect changing bits
0x7a002 shift the location of the sprite, but the direction is the opposite between mame vs hardware. Mame moves the sprite down, while hardware moves it up (0xff mask)
0x7a004 = no effect changing bits
0x7a006 = unsetting bit 0 caused the sprite to disappear, none of the other 15 bits seemed to do anything

[mamehaze]

Fwiw I seem to remember there being different hardware revisions of this, some where screen flipping works as expected and some where it doesn't. Could be these screens work on some PCBs but not others too?

[angelosa]

mame/src/mame/tecmo/gaiden.cpp

Lines 1016 to 1024 in ad43ead

	map(0x07a104, 0x07a105).w(FUNC(gaiden_state::txscrolly_w));
	map(0x07a108, 0x07a109).w(FUNC(gaiden_state::txoffsety_w));
	map(0x07a10c, 0x07a10d).w(FUNC(gaiden_state::txscrollx_w));
	map(0x07a204, 0x07a205).w(FUNC(gaiden_state::fgscrolly_w));
	map(0x07a208, 0x07a209).w(FUNC(gaiden_state::fgoffsety_w));
	map(0x07a20c, 0x07a20d).w(FUNC(gaiden_state::fgscrollx_w));
	map(0x07a304, 0x07a305).w(FUNC(gaiden_state::bgscrolly_w));
	map(0x07a308, 0x07a309).w(FUNC(gaiden_state::bgoffsety_w));
	map(0x07a30c, 0x07a30d).w(FUNC(gaiden_state::bgscrollx_w));

My 2 c.:
It may be possible that the "offset" registers requires a "timing window" where writes are valid and discarded otherwise.
Also the hookup is technically wrong: the "offset" should use set_scrolldx/dy (tilemap origin), not negate the existing scroll values.

[Gurudumps]

There's no different hardware. If this refers to Tecmo Ninja Gaiden / Wild Fang / Tecmo Knight / Raiga etc. They all run on the same identical PCB. The only difference is some of the MCUs and supporting components (crystal etc) are not populated. I've converted this same hardware to run all those games and I know for sure the hardware is identical on all the games listed above.
Of course there can be software differences where it uses the hardware in different ways which we have all seen many times with systems that run different games. But this is nothing to do with changed hardware, it's just software using parts of the hardware that some other games don't use or use differently.