You must first define the horizontal and vertical rate of the monitor on which you wish to display your "pixel stream." You must also define the retrace period, and the requisite blanking period and sync pulse widths.

Generally, raster display CRT's like the horizontal sync to continue at its nominal rate during vertical sync and blanking, so you can define the scan line width based on the nominal horizontal rate of the display (CRT) in question, and try to find the appropriate position of sync within the blanking (inactive, or retrace) interval of the horizontal oscillator. I haven't looked at it in quite some time, but IIRC, the horizontal sync is often inverted during the vertical sync, though I doubt this is necessary. Several of the CRT's for which I designed adapters back in the "old days" simply ANDed (negative-logic OR) the two sync pulses to produce a composite sync and drove them, via open-collector logic, to GND, while blanking was driven to GND through a resistor, thereby providing the nominal black level for blanking. In the case in which you have to drive that sync on the GREEN signal, a bit more circuitry is required, but the timing remains the same.

If your line width (in pixels) is defined, then you can determine how many pixels you can reasonably display on the screen without overscanning. Overscanning, BTW, is common on TV's. Once you have defined the the pixel count, probably by dividing the horizontal rate by the dot (pixel) clock you've calculated, you can determine how many pixels you can display during the active portion of your scan.

If you choose, you can use a character generator to form your alphanumeric/symbolic elements. The strategy works in this way ...

pixel clock (must be less than bandwidth of CRT) : dotclk
character generator output data width : charw
number of char's on a single scan line : nchars
character clock (= nactivepixelsperscan/charw) : chclk
shift-register load skew (normally 1) = int(cgen_Tacc / chclkperiod) : choffs
character generator load offset : cgldoffs


Now ...
You must provide a counter that count the number of character times per scan line. This is, in fact, the number of pixes per scan line, divided by the number of pixels per character. If you're planning to omit the character generator, which is done by presenting each character as a graphic, which takes MUCH more processing power away from the MCU, then you'll not have to deal with the offsets and strobes associated with the character generator. It will require a considerably larger refresh memory, however.

Most of this is pretty easy, BTW, as you simply need a long counter that counts the number of pixels to be displayed in each vertical frame. That vertical frame must be of the nominal vertical scan rate of the CRT. Everything else must, in general, be decoded from that counter. For that reason, a CPLD is a good choice of ways in which to do this, as CPLD's have quite large gates by means of which large counters can be decoded with minimal hassle and, above all, uncertainty. The timing in a CPLD is quite deterministic, while routing delays, etc, can raise HELL with FPGA timing. It can be done in FPGA with somewhat more effort, however.

Obviously, you must FIRST have the complete specifications of the desired display device, e.g. CRT. A pipeline register or two is useful for synchronizing MCU operation with the display timing, but ... waiting for horizontal blanking before writing to the refresh memory is a pretty decent way to avoid unsightly hashing of the display.

The MCU will typically have no trouble writing to the display at the character rate. If it's done pixel-by-pixel, it will require more firmware overhead, but will still work out with byte-by-byte writes to refresh memory.

There's LOTS of information on the www about raster displays.

RE