OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů


Právě je 31.01.2023, 04:48

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 18 ]  Přejít na stránku 1, 2  Další
Autor Zpráva
PříspěvekNapsal: 17.02.2022, 11:24 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
Jaký je váš názor na to, jak by se měla správně počítat baudová rychlost u streamu, který je ukládán na magnetofonový pásek?

V úvaze budu vycházet z hodnot a protokolu, který odpovídá specifikaci pro Sharp MZ-800, nicméně uvítám, když se nám tady podaří najít vzorec, který bude dle vstupní konfigurace aplikovatelný na libovolný CMT stream.
Mým cílem je to, abych podle vstupní specifikace délky pulzů uměl přesně určit baudovou rychlost.

Tedy vstupní specifikace CMT streamu MZ-800, který je oficiálně presentován jako 1200 Bd:

- short pulse "0" = 240 us (HI) + 278 us (LO)
- long pulse "1" = 470 us (HI) + 494 us (LO)
- za každým odeslaným bajtem následuje stop bit, který je presentován jedním long pulzem

Úvaha:

Do jedné sekundy se vejde buď 1930 short, nebo 1037 long - průměr je 1483 pulzu.

Do jedné sekundy se vejde 195 bajtů s hodnotou 0x00, což se i se stopbitama 1761 pulzů.

Do jedné sekundy se vejde 115 bajtů s hodnotou 0xff, což se i se stopbitama 1037 pulzů, což se shoduje s výše uvedeným proveditelným počtem long pulzů v jedné sekundě.

Do jedné sekundy se vejde 145 bajtů s hodnotou 0x55, což se i se stopbitama 1305 pulzů.

Z výše uvedených hodnot není nic, co by se nějak smysluplně blížilo hodnotě 1200 Bd.

Při "čarování" s čísly jsem se nejblíže k 1200 Bd dostal s výpočtem ( 1 / ( (short*1) + (long*2) ) ) * 3 = 1226 pulzů.

Michal


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 12:16 
Offline
Profík
Uživatelský avatar

Registrován: 21.01.2021, 11:05
Příspěvky: 901
Bydliště: Pardubice
Has thanked: 3 times
Been thanked: 94 times
Myslím, že střídání jedniček a nul 0x55 je optimální. V některých příručkách Sharpu se píše 1350Bd

_________________
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č ...


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 12:30 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
Aha, to by celkem sedělo (1 / (short + long) ) * 2 = 1349.52


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 12:36 
Offline
Profík
Uživatelský avatar

Registrován: 21.01.2021, 11:05
Příspěvky: 901
Bydliště: Pardubice
Has thanked: 3 times
Been thanked: 94 times
Nevím proč kvůli zrychlení nepoužili jen jednu půlvlnu, bylo by to jednou tak rychlejší.

_________________
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č ...


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 13:38 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2554
Has thanked: 130 times
Been thanked: 349 times
MilasPce píše:
Nevím proč kvůli zrychlení nepoužili jen jednu půlvlnu, bylo by to jednou tak rychlejší.


Kvuli moznym kondenzatorum na ceste je potreba zajistit aby log0 a log1 byl pokud mozno stejny, aby stredni hodnota signalu byla konstantni. Jinak v jinem vlakne http://oldcomp.cz/viewtopic.php?f=133&t=10445 to pisi.

Vzorec pro vypocet rychlosti je:
240+278+470+494=1482 us
baudu 1/(1482*10^-6) = 1349,53

Jinak jak se to realne resilo v roce 1989 byl algoritmus ze se vynuloval citac 8253. Pak nactete primerene mnozstvi short impulsu na zacatku souboru (pilot signal). Vite ze jsou vsechny stejne dlouhe. Pak to to trivialne podelite, idelani je cislo 16 nebo neco podobneho. Pak dostanete hodnotu pro jeden impuls. Neni problem delat korekce i pri nahravani dat z cmt.

===

jeste vzorec na vypocet toho 1200 baudu:

Kód:
short   long         
240   470         
278   494         
518   964         
            
