Path: utzoo!mnetor!uunet!husc6!bbn!rochester!PT.CS.CMU.EDU!IUS3.IUS.CS.CMU.EDU!ralphw
From: ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre)
Newsgroups: comp.sys.apple
Subject: Re: VT220, GS+ (actually, just GS+)
Message-ID: <1188@PT.CS.CMU.EDU>
Date: 21 Mar 88 22:23:58 GMT
References: <8803061316.aa29780@SMOKE.BRL.ARPA> <37@fizban.Fizban.MN.ORG> <7438@brl-smoke.ARPA> <490@n8emr.UUCP> <7463@brl-smoke.ARPA>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 51

In article <7463@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <490@n8emr.UUCP> lwv@n8emr.UUCP (Larry W. Virden) writes:
>>Yet isnt it true that the Mac family all use the same fonts?  I am confused as
>>to how they do this if altering the resolution on the IIgs would cause major
>>problems with software, fonts, etc.?
>
>I don't know how the Mac II does this, if it does.
>The basic problem would be that the fonts are defined as bit-maps
>and if the resolution were doubled the 10-point bit-map (for example)
>would come out as 5-point on the display.  The programming problem
>is more basic, in that the current GS display memory is contiguously
>allocated and addressed by software on the assumption that there are
>200 scan lines per screen.  There was no allowance made for more, so
>existing software could not find it.
Existing software shouldn't be trying to find it, except through the Toolbox.
The Mac toolbox provides calls to find out the screen resolution, and
the font toolbox allows the programmer and user to select and specify font 
size (scaling if the size isn't directly on the machine) 

On the Mac, programs that assumed the screen buffer was in a certain location
(and a certain size) would fail to run on anything but a 128K Mac.  With the
Mac XL (aka Lisa) and Mac II, I think the Mac community is reasonably well
educated in this area.  Maybe someone should clone the GS in a hurry so that
programmers don't get used to the display being a certain way.  That's one
thing the Toolbox is for, to protect the programmer from future hardware
changes.

>I suppose if one could arrange
>for the other 200 scans to be interlaced from a separate area of
>memory, then if it were set to all-black the appearance would mimic
>that of the current GS display, and any software written to know
>about the additional interlaced frame could stuff bits there to
>produce a higher-resolution image.  Unfortunately this complicates
>programming of access to the display bitmap.

Yet Another reason to use the toolbox.

BTW, I believe there's a hack for the ][ series that lets you get 280x384 (and 
maybe 560x384 on a //e) resolution with this.  Flip hires pages during the
vertical blanking interval, and the even frames you get one page, odd frames
another.  You'll want a high-persistence monitor for this.
--
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA
-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA