PEEKing bytes needed to hold screen 
Author Message
 PEEKing bytes needed to hold screen

I am writing a subroutine that will BSAVE the contents of the screen and
another that will BLOAD them back up later. the idea is that it will work on
any of the Qbasic screen modes. There is a memory location that is supposed
to hold the number of bytes needed to store the graphics information for one
screen in the current mode (Provided by BIOS). It worked in some screen
modes but returned a value that was way off in SCREEN 13. Am I doing
something wrong?

Here's the part that's not working:

DEF SEG = &H40
ScreenBytes& = PEEK(&H4D) * 256& + PEEK(&H4C)

And here's the full sub:

SUB SaveScreen (File$)
  DEF SEG = &H40
  VideoMode% = PEEK(&H49)
  PageOffset& = PEEK(&H4F) * 256&  + PEEK(&H4E)
  ScreenBytes& = PEEK(&H4D) * 256& + PEEK(&H4C)
  IF VideoMode% >= 0 AND VideoMode% <= 6 THEN VideoSeg& = &HB800
  IF VideoMode% = 7 THEN VideoSeg& = &HB000
  IF VideoMode% >= &HD AND VideoMode% <= &H13 THEN VideoSeg& = &HA000
  DEF SEG = VideoSeg&
  BSAVE File$, PageOffset&, ScreenBytes&
  DEF SEG
END SUB

--
Cyd
Visit my programming Web site:
http://www.*-*-*.com/ ~snicker/



Fri, 12 Oct 2001 03:00:00 GMT  
 PEEKing bytes needed to hold screen

Quote:
> any of the Qbasic screen modes. There is a memory location that is
supposed
> to hold the number of bytes needed to store the graphics information for
one
> screen in the current mode (Provided by BIOS). It worked in some screen
> modes but returned a value that was way off in SCREEN 13.

> DEF SEG = &H40
> ScreenBytes& = PEEK(&H4D) * 256& + PEEK(&H4C)

"The Programmer's PC Sourcebook" describes those memory addresses as "length
of the regen buffer in bytes". It also notes that, on a Phoenix BIOS, the
meaning is the current page size. Dunno to what extent the meanings differ,
although it seems like they'd be the same or close.

On my system, your formula comes up with 64000, which is the proper length
for SCREEN 13 (320 * 200 pixels, where each pixel takes up one byte). Are
you getting something else?

Possibly it would be easier to get the current screen mode and calculate the
buffer size accordingly.  The display mode is the byte at &H40:&H49, or
&H0:&H449 if that's easier. It corresponds to the BIOS display mode. I'm not
eager to type in all of the info for all of the display modes-- check
against the BASIC SCREEN modes you want to support, or be specific about
what information you'd like me to post. You should be able to find this info
from any number of other sources as well.



Sat, 13 Oct 2001 03:00:00 GMT  
 PEEKing bytes needed to hold screen
I get 8192 in screen 13 and 4096 in screen 0.  O well I can do it the other
way I just thought it would be easier and faster this way.


Quote:


> > any of the Qbasic screen modes. There is a memory location that is
> supposed
> > to hold the number of bytes needed to store the graphics information for
> one
> > screen in the current mode (Provided by BIOS). It worked in some screen
> > modes but returned a value that was way off in SCREEN 13.

> > DEF SEG = &H40
> > ScreenBytes& = PEEK(&H4D) * 256& + PEEK(&H4C)

> "The Programmer's PC Sourcebook" describes those memory addresses as
"length
> of the regen buffer in bytes". It also notes that, on a Phoenix BIOS, the
> meaning is the current page size. Dunno to what extent the meanings
differ,
> although it seems like they'd be the same or close.

> On my system, your formula comes up with 64000, which is the proper length
> for SCREEN 13 (320 * 200 pixels, where each pixel takes up one byte). Are
> you getting something else?

> Possibly it would be easier to get the current screen mode and calculate
the
> buffer size accordingly.  The display mode is the byte at &H40:&H49, or
> &H0:&H449 if that's easier. It corresponds to the BIOS display mode. I'm
not
> eager to type in all of the info for all of the display modes-- check
> against the BASIC SCREEN modes you want to support, or be specific about
> what information you'd like me to post. You should be able to find this
info
> from any number of other sources as well.



Sat, 13 Oct 2001 03:00:00 GMT  
 PEEKing bytes needed to hold screen

Quote:
> I get 8192 in screen 13 and 4096 in screen 0.  O well I can do it the
other
> way I just thought it would be easier and faster this way.

