Thread: Calling ISR w/o interrupt

I'm using VESA modes 10Eh and 111h. In real mode bank switching is slow, but a necessary evil. So, instead of calling the ISR via an interrupt I figured that a far call would be faster.

Obviously I was wrong. Why is the far call slower than the interrupt when interrupts are known for being notoriously slow?

Here is my code:

Code:

void far (*VideoINT)();
void far *ISR;

int main(void)
{
  WORD vidoffset
  WORD vidsegment

  asm
  {
    mov ax,0
    mov es,ax
    mov [vidoffset],es:[010h*4]
    mov [vidsegment],es:[010h*4+2]
  }
  ISR=MK_FP(vidsegment,vidoffset);
  (void far *)VideoInt=(void far *)ISR;
  ...
  ...   //this portion sets up the rendering system
  ...   //Not relevant to question, didn't include
return 0;
}

so for bank switch:

Code:

void PlotPixel(DWORD offset,WORD color)
{
  static WORD bank;
  WORD actualoffset=offset & 0xFFFF;
  WORD curbank=offset>>16;
  asm
 {
    START:
      mov ax,[curbank]
      cmp ax,[bank]
      jz PLOTPIXEL
    BANKSWITCH:
      mov ax,04f05h
      mov bx,0
      mov dx,[curbank]
      push dx                //Preserve dx across call
      call VideoINT        //far call to int 10 based on int vector table
      pop dx
      mov [bank],dx     //Set bank to curbank
    PLOTPIXEL:
      mov ax,0a000h
      mov es,ax
      mov di,word(actualoffset)
      mov ax,color
      stosw
  }
}

If I was to replace call VideoINT with int 10h, the entire function is faster.

This does not make sense to me. It is faster to plot pixels via a far pointer than to use an ISR to do so. Why isn't it faster to call the INT 10 ISR instead of invoking it via an interrupt? I thought this would be a way to circumvent the slow bank switch interrupt call, but I guess not.

I'm also only specifying 0 in BX because it is too slow to call or invoke the ISR twice for 0 and 1. Besides, it works fine just using 0, so I left it.


Never mind....I'm so careless. In my actual code I forgot to preserve dx across the call. So when I called the ISR, dx was obviously changed. When I assigned dx to curbank, dx did not really represent the correct bank. This forced a bank switch on every single pixel (hitting myself in the head). Sorry everyone, but I figured it out amidst writing this.


Well, anyways, this is a fast plot pixel function for VESA modes.
For those that don't like or know assembly (mine is far from perfect) this can be done in C as well.

Did some more testing. It seems that my failure to preserve dx across the call was also costing me frames on my function that uses int 10h.

It is slightly faster to use the interrupt than the far pointer. Still don't know why. Both operations have to push the return address or the address of the caller onto the stack. Perhaps C does one more operation or two on a far call. Obviously the ISR lies too far away from my segment for it to be a near pointer. My ISR is at df5f:000f for int 10. My segment according to DOS is way away from there.

I know what happens when the CPU encounters an interrupt. I don't know for sure what exactly happens during a far call in C. This might be where the speed discrepancy is.

Anyone know?

Yes, I know how to get the address of the LFB, and no I cannot use it in real mode. VBE 2.0+ cannot be done in real mode, as far as I know. I don't even think I could get around the problem in assembly. The pixel offset will always extend beyond a 64K segment. I have downloaded several IDEs, NASM, TASM, MASM, DPMI16, and DPMI32 so I am going to port to protected mode soon - after I make sure they are virus free.

I also downloaded the new Art of Assembly lanugage for protected mode. It seems that the original site for AoA has been moved (link was broken for some time), but now www.webster.cr.edu (look up art of assembly language on excite) There is also a free version of HLA or High Level Assembly language assembler. From what I've seen it looks like it uses C/C++ constructs, which makes it easier to learn asm.

Check it out, if you are interested.

I've been looking for DOS4GW, but not much is available. Not sure if Rational Systems is still around. No info on DOS4GW in the interrupt listing.