• Please review our updated Terms and Rules here

VGA Scanline Effects

Mills32

Experienced Member
Joined
Sep 25, 2018
Messages
149
Location
Spain
I want to know (or calculate) the number of CPU cycles a VGA scanline takes to be drawn. I'll do it for 8088 and 8086 only, because 286 is fast enough to wait for scanlines (reading the vga ports). I don't think there is another way to synchronize code with the crt display.

Any ideas on how to do it?.

I could write pixels to vram with changing colours, and just count myself, but maybe this is not very accurate :(.

Thanks!
 
The VGA pixel clock in standard 320 pixel and 640 pixel graphics modes is 25.2/1.001 MHz, and there are 800 of these pixels per scanline total. The CPU clock speed at 4.77MHz is 4.7775/1.001 MHz, so there are 800*4.7775/25.2 = 455/3, so 455 CPU cycles for every 3 scanlines. These calculations are exact using the derivations of the NTSC and VGA clock frequencies. However, the VGA uses a separate crystal than the one on the PC/XT motherboard, so (depending on details of the hardware and even environmental conditions) these clocks may drift from each other. It might be sufficient to resynchronize every frame - I haven't tried it myself.
 
So, it is possible to make scanline effects on slow PC's without modifying the problematic hblank crt registers (which won't work on modern lcds and most emulators). This is a test on pcem (8088 4.77), the function can be tweaked to produce a stable image on the emulator, so I think any real PC can cope with it.

Screenshot from 2022-01-12 13-42-53.png

Here I changed VGA register 0x03D4 port 13, so that it jumps to specific locations ahead (you can only jump 256 bytes in 8 byte steps). The image was loaded by interlacing 4 copies of every scanline, with 2, 4, 6 pixel offsets, so VGA can jump to any of the next lines, and the image and vram logic width, is 256 pixels max.

You see we can only move in 2 pixel steps to the right or left, but it looks ok :). The big problem is the array needed can't be animated by changing offset :(.

I'll try to update the fine X scroll register (3C0h/13h) each scanline, just in case it might also help to get another approach.
 
Last edited:
Back
Top