I'm designing a graphics program, and I want to be able to have 16-bit color and 32-bit color. DirectQB only gives me the familiar screen 13, and future library aborts if given a bad mode. I'm thinking of writing my own VESA routines in MASM (I happen to have the VESA specs)
Also, DirectQB doesn't want to work with QB7.1
Do I need to do anything (like screen 13) before switching VESA modes, or will QBasic figure out what I'm up to?
Would there be any problems with using VESA in QB via MASM modules? I'm curious if there are any subtle details I need to know about.
I really need a response ASAP, even if its to say I shouldn't be asking. I'm a newbie, so dont flame me.
VESA standard VS DirectQB & Future Library
Moderators:Administrator, Global Moderator
-
Guest
Re: VESA standard VS DirectQB & Future Library
Remember, always error check your variables to see if they are out of range.
-
Guest
Re: VESA standard VS DirectQB & Future Library
Good advice for general programming, :)
But it doesn't help for this specific problem ???
What I want to do is write a library with MASM, then make a QuickLibrary to use with QB7.1
Will there be any technical problems if in that assembly code I include access to INT 10h, function 4Fh (This selects subfunctions that are part of the VESA standard)
Will QB freak out if its "text mode" changes to graphics without it knowing? Do I need to at least set it to some graphics?
I tried using VESA, and QB started acting REALLY weird, but the biggest problem is a corrupt screen if I BREAK, STOP, or END. Weird snow doesn't look good.
Is there anything I need to do to prepare QB for a VESA mode, or is it as simple as just calling the VESA interrupt and doing as I please with the video memory? ???
But it doesn't help for this specific problem ???
What I want to do is write a library with MASM, then make a QuickLibrary to use with QB7.1
Will there be any technical problems if in that assembly code I include access to INT 10h, function 4Fh (This selects subfunctions that are part of the VESA standard)
Will QB freak out if its "text mode" changes to graphics without it knowing? Do I need to at least set it to some graphics?
I tried using VESA, and QB started acting REALLY weird, but the biggest problem is a corrupt screen if I BREAK, STOP, or END. Weird snow doesn't look good.
Is there anything I need to do to prepare QB for a VESA mode, or is it as simple as just calling the VESA interrupt and doing as I please with the video memory? ???
-
drrbhandari
- Newbie
- Posts:1
- Joined:Tue Feb 11, 2003 7:43 pm
Re: VESA standard VS DirectQB & Future Library
Hi pal,
I would suggest writing the break and error handlers as a part of the library or the basic code. Another trick that can be used is to launch the application from a shell which resets the appropriate modes on exit. Library would be more appropriate. Incidentally I too would like to work with a VESA library for QBasic. I too code in assembly, C++ but haven't moved on to 32bit for assembly. Any help needed or provided will be valued. ::) .
I would suggest writing the break and error handlers as a part of the library or the basic code. Another trick that can be used is to launch the application from a shell which resets the appropriate modes on exit. Library would be more appropriate. Incidentally I too would like to work with a VESA library for QBasic. I too code in assembly, C++ but haven't moved on to 32bit for assembly. Any help needed or provided will be valued. ::) .
-
Guest
Re: VESA standard VS DirectQB & Future Library
;D
All right! This is the help I've been looking for!
Regarding 32-bit assembly:
32-bit assembly code is pure hell.
1. You ***CANNOT*** access I/O ports or call common interrupt services (like INT 10h), Windows has a temper tantrum if you try.
(I tried and got a Blue Screen Of Death on the interrupt, and the I/O got me an exception unless I wrote a console program. I was trying DOS BOX graphics)
2. BIOS routines are also ***OFF LIMITS***. There is no way to access the BIOS directly, because 32-bit code is by definition protected mode code, and a 32-bit application can only go through the API. Any I/O (unless you're a console or running kernel mode), any INT instructions, and other such DOS assembly goodies are off limits if you're making 32-bit code.
3. Default register and operand size is 32-bit DWORD, not 16-bit Word.
4. Except in rare cases, there is no such thing as segmentation SEG:OFF addresses. Your code and data are flat spaces
5. You have to explicitly allocate any memory you want
(if you don't, you'll get a GP fault and your module is killed)
6. 32-bit assembly is best implemented with the __asm keyword. Using ASM for a whole program is a huge task, don't try it unless you are ready for a HUGE headache.
7. Good luck to you if you're brave (or foolhardy) enough to try.
All right! This is the help I've been looking for!
Regarding 32-bit assembly:
32-bit assembly code is pure hell.1. You ***CANNOT*** access I/O ports or call common interrupt services (like INT 10h), Windows has a temper tantrum if you try.
(I tried and got a Blue Screen Of Death on the interrupt, and the I/O got me an exception unless I wrote a console program. I was trying DOS BOX graphics)
2. BIOS routines are also ***OFF LIMITS***. There is no way to access the BIOS directly, because 32-bit code is by definition protected mode code, and a 32-bit application can only go through the API. Any I/O (unless you're a console or running kernel mode), any INT instructions, and other such DOS assembly goodies are off limits if you're making 32-bit code.
3. Default register and operand size is 32-bit DWORD, not 16-bit Word.
4. Except in rare cases, there is no such thing as segmentation SEG:OFF addresses. Your code and data are flat spaces
5. You have to explicitly allocate any memory you want
(if you don't, you'll get a GP fault and your module is killed)
6. 32-bit assembly is best implemented with the __asm keyword. Using ASM for a whole program is a huge task, don't try it unless you are ready for a HUGE headache.
7. Good luck to you if you're brave (or foolhardy) enough to try.