From: "Tony O'Bryan" <aho450s AT nic DOT smsu DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Geting 8x8 text from rom?
Date: Tue, 16 Dec 1997 08:14:10 -0600
Organization: Southwest Missouri State University
Lines: 13
Message-ID: <34968CB2.13C5@nic.smsu.edu>
References: <34938c5f DOT 0 AT pusher DOT student DOT adelaide DOT edu DOT au> <34951A01 DOT 5C6864E3 AT nm3 DOT ktu DOT lt> <3495C407 DOT 1562 AT nic DOT smsu DOT edu> <349650FC DOT F89BC691 AT nm3 DOT ktu DOT lt>
Reply-To: aho450s AT nic DOT smsu DOT edu
NNTP-Posting-Host: marie.a08.smsu.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Martynas Kunigelis wrote:

> guilty. Again, sorry, didn't mean it. However, weren't you supposed
> to use MK_FP(0xa000,0) under Borland instead of the 0xa0000000 hack? :)

MK_FP() was a convenience function that did the same thing.  Both
methods are non-portable, but you had a choice.  On the other hand, all
graphics are non-portable so it's not too important if the program used
a higher-level API to manipulate the low-level graphics accesses.  If
the accessing routine were poorly written in-line with the portable
code, then changing platforms from 16-bit to 32-bit (and vice-versa)
systems will be very unfriendly.  And 16-bit compiler just BEG to have
non-portable code written for them. -grin-