02195: profpac, tenpindx: The 'screen ram' test in the TEST menu is BAD.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
02195	Misc.	Trivial	Always	Sep 2, 2008, 20:44	Oct 16, 2008, 15:55

Tester	M.A.S.H.	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	Open	OS	Windows XP/Vista 32-bit
Status [?]	Confirmed			Driver	midway/astrocde.cpp
Version	0.127u1	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	02195: profpac, tenpindx: The 'screen ram' test in the TEST menu is BAD.
Description	The 'screen ram' test in the TEST menu (F2) of Professor Pac-Man and Ten Pin Deluxe is BAD. See screenshots 1. Test menu 2. Circuitry tests 3. Ram tests 4. Screen ram test (all bit planes are bad!)
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	profpac, tenpindx

Attached Files	profpac1-2-3-4.png (30,891 bytes) Sep 2, 2008, 20:44

No.02313 Fujix Administrator Sep 3, 2008, 04:25 edited on: May 17, 2009, 19:31	It's already known in the source code: * No audio board for Demons & Dragons * Demons & Dragons doesn't work with RAM protection enabled * Professor Pac-Man fails screen RAM test Closing the report. MASH, please read tutorial again. http://mametesters.org/tutorial.html
No.02314 Tafoid Administrator Sep 3, 2008, 04:26	Re: profpac - the source file clearly states in it's bugs listed at the top: Known bugs: * No audio board for Demons & Dragons * Demons & Dragons doesn't work with RAM protection enabled * Professor Pac-Man fails screen RAM test No bug report needed for this one. Re: tenpindx - This set is labeled GAME_NOT_WORKING. No bug accepted at this time for GAME_NOT_WORKING, as any amount of working is purely coincidental. If it were a recent regression from another version - it might be valid. So, no changes.. closing report. M.A.S.H - you should know better than to put up reports like this :D
No.02318 robiza Developer Sep 4, 2008, 05:40	in this case i prefer a mantis entry this is a standard bug (only the bug about "screen ram test") not a useful info in the source that explain why a feature is not present (like the bugs about audio or protection) obviuos IMO
No.02321 Fujix Administrator Sep 4, 2008, 06:52	robiza, our policy that we don't add report which is already known by the driver author to avoid duplicate (and offending the author's feeling) is lead by long experience between Devs and testers and it works well for long time It is impossible for all testers to determine which bug is standard and to be listed in Mantis.
No.02327 Haze Senior Tester Sep 4, 2008, 14:24	Nicola, Robiza, and myself all disagree with the current policy. I still advocate that ALL bugs should be reported here (regardless of flags / code notes) This is being discussed by the dev team.
No.02330 Tafoid Administrator Sep 4, 2008, 14:56	For what it's worth, I have no problem with either way we want to go here. All I'm looking for in consistency across the board. Having policy instituted way back and desires now differ is frustrating, to say the least (as Fujix has gotten a rant or two from me about it). I am glad, finally, this is being discussed by the Dev team.
No.02331 Fujix Administrator Sep 4, 2008, 15:11 edited on: Sep 4, 2008, 15:26	In either way, we should consider a way to avoid useless complaining for obvious incomplete emulation by who doesn't have enough knowledge of the situation. How about introducing a flag "The driver author is rejecting bug reports."? The problem is that some of Devs don't like being criticized. It was the main reason that Smitdogg has introduced this rule.
No.02332 Haze Senior Tester Sep 4, 2008, 15:39	> The problem is that some of Devs don't like being criticized. tough sh*t, they shouldn't write buggy drivers.
No.02338 aaron Developer Sep 4, 2008, 20:30	I agree in principle that we should consolidate all bugs here. It is much easier to find all the issues in one place. If you are a dev on this project, you have to be willing to accept criticism. At least one dev was not open to this and he has decided not to contribute for the time being (his choice). That said, I also agree that we need a way to flag drivers that are in an known incomplete state. Are the current flags sufficient? How about no graphics bugs if GAME_IMPERFECT_GRAPHICS and no sound bugs if GAME_IMPERFECT_SOUND/GAME_NO_SOUND? The problem with those flags is that they imply knowledge of problems, but that doesn't mean there aren't other things worth tracking here. Obviously GAME_NOT_WORKING should be respected.
No.02339 Haze Senior Tester Sep 4, 2008, 20:50	> How about no graphics bugs if GAME_IMPERFECT_GRAPHICS and no sound > bugs if GAME_IMPERFECT_SOUND/GAME_NO_SOUND? these are the current rules, and IMHO they simply don't work. I'd simply say 'no sound bugs if GAME_NO_SOUND' and 'no bugs at all if GAME_NOT_WORKING' Those imply that there is something seriously wrong. If a game is marked as working, specific graphic / sound issues should be logged here even if they're flagged, that way if somebody wants to fix them they can look here instead of relying on a knowledge of the problem. Just because R.Belmont (for example) has a comprehensive list of KonamiGX bugs he knows about doesn't mean everybody else knows about them. Having them logged here would change that. Likewise there are drives I've written with graphic bugs I know about, which aren't logged here because of the current 'rules'. Some of them occur only on the last level of the games so somebody finding them (to fix them) without knowing about them in advance is remote. We need to do everything we can to move the project forward, and create drivers with the highest level of accuracy possible. MAME is still severely lacking, even for some common chips. Proper documentation of bugs would help.
No.02342 Fujix Administrator Sep 4, 2008, 22:46 edited on: Sep 4, 2008, 23:37	OK, I'll lift the old restrictions for flagged games (except GAME_NOT_WORKING) and known bugs in the source files. Before that, I'd like an agreement of all devs on this (and won't accuse reporters for their ignorance). Tafoid is now making up new handling of reports for games with each flag. Maybe we will call for volunteers when we move known bugs in source files to mantis. In the future, driver authors themselves will have to enumerate known bugs when they write a driver. Thanks in advance. (Reopened the entry to allow everyone to add a note.)
No.02344 Reip Developer Sep 5, 2008, 07:58	I agree with the new policy, but what about, for example, listing all the graphics bug for a game flagged as IMPERFECT_GRAPHICS in the same report?
No.02346 stephh Developer Sep 5, 2008, 09:56	It seems that there has been some changes as I don't find how to create a new BTANB entry. Are such entries supposed to be "Documentation" ? BTW, for such entries, the required fields shall be "Affected sets" (I can't tell about "Driver"), "Summary" and "Description" ("Version" isn't needed).
No.02347 Fujix Administrator Sep 5, 2008, 10:18 edited on: Sep 5, 2008, 11:04	Yes, as long as these bugs are from the same cause, they should be in one entry as ever. Although these regulations are removed, it doesn't mean we will accept any reports. A report like "The game has no sound." for a game without sound emulation is neither helpful nor informative for anyone, it will be invalid as heretofore. GAME_NOT_WORKING flag will be respected and we won't accept "bug" reports for these games except heavy regression. (We accept information for them) If you think your driver is in the initial stage and/or it's too early to accept bug reports, you can prevent bug reports by leaving this flag.
No.02348 Fujix Administrator Sep 5, 2008, 10:38 edited on: Sep 5, 2008, 12:20	BTANB is not a category anymore and is a resolution. This may sound strange for you, but this was done from half-year operation of the tester site. Category is supposed to categorize the attribution of the report contents such as sound, graphics, color etc. Resolution is to show how it was processed and the current or final position of the report. Also, it is not very good when a bug turns out to be an original bug and changing the category, the original category is lost. So we determined to move BTANB to Resolution from Category. The version field for BTANB is not harmful. And I'd like to keep it to show when it was found and filed.
No.02349 Haze Senior Tester Sep 5, 2008, 12:11	these changes sound good.
No.02363 Tafoid Administrator Sep 5, 2008, 20:18 edited on: Sep 5, 2008, 21:02	A long note, but here is what has been written up as a detail for handling specific flags. If there are Devs that find something out of place or think something isn't correct or can suggest a better plan, please speak up now. GAME_NOT_WORKING - The only usefulness that this flag guarantees to the end user is that you can load the romset into memory, setup MAME and type "OK". Anything beyond this is completely bonus when dealing with this flag. The only time a bug should be accepted for this flag is when the game fails to load correctly (fatal error or assertion) or any other bug which causes you not to be able to see the disclaimer screen. If you cannot see the screen, the end user has no idea that the game is flagged. GAME_UNEMULATED_PROTECTION - Similar to GAME_NOT_WORKING. The only time we should accept a bug with this flag is there a noticeable/obvious regression from one version to another. For example: A game plays as it has for numerous versions prior then suddenly, in a recent version, the sound is completely missing. A bug report would then be acceptable here. GAME_WRONG_COLORS / GAME_IMPERFECT_COLORS - These shouldn't need a report unless it's a side-by-side or an informational bug report including reference documents or materials. GAME_NO_COCKTAIL - No reports should be accepted as they are sets which knowingly have this feature known to be in the hardware but unimplemented. GAME_IMPERFECT_GRAPHICS - All bugs as related to a specifically identified problem with graphics presentation in sprites, tilemaps or color/palette. All bugs reported under this flag must be VERY specific to be useful. Reports stating: "The graphics on the first level are wrong" is not good enough for a valid and acceptable report. The tester must be verbose and as descriptive as possible with details and, of course, attach screenshots and other reference materials when available to PROVE this is an authentic problem with the way the game is being emulated. GAME_NO_SOUND - If flagged, there is no need to file a report. The game likely will not produce any sound anyway. GAME_IMPERFECT_SOUND - All bugs as related to a specifically identified problem with the audio output as it's being presented. Reports will be accepted for confirmed missing voices/sounds or music elements from prior versions or original sources. Sound mixing or sound level bugs are not valid unless evidence is provided by PCB/OST source recordings to support the claim. Like the graphics flag, the report must be as descriptive as possible, noting exactly what is missing and providing comparison sound recordings to prove the point. Company produced (game specific) OSTs can be used be used as a source of reference but are not to be taken as "100% correct" when dealing with certain sound related differences. It's been noted that in some cases released OSTs are given special audio enhancements (reverb/echo) or are "remastered" and it's important to note that much of this is not included in the original PCB output. GAME_SUPPORTS_SAVE - Reports concerning only games which have SPECIFICALLY CODED Save State support in the source are to be accepted. If a game has support but fails in a saving or fails to properly resume a game - it is eligible for reporting. MAME Source TODO and KNOWN BUG entries - These will need to be added to MANTIS eventually. It's assumed that once all items in the source are transitioned over - any additional entries of this type will have to be monitored and entered by the driver maintainer himself. Those who have intimate knowledge of a driver or a gaming system should be the ones entering the items that are known to fall short of perfect emulation.
No.02366 robiza Developer Sep 6, 2008, 07:29	thanks fot the change
No.02367 Robbbert Senior Tester Sep 6, 2008, 08:38 edited on: Sep 6, 2008, 08:46	This all looks pretty good. In my opinion, if the game is GAME_NOT_WORKING and it crashes MAME (assert or violation), it should be reportable. Doesn't mean it has to be fixed - just on record as an extremely serious error.
No.02387 Fujix Administrator Sep 7, 2008, 05:00	Yes, they will be accepted. Now I'm updating the rule and tutorial page. And added new flag "Noted in Source" for known issues.
No.02389 Firewave Senior Tester Sep 7, 2008, 11:35	I don't think games with the GAME_NOT_WORKING flag, that are bailing out should be reported, unless it's a regression. There are various games in MAME with that flag, that bail out, but it's always been this way.
No.02390 Tafoid Administrator Sep 7, 2008, 14:16 edited on: Sep 7, 2008, 14:17	To Reiterate: All games in MAME should at least bring you to the disclaimer screen/game information screen. If not, it's reportable, even if it's a GAME_NOT_WORKING.
No.02391 Haze Senior Tester Sep 7, 2008, 14:43	yeah, GAME_NOT_WORKING should at least get to the red screen that tells you the game doesn't work. If they crash before that point it's a bug. If they crash after that point it isn't, you were already warned ;-)
No.02420 Fujix Administrator Sep 10, 2008, 02:22 edited on: Sep 10, 2008, 12:33	We are asking devs on the list what kind of issues should be imported from source notes here. Still no response yet though. Testers' current plan is: - Just adding items in known bugs or to-do that effect emulation in a visible manner. No speculation, no "might be" or "unsure if" notes. Only things that can be confirmed as lacking and identifiable as bugs. - Devs can add their driver's note whatever it is as long as it's done consistently.
No.02872 Fujix Administrator Oct 16, 2008, 15:55	As seen in a few releases, it seems that Devs don't feel up for maintaining source known bugs for their updates. Actually, it's a job, not only for Devs, but also us...