Původní podoba příspěvku

Surová data tak, jak byla v roce 2013 stažena z Pandory (HTML zdroj bez úprav, osobní e-mailové adresy jsou maskované).

<!-------------------------------------------------------------->
<table width="100%"><tr><td align="left" valign="middle"></td><td align=right valign="middle"></td></tr></table><BR><pre><span class="replyquote1">&gt; ------------ Původní zpráva ------------
&gt; Od: Zdenek Adler (sharpemu@pandora.cz) 
&gt; 
&gt; - No, myslim ze pouziti ext. procesoru by bylo na miste. Preci nebudeme 
&gt; Sharpa zatezovat souborovymi operacemi a rvanim se s FATkou a podobnymi 
&gt; nechutnostmi. Idealni by opravdu bylo nechat vsechnu praci na ext. procesoru
&gt; aby Sharp uz ziskaval jen surova data. Pak by nebyl problem hrat treba 
&gt; samplovanou hudbu aj.
</span>
Tedy, navrhuji, ac mam PICy opravdu rad a umim s nimi, ATMEGA8( pak32) s 1k
datove RAM, 16MIPS, programovanim v GCC a cenou cca 35Kc. Aspon budu
mit padny duvod se s touto platformou naucit :-)

<span class="replyquote1">&gt; - No, taky jsem spise na stourani do hardwaru a software pisu jen kdyz me k 
&gt; tomu prinuti okolnosti. Kdyby se k tomu prihlasil nekdo schopnejsi (halooo, 
&gt; Romane, jsi tu? :-))), byl bych hrozne rad. Myslim ze by pro zacatek stacil 
&gt; i nejaky souborovy manazer nezavisly na CPM (NIPOSu).
</span>
To podle meho nazoru neni uplne dobre reseni, OS _MUSI_ zajistovat zakladni
sluzby pro vsechny sve ovecky - programy. Pristup k periferiim, pristup k
<img src="BODY_IMAGES_WRAP_GIF"> souborum.

Spise bych to tlacil cestou nativni podpory FAT16 v NIPOSu, pricemz nejnizsi
<img src="BODY_IMAGES_WRAP_GIF">vrstva
bude implementovana v ATMEGA (8kB na testovani, pak napr.32kB jako
<img src="BODY_IMAGES_WRAP_GIF">full-featured).

V kazdem pripade, ja potreba se domluvit aspon na meziobliceji:
- ATMEGA se musi chovat pro boot stejne jako ROMDISK
- pak pro OS zajisti zakladni operace - zapis, cteni souboru

Vasek
</pre>