TCRF: I had previously registered using the same username I have here, a long time ago (back when the domain was still wiki.rustedlogic.net), but I forgot my password and can't reset it because there is no email address associated with the account. I was not prompted for one during registration, and I could not find the option in Special:Preferences immediately afterward. Due to various personal issues, I have not since re-registered.

MAMETesters:doesn't appear to support HTTPS, but the main reason I haven't registered is a prior lack of interest; specifically, I do not personally own any PCBs to test.

Please write my username in all lowercase; it appears capitalized only due to limitations of the MediaWiki software.

MAME developers: Sorry for not contacting you directly through MAMETesters.

When you change the visible area, it's probably also a good idea to change the refresh rate on the non-bootleg sets to match the 60.0559Hz measurement mentioned in the comment at the top of the driver. Better yet, have a PCB owner (unfortunately not me) measure the screen raw parameters.

TODO: Specifically mention inclusion criteria on the parent page: If a MAME/MESS driver is used as a citation, it MUST (SHOULD?) contain the MCFG_SCREEN_RAW_PARAMS macro (TODO: find the place where it is defined) and MUST NOT (SHOULD NOT?) contain comments saying the raw parameters are a dubious guess.

Generally, one should check xtal.cpp to ensure that XTAL(foo) or foo_MHz_XTAL really means exactly foo MHz.

Measurements of horizontal scan frequency are not necessarily trustworthy due to incorrect filtering of sync pulses causing an artificially low result (forums.bannister.org or www.mameworld.info - cn?).

In the first two sections here, only include games that run on "standard-resolution" (~15 kHz horizontal scan rate) or "high/VGA-resolution" (~31 kHz) arcade monitors, not "medium-resolution" (~24 kHz), and only include games for which a standard NTSC television could plausibly sync to the output of a supergun. (In particular, the refresh rate must be closer to that of NTSC than PAL.)

Also, is it worth making any distinction between clean aperture and safe area? For example, many Neo Geo games and some N64 games are designed around a safe area 304 pixels wide (usually treating the pixels to the left/right of this as extra blanking).

New readers: What is MCFG_SCREEN_RAW_PARAMS?

The parameters of the MCFG_SCREEN_RAW_PARAMS macro are defined (or at least conventionally labeled) (cn) as (PIXEL_CLOCK, HTOTAL, HBEND, HBSTART, VTOTAL, VBEND, VBSTART), where the full scan frame is HTOTAL by VTOTAL and the clean aperture is (HBSTART-HBEND) by (VBSTART-VBEND).

(The names denote end of vertical blank, etc., and they have nothing to do with the word "bend.")

Standard definition

Sourcing issues

Capcom 1942 (1942.cpp): 256px; 12MHz is the only crystal used on the non-bootleg PCBs, so the most likely pixel clock is 6MHz, but no MCFG_SCREEN_RAW_PARAMS macro is present.

Jaleco Momoko 120% (momoko.cpp): The main CPU clock is believed to be 5MHz, and all other clocks appear to be fractions of that, so it's a reasonable guess given the addressable horizontal resolution of 240 pixels that the pixel clock is also 5MHz. The driver does not use MCFG_SCREEN_RAW_PARAMS nor contain comments about the oscillators found on the PCB.

Cave CV1000 family (cv1k.cpp): 320px suggests 6.4MHz from 12.8MHz/2, but there is nowhere near enough info available to verify this; we don't even know an accurate refresh rate. See also forum thread claiming that the active scanline fraction is higher (hence the pixel clock is lower) than that of other common 320px PCBs (toaplan2 and/or unspecified Taito hardware).

Sega System 16A: segas16a.cpp lacks MCFG_SCREEN_RAW_PARAMS, but its comments imply that the PCB should have the same crystal as 16B. This is also mentioned in xtal.cpp.

Psikyo PS5v2 (and rest of PS3/5 family?) (psikyosh.cpp): Currently believed to be 7.16 MHz (2x colorburst) from 57.2727/8. Tetrisconcept member Muf confirms a rather high resulting refresh rate of 61.68 Hz in Tetris The Grand Master 2, but some success has been had in outputting to superguns (cn). Other games on this hardware, if they follow the NTSC standard, could have 455 dots/scanline (vs. 443 for TGM2, all else equal) according to a comment on MAME Testers.

Taito Rainbow Islands (rbisland.cpp): If you are following up on a mention from an external site, especially The Cutting Room Floor (TCRF), see notes above.MAME currently declares the clear aperture to be the 320x224 pixels used in normal gameplay; it is more likely 320x232. The bottom-most tile row is used only by the game's crash handler to display the type of 68000 exception, using text that is not currently visible in a MAME screenshot. This row is all black in normal operation.

Collapsed speculation about pixel clock and other params

Measurements of 60.0559Hz V and 15.7345KHz H suggest 261 scanlines/frame, but the closest solution for this would beMCFG_SCREEN_RAW_PARAMS(XTAL_26_686MHz/5, 340.5, 0/*+x*/, 320/*+x*/, 261, 8/*?*/, 232+8/*?*/)...which can't be used verbatim in MAME due to the lack of support for non-integer parameters. The next best guess would beMCFG_SCREEN_RAW_PARAMS(XTAL_26_686MHz/4, 424, 0/*+x*/, 320/*+x*/, 262, 8/*?*/, 232+8/*?*/)Operation Wolf (opwolf.cpp) might have the same pixel clock and total H / V.

Namco NA-1/NA-2 family (namcona1.cpp): 288px or 304px, but can't possibly use the Galaxian dot rate due to lack of an appropriate crystal; possibly 50.113MHz/8? (no accurate refresh rate measurement)

