rde@ukc.ac.uk (R.D.Eager) (08/12/86)
[food for line eater]
I have mounted MicroEMACS 3.7 on my PC compatible using Lattice 2.14. I
had no problems, except I had to use large code and large data model to
get it to fit.
My problem is that response to some commands (e.g. PgDn) is distinctly
soggy. Is this true of all versions? just the PC version? Lattice C versions?
My machine is an 8086 based PC compatible, fitted with a NEC V30 and
running at the normal clock speed of 4.77 MHz.
Any ideas, anyone?
--
Bob Eager
rde@ukc.UUCP
rde@ukc
...!mcvax!ukc!rde
Phone: +44 227 66822 ext 7589toma@tekgvs.UUCP (Thomas Almy) (08/13/86)
In article <1774@eagle.ukc.ac.uk> rde@ukc.ac.uk (R.D.Eager) writes: >I have mounted MicroEMACS 3.7 on my PC compatible ... >My problem is that response to some commands (e.g. PgDn) is distinctly >soggy. Is this true of all versions? just the PC version? Lattice C versions? I noticed that too. In order to run with brain-damaged display adapters (which snow) on every line it waits for the next vertical retrace interval to move the character. Thus it takes 24 retraces (almost a second) for a complete screen rewrite. If your display does not snow, just remove the problem code from ibmpc.c. It speeds up alot. Also, when compiled with Microsoft C, most of the spawning operations just plain don't work. And control-P toggles the printer again. I ended up taking the code for the features I wanted that were new to 3.7 (incremental search, modified C mode, new position display, quoting in search strings) and retrofitting them into the version of 3.6 that has a working spawn and handles my display (EGA in 43 line mode). Tom Almy Tektronix
daveh@cbmvax.cbm.UUCP (Dave Haynie) (08/14/86)
> Xref: cbmvax net.emacs:435 net.micro:1339 net.micro.pc:2317 > > > [food for line eater] > > I have mounted MicroEMACS 3.7 on my PC compatible using Lattice 2.14. I > had no problems, except I had to use large code and large data model to > get it to fit. > > My problem is that response to some commands (e.g. PgDn) is distinctly > soggy. Is this true of all versions? just the PC version? Lattice C versions? > > My machine is an 8086 based PC compatible, fitted with a NEC V30 and > running at the normal clock speed of 4.77 MHz. > > Any ideas, anyone? > -- > Bob Eager Except during high loads, most of the commands are acceptably fast on my VAX (Ultrix == BSD3.2 or thereabouts), and I've had similar results with 3.6 on my Amiga. Its not exactly blinding, but fully usable. Also, on the VAX when the system's slow the cursor will keep up with my typing and the program will go back and fill in what I typed when I slow down. Your problem on the PC may be due to the inherent slowness of PCs, but there's a good chance you could blame your compiler's large memory model as well. Some of these models call memory access routines for each and every pointer access in the program! With some code at least that could slow you down by a few orders of magnitude. I'm not completely familiar with PC family compilers, but recently one of the software magazines had an article on large-memory models for 8088... family systems (think it was Computer Language, but it could have been DDJ). -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "I gained nothing at all from Supreme Enlightenment, and for that very reason it is called Supreme Enlightenment." -Gotama Buddha These opinions are my own, though for a small fee they be yours too. \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
jon@amc.UUCP (Jon Mandrell) (08/14/86)
<line eater food> If you think 3.7 is bad, you should have seen 3.6. Are you compiling it with the IBMPC.C file, or with the ANSI.C file? I find it runs faster with the IBMPC.C. Note that if you are running on a PC without a graphics adaptor, this code will not work! There is a #define for the screen location as 0xb8000000L. This should be changed to 0xb0000000L. Actually, the code should check for this. To the author of Micro-emacs: I really like the program, but a question. Why do you provide #define's for Mark Williams C and then not support it in the code? Version 3.6 had the same problem with both Mark Williams and Lattice v3.0. It seems that you should either complete the #if's AND TEST IT, or remove them. -- Jon Mandrell (ihnp4!uw-beaver!tikal!amc!jon) Applied Microsystems Corp. "flames >& /dev/null" - me
dennis@CSNET-SH.ARPA (Dennis Rockwell) (08/15/86)
From: Jon Mandrell <tikal!amc!jon@uw-beaver.ARPA> Date: 14 Aug 86 19:24:58 GMT Subject: Re: MicroEMACS 3.7 response [ ... ] It seems that you should either complete the #if's AND TEST IT, or remove them. Give the guy a break! Much of the compiler- and machine-specific code is contributed; how is anybody supposed to afford to buy all possible combinations of software and hardware to test? The source code is freely distributed so that *we* can make the changes and fixes that we need and feed them back. So, go fix your problems and mail them in. The code is clear enough. Dennis
dennis@CSNET-SH.ARPA (Dennis Rockwell) (08/15/86)
Greetings! I've been looking into causes for the slow response that I've been seeing on our overloadad 11/750. Doesn't it bother anybody else that the routine execute in main.c scans the entire binding table on each keystroke? For most keystrokes (those that effectively self-insert), this search will fail. I have rewritten the relevant code and rearranged keytab so that keytab lookups are simple array indexes. There really is a (bindable!) self-insert command and function. Startup is much faster because bind-to-key is dramatically faster. It's perceptibly harder to type faster than emacs can update my screen. Because of the complete rewrite of ebind.h, these changes are probably too big to post. However, I'm sending them to Daniel Lawrence, in hopes of getting them into the next release. The drawback here is that there are now three tables that are each 256 entries long, containing the keybindings. I have also fixed wrapword to behave better (you've probably had it mess up on you), and fillpara has been modified similarly (fillpara now just removes all the newlines in the paragraph and calls wordwrap). These changes will also be sent to Daniel Lawrence. Dennis
rde@ukc.ac.uk (R.D.Eager) (08/16/86)
In article <1680@tekgvs.UUCP> toma@tekgvs.UUCP (Thomas Almy) writes: >In article <1774@eagle.ukc.ac.uk> rde@ukc.ac.uk (R.D.Eager) writes: >>I have mounted MicroEMACS 3.7 on my PC compatible ... >>My problem is that response to some commands (e.g. PgDn) is distinctly >>soggy. Is this true of all versions? just the PC version? Lattice C versions? > >I noticed that too. In order to run with brain-damaged display adapters >(which snow) on every line it waits for the next vertical retrace interval to >move the character. Thus it takes 24 retraces (almost a second) for a >complete screen rewrite. If your display does not snow, just remove the >problem code from ibmpc.c. It speeds up alot. Actually, that was the first thing I tried. Didn't seem to make a lot of difference though. Perhaps it's just Lattice C (sigh).... -- Bob Eager rde@ukc.UUCP rde@ukc ...!mcvax!ukc!rde Phone: +44 227 66822 ext 7589
rde@ukc.ac.uk (R.D.Eager) (08/19/86)
[food for line eater]
Many thanks to those who replied to my query about MicroEMACS 3.7
response on a PC-compatible. I had already tried for the retrace delay,
but it didn't make a whole lot of difference...just snow.
Thanks to 'Ron' - I can't find his reply now. The problem was that I was
using the L model (large code and large data) because I couldn't get the
D model (small code, large data) into 64K of code. He suggested using
the -s compiler switch which tells the compiler not to normalise
pointers; this speeded it up *and* got it under 64K so I could use the D
model and speed it up even more!
It's fine now. Thanks!
--
Bob Eager
rde@ukc.UUCP
rde@ukc
...!mcvax!ukc!rde
Phone: +44 227 66822 ext 7589