Difference between revisions of "User:Eighty5cacao/misc/Unverified dot clock rates"

From Pin Eight
Jump to: navigation, search
(Standard definition: I was stupid and forgot the divisor)
m (Undid revision 16595 by self: probably ok for mainspace article)
Line 51: Line 51:
 
*Data East ''Locked 'n Loaded'': 7MHz pixel clock with 320px-wide clean aperture; possible but unverified for other members of this hardware family ([https://github.com/mamedev/mame/blob/master/src/mame/drivers/deco32.cpp deco32.cpp])
 
*Data East ''Locked 'n Loaded'': 7MHz pixel clock with 320px-wide clean aperture; possible but unverified for other members of this hardware family ([https://github.com/mamedev/mame/blob/master/src/mame/drivers/deco32.cpp deco32.cpp])
 
*Taito ''The FairyLand Story'' family ([https://github.com/mamedev/mame/blob/master/src/mame/drivers/flstory.cpp flstory.cpp]): 256px wide; claimed to be 8MHz, but comments say "guess"
 
*Taito ''The FairyLand Story'' family ([https://github.com/mamedev/mame/blob/master/src/mame/drivers/flstory.cpp flstory.cpp]): 256px wide; claimed to be 8MHz, but comments say "guess"
*Konami GX400 family ([https://github.com/mamedev/mame/blob/master/src/mame/drivers/nemesis.cpp nemesis.cpp]): <code>set_raw(XTAL(18432000.0)/4,288,0,256,264,2*8,30*8)</code>, i.e., 256x224 out of 288x264 at 4.608MHz (derived from 18.432/4), giving gives 60.6060... Hz V. This information had been known long before the driver was made to call <code>set_raw</code>.
+
*Konami GX400 family ([https://github.com/mamedev/mame/blob/master/src/mame/drivers/nemesis.cpp nemesis.cpp]): <code>set_raw(XTAL(18432000.0)/4,288,0,256,264,2*8,30*8)</code>, i.e., 256x224 out of 288x264 at 18.432MHz, giving gives 60.6060... Hz V. This information had been known long before the driver was made to call <code>set_raw</code>.
  
 
=== <span id="Unknown_relation_to_colorburst">Unknown relation to common frequencies</span> ===
 
=== <span id="Unknown_relation_to_colorburst">Unknown relation to common frequencies</span> ===

Revision as of 00:39, 30 August 2019

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.
  • 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.
  • 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.
  • IGS PolyGame Master (PGM) (pgm.cpp): Some games for the standard cartridge system check for 60.0 +/- 0.1 Hz refresh in POST; best guesses for these are:
    MCFG_SCREEN_RAW_PARAMS(33868800/4,   560, 0/*+x*/, 448/*+x*/, 252, 0/*+y*/, 224/*+y*/) ()
    MCFG_SCREEN_RAW_PARAMS(XTAL_50MHz/6, 591, 0/*+x*/, 448/*+x*/, 235, 0/*+y*/, 224/*+y*/) ()
    MCFG_SCREEN_RAW_PARAMS(10000000,     615, 0/*+x*/, 448/*+x*/, 271, 0/*+y*/, 224/*+y*/) (from either 50MHz/5 or 20MHz/2)
    MCFG_SCREEN_RAW_PARAMS(10000000,     646, 0/*+x*/, 448/*+x*/, 258, 0/*+y*/, 224/*+y*/) ()
    MCFG_SCREEN_RAW_PARAMS(10000000,     641, 0/*+x*/, 448/*+x*/, 260, 0/*+y*/, 224/*+y*/) ()
    The dedicated-PCB games developed by CAVE were measured at 59.17 Hz. Best guesses for these are:
    MCFG_SCREEN_RAW_PARAMS(33868800/4,   540, 0/*+x*/, 448/*+x*/, 265, 0/*+y*/, 224/*+y*/) ()
    MCFG_SCREEN_RAW_PARAMS(XTAL_50MHz/6, 548, 0/*+x*/, 448/*+x*/, 257, 0/*+y*/, 224/*+y*/) (not sure whether the 50MHz crystal from the standard PGM motherboard exists here)
    MCFG_SCREEN_RAW_PARAMS(10000000,     593, 0/*+x*/, 448/*+x*/, 285, 0/*+y*/, 224/*+y*/) ()
    MCFG_SCREEN_RAW_PARAMS(10000000,     655, 0/*+x*/, 448/*+x*/, 258, 0/*+y*/, 224/*+y*/) (assuming CAVE PCBs differ from the generic motherboard only in horizontal dot count)
    MCFG_SCREEN_RAW_PARAMS(10000000,     650, 0/*+x*/, 448/*+x*/, 260, 0/*+y*/, 224/*+y*/) (ditto)
    (x and y indicate unknown absolute positioning of the clean aperture within the scan frame, which the MAME project does not typically bother with anyway)
  • 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)
  • 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
  • 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"
  • Konami GX400 family (nemesis.cpp): set_raw(XTAL(18432000.0)/4,288,0,256,264,2*8,30*8), i.e., 256x224 out of 288x264 at 18.432MHz, giving gives 60.6060... Hz V. This information had been known long before the driver was made to call set_raw.

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

Footnotes

  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.