From: ey200 AT thor DOT cam DOT ac DOT uk (E. Young) Newsgroups: comp.os.msdos.djgpp Subject: Linear virtual screen -> Mode X Date: 29 Oct 1996 09:37:54 GMT Organization: University of Cambridge, England Lines: 53 Message-ID: <554j9i$jn9@lyra.csx.cam.ac.uk> NNTP-Posting-Host: hammer.thor.cam.ac.uk To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp I'm sure everyone's heartily sick of people complaining that they can't set pixels, so I apologise for saying anything even vaguely connected. Still... I've written a fair number of graphics routines, which all work by writing to a malloc'ed buffer. When the vertical retrace comes along, I copy the whole thing into video memory with dosmemput(). This works fine, but I'd now like to try Mode X screens, which have an eccentric screen memory layout, *without rewriting all my graphics code*. The solution I've adopted is to reorganise the memory in the virtual screen at the same time as copying it to video ram. I've written a function that does this (included below), but it's horrendously slow; can anyone explain why? The function is basically identical to __dj_movedata (and is called in the same way) with a bit of bit fiddling in between. Here's the function: # protected mode procedure # copies %ecx bytes from the linear virtual screen at %ds:%esi # to modeX video memory at %es:%edi. Clobbers eax,ecx,edx,esi,edi # videoPtr holds offset of video memory .file "do_xflip.s" .text .align 4 .globl _do_xflip _do_xflip: # plane 1 movl _videoPtr,%edi #videoPtr = 0xA0000 movl $128000-16,%ecx #screen size = 320*400 movl $0x03c4,%edx #select VGA Sequence Control index movl $0x0102,%eax #plane 1 + map_mask outw %ax,%dx #enable plane 1 only loop_start: movb 15(%esi,%ecx),%al #get last bytes from each of 4 movb 11(%esi,%ecx),%ah #words and pack them into output rorl $16,%eax movb 7(%esi,%ecx),%al movb 3(%esi,%ecx),%ah roll $16,%eax stosl subl $16,%ecx jne loop_start ... here there's very similar code for the other 3 planes... ret Thanks very much, -Edwin Young