|
No.02503
user413
Sep 19, 2008, 20:18
|
Confirmed and added regression version. |
|---|---|
 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. |
 No.02506
Haze Senior Tester
Sep 20, 2008, 10:33
|
applies to finehour too. |
|
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. |
|
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. |
 No.02610
Fujix Administrator
Sep 27, 2008, 10:25
|
gnomick, please enjoy Testers by viewing now. Thank you. |
 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. |
 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 |
|
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. |
 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. |
|
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. |