Celé vlákno · 8 zpráv

Áno, toto som si všimol aj ja. Lenže háčik je možno v medzerách medzi pulzami. Nemôžeš mať predsa skok z 1 na 0 a okamžite skok z 0 na 1. Nejaká medzera tam musí byť. To tam ale popísané tuším nie je, že koľko sú tie medzery.

Miloš

Chystam se napsat k emulatoru virtualni CMT. Divam se do servisniho manualu ve kterem pisou, ze short pulse trva 518 us a long pulse trva 964 us. Podle techto informaci to znamena, ze za sekundu uplyne bud cca 1930 short, nebo 1037 long pulsu.

Nejak mi v tom unika vztah k tem 1200 baudum. Je to nejak zprumerovano? Jakym zpusobem?

Vzhledem k tomu, ze long reprezentuje bity s hodnotou 1 a short bity s hodnotou 0, tak je jasne, ze se rychlost bude menit podle toho jak vypadaji data, nicmene ani v pomeru 50:50 mi z toho tech 1200 nevychazi.

Michal

_______________________________________________
SharpMZ mailing list
SharpMZmail.ordoz.com
http://mail.ordoz.com/mailman/listinfo/sharpmz

Áno, toto som si všimol aj ja. Lenže háčik je možno v medzerách medzi pulzami. Nemôžeš mať predsa skok z 1 na 0 a okamžite skok z 0 na 1. Nejaká medzera tam musí byť. To tam ale popísané tuším nie je, že koľko sú tie medzery.

Co vim tak impuls Long i Short ma log1 a log0 vzdy stejne dlouhe.  Viz http://www.sharpmz.org/mz-800/download/MZ800_Technical_reference_manual.pdf strana 26.

Radek

Áno, toto som si všimol aj ja. Lenže háčik je možno v medzerách medzi pulzami. Nemôžeš mať predsa skok z 1 na 0 a okamžite skok z 0 na 1. Nejaká medzera tam musí byť. To tam ale popísané tuším nie je, že koľko sú tie medzery.

Miloš

Dňa 14. 12. 2014 11:56 Michal Hucik - ORDOZ wrote / napísal(a):

Chystam se napsat k emulatoru virtualni CMT. Divam se do servisniho manualu ve kterem pisou, ze short pulse trva 518 us a long pulse trva 964 us. Podle techto informaci to znamena, ze za sekundu uplyne bud cca 1930 short, nebo 1037 long pulsu.

Nejak mi v tom unika vztah k tem 1200 baudum. Je to nejak zprumerovano? Jakym zpusobem?

Vzhledem k tomu, ze long reprezentuje bity s hodnotou 1 a short bity s hodnotou 0, tak je jasne, ze se rychlost bude menit podle toho jak vypadaji data, nicmene ani v pomeru 50:50 mi z toho tech 1200 nevychazi.

Michal

_______________________________________________
SharpMZ mailing list
SharpMZmail.ordoz.com
http://mail.ordoz.com/mailman/listinfo/sharpmz

_______________________________________________
SharpMZ mailing list
SharpMZmail.ordoz.com
http://mail.ordoz.com/mailman/listinfo/sharpmz

Máš pravdu, práve to pozerám. Ostáva ti len previesť MZF na WAV a kuknúť to tam. Alebo ideálne nahrať WAV zo Zdeňkovho emulátora.

No a keď už spomínaš CMT, jeden z mojich nápadov, ktorý by si mohol skúsiť realizovať je automatická detekcia rýchlosti čítania. Niektoré programy vyžadujú 2x rýchlosť (napr. Saboteur). Pri testovaní portov by si zistil ako sa často testuje a podľa toho by si automaticky zaradil rýchlosť. Síce to nie je až tak jednoduché na prvý pohľad, ale myslím, že by to šlo urobiť.

Miloš

Ne Milosi, tam zadne mezery nejsou.

Dne 14.12.2014 v 12:11 Miloš napsal(a):

Áno, toto som si všimol aj ja. Lenže háčik je možno v medzerách medzi pulzami. Nemôžeš mať predsa skok z 1 na 0 a okamžite skok z 0 na 1. Nejaká medzera tam musí byť. To tam ale popísané tuším nie je, že koľko sú tie medzery.

_______________________________________________
SharpMZ mailing list
SharpMZmail.ordoz.com
http://mail.ordoz.com/mailman/listinfo/sharpmz

