Talk:Dot clock rates

From Pin Eight
Revision as of 07:52, 18 September 2020 by Firebrandx (talk | contribs) (PS1 "366" mode:: new section)
Jump to: navigation, search

MAME source

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

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

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

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

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

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

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

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:

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.