On Sun, 17 Mar 2002 at 18:17:21, ZN wrote:
(ref: <[EMAIL PROTECTED]>)
>Joachim wrote:
>
>> As I already mentioned, I am willing to volunteer for the following
>> changes in SMSQ.
>>
>>- have all windows draw their contents in the save area
>>- background update of windows (same mechanism)
>
>Yessss! :-)
>
>>In general I propose the following changes.
>>- Application should not draw onscreen, but in the save area. When they
>>properly use the iow.xtop call as exists at the moment, nothing needs to
>be
>>done, except that the use of iow.xtop will no longer be necessary (the
>call
>>now gives the address with the screen base, so that makes things easy). In
>>practice the applications which work in extended resolutions will not need
>>any changes.
>
>Exactly.
>Also, emulation for applications that need to use the original screen areas
>would actually be easyer to implement. They would effectively get one save
>area that just happened to be at $20000.
>Further important side effects:
>a) 'Regular' memory is generally quite substantially faster than screen
>memory
Wasn't it 30%?
>b) The address of the screen memory can really be anywhere, only the
>'sweeper' task needs to know where.
How does the second screen concept fit into all this?
... sorry if you said but there was a _lot_ of text (8-)#
It is a long time since I have seen this (now I use SGC) but if memory
was short, TT used the visible screen area as a working area. Quite
entertaining to watch.
--
QBBS (QL fido BBS 2:252/67) +44(0)1442-828255
tony@<surname>,demon.co.uk http://www.firshman.demon.co.uk
Voice: +44(0)1442-828254 Fax: +44(0)1442-828255
TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
