User:eighty5cacao/misc/Unverified dot clock rates

From Pin Eight
< User:Eighty5cacao‎ | misc
Revision as of 18:20, 25 August 2020 by Eighty5cacao (talk | contribs) (to prevent any established MAME developers from getting the wrong idea; minor only for "poor man's RCC")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
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)?

If you are here because of the TCRF article on Rainbow Islands

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.

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.
  • 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 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

  • 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.

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][2]
  • Compact Macs (512x342):[2] 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)[2][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


  1. PC Mag Feb 14, 1989, via Google Books
  2. 2.0 2.1 2.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.