scs@hstbme.mit.edu (Steve Summit) (09/09/89)
In article <1117@clyde.Concordia.CA> patrice@concour.CS.Concordia.CA (Patrice Scattolin) writes: >I a memmove when I use a constant for the start address everything >works fine. But when I put a "int" with the exact same variable >it does no longer work. I assume you are trying to do something like this: #define DISPMEM 0x00b80000 memmove(DISPMEM, bits, bitsize); or char *dispmem = DISPMEM; memmove(dispmem, bits, bitsize); Microsoft generally does a very good job of handling near and far addressing from you, and hiding the gory segmentation details from you if you're not interested in them. When writing portable, machine-independent code, it is wise to avail yourself of this behavior, and not uglify your code with explicit "near" or "far" references unless you really have to. However, I have found that doing DMA graphics is one area where one has to. (Since DMA graphics code is inherently machine-specific, nonportable code constructs are much less of a problem.) I always declare all screen memory pointers as being explicitly "far": #define DISPMEM (unsigned char far *)0x00b80000 memmove(bits, DISPMEM, bitsize); or unsigned char far *dispmem = DISPMEM; memmove(bits, dispmem, bitsize); I don't know why you noted differences depending on whether you used a "literal constant" or a variable, but the compiler does have to make some assumptions when converting ints to pointers, and it may do it differently and/or get it wrong depending on which you use. (If one mildly positive thing can be said about programming the 80*86, it's that it teaches you to follow some of the rules about pointers which have been there since day one but which "VAXlike" architectures let you break with impunity.) Were you getting warnings about casts between integers and far pointers? By the way, you'll have to compile with compact or large model for memmove to be able to handle far pointers. Steve Summit