Én nem említettem senki (ál)nevét mostanában, nem is mondanak nekem semmit. A híresebbek közül is csak Kosir Loncsi Godzilla Mad Attilát ismertem. De nehogy összekeverjétek a másik Maddel! ;)
Annyit tennék hozzá a dologhoz, hogy BSZ (aki a SID kártyát csinálta) és a soros egérrel küzdő srác, aki itt bszqqq néven volt nem ugyanaz, szóval ne keverjétek, lécci.
Az 1351 egy kényszermegoldás, a C64-en eredetileg 2db potméteres paddle-nak szánták (azok a vicces tekergetős cuccok a 70es évek elejéről az un "tévéjátékokról") a SID két analóg portját, aztán úgy alakult, hogy erre fejlesztett a MOS egy optikai- kapu-->végtelenített-potméter emulátor egzotikus cél-chip-szörnyszülöttet, megoldva az amúgy is ritkán használt analóg portokkal az alacsony gépigényű analóg elmozdulás érzékelést.
De akkoriban a professzionális világban sem volt az egér gyakori, kb mi is akkor fogtuk meg, ha a már nem emléxem miféle C64 rajzprogrammal, vagy a final3-mal variáltunk.
A pluszira, ahol kb semmiféle kváziszabványos egér-szoftver nincs, még annyi sem, mint C64-re, teljes agyrém a SID+1351 kombó, kétségtelen ,hogy működik, de total overkill.
Néhány soros protokollt tudó egérhez semmi nem kell egyébként, mivel eleve 5V-osak, hiszen PS2 egerek..(csak az átalakítót rádugva "beszélik" valamelyik(!) soros protokollt is)
ÉS akkor itt jön az első amivel szerintem szívtok, a soros egér is ahány ház, annyi szokás, a PS2 egerek pl a legtitokzatosabb módokon próbálják "eldönteni", soros portra dugták-e valami konverterrel őket, tehát melyik protokollal is kell beszélgetni..
De, ha echte original soros egeret találtok és dugtok be, az sem mind kezdi ám azonnal mondani mit mozog!
Néhány kifejezetten elvárja ,hogy kapjon valami soros parancsot, a gép (egér driver) "piszkálja" a DSR-CTS stb vonalakat, (ahonnan a tápot ezek az egerek "lopják"), és még ha ez meg is van mind, legalább 3féle sorosegér protokol létezik, és ezek nyelvjárásai!
Előbb teljesen meg kell(ene) érteni ezt a bsz féle kódot, és utána lehet abból találgatni, neki milyen egere is volt, majd olyat kell találni, ami szintén nem kis mutatvány, lévén egy egérre sincs ráírva, melyik nyelveket és milyen tájszólásban beszéli.
Már egy win85 egérdrivere is majd 100 kilobyte, és rengeteg figurát tud, a logitech spéci dialektusától a microsoft original és módosított nyelvjárásaiig.
(és még így is volt olyan, hogy PC-n ha nem az elején, bootoláskor dugtad be az egeret, bizony az nem "indult el", állt szépen az egérnyíl ahol volt..)
Egyébként válaszolva kérdésre: egy 1351 + SID kártya együtt kb 45 ezer forintra jön ki, ha Valaki nulláról kezdi (ebből 60€+ PP (kb 22 ezer) a SID kártya))
Könnyen összejöhet egy 60 ezres számla is, ha Valaki impulzus vásárló, meg nem talál Európában eladót. (az az alap, hogy floppy egység kellett a C64-hez, hogy legyen rá egeret támogató SW, és ez inkább az USA-ra volt jellemző)
Szerintem ez az alsó hangon is 40 ezer Ft azért elég húzós.
Ezt kell szembeállítani az alábbi költségekkel
-2000-2500 Ft-os User port csatlakozó
-Max232 áramkör TTL-RS232 (800-1500Ft)
-Dupont kábelek (ha annyira nem szeret forrasztani, mint én) 500Ft
-RS232 anya/anya fordító csatlakozó - (1000Ft) Max232 és az egér is apa csatlakozós
-forrasztóón + idő
Eddig kb 6000Ft, erre jön még az RS232 csatlakozós egér (vagy egy PS/2 egér + PS/2--> RS232 konverter, ha így is működik, nem tudom, szerintem nem garantált).
Jó esetben a padláson van egy félrerakott darab, vagy van egy lúzer haverod, aki nem tudja mennyi ér és megveszed Tőle 1000Ftért. :-)
Az eBay-en valóban szálltak egy kissé az árak, de mi MO-on élünk :-)
Nem irreális cél keresni és leütni egyet pár ezer forintért, találni egy PC bontóban vagy gyűjteményben:
Létezik egyes komplemens, csak ritkán használják, mert bonyolult a nullák (!) lekezelése.
(mondjuk számomra a kettes komplemens is túl bonyolult, maradjunk a BCD-nél :-) )
Nekem az egyik ugrás annak idején úgy tűnt, hogy pont ezt ellenőrzi. De lehet,hogy csak sok sört ittam, és duplának láttam a nullát :-D
Egyes komplemens képzés
Mivel ez azt jelenti, hogy formailag, mint bitminta sem egyezhetnek meg egymással (mert nem lehet olyan pár, ahol a pozitív és a negatív elem bitmintája azonos) és mivel egy helyi értéken két alaki érték lehet, 0 vagy 1, ezért a két diszkrét halmaz szétválasztására az alaki elemek formális felcserélésével is juthatunk. Ez világosabban fogalmazva azt jelenti, hogy ahol egy pozitív szám esetén egyest írunk, ott ugyanannak az elemnek a negatív párja esetén nullának kell állnia. Ez pedig nem más, mint a korábban a digitális alapoknál már jól ismert bitenkénti invertálás vagy negálás. Tehát most már rutinosan egy pozitívan ábrázolt számból a negatívba bitenkénti invertálással jutunk és fordítva. Ez a művelet az egyes komplementer képzés.
és ez az egyes komplemens ábrázolásnak az egyik legnagyobb hátránya. (Vagyis két nulla van, és ezért írtuk korábban, hogy majdnem igaz az, hogy a negatív számok és a pozitív számok számossága a két nullával azonos, de a valóságban nincs két nulla, hanem a nulla nem tartozik egyik tartományhoz sem.) A hátrányt a számítási eredményeket végző digitális számító művek felesleges bonyolultsága jelenti, mert fel kellene készülni a pozitív és negatív nulla keletkezésére és a vele való műveletekre is.
Papíron fejtettem vissza (nekem úgy kényelmesebb, mert jobban átlátom,nyilak, miegymás :-) ) de visszanézve a 610C egy PLA-s rövid rutinra mutat, ami visszaugrik $60D6-ra.
Ez a kódrészlet nekem teljesen hiányzik a papírról és helyette a BRK van és onnan is folytatódik :-O
A valós hardverre mikor bepötyögtem a papírról (még nem volt SDs cuccom, illetve x1541-em), akkor meg szintén BRK-val állt le, szerintem pont a hiányzó kódrészlet miatt. Oooops.
Most a YAPE-n visszalép egy Syntax error keretében, de ez normális. Tényleg össze kel raknom a konfigot egy újabb tesztre, már van SD kártyás cuccom is.
Pl. a kód elején levő JMP $610C konkrétan egy BRK-ra mutat
Ez nem igaz. A 6114-en volt BRK, ha jól emlékszem, de talán oda nem ugrott a kód 610f-ről, amikor tesztelték.
Szerintem akkor kezdjél a kódon rövidíteni, ha a meglévő már működik.
Én nagy nehezen GNU/Linuxon patch-elt xplus4-gyel látom, hogy a hibák ellenére elvileg működhet, bár a soros egerem is hibás, meg szerintem az emu is (tcsetattr is hibádzik). A 603b-t át kellett írnom b8-ra, hogy bármi is működjön az emuban.
Az a jó hosszú komment, amit tegnap írtam, az sajnos elszállt, mostanában (a legutolsó Win10 frissítés óta) rendszeresen lefagy a felhasználói felületem, egyáltalán nem reagál a kattintásokra.
Most nincs már energiám újra begépelni. (Egyébként pont ismét lefagyott, b*sszus, szinte csak a billentyűzetre reagál, meg itt-ott az egérre). Ezek a gombok az "elküldöm" gombok még épp működnek...
Tömören: -az ACIA/UART/6551 felprogramozása a kód legelején kifejezetten olyasmi, amit elég ritkán látni, keveset van használva.
-a későbbi bitpakolászás teszi ki a kód legnagyobb részét.
-Az egér alapvetően elmozdulást küld, ami lehet negatív vagy pozitív, és ha jól értelmeztem, a kód egyes komplementer móddal dolgozik a negatív számok kezelésénél, és őszintén szólva egy idő után elveszettem a fonalat.
1) nem akartam az általam szétbarmolt kódot berakni, ami szintén nem működik, de még azt sem hihetem, hogy működött volna, mert bszggg-nek van legalább egy screenshot-ja, hogy ez az eredeti (valamelyik változatában) működhetett :-)
Pl. a kód elején levő JMP $610C konkrétan egy BRK-ra mutat, de NOP-ra cserélve sem lett jobb :-)
2) A kommentezést és a kód értelmezését csak papíron csináltam meg, de a kommentek nem lettek begépelve. Színes nyilakkal jelöltem magamnak az ugrásokat, zölddel a feleslegesnek gondolt parancsokat, stb.
Nekem az egyik főbb célom a kód lerövidítése volt, hogy beférjen a nulláslap itt-ott találhat réseibe (tape buffer 191 bájt, speech buffer 141 bájt, ha már ugrálni kell, tök mindegy, hová)
A NOP-okból van 17, de monitorban fejlesztés során elég sok ilyet szét kell szórni.
A kód értelmezésekor merült fel, hogy nem lenne-e jobb egy bájton tárolni a X koordinátát, sokkal kevesebb bit-toszogatás kell, kb 40-45 bájttal lehetne rövidebb a kód.
Kösz, ránéztem. De korábban azt írta, hogy visszafejtette, kommentezte, javította, és ezt nem látom.
A kód valóban tökéletlennek tűnik, de nekem nem fagy tőle az emulátor. Megszakításkezelőben ne legyen BRK, úgyhogy kezdetnek 6114-re betennék egy NOP-ot.
bszggg kódja - minden tiszteletem mellett, mert a géphez (meg sok minden máshoz is) nálam sokkal jobban ért- egy klasszikus spagetti kód, oda-vissza ugrásokkal, a programkód BRK-kal itt-ott megszakítva.
Ha meg tudod javítani, és működik a rezidens kód, ami az RS232 egér mozgását a User portról X és Y koordinátákra fordítja (még ha nem is fér bele nulláslapba) Tiéd a karton sör, sőt még küldök ingyen egy RS232 egeret is. Az értékét már nagyjából sejtheted.
Szerettem volna csinálni egy Mindenki által könnyen és olcsón elérhető egeret Plus/4-hez. Ha visszanézed, már 2010 előtt foglalkoztam a témával a Plus4wolrld-ön
-Túl drága és ritka az 1351 egér (SID kártya is kell hozzá)--> soha nem fog elterjedni
Jött az ötlet az RS232 egérről, miután végigolvastam Levente microcontrolleres PS/2 illesztőjének a doksiját. Látható volt, hogy ezt izomból, aktív programozott külső elem nélkül a Plus/4 nem tudja megoldani. A mikrokontroller programozás túl bonyolult nekem, polcról leemelhető megoldást kerestem.
-Amikor elkezdtem foglalkozni a User portra dugható RS232-áramkörrel (ezeket C64-en nézetm meg), akkor jöttem rá, mennyire hasonló a két User port kiosztása/működése. Ebből lett az SVS Ultimate Map-ben a C64-Plus/4 User Port összehasonlító táblázat.
-bszggg oldalán találtam rá az általa fejlesztett cuccra. Nagyon jó cucc, és elviekben működhet is (legalábbis azok alapján amit addig olvastam). Sajnos sem működő prototípusa, (mint kiderült) sem működő a rezidens drivere, sem dokumentációja nincs
-Emiatt döntöttem a Max232 áramkörök beszerzése mellett, plus user port csatik, kábelek, ház mellett. Ebből csináltam egy prototípust. Sajnos itt elakadtam, mert nem ment a rezidens driver
-Úgy döntöttem, legalább a hardver dokumentációját rendbe rakom. Ebből született az RS232 Mouse dokumentáció. Ez alapján bárki legyárthatja olcsón az illesztőt, sőt lehet, hogy többeknek van még régről ki nem dobott RS232 egere.
Kb itt tartok most.
Szerintem sem az indokaim, sem a felmerült problémák nem olyanok, ami miatt oltani kellene engem. Kifejezetten a scene számára szerettem valami könnyen és olcsón összedobható valamit csinálni.
Az, hogy nem vagyok jó programozó, soha, sehol nem tagadtam.
Az, hogy a User portról olvasson, nem kell hogy lefagyást produkáljon, ha nincs rádugva semmi. Szerintem a $30. körül valamit csinálnia kellene, ami hiányzik a kódból és BRK-ra fut. Ha ki NOP-olom, akkor meg teljesen befagy a gép, nem lép vissza RTS-el.
Egyébként a korábbi felvetéseddel kapcsolatban: természetesen a kereten kell ezt is elvégezni, hogy ne akadjon össze pl az osztott képernyővel.
bszggg kódja (legalábbis az a residens driver ami neki most megvan) nem működik.
Elkezdtem visszafejteni, kommentelni, kijavítani, lerövidíteni, hogy beleférjen a nulláslapba, de nem vagyok nagy kóder.
A residens nem akar működni, na. BRK-val mindig lefagy, valahol rossz helyre fut.
(Egyébként azon gondolkodtam, hogy vízszintesen az 0-159 pozíció is elegendő lenne az egérpozíció tárolására, multicolorban tökéletes, és hiresben sem kellene két bájt a pozíció tárolásához, csak fel kellene 2-vel szorozni a X-en tárolt értéket. Rajzoláshoz kellhetne az a precizitás hiresben, de ahhoz rajzolóprogram is kellene :-) ).
A PS/2 egerek több funkciót tudnak (pl görgő gomb lenyomottsága), és amennyire emlékszem, sokkal nagyobb adatsebességet használnak (már csak azért is, mert programozható a pontosságuk). Van RS232 serial mouse protokoljuk, de ehhez vissza kell őket kapcsolni ha jól emlékszem. Az adatcsomag első bájtja ne is egyezik meg az RS232-ével.
Nyilván nem lehetsz hibás az RS-232-es egerek árának emelkedéséért, de az érveid rosszul felsorakoztatásában igen. Viszont. bszggg-nek látszólag van működő megoldása az egér kezelésére. Legalábbis az oldalán olvasható leírás alapján. Azzal mi a baj? Működik, ha nem is elégít ki minden luxus igényt. Mondjuk forrásban, dokumentálva jobb lenne. Dehát a bináris forrás, a forrás meg dokumentáció, ahogy a nagyok mondják. :)
Ja, és tegnap kíváncsiságból keringtem egyet az eBay-n. Egy eladónál találtam PS/2 egeret és PS/2->RS-232 átalakítót szumma 10 Euróért. Csak gondolom a szállítás legalább még egyszer annyi lenne. Bár a mai világban hétezer plusz-mínusz pár száz Forint nem feltétlenül kezelhetetlen összeg, inkább az aránytalanság a bosszantó. :(
Elvileg a 2-es eszköz az RS232 lenne, de nem tudom, hogy mennyire van implementálva meg egyáltalán használta-e valaki, valaha. És egyébként mintha a KERNAL IRq handler is foglalkozna az ACIA megszakításokkal. De ezek csak halvány emlékek, régen piszkáltam már a KERNAL rutinokat.
1351 + SID kártya együtt mennyibe is kerül?... No. Akkor végül is mégsem az a probléma, hogy mennyit kóstál a Commodore egér, mert előtte még van másik bökkenő? Akkor mégis csak felesleges volt a drágaságát emlegetni? És ha már itt vagyunk akkor említsük meg a gyakori beszerezhetőségét! Ezen felül mi is van akkor az RS-232-es egerekkel? Csak nem azok is ritkák és drágák? Erre te itt viccelődsz az elterjedtséggel. Bármi a mi gépeinken nem bír elterjedt lenni az elterjedtség hétköznapi értelmében. Ott kerekítési hibának számít, vagy még annak sem. Szerintem.
Egyébként egyáltalán: melyik része az OFF? A témaidegen rész természetesen a 64-es működésének vesézgetése volt. A 2. pont meg a közvetlen előzményei. Tudom, én kezdtem. Bocs!
Egyébként hogyan van elképzelve az a soros egér bővítő? Mintha rémlene valami, hogy az ACIA-hoz kell külső szintillesztő és azon keresztül valami natív meghajtóval olvasnánk az egér pozícióját. Valami ilyesmi? Mert akkor kb. semmilyen megszakítás vezérelt programmal nem lehet majd párhuzamosan használni az eseményidőzítések véletlenszerű összekeveredése nélkül. Hacsak nem megszakítás nélkül, intenzív regiszter olvasgatással próbálnád az adatokat venni, de az meg a programozást bonyolítja el és/vagy időnként egyszerűen le fogsz maradni adatokról.
1200 bps, 7N1 keret (1 start+7 adat+nulla paritás+1 stop = összesen 9 bit), 3 keret per adatcsomag. Ez az adatátviteli formátum, igaz? Ebből az jön ki, hogy egy keret ~133,33-szor jön másodpercenként. A teljes adatcsomag gyakorisága meg ennek a harmada, kb. ~44,44 másodpercenként. Hacsak rosszul nem olvastam ki az adatokat az internetből. Ez semmilyen formában nem fog passzolni a ~50 vagy ~60 Hz-es megszakításhoz, szóval egyszerű KERNAL megszakításrendszer bővítéssel ez nemigen megoldható, mert azzal lemaradsz egy rakás adatról. Csinálhatod bonyolultabb módon, az ACIA megszakításkéréseinek elkülönítésével és feldolgozásával, de azzal valószínűleg nem lehet jól szinkronizálni a BASIC osztott képes grafikus módjait (grA 2 vagy 4), már amennyire fáj ez valakinek. ... Oppá! Most hirtelen a nehézségek sorolása közben felmerült bennem, hogy a KERNAL-nak nincs valamilyen soros adatátvitel támogatása? Ezt eddig sosem néztem. Egy kicsit elbizonytalanodtam...
1350 módban lehet 264-es gépeken használni az egeret. Csak speciális joystick adapter kell hozzá, mert a "hagyományos" a mini din select lábát köti össze a d-sub gnd lábával, azaz nem folyamatos a föld jel, hanem csak akkor föld, amikor éppen az adott joyportot olvasod. Ezt meg a túloldali olyan digitális áramkörök, amiknek szükségük van a stabil tápellátásra (pl. autofire, de ilyen az egér is) nem szokták tolerálni és válaszul olyan impulzusokat tudnak generálni, ami kinyírja a TED-et.
De ha valaki egy olyan joyportot épít, ami stabilan adja a tápokat és a bemenő jeleket (4 irány plusz tűz) a select lábbal kapuzza, akkor az működhet. Triviáisan OR kapu lenne, de abból 4 portosak vannak, ezért TLC pl. egy műveleti erősítőt használt rá, az 6 vagy 8 portos. (nem emlékszem)