Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
03600 Gameplay Minor Always Dec 24, 2009, 13:27 Jan 20, 2012, 08:02
Tester Haze View Status Public Platform
Assigned To hap Resolution Fixed OS
Status [?] Resolved Driver
Version 0.135u4 Fixed in Version 0.144u7 Build
Fixed in Git Commit Github Pull Request #
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
Github Commit
Flags Verified with Original
Regression Version
Affected Sets / Systems gberet
Attached Files
 
Relationships
related to 04621ResolvedKale  ironhors: 30fps framerate seems abnormal 
Notes
11
User avatar
No.05304
Haze
Senior Tester
Dec 24, 2009, 13:27
I created this because I'd like to see an original measured reference for it.
User avatar
No.05333
aaron
Developer
Dec 28, 2009, 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
No.05344
Kale
Developer
Dec 29, 2009, 21:20
edited on: Dec 29, 2009, 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
No.05351
Kold666
Developer
Dec 31, 2009, 13:00
I have both Green Beret and Jail Break. What should I check?
User avatar
No.05352
Kold666
Developer
Dec 31, 2009, 13:13
Vsync is 60.60hz
User avatar
No.05353
Kale
Developer
Dec 31, 2009, 15:41
ironhors has the same issue, do you have it?
User avatar
No.05356
Kold666
Developer
Jan 1, 2010, 11:39
unfortunately not
User avatar
No.05391
Mamesick
Senior Tester
Jan 5, 2010, 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
No.05394
Haze
Senior Tester
Jan 5, 2010, 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
No.06801
Kale
Developer
Oct 25, 2010, 01:00
Uhm ... raw guessing ...

Maybe this HW has huge waitstate penalties? How to measure them on a real PCB?
User avatar
No.08053
haynor666
Tester
Jan 20, 2012, 08:02
This remind me another hardware (driver) from that era - cischeat.c
Should be also 60 Hz ?