Merge branch 'waschtl' into merge-all

main.auxlock

@@ -1 +0,0 @@
-\def \tikzexternallocked {0}

sections/DP/UART/main.tex

@@ -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
+error, a program which regularly transmits a character as well as
-a simple echo program, which transmits all received characters. Both programs
+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
+\ref{fig:232_echo}. The initialisation is practically the same for the
-transmission code, as well as the read and write routines in Listing 
+echo code as well as the read and write routines in Listing
 \ref{lst:16550-general}.
 
 \lstinputlisting[language=C,frame=trBL,

sections/DP/dac/main.tex

@@ -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
+sample rate of 10MHz \cite{tlc7528}, and which (should be
-entire D/A Conversion Range. The TLC-7528 was the only component chosen, where
+\footnote{See Figure \ref{fig:tlc7528_saw_nonlin}}) is monotonic over the
-availability was not a factor, but rather it's design. It is the cheapest
+entire D/A Conversion Range. The TLC-7528 is the only component chosen, where
-dual R2R Ladder dac which takes \textbf{PARALLEL} input, which is an important
+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
+DAC was developed for audio aplications\cite{tlc7528}, which made its use 
-and the TLC-7528 was the only IC available as DIP
+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
+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
+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.
 

sections/DP/fpga_interface/main.tex

@@ -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
+logic level converters have been obtained on amazon, and are not well
-documented. Their functionality has been tested and verified in both directions,
+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 
+was determined through measurements with a multimeter, and the 
-schematic in figure \ref{fig:schem_lvlshift} shows similar resistor values in
+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
+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
+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.

sections/DP/textadv/main.tex

@@ -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
+The macro BUS_HOLD_US is used to tell the AVR how many microseconds it takes for
-data bus to be latched into input register of the devices on write or how long
+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 
+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 
+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
+Therefore the AVR generates the audio during runtime. In order to do that it has
-modes in which it can run, as can be seen in listing
+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
+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 
+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
+\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
+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
+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
+The carriage return character, which is sometimes transmitted with a line
-feed character is not parsed in this text adventure. Incoming character
+feed character, is not parsed in this text adventure. Incoming character
-parsing can be seen in listings \ref{lst:textadv-routine-uart} and 
+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
+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
+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
+write\_char function, writes it's parameter to the user., in this case the 
-terminal which sent it. This is done to write what the user typed out to the
+input sent by the user.
-terminal as otherwise it would not be seen what has been typed on any VT100
+This is done to write what the user typed out to the
-compatiable terminal\cite{vt100} or terminal emulator. 
+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
+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
+character with 0x00, which is ascii NUL, and decrements the buffer pointer by 
-if the received character was 0x7F. 0x7F is the ADCII DELETE character
+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
+\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
+marks the end of a string, because after command parsing, the string is 
-with zeros as seen in listing \ref{lst:textadv-parsecmd}.
+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
+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
+\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
+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
+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
+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
+you have to get a computer to start. The game then proceeds to get recursive, 
-your goal is to break out of the recursion.
+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
+machine implementation can be seen in Listing \ref{lst:textadv-fsm} and the
-state diagram in figure \ref{fig:textadv_compfsm}.
+state diagram in Figure \ref{fig:textadv_compfsm}.
 
 \lstinputlisting[language=C,frame=trBL,
 	breaklines=true, breakautoindent=true, formfeed=\newpage,

sections/texput.log

@@ -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.