Update doc, remove z80uPC.tex, improved z80uPC_nostyle

it was useless to have 2 copies of the same thing,
soon z80uPC_nostyle will be renamed to z80uPC

1 files changed, 147 insertions, 24 deletions

diff --git a/doc/report/z80uPC_nostyle.tex b/doc/report/z80uPC_nostyle.tex
index fe9fa23..569e665 100644
--- a/doc/report/z80uPC_nostyle.tex
+++ b/doc/report/z80uPC_nostyle.tex
@@ -1,5 +1,14 @@
 \documentclass[a4paper, 11pt]{article}
 
+% draftwatermark
+\usepackage{draftwatermark}
+\SetWatermarkText{\tt DRAFT}
+\SetWatermarkLightness{.8}
+\SetWatermarkScale{10}
+
+% urls
+\usepackage{url}
+
 % figures
 \usepackage{array}
 \usepackage{float}
@@ -80,6 +89,10 @@
 \end{abstract}
 
 \break
+\tableofcontents
+\break
+
+%-----------------------------------------------------------------------------
 \section{Hardware}
 
 \subsection{Specifiche tecniche dello Z80}
@@ -121,7 +134,7 @@ Il minimo necessario per far funzionare uno Z80 sono una {\tt RAM} ed una
 anche di una porta seriale, di una porta parallela e di un counter timer;
 Hardware che si presenta normalmente all'interno di microcontrollori odierni.
 
-\begin{table}[hb]\centering
+\begin{table}[h!]\centering
 \caption{Lista dei componenti}
 \begin{tabular}{ >{\tt}p{.1\textwidth} >{\tt\bfseries}p{.2\textwidth} >{\footnotesize}p{.6\textwidth} }
     \toprule
@@ -156,7 +169,16 @@ vedere in tempo reale i valori sui bus degli indirizzi e dei dati.
 \end{tabular}
 \end{center}
 
+\subsection{Schema a blocchi}
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{res/block_diagram}
+    \caption{Schema a blocchi del \prj}
+\end{figure}
+
+% TODO
 \subsubsection{Implementazione dei generatori di clocks}
