Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #952 > unrolled thread

MS-DOS direct screen output - native and in a window

Back to article view | Back to comp.os.msdos.programmer

Contents

  MS-DOS direct screen output - native and in a window "James Harris" <james.harris.1@gmail.com> - 2013-08-29 10:10 +0100
    Re: MS-DOS direct screen output - native and in a window "R.Wieser" <address@not.available> - 2013-08-29 12:58 +0200
    Re: MS-DOS direct screen output - native and in a window "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 05:59 -0500
      Re: MS-DOS direct screen output - native and in a window "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 07:23 -0500
        Re: MS-DOS direct screen output - native and in a window "Bill Buckels" <bbuckels@mts.net> - 2013-08-29 08:35 -0500
    Re: MS-DOS direct screen output - native and in a window "Ed" <invalid@invalid.com> - 2013-09-28 20:34 +1000
      Re: MS-DOS direct screen output - native and in a window pete@nospam.demon.co.uk - 2013-09-29 06:45 +0000
        Re: MS-DOS direct screen output - native and in a window "Ed" <invalid@invalid.com> - 2013-09-29 19:33 +1000
          Re: MS-DOS direct screen output - native and in a window "James Harris" <james.harris.1@gmail.com> - 2013-09-29 16:06 +0100
            Re: MS-DOS direct screen output - native and in a window "Ed" <invalid@invalid.com> - 2013-10-01 11:28 +1000

#952 — MS-DOS direct screen output - native and in a window

Basic question: Is there a "good" way for DOS direct screen writes to be 
handled?

From what I have found so far MS-DOS programmers are expected to use BIOS 
services for screen writes. That is surprising but it is OK as it stands. 
However, how should things like the screen size (rows and columns) be 
determined? I know there is a BIOS call int 0x10-0f to get the columns but 
not the rows.

Furthermore, under Windows the display size could even be changed as the 
program runs.

I have seen programs that force a window to a specific mode/size (and kill 
the scrollback buffer at the same time). Possibly they are "real" MS-DOS 
programs...? ;-)

Is there any standard or recommended way for programs to carry out direct 
screen writes (i.e. to arbitrary parts of the screen) that works in pure 
MS-DOS but also works well under Windows?

James

[toc] | [next] | [standalone]

#953

Hello James,

> That is surprising but it is OK as it stands.

Not all, as video-cards are (still) as different as people.  Using
(Video-)BIOS calls was one way to make sure that any needed conversion was
handled by the driver-program especially written for that card.

Compare it to the nowerdays (still needed!) installation of a video-driver.
Don't do it and you get only standard stuff, low resolutions & color depths
and slow speeds.

> However, how should things like the screen size (rows and
> columns) be determined?

Take a look at Int21h, 440Ch, and search for "character rows" (I'm using
RBIL)

The above method was gleaned off of DOS 5.0 own MORE command. :-)

> Furthermore, under Windows the display size could even be
> changed as the program runs.

Sorry, but that is Windows, which has got nothing to do with DOS at all.

> I have seen programs that force a window to a specific mode/size

I've been told that that possibility is removed in Win 7.  Can't say
anything about Win 8.x.  For Win XP its as easy as calling the MODE CON
COLS=80 ROWS=25.  And as long as that works switching video-mode by using
INT 10h, AH=00h should be possible too. :-)

> Possibly they are "real" MS-DOS programs...? ;-)

Any program can request it, but its upto the OS to honour it.  If it
doesn't, you're SOL.

I happened to me when I needed to run an old QBASIC (DOS 5.0) on a Win7
machine.  It refused.  I had to install a program called 'DosBox' to be able
to do it.

> Is there any standard or recommended way for programs
> to carry out direct screen writes (i.e. to arbitrary parts of
> the screen) that works in pure MS-DOS but also works
> well under Windows?

Not that I know of.   Also be aware of the fact that Windows has been
removing more-and-more DOS/console functionality, and there is no way to
tell how such removals will break certain DOS methods.

Regards,
Rudy Wieser


