Soros PC egér illesztő Commodore-hoz

Előszó

Ez az illesztőterv hosszú fejlesztés eredménye. Ez valójában az első mikrokontrolleres terv amit valaha is kezdtem. Valamikor néhány éve kezdett érdekelni a dolog. Az első vonalakat a prototípus kapcsolási rajzán talán 1998. elején kezdtem rajzolni. Később 1998 közepén ez lett a diplomamunkám témája az államvizsgámra. Mivel voltak hiányosságok a tervben, gyakran kiraktam az asztalra, és időztem el rajta - csak alkalmilag - ilyenkor általában átnéztem a panelt (gyorsan összegeztem 4-5 alkalommal) és bővítettem a szoftvert új részlettel. Úgy gondolom ennek ellenére hogy lehetett volna még néhány részlettel bővíteni, de szerintem a legjobb eredményt oszthatom meg veletek (már a kezdettől úgy terveztem, hogy ingyenes lesz a terv) és lássam van-e valaki aki értékeli (vagy egyáltalán érdekel-e valakit).



Szóval itt van ;-). (a kép egy síkágyas szkennerrel készült.)
 

Interface photo

 

Sok ember segített nekem a fejlesztések során (néhányan nem is tudják hogy segítettek :-) ). Először is a legtöbb Commodore anyag a Funet CBM archive -on volt elérhető. Egy meleg személyes köszönet a következő embereknek (nem fontossági sorrendben) Turóczi Endre (a panel elkészítésében segített); Oravecz László (1351 egér adatok). Köszönet a többieknek akik anyagait használtam: Tomi Engdahl (PC-s egér információk), Jens Dyekjör Madsen (simple PIC programmer), Silicon Software Studio (PIP02, PIC programozó szoftver) /sajnos megszűnt a cég - a fordító megj./, Microchip Technology Inc. (MPASM, nem beszélve a csodás PIC családról! ;-) ), Holophase Inc. (Circad). A dokumentum a Netscape Composer segítségével készült, a képek az Adobe Photoshop 4.01-es verziójával lettek szerkesztve.

Ez az 1.01-es verziója ennek a dokumentumnak (2001.01.08), megjegyzésekkel a PIC16F84-es chiphez, és kijavítva egy rossz link.


Szerzői jogok

A tervekre, és a szoftverre minden jog fenntartva 1998, 2000 Hársfalvi Levente részére. Minden amit itt találsz a General Public License alatt lett publikálva, amit a Free Software Foundation adott ki. Abban a reményben lett terjesztve, hogy hasznos lesz, de MINDEN GARANCIA NÉLKÜL; beleértve az ANYAGI, és NEM MEGFELELŐ HASZNÁLATBÓL eredő károkat. Bővebben lásd: GNU General Public License .


Tartalom

Ha akarsz építeni egy illesztőt, és mélyebben meg akarsz ismerkedni az alapelvekkel, akkor próbáld meg ezt a linket
 


Áttekintés

Az emberek akik a C= világban élnek tudják, hogy a Commodore nem tervezett egér támogatást a 8 bites vonalhoz, amikor a gépek először kerültek az üzletekbe. Amikor a C64 1982-ben megjelent nem okozott gondot az egér hiánya; támogatta az eléggé elavult tekerőt, valamint a szabványos digitális (ATARI VCS típusú) joystick-okat. Az egér támogatás jóval később jelent meg, amikor a GUI-k mint a GEOS tervbe lettek véve, és megjelentek. Az első egerük az 1350-es volt, majd később az utódja az 1351. ... de ahogy a dolgok mindig is mentek a Commodore-nál, a rossz üzletpolitikájuk nem segítette ezeknek az egereknek az elterjedését. Ha a C64-ről beszélünk, ahogy látom, a legnépszerűbb mutató eszköz mindig is a joystick volt, és nem sok alkalmazás, kivéve a GEOS természetesen, támogatta az egeret közvetlenül.

Más részről egy egér nagyon hasznos lett volna sok esetben. Emellett sok program lehetett volna irányítható egérrel, vagy a joystick mellett segédeszköz. (Próbálj meg rajzolni valamit az Art Studio-ban joystick-kal, vagy egérrel; tudni fogod mit jelent amire gondolok. Az érzés kissé más.)

Jelenleg nálunk (Magyarország, Európa) a Commodore egér beszerezhetetlen. Sajnos egyetlen eredeti 1351-es egerem sincs (pedig nagyon próbáltam szerezni egyet) :-(. Ahogy emlékszem még beszerezhetőek az Egyesült Államokban. Ez viszont nem számottevő különbség az én nézőpontomból, mivel nehezen beszerezhetőek, és drágák. Egyetérthetsz velem, vagy nem - a lehetőségeidtől függ.

Viszont mindenki tud egyszerűen szerezni egy tökéletes, jól kinéző és olcsó PC kompatibilis egeret bárhol a világon. Miért ne próbálnánk meg összehozni ezeket az egereket hogy a C64-el működjenek ha lehetséges?...

Ez az utolsó 'ha' meglehetősen komplikáltabb mint bárki gondolná első ránézésre... A Commodore 1350/1351 és a PC soros egér dugója egyforma ;-), és eléggé azonos a mechanikai, és elektronikai tervezésük is. De sajnos ezek az utolsó hasonlóságok. A fő probléma egy soros egeret illeszteni egy Commodore-hoz, hogy a Commodore eltérő kommunikációs módot használ (és vannak feszültségszint inkompatibilitások is). Röviden, a Commodore egér követi a Commodore tradíciókat. ... vagy inkább feltételeket. Nyilvánvaló okok miatt a Commodore-nak olyan egeret kellett készítenie, amit a joystick portra lehet csatlakoztatni a legszélesebb körben elterjedt géphez, a C64-hez. A másik oldalról a PC soros egér tulajdonságai történelmi okokra vezethetők vissza. Az IBM se tervezte az egér támogatását amikor kiadta a PC-t; amikor az egér fontossá vállt, a PC/egérgyártóknak sok dolguk volt hogy megteremtsenek egy valódi egértámogatást. A nagyon drága megoldás mellett (busz egér ISA illesztőkártyával) olcsóbb megoldás volt visszatérni a már meglévő (általában nem használt) RS-232 soros porthoz. Az egér elektronika tápfeszültségét néhány nem túl fontos RS-232 port csatlakozóról kapta, és az egér a mozgás adatokat sorosan küldte át (RS-232-es szabvány) a kommunikáció során. Később az IBM megjelentette a PS/2-es egeret egy dedikált egérillesztővel, és porttal az új IBM PS/2-ben, de hosszú ideig ezt a tervet nem támogatták széles körben. A soros egér lett a piac közös tárgya.

Ahogy ebből a rövid áttekintésből is látszik, egy PC egeret illeszteni egy Commodore számítógéphez meglehetősen bonyolult. Az illesztőnek tartalmaznia kell a soros egér (vagy bármilyen egér) pontos emulációját, egy kis szerencsével hogy a belső alkatrészek, diódák, szenzorok ne melegedjenek túl, + szintén szükséges a pontos (esetleg programozható) logika ami a C= egér chipjét helyettesíti.

Vagy tartalmaz egy egeret közvetlenül összekapcsolva a számítógéppel - minden alkalmazást átalakítva egy zavaros kóddal hogy kezelje az egyedi (nem C= szabványos) egér típust. Mindamellett ezt láttam már régen; Frank Kontros illesztett Amiga egeret a C64-hez felhasználva némi TTL csatoló logikát, és néhány programot amik eleve kezelik az Amiga egeret (minden járulékos áramkör nélkül) a joystick porton (Egy példa a Fart Studio, egyszerűen módosított változata az Art Studio 2.3-nak). Egy másik példa közvetlenül összekötni egy soros egeret a C64-el (extra áramkörök nélkül, az Expansion portról kapja a TTL szintű tápot - néhány egyszerűen tervezett egér jól működik ha alacsony bemenő feszültségű jelet kap 0 - +5V között). Ez utóbbi Soci/Singular crew által készült (Ő alkalmazta ezt a Fuckpaint-ban, a grafikus editorában). Mindkét megoldás lehetséges. Járulékos probléma az Amiga egérnél (amellett hogy lennie kell) : a joystick port csatlakozóinak folyamatos vizsgálata jelentős processzor erőforrást foglal le, tehát csak olyan programok kezelése lehetséges, mint a grafikus szerkesztők, de nem lenne jó más programokhoz amelyeknél a processzor erőforrás kritikus.

Vagy beszélhetünk egy eltérő megközelítésről: készíteni kell egy illesztőkártyát, nem babrálva a PC egeret és/vagy a programokat, de pontosan emulálni a Commodore saját egerét ezzel a kártyával valahogyan. Ez néz ki a legbonyolultabb megvalósításnak, de ezzel néz ki a legkevesebb probléma ha az illesztő már jelen van (nincs probléma az egér belsejével, és a programokkal amik a joystick-ot kevésbé támogatják)

