Turbo C / VGA x86 assembly: Copy from ram to vram

Question

I'm just having fun with turbo c to draw "sprites" on an 8086/286 (emulated with pcem) with an MCGA/VGA card.

Compiled with turbo c 3.0 it should work on real 8086 with MCGA. I'm not using the VGA mode x because it is a bit complex and I don't need extra vram for the things I want to do, even if there is some flickering on the screen, it's ok :).

In C, I have a bunch of memcpys moving data from the loaded sprite struct to the VGA in mode 13:

byte *VGA=(byte *)0xA0000000L;    
typedef struct tagSPRITE             
{
    word width;
    word height;
    byte *data;
} SPRITE;

void draw_sprite(SPRITE *sprite){
    int i = 0; int j = 0; 
    for(j=0;j<16;j++){
        memcpy(&VGA[0],&sprite->data[i],16);
        screen_offset+=320;
        i+=16;
    }
}

The goal is to convert that code to a specific assembly function to speed things just a bit.

---

(editor's note: this was the original asm attempt and text that an answer was based on. See the revision history to see what happened to this question. It was all removed in the last edit, making only the asker's own answer make sense, so this edit tries to make both answers make sense.)

I tried to write it in assembly with something like this, which I'm sure has huge mistakes:

void draw_sprite(SPRITE *sprite){
    asm{
        mov ax,0A000h
        mov es,ax           /* ES points to the video memory */

        mov di,0            /* ES + DI = destination video memory */
        mov si,[sprite.data]/* source memory ram ???*/
        mov cx,16           /* bytes to copy */

        rep movsb           /* move 16 bytes from ds:si to es:di (I think this is the same as memcpy)*/

        add di,320          /* next scanline in vram */         
        add si,16           /* next scanline of the sprite*/
        mov cx,16   

        rep movsb           /* memcpy */

        /*etc*/
    }
}

I know the ram address can't be stored in a 16 bit register because it is bigger than 64k, so mov si,[sprite.data] is not going to work.

So How do I pass the ram address to the si register? (if it's possible).

I know I have to use ds and si registers to set something like a "bank" in "ds", and then, the "si" register can read a 64k chunk of the ram, (so that movsb can move ds:si to es:di). But I just don't know how it works.

I also wonder if that asm code would be faster than the c code (on an 8086 8 Mhz, or a 286), because you don't have to repeat the first part every loop.

I'm not copying from vram to vram for the moment, because I'd have to use the mode X and that's another story.

Answer 1

rep movsb increments SI and DI as well as decrementing CX. It's like a memcpy that takes its dst,src by reference and updates them to the end of the copied region.

So you need add di, 320-16, and si is already pointing to the next row of the sprite (because the row stride matches the width = 16).

As far as segmentation, movsb copies from DS:SI to ES:DI, so setting up ES:DI to point at video memory is correct.

Turbo C's calling convention requires/ensures DF=0 on function entry/exit (like normal 32-bit calling conventions), so you don't need a cld to make sure movsb goes in the right direction (forward instead of backward). (If you used std somewhere else and didn't put it back, fix it there to avoid violating the calling convention.)

Turbo C's calling convention also has call-clobbered AX/BC/CX/DX, and ES. (Thanks @MichaelPetch). If its inline asm is anything like MSVC, the compiler will save/restore DI and SI for you. But possibly it doesn't save/restore DS for you, so @MichaelPetch suggests you'll need to push/pop DS to save/restore it yourself. Have a look at the compiler-generated asm to make sure you're following the calling convention.

From your updated question, we can see your build options include memory model = large that makes all pointers into far-pointers, which will be a significant slowdown vs. manually choosing which pointers need to be FAR and others being only 16 bit. But if you don't have any reason to learn about 16-bit real-mode segmentation and all that no-longer-relevant stuff, then sure keep using that. (You might choose a memory model where at least code can be near, so near call/ret only push/pop an IP value, not also a CS.)

---

You can put the code in a loop, like this.

I have a mix of hard-coding width / height vs. loading it, like your question, but if you calc the row stride in BX (320-width), you have enough registers to hoist the calculations out. The loop branch itself already handles runtime-variable sprite sizes, too.

    push  ds

    xor   di,di             // DI=0

    //mov   si,[sprite.data]  /* source memory ram ???*/
    lds   si,[sprite.data]  // with your build options, everything is a seg:off FAR pointer
    lea   ax, [si + 16*16]  // end_src pointer

    mov   dx, [sprite.width]
    shr   dx, 1              // words to copy = bytes / 2
    // if you can't assume even width, then just use movsb
    // or optimize with rep movsb + a test of the low bit for one movsb

@loop:                    // do {
    mov   cx,dx            /* words to copy */

    rep movsw             /* copy 16 bytes from ds:si to es:di */

    add   di, 320-16      /* starting column in next scanline in vram */         
    // add si, 0          // sprite row stride - width = 0

    cmp   si, ax
    jb   @loop           // } while(src < endsrc);

    pop   ds

Note the use of movsw to copy in 2-byte chunks. x86 before PPro really did just copy 1 byte or 1 word at a time, according to the operand size.

PPro and later have fast-strings microcode that copies in larger chunks. But this has significant startup overhead so for only 16 bytes it would be best on a modern x86 in 16-bit mode to use maybe 4 DWORD integer registers (eax), or qword with x87 fild qword/fistp, or 16-byte with one XMM register.

On an actual 8086 or 286, fild/fistp would be horribly slow compared to integer copies. With a 16-bit data bus you can only copy 2 bytes at a time anyway so rep movsw is good on a real 286.

See also What setup does REP do?

And Enhanced REP MOVSB for memcpy for memcpy on modern x86 (mostly focused on large copies, though.)

Also note that VRAM is typically uncacheable or write-combining, so if you're actually optimizing a copy-to-VRAM routine, multiple narrow stores to the same cache line suck for UC, but are not bad for WC, on a CPU with cache.

Answer 2

Thanks to Michael Petch, Peter Cordes, and everybody. I got the answer.

The assembly code to copy data to the vga video memory looks like this:

DGROUP          GROUP    _DATA, _BSS
_DATA           SEGMENT WORD PUBLIC 'DATA'
_DATA           ENDS
_BSS            SEGMENT   WORD PUBLIC 'BSS'             
_BSS            ENDS
_TEXT           SEGMENT BYTE PUBLIC 'CODE'
                ASSUME CS:_TEXT,DS:DGROUP,SS:DGROUP

            PUBLIC _draw_sprite       
_draw_sprite    proc    far 
    push bp
    mov bp,sp
    push ds
    push si
    push di
    ;-----------------------------------
    lds     bx,[bp+6]
    lds     si,ds:[bx+4]        ; sprite->data to ds:si
    mov     ax,0A000h
    mov     es,ax                       
    mov     di,0                ; VGA[0] to es:di

    mov     ax,16               ; 16 scan lines
copy_line:  
    mov     cx,8
    rep     movsw               ; copy 16 bytes from ds:si to es:di
    add     di,320-16           ; go to next line of the screen
    dec     ax
    jnz     copy_line
    ;-----------------------------------
    pop di
    pop si
    pop ds
    mov sp,bp
    pop bp
    ret 
_draw_sprite    endp

Declare the function in c as:

    void draw_sprite(SPRITE *spr);

Data stored at spr->data, is an array of numbers (from 0 to 255, storing the color of a pixel).

That code finally draws the 16x16 bitmap at position x = 0, y = 0.

Thanks a lot!