Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
04249 Crash/Freeze Critical (emulation) Always Feb 14, 2011, 15:16 Feb 28, 2011, 14:23
Tester Saku00 View Status Public Platform MAMEUI
Assigned To aaron Resolution Fixed OS Windows Vista/7 (32-bit)
Status [?] Resolved Driver
Version 0.141u2 Fixed in Version 0.141u3 Build Normal
Fixed in Git Commit Github Pull Request #
Summary 04249: Several saturn.c sets: Black screen after system checking
Description Black screen after checking screen but the game don't freeze because config menu or F2/F3 buttons works perfectly.

Had to be fixed per-game in stvinit.c
known to be affected:
rsgun - fixed
cotton2 - fixed
grdforce - fixed
maruchan - fixed
othellos - fixed
Steps To Reproduce
Additional Information stv.c merged into saturn.c in 0.142u2
Github Commit
Flags
Regression Version 0.141u2
Affected Sets / Systems Several saturn.c sets
Attached Files
 
Relationships
related to 04245Resolvedaaron  gunfront, gunfrontj, driftout: No sound 
Notes
7
User avatar
No.07195
Haze
Senior Tester
Feb 15, 2011, 00:17
hap> I call 'hack' on your fix.

Reducing the interleave (which is what you're doing by reducing the period of 'perfect sync') should not FIX anything. It should just make it faster.

This IMHO points at a more serious problem which you're just hiding by doing so.
User avatar
No.07196
Tafoid
Administrator
Feb 15, 2011, 00:22
edited on: Feb 15, 2011, 00:23
Yeah. I had researched it and it looks more to do with the emu/timer changes (r11464/r11472) rather than attotime bulk changes that happened.
User avatar
No.07197
hap
Developer
Feb 15, 2011, 01:27
Yes I know what the change does, I made timeslices smaller which increases the interleave frequency, should make it more accurate (and slower on old PCs, not faster)

I couldn't find the underlying issue, I suppose it's either a bug in core timer changes, or actually a bug _fix_ in it.
User avatar
No.07199
Haze
Senior Tester
Feb 15, 2011, 12:59
ah true, I though you'd changed the other param (the length of time it was boosted for)

either way, I'm a little miffed as to why the behavior has *changed* unless there was an underlying bug in the system before. It's a little unnerving that refactoring changes to the timer system have measurable effects on the behavior when we're dealing with attoseconds in the first place.
User avatar
No.07209
hap
Developer
Feb 16, 2011, 16:29
setting it to resolved
User avatar
No.07253
hap
Developer
Feb 22, 2011, 16:43
temporary reopening
User avatar
No.07270
hap
Developer
Feb 28, 2011, 14:23
underlying issue was fixed in u3