The makers of your video card may not care about DOS compatibility-- but you
might try bringing it up with them. I'd be inclined to describe such
behavior as a bug. Wouldn't be a Diamond card, by any chance? They're a bit
notorious for such quirks.


Sat, 13 Oct 2001 03:00:00 GMT  
 PEEKing bytes needed to hold screen
I have a Matrox Millennium II AGP, which I know nothing about. I have a Dell
computer and I think it is interesting that the Dells at my school do the
same thing. However I do not know what video card they are using. Isn't that
memory location handled by the BIOS?

Cyd


Quote:


> > I get 8192 in screen 13 and 4096 in screen 0.  O well I can do it the
> other
> > way I just thought it would be easier and faster this way.

> The makers of your video card may not care about DOS compatibility-- but
you
> might try bringing it up with them. I'd be inclined to describe such
> behavior as a bug. Wouldn't be a Diamond card, by any chance? They're a
bit
> notorious for such quirks.



Mon, 15 Oct 2001 03:00:00 GMT  
 PEEKing bytes needed to hold screen

Quote:
> I have a Matrox Millennium II AGP, which I know nothing about. I have a
Dell
> computer and I think it is interesting that the Dells at my school do the
> same thing. However I do not know what video card they are using. Isn't
that
> memory location handled by the BIOS?

That's a bit more of a complex question than it may appear. The BIOS data
area may be handled by the ROM BIOS on the main computer (for older
computers, and for MDA and CGA display modes), by the ROM BIOS(es) on your
video card(s), by installed drivers (such as ANSI.SYS, or Windows device
drivers), and by other programs. There is no law that says a manufacturer
needs to provide BIOS-compatible support for their video card, but it's a
feature that's generally taken for granted, since it strongly affects
compatibility with existing DOS programs, and it's a trivial feature to
implement. The specific information that you're looking at is not widely
used, however. Chances are that you've discovered a small bug in the Matrox
BIOS implementation. You might want to check with 'em on that.


Wed, 17 Oct 2001 03:00:00 GMT  
 PEEKing bytes needed to hold screen
Yes there are differences in the Bits Pre Pixel between all the modes most
of them run in 4Bit color, but SCREEN 13 uses 8 Bit colour so it gets
completly messed up, plus all of the screen modes are different sizes.
If you wanted to implement this you should think about making your own
Graphics file type that would be able to use all of these modes.

Screech


Quote:
> I am writing a subroutine that will BSAVE the contents of the screen and
> another that will BLOAD them back up later. the idea is that it will work
on
> any of the Qbasic screen modes. There is a memory location that is
supposed
> to hold the number of bytes needed to store the graphics information for
one
> screen in the current mode (Provided by BIOS). It worked in some screen
> modes but returned a value that was way off in SCREEN 13. Am I doing
> something wrong?

> Here's the part that's not working:

> DEF SEG = &H40
> ScreenBytes& = PEEK(&H4D) * 256& + PEEK(&H4C)

> And here's the full sub:

> SUB SaveScreen (File$)
>   DEF SEG = &H40
>   VideoMode% = PEEK(&H49)
>   PageOffset& = PEEK(&H4F) * 256&  + PEEK(&H4E)
>   ScreenBytes& = PEEK(&H4D) * 256& + PEEK(&H4C)
>   IF VideoMode% >= 0 AND VideoMode% <= 6 THEN VideoSeg& = &HB800
>   IF VideoMode% = 7 THEN VideoSeg& = &HB000
>   IF VideoMode% >= &HD AND VideoMode% <= &H13 THEN VideoSeg& = &HA000
>   DEF SEG = VideoSeg&
>   BSAVE File$, PageOffset&, ScreenBytes&
>   DEF SEG
> END SUB

> --
> Cyd
> Visit my programming Web site:
> http://www.velocity.net/~snicker/



Sun, 21 Oct 2001 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Need to convert a 16 byte array of bytes to 4 byte integer

2. Need help on converting 2-byte signed to 2-byte unsigned

3. Holding screen updates

4. Need help on Peek / Poke comands

5. STILL NEED HELP: INITIALIZING WAV FILE HELD IN ACCESS db THRU VB

6. STILL NEED HELP: INITIALIZING WAV FILE HELD IN ACCESS db THRU VB

7. I need hand held RF units that run Windows

8. Q: Copy screen into a byte array

9. How to convert 4 byte date to 8 byte date

10. Copy bytes from an Integer to a location of bytes array

11. VB6 Byte Array to Byte()

12. Invalid byte was found at byte index n

 

 
Powered by phpBB® Forum Software