Skip to content

Commit

Permalink
konami/xmen.cpp: worked around MT08470
Browse files Browse the repository at this point in the history
  • Loading branch information
@Osso13
Osso13 committed Oct 28, 2022
1 parent 28d2fc3 commit aefb991
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion src/mame/konami/xmen.cpp
View file
Expand Up @@ -730,7 +730,9 @@ void xmen6p_state::xmen6p(machine_config &config)
// video hardware
config.set_default_layout(layout_dualhsxs);

SCREEN(config.replace(), m_screen, SCREEN_TYPE_RASTER);
config.device_remove("screen");

SCREEN(config, m_screen, SCREEN_TYPE_RASTER);
m_screen->set_refresh_hz(60);
m_screen->set_vblank_time(ATTOSECONDS_IN_USEC(0));
m_screen->set_size(64*8, 32*8);
Expand Down

9 comments on commit aefb991

@happppp
Copy link
Member

@happppp happppp commented on aefb991 Oct 28, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It means there is a bug with config.replace? (I mean in the MAME core)

@angelosa
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so, in theory setting m_screen->set_screen_update(FUNC(xmen6p_state::screen_update<0>)); should be enough.

Some observations:

  1. I think this function is unsafe on cliprect:

    mame/src/mame/konami/xmen.cpp

    Line 267 in aefb991

    for (int y = 0; y < 32 * 8; y++)
  2. each screen should update every other frame as per Run N Gun / Soccer Superstars, as also observed by the note on top.
  3. I'm surprised this doesn't use CCU(s) / k053252_device, may been released just before Hexion but can't test log atm to be sure.

@happppp
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The config.replace thing does not break the screen_update call.
It could be something with src/emu/divideo.

@firewave
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rungund (the dual screen version) is not drawing safely either it seems - https://mametesters.org/view.php?id=7543

@cuavas
Copy link
Member

@cuavas cuavas commented on aefb991 Nov 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this replacing the screen in the first place rather than just reconfiguring it? This strikes me as the kind of thing that “fixes” it by coincidence while the underlying issue is still present.

@happppp
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already tried that, it causes the same problem.

@cuavas
Copy link
Member

@cuavas cuavas commented on aefb991 Nov 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hence why it strikes me that this is likely just burying the real problem rather than actually fixing it. I think @firewave might be onto something with memory corruption.

@angelosa
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized it uses screen_vblank from second screen, while referencing first screen for timing ...

mame/src/mame/konami/xmen.cpp

Line 279 in aefb991

// my lefts and rights are mixed up in several places..

@happppp
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the order of vblank handlers changes.

with device_remove:
scanline 240:
update "screen"
update "screen2"
vblank callback "screen"
vblank callback "screen2"

without device_remove:
scanline 240:
vblank callback "screen2"
update "screen"
update "screen2"
vblank callback "screen"

Please sign in to comment.