git @ Cat's Eye Technologies The-Dossier / master
Revise "A Basic Theory of Video Games": illustrations and editing. Chris Pressey 1 year, 4 months ago
1 changed file(s) with 241 addition(s) and 151 deletion(s). Raw diff Collapse all Expand all
11 =============================
22
33 * publication-date: 3 May 2017
4
5 Modern computers are extremely powerful. But they weren't always so, and
6 video games were invented back in an age when processing power was still
7 rather modest. But they were still capable of fast and frenetic action,
8 demanding of the player's reflexes. So one might wonder: How did they work?
4 * revision @ 12 Mar 2020 (added illustrations, more footnotes, edited for clarity)
5
6 In the modern era, computers are extremely powerful. But they weren't always so,
7 and video games were invented back in an age when processing power was still
8 quite modest. But they were still capable of fast and frenetic action,
9 demanding of the player's reflexes. So one might wonder: How did they do that?
910
1011 The operative word is _video_. Understanding how a television works will
1112 really help in understanding how a video game works.
1213
1314 ### Video
1415
15 How an old-school black-and-white analog television generates its glowing
16 screen is not too complicated. At the back there's a "gun" that shoots a
17 beam of electrons forward, and where this beam hits the screen from behind,
18 it makes a glowing spot. The intensity of glow can be varied by changing
19 the intensity of the beam. And there are some magnets along the sides which
20 can bend the beam before it hits the screen and thus determine where on the
21 screen the spot appears.
22
23 But, there can only be one spot that is being hit like this at any one time,
24 so to create the illusion that the whole screen is glowing, the trick is to
25 move the spot around very, very quickly.
26
27 So what we need is a good method for covering the entire screen in an
28 orderly fashion. And what we have is this: each _frame_ starts at the top,
29 and is composed of successive left-to-right _scan lines_, each of which is
30 slightly lower down on the screen. Then when we get to the bottom-right of
31 the screen, the beam goes back up to the top-left for the next frame.
16 How an old-school analogue television tube generates images on
17 its glowing screen is not too complicated. At the back of the tube there's
18 a "gun" that shoots a beam of electrons forward, and where this beam hits the
19 screen from behind, it makes a glowing spot. The intensity of the beam can
20 be changed to vary the brightness of the glow, and there are some magnets along the
21 sides of the tube which can bend the beam before it hits the screen, and thus determine
22 where on the screen the spot appears. (It's a little more complicated for
23 colour TVs, but let's ignore those for now to keep things simple.)
24
25 But — at any given time there can only be *one* spot on the screen that's being
26 hit by the beam like this. So to create the illusion that the whole screen is
27 glowing, the trick is to move the spot around *very, very quickly*.
28
29 To make an image that fills the screen, we need a good method for
30 covering the the entire screen in an orderly fashion. The method developed
31 for television broadcasting is one such method. Each _frame_ starts at the
32 top-left of the screen, and is composed of successive left-to-right _scan lines_,
33 each of which is slightly lower down on the screen than the one before it. Then,
34 when we get to the bottom-right of the screen, the beam goes back up to the
35 top-left for the next frame.
3236 [(Footnote 1)](#footnote-1)
37
38 ![Diagram of video frame scan lines](https://static.catseye.tc/images/illustrations/617px-Raster-scan.svg.png)
3339
3440 While there are certainly some differences, modern displays work quite
3541 similarly. [(Footnote 2)](#footnote-2)
3642
3743 That glowing spot is fairly small, so to get a nice, solid-looking frame, we
38 should space the scan lines closely together. Say that there are 200
39 scan lines on our picture tube. And, remember we're varying the intensity of
40 the beam as it goes along the scan line, in order to draw individual pixels;
41 say there are 200 pixels on a scan line. (Note that I'm just making up
42 representative numbers in this section; they don't necessarily correspond to
43 the specs of any real video equipment.)
44
45 As I said, the frame must be drawn quickly to make it look solid, and further,
46 if we want the impression of smooth movement in the video, the frames must be
47 done in quick succession as well — say, 30 frames per second.
48
49 So, each frame must be drawn in 1/30 of a second, and thus each scan
50 line must be drawn in 1/6000 of a second. That's a really short time —
51 one-sixth of a millisecond. And since each scan line contains 200 pixels, the
52 beam must be able to change in intensity 1.2 million times a second.
44 should space the scan lines closely together. For the sake of concreteness,
45 let's say there are 200 scan lines on our picture tube, and that we will
46 vary the intensity of the beam 200 times during each scan line.
47 Each frame must be drawn quickly to make it look like a solid image, and
48 if we want the impression of smooth motion in the video, the frames must be
49 generated in quick succession, as well — say, 30 frames per second.
50
51 Crunching these numbers, we find that each frame must be drawn in 1/30 of a
52 second, and each of its 200 scan lines must be drawn in 1/6000 of a second.
53 That's a really short time — one-sixth of a millisecond. And since each scan
54 line contains 200 pixels, the beam must be able to change in intensity
55 1.2 million times a second!
5356
5457 ### Video display circuitry
5558
56 1.2 million times per second is a lot of times per second to do anything,
57 and while it's not too difficult to pack this many changes into an analog TV
58 signal, if you wanted a *computer* to generate this signal, it would really
59 help matters if it had some dedicated hardware to do that, because you'd use
60 up a lot of cycles if you were to task the CPU with controlling every pixel
61 individually.
62
63 So early computers, or at least the kind inside video arcade games and home
64 units that were meant to be hooked up to TVs, often had a significant amount
65 of their electronics dedicated to the problem of generating the video signal.
66
67 In fact, to appreciate how video-oriented the early computers were,
68 consider that the Commodore 64's clock speed in North America was
69 1.023 MHz. Why such a weird number, especially when the CPU was capable
70 of 2 MHz? Because the clock signal that was driving the CPU was obtained
71 by scaling down the master clock, whose frequency was 14.31818 MHz,
72 which was chosen because it could generate frequencies matching the NTSC
73 standard. ([This StackExchange answer][] has a detailed exposition of
74 this design approach.) Later generations of computers used dedicated video
75 clocks in their video circuitry to allow the CPU and the video to run at
76 independent rates.
77
78 Either way, we have this dedicated video display circuitry which can generate
79 a video signal without taking up any of the CPU's time. How does it generate
80 the display? There are many possible tricks it can use [(Footnote 3)](#footnote-3),
81 but the basic idea is that there is a chunk of RAM dedicated to holding a
82 representation of the display — the "video RAM" — and this circuitry reads it
83 and derives the signal that will modulate the beam which will make the various
84 points on the screen either bright or dark (or different colours, but we can
85 ignore that complication for our purposes).
86
87 The contents of the video RAM are relatively persistent — the video circuitry
88 just reads it over and over and generate the frames from it over and over
89 and, if nothing changes the contents of the video RAM, the frames don't change
90 either and the picture looks still. And a program (running on the CPU)
91 only has to write a different value to one of the bytes of RAM, and the
92 part(s) of the screen that correspond to that byte will look different when
93 the next frame is drawn.
94
95 [This StackExchange answer]: https://retrocomputing.stackexchange.com/questions/2146/reason-for-the-amiga-clock-speed
59 1.2 million times per second is a lot of times per second to do anything.
60 It's not too difficult to pack this many changes into an analogue signal
61 that's being transmitted via radio waves (as TV signals originally
62 were), but if you need a *computer* to generate such a signal, that's
63 a slightly different story.
64
65 In the 80's it was not unusual for a CPU to have a clock speed of 4MHz,
66 that is, four million times per second. But it would take several
67 clock cycles to perform a single instruction. Let's say it took 4
68 on average, so the CPU could execute one million instructions per
69 second.
70
71 This CPU would be *almost* fast enough to control the intensity of
72 the video beam to generate our 200 scan lines of 200 pixels each.
73 But — if it were tasked with doing that, we would have another problem:
74 it wouldn't have any time left over to do anything else!
75
76 To solve this problem, early computers, or at least the kind meant to be
77 hooked up to a television tube (arcade games and home computers),
78 often had a significant amount of electronics inside them dedicated
79 solely to the task of generating the video signal.
80
81 In fact, some of the architectural designs of these older computers
82 are so video-oriented that they feel like devices designed to
83 generate a video signal with a general-purpose computer strapped
84 onto them, rather than the other way around.
85
86 Consider, for example, that the processor clock speed of a Commodore 64
87 in North America was 1.023 MHz. Why such a weird number, especially when the
88 CPU was capable of 2 MHz? Because the clock signal that was driving the CPU was
89 obtained by scaling down a master clock whose frequency was 14.31818 MHz.
90 And why did it have such a master clock? So that it could generate frequencies
91 matching the NTSC standard, to make the video signal for the North American
92 TV set that it would typically be hooked up to. [(Footnote 3)](#footnote-3)
93
94 At any rate, instead of making it the CPU's responsibility to generate the video signal,
95 the computer would have dedicated video display circuitry to generate
96 the video signal without taking up any of the CPU's time.
97
98 But how does this circuitry generate the display? There are many possible tricks it
99 can use [(Footnote 4)](#footnote-4),
100 but the general idea is that in the computer there is some RAM dedicated to holding a
101 representation of the display — the "video RAM" — that both the CPU and this
102 circuitry can access. The CPU writes some values to it describing what should
103 be displayed, and the video display circuitry reads these values and uses them to
104 derive the signal that will modulate the beam that will make the various
105 points on the screen either bright or dark.
106
107 The contents of the video RAM persist while the computer is powered on.
108 The video display circuitry reads the video RAM (over and over and over), and
109 generates the video signal from it (over and over and over), and
110 if nothing changes the contents of the video RAM, the frames don't change
111 either, and the picture on the screen looks still. A program running on the CPU
112 only has to write a different value to one of the locations in video RAM, and the
113 part(s) of the screen that correspond to that location will look different when
114 the next frame is drawn. [(Footnote 5)](#footnote-5)
96115
97116 ### Vertical blanking interval
98117
99118 I say "next frame" but of course, since the CPU doesn't have direct
100119 control over when the video circuitry will turn any given part of video
101 RAM into a video signal, there is no guarantee that the video RAM won't
102 be updated right when the frame is being drawn. When that happens, the
103 frame is based partly on the previous state of the video RAM, and
104 partly on the new state of the video RAM, and the viewer sees just that —
105 a flickering between partial images. (A particularly egregious instance
106 of this effect is "CGA snow".) How do we prevent this?
107
108 There's one thing I've omitted, and it comes from the fact that in an
109 analog TV, the beam can't travel around the screen instantaneously. It
120 RAM into a video signal, there is no guarantee that the CPU won't update
121 the video RAM at the exact moment when the frame is being drawn. When
122 that happens, the frame is based partly on the previous state of the
123 video RAM, and partly on the new state of the video RAM, and what do you
124 suppose the viewer sees on the screen when that happens? Generally speaking,
125 they see a choppy flickering between partial images, and generally
126 speaking, it's unpleasant. (A particularly egregious instance
127 of this effect is the so-called [CGA snow](https://en.wikipedia.org/wiki/Color_Graphics_Adapter#Limitations.2C_bugs_and_errata).)
128 So, how can this unpleasantness be prevented?
129
130 There's one detail I've omitted in the description of how the television
131 works: the beam can't travel around the screen instantaneously. It
110132 takes a bit of time, however small it might be, to change the power to
111 the magnets, and that glowing spot always must make a continuous path
112 from one point to another.
133 the magnets. That glowing spot can't teleport; it always takes a
134 continuous path from one point to another.
113135
114136 So what happens is, each time the beam gets to the right side of the screen,
115 it "blanks" (becomes intensity zero = no glow) as it travels back to the left
116 for the next scan line. Ditto each time it gets to the bottom, it "blanks"
117 while travelling back to the top. These short periods of time are called the
118 _horizontal blanking interval_ (HBI) and the _vertical blanking interval_
119 (VBI), respectively. The latter, especially, is very important for video games.
137 it "blanks" (becomes intensity zero = no glow) as it "retraces" (travels back)
138 to the left for the next scan line. Ditto, each time it gets to the bottom, it
139 "blanks" as it "retraces" to the top-left. The short periods of time when these
140 retraces are happening are called the _horizontal blanking interval_ (HBI) and
141 the _vertical blanking interval_ (VBI), respectively. The latter, especially,
142 is very important for video games.
120143
121144 The key idea is that *if you wait for the vertical blanking interval before
122 making changes to video RAM, and also get all those changes done before the
145 making changes to video RAM, and also get all your changes done before the
123146 first scan line of the next frame starts being displayed, you will get a
124147 smoothly-drawn and smoothly-animated display*.
125148
126149 To enable this, the computer architecture is usually wired up such that
127150 the CPU is able to detect when a VBI has begun. Often this is done with an
128 _interrupt_, which is a way to alert the CPU of an external event regardless
129 of what the CPU is doing at the time.
151 _interrupt_, which is a way to alert the CPU of an external event no matter
152 what the CPU is doing at the time.
130153
131154 But regardless of how it's implemented exactly, the idea is that the CPU
132155 waits for the VBI to start, and then gets to work writing new values to the
133 video RAM that reflect what the screen should look like next. It is also
134 important that it should finish this work before the VBI is over, because
135 as soon as the next frame begins being drawn, any updates to video RAM
136 could cause flickering. And the CPU shouldn't touch the video RAM again
156 video RAM that reflect what the screen should look like next. It's
157 important that it should finish this work before the VBI is over, too,
158 because as soon as the next frame begins being drawn, any updates to video
159 RAM could cause flickering. And the CPU shouldn't touch the video RAM again
137160 until the next VBI begins.
138161
139 But there is this entire screen that is being drawn by the video hardware
140 during this time between VBIs. Does the CPU just sit there, waiting idly
162 In the time between VBIs, there's this entire screen being drawn, scan line
163 by scan line, by the video display circuitry, and the CPU can't touch the
164 video RAM. So does the CPU just sit there, waiting idly
141165 for the next VBI to start? No, that would be wasteful. Instead, it can
142166 use this time productively by computing the next state of the game. For
143167 example, what will be the player's new position based on their velocity?
144168 Did they collect a treasure and should we increase their score? That sort
145169 of thing. Then, when the next VBI does come, it will update the video RAM
146 from that new game state that was computed.
147
148 So in some sense, the history of video games has been "how much processing
149 can you get done in 1/*n*'th of a second?"
170 from that new game state that was computed. And if the new game state has
171 been completely computed by that time, it can perform the display updates
172 quickly — within the space provided by the VBI. [(Footnote 6)](#footnote-6)
173
174 So in some sense, the history of video games can be summed up as: "How
175 much processing can you get done in 1/*n*'th of a second?"
150176
151177 To recap:
152178
160186
161187 ### State
162188
163 Now that we've made it clear, hopefully, how dependent a video game is on
164 translating the game state into video updates which can occur in a timely
165 manner, and updating the game state in a timely manner as well during the
166 period that the screen is actually being drawn, we should probably talk
167 about how the game state can be structured to accomplish this.
189 Hopefully the above has made it clear just how dependent a video game is on
190 translating the game state into a set of video updates which can occur in a timely
191 manner, as well as updating the game state in a timely manner during the
192 period that the screen is actually being drawn. Now let's discuss
193 how the game state can be structured to actually accomplish this.
168194
169195 Saying "the next game state is based on the current game state plus the
170 state of input devices" is very nice from a sort of mathematical point of
171 view, but it's far too abstract to do much with. Computer science provides
196 state of input devices" is very nice from a mathematical point of
197 view, but it's rather abstract to work with. Computer science provides
172198 us with the concept of the _state machine_ which can help us break it down.
173199
174 However, note that here the state machine concept is used primarily as a
175 *concept*, and not as programming abstraction. That is, you don't tend to
176 see anything like `class StateMachine { ... }` in a video game's code, at
200 Note, however, that here the state machine concept is used primarily as a
201 *design pattern* rather than as a reusable framework. There are many, many
202 ways to implement a state machine, and you don't tend to see anything
203 as elaborate and refined as `class StateMachine { ... }` in a video game's code, at
177204 least not until the 1990's, because the overhead for such a thing would be
178205 prohibitive on (e.g.) an 8-bit processor.
179206
183210 subtle; it basically comes down to, if we are inside such-and-such part
184211 of the code, we know we must be in such-and-such state (because otherwise,
185212 how did we get here?), so act accordingly. It's like the information
186 about current state has been "compiled into" the code.
187
188 There are two other things to note about the states of a video game:
213 about the current state has been "compiled into" the code.
214
215 This sort of code-to-state association also leads to a neat trick where the
216 address of the routine that handles a particular state can be used to uniquely
217 identify that state; you can store the address of the routine directly in the
218 "current state" variable, and make comparisons on it. This saves having to
219 establish an extra enumeration of values to represent the state.
220
221 There are a couple of other things about the state structure of a video game
222 that might be easy to miss:
189223
190224 * They extend outside of the game itself. Coin-op arcade games have
191225 an "attract mode", which might include a pre-recorded demonstration
192226 of the game being played, but even simple home games generally have a
193227 title screen or something before a new game begins, and that title
194228 screen is a state too.
195
196229 * They are composed of smaller states, sometimes sub-state machines.
197230 For instance, in the "attract mode" state, the machine might
198 switch between showing a title screen, the list of high scores,
199 and a summary of the rules, each displayed for 5 seconds — these
231 switch between showing a title screen and the list of high scores,
232 each displayed for 5 seconds — these
200233 are sub-states of the "attract mode" state. Or, during the game
201 itself, there might be 12 spaceships on the screen, each with
234 itself, there might be 12 antagonists on the screen, each with
202235 its own state (position and velocity). You could also call those
203 sub-states, but here they compose differently — you could say the
204 state of the "game screen" is the "Cartesian product" of those 12
236 sub-states of the game, but here they compose differently — you could
237 say the state of the game includes the [Cartesian product][] of those 12
205238 states.
206239
207240 There are virtually an endless number of ways these configurations of
208241 states can be combined and implemented, and even listing the most common
209 patterns would probably be outside the scope of this article. But to
210 try to give a single, illustrative example, here are how the state logic
211 for a very simple video game might appear inside the video-updating loop
212 given in the previous section:
242 patterns would probably be outside the scope of this article.
243
244 But as a concrete example, here is the diagram of a nested state machine describing
245 the _Asteroids_-like game [Cosmos Boulders](https://github.com/catseye/Cosmos-Boulders):
246
247 ![State machine diagram for the game "Cosmos Boulders"](https://raw.githubusercontent.com/catseye/Cosmos-Boulders/master/images/state-machine-diagram.png)
248
249 And here's a rough description of how the state logic in the above
250 diagram might be coded inside the video-updating loop we talked about in
251 the previous section. (In a few places in it I've not included
252 every last detail, so as not to be bogged down while getting the main points
253 across. If it's the sort of thing that appeals to you, you can say that filling
254 in every last detail here is left as an exercise for the reader.)
213255
214256 * Wait for the VBI to begin.
215257 * Update the video RAM based on the current game state:
216 * If we are in attract mode, draw the game's logo.
217 (Perhaps the logo is animated, in which case, draw frame _n_
218 of it, where _n_ comes from a counter which is incremented each
219 time a VBI starts.)
258 * If we are in attract mode, draw either the game's logo,
259 or the list of high scores, depending on the sub-state.
220260 * If we are in game-over mode, draw the text "GAME OVER"
221261 on the screen.
222 * If we are in game-play mode, draw the ships on the screen
223 based on their position.
262 * If we are in game-on mode, draw the ship, boulders, and missiles
263 on the screen, based on their position and their individual
264 states (i.e. if they're exploding, draw an explosion instead).
224265 * Update the game state:
225266 * If we are in attract mode, check if the "Start Game" button is
226 being pressed, and if so change to game-play mode.
267 being pressed, and if so change to game-on mode. If not,
268 check if a certain amount of time has passed, and if so,
269 switch from showing the logo to showing the high scores, or
270 vice versa.
227271 * If we are in game-over mode, check if a certain amount of
228272 time has elapsed, and if so change to attract mode.
229 * If we are in game-play mode:
230 * compute the new position of each ship based on its current
231 position and velocity;
232 * compute the new velocity of the player's ship based on
233 the position of the joystick;
234 * compute the new velocity of the enemy ships based on
235 the position of the player's ship and their "AI"; and
236 * if the player's ship overlaps with one of the enemy ships,
237 change from game-play mode to game-over mode.
273 * If we are in game-on mode:
274 * If the player is in playing mode, compute the new velocity
275 of the player's ship based on the position of the joystick;
276 Also, if the player's ship overlaps with one of the boulders,
277 change the player from playing mode to exploding mode.
278 * If the player is in exploding mode, check to see if a certain
279 amount of time has passed. If it has, decrement the number of
280 lives of the player. If it is above zero, go back to playing
281 mode, else go to game-over mode.
282 * For each boulder, if the boulder is in moving mode,
283 compute its new position based on its current
284 position and velocity.
285 * For each missile, if the missile is in moving mode,
286 compute its new position based on its current
287 position and velocity.
238288 * Wait for the next VBI to begin.
239289 * Repeat ad infinitum.
240290
241291 ...and when the machine is powered on (or when this game is loaded from
242292 a cassette tape, or whatever,) there is some startup code that sets
243293 up the initial state (current mode = attract mode, etc.) and jumps
244 to this loop.
294 into this loop.
245295
246296 ### Conclusion
247297
253303 of little holes that have been glossed over — but knowing about it
254304 might give you a deeper appreciation of the medium.
255305
256 For example, have you ever been playing a first-person shooter and you
306 For example, it gives some insight as to why there are bars of
307 "dead space" above and below the main display on many older
308 home computers: it effectively makes the VBI longer. Some games
309 also update only the top half of the screen regularly, and
310 fill the bottom half with an ornate, but largely static,
311 "status display", which is another way to artificially lengthen
312 the amount of time they have to update video RAM before the
313 display circuitry gets to converting it to a video signal.
314
315 Or, have you ever been playing a first-person shooter and you
257316 trigger some kind of boobytrap and a bunch of antagonists appear and
258317 everything gets all choppy? You might know that that's called "frame drop",
259318 and you probably guessed it's because the computer now has "too much to do".
269328 capable of doing all kinds of things completely independently of the
270329 CPU, and because games often now run under multitasking operating systems
271330 that try to fairly distribute resources like processing time (and
272 the video display!) to multiple programs at once, and that thus require
273 their programs to use abstractions that distance them significantly from
274 the video hardware.
331 the video display!) to multiple programs at once, and that require
332 these programs to access these resources via abstractions
333 that distance them significantly from the hardware.
275334
276335 But also no, because you don't have to look far to see many of the
277336 same ideas, just in a different guise. For example, in Javascript in
278337 a modern web browser you can [request an animation frame][], which is
279338 an awful lot like waiting for the VBI.
280339
340 [Cartesian product]: https://en.wikipedia.org/wiki/Cartesian_product
281341 [request an animation frame]: https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame
282342
283343 ### Footnotes
293353
294354 Modern display devices are composed of millions of display elements —
295355 effectively, tiny lights — so in theory they no longer have the restriction
296 of only being able to make one spot glow at a time. However, it it still
356 of only being able to make one spot glow at a time. However, it's still
297357 more energy-efficient to do it that way. So they still work in basically
298358 the same way, with frames made up of scan lines.
299359
306366
307367 ##### Footnote 3
308368
369 [This StackExchange answer](https://retrocomputing.stackexchange.com/questions/2146/reason-for-the-amiga-clock-speed)
370 has a detailed exposition of this approach as it applies to the Amiga.
371 Later generations of computers used dedicated video
372 clocks in their video circuitry to allow the CPU and the video hardware
373 to run at independent rates.
374
375 ##### Footnote 4
376
309377 Discussing all the tricks that have been used to make it possible to generate
310378 a signal for the entire screen in such a short amount of time on a system with
311379 limited processing power is probably outside the scope of this article, but
316384 * hardware sprites
317385 * double-buffering
318386 * scan line and frame offsets ("smooth scrolling")
387
388 ##### Footnote 5
389
390 The seperation wasn't always as clean as this makes it sound. The Atari 2600,
391 for example, did have some dedicated hardware for displaying some "players and
392 missiles" without the CPU's involvement, and the registers in this chip were in
393 some sense the machine's "video RAM"; but that's effectively *all* it had. If
394 you wanted to display other graphics, such as a background, the CPU *would* have
395 that responsibility. The CPU would need to execute instructions to change the
396 video signal at certain points on each scan line, as it was being drawn,
397 sometimes executing dummy instructions to make sure it was in sync with where the
398 scan line was at all times — a technique that has been called "racing the beam".
399
400 ##### Footnote 6
401
402 It's probably worth noting that, once RAM became affordable enough, the
403 double-buffering technique came to dominate, as it makes this much easier.
404 The machine's memory essentially contains two banks of video RAM.
405 When bank 1 is being displayed, the CPU updates bank 2, and vice versa.
406 When the VBI comes, all that has to happen is, the video hardware is told
407 to display the other bank, and the CPU is likewise told to to update the
408 other bank, for the next frame.