Az illesztő ami le van írva ebben a dokumentumban a Microchip PIC16c84 mikrokontrolleren alapul, amely egy kicsi, meglehetően olcsó 18 lábú áramkör ami tartalmaz egy kis CPU magot, 1Kx14bit EEPROM program memóriát, és egy halom egyéb hasznos dolgot. Csak rá kell dugnod az illesztőt a joystick portra, rádugni egy PC soros egeret (támogatott a Microsoft, és a Mouse System protokoll) az illesztőre, és Voalá!


 Technikai háttér

 Az egerekről általában

Nem szeretném fölöslegesen vesztegetni a szót ebben a témában. Röviden egy tipikus opto-mechanikai egérnek három fő része van: a mozgási futófelület a golyóval, a két tengely a végükön réselt tárcsával és optikai érzékelőkkel, a gombok, és a vezérlő elektronika. Amikor valaki elmozdítja az egeret, a golyó átadja az elfordulást a tengelyeknek X, és Y irányban. A két réset tárcsa a tengelyek végén nyitja, és zárja a két pár optikai kaput folyamatosan. A jel az optokapukról és a gombok az elektronikához vannak csatlakoztatva.

A legegyszerűbb egér a következőképp működik - nem tartalmaz más elektronikát, csak az optoérzékelőket, és gombokat amelyek jelei közvetlenül a fogadó számítógépbe mennek (némi elektronikus jelszint illesztővel). Két tipikus képviselője a Commodore Amiga, és a PC busz egér. A működésnél a gazda számítógép feladata dekódolni a mozgást az optikai érzékelők jeleiből, ami jelentős processzor erőforrást igényel (sok lekérdezéssel terhelt), vagy egy sokkal barátságosabb (= bonyolultabb), egér illesztő áramkör.

A legtöbb egér beleértve a C=1351 és a legtöbb PC egeret más módon működik. Van bennük egy kis 'intelligens' chip, 'controller' (vezérlő) az egér belsejében, követi az optikai érzékelők jeleit, a mozgásokat, és elküldi az elmozdulás adatokat a gombok állapotával együtt a gazda számítógépnek kódolt formában. Ez a megoldás előnyös, mivel egyszerűbb, és sokkal hatékonyabb a meghajtóprogram a gazda számítógépen (nem beszélve a történelmi okokról, mint a soros, és a C=1351 háttere). Amint már említettem, minden RS232 típusú soros, PS/2, USB egér, és az 1350/1351 ebbe a csoportba tartozik.
 
 

A Commodore 1351A

Ez az egér a második kísérlet a Commodore-tól amivel segíteni akarta a 8bites felhasználókat egy egérrel (A kistesójával a C=1350-el). Kívülről az egér kinézete megegyezik az Amiga 500-hoz járóval. Belül azonban sok eltérés van. Ameddig az Amiga egér csak egy 'csokor' optikai érzékelő, mikrokapcsoló, és egy egyszerű 4 utas analóg komparátor, az 1351 egy sajátos Commodore chipet tartalmaz (MOS 5717), átalakítva ezt a 'csokrot' egy félig intelligens egérré. ... Félig intelligensnek neveztem, mivel csakugyan tartalmazza a kódolást, mint a legtöbb intelligens egér teszi, de a kódoló eljárás bedrótozott (lásd az 1351 adatlapját ha érdekel bővebben).

Az 1351 két különböző üzemmóddal rendelkezik. Tudod használni joystick módban (amikor mozgatod az egeret úgy viselkedik mintha egy joystickot mozgatnál). Ezt úgy hívják hogy 1350 vagy kompatibilis mód. Joystick módhoz lenyomva kell tartani a jobb gombot miközben bekapcsolod a gépet. Belül az egér logikája átalakítja az egér mozgásait joystick eseményekké egy egyszerű eljárással: amikor mozgatod az egeret a chip rövidre zárja a megfelelő joystick irányvonalat a testtel ~20ms időtartamig (Kapcsolódó infó: a bal egérgomb lesz a tűzgomb, míg a jobb gomb a POTX vonalhoz van rendelve). Ha az egeret lassan mozgatod a hatás valódi mozgáshoz hasonló, de ez a hatás megszűnik ha a mozgás folyamatos (gyors). Ez az üzemmód nagyon hasznos olyan alkalmazásoknál amelyek nem támogatják közvetlenül az 1351-es egeret.

Valódi 1351-es (arányos) módban az egér le tudja követni, és elküldeni a számítógépnek a valós mozgásokat. Ha megnézed a C64 joystick portját sejtheted, hogy a Commodore mérnökei nehéz napokat éltek át amikor ilyen leleményes protokollt kellett kidolgozniuk ;-). Rengeteg időmbe telt mire teljesen megértettem a lényegét. Eddig a ponting minden Commodore egér programozó tudja, hogy a lineáris mozgás közlése a SID POTX, és POTY vonalon át valósul meg.

A C64 oldaláról az egér pozíció lekövetése a következő képpen zajlik:

  1. Fenntartva egy változó az egér pozíciójának, és a mutató pozíciójának mindkét (X és Y) irányban.

  2. A 4066 analóg kapcsolók bekapcsolása az általánosan használt joystick porton, hogy a SID POT vonalai hozzákapcsolódjanak a joystick portra. Ez elvégezhető a CIA1 chip PA6 vagy PA7 kimenet egyenkénti '1'-re állításával ($DC00-án állíthatod be). Ha a POT vonalak előzőleg nem voltak csatlakoztatva várni kell 'egy csomót'. Jobb megoldás aktiválni a SID POT kimeneteit néhány periódusig, azután beolvasni az egér pozíciót először, lekezelni a billentyűzetet (kikapcsolni a SID POT-ot ha szükséges), és újra aktiválni a vonalakat. Erre a SID, és az 1351 szinkronizálása miatt van szükség.

  3. Be kell olvasni a POTX, és POTY regisztereket a SID-ből ($D419 / $D41A). A 0. bit zaj, a 7. bit pedig nem változik. A maradék 6 bit az egér aktuális koordinátái.

  4. Össze kell hasonlítani a letárolt, és beolvasott pozíciót amiből számítható az elmozdulás, és az új pozíció. Ezután a mutatókat a különbséggel meg kell változtatni. Utolsó lépésként ki kell cserélni a régi egér pozíciót az újjal.

  5. A 2-es lépéstől ismétlődik.



A pozicionálás természetéből adódóan az adat amit az 1351-ből veszünk, és a pozicionáló algoritmus nem túl biztonságos. Csak az alsó 6 bitje kerül elküldésre az aktuális pozíciónak, ezért a fenti algoritmus nem tudja pontosan meghatározni a mozgás irányát (1351 felhasználók ismerik a dolgot amiről beszélek: ha túl gyorsan mozgatod az egeret a mutató eléggé rángatózik egy pont körül ahelyett hogy lekövetné az egérmozgást). A problémának két megoldása van: megpróbálni frissíteni a mutató pozíciót minél többször, így a helytelen érték két lekérdezés alatt kisebb (a mintavételi periódus elméleti minimuma 512 ciklus ha a SID sosem kapcsolódik le a joystick portról a CIA portbitjei által). Egy másik megoldás hogy alkalmazzunk egy agyafúrtabb egér meghajtó algoritmust. Ez az amit Andrew Vardy-tól vettem ebben a témában.
 
"Minden amire szükséged van letárolni az előző hibás elmozdulást, így össze tudod hasonlítani a következő futásnál. Ha van egy hosszú vízszintes eltérés, a rutin természetesen tudja, hogy ez a rész hibás volt, tehát figyelmen kívül hagyja a jelet. Egyszerűen lehetetlen, hogy a felhasználó tudja mozgatni az egeret jobbra, majd egy századmásodperccel vagy néhány tizedmásodperccel később, mozgassa az egeret gyorsan jobbra. Ez egy egyszerű következtetés. Egyszerűen tudod ellenőrizni ezeket az eseteket:

*ha Elozo_pozicio nagy ÉS aktuális_pozicio nagy (>xx)
ÉS
*ha jelek ellentétesek

akkor dobja el a jelet. Nem ördöngősség ugye?"



Az 1351 belseje

