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>Ahoj Feri, Ja psal autorovi T7ZX (resp. nejakemu jeho kamosovi) - dostal jsem od nej velice <img src="BODY_IMAGES_WRAP_GIF"> kratkou odpoved s moznosti kontaktu primo autora. Chtel jsem nejakym zpusobem <img src="BODY_IMAGES_WRAP_GIF">pochopit primo RAUDO metodu, ta se mi jevila jako nejrychlejsi s dostatecnou <img src="BODY_IMAGES_WRAP_GIF">spolehlivosti. Lec jsem dostal nasledujici odpoved - viz dole. Jak se zda, nekdo adaptoval rychlonahravani i na jine platformy, nez je Speccy. <img src="BODY_IMAGES_WRAP_GIF">Ale zatim jsem nemel cas to nijak hledat... Vasek I don't recommend the 'Raudo' method. It's a very complicated algorithm which <img src="BODY_IMAGES_WRAP_GIF">takes advantage of things that are only available in the Spectrum. I suggest to start with something a lot simpler like FSK and then try Shavings <img src="BODY_IMAGES_WRAP_GIF">Slow, which is now being used by Amstrad and MSX users." <span class="replyquote1">> ------------ Původní zpráva ------------ > Od: Feri (sharpemu@pandora.cz) > Předmět: =?iso-8859-2?Q?nov=FD turbo loader - pros=EDm reakciu?= > Datum: 23.6.2008 17:57:16 > ---------------------------------------- > > > takže, ľudia čo tu upozornili na spektristov s ich rýchlym > nahrávaním ma vyburcovali ku klasickému "a čo my sme horší?" a tak som > sa rozhodol spraviť nejaké to turbo ktoré by bolo aspoň zčasti tak > rýchle ako to vybájnené spektrácke... > > 1) > nemám v úmysle loviť baudy - ich 5 miestne cifry s rýchlosťou ma > nechávajú chladným, podľa mňa je podstatná životaschopnosť a > jednoduchosť (vždy tvrdím, že v jednoduchosti je genialita) > > 2) mojim cieľom je aspoň niekoľkonásobne pokoriť doterajšiuu "magickú <img src="BODY_IMAGES_WRAP_GIF">hranicu" > trojnásobnej rýchlosti (tzn. pre začiatok budem spokojný s tak 6-10 <img src="BODY_IMAGES_WRAP_GIF">násobkom > základnej rýchlosti) > > 3) zatiaľ ma to baví, výsledky nesľubujem, ale je to zatiaľ na dobrej <img src="BODY_IMAGES_WRAP_GIF">ceste. > > > KONCEPCIA: > inšpiroval > som sa spektráckymi loadermi a mám návrh, ako získať rýchlosť: > doterajšie loadery (ako už bolo napísané v mojom minulom príspevku) <img src="BODY_IMAGES_WRAP_GIF">zachovávajú > sharpovský > logický formát zápisu (každý bit kódovaný ako nábežná hrana, dlhší <img src="BODY_IMAGES_WRAP_GIF">alebo kratší > peak, rovnako > dlhý low signal, a tak dokola) - toto si spektristi zmenili a m7zx > funguje na princípe kódovania rovno dvoch bitov v jednej vlne - prvý bit <img src="BODY_IMAGES_WRAP_GIF">kóduje > dĺžka > peaku, druhý bit kóduje dĺžka low signálu - teda presne ako to robí <img src="BODY_IMAGES_WRAP_GIF">mnou > spomínaný čiarový kód. to dáva teoretické zdvojnásobenie > rýchlosti - skombinované s extrémnym skrátením časových konštánt na > niekoľkonásobok to teoreticky dáva (vraj) viac ako 20 násobok základnej > rýchlosti... > > moja > koncepcia vychádza zhruba podobne, až na to že dĺžka peeku nebude > dvojstavová (0/1), ale 2^n stavová, čím zakódujeme n bitov v jednej <img src="BODY_IMAGES_WRAP_GIF">polvlne. > potom prichádza na rad voľba vhodného n: > - pre n = 1 je to to čo majú spektristi, bajt je kódovaný štyrmi vlnami <img src="BODY_IMAGES_WRAP_GIF">max. > dvojnásobnej dĺžky; (pomer 18/10 =&gt; 14) > - pri n = 2 sa bajt zakóduje na 4 vlny max. štvornásobnej dĺžky; (pomer <img src="BODY_IMAGES_WRAP_GIF">18/6 > =&gt; 12) > - pri n = 3 (presnejšie 3+3+2) sa bajt zákóduje na dve vlny osem (resp. <img src="BODY_IMAGES_WRAP_GIF">štvor) > -násobnej dĺžky; (21/4 =&gt; 12,5) > - n &gt; 3 nemá význam - dĺžka vlny by bola 16, 32, ... násobkom <img src="BODY_IMAGES_WRAP_GIF">pôvodnej a to > je už neefektívne... > > čísla v zátvorke znamenajú počet jednotiek času potrebné na <img src="BODY_IMAGES_WRAP_GIF">zakódovanie bajtu > $FF/$00, za šípkou je priemerná dĺžka pri štatisticky rovnomernom <img src="BODY_IMAGES_WRAP_GIF">rozložení núl > a jednotiek. jednotka času zodpvedá zhruba dvom samplom, takže <img src="BODY_IMAGES_WRAP_GIF">teoretická > rýchlosť pri ~12 je cca 24 samplov na bajt, takže cca 14700 baud (ak by <img src="BODY_IMAGES_WRAP_GIF">sme > chceli spektristov tromfnúť, tak nahranie programu zo samých NOPov by sa <img src="BODY_IMAGES_WRAP_GIF">dalo > rýchlosťou trojnásobnou - teda cca 44100 baud). výsledné číslo sa <img src="BODY_IMAGES_WRAP_GIF">možno kvôli > stabilite zníži, prípadne pri obetovaní spoľahlivosti, naopak, zlepší <img src="BODY_IMAGES_WRAP_GIF">:-) > > mne osobne z toho vychádz víťaz n=2 (ale pocitovo sa mi páči skôr 3, <img src="BODY_IMAGES_WRAP_GIF">pretože > všetky párne kódovania majú jednu zbytočnú hranu na konci, a navyše <img src="BODY_IMAGES_WRAP_GIF">rozličnejšia > dĺžka vlny (tzn. namiesto striedania dvoch frekvencií tam bude 8 <img src="BODY_IMAGES_WRAP_GIF">frekvencií) > bude mať asi coolovejší zvuk :-) > > do pléna dávam otázky: > 1) loader sa mi zatiaľ zmestí do hlavičky, takže sa rýchlejšie spustí. <img src="BODY_IMAGES_WRAP_GIF">takto ale > funguje len na single programy (štýlu basic). ak by mal loader fungovať aj <img src="BODY_IMAGES_WRAP_GIF">na > multiparty (wooky, saboteur...), tak ho treba realokovať, aby ho hlavička > ďalšieho bloku neprepísala. zvažujem pod D000 (tesne pod VRAM). má niekto <img src="BODY_IMAGES_WRAP_GIF">iný > nápad kam umiestniť cca 100 bajtov kódu? > > 2) mám vôbec robiť loader pre multiparty? ak áno, budú musieť byť dve <img src="BODY_IMAGES_WRAP_GIF">verzie > loadera, pre singleparty (v hlavičke) a pre multiparty (realokovaný). > > 3) je dôležité testovanie SHIFT+BREAK? zaberá zbytočne miesto, nie je > jednoduchší reset? > > > zatiaľ všetko, čakám na feedback... > > Feri > > > > > > === reklama ====================================== > > http://mail.szm.com - e-mail a priestor na www stranku zadarmo > > http://webhosting.szm.com - domeny a webhosting za najnizsie ceny > > > > > > --- > > > </pre>