kicker: in-deep hardware differences

[jotego]

• Scan line available to the game
  The device KONAMI_085 is used to write the vertical scroll position (see MAME driver). But the software also reads from it using memory address $200 to $2FF.
  Currently MAME returns a dummy value for that read. From the circuit connection (see device F13 in my extracted schematics here), the circuit can only return the scan line or the scrolled position.
  I wrote a small piece of M6809 code to find out what reading to that device produced. You can check that code here. I burned that program to an EEPROM and hooked to a real board. I found out that the device returns the current scan line when read. The actual memory address used to read is not important, as those A bus bits don't go to the device.
• Refresh rate and screen size
  Also, the real game has a refresh rate of 60.5Hz, not 60Hz as shown in the driver. And the screen resolution is 256x216 and not 256x240 as seen in the driver. You can check the measurements here.
• Real sprite table
  The sprite data does not work as the MAME driver assumes. If you check the schematics above, you'll see that the GFX hardware does not have access to the memory locations used by MAME to draw the sprites. So the MAME driver is currently using an internal game table to draw the sprites.
  The sprites are in memory $3000, 4 contiguous bytes each and a total of 24 sprites (as more cannot be written due to the clock speed) -- see updated post below--

I don't have the needed experience in MAME to fix the driver. I hope another contributor can implement these changes.

256x216 would result in graphics being cut off, I don't see how that can be correct. The driver is set to 256x224, not 256x240 video output on the text layer already extends to the extreme edges, there's nowhere to cut an extra 8 pixels from.

as the screen is rotated 224 is the horizontal part of the screenshot
https://i.postimg.cc/Xv0ThJz0/0001.png

cutting 8 pixels off would destroy either the P1 text or the P2 score

if that is genuinely what you're getting I suspect the PCB could be faulty.

[jotego]

I think 224 is correct indeed. From the vertical blank duration I calculate 220 visible lines, but the oscilloscope has its limitations and 220 is not a multiple of 8, so 224 indeed.

[paulb-nl]

More accurately the refresh rate calculation is 6144000÷384÷264 = 60.606060Hz. That's the pixel clock speed I found in the comments of Jotegos core.

Vblank close up 2 says Vblank is 2.50ms which is exactly 40 lines. 60.6060Hz & 264 lines = 0.0625ms per line.

[angelosa]

Hmm, it's not 224 with +16 border overscan then?
Just a curiosity, not that it matters for MAME since we don't really have real screen geometries unless custom video code is added, which is generally not done unless border info is meaningful (-> not black).

[smf-]

So the MAME driver is currently using an internal game table to draw the sprites.

This has now been fixed. There is some question on the y coordinate, both with flipped and non-flipped screen.

I've made non-flipped behave the same as the previous code. However it was previous broken with flipped screen & so I've made it look the same as the non-flipped. This requires the sprite y coordinate to be adjusted by 1 pixel when flipped.

Is there anything that explains that? I did wonder if it could be the tile layer that isn't aligned properly.

[jotego]

When the screen is flipped it doesn't appear in the same position in the monitor. Maybe that explains what you face.

The flip mode is implemented in a strange way in this hardware, partly in hardware and partly in software (whereas most arcade systems just have a "flip" signal going to the video hardware to do the flip).

[jotego]

While working on a related title, I noticed that I had written the sprite information wrong. The schematics and the verilog implementation were correct, I just wrote it wrong here: the 4-byte sprite information is split between the two sprite RAM banks, 2 bytes in each bank. Apologies for the bad writting.

[smf-]

Thanks, I already noticed https://github.com/mamedev/mame/blob/ec401fec51d46fdc0ea6e8081c082730d01aa1c5/src/mame/drivers/shaolins.cpp#L143 The hard work was finding that MAME was wrong, I appreciate any reports on similar issues.

…

On 19/12/2021 08:12, Jose Tejada wrote: While working on a related title, I noticed that I had written the sprite information wrong. The schematics and the verilog implementation were correct, I just wrote it wrong here: the 4-byte sprite information are split between the two sprite RAM banks, 2 bytes in each bank. Apologies for the bad writting. — Reply to this email directly, view it on GitHub <#8954 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGVYYXFETNJAT6P44PO2S3URWHYDANCNFSM5JW755IA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[jotego]

A couple more things:

• This sprite hardware doesn't latch the raster line count during blanking. What that means is that by the time the sprite hardware it reaches a certain sprite count, the raster line has already changed and that will shift the reamining sprites in the same line by one pixel. That is why the Yie Ar Kungfu driver has this hack. This needs be added to Kicker too
• Could you please double check that the sprite draw order is correct? I think it is in the latest version of the file, but please compare it with these photos from the original PCB:

The main character is behind while alive

And on the front when dies

[StHiryu]

Tested in current mame 0.239 and is the same than in the images provided.

[angelosa]

Split this issue into three tasks.
Unless I'm mistaken all three issues have been addressed by ec401fe , 7d753ec , 9d1d94f

and this should be added to OP message too:

This sprite hardware doesn't latch the raster line count during blanking. What that means is that by the time the sprite hardware it reaches a certain sprite count, the raster line has already changed and that will shift the reamining sprites in the same line by one pixel. That is why the Yie Ar Kungfu driver has this hack. This needs be added to Kicker too