A belső működés megértéséhez fontos beszélni arról hogyan is működik a SID POTX/Y bemenet. Ahogy ismeretes ezek felelősek egy külső változtatható ellenállás értékének a bedigitalizálásáért. Ez úgy nevezzük: a tekerőkerék pozíciójának meghatározása. A tekerő potenciométer a +5V, és a SID POTX vagy POTY bemenet között helyezkedik el (egy 4066 CMOS kapun keresztül, de ez nem fontos ennél a pontnál, jelentősége csak a SID POT vonalak két joystick port közötti megosztásának van). Egy kis értékű kondenzátor (1000 pF keramikus) van a test, és a POTX / POTY között a számítógépben. A digitalizálási eljárás ('single slope') működése során ezt a kis kapacitást süti ki a SID POTX/Y vonalon keresztül, majd megméri az időt ami alatt a kapacitás feltöltődik a SID bemeneti küszöbszintjéig a potenciométeren át. Kisebb ellenállásnál rövidebb a feltöltődési idő (egyenes arányosság van az ellenállás, és a töltési idő között).

Az egész digitalizálási műveletet a SID maga csinálja. Az eljárás 512 órajel periódusig tart. Az első 256 ciklusnál a SID alacsonyra húzza a POTX / X kimeneteket, és teljesen kisüti a kondenzátorokat. Ezután a lehúzókat kikapcsolja a kimenetről, elkezdi a ciklusokat számlálni (egyel növeli minden órajelciklusnál) és figyelni kezdi a vonalat. A kapacitások töltődni kezdenek (a +5V-ból a potenciométeren átfolyó árammal). Amikor a feszültség a kapacitáson eléri a SID bemenetének küszöbszintjét, a SID kiolvassa a számláló értékét, és berakja a POTX/Y regiszterbe. A művelet ismétlődik újra és újra.

(Megjegyzés: ha az ellenállás túl kicsi, a kapacitás 'azonnal' feltöltődik, tehát az érték amit a SID kiolvas '0'. Hasonlóan ha túl nagy, vagy szakadás a kapacitás nem töltődik fel a mérési periódus alatt így a SID '255' értéket olvas ki.)
 
Az 1351-es belsejének feltérképezése végül az eredeti 1351 mouse patent document (US No. 4,886,941, 1989.12.12) elolvasásával lett teljes. Itt egy rövid megjegyzés az algoritmusról ami a MOS 5717 egyedi chip tartalmaz az egérben.
 

Egy adott pozíció érték átadása a következőképpen történik:

  1. A chip figyeli a Sync bemenetét, ami közvetlenül a POTX-re van kötve. Amikor a bemeneti szint eltűnik a SID mérési ciklus kezdetét jelenti.

  2. A számláló kezdeti beállítása 0-ra. Ezt növeli minden órajel-periódusnál (1MHz) 1-el. Egy hasonló érzékelőt indít a következő fázisban, amikor a számláló eléri a 256+64=320 ciklusszámot.

  3. Ezután a számláló továbbra is növekszik minden órajelciklusnál. Két azonos detektor komparálja a számláló 6-1 bitjeit mind az X és az Y irányban a mutató 5-0 bitjeinél. Amikor az értékek megegyeznek, az adott POT kimenet magasra húzza. A mérő kapacitás a SID mellett töltődni kezd az 5,1K ellenálláson át, és néhány ciklussal később a szint eléri a SID bemeneti küszöbszintjét; A SID kiolvassa a számláló értéket az olvasható POT regiszterbe. Az érték át lett küldve a számítógépbe ;-).

  4. A chip várakozni kezd, 512-32 (=480) ciklusig, aztán megszakítja mindkét POT kimenetet. Ezután a #2-től újrakezdi

Néhány kiegészítés a fentiekhez. Úgy gondolom az emulátor programozók is hasznot húzhatnak ebből, hogy felfedeztem néhány kizárólag 1351-es dolgot



Hát, szerintem meglehetősen furcsa eljárás...
 
Végül itt egy rövid összesítés a C64 joystick port kiosztásáról. A csatlakozó egy Cannon DB-9 (tüskés)



Lábszám 

Jel neve 

Feladat 

FEL 

Fel irány bemenet 

LE 

Le irány bemenet  

BAL 

Bal irány bemenet  

JOBB 

Jobb irány bemenet 

POTY 

Tekerő Y bemenet 

TŰZ 

Tűz bemenet 

+5V 

Tápfeszültség kimenet

GND 

Közös test

POTX 

Tekerő X bemenet 

A Commodore 64 joystick port kiosztása

PC soros egér

Sok különböző PC egér tervet csináltak, és sok közülük ma is jelen van. Röviden, három alapvető típust találhatsz: soros, PS/2, és USB egeret csatlakoztatva az RS232, egy kitüntetett PS/2 egérportra, és az USB portra külön-külön. Néhány egér 'kombi', azaz csatlakoztatható minden soros / PS/2, vagy PS/2 / USB portokhoz (általában egy kis adapter segítségével ami az egérhez jár). Az utóbbiak kiforrott tervezésűek, de a soros fajta nem nyilvánvalóan az. A soros portot általánosan kommunikációra tervezték, nem pedig egy külső eszköz csatlakoztatására. Az egérnek szüksége van némi áramra a működéséhez. Mivel itt nincs kitüntetett tápfeszültség forrás a soros porton, az áramot néhány nem használt jelkimenetből nyerjük (amelyeket a kívánt szintre a PC-n futó driver program állít be). Ez egy kicsit sántít, de mivel ezek az egerek általában alacsony fogyasztásúak, a tápáram relatív kicsi, körülbelül néhányszor 10-15 milliamper. Az érték az RS232 szabványban megadott maximum alatt van, tehát ez így helyes.

Ebben a dokumentumban el fogom kerülni hogy mélyebben belemenjek a PS/2 vagy az USB egér működésébe, mivel a PS/2 egér más programozási technikát igényel (a bitrátájuk meglehetősen magas, ami különleges illesztőhardvert igényel) a soros egérre koncentrálok.



Ez a táblázat az általános csatlakozási beállításokat mutatja az RS232 port, és egy soros egér között. Ez a táblázat a kisebb Canon DB9-es RS232 szabványú csatlakozó kiosztását veszi alapul. A jelek PC szemszögéből lettek elnevezve nem az egéréből.

Pin number

Signal name

...on the mouse 

1

DCD

Nincs bekötve 

2

RxD

Soros adat 

3

TxD

-Utáp 

4

DTR

+Utáp 

5

SGND

Közös test 

6

DSR

Nincs bekötve

7

RTS

+Utáp 

8

CTS

Fehúzva +Utáp 

9

RI

Nincs bekötve

Soros egér csatlakozókiosztása





A csatlakozások gyakorlati tapasztalatok alapján lettek feltérképezve, néhány különböző egérkapcsolás segítségével. Ennél fogva nem minden egérnél szükséges minden pontot csatlakoztatni; néhány egérnél elegendő csak egy +Utáp vonal. Mindemellett ez a kiosztás úgy néz ki hogy passzol minden egérhez. Ezt a táblát észben tartottam mikor az áramkört terveztem.

A soros egér szabványos RS232-es adatcsomagokkal kommunikál. A kommunikáció általában egyirányú, csak az egér küld adatokat a számítógépnek. Más vonal nincs használva a kommunikációhoz, legtöbbször az egér tápellátását biztosítja; csak az RxD adatvételi vonal bizonytalan. A vezérlő vonalak nem csak tápfeszültség vonalnak használatosak, hanem ezek szolgáltatják a feszültségszinteket is az RS232-es kommunikációhoz. A legtöbb egér 1200 bauddal kommunikál alaphelyzetben (a legtöbb közülük kizárólag 1200 bauddal, néhány tud csak átkapcsolni magasabb sebességre). A használt adatformátum típusonként eltérő. Általánosan a legtöbb egér kivéve a Microsoftot, és változatait 8 bitet használnak egy start, két stopbittel paritás nélkül (8N2-nek nevezik). A Microsoft variációk 7 bites adatcsomagot használnak, a többi paraméter azonos. A legtöbb soros egérnek 3 gombja van, kivéve a Microsoft kompatibiliseket amiknek kettő van. (Kivételek: néhány új Microsoft változat, mint a Logitech MouseMan és kompatibiliseknek (mint a Genius egerek) szintén 3 gombjuk van).

(Mellőztem felfedezni az újabb egereket görgetőkerékkel, és egyéb szerkentyűkkel, de ezeknek az alább tárgyaltnak egy variációjának kell lennie)

Mivel sok egér csak két protokollal kompatibilis, én ezekre koncentráltam, és nem tárgyalok másokat. Ezek a Microsoft, és a Mouse Systems protokollok. Ha veszel egy egeret a boltban várhatóan az egyiket, vagy mindkettőt megtalálod (napjainkban inkább a Microsoft fajtákat), és másfajta soros egeret nem. A régebbi egerek szintén támogatják ezeket a protokollokat kivéve a nagyon régieket. Végül ha neked egy nem kompatibilis egered van, akkor nézd meg az illesztő kontroller forráskódját és változtasd meg, hogy támogassa az egyedi egeredet.



