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 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
See MAME's video/galaxian.cpp. 120.148.10.188 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 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)
- Ok, done. --Eighty5cacao (talk) 01:34, 17 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)
- 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 B
DRD 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)
- ...and also on Reddit here (sloppy, not sure where we should be tracking this stuff). --Eighty5cacao (talk) 20:20, 24 April 2021 (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)
- Yep, only in this case, the buffered frame is being confused with 'safe zones' and emulator authors should only offer clipped options like that as a menu feature. It should not replace 384 as the name of the mode though. On 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 (like in the case with some 384-mode PS1 games).
- Update: Original Sony documents are to blame for the initial confusion. They listed "360" as the recommended 'safe zone' on CRTs, and then made the mistake of actually labeling the mode as "360". Then later, Sony corrected the mistake for their Net Yaroze documentation and correctly list the frame buffer for that mode as "384". Unfortunately, the initial confusion lead to a lot of emulator dev work basing the output on clipped values like "364" or "368". In reality, all 384 lines are always sent in the signal, regardless of how much pillarboxing you use. Thus, the frame is 384. The OSSC proves this when you dial in optimal timing on ANY game that uses 384 mode, as it only correctly resolves pixel detail if the sampling width is set to 384. So we have a case of new equipment showing old documentation was incorrectly released by Sony, but some emulator authors are having a hard time coming to terms with this. There's a lot of 'appeal to authority' fallacies going on in order to dismiss the concrete evidence provided by both the OSSC and the PS1Digital (which itself bases each mode on the sync signal for the buffered frame). -Firebrandx
Konami GX400 cannot be correct:
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
- I reviewed two separate arcade spec entries in MAME's Nemesis.cpp file, and both entries specified the clock is divided by 3, so it's 99% likely a typo. I've added the correct entry for GX400 back in dot clock list, and I submitted a report to MAME's Github. -Firebrandx