Viewing Issue Advanced Details [ Jump to Notes ] [ View Source: gberet.c ]
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
03600 Gameplay Minor Always 2009-12-24 13:27 2012-01-20 08:02
Tester Haze View Status Public Platform
Assigned To hap Resolution Fixed OS
Status [?] Resolved   Driver gberet.c
Version 0.135u4 Fixed in Version 0.144u7 Build
Summary 03600: gberet: 30fps framerate seems abnormal
Description gberet is runs at 240x224 resolution, and is set to output a framerate of 30fps.

This seems abnormal, even if it gives the correct gameplay speed.

I wonder if it's actually missing some interrupt masking, and should run at 60fps, but with an interrupt every other frame? The other game on the same hardware (mrgoemon) is set to 60fps output, and seems normal. The bootleg is also set to 60fps.

can the correct output frequency be verified on an original board?
Steps To Reproduce
Additional Information
Flags Verified with Original
Regression Version
Affected Sets / Systems gberet
Attached Files
  

- Relationships
related to 04621Confirmed ironhors: 30fps framerate seems abnormal 

-  Notes
User avatar (05304)
Haze (Developer)
2009-12-24 13:27

 I created this because I'd like to see an original measured reference for it.
User avatar (05333)
aaron (Developer)
2009-12-28 08:46

 It's definitely wrong, it should have the same refresh rate as other games from the same era. The real question is why does it run so fast at that rate?
User avatar (05344)
Kale (Administrator)
2009-12-29 21:20
edited on: 2009-12-29 21:28

 fwiw, irq 0 controls the game speed, NMI controls game logic like reading the system port, this event happens for every 8 NMI triggered, check PC=0x8a onward.
User avatar (05351)
Kold666 (Developer)
2009-12-31 13:00

 I have both Green Beret and Jail Break. What should I check?
User avatar (05352)
Kold666 (Developer)
2009-12-31 13:13

 Vsync is 60.60hz
User avatar (05353)
Kale (Administrator)
2009-12-31 15:41

 ironhors has the same issue, do you have it?
User avatar (05356)
Kold666 (Developer)
2010-01-01 11:39

 unfortunately not
User avatar (05391)
Mamesick (Senior Tester)
2010-01-05 06:56

 1 NMI call for every 32 scanlines. 1 IRQ0 for every 8 NMIs. Though the game is still too fast at 60.60 fps. I fixed it using:
	MDRV_CPU_PERIODIC_INT(irq0_interrupt, 30)

where irq0_interrupt is:
static INTERRUPT_GEN( irq0_interrupt )
{
	gberet_state *state = (gberet_state *)device->machine->driver_data;

	if (state->irq_enable)
		cpu_set_input_line(device, 0, HOLD_LINE);
}

Then consequentially:
static TIMER_DEVICE_CALLBACK( gberet_scanline )
{
	gberet_state *state = (gberet_state *)timer->machine->driver_data;
	int scanline = param;

	/* An NMI interrupt is generated every 32 scanlines */
	if (state->nmi_enable)
	{
		if (scanline % 32 == 0)
		{
			cputag_set_input_line(timer->machine, "maincpu", INPUT_LINE_NMI, PULSE_LINE);
		}
	}
}

etc. etc. This works fine but seems a bit too hacky? Notice that for the bootleg and Mr.Goemon you have to use the value 60 in the periodic interrupt or the games will be too slow.
User avatar (05394)
Haze (Developer)
2010-01-05 08:47

 I think it's hacky. You CAN slow the games down by overloading them with NMIs, but given what the NMI routine does it seems highly unlikely that it's how the hardware works. (and it will introduce much more severe slowdowns later in the game)

It's more likely some kind of IRQ masking that causes the IRQ to only fire every other frame in Green Beret.
User avatar (06801)
Kale (Administrator)
2010-10-25 01:00

 Uhm ... raw guessing ...

Maybe this HW has huge waitstate penalties? How to measure them on a real PCB?
User avatar (08053)
haynor (Tester)
2012-01-20 08:02

 This remind me another hardware (driver) from that era - cischeat.c
Should be also 60 Hz ?