From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,76e8d3fd68c3d761 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-23 22:36:44 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-post-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: achrist@easystreet.com Newsgroups: comp.lang.ada Subject: Re: Screen Handling packages! Date: Thu, 23 May 2002 22:37:20 -0700 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <3CEDD190.8A1E722A@easystreet.com> X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <88d37469ae67efc323ba84e966f7b387.86200@mygate.mailgate.org> <3CEDC195.479B58C0@adaworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: newsabuse@supernews.com Xref: archiver1.google.com comp.lang.ada:24623 Date: 2002-05-23T22:37:20-07:00 List-Id: Richard Riehle wrote: > > Another approach, not for the faint of heart, but one I have > seen used successfully is to access Hex B800 directly. At > B800, you have a mapping to the screen at the pixel level. > If you have a system address capability in your compiler > to access B800, you can actually peek and poke with Ada > into that area of memory. > Mostly this is done in text mode, then it's not the pixel level, it's a buffer of characters and attributes (colors, etc), one for each screen character. BTW, you should check some of the other low memory addresses to see what screen mode is in effect. I've thrown out my DOS documentation, but there are addresses to check to see whether the screen is monochrome or color (the monochrome video buffer is at B000 IIRC, and the color attributes are different for monochrome). if the screen is 80 x 25, 40 x ??, 100 x ???, or whatever, and if it's in text or graphics mode. I vaguely remember doing direct screen writes with both the RR and the GNAT for DOS compilers. The GNAT DOS compiler works with djgpp, which came with some C library that could access the low memory addresses directly, So it took a call out from Ada to C to make it happen, but it was pretty simple. As mentioned recently, the RR for DOS compiler comes with a function to do just about the same thing that also worked just fine for me. There is one reason to not do this: it doesn't give you any UI for the mouse. Many users today reach for the mouse so instinctively that they will not like a mouseless program. If you are using the GNAT for DOS compiler, you might want to look at some of the graphics libraries that are available for djgpp. These may provide a graphical (not text mode) UI, mouse support, some widgets, etc, etc. Most of these are in C or C++ and intended for games programmers, but it should be possible to talk to them from GNAT and they may give a much nicer UI than you can make happen easily in pure Ada. I haven't done any DOS in about four years, so I can't say for sure what you will find, but there was still some large amount of games programming and UI support for djgpp back then. Ansi.sys was not popular in the MS-DOS days, mainly because it was noticeably slower than direct screen updates. I suppose that with fast computers of today, it would be hard to notice any delay from using ansi.sys, but not all versions of Windows allow ansi.sys in a DOS box. Al