More modifications
Signed-off-by: Tyrolyean <tyrolyean@tyrolyean.net>
This commit is contained in:
parent
6d09e50327
commit
28abbf430e
7 changed files with 97 additions and 111 deletions
|
|
@ -1 +0,0 @@
|
|||
\def \tikzexternallocked {0}
|
||||
BIN
main.pdf
(Stored with Git LFS)
BIN
main.pdf
(Stored with Git LFS)
Binary file not shown.
|
|
@ -123,8 +123,9 @@ MAX-232 as the C1 has to the 16550-UART.
|
|||
\subsubsection{Demonstration Software}
|
||||
|
||||
To demonstrate the functionality and prove that the schematic has no underlying
|
||||
error, a program which regularly transmits a character was written as well as
|
||||
a simple echo program, which transmits all received characters. Both programs
|
||||
error, a program which regularly transmits a character as well as
|
||||
a simple echo program, which transmits all received characters are used.
|
||||
Both programs
|
||||
transmit 8 bit characters without parity at 38400 Baud. The output for program
|
||||
one can be seen in Figure \ref{fig:uart232} and the output for program two in
|
||||
Figure \ref{fig:232_echo}.
|
||||
|
|
@ -150,7 +151,7 @@ Figure \ref{fig:232_echo}.
|
|||
|
||||
\paragraph{Transmit code}
|
||||
The transmit code regularly transmits the letter capital A via the 16550 UART.
|
||||
Before it can do this it needs to perform some initialisations. The
|
||||
Some initialisation is required beforehand. The
|
||||
functions shown in Listing \ref{lst:16550-general} are the read and write
|
||||
routines for accessing the 16550 UART. These routines also apply to the echo
|
||||
code.
|
||||
|
|
@ -189,8 +190,8 @@ SOUT lane of the 16550 UART can be seen in Figure \ref{fig:16550A}
|
|||
The echo code permanently polls the 16550 UART wether a character has been
|
||||
received, and if yes, reads it from the receiver holding register and writes it
|
||||
back to the tx holding register. The output of this code can be seen in Figure
|
||||
\ref{fig:232_echo}. The initialisation is practically the same as for the
|
||||
transmission code, as well as the read and write routines in Listing
|
||||
\ref{fig:232_echo}. The initialisation is practically the same for the
|
||||
echo code as well as the read and write routines in Listing
|
||||
\ref{lst:16550-general}.
|
||||
|
||||
\lstinputlisting[language=C,frame=trBL,
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
\subsection{Audio Digital-Analog-Converter}
|
||||
|
||||
A digital to analog converter takes a digital number and converts it to a
|
||||
analog signal. The output of one such conversion is called a sample. With
|
||||
analog signal. The output of such a conversion is called a sample. With
|
||||
enough samples per second various different waveforms can be produced, which,
|
||||
when amplified and put onto a speaker, can be heared by the human ear as a tone.
|
||||
With various tones in series a melody can be produced, which is what the DAC in
|
||||
|
|
@ -10,15 +10,16 @@ this implementation does.
|
|||
\subsubsection{TLC 7528 Dual R2R Ladder DAC}
|
||||
|
||||
The TLC 7528 is a Dual output parallel input R2R Ladder DAC with a maximum
|
||||
sample rate of 10MHz \cite{tlc7528}, and which (should be) is monotonic over the
|
||||
entire D/A Conversion Range. The TLC-7528 was the only component chosen, where
|
||||
availability was not a factor, but rather it's design. It is the cheapest
|
||||
dual R2R Ladder dac which takes \textbf{PARALLEL} input, which is an important
|
||||
sample rate of 10MHz \cite{tlc7528}, and which (should be
|
||||
\footnote{See Figure \ref{fig:tlc7528_saw_nonlin}}) is monotonic over the
|
||||
entire D/A Conversion Range. The TLC-7528 is the only component chosen, where
|
||||
availability is not a factor, but rather it's design. It is the cheapest
|
||||
dual R2R Ladder DAC which takes \textbf{PARALLEL} input, which is an important
|
||||
feature, because the backbone of the project is its parallel bus. Further the
|
||||
DAC was developed for audio aplications\cite{tlc7528} which made its use obvious
|
||||
and the TLC-7528 was the only IC available as DIP
|
||||
DAC was developed for audio aplications\cite{tlc7528}, which made its use
|
||||
obvious. The TLC-7528 was the only IC available as DIP
|
||||
\footnote{DIP... Dual Inline Package}, of which the pinout can be seen in Figure
|
||||
\ref{fig:tlc7528_pinout}
|
||||
\ref{fig:tlc7528_pinout}.
|
||||
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
|
|
@ -29,7 +30,7 @@ and the TLC-7528 was the only IC available as DIP
|
|||
|
||||
\subsubsection{IDT7201 CMOS FIFO Buffer}
|
||||
|
||||
The IDT7201 is an asychronous CMOS FIFO, which means that it can be read with
|
||||
The IDT7201 is an asychronous CMOS FIFO. That means, that it can be read with
|
||||
a completely independant speed from which it is written and vice versa. It has
|
||||
9 bit words, which can be seen in Figure \ref{fig:idt7201_pinout}, and can
|
||||
store up to 256 words\cite{idt7201}. It is used as a buffer
|
||||
|
|
@ -102,7 +103,7 @@ Based on the descriptions in the datasheets the schematic in figure
|
|||
|
||||
Diodes D1 through D4 are used as OR-Gates in conjunction with R1 and R2 to
|
||||
generate the $\lnot MODRD$ and $\lnot MODWR$ signals for the D Flip-Flop
|
||||
\footnote{74HC374\cite{74hc374}} and FIFO respectively, by these formulas:
|
||||
\footnote{74HC374\cite{74hc374}} and FIFO respectively by these formulas:
|
||||
|
||||
$\lnot MODRD = \lnot RD \lor \lnot MS2$
|
||||
|
||||
|
|
@ -111,22 +112,23 @@ $\lnot MODWR = \lnot WR \lor \lnot MS2$
|
|||
On a read access the output enable of the D-Latch becomes low, which writes
|
||||
the status bits of the FIFO onto the data bus. C1, C2 and C3 are for stability
|
||||
reasons and are good practice similar to the UART module. 74HC00 is a quad
|
||||
NAND-Gate\cite{74hc00} which is only used for inversion, chosen, like the
|
||||
NAND-Gate\cite{74hc00}, which is only used for inversion, chosen, like the
|
||||
74HC374, for availability reasons. The A part of the NAND-Gate inverts the $MR$
|
||||
signal from the bus to a $\lnot MR$ signal, as the FIFOs reset is low active.
|
||||
The B part of the NAND-Gate inverts the FIFO Empty flag. It's output is
|
||||
connected to the $\lnot WR$ input of the DAC, which means that the DAC doesn't
|
||||
connected to the $\lnot WR$ input of the DAC, which means, that the DAC doesn't
|
||||
convert the input anymore, if the FIFO Empty flag is set to low.
|
||||
|
||||
The NE555 generates the audio clock signal, which should be the double of
|
||||
44.1kHz\footnote{Because we have 2 output channels} as 44.1kHz is the standard
|
||||
samling rate of CD-Audio\cite{iec60908}. Resistors R9 and R10 togehter with C7
|
||||
44.1kHz\footnote{Because we have 2 output channels}, as 44.1kHz is the standard
|
||||
samling rate of CD-Audio\cite{iec60908} and 2 channels need to be sampled.
|
||||
Resistors R9 and R10 togehter with C7
|
||||
form the Oscillator part of the NE55. C4 is for stability reasons and doesn't
|
||||
define the frequency of the oscillator.
|
||||
|
||||
The generated clock is used for the $\lnot RD$ of the FIFO and inverted on the
|
||||
DAC, which makes the data available on the output before being stored into the
|
||||
DAC as it receives the signal to store the data after the FIFO makes it
|
||||
DAC, as it receives the signal to store the data, after the FIFO makes it
|
||||
available on the bus.
|
||||
|
||||
The DAC is operated in voltage mode, as described in Figure \ref{fig:tlc7528_volt},
|
||||
|
|
@ -142,7 +144,7 @@ $f_C = \frac{1}{2\pi R C} = \frac{1}{2\times \pi\times 10K\Omega\times 100\mu F
|
|||
|
||||
which should cover the hearable spectrum. The high pass was needed to generate
|
||||
a positive and negative half of the wave form, as the DC-Offset with a frequency
|
||||
of 0Hz is orders of magnitudes lower than the $f_C$ of the highpass gets
|
||||
of 0Hz is orders of magnitudes lower, than the $f_C$ of the highpass gets
|
||||
filtered away.
|
||||
|
||||
R7 and R8 have been installed in order to unload the capacitors after device
|
||||
|
|
@ -303,7 +305,7 @@ The look-up table has a size of 256, which is the maximum value an 8 bit integer
|
|||
can take. This size was chosen to make operation faster as it only takes
|
||||
one cycle to load an array value into a register and another one to store it
|
||||
into the GPIO register. The sine table in further examples was pre-genrated on
|
||||
the compiling host to reduce startup time. The mothod shown in listing
|
||||
the compiling host to reduce startup time. The method shown in listing
|
||||
\ref{lst:dac_sine_lut} is not fast due to the lack of a floating point unit
|
||||
on the AVR. \cite{atmega2560}
|
||||
|
||||
|
|
@ -344,12 +346,12 @@ on the AVR. \cite{atmega2560}
|
|||
|
||||
\subsubsection{Addressing DACA and DACB}
|
||||
|
||||
The DAC used has 2 output channels which can be selected by the
|
||||
The DAC used has 2 output channels, which can be selected by the
|
||||
$\lnot DACA/DACB$ pin as seen in figure \ref{fig:tlc7528_pinout}. This pin was
|
||||
mapped to bit 0 of the address bus in order to make use of it. Bit 8 on the fifo
|
||||
was used to store the bit. It was not implemented with half the bus clock to
|
||||
was used to store the bit. It is not implemented with half the bus clock to
|
||||
make both channels independent of each other. This however uses more time on the
|
||||
backend because it means the fifo is used up at twice the speed. No current
|
||||
backend because it means the FIFO is used up at twice the speed. No current
|
||||
example makes use of this, but it may be used in future examples and
|
||||
implementations on this unit.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,14 @@
|
|||
\subsection{FPGA to Hardware interface}
|
||||
|
||||
To make the Hardware work with the FPGA's 3.3V I/O, level shifter have been
|
||||
installed and a FPGA module was built. This module maps the IO/Pins in a similar
|
||||
installed, and a FPGA module was built. This module maps the I/O Pins in a
|
||||
similar
|
||||
way to the ATMega 2560 used in examples before. The bidirectional 5V<->3.3V
|
||||
logic level converters have been obtained on amazon, and have not been well
|
||||
documented. Their functionality has been tested and verified in both directions,
|
||||
logic level converters have been obtained on amazon, and are not well
|
||||
documented. Their functionality is tested and verified in both directions,
|
||||
which can be seen in figures \ref{fig:3v35v} and \ref{fig:5v3v3}. The schematic
|
||||
has also been determined through measurements with a multimeter and the
|
||||
schematic in figure \ref{fig:schem_lvlshift} shows similar resistor values in
|
||||
was determined through measurements with a multimeter, and the
|
||||
schematic in Figure \ref{fig:schem_lvlshift} shows similar resistor values in
|
||||
the same configuration \cite{lvlshift}.
|
||||
|
||||
\begin{figure}[H]
|
||||
|
|
@ -31,8 +32,8 @@ the same configuration \cite{lvlshift}.
|
|||
\label{fig:3v35v}
|
||||
\end{figure}
|
||||
|
||||
The in figure \ref{fig:3v35v} shown output on the HV side, corresponds with the
|
||||
schematics in figure \ref{fig:schem_lvlshift} where it can be seen that the
|
||||
The in Figure \ref{fig:3v35v} shown output on the HV side corresponds with the
|
||||
schematics in Figure \ref{fig:schem_lvlshift}, where one can see, that the
|
||||
resistor R2 is loading the bus capacitance to a 5V high state.
|
||||
|
||||
\begin{figure}[H]
|
||||
|
|
@ -67,7 +68,7 @@ resistor R2 is loading the bus capacitance to a 5V high state.
|
|||
|
||||
During an attempt to measure wether the level shifters in the final module were
|
||||
working, a measurement between the LV and the HV side showed only a difference
|
||||
of 0.7V. After some troubleshooting, it was found that the Analog Discovery has
|
||||
of 0.7V. After some troubleshooting, it was found, that the Analog Discovery has
|
||||
clamping diodes against the 3.3V rail shown in figure \ref{fig:ad2_diode}. These
|
||||
diodes produce the 0.7V offset and prevent the parallel bus from rising to
|
||||
5V when a digial I/O pin of the Analog Discovery 2 is connected to the bus.
|
||||
|
|
|
|||
|
|
@ -9,11 +9,12 @@ one developed.
|
|||
|
||||
\subsubsection{General definitions and pinout of the AVR}
|
||||
|
||||
Like the before examples, the textadventure was implemented on an ATMega2560
|
||||
Like the examples seen before, the textadventure was implemented on an
|
||||
ATMega2560
|
||||
and uses 3 different Registers for transmission: PORTF, PORTK and PORTL for
|
||||
address bus, data bus and control bus respectively, as can be seen in listing
|
||||
\ref{lst:textadv-avr.h}
|
||||
\newpage
|
||||
|
||||
\lstinputlisting[language=C,frame=trBL,
|
||||
breaklines=true, breakautoindent=true, formfeed=\newpage,
|
||||
label={lst:textadv-avr.h}, caption={The avr.h header file},
|
||||
|
|
@ -25,8 +26,9 @@ RD_SHIFT, CS_UART_SHIFT and CS_DAC_SHIFT are used to indicate the position of
|
|||
the corresponding control lines inside the control bus register. All other
|
||||
shift values are the same bitordering in input as in output.
|
||||
|
||||
The BUS_HOLD_US is used to tell the avr how many microseconds it takes for the
|
||||
data bus to be latched into input register of the devices on write or how long
|
||||
The macro BUS_HOLD_US is used to tell the AVR how many microseconds it takes for
|
||||
the
|
||||
data bus to be latched into input register of the devices on write, or how long
|
||||
it takes for the data bus to become stable on read. A delay of less than 1
|
||||
microsecond is not possible due to limitations of the AVR and the bus capacity,
|
||||
which increases the BER\footnote{BER...Bit Error Ratio} to a level which effects
|
||||
|
|
@ -48,7 +50,7 @@ respective modules for updates as can be seen in listings
|
|||
\ref{lst:textadv-routine-uart} and \ref{lst:textadv-routine-dac}. When a
|
||||
character is received, it is stored inside a bufer array and regular operation
|
||||
continues. If the $\lnot EF$ status bit is set in a read from the dac, the
|
||||
feed\_dac function is called which stores 256 bytes into the DAC and regular
|
||||
feed\_dac function is called, which stores 256 bytes into the DAC, and regular
|
||||
operation continues.
|
||||
|
||||
\lstinputlisting[language=C,frame=trBL,
|
||||
|
|
@ -72,9 +74,9 @@ operation continues.
|
|||
\subsubsection{Program execution path}
|
||||
|
||||
On microprocessors it is required to not leave a return path for programs, as
|
||||
a return path would lead to the microcontroller either resetting, or seicing to
|
||||
a return path would lead to the microcontroller either resetting or seicing to
|
||||
work until the next power cut. Therefore the program performs all it's tasks in
|
||||
an infinte loop. This loop can be seen in listing \ref{lst:textadv-routine} and
|
||||
an infinite loop. This loop can be seen in listing \ref{lst:textadv-routine} and
|
||||
in figure \ref{fig:textadv_pexfl}.
|
||||
|
||||
\begin{figure}[H]
|
||||
|
|
@ -92,15 +94,15 @@ The DAC can produce any waveform described by 8 bit unsigned PCM code. Though
|
|||
possible to feed predefined waveforms into the DAC, the AVR doesn't have enough
|
||||
onboard memory to store more than a few seconds of these waveforms.
|
||||
|
||||
For example to store one second of 8 bit unsigned PCM Code at 2 times 44.1KHz
|
||||
sampling rate of the DAC, the AVR would have to store
|
||||
For exampl: To store one second of 8 bit unsigned PCM Code at 2 times 44.1KHz
|
||||
sampling rate of the DAC the AVR would have to store
|
||||
$s = 2 \times 44100\frac{Bytes}{s}*1s = 2\times 44100 Bytes = 88.2KB$, but it
|
||||
has only a total of 256KB of onboard flash\cite{atmega2560} which makes for a
|
||||
has only a total of 256KB of onboard flash\cite{atmega2560} which results in a
|
||||
total track lengh of $ t = \frac{256KB}{88.2\frac{KB}{s}} = 2.9s$ with only
|
||||
one track.
|
||||
|
||||
Therefore the AVR generates the audio on runtime. To do that it has 6 builtin
|
||||
modes in which it can run, as can be seen in listing
|
||||
Therefore the AVR generates the audio during runtime. In order to do that it has
|
||||
6 modes in which it can operate, as can be seen in Listing
|
||||
\ref{lst:textadv-dac-modes}:
|
||||
|
||||
\begin{enumerate}
|
||||
|
|
@ -129,7 +131,7 @@ To perform these tasks the DAC takes two parameters, again seen in listing
|
|||
\ref{lst:textadv-dac-modes}:
|
||||
\begin{itemize}
|
||||
\item{A frequency deviation:}
|
||||
Used to tell the dac how much the desired frequency deviates
|
||||
Used to tell the DAC how much the desired frequency deviates
|
||||
from the base frequency of each waveform.
|
||||
\item{A mode:}
|
||||
Used to tell it which waveform to generate
|
||||
|
|
@ -154,9 +156,9 @@ a waveform at a specific frequency played for a specific time. To perform the
|
|||
specific time functionality independant of DAC speed, an ISR
|
||||
\footnote{ISR...Interrupt Service Routine} on the AVR was used to change to
|
||||
the next tone every millisecond. A track is an array of tones with an end marker
|
||||
tone at the end which is a tone with a length of 0ms. The end marker tone tells
|
||||
the ISR to reset to the initial tone. The ISR can be seen in listing
|
||||
\ref{lst:textadv-isr} and the sound update function, which actually updates the
|
||||
tone at the end, which is a tone with a length of 0ms. The end marker tone tells
|
||||
the ISR to reset to the initial tone. The ISR can be seen in Listing
|
||||
\ref{lst:textadv-isr}, and the sound update function, which actually updates the
|
||||
current tone and is responsible for playing a track in listing
|
||||
\ref{lst:textadv-upsnd}. The output of an example track can be seen in
|
||||
figures \ref{fig:textadv_track_ex1} and \ref{fig:textadv_track_ex2}.
|
||||
|
|
@ -222,8 +224,8 @@ figures \ref{fig:textadv_track_ex1} and \ref{fig:textadv_track_ex2}.
|
|||
To switch tracks on different actions, there is a map of tracks associated with
|
||||
rooms. Every room has an associated track, where the association can change on
|
||||
actions performed, which allows for a game atmosphere change. Track changes are
|
||||
performed outside the ISR, which could theoretically result in a race condition
|
||||
where the ISR would load a faulty track for 1ms if the track change was not
|
||||
performed outside the ISR, which could theoretically result in a race condition,
|
||||
where the ISR would load a faulty track for 1ms, if the track change was not
|
||||
performed fast enough, but this is prevented by disabling global interrupts
|
||||
during a track change.
|
||||
|
||||
|
|
@ -232,21 +234,23 @@ during a track change.
|
|||
\subsubsection{Command structure and parsing}
|
||||
As in other text adventures \cite{dunnet} a command consits of one line of
|
||||
input terminated by a newline or line feed character \textbackslash n.
|
||||
The carriage return character which is sometimes transmitted with a line
|
||||
feed character is not parsed in this text adventure. Incoming character
|
||||
parsing can be seen in listings \ref{lst:textadv-routine-uart} and
|
||||
The carriage return character, which is sometimes transmitted with a line
|
||||
feed character, is not parsed in this text adventure. Incoming character
|
||||
parsing can be seen in Listings \ref{lst:textadv-routine-uart} and
|
||||
\ref{lst:textadv-ingest}.
|
||||
|
||||
As one command is parsed each part is required to be separated by an empty
|
||||
space character which is ascii code 32 \cite{ascii}. The first part of the given
|
||||
As one command is parsed, each part is required to be separated by an empty
|
||||
space character, which is ascii code 32 \cite{ascii}. The first part of the
|
||||
given
|
||||
input is then compared to an array of actions a user can perform, for example
|
||||
use or search, as can be seen in listing \ref{lst:textadv-parsecmd}
|
||||
use or search, as can be seen in Listing \ref{lst:textadv-parsecmd}
|
||||
|
||||
In listing \ref{lst:textadv-routine-uart} the comment echo back can be seen. The
|
||||
write\_char function before it writes the last received character back to the
|
||||
terminal which sent it. This is done to write what the user typed out to the
|
||||
terminal as otherwise it would not be seen what has been typed on any VT100
|
||||
compatiable terminal\cite{vt100} or terminal emulator.
|
||||
write\_char function, writes it's parameter to the user., in this case the
|
||||
input sent by the user.
|
||||
This is done to write what the user typed out to the
|
||||
terminal as otherwise one would not be able to see what has been typed on any
|
||||
VT100 compatiable terminal\cite{vt100} or terminal emulator.
|
||||
|
||||
\lstinputlisting[language=C,frame=trBL,
|
||||
breaklines=true, breakautoindent=true, formfeed=\newpage,
|
||||
|
|
@ -254,12 +258,12 @@ compatiable terminal\cite{vt100} or terminal emulator.
|
|||
columns=flexible, style=cstyle, firstline=73, lastline=81]
|
||||
{code/textadv/src/game.c}
|
||||
|
||||
The in listing \ref{lst:textadv-ingest} shown branch overrides the last received
|
||||
character with 0x00 which is ascii NUL and decrements the buffer pointer by one
|
||||
if the received character was 0x7F. 0x7F is the ADCII DELETE character
|
||||
\cite{ascii} which instructs the receiving end that the last received character
|
||||
The in Listing \ref{lst:textadv-ingest} shown branch overrides the last received
|
||||
character with 0x00, which is ascii NUL, and decrements the buffer pointer by
|
||||
one if the received character was 0x7F. 0x7F is the ADCII DELETE character
|
||||
\cite{ascii} which instructs the receiving end, that the last received character
|
||||
was a mistake and should be purged. This is also what a vt100 compiant terminal
|
||||
emulator sends when the backspace or delete key is pressed \cite{vt100}.
|
||||
emulator sends, when the backspace or delete key is pressed \cite{vt100}.
|
||||
|
||||
\lstinputlisting[language=C,frame=trBL,
|
||||
breaklines=true, breakautoindent=true, formfeed=\newpage,
|
||||
|
|
@ -269,15 +273,15 @@ emulator sends when the backspace or delete key is pressed \cite{vt100}.
|
|||
|
||||
\subsubsection{Command parameters}
|
||||
|
||||
Command paramters are interpreted as the string that follows the action
|
||||
Command paramters are interpreted as the string, that follows the action
|
||||
and the space behind it. As can be seen in the case for ACTION\_USE in
|
||||
listing \ref{lst:textadv-perfact} the use item function is passed the
|
||||
Listing \ref{lst:textadv-perfact}, the use item function is passed the
|
||||
command buffer\footnote{which is an address in memory} plus the length of the
|
||||
entered command plus one for the space. So the string starting at the passed
|
||||
address should match the start address of the parameter. If no parameter is
|
||||
supplied, the address should point to a character containing ASCII NUL, which
|
||||
marks the end of a string, bcause after comand parsing the string is overwritten
|
||||
with zeros as seen in listing \ref{lst:textadv-parsecmd}.
|
||||
marks the end of a string, because after command parsing, the string is
|
||||
overwritten with zeros as seen in Listing \ref{lst:textadv-parsecmd}.
|
||||
|
||||
\lstinputlisting[language=C,frame=trBL,
|
||||
breaklines=true, breakautoindent=true, formfeed=\newpage,
|
||||
|
|
@ -288,7 +292,7 @@ with zeros as seen in listing \ref{lst:textadv-parsecmd}.
|
|||
\subsection{Gameplay}
|
||||
|
||||
The game itself plays like a regular game with limtations set in direction.
|
||||
Playeras can search for items in each room and grab the found items as can be
|
||||
Players can search for items in each room and grab the found items as can be
|
||||
seen in figure \ref{fig:tetadv_gameplay}. The general gamplay is perfomred via
|
||||
altering the map data and the strings output to the user.
|
||||
|
||||
|
|
@ -301,45 +305,45 @@ altering the map data and the strings output to the user.
|
|||
|
||||
\subsubsection{Memory constraints}
|
||||
|
||||
The AVR has 8kB of internal SRAM which are used for stack and heap
|
||||
\cite{atmega2560}. During the build of the program an ELF file can be obtained
|
||||
The AVR has 8kB of internal SRAM, which are used for stack and heap
|
||||
\cite{atmega2560}. During the build of the program an ELF file can be obtained,
|
||||
which contains infromation on the programs structure and memory usage on boot.
|
||||
Strings and variables are contained within the .data section of the elf file,
|
||||
Strings and variables are contained within the .data section of the elf file
|
||||
and loaded into memory during boot\cite{elf}. This is done for integer
|
||||
variables, as well as for strings, which makes the use of strings limited not
|
||||
variables as well as for strings, which makes the use of strings limited not
|
||||
to the flash size but to the RAM size of the AVR. To save memory, sound tracks
|
||||
as well as the sine and noise table have been put into program space with the
|
||||
PROGMEM attribute as described by the avr-libc documentation\cite{progmem}.
|
||||
In listing \ref{lst:textadv-dac-gen} a read from program memory can be seen in
|
||||
the noise and sine modes. Strings have not been put into programmspace as this
|
||||
the noise and sine modes. Strings have not been put into programmspace, as this
|
||||
would require each string to be declared independantly and then be put into
|
||||
arrays\cite{progmem} as is done now, which would make the code much less
|
||||
readable and increase overhead As well as make the usage of buffers nescessary
|
||||
arrays\cite{progmem} as is done now. Which would make the code much less
|
||||
readable and increase overhead as well as make the usage of buffers nescessary
|
||||
in order for the override of the printf function to work.
|
||||
|
||||
\subsubsection{Story}
|
||||
|
||||
The basics of the storyline are that you wake up in the middle of a forest and
|
||||
The basics of the storyline are, that you wake up in the middle of a forest and
|
||||
don't remember anything. You have to get through the forest to an old house,
|
||||
while having to get rid of a bear which is blocking the way. Inside the house
|
||||
you have to get a computer to start. The game then proceeds to get recursive and
|
||||
your goal is to break out of the recursion.
|
||||
while having to get rid of a bear, which is blocking the way. Inside the house
|
||||
you have to get a computer to start. The game then proceeds to get recursive,
|
||||
and your goal is to break out of the recursion.
|
||||
|
||||
\subsubsection{Recursion}
|
||||
|
||||
The game, when performing the recursion, resets your inventory and internal
|
||||
state machines, before putting you back to the starting point. However by
|
||||
state machines, before putting you back to the starting point. However, by
|
||||
altering the orientation of rooms, altering the list of items found inside rooms
|
||||
and by altering the texts output by the game, the atmosphere can be changed, and
|
||||
and by altering the texts output by the game, the atmosphere and
|
||||
the outcome changed.
|
||||
|
||||
\subsubsection{Computer State Machine}
|
||||
|
||||
One example of a state machine inside the game is the computer inside the
|
||||
old-house. The computer needs three items: a keyboard to type on, something to
|
||||
old-house. The computer needs three items: A keyboard to type on, something to
|
||||
boot from, for example a floppy disk, and a screwdriver to start it. The state
|
||||
machine implementation can be seen in listing \ref{lst:textadv-fsm} and the
|
||||
state diagram in figure \ref{fig:textadv_compfsm}.
|
||||
machine implementation can be seen in Listing \ref{lst:textadv-fsm} and the
|
||||
state diagram in Figure \ref{fig:textadv_compfsm}.
|
||||
|
||||
\lstinputlisting[language=C,frame=trBL,
|
||||
breaklines=true, breakautoindent=true, formfeed=\newpage,
|
||||
|
|
|
|||
|
|
@ -1,21 +0,0 @@
|
|||
This is XeTeX, Version 3.14159265-2.6-0.999991 (TeX Live 2019/Arch Linux) (preloaded format=xelatex 2020.3.10) 18 MAR 2020 19:52
|
||||
entering extended mode
|
||||
restricted \write18 enabled.
|
||||
%&-line parsing enabled.
|
||||
**main.tec
|
||||
|
||||
! Emergency stop.
|
||||
<*> main.tec
|
||||
|
||||
End of file on the terminal!
|
||||
|
||||
|
||||
Here is how much of TeX's memory you used:
|
||||
3 strings out of 492483
|
||||
18 string characters out of 6134979
|
||||
66274 words of memory out of 5000000
|
||||
4587 multiletter control sequences out of 15000+600000
|
||||
3640 words of font info for 14 fonts, out of 8000000 for 9000
|
||||
1348 hyphenation exceptions out of 8191
|
||||
0i,0n,0p,1b,6s stack positions out of 5000i,500n,10000p,200000b,80000s
|
||||
No pages of output.
|
||||
Loading…
Reference in a new issue