From 4d02ee15563a1568c960e967eebce73fd463f5fc Mon Sep 17 00:00:00 2001 From: Nao Pross Date: Tue, 14 Nov 2017 11:45:17 +0100 Subject: 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 --- doc/report/build/notes.pdf | Bin 34156 -> 20001 bytes doc/report/build/z80uPC_nostyle.pdf | Bin 69118 -> 96869 bytes doc/report/build/z80uPC_nostyle.toc | 16 ++ doc/report/res/addrspace.pdf | Bin 7744 -> 6481 bytes doc/report/res/addrspace.svg | 38 +-- doc/report/res/block_diagram.pdf | Bin 19532 -> 23235 bytes doc/report/res/iospace.pdf | Bin 6435 -> 6120 bytes doc/report/res/kernel_mem_base.pdf | Bin 17254 -> 17257 bytes doc/report/res/mem_kern_alloc.pdf | Bin 8128 -> 8130 bytes doc/report/res/mmu_addr.eps | 470 ++++++++++++++++++++++++++++++++++++ doc/report/res/mmu_addr.fig | 182 ++++++++++++++ doc/report/res/mmu_ram_map.eps | 229 ++++++++++++++++++ doc/report/res/mmu_ram_map.fig | 57 +++++ doc/report/res/mmu_ram_map.fig.bak | 57 +++++ doc/report/z80uPC.tex | 307 ----------------------- doc/report/z80uPC_nostyle.tex | 171 +++++++++++-- 16 files changed, 1177 insertions(+), 350 deletions(-) create mode 100644 doc/report/build/z80uPC_nostyle.toc create mode 100644 doc/report/res/mmu_addr.eps create mode 100644 doc/report/res/mmu_addr.fig create mode 100644 doc/report/res/mmu_ram_map.eps create mode 100644 doc/report/res/mmu_ram_map.fig create mode 100644 doc/report/res/mmu_ram_map.fig.bak delete mode 100644 doc/report/z80uPC.tex (limited to 'doc/report') diff --git a/doc/report/build/notes.pdf b/doc/report/build/notes.pdf index ad70a98..c96785c 100644 Binary files a/doc/report/build/notes.pdf and b/doc/report/build/notes.pdf differ diff --git a/doc/report/build/z80uPC_nostyle.pdf b/doc/report/build/z80uPC_nostyle.pdf index 2ba99e8..55a6f90 100644 Binary files a/doc/report/build/z80uPC_nostyle.pdf and b/doc/report/build/z80uPC_nostyle.pdf differ diff --git a/doc/report/build/z80uPC_nostyle.toc b/doc/report/build/z80uPC_nostyle.toc new file mode 100644 index 0000000..73b0474 --- /dev/null +++ b/doc/report/build/z80uPC_nostyle.toc @@ -0,0 +1,16 @@ +\select@language {italian} +\select@language {italian} +\contentsline {section}{\numberline {1}Hardware}{3} +\contentsline {subsection}{\numberline {1.1}Specifiche tecniche dello Z80}{3} +\contentsline {subsection}{\numberline {1.2}Componenti e modello di design}{3} +\contentsline {subsection}{\numberline {1.3}Schema a blocchi}{4} +\contentsline {subsubsection}{\numberline {1.3.1}Implementazione dei generatori di clocks}{4} +\contentsline {subsubsection}{\numberline {1.3.2}Uscite verso l'esterno (DIN 41612)}{4} +\contentsline {subsection}{\numberline {1.4}Address space}{5} +\contentsline {subsection}{\numberline {1.5}Memory management unit}{5} +\contentsline {section}{\numberline {2}Software}{8} +\contentsline {subsection}{\numberline {2.1}Organizzazione del codice sorgente C}{8} +\contentsline {subsection}{\numberline {2.2}C Toolchain}{8} +\contentsline {subsection}{\numberline {2.3}CRT0 per lo Z80}{9} +\contentsline {subsection}{\numberline {2.4}Codice sorgente VHDL}{10} +\contentsline {subsubsection}{\numberline {2.4.1}Programmazione della MMU}{10} diff --git a/doc/report/res/addrspace.pdf b/doc/report/res/addrspace.pdf index 26c28d8..c949e0a 100644 Binary files a/doc/report/res/addrspace.pdf and b/doc/report/res/addrspace.pdf differ diff --git a/doc/report/res/addrspace.svg b/doc/report/res/addrspace.svg index 0f73784..ef9be71 100644 --- a/doc/report/res/addrspace.svg +++ b/doc/report/res/addrspace.svg @@ -14,7 +14,7 @@ viewBox="0 0 180.64061 257.56342" version="1.1" id="svg8" - inkscape:version="0.92.1 r" + inkscape:version="0.92.2 (5c3e80d, 2017-08-06)" sodipodi:docname="addrspace.svg"> @@ -26,16 +26,16 @@ inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:zoom="0.33575172" - inkscape:cx="902.43963" + inkscape:cx="-44.688802" inkscape:cy="551.46623" inkscape:document-units="mm" inkscape:current-layer="layer1" showgrid="false" showborder="false" - inkscape:window-width="1266" - inkscape:window-height="763" - inkscape:window-x="5" - inkscape:window-y="28" + inkscape:window-width="1280" + inkscape:window-height="800" + inkscape:window-x="0" + inkscape:window-y="0" inkscape:window-maximized="0" fit-margin-top="0" fit-margin-left="0" @@ -49,7 +49,7 @@ image/svg+xml - + @@ -98,7 +98,7 @@ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:13.05277824px;font-family:'Roboto Mono';-inkscape-font-specification:'Roboto Mono, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:center;writing-mode:lr-tb;text-anchor:middle;stroke-width:0.26458332" /> 0x0000 + style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:13.40555556px;font-family:'Latin Modern Mono';-inkscape-font-specification:'Latin Modern Mono, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-feature-settings:normal;text-align:center;writing-mode:lr;text-anchor:middle;stroke-width:0.26458332;">0x0000 0x2000 0x4000 0x8000 0xFFFF 32KB RAM SPACE 8KB ROM > + +matrix +makepattern +/P4 exch def + +/cp {closepath} bind def +/ef {eofill} bind def +/gr {grestore} bind def +/gs {gsave} bind def +/sa {save} bind def +/rs {restore} bind def +/l {lineto} bind def +/m {moveto} bind def +/rm {rmoveto} bind def +/n {newpath} bind def +/s {stroke} bind def +/sh {show} bind def +/slc {setlinecap} bind def +/slj {setlinejoin} bind def +/slw {setlinewidth} bind def +/srgb {setrgbcolor} bind def +/rot {rotate} bind def +/sc {scale} bind def +/sd {setdash} bind def +/ff {findfont} bind def +/sf {setfont} bind def +/scf {scalefont} bind def +/sw {stringwidth} bind def +/tr {translate} bind def +/tnt {dup dup currentrgbcolor + 4 -2 roll dup 1 exch sub 3 -1 roll mul add + 4 -2 roll dup 1 exch sub 3 -1 roll mul add + 4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb} + bind def +/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul + 4 -2 roll mul srgb} bind def +/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def +/$F2psEnd {$F2psEnteredState restore end} def + +/pageheader { +save +newpath 0 259 moveto 0 0 lineto 488 0 lineto 488 259 lineto closepath clip newpath +-225.8 369.9 translate +1 -1 scale +$F2psBegin +10 setmiterlimit +0 slj 0 slc + 0.06299 0.06299 sc +} bind def +/pagefooter { +$F2psEnd +restore +} bind def +%%EndProlog +pageheader +% +% Fig objects follow +% +% +% here starts figure with depth 50 +/Times-Roman ff 873.13 scf sf +6345 4275 m +gs 1 -1 sc (}) col0 sh gr +/Times-Roman ff 254.00 scf sf +6795 4140 m +gs 1 -1 sc (Program A) col0 sh gr +/Times-Roman ff 873.13 scf sf +6345 5220 m +gs 1 -1 sc (}) col0 sh gr +/Times-Roman ff 254.00 scf sf +6840 5040 m +gs 1 -1 sc (Program B) col0 sh gr +% Polyline +0 slj +0 slc +15.000 slw +n 6570 2295 m 6795 2295 l 6795 2520 l 6570 2520 l + cp +% Fill with pattern background color +gs /DeviceRGB setcolorspace 1.00 1.00 1.00 setcolor fill gr + +% Fill with pattern pen color +gs /DeviceRGB setcolorspace 0.00 0.00 0.00 P4 setpattern fill gr + +gs col0 s gr +/Times-Roman ff 254.00 scf sf +6975 2520 m +gs 1 -1 sc (Kernel) col0 sh gr +/Times-Roman ff 254.00 scf sf +6975 2835 m +gs 1 -1 sc (Reserved) col0 sh gr +% Arc +7.500 slw +gs clippath +9409 4408 m 9485 4272 l 9433 4242 l 9357 4379 l 9357 4379 l 9442 4289 l 9409 4408 l cp +eoclip +n 8347.5 3730.5 1229.6 26.2837 97.3591 arc +gs col0 s gr + gr + +% arrowhead +n 9409 4408 m 9442 4289 l 9357 4379 l 9409 4408 l cp gs col7 1.00 shd ef gr col0 s +% Polyline +n 4500 4950 m + 6300 4950 l gs col0 s gr +% Polyline +n 6300 4500 m + 4500 4500 l gs col0 s gr +% Polyline +n 4500 4050 m + 6300 4050 l gs col0 s gr +% Polyline +n 4500 2250 m 6300 2250 l 6300 3600 l 4500 3600 l + cp +% Fill with pattern background color +gs /DeviceRGB setcolorspace 1.00 1.00 1.00 setcolor fill gr + +% Fill with pattern pen color +gs /DeviceRGB setcolorspace 0.00 0.00 0.00 P4 setpattern fill gr + +gs col0 s gr +% Polyline +n 4500 5400 m 6300 5400 l 6300 5850 l 4500 5850 l + cp +% Fill with pattern background color +gs /DeviceRGB setcolorspace 1.00 1.00 1.00 setcolor fill gr + +% Fill with pattern pen color +gs /DeviceRGB setcolorspace 0.00 0.00 0.00 P4 setpattern fill gr + +gs col0 s gr +% Polyline +15.000 slw +n 4500 2250 m 6300 2250 l 6300 5850 l 4500 5850 l + cp gs col0 s gr +% Polyline +7.500 slw +n 8550 2700 m + 10350 2700 l gs col0 s gr +% Polyline +15.000 slw +n 8550 4050 m 10350 4050 l 10350 2250 l 8550 2250 l + cp gs col0 s gr +% Polyline +7.500 slw +n 8550 3600 m + 10350 3600 l gs col0 s gr +% Polyline +n 8550 3150 m + 10350 3150 l gs col0 s gr +/Times-Roman ff 285.75 scf sf +4500 2025 m +gs 1 -1 sc (RAM) col0 sh gr +/Courier ff 190.50 scf sf +3600 3600 m +gs 1 -1 sc (0xB000) col0 sh gr +/Courier ff 190.50 scf sf +3600 2250 m +gs 1 -1 sc (0x8000) col0 sh gr +/Courier ff 190.50 scf sf +3600 5850 m +gs 1 -1 sc (0xFFFF) col0 sh gr +/Times-Roman ff 317.50 scf sf +8505 2025 m +gs 1 -1 sc (Program) col0 sh gr +/Courier ff 222.25 scf sf +9450 2565 m +gs 1 -1 sc (DATA / BSS) dup sw pop 2 div neg 0 rm col0 sh gr +/Courier ff 222.25 scf sf +9450 3870 m +gs 1 -1 sc (STACK) dup sw pop 2 div neg 0 rm col0 sh gr +/Courier ff 190.50 scf sf +10575 2250 m +gs 1 -1 sc (0x0000) col0 sh gr +/Courier ff 190.50 scf sf +10575 4050 m +gs 1 -1 sc (0x2000) col0 sh gr +/Courier ff 222.25 scf sf +9450 3015 m +gs 1 -1 sc (HEAP) dup sw pop 2 div neg 0 rm col0 sh gr +/Courier ff 222.25 scf sf +9450 3465 m +gs 1 -1 sc (TEXT) dup sw pop 2 div neg 0 rm col0 sh gr +/Courier ff 190.50 scf sf +3600 4500 m +gs 1 -1 sc (0xD000) col0 sh gr +% here ends figure; +pagefooter +showpage +%%Trailer +end +%EOF diff --git a/doc/report/res/mmu_ram_map.fig b/doc/report/res/mmu_ram_map.fig new file mode 100644 index 0000000..3c22a92 --- /dev/null +++ b/doc/report/res/mmu_ram_map.fig @@ -0,0 +1,57 @@ +#FIG 3.2 Produced by xfig version 3.2.6a +Portrait +Center +Metric +A4 +100.00 +Single +-2 +1200 2 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 1 8347.500 3730.500 9450 4275 8505 4950 8190 4950 + 1 0 1.00 60.00 120.00 +6 6345 3645 8010 4455 +4 0 0 50 -1 0 55 0.0000 0 795 435 6345 4275 }\001 +4 0 0 50 -1 0 16 0.0000 0 240 1200 6795 4140 Program A\001 +-6 +6 6345 4590 8055 5400 +4 0 0 50 -1 0 55 0.0000 0 795 435 6345 5220 }\001 +4 0 0 50 -1 0 16 0.0000 0 240 1185 6840 5040 Program B\001 +-6 +6 6525 2250 8010 2835 +2 2 0 2 0 7 50 -1 44 0.000 0 0 -1 0 0 5 + 6570 2295 6795 2295 6795 2520 6570 2520 6570 2295 +4 0 0 50 -1 0 16 0.0000 0 180 735 6975 2520 Kernel\001 +4 0 0 50 -1 0 16 0.0000 0 180 1005 6975 2835 Reserved\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4500 4950 6300 4950 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 6300 4500 4500 4500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4500 4050 6300 4050 +2 2 0 1 0 7 50 -1 44 0.000 0 0 7 0 0 5 + 4500 2250 6300 2250 6300 3600 4500 3600 4500 2250 +2 2 0 1 0 7 50 -1 44 0.000 0 0 -1 0 0 5 + 4500 5400 6300 5400 6300 5850 4500 5850 4500 5400 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 4500 2250 6300 2250 6300 5850 4500 5850 4500 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 8550 2700 10350 2700 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 8550 4050 10350 4050 10350 2250 8550 2250 8550 4050 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 8550 3600 10350 3600 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 2 + 8550 3150 10350 3150 +4 0 0 50 -1 0 18 0.0000 0 195 690 4500 2025 RAM\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 3600 3600 0xB000\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 3600 2250 0x8000\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 3600 5850 0xFFFF\001 +4 0 0 50 -1 0 20 0.0000 0 300 1125 8505 2025 Program\001 +4 1 0 50 -1 5 14 0.0000 0 180 1500 9450 2565 DATA / BSS\001 +4 1 0 50 -1 5 14 0.0000 0 135 750 9450 3870 STACK\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 10575 2250 0x0000\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 10575 4050 0x2000\001 +4 1 0 50 -1 5 14 0.0000 0 135 600 9450 3015 HEAP\001 +4 1 0 50 -1 5 14 0.0000 0 135 600 9450 3465 TEXT\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 3600 4500 0xD000\001 diff --git a/doc/report/res/mmu_ram_map.fig.bak b/doc/report/res/mmu_ram_map.fig.bak new file mode 100644 index 0000000..f62f655 --- /dev/null +++ b/doc/report/res/mmu_ram_map.fig.bak @@ -0,0 +1,57 @@ +#FIG 3.2 Produced by xfig version 3.2.6a +Portrait +Center +Metric +A4 +100.00 +Single +-2 +1200 2 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 1 8347.500 3730.500 9450 4275 8505 4950 8190 4950 + 1 0 1.00 60.00 120.00 +6 6345 3645 8010 4455 +4 0 0 50 -1 0 55 0.0000 0 795 435 6345 4275 }\001 +4 0 0 50 -1 0 16 0.0000 0 240 1200 6795 4140 Program A\001 +-6 +6 6345 4590 8055 5400 +4 0 0 50 -1 0 55 0.0000 0 795 435 6345 5220 }\001 +4 0 0 50 -1 0 16 0.0000 0 240 1185 6840 5040 Program B\001 +-6 +6 6525 2250 8010 2835 +2 2 0 2 0 7 50 -1 44 0.000 0 0 -1 0 0 5 + 6570 2295 6795 2295 6795 2520 6570 2520 6570 2295 +4 0 0 50 -1 0 16 0.0000 0 180 735 6975 2520 Kernel\001 +4 0 0 50 -1 0 16 0.0000 0 180 1005 6975 2835 Reserved\001 +-6 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4500 4950 6300 4950 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 6300 4500 4500 4500 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4500 4050 6300 4050 +2 2 0 1 0 7 50 -1 44 0.000 0 0 7 0 0 5 + 4500 2250 6300 2250 6300 3600 4500 3600 4500 2250 +2 2 0 1 0 7 50 -1 44 0.000 0 0 -1 0 0 5 + 4500 5400 6300 5400 6300 5850 4500 5850 4500 5400 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 4500 2250 6300 2250 6300 5850 4500 5850 4500 2250 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 8550 2700 10350 2700 +2 2 0 2 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 8550 4050 10350 4050 10350 2250 8550 2250 8550 4050 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 8550 3600 10350 3600 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 2 + 8550 3150 10350 3150 +4 0 0 50 -1 0 18 0.0000 0 195 690 4500 2025 RAM\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 3600 3600 0xB000\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 3600 2250 0x8000\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 3600 4500 0xE000\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 3600 5850 0xFFFF\001 +4 0 0 50 -1 0 20 0.0000 0 300 1125 8505 2025 Program\001 +4 1 0 50 -1 5 14 0.0000 0 180 1500 9450 2565 DATA / BSS\001 +4 1 0 50 -1 5 14 0.0000 0 135 750 9450 3870 STACK\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 10575 2250 0x0000\001 +4 0 0 50 -1 5 12 0.0000 0 120 720 10575 4050 0x2000\001 +4 1 0 50 -1 5 14 0.0000 0 135 600 9450 3015 HEAP\001 +4 1 0 50 -1 5 14 0.0000 0 135 600 9450 3465 TEXT\001 diff --git a/doc/report/z80uPC.tex b/doc/report/z80uPC.tex deleted file mode 100644 index 50034ec..0000000 --- a/doc/report/z80uPC.tex +++ /dev/null @@ -1,307 +0,0 @@ -\documentclass[a4paper, 11pt, twoside]{article} - -\usepackage{array} -\usepackage{float} -\usepackage{wrapfig} - -% source code -\usepackage{listings} - -% set correct hypenation -\usepackage[italian]{babel} - -% set margins -\usepackage[ - inner=2.5cm, - outer=2.5cm, - top=3cm, - bottom=3.75cm -]{geometry} - -% set headers -\usepackage{fancyhdr} -\pagestyle{fancyplain} -\fancyhf{} -\setlength{\headheight}{1.3cm} -\rhead{\includegraphics[height=1.25cm]{res/logo_sam}} -\lfoot{SAM 3E - Naoki Pross} -\rfoot{\thepage} - -% set font -\usepackage{fontspec} -\setmainfont{Roboto} -\setmonofont{Roboto Mono} - -% to fix macros -\usepackage{xspace} -% commands -% macro for project name -\newcommand{\prj}{Z80μPC\xspace} - -% invert signal (not, active low) -\newcommand{\inv}[1]{$\overline{\mbox{#1}}$} - -% metadata -\title{\vspace{-1cm}\texttt{\prj} Single Board \\ Computer Development } -\author{Naoki Pross} - -% document -\begin{document} - -\maketitle -\begin{abstract} - - Lo Zilog Z80 \`e un processore a 8 bit che fu introdotto nel 1976 che ebbe - un grandissimo successo nel mondo dell'elettronica e dell'informatica - nella fine del 20esimo secolo. In memoria di questo pioniere - dell'industria dei sistemi informatici questo progetto documenta la - realizzazione di un microcomputer a scopo generico a base di esso. - L'obiettivo primario dunque \`e di realizzare una scheda simile ad una - motherboard dei computers venduti all'epoca completa di RAM, ROMs, - interfacce seriali e altri circuiti di supporto. Successivamente per - l'aspetto software il progetto deve implementare i drivers per ogni - circuito presente sulla scheda in modo da semplificare la programmazione. - L'obiettivo opzionale del progetto, una volta terminata la costruzione - hardware, \`e di realizzare una kernel monolitica che offre funzioni - minimali simili ad un sistema UNIX, quali processi, filesystem, memory - management e drivers. - -\end{abstract} - -\section{Specifiche tecniche dello Z80} -Lo Z80 \`e un processore molto minimalistico se paragonato a ci\`o che si -trova oggi sul mercato dei microcontrollori. Per il progetto \prj la CPU in -uso \`e il modello originale \texttt{Zilog Z8400} che non dispone di sistemi -integrati come i modelli SoC odierni. Le specifiche pi\`u importanti sono -elencate a seguire. - -\begin{itemize} - \item Architettura a 8 bit con bus a 16 bit, 64K indirizzi indirizzabili - \item Registri a 16 bit per {\tt SP,PC} e registri di utilizzo generico a - 8 bit {\tt A..F} combinabili a coppie {\tt AF,BC,..} per utilizzare - valori a 16 bit - \item Clock fino a 8 MHz - \item Segnali di controllo tra cui \texttt{\inv{RD}, \inv{WR}, - \inv{IOREQ}, \inv{MREQ}} e \texttt{\inv{RST}} - \item Interrupts mascherabili e non con vettore a 8 bit -\end{itemize} - -\section{Architettura di base} -Il minimo necessario per far funzionare un computer con lo Z80 sono una ROM e -una RAM, ma per il mio progetto ho scelto di aggiungere dell'hardware -aggiuntivo per lo sviluppo si sistemi pi\`u complessi per apprendere -conoscenze sia nel mondo dell'elettronica che dell'informatica. Per questa -ragione lo \prj possiede i seguienti componenti: - -\begin{center} -\begin{tabular}{ >{\tt}l >{\tt\bfseries}l p{.7\linewidth} } - % \hline \\ - ROM & M28C64 & EEPROM da 8KB x 8 bit (64K) per il BIOS / Bootloader / - OS installata doppia per avere 16KB \\ - RAM & HM62256B & SRAM da 32KB x 8bit (256K) \\ - CTC & Z8430 & Counter timer circuit ufficiale di Zilog a 4 canali che - permette di essere programmato \\ - PIO & Z8420 & Parallel input/output controller di Zilog per avere un - intefaccia digitale con due porte da 8 bit \\ - MMU & M4-32/32-15JC & CPLD programmabile che implementa una memory - management unit semplificata in grado di gestire i 5 - bit pi\`u significativi della linea di indirizzi \\ - USART & TL16C550C & Interfaccia USART per poter comunicare utilizzando il - protocollo RS232 -\end{tabular} -\end{center} - -Oltre a tutto ci\`o per uno scopo formativo lo \prj dispone anche di strumenti -da debug e analisi per comprendere ogni operazione del processore. Il modello -di Z80 scelto \`e in grado di utilizzare un clock fino a 8MHz, ma non -definisce un minimo dunque sono presenti 3 circuiti che generano 3 clock di -velocit\`a differenti. - -\begin{center} -\begin{tabular}{ >{\bfseries}r p{.8\linewidth} } - 0Hz & Questo clock \`e un bottone che permette di creare - manualmente le pulsazioni del clock, per poter analizzare - ogni istruzione \\ - 200Hz & Mediante un classico circuito con un LM555 si ha un clock da - 200Hz per eseguire i programmi a velocit\`a rallentata \\ - 4MHz & Clock per esecuzione a velocit\`a piena (normale) -\end{tabular} -\end{center} - -Una seconda disposizione per aiutare la comprensione del funzionamento del -processore \`e data da 6 display a 7 segmenti che durante l'esecuzione -rallentata o a step (bottone) visualizzano i bytes presenti sulla bus di -indirizzi a 16 bit e sul bus di dati a 8 bit. - -\begin{figure}[!h] \centering - \includegraphics[width=\linewidth]{res/bus_displays} - \caption{Display a 7 segmenti per visualizzare il flusso di dati della - CPU} -\end{figure} - -\section{Memory Management Unit} - -Alcuni modelli successori dello Z8400 implementavano una MMU SoC che -permetteva di indirizzare un address space di dimensione maggiore. Per lo \prj -non necessito di un indirizzamento pi\`u grande ma piuttosto sono interessato -dalle operazioni di gestione della memoria di una MMU simile a ci\`o che -accade nelle architetture X86. Nelle architetture odierne basate sull'X86/64 -\`e presente un sistema di traslazione di indirizzi di memoria da virtuale a -fisica. Con lo scopo di trarne solamente i vantaggi pi\`u fondamentali lo \prj -implementa nella CPLD MMU un sistema basilare di gestione di pagine di memoria -con traslazione di indirizzi in modo da poter allocare pi\`u programmi nella -RAM anche se il sistema non implementa il multitasking. - -% TODO: write about this in more details - -\subsection{Address Space} - -\begin{wrapfigure}{r}{.4\linewidth} \centering - \vspace{8mm} - \includegraphics[width=.9\linewidth]{res/addrspace} - \vspace{4mm} - \caption{Address space dello \prj} -\end{wrapfigure} -La funzione primaria della MMU \`e di mappare i dispositivi I/O e le memorie -nell'address space. Nell'implementazione reale la MMU controlla i segnali {\tt -\inv{CS}} seguendo una logica combinatoria molto semplice che controlla se -l'indirizzo sul bus si trova in una zona definita per un dispositivo. -L'address space si presenta dunque nella seguente maniera, per cui la ROM -occupa il primo quarto, i dispositivi mappabili il secondo quarto e la RAM la -met\`a restante. Essendo un progetto pensato per essere esteso 16KB sono -liberi per mappare dispositivi esterni collegati attraverso il connettore -DIN41612. - -% \begin{wrapfigure}{l}{.4\linewidth} \centering -% \includegraphics[width=.8\linewidth]{res/iospace} -% \end{wrapfigure} - -\subsection{Page Table} - -Per poter controllare la traslazione degli indirizzi la MMU dispone di una -Page Table a cui \`e possibile accedere attraversso un certo indirizzo -nell'I/O space. La page table di 5 bit permette la gestione delle regioni di -memoria da impostare per dei determinati processi. Questa funzione \`e -importante perch\`e permette la separazione dello stack e della memoria della -kernel dai programmi normali. Per lo \prj potrebbe sembrare eccessivo ma -essendo uno strumento per apprendere le fondamenta dell'elettronica e -dell'informatica \`e interessante implementare questa funzionalit\`a che -comunque se necessario pu\`o essere disabilitata. - -\section{Schema a blocchi} - -\begin{figure}[!h] \centering - \includegraphics[width=.85\linewidth]{res/block_diagram} -\end{figure} - -\section{Software / Sistema operativo} - -Negli sviluppi pi\`u recenti intorno allo Z80 esso veniva utilizzato come un -microcontrollore anzich\`e come processore da computer, per questa ragione non -sono presenti molti sistemi operativi per questa piattaforma. Dunque per lo -\prj il progetti implementa un sistema operativo soprannominato {\tt -HelvetiOS} con le funzioni minime necessarie come un interfaccia seriale a -comandi e un meccanismo per caricare i programmi. - -\subsection{Componenti di base} - -Per garantire un funzionamento minimo il sistema {\tt HelvetiOS} deve offrire -drivers e utility di base quali: - -\begin{center} -\begin{minipage}[t]{.4\linewidth} - \begin{itemize} - \item USART driver and API - \item PIO driver and API - \item CTC driver and API - \end{itemize} -\end{minipage}% -\begin{minipage}[t]{.4\linewidth} - \begin{itemize} - \item Bootloader - \item Program launcher - \item Shell-like interface - \end{itemize} -\end{minipage} -\end{center} - -\subsection{Interfacce dell'API} - -Nel corso dello sviluppo questa sezione verr\`a continuamente espansa per -documentare le interfacce dei vari drivers. - -\subsubsection{USART} -\begin{lstlisting}[language=C, basicstyle=\ttfamily] -void usart_set_baudrate(uint16_t baudrate); -void usart_set_parity(int mode); -void usart_set_stop_bits(int count); -void usart_set_word_length(int length); -void usart_set_autoflow(int mode); - -inline void usart_init(uint16_t baudrate, int parity, int stop_bits); - -void usart_transmit(uint8_t data); -uint8_t usart_receive(); - -int usart_write(uint8_t *data, size_t size); -int usart_read(uint8_t *buffer, size_t count); -\end{lstlisting} - -% \subsection{PIO} - -\subsection{Toolchain per la compilazione} - -Per compilare il software del progetto si utilizza SDCC, un progetto -open-source che supporta la compilazione di binari per l'architettura dello -Z80. Nella mia configurazione utilizzo GNU make con il seguente makefile. - -\newpage -\begin{lstlisting}[language=make, numbers=left, basicstyle=\ttfamily] -#### -# Source code settings -# -OSNAME := helvetiOS - -CSOURCES := $(wildcard kernel/*.c) $(wildcard libc/*.c) -OBJECTS := $(patsubst %.c,build/%.rel,$(CSOURCES)) -HEXFILE := build/$(OSNAME).hex -BINARY := build/$(OSNAME).bin - -### -# Compiler settings - -CC := sdcc - -CFLAGS := -mz80 \ - -I kernel/include -I libc/include -DDEBUG - -LDFLAGS := -mz80 --no-std-crt0 crt0.rel \ - --code-loc 0x0800 --data-loc 0x8000 - -.PHONY: dirs dis clean -all: $(BINARY) - -# build binary -$(BINARY): $(OBJECTS) dirs - $(CC) $(LDFLAGS) $(OBJECTS) -o $(HEXFILE) - xxd -r -p $(HEXFILE) $(BINARY) - -$(OBJECTS): build/%.rel : %.c $(CSOURCES) dirs crt0.rel - $(CC) $(CFLAGS) -c $< -o $@ - -crt0.rel: crt0.s - sdasz80 -o $< - -dirs: - mkdir -p build build/kernel build/libc - -dis: $(BINARY) - z80dasm -a -g 0h $< -o $(OSNAME).s - -clean: - - rm -rd build/* - - rm $(OSNAME).s - - rm crt0.rel -\end{lstlisting} - -\end{document} 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 \ -I. -c -o \end{verbatim} In cui {\tt } \`e il documento con il codice sorgente e {\tt -} \`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 +} \`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 \ --code-loc= -o $ makebin -s -yo 1 -ya 1 \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 \end{verbatim} -Quindi l'argomento {\tt --no-std-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 } 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} -- cgit v1.2.1