256 colors - OS2

This is a discussion on 256 colors - OS2 ; Using VioWrtCharStrAtt(), and the number of VIO colors set to 256 (instead of the default of 16), how can I actually display all 256 colors? It seems like the original 16 colors are still in use (using a slightly changed, ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: 256 colors

  1. 256 colors


    Using VioWrtCharStrAtt(), and the number of VIO colors set to 256 (instead
    of the default of 16), how can I actually display all 256 colors? It seems
    like the original 16 colors are still in use (using a slightly changed, old
    article in this ng which displays "Programming is fun!"), but I may miss
    something extremely obvious here (yes, I called VioSetMode() to actually
    change the numbers of colors).

    Besides that, PRCP reads:

    Attr (PBYTE) - input
    Address of the attribute(s) (1 or 3 bytes) ...

    I'm only using 1 byte, how/when/why should I use 3?



    ---

  2. Re: 256 colors


    > Besides that, PRCP reads:


    > Attr (PBYTE) - input
    > Address of the attribute(s) (1 or 3 bytes) ...


    > I'm only using 1 byte, how/when/why should I use 3?


    "PRCP" should be "PRCP.INF", the 16-bit Vio*-documentation supplement.



    ---

  3. Re: 256 colors

    ML schrieb:
    > Using VioWrtCharStrAtt(), and the number of VIO colors set to 256 (instead
    > of the default of 16), how can I actually display all 256 colors? It seems
    > like the original 16 colors are still in use (using a slightly changed, old
    > article in this ng which displays "Programming is fun!"), but I may miss
    > something extremely obvious here (yes, I called VioSetMode() to actually
    > change the numbers of colors).


    First question: are you writing a fullscreen app ? VioSetMode will only
    work in a fullscreen app, it basically is a nop when executed in a
    console window.

    The attribute can only be a byte (information below seems to be wrong)
    and it is defined this way:

    Bit Meaning When Set
    0 Foreground blue
    1 Foreground green
    2 Foreground red
    3 High intensity
    4 Background blue
    5 Background blue
    6 Background blue
    7 Blinking character

    So first, you have to get the RGB values from the color table but I
    cannot find an easy way to do that.

    On the other hand, I don't think that textmodes support more than 16
    colors. I wonder if VioSetMode returns 0 on an attempt to set a textmode
    with more than 16 colors.

    Can you post your sample program or at least the relevant part ?


    Lars





    >
    > Besides that, PRCP reads:
    >
    > Attr (PBYTE) - input
    > Address of the attribute(s) (1 or 3 bytes) ...
    >
    > I'm only using 1 byte, how/when/why should I use 3?
    >
    >
    >
    > ---


  4. Re: 256 colors

    Lars Erdmann schrieb:
    > ML schrieb:
    >> Using VioWrtCharStrAtt(), and the number of VIO colors set to 256
    >> (instead
    >> of the default of 16), how can I actually display all 256 colors? It
    >> seems
    >> like the original 16 colors are still in use (using a slightly
    >> changed, old
    >> article in this ng which displays "Programming is fun!"), but I may miss
    >> something extremely obvious here (yes, I called VioSetMode() to actually
    >> change the numbers of colors).

    >
    > First question: are you writing a fullscreen app ? VioSetMode will only
    > work in a fullscreen app, it basically is a nop when executed in a
    > console window.
    >
    > The attribute can only be a byte (information below seems to be wrong)
    > and it is defined this way:
    >
    > Bit Meaning When Set
    > 0 Foreground blue
    > 1 Foreground green
    > 2 Foreground red
    > 3 High intensity
    > 4 Background blue
    > 5 Background blue
    > 6 Background blue
    > 7 Blinking character
    >
    > So first, you have to get the RGB values from the color table but I
    > cannot find an easy way to do that.


    VioGetState and VioSetState will allow you to reassign new colors to the
    16 palette registers (as I said, I think textmode can handle only 16
    colors at best). I don't know the exact format, each palette register is
    16 bits long. Maybe you need to experiment a little. But you cannot use
    256 colors at once, only 16 colors out of 256 at a time.

    Lars


  5. Re: 256 colors

    Lars Erdmann writes:

    > VioSetMode will only work in a fullscreen app, it basically is a nop
    > when executed in a console window.


    Incorrect. I wrote an application that uses VioSetMode, and it works
    just fine in a window. It's been awhile since I built that application.
    It may have required setting a flag in the executable to allow both full
    screen and windowed use.


  6. Re: 256 colors


    >> Using VioWrtCharStrAtt(), and the number of VIO colors set to 256 (instead
    >> of the default of 16), how can I actually display all 256 colors? It seems
    >> like the original 16 colors are still in use (using a slightly changed, old
    >> article in this ng which displays "Programming is fun!"), but I may miss
    >> something extremely obvious here (yes, I called VioSetMode() to actually
    >> change the numbers of colors).


    > First question: are you writing a fullscreen app ?


    No, it should be possible to run it in a windowed session too.

    > VioSetMode will only work in a fullscreen app, it basically is a nop
    > when executed in a console window.


    In general, that's not true. I'm already using it to change the size of
    the screen to 40x25. But it could be a NOP w.r.t. setting the number of
    color bits (which default is 4, changing that to 8 didn't help at all).

    BTW, IIRC once I polluted an app with many smart solutions in order to
    make sure it was run as a fullscreen app. I assume because some *.INF
    mentioned Mou*() needed that environment. All protection was active,
    so it did took a while to found out that it also worked perfectly in a
    windowed session.

    > So first, you have to get the RGB values from the color table but
    > I cannot find an easy way to do that.


    Thanks for the usefull pointer to Vio[Get|Set]State's possibilities, I
    just assumed setting the number of color bits to 8 would have some
    effect.

    > On the other hand, I don't think that textmodes support more than
    > 16 colors.


    Probably EGA-related, I'ld say.

    > I wonder if VioSetMode returns 0 on an attempt to set a textmode
    > with more than 16 colors.


    Adding "ModeData.color=8;" returns 355 (ERROR_VIO_MODE), both windowed
    and fullscreen. Please note no attempt is made to change from EGA+ to
    VGA+ modes, for one:

    ----------
    /* Skeleton test app */
    #define INCL_VIO

    #include
    #include

    int main(void)
    {
    APIRET rc;
    BYTE i;
    VIOMODEINFO ModeData;
    ModeData.cb=sizeof(VIOMODEINFO);
    ModeData.color=8; /* 8 bits instead of 4 */
    rc=VioSetMode(&ModeData,(HVIO)0); /* Returns 355 */
    printf("\nrc=%d\n",rc);
    for (i=0;i<=31;i++)
    VioWrtCharStrAtt("X",1,12,23+i,&i,(HVIO)0);
    return 0;
    }
    ----------

    What I somehow expected (due to a port from memory) was that with e.g.
    5 color bits I'ld see 32 colors, instead of the 16 repeating character
    colors... :-)

    FTR: ColorPicker returns these RGB-settings for the 16 default colors:

    0x000000, 0x000080, 0x008000, 0x008080, 0x800000, 0x800080, 0x808000,
    0xCCCCCC, 0x808080, 0x0000FF, 0x00FF00, 0x00FFFF, 0xFF0000, 0xFF00FF,
    0xFFFF00, 0xFFFFFF

    If it's possible to change the 16 colors with VioSetState(), it cannot
    be that hard to understand how the 16 16-bits USHORT color definitions
    in use are related to the RGB-values above.

    > Can you post your sample program or at least the relevant part ?


    I'll start fighting with the posibilities of VioSetState() you referred
    to. First I'll try that, next I may have to try to use VGA+, and if it
    works I could post an extended, colorfull example here. Please note the
    example above is a very basic testing skeleton, it's not an attempt to
    actually use 16 (different) colors. It just shows the 355, and it shows
    X's with a color attribute in the range 0-31.

    Thanks so far. BTW, using 16 colors (at the same time) is more than
    enough, as long as I can define 13 other colors between blue, bleen
    and green! ;-)



    ---

  7. Re: 256 colors

    On Sat, 30 Jun 2007 16:53:28 +0200, ML wrote:

    > VIOMODEINFO ModeData;
    > ModeData.cb=sizeof(VIOMODEINFO);
    > ModeData.color=8; /* 8 bits instead of 4 */
    > rc=VioSetMode(&ModeData,(HVIO)0); /* Returns 355 */


    Well what do you expect? What about all the other members of the ModeData
    structure that are uninitialized?

    If you set .cb to 4 and set the .type field as well, then you may get
    more useful results. Or do a VioGetMode() first.

    BTW, my documentation (PRCP.INF) has .length, .type, .numcolors etc. as
    structure members. Wonder why yours differs....

  8. Re: 256 colors

    Just a side note:

    according to an admittedly very ancient Microsoft OS/2 doc that I have,
    color can only be set to 1,2 and 4 (2, 4 and 16 colors, respectively).
    But that restriction might still be true for compatibility reasons ...
    And RC = 355 means that the video mode you try to choose is not
    supported (try "help sys355" on a commandline).

    So the best you can do seems to be to stick to 16 simultaneous colors
    and try to manipulate the palette via VioSetState.



    Lars

    > > I wonder if VioSetMode returns 0 on an attempt to set a textmode
    > > with more than 16 colors.

    >
    > Adding "ModeData.color=8;" returns 355 (ERROR_VIO_MODE), both windowed
    > and fullscreen. Please note no attempt is made to change from EGA+ to
    > VGA+ modes, for one:
    >
    > ----------
    > /* Skeleton test app */
    > #define INCL_VIO
    >
    > #include
    > #include
    >
    > int main(void)
    > {
    > APIRET rc;
    > BYTE i;
    > VIOMODEINFO ModeData;
    > ModeData.cb=sizeof(VIOMODEINFO);
    > ModeData.color=8; /* 8 bits instead of 4 */
    > rc=VioSetMode(&ModeData,(HVIO)0); /* Returns 355 */
    > printf("\nrc=%d\n",rc);
    > for (i=0;i<=31;i++)
    > VioWrtCharStrAtt("X",1,12,23+i,&i,(HVIO)0);
    > return 0;
    > }
    > ----------
    >
    > What I somehow expected (due to a port from memory) was that with e.g.
    > 5 color bits I'ld see 32 colors, instead of the 16 repeating character
    > colors... :-)
    >
    > FTR: ColorPicker returns these RGB-settings for the 16 default colors:
    >
    > 0x000000, 0x000080, 0x008000, 0x008080, 0x800000, 0x800080, 0x808000,
    > 0xCCCCCC, 0x808080, 0x0000FF, 0x00FF00, 0x00FFFF, 0xFF0000, 0xFF00FF,
    > 0xFFFF00, 0xFFFFFF
    >
    > If it's possible to change the 16 colors with VioSetState(), it cannot
    > be that hard to understand how the 16 16-bits USHORT color definitions
    > in use are related to the RGB-values above.
    >
    > > Can you post your sample program or at least the relevant part ?

    >
    > I'll start fighting with the posibilities of VioSetState() you referred
    > to. First I'll try that, next I may have to try to use VGA+, and if it
    > works I could post an extended, colorfull example here. Please note the
    > example above is a very basic testing skeleton, it's not an attempt to
    > actually use 16 (different) colors. It just shows the 355, and it shows
    > X's with a color attribute in the range 0-31.
    >
    > Thanks so far. BTW, using 16 colors (at the same time) is more than
    > enough, as long as I can define 13 other colors between blue, bleen
    > and green! ;-)
    >
    >
    >
    > ---


  9. Re: 256 colors


    >> VIOMODEINFO ModeData;
    >> ModeData.cb=sizeof(VIOMODEINFO);
    >> ModeData.color=8; /* 8 bits instead of 4 */
    >> rc=VioSetMode(&ModeData,(HVIO)0); /* Returns 355 */


    > Well what do you expect? What about all the other members of the
    > ModeData structure that are uninitialized?


    > If you set .cb to 4 and set the .type field as well, then you may
    > get more useful results. Or do a VioGetMode() first.


    Excuse me, I may have deleted a line too much:

    >> VIOMODEINFO ModeData;


    VioGetMode(&ModeData,(HVIO)0);

    >> ModeData.cb=sizeof(VIOMODEINFO);
    >> ModeData.color=8; /* 8 bits instead of 4 */
    >> rc=VioSetMode(&ModeData,(HVIO)0); /* Returns 355 */


    Both the real app and a slightly longer version of this skeleton app
    used VioGetMode() first. And w.r.t. the .type-field, Lars seem to be
    right. Textmodes only support <=4 color bits, hence 355. VioSetState()
    may be the way to - if actually possible - redefine those 16 colors in
    use indeed. Otherwise a switch to a "graphics mode"/type seems to be
    required in order to use <=8 color bits.

    > BTW, my documentation (PRCP.INF) has .length, .type, .numcolors etc.
    > as structure members. Wonder why yours differs....


    AFAICT there is no difference. Select e.g. the "Bindings: C"-link at
    line 1 of the VioSetMode()-page, which matches VIOMODEINFO's typedef
    in \INCLUDE\OS2\BSESUB.H



    ---

  10. Re: 256 colors


    > So the best you can do seems to be to stick to 16 simultaneous colors
    > and try to manipulate the palette via VioSetState.


    Yes. I haven't actually tried that yet, but it would be "funny" if it
    works that way. The USHORT-color definitions looks promising, but I'ld
    otherwise somehow have assumed EGA had 16 fixed colors. Well, maybe
    rounding to the nearest available color still spoils the party, but
    the odd one out (0xCCCCCC: no 00's, 80's nor FF's) offers enough hope
    to give this a try!



    ---

  11. Re: 256 colors


    > Yes. I haven't actually tried that yet


    I have now. In a default CMD.EXE-fullscreen session the 16 colors seem
    to be changable, but in a VIO window VioSetState() (Lars mentioned the
    chance of such a thing happening w.r.t. VioSetMode() earlier) returns
    494, which comes down to: not supported in a VIO (text-) window



    ---

  12. Re: 256 colors

    ML schrieb:
    > > Yes. I haven't actually tried that yet

    >
    > I have now. In a default CMD.EXE-fullscreen session the 16 colors seem
    > to be changable, but in a VIO window VioSetState() (Lars mentioned the
    > chance of such a thing happening w.r.t. VioSetMode() earlier) returns
    > 494, which comes down to: not supported in a VIO (text-) window
    >
    >
    >
    > ---

    In a way, that makes sense. Manipulating the system on this comparably
    low level can only be "virtualized" with increasing difficulty.
    The system would have to manage palette switching on a program switch
    but basically all PM and windowed programs run in a common session and
    the session used to be the means to save specific info like mouse cursor
    position, screen colors etc. before PM entered the scene (that is OS/2
    1.1 or so).
    With PM apps this has changed, even though they run in a common session,
    PM manages the mouse cursor, screen colors, fonts etc. for each PM app
    individually but the old VIO API has no relationship to PM per se.


    Lars

  13. Re: 256 colors


    > PM manages the mouse cursor, screen colors, fonts etc. for each PM
    > app individually but the old VIO API has no relationship to PM per
    > se.


    The colors don't even last. Run this, derived from an earlier example
    here, in a full-screen textmode session. Something green should appear.
    The line "rc=0" should be displayed then ("rc=494" in a VIO window).
    Next, press to switch to the PM tasklist, and press
    to return to this greenish full-screen textmode session. If I perform
    those steps here, the green screen disappeares, demonstrating issues
    w.r.t. changing VIO colors using the VioGetState() API for changing
    the colors.

    In a VIO window VioGetState() returns 494. In a full-screen textmode
    session it returns 0, but losing the focus can spoil the wanted look.



    ---
    #define INCL_NOPMAPI
    #define INCL_VIO

    #include
    #include
    #include

    int main(void)
    {
    APIRET rc;
    BYTE attr;
    char msg[40];
    int i;
    VIOMODEINFO ModeData;
    VIOPALSTATE vpal;

    VioGetMode(&ModeData,(HVIO)0);

    VioScrollUp(0,0,(USHORT)0xFFFF,(USHORT)0XFFFF,(USH ORT)0xFFFF," \x7",(HVIO)0);

    vpal.cb=sizeof(VIOPALSTATE);
    vpal.type=0;
    VioGetState(&vpal,(HVIO)0);
    for (i=0;i<16;i++)
    {
    printf("%d\n",vpal.acolor[i]);
    vpal.acolor[i]=80;
    }
    printf("rc=%d\n",VioSetState(&vpal,(HVIO)0));
    VioSetMode(&ModeData,(HVIO)0);

    attr=0;
    for (i=0;i<22;i++)
    {
    sprintf(msg,"Line %2d: Programming is fun!",i);
    VioWrtCharStrAtt(msg,strlen(msg),i,i,&attr,0);
    attr+=16;
    }

    VioSetCurPos(23,0,0);

    return 0;
    }

  14. Re: 256 colors

    [A complimentary Cc of this posting was sent to
    ML
    ], who wrote in article :
    >
    > > PM manages the mouse cursor, screen colors, fonts etc. for each PM
    > > app individually but the old VIO API has no relationship to PM per
    > > se.

    >
    > The colors don't even last. Run this, derived from an earlier example
    > here, in a full-screen textmode session. Something green should appear.
    > The line "rc=0" should be displayed then ("rc=494" in a VIO window).
    > Next, press to switch to the PM tasklist, and press
    > to return to this greenish full-screen textmode session. If I perform
    > those steps here, the green screen disappeares, demonstrating issues
    > w.r.t. changing VIO colors using the VioGetState() API for changing
    > the colors.


    A trivial remark: AFAIU, it is up to an application to decide what
    should be made when the similated hardware ("the screen") is suspended
    (switched away from the session), and then awaikened back. There is
    an API to be notified about such events.

    Hope this helps,
    Ilya

  15. Re: 256 colors

    Hallo,

    ML schrieb:
    > > PM manages the mouse cursor, screen colors, fonts etc. for each PM
    > > app individually but the old VIO API has no relationship to PM per
    > > se.

    >
    > The colors don't even last. Run this, derived from an earlier example
    > here, in a full-screen textmode session. Something green should appear.
    > The line "rc=0" should be displayed then ("rc=494" in a VIO window).
    > Next, press to switch to the PM tasklist, and press
    > to return to this greenish full-screen textmode session. If I perform
    > those steps here, the green screen disappeares, demonstrating issues
    > w.r.t. changing VIO colors using the VioGetState() API for changing
    > the colors.
    >
    > In a VIO window VioGetState() returns 494. In a full-screen textmode
    > session it returns 0, but losing the focus can spoil the wanted look.


    I have modified your code and look there, it works as you expect it (at
    least in fullscreen).
    Thoroughly read the 16-bit API doc (find it under inf16bit.zip on
    Hobbes), especially in view of
    VioGetBuf,VioSetBuf,VioSavRedrawWait,VioSavRedrawU ndo,VioModeWait,VioModeUndo:


    #define INCL_BASE
    #define INCL_VIO

    #include
    #include
    #include

    VIOPALSTATE vpal={0};
    PVOID pBuf = NULL;
    USHORT usLen = 0;

    VOID APIENTRY ScreenSwitchThread(ULONG u);
    VOID APIENTRY PopupThread(ULONG u);


    int main(int argc,char *argv[])
    {
    APIRET rc;
    BYTE attr;
    char msg[40];
    TID tid1,tid2;
    ULONG i;


    vpal.cb = sizeof(VIOPALSTATE);
    vpal.type = 0;
    vpal.iFirst = 0;
    for (i=0;i<16;i++)
    {
    vpal.acolor[i]=80;
    }
    VioSetState(&vpal,(HVIO)0);
    VioGetBuf((PULONG)&pBuf,&usLen,(HVIO)0);

    DosCreateThread(&tid1,ScreenSwitchThread,0,CREATE_READY |
    STACK_SPARSE,8192UL);
    DosCreateThread(&tid2,PopupThread,0,CREATE_READY |
    STACK_SPARSE,8192UL);

    VioScrollUp(0,0,(USHORT)0xFFFF,(USHORT)0XFFFF,(USH ORT)0xFFFF,"
    \x7",(HVIO)0);

    attr=0;
    for (i=0;i<22;i++)
    {
    sprintf(msg,"Line %2d: Programming is fun!",i);
    VioWrtCharStrAtt(msg,strlen(msg),i,i,&attr,0);
    attr+=16;
    }

    VioSetCurPos(23,0,0);

    DosSleep(20000UL);

    VioSavRedrawUndo(UNDOI_RELEASEOWNER,UNDOK_TERMINAT E,(HVIO)0);
    VioModeUndo(UNDOI_RELEASEOWNER,UNDOK_TERMINATE,(HV IO)0);
    DosWaitThread(&tid1,DCWW_WAIT);
    DosWaitThread(&tid2,DCWW_WAIT);

    return 0;
    }



    VOID APIENTRY ScreenSwitchThread(ULONG u)
    {
    USHORT usNotify = 0;
    char msg[40];
    ULONG ulLen;
    APIRET rc;

    while (1)
    {
    if ((rc =
    VioSavRedrawWait(VSRWI_SAVEANDREDRAW,&usNotify,(HVIO)0)) == NO_ERROR)
    {
    if (usNotify == VSRWN_SAVE)
    {
    VioGetBuf((PULONG)&pBuf,&usLen,(HVIO)0);
    }
    if (usNotify == VSRWN_REDRAW)
    {
    VioSetState(&vpal,(HVIO)0);
    VioShowBuf(0,usLen,(HVIO)0);
    }
    }
    else
    {
    ulLen = sprintf(msg,"rc = %d",rc);
    VioWrtTTY(msg,ulLen,(HVIO)0);
    }
    }
    }

    VOID APIENTRY PopupThread(ULONG u)
    {
    USHORT usNotify = 0;
    char msg[40];
    ULONG ulLen;
    APIRET rc;

    while (1)
    {
    if ((rc = VioModeWait(VMWR_POPUP,&usNotify,(HVIO)0)) == NO_ERROR)
    {
    if (usNotify == VMWR_POPUP)
    {
    VioSetState(&vpal,(HVIO)0);
    VioShowBuf(0,usLen,(HVIO)0);
    }
    }
    else
    {
    ulLen = sprintf(msg,"rc = %d",rc);
    VioWrtTTY(msg,ulLen,(HVIO)0);
    }
    }
    }

    P.S: I have tried it without VioGetBuf/VioSetBuf but obviously you can
    only have either one: do nothing by yourself or do everything by yourself.

    P.P.S.: It's not necessary to use VioGetPhysBuf as you are using
    textmode. The VioWrtxx calls will go into the logical video buffer (LVB)
    once you call VioGetBuf (again, see doc). For graphics modes this is a
    different pair of shoes (no VioWrtxx calls, therefore no usable LVB) and
    it will get more involved, you will need to save the complete screen to
    memory (using the huge pointer from VioGetPhysBuf) and then write it
    back on restore (directly via the huge pointer returned by VioGetPhysBuf).

    P.P.P.S.: I have done almost no error checking. I think it would be a
    good idea to install an exit handler to call
    VioSavRedrawUndo,VioModeUndo from the exit handler (in case someone hits
    Ctrl-C).


    By the way: for emx/gcc there is a fullscreen library that would offer
    you all this (even graphics modes).


    Have fun,
    Lars





  16. Re: 256 colors


    >> The colors don't even last.


    > I have modified your code and look there, it works as you expect it


    Let me rephrase that: the colors didn't even last! Thanks, I guess
    this modified demonstration fills the gap between "let's try to set
    the number of color bits to 8 and cross some fingers" and a working
    situation involving a "slightly" higher number of Vio* API's (and I
    didn't expect that, the documentation also wasn't flooded which many
    cross-references, so glueded-together code like this is very helpfull
    indeed).

    > (at least in fullscreen).


    Right, running it in a VIO window isn't recommended... :-)

    I guess I'm going to use both. The 16 default colors in a VIO window,
    or modified colors in a fullscreen environment (a better environment
    in this case anyway, but that's an unrelated topic).

    FTR: I haven't figured out the color pallette yet, but that cannot be
    that hard to find out. For testing purposes I just picked a value with
    a visible change, it could have been yellow instead of green.

    FTR/2: I ran the unmodified code in a VIO window (rc=494, returns to
    the CMD.EXE-prompt), while my app was also running in a VIO window too,
    updating the screen frequently. In that situation the OS (?) sometimes
    produces an official beep (unmodified code finished, my app in use),
    maybe indicating some kind of race condition, or something like that.
    Just FTR, those beeps aren't that important nor disturbing, and IRL I
    don't think it's likely that many colored VIO windows are used at the
    same time anyway. I haven't tried to reproduce this with an opened,
    default VIO/CMD.EXE-window yet, my app is installed on another pc.

    > I think it would be a good idea to install an exit handler to call
    > VioSavRedrawUndo,VioModeUndo from the exit handler (in case someone
    > hits Ctrl-C).


    During this learning experience (the original app is about 22 years
    old, my only app ever with embedded assembly programming back then
    because of the "speed" gain and due to 11 KB of memory, hence 40x25
    and Vio*), I already did include My First Handler, albeit not
    completely perfected yet. I'll figure that out, including those calls.



    ---

  17. Re: 256 colors


    > I haven't figured out the color pallette yet


    I still haven't, what I intended doesn't seem to be possible. I can set
    the 16 colors at random in a loop, but it looks like VioWrtCharStrAtt()
    uses the same 16 different colors each time in that loop. IOW: so the
    background color can be changed, but I don't think it's possible to use
    16 different shades of green at the same time. Well, perhaps contrast
    was kept in mind w.r.t. changing colors. :-)

    Minor changes made to the fullscreen app posted earlier:

    - added a loop to repeat the most relevant part 100 times
    - assigned random acolor[] values
    - reduced the DosSleep() time, so it doesn't take 100 times 20 secs

    I prepared my app to include the concept of the posted app. I'll leave
    it in that state for a while, just in case it turns out to be possible
    to use 11 different shades of yellow at the same time anyway...



    ---

+ Reply to Thread