Hírek | Archívum | Fórum | IRC | Amiga | AmigaOS | FAQ | RSS

 - Fórumok - Keresés - Statisztika - Szabályzat - Pegasos.hu fórum
forum.amigaspirit.hu / Fejlesztés / Általános fejlesztési kérdések
<< 1 ... 18 . 19 . 20 . 21 . 22 . 23 . 24 .
Szerző Üzenet
siz
Tag

# Elküldve: 2021. Okt. 01. 09:23


Én teljesen zöldfülű vagyok Amiga programozás témában, de azért átnézném a kódot aszerint, amit Charlie mondott: szerintem (is) minden struktúrát, amit op.rendszer hívásra használsz wordre kell igazítani és itt ezt semmi nem garantálja.

Yellow Dog
Tag

# Elküldve: 2021. Okt. 01. 10:32


Bekerült a megfelelő helyekre CNOP 0,4 pl. mytask, oldWindowPtr illetve minden dc.l longword-re igazítva. Sajnos így sem változott az eredmény, de mint említettem, egyébként működik a LOCK egyéb esetekben, illetve NDOS lemez foglalásánál is rendesen, ha engedem, hogy felugorjon a requester és én nyomok rá egy CANCEL-t. Egyedül akkor áll meg a task, ha -1 értékkel ki akarom kapcsolni a megjelenését, ekkor a leírás szerint önmaga küld(ene) egy CANCEL-t, de ez nem történik meg:
"If pr_WindowPtr is set to negative one, the system request will never appear and the return code will be as if the user had selected the rightmost button (negative response)"

:-( :-( :-(

Chain-Q
Divatamigás

# Elküldve: 2021. Okt. 01. 12:19 - Szerkesztve: charlie


Obazmegrajottem.

move.l -1,pr_WindowPtr(a0)

helyett

move.l #-1,pr_WindowPtr(a0)...

?

A move.l -1 ugye nem -1 konstanst, hanem az $FFFFFFFF cim-tol kezdodo dword-ot (ami valszeg korbewrappol, tehat az address range utolso, es elso harom byte-jat fogod kapni), fogja a pr_WindowPtr-be tolteni. Ami jo esellyel nem lesz -1, se nulla. Ezert amikor a Lock() meg akarja nyitni a warning ablakot, akkor ervenyes mutatonak hiszi, es megprobalja a requestert hozzacsatolni, amibe az intuition szetfagy (lasd megall a kurzor).

Mondjuk az ilyesmi bugokon egy disassembly tanulmanyozasa szokott am segiteni... Ha mar assembler koderek vagyunk, ugye, khmm.

Szerk: es ahogy megmondtam, semmi koze az ilyen intuition IDCMP magiazashoz, meg hogy sajat v. konzol ablakod van. Sima typo.

Szerk#2: Es kozben arra is rajottem h. ez az en bugom valszeg, ha csak copypastelted amit ideirtam, mert ugye en egy FPC disassemblyt massziroztam at kezzel neked peldakodnak, es valszeg lemaradt a #... :) Te meg bemasoltad.

Szerk#3: Itt az eredeti kod/post. Es igen, abban is hianyzik a #, viszont ott a tetejen h. "Pszeudokod". :P Szoval nem vallalok felelosseget! :)

Szerk#4: Javitottam a pszeudokodot az eredeti postban, hogy csokkentsuk a copypaste problemak eselyet, hatha kesobb mas is megtalalja a hozzaszolast, es felrevezetodik. Az eredeti postba megjegyzest fuztem, hogy maradjon nyoma a szerkesztesnek.

siz
Tag

# Elküldve: 2021. Okt. 01. 12:55


Quoting: charlie
Mondjuk az ilyesmi bugokon egy disassembly tanulmanyozasa szokott am segiteni... Ha mar assembler koderek vagyunk, ugye, khmm.

Ja, hasonlókat én is szoktam csinálni plus/4-en (ott ugye magas szintű nyelvek használata nem túl jó megoldás) és az első debugnál kiderül, h nem az került a regiszterbe, mint amit vártam. (vagy a fordítási listingből is, ha belenézek és azt látom, hogy nem a9-es opkód van ott, hanem mondjuk ad)

Yellow Dog
Tag

# Elküldve: 2021. Okt. 01. 16:47


Quoting: charlie
Obazmegrajottem...

A move.l -1 ugye nem -1 konstanst, hanem az $FFFFFFFF cim-tol kezdodo dword

Ó tényleg, így elnézni, pedig még próbáltam a #0-val is, mondom hátha, majd visszaírtam szimplán -1 értékre. Nem vagyok százas az biztos :-)

Quoting: charlie
Mondjuk az ilyesmi bugokon egy disassembly tanulmanyozasa szokott am segiteni... Ha mar assembler koderek vagyunk, ugye, khmm.

Hát igen, tény és való, de én ugye inkább assembly kókler babérokra pályázok... :-D Mondjuk én a helyedben csak annyit írtam volna, hogy egy karakter hiányzik, tessék figyelmesebben nekifutni még egyszer! ;-)

Szóval, köszönöm szépen a megoldást, természetesen :-)

Yellow Dog
Tag

# Elküldve: 2021. Okt. 29. 22:55 - Szerkesztve: yellowdog


Tudom, nem konkrétan Amiga, de azért megkérdezem, hátha...
Normális az, hogy az SD kártya csatlakoztatását követően (USB MSD) a szektorok lekérdezése (SCSI read_10 command) 8-szor hajtódik végre Windows (32 és 64bit) rendszeren? A kártya FAT32-re (512byte/sector) van formázva.
Köszönöm

Yellow Dog
Tag

# Elküldve: 2021. Nov. 05. 16:07


Na, akkor Amiga kérdés...

Van mód egy-egy meghajtó (pl. DH0 vagy DH1) teljes írásvédelmére, tehát, hogy egyéb taszk csak olvasni tudja? Természetesen ideiglenesen. Illetve van mód programból figyelni a diszk eléréseket, tehát, hogy történt-e törlés vagy másolás?

Köszönöm

Chain-Q
Divatamigás

# Elküldve: 2021. Nov. 05. 20:44


Na ez megint olyan kérdés, aminél felettébb gyanús, hogy valszeg megint valamit körbe akarsz tákolni, amit leginkább nem kéne. Mi az eredeti probléma, amit meg akarsz oldani? :)

