The previous log discussed the display columns. This one will cover the rows, but first the clocks:
- Dot Clock (dclk) - 25.175 MHz
- Machine Clock (mclk) - 12.588 MHz (1/2 dclk)
- Processor Clocks (pclk/qclk) - 6.294 MHz (1/2 mclk, qclk is pclk inverted)
- Extended Clocks (rclk/sclk) - 6.294 MHz (pclk/qclk shifted 90-degrees)
- Text Clock (tclk) - 3.147 MHz (1/2 pclk)
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:
- Index the character bitmap row to be rendered in text mode
- 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:
- divide by 2 - hi-res graphics mode (repeat lines twice)
- divide by 4 - lo-res graphics mode (repeat lines 4-times)
- divide by 8 - hi-res text mode (8-bit character)
- divide by 16 - lo-res text mode (16-bit character)
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 Name||Total Lines||Front Porch||V-Sync||Back Porch||Refresh Rate|
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:
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.