| 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.
|
Yellow Dog
Tag
|
# Elküldve: 2021. Dec. 02. 19:59 - Szerkesztve: yellowdog
Bekapcsolás követően is vártam pár percet, de úgy nézem, csak másolás alatt villog a LED, se azt megelőzően, sem azt követően még csak fel sem villan...
Quoting: charlie ha a korulotte levo kod gyorsabb lesz, akkor tobbszor is kerulhet vegrehajtasra hiszen az Amiga gyorsabban tolti a buffert.
Nos, úgy néz ki az Amiga gyorsabb mint a PC :-D Megcsináltam az ajánlott módosításokat, de a sebesség nem változott, így gondoltam egyet és kivettem a túlcsordulás figyelést, aminek az lett az eredménye, hogy kb. 200kB feltöltés után kifagy az egész, tehát a PC oldal lesz a problémás, illetve a TotalCommander plugin, nagy valószínűséggel. Megpróbálok felrakni egy 64 bites VisualStudio-t és a 64 bites forrást módosítani az igényeknek megfelelően, ha az sem mutat javulást, akkor ez ennyit tud, nem gyors, de vállalható sebesség, szerintem.
|
Chain-Q
Divatamigás
|
# Elküldve: 2021. Dec. 06. 11:49 - Szerkesztve: charlie
@Yellow Dog;
tehát a PC oldal lesz a problémás, illetve a TotalCommander plugin, nagy valószínűséggel.
Ez amugy dokumentalva van:
"The PORT connection through the parallel port allows to transfer data between two computers in the same room over a special parallel cable. (...) It allows a transfer rate of about 50KB/sec."
Vagyis a TC dokumentacio szerint 50KB/sec-nel tobbet ne varj. Nem ertek az analog reszehez, se siman lehet h. jeldegradacio miatt ami pl. a plipbox.device-nal mukodik sebesseg, az egy 2m-es v. akarmilyen hosszu laplink kabelen keresztul mar nem. Szoval ha te a dokumentalt 50kB/sec duplajat latod, akkor orulj. :)
|
Chain-Q
Divatamigás
|
# Elküldve: 2021. Dec. 06. 12:20
... amúgy én nem akarok beleszólni, meg nem is értek hozzá meg semmi, de nem volt neked valami ilyen problémád, hogy az átvitel közben sérül a fájl? És majd utána ha gyors lesz, kideríted hogy mitől? :)
Csak mert megnéztem most, mert a DOS/Linux verziójához a pluginnak van Pascal forráskód, és az kurvára nibble-okat küld és fogad, és nem byte-okat a parallel porton. Vagyis egy portírás az 4 bit, nem 8. Ennek megfelelően meg is van, hogy a plugin miért mond 50KB/secet, te meg miért látsz százat maximum.
Azért mert kétszer annyi adatot küldesz, mint kéne. De amúgy ugyanúgy ottvan, hogy ötven a vége. Persze ez csak spekuláció, meg mittudomén... Csak gyanúsan egybeesnek a számok.
|
MMG
Tag
|
# Elküldve: 2021. Dec. 07. 12:41 - Szerkesztve: MMG
Amiga OS 3.1 Script
Készítettem egy egyszerű script fájlt (lzx data: tömörítése).
Az elején és a végén kíírom a dátumot-időt, de gondoltam felteszem valami local változóba az indulási és befejezési dátumot és a végén majd kíírom. Esetleg kettő kivon egymásból és a futás időt is jelzem, mivel pont erre voltam kíváncsi, hogy mennyi időn keresztül fut a script.
A SET-el csak string változót sikerült felvenni, kíírni. SETENV ua. csak ugye globális.
Script futásidejének kíírására van valami megoldás?
|
GK
Tag
|
# Elküldve: 2021. Dec. 07. 14:01
Quoting: MMG Script futásidejének kíírására van valami megoldás?
https://aminet.net/package/util/shell/Timeme
|
MMG
Tag
|
# Elküldve: 2021. Dec. 07. 17:21 - Szerkesztve: MMG
Quoting: gk https://aminet.net/package/util/shell/Timeme
Köszönöm.
Sajnos ha átirányítás ">ram:out.txt" van a parancsban akkor azt a futásidővel írja felül a "timeme" ...
timeme list >ram:data.list.txt data: ALL FILES
A data.list.txt-ben nem a data: tartalma hanem a timeme futásidő szerepel...
A példa alapján futtattam...
* Examples
17/0.Ram Disk:> timeme dir ram:
IbrowseCache (dir)
ENV (dir)
Clipboards (dir)
T (dir)
disk.info
-- 0 hours, 0 minutes, 0 secs, 159234 msec --
|
GK
Tag
|
# Elküldve: 2021. Dec. 07. 23:52 - Szerkesztve: gk
És ha idézőjelekbe rakod a parancsot?
timeme "list >ram:data.list.txt data: ALL FILES"
Kipróbálni most nem tudtam.
Szerk: Ill. még egy ötlet: a listázás parancsot valami shell scriptbe is írhatod, és a shell script futtatásának idejét is tudod mérni.
|
Yellow Dog
Tag
|
# Elküldve: 2021. Dec. 12. 21:43 - Szerkesztve: yellowdog
Quoting: charlie nem volt neked valami ilyen problémád, hogy az átvitel közben sérül a fájl? És majd utána ha gyors lesz, kideríted hogy mitől?
De igen, WinUAE alatt fejlesztettem az Amiga oldali programot kényelem és egyéb okokból, viszont ott ugye nincs parallel port, csak soros amin keresztül tudok kommunikálni a Windows-al (két virtuális port segítségével) és itt jött elő az a bug(?), hogy a PC felől érkező adatokból időnként elveszett egy bájt, adás irányban nem tapasztaltam adatvesztést, illetve real vason természetesen a soros rutin ki van cserélve a parallel portot kezelővel, és ott sincs adatvesztés, megy stabilan, egyedül a sebességet kevesellettem, de úgy néz ki megvan az oka...
Quoting: charlie a TC dokumentacio szerint 50KB/sec-nel tobbet ne varj. Nem ertek az analog reszehez, se siman lehet h. jeldegradacio miatt ami pl. a plipbox.device-nal mukodik sebesseg, az egy 2m-es v. akarmilyen hosszu laplink kabelen keresztul mar nem
Jaj, nem! Elbeszéltünk egymás mellet, vagy félreértettél, nem ezt a plugint használom, hiszen nincs is már a gépeinken parallel port. Egy FT245BL chipes modulra épül a kapcsolás, és USB-n keresztül csatlakozik a PC-hez, ott egy soros portot emulál, melyhez a Serial plugin version 2.0 for Total Commander-t használom pár módosítással, ennek a forrása van meg C-ben, ehhez kértem anno segítséget ;-) Mivel erre gyanakodtam eddig, így kipróbáltam a csomagban megtalálható a PC-n futó szerver programmal mit tud a plugin, hát igen, hasít rendesen :-( Tehát kiesett ez is, már csak a hardverben lehetett keresni a problémát, mivel a modult nem tudom (egyelőre) mással helyettesíteni, így a Fast RAM bővítőmön található CPLD-ben megcsináltam a 8520 parallel port funkcióját, annyi különbséggel, hogy nincs E clock korlát. Így kb. 200kB/s lett az átviteli sebesség, a modul leírásában egyébként a következőt írják: "Transfer Data rate to 300 Kilobyte / Sec - VCP Drivers", eredeti esetén, ez meg egy kínai utángyártott (gondolom). Tehát az eredeti 8520-nál kell még körülnézni, hol csúszik el az ütem, aminek eredménye a sebesség feleződése, rá kell néznem logikai analizátorral, talán azzal kiderül...
|
