Starting a fighting game

[Glenn]

by referring a segment and offset from that segment. A "memory segment" is a contiguous group of 16 bytes, starting at segment 0--the beginning of memory. Once you specify a segment, the memory location is further specified by the number of bytes from the beginning of that segment. That number of bytes is called the "offset". In QB, the segment you need to access is pointed to by DEF SEG. When you say, for example,

DEF SEG = &HA000

you're telling your program that any offsets specified after that are to be counted from that segment (and like segments, offsets begin at 0).

[na_th_an]

Maybe this will begin a flame war like some months ago, but Glenn is a little bit inaccurate. A segment measures 64Kb (65536 bytes), but they are overlapped so there is a new segment each 16 bytes. That is 'cause addresses are really done using 20 bits, and the callculation is done like this:

Code:

SEGMENT=      A 0 0 0           (16 bits)
OFFSET =    +   0 0 0 3         (16 bits)
-------------------------
real address  A 0 0 0 3         (20 bits)

This time I'm the one who nitpicks no offense.

(disclaimer: this info has been took direclty from the 8086 documentation by Intel)

[Kofman]

Nathan I'm lost buddy. I have no idea what you mean by that. I swear I reread what you said five times. Still very little actual understanding of segments and offsets.

The way Glenn explained it made good sense. Well I understood it.
It's sort of like this right?:

Segments are 16 bytes and those segments are then devided into offsets. This makes sense. Question. Does an offset start at zero when it's introduced to the next segment. Also is there a limit over the amount of offset. Not like a memory limit although I'd like to know that too but more like a specific number of max offsets possible.

Now that I read your post again nathan, it seems that your saying what glenn was. What are you disagreeing about?

Wait not done yet.

Can you give me an example of one line of code that demonstrates how to access segments and offsets. What's up with the &HA000 and other symbols that I see all over the place recently. Is it a way to refer to a pointer in memory?

Also I still don't have a definition of a buffer lol. Like I said I only know that it's a way to avoid screen blinking. But what's actually happening?

Sorry for these long posts but they can be used as references for others.

[na_th_an]

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

[Glenn]

your "overlapping by 16 bytes" is just a way of dancing around the fact that a segment is in fact 16 bytes. DEF SEG points to a memory segment. You are simply being confused by the multitude of different contexts of the word "segment," (and I was waiting for someone to try to correct me with that erroneous correction ). If you do

DEF SEG = &HA000

and then

DEF SEG = &HA001

the second DEF SEG statement points to a location 16 bytes in memory past the first one, not 65,536. As another example, the location in the bios data area that stores the current video mode is often said to be 40:84h. It is also said to be 0:484. The number before the ":" is the segment. The number after the ":" is the offset. Those two memory locations can only be equivalent if a memory segment is 16 bytes (or 10h bytes), not 65,536 (10000h) bytes.


And you basically said that same thing, contradicting your theory of what a segment is when you said:


"To illustrate it, think that (segment 0, offset 16) is the same address that (segment 1, offset 0):

Code:
actualAddress = segment * 16 + offset"


