OldComp.cz

Nepsal bych, jak píše l00k, že se magnetofonům signál z počítače nelíbí.

Jde o to, že magnetofony i magnetofonové pásky mají omezený nelineární frekvenční rozsah. Když se na ně zapíše jednou (z kopírovacího programu), je signál bezpečně v toleranci, vyšší frekvence nejsou utlumené tak moc, aby to vadilo, nízké frekvence nejsou tak nízké, aby to vadilo...

K frekvenčnímu rozsahu záznamu na pásku https://en.wikipedia.org/wiki/Compact_C ... rmulations ... liší se podle magnetofonu, magnetického materiálu pásky... U ZXS jsme zapisovali výhradně na pásky železité, na některých je uvedeno "TYPE I NORMAL BIA 120us EQ", ale taky často na pásky levné, východní provenience, na levných magnetofonech.

Ale když analogový signál projde stejnou cestou ještě jednou, tak se na následném záznamu projeví všechny chyby předchozího záznamu plus další útlum vyšších frekvencí plus další šum, plus případně špatně nastavená kolmost hlavy čtecího magnetofonu, další kolísání rychlosti posuvu pásky atd...

Digitalizací a následným zápisem "čistého signálu" se tyhle chyby a útlum odstraní.

Ostatně je to vidět na https://shred.zone/cilla/page/440/r-tap ... error.html Proto ZX Spectrum (a i mnoho jiných počítačů) musí detekovat "průchod nulou" a měřit čas mezi = rozlišuje frekvenci pulzu. Proto je ZX Spectrum relativně odolné vůči špatné kvalitě záznamu. A proto je baudrate tak nízký, protože na vyšších frekvencích (turbo) se víc projeví nekvalita záznamu.

První a možná i druhá kopie na dobře nastaveném "dvojčeti" bývá dobře použitelná. Dokonce i v případě turba.

A jak píše l00k - na ZXS je zvykem ukládat velké bloky. Není pravda, že by data nešla uložit do menších bloků, ale záznam by se tím prodloužil o pilotní tóny (a možná i když ne nutně další hlavičky). Ze zkušenosti - nejspíš by to nepomohlo. Když je záznam poškozený tak, že nejde přečíst napoprvé, málokdy jde přečíst napodruhé. Programátoři měli (v pozdějších dobách) tendenci jít spíš cestou zkracování záznamu kompresí dat a rozdělení na víc bloků by šlo pricipielně proti zkrácení doby načítání.

_________________
https://cygnus.speccy.cz ZX Spectrum 128k, Betadisk, DivIDE, ESXDOS

Kupodivu často platí, že levnější magnetofony ukládají digitální záznam spolehlivěji než drahé profi. Zřejmě proto, že kvalitnější mgf ořezává ostře horní frekvence a deformuje tak víc hrany a fázi. "Zlepšovače audio signálu" jako Dolby nebo chromdioxid jsou pro digitální záznam horší než běžný záznam. U sálových počítačů se používaly speciální digitální kazety, které ale na běžných kazeťácích moc nefungovaly, protože vyžadovaly vyšší záznamový proud.

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement

Aby to niekto nepochopil zle. Týt vyší tón krátký impulzy = 0, a tůt nižší tón dlouhé impulzy = 1.

Samozrejme každý tón je tvorený jednou sínusovkou, čo je najkratšia časť tónu aká môže byť. Ono by išlo spraviť aj aby bol tvorený polovicou sínusovky, ale potom by sa už museli strážiť dáta alebo pridať nejaký pilotný medzitón. Totiž bežný magnetofón sám hľadá stred medzi vrchnou a spodnou polovicou sínusovky záznamu. Pri plnej sínusovke je to v strede, signál je symetrický (dá sa to predstaviť ako vlnovka rôznej hustoty ktorej stredom prechádza vodorovná čiara). Ale keby sme mali uložiť 101010101010 do pol sínusoviek, tak hore máme 1 teda dlhé, dolu 0 teda krátke, a vznikne nesymetrický záznam (vlnovka, ale čiara by prechádza nie v strede, ale o kus nižšie, vrchné časti väčšie ako spodné). Magnetofón by určil stred signálu, a vzniklo by nám čosi, čo je všade rovnaké, teda medzi 1 a 0.

