This mess comes 'cause QB runs in 16 bits DOS, and 16 bits DOS still uses the memory management of ol' 8086s (if you take out XMS and EMS).
Imagine a window in your memory. That window measures 64Kb (65536 bytes), so if you wanna deal with memory you have to do it thru that window, so you can only access 64Kb.
But that window can be moved with a precission of 16 bytes.
The segment tells the possition of that window (note that 16 * 65536 = 1 Meg), and the offset tells the position inside that window.
For example, to access screen you have to move your "window" to address &HA000, 'cause the video memory is mapped there, and then you can access screen using the offset.
This is done 'cause the 8086 had 1 Meg of total memory (1 meg needs 20 bits to be measured), and registers measure 16 bits (registers are used to point to memory locations), so a trick had to be introduced, 'cause a 16 bits number is from 0 to 65535 so you can only address 64Kb. Using segments, you can access the whole 1 Meg. You still use addresses of 64 Kb (that fit on a register), but you first set up your window (segment) so all the 1st Mb can be covered just moving your segment.
That's why I said that segments are overlapped. You have a new segment, measuring 64Kb each 16 bytes of memory. If you divide the total 1 Meg by 16 bytes you get 65536, it is the number of segments.
To illustrate it, think that (segment 0, offset 16) is the same address that (segment 1, offset 0):
Code:
actualAddress = segment * 16 + offset
"&HA000" is just an hexadecimal number. It comes to be the address of the so called "video segment". Hexadecimal numbers are used 'cause they are really handy. Note that each figure represents 16 values (not 10 like in a decimal number), so it takes 4 bits. It is easy to callculate how many bits a number has just multiplying the number of figures by four. That's why they're used. Translation to binary is direct.
Code:
hex dec
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
A 10
B 11
C 12
D 13
E 14
F 15