FIGnition FUZE Application guide

FUZE Hardware Ref
Contents
Introduction!4
1 Overview!5
1.1 System Circuit Diagram!6
2. Keypad!7
2.1 Circuit Diagram!7
2.2 Operation!8
2.2.1 Reading the switches.!8
2.2.2 Ghost Keys!9
2.2.3 Debouncing the Keypad!10
2.2.4 Converting Single and Double Keypresses to Characters!11
3 Video!13
3.1 Circuit Diagram!13
3.2 Operation!13
3.2.1 Composite Video Basics!13
3.2.2 Video Circuit Basics!15
3.2.3 Video Firmware Details!16
3.2.4 Composite Video Details!18
3.2.6 Bitmapped Video Basics!19
4. Audio!22
4.1 Circuit Diagram!22
4.2 Operation!22
4.2.1 Circuit Details!22
4.2.2 Using Timer 0 To Generate Audio!27
4.2.3 Making It Easy With Pitch> .!28
4.2.4 Audio In!31
5. Storage!32
5.1 Circuit Diagram!32
5.2 Hardware Operation!32

5.2.1. Electrical Connections!32
5.2.2 The SPI Protocol!33
5.2.3 The Flash Chip Commands!34
5.3 Firmware Operation!35
5.3.1 Virtual Blocks!35
5.3.2 Purging!37
5.3.3 Virtual Table Purging!39
5.3.4 Conclusions!40
6. RAM!41
6.1 Circuit Diagram!41
6.2 Operation!41
6.2.1. Electrical Connections!41
6.2.2 The SPI Protocol!41
6.3 Firmware Operation!42
6.3.1 Locality!43
6.3.2 Pipelining!43
6.3.3 Branch Caching!44
6.3.4 Conclusions!45
7. USB!46
7.1 Circuit Diagram!46
7.2 Hardware Operation!46
7.3 Firmware Operation!48
7.3.1 AVR Flash Memory Organization!48
7.3.2 The Bootloader Key!48
7.3.3 Realtime Requirements!48
7.3.4 Chicken And Egg!49
7.3.5 Licensing!49
8. Microcontroller!50
8.1 Circuit Diagram!50
8.2 Operation!50
8.2.1 How FIGnition Uses Pins!50
8.2.2 AVR Block Diagram!52
8.2.3 FIGnition's Firmware Overview!53
9. Expanding FIGnition!58

9.1 Circuit Diagram!58
9.2 Operation!58
9.2.1 Controlling the LED!59
9.2.2 Default I/O!60
9.2.3 Reading Analog Channel 5.!60
9.2.4 I/O Trade-Off!63
9.3 Using SPI to talk to an Arduino!64
9.4 Using I2C to talk to a Maxim Digital To Analogue Converter.!66
9.5 Using I2C to talk to a Microchip I/O Expander!68
9.6 Using SPI to backup the external Flash.!70
Appendix A: Potential Dividers!73
Circuit Diagram!73
Operation!73
Detailed Explanation!75
Simulation!79
Code Description!80
Appendix B Diodes!82
B.1 Signal Diodes!82
B.2 Zener Diodes!83
Appendix C Capacitors!85
C.1 How Capacitors Work!85
C.2 Capacitors As Temporary Power Sources!86
C.3 De-coupling Capacitors!87
C.4 Capacitors As Audio Filters!87

Introduction
FIGnition FUZE's hardware contains the essentials of a true computer: a keypad for typing
programs and entering text; a power supply connector; it can output data to the user (via
video and audio); it runs programs from RAM; it has built-in storage for when the computer
is turned off; it has a CPU for running programs and a built-in program which manages all
these features and implements a fully-featured programming language (FIGnition Forth).
All true computers are like this; the only difference is the level of sophistication for each of
these parts. This manual takes you through the design and construction of every aspect of
FIGnition: bottom up from the components themselves to the way they interface to FIGni-
tion's processor chip to the code that manages each part.
FIGnition is a computer designed to be built, programmed and understood. The firmware is
fully open-sourced and the circuit is Open-Source Hardware compliant. This document
covers its operation with a view to understanding it, but it is not a substitute for an electron-
ics or programming course. For this you would find this additional material useful:
•An Electronics Tutorial.
•The User Guide for the AtMega168 and AtMega328.
•The FIGnition firmware source, which is on GitHub at: https://github.com/Snial/FIGnition
•The FIGnition programming Tutorial, Topics and Command Reference guides.

