Thread: Another question

I think you're going the wrong way about this. Hardware interrupts are outdated and only used for backwards compatibility. You have to use an API such as OpenGL or DirectX because they guarantee you that they will work on a variety of hardware. Most graphics hardware only supports OpenGL and DirectX. So in order to write an engine from scratch I recommend you buy an OpenGL book and learn it. If you write it using Hardware interrupts I assume you will end up with a Software engine which will be much slower than the equivilent opengl based implementation because it will be unable to take advantage of the hardware layers. If that is what you want you are better off using GDI or SDL which are also APIs.

GDI is the lowest level Windows API you will find for 2d graphics but it does not use hardware. SDL is a higher-level cross-platform API which allows for both 2d and 3d graphics and is capable of using OpenGL for hardware interaction.

But if you want to write an outdated DOS graphics program, it's really up to you.

Sounds like you want to get really low level with this, which isn't a bad thing. OpenGL is definitely the way to go if you want to get away from Pascal (which you eventually will, trust me). OpenGL is a pretty low level API. In fact, most of the functions are set up so that it's like you're using the video cards instruction set. Then you can eventually get into Shader assembly, which is pretty neat.

it just has easy access to int's

I'm unaware of a language that makes it difficult to handle numbers. Perhaps I don't understand what you mean by that?

First off, hardware interrupts are just that - hardware. You cannot invoke a hardware interrupt. An example of a hardware interrupt is on your sound card. The DMA chip is programmed for half the length of the sound sample and the card is as well. The programmer then writes an interrupt handler to catch a hardware interrupt from the card. When the DSP chip on the sound card reaches the end of the programmed length of the sample, it fires off a hardware interrupt on a certain IRQ channel - which one is purely up to the manufacturer of the card, but most used IRQ 3 through IRQ 7 in the DOS days. These IRQs are NOT actually 3, 5, and 7 on the list of all 255 interrupts. IRQ 5 actually is about IRQ 55 hex - but it was known as IRQ 5 and called that by Creative Labs and other companies that manufactured sound cards. The hardware interrupt is then fired which signals that the sound sample has finished playing or finished iterating through the data. Now your interrupt handler catches the interrupt (after correct setup of the PIC) which then would load more data into the circular buffer. It's a circular buffer - always loading into the section that just finished playing and always playing the section that just finished loading. In this way the load cursor will never conflict with the play cursor (essentially the pointers will never overlap) so there is no danger of getting a popping sound when playing large sound files.

Hardware interrupts cannot be invoked from software - they must be hardware generated. Now software interrupts can be invoked and they can be invoked from XP as well inside of a DOS session. Don't be so sure that the emulator won't do just what you want it to. I've yet to find any software interrupts that behave unexpectedly inside of XP. However, DMA, PIC, and other types of programming will probably fail miserably. But this code should compile and run fine under TC 1.0 with TASM 5.0.

Code:

void SetMode13h(void)
{
  asm {
    mov  ax,13h
    int 10h
   }
}

void ResetMouse(void)
{
   asm {
     mov ax,0000h
     int 33h
   }
}

void ShowMouse(void)
{
  asm {
    mov ax,01h
    int 33h
  }
}

void HideMouse(void)
{
  asm {
    mov ax,02h
    int 33h
  }
}

struct Mouse
{
  int x,y,button;
}

void GetMouseButtonDown(Mouse &outMouseData)
{
  asm {
    mov ax,03h
    int 33h

  }
  outMouseData.button=_BX;
  outMouseData.x=_CX >> 1;         //Divide by 2 only if in mode 320x200x256
  outMouseData.y=_DX;
}

Try it.