graph unit 
Author Message
 graph unit

Free Pascal Compiler version 1.00.0 [2000/07/07] for i386
Target: GO32v2

I have downloaded the FPC v1.00, but I encountered some
problem when using the graph unit. This problem is specific to the
VGA card I use; other people do not have this problem.
(I use a 8MB AGP i740 accelerator card using VBE 2.0 . It is
known to support LinearFrameBuffer but not banked mode.)

When testing with a simple program which draws dots on the screen,
the compiled program does not write to the video screen, but
instead write to the current video mode.

For example, when the program is executed from a full-screen
text-mode DOS Prompt under Windows 98, the characters become garbled;
both the 80x25 text-mode screen and the 16*8 font becomes rubbish.

When it is executed from a windowed DOS Prompt inside Windows, the dots
are drawn to the Windows' Screen ! (the 'Start' button soon disappears)

When I try to use GDB.exe to debug it, a fatal GPF is generated which
causes the machine to hang (with the blue screen).

It seems that the compiled program does not switch to the video mode
correctly before drawing anything to it.

Any idea?

(If you need the executable, I can send it to you)

uses graph,crt;
var gd,gm:word;
  c:longint;
begin
  detectgraph(gd,gm);
  initgraph(gd,gm,'');
  repeat
    c:=random(getmaxcolor);
    putpixel(random(getmaxx),random(getmaxy),c);
  until keypressed;
  while keypressed do readkey;
  closegraph;
end.

--



Tue, 07 Jan 2003 03:00:00 GMT  
 graph unit

Quote:
> I have downloaded the FPC v1.00, but I encountered some
> problem when using the graph unit. This problem is specific to the
> VGA card I use; other people do not have this problem.
> (I use a 8MB AGP i740 accelerator card using VBE 2.0 . It is
> known to support LinearFrameBuffer but not banked mode.)

> When testing with a simple program which draws dots on the screen,
> the compiled program does not write to the video screen, but
> instead write to the current video mode.

Jonas (who wrote Graph) is the one for this kind of questions,
but I think it is the fact that it is the opposite way:
Graph supports banked, but not LFB


Tue, 07 Jan 2003 03:00:00 GMT  
 graph unit

Quote:
> > When testing with a simple program which draws dots on the screen,
> > the compiled program does not write to the video screen, but
> > instead write to the current video mode.

> Jonas (who wrote Graph) is the one for this kind of questions,
> but I think it is the fact that it is the opposite way:
> Graph supports banked, but not LFB

This answer to this post I got via Email from Thomas Schatzl, try it.

Set the variable UseLFB to true before a call to InitGraph.

E.g.
begin
    UseLFB := true;
    gd := <whatever>; gm := <something else>;
    InitGraph(gd, gm, '');
    <do your work>
    CloseGraph;
end.

--




Wed, 08 Jan 2003 03:00:00 GMT  
 graph unit

Quote:
> Set the variable UseLFB to true before a call to InitGraph.

> E.g.
> begin
>     UseLFB := true;
>     gd := <whatever>; gm := <something else>;
>     InitGraph(gd, gm, '');
>     <do your work>
>     CloseGraph;
> end.

It does not work...
I tried both auto-detect (using GraphDetect)
and manually setting the mode. Both do not work.

Is this feature disabled in 1.00.0 [2000/07/07] ?

Maybe it is not related to LFB...
The pixels are still drawn everywhere, from Windows' screen
to VGA text font buffer and Text mode screen...

Perhaps the program doesn't even call to switch video mode...
( How do I check this with GDB ? )

Thanks.



Wed, 08 Jan 2003 03:00:00 GMT  
 graph unit

Quote:

> Free Pascal Compiler version 1.00.0 [2000/07/07] for i386
> Target: GO32v2

> I have downloaded the FPC v1.00, but I encountered some
> problem when using the graph unit. This problem is specific to the
> VGA card I use; other people do not have this problem.
> (I use a 8MB AGP i740 accelerator card using VBE 2.0 . It is
> known to support LinearFrameBuffer but not banked mode.)

That should be ok, the linear frame buffer support has been fixed in the
graph unit of version 1.0 (it works fine now on my S3 trio64 with univbe).

Quote:
> When testing with a simple program which draws dots on the screen,
> the compiled program does not write to the video screen, but
> instead write to the current video mode.

> For example, when the program is executed from a full-screen
> text-mode DOS Prompt under Windows 98, the characters become garbled;
> both the 80x25 text-mode screen and the 16*8 font becomes rubbish.

> When it is executed from a windowed DOS Prompt inside Windows, the dots
> are drawn to the Windows' Screen ! (the 'Start' button soon disappears)

That's really weird... Normally, windows should switch to full screen
after you enter the graph mode.

Quote:
> When I try to use GDB.exe to debug it, a fatal GPF is generated which
> causes the machine to hang (with the blue screen).

?? I've never seen this before... It is very hard to debug graph programs
under Dos with GDB (unless you use standard VGA modes) since you don't see
any output from GDB, but it shouldn't crash windows.

Quote:
> It seems that the compiled program does not switch to the video mode
> correctly before drawing anything to it.