Az egész driveot lehet lockolni magadnak (ACTION_INHIBIT DOS packet), de ez csak akkor érvényes, ha szektorszinten akarod manipulálni a lemezt, mert ekkor a lemez fájlsziszteme kikapcsol, amig vissza nem kapcsolod, és egyéb mellékhatásai is lehetnek, szóval ezt valszeg nem akarod. De akkor mit akarsz?

Yellow Dog
Tag

# Elküldve: 2021. Nov. 06. 09:08


Nem akarok tákolni, kizárólag OS barát módon szeretném a fájlműveleteket logolni, erre keresnék OS szintű támogatást illetve a kérdésem arra irányult, megoldható-e ez egyáltalán, köszönöm.

Chain-Q
Divatamigás

# Elküldve: 2021. Nov. 06. 09:31 - Szerkesztve: charlie


Újra fel akarod találni a SnoopDos-t, vagy mi? :)

https://aminet.net/util/moni/SnoopDos.lha

Amúgy ilyen támogatás nincs az OS-ben. A SnoopDos úgy oldja meg, hogy exec.library/SetFunction()-nal magára irányítja a trackelni kívánt OS függvényeket, logolja a meghívásukat, aztán továbbhív az OS-be. Az ezt megoldó forrásfájl a SnoopDos-ban több mint 200K... Nyilván ez jó sok függvény és DOS packet támogatását tartalmazza, de talán jelzi h. nem triviális feladatról beszélünk.

De az _nagyon_ erősen ellenjavallott, hogy egy bármilyen átlagos alkalmazás ilyesmit csináljon. Ha nem érted miért, akkor meg főleg. :) (Ha van igény leírom, de még túlságosan reggel van ehhez...)

Szerk (2 órával később): najó, már nincs annyira reggel, leírom. Szóval a fő probléma az OS patcheléssel az, hogy abban a pillanatban, hogy több program is elkezdi csinálni, mindenféle konfliktusokba ütközöl. Pl.:

"A" program megpatcheli a dos.library Lock függvényt, ez esetben nincs gond, az eredeti függvény címe a ROM-ba mutat, miután "A" program elvégezte a dolgát az függvénnyel, meghívja az OS rutint.

Majd miközben "A" program fut, "B" program elindul és megpatcheli ugyanazt a dos.library Lock() függvényt. Ez esetben a "B" program által "látott" régi függvény cím, az "A" programra mutat. Szóval "B" program elvégzi a dolgát, majd belehív "A"-ba, ami elvégzi amit ő akar, majd továbbhív az OS-be. Eddig jó.

A probléma ott kezdődik, mi történik, ha "A" program futása eközben be akar fejeződni. A következő lehetőségek vannak.

1., "A" program leszarja mi történik, és visszaállítja az eredeti ROM függvény címét. Ebben az esetben "B" program működése sérül, hiszen többé nem mutat rá a patchelt függvény, ergó nem tudja ellátni a feladatot, amiért megpatchelte az OS hívást. Amikor ezután a "B" program kilép, akkor további változatos lehetőségek vannak, amiket ebből a három pontból hasonló logikával le lehet vezetni.