That "16" multiplying "segment" could only be the right number to use there if 16 was the number of bytes in a segment. (Otherwise, why aren't you multiplying by 65,536?)

[na_th_an]

If you do

DEF SEG = &HA000

and then

DEF SEG = &HA001

the second DEF SEG statement points to a location 16 bytes in memory past the first one, not 65,536.

I know that. I wrote that the segments overlapped, so segment 0, offset 16 is the same address that segment 1, offset 0. In the documentation I have, they call "segment" to the whole 64Kb "window" where you can peek and poke using the offset.

[Glenn]

says that a segment is 64KB. That and other nonsense is all over the internet. And as I pointed out in the addition to my post (that I made while you were obviously making your reply), I realized that you "knew that." But as I also said, your knowing that means that you know there's a problem with your documentation's definition. If there are 65,536 bytes in a segment, you get the linear address via

segment * 65536 + offset.

The "overlapping" would have nothing to do with it. A segment is a segment. However many bytes it is is however many bytes it is. That overlapping nonsense is just that. It adds nothing to the definition and only confuses things.

And the confusion has nothing to do with QB and its being a 16-bit program.

However, you may have noticed that I initially took great care to use the term "memory segment". As I said, there are other contexts of the word. It may in fact be useful to refer to a "code segment" or a "data segment". Such terms are in fact used and a 64K size is usually associated with them. Such segments may in fact contain 4,096 "memory segments", but that doesn't detract from what a memory segment is in the context of referring to specific locations in memory.

[na_th_an]

I think you don't quite understand my point. As I don't write correct english as I know (and may it be the fault), I refer to external documentation:

http://www.shsu.edu/~csc_tjm/fall2001/cs...ule03.html

Memory

* 8086 - 1 megabyte of memory (2^20 bytes)
* Each byte is accessed by specifying an address (00000h through FFFFFh)
* 20-bit addresses must be formed from 16-bits of information

Memory Segmentation

* Memory segments are a direct consequence of using a 20 bit address in a 16 bit processor
* Memory is partitioned into 64K (2^16) segments
* Each segment is identified by a 16-bit segment number ranging from 0000h-FFFFh
* Within a segment, a memory location is specified by a 16-bit offset (the number of bytes from the beginning of the segment)
The Segment:Offset address is a logical address

Note that, when coding in assembly, you refer to a "data segment", that measures 64Kb and not 16 bytes. Of course there is a new segment each 16 bytes, but they measure 64Kb. How is it done? 'cause the therm "segment" refers to a "memory window", not to an actual subdivision of memory.

* Segment Register Example
* 20-bit addresses are formed by pairing a segment register with another register in a segment:offset address
* The segment register holds the segment number
* The other register holds the offset
* Address = (segment number)*16+offset
* Example CS: 010C IP: 14D2
* Address = 010Ch*10h+14D2h = 010C0h+14D2h
Address = 02592h
* Since segments are 64K they can start at any paragraph boundary

If this ain't enough, let's hover to Intel site. I bet that Intel has the answer, as they designed the architecture.

http://developer.intel.com/design/pentiu...243190.htm

It leads you to a ftp where you can download the reference guide. I've extracted a paragraph:

The 8086 has 16-bit registers and a 16-bit external data bus, with 20-bit addressing giving a 1-MByte address space. The 8088 is identical except for a smaller external data bus of 8 bits.
These processors introduced IA segmentation, but only in “Real Mode”; 16-bit registers can act as pointers to address into segments of up to 64 KBytes in size. The four segment registers hold the (effectively) 20-bit base addresses of the currently active segments; up to 256 KBytes can be addressed without switching between segments, and a total address range of 1 MByte is available.

This time you're wrong, or you have misunderstood me, or I have misunderstood you. I've proven my point. Now prove yours.

Sorry, Kofman, this has gone a little bit off-topic, but I had to prove my point.

[Glenn]

contested, i.e., that you've read something misleading and you've decided to worship it. I've already proven my point, as you did. I don't think things can be any simpler than what you've already said. You yourself multiplied a segment by 16 to get the number of bytes in it. Address the factual issues that have already been raised instead of falling in love with some nonsense you've read. You yourself have made it clear that your documentation's definition of a segment does not work for converting segments to bytes. Go with the facts that *you* know work! Forget the theoretical rubbish that doesn't have anything to do with what memory segments and offsets are used for. (Would you convert meters to centimeters by multiplying the meters by 10 simply because there are 10 millimeters in a centimeter--and not by 100 because there are 100 centimeters in a meter?)

And to possibly (but I doubt it) explain the importance of taking the context into account, here's a quote from the article you're in love with:

"there is a new segment each 16 bytes, but they measure 64Kb. "

You see that "there is a new segment each 16 bytes"? Bingo! *Think*. (If *that* doesn't mean that there are 16 bytes per segment, there's something seriously wrong with the English/American language.) That "but they meaure 64Kb" only applies if you need them to "measure" 64 KB. There's nothing magical about the 64 KB. It's just a definition of convenience he makes for his purposes. If he wants to think of a segment as the *beginning* of a 64 KB window, he's free to do that. And as I said, that can be a useful thing to do. But also as I said, it doesn't detract from a segment itself referring to 16 bytes. (I seem to be repeating myself.)

[na_th_an]

I just replied to this:

A "memory segment" is a contiguous group of 16 bytes, starting at segment 0--the beginning of memory

with this:

A segment measures 64Kb (65536 bytes), but they are overlapped so there is a new segment each 16 bytes.

Take it as you like. I just referred to Intel manuals and assembly usage. In assembly, a segment is 64 Kb. End of discussion. You won't change my mind, and yours is impossible to change even when you are not completely right.