Re: [Bochs-developers] Last standard video mode

[Dave P. <ek...@on...>]

On Fri, Mar 15, 2002 at 02:42:02PM +0100, Sebastien Bechet wrote:
> Hello bochs-dev and others,
> 
> le jeu 14-03-2002 ? 15:01, Dave Poirier a ?crit :
> > On Thu, Mar 14, 2002 at 10:05:12AM +0100, Sebastien Bechet wrote:
> > > 3) -----------------------------
> > > Last question :
> > > Why Height values are so strange sometimes ?
> > > 352->350, 192->200, 208->200 ...
> > > I can't understand it.
> > 
> > The reason for this is pretty simple, the vga->gui works using 16x16
> > bitmaps.  For example, when you setup 320x200 (mode 13h), the vga
> > register will setup a GUI window of 320x208, which is is a perfect 16x16
> > multiple.
> 
> Okey, so, why sometimes 192 and sometimes 208 ?
> 192 is impossible in my opinion because we can't see the last part of
> the screen, so ?

hrm, I don't know, but in vga.cc the following code exists:

        if (BX_VGA_THIS s.CRTC.reg[19] == 0x14)
          {
          BX_VGA_THIS s.scan_bits=320;
          *piWidth = 320;
          *piHeight = 192;
          }
        else
          {
          *piWidth = 640;
          *piHeight = 208;
          }

I'm not too sure what this is supposed to mean, AFAIK there is no
320x192 mode, I only know of 320x200 and 320x240.  Maybe there are some
CRTC/VGA gurus who could explain that better.

> I think vga.cc must not not have GUI dependances... Do you think we can
> do something ?

yes, we can do something ;)

> In my last CGA patch (in CVS since one month i think), I choose 200
> because I don't read and understand determine_screen_dimensions()
> before. So, there is certainly a _segfault_ or strange things somewhere
> in the GUI now ?

the only time I have experienced a segfault with the vga/gui code
related to the x.y resolution of the emulated window is when the GUI
window is created in 320x200 (some experiment I did with SDL) while the
vga code really sets it to 320x208.  Again though, I sincerly think all
this should be changed.

> In last 1.4pre2 I can see strange vertical lines at top of the screen in
> CGA 320*200*2 maybe the problem ?
> 
> > Personally I believe the entire vga->gui protocol should be changed, but
> > that can always wait for now.
> 
> It's my opinion. Do you have an idea to expose to do it better ?
> 
> Three things in my mind :
> 
> * Seems X_TILESIZE*Y_TILESIZE blocks rest a good idea for speed.

I think I do..

> * A possibity is : Always work in 640*480 for GUI and to MAP all video
> modes to this size. Better because 320*200/240 are really small
> resolutions for today's screen.
> 320*200 -> 640*400 with 80 dark lines (40 upper/40 lower in GUI's)
> 640*200 -> 640*400 with 80 dark lines (...) (double vertical lines)
> 320*240 -> 640*480 (double horizontal and vertial lines)
> 640*350 -> 640*350 with 130 dark lines (65 upper/65 lower in GUI's)
> 640*480 -> 640*480

I wouldn't do that.  First, what would happen of 1024x768 and above
video modes? second, the GUI code already supports modifying the Bochs
window, so this part of the code would have to be stripped down, meaning
more work.

> * Do you think we can have a sort of "xterm like" when we are in text
> video mode ? How much the work can be hard ?

It is possible, and midly hard, but it is complicated by videomodes
which allow both text and graphic to be displayed at the same
time.  Now, the "xterm like" means to me 2 things:

1.) the text is buffered so we can scroll back and see previous lines
2.) we can select text and copy/paste it

I don't think we should implement buffering, this should be a guest-os
feature.  As for selection, it would be nice, but as said above, it
would be tad hard with text/gfx combo modes using the current setup.

Now, what I see is the following for vga<->gui communication.

  The vga.cc would pass the bitmaps to print in variable height and
  width, always using 24bpp.

    The current code have to actually update the entire palette before
    displaying every 16x16 bitmap.  This penalty is great and I
    suspect it to be the reason behind a vga refresh to be so slow.

    Using a fixed bpp would simplify both the gui and vga code, and
    a significant speed gain could be achieved if the host os can
    provide a native 24/32 bpp mode for Bochs.

    The variable height and width of the passed bitmaps fixes the
    problem we are having with 320x(208/192) mode;  could reduce the
    number of function calls required between the vga and gui code
    to update a screen area.

  The text->gfx conversion should be handled internally by the vga
  code using a modifiable font.

    This would make dealing with text/gfx combo modes possible, and
    would remove the dependency for an external fixed-width vga font.

  if selection is ever implemented, the gui code could query the vga
  for the content in range x.y/x.y, and the vga code would return a
  pointer to the content with indication as whether it is text or
  graphic, in both cases returning the number of units (text chars or
  pixels) horizontally and vertically and the pitch between the lines.

There are probably things that could be improved in this model, but I
personally believe that this is already better than what we have at the
moment.  Feel free to suggest your own model :)

EKS - Dave Poirier