<div dir="ltr"><div><div><div><div><div>Ja by som baudy videl ako pocet bitov prenesenych za sekundu, nie pocet zmien fyzickeho signalu.<br><br></div>Obsah, presnejsie pomer logickych 1 a 0 v datach ovplyvni celkove trvanie a tym aj rychlost. Ak v datach su same nuly, moze to teoreticky vystupat takmer na dvojnasobok oproti suboru so samymi jednotkami. Statisticky bude presna hodnota kolisat okolo tych 1300 baud ako si spocital. Preco bol zvoleny zapis 1200 je asi skor vec marketingu alebo konvencie v tom case.<br><br></div>Poznamka o zbytocnej dlzke low pri logickej jednotke je trefna, pri implementacii mojho nastroja mzf2wav som ho skratil v oboch pripadoch na short, efekt je vsak dost nevyznamny.<br></div><div>Zapisy v nasobkoch hodnoty 1200 len hovoria o prislusnom deleni casovych konstant na polovicu, tretinu..., stale plati to, ze realna rychlost kolise podla obsahu.<br></div><br></div>Mimochodom, experimentoval som s rôznymi novymi turbo rezimami, kde napr kodovanie log. 1/0 bolo riesene cez hrany, nie stav HI/LO v case X ms po hrane (podobne funguje ciarovy kod). Dalsou verziou bolo kodovanie dvoch bitov (00/01/10/11) do styroch roznych dlziek HI signalu. To usetri nejaky balast, ale zrychlenie nie je prilis vyznamne. V kombinacii so skratenim casovych konstant to bolo ale celkom slusne. Davnejsie som do konfery posielal vzorku WAV pre basic, Zdenek to prehnal cez emu a slapalo to, avsak realny sharp s tym mal problem.<br><br></div>Feri<br><div><div><div><br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-03 13:15 GMT+02:00 Michal Hucik - ORDOZ <span dir="ltr"><<a href="mailto:ordoz@ordoz.com" target="_blank">ordoz@ordoz.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<p><font size="+1">Snazim se vytvorit nejake kompendium o logickych
a fyzickych CMT formatech. Nicmene stale mi unika zpusob jakym
se vlastne urcuje baudova rychlost. Definice rika, ze se jedna o
pocet zmen signalu za sekundu....</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">Analogovy format:<br>
===============<br>
</font></p>
<p><font size="+1">Hodnota < 0 reprezentuje logickou uroven "1".
Hodnota >= 0 reprezentuje hodnotu "0".<br>
</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">Fyzicky format pulzu:<br>
=================<br>
</font></p>
<p><font size="+1">Rozlisuje dva typy "slov" Long Pulse a Short
Pulse, ktere se skladaji z logickych urovni "1" a "0".</font></p>
<p><font size="+1">Zakladni Sharp </font><font size="+1"><font size="+1">format </font>definovany servisnim manualem ma Long
Pulse: 470 us ve stavu "1" a 494 us ve stavu "0" (celkem 964
us). Short pulse: 240 us v "1" a 278 us v "0" (celkem 518 us). <br>
</font></p>
<p><font size="+1">Dale je v komentovanem vypise uvedeno, ze
readpoint je situovan 379 us od vzestupne hrany.</font></p>
<p><font size="+1"><br>
</font></p>
<p><font size="+1">1200 baudu?<br>
===========<br>
</font></p>
Jak uz bylo receno, tak baudova rychlost definuje pocet zmen v
modulovanem signalu za 1 sekundu. Mam tomu rozumet tak, ze Long
Pulse i Short pulse je slozen ze dvou zmen (vzestupna a sestupna
hrana)? V nasi definici slov jsme schopni za sekundu prenest bud
1930 Short "0" bitu, nebo 1037 Long "1" bitu. S poctem zmen signalu
se tato cisla vynasobi 2x.<br>
<br>
V definici Bd je uvedeno, ze u starych zarizeni platilo, ze 1 Bd = 1
bit, nicmene u novych zarizeni je pocet bitu na 1 Bd vyssi (chapu,
ze napr. modemy dokazi rozlisovat zda napetovy pulz sel nahoru, ci
dolu a nebo to o kolik mV se signal zmenil a tim tedy kodovat do
prenosu vice informaci, nez jen 0 a 1). Predpokladam, ze Sharp
samozrejme spada do kategorie techto starych zarizeni a tato
definice pak navadi k tomu, ze "pocet zmen" neodpovida skutecnemu
poctu napetovych zmen, ale "poctu informacnich zmen" ... Stale vsak
se takto nedoberu k hodnote 1200 Bd.<br>
<br>
Aritmeticky stred poctu Long a Short za sekundu je 1483. <br>
<br>
Aritmeticky stred delky Long a Short pulzu je 741 us ... 1 /
0.000741 = 1349 (tim jsme zatim k tem 1200 Bd asi nejblize).<br>
<br>
Podstatnou slozkou prenosu je ten vyse zminovany read point ze
ktereho plyne, ze je vzdy dulezite presne dodrzet delku te prvni
casti pulzu, zatimco druha polovina muze byt vlastne libovolne
dlouha.<br>
Vlastne v tuto chvili moc dobre nechapu duvod, proc Long Pulse a
Short Pulse nemaji tu druhou polovinu pulzu stejne dlouhou? <br>
<br>
Vychazime-li z toho, ze 1 Bd = 1 bit, tak je rychlost urcena delkou
doby po ktere nasleduje read point + delkou read pointu + nacitenim
klidove casti pulzu, coz by melo byt zhruba stejne jako je
readpoint.<br>
Vime, ze Short Pulse trva 518 us po odecteni read pointu nam zbyva
139 us, pricemz neco z toho jeste musi byt rezerva...<br>
<br>
1 / 1200 = 833 us<br>
<br>
Znate nekdo nejaky oficialni vzorec, ktery by mne z techto hodnot
dovedl k tem 1200 Bd?<br>
<br>
Mereni:<br>
=======<br>
<br>
Intercopy 10.2 umi m.j. po nacteni hlavicky programu vypsat
informaci o Bd. <br>
Udelal jsem na Sharpu nejaka mereni. Ulozil jsem vzdy stejny soubor
z ROM, Turbo Copy a v Intercopy - CMT vystup jsem nahral do WAV a
pak jsem to nacital a meril v Intercopy 10.2.<br>
Zaroven jsem mel na vystupu z 8255 pripichnuty logicky analyzer a
pri SAVE jem meril delky pulzu. Nize uvedena hodnota Bd je to, co mi
o tom zaznamu rekl Intercopy, kdyz jsem se to snazil z tech WAV
zpatky nahrat:<br>
<br>
ROM 1/1: 1152 Bd, Long: 469 us / 487 us, Short: 238 us / 259 us<br>
<br>
(Delky pulzu z Turbo Copy byly dost rozlitane - snazil jsem se
udelat nejaky prumer)<br>
TC 1/1: 1152 Bd, Long: 497 us / 497 us, Short: 250 us / 245 us<br>
TC 2/1: 2043 Bd, Long: 282 us / 283 us, Short: 141 us / 139 us<br>
TC 3/1: 2756 Bd, Long: 208 us / 206 us, Short: 105 us / 104 us<br>
<br>
(Delky pulzu z Intercopy byly vetsinou velice presne - je videt, ze
Marek odvedl precizni praci)<br>
IC 1200: 1149 Bd, Long: 470 us / 495 us, Short: 235 us / 264 us<br>
IC 2400: 2262 Bd, Long: 235 us / 260 us, Short: 114 us / 139 us<br>
IC 2800: 2701 Bd, Long: 177 us / 224 us, Short: 88 us / 125 us<br>
IC 3200: 2945 Bd, Long: 178 us / 223 us, Short: 88 us / 124 us<br>
<br>
Formaty:<br>
=======<br>
<br>
Marek ma v Intercopy 10.2 uveden normalni MZ format, ktery tam
disponuje rychlostma 600, 1200, 2400, 2800 a 3200.<br>
Dale tam ma CP/m format (program tape), ktery ma mozne rychlosti
1200, 2400, 2800, 3200 a 3600.<br>
<br>
Vzdycky jsem si myslel, ze cp/m tape a sharp format jsou identicke,
akorat ze cp/m je nativne v rychlosti 2400. Ten rozdil v maximalni
rychlosti vsak naznacuje, ze je to mozna jinak. Vite o tom nekdo
neco?<br>
<br>
Je mozne, ze <a href="http://tape.com" target="_blank">tape.com</a> podporuje vice typu fyzickych, ci zaznamu.
Kazdopadne pokud v Intercopy ulozim jeden a ten samy soubor v Normal
2400 a v CPM 2400, tak pri zpetnem nacitani to Intercopy umi
rozlisit a u kazdeho pak napise bud Normal, nebo cp/m.<span class="HOEnZb"><font color="#888888"><br>
<br>
Michal<br>
<br>
</font></span></div>
<br>______________________________<wbr>_________________<br>
SharpMZ mailing list<br>
<a href="mailto:SharpMZ@mail.ordoz.com">SharpMZ@mail.ordoz.com</a><br>
<a href="http://mail.ordoz.com/mailman/listinfo/sharpmz" rel="noreferrer" target="_blank">http://mail.ordoz.com/mailman/<wbr>listinfo/sharpmz</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div></div>