-- Origional mesage:
James Harris <james.harris.1@gmail.com> schreef in berichtnieuws
kvn372$vnt$1@dont-email.me...
> Basic question: Is there a "good" way for DOS direct screen writes to be
> handled?
>
> From what I have found so far MS-DOS programmers are expected to use BIOS
> services for screen writes. That is surprising but it is OK as it stands.
> However, how should things like the screen size (rows and columns) be
> determined? I know there is a BIOS call int 0x10-0f to get the columns but
> not the rows.
>
> Furthermore, under Windows the display size could even be changed as the
> program runs.
>
> I have seen programs that force a window to a specific mode/size (and kill
> the scrollback buffer at the same time). Possibly they are "real" MS-DOS
> programs...? ;-)
>
> Is there any standard or recommended way for programs to carry out direct
> screen writes (i.e. to arbitrary parts of the screen) that works in pure
> MS-DOS but also works well under Windows?
>
> James
>
>

[toc] | [prev] | [next] | [standalone]

#954

"James Harris" <james.harris.1@gmail.com> wrote:

>Basic question: Is there a "good" way for DOS direct screen writes to be 
>handled?

Hi James,

Through the 80's and into the '90's I wrote MS-DOS programs in the C and 
Assembly language for a living. Like the other C programmers of the day I 
generally used the BIOS calls to set-up my screen mode controls, both 
graphics and text,  but wrote directly to the screen.

That is the best way.

Bill

 

[toc] | [prev] | [next] | [standalone]

#955

"Bill Buckels" <bbuckels@mts.net> wrote:

>> "James Harris" <james.harris.1@gmail.com> wrote:
>> Basic question: Is there a "good" way for DOS direct screen writes to be 
>> handled?
> I  generally used the BIOS calls to set-up my screen mode controls, both 
> graphics and text,  but wrote directly to the screen.

Since this is a programming group, I will provide you with a short example. 
I assume you know about programming and about the PC's memory layout and 
BIOS and MS-DOS. Keep in mind that this has nothing to do with Windows. 
Simple user commands like the mode command in windows predate Windows to 
MS-DOS. This is not about user commands. This is about programming in MS-DOS 
using BIOS calls. For help with Windows type HELP in Windows.

You can download some examples with compiler from my Aztec C website's 
compiler page:

Aztec C86 for the 8086
Version 4.2b
9/29/89
Rebundled for Windows XP

http://www.aztecmuseum.ca/AztecC86.zip

The code is from a text screen demo in that bundle called batch.exe.

Typically when one used a bsaved text screen as a background in text screen 
memory the text cursor needed to be turned off, and turned back on again 
afterwards. One always defaulted to monochrome screen memory address and 
checked for color adapter in the bios.

One always used int16h for keypresses and hilighted menus were generally 
arrow keyed controlled which always took special handling because of the 
first null byte for the extended keys.

You will note that I use two different methods to make my BIOS assembly 
level calls. All the good compilers of the day provided a REGS interface, 
and the good ones also provided inline assembly.

The screen arrays are simple PCX style encoded text screens.

Bill

x-- snip --x

/* reference */
unsigned char BATCH000[], BATCH001[],BATCH002[],BATCH003[],BATCH004[];

struct regs{
    int AX;
    int BX;
    int CX;
    int DX;
    int SI;
    int DI;
    int DS;
    int ES;
}inregs,outregs;

#define SCREENSIZE 4000
unsigned int SCREENSEG= 0xb000;

#define TERMINATOR 1

void showpic(int argc, unsigned char *argv)
{

    unsigned int byteoff=0,secondoff=1,packet;
    unsigned char byte,bytecount;
    int wordcount,target;
    unsigned char *databuf;
    unsigned int segregs[4];

    target = argc-TERMINATOR;
    databuf = malloc(SCREENSIZE);

    wordcount=0;
    do{ bytecount=1;                          /* start with a seed count */
        byte=argv[wordcount];
        wordcount++;
                                              /* check to see if its raw */
        if(0xC0 == (0xC0 &byte)){             /* if its not, run encoded */
                    bytecount= 0x3f &byte;
                    byte=argv[wordcount];
                    wordcount++;
                    }
        for(packet=0;packet<bytecount;packet++){
                   if(byteoff<SCREENSIZE){
                        databuf[byteoff]=byte;
                        byteoff+=2;
                        }
                   else{
                        databuf[secondoff]=byte;
                        secondoff+=2;
                        }
                    }

        }while(wordcount<target);

          #define dseg 2
          /* returns base of dgroup */
          segread(&segregs);
          movblock(*((unsigned int*)&databuf),segregs[dseg],
                     0x0000,SCREENSEG,SCREENSIZE);
         free(databuf);
}

