- --
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
Notes
11
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. |
---|---|
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? |
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. |
No.05351
Kold666 Developer
Dec 31, 2009, 13:00
|
I have both Green Beret and Jail Break. What should I check? |
No.05352
Kold666 Developer
Dec 31, 2009, 13:13
|
Vsync is 60.60hz |
No.05353
Kale Developer
Dec 31, 2009, 15:41
|
ironhors has the same issue, do you have it? |
No.05356
Kold666 Developer
Jan 1, 2010, 11:39
|
unfortunately not |
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. |
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. |
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? |
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 ? |