1 Overview
The FIGnition PCB contains 51 components connected by ground planes; power and sig-
nal traces. The signals wind their way across the PCB to the various building blocks as
shown on the left and as a block diagram on the right.
Flash
RAM
CPU
Video
Audio
USB
Keypad
These blocks are:
1. Keypad. The keypad allows you to type in programs; enter data and initiate a firmware
upgrade.
2. Video. The Video Phono outputs composite video to a TV.
3. Audio. The Audio Phono provides Audio In/Out.
4. Flash. The External Flash memory is where all your programs are stored when the
computer is switched off.
5. RAM. The external RAM chip is loaded with a program and the program runs from it.
6. USB. The connector is used to power a FIGnition and upgrade the firmware as FIGni-
tion is improved.
7. The AVR Microcontroller. The Avr Microcontroller is the 'brains' behind it all. It contains
an 8-bit processor for running internal firmware and the internal firmware implements a
built-in programming language and the code that manages the USB, Audio, Video,
Keypad, Storage and RAM.

8. Arduino Headers.
The block diagram tells you some basic information about the structure of the computer.
For example, the arrow between USB and CPU is two-headed, because data goes in both
directions. The arrow from the keypad is single-headed, because data only goes from the
keypad. RAM and Flash share a multi-head arrow, because data transfer is shared be-
tween them.
1.1 System Circuit Diagram
A circuit diagram for FIGnition represents a detailed, logical diagram of the computer, a
schematic; showing all components and their connections to every signal. Every section of
the FIGnition hardware reference starts with its part of the circuit diagram.
As you can see, components on the circuit schematic don't look like real-life. In addition
some of them aren't in the same places as on the PCB (e.g. USB isn't really in the middle
of the PCB) and this is done to make the logical relationships clearer. Finally, the keypad
looks like it's disconnected, but it's not really, instead each disconnected wire is labelled
and wherever else you see the same label the wire continues from there. For example,
/SWROW1 on the keypad also appears on the right-hand edge of the U1 rectangle, next to
the number 13 . This means the /SWROW1 connection on the keypad connects to pin 13 of
U1 (the CPU).

2. Keypad
The keypad uses 8 switches and 6 input ports on the AVR Microcontroller to implement a
switch-matrix keypad. Using individual keys and combinations of two keys pressed one
after the other a full set of letters, numbers and symbols can be typed.
2.1 Circuit Diagram
Fig 2.1
The visible part of the circuit includes only the switches, but inside the microcontroller, the
column signals are set up to connect to some 'pull-up' resistors which are connected to
VCC. PortC, bits 3 to 0 are always set up as inputs. PortB0 and PortD7 are normally set
up as inputs without pull-up resistors, and when we're actually reading keys either PortB0
or PortD7 (but never both together) are set up as outputs.
To understand how the switches themselves work you'll need to first understand Potential
Dividers (Appendix A).