Itt egy összefoglaló leírás található eme egerek adatformátumáról

Bit # 

6

5

4

3

2

1

Byte #

1

1

Bal

Jobb

Y7

Y6

X7

X6 

2

0

X5

X4

X3

X2

X1

X0 

3

0

Y5

Y4

Y3

Y2

Y1

Y0 

Microsoft egér adatcsomag

 

Az adatcsomag három 'bájtot' tartalmaz (helyesen: 7 bit adatot). Csak az első csoport bit6-ja '1' a többi '0' (ez a szinkronizálás miatt van; a vevő oldalnak tudnia kell melyik az első byte, és a többi a csomagban). X0..X7 8 bites előjeles adata az X iránynak az utoljára elküldött adatcsomag óta (nevezd Dx-nek). Az Y0..Y7 az Y irányé. A Jobb, és Bal az egérgomb bitek. Az egér ezeken a helyeken küld 1 bitet ha valamelyik egérgombot lenyomják. Összesítve bármi is változik a pozíciónál, vagy az egérgombok állapotánál az utolsó küldési időpont óta, adatcsomagot generál, és elküldi.

A fenti protokollt kiegészítve, a Logitech MouseMan egér azonosat támogat de egy kissé furcsa kiegészítéssel. Ezeknek az egereknek 3 gombjuk van. Amikor a harmadik gomb lenyomódik, az egér küld egy nem szabványos 4 bájtos csomagot. A 4. bájt azonosítható a 0 értékkel a 6. bitjében (1 helyett, aminek az 1. bájtnak kéne lennie). Ha ez jelen van, az 5. bitjében ennek a bájtnak van a középső gomb állapota. (Ezt az információt a GPM -General Purpose Mouse kiszolgáló Linuxhoz- dokumentációjából vettem; Egy kicsit ravaszkodtam a Nosey-el is ami egy egér detektáló Linuxhoz. Hálás köszönet a szerzőknek... )

Bit # 

7

6

5

4

3

2

1

Byte #

1

1

0

0

0

0

Bal

Középső

Jobb 

2

X7

X6

X5

X4

X3

X2

X1

X0 

3

Y7

Y6

Y5

Y4

Y3

Y2

Y1

Y0 

4

X7

X6

X5

X4

X3

X2

X1

X0 

5

Y7

Y6

Y5

Y4

Y3

Y2

Y1

Y0 

Mouse Systems egér adatcsomag

 

Ez az egér 5 bájt hosszú adatcsomagot küld amiből mindegyik 8 bites. Az első bájt szinkronizál. Bit0..bit2 adja vissza a három egérgomb állapotát. Szemben a Microsoft egérrel ezek a bitek 0-t adnak amikor a gombot megnyomják nem 1-et. X0..X7 megegyezik a fent tárgyalttal. A 4. és 5. bájt tartalmazhatja az első 3 bájt küldése alatt történt elmozdulást.



Úgy gondolom ez minden a soros egérrel kapcsolatban. Ezek nem olyan csúnyák mint az 1351 tervezése, tehát egérkezelőt írni hozzájuk sokkal barátságosabb, mint írni egy 100%-os kezelőt az 1351-hez (egy 1351 kezelőt sokkal nehezebb lenne lekódolni, ha a használt hardver nem számláló típusú digitalizáló). Más részről, mialatt az adatcsomag küldésre kerül, említésre méltó idő telik el (több mint egy periódusa az 50Hz-nek), az egérmutató nem mozog olyan simán mint például az Amigán. A PS/2 vagy USB egér jobb ezen a téren.
 
 



 

Az illesztő hardvere

Ez az illesztő kártya kapcsolási rajza. Nagy felbontású 300dpi verzióhoz kattints ide. Az eredeti kapcsolás CirCad 3.5-ös formátumban itt találod.
 

Interface schematics

 


Az illesztő lelke egy mikrokontroller (Microchip PIC16C84, de néhány másik is működik ebből a szériából - 16F84, 16CR84, és a 16C61). Ez egy kicsi programozható (és könnyen újraprogramozható) EEPROM alapú chip, a következő tulajdonságokkal:



A PIC16C84 nagyon közkedvelt a kis, alacsony költségű megoldásoknál. Az EEPROM program memóriája tökéletessé teszi az otthoni, és hobbi felhasználáshoz mivel lehetőség van felprogramozásra, törlésre, és újraprogramozásra könnyen. Sok programozó eszköz található a PIC sorozathoz a Neten. A bináris kódot egyszerűen be lehet tölteni a mikrokontrollerbe - csak egy PC-re van szükséged, és egy kicsi programozó kártyára ami néhány olcsó alkatrészt tartalmaz.

A hardver másik alkatrésze egy MAX232 RS-232 illesztő chip. Nagyon közkedveltté vállt; röviden, ez a chip gondoskodik minden szükséges jelszintről (a +-10V-ról) egy szimpla 5V-os tápról (4 elkó kondenzátor felhasználásával) és az RS-232 szintillesztésről. Ez látszik a legegyszerűbb megoldásnak egy egyszerű áramkörhöz mint ez az illesztő is, tápfeszültséget előállítani az egér részére. Keményen próbáltam keresni egy kisebb/egyszerűbb/olcsóbb utat a szükséges feszültség előállítására 15-20mA-es áramnál az egérnek, de túl sok idő elment a semmire. Ma mindenki beszerezheti a MAX232-t vagy kompatibiliset minden gond nélkül, és a chip is meglehetősen olcsó.

Ahogy a kapcsoláson látszik, minden tiszta, és követi a gyártó előírásait. A mikrokontroller (U1) előállítja az órajelét az Y1, C1, és C2-vel amelyek a Microchip által előírt értékeket követik. A 4-es láb VCC-re van kötve, hogy aktiválja a beépített power on reset áramkört a mikrokontrollerben.

Port A bemenetnek van használva. Valójában csak 2 láb van használva: RA0 a soros bemeneti láb, ami a MAX232-n át a soros portról érkezik. RA2 a J1-ről jön, és konfigurációs bemenetnek van használva: ha a GND-re van kötve akkor az illesztő joystick emulációs módban indul, egyébként arányos (egér) módban. (egyesek megpróbálhatják kicserélni egy DIP kapcsolóra, vagy nyomógombra (később változtatva lesz az init kód a kontrollerben))

Port B a kimenetek számára foglalt (öt joystick vonal ami közvetlenül megy a porthoz, és a POTX/Y vonalak amelyek ellenálláson át csatlakoznak). PortB.0/INT a POTX-hez csatlakozik. Ugyanabból az okból, amiért a Sync az eredeti 1351 egérnél: ezzel a mikrokontroller megszakítás kérelmet generál amikor a bemenetet eldobja.

Az ellenállások a POTX/Y vonalakon ugyanazt a szerepet játsszák mint az ellenállások az eredeti 1351-ben: lehatárolják az áramot amikor a két oldal ellentétes szintre húzza a vonalakat. Az ok amiért 11K ellenállásokat használtam: Úgy találtam, hogy a PIC kimenetei sokkal kisebb belső ellenállással rendelkeznek mint az 5717-nek van (amíg az 5717 valamilyen NMOS technológiájú a PIC valódi CMOS chip 20mA-es forrásárammal kimenetenként). Ez az érték kísérleti, ez az oka, hogy ugyanazokat az értékeket veszik a POT regiszterek mint az 5.1K-val az eredeti hardverrel (100% kompatibilitás :-) ).

A MAX232 konfigurációja szintén meglehetősen szabványos. Semmi különös, feszültségnövelő/invertáló kapacitások vannak használva, és egy RS-232-->TTL vevő. A pozitív, és negatív kimeneti feszültségek puffereltek C7, és C8 által amikor táplálják a soros egeret.

Az R3, és R4 szintén okoztak némi fejfájást és átkozódást :-/. Eltöltöttem némi időt mire rájöttem, hogy ezek a soros egerek valójában meglehetősen függnek elektronikai oldalról az RS-232-es szabványtól. Belül a legtöbb egy kisebb feszültségről üzemel (néha 5V-ról), amit valamelyik bemenetről csökkent le. A feszültség esést általában Zenner-diódával érik el. Mivel az egység a soros portról kapja a tápot, és mivel a valódi RS232 portnak van egy csinos 'magas' soros ellenállása, az egerekben nincs soros ellenállás; a feszültségesés az RS232 port belső ellenállásán jön létre, és az áram ezen keresztül folyik a Zenner-diódára, ahonnan a GND-be jut. Amikor nem használtam soros ellenállást, valami (a Zenner dióda) melegedett belül az egérben, ha a tápegység 'erős' volt. A MAX232 másként viselkedett: nem növelte, és invertálta a feszültségeket, mivel az elsődleges kimenete (a duplázott) eltűnt egy perc alatt C7-ből, ezzel az egér működésképtelenségét okozva.



 

