Talk:Dot clock rates

From Pin Eight
Revision as of 21:35, 10 January 2021 by Firebrandx (talk | contribs) (Konami GX400 cannot be correct:)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

MAME source[edit]

In response to your request for a source here, the page could have been found by following the same pattern as the existing citations for CPS1 and CPS3. But I currently prefer to use the web interface of their Git repository, since the copy isn't updated as regularly and sometimes breaks when a new version is released. --Eighty5cacao (talk) 20:31, 24 September 2013 (UTC)

The source is no longer browsable through anyway (the link that used to point to that copy of the source now points to GitHub). --Eighty5cacao (talk) 01:14, 17 October 2014 (UTC)

PC Engine video modes[edit]

I was initially reluctant to put the pixel counts on these because they are theoretically capable of a bit more than the nominal 256 / 352 / 512 pixels (those are just the max used by actual commercial games). I don't have a truly reliable source at hand though. --Eighty5cacao (talk) 04:26, 29 December 2013 (UTC)

Galaxian hardware uses same pixel clock as Pac-Man[edit]

See MAME's video/galaxian.cpp. 01:19, 1 April 2014 (UTC) (.c→.cpp fix by Eighty5cacao (talk) 18:32, 9 November 2015 (UTC))

Shmups Forum[edit]

We have been cited in this Shmups Forum thread.

To be clear, the context of that thread is really more about calculating overall frame rate (as could be done, for example, with knowledge of the number of clocks in HBLANK vs. active scanline & the number of scanlines in VBLANK vs. active frame). --Eighty5cacao (talk) 04:28, 10 June 2014 (UTC)

MAME source: problem[edit]

As of now, all pages on are showing a "Repository seems to be empty" message.

I remember reading somewhere that the development of MAME/MESS is really done via SVN and that the Git repository is just provided for convenience. (To investigate.)

We should wait a few days to see whether this is a temporary problem, but in the meantime I'll look for forum posts to see whether there was a legitimate shutdown. Don't blindly revert any of the links to point to, as that copy of the source is updated infrequently and has also broken in the past no longer exists. --Eighty5cacao (talk) 18:14, 16 October 2014 (UTC)

It is not a temporary problem; the repository has been moved to GitHub. I'll work on this article's links later this evening; I have no particular schedule for the rest of the aforementioned LinkSearch. --Eighty5cacao (talk) 22:03, 16 October 2014 (UTC)
Ok, done. --Eighty5cacao (talk) 01:34, 17 October 2014 (UTC)

For the record, a mirror of the repository was eventually restored to, but we should continue to link to GitHub due to HTTPS support. --Eighty5cacao (talk) 20:40, 30 September 2015 (UTC) now supports HTTPS, for what it's worth. --Eighty5cacao (talk) 20:36, 18 October 2016 (UTC)

TRS-80 Color Computer[edit]

Through private communication, trainbart on suggested that the Tandy CoCo 3 uses a dot clock of 3/2*color burst (hence 8:7 PAR) like the ColecoVision. Source --Tepples (talk) 14:26, 25 April 2016 (UTC)

I acknowledge that coco3.cpp does not appear to contain MCFG_SCREEN_RAW_PARAMS, unless the call is buried inside one of the other macros. --Eighty5cacao (talk) 19:33, 25 April 2016 (UTC)
I did more research, and it turns out that's not the case. CoCo uses a Motorola 6847, whose pixel clock is the same as that of Apple and Atari computers: twice color burst. And yes, the side borders are huge. --Tepples (talk) 15:31, 26 April 2016 (UTC)

Data East HMC20[edit]

If the 11.9931 on Data East's games using an HMC20 CRTC was originally intended to be NTSC*10/3 = 525/44 = 11.9318 MHz, it would have been 525/88 = 5.97 MHz and 36:35 PAR. Either someone at Data East put in a typo when ordering crystals, or the 11.9931 MHz isn't verified. Angelo Salese thought the latter when reverting the 11.9931 change. --Tepples (talk) 22:19, 11 November 2017 (UTC)

I reverted the edit before I looked at this talk page. My bad for not putting it in userspace first. (According to that commit, there also appears to have been a concern about whether the CRTC is called "HMC20" at all, but I digress.)
You may recall that I do not use watchlists and do not necessarily check RC before every edit I make here. Therefore, as a general policy suggestion, except where there are BLP or other urgent implications, please try to wait 1–2 hours after you notice an issue of similar scope to this, to give me a chance to fix it myself. --Eighty5cacao (talk) 23:09, 11 November 2017 (UTC)
I realize that may have sounded a bit rude. You do not need to change how you handle situations where you won't be in front of your computing device for another 1–2 hours. After all, there's a reason that BDRD has a "D" in it. --Eighty5cacao (talk) 23:30, 11 November 2017 (UTC)
What drove me to make the post wasn't the GitHub revert as much as the NTSC*10/3 speculation. --Tepples (talk) 02:17, 12 November 2017 (UTC)

Cited by Retrocomputing Stack Exchange[edit]

The question "Did arcade monitors have same pixel aspect ratio as TV sets?" by rwallace cites this table. --Tepples (talk) 19:10, 24 March 2019 (UTC)

PS1 "366" mode:[edit]

Just wanted to point out certain emulators are misreporting the PS1's 384 mode. I was able to confirm this by using real hardware on the OSSC and dialing in optimal timing for various Capcom games that run in 384x224 (same as the CPS and CPS2 resolution). I've seen various reports on this mode as being 368, 366, and 364. These are all wrong. The 240p modes on the PS1 are 256, 320, 384, 512, and 640.

I'm guessing the association of 366 or 368 with the 384-pixel mode is analogous to the association of 304 with Neo Geo: don't waste GPU time rendering pixels in almost all TVs' overscan. --Tepples (talk) 14:32, 18 September 2020 (UTC)
Even when using all 384 active pixels, there's still overscan padding on the sides of this resolution mode. A perfect example is Captain Commando (Japan), where there's some pixel garbage on the right-side overscan area beyond the 384 resolution. Also considering DAR is 4:5, obviously the image gets squished inward on a CRT so as not to lose too much of it (and makes characters in fighting games look 'correct' instead of warped). As for the Neo Geo, there are a lot of games that use the full 320, though some like Art of Fighting use a pillarbox approach to use less of the available active resolution.

Konami GX400 cannot be correct:[edit]

The dot clock entry for GX400 would make for an incredibly wide image, which doesn't match known captured footage of Salamander arcade output. The dot clock is actually 6.144MHz, which means the active display area of 256x224 is in perfect square pixels (8:7).

It appears the set_raw at line 1733 should be changed to use XTAL(18432000.0)/3 instead of the current XTAL(18432000.0)/4. That'd put it in the same rate/PAR block as the Namco 288x224 boards, just with bigger side borders. What sort of verification would the MAME team ask for to justify this change? --Tepples (talk) 16:19, 10 January 2021 (UTC)
The Salamander PCB is confirmed to use a 18432000 crystal divided by 3, not 4, and this is the same crystal circuit as used in older Konami hardware. - Firebrandx