Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!uunet!bfmny0!tneff From: tneff@bfmny0.BFM.COM (Tom Neff) Newsgroups: alt.sources.d Subject: Re: Stevie (vi clone) Keywords: stevie Message-ID: <15789@bfmny0.BFM.COM> Date: 24 Aug 90 08:54:26 GMT References: <55195@iuvax.cs.indiana.edu> Reply-To: tneff@bfmny0.BFM.COM (Tom Neff) Lines: 33 In article cybrspc!roy@cs.umn.edu (Roy M. Silvernail) writes: >I've played about pretty extensively with Stevie 3.69 whilst modifying >it for BBS use (under MS-DOS). I have compiled both with and without >BIOS video writes. The non-BIOS routines are _significantly_ faster on >my machine. The only difference I can see is that BIOS video doesn't >require the NANSI driver. Perhaps I just have a lethargic BIOS? Very likely so. There are three ways a program can write to a PC screen: (1) use the BIOS interface, (2) pump escape sequences at the DOS CON: device in the expectation that some ANSI driver (ANSI.SYS, NANSI, FANSI-CONSOLE) will be installed; (3) toggle the screen hardware directly. Programs that use the BIOS succeed almost everywhere, but they rely on the BIOS's efficiency and speed optimization, which frequently stinks. Some of the old IBM BIOS code, for instance, was an absolute pig on character write and flashed the screen repeatedly during scrolls to avoid snow during the retrace interval. Programs that use ANSI escape sequences are hostage to the presence, efficiency and completeness of the user's installed screen driver. With the right driver (NANSI or FANSI) applications can handily beat BIOS based times. This is probably the case with Stevie 3.69 on Roy's machine. Programs that write directly to the video hardware can often outperform everyone else, but are also most likely to have portability problems across various PCs and software environments. -- There's nothing wrong with Southern California that a ~~ Tom Neff rise in the ocean level wouldn't cure. - Ross MacDonald ~~ tneff@bfmny0.BFM.COM