Ahoj, řekl bych, že původní záměr byl něco podobného tehdejšímu "standardu" tedy modemům Bell 202.
Pro 1200Bd tehdy používal modulaci 1200Hz pro log.1 a 2200Hz pro log.0. Tady vzhledem k použitému médiu a co nejjednodušší filtraci byl zrušený konstantní datový tok, vysoký tón zkrácen na jednu periodu a frekvence signálu se počítá dobou trvání mezi reverzacemi na pásce. Zachované je tu rozlišení log.1 a 0 a taky poměr mezi jejich frekvencemi (cca 11/6). No a když se podle datasheetu spočítá průměrná Bd rychlost (se započítáním synchronizační log.1 po každých 8mi bitech) vychází mi 1161Bd (což by se v propagačních materiálech už na 1200Bd zaokrouhlit dalo :) ).

Ale to vše jsou jen mé domněnky, Japonským inženýrům z minulého století do hlavy nevidím (a i kdybych viděl, stejně bych asi nepochopil :) ).

Bohouš

Zobrazit citovaný text

---------- Původní zpráva ----------
Od: Michal Hucik - ORDOZ <ordoz[doména skryta]>
Komu: sharpmzmail.ordoz.com
Datum: 14. 12. 2014 11:57:38
Předmět: [SharpMZ] CMT rychlost 1200 baudu

Chystam se napsat k emulatoru virtualni CMT. Divam se do servisniho manualu ve kterem pisou, ze short pulse trva 518 us a long pulse trva 964 us. Podle techto informaci to znamena, ze za sekundu uplyne bud cca 1930 short, nebo 1037 long pulsu.

Nejak mi v tom unika vztah k tem 1200 baudum. Je to nejak zprumerovano? Jakym zpusobem?

Vzhledem k tomu, ze long reprezentuje bity s hodnotou 1 a short bity s hodnotou 0, tak je jasne, ze se rychlost bude menit podle toho jak vypadaji data, nicmene ani v pomeru 50:50 mi z toho tech 1200 nevychazi.

Michal

_______________________________________________
SharpMZ mailing list
SharpMZmail.ordoz.com
http://mail.ordoz.com/mailman/listinfo/sharpmz

Máš pravdu, práve to pozerám. Ostáva ti len previesť MZF na WAV a kuknúť to tam. Alebo ideálne nahrať WAV zo Zdeňkovho emulátora.

Nerozumim. To jak ty data na CMT vypadaji je presne popsano v SM, viz odkaz od Radka. Predpokladam, ze napr. v pripade odesilani rychlosti 2400 baudu ty casy jen o polovinu zkratim. Z WAVu bych se k tomuto tematu uz zrejme nic zajimaveho nedozvedel.

Ten dotaz, ktery jsem v puvodnim mailu polozil je jen o tom, ze nerozumim tomu proc je zrovna tento pomer short/long oficialne oznacovan jako 1200 baudu, protoze at pocitam, jak pocitam, tak mi z toho tech 1200 bps nevychazi a predpokladam, ze je to urceno nejakym statistickym prumerem.

No a keď už spomínaš CMT, jeden z mojich nápadov, ktorý by si mohol skúsiť realizovať je automatická detekcia rýchlosti čítania. Niektoré programy vyžadujú 2x rýchlosť (napr. Saboteur). Pri testovaní portov by si zistil ako sa často testuje a podľa toho by si automaticky zaradil rýchlosť. Síce to nie je až tak jednoduché na prvý pohľad, ale myslím, že by to šlo urobiť.

Nejsem si jisty, zda je nutne, aby si nacitaci program v Sharpu sahal pro data z CMT prave jen takhle. Verim, ze chytrejsi CMT loadery budou v zavadeci sledovat nastupne i sestupne hrany a podle toho se pak samy adaptuji na prislusnou rychlost ... Jak by tva emulace rozeznala, zda se jeste analyzuje zavadec a nebo zda uz se ctou data?

Navic predpokladam, ze i pri beznem cteni z CMT se bude hledat nastupna hrana i pri cekani na dalsi bit, coz znamena neustale cteni CMT portu porad dokola, coz by take tvuj mechanismus identifikoval jako super rychlost.

No a pokud se zamyslime nad tim, ze by program pri nacitani dat delal i neco jineho, pri cem by se cetl stav brany C na 8255, tak uz jsi s tou analyzou uplne v haji, protoze kdyz CPU cte port C, tak prece netusis ktery bit z portu jej prave zajima.
 
Michal

Z vlastni zkusenosti z roku 1989 kdy jsem si hral s CMT, tak je dosti casu na ruzne veci pri nahravani dat. Neni problem menit border, vykreslovat obrazek spolu s ukazetelem casu a klidne i pustit nejakou muziku. V te dobe jsem pouzival pevne konstanty na 1/1 a 1/2. Rychlost 1/3 jsem uz nemel rad a vetsi uz skoro nefungovala. Neni ale problem na zacatku zaznamu, kdyz se vysila (az) 22000 Short znaku si zjistit jakou rychlosti je to nahrane. Protoze log0 a log1 jsou trosku jine tak je mozno i zjistit zda neni potreba pri nahravani zpet udelat obraceni (XOR) signalu. Pak pri Tape Mark si overit ze vypocitane konstanty jsou spravne a nasledne hodnoty pouzit ve vlastni rutine. Jen to chce mit volny cas na hrani. Osobne kdyz bych mel volny cas tak bych udelal rutinku takovou, jakou co ja vim nikdo neudelal a to ze 8253 bych naprogramoval aby vyvolal ve spravnou dobu preruseni a to by precetlo bit a ulozilo. Po RET by se to vratilo puvodnimu programu co by neco delal treba vykresloval obrazovku a na konci (240+278uS) by se jen cetl PC5 zda je nabezna hrana a kdyz by toto nastalo tak by se spustil opet casovac 8253 + EI. Prerusovaci rutinka by mohla i reagovat tak ze pri Long by vedela ze ma navic 220uS a mohla by delat jeste neco navic na co by nebyl cas pri Short, treba dekompresi dat.

Radek

Dne 14.12.2014 v 12:20 Miloš napsal(a):

Máš pravdu, práve to pozerám. Ostáva ti len previesť MZF na WAV a kuknúť to tam. Alebo ideálne nahrať WAV zo Zdeňkovho emulátora.

Nerozumim. To jak ty data na CMT vypadaji je presne popsano v SM, viz odkaz od Radka. Predpokladam, ze napr. v pripade odesilani rychlosti 2400 baudu ty casy jen o polovinu zkratim. Z WAVu bych se k tomuto tematu uz zrejme nic zajimaveho nedozvedel.

Ten dotaz, ktery jsem v puvodnim mailu polozil je jen o tom, ze nerozumim tomu proc je zrovna tento pomer short/long oficialne oznacovan jako 1200 baudu, protoze at pocitam, jak pocitam, tak mi z toho tech 1200 bps nevychazi a predpokladam, ze je to urceno nejakym statistickym prumerem.

No a keď už spomínaš CMT, jeden z mojich nápadov, ktorý by si mohol skúsiť realizovať je automatická detekcia rýchlosti čítania. Niektoré programy vyžadujú 2x rýchlosť (napr. Saboteur). Pri testovaní portov by si zistil ako sa často testuje a podľa toho by si automaticky zaradil rýchlosť. Síce to nie je až tak jednoduché na prvý pohľad, ale myslím, že by to šlo urobiť.

Nejsem si jisty, zda je nutne, aby si nacitaci program v Sharpu sahal pro data z CMT prave jen takhle. Verim, ze chytrejsi CMT loadery budou v zavadeci sledovat nastupne i sestupne hrany a podle toho se pak samy adaptuji na prislusnou rychlost ... Jak by tva emulace rozeznala, zda se jeste analyzuje zavadec a nebo zda uz se ctou data?

Navic predpokladam, ze i pri beznem cteni z CMT se bude hledat nastupna hrana i pri cekani na dalsi bit, coz znamena neustale cteni CMT portu porad dokola, coz by take tvuj mechanismus identifikoval jako super rychlost.

No a pokud se zamyslime nad tim, ze by program pri nacitani dat delal i neco jineho, pri cem by se cetl stav brany C na 8255, tak uz jsi s tou analyzou uplne v haji, protoze kdyz CPU cte port C, tak prece netusis ktery bit z portu jej prave zajima.
 
Michal

_______________________________________________
SharpMZ mailing list
SharpMZmail.ordoz.com
http://mail.ordoz.com/mailman/listinfo/sharpmz