2072   (4x short)
4820   (5x long)
6892   celkem
861,5   /8 - prenasi se 8 bitu - ten jeden long "zpomaluje"
0,0008615 s
1160,766 baudu



Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 13:50 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2554
Has thanked: 130 times
Been thanked: 349 times
chaky píše:
- za každým odeslaným bajtem následuje stop bit, který je presentován jedním long pulzem

Chaky podivej se do zdrojaku romky. Na adrese 0767h je zapis jednoho bajtu, rutina WBYTE. Long impuls je pred vlastnim zapisem bajtu, ne az potom.


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 14:12 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
Jo jasně, je to samozřejmě start bit. Jinak těch 1160 Bd už je asi nejblíže tomu, co počítá Marek Šmihla v Intercopy pro 1:1 Sharp CMT speed.

Bude to takhle sedět i pro CMT stream ze ZX? Intercopy v ZX formátu aplikuje pro shrot 2 * 241 us a pro long 2 * 483 us. Tam mi potom vychází 1183 Bd, nicméně Marek tam tvrdí, že je to 1400 Bd - samozřejmě nikde nemám ověřeno, že ty časy tam má Marek nastavené správně.


suksoft píše:
chaky píše:
- za každým odeslaným bajtem následuje stop bit, který je presentován jedním long pulzem

Chaky podivej se do zdrojaku romky. Na adrese 0767h je zapis jednoho bajtu, rutina WBYTE. Long impuls je pred vlastnim zapisem bajtu, ne az potom.


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 14:27 
Offline
Profík
Uživatelský avatar

Registrován: 21.01.2021, 11:05
Příspěvky: 901
Bydliště: Pardubice
Has thanked: 3 times
Been thanked: 94 times
suksoft píše:
Kvuli moznym kondenzatorum na ceste je potreba zajistit aby log0 a log1 byl pokud mozno stejny, aby stredni hodnota signalu byla konstantni.

To je blbost. To se děje vrámci jedné půlvny je jedno kolik jich jde zasebou.

_________________
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č ...


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 14:36 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2554
Has thanked: 130 times
Been thanked: 349 times
MilasPce píše:
suksoft píše:
Kvuli moznym kondenzatorum na ceste je potreba zajistit aby log0 a log1 byl pokud mozno stejny, aby stredni hodnota signalu byla konstantni.

To je blbost. To se děje vrámci jedné půlvny je jedno kolik jich jde zasebou.


Ale ta log0 a log1 jsou prave ty pulvlny. Je dulezite aby ta "sinusovka" alespon trosku vypadala. Sice u Sharpa s vnitrnim cmt jsou to jen dve hodnoty ale u externiho kazetaku uz je to dulezite.


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 14:43 
Offline
Profík
Uživatelský avatar

Registrován: 21.01.2021, 11:05
Příspěvky: 901
Bydliště: Pardubice
Has thanked: 3 times
Been thanked: 94 times
Ten kondík se nabije náběžnou hranou a sestupnou se vybije. Proto, že se to pořád střídá funguje to a nemůže se kondík nabít do saturace. Kolmost hrany závisí jen na horním přenosovém kmitočtu zařízení a je stejná pro krátký i dlouhý impulz. Proto, že to generují obdélníky z logických obvodů je kolmost přechodu vždy stejná.

_________________
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č ...


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 14:49 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2554
Has thanked: 130 times
Been thanked: 349 times
Chaky podle mne 1183 baudu je hodnota "uzitecnych dat". Hodnota 1400 baudu (vypoctena 1383) je realna rychlost jednoho bitu. To je cislo co musi znat vlastni program co zapisuje (cte) data. Programatora rutinky nezajima nejakych 1200 baudu ale 1400 baudu. To je doba (cislo) kdy se ma menit polarita signalu. Jak jsem jiz psal, resilo se to tak, ze se cekalo na nabeznou hranu. Vynuloval se citac 8253. Pak se cekalo az bude signal na log0. Vzalo se cislo z 8253 a pricetlo se HL. To se udelalo 16x. Pak se vysledek podelil rotaci a mel jsi presne cislo jak v prumeru trva jeden pultakt. Algoritmus jsem napsal hodne strucne.