!Fig 2.2a!Fig2.2b
In the opposite way that a small resistor is like a wire causing a tiny voltage to drop across
it; an open switch is like a nearly infinite resistor taking the place of R2; so R1 will pull a
PortC input up to very nearly 5v [Fig 2.2a]. But when the switch is pressed, it connects to
0v and so its PortC input would read as 0 [Fig 2.2b].
Fig 2.3
When either PortB0 or PortD7 is set as an input, it has an extremely high resistance com-
pared with a PortC 'pull-up' resistor causing its PortC input to read as a 1 even if the switch
is pressed [Fig 2.3].
2.2 Operation
Even for something as simple as the set of switches making up the keypad there are sev-
eral layers to its operation.
2.2.1 Reading the switches.
We can see from Fig 2.1, pressing a single switch will connect exactly one row signal to
one column input (for example, pressing SW1 will connect PortD7 to PortC0). In the initial
case (when keys aren't pressed), the voltage at every column input will be high, because
all the keys behave as in Fig 2.2.
If we set PortD7 to an output and make it output 0, then any pressed keys (on the top row)
will connect to 0v and will be read as 0s by PortC [Fig 2.4]

Fig 2.4
Here, SW5 and SW3 are the only keys pressed and because only SW3 is connected to 0v,
only PortC2 reads as 0.
SW5 is also pressed, but because PortB0 is set up as an input, it means the switch acts as
in Fig 2.3.
To read the bottom row, we set up PortD7 back to being an input and make PortB0 an out-
put, ouputting 0. This time SW3 has no effect on PortC inputs, but SW5 does, meaning
PortC3 to PortC0 will read 1110.
In the FiGnition firmware, the basic switch reading is handled by the 'C' function KeyScan-
Raw in the manner described here.
2.2.2 Ghost Keys
A switch-matrix keyboard can't read more than two keys at a time without getting con-
fused. Let's see what happens if we press SW1, SW3 and SW5. When the bottom row is
being read we can see that there is also a connection between PortC2 and PortB0, be-
cause PortC2 connects to SW3 which connects to SW1 which connects to PortC0. So it
looks like SW7 is also being pressed [Fig 2.5].

Fig 2.5
Normal computer keyboards suffer from the same problem. If I press any pair of keys (e.g.
'w' and 'n') then it will choose to display both and repeat one of them. However, if I press
(e.g 'e', 'd' and 'u') on my laptop simultaneously then the laptop recognizes that there could
be a ghost key and types nothing at all.
2.2.3 Debouncing the Keypad
In a simple circuit with a switch and a light-bulb, we press the switch, the light comes on
and we think that it's as simple as that. But to electronic circuits that operate at anything
above a few hundred Hz, a keypress appears to bounce several times before settling
down, as though you'd pressed it many times very quickly [Fig 2.6].

Approx 3ms
Fig 2.6
So, the job of a computer keyboard is to filter out all the key-bounce without missing any
keys you intended to press. The way FIGnition does it is entirely in software. It reads the
keypad 50 times per second and if it sees the same set of keys being pressed at least
twice, it concludes that the key presses have settled down. This works, because key
bounce is <20ms so the scanning won't catch it twice. Also, a human being can't (nor-
mally) press keys at over 25 key presses per second, nor press a key for less than 40ms
when typing - it would be equivalent to a typing rate of over 200 words per minute.
In the FIGnition firmware, debounce is handled by the 'C' function KeyScan. It simply com-
pares the previous keyscanning state with the new one and if they're the same, converts
the scan to a character.
2.2.4 Converting Single and Double Keypresses to Characters
On FIGnition key scanning doesn't directly generate characters, because we need to ana-
lyze pairs of keys in sequence. In fact there are quite a number of requirements for con-
verting characters:
•Recognizing which key has been pressed first, then second.
•Recognizing if a single key has been pressed for more than one second and displaying
the key layout prompt.
•Generating a repeat character if a pair of keys have been held down for 0.4s and 25
times per second thereafter. This provides a delay before keys repeat, and makes keys
repeat pretty quickly.
•Recognizing a key press, then a single key release followed by another key as another
keypress (you don't have to release both keys before pressing another key).
•Allowing the computer to execute code normally while all this is going on.

The challenge here is in allowing the computer to keep running in the background - this
means the keypad code doesn't run continually as soon as you press a key, but performs
a small amount of processing on every frame. We manage this all in firmware, by imple-
menting the keypad conversion process as a state machine.
A keypad state machine is actually (in FIGnition's case) just a byte variable (the state)
that's used to select which piece of code is executed on every scan (the machine). A state
machine is always one of several straight-line pieces of code that gets executed depend-
ing on the current state: it reads some inputs; sets a new state and perhaps performs a
minor action. State machines are useful for providing the appearance of a thread or task
with a far smaller overhead than for a normal operating system.
So, FIGnition's state machine (in the 'C' function IntKey) works like this:
KeyState
Released
KeyState
Single
First key pressed,
Help countdown
set to 16
KeyState
Double
No change and help
count-down>0: de-
crease help count-
down by 1.
(Help)
Key released,
generate single
Key character
All keys
released
No change and repeat
count-down>0: de-
crease repeat count-
down by 1.
No change and repeat
count-down=0: Generate
repeat character.
KeyState
SingleAfterDouble
One Key Re-
leased: Help
countdown
set to 16.
No change and help
count-down>0: de-
crease help count-
down by 1.
No change and help
count-down=0: acti-
vate help.
Second Key pressed.
Generate Key pair
character. Set Repeat
countdown to 10.
Fig 2.7
( Ovals represent the state; arrows show movement from one
state to another; text shows the condition required to move to
a different state, with the action in bold)

3 Video
Video support on FIGnition requires just 2 diodes, 2 resistors and a phono socket to pro-
vide PAL or NTSC monochrome video. It uses the internal serial port to output pixels; a
timer to generate TV synchronisation signals and another timer to manage the top and bot-
tom margins without CPU intervention. FIGnition is capable of a text-based video mode
(with 16 UDGs) and a fully bitmapped video mode using the external SRAM as video
memory.
3.1 Circuit Diagram
Fig 3.1
3.2 Operation
We'll start with the way a TV generates composite video; then look into how the circuit
generates the right signals for it. Then we'll look again in more depth and look into how the
AVR and video firmware provides video efficiently.
3.2.1 Composite Video Basics
Intuitively we may think TV receives video the way we see the outside world, that is, in the
same way countless beams of light from our surroundings continually hit our eyes, broad-
casters send countless (invisible) beams of light as TV signals to TVs. This is not true.
Instead TV uses a property of human vision called "persistence of vision". If you look a
bright scene, then snap your eyes shut, the scene will fade quickly, but not instantly. Video
uses this to create an illusion of movement by showing a rapid sequence of still images,
called frames, at least 25 per second. It makes use of the same principle to break down
each still image into hundreds of thousands, or millions of individual dots, which are dis-
played one at a time in the order we read books: a row of (perhaps thousands) of dots (of
different colours) in a line and repeated for hundreds or thousands of lines (called scans)
for each frame [Fig 3.2]. This is true for traditional 20th century TVs and the basic principle
is true for LCD TVs too.

625/2
scans
Scan period = 64µs
Visible period = 51.2µs
Fig 3.2
In operation TV stations convert the series of dots into radio waves and a TV converts
them back into a stream of dots. Composite video doesn't need to convert the stream of
dots. Instead, they are sent directly along a cable from the source (e.g. FIGnition) to the
TV. For PAL TV, every frame consists of 312.5 scan lines and every scan line is 64µs long
of which no more than 51.2µs can be used for dots.
In addition to the image itself, the signal needs to send information about when to start a
new frame and when to start a new scan. These are called Frame Sync and Horizontal
Synchronization signals [Fig 3.3].
Frame
Sync
HSync: 4.3µs
Fig 3.3
All this is controlled by a single signal at different voltages. A voltage between 0.3v and
1.0v is used to send a dot (0.3v is black and 1.0v is white); a voltage of 0v is a synchroni-
zation signal: a Horizontal sync is 0v held for 4.3µs and a Vertical sync is a special pattern
of 0v and 0.3v signals over a 480µs period [Fig 3.4].

Fig 3.4
3.2.2 Video Circuit Basics
To generate video, FIGnition must be able to produce three voltages: a 0v Synchronisation
voltage, a 0.3v voltage for black and a 1.0v voltage for white. It does this using two diodes
and two resistors.
The synchronisation voltage is easy, when PD1 and PD3 output 0v, a 0v synchronisa-
tion voltage will appear on the output.
Black is next. To output black PD3 (Sync) outputs a 1 and PD1 outputs a 0. The diode on
PD3 lowers the voltage by 0.7v (taking it to 4.3v) and then the 1KΩand 75Ωresistors act
as a potential divider (see Appendix A). The voltage on the potential divider will be:
4.3x75/(1000+75) = 0.3v.
But what about the 470Ωresistor - doesn't it affect the circuit? In this case, no. Because
the voltage at the junction of R5 and R6 is greater than the 0v voltage at PD1, the diode is
reversed biased and acts as a large resistance. This means no current flows [Fig 3.5].

Fig 3.5
White is the most complex. To output white, PD3 (Sync) and PD1 both output a 1. The
diode on PD3 and PD1 both lower their voltage by 0.7v (taking their output voltage to
4.3v). Then, because the 1KΩand 470Ωresistors are in parallel, they have a combined
resistance of 1/(1/1000+1/470) = 320Ω.
Finally, this combined resistance and the 75Ωresistor acts as a potential divider generat-
ing an output voltage of: 4.3x75/(320+75) = 0.817v; which is close to 1v.
This means 'white' on FIGnition is only 75% as bright as it could be. The ideal resistor
would be 328.9Ωinstead of 470Ω, but I chose 470Ω, because it is much easier to get hold
of than a 330Ωresistor (which is the closest normal resistor to 470Ω).
3.2.3 Video Firmware Details
A text-mode FIGnition image consists of 25 characters x 24 characters on the screen and
each character has 8 rows of 8 pixels. This means the firmware must generate 200 pixels
across and generate an image of 192 scans.
Generating A Frame. We can see there are 192 scans that contain an image, but 312.5
scans in a frame. The first 7.5 scans of a Frame are the vertical sync. Then there is a top
margin of 56 scans, which are just blank. Then there are 192 image scans and finally there
are another 56 scans for the bottom margin. FIGnition handles this using another state
machine (See section 2.2.4 for an introduction to state machines), which it runs through in
a simple sequence. It uses 4 states to manage the vertical sync, then a state for the top
margin, two states per image scan line and finally one more state for the bottom margin
[Fig 3.6].

Vertical Sync:
PreEqualize
Equalize
LastEqualize
PostEqualize
If ScanLine>0,
Timer1 Int in 55µs
TopMargin
ScanLine
ScanGen
Dec ScanLine, Gen-
erate Scan.
BotMargin
Timer2 set to 4.5µs pulse over
64µs. Timer1 Int in 56*64µs.
ScanLine=192
Timer2:=2µs pulse over 32µs,
Timer 1Int in 5*32µs.
Timer1 Int in 9µs. Sleep
until Int (for exact timing)
If ScanLine=0,
Timer1 Int in 55µs
Timer1 Int
in 56*64µs
Fig 3.6
Each state begins with an interrupt that causes a short section of code to run at a precise
moment in time, a number of 400 nanosecond periods after the current state. The top and
bottom margin states simply set the time when the next state should start. The vertical
sync states change the width of the synchronisation pulses to match the pattern the TV
expects. The image scan states generate the actual image.
Generating Synchronisation Signals. FIGnition uses some built-in hardware called a
timer (Timer 2) to automatically generate synchronisation signals. During initialisation,
Timer 2 is set to tick at 2.5MHz, which is the 20MHz crystal frequency / 8 and set to oper-
ate in a Pulse Width Modulation mode, which keeps looping forever with a given timing pe-
riod and a pulse width. The timer's timing period is set to the length of a 64µs scan line x
2.5MHz; which is 160 ticks and the pulse width is set to 4.8µs (12 ticks). The pulse is in-
verted so that the pulse is low (0v) and the rest of the period is high (5v).
Generating An Image Scan. A scan line is 64µs and 51.2µs can be used for dots. To out-
put the dots we use the AVR's serial port in SPI mode and set the frequency to a conven-
ient value of 20MHz/4 = 5MHz. The 200 dots on the screen then take up 40µs. To make
each line of dots as central as possible we add a margin of (64-4.8-40)/2 = 9.6µs before
we start displaying them [Fig 3.7, Lower half]. The code for generating an image scan line
is written in assembler; you can find it in the routine VideoScan in the file VideoScan.s.

Fig 3.7
Generating A Text Screen. FIGnition FUZE uses 25x24 = 600 bytes of internal RAM for
display memory, and each byte contains a character not a bit pattern. The bit patterns are
stored in the AVR's internal Flash memory starting at the location kChrSet. There are 8
bit-pattern bytes per character. To display each bit pattern the firmware looks up the char-
acter code byte in video memory according to the current row and column; then looks up
the bit pattern at kChrSet+8*TheCharacterCode+(ScanLine mod 8). If the charac-
ter code was <16, then it looks up the bit pattern from the UDG memory. If bit 7 of the
character code was set, the bit pattern is inverted [Fig 3.7, top half]. After all this, the bit
pattern is sent to the serial port, by storing the bit pattern at location $C6.
3.2.4 Composite Video Details
Each scan line is almost as simple as described earlier except that after the HSync pulse
there is a 4µs gap for what is called the colour burst, which FIGnition ignores.
Vertical sync however, is complex; complex enough for most websites to get it wrong. Fig
3.4 shows the true standard for PAL Vertical Sync; shown as a single sequence from the
end of one frame to the beginning of the next for even frames.
Vertical Sync is composed of 15 x 32µs periods. The First 5 contain 2µs pulses in each
32µs period. The next 5 contain 30µs pulses in each 32µs period and finally the last 5 con-
tain 2µs pulses in each 32µs period.
This description of composite video provides 312.5 scan lines at 50Hz, but a full imple-
mentation of the PAL video standard provides 625 lines at 25Hz. It does this using a tech-
nique called 'interlacing'. The video is divided into odd and even frames; and the scan lines
of the even frames are shown between those of the odd frames. To distinguish the two, the

VSync part of a frame is slightly different for even frames. Since FIGnition doesn't use in-
terlacing, we won't cover it any further here.
NTSC Video. FIGnition is capable of displaying NTSC video using slightly different firm-
ware. NTSC video is used in the US, Canada and parts of South America and provides
525 lines each of 63.9µs. This means there are 14 x 31.95µs periods in the VSync portion
leaving 31 scans for the top margin and 32 scans for the bottom margin.
3.2.6 Bitmapped Video Basics
The Bitmapped video and Blitter (Sprite Engine) are covered in more detail in the Firm-
ware Reference, but some of the basics are worth covering here.
Bandwidth. After FIGnition was designed it was discovered that the serial SRAM could be
read fast enough to generate a full bitmapped image on a TV. The Serial SRAM is read at
10MHz and requires 9 bit times to read each byte. Therefore in a single 64µs video scan
we can (in theory) read up to 64µs x 10MHz / 9CyclesPerByte = A theoretical maximum of
71 bytes. Video data is pumped out of the USART at 5MHz for 40µs requiring only 25
bytes per scan. Therefore we can copy bitmapped data from the serial SRAM to the
USART quickly enough. A 160x160 bitmapped image was chosen (using 3200 bytes) to
leave adequate room for programs from a FIGnition's standard 8Kb of SRAM.
Interrupting SRAM. FIGnition uses the serial SRAM to execute Forth programs. To read a
bitmapped video image from the SRAM means interrupting its use for reading programs
and then restoring it at the end. However, it's not possible to read the current SRAM ad-
dress from the chip and it's not practical to analyze the firmware to work out which address
was last read or written.
The solution is to only use the SRAM for video when the SRAM gets deselected, which
happens every time a Forth program jumps to a different location; reads or writes a vari-
able or executes a Forth command1in ROM. When the SRAM is deselected, PortB1 goes
high and because it's possible to automatically generate an interrupt when a port pin
changes (Chapter 13 of AtMega328 User Manual) it's possible to notify the AVR when the
SRAM is free to be used to generate bitmapped video.
Bitmapped Image Format. The goal for the bitmapped video mode is to enable sprites
and bitmap images to be copied quickly to the screen. If the bitmapped video memory was
organised in the same way as a TV image, scan line by scan line [Fig 3.8], then copying,
for example an 8x8 image would require writing at least 8x3 = 24 command bytes + 8 data
bytes to SRAM = 32 in total. However, by organising the bitmapped video memory as 8x8
bit tiles then the same example would require writing as little as 3 command bytes + 8 data
bytes = 11 in total, about 3x faster2[Fig 3.9].
1FIGnition Forth executes byte codes (which are byte values in the range 0 to 79) and compiled commands
which are two-byte addresses in ROM or RAM.
2The worst case for a scan line order would be 24 command bytes + 16 data bytes = 40 if the 8x8 images
weren't aligned and 30b for the tiled version (2x3 = 6 command bytes + 24 data bytes).

Fig 3.8
Fig 3.9
SRAM Buffering. A consequence of using a tiled video image format is that it must be
read in and converted to scan lines for the TV and this means 16 scans of SRAM must be
buffered in internal RAM. That's because the end of the first scan line in a row of tiles will
require reading in the last tile in the row, so all the tiles must be read in first. Similarly, the
generating the last scan line in a row of tiles requires all the tiles in the row to be kept in
internal RAM and therefore the next row of tiles will need to be read into internal RAM
ready for the following scan [Fig 3.10].
Fig 3.10