Az illesztő szoftvere

 
Ha mélyen bele akarsz menni az emulációs szoftverbe, vagy a program valamilyen funkciójába, ajánlatosabb venni a forráskódot, és azt elolvasni. Ez a fejezet inkább a kód teljes megértésének támogatására szántam.

A programot alrészekre lehet osztani mint az inicializálás, a főhurok, a megszakítás kiszolgáló rutin, és szubrutinok. Az init meglehetősen közös

Az egér fajta detektálása

Szerencsére eléggé egyszerű azonosítani hogy Microsoft, vagy Mouse Systems egér van-e a porton. A protokollt azonosítani lehet ha a legelső első bájtokat beolvassuk amit az egér küld. Ez az egyedi bájt (a legelső bájtja az adatcsomagnak) speciális mindkét protokollnál, mivel egyformán szinkronnak használják. Microsoft módban '01XXXXXX' formájú (ha nincsenek gombok lenyomva: '0100XXXX'), míg a Mouse Systems-nél ez '10000XXX' (előző feltétellel: '10000111'). A soros vonal figyelésével, beolvasva ezt a bájtot a program el tudja dönteni az egér protokollt; azután beállítja ennek megfelelően a wflags.mouse_t-t és visszatér.

Az emulációs protokoll detektálása

Jelenleg J1 egy 'kapcsolóként' szolgál az emuláció fajtájának beállításához. Sajnos az 1351-es egyszerű eljárását nem lehet megcsinálni. Az egér nem adja az interfész tudomására a gombok kiinduló állapotát. A terv egyszerűsítése miatt, és a 16C84 beépített EEPROM-ból következett valami beállítás -féle amit az egérrel lehet valahogy állítani jumper (vagy DIP kapcsoló) helyett. Megpróbáltam elkészíteni valamilyen tárolót az EEPROM-ban, és visszaolvasni a wflags.emul_t-be induláskor, aztán ellenőrizni az egér első adatbájtját, és ha a jobb gomb megnyomott, invertálni ezt a beállítást, és visszamenteni az EEPROM-ba. Működnie kellett volna, de problémák merültek fel: az egérgomb adat a legelső bájtban nem volt határozott! Egy csomó bűvészkedés után fogtam az egészet, és elálltam az ötlettől. Később amikor hibát kerestem a kódban kiderült, hogy egy hiba volt az alapértelmezett IRQ kezelőben, így ez a soros számlálót (sch) háromszor lassabban futtatta mint szükséges lett volna, így az utolsó bitek az első adatcsomagból hibásak voltak. Ennek ellenére megtartottam a jumpert, habár eltávolíthattam volna a kártyáról hogy a sokkal bonyolultabb, ám felhasználóbarátibb megoldást csináljam.
 

Joystick mód

