OldComp.cz

To jsme se nepochopili. Ten "trojitý hack" tam není jako záplata kvůli nějaké hardwarové složitosti. To je tam proto, že každý typ myši (virtuální v emulátoru, ATARI, pingpong) má jinou citlivost, a pokud chci implementovat dynamické zrychlování (a to já kvůli příjemné ergonomické odezvy chci), tak jiná možnost není. Prostě musíš mít tři různé převodníky citlivosti, které násobí počet "natočených" pixelů proměnlivou konstantou v závislosti na rychlosti pohybu myši. Ať už s plně softwarovým čtením, nebo s čítači uvnitř myši.

Jinak myš nemá žádné rozlišení ve smyslu 288x256. Ale jestli myslíš max. hodnotu relativních čítačů v osách X a Y (tedy vždy mocnina čísla 2), které lze procesorem přečíst z portu myši, tak by nakonec možná stačilo i 16x16 pixelů (tedy dva 4-bitové čítače, po jednom pro osy X a Y), a co je nad, to by "střádal" procesor v PMD-85. Počet bitů těch čítačů je jen o tom, kolik času si může CPU dovolit ignorovat stav myši. Stejně by se ty polohové čítače (bez ohledu na jejich šířku) nebraly jako absolutní pozice myši ale jako relativní změna od minulého čtení.

Jinak jsem zrovna uvolnil další verzi hry Miny s novým myším ovladačem. Sice nemá autostarter a úvodní obrázek, ale to je jen po dobu testování. Pokud bude tato verze finální, oboje tam samozřejmě doplním.

Ano, proto jsem si říkal zda toho PMD neušetřit a servírovat mu data pouze v unifikované rychlosti. Bulharské konstanty dle připojeného myšítka by měla na starost HW logika řadiče. Třeba je to naivita nebo moc komplikované ale můj úmysl je minimalizovat výpočty polohy myši i jejího přesunu v PMD na co nejmenší míru, ideálně se ho zbavit.



Ovšem že nemá, ale čítače mít mohou . Bratru 30 dpi pingpongačka potřebuje co jsem tak viděl v cygnusově videu zhruba vzdálenost 1:1 aby přejela stejnou vzdálenost i na monitoru. Zatímco výrazně citlivější Atari myši stačilo na to samé doslova pár centimetrů aby nahrabala stejný počet impulzů. Na PP-01 by se krásně vystačilo se 2 čítači po 8bitech, to má rozlišení 256x256 a mohlo by to frčet čistě hardwarově. PMD má moc velké fyzické rozlišení aby se vystačilo s 1 bajtem i na osu X. Opět idea je PMD úplně z procesu určení absolutní polohy vyloučit, pouze by si načítalo přes nějaký /REQ signál chytré logice myši 3 bajty informace kde myš je a zda je na ní zmáčknuté tlačítko. 2 bajty by byly pro osu X a tlačítka (krásně by na to padl 1bajt + 5 prvních bitů druhého do 288 a zbyly by 3 horní bity pro 3 tlačítka) a 1 bajt pro osu Y. A na systémovém konektoru je napětí, tak by se to mohlo celé živit z PMD.

Na os X Ti stačí 9 bitov a nie 13.
M1

To je pravda, o to líp. Počítal jsem si to na kolik bajtů to vyjde a pod 3 se nemůžu dostat. Asi bude jednodušší než sčítat bity je mechanicky překlopit do 16bitové hodnoty buď s ignorací těch horních pro osu X, případně protože to budou pak násobky 64 000, 32 000 a 16 000 by se z toho daly lehce odvodit i ta zmáčknutá tlačítka 1, 2 a 3.

