| Szerző |
Üzenet |
anchor
Tag
|
# Elküldve: 2020. Jan. 31. 15:59
Yellow Dog cmpa.l #$0,a2 ... de ez hosszabb kódot eredményez :)
6 byte 4 helyett. emiatt nem garantált hogy a végrehajtása gyorsabb.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Jan. 31. 21:12 - Szerkesztve: yellowdog
Quoting: anchor cmpa.l #$0,a2 ... de ez hosszabb kódot eredményez
Köszönöm, jó tudni, hogy van ilyen is! Végül módosítottam a kódot, a visszatérési értéket D0-t tesztelem és csak azt követően, ha érvényes, adom át A2-be sz értéket, így még egyszerűbb is lett a kód.
Esetleg véleményezésre ide tenném, köszönöm:
; ---------------- get device name ----------------
move.l #5,d1 ;devices = 4, volumes = 8, assign = 16
CALLDOS LockDosList
move.l d0,a2
lea DeviceList(PC),a3 ;mutató a névlista első elem címére
DLLoop
move.l a2,d1
move.l #5,d2
CALLDOS NextDosEntry
tst.l d0 ;érvényes bejegyzés?
beq DLEndList ;ha nem, nincs több -> keresés vége
move.l d0,a2 ;ha igen, következő pointer eltárolása
move.l dol_Task(a2),d0 ;file system device?
tst.l d0
beq DLLoop ;ha nem, ugrás a következőre
lea DeviceNum(PC),a4 ;érvényes device-ok darabszáma +1
add.l #1,(a4)
move.l a3,d3 ;aktuális bejegyzés mutató tárolása
move.l d0,(a3)+ ;task pointer letárolása
move.l dol_Name(a2),d0 ;név pointer beolvasása és x4
lsl.l #2,d0
addq.l #1,d0 ;hossz érték tároló átlépése és
move.l d0,a4 ;mutató beállítása első karakterre
DLStoreChar
move.b (a4)+,(a3)+ ;név másolása
tst.b (a4) ;van még karakter?
bne DLStoreChar ;ha igen ugrás a következőre
move.b #$3a,(a3) ;utolsó karakter után : tárolása
move.l d3,a3 ;aktuális bejegyzés mutató visszatöltése
add #$10,a3 ;következő bejegyzés címe +$10
bra DLLoop ;következő keresése
DLEndList
move.l #5,d1
CALLDOS UnLockDosList
|
Yellow Dog
Tag
|
# Elküldve: 2020. Feb. 26. 03:30
Tehát azt megbeszéltük, hogy a fájlnév (elérési úttal együtt) nem lehet több 256 bájtnál klasszik OS esetén, vagy esetleg mégis, de most egyelőre próbálom ezen lehetőséget elengedni, szóval a kérdésem, kérdéseim a következők:
1. directory listázásához mekkora adatterületet ajánlanátok méret = X * 256bájt, vagyis mennyi bejegyzés lehet max. illetve ha nincs elméleti limit, a józan ész mennyit mondana, mennyivel számolnátok ti?
2. az adatterületet tegyem a program végébe és cipelje mint pók a potrohát, vagy allocmem-et használjak inkább? Nyilván utóbbi bonyolultabb és szemeteli a memóriát, cserébe kisebb lenne magának a programnak a mérete.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Feb. 26. 09:56 - Szerkesztve: charlie
@Yellow Dog:
move.l a2,d0
tst.l d0
Ha mar assembly kodnal tartunk, most total emlekezetbol irom, szoval lehet h. hulyeseg, de ugy remlik hogy a tst.l ez esetben felesleges, foleg ha csak azt akarod megtudni hogy nulla-e az eredmeny vagy nem, mivel a move.l utasitas a mozgatott ertektol fuggoen mar onmagaban be fogja allitani a flageket megfeleloen.
az adatterületet tegyem a program végébe és cipelje mint pók a potrohát, vagy allocmem-et használjak inkább?
AllocMem. Nyilvan. Helyesebben - AllocVec, ugy nem kell nyilvantartani a meretet. Nincs olyan h. "biztos belefer" adatmeret ebben az esetben. Minden mas csak borzaszto takolas. Ne csinald.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Feb. 26. 18:39 - Szerkesztve: yellowdog
Quoting: charlie move.l utasitas a mozgatott ertektol fuggoen mar onmagaban be fogja allitani a flageket megfeleloen
A doksi nem írja érdekes módon, de EASy68k-ban teszteltem és valóban 0 betöltése esetén Z=1, köszi az infót :-)
Quoting: charlie Helyesebben - AllocVec
Sajnos nem játszik, V36-os, és igazából nem is értem a működését, mi alapján változtatja a méretet utólagosan? Arra gondoltam, AllocMem mondjuk 4k vagy 8k, ha közben látom, hogy nem elég akkor foglalok egy duplát, oda átteszem az addig összegyűlt tartalmat, majd az eredetire FreeMem.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Feb. 26. 20:49 - Szerkesztve: charlie
@Yellow Dog:
A doksi nem írja érdekes módon
Ööööööö? De?
V36-os, és igazából nem is értem a működését, mi alapján változtatja a méretet utólagosan?
Hogy a mi? Nem változtat az meg semmit. Az AllocVec ugyanaz mint az AllocMem, csak a FreeVec-nek nem kell megadni a foglalásod méretét, mert magában a memóriablokkban eltárolja amit foglal. Amúgy az algoritmus amit leírtál működhet, bár ez a legtutibb módja h. memóratöredezettséget állíts elő,... Szóval azért érdemes valami szép nagyot befoglalni az elején, vagy méginkább - felfűzni az adataid egy láncolt listába, aminek minden elemét külön foglalod, és akkor nem kell blokkokat újrafoglalgatni meg másolni.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Feb. 26. 22:45
Quoting: charlie Ööööööö? De?
Ő, de, valóban, nem láttam a csillagokat pdf teljes oldalas nézetben :-)
Quoting: charlie felfűzni az adataid egy láncolt listába, aminek minden elemét külön foglalod
Van értelme kb. kB-os blokkokat külön foglalni? Mondjuk forráskód szinten valóban korrekt, és végül is a memóriával is takarékoskodik ha jobban belegondolok. De ez most egyelőre megy az "optimalizálás" kategóriába, ha már működik minden rendesen, akkor jöhet a finomhangolás, méret csökkentés, stb. Első körben foglalok egy nagyobb blokkot azt hiszem
|
YADA
Tag
|
# Elküldve: 2020. Feb. 27. 07:18
Egyenkent foglalas boven belefer lancolt listaval, ne varialj feleslegesen. Eloszor mukodjon jol es stabilan.
Aztan ha mar tuti jol mukodik nagy listakkal is, akkor esetleg lehet jatszani optimalizalast (de az mar nagyon a folyamat vege, elotte meg millio egyeb fontosabb gondod lesz).
Lattad mar akar csak egyszer is, hogy mit muvel az eger mozgatas a memoriaval? Ha igen, akkor soha tobbe nem fog zavarni a kismillio egyenkenti allocmem es annak a kovetkezmenye.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Feb. 28. 03:17
Quoting: Yada Lattad mar akar csak egyszer is, hogy mit muvel az eger mozgatas a memoriaval?
Ő, izé szedtem már szét a gépet, de úgy sem láttam... ;-)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Feb. 28. 16:20
Bináris - > ASCII (?) átalakításra keresek forrást, C kizárva, vagy algoritmust, vagyis milyen módon tudnám a leggyorsabban egy long bináris értékét olvasható karakteres formába konvertálni?
A "LONG fib_Size ; Number of bytes in file)" fájlméretet kell átküldeni a TotalCommander felé már karakteres formában, illetve a "STRUCT fib_DateStamp,ds_SIZEOF ; Date file last changed" dátumot is, 14 karakter hosszan: ééééhhnnóóppmm
STRUCTURE DateStamp,0
LONG ds_Days ; Number of days since Jan. 1, 1978
LONG ds_Minute ; Number of minutes past midnight
LONG ds_Tick ; Number of ticks past minute
LABEL ds_SIZEOF
Köszönöm előre is az ötleteket és segítséget.
|
anchor
Tag
|
# Elküldve: 2020. Feb. 28. 21:21 - Szerkesztve: anchor
van egy ilyen fuggveny az execben hogy RawDoFmt(). ha jol ertem mit szeretnel, akkor ez hasznos lehet neked.
link
a datestamp tartalmaz minden adatot hogy a megadott formatumba alakitsd, de en nem bajlodnek ezzel. biztosra veszem hogy van OS fuggveny az atalakitasara, erdemes korbenezni.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Feb. 28. 23:36 - Szerkesztve: yellowdog
Quoting: anchor van egy ilyen fuggveny az execben hogy RawDoFmt()
Sajna ez is V36-os...
Tehát azt szeretném, ha mondjuk D0 = $00000100 (256) akkor a decimális formában adja vissza ascii karakterekként a memóriában valahogyan így:
$0000 $32
$0001 $35
$0002 $36 mert ezt a stringet kell átküldenem, ilyen böszme módon fogadja a TC plugin, amely C-ben íródott, tehát esélyem sincs a saját elképzelésemnek megfelelően módosítani. Alkalmazkodnom kell...
szerk. a fájl méret konverzió megoldódott, max. 10 karakter hosszú lehet, tehát ciklusban elindulok és kivonok 1 000 000 000-od ahányszor megvan, a darabszám kerül a megfelelő helyiértékre, majd 100 000 000-t, majd 10 000 000-t, és így tovább. A dátumnál hasonló lesz az elv, szökőév ügyileg kiegészítve.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Már. 01. 15:11 - Szerkesztve: charlie
@Yellow Dog:
anchor: "van egy ilyen fuggveny az execben hogy RawDoFmt()"
Sajna ez is V36-os...
Amúgy nem, csak a format template egyes elemei v36-ok, de maga a függvény megvan az elejétől.
A dátumnál hasonló lesz az elv, szökőév ügyileg kiegészítve.
Amúgy az utility.library-ban vannak erre függvények (Amiga2Date és Date2Amiga), de az is v36 mind. A végén még kiderül h. az az OS2.0 mégse volt értelmetlen faszság. :P
Amúgy az amigázás közben a lelkem kicsiny zugába elrejtőzött senior fejlesztő mindig némán sikoltozni kezd, amikor arról olvasok, hogy valaki dátumfeldolgozó rutinokat akar írni, pláne assemblyben. Egyáltalán, saját dátumfeldolgozó és konvertáló rutinokat. Mert ugye, a számítástechnika történetében még alig hallottunk idő/dátumkezelési bugokról. Ez az a terület, amiről minden fejlesztő azt hiszi h. érti, amíg el nem kell kezdeni dolgozni vele. Mindegy, sok sikert. :P
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 01. 16:32 - Szerkesztve: yellowdog
Quoting: charlie OS2.0 mégse volt értelmetlen faszság. :P
Az A500 kompatibilitás lehetőségét, amíg nem muszáj nem adnám fel ;-)
Quoting: charlie az utility.library-ban vannak erre függvények (Amiga2Date és Date2Amiga
Ezt nem tudtam, honnan is tudhattam volna, de (ismételten) köszönöm a segítséget :-)
Quoting: charlie senior fejlesztő
Két, vagyis már csak másfél hónap és túl leszek a fél évszázadon, oké a fejlesztő talán még erős, de azért dolgozom azon is, mint (pre)senior... ;-)
Quoting: charlie valaki dátumfeldolgozó rutinokat akar írni, pláne assemblyben. Egyáltalán, saját dátumfeldolgozó és konvertáló rutinokat.
Ez most komoly, de tényleg? Amiga programozása hogyan ha nem assembly nyelven ("C" br....) és miért baj, hogy 49,93 évesen nem csak bohóckodom (játszok, stb. ami belefér a kategóriába) hanem programot írok? Arról nem beszélve, a fentebb feltett kérdéseim egyikét, a bináris->ascii konvertáló rutint (már) megcsináltam és szétteszteltem (0-tól max. fájlméretig), szóval mondhatom, hogy hibátlanul működik, és mindössze 82 bájt, és ha másért nem, tanulás gyanánt, és most már csak azért is :-P a dátum átalakítást is megírom, azért is :-P és azért is, hogy ne kelljen a programom futtatásához egyéb könyvtárat telepítgetni :-) Utálom Windows esetén is, hogy teleszemeteli egy-egy telepítő a rendszert, ha egy mód van rá az "egyexés" Portable dolgokat részesítem előnyben, szóval igyekszem Amiga rendszeren is ezt az elvemet követni, persze ameddig lehet... ;-)
Quoting: charlie minden fejlesztő azt hiszi h. érti, amíg el nem kell kezdeni dolgozni vele
Én nem hiszem, de tanulok és ráérek, mert nincs határidőm mert hobbi ez az egész :-)
Quoting: charlie sok sikert. :P
Köszönöm, és elvárom(???) :-P a további közreműködésedet, ha elakadnék, hiszen az Amiga közös ügyünk ;-) :-)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 01. 16:48 - Szerkesztve: yellowdog
Na, ittam egy páleszt és megnéztem azért a Amiga2Date rutint:
INPUTS AmigaTime - the number of seconds from 01-Jan-1978.
FileInfoBlock viszont az alábbi módon tárolja a dátumot:
STRUCTURE DateStamp,0
LONG ds_Days ; Number of days since Jan. 1, 1978
LONG ds_Minute ; Number of minutes past midnight
LONG ds_Tick ; Number of ticks past minute
LABEL ds_SIZEOF ; DateStamp
Szóval nem jó a problémára, arról nem beszélve az eredmény az alábbi struktúrába kerül ami szintén további feldolgozást igényelne:
struct ClockData
{
UWORD sec;
UWORD min;
UWORD hour;
UWORD mday;
UWORD month;
UWORD year;
UWORD wday;
};
#endif
szerk.: csak 58 bájt... :-)
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Már. 02. 00:30 - Szerkesztve: charlie
Ugye ezt elvileg ugy csinaljuk, hogy a DateStamp-ot eleg egyszeru atkonvertalni masodpercbe, mivel a keplet:
seconds = (ds_Days * 60 * 60 * 24) + (ds_Minute * 60 * 60) + (ds_Tick / TICKS_PER_SECOND)
Ahol a TICKS_PER_SECOND erteke mindig 50. Ezutan az igy kapott erteket behanyjuk az Amiga2Date-nek es orulunk. Ezutan az igy kapott struktura fuggvenyeit mar mezonkent lehet az altalad is megoldott modon (vagy hasonloan) stringge alakitani. Az egyetlen problemas dolog az az lehet, hogy a ds_Days-hoz valszeg 32*32 bites szorzas dukal, mivel a 60*60*24 az 86400, es a ds_Days erteket is ajanlott 32 biten kezelni, es ugye olyan csak 020+-on van. Mondjuk nem tul nehez a 16*16->32 bit szorzasbol es osszeadasokbol osszerakni egy 32*32 bites szorzast, csak megsem olyan h. 1 utasitas az egesz.
Mellesleg ha mar a v36-ot targyaljuk. A dos.library-ban van DateToStr fuggveny is, amivel 1 lepesben stringge lehet alakitani a DateStampot, es nem kell semmit sehova varialni.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 02. 15:29
Quoting: charlie az igy kapott erteket behanyjuk az Amiga2Date-nek es orulunk. Ezutan az igy kapott struktura fuggvenyeit mar mezonkent lehet az altalad is megoldott modon (vagy hasonloan) stringge alakitani
Ó, erre nem gondoltam, köszönöm, csak az a sok szorzás... Lehet túlreagálom csak, mert viszonylag rövid idő alatt kell visszaküldeni a TC felé a könyvtár tartalmát (ascii (név, fájlméret, dátum, protect bitek) ellenkező esetben timeout-os hiba keletkezik. Az átalakításokat ugye minden bejegyzésnél fájl, vagy könyvtárnév ki kell számolni, mondjuk könyvtár esetén nincs fájlméret.
Quoting: charlie ha mar a v36-ot targyaljuk
Nem nem, pont azt írom, írtam, hogy A500-al is kompatibilis készüléket szeretnék készíteni, a programot is 68000 kompatibilis utasításokat használva írom.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Már. 03. 17:36
@Yellow Dog:
Ó, erre nem gondoltam, köszönöm, csak az a sok szorzás... Lehet túlreagálom csak, mert viszonylag rövid idő alatt kell visszaküldeni a TC felé a könyvtár tartalmát (ascii (név, fájlméret, dátum, protect bitek) ellenkező esetben timeout-os hiba keletkezik.
Nem hiszem h. túl lassú lenne, még akkor sem ha szorozgatni kell... Azért _annyira_ nem lesz lassú még egy 68000-n sem, hacsak nem egy ötvenezer elemű könyvtárat akarsz feldolgozni...
Nem nem, pont azt írom, írtam, hogy A500-al is kompatibilis készüléket szeretnék készíteni, a programot is 68000 kompatibilis utasításokat használva írom.
Azt értem, csak mivel több v36-os megoldás is szóba jött, gondoltam beleírom közéjük ezt is, hátha valaki később olvassa a fórumot és esetleg hasznos valami másik projekthez, aminél elég ha újabb OS-eken fut.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 04. 18:02
Quoting: charlie mivel több v36-os megoldás is szóba jött, gondoltam beleírom közéjük ezt is
Igen, persze jogos, más is tanulhat az itt olvasottakból.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 17. 12:36
ASM-One esetén megoldható, CLI-ből fordítás, tehát parancssorban megadható paraméterekkel?
Mert jelenleg NotePad++ írom a programot és minden esetben el kell indítani az ASM-One-t, be kell tölteni majd fordítás végül futtatás. Eléggé macerás, jobb volna egy MAKE szerűséget futtatni amely mindezt elvégzi és csak indítani kellene a végeredményt. Doksit nézegettem, de nem találtam erre vonatkozó információt.
Köszönöm
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Már. 17. 12:51
Miert nem forditod pl. vasm-mal? Azzal meg keresztforditani is birnal es csak a vegso exe-t kene Amigara masolni.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 17. 21:39
Quoting: charlie Miert nem forditod pl. vasm-mal?
Hát, nekem olyanom nincs ;-) Itt viszont nem találok Windows verziót...
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Már. 17. 22:13 - Szerkesztve: charlie
Van par Windows binaris build online. Pl. innet szedd le, https://www.chibiakumas.com/z80/vasm.php
Van ott valahol egy tavaly nyari Vasm.7z, az valszeg eleg friss. A sok binarisbol ami benne van jo esellyel a vasmm68k_mot_win32.exe kell majd neked.
Gondolom jo AsmOne-os modszerrel ez is egy egyfileos projekt, szoval linkerre nem lesz szukseged, a vasm-nak meg olvasd el a manualjat, de valszeg az -Fhunkexe opcioval fog neked Amigas exet forditani.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 18. 16:32 - Szerkesztve: yellowdog
Quoting: charlie vasmm68k_mot_win32.exe kell majd neked
Leszedtem, működik az -Fhunkexe opcióval, köszönöm :-) Mondjuk nagyobb fájlt generál... de ez végül is fejlesztés időszakában annyira nem probléma.
Quoting: charlie Gondolom jo AsmOne-os modszerrel ez is egy egyfileos projekt
Természetesen ;-) Bár az include-okat fordításnál tölti be természetesen. Szebb volna forrásként ha szétbontanám, de a kezelése nekem nehézkesebbnek tűnik mintha egyben van a szerkesztőben.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Már. 18. 17:52
Mondjuk nagyobb fájlt generál... de ez végül is fejlesztés időszakában annyira nem probléma.
Be kéne kapcsolni az optimalizációkat... Az AsmPro/AsmOne ugyanis optimalizálja kódod, ergó átír utasításokat hogy rövidebb legyen. Ezt a vasm is meg tudja csinálni neked, de mondtam h. olvasd el a manualt, abban le van írva az összes m68k specifikus kapcsoló, közte az optimalizációk is.
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 19. 11:07
El fogom olvasni, tényleg, köszönöm :-)
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 30. 21:47 - Szerkesztve: yellowdog
Jól értelmezem, ha Amiga kódot írunk/írok akkor annak mindenképpen relokálhatónak kell lennie, tehát a kódban elhelyezett db-k, adatok és egyéb dolgok esetében a LEA minden esetben (PC) címzést kíván?
És természetesen nincs JMP és JSR, helyettük BRA és BSR
|
anchor
Tag
|
# Elküldve: 2020. Már. 30. 23:33
nyugodtan hasznalhatsz nem pc rel. cimzest, az OS relokalja a kodot betolteskor. erre van a reloc hunk.
|
Chain-Q
Divatamigás
|
# Elküldve: 2020. Már. 31. 09:46 - Szerkesztve: charlie
Ahogy Anchor is írta, nyugodtan használhatsz bármilyen címzésmódot.
És hogy a relokáció hogy működik: a fent említett reloc hunk (ami egy külön blokk - azaz hunk - az exe-ben), egy táblázat, ami megmondja az OS exe betöltőjének mik azok a pozíciók az exe-ben, ahol fix címek vannak használva, és betöltéskor az OS át kell hogy írja őket, hiszen csak betöltéskor derül ki, hogy milyen tényleges címre kerülnek. Szóval miután betöltéskor kiderült, hogy hova került a kódot (és az adatod(!), az adat hunkot is relokálni kell, hiszen lehetnek benne egymásra mutató címek!) az OS szó szerint végigmegy a reloc hunkon és "megpatcheli" a kódodat betöltéskor, hogy a reloc hunkban megadott helyeken a megfelelő címek legyenek. (Ezért bírom amikor az assembly programozók órákat reszelgetik a kódjukat hogy minden bit egy irányba áljon, aztán jön az assembler, a linker, meg az OS loader, és annyi mindent átturkálnak, hogy a végeredmény a memóriában már kis túlzással alig hasonlít arra amit leírtál, de nem baj. :P)
Ez a mechanizmus amúgy minden OS-ben jelen van, attól függetlenül h. sok OS-ben sokáig nem használták, mert hogy minden procesz saját címterületet kapott, így elvileg nem kellett relokálhatónak lenni az exe-nek, de a modern ABI-k és pl. a fejlettebb OS-eken használt ASLR (Address Space Layout Randomization) biztonsági feature-ök nélkülözhetetlenné teszik.
(Megj: bizonyos primitívebb OS-eken (pl. classic MacOS, PalmOS) a relokálási funkciót legalább részben nem az OS, hanem az exe saját maga végzi, pl. a különféle compilerek startup kódja. Na ezért nincs még Free Pascal classic 68k MacOS-re, mert nem volt még elég hosszú az életem h. kiszopjam, hogy mit is akar tőlem az az OS-nek csúfolt bughalom... :P )
|
Yellow Dog
Tag
|
# Elküldve: 2020. Már. 31. 10:28 - Szerkesztve: yellowdog
Értem, köszönöm mindkettőtöknek az infót, megmondom őszintén, erre nem gondoltam, hogy ilyen van. Régen sem értettem, az asm kódok egy része tele volt PC-zve míg másokban semmi, és mégis működtek...
Akkor elengedem ezt a dolgot, bár éppen az imént kezdtem átírogatni a kódot, mert (miért is ne) időnként random fagyogat a program, van, hogy indulás után szinte egyszerre, van úgy, hogy percekig megy hiba nélkül. Bíztam benne, hogy esetleg valami ilyesmi lehet a gond rossz helyre ír és valami felülírja, de ezek szerint keresgélhetek tovább. Van esetleg valami realtime debugger ami használható is?
|