2., "A" program észreveszi, hogy valaki más is hozzányúlt az OS függvényhez, és ezért nem állítja vissza az eredeti címet, de kilép és törlődik a memóriából. Ebben az esetben a "B" programban eltárolt "eredeti függvény" cím hibás lesz, hiszen a már nem létező "A" programra mutat. Az eredmény jó eséllyel a megpatchelt függvény első meghívásakor egy masszív fagyás lesz.

3., az "A" program észreveszi, hogy valaki más már hozzányúlt az OS-hez, ezért nem állítja vissza az eredeti címet és benne hagyja magát a memóriában. Ez még a legemberibb megoldás, mert legalább az azonnali fagyást kivédi, de nyilván a program többet nem törölhető a memóriából biztonságosan. Ezt a megoldást választja egyébként a SnoopDos, még egy figyelmeztető requestert is feldob, hogy hüjegyerek, valami más is beleturkált a patchekbe, nem lépek ki.

A fent vázolt probléma megoldására léteznek amúgy "patch managerek", és patch control alkalmazások, de ezek egyike sem szabványos megoldás, szóval nem várható el, hogy minden program használja is. Szóval ja. Ha csak nem feltétlen muszáj, ne akarj ilyesmit csinálni.

Yellow Dog
Tag

# Elküldve: 2021. Nov. 06. 12:00


Értem, köszönöm a részletes információt, akkor ezt a dolgot ebben a formájában elengedem.

Yellow Dog
Tag

# Elküldve: 2021. Nov. 30. 17:55 - Szerkesztve: yellowdog


Lehet ezen a kódon gyorsítani? Köszönöm

;*****************************************************************
;--- Send Data (D0 x Byte) ---
;*****************************************************************
SendByte
move.b #$ff,$bfe301 ;parallel port direction: output

SendByteLoop
btst.b #2,$bfd000 ;varakozik ha SEL = 0, TX buffer full
beq.s SendByteLoop

move.b (a1)+,d1
move.b d1,$bfe101 ;port iras
move.b #$fd,$bfd000
move.b #$ff,$bfd000 ;WRITE inp. (1. bit) High -> Low -> High
subq.l #1,d0
bne.s SendByteLoop

move.b #$00,$bfe301 ;parallel port direction: input

rts

Chain-Q
Divatamigás

# Elküldve: 2021. Nov. 30. 19:33


Hatvanason nemhiszem h. sok kulonbseg van, de 'ec020-on es sima '000-n lehet rajta gyorsitani.

1., Az $bfd000 cimet amit 2x is olvasol es irsz is, betennem egy regiszterbe, ahelyett h. 3x beinline-olnam a kodba. A cimregiszter indirekt cimzes gyorsabb mint az abszolut cimre mutato.
2., A move.b (a1)+,d1; move.b d1,$bfe101-helyett en itt ugyanezt csinalnam, az $bfe101 mint cimet betennem egy regiszterbe meg a loop elott, es akkor move.b (a1)+, (aX). Ha nincs szabad cimregiszter, ez akkor is mehet 1 lepesben, nem kell elotte d1-be huzni az erteket, szoval move.b (a1)+,$bfe101

De ez csak a hogyan irjunk gyorsabb 68k kodot gyakorlat, mert nem sok ertelme van gyorsitgatni, ha ugyis van benne egy delay loop... :)

Ezen kivul meg, itt egy blogpost arrol, hogy milyen gyorsan lehet tolni a parallel portot Amigan, gyakorlatilag ha jol ertem az ECLOCK (ami a CIA clockja) a harmadanak sebessegevel ahhoz, hogy ne legyen elveszett adat a buszon. Szkoppal kielemezve:

https://lallafa.de/blog/2015/09/amiga-parallel-port-how-fast-can-you-go/

A parallel portos etheret kutyu a PLIPBOX drivere ezt a "3E" metodust hasznalja, es kb. 240KB/sec-t er el vele.

siz
Tag

# Elküldve: 2021. Nov. 30. 19:50


Nekem egy dolog jutott eszembe (de nyilván én m68k-hoz nem értek és Charlie amúgy is adott jobb választ): ha a küldeni kívánt bájtot előbb kiolvasod a memóriából és csak _utána_ vársz a handshake-re, akkor utána már csak írni kell.

Chain-Q
Divatamigás

# Elküldve: 2021. Nov. 30. 21:19 - Szerkesztve: charlie