Mivel ez a legegyszerűbb mód, az illesztő hosszú ideig csak ezt a módot támogatta (az 1351 mód volt az utolsó vonás amit hozzáadtam, mivel ezt eléggé nehéz volt elvégezni). Röviden, először az eredeti módszert készítettem el (a joystick irányvonalainak pulzálása 20 millisecundumos impulzusokkal amikor az egér mozog) de nem voltam elégedett az eredménnyel, így valami másat próbáltam. Az eredmény olyan kinézetű/érzésű lett ami kicsit jobban hasonlít az arányos viselkedéséhez (végül jobb lett mint az eredeti, viszont a joystick mód durvább megközelítése az arányos mozgás átadásának :-( ).

Ez a mozgásérték --> késleltetés mint az arányos megoldásnál. Ez azt jelenti, ahogy mozgatod az egeret a program mindig megpróbálja követni a mozgását időben, és alacsonyan tartja a joystick vonalakat amíg a különbség nem nulla.

Az eljárás természete miatt van két kritikus paraméter. Az első az időalap, a késleltetése a mozgásegységnek. Az érték kísérleti, a programban hatvanszorosa a megszakítási periódusnak, ami körülbelül 3,84 millisecundum (más szóval ~5,2 mozgásegység felel meg az eredeti 20 millisecundumos késleltetésnek az 1351-nél). A másik fontos érték a maximálisan elfogadott elmozdulás (a maximális idő az egér gyors leállítása + hosszas mozgatása). A kódban ezt a Clcimit rutin végzi, amely behatárolja az aktuális koordináták +-64 -re (szintén kísérleti érték) így az érték nem eshet kívül a +-64-es intervallumon.
 
Az egéradatok beolvasása (Serin), a bájtok értelmezése, az X és Y mutatók frissítése (Clclimit hívása először, aztán a behatárolt eltérések X és Y-hoz adása) a főhurokban kerül végrehajtásra. Az ok, amiért nem használok egy 'paraméteres' főhurkot a sebesség, és az aránytalanul sok ugrás (egyszerűbb volt így); az egér csomagok Microsoft és Mouse Systems egerek sokban eltérnek egymástól, így különböző eljárások szükségesek. Az egérgombok szintén itt vannak értelmezve, ami beállítja a megfelelő biteket az OUTBUF változóban. A valós frissítést a joystick vonalakon az IRQ rutin végzi.

Hasonlóan az 1351-hez, a bal egérgomb a TŰZ-höz van rendelve, a jobb gomb pedig a POTX-hez (amikor a jobb gomb van megnyomva, <$80 érték van a POTX regiszterben). Mivel mind a Mouse Systems, mind a Logitech Mouseman egérnek van harmadik gombja, alkalmassá tettem hogy a POTY regiszterhez rendeljem, mint az előzőt.
 
Két tárgyalni való komponens maradt: az IRQ rutin és a soros vevő rutin (SERIN).

Ennél a mikrokontrollernél sajnos nincs sok hasznos szerkentyű amivel játszani lehet :-(. Hiányzik a hardver RS232 port, így az RS232 kommunikációt szoftverből kell kezelni. Ez a rutin folyamatosan figyeli a soros bejövő vonalon a startbitet, és beolvas 7 vagy 8 bit adatot a wflags.mouse_t -től függően (7 bit adat ha Microsoft egér van a porton, máskülönben 8-at). Az időzítést TMR0-ból veszi (az egyetlen időzítő a mikrokontrollerben). Ha az időzítő IRQ rutinja aktív, Serin frissíti az Sch változót. Sch növelve van minden 64 utasítás ciklusban. A szükséges bit időt az 1200 baudhoz, ez az IRQ periódusnak kell számolnia újra 13-szor (a periódus értéke körülbelül 1202 Hz, ami elég közeli az 1200-hoz). Amint egy startbitet érzékel, Serin várakozik, amíg Sch 4-el nem növelődik (megbizonyosodva hogy ez valahol a startbit idő egyharmadán van). Ezután Sch-t 4-el csökkenti, és 1 bittel eltolja az FSR által címzett regisztert minden időpontban, amikor Sch eléri a 13-at (aztán csökkenti 13-al). A végén, ha 7 bites adat érkezett eltolja még egyszer a helyes pozícióba. Végül visszatér amíg nem érzékel stop bitet.

Végül néhány szó a megszakítás kezelésről. Röviden a PIC sorozatnak egy 'teljes' IRQ kezelője van egy halom lehetséges IRQ forrással. Az IRQ rutinnak a 04h címen kell kezdődnie. Nincs prioritás beállítva, ugyanaz a megszakítás kezelő rutin aktiválódik amint egy IRQ bekövetkezik. A visszatérési címet berakja a verembe, de sem a státuszregisztert, sem a munkaregisztert nem menti hardveresen :-O. A rutin felelős a megszakítási jelzőbitek törléséért, kivéve a globális megszakítás engedélyezőt, amit a RETFIE utasítás kezel. A végén a regisztereket vissza kell állítani.

Mivel sok különböző feladatot kell az illesztőnek elvégeznie, megváltoztattam egy kissé a bedrótozott kezdőcímű IRQ kezelőt. A kódok itt elmenti a regisztereket, aztán beolvassa az 'irql' változót, és beírja a PCL-be. Nem aggódom a PCH miatt, mivel minden IRQ rutin $0100 alatt kezdődik, de ez elegendő (és mindenképpen gyorsabb).

Van itt még egy gubanc. TMR0 az egyetlen felhasználható számláló a 16C84-ben, és ez csak 8 bites és nem automatikusan újratöltődő :-(. Konstans időzítéshez mindig újra kell tölteni 'kézzel' az IRQ rutinban. A Commodore-os embereknek ez gyanús lehet, mivel az IRQ indulhat előre meghatározatlan időpontokban is. Szerencsére a PIC egyszerű felépítése segít ebben: minden utasítás egy ciklust vesz igénybe. Minden ugrás két ciklus alatt fut le mint két egyszerű utasítás :-) (a GOTO maga, és egy NOP ami kiüríti a beolvasott utasítást az utasításcsőből). Amikor egy IRQ bekövetkezik, elindul amit az aktuális utasítás véget ér. Más szavakkal minden IRQ 'ciklus pontos' az időzítő minden kiegészítése nélkül. Végül újratöltődik az időzítő az IRQ kiszolgálóban ami konstans időzítéseket tud produkálni, mivel az újratöltés megtörténik előre meghatározott időpontban.

A joystick emulációs megszakítás rutin magában elég egyszerű. Miután elmentette a regisztereket, és beállította TMR0-t, növeli Sch-t (soros időzítő), csökkenti Stickcnt-t, és ellenőrzi hogy 0-e? Ha igen frissíti az X pozíciót mint fenn, és újratölti Stickcnt-t. Ha az érték 30, frissíti az Y pozíciót. Végül beírja az eredményt az Outbuf-ból TRISB-be (PORTB adatirány regisztere).

1351 mód

Pfúúú =-|... Ez valószínűleg a legtrükkösebb kód amit valaha csináltam. Az ok mélyen amögött a tény mögött van hogy ez a mikrokontroller meglehetősen egyszerű és bármit meg lehet csinálni szoftverből. Bit faragás. Nagyon ismerős kifejezés a mikrokontroller programozásban :-).

A joystick módhoz hasonlóan, a mikrokontrollernek kell beolvasnia az egér adatokat az egérből, és gyakran frissíteni a belső változóit. Mivel valódi lineáris mozgást közvetít, nincs szükség a határolásra mint a joystick módnál.

Mi szükséges az 1351 emulációjához?

Ez felvet egy halom problémát. A SID ciklus kezdetét érzékelni (egy órajelciklus precizitással) az első; szerencsére az egyszerű felépítés és a PIC külső IRQ-ja segít. POTX az RB§/INT-re van csatlakoztatva. A megfelelő beállítással, egy negatív él az INT-en indítja az IRQ-t, ami elindul, ha az aktuális utasításnak vége.

Egy új probléma is előjön: a külső megszakítási ciklus igénye miatt minden egyéb megszakítást le kell tiltani (egyébként az aktuálisan kiszolgált IRQ hibás időzítéseket kap). Tehát a TMR0 megszakítást le kell tiltani. Tehát a soros bemeneti rutint másképpen kell kezelni, mivel ez függ a TMR0 megszakítástól aminek a feladata Sch növelése minden alkalommal. Ez ki lett javítva a Serin-ben; Amikor TMR0 IRQ tiltva van, saját maga kérdezgeti le az időzítőt, és frissíti Sch-t, felhasználva Scl-t egy másik változót amit négyszer növel egy frissítési cikluson belül. A túlcsordulást Scl-ből Sch-ba számolja, és végez egy számítást (még precízebb).

Másodsorban, miután a külső megszakítási rutin elindul, a feladatnak szüksége van TMR0-ra a saját időzítése miatt. Egy teljes SID mérési ciklust nem szolgálhatunk ki egy hosszú időzítéssel, mivel hosszabb mint egy fél bitideje az 1200baud bitnek, tehát a program el fog veszteni néhány bitet rendszeresen. Minden alrutin időzítését TMR0 végzi; Megszakítás tiltva.... Ez volt az első helyen, létrehozni a saját időzítés-frissítését a Serin-nek, mivel TMR0 megváltozik minden szó nélkül. (Mind a Serin, mind az impulzus időzítésnek szüksége van TMR0-ra egyazon időben, mivel csak egy időzítő van a 16C84-ben) Végül két jelzőbittel lett megoldva wflags-al. TRACE1, és TRACE2 közül mindkettő 0 kezdetben. Amint az impulzus megszakítás elindul TRACE2-t magasra állítja, és egyszerűen törli ha befejezi az egész impulzusgenerációs eljárást - Serin nem változtathatja meg az időzítő változókat. Ezalatt a periódus alatt Sch frissítve van a TMR0 IRQ-val a másik folyamattal együtt. Más részről az U_sercnt rutin számolja az időt az utolsó futás óta, és ellenőrzi TRACE2-t. Ha nincs beállítva, beállítja TRACE1-et, és frissíti Scl, és Sch-t. A frissítés végén törli TRACE1-et. Az INT IRQ rutin frissíti Scl, és Sch-t, ha TRACE1 0 a megszakításkérés időpontjában, különben nem nyúl hozzájuk, így az U_sercnt rutinnak van gondja rájuk. (Fúúú...)

Akkor menjünk vissza az első (külső) megszakítás kiszolgálóhoz, TMR0 IRQ engedélyezett, a soros számláló frissítve van, és a másodlagos IRQ kiszolgáló van beállítva (Pirq2). Az időzítés 128 ciklus (az első megszakítási pontból).

Pirq2 egyszerűen frissíti Sch-t és beállítja a következő IRQ kezelőt (Pirq3). Az időzítés szintén 128 ciklus az előző megszakításból. Az első (256) ciklus, pl.: kisütési periódus a SID-ben eltelik mialatt Pirq3 fut. Az ötlet, hogy ne egyben teljen jobb felbontást ad Sch frissítéséhez (kétszer 2 egység, egyszer 4 egység helyett).

Pirq3 64 ciklust állít be a következő megszakításnak, mint az 1351 belső időzítése, de kevesebbre állítja, hogy Pirq4-nek legyen ideje lefutni.

A legtrükkösebb rész (ha a jelzőbitek nem voltak elegek ;-) ) a Pirq4-ben található. Ez a rutin ügyeli fel a POTX, és POTY vonalak felhúzását egy megadott ideig, egymástól függetlenül, egy megadott számú ciklus elteltéig tartja, aztán lehúzza azokat. Úgy gondolom a következő fejezetben fogom kifejteni részletesen. Először a rutin beállít 128 ciklust (+még néhányat) a TMR0-ba, hogy időben tartsa bármit is csinál a belső rutin. A végén lekérdezi az időzítőt hogy tudja vége van-e a periódusnak, aztán egyszerűen tiltja a TMR0 időzítő IRQ-ját, engedélyezi az INT-et, frissíti Sch-t, beállítja Pirq1-et, mindkét POT vonalat kikapcsolja, és visszatér a megszakítás kiszolgálásból. Egy ciklus volt kiszolgálva, ezután kezdi elölről. Mivel TMR0 be volt állítva, U_sercnt (ha fut) tudja használni számlálásra minden egyes ciklusban, és hozzáadja ezeket az Sch/Scl-hez.

A ciklus generáció ... Nos ezek után ez nem túl bonyolult miután elkészítettem, és újra átgondoltam ;-). Ez egy paraméteres időzítő vonal. Optimalizálva van a TRISB-be íráshoz a határértékek között 0..126 ciklusos periódusra. Felhúzni POTX, és/vagy POTY-t egy egyszerű TRISB-be írás végzi (hogy mit ír azt a külső rutin határozza meg, az X és Y értékek egymás komparálásával; ez fogja beállítani POTX, POTY-t vagy mindkettőt aktív állapotba). Az idő késleltetéseket GOTO*+1 utasítás végzi, ez megfelel "2 ciklusos NOP"-nak.

Egy késleltető ciklus valahogy így néz ki általánosan:

A kérdés a fenti késleltető vonal írására irányult. Ha statikus időzítéseket használunk akkor a program úgy fog kinézni mint egy halom NOP, kimenet beállítása, újabb halom NOP másik kimenet beállítása. Ami nekünk kell most, a NOP-ok számának vezérlése a kiment állítása előtt, és között. A programomban ez a 'futási NOP-ok száma' számított GOTO-kal van megcsinálva. Egy külső rutin számolja, hány darab 2 ciklusos NOP-nak (GOTO*+1) kell eltelnie, és az időzítő vonalat paraméterezi eképpen: 'ugrás egy hosszú NOP sorra - érték beírása TRISB-be - ugrás egy másik hosszú NOP sorra TRIB-be ír (előre kiszámított) értéket'

Van itt egy probléma. Az írás, és az ugrás szintén igényel néhány ciklust. Vannak speciális esetek, amikor néhány rész nem szükséges (0 a paraméter, tehát az első időzítő programot ki kell hagyni teljesen, vagy amikor a két koordináta egyforma, tehát egy időben kell váltani a kimenetet). Másik speciális eset, amikor szükséges, de túl rövid az időzítés ahhoz, hogy az algoritmus elvégezze, a járulékos ugrások, és utasítások miatt.