unsigned int catch()
{
           inregs.AX = 0x0000;
           inregs.DX = 0x0000;
           sysint(0x16,&inregs,&outregs);
           return outregs.AX&0x00ff;
}


main()
{
    int i;

    sysint(0x11,&inregs,&outregs); /* get equipment list from the bios */
    /* get display type (bits 4 and 5 of ax) */
    if ((outregs.AX & 0x30) < 0x30)SCREENSEG=0xb800;

               /* clearscreen and turn cursor off */
               #asm
                 mov ah,6
                 mov al,0
                 mov cx,0
                 mov dh,24
                 mov dl,79
                 mov bh,0
                 int 10h
                 xor ax,ax
                 mov ah,1
                 mov cx,2000h
                 int 10h
               #endasm
        /* allow a keypress to advance */
        /* allow escape to exit */

        for(i=0;i<5;i++)
        {
          switch(i)
          {
            case 0:showpic(sizeof(BATCH000),BATCH000);break;
            case 1:showpic(sizeof(BATCH001),BATCH001);break;
            case 2:showpic(sizeof(BATCH002),BATCH002);break;
            case 3:showpic(sizeof(BATCH003),BATCH003);break;
            case 4:showpic(sizeof(BATCH004),BATCH004);break;
            }
          if(catch()==27)i+=5;
          }

       /* clear screen and turn cursor on */
       #asm
           mov ah,6
           mov al,0
           mov cx,0
           mov dh,24
           mov dl,79
           mov bh,0eh
           int 10h
           xor ax,ax
           mov ah,1
           mov cx,0607h
           int 10h
       #endasm
       exit(0);
}

[toc] | [prev] | [next] | [standalone]

#960

"Bill Buckels" <bbuckels@mts.net> wrote:

> hilighted menus were generally arrow keyed controlled which always took 
> special handling because of the first null byte for the extended keys.

An example of how we do this is here (see source code for SHOWPIX - Menu 
Driven Picture Viewer for DOS):

http://www.teacherschoice.ca/kidstuff/worktool/wrktoo20.zip

Doc: http://www.teacherschoice.ca/kidstuff/worktool/wrktoo20.txt

Bill 

[toc] | [prev] | [next] | [standalone]

#1004

James Harris wrote:
> ...
> However, how should things like the screen size (rows and columns) be
> determined? I know there is a BIOS call int 0x10-0f to get the columns but
> not the rows.

Here's how I did it.


        mov     ax,0500h                ; set video page = 0
cold1:  call    video
        call    gmode                   ; get video mode
        cmp     al,7                    ; 80 col mono
        jz      cold2
        cmp     al,3                    ; 80 col color
        jz      cold2
        cmp     al,2                    ; 80 col b/w
        jz      cold2
        mov     ax,3                    ; set video mode = 80 col color
        jmp     cold1                   ; (screen will blank)
cold2:  dec     bh                      ; cols
        mov     wmax,bh
        sub     bh,bh
        sub     dl,dl                   ; assume old CGA card
        mov     ax,1130h
        call    video
        or      dl,dl                   ; rows if EGA+
        jnz     cold3
        mov     dl,24
cold3:  mov     wmax+1,dl
        ...


;       get video mode  AL=mode AH=page BH=cols

gmode:  mov     ah,0fh
        call    video
        xchg    bh,ah
        mov     word ptr cmode,ax       ; save
        ret

video:  push    si
        push    bp
        int     10h
        pop     bp
        pop     si
        ret

[toc] | [prev] | [next] | [standalone]

