wrong refresh rate in k052109 based games

[jotego]

MAME version

0.248

System information

Ubuntu Mate 20.04

INI configuration details

No response

Emulated system/software

No response

Incorrect behaviour

Konami games based on the K052109 use an incorrect refresh rate. It seems to vary between 59 and 60Hz values, although I have not tested all the games. Even if the value was wrong, it should be the same in all games, but there is no consistency either. Super Contra has 59.17, TMNT has 60 and Ajax has 59.1856

Expected behaviour

@furrtek extracted the logic for this custom chip and made a verilog model for it. I have simulated it (see the attached file with gtkwave) and measured the frame rate, which matches the TRIG_IRQ signal, to be 16.8957297ms or 59.1865Hz. The horizontal rate is 64us (15.625kHz).

test.zip

Steps to reproduce

No response

Additional details

No response

[cuavas]

What are the actual timings and how are they derived from the master clock? Just changing the refresh rate doesn't fix it properly.

[jotego]

The master clock for video is 24MHz, from which a 6MHz pixel clock is derived. The H/V counters do not travel around the board but instead each video chip regenerates them internally. From the counters, the sync and blank signals are derived.

• Hcnt from 20 to 19F. 20-60 = HB (64 pixels). 40-5A = HS
• Vcnt from F8 to 1FF. 1F0 -> F8 -> 110 = VB. F8-100 = VS

Note that there are 240 active lines, despite some drivers (like Aliens') reporting 224. I do not know if any game displays active pixels in those two extra rows but as far as I can see with the two tile mapper chips (k052109/k051962) the hardware can display tiles over 240 lines. I wonder if the sprite hardware set the limitation for drawing only in 224 lines, or whether it was an artist choice (like movies nowadays cutting off the image height by giving up resolution).

Let me know if you need more information.

[angelosa]

Gonna assume that HW just throws vblank at 240, and 224/240 difference is just overscan: somehow the HW either draw border lines or draws whatever garbage, with the assumption that service mode cross hatch dictates to the operator the intended safe area.

[cuavas]

So you’re saying total 264 lines and 384 dots per line from a 6 MHz dot clock? That gives 15.625 kHz horizontal and 59.18560606… Hz vertical, which is definitely in range for a standard resolution monitor. 83.3333% horizontal active is a bit higher than some other games (e.g. the Psikyo games are about 70%), but not implausible.

Gonna assume that HW just throws vblank at 240, and 224/240 difference is just overscan: somehow the HW either draw border lines or draws whatever garbage, with the assumption that service mode cross hatch dictates to the operator the intended safe area.

This is Konami – I wouldn’t put it past them to have logic to suppress the other sixteen lines on some games.

[galibert]

Konami gx 288x224 is CLK_6M, 384, 49, 49+288, 264, 15, 15+224, which matches quite a bit.

IIRC the gx doc we have says that programming that is view-layout compatible with older konami games.

OG.

On Mon, Apr 17, 2023 at 5:04 PM Vas Crabb @.***> wrote:

So you’re saying total 264 lines and 384 dots per line from a 6 MHz dot clock? That gives 15.625 kHz horizontal and 59.18560606… Hz vertical, which is definitely in range for a standard resolution monitor. 83.3333% horizontal active is a bit higher than some other games (e.g. the Psikyo games are about 70%), but not implausible.

Gonna assume that HW just throws vblank at 240, and 224/240 difference is just overscan: somehow the HW either draw border lines or draws whatever garbage, with the assumption that service mode cross hatch dictates to the operator the intended safe area https://en.wikipedia.org/wiki/Safe_area_%28television%29.

This is Konami – I wouldn’t put it past them to have logic to suppress the other sixteen lines on some games.

— Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/11118#issuecomment-1511544235, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACGSF4JJMHYJ3VH7LHCSCPDXBVLZBANCNFSM6AAAAAAXAV72X4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ghost]

worth noting that Aliens still has rather bad sprite flicker in places in MAME due to update timing issues (or some kind of sprite buffer?)

[jotego]

There is a DMA logic in the original chips that can be disabled with the chip MMR configuration. The CPU also checks whether the DMA is done before updating the sprite table. That may be what's missing in MAME's implementation. We can take this to a different issue if you need details about it.

[jotego]

I think the wrong refresh and blanking is what causes the Super Contra (scontra) wrong row of ground at the top of the sky in the first scene:

MAME 0.251

instead of

My FPGA implementation

Original in YT.

Note that as the game is vertical, that row is actually the left of the horizontal screen.

[paulb-nl]

This video of original Super Contra PCB shows the ground at the top. https://youtu.be/7uKfUUomRlY?t=11

The screenshot of your implementation shows the last tile row is repeated at the bottom.

[jotego]

This video of original Super Contra PCB shows the ground at the top. https://youtu.be/7uKfUUomRlY?t=11

The screenshot of your implementation shows the last tile row is repeated at the bottom.

You are right. Thank you for providing that better reference.