On 2002-12-05, Michal H. Tyc wrote:
> So I think that COLOR: and MONO: devices would be better.
> If I understand well, "MODE MONO" would attach CON: to MONO:
> and "MODE [CO|BW][80|40]" to COLOR:?
Actually, these ("COLOR:" and "MONO:") are the names used in
Axel's DUALMON.SYS driver... ;-)
I have had some reservations against these names, as they are
more likely to exist as filenames on disk, and for some odd
aesthetical reasons I didn't liked that the names' lengths
were different, so I thought "CO80:" and "BW80:" were good
alternatives, but you have a very good point here, they
are not. Maybe "CONC:" or CONM:", or just "CON1:" and
"CON2:"? ;-) Anyway, once DISPLAY would accept the con[:]=...
thing as an actual parameter, the actual name wouldn't
matter much any more.
Switching between a monochrom MGA/HGC/HGC+ etc. and a color
CGA/MCGA/EGA/VGA/SVGA goes by "MODE MONO" and "MODE CO80".
> And, finally, a bit exotic scenario, that should also be handled
> properly, if all these features are introduced:
>
> DEVICE=DISPLAY.SYS COLOR:=(cga,(437,161),0) MONO:=(ega,437,1)
>
> (i.e., Arabic CGA with color monitor plus EGA with TTL monochrome
> one -- I have never seen such a combination, but handbooks say
> it is possible).
Yes, this should be possible as well, but I too have never used
this combination.
>> Some earlier issues of MS-DOS/PC DOS DISPLAY.SYS
>> seem to have had a facility to store them in the HMA, but I'm
>> not completely sure about that. I have never observed this to
>> happen.
>
> But I have. It could be MS-DOS 5.00, but I'm not sure --
> too long time ago.
Thanks for the info. Did DISPLAY.SYS took over the HMA completely,
or did it occupy only parts of it and shared the rest with
other clients?
>> The DR-DOS DISPLAY.SYS does not currently support
>> storing the fonts in the HMA or XMS, unfortunately.
>
> If we are already talking about all the small potential risks ;-)
> then it should be also said that some old or poorly written
> programs may not like to receive pointers into HMA (because of
> possible 20-bit address wraparound). Maybe this is the reason
> why MS removed this feature in later versions?
Of course, this can only work if there are no public pointers
pointing into the HMA, and DISPLAY.SYS (or any other HMA client)
will only access the HMA from within a mutex which ensures that
A20 is on. That's one of the reasons, why relocation into the
HMA is difficult, and drivers usually require a stub in the
1st meg to ensure that A20 is on before they just in there.
Greetings,
Matthias
--
<mailto:[EMAIL PROTECTED]>; <mailto:[EMAIL PROTECTED]>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
----------
list options/archives/etc.: http://www.topica.com/lists/fd-dev
unsubscribe: send blank email to: [EMAIL PROTECTED]
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bz8Rv5.bbRv4l.YXJjaGl2
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