Namco NB-1/NB-2 family (namconb1.cpp): 288px, but can't possibly use the Galaxian dot rate due to lack of an appropriate crystal; refresh rate measured as 59.7 Hz and Hsync as 15.75 KHz - possibly the same horizontal and vertical dot counts as Galaxian, but with a slower 48.384MHz/8 pixel clock, that is, MCFG_SCREEN_RAW_PARAMS(MASTER_CLOCK/8, 384, 0/*+x*/, 288/*+x*/, 264, 0/*+y*/, 224/*+y*/) which happens to "exactly" match the measured hsync and give 59.659 Hz for vsync - TODO: this guess appears to have been officially accepted for the purpose of calling the modern set_raw function

NMK "16-bit family" (proper name?) (nmk16.cpp): also 56.18 (or 56.19?) Hz V, 256x224 or 384x224 clean aperture; the "higher res is an afterthought" comment may imply the pixel clock is the same for both choices of clean aperture (which is actually implausible for 384, due to the low amount of hblank); probably 6MHz pixel clock, 406x263 dots, matching Mega System 1-A

Kaneko "16-bit family" hardware (kaneko16.cpp): For Wing Force in particular: 59.1854 Hz refresh claimed (by comparison with other games on the same hardware), 320x240 clean aperture. A likely possibility for this game is a 512x264 scan frame at 8MHz pixel clock, that is, MCFG_SCREEN_RAW_PARAMS(XTAL_16MHz/2, 512, 0/*+x*/, 320/*+x*/, 264, 0/*+y*/, 240/*+y*/); other members of this hardware family are more likely to have a 6MHz pixel clock and 384 dots/scanline.

Kaneko's Gals Panic II (galpani2.cpp) should have the same timings as the 2nd-generation Toaplan hardware (specifically, the 6.75 MHz SIF dot rate) according to comments in the driver. The driver does not yet use the MCFG_SCREEN_RAW_PARAMS macro due to other parts of the emulation being incomplete.

Seta "1st generation" hardware (seta.cpp): As most games have only a 16MHz crystal, the dot clock is probably 8MHz:

The games listed as 60Hz refresh should probably be 59.1845Hz, based on the measurement of Thundercade (which also has 15.21 kHz H, giving 257 scanlines per frame). This gives MCFG_SCREEN_RAW_PARAMS(XTAL_16MHz/2, 526, 0/*+x*/, 384/*+x*/, 257, 0/*+y*/, 224/*or 240 depending on game*//*+y*/)

Some other games are listed as 57.42Hz refresh; perhaps these should beMCFG_SCREEN_RAW_PARAMS(XTAL_16MHz/2, 540, 0/*+x*/, 384/*+x*/, 258, 0/*+y*/, 224/*or 240 depending on game*//*+y*/)

Tecmo Rygar family, not including bootlegs (tecmo.cpp): No dispute about the 6MHz pixel clock, but the hsync measurement of 15.1436kHz, if it can be trusted, implies that the dot counts should be adjusted to MCFG_SCREEN_RAW_PARAMS(XTAL_24MHz/4, 396, 0/*+x*/, 256/*+x*/, 256, 0/*+y*/, 224/*+y*/). The full precision of the vsync measurement, given in the same comment, is 59.1856Hz.

Namco System 21 (namcos21.cpp) has been claimed to use twice the pixel clock of previous standard-definition Namco hardware; there is a TODO comment, implying it is uncertain what has or has not been verified. A further doubling in the MAME driver is used to work around MAME's lack of support for interlaced displays (i.e., by weave deinterlacing?). 768x264 (field) scan with interlace accommodates a 496x480 clean aperture, 60.6060... Hz

Data East Locked 'n Loaded: 7MHz pixel clock with 320px-wide clean aperture; possible but unverified for other members of this hardware family (deco32.cpp)

Taito The FairyLand Story family (flstory.cpp): 256px wide; claimed to be 8MHz, but comments say "guess"

Unknown relation to common frequencies

Enhanced definition

Sourcing issues

Sega Dreamcast (dccons.cpp) in NTSC mode: clean aperture nominally 640x480; dot clock currently believed to be 26917135 Hz, but comment states that crystal source is uncertain, and the total horizontal and vertical dot counts are alleged to differ between the home console and the arcade system boards derived from it (naomi.cpp).

Frame rate neither NTSC- nor PAL-like

Seibu Kaihatsu Raiden II family (raiden2.cpp): 512x282 scan, 320x240 addressable, 8MHz (32MHz/4) pixel clock gives 15625 Hz H, 55.41 Hz (calculated)/55.47 Hz (measured) V. Some people have had success outputting these PCBs through a NTSC supergun, but some video-capture devices are reported to auto-detect the signal as PAL-like (cn, presumably due to the scanline count of 282 being close to 288). The 1996–2000 revision of this hardware (r2dx_v33.cpp) has been reported to have the same refresh rate, but the clock source has not been verified on those PCBs.

IBM 8514, which has 35.52 kHz and 43.48 Hz,[1] for 817 lines per 2-field frame

GRiD Compass (gridcomp.cpp) models with 320x240 clean aperture: pixel clock measured as 7.5 MHz and refresh rate measured as 66 Hz. This is also a sourcing issue, as the MCFG_SCREEN_RAW_PARAMS invocation in the driver knowingly does not represent the refresh rate accurately.

Footnotes

↑ 2.02.12.2The relevant MESS drivers are lisa.cpp, mac.cpp, and mac128.cpp. These also have a sourcing issue: The MCFG_SCREEN_RAW_PARAMS macro is not yet used for the resolutions described here, only for later-model Macs that use VGA timings.