Čo tam bolo ďalej? Ako funguje LOAD? Len stručne: najprv sa čaká na zavádzajúci tón. To je tóninou skoro ako samé 1. Keď sa zistí a v dostatočnej dĺžke, čaká sa až v ňom nastane synchronizačný impulz, teda 0. Ten slúži na nastavenie správnej polarity - signál totiž môže byť aj invertovaný a ničomu to nevadí. Až od tohoto signálu sa určí polarita signálu, teda čo je koniec sínusovky. Potom sa už prijímajú samotné dáta 1 a 0 a z nich sa skladajú byty. 1. byt je značkový (štandardne 0=hlavička, 255=telo, alebo neštandardne akýkoľvek), tak sa neukladá, iba sa porovná s očakávaným a keď sa nezhoduje, tak chyba. Keď sa zhoduje, tak sa nahrávajú do pamäte ďalšie dáta. Posledný je CRC byt ktorý sa neukladá. Pri XORovaní celého záznamu vrátane značkového bytu a CRC musí vyjsť 0, inak je chyba.
Samotné 1 alebo 0 sa prijímajú tak, že sa čaká na 2 krát zmenu stavu vstupu, a tento čas sa počíta. Ak je moc dlhý, tak chyba. Ak je vhodný, tak sa porovná stredný čas medzi 1 a 0, a všetko nad je 1 a pod je 0. Časy sú nastavené pevne (1 je dvakrát tak dlhá ako 0), ale majú určitú toleranciu, takže záznam môže byť v určitých medziach pustený aj pomalšie alebo rýchlejšie.
Len pre zaujímavosť, ja som naprogramoval rutinu, ktorá nemá pevné časy, ale porovnáva ich s predošlými prijatými časmi+dovolená odchýlka. Aj zavádzací tón môže mať akúkoľvek tóninu. Ono keď platí že 1 je vždy 2x 0, tak na rýchlosti vlastne ani nezáleží. Pôvodne pri ZX Spectre mal byť zrejme zavádzací tón unikátny, ale ako iste vieme, berie to ako zavádzací tón aj signál uložených 1. A keď nasledujú uložené 0, vypíše to "Program: ??????????". Ako to? Jednoducho. Dlhší blok jednotiek si myslí že je zavádzací tón. Potom nuly: synchronizačný impulz je nula, značkový byt pre Program je nula, názov na 10 písmen zo znaku číslo nula je interpretovaný ako 10x otáznik, kontrolný súčet samých núl je zasa nula... v podstate je to regulérna hlavička. Čo na tom že záznam pokračuje nulami ďalej. Niekedy som skúšal urobiť hlavičku v strede dát tak, že som uložil dlhší blok #FF, potom #FE, a následne dáta hlavičky (vrátane značkového bytu a CRC). A išla normálne nahrať ako hlavička, pritom to boli dáta v strede bloku.
Ale nejako som sa nechal uniesť.

_________________
Oznamy o novom príspevku mi na mail chodia iba sporadicky, takže keď sa nehlásim v diskusii, tak je to tým. V 80% nepríde mail vôbec.

V pravěku jsem obšlehl kód pro zápis/čtení z kazeťáku s 8251 asi z PMD:

http://www.valachnet.cz/lvanek/diy/old_story/monit.txt

rutiny PUTMGF a následující. Torzo zapojení:

http://www.valachnet.cz/lvanek/diy/old_story/mgf.gif

_________________
RC2014 Pro, RC2014 LittleBro, RC2014 Zed, RC2014 Mini

