VGA signal timing calculation using MCU
It is easy enough to calculate all you need from just the basic provided information.

For instance, the site I use most for a reference is this one: http://tinyvga.com/vga-timing/640x480@60Hz and it has all you need for 640x480 @ 60Hz (it specifies most common resolutions, but that's the simplest to work with).

It specifies everything in pixels and lines, and it provides a pixel clock frequency, as well as refresh frequencies.  All you need though is the pixel clock and the number of pixels for each thing.

For instance, it gives a pixel clock of 25.175 MHz. That is not easy for most microcontrollers to generate, since it's both high frequency and high resolution - in general you can have one of those two - high frequency or high resolution.  However, 25MHz is usually easy enough to generate, and is "close enough" for most monitors to cope with.

So we have a 25MHz pixel clock.  We also have a "whole line" size of 800 pixels.  That size includes the porches, sync and visible area.  So a line of 800 pixels, at 25MHz clock, would be running at (25,000,000/800) 31250 Hz, or one line every 32µS.

The horizontal sync pulse - 96 pixels - would be (96/25,000,000) = 3.84µS long.

We know that a line takes 32µS, and there are 525 lines in a "whole frame", so 0.000032×525 = 0.0168s for a frame, or 59.524Hz.  That's pretty close to the 60Hz for the specification.

So given a pixel clock, and a set of pixel periods, you can calculate anything.  Of course, you can also go backwards.  Given a frame rate and a resolution you can work out:

$$
60Hz × 525  = 31500Hz
$$

$$
31500Hz × 800px = 25.2MHz
$$
So that shows that even the given specifications aren't 100% exact, but there is a bit of flexibility in the VGA timings so you can bend your clock to suit you within certain bounds.

And while we're at it, generating VGA purely with software takes a lot of processing and often leaves you starved of CPU cycles to do anything.  One of the most common "tricks" for making a VGA signal on a CPU is to use SPI to generate the pixel data stream.  Even better if you have DMA in your microcontroller to output an entire line of data without the CPU having to do anything.  The CPU is then just responsible for generating the sync pulses and loading the DMA system with the right addresses - the rest is done in the background.  Of course, that leaves you with just a 1-bit monochrome display. If you happen to have an SQI interface, and enough RAM, you could make a 4-bit display (16 colours) easy enough.