@Yellow Dog:
Közben meg, eszembe jutott, hogy még az előző kérdésedre amire a SetFunction-t mondtam (a fájlműveletek logolása) van egy másik megoldás is, bár ez csak részleges. OS 2.0 felett, ill. a megfelelő fájlrendszerekkel (mert hogy FS szinten van implementálva), lehet értesítést kérni az OS-től ha egy adott fájlban, vagy könyvtárban változik valami, a StartNotify/EndNotify híváspár használatával. De ez eléggé pilótavizsgás API mint mondtam, elég komplex message és signal feldolgozást kell hozzá írni, és nem is minden fájlrendszer (pl. hálózati FS-ek) támogatják teljes mértékben, vagy a különböző FS-ek eltérően viselkednek.

De ebben további segítséget nem tudok adni, mert még sosem használtam ezt az API-t (ezért is felejtkeztem el róla), és ahogy nézem a neten sincs róla sok minden. De csak a teljesség kedvéért, gondoltam említsük meg. Fingom sincs, hogy végül jó lenne-e arra amire használni akarod. De ha szivatni akarod magad, akkor esetleg belenézhetsz. :)

Yellow Dog
Tag

# Elküldve: 2021. Nov. 30. 22:25


Igen, ilyen "trükköket" vártam hozzáértőktől, amelyek a magamfajtának nem ugranak az arcába egy látszólag már sallang mentes kódból :-)

Köszönöm szépen!

Quoting: charlie
ha szivatni akarod magad, akkor esetleg belenézhetsz

Azt hiszem egyelőre nem indulok el ezen az ösvényen, találtam (szigorúan elméleti síkon) alternatív megoldást, illetve inkább kísérletezési lehetőséget...

De most elővettem ezt a bizonyos TotalCommander pluginnal megvalósított USB kapcsolaton alapuló fájltranszfer dolgot, több mint egy év kihagyást követően, ennek szeretnék (már) a végére jutni, így egyszerre csak egy, mert aztán megint minden félbe marad, mint általában szokott :-)

Yellow Dog
Tag

# Elküldve: 2021. Dec. 01. 06:20


Quoting: charlie
ugyis van benne egy delay loop

Jó esetben nem csinál semmit, de ha az Amiga gyorsabban tölti a tx buffert mint ahogyan ürül, akkor ezzel tudom megakadályozni az adatvesztést, ha megtelt akkor jön a loop késleltetés.

Chain-Q
Divatamigás

# Elküldve: 2021. Dec. 01. 12:13 - Szerkesztve: charlie


@Yellow Dog:
Azt ertem, de ha a korulotte levo kod gyorsabb lesz, akkor tobbszor is kerulhet vegrehajtasra hiszen az Amiga gyorsabban tolti a buffert. :) Szoval egyaltalan nem biztos h. vegeredmenyben barmi is gyorsul.

(Szerk: a fenti ures hozzaszolasod toroltem)

Yellow Dog
Tag

# Elküldve: 2021. Dec. 01. 18:01


Quoting: charlie
(Szerk: a fenti ures hozzaszolasod toroltem)

Köszönöm, telefonról véletlenül kétszer küldtem el...

Quoting: charlie
egyaltalan nem biztos h. vegeredmenyben barmi is gyorsul

Igen, természetesen!
Egyelőre csak próbálom megtalálni mitől nem érem el a 240kB/s sebességet, első körben a programban gondoltam kiküszöbölni a lehetséges lassító tényezőket. Ha ezzel nem járok sikerrel akkor jön a logikai analizátor, annak segítségével látható lesz mi is történik valójában, az is lehet, hogy az FT245 (kínai) klón ennyit tud, bár én első körben inkább az alap A1200 sebességét gondolom a féknek, de ez persze csak az én elméletem :-)

Yellow Dog
Tag

# Elküldve: 2021. Dec. 01. 18:09


Jut eszembe, felosztottam a CF kártyán a DH1: partíciót 4 részre: FFS 512, FFS 4096, PFS 512 és PSF 4096-ra formatálva. Érdekes, nem várt eredményt kaptam, az utóbbi háromról történő másolás a 100kB/s körüli értéket hozta míg az új DH1: FFS 512-es esetében kb. a fele volt mindössze a sebesség. Ugyanakkor a szintén FFS 512 formatált DH0: rendszerpartíció esetében szintén jött a 100kB/s... CF kártya lehet a ludas?

dh1
Mr. DTP

# Elküldve: 2021. Dec. 01. 18:29


nem eppen validal?

dino
Kék troll

# Elküldve: 2021. Dec. 01. 21:41


yellowdog
Nezd kozben a HDD ledet, ha indokolatlanul sokat vilagit, vagy midig villog, akkor biza validal.

<< 1 ... 18 . 19 . 20 . 21 . 22 . 23 . 24 .
forum.amigaspirit.hu / Fejlesztés / Általános fejlesztési kérdések
 
 

Powered by online community software miniBB™ © 2001-2021