News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Double buffer in mode 13H

Started by popcalent, February 07, 2024, 04:46:28 PM

Previous topic - Next topic

sinsi

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

popcalent

Quote from: sinsi on February 13, 2024, 04:05:59 PMI 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
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

Quote from: sinsi on February 13, 2024, 04:23:46 PMYou 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  :nie:

NoCforMe

Quote from: sinsi on February 13, 2024, 04:23:46 PMMove 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 ...
Assembly language programming should be fun. That's why I do it.

sinsi

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

_japheth

Quote from: NoCforMe on February 13, 2024, 06:59:52 PMYes; 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].
Dummheit, gepaart mit Dreistigkeit - eine furchtbare Macht.

popcalent

Quote from: sinsi on February 13, 2024, 07:18:05 PMOne 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

Quote from: _japheth on February 13, 2024, 07:41:12 PM
Quote from: NoCforMe on February 13, 2024, 06:59:52 PMYes; 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

Quote from: sinsi on February 13, 2024, 08:23:54 PMThat'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

Quote from: popcalent on February 14, 2024, 05:39:57 AMI 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.
Assembly language programming should be fun. That's why I do it.

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.
Assembly language programming should be fun. That's why I do it.

popcalent

Thanks.

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