Ta logika by jen přičítala a odečítala stavy bitů a čekala na signál /REQ, po kterém by ty 3bajty vysypala na sběrnici. S tímhle přístupem by PMD mohlo lehce myš přestat sledovat úplně pravidelně a mohlo by docházet k delším časovým dírám. Cenou za to by bylo případné poskočení kurzoru když by to trvalo moc dlouho a uživatel by myší stále hýbal. Ale pár desetin sekundy by asi moc nehrálo roli, to už je hodně cyklů navíc. A umožnilo by to i přesnou digitalizaci v rastru 288x242, například tvorbu vektorového obrázku z předlohy.

Protokol u sériových (RS232C) myši je tak udělán aneb myš vrací 3 byte. Tj. souřadnice a stav tlačítek. Aby toho nebilo málo tak jsou dva protokoly a to M$ a GENIUS kdy se od sebe liší tím že M$ vrací, poloho v rozsahu +-128 a umí dvě tlačítka a GENIUS vrací, poloho v rozsahu +-256 a umí tři tlačítka. Souřadnice co myš vrací je relativní aneb je to změna polohy od posledního čtení. Vzhledem k tomu že přenos je sériový tak si moc nepomůžeš, aneb dost vysoká režie se sériovým portem.

Co jsem to probíral už dávněji s Liborem tak není problém detekce pohybu myši ale její kreslení takže paradoxně přímé čtení stavu clonek a tlačítek je efektivnější než zpracovávat už předzpracovaná data.

_________________
Ne všichni jsme měli z češtiny za jedna, aneb jsem dyslektik a dysgrafik.

http://www.sapi.cz/

A Intellimouse vracia až štyri bajty.

Aha, já měl ale na mysli paralelní přenos, ne sériový. A zápis 2 absolutních hodnot souřadnic + tlačítka na 3 místa v paměti kam si v dalším kroku sáhne vykreslovač kurzoru a program bude náročnější než neustálé načítání změn a jejich přidávání taky na místo v paměti s hlídáním přetečení apod? Neříkám že ne, ale přijde mi to spíš jednodušší protože odpadá veškerá matematika s bity. Já totiž celou dobu halucinuju nad variantou že rozhraní té myši bude inteligentní a dodávat absolutní souřadnice a PMD si je bude jen nahrávat když bude potřeba a program následně využívat.

Jo něco v tom duchu jsem začal páchat s TTL logiky a nestačila mi na to SAPI-1 deska aneb se měli číst tři byte tj. souřadnice a stav tlačítek ale Libor mi politicky vysvětlil, že je to zbytečnost aneb těch pár instrukcí co se ušetří, při vlastní detekci pohybu myši nemá význam. Aneb ta detekce má relativně malou režii, daleko větší režii má vlastní kreslení kurzoru myši. Pokut se bude bavit o hrách tak stejnak děláš pravidelně testy všeho možného tak se s tím sveze i ovladač myši ….

_________________
Ne všichni jsme měli z češtiny za jedna, aneb jsem dyslektik a dysgrafik.

http://www.sapi.cz/

Ok, přínos nevyváží náklady. Stručné, jasné, výstižné .

S malým mikročipom by to bola vcelku jednoduchá úloha, dokonca by niekoľko sád súradníc mohlo chvíľu podržať v pamäti, kým dôjde k vyčítaniu.
M1

Taky si myslím že by to nemuselo být kdovíjak složité zařízení. Jenže když by to nepřineslo efekt ve formě uvolnění CPU PMD pro další věci tak to nemá moc cenu... To může posoudit ten, kdo ví jak ten ovladač má fungovat a kolik taktů přesně spotřebuje grafická část a kolik výpočet samotné polohy a změn. Ušetřit se dá výpočet polohy, ale jestli to je třeba 80:20 nebo i 90:10, tak se celkově ušetří málo taktů. Být to třeba 50:50 už by bylo jinak, to by se náročnost driveru shodila skoro na půlku a protože to zabere CPU většinu času, už by ten rozdíl byl významý... Ale i těch 10% dolů by při velké zátěži CPU nebylo špatné, uvolnilo by to zase nějaký CPU čas navíc.