+
 \subsubsection{Uscite verso l'esterno (DIN 41612)}
 Per poter estendere lo \prj a lato \`e presente un connettore {\tt DIN 41612}
 per poter interfacciare schede di estensione della funzionali\`a siccome il
@@ -192,20 +214,79 @@ la parte di address space in cui \`e previsto di mappare dispositivi esterni.
 \end{tabu}}
 \end{table}
 
+% TODO
+\subsection{Address space}
+L'address space dello z80 \`e in grado di indirizzare 64 KB; la met\`a di
+questi \`e assegnata alla RAM e un quarto \`e della ROM. La ROM \`e minore
+della RAM perch\'e \`e intesa per essere un bootloader piuttosto che un vero e
+proprio OS.
+% TODO: redraw with xfig
+\begin{figure}[H]
+\centering
+\includegraphics[height=8cm]{res/addrspace}
+\end{figure}
 
 \subsection{Memory management unit}
-Alcuni modelli sucessori dello Z8400 implementavano ina MMU (Memory
-Management Unit) SoC che permetteva di ampliare la dimensione dell'address
-space, permettendo quindi di mappare pi\`u memorie o dispositivi separati
-negli stessi indirizzi. Ci\`o \`e un sistema \`e comune nei sistemi a base di
-microcontrollers per ovviare al problema dello spazio. Lo \prj per\`o ha un
-architettura pi\`u simile ad un computer X86 in cui la MMU viene utilizzata
-per la gestione delle \emph{pagine} di memoria.
+Alcuni modelli sucessori dello Z8400 implementavano ina MMU (Memory Management
+Unit) SoC che permetteva di ampliare la dimensione dell'address space,
+permettendo quindi di mappare pi\`u memorie o dispositivi separati negli stessi
+indirizzi. Lo \prj per\`o cerca di imitare un architettura pi\`u simile ad un
+computer X86 in cui la MMU viene utilizzata per la gestione delle \emph{pagine}
+di memoria. Il concetto di pagine (pages in inglese) \`e necessario per sistemi
+con un supporto per il multitasking. La conseguenza di questo design implica
+per\`o che sia introdotto anche il concetto di \emph{virtual address space}
+siccome, potendo reindirizzare a piacimento gli indirizzi, diventa possibile e
+conveniente offrire ai programmi eseguiti la stessa struttura di memoria
+indipendentemente dalla loro vera locazione in memoria.
+
+La struttura designata per il progetto \`e la seguente. \`E resa possibile
+solamente l'esecuzione di 2 programmi semi-paralleli, perch\`e
+l'implementazione di uno scheduler \`e troppo complessa con il CTC a
+disposizione. Si pu\`o quindi avviare due programmi ma solamente uno \`e in
+esecuzione ed utilizza il 100\% del tempo della CPU. Purtroppo le limitazioni
+di questo design non permettono di offrire funzionalit\`a importanti della
+kernel, ma in un futuro  si potrebbe risolvere il problema estendendo la
+piattaforma. Infatti grandi spazi dell'iospace sono stati lasciati liberi per
+l'aggiunta di dispositivi esterni.
+
+\begin{figure}[h!]
+    \centering
+    \includegraphics[height=5cm]{res/mmu_ram_map}
+\end{figure}
+
+I due programmi in `esecuzione' sono salvati nella RAM alle locazioni {\tt
+0xB000} e {\tt 0xD0000} con 8 KB di RAM per uno. Per passare da un programma
+all'altro la kernel offre delle system calls che modificano la \emph{page
+table} all'interno della MMU in maniera da mappare l'indirizzo {\tt B000} o
+{\tt D000} a {\tt 0000}.
+
+\begin{figure}[h!]
+\centering
+\begin{minipage}[c]{.45\textwidth} \centering
+    \includegraphics[width=\linewidth]{res/mmu_addr}
+\end{minipage}%
+\begin{minipage}[c]{.45\textwidth} \centering
+\begin{verbatim}
+    Example program running 
+    at address 0xB000
+
+    Virtual address
+    LD (#0x1200), #0xFE
+
+    Real Instruction
+    LD (#0xC200), #0xFE
+\end{verbatim}
+\end{minipage}
+\end{figure}
 
-Il concetto di pagine (pages in inglese) \`e necessario per sistemi con un
-supporto per il multitasking o per poter ampliare la memoria dinamica.
+Naturalmente ci\`o significa che il programma non ha l'accesso all'iospace,
+perci\`o per le operazioni con i dispositivi \`e necessario implementare un
+driver nella kernel. Nel caso in cui si volesse creare dei drivers userspace la
+kernel dovr\`a mettere a disposizione delle system calls che permettano di
+modificare la page table in maniera indiretta.
 
 \break
+%-----------------------------------------------------------------------------
 \section{Software}
 \subsection{Organizzazione del codice sorgente C}
 Il codice sorgente dell'intero progetto \`e contenuto nella cartella {\tt
@@ -235,23 +316,25 @@ $ sdcc -mz80 -pedantic --no-std-crt0 <crt0> \
        -I. -c <source_file> -o <object_file>
 \end{verbatim}
 In cui {\tt <source\_file>} \`e il documento con il codice sorgente e {\tt
-<object\_file>} \`e il nome dell'object (solitamente lo stesso del sorgente
-con l'estensione {\tt .o}). Mentre per linkare gli objects e generare un
-eseguibile si utilizza
+<object\_file>} \`e il nome dell'object (solitamente lo stesso del sorgente con
+l'estensione {\tt .o}).  La flag {\tt --allow-unsafe-read} \`e permessa
+solamente nella compilazione per Z80 e serve ad indicare al compiler che le
+letture da locazioni arbitrarie di memoria sono ammesse (normalmente non lo
+sono). Per linkare gli objects e generare un eseguibile si utilizza
 \begin{verbatim}
 $ sdcc -mz80 --no-std-crt0 <crt0> \
        --code-loc=<addr> <objects> -o <hexfile>
 
 $ makebin -s <rom_size> -yo 1 -ya 1 <hexfile> <binary>
 \end{verbatim}
-Gli argomenti {\tt -yo 1 -ya 1} specificano rispettivamente il numero di
-banchi di ROM e di RAM. 
+Le flags {\tt -yo 1 -ya 1} specificano rispettivamente il numero di banchi di
+ROM e di RAM.
 
 \subsection{CRT0 per lo Z80}
-In C il CRT0 \`e un insieme di routines che vengono eseguite prima del codice
-C che servono ad inizializzare il sistema. Nel caso dello \prj \`e utilizzato
-per inizializzare lo stack pointer e per organizzare i settori dell'eseguibile. 
-Un esempio di crt0 utilizzato per il progetto:
+In C il CRT0 \`e un insieme di routines che vengono eseguite prima del codice C
+che servono ad inizializzare il sistema. Nel caso dello \prj \`e utilizzato per
+inizializzare lo stack pointer e per indicare al linker come organizzare i
+settori dell'eseguibile. Un esempio di crt0 utilizzato per il progetto:
 
 \lstset{escapechar=@,style=customasm}
 \begin{lstlisting}
@@ -303,19 +386,24 @@ assembler per lo Z80, per esempio quello fornito in SDCC.\@
 $ sdasz80 -o <crt0.s>
 \end{verbatim}
 
-Quindi l'argomento {\tt --no-std-crt0 <crt0>} per il compiler descritto precedente non 
-\`e assolutamente necessario ma \`e consigliato siccome permette di avere un
-controllo maggiore del contenuto dell'eseguibile.
+Quindi l'argomento {\tt --no-std-crt0 <crt0>} per il compiler descritto
+precedente non \`e assolutamente necessario ma \`e consigliato siccome permette
+di avere un controllo maggiore del contenuto dell'eseguibile.
 
 \subsection{Codice sorgente VHDL}
 Il codice sorgente in VHDL per la CPLD utilizzata come address decoder e MMU, 
 \`e contenuto nella cartella {\tt sw/cpld}. La toolchain utilizzata \`e quella
 offerta da Lattice.
 
+% TODO
+\subsubsection{Programmazione della MMU}
+
+
 \break
+%-----------------------------------------------------------------------------
 \section*{Glossario Tecnico}
 {\def\arraystretch{1.4}
-\begin{tabular}{ >{\bfseries}p{.3\linewidth} p{.7\linewidth} }
+\begin{tabular}{ >{\bfseries}p{.35\linewidth} p{.65\linewidth} }
 
     Address Space & In informatica l'\emph{address space} \`e un intervallo di
     indirizzi che possono corrispondere a indirizzi in rete, regioni di un
@@ -324,14 +412,49 @@ offerta da Lattice.
     all'intervallo indirizzabile dal processore, ovvero \(2^{16}\) locazioni
     siccome il sistema dispone di un bus a 16 bit. \\
 
+    Virtual Address Space & Il virtual address space \`e un livello di
+    astrazione che estende l'address space utilizzato nelle architetture
+    moderne (X86 / 64). In un sistema senza VAS, i programmi caricati in
+    memoria `vedono' l'indirizzo in cui si trovano e devono perci\`o essere
+    caricati in una regione di memoria continua. In un sistema con VAS invece
+    al programma figura sempre di avere l'intero address space disponibile per
+    se, e la MMU si occupa di traslare gli indirizzi virtuali in indirizzi
+    reali prima che essi raggiungano l'hardware. \\
+
     Registro & Un registro \`e un dispositivo di memoria in cui \`e possibile
     pu\`o leggere e/o scrivere un certo valore. Normalmente in un computer /
     microcontrollore la dimensione della memoria \`e data dall'architettura,
     dunque 8, 16, 32 o 64 bits.  In questo documento viene viene comunemente
     utilizzato per riferirsi ad una memoria di un dispositivo fisico come la
     CPU o un IC seriale. \\
+
+    Toolchain & Da Wikipedia \cite{wiki:toolchain}: In ambito software, una
+    toolchain è l'insieme dei programmi (tools) usati nello sviluppo di un
+    prodotto (tipicamente un altro programma o sistema di programmi). I tool
+    possono essere utilizzati in catena, in modo tale che l'output di ciascun
+    tool rappresenti l'input per il successivo, ma il termine è utilizzato in
+    maniera più estesa per riferirsi, più in generale, a qualunque insieme di
+    tool di sviluppo collegati tra loro. \\
+
+    Stack Pointer,\newline Program Counter & Lo Stack Pointer \`e un registro a
+    16 bit in cui \`e salvato l'indirizzo della fine (pi\`u in alto, ultimo
+    inserito) dello stack. Il program counter, un altro registro a 16 bit
+    contiene l'indirizzo da cui leggere della prossima istruzione da
+    eseguire.\\
+
 \end{tabular}}
 
-\section*{Bibliografia}
+\begin{thebibliography}{2}
+\bibitem{wiki:toolchain}
+    \url{https://it.wikipedia.org/wiki/Toolchain}
+
+\bibitem{z80book}
+    \textbf{Paolo Di Leo},
+    Z80 Microcomputer didattico, 
+    Gennaio 2016,
+    Libri SANDIT,
+    {\tt ISBN 978-88-6928-142-6}
+
+\end{thebibliography}
 
 \end{document}