danbabcock@eklektik.UUCP (/dev/tty000) (04/10/90)
Jonathan Abbey (jonabbey@ccwf.cc.utexas.edu) wrote in message ID
<27737@ut-emx.UUCP>:
> Good advice at the last, but how do you intend for him to use the copper?
Consider writing out a new line of text at the bottom of the screen and
scrolling. Most editors just rewrite the entire screen from the ASCII
buffer, or else use the blitter to copy the bitmap to itself, offset one
line, and write out the new line to replace the last line in the bitmap.
However, the most efficient approach is to use the copper to simulate a
circular buffer-type display, much like the VIDC in the Archimedes.
In this scheme, the new line is placed where line 1 used to be, and the
copper list is adjusted so that line 1 (in memory) is displayed at the
bottom of the screen. Only one line (i.e. 640 bytes) in the bitmap needs
to be rewritten, and no memory needs to be physically moved. No "extra"
memory is required, besides the few words needed for the copper list.
(please note that when I say "line" I mean a line of text, not a line
of the bitmap)
Admittedly, using such a copper list could result in intuition menus
popping up in unusual areas of the screen, so it might be neccesary to
write custom menu code.
I agree that adding an ARexx port is a good idea.
-- Dan Babcock
1106 Jefferson Road
Pittsburgh, PA 15235
(412)-373-1753a464@mindlink.UUCP (Bruce Dawson) (04/11/90)
The blitter can scroll a non-interlaced text screen at 60 fps. No need to
go faster. The blitter can scroll an interlaced text screen at 30 fps. No
need to go faster, since that's how long it takes to display the whole screen
and faster scrolling would be detrimental.
Therefore, copper scrolling is not needed.
It might reduce the CPU/bus usage of the editor, but not necessarily.
Remaking copper lists in an intuition friendly way does take a chunk of time,
makes dragging screens tiresomely slow, and can cause problems when the screen
with the custom copper list is visible but is partially covered.
.Bruce Dawson - no signature.martint@altitude.CAM.ORG (Martin Taillefer) (04/12/90)
In article <1463@mindlink.UUCP> a464@mindlink.UUCP (Bruce Dawson) writes: > > It might reduce the CPU/bus usage of the editor, but not necessarily. >Remaking copper lists in an intuition friendly way does take a chunk of time, >makes dragging screens tiresomely slow, and can cause problems when the screen >with the custom copper list is visible but is partially covered. > >.Bruce Dawson - no signature. And let's not forget to mention that using a copper list prevents things like prop gadgets or real Amiga windows with borders to work. -- ---------------------------------------- Martin Taillefer INTERNET: martin@pnt.CAM.ORG UUCP: uunet!philmtl!altitude!martint TEL: 514/640-5734 BIX: vertex
mks@cbmvax.commodore.com (Michael Sinz - CATS) (04/12/90)
In article <1656@eklektik.UUCP> danbabcock@eklektik.UUCP (/dev/tty000) writes: >Jonathan Abbey (jonabbey@ccwf.cc.utexas.edu) wrote in message ID ><27737@ut-emx.UUCP>: > >> Good advice at the last, but how do you intend for him to use the copper? > >Consider writing out a new line of text at the bottom of the screen and >scrolling. Most editors just rewrite the entire screen from the ASCII >buffer, or else use the blitter to copy the bitmap to itself, offset one >line, and write out the new line to replace the last line in the bitmap. > >However, the most efficient approach is to use the copper to simulate a >circular buffer-type display, much like the VIDC in the Archimedes. >In this scheme, the new line is placed where line 1 used to be, and the >copper list is adjusted so that line 1 (in memory) is displayed at the >bottom of the screen. Only one line (i.e. 640 bytes) in the bitmap needs >to be rewritten, and no memory needs to be physically moved. No "extra" >memory is required, besides the few words needed for the copper list. >(please note that when I say "line" I mean a line of text, not a line >of the bitmap) > >Admittedly, using such a copper list could result in intuition menus >popping up in unusual areas of the screen, so it might be neccesary to >write custom menu code. I find that the editors I am using scroll faster than I can even try to see let alone read. It seems that everyone is looking at the wrong place where editors need help. Editors need to work WITH the system, not against it. Editors need to have ZERO bugs. Editors need to have GOOD ARexx ports. Editors need to have ZERO bugs. (Can't say this enough) Editors need to use the ClipBoard device. Editors need to have ZERO bugs. (An EDITOR should NEVER crash my machine!) Editors need to have multiple tasks for multiple files. Editors need to habe ZERO bugs. (A buggy editor is worthless) Editors need to be able to reconfigure the keyboard easily. Editors need to have ZERO bugs. (I used them a lot and can not with bugs) Editors need to have features that help in editing (column cut/paste, etc) Editors need to have ZERO bugs. (They should work in ANY version of the OS) Editors need to have features that help in coding (folds, simple syntax, etc) Editors need to have ZERO bugs. (This is very important!) /----------------------------------------------------------------------\ | /// Michael Sinz -- CATS/Amiga Software Engineer | | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | | /// | |\\\/// "I don't think so," said Ren'e Descartes. | | \XX/ Just then, he vanished. | \----------------------------------------------------------------------/
martint@altitude.CAM.ORG (Martin Taillefer) (04/13/90)
Gee Mike, I wonder what editor you're using which meets all those requirements? ;-) -- ---------------------------------------- Martin Taillefer INTERNET: martin@pnt.CAM.ORG UUCP: uunet!philmtl!altitude!martint TEL: 514/640-5734 BIX: vertex