A végső megoldás egy csoport kódszekvencia ami csinál némi speciális időzítést és írja a TRIB-t, aztán beolvas egy értéket, beírja a PCL-be, lefuttatva egy 'számított GOTO-t'. Minden kis darab olvas egy 'programot', egy indirekt címző bájtszekvenciát, mindig csökkentve a mutatót a következő bájtban. A beolvasott bájt betöltődik PCL-be vagy TRISB-be az aktuális rutintól függően.

Az egész csoport egy külső rutinba van rendezve, 'Clcline' néven ami futtatásra kerül egyszer amikor az X és Y koordináta is ismert. A bemenő paraméterek amiket a rutin használ a feladathoz a számok közötti relációk (több/kevesebb/egyenlő), a kisebb szám értéke, és a különbség a számok között. A relációból a TRISB maszk van származtatva (az Outbuf értéke, + a POTX/POTY maszk; a második beírás természetesen mindkettőt felhúzza, és az egyezés speciális eseténél mindkettőt egyszerre kell felhúzni). Ha Y kisebb, az értékek, és a maszkok megfordulnak. A következő döntés függ a kisebb értéktől, és az utolsó különbségtől. A rutin ellenőriz minden speciális esetet, meghatározza melyik címet használja (=melyik részét a kódnak) beállítja a címet / TRISB értékeit a következő pozícióba hozza a késleltető program. Az időzítési értékek számítottak figyelembe véve az összes járulékos időzítést a részekben. Végül a program tudatja az IRQ rutinnal az új program kezdőcímét: beírja a Line változóba amit a megszakítás kiolvas.

Az időzítő program 6bájtot foglal el legrosszabb esetben. Line1 és Line2 fenntartottak a mikrokontroller RAM-ban. Természetesen a rutin dupla pufferelést használ: sosem próbálja megváltoztatni az aktuálisan aktív késleltető programot.
 
Fúúú... Azt hiszem könnyű volt megérteni a működést. Analizálni az összes speciális esetet, tüske volt a *eggben. A sok döntéshozás ellenére a számoló rutint meg kellet csinálni, szerencsére elég gyorsan fut. ... ellenőrizd a kódot ha szépet akarsz látni ;-).

A többi feladat már sokkal könnyebb. A gombok beolvasása azonos elven működik mint a joystick módnál le volt írva. Egy eltérés van: azonosan az 1351-hez, a jobb gomb a FEL-hez van rendelve, és ha rendelkezésre áll a középső gomb a LE-hez van rendelve itt. ...A gombokkal szintén volt egy kis gubanc: az állapotaik a kimeneti porton csak az IRQ kezelőben frissültek, tehát csak akkor aktualizálódott az állapotuk, amikor egy IRQ-t indított a SID chip. Úgy gondolom ez nem egy nagy probléma mivel nem lehet letiltani a SID POT vonalait teljesen, és csak a gombokat olvasni. Amikor az egér pozíciót olvassa a C64 a gombok állapota rendben van.



 

Hogyan épült...

 
Nos úgy gondolom nem túl nehéz utánaépíteni az illesztőt. Ha megpróbálod, feltétlenül szükséged lesz néhány eszközre, egy PC-re és szakértelemre, bár az áramkör elég egyszerű. Bár ajánlom, hogy készíts egy panelt, feltételezem, a múltat alapul véve ez a legnehezebb feladat, és egy próbapanelon építed meg az áramkört, vagy a kedvenc 3D hálózatoddal :-).

Ezekre az alkatrészekre lesz szükséged:
 
 

Alkatrész

Mennyiség

Megjegyzés

PIC16C84-04/P

1

Lásd a megjegyzést

MAX232CPE

1

Kompatibilisek is jók

4Mhz crystal

1

10µF elkó kondenzátor

4

16V, tantál

15pF kerámia kondenzátor

2

100nF kerámia kondenzátor

1

11k ellenállás

2

1/8W, 5%

680 ohm ellenállás

2

1/8W, 5%

DB9 dugó papa

1

DB9 dugó, mama

1

Mindkettő egyszerű dugó

DIP 20 foglalat

1

DIP 18 foglalat

1

Tűkivezetés

1

Kis darab J1-nek

Jumper

1

J1



Minden alkatrészt megkaphatsz a helyi kereskedőknél. A PIC 16C84 ára itt körülbelül 2000HUF ($7-8 ha igaz)
(A PIC 16C84-et nem gyártják már csak a 16F84-et melynek ára 1000Ft körül mozog - a fordító megjegyzése)

Helyettesítheted a 16C84-et egy másik (olcsóbb?) PIC mikrovezérlővel mint a 16F84, 16LF84, vagy egy 16C61-el, de tartsd fejben, hogy ezek különböző programozó készüléket / szoftvert igényelnek (de szoftveresen kompatibilisek). A PIC szakértők megpróbálhatják az újabbakkal, vagy a nagyon közkedvelt 16C71-el, bár ez OTP chip. (OTP-egyszer programozható. A 16C61, és 16C71-et nem gyártják már helyette a 16F620, és 16F710 van - a fordító megjegyzése) Nem teszteltem. Első próbának egy 16C61-04/JW kéne használni, mielőtt beégeted a kódot egy OTP verziójú chipbe.

Először el kell készítened a panelt. Készítheted a kedvenc eljárásoddal, de itt megtalálod az én módszeremet. Vannak cégek, ahol kis darabszámban legyártják a panelt. Szóval, itt a PCB (300 dpi). Használhatsz műanyag, és üvegszálas panelt egyaránt - az utóbbiak mechanikusan erősebbek, de nehezebb őket vágni, és fúrni. Ha unalmasnak találod a panel elkészítését, kihagyhatod és összehuzalozhatod az alkatrészeket egymáshoz panel nélkül - az áramkör eléggé egyszerű, csak bizonyosodj meg róla, hogy IC foglalatot használsz, és a vezetékek nem érhetnek össze.

Ellenőrizd a panelt szakadások, és zárlat ellen a vonalakat. Egy rövidzár az illesztő működésképtelenségét okozhatja, vagy kisüti a biztosítékot, vagy valami mást a számítógép belsejében. Vigyázz az egyszerű dolgokra is, mint a keret a körbe az áramkörön amikor vágod, ez csak a fizikai méret jelölésére van, nem része az áramkörnek, teljesen el kell távolítani, mert rövidre zárhatja a csatlakozásokat.

Az alkatrészeket magassági sorrendben kezdd beültetni. Ellenállások, kvarc, IC foglalatok, kondenzátorok, végül a jumper, és a DB9 csatlakozók. Használj hőfokszabályzós forrasztópákát. A sarkas alkatrészek jelöltek - a pozitív oldaluk megy a szögletes forraszszemekbe a panelon. A chipek 1-es lába szintén jelölve van. Végül a panelt közre kell fogniuk a DB9 csatlakozóknak. Használj kis drótdarabokat a felső oldali lábak csatlakoztatására a panelba. Mivel az alsó részét a csatlakozóknak közvetlenül a panelhoz kell forrasztani, a felsőket a drótok tartják. Elég stabil konstrukció.

Ez az ábra remélhetőleg segít (ellenőrizheted a fotót)
 

Components

 

Ha minden kész, akkor berakhatod a MAX23-t a foglalatba.

Mielőtt befejeznéd a munkát égetned kell (PIC dialektussal: befújni) a programot a PIC-be. ... ehhez a művelethez szükség van némi előkészülethez. Ha nincs neked, akkor szerezned kell egy PIC programozó áramkört, és szoftvert. Egy halom van mindenfelé a neten; Én személy szerint a PIP02-t használtam a Silicon Software Studio-tól, programozó hardvernek összedobtam egy egyszerű programozó panelt Jens Dyekjör Madsen.-től. Láttam PIC programozó alkalmazásokat Linuxra is. Be tudsz szerezni néhány stuffot a netről a lenti linkekről, vagy egyszerű kereséssel a kifejezésekre a témában.

Az egyszerű elkészítéshez itt a lefordított kód Intel Hexa formátumban (talán minden programozó be tudja olvasni). Egyébként letöltheted az ASM kódot, és újrafordíthatod MPASM-el.

Egy megjegyzés: ha a programozó hardver rosszul kezeli a konfigurációs biteket, a chipet így kell beállítani: XT oszcillátor, WDT bekapcsolva, PWRT bekapcsolva CODE PROTECT kikapcsolva

Ha beprogramoztad a PIC-et, be lehet ültetni a foglalatba.

Itt a pillanat amire vártál: kipróbálni működik-e az áramkör. Állítsd a jumpert joystick módba. Dugd be az illesztőt a joystick portjába a C64-nek. Dugj egy soros egeret az illesztő csatlakozójába. Vigyázva kapcsold be a rendszert (talán hasznos, ha először a képernyőt kapcsolod be). Ha semmi sem történik (nincsenek véletlenszerű billentyűleütések), OK. Töltsd be egy kedvenc joystick vezérelt programodat (az enyém a Final Cartride III). Mozgasd az egeret. A mutatónak követnie kell a mozgást...