Samozrejme jsi mohl cislo upravovat. Na zacatku kazety mohlo byt jine nez na konci.


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 14:54 
Offline
Profík
Uživatelský avatar

Registrován: 21.01.2021, 11:05
Příspěvky: 901
Bydliště: Pardubice
Has thanked: 3 times
Been thanked: 94 times
Ty pošleš změnu z TTL které má přenosovou rychlost 16MHz do NF obvodů který má 5kHz pak každá hrana po průchodu NF zesilovačem bude odpovídat úhlu který by byl jako ze sinusovky 5kHz a je jedno střídáš-li ty hrany po 1kHz nebo 2kHz budou stejné jen se bude lišit časový odstup.

_________________
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č ...


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 16:43 
Offline
Pan Generální

Registrován: 22.05.2013, 21:14
Příspěvky: 3375
Bydliště: Bratislava
Has thanked: 351 times
Been thanked: 703 times
chaky píše:
Do jedné sekundy se vejde 195 bajtů s hodnotou 0x00, což se i se stopbitama 1761 pulzů.
Do jedné sekundy se vejde 115 bajtů s hodnotou 0xff, což se i se stopbitama 1037 pulzů
Tak to nazvime variable bit rate, ktory sa meni v intervale od 1037 do 1761 Bd ... a je to :)
MilasPce píše:
Nevím proč kvůli zrychlení nepoužili jen jednu půlvlnu, bylo by to jednou tak rychlejší.
Pretoze to s iba jednou polvlnou, vzhladom na specifika analogoveho zaznamu a beznych kazetakov proste neslo.

Ked uz som kedysi davno robil rozne exoticke loadery, tiez ma napadlo, ze by mohla na jeden bit stacit jedna polvlna. Napisal som si kompletne SAVE aj LOAD co funguje na jednej polvlne, vsetko sice islo 2x rychlejsie, ale bolo to velmi nespolahlive. Niektore nulove bity s kratsou polperiodou, za ktorymi nasledovali jednotkove bity s dlhsou polperiodou, sa sporadicky vyhodnocovali ako jednotkove.

Mozno keby som mal nejaky specialny kazetak urceny na datovy zaznam, ktory dokaze lepsie pracovat s jednosmernou zlozkou signalu, ze by to slo, ale s beznym kazetakom, urcenym na hudbu, to bolo proste nespolahlive. Mam taku teoriu, cim by to mohlo byt. Vstupny komparator sledujuci signal sa nepreklapa presne v nulovej urovni, ale v inej, pri ktorej dany priebeh signalu (frekvencne spotvorena sinusovka) da vo vysledku ine casove parametre ktore ktore mozu prekrocit rozhodovaciu hranicu medzi 1 a 0.


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 17:43 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2554
Has thanked: 130 times
Been thanked: 349 times
Tady si asi MilasPce nerozumime. Ja rikam ze pri signalu Short se da vystup WRITE do log1. Tam je po dobu 240 us. Pak se nastavi log0 a ta je nasledujicich 278 us. To udela jeden impuls o frekvenci 1930 Hz.

Kdyz by jsi snizil dobu pri log0 na nejakou malou hodnotu, tak kondenzator C65 by se nestacil vybit a postupne by se vice a vice nabijel az by se uplne nabil a prestal by prenaset data.


Nahoru
 Profil  
 
PříspěvekNapsal: 17.02.2022, 17:58 
Offline
Kecálek

Registrován: 07.05.2014, 12:10
Příspěvky: 190
Bydliště: Jbc
Has thanked: 0 time
Been thanked: 35 times
Busy píše:
Mozno keby som mal nejaky specialny kazetak urceny na datovy zaznam, ktory dokaze lepsie pracovat s jednosmernou zlozkou signalu, ze by to slo...

Uz samotny princip snimani magnetickeho zaznamu je bez stejnosmerne slozky, takze uz pri prevodu magnetickeho zaznamu s nenulovou stejnosmernou slozkou na elektricky signal by dochazelo ke zkresleni.


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 18 ]  Přejít na stránku 1, 2  Další

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 1 návštěvník


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
cron
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz