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 13:09 Michal Hucik -
ORDOZ napsal(a):
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