Ha ez működött, kapcsold ki, változtasd meg a jumpert 1351 módba, és kapcsold be újra a számítógépet. Töltsd be próbának egyet az egyszerű példaprogramok közül az 1351 demodisk-ről (Ne felejtsd el leállítani a FC III. Mielőtt futtatod őket - egyedi IRQ kezelőket használ ha a program BASIC-ba tér vissza). Mozgasd az egeret mint előzőleg... Remélem működik jól.

Ha működésképtelennek látszik, először ellenőrizd a mikrokontrollert, valóban betöltődött-e a program (tedd vissza a programozóba, és próbáld meg kiolvasni a tartalmát). Ellenőrizd a kondenzátorok polaritását (...nos, ha valamelyik felrobbant ez rossz jel, de legalább megvan a hiba...). Nézd át újra. ... mondtam, hogy a Chipeket foglalatba rakd??? Mivel az áramkör egyszerű, nem tud igazán nagy hibát okozni, az illesztő feltehetően működni fog az első bekapcsoláskor.
 

Megjegyzés a PIC16F84 felhasználóknak

Ez a kontroller később készült mint a 16C84. Valószínűleg az utódjának szánták, mivel nagyban azonosak, néhány apró kivétellel. Micochip kijavított néhány tervezési hibát a 16C84-ben. Egy ezek közül a külső megszakítás lábat érinti (RB0/INT) a chipben. A 16C84-nél egyszerű TTL kompatibilis a bemenet, míg a 16F84-nek Schmitt-triggere van, amikor külső megszakításforrásnak használod.

Ez az illesztő használja a chip külső megszakítás lehetőségét. Sajnos a POTX jel elég volt a 16C84-hez hogy generáljon egy megszakításkérést, de ez túl kevés ehhez a Schmidt-trigger bemenethez :-(. Amit ebből látsz, hogy tudod használni a 16F84-et mint 16C84 helyettesítőt - de az illesztő nem fog működni natív 1351 módban minden esetben! Ez igaz a 16CR84 chipre is.

Szerencsére van egy trükk amivel rávehető az illesztő a működésre. Ehhez csak egy nem használt soros adó kell és egy vevő kapu a MAX 232 chipben, amivel regenerálni lehet a POTX jelét hogy megfeleljen az igényeknek.

Ellenőrizd a munkádat. Nézd meg a kapcsolási rajzot ha nem vagy benne biztos. Miután elkészültél, próbáld ki az illesztőt 1351-es módban. Működnie kell a mikrokontroller programjának módosítása nélkül.



 

A haladás iránya (javítási lehetőségek)



Mindennek ellenére elégedett vagyok a terv jelenlegi állásával, mindazonáltal sokféle képpen javítható.

Először is talán tudsz csinálni egy jobbat és elkészíted az emuláció mód kiválasztását, mint ahogy az egér teszi. Ekkor J1-et el lehet hagyni a panelról.

Másik gondolat, készítsük el a tervet más egér szabványokhoz is: főleg PS/2 és USB egérhez. Sok tény szól mellette. Először is a soros egér lassan el fog tűnni - a fenti okok miatt. Másod sorban TTL szinteken működnek, tehát nincs szükség speciális tápfeszültségforrásra - ezek az egerek közvetlenül a +5V-ról működnek, amit könnyen elő lehet állítani, egyszerűbbé téve a hardvert.

Más részről elkészíteni a támogatást hozzájuk nehéz. Nem ismerem az USB egeret, de a PS/2 egér elég gyakran közvetít adatot. A kommunikáció szinkron soros, egy clk, és egy adat vonallal. Az adat bitek az egér által szinkronizáltak - körülbelül 30-60 µsec mind :-(. Ez nagyon gyors ennek a hardvernek, az 1351-es emulációhoz. Itt az IRQ csatolva van a SID POT impulzus generátorához - és szoftveresen lekérdezéssel, az IRQ futása sosem késhet többet mint 15-20 µsec. Az az álláspontom, hogy ez egyszerűen lehetetlen elkészíteni. ...Talán egy modernebb mikrokontrollerrel? Lehetséges lenne az egész tervet átültetni egy Atmel AVR chipre (például egy AT90S2313) - de minden kódot újra kéne írni, beleértve a problémás részeket (1351 időzítések).

A Microchip már gyárt olyan kontollereket amelyekben hardveresen sok részegységet beépítettek (3-4 független időzítő, szinkron, és aszinkron soros port, mester/szolga üzemmód, IIC sín, A/D konverter, PWM modul, USB illesztő) pl.: PIC16F877 sok más előnnyel is rendelkezik mint a régebbiek, és kód kompatibilis velük. - a fordító megjegyzése

Lehetséges lenne Amiga egeret is támogatni. Ahogy én látom ezek kihaltak 8-) mint az eredeti 1351-es :-(. Persze lehetőség lenne az Amiga egér protokollt támogatni a Commodore oldalon (a joystick és az 1351 mód között) ;-).

Más részről lehetséges lenne más kiszolgáló platformok támogatása. Jelenleg hasonlóan az 1351-hez, az illesztő C64, és C128-on tud működni.

Nem működik Plus/4-el, még joystick módban sem ha csak csatlakoztatod egy egyszerű pont-pont C64 joystick interfész kábellel. Működik joystick módban (tesztelve...), ha van hasonló joystick illesztőd az állatkához mint az enyém - nézd meg az alap Plus/4 joystick illesztő dodokumentumot ha érdekel. Nos, ne felejtsük el: tudod használni az illesztőt Plus/4-en natív 1351 módban is, ha van egy SID kártyád a Synergy-től - a joystick portja tökéletes, és szintén tartalmaz POTX/Y vonalakat; nézd meg a SID kártyád dokumentációját a részletekért.

Teszteltem egy PAL VIC 20-ason is. Joystick módban jól működött (látnod kellett volna amikor Star Battle-t játszottam egérrel; kiütöttem néhány célt ;-) ). A jobb, és a középső gombok a VIC-I POT regisztereiből olvashatók ki. Nem működik 1351-es módban sajnos. Ha a számítógép azonos módon kezeli a tekerő bemeneteket (Így van?!), az órajele túl magas lehet a mostani emulációs kódhoz - és egy eredeti 1351-nek is.

Más rendszerek támogatásánál, egyszerű lehet a problémát megoldani amíg az illesztő intelligens. Bármilyen algoritmust készíthetsz a PIC-el. Ezzel az előnnyel támogathatsz más rendszereket (utolsó sorban joystick módban) csak a hardver illesztésre kell ügyelni (a szükséges paramétereket a célszámítógép port karakterisztikája határozza meg, tápfeszültséget meg valahonnan venni kell) és némi kód újrarendezés a PIC-ben.


 

Irodalom

Csak a gyűjtött dolgok vannak itt

Linkek

 

Fájlok


 

Galéria

Különböző képek a fejlesztésről...

Először az eredeti prototípus amit 1998 februárjában készítettem. Sajnos nincs róla fénykép. Kitalálod hol van a PIC16C84? ;-)
 

Interface board - revision A

 
 



 
 Ezek a képek a második prototípusról készültek VHS kamerával, és egy digitalizáló kártyával.

Revision B - picture 1

 
 

Revision B - picture 2

 
 

Revision B - picture 3

 
 
És itt a panelja ennek. A tápfeszültséget egy TL497A kapcsoló üzemű táp IC állítja elő feszültségtöbbszöröző üzemmódban.
 
 

Top side of Rev B

Bottom side - Rev B

 



 

C verzió, valamikor 1998. környékén. MAX232 táplálású (volt még 2 verzió ami MAX680, vagy TL497 táplálású volt)
 

Component layout - Rev C

 
 
 

Top side, Rev C

Bottom side, Rev C

 


 

A közvetlen elődje a tárgyalt áramkörnek D Verzió. Megjegyezném a csökkentett alkatrészszámot, és a kis panelt :-). Minden el lett távolítva róla, még az RS232 feszültségforrás is, mivel néhány egér képes működni TTL jelszintről is. Van egy hiba a panelon, az egér rossz polaritással veszi a tápfeszültséget :-O. Sajnos, nincsenek fényképeim.

 


Kapcsolat

Ha problémáid vannak, kérdéseid, megjegyzéseid - nyugodtan írhatsz nekem. Dobj egy mélt: mailto://Levente@Terrasoft.hu.

Az eredeti angol szöveget lefordította: Mészáros Árpád mail: capac@freemail.hu