Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!rutgers!mcnc!uvaarpa!murdoch!astsun9.astro.Virginia.EDU!gl8f
From: gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Closing AES boxes interfering with VDI drawing
Keywords: aes dialog
Message-ID: <1990Dec20.014600.22089@murdoch.acc.Virginia.EDU>
Date: 20 Dec 90 01:46:00 GMT
References: <4545@ruuinf.cs.ruu.nl> <1990Dec19.150920.12812@murdoch.acc.Virginia.EDU> <4eb2849b.20b6d@apollo.HP.COM>
Sender: news@murdoch.acc.Virginia.EDU
Distribution: na
Organization: Department of Astronomy, University of Virginia
Lines: 23

In article <4eb2849b.20b6d@apollo.HP.COM> rehrauer@apollo.HP.COM (Steve Rehrauer) writes:

>>The question is, of course, is how much faster is your hard-wired
>>routine than using a software-blitter? It's better to fix the slow ROM
>>code in one place than fix it in all your programs.
>
>Which (code in TOS ROMs) is out of Jeroen's control.  And, this assumes
>that Atari *will* optimize the ROMs in our lifetimes.

No, I was talking about commercial programs like TurboST and QuickST,
that replace the ROM routines. They are sometimes not completely
compatible, but it seems that if you're doing "ordinary" GEM programs,
they do pretty well. And you can just program in GEM and not have to
drop into assembler all the time.

>(*Have* they significantly sped-up AES or VDI since v1.0 of the ROMs?

Well, from what people said, removing the line-F traps and putting in
subroutine calls made things faster. But they certainly didn't go in
and rewrite the VDI routines in assembler :-( Fortunately, there are
at least 2 companies happy to exchange your cash for their solution.

Are QuickST and TurboST available in Europe?