As far as I know, it generates pixels just like a VGA, so using the base 14.31818MHz clock, 14318180 pixels clocks each second. That never changes. The only thing ever changing is the amount of clocks each scanline, which is always a multiple of 8 clocks plus horizontal adjust clocks. This is then multiplied with the vertical amount of scanlines(multiples of 8 lines), with vertical adjust scanlines added for the total amount of clocks in a frame. To get the framerate(not neccesarily 60FPS), divide the base clock(14318180Hz) with the resulting clocks per frame.

Although, this is from the top of my head:
((Horizontal total + Horizontal adjust) * 😎 * ((Vertical total * 😎+vertical adjust) = cycles per frame

The cycle rate is constant at 14318180Hz.
So your framerate is:
14318180/113792=~125.82Hz.

But, the pixel clock is halved with 40 column text mode, so the frame rate is halved too:
14318180/(113792*2)=~62.91Hz

vladstamate wrote:

The CGA is set up in 40x25 mode. And the registers are as follows: […]
Show full quote

The CGA is set up in 40x25 mode. And the registers are as follows:

Horizontal total 56 (characters)
Vertical total 31 (characters)
Vertical adjust 6 (lines)

Characters are 8x8. So that gives me: 56 x 8 x ( 31 x 8 + 6 ) = 113792 (pixels).

Slightly off - horizontal and vertical total are total number of characters minus one. So you should actually get :
57 x 8 x ( 32 x 8 + 6 ) = 119472
Using the base 14.31818 MHz, divided by two for 40 column mode gives 7.15909 MHz. Divide that by 119472 and you get 59.92 Hz.

Whoops. You're correct about them being minus one. Sometimes forget those, as I've long since implemented those in UniPCemu. The only parts I'm looking at nowadays are the character clocks themselves with the SVGA cards, as they're the only problems still left(like 8-bit and 15/16-bit color graphics modes on the ET3K/ET4K graphics cards).

Thank you Sarah and superfury. That explains a lot. I had forgotten about the half clock for 40 columns mode.

Was sure the CGA vertical frequency is the standard NTSC one - 60 / 1.001 ≈ 59.94 Hz. And the horizontal frequency is 262 * 60 / 1.001 ≈ 15.704 kHz.
So we have 456 * 262 * 60 * 2 / 1.001 = 14336640 / 1.001 ≈ 14.322318 MHz clock rate.

Gamecollector wrote:

Was sure the CGA vertical frequency is the standard NTSC one - 60 / 1.001 ≈ 59.94 Hz. And the horizontal frequency is 262 * 60 / 1.001 ≈ 15.704 kHz.
So we have 456 * 262 * 60 * 2 / 1.001 = 14336640 / 1.001 ≈ 14.322318 MHz clock rate.

The CGA signal doesn't have precisely the same field rate as the NTSC standard, because CGA is 262 scanlines of 228 color carrier cycles per scanline, and NTSC is 262.5 scanlines of 227.5 color carrier cycles per scanline. That's okay though - monitors can accept a certain amount of variance in the horizontal and vertical timings (and indeed, must do so in order to able to lock onto a new signal). The really critical frequency is the color carrier frequency itself, which must be 157.5MHz/44 (~= 3.579545MHz) to a tolerance of something like 1 part in 100,000 in order to avoid hue drift over the width of the screen. The PC/CGA oscillator crystal is actually 4 times this frequency (157.5MHz/11 ~= 14.318181MHz) in order to get exactly 4 high-res pixels per colour carrier cycle (and therefore 16 possible colour waveforms in standard composite mode). So the CGA's frame rate is 1/(262*228*4) of this frequency or approximately 59.92Hz, while the standard NTSC field rate is 1/(262.5*227.5*4) of this frequency, or exactly 60/1.001.

157.5MHz/11 is the 14MHz used by the PC? I've always thought it was simply 14.31818MHz(Used in current UniPCemu builds). I'll adjust the clock right away.

Edit: Not needed, it seems: UniPCemu got 15.75/1.1, which is the same as 157.5/11.

superfury wrote:

157.5MHz/11 is the 14MHz used by the PC? I've always thought it was simply 14.31818MHz(Used in current UniPCemu builds). I'll adjust the clock right away.

Yes, 157.5MHz/11 is the correct (nominal) value, if you look into the derivation of the NTSC timings. 14.31818MHz is never going to give incorrect results if it's the timebase for all the same clocks that the crystal drive in real hardware (the crystals used aren't accurate to anywhere near 1 part in 10 million so the difference could never be noticable) but if you do want an exact value then 157.5MHz/11 is it.

I've used 315/88 MHz for the color carrier, so that's 315/22 MHz for the crystal frequency (157.5MHz/11 is just as good of course).

It's really not just 14.31818 MHz as written on crystals.

Modern devices use 27 MHz crystal to get 13.5 MHz for sampling PAL and NTSC, and as NTSC line is 858 pixels wide, and there are 227.5 cycles of color carrier per line. 4*227.5*13.5/858 = 315/22. Also as the legend says, when trying to minimize interference between different frequencies, they were not able to change audio carrier of 4.5MHz nor lines per field (or frame), so they had to slow down the line rate (and field/frame rate) a bit to make the audio carrier to be integer multiple (286) of line rate. Thus again, 4*227.5*4.5/286 = 315/22.

NTSC specs say the carrier is 3579545 Hz +/- 3ppm, or in some other specs, 5MHz*63/88 +/- 10 Hz. That's basically something that's not going to happen in a consumer equipment as normal crystals have initial tolerances and temperature dependencies between 20ppm and 50ppm. So that's why when ordering NTSC crystals, they might read 14.318 or 14.31818 MHz, as error to the nominal is 13ppm and 0.13 ppm respectively, so a lot less than the tolerance they can be manufactured with.

I've also dug out some of my old notes and there it is said that CGA (not NTSC) is 262 lines (not 262.5) and it's 912 clocks ticks (not 910) of the crystal frequency per line. So essentially CGA frame has 238944 crystal ticks (not 238875).

Jepael wrote:

Modern devices use 27 MHz crystal to get 13.5 MHz for sampling PAL and NTSC, and as NTSC line is 858 pixels wide,

Oh, interesting - I had wondered where the 13.5MHz sample rate came from, being neither a nice multiple of the NTSC color carrier frequency nor giving square pixels. The fact that it gives an integer number of pixels per scanline for both NTSC (858) and PAL (864) probably doesn't hurt! Of course, with modern digital signal processing techniques it doesn't really matter what the sample rate is as long as all the frequencies of interest are above the Nyquist limit. And indeed, the 13.5MHz sample rate isn't universal - the capture card I use (based on a Fusion 878A chip) has a 28.6MHz (~8x NTSC color carrier) sample rate, but also has a programmable PLL for generating other sample rates up to 35.47MHz for PAL. The crystal is only 50ppm, though, so when decoding it's necessary to calibrate the frequency against that found in the color burst to avoid hue drift over the width of the screen.

Jepael wrote:

I've also dug out some of my old notes and there it is said that CGA (not NTSC) is 262 lines (not 262.5) and it's 912 clocks ticks (not 910) of the crystal frequency per line. So essentially CGA frame has 238944 crystal ticks (not 238875).

A very interesting number for democoders (especially when divided by 12) 😀

reenigne wrote:

Jepael wrote:

Modern devices use 27 MHz crystal to get 13.5 MHz for sampling PAL and NTSC, and as NTSC line is 858 pixels wide,

Oh, interesting - I had wondered where the 13.5MHz sample rate came from, being neither a nice multiple of the NTSC color carrier frequency nor giving square pixels. The fact that it gives an integer number of pixels per scanline for both NTSC (858) and PAL (864) probably doesn't hurt! Of course, with modern digital signal processing techniques it doesn't really matter what the sample rate is as long as all the frequencies of interest are above the Nyquist limit. And indeed, the 13.5MHz sample rate isn't universal - the capture card I use (based on a Fusion 878A chip) has a 28.6MHz (~8x NTSC color carrier) sample rate, but also has a programmable PLL for generating other sample rates up to 35.47MHz for PAL. The crystal is only 50ppm, though, so when decoding it's necessary to calibrate the frequency against that found in the color burst to avoid hue drift over the width of the screen.

Yes, PAL Htotal is 864 pixels wide at 13.5MHz sampling. With modern video decoders such as ADV7800, they only use some common crystal for reference, and they lock on to the input signal, utilize oversampling and DDS techniques to generate digital sine waves to decode the chroma. Even do some time base correcting for unstable sources like VCRs, so they scale the oversampled and decoded data so that it's still output at standard pixel clocks, locked to the input signal.

reenigne wrote:

Jepael wrote:

I've also dug out some of my old notes and there it is said that CGA (not NTSC) is 262 lines (not 262.5) and it's 912 clocks ticks (not 910) of the crystal frequency per line. So essentially CGA frame has 238944 crystal ticks (not 238875).

A very interesting number for democoders (especially when divided by 12) 😀

Indeed, I believe I updated my video timing notes with CGA based on information written by you and/or Scali 😀 PIT rulez!

So in 40x25 text mode (where the CGA is supposed to be running at half clock speed) does it still take 912 clocks to deal with a horizontal scan line?

Yes because it needs the same horizontal line rate. I think based on what SarahWalker it's 57 characters total instead of 114 characters total so that's 57*8 == 912/2.

So new pixel data is sent every other clock so in essence pixels are double as wide so there can be half the pixels on screen when compared to 80x25 mode.

Essentially the effect is the same as the VGA using pixel doubling in 640 pixel mode(UniPCemu translates all rendering timing on the CGA to VGA compatible values(not on the CRT raster itself). Only the raster timings, which drive the virtual CRT beam and display areas(active display, overscan, blanking and retraces), are used with a custom handler instead of the VGA one. All other VRAM-related stuff(pixel doubling too) is handled by the VGA code(active display code). Although there are some custom code insertions in the renderer and attribute controller to deal with CGA specifics.

https://bitbucket.org/superfury/unipcemu/src/ … mda.c?at=master