#1005

On 28th Sep 2013 at 20:34 "Ed" <invalid@invalid.com> wrote:

> James Harris wrote:
> > ...
> > However, how should things like the screen size (rows and columns) be
> > determined? I know there is a BIOS call int 0x10-0f to get the columns but
> > not the rows.
> 
> Here's how I did it.
> 
> 
>         mov     ax,0500h                ; set video page = 0
> cold1:  call    video
>         call    gmode                   ; get video mode
>         cmp     al,7                    ; 80 col mono
>         jz      cold2
>         cmp     al,3                    ; 80 col color
>         jz      cold2
>         cmp     al,2                    ; 80 col b/w
>         jz      cold2
>         mov     ax,3                    ; set video mode = 80 col color
>         jmp     cold1                   ; (screen will blank)
> cold2:  dec     bh                      ; cols
>         mov     wmax,bh
>         sub     bh,bh
>         sub     dl,dl                   ; assume old CGA card
>         mov     ax,1130h
>         call    video
>         or      dl,dl                   ; rows if EGA+
>         jnz     cold3
>         mov     dl,24
> cold3:  mov     wmax+1,dl
>         ...
> 
> 
> ;       get video mode  AL=mode AH=page BH=cols
> 
> gmode:  mov     ah,0fh
>         call    video
>         xchg    bh,ah
>         mov     word ptr cmode,ax       ; save
>         ret
> 
> video:  push    si
>         push    bp
>         int     10h
>         pop     bp
>         pop     si
>         ret

Sorry, I don't appear to have received the original article from 
James.  Provided you are using EGA or later and only interested in 
text modes, just look in the bios data area at seg 40h:

        mov     ax, 40h
        mov     es, ax
        mov     dl, es:[4Ah]    ; DL is nr of screen columns
        mov     dh, es:[84h]    ; max screen row index
        inc     dh              ; DH is nr of screen rows

Pete
-- 
Believe those who are seeking the truth.
Doubt those who find it.  -  André Gide

[toc] | [prev] | [next] | [standalone]

#1006

pete@nospam.demon.co.uk wrote:
> ...
> Sorry, I don't appear to have received the original article from
> James.

It appeared on the news server I'm using.  Unfortunately I didn't notice
until too late I had replied to a post exactly a month old ...

> Provided you are using EGA or later and only interested in
> text modes, just look in the bios data area at seg 40h:
>
>         mov     ax, 40h
>         mov     es, ax
>         mov     dl, es:[4Ah]    ; DL is nr of screen columns
>         mov     dh, es:[84h]    ; max screen row index
>         inc     dh              ; DH is nr of screen rows
>
> Pete

Nice and easy.

It's a pity IBM didn't think to provide ROWS info from the beginning.

[toc] | [prev] | [next] | [standalone]

#1007

"Ed" <invalid@invalid.com> wrote in message 
news:l28ruq$3v9$1@speranza.aioe.org...
> pete@nospam.demon.co.uk wrote:
>> ...
>> Sorry, I don't appear to have received the original article from
>> James.
>
> It appeared on the news server I'm using.  Unfortunately I didn't notice
> until too late I had replied to a post exactly a month old ...

Not too late. The OP saw the replies. ;-)

James

[toc] | [prev] | [next] | [standalone]

#1009

James Harris wrote:
> "Ed" <invalid@invalid.com> wrote in message
> news:l28ruq$3v9$1@speranza.aioe.org...
> > pete@nospam.demon.co.uk wrote:
> >> ...
> >> Sorry, I don't appear to have received the original article from
> >> James.
> >
> > It appeared on the news server I'm using.  Unfortunately I didn't notice
> > until too late I had replied to a post exactly a month old ...
>
> Not too late. The OP saw the replies. ;-)
>
> James

Hope the responses helped.

I used BIOS calls for console I/O primarily to avoid the need
for ANSI.SYS and stop inadvertent exits via CTRL-C etc.
OTOH I've found it handy to be able to switch back to INT 21h
calls as required e.g. to allow redirection of output to a file.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.msdos.programmer

csiph-web