Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
02197 Gameplay Critical (emulation) Always Sep 3, 2008, 10:21 Jul 11, 2009, 12:39
Tester russ h. View Status Public Platform MAME (Self-compiled)
Assigned To Phil Bennett Resolution Fixed OS Windows XP/Vista 32-bit
Status [?] Resolved Driver
Version 0.127u1 Fixed in Version 0.132u5 Build C2D
Fixed in Git Commit Github Pull Request #
Summary 02197: rthun2, rthun2j, finehour: Black screen, game does not start
Description on rolling thunder 2 mame loads and the game passes the ram checks, but the game does not start.
Steps To Reproduce
Additional Information
Github Commit
Flags
Regression Version 0.127u1
Affected Sets / Systems rthun2, rthun2j, finehour
Attached Files
 
Relationships
There are no relationship linked to this issue.
Notes
12
No.02503
user413
Sep 19, 2008, 20:18
Confirmed and added regression version.
User avatar
No.02504
Tafoid
Administrator
Sep 19, 2008, 20:42
Gnomick,
Huh? The regression version was already confirmed and added on 2008-09-03 at 13:02 UTC by myself according to the change log at the bottom of the screen. Please do not continue posting notes to ANY bugs unless it's NEW information that is not already reflected in the report. Confirm all you want any bugs already confirmed - but only comment if you can fill in any vital information as to when or why a bug is present.

Future wasteful notes by will be promptly deleted.
User avatar
No.02506
Haze
Senior Tester
Sep 20, 2008, 10:33
applies to finehour too.
User avatar
No.02515
Haze
Senior Tester
Sep 21, 2008, 09:27
could this be related to the 68k interrupt changes.. I can't think of many others which might cause these to malfunction (unless something has been broken in one of the other cpu cores)
No.02604
user413
Sep 27, 2008, 01:36
Resolved in .127u5.
User avatar
No.02605
Tafoid
Administrator
Sep 27, 2008, 04:43
It's bug is still present for me on 0.127u5 .. all 3 sets still show black screen after all the checks.
User avatar
No.02610
Fujix
Administrator
Sep 27, 2008, 10:25
gnomick, please enjoy Testers by viewing now.

Thank you.
User avatar
No.02882
Phil Bennett
Developer
Oct 18, 2008, 21:47
edited on: Oct 20, 2008, 12:53
For rthun2 at least, this is the problem:

1. Through its C148 interrupt controller, the slave CPU requests a master CPU interrupt ('CPUIRQ').
2. The master CPU's C148 translates the request to a a level 4 interrupt.
3. The interrupt is never acknowledged, so the master CPU is stuck running the level 4 interrupt routine forever (which happens to be the VBLANK routine).

This interrupt seems spurious. I'm not sure if writes to 0x1d4000 (or 0x1d0000) should be causing a 'CPUIRQ'. Removing the IRQ trigger fixes the affected games and doesn't appear to have any ill effect on the others. I'd like to know if any games actually rely on the CPUIRQ generation to work.
User avatar
No.04297
fsampei
Tester
May 1, 2009, 12:58
edited on: May 1, 2009, 12:58
this problem (black screen after the rom check) there is also in mame 131
User avatar
No.04298
Tafoid
Administrator
May 1, 2009, 13:19
Any bug which is in this system that isn't closed or resolved is assumed to be still happening. While it seems like you are trying to help, fsempei, you are not adding anything constructive to this discussion. As applied to another former Tester in this very report, only comment if you can fill in any vital information as to when or why a bug is present. Thank you.
User avatar
No.04585
hap
Developer
Jun 29, 2009, 14:51
"could this be related to the 68k interrupt changes.."
For reference, here's the note in whatsnew. No changes were made in machine/namcos2.c and drivers/namcos2.c btw.

"Changed 68000 IRQ support so that the IRQ lines explicitly simulate
a standard demux chip connected to the IRQ lines. This means that the
sequence:

      cpunum_set_input_line(5, ASSERT_LINE);
      cpunum_set_input_line(3, ASSERT_LINE);
      cpunum_set_input_line(3, CLEAR_LINE);

now works as expected. This required fixes to several Atari and other
drivers. [Olivier Galibert]"

Phil: After commenting out 0x1d0000/0x1d4000 cpu_set_input_line(altcpu, pC148RegAlt[NAMCOS2_C148_CPUIRQ], ASSERT_LINE);, I've tested all namcos2 sets for about an hour, and didn't find any new bugs. 0x1d0000 is hardly ever written to, and 0x1d4000 is usually only written to at boot and in service mode, both without any noticeable effect. I guess it's safe to remove those CPUIRQ asserts.
User avatar
No.04628
Phil Bennett
Developer
Jul 11, 2009, 12:39
Ok, lets go with this. I still need to verify the interrupt controller emulation against the hardware at some point.