No, good questions!
sergiopolog wrote:- Why is it considered that there are twice (864) "pixels" per line? Maybe the clock used to trigger the latches in the output RAMDAC (they are always a pair of 74LS273) is down to a half of its frequency? (6.75MHz)
The 13.5MHz clock I measured is pin 218 from GP9001 ("GCUCLK" according to
Knuckle Bash schematics), and as as you correctly say, only half the frequency reaches DAC stage (pin 11 of each 74LS273), where it is called "DCLK". So there are not actually 864 "pixels" per line, but 432
One can nicely see that this is correct if one takes the game's test pattern as a reference (V-V in this case)..
..and juxtaposes that with the look of a scanline on the oscilloscope:
Channel 1 is green video, channel 2 is GCUCLK, channel 3 is Csync.
What we see here is: a little bit of green, no green, a little bit of green, no green, then 100% for: 148ns, 296ns (x3), followed in shorter succession by another 100% for 148ns.
This is the end of a scanline that we can see within the upper half of the CRT photo.
The CRT is not correctly calibrated, but if we inspect the white grid's horizontal bars, we can see that these extend across two scanlines. This being a test pattern, we can assume that the vertical bars are supposed to be just as wide. There are no pixels in analog video, we are looking at their analog representations. Nevertheless, because the red square ends amidst a vertical bar, we can reason that the thin white portion after that is supposed to have the width of the smallest unit of the game's internal resolution: one pixel.
If we now zoom in on the "pixel", we can see that, fittingly, 148ns is 2x GCUCLK period (two falling clock edges while green video is active):
Taking a screenshot in MAME and activating a pixel grid when viewing the image confirms this.
864 is the number of needed samples per line; tapping DCLK for reference clock could also work in principle, but to reconstruct the digital signal with an ADC, the sampling rate has to be at least x2 the pixel clock (Nyquist rate), otherwise you lose information, so you'd have to multiply DCLK again. Conveniently - for the same reason, in fact - 13.5MHz is also what Rec. 601 standardized to sample 480i with. I'd guess that, to keep things simple, this is why cps2_digiav takes GCUCLK instead (please correct me if I'm wrong marqs).
sergiopolog wrote:- Why are “263” lines per frame instead of 262?
You can either
drop half of a scanline or add another half to get from the initially standardized 480i to 240p (the latter being a
clever "hack" of the former), so due to that (and because this necessarily lies within Vblank anyway), it does not really matter whether a 263th line is present or not. Thanks again to rama who brought that article to my attention earlier.
I'm quite sure 263 would be technically correct for Toaplan V2, 262 would contradict measurements across 4 games (which I've each double-checked). To arrive at 262 lines, I'd have needed to measure 16768000ns Vsync period for an OSSC-compatible game, meaning ~63952ns less, while all measurements lie within a 150ns window (normalized for sync quirk), so that's by no means a realistic error margin. But I haven't studied the MAME source enough to be able to say whether the difference matters there.