Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Is Intel exceptionally unsuccessful as an architecture designer?
Date: Fri, 20 Sep 2024 09:55:53 +0200
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <vcj9q9$10k84$1@dont-email.me>
References: <memo.20240913205156.19028s@jgd.cix.co.uk>
 <vcd3ds$3o6ae$2@dont-email.me>
 <2935676af968e40e7cad204d40cafdcf@www.novabbs.org>
 <vcd7pr$3op6a$3@dont-email.me> <7wCGO.45461$xO0f.1783@fx48.iad>
 <20240918190414.00005806@yahoo.com>
 <8e1aed9ce25c70cc555731140ae14eb1@www.novabbs.org>
 <vcfln9$836k$1@dont-email.me> <vcgi7p$fmaa$2@dont-email.me>
 <vcgjns$g1mt$1@dont-email.me> <vcgpqt$gndp$1@dont-email.me>
 <vcgvt0$hp5o$1@dont-email.me> <vcicol$ov66$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 20 Sep 2024 09:55:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5f413b970078924406529bce4531efbd";
	logging-data="1069316"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1++wvOC2jR42wNp3N4UM5aBf/PS5fDXY7r1eDFWdCC6Tg=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.19
Cancel-Lock: sha1:/6fl1VG8RDLNTCdN7UQM00yDyTw=
In-Reply-To: <vcicol$ov66$3@dont-email.me>
Bytes: 3828

Lawrence D'Oliveiro wrote:
> On Thu, 19 Sep 2024 12:54:23 +0200, Terje Mathisen wrote:
>=20
>> The way I implemented it was by updating the "official" back frame
>> buffer, and compare the update with the visible front buffer. If at an=
y
>> time a write to the back buffer did not result in something that was
>> already in the front buffer, I just copied the back buffer to the fron=
t
>> and went on from there.
>=20
> Is this where the need for =E2=80=9Ctriple buffering=E2=80=9D comes fro=
m -- the fact that
> you need to copy the entire contents of one buffer to another?
>=20
> The way I understood to do flicker-free drawing was with just two buffe=
rs
> -- =E2=80=9Cdouble buffering=E2=80=9D. And rather than swap the buffer =
contents, you just
> swapped the pointers to them.
>=20
If you cannot swap the buffers with pointer updates, then you need to=20
copy, and if that copy takes a long time, then you might need a third=20
buffer which you actually updating all the time.

This would be one HW frame buffer, with a slow write port (ancient IBM=20
CGA needed a bunch of frame times in order to update all of it=20
flicker-free, since you could only write during beam retrace intervals:=20
A few char cells duing each horizontal retrace, several lines during=20
vertical retrace.

In the back end you could flip between two buffers in RAM, but I never=20
found a need to do so. I just measured that it was much faster to write=20
a full screen from RAM to frame buffer than it was to do even a partial=20
copy from one part of the frame buffer to another, i.e for doing=20
scrolling within a window.

When lots of stuff was happing in my terminal emulator, I would limit=20
screen refreshes so that I didn't have to update the frame buffer more=20
than maybe 20 times/second. For smaller updates, they would be instantly =

visible (during the next horizontal retrace).

BTW, my back buffer was a list of lines, so that I could scroll by just=20
uninking the top line and adding a blank at the bottom, I tried to limit =

the number of bulk RAM accesses as much as possible.

Terje

--=20
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"