Close

Clocks, Scans, and Refresh Rates

A project log for Novasaur CP/M TTL Retrocomputer

Retrocomputer built from TTL logic running CP/M with no CPU or ALU

alastair-hewittAlastair Hewitt 04/10/2019 at 22:220 Comments

The previous log discussed the display columns. This one will cover the rows, but first the clocks:

The dclk is the standard VGA dot clock and is used to latch the output of the first video DAC (VDAC1) and to shift the bits of the character buffer in text mode. This renders the text at the full 640 horizontal graphics resolution of VGA by displaying 80 columns of text using 8-bit wide characters (not the 9-bits of the 720 horizontal resolution VGA-400 text mode).

The mclk is the native speed at which the hardware is clocked at. This is divided down again to generate the pclk at which each processor operates. Therefore each processor cycle includes two machine cycles. One machine cycle is used to access the ROM and the other to access the RAM. The GPU and CPU operate on opposite clocks to access both memories concurrently.

The rclk is a delayed version of the pclk used by the CPU state machine. This provides a 40ns delay in which to perform the instruction decode and maintain the state across the edge of the 80ns machine cycle.

The final clock is the tclk and is used by the GPU in text mode. Each column of text uses two bytes, so the GPU divides down the pclk to alternated between reading the ASCII code point and font/color bytes on each processor cycle.

Each line of the display requires 200 process cycles as discussed in the previous log. This results in a horizontal scan frequency of 31.47 kHz. This is fixed in hardware and is the same for every video mode. At the end of each line the Scan Counter (SC) is incremented. This is a 4-bit counter that can count up to 16 lines. This serves two purposes:

  1. Index the character bitmap row to be rendered in text mode
  2. divide down the line count

The lo-res text mode uses 16 lines for each character, so the whole of the scan counter is required for this. The hi-res text only needs 8 lines, so just the first 3 bits are used. The bits are also combined to create an ent signal for the vertical counter depending on the video mode as follows:

This is what drives the vertical scan count, but the software must blank the display at the bottom of the screen, generate the V-Sync pulse, and then reload the V register to reset the counter to the top of the screen. The value loaded in to the V register can be moved up and down to perform a smooth scroll of a larger text area within the video RAM.

Since the vertical sync timing is software defined it is possible to supported different screen sizes. The YATAC defines 4 screen heights and when combined with the 4 other video modes provide a total of 16 configurations for the display. Both the standard VGA-400 and VGA-480 modes are supported, allowing full compatibility with even the most ancient PS/2 CRT monitors. The other two modes are YATAC-specific custom defined: The YATAC-9x4 is a 419 line mode at 75 Hz and will map directly to HD/UHD 9:4 ratio displays (but at a much lower resolution). The YATAC-MAX is a 561 line mode at 56 Hz and renders the maximum number of lines in RAM (256) when using the hi-res graphics mode.

The mode name, total lines and how they are made up are defined as follows:

Mode NameTotal LinesFront PorchV-Sync Back PorchRefresh Rate
YATAC-9x44191724075.10 Hz
VGA-4004491223570.09 Hz
VGA-4805251023359.94 Hz
YATAC-MAX5611223556.09 Hz

The screen refresh rate drops as the lines increase since the horizontal frequency is fixed. However, even the custom modes are designed to fall in line with standard refresh rates that most monitors should support. All 16 modes are shown below along with the line count for each:

Refresh

Rate

Native

VGA

Hi-Res

Graphics

Lo-Res

Graphics

Hi-Res

Text

Lo-Res

Text

75 Hz360180904522
70 Hz4002001005025
60 Hz4802401206030
56 Hz5122561286432

Finally there is the RS232 serial communications. The plan is to support multiple baud rates up to 38400 baud. The highest speed would require processing one bit every 164 machine cycles and a whole byte would take 1476 machine cycles to transmit/receive. This seems achievable, but that speed might be dropped once development reaches that stage. The era-appropriate rate would be 300 baud, but I'm hoping to do better than that.

Discussions