A BASIC programban a sorok egymásutániságát nem a sorszámok határozzák meg a memóriában. Láncolt listaként tárolja őket a gép. Itt olyan, mintha a 30. sor beszúrásakor rossz helyre rakta volna be a láncolt listába, a 10. sor elé.
Az eredeti megosztás 3. fotóján 30 - 10 - 20 ... sorrendben listáz (a gép). A 4. képen két egymás utáni listázás között átírta a 90-es sorszámot 110-re. Ez nem bithiba.
Abból lehet kiindulni ha RAM hiba, általában (ez sem szentírás) egy memória IC rossz a 8db ból. Tehát mindig egy adott bit kezd el elromlani a memóriában random (vagy nagyon is periodikus) címeken.
Azt próbálhatod kideríteni, pl monitor-ban vizsgálva a RAM-ot, melyik bit az.
Nemtudom uC-t miben programozol, gondolom kb C-ben, /assembly-t ma már alig valahol használnak/, ennek ellenére így már azt mondom, sokkal esélyesebb, hogy sikeresen megoldd a javítást.
Ez a nyugdíjas-tévészerelőbácsi-style szkóppal mérünk ami eszünkbejut ez zsákutca, viszont ha egy gép már (vagy MÉG) megy, nem esélytelen némi szoftveres nyomozást folytatni.
Gépet mindig lehet kapni, a piac határozza meg mennyiért, szépen felugrottak az árak, de azért van:
Egy tizesért, ha biztosan működne, teljesen elfogadható ár lenne, báár..lehet fel sem megy addig, jelenlegi helyzetben senki nem ilyenekre szánja a pénzt, hosszú távon viszont engem is meglepett mennyire "értékálló" cuccok ezek.
Most kérdezheted, honnan a francból tanuld meg, hogyan kell 6502-t programozni, vagy a +4-ben mi hogy működik, egyáltalán mik monitorban a parancsok,stb.
Nos..itt van pár régi könyv, sajnos a legtöbb nem plus4-ről, de általában azért hasznosak:
> beteszel egy halom rosszul kompenzált, kissávszélességű, túllövéses, franc tudja milyen és mitől ennyire képtelenül zajos szkópábrát,
És mitől ilyen? Ugyanúgy néztem, ahogy a saját szoftvereimet szoktam. Föld az IC föld lábára, mérés az összes többi lábon. Az tény, hogy ott szoftveres hibakeresés folyik, tehát ha rossz értéket írtam a regiszterbe, és ezért nem jó a PWM frekvencia, akkor azt a szkóppal észreveszem. Ilyen hülye jelalakot a négyszögjel helyett még nem láttam. Ha te tudod, hogy hogyan kell egy ilyen rendszerben mérni, vagy akár csak egy linket egy leírásnak, akkor annak több hasznát venném... Kösz. ;-)
> (úgysincs jelentőségük, ha szuperek lennének sem...) hogy segítsen valaki ,mitől áll meg a gép
Akkor meg nem mindegy? :-)
A kérdés az volt, van-e tippje valakinek, hogy milyen irányba érdemes indulni.
> Alkatrészeket kell cserélgetni egy ismerten működő hibátlan gépből és kiderül.
Igen, ehhez találni kell egy működő példányt.
> A komplett gép, ha jól működik is, szinte mindig olcsóbb
Ha éppen lehet kapni.
De ebben benne van az is, hogy érdekel a hardveres hibakeresés. A munkámhoz használt mikrokontrollereken belül van mindez (cím és adatbusz, stb).
> 8db ramot kiszedni nem móka és kacagás, könnyű az alaplapot is tönkretenni
Ezzel tisztában vagyok. De ha érdekel, akkor megcsinálom.
Összefoglalva: Jó lenne egy működő plus4, de tudok nélküle élni. Ami igazán jó lenne: Tudni, hogy miért nem működik ez a példány. :-)
"napi munkám mikrokontroller programozás, alapszinten bánok az oszcilloszkóppal és a logikai analizátorral"
Akkor nem is értem az alábbiakat, beteszel egy halom rosszul kompenzált, kissávszélességű, túllövéses, franc tudja milyen és mitől ennyire képtelenül zajos szkópábrát, (úgysincs jelentőségük, ha szuperek lennének sem...) hogy segítsen valaki ,mitől áll meg a gép.. :) tényleg nem sértegetni akarlak, csak kicsit mintha egy rosszlány keresné az igaz szerelmet, érted....
"Szerencsére nagyon jól reprodukálható a hiba. 10 sornál hosszabb BASIC program szinte biztos"
A gépben olyan ezer "véletlenszerű" sorrendiségű és lefolyású dolog történik, miközben a "10soros basic" program fut. Vagy begépeled, aközben, vagy akármi.
Egyáltalán nem induló gépnél lehet gubizni szkóppal, mert pl. kommersz hibaok, hogy valami lefogja a buszt, nincs órajel, rossz a táp, beragad a reset...stb, stb hamar lebuknak.
De egy élő, működő gépben szkóppal egy ilyen degradációs hibát megkeresni nem lehet. Igazából logikai analizátorral sem igen.., értelme nincs szenvedni vele.
Alkatrészeket kell cserélgetni egy ismerten működő hibátlan gépből és kiderül.
"tapasztalattal, és cserealkatrészekkel hamarabb is meg lehet"
Valamiért van egy plusz4-ed amit javítani szeretnél. Veszel egy másikat, ami ismerten jó, --->lesz kettő. A komplett gép, ha jól működik is, szinte mindig olcsóbb, mint a (kitudja milyen) alkatrészek.
Másik út, mivel a ramhibára nagy az esély, felkutatsz RAM-ot, azt azért még lehet találni. Viszont ahhoz keményen kell tudni forrasztani is, a 8db ramot kiszedni nem móka és kacagás, könnyű az alaplapot is tönkretenni...
> nagyon furcsák ezek a szkópábrák egy működő gépre
A napi munkám mikrokontroller programozás, alapszinten bánok az oszcilloszkóppal és a logikai analizátorral. Úgyhogy nem kizárt a mérési hiba. Csak nem tudom, hogy hol követtem el.
> egy komolyabb ( min. 50-100MHz) tárolós szkóppal
Hantek DSO5202P (200 MHz), a munkám során használom, és jól működik.
> Egy néha megálló "megőrülő" gépben
Szerencsére nagyon jól reprodukálható a hiba. 10 sornál hosszabb BASIC program szinte biztos, hogy elszáll. Listázásra olyan, mintha az egyes részeit véletlenszerűen lecserélték volna.
> Még logikai analizátorral is több hónapos munka és nyomozás lenne
Szerencsére van logikai analizátorom. De ahogy fentebb írtam, mikrokontrollerekkel foglalkozom, ott főleg PWM, I2C és SPI jeleket vizsgálok. Számítógép komplex adat/cím/kontroll busz időzítés hibakeresésben nincsen gyakorlatom. De szívesen nézem online, ahogy mások régi gépeket javítanak. :-)
A több hónapot viszont kizárnám. Tapasztalattal, és cserealkatrészekkel hamarabb is meg lehet találni. Tapasztalatom részben van, részben kérdezek a fórumon. A cserealkatrészek kérdése nehezebb, de megpróbálok szerezni.
> Első gyanus a ramhiba, de szokott ezekben a gépekben is rossz lenni a PLA, a furcsa TED és processzorhiba sem kizárt.
Egy néha megálló "megőrülő" gépben soha ebben az életben nem fogod meg a hibát egy szál oszcilloszkóppal.
Még logikai analizátorral is több hónapos munka és nyomozás lenne, mivel kezdődik a baj, és azután mikor már minden összeomlik, mi okoz mit.
Első gyanus a ramhiba, de szokott ezekben a gépekben is rossz lenni a PLA, a furcsa TED és processzorhiba sem kizárt.
4V bőven elég logikai 1-nek.., de egyáltalán nem biztos, hogy valami szkóppal rálépve egy vonalra a "valóságos jelalakot" látod.
(nagyon furcsák ezek a szkópábrák egy működő gépre, egy komolyabb ( min. 50-100MHz) tárolós szkóppal ez nem így néz ki, és mivel alapvetően megy a gép, ezért ez a sok homokvár meg fűrész meg tüske stb, 99% mérési és nem működési hiba szinte mind..)
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...