Jeden taky analyzator priamo pre ZX Spektrum som naprogramoval aj ja, tu je pokec a download (subor rec-just.tap).
Tu by som len upresnil, ze v niektorych pripadoch bolo primarnym dovodom to ze tieto pocitace proste nestihali naraz loadovat data, zaroven vyhodnocovat ich spravnost a ukladat ich na cielove miesto. Loadli preto do buffera urcity blok obmedzenej dlzky, ten sa vyhodnotil ci je OK a ak ano tak sa ulozil na cielove miesto. A az potom boli schopne loadovat dalsi blok dat. Nastastie to obvykle nebolo tym zeby CPU bolo prilis pomale, ale skor preto lebo dizajneri proste vymysleli taku "paketovu" koncepciu a programatori sa jej mali drzat.
Presne s tymto som sa kedysi hodne hral. Ta predstava ze dosiahnem dvojnasobnu rychlost pri nezmenenych potrebach na frekvecne pasmo bola tak lakava ze som sa rozhodol kompletne prepisat load/save rutinky na tento sposob zaznamu s kodovanim bitov do polperiod.
A napodiv to (s +2 kazetakom) aj celkom pekne fungovalo, dokonca ani s 10101010 nebol problem, akurat to obcas sporadicky robilo take zvlastne chyby - ak po vela nulovych bitoch nasledovalo viac jednotkovych bitov, tak posledny nulovy bit to vyhodnotilo ako jednotku. Pri loadovani screenu to bolo pekne vidno - cierne plochy (pri defaultnych farbach INK 0 PAPER 7) mali sem-tam na svojej lavej strane este jeden trciaci pixel navyse
Podla mna ak by som v rutinke poriadne odladil casove konstanty pre rozhodovanie medzi 0 a 1 tak by to mohlo pekne fungovat. Otazka ale je, ci by pre iny kazetak nebolo treba tieto konstany nastavit inak.

Na to by sa našlo riešenie:
00 - dve krátke polperiódy I¯I_I
11 - dve dlhé polperiódy I¯¯I__I
10 - dlhá a krátka, krátka a dlhá I¯¯I_I¯I__I
01 - krátka a dlhá, dlhá a krátka I¯I__I¯¯I_I
čiže by sa ušetrila cca 1/4 času (priemerne 3 polperiódy na 2 bity), a stred signálu by zostal ± zachovaný. Pri nahrávaní 48k hry úspora času vyše 1 minúty.

Nastávali by okamžiky, kdy je tam jen jedna půlvlna, takže to zrovna můžeš použít jen jednu půlvlnu.

_________________
Praxe znamená, že vše funguje, ale nevíme proč. Teorie znamená, že vše víme, ale nic nefunguje.
Někdy je teorie spojena s praxí. Znamená to, že nic nefunguje a nikdo neví proč ...

Zbytocne komplikovane a prinos maly.
To uz je lepsie pouzit napriklad OTLA turbo loader ktory pouziva sice vzdy celu sinusovu periodu (takze nie je problem s magnetofonmi) ale koduje rovno dva bity naraz do styroch roznych dlzok sinusovky:

00 - |¯¯¯¯|____|
01 - |¯¯¯¯¯|_____|
10 - |¯¯¯¯¯¯|______|
11 - |¯¯¯¯¯¯¯|_______|

co mu pri temer nezmenenej potrebe na frekvence pasmo umozni az dvojnasobny tok dat.

Ale OTLA funguje na CD/MP3, ale nie je spolahliva na Emgetonke v mgf . K tomu by uz boli potrebne nejake samoopravne algoritmy.

Jasne, ale to nie kvoli vyssie popisanemu sposobu modulacie, ale kvoli tomu ze pouziva aj ovela vyssie frekvencie (kratsie periody sinusoviek). Pokial by sa pouzilo frekvencne pasmo podobne ako klasicke 1500Bd (popr. 3000 Bd) tak by to pekne fungovalo aj s paskou.

Za ideálnych okolností a kvalitnej technike áno. Keď si spomeniem, ako kolísala rýchlosť pri prehrávaní na našom tuzexovom mgf, tak asi by to celkom spoľahlivé nebolo. Ale stálo by za pokus otestovať to.