Re: [fd-dev] DISPLAY CON?=
On 2002-12-03, Tom Ehlert wrote: I have a dual monitor configuration the second IS HGC I USE the hercules card - nearly every day I NEVER EVER got even the idea to install a DOS driver for that. I'm VERY happy to have a HGC card (and minitor) Fine, I'm too. All my systems are dual screen systems (most of them SVGA + HGC) and I know several people, who do use dual screen drivers to redirect text to just the other screen using something like: ECHO Foo CO80: ECHO Bar BW80: ECHO Hello World CON: IMO, I prefer working 2003 for 98% all cases over might work in 2010 - eventually (if I'm not too busy) Hm, being at 98% in 2003 is completely illusoric, IMHO. The FreeDOS kernel has made significant progress, that's great. And there are a few really outstanding drivers and utilities. But being realistic, several more years of hard work will have to go by before the majority of the FreeDOS utility set will have reached the same level of maturity as in MS-DOS/PC DOS or DR-DOS. I hope it will happen eventually. As I see it, the most significant problem for many volunteers is simply lack of knowledge, what's actually going on under the hood, and also of the historical background, why some DOS components were designed this way and not another, originally. Knowing this helps to better understand DOS' internals. Hence, I'm trying to share what I can share (and my time allows), and I'm also very happy to learn from others, where they can provide expertise. sorry for being harsh, but these 'one could think of' messages effectively STOP all useful work. No, not in my opinion. Knowledge can never harm, being ahead in ideas and design compared to the actual implementation cannot either. It enables people to create better and more compatible software. Not knowing issues will often lead into dead ends or cause compatibility issues. Look at most questions raised in the DOS related newsgroups (probably even more so in the Windows groups), most of them are the result of lacking knowledge or improper documentation. Of course, even with enough knowledge it is still some kind of trial-and-error process, but I hope the learning curve will be much higher, as potential mistakes can be identified much earlier. IMHO the fine arts of engineering is to find the right compromise, that is, to /be/ knowledgable at first, and then /actively/ decide to temporarily put down some marginal issues to fulfill the deadline. But since there is no deadline for FreeDOS, and we do have mature and flexible (but now for the most part static) DOS issues already, there is IMHO no point in recreating the wheel without coming up with a better solution in the end... ;-) I don't say, the first release will/could/should be final, but if you don't think of potentially planned extensions right from the start, you might have to start from scratch in the middle of the project. However, my comments are never meant like Please implement this for me - if I'd need it for myself *now*, I could and would sure just implement it myself. But I usually use DR-DOS anyway, so I won't have any direct advantage of FreeDOS extensions except for enjoying that some of the DR-DOS features and ideas are spreading into other implementations, thereby making DOS as is a more convenient and attractive platform, which, I hope, will keep it alive a bit longer. That's also why I care that my own solutions are compatible with any DOS, including FreeDOS and DR-DOS. My comments are always meant as Please take this non-obvious issue/ idea into account, while working on xyz so that different solutions stay compatible with each other. I have seen more than one FreeDOS component being seriously incompatible with established DOS standards due to an only partial understanding and therefore implementation of the standard, and while it is always possible to fix these problems in later issues, I see no purpose in introducing them in the first place. I don't know how this would be possible without deeper insight, that's why I try to answer questions raised here and give some background info. --- On 2002-12-03, Aitor Santamaría Merino wrote: Suppose that I name DISPLAY as device CO80:, who assigns CON to CO80: ? DISPLAY.SYS loads on top of another console driver, usually named CON:. I doubt other names of the console driver will be accepted despite the syntactical provision for the parameter. The CON: string is probably hardwired into the driver at the moment. But if you could already attach DISPLAY.SYS to other console drivers (as it for sure was planned to be possible), the CON: driver itself would have to use the, say, CO80: (or BW80:) driver internally, just like the PRN: driver internally uses the LPT1: driver (unless you are under a DOS issue where you can reassign this). If you would want independent codepage switching on both, CO80: and BW80:, you would have to load DISPLAY.SYS on top of both console drivers, I guess. Hypothetical example: DEVICE=DISPLAY.SYS
Re: [fd-dev] DISPLAY CON?=
On 2002-12-04, Tom Ehlert wrote: DEVICE=DISPLAY.SYS co80:=(ega,437,(6,3)) bw80:=(mono,(437,161),0) AFAIK, there is no possibility to change the fonts on BW80 =HGC ? and so there is no need for display to do anything to BW80. For illustration purposes I assumed an Arabic HGC clone card, which has two hardware fonts (codepages 437, 161), no software fonts (0), here. Actually, using codepage 161 (Arabic) was a bad example, because this particular one is usually provided as a software codepage in VIDEO.CPI, but there are similar hardware codepages or fontpages like codepage 151 (Nafitha Arabic (EPROM fontpage)). For the common HGC and CGA clone cards as we know them over here, you're right. But I have at least seen cards with more than one font switchable by a jumper (easy to make this software configurable by a little user modification) - not the same as the rare HGC/RAMFONT, which provides a font RAM to store fonts. Anyway, a tiny TSR providing a small API in INT 10h, INT 15h, or INT 2Fh, could solve the problem, when DISPLAY.SYS would talk to this interface when it attempts to switch hardware codepages. In fact, a similar facility exists in Arabic and Hebrew issues of MS-DOS at INT 2Fh/AX=AD4xh, although they don't actually use console drivers named DISPLAY.SYS, but ARABIC.COM/HEBREW.COM, SK_HGC.COM, and a bunch of others. Most probably there is a lower-lever API as well, but I'm certainly no expert on Arabic/Hebrew DOS. Anyone? Maybe MONO should be replaced by AMONO or HMONO to better distinguish between them? Greetings, Matthias On 2002-12-04, Aitor Santamaría Merino wrote: The : I assume it's optional Many times it appears, many others it doesn't. That's right. Hey, now that I notice, I'll have to review in the documentation (possibly in your long messages about internationalisation) what is meant by (437,161) At a first sight, the device to be replaced is single, the codepage should be single too (?). Sorry, I don't comprehend. You can prepare up to a total of 12 concurrent codepages, so you could easily switch between them without having to prepare the desired target codepage all the time. Of course, this would require lot's of memory for the font buffers, that's why some issues of DISPLAY.SYS (of PC DOS 7/2000, for example) store the currently unused fonts in XMS memory. 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. The DR-DOS DISPLAY.SYS does not currently support storing the fonts in the HMA or XMS, unfortunately. 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: archive@mail-archive.com 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 ==^^===
Re: [fd-dev] DISPLAY CON?=
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: archive@mail-archive.com 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 ==^
