- Warning: "Unverified" means exactly that. Please don't add any of these guesses to MAME without additional supporting evidence.
- TODO: Mention the modern, non-macro-based replacement for
MCFG_SCREEN_RAW_PARAMS
appropriately, once I confirm what it's named (set_raw
)?
I have no active account on TCRF, MAMETesters, or GitHub
|
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.
I am not cam900. More generally, I have no GitHub account as of this writing (18:20, 25 August 2020 (UTC)) due purely to laziness.
|
Obsolete notes for TCRF editors
|
Please credit Porchy (linking to that blog post), not just me.
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.
This page's purpose and guidelines
|
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.
- 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.
- Sega System 1 and 2 (system1.cpp): Appears to be 10MHz, probably supposed to be 5MHz - why does MAME emulate twice the horizontal resolution of what the games actually seem to use? ("There are several systems (Wonder Boy in the arcade, etc.) that have a resolution 256 pixels across, but seem to allow scrolling in increments of half a pixel." - Chris Covell, on NESdev forums)
- 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 be
MCFG_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 be
MCFG_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.
See also: Operation Thunderbolt (similar refresh rate, but measurements suggest VTOTAL=258); Top Speed (similar refresh rate, but no hsync measurement); Taito Z System (video board has 26.686MHz crystal, and MAME developer Angelo "Kale" Salese agrees with this guess)
|
- 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)
- 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 be
MCFG_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
- Universal Mr. Do's Castle hardware family (docastle.cpp): 240px; 4.914MHz (9.828MHz/2)
- Exidy 6502-based hardware (includes/exidy.h): 256px; 11.289MHz/2
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).
Unknown relation to common frequencies
Unacceptable for NTSC displays
PAL-like frame rate
- Sinclair ZX Spectrum (spectrum.cpp/.h): 256px normally addressable; 7MHz, from 14MHz/2. Information is unavailable for the NTSC equivalent (Timex Sinclair TS2068) (TODO: really? Also, describe the differences in dot counts between Spectrum models)
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.
- Konami Xexex (xexex.cpp): 512x288 scan, 384x256 addressable, 8MHz (32MHz/4) pixel clock gives 15625 Hz H, 54.25 Hz V
- Irem M72 family (m72.cpp): 512x284 scan, 384x256 addressable, 8MHz (32MHz/4) pixel clock gives 15625 Hz H, 55.02 Hz V
- 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.
- PlayStation Portable (PSP) LCD: 480x272 out of 525x286, 9 MHz dot clock, 17.14 kHz by 59.94 Hz sync[2] (TODO: compare against the "video out" on PSP-2000 and later)
Medium ("EGA") resolution
- Sega System 24 (segas24.cpp): 16MHz (32MHz/2) pixel clock, 496x384 addressable, 656x424 scan, 57.52Hz V (58Hz in comment is only an approximation), 24.39KHz H
- Apple Lisa (720x360)[1][2][3]
- Compact Macs (512x342):[3] Vsync is 60.15 Hz.[3] LocalTalk networking runs at 230400 Hz (24 * 9600 bps), the 7.8336 MHz CPU clock is 34 times that,[4] and the video circuit outputs 16 pixels every 8 CPU cycles (wikipedia:Macintosh 128K/512K technical details). The PCM output is 22254 Hz, just over half CD rate, outputting one 8-bit sample every 352 CPU cycles, and hsync is the same rate.[5] Verdict: A 15667200 Hz dot clock with 512x342 active out of 704x370.
- Macintosh LC and Color Classic (512x384)[3][6] The best guess, given the measured 60.15 Hz and 24.48 kHz frequency, is the same 15667200 Hz dot clock with a 640x407 total signal.
- IBM MDA, Hercules Graphics Card, IBM EGA (720x350, 720x348, 640x350)
- Early XGA-class displays with 1024x768i, though not the IBM 8514
- ↑ PC Mag Feb 14, 1989, via Google Books
- ↑ "Build A PSP LCD Interface". Accessed 2021-08-30.
- ↑ 3.0 3.1 3.2 The 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.
Categories: Noindexed pages