Double buffer in mode 13H

[sinsi]

I put screen_address in the code segment, for ease of access. You have it in the data segment.

[popcalent]

I put screen_address in the code segment, for ease of access. You have it in the data segment.

Oh! I didn't catch that. I corrected it and it still doesn't work. I tried also printing a character and it won't. It prints it after setting interrupt 15h, but not inside the handler.

[sinsi]

You probably need a stack, at the moment there is none

Code Select Expand

STACKSG SEGMENT STACK
  db 4096 dup (?)  ;make a 4KB stack
        STACKSG ENDS       
Move the other vars from data to code as well - the code is written so JMP FAR PTR OLD_INT15_VECTOR is probably using the wrong value in DS (which the BIOS is using)

[popcalent]

You probably need a stack, at the moment there is none

Move the other vars from data to code as well - the code is written so JMP FAR PTR OLD_INT15_VECTOR is probably using the wrong value in DS (which the BIOS is using)

All done. No difference 

[NoCforMe]

Move the other vars from data to code as well - the code is written so JMP FAR PTR OLD_INT15_VECTOR is probably using the wrong value in DS (which the BIOS is using)

Yes; so if it's in the code segment, then you'd use JMP FAR PTR CS:OLD_INT15_VECTOR, right?

Gawd, it's been a long time since I coded any of this stuff ...

[sinsi]

One major problem I finally saw with your code - you don't actually set 320x200 mode 13h

[_japheth]

Yes; so if it's in the code segment, then you'd use JMP FAR PTR CS:OLD_INT15_VECTOR, right?

Gawd, it's been a long time since I coded any of this stuff ...

OMG - what a mess!

Do you guys know how a type cast is supposed to work?

I'm asking vecause that "FAR PTR" behind the JMP instruction actually makes label OLD_INT15_VECTOR a far code label which surely isn't what you want to achieve. OLD_INT15_VECTOR is a normal variable holding a FAR code address, that's something completely different.

The assembler (masm or tasm) is smart enough to know that a DWORD variable in 16-bit will hold a FAR address, so no type cast is needed, just code JMP CS:[OLD_INT15_VECTOR].

[popcalent]

One major problem I finally saw with your code - you don't actually set 320x200 mode 13h

I did after you suggested printing a pixel to check if the handler executed.

[sinsi]

Yes; so if it's in the code segment, then you'd use JMP FAR PTR CS:OLD_INT15_VECTOR, right?

Gawd, it's been a long time since I coded any of this stuff ...

OMG - what a mess!

Do you guys know how a type cast is supposed to work?

I'm asking vecause that "FAR PTR" behind the JMP instruction actually makes label OLD_INT15_VECTOR a far code label which surely isn't what you want to achieve. OLD_INT15_VECTOR is a normal variable holding a FAR code address, that's something completely different.

The assembler (masm or tasm) is smart enough to know that a DWORD variable in 16-bit will hold a FAR address, so no type cast is needed, just code JMP CS:[OLD_INT15_VECTOR].

That's the problem with looking at someone else's block of code. I rewrote it with FASM and it worked as it should have but haven't got around to converting it to MASM (or is it TASM?)

[popcalent]

That's the problem with looking at someone else's block of code. I rewrote it with FASM and it worked as it should have but haven't got around to converting it to MASM (or is it TASM?)

TASM

[popcalent]

It seems to work now with JMP CS:[OLD_INT15_VECTOR]. However, I guess I need to uninstall my handler after exiting the program because if I execute it a second time it crashes.

[NoCforMe]

I guess I need to uninstall my handler after exiting the program because if I execute it a second time it crashes.

Yes, you definitely do. Otherwise that interrupt vector is pointing straight into garbage.

I hope you're not getting too frustated here; this is just beginning to be fun.

[FORTRANS]

Hi,

   I am not sure this is of interest, but I replied to a question
about interrupt handling a while back.

"Interrupt Hooking in MS DOS"

https://masm32.com/board/index.php?topic=9494.msg103835#msg103835

Regards,

Steve N.

[NoCforMe]

Some useful stuff in there for sure.

Hey, I'd forgotten about those DOS (INT 21h) functions to get and set an interrupt vector (35h & 25h respectively). That's a more kosher way to handle it, rather than my method of just "peeking and poking" down there in the "zero segment", which'll work, but better to do it through the OS.

[popcalent]

Thanks.

I'll be working on this later this week and get back to you guys.