1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
# Graphics
Even though the STM32 is a relatively powerful microcontroller, it will likely
not be fast enough for running game logic, sound logic and a graphics processor
on it's single CPU core. To minimize the risk of overloading the STM32
processor, all graphics processing and compositing will be outsourced to a
custom PPU implemented on the Basys 3 FPGA.
Because we're creating a sidescrolling 2D platformer, we don't need a very
complicated graphics processor. We also lack any knowledge about how
'real-world' graphics processors work, so we're basing our design on a product
closest to our target result, the NES.
## NES graphics
The NES has a separate coprocessor chip designed to generate video signals
called the RP2C02, which is manufactured by Ricoh. This chip has a lot of
features, some of which we don't need for our game. Here's a quick rundown of
this chip's features and limitations:
- composite output at 256x224 @ 60Hz (NTSC) or 256x240 @ 50Hz (PAL)
- 256 tiles per tilemap (with 8x8 tiles)
- 2 tilemaps (pattern tables)
- 4 palettes per sprite with 64 possible colors
- 512x480 background canvas with scrolling
- background scrolling splits
- 64 total sprites on screen (max 8 per scanline)
- sprites can be drawn before or after the background layer
- PPU control using DMA
- 8K character memory (tilemaps)
- 2K nametable memory (OAM for background tiles)
- 256B object attribute memory (OAM)
- tiles can be flipped using OAM
- no frame buffer
### Usage
The NES PPU has a lot of capabilities, so here's a quick run-down of how the
PPU is used by games to produce pictures.
On boot, the NES copies the contents of the so-called CHR-ROM (in game
cartridge) into the PPU's pattern tables. The NES has two 256-tile tilemaps
called the pattern tables which store all sprites in the game. By modifying the
nametable memory directly, the game can control which tile, and which palette
will be used for any given tile on the background layer. Because the background
layer only displays tiles in a fixed grid, the nametable memory area is not
very big.
The same process happens for the foreground sprites, though these can each be
positioned using screen coordinates, and don't have to conform to any grid. The
NES also has some limitations on how many sprites can be drawn and how many
palettes can be used. An important note is that the first color of any palette
used on any foreground sprite, is treated as the transparency color. Our PPU
also copies this behavior.
The following is a small section of pseudocode, depicting a program that will
display a triangle moving in a circle:
```c
unsigned frame = 0;
void setup() {
// copy character rom to PPU
memcpy(CHR, PPU->CHR, 0x8000);
// character rom contains a sprite of a triangle at index 0
// set palette index 0 to have 4 random colors
PAL[0] = (palette) {
PALETTE_COLOR_25,
PALETTE_COLOR_F3,
PALETTE_COLOR_00,
PALETTE_COLOR_3D,
};
// copy palette data to PPU
memcpy(PAL, PPU->PAL, 0x40);
}
void loop() {
frame++; // increment frame counter
OAM[0] = (sprite) {
.x = sin(frame) * 20 + 10, // calculate circle position using frame counter
.y = cos(frame) * 20 + 10, // calculate circle position using frame counter
.pattern_index = 0, // triangle sprite
.palette_index = 0, // palette 0 (see setup)
.attributes = PPU_FX_FLIP_H | PPU_FX_FLIP_V, // flip horizontally and vertically
};
memcpy(OAM, PPU->OAM, 0x100); // update PPU with local copy of OAM
}
int main() {
setup();
while(1) loop();
}
```
## Custom PPU
Here's a list of features our PPU should have:
<!-- TODO: expand list with PPU spreadsheet -->
- 256x224 @ 60Hz VGA output
- single tilemap with room for 1024 tiles of 16x16 pixels
- 8 colors per palette, with 4096 possible colors (12-bit color depth)
- 512x448 background canvas with scrolling
- NO background scrolling splits
- 128 total sprites on screen (NO scanline sprite limit)
- sprites are always drawn on top of the background layer
- PPU control using DMA (dual-port asynchronous RAM)
- tiles can be flipped using FAM or BAM
- no frame buffer
- vertical and horizontal sync output
Notable differences:
- NES nametable equivalent is called BAM (background attribute register)
- NES OAM equivalent is called FAM (foreground attribute register)
- No scanline sprite limit
Unless not imposing any sprite limit makes the hardware implementation
impossible, or much more difficult, this is a restriction that will likely
lead to frustrating debugging sessions, so will not be replicated in our
custom PPU.
- Sprites are 16x16
Most NES games already tile multiple 8x8 tiles together into "metatiles" to
create the illusion of larger sprites. This was likely done to save on memory
costs as RAM was expensive in the '80s, but since we're running on an FPGA
cost is irrelevant.
- Single 1024 sprite tilemap shared between foreground and background sprites
The NES OAM registers contain a bit to select which tilemap to use (of two),
which effectively expands each tile's index address by one byte. Instead of
creating the illusion of two separate memory areas for tiles, having one
large tilemap seems like a more sensible solution to indexed tiles.
- 8 total palettes, with 8 colors each
More colors is better. Increasing the total palette count is a very memory
intensive operation, while increaing the palette color count is likely slower
when looking up color values for each pixel on real hardware.
- Sprites can be positioned paritally off-screen on all screen edges using only
the offset bits in the FAM register
The NES has a separate PPUMASK register to control special color effects, and
to shift sprites off the left and top screen edges, as the sprite offsets
count from 0. Our PPU's FAM sprite offset bits count from -15, so the sprite
can shift past the top and left screen edges, as well as the standard bottom
and right edges.
- No status line register, only V-sync and H-sync outputs are supplied back to
CPU
The NES status line register contains some handy lines, such as a buggy
status line for reaching the max sprite count per scanline, and a status line
for detecting collisions between background and foreground sprites. Our PPU
doesn't have a scanline limit, and all hitbox detection is done in software.
Software hacks involving swapping tiles during a screen draw cycle can still
be achieved by counting the V-sync and H-sync pulses using interrupts.
- No background scrolling splits
This feature allows only part of the background canvas to be scrolled, while
another portion stays still. This was used to draw HUD elements on the
background layer for displaying things like health bars or score counters.
Since we are working with a higher foreground sprite limit, we'll use regular
foreground sprites to display HUD elements.
- Sprites are always drawn on top of the background layer
Our game doesn't need this capability for any visual effects. Leaving this
feature out will lead to a simpler hardware design
### Hardware design schematics
[nesppuspecs]: https://www.copetti.org/writings/consoles/nes/
[nesppudocs]: https://www.nesdev.org/wiki/PPU_programmer_reference
[nesppupinout]: https://www.nesdev.org/wiki/PPU_pinout
[custompputimings]: https://docs.google.com/spreadsheets/d/1MU6K4c4PtMR_JXIpc3I0ZJdLZNnoFO7G2P3olCz6LSc/edit?usp=sharing
# Generating audio signals
In order to generate sound for this project, a few posibilities exist (see chapters below)
## Sound chips
A sound chip is made to use digital, analog or mixed signals and produce a tone or sound based on that.
| Manufacturer | Chip | Year | Channels | Stand-alone | Cost/availability |
| ------------------ | ------------------------------------------------------------------------------------------------------------- | ---- | -------- | ----------- | ----------------- |
| Atari, Inc. | [POKEY](https://en.wikipedia.org/wiki/POKEY) | 1979 | 4 | Somewhat | N/A |
| General Instrument | [AY-3-8910](https://en.wikipedia.org/wiki/AY-3-8910) | 1978 | 3 | Yes | N/A |
| General Instrument | [SP0250](https://en.wikipedia.org/wiki/General_Instrument_SP0256) | 1981 | 1 | Yes | N/A |
| Konami | [VRC6](https://en.wikipedia.org/wiki/VRC6) | 1987 | 3 | Yes | N/A |
| Philips | [Philips SAA1099](https://en.wikipedia.org/wiki/Philips_SAA1099 "Philips SAA1099") | 1984 | 6 | Yes | N/A |
| Sunsoft 5B | [Sunsoft 5B](https://en.wikipedia.org/wiki/Memory_management_controller#FME-7 "Memory management controller") | 1992 | 3 | Yes? | N/A |
| Texas Instruments | [SN76477](https://en.wikipedia.org/wiki/SN76477) | 1978 | 1 | Yes | N/A |
| Texas Instruments | [SN76489](https://en.wikipedia.org/wiki/SN76489 "SN76489") | 1980 | 4 | Yes | N/A |
| Texas Instruments | [Sega PSG (SN76496)](https://en.wikipedia.org/wiki/SN76496 "SN76496") | 1982 | 4 | Yes | N/A |
This chart shows different audio chips that might have been used in retro consoles. While all of them aren't easily available anymore it is still interesting to take a close look at how these IC's (Intergrated Ciruit) work.
Most chips work on one of two pricibles, this being either a "Programmable sound generator" or "Sound Chip"
### Programmable sound generator (PSG)
PSG's are a subset of sound chips that generate sound based on a set of pre programmed tones they can generate. For example, this can be done by: modulating a input square wave to a different frequency and or amplitude.
### Pulse-code modulation
Pulse-code modulation uses pre-sampled data to generate sounds. This causes a lot more work for the engineer before gaining a working system. The flip side of that coin is that the Output can be of a better quality (depending on the sampled audio used).
## FPGA Circuit
|