| Szerző |
Üzenet |
Chain-Q
Divatamigás
|
# Elküldve: 2020. Már. 31. 10:34
Asm-Pro? :) Szerintem kb. az Enforcer tudja még megmondani ha valamit rossz helyre írsz és szétcsapsz a memóriában, de eléggé pilótavizsgás a használata.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 31. 15:23
Úgy nézem az Asm-One is tartalmazza a debuggert (eddig miért nem vettem észre...) na majd megpróbálkozom vele, talán segít megtalálni a probléma okát. Elkezdtem már behatárolni a hiba helyét, arra gyanakszom, hogy időnként valami lekérdezi a soros portot (regiszter szinten vagy OS barát módon) emiatt elveszik egy karakter és végtelen várakozó ciklusban ragad a program.
|
YADA
Tag
|
# Elküldve: 2020. Már. 31. 17:46
winuae nem tud memoria figyelest? valami remlik hogy van benne support developerek szamara (csak meg ne kerdezzetek hogyan lehet mukodesre birni)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 02. 09:27 - Szerkesztve: yellowdog
De igen, valóban tud :-) Viszont nekem realtime capture-re volna illetve volt szükségem, így beraktam a programba egy ezt megvalósító kódot és sajnos beigazolódott a sejtésem, a fagyás minden esetben attól következik be, hogy kimarad, pontosabba elveszik egy bájt és onnan ugye felborul a logika, elcsúszik minden, majd végtelen ciklusú várakozás a vége. :-(
Megpróbáltam a WinUAE serial beállításoknál minden variációt, de az eredmény ugyanaz. Az jutott eszembe, lehet kipróbálom FS-UAE alatt (még soha nem használtam) illetve az sem kizárt, hogy valami esetleg az OS felől "ellophatja" a hiányzó bájtot, ez esetben lehet valamilyen módon le kellene foglalnom OS szinten a portot, van erre valamilyen lehetőség?
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Ápr. 02. 09:40
Először is, egy kommunikációs kódnak/protokollnak olyannak kéne lenni, ami mindíg tud recovery-t, vagy legrosszabb esetben szétdobja a kapcsolatot ha olyasmit kap amit nem vár (vagy nem kapja meg amit vár), de nem esik végtelen ciklusba. Szóval inkább örülj, hogy van egy fasza teszteseted, amivel letesztelheted h. mennyire robosztus amit írtál - jelenleg semennyire.
Aztán majd ha kijavítottad h. ne kerüljön semmitől végtelen ciklusba, utána beszélgethetünk arról, hogy mi okozza a kommunikációs problémát.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 02. 10:05
Sajnos a PC oldali TotalCommander plugin adott és vele a sz.r protokollja is, azzal tudok főzni ami van... :-(
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Ápr. 02. 10:07 - Szerkesztve: charlie
Amiga oldalon gondolom hardware banging a portkezelésed, nem rendszerbarát...
Szerk: Amúgy teljesen mindegy h. szar-e a protokol, akkor is meg kell oldani h. legalább a ware ne fagyjon/essen végtelen ciklusba. Ez a feladat. Stabilitás először, sebesség másodsorban. Főleg amigán, ahol az egész OS-t indíthatod újra ez esetben.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 02. 10:24
Igen, a parancsok 4 bájtosak, tehát először 4 bájtra várakozik a ciklus. Ha megérkezett, jön a parancs dekódolás, az ezt követő két bájt a további érkező adat hossza, tehát két bájt olvasása, majd ezen érték alapján újra meghívásra kerül a ciklus D0-ban a várt bájtok darabszámával.
ReceiveByteLoop
btst.b #14,$dff018
beq.s ReceiveByteLoop
move.w $dff018,d1
move.b d1,(a1)+
move.b d1,(a2)+
sub #1,d0
bne ReceiveByteLoop
rts
A2 csak a debug memoria címe, ide írattam ki párhuzamosan, mi érkezik és itt látszik, hogy elveszik időnként egy bájt. Van úgy, hogy 5-10 könyvtár olvasás művelet is rendben lezajlik, de van úgy, hogy egy kettő után elveszik.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Ápr. 02. 10:27 - Szerkesztve: charlie
Az megvan ugye, hogy az Amiga pre-emptív multitaszkos? Szóval ha az OS beléd szakít (márpedig beléd fog) akkor beszopsz. Mert ugye az Amiga serial porton nincs HW FIFO, szóval ha nem olvasod ki időben, így jártál. Esetleg tehetsz köré egy Forbid/Permitet és megpróbálhatod úgy, de a csomagmérettől függően meg fog állni a gép mint a szög, nem tudom hogy ezt akarod-e. Pluszban ha még így is elvesztesz byteokat, akkor lefagy az egész a picsába.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 02. 10:32 - Szerkesztve: yellowdog
Igen, sajnos nincs Rx buffer mint mondjuk az MCU-kban, akár 64 bájt is. Ha nem kerül kiolvasásra időben és jön az új adat, gondolom akkor szépen felülíródik :-(
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 02. 10:33
Na pont te is azt írod :-) Köszönöm, megpróbálom a Forbid/Permit-et, jó ötlet.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Ápr. 02. 10:34
Mekkora BPS-en hajtod te ezt az egészet? Mert amúgy magas BPS-nél még az is bejátszhat egy alap ötszázon, hogy hány szinű képernyőd van nyitva.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 02. 10:39
A1200 fut, 4 színben + 8MB fast ram-ot adtam hozzá és "Fastest possible" bár ezen a laptopon ez nem sokat számít.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Ápr. 02. 10:57 - Szerkesztve: charlie
Aha... Ja hogy ez még nem is igazi HW, értem... Fantasztik. :)
Amúgy, most megnéztem hardware manualt és a SERDATR regiszter 16 bites ám, és a legfölső bitjében van ilyen mágia, hogy bit, ami megmondja h. lett-e buffer túlcsordulásod receive oldalon, meg ilyesmi, amiket ha tesztelnél, akkor lehet h. nem várnál végtelenségig byte-ra, ami sose fog megérkezni, mert a hardver óbégat neked h. gáz van, te meg leszarod...
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 02. 16:07
Quoting: charlie Ja hogy ez még nem is igazi HW,
Így van, ráadásul virtual soros portok vannak a gépen, ezek virtuálisan cross-ba kötve, egyiken a WinUAE ül a másikra a TotalCommander kapaszkodik. De ezzel egyébként nincs gond, mert portmonitor is fut, hogy ott is figyelemmel tudjam kísérni mi merre és hány darab...
Quoting: charlie a legfölső bitjében van ilyen mágia, hogy bit, ami megmondja h. lett-e buffer túlcsordulásod receive oldalon
Anyám, és igen, én eddig ezt tényleg nagy ívben, pedig nézegettem tegnap is... Azt hiszem megyek megkeresem Wilsont... :-)
Köszönöm (újfent) a segítséget :-)
Csak halkan jegyzem meg, real vason nem lesz ezzel gond, ott a párhuzamos portra kapcsolódik az USB-parallel modul amely tartalmaz 256 bájtos FiFO-t illetve ha megtelik sincs gond a PC oldali driver addig nem küld újabb adatot amíg ki nem ürül. De amíg nagy vonalakban nincs kész addig nem akarom áttenni real hardverre, így sokkal kényelmesebb, hordozható és mem mellesleg gyorsabb a fejlesztés.
|
siz
Tag
|
# Elküldve: 2020. Ápr. 02. 16:22
Quoting: yellowdog így sokkal kényelmesebb, hordozható és mem mellesleg gyorsabb a fejlesztés.
És behozol magadnak pluszban olyan extra problémákat, amikkel napokig szívhatsz. :D
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 02. 16:48
Így van, nincsen rózsa tövis nélkül :-)
|
YADA
Tag
|
# Elküldve: 2020. Ápr. 02. 17:28
Csak halkan kerdem, a sorosportos pluginnak nincs handshake kezelese?
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 02. 18:54
De igen, van. Arra gondoltam, a ciklus elején indítok valamilyen timert(?) és ha mondjuk 2mp alatt leszámol 0-ra, akkor küldök egy hibajelzést, és visszaugrok a főprogramba. Természetesen rendszerbarát módon.
|
dino
Kék troll
|
# Elküldve: 2020. Ápr. 05. 07:34
Quoting: yellowdog a ciklus elején indítok
En csak a havi ciklust ismerem...
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 05. 09:52
Igen, az mindannyiunk életét meg szokta keseríteni... ;-) :-D
De komolyra fordítva, milyen kulturált és természetesen OS barát megoldás létezik, mert MCU-nál indítok egy HW timert majd amikor lejár, generál egy IRQ-t, tiszta sor, de ha jól látom az Amiga használja a CIA timereket, tehát nem foghatom, foglalhatom le csak úgy. Arra gondoltam, kézenfekvő lehet az 50Hz-es VBlank megszakítással számoltatni egy értéke, 100-ról 0-ra, akkor az 2s lenne például. De ez még csak elmélet, megvárom Csárlit... :-)
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Ápr. 06. 10:44 - Szerkesztve: charlie
Kultúrált megoldás rengeteg van, de többnyire v36+
Nyitásnak ott a timer.device lekérdezése, de nem tudom hogy 1.3 alatt az mennyire fejlett és eléggé halálcsillag a használata még újabb OS-eken is, jópár helper függvényt kell megírni hozzá, hogy értéket csiholj ki belőle.
Gyakorlatilag nagy vonalakban a device megnyitásához össze kell rakni egy IORequestet, amihez elobb kell egy MessagePortot foglalni, aztán DoIO() hívásokkal lekérdezni a device-ot. Elég macera, de ez a teljesen rendszerbarát megoldás. Magas szinten (C-ben) vannak ehhez helper függvények az amiga.lib-ben, mert amúgy az exec.libraryban csak v37 (3.0+) után van hozzá CreateIORequest függvény.
Aztán szintén timer.device, de v36+ a ReadEClock használata, ezzel legalább a DoIO()-s macerálást meg lehet spórolni. Lehet h. ez vagy valami hasonlóan konstans növekvő értéket ki lehet olvasni alapból a hardverből és akkor nem kell a device-szal szopni. De ezzel nincs tapasztalatom, talán majd valaki HW-közelibb kóder megmondja. Szerintem amíg _kiolvasod_ az értéket a ciklusodban a hardverből és nem írsz bele, addig rendben vagy...
Ugye ha megírtad volna rendesen a device-kezelést, és nem HW banging módon kezelnéd a soros portot, akkor A., egyrészt menne a cuccod más serial.device-okkal is (pl. nekem van egy IOBlixem, amin van rendes UART, és simán tud 115200-at lassú gépen is), B., most meg lenne a komplett keretrendszered a timer.device lekérdezéséhez, mert nagyjából ugyanaz. :)
Bocs, erre nem tudok most okosabbat mondani.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 06. 12:30 - Szerkesztve: yellowdog
Köszönöm!
Quoting: charlie Szerintem amíg _kiolvasod_ az értéket a ciklusodban a hardverből és nem írsz bele, addig rendben vagy...
Talán ez lehet a jó kompromisszumos megoldás, hiszen két érték különbségét is lehet figyelni, így elegendő az olvasás, ami önmagában akár nevezhető még rendszerbarátnak is, persze csak nagy jóindulattal :-)
Úgy nézem a CIA, természetesen mindkettő tartalmaz egy-egy Time-of-Day (TOD) Clock 24 bites számlálót, az egyiket a VSync a másikat a HSync hajtja, tehát előbbi értéke mondhatjuk másodpercenkét 50-el növekszik, ha 100-as különbséget figyel a program akkor megkapom a 2s-ot, szerintem ezen az úton indulok el.
Quoting: charlie menne a cuccod más serial.device-okkal is (pl. nekem van egy IOBlixem, amin van rendes UART, és simán tud 115200-at lassú gépen is)
A fejlesztés közben (WinUAE miatt) használom csak a soros portot, a végeredmény a parallel porton fog kommunikálni.
|
mc68k
Tag
|
# Elküldve: 2020. Ápr. 06. 18:43
Quoting: charlie Ugye ha megírtad volna rendesen a device-kezelést, és nem HW banging módon kezelnéd a soros portot, akkor A., egyrészt menne a cuccod más serial.device-okkal is (pl. nekem van egy IOBlixem, amin van rendes UART, és simán tud 115200-at lassú gépen is), B., most meg lenne a komplett keretrendszered a timer.device lekérdezéséhez, mert nagyjából ugyanaz. :)
Majd rájön, én ezt az iskolát már kijártam. Demot hw-re írunk, programot meg OS-re; semmi direkt hw access. Aztán rájön arra is, hogy OS-t programozni asm-ben kínszenvedés. Nem hiába találták ki a C-t. Örök érvényű. Biszbasz divatnyelvek jönnek-mennek, a C marad 40 év után is.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 07. 10:49
Quoting: mc68k Aztán rájön arra is, hogy OS-t programozni asm-ben kínszenvedés
Igen, érzem, hogy lehetne ennél egyszerűbb, könnyebb, de nekem a "C" a kínszenvedés, az biztosan nem az én utam. Többször nekiszaladtam, de képtelen vagyok értelmezni, átlátni mikor és "mire gondolt a költő"... :-(
Arról nem beszélve, nagyon szeretem (C16 óta) szeretem az asembly szintaktikát ill. programozást :-) Viszont Csárli féle Pascal esetleg szóba jöhet, ha elkészülök nagy vonalakban, az alap funkciókat illetően. Így lehetőség lesz sebesség összehasonlításra is, illetve egyéb (nem sebesség kritikus) funkciók kényelmesebb megírására.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 07. 10:59
Quoting: mc68k semmi direkt hw access
Mielőtt az egésznek nekiláttam, illetve ami induló lökést adta az egy működő és asm forrással(!) ellátott érthetően kommentezett USB device.driver elemzése majd sikeres próbálgatása, módosítása volt.
Innen indult a dolog, amely felkeltette az érdeklődésem, majd hosszas keresgélést követően meglett a src, amely segítségével kicsit belepillanthattam a handler és driver illesztésének mikéntjébe, szerencsémre, mint fentebb említettem az egész asm-ben készült, a parallel port meghajtása is rajta keresztül a kommunikáció a FTDI Vinculum chip-el is. Mindez nagyon jó alapot adott, azt hiszem, de a driver-ben is közvetlen regiszter hozzáférés van egyébként, amit én amúgy sem vetek meg, mint elsősorban hardveres másodsorban szoftver tákoló szagember :-)
|
dino
Kék troll
|
# Elküldve: 2020. Ápr. 07. 11:32
yellowdog
Segtenek, pontosabban egy profi haverom, de kene a mail cimed.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 07. 17:39
A profilomban elvileg ott van, köszi :-)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Ápr. 12. 19:46
-(a7) ... (a7)+ vagy -(sp) ... (sp)+ ez itt a kérdés... Van ahol azt olvasom, az A7 a verem mutató, van ahol meg SP-vel kezdődik a program :-(
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Ápr. 12. 20:17
Ugyanaz. A7 = SP. Nehany assembler az "olvashatosag" kedveert megkulonbozteti a veremmutatot "Stack Pointer"-kent, a "normal" cimregiszterektol. Hogy miert van a kettos elnevezes, talan vilagosab lesz, ha azt is megnezzuk, hogy bizonyos assemblerek "FP" neven hivatkoznak a frame pointerre, ami egy sima cimregiszter aliasa, platformfuggoen lehet a4, a5 v. a6. Amigan altalaban a5, de pl. Linuxon a6. Ez azert jo, mert igy lehet platformfuggetlen assembly rutinokat irni, amelyek mindig a megfelelo regiszterre hivatkoznak, akkor is, ha az platformonkent mas.
Amugy a Stack Pointerbol is ketto van, egy az user space, egy a supervisor programoknak (idonkent SSP neven is hivatkoznak ra), es amugy a CPU mindig 2 byte hatarra igazitja, tehat pl. move.b d0,-(sp) v. move.b d0,-(a7) a veremmutatot _KETTOVEL_ csokkenti, nem eggyel. Ezzel pl. olyan trukkok is kivitelezhetove valnak, mint pl. word-ok byteswappelese stacken at:
move.b d0,-(sp)
move.w (sp)+,d0
A fenti ket utasitas a d0 regiszter also byte-jat lementi a stackbe, majd visszatolti word-kent, de kozben az sp erteke ugyanaz lesz mint korabban, viszont a d0 erteke felcsuszik a d0.w regiszter felso byte-jaba.
Es ez gyorsabb mint az lsl.w #8,d0, sima 68000n. :)
Szoval, igen, az A7/SP eleg specialis 68k-n- abbol a szempontbol sima cimregiszter, hogy a cimregiszterrel dolgozo utasitasok szinte ugyanugy kezelik mint barmelyik masik cimregisztert (ertsd: binaris szinten ugyanugy van encode-olva az utasitasban), de abbol a szempontbol nem, hogy megis csak ez a veremmutato, annak minden specialitasaval egyutt.
|
