Myš uvedeného typu využívá k přenosu informací o pohybu do počítače celkem čtyř signálů. Pro vodorovný směr dva a pro svislý směr rovněž dva. Pak jsou samozřejmě k dispozici i signály, nesoucí informaci o tom, zda bylo stisknuto některé z tlačítek myši, ovšem jejich čtení a interpretace nečiní v praxi žádný problém a proto se jimi prozatím nebudeme zabývat.
Ony dva signály pro každý směr představují dva obdélníkové signály (při pohybu myší), navzájem posunuté o 90°. Pak se dá analýzou této dvojice signálů rozpoznat směr pohybu. Metod je mnoho, já jsem použil takovou, kdy jsem do spodní čtveřice bitů v bajtu umístil nový stav všech čtyř pohybových signálů a do horní čtveřice bitů v bajtu jsem umístil starý stav všech čtyř pohybových signálů. Takto sestavený bajt ukazuje do tabulky o délce 256 bajtů, jejíž prvky mají vhodně nadefinovány kódy 0..9, které znamenají: 0=myš se nehýbe, 1=sever, 2=severovýchod, 3=východ, … 8=severozápad, 9=neplatný stav (přeskok dvou fází). Tato metoda má výhodu v maximální možné rychlosti, nevýhodou je právě velikost té nahlížecí tabulky. Ale v množství ostatního potřebného kódu se velikost té tabulky jeví jako nevýznamná. Samotný kód ovladače je samozřejmě hutnější a kompaktnější ale princip je tento.
Samotný ovladač nabízí následující procedury:
- Procedura „MYSACT“: Aktivace kurzoru myši. Provede test adresy kurzoru myši, zda se nachází ve videoram. Pokud ne, nastaví kurzor myši doprostřed obrazovky. Dále se uschová pozadí pod kurzorem myši a nakonec se zobrazí samotný kurzor myši. Nic jiného tato procedura nedělá.
- Procedura „MYSDEA“: Obsah buferu pozadí pod kurzorem myši zobrazí na pozici tohoto kurzoru, čímž se kurzor ztratí a objeví se původní obsah obrazovky. Opět se nic jiného neděje a jedná se pouze o grafickou operaci zhasnutí kurzoru myši.
- Procedura „MYSRUN“: Tuto proceduru možno též volat instrukcí RST 7. Procedura otestuje případný pohyb myši a v kladném případě posune kurzor myši požadovaným směrem. S ohledem na nízkou rychlost PMD-85 je nutno tuto proceduru volat stále dokola bez zbytečného prodlení aby nedocházelo ke ztrátě dat směrem od myši k CPU. Po návratu z této procedury obsahuje příznak CY hodnotu 1 v případě stisku pravého tlačítka myši a příznak S hodnotu 1 v případě stisku levého tlačítka myši.
- Funkce „MYSCOR“: V registru ACC vrací aktuální Y-souřadnici kurzoru myši. V registrovém páru H:L vrací X-souřadnici kurzoru myši. Záměrným bodem kurzoru myši se rozumí levý horní rozsvícený pixel myši (špička šipky).
Kurzor se vykresluje jako šikmá šipka s jednopixelovou mezerou po obvodě, přičemž korektně pracuje s pozadím obrazovky. Proto je nutný i bufer pro úschovu tohoto pozadí a poněkud složitý mechanismus rotací tohoto buferu při pohybu kurzoru myši.
Ovladač kvůli rychlosti začíná na adrese 0038h a má striktní požadavky na umístění jednotlivých částí kódu. Například tabulka přechodových stavů musí začínat na adrese s nulovým spodním bajtem, stejně tak tabulka s ofsety a samotnými animačními fázemi kurzoru myši, atd. Je to daň za fakt, že ovladač myši vůbec jede s rozumnou odezvou. Pokud tedy nemusíte, nechte ovladač myši jako první programový blok od zmíněné adresy 0038h a své programy, které knihovnu myši využívají, pište až za ovladač myši. RST vektory 0 až 6 jsou vám tak plně k dispozici.
V emulátoru PMD-85 od RM-Teamu do verze 3.0.1.142 prozatím existuje podpora pouze pod verzí PMD 85-1, na fyzickém hardware myš funguje na všech verzích (ověřeno na fyzickém stroji PMD 85-2A). Díky faktu, že PMD-85 přepíná oddělovač rozšiřující sběrnice směrem k CPU pro všechny I/O adresy s hodnotou 1xxx11xx (binárně) kvůli zabránění kolize s interními periferními obvody, lze tento oddělovač sběrnice použít i jako vstupní port a výstupní signály myši připojit přímo na vstupní datové vodiče rozšiřující sběrnice. Jen je dobré použít sériové oddělovací odpory o velikosti zhruba 4k7. Signály tlačítek je nutno invertovat a použít PULL-UP rezistory, neboť zmíněný oddělovač sběrnice je neobsahuje a myš z historických důvodů rovněž ne. Bez těchto PULL-UP odporů jsou signály tlačítek nestabilní a kmitají. Pokud použijete tranzistorové invertory, pak je jejich principiální součástí i ten PULL-UP rezistor a je to OK.
Tělo procedury MYSRUN, tedy ta část programu, která určuje „rychlost“ pohybu myši, trvá od 1517T CPU do 3565T CPU podle směru pohybu myši. Tomu odpovídá testovací frekvence 482 až 1134Hz. Na základě praktických zkoušek na skutečném hardware mohu potvrdit, že na internetu uváděná minimální požadovaná frekvence testů stavu clonek myši o hodnotě zhruba 500 testů za vteřinu je adekvátní. Od této četnosti testování pohybu myši směrem nahoru lze hovořit o komfortní odezvě. Vůbec však nejde o rychlost pohybu myši jako takovou, spíše jde o to, že při nižší rychlosti testování CPU občas nezaregistruje některé stavy clonek, následně další stav zákonitě vyhodnotí jako neplatný a kurzor myši se pak spíše třese na místě a nepohybuje se rovnoměrně.
Zdrojový kód testovacího programu pro kreslení pomocí myši
Zdrojový kód knihovny pro ovládání myši 602
Testovací program pro kreslení myší (soubor virtuální MGF pásky pro emulátor od RM-Teamu)
Průmět kurzoru myši
HelloWorld
Ovladač MOUSE602 je hotov a ani to moc nebolelo. Myslím, že má dostatečnou výkonovou rezervu na nějakou menší současnou animaci. Tím narážím na použití tohoto ovladače myši v připravované hře FF.
Tak jsem zkoušel ATARI ST myš připojenou ke skutečnému PMD-85 ve stylu MYŠ602 a ta rychlost je na hraně. Tedy spíše pod hranou. Není to úplná tragédie ale při trochu rychlejších gestech prostě CPU nestíhá. Signály myši jsem připojil jen přes odpory 4k7 přímo na datové linky expanzního portu. Signály tlačítek bude třeba invertovat – ale princip je OK. Asi zkusím udělat alternativní ovladač, kde se vykašlu na kurzor, který „jede“ nad pozadím a udělám sprostý XOR. Tím bych měl drasticky navýšit rychlost odezvy na pohyb myši. Když jsem měřil odezvu (2500-4000T) na pohyb myši, tak detekce pohybu myši dělá odhadem 150T a zbytek žere animace kurzoru..
Cvičně jsem se pokusil udělat nějaké optimalizace a ejhle, většinu sekvencí jsem srazil na 60-70% původní délky. Takže asi tu optimalizaci pečlivě dokončím a znovu vyzkouším na skutečném železe, které nemá bufer pro pohyb myši..
Pre zaujímavosť, tu je scan návodu k myši 3 WN 16605 a jej schéma zapojenia a schéma, ako som ju ja pripojil k PMD 85.
https://pmd85.borik.net/_work/3WN16605.zip
Nepamätám si to síce úplne presne, keďže to bolo už pomerne dávno, ale keď som skúšal tú myš na PMD 85-1 s programom GREDIT16, tak sa mi marí, že to v ňom išlo celkom uspokojivo.
Super, díky za to schéma. Proč se vlastně neguje polarita tlačítek, když jednodušší je spínat tlačítka proti zemi? Je to jen kvůli kompatibility s jediným SW pro PMD-85, který to tak používá? Jinak zapojení mám stejné jako Ty. Jen jsem tam dal na ty datové linky sériové ochranné odpory kvůli zpětnému zápisu na port 8Ch (ne že bych tam něco zapisoval, ale pro jistotu). Já jsem zkoušel myš z ATARI ST a ta nemá PULL-UPy na tlačítkových signálech a trochu to kmitá při nestisknutých tlačítkách. Přeci jen se očekávalo, že ty PULL-UPy bude mít v sobě počítač a ne JOYSTICK nebo myš. Jinak signály clonek jsou u té myši prohnány čtyřnásobným komparátorem tuším LM339 a tudíž tyto signály PULL-UPy již nepotřebují.
Tlačidlá sú aktívne v log.1, pretože bola takto Myš 602 navrhnutá. To znamená, že som to bral ako fakt a takto bola emulácia napísaná.
OK. Beru na vědomí. Ty dva invertory navíc nejsou až takový problém.
S poslední verzí ovladače myši, která je už dostupná ke stažení, jsem spokojen. Tímto považuji akci myš za dořešenou. Alespoň do té doby, než se na něco přijde.
Přeci jen ještě +5% výkonu při bočních posunech a s tím spojené mírné zkrácení kódu ovladače. Upravil jsem jak zdrojový kód ovladače v textové podobě, tak i soubor virtuální MGF pásky s demem.
Nebilo by lepší použit prográmek ze ZXMagazínu 1995-1 ten používá taktéž tabulku ale optimalizovanou pomoci karnaughovy mapy na 2×8 bajtů.
https://z00m.speccy.cz/files/ZXMagazin-1995-1.pdf
Osobně bych tento problém řešil diskrétně, tj. na dekódování fázově posunutého signálu je zapotřebí 8 klopných obvody D (4 pouzdra 7474) a dvě hradla 4 vstupová hradla NAND (1 pouzdro 7420) a výstup z těchto hradel je přímo použitelný pro čítače 74193 a po přidání pár hradel i pro čítače řady 74160 – 74163. Na vstupu je vhodné mít nějaké oddělení kvůli zátěži a také k získání obou polarit signálů potřebných pro dekodér např. jedno pouzdro 7400. Takže na jednu osu je zapotřebí 8 pouzder IO za předpokladu, že budou požity 2 čítače 74193 na osu. Což dává 256 kroku vyrovnávací paměť a mezní zpracovaný kmitočet je cca 10MHz pro klasickou řadu nebo LS. Ano kompletní modul bude obsahovat 20 až 30 IO ale celá obsluha myši se scvrkne na přečtení 3 byte a přepočet souřadnic na absolutní polohu na stínítku. Tímto udělátkem se dostaneme na úroveň myší Gmouse jen s tím rozdílem že přenos bude rychlejší tj. paralelní místo sériového. Dekodér je popsán v ARB 83/3.
Právě na tento odkaz jsem při začátku vývoje ovladače myši pro PMD-85 narazil. Ale nelíbila se mi od pohledu jeho délka, která se nutně musí projevit na počtu taktů, čili na „pomalosti“ odezvy. Pravda je ta, že předtím to bylo něco na pomezí předsudku, nechuti studovat cizí dílo a naopak chuti vyzkoušet něco svého. Až nyní jsem to spočítal (z hlavy, takže jsem se možná spletl) a vyšly mi následující poměry: verze AMOUSE pro ZXS má celkovou délku 99 bajtů, počet taktů vnitřní smyčky 326T – oproti tomu verze pro PMD85 má celkovou délku 19 bajtů + 256 bajtů tabulka a počet taktů na jeden průchod smyčkou je 82T. Ta forma multitaskingu u AMOUSE se mi navíc nějak nezdá. Asi to autorovi fungovalo, ale mám obavy, že ten kurzor by se viditelně zasekával při přepínání na nějakou delší paralelní úlohu. Ovšem záleží, jakou úlohu paralelně zpracovával. Já jsem ovladač myši od začátku koncipoval pro jednu konkrétní hru s jejími předpokládanými dispozicemi a proto jsem volil jak jsem volil.
Co se týče hardwarového dekódování pozice, proč ne. Bylo by to pěkné cvičení z aplikace logických obvodů. Ovšem je třeba si uvědomit, že je několik levelů uživatelů. Jedněm je nějaké PMD-85 s myší ukradené, druzí maximálně připojí myš na konektor a jeden nebo dva lidi v bývalém ČSSR by si ten hardwarový dekodér postavili (ale spíše nikdo). Skoro si troufám tvrdit, že pro myš další hra na PMD-85 nevznikne. I s XORovým kurzorem totiž ovladač myši žere obrovské množství strojového času a na samotnou hru už zbude jen málo. Tou časovou náročností nemyslím pouze obsluhu signálů, spíše celkovou náročnost ovladače myši včetně následné grafické části pro překreslování kurzoru. Takže možná nějaké karty nebo hra formátu Funny Fruits. Myš pro PMD-85 je jen parádička, technická fajnovost bez praktického využití.
Každopádně děkuji za příspěvek, případný zájemce může srovnávat a možná zrovna v tom rozdílném pojetí najde nějaké pojítko a inspiraci. Kdysi jsem se takto inspiroval taky, když jsem někdy kolem roku 1995 dělal satelitní pozicionér. A tehdy jsem dostal lekci, ty dva fázově posunuté signály se hodí leda pro myš. V praxi dochází u těch dvou signálů k významné chybovosti a falešnému dekódování pohybu, což je u průmyslových snímačů řešeno třetím signálem, který jednou za čas uvede počitadlo pozice na pravou míru.
Aha já v programování nejsem takový guru, ale mám tu zkušenost, že dost lidi si myslí, že softwarem zvládne cokoli a podle toho to pak vypadá v daném případě nemyslím tebe a tobě podobným. Ten diskrétní dekodér jsem navrhl proto, že řeší to, že ctění stavu může probíhat nahodile a i s relativně dlouhými časovými odstupy. Ale pokut ti obsluha kurzoru sežere velkou část strojového času, obsluha myši minimum a sem tam ztracený krok/kroky nevadí tak diskrétní dekodér je pasé.
Ta nespolehlivost fázově posunutých signálů se mi moc nezdá, v principu jde o variaci na Grayuv kód, tj. mění se vždy jen jeden signál. Drtivá většina odměřovacích systému v průmyslu používá právě tento systém a to s přesností odměřovaní až na mikrometry takže s to stou spolehlivostí tak zlé nebude. Pokut je poškozené pravítko, snímače nefunguji, jak mají, nebo dochází k přeslechům na vedení od snímače k vyhodnocovací elektronice tak se pak dějí věci. A ten třetí signál tam není pro srovnání chyby ale jako referenční značka polohy. Například u otáčkových snímačů je jednou za otáčku a slouží k tomu, aby po zapnutí byl stopen řídicí systém si srovnat polohu rotoru s virtuálním úhloměrem, a u lineárních značí např. krajní polohy pracovního prostoru a podobně. Pro zvýšení spolehlivosti přenosu a možnosti detekce chyb se přenášejí jak pozitivní tak negativní úrovně všech signálů, pokut je signál zpracovaný již ve snímači tak pak je to dáno protokolem daného snímače.
S dekodérem z těch 8 klopných obvodu D jsem si kdysi hrál a chodil perfektně jak s profesionálním snímačem otáček taka tak s převodníkem z BIN čítače a nestalo se mi, aby se mi ztratil nějaký krok a to jak s čítači 74192/3 tak 74160-74163. Pokut bude zájem tak mohu zkusit něco navrhnout.
Já jsem u již zmíněného pozicionéru vedl souběžně s datovými signály i silový signál pro motor a ta chybovost byla značná. Délka těch kabelů byla ca 7-10m. Ale souhlasím s Tebou, že to je dáno přeslechy a ne systémovou chybou při dekódování těch dvou signálů. Ten systém je! neprůstřelný (v laboratorních podmínkách) ale jeho praktická realizace má své limity. A k tomu třetímu signálu: Kdysi dávno mě chlapci praktici v práci poučovali na zařízení, kterému říkali „reta“ (sám nevím, od čeho je to odvozeno, ale byl to průmyslový snímač na bázi dvou posunutých signálů o průměru ca 250mm pro polohování na válcovacích stolicích) a tam ten třetí signál byl, vždy po zhruba 500 „dvouimpulsech“ se aktivoval ten třetí a ten prý sloužil k do-synchronizaci pro diskrétní dekodér, tehdy tuším ještě na vanových systémech SAPI s nějakou doplňkovou kartou. Ale pravda je ta, že ten třetí signál jsem v praxi nikdy nepoužil a tak se jedná jen o můj předpoklad. A jsem si naprosto vědom faktu, že mysleti znamená h…o věděti. Mimochodem, autorkou software pro ten systém byla nějaká dáma, která tam implementovala bezezbytkové dělení na válcovací trati.
Takové blbosti si pamatuji od roku 1995. Nebo na které stránce v katalogu Tesla je D346D. Ale abych si pamatoval data narození celé rodiny nebo jak se co vaří, to ne. No, to jsem trochu sešel z cesty, ale dnes jsem si udělal volno, tak proč ne..
Ale v jednom Ti musím dát 100% za pravdu. Nedám dopustit na fyzické čipy C520D a ICL7106/7107/7135. Tyto obvody programem nenahradíš. A nahradíš-li, není to fyzikálně čisté. A je-li to fyzikálně čisté, tak jen do pláče.. Doufám, že mě Cimrmani nezažalují za plagiátorství v poslední větě.
Mimochodem, posledních několik let věnuji nákupu zbytkových a zlevněných zásob LS/ALS TTL obvodů, abych mohl dělat věci, o kterých mluvíš. Akorát mi dosluhuje nepájivé pole EIC-106 a ty nové atrapy se nedají použít!
Jo tak to už mi dává smysl. Ten snímač u té válcovací stolice mohl ten třetí signál opravdu používat k dorovnání chyby (ideálně po násobku 2^n v daném případě 512), aneb tam muselo být šílené rušení, klasika v těžkém průmyslu spíš obecně v průmyslu. Při tom dělení jeli tak s přesností na mm možná až cm tak sem tam chyba nevadila.
No bodejť ti to nechodilo. Už jen přenést logický signál na tu vzdálenost je kapitola sama pro sebe a pokut to má jit spolu se silovým vedením tak to už je vysoká dívčí nebo problém řešitelný pouze optikou. Pout jsem pochopil spraně tak silová část byla v blízkosti motoru. Pokut bys na datovém vedení použil proudovou smyčku nebo spíš budiče po RS485 s odpovídajícím kabelem tak to mělo vysokou šanci na úspěch, za předpokladu že ses cestou vyhnul zdroji rušení např. elektroinstalaci. Další věc jak dobře bylo řešeno odrušení od silové časti.
Co do mašin montujeme profesionální snímače otáček, z kterých leze signál slučitelný s 5V TTL tak mám pocit, že délka stíněného kabelu smí být max. 5m možná víc a min 1metr od zdroje rušení. Pro delší vzdálenosti myslím, že do 100-500m je tam převodník ala RS485 ale podmínka min 1m od zdroje rušení tam pořad je.
V jedné již historické knize co mám je jedna kapitola věnovaná přenosu signálů na velké vzdálenosti, v TTL tam za velkou vzdálenost považuji už 30cm!! A vedení se má přizpůsobit. Mají tam také průběh signálu na dálnopisném vedeni. Aby dostali na výstupu krásný pulz tak na vstupu je defakto obecně číslicový signál který v konečné fázi jde do záporných hodnot.
Nazpátek k tématu mám pocit, že do SAPI-1 existuje deska MIS-1 ale tam to je asi řešeno pomoci MHB 8035. U SAPI-1 s alfanumerickým displejem by myš v textovém editoru chodila v pohodě. A diskrétní dekodér byl výhodný, protože při časově náročných operacích s textem by se editor nemusel zdržovat obsluhou myši. U případných, diskových operaci by byl, CPU plně vytížen obsluhou u řadiče RPD-1 a u řadičů na bázi 8272/8257 dost zdržován DMA takže na nějakou smysluplnou obsluhu by byl čas tak mezi sektory
Asi zkusím něco navrhnou ale asi to nebudu dělat jako desku do systému SAPI-1 ale jako obecnou desku k připojení k portům tj. bude to univerzálnější a také to půjde použít i k jiným aplikacím, obecně k odměřování
V TTL mám něco přes 17 000 kusu IO a s pájeními je to přes 20 000 a i tak pokut stavím něco trochu specifického tak něco vždy chybí nebo toho mám málo.
Aha neumím číst, pokut jsi táhnul sílový signál pro motor spolu s datovými signály od snímače tak to mělo šanci bud se speciálním kabelem na to určeným a se splavnými budiči vedeni nebo s optikou na signálovém vedení. Ale jak jsem psal, na té délce to chce svoje a pokut možno se vyhnout společné cestě signálových a silových vedení pokut jsou signálové vedení řešena v kovovém provedení. Stínění toho dost odchytí ale i to má své limity.
Při diskusi na fóru OldComp mi ohledně obsluhy myši typu 602 poradil Hynek věc přímo geniální. Až se stydím, že jsem na to již dříve nepřišel. Takže asi vznikne nový ovladač myši, který by razantním způsobem snížil zatížení procesoru a umožnil využití i v aplikacích, které jsou náročnější na výpočetní výkon CPU.
V praxi se jedná o to, že oddělím překreslování pohybu myši od detekce pohybu. Detekci pohybu budu stále dělat velice často (typicky >500x za vteřinu) ale překreslení kurzoru se bude dělat nezávisle na pohybu myši, synchronně s hlavním programem (což je stejně důležité jako ušetřený výpočetní výkon) a bude se pravděpodobně odvíjet od vypršení „časovače“ na bázi obvodu UART8251, který na PMD-85 umožňuje časovat v okolí použitelných hodnot časy 10,8ms (93Hz) popřípadě 100ms (10Hz).
Asi vznikne další testovací miniaplikace..
Zkusil jsem napsat nový ovladač pro PMD-85 a Myš602, u kterého jsou odděleny detekce pohybu a vlastní pohyb kurzoru myši. Podle očekávání je reakce mnohem svižnější, ale:
1) Je dobré nastavit konstantní frekvenci překreslování kurzoru, konkrétně jsem zvolil cca 93Hz. Toto číslo je dáno možnostmi hardwarového časování procesů na PMD-85. Zkoušel jsem i nejblíže pomalejší frekvenci 10Hz, to je však již nepřijatelně pomalé a odezva je nepoužitelná. Bohužel, nic kolem 50Hz není k dispozici, pokud chci ovladač provozovat i na PMD-85 verze 1. Taky jsem zkoušel ve smyčce několikrát volat jen detekci pohybu a pak překreslit pozici (tak to je myslím u jedné testované rutiny myši pro ZX Spectrum viz dřívější diskuse). Ovšem kurzor myši při pohybu viditelně blikal a laborování s konstantami tomu příliš nepomáhalo.
2) V momentě, kdy nejsou detekce pohybu a samotný pohyb synchronní, vznikají větší nároky na ošetření všech stavů na straně uživatele knihovny pro obsluhu myši. Dochází totiž k tomu, že pozice kurzoru vykresleného na obrazovce a již nově vypočtená pozice nejsou totožné. Z toho vyplývá nutnost testovat různorodé kolizní stavy při kreslení čehokoliv do videoram, aby to nepřepisovalo kurzor myši. Pokoušel jsem se vně knihovny při kreslení do videoram kurzor myši aktualizovat a tím i sjednotit s aktuální vypočtenou pozicí, to ovšem vede k mnohem pomalejším reakcím než u původního ovladače.
Hlavně bod 2 je problémový z pohledu univerzálního využívání ovladače jako volně šířené knihovny. Ale kdo se s tím dokáže vypořádat, dostane mnohem rychlejší ovladač než ten původní. Jako vždy: něco za něco..
Mám otázku. Ten testovací program Mouse602 spustím aj bez ovládača myšky ?
Pýtam sa preto, lebo ovladač na stiahnutie vo formáte .ptp tu nevidím.
Když tak na ty programy koukám, zjišťuji, že je to správný dotaz.
Nejprve trochu obecně, tuto část můžete přeskočit. Ovladač myši je natvrdo dělaný pro umístění od adresy 0038h, aby šel volat instrukcí RST 7, která je identická s instrukcí CALL 0038h ale má kratší zápis a kratší dobu vykonávání (11T CPU oproti 17T CPU). Navíc je tímto posazením na fixní adresu zajištěno, že tabulky začínají na adresách s nulovým spodním bajtem a proto je přístup do těchto tabulek velice jednoduchý: Do některého „vyššího“ registru (např. H) načtete bázi tabulky (to je ta adresa dělitelná číslem 256 s nulovým spodním bajtem) a do příslušného „spodního“ registru (zde tedy L) načtete index. A pak instrukcí MOV A,M načtete obsah tabulky s daným indexem.
Teď prakticky. Testovací program bez ovladače nebude dělat to, co od něj chcete. Aby ten testovací program fungoval, musíte zkompilovat testovací program a do stejně složky umístit před kompilací i tu knihovnu myši ve formátu *.asm (zdrojový kód knihovny). Nic víc nemusíte dělat. Pak si ten testovací program pomocí pseudoinstrukce #include „mouse602.asm“ přikompiluje tu knihovnu na to správné místo. Pokud do stejné složky tu knihovnu neumístíte, pak při kompilaci kompilátor zahlásí chybu, že tuto požadovanou knihovnu nenašel.
Abyste toto všechno nemusel dělat, je zde soubor *.ptp, který obsahuje kompletní testovací demo. Jak ten kraťoučký testovací program, tak už i tu myší knihovnu. Ten soubor *.ptp si otevřete v emulátoru PMD-85, nahrajete jej příkazem MGLD 01 a spustíte příkazem JUMP 0000. A uvidíte výsledek.
Vďaka za podrobný výklad, nakoľko sa assembleru nevenujem, osvojil som si tú druhú „praktickú“ časť :)
Čiže stačí takýto krátky .ptp súbor 2in1. Osobne viac využívam original PMD85-2A a 3 a .ptp spúšťam cez PTP Manager.