Talk:Dot clock rates
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 mamedev.org 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 mamedev.org 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
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 git.redump.net 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 mamedev.org, 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)
For the record, a mirror of the repository was eventually restored to git.redump.net, but we should continue to link to GitHub due to HTTPS support. --Eighty5cacao (talk) 20:40, 30 September 2015 (UTC)
- git.redump.net 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 forums.nesdev.com 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)
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 B
DRD has a "D" in it. --Eighty5cacao (talk) 23:30, 11 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.
- 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.