Van egy beteg plus/4, segítséget kérek a gyógyításhoz.
Tápja nincs meg, a teszteket labortáppal végzem. 5 Volton 0.9 Ampert vesz fel. Elektrolit kondenzátorokat cseréltem.
Rendben bekapcsol, képe szép.
Rövidebb BASIC programokat be lehet gépelni, le is futnak, ám véletlenszerűen megváltoznak. Tehát a print hello world goto 10 egy darabig írja a szöveget majd megáll hibaüzenettel.
Ennél hosszabb BASIC program esetén már beíráskor megfagy.
A paraméterezési hibák/hiányosságok a VICE unixos és widowsos hardverkezelőjében vannak.
„Ja és Microsoft soros egérnek nincs "5eres kábele"...!!”
Azt elhiszem, de nem olyan családbú származom, hogy lett volna olyanom. Amit tizenévig használtam, az egy 3-gombos márkátlan, amelyet át lehet kapcsolni MS-kompatibilis üzemmódra a golyó melletti kapcsolóval. Ebben a DTR is be volt kötve.
Igen, az egy bájt a drivernek szól: M a Microsoft-mód.
Nekem glew kellett a VICE 3.4 képkezeléséhez (a fordításhoz is), és nincs gondom a megjelenítéssel.
Akkor csak a "natív" "device alapú" RS232 kezelésnél vannak ezek a státusz, irq, szóméret, stb hibák?
Mert nekem ez, egy PLxxxx gagyi USB-soros átalakítóval +TCP seriallal "belökve" az adatot simán működik.
Ja és Microsoft soros egérnek nincs "5eres kábele"...!!
RTS,GND,TXD,RXD
De a TXD-n nem is lehet kifelé beszélni hozzá (legalábbis ehhez a példányhoz) onnan az IC-nek "lopja" az 5Vot.
Az RTS-ről meg a ledeket járatja, illetve ha állaptot vált, reseteli a
kontrollerét, és visszaküld egy byte-ot, (gyanítom a wingyózok pl így ismerik fel, ha nem mozdítom meg, akkor is)
+ok nélkül "szóltam be", soros egérhez és 2MHz-es retro kisgéphez képest tényleg elfogadható sebességű ez a cucc (a vice villog, mert egy kalap szamóca, régebben normálisabb directX-es win drivere volt, most meg tragikus az egész, de ahhoz elég lesz, hogy a kódot piszterkáljuk)
Ha érdekel még valakit ez az ACIA-emuláció, akkor be lehet jelenteni a VICE projektben, hogy van igény a szóméret (control register b5-6) figyelembe vételére. Vagy lehet implementálni, akár egyéb kedvenc emulátorban is. :)
Nem volt könnyű összerakni Linuxon a VICE 3.4-et. A build sem megy egyszerűen (pl. CFLAGS), pedig már trunkra vetemedtem. Nem tudom, mit értesz „linux like a GUI”-n, de szerencsére nem modern GNOME-os. :) Néhány dolog eltűnt a menükből (speed, pause), de cserébe általam soha nem látott módon működik a billentyűzet. A korábban idézett ACIA patch-ek benne vannak már, de továbbra is rossz a tcsetattr. Pl.:
buf.c_cflag |= CS8
Ennek C7-nek kell lennie, hogy működjön az egér, de leginkább a ACIA control registeréből kellene kiolvasnia a felprogramozott értéket.
Egy működő egeret is kellett szereznem, mert ami kéznél volt, annak mindkét végén töredezett a kábele, így nem volt ideális a teszteléshez. :) Hol lehet olcsón jó minőségű 5 eres kábelt venni? Már van 2-3 erre váró egerem.
A tcpsert nem ismerem, és most abba inkább nem merülnék el, mert az én tesztelésemhez már off-topic. :)
A CS7-re patchelt xplus4-gyel, és a DSR/DCD figyelembe nem vételével (ezúttal nem b8, hanem d8 vált be 98 helyett, de ki lehet éselni ezeket az 5-6. biteket a driverben, ha valaki úgyis újraírja:)) nálam működik az egér minden irányban, és mindkét gomb. Persze össze lehet hozni vele egy kis laget, de ez inkább a draw lassúságától lehet: 1200 baudnak kezelhetőnek kellene lennie.
Nézd az adatokat 5001-5003 között, ha fennakadás van: ott kellene lennie a 3 beolvasott bájtnak.
A vánszorgás adódhat abból is, hogy a felső bitek elvesznek, nem? Valami halvány emlékem van, hogy valamelyik partin láttam én ezt élőben és egészen vállalható volt, úgy mozgott az egér, ahogy azt elvárná az ember.
Nativ linuxon azért talán nem akkora szívás, mint mindent összerakni, letölteni, előkészíteni, konfolni, majd kecskét áldozni keresztútnál éjfélkor, hogy msys alatt működő win-es bináris forduljon...
Btw a dolog így (3.4 alatt) SEM tökéletes, sőt.
Most szöget ütött a fejembe ez a DCD dolog, vajon TCPser az hogyan viszi át ezeket a státus vonalakat? Hiszen ez (ahogy eddig én hittem) egy natív TCP stream, ha ad egy byte-ot az vett soros adatként értelmezendő, mivel fogja jelezni, hé, most épp a státuszvonalakról beszélgetünk...hmm..
Azthittem az emulátor kényelme egyszerűsíti ezt a primitív fejlesztést (ami pl. anno Boticelli hardverkulcsnál csak részben volt opció), de most már kezdem azt látni, annyi plusz problémát visz be, ami az egész eredményt kétségessé teszi
Ettől függetlenül jelenleg úgy érzem, bszggg kartács által kitaposott út inkább csak egy halvány játhatatlan ösvény, egy nyomnál nem több
Nem tudom a pluszi teljesítménye elég-e ide, vagy mire elég...(nagyon megszoktuk a végtelen teljesítményű hardverkurzoros egereket), egy final3 egér nyila azért még egy Win3.0 XT vagy amiga500 képességeit sem éri el, nyilván...
...de ez a villogó bizonytalan, szószerint vánszorgó valami ez nem rajzra vagy játékra esetleg desktopra alkalmas egérkezelés, ez még tech demonak is csak "éppen hogy.."
* Changes in Vice 3.4 - added support for the IP232 protocol that was used by the long lost VICE1.19 hack, and which is supported by tcpser for emulating DTR/DCD (carrier detect) - various userport rs232 fixes - ACIA IRQ fix Ja, hát úgy könnyű. :P Na, megnézem, hogy le tudom-e fordítani...
Én tegnap addig jutottam ,hogy letöltöttem a legutolsó VICE-t, amiből találtam Win binárist....(3.4-x64).. (mert a 3.1-x64 ben semmit nem csinált a kód, csak a sarokban vibrált a pont)
A 3.4-x64 az agyamat kikezdte, mennyire -és miért?!?!- linux like a GUI, illetve miért nem úgy működik a drive emuláció, ahogy megszoktam, stb.
Miután evvel mind megküzdöttem, nagy nehezen sikerült annyit elérnem, hogy az egér már fel-le mozog, jobbra balra nem.
Nemtudom ez a bszgg féle kód 3byte-os csomagot eszik-e,..... éppenséggel lehet az az adatvesztéses móka van, amit írsz,...
....bár fura, miért mindig az X adat vész el,..
..illetve ha nagyon megrántom az egeret, a felső biteknek is ugrani kellene, (ami byte pedig tuti "átmegy", mert gombok azok vannak).
Mondjuk hozzátartozik a történethez, hogy 0 kedvem volt fizikai egérrel szívni, egyszerűen fogtam a tcp-sorosegér-emulátort, amit dosboxhoz írt egy srác, socat-al összekötöttem a két portot és tadam.
Eleinte ráfogtam az emulátorra, biztos rossz, de ma melóban gyorsban írtam egy PS script terminált, ami gyönyürűen eszi és elemzi a TCP 3byte-okat, és 100% működést mutat, vagyis nem az emu a rossz, fura is lenne, mert dosbox-osok lelkendeznek, hogy mennyire tuti, innentől a vice sorosport nem eszi a byte-okat normálisan.
Abból sem értek (még) semmit, ami byte-ot írtál ,hogy a kódban módosítani kell, ha azt én átírom, semmi működés nincs, visszajutok oda, hogy áll az egész, és meg sem moccan.
Sajnos pluszin még gyorsban "ellenőrizni" sem tudom a soros portot, assemblyben nincs lelkierőm, megszakítás, összes bit felkódolás, stb megírni (kb ennyi erővel ~nulláról az egér drivert írhatom újra)
Basicben meg egy hangot nem találtam, hogyan nyitható meg (legalább olvasásra) az RS232...próbáltam hátha C64-el kompatibilis, végülis commodore basic.. nem akart működni.
Végül mindenféle rég elfeledett terminálokat keresgéltem, de tragikusak, mind egész sornyi szöveget akar venni, enter-ig, modemet kezelni meg ilyenek.
É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.