Indeed. But you don't check whether the switch is successful either in
your program. One problem may be that as of a certain VESA version (I
don't remember whether it was 2.0 or 3.0), the mode numbers aren't really
defined anymore. E.g. in VESA 1.x, mode $101 is always 640x480x256, but as
of that VESA version mode $101 may either not exist or be a completely
different resolution.

However, we do get all supported VESA mode numbers straight from calling
an interrupt, so even if that were the case, you'd simply end up in a
different mode than what you asked for.

Quote:
> Any idea?

Do you have any Dos SVGA programs that do run correctly on your system?
Also, try changing the following in your program

Quote:
> (If you need the executable, I can send it to you)

> uses graph,crt;
> var gd,gm:word;
>   c:longint;
    error: integer;
> begin
>   detectgraph(gd,gm);
>   initgraph(gd,gm,'');

    error := graphresult;
    if error <> grok then
      begin
        writeln(grapherrormsg(error));
        halt(1);
      end;

Quote:
>   repeat
>     c:=random(getmaxcolor);
>     putpixel(random(getmaxx),random(getmaxy),c);
>   until keypressed;
>   while keypressed do readkey;
>   closegraph;
> end.

See if you get an error.

Jonas



Sun, 12 Jan 2003 03:00:00 GMT  
 graph unit

Quote:

> Indeed. But you don't check whether the switch is successful either in
> your program. One problem may be that as of a certain VESA version (I
> don't remember whether it was 2.0 or 3.0), the mode numbers aren't really
> defined anymore. E.g. in VESA 1.x, mode $101 is always 640x480x256, but as
> of that VESA version mode $101 may either not exist or be a completely
> different resolution.

That would be really weird.. that means that VBE 2.0/3.0 isn't really fully
VBE1.0/1.2 compliant


Sun, 12 Jan 2003 03:00:00 GMT  
 graph unit

Quote:

> > Indeed. But you don't check whether the switch is successful either in
> > your program. One problem may be that as of a certain VESA version (I
> > don't remember whether it was 2.0 or 3.0), the mode numbers aren't really
> > defined anymore. E.g. in VESA 1.x, mode $101 is always 640x480x256, but as
> > of that VESA version mode $101 may either not exist or be a completely
> > different resolution.

> That would be really weird.. that means that VBE 2.0/3.0 isn't really fully
> VBE1.0/1.2 compliant

Correct. You can see it for yourself by downloading the file vbe3.pdf
from somewhere under <ftp://ftp.vesa.org/pub>. I'd copy/paste the
relevant paragraph, but they don't allow selecting/copying text from
that PDF file :/

It's on page 27 under the mode numbers table.

Jonas



Sun, 12 Jan 2003 03:00:00 GMT  
 graph unit

Quote:

> > Indeed. But you don't check whether the switch is successful either in
> > your program. One problem may be that as of a certain VESA version (I
> > don't remember whether it was 2.0 or 3.0), the mode numbers aren't really
> > defined anymore. E.g. in VESA 1.x, mode $101 is always 640x480x256, but as
> > of that VESA version mode $101 may either not exist or be a completely
> > different resolution.

> That would be really weird.. that means that VBE 2.0/3.0 isn't really fully
> VBE1.0/1.2 compliant

Correct

From the VBE 2.0 doc:

Quote:
> Note: Starting with VBE version 2.0, VESA will no longer define new VESA mode numbers
> and it will not longer be mandatory to support these old mode numbers.  However, it is
> highly recommended that BIOS implementations continue to support these mode numbers
> for compatibility with older software.
> VBE 2.0-aware applications should follow the guidelines in Appendix 5 - Application
> Programming Considerations - for setting a desired mode.

Michael
--
+-----------------------------------------------------------------+
| Michael Knapp - Mauerbach - Nieder?sterreich - Austria - Europe |
|   Informatik-Student an der TU-Wien - http://www.tuwien.ac.at   |

+-----------------------------------------------------------------+
|     G r a p h i X  -  Freeware Graphics-Library for Pascal      |
|           http://programmierer.freepage.de/graphix              |
+-----------------------------------------------------------------+


Sun, 12 Jan 2003 03:00:00 GMT  
 graph unit
continued:

Quote:
> Note:  Future display resolutions will be defined by VESA display vendors.  
> The color depths will not be specified and new mode numbers will not be assigned
> for these resolutions.  For example, if the VESA display vendors define 1600x1200
> as a VESA resolution, application developers should target their display resolution
> for 1600x1200 rather than choosing an arbitrary resolution like 1550x1190.
> The VBE implementation should be queried to get the available resolutions and color
> depths and the application should be flexible enough to work with this
> list.  Appendix 5 gives a detailed summary of the way an application should go
> about selecting and setting modes.

Michael


Sun, 12 Jan 2003 03:00:00 GMT  
 graph unit

Quote:

> > E.g. in VESA 1.x, mode $101 is always 640x480x256, but as
> > of that VESA version mode $101 may either not exist or be a completely
> > different resolution.

> That would be really weird.. that means that VBE 2.0/3.0 isn't really
fully
> VBE1.0/1.2 compliant

Indeed. VBE 2.0 was a complete and utter balls up. Jesus, who are these
people who are given the task of defining standards, 12 year-old computer
enthusiasts or just stupid lazy bastards that can't actually do anything
productive?

Thankfully most, if not all VBE implementors kept to the 1.x mode number
standard.

--
Jay

Jason Burgon - Author of "Graphic Vision"
Professional Win95-style GUI for DOS/DPMI
Graphic Vision evaluation (version 2.04) available from:
http://www.jayman.demon.co.uk



Sun, 12 Jan 2003 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. problem with the graph unit-graph.tpu

2. graph unit

3. Graph unit question.

4. Patch for Graph Unit of fast PCs

5. TP7 Graph unit, conflicts with windows XP ?

6. Patch for Graph Unit of fast PCs

7. graph unit text input

8. Graph unit trouble!

9. TPW Graph unit - is anyone interested?

10. Graph Unit Help?

11. graph unit

12. URGENT: Two Graph Unit Questions.

 

 
Powered by phpBB® Forum Software