Jak s Liborem řešíme BGP-1 a MPH-1 tak jsem tak velmi lehce zasvěcen do toho jak ty hry fungují. A taky tak velice matněte tuším, jak to Libor vidí s programátorského hlediska, takže když to velice zjednoduším tak to je v duchu že na vše a za všech okolností stačí to měkké a mám problém přesvědčit Libora, že trocha železa navíc se taky může hodit. Nakonec jsme došli ke kompromisu.

Konkrétně s tím ovladačem myši to opravdu vychází lépe číst přímo myš aneb ta detekce pohybu je jen velice malí kousek kódu (mám pocit, že se to řeší přes tabulky). Něco jiného by bylo použití MCU co by převzal větší část toho ovladače tj. i tu dynamickou část plus by vracel normalizovaný krok ale stejnak by ten MCU vracel jen změnu od posledního čtení, takže kus toho ovladače by musela zůstat. Něco by se ušetřilo jak na čase tak i kódu ale přibila by destička v MCU kterou by bylo třeba nějak přečíst a nějak se musí mezi sebou domluvit , že jsou platná data. Což znamená obousměrný přenos tj. bud být přímo připojen na systémovou sběrnici nebo mít minimálně dva porty a to jeden pro čtení a druhý pro zápis a k tomu nějaký ten protokol …. Ve finále by se zjistilo, že se nic neušetřilo, ale rapidně se zkomplikovalo připojení myši . Pokut se nepletu tak některé myši jdou připojit místo ….

_________________
Ne všichni jsme měli z češtiny za jedna, aneb jsem dyslektik a dysgrafik.

http://www.sapi.cz/

Toto je veľmi komplikovaná otázka.
1. vyčítanie polohy resp. zmien z myši
tu je zásadný rozdiel v počte cyklov pri čítaní sériového protokolu oproti jednoduchému vyčítaniu troch bajtov z portu. Keď pozerám svoj kód na obsluhu PS2 klávesnice, tak to tipujem na 1000x viac cyklov. Tiež musíš zabezpečiť, aby Ti myš neposielala dáta kedykoľvek, ak to nemáš riešené cez prerušenie.
2. prepočet relatívnych súradníc na absolútne
toto je triviálna záležitosť a významne nemá vplyv na spotrebu času. Samozrejme, pokiaľ neriešiš nejaké algoritmy na akceleráciu posunu kurzoru.
3. vykresleni kurzoru
závisí od jeho veľkosti. Pravdepodobne bude potrebné uchovať pôvodný podklad a po zmene polohy kurzoru ho vracať naspäť. Pri veľkosti kurzoru 6x8 resp. 8x8 px. to bude odložiť 16 bajtov, nakresliť 16/32 bajtov a vrátiť 16 bajtov (ak je pohyb kurzoru po pixloch a nie znakoch).

Má idea jak to řešit byla taková, že by si mikročip počítal sám impulzy z myši a přičítal nebo odčítal v rozsahu 0-287 a 0-241 + při zmáčknutí tlačítka by přehodil jeden ze tří bitů posledního bajtu. A čekal by na signál z PMD, pinů je tam na to dost. Když by přišel signál /REQ, odvysílal by ty 3 bajty paralelně po sběrnici do PMD. Mohl by tam být pomocný signál z PMD aby mu řekl že předchozí bajt už je přečtený.

No a potom by PMD shodilo signál /REQ, tak by mikročip přestal vysílat a věnoval by se opět plně čtení dat z myši a aktualizování hodnot do nového /REQ signálu. Sériová komunikace směrem do PMD by se nekonala, tak si myslím že rychlost přenosu by byla velice slušná v řádu desítek taktů. Vykreslení kurzoru by už bylo stejné jako v současných řešeních, tam asi není proč vymýšlet kolo znovu.

Ano, takto by to mohlo byť, akurát ten kód, čo by si mal v počítači, musíš preportovať do MCU. Inak nič zložité, najdrahší by bol na tom konektor FRB.
M1