Szerző |
Üzenet |
Yellow Dog
Tag
|
# Elküldve: 2022. Jan. 10. 16:28
Szeretném megkérdezni, tavasz magasságában volna valakinek egy elfekvőben lévő A1200-ba való gyorsító kártyája amelyet 1-2 hónapra kölcsön tudna adni fejlesztés ügyén? Természetesen mindkét irányban állom a postaköltséget és nem a kártya lenne a fejlesztés tárgya, sajnos az alap A1200-ból kifogyott a szufla, nem tudok gyorsabb CPU sebesség híján tovább lépni. A nemleges választ is elfogadom természetesen:-) Köszönöm
|
Yellow Dog
Tag
|
# Elküldve: 2022. Már. 10. 19:30 - Szerkesztve: yellowdog
Nem amiatt írok, de akkor azért rákérdeznék először (ismét), tehát egy hétvégére volna szükségem valamilyen gyorsító kártyára, kölcsönbe, természetesen minden költség állok, volna aki ennyi időre megválna esetleg egyikétől?
68000 (68020) esetében van olyan utasítás vagyis lehetőség, hogy egy 32 bites regiszter adott bájtját tudom move-olni, mondjuk egy index segítségével kiválasztva, hogy a négyből melyiket? A leléptetés vagy eltolás nem jó... Köszönöm
|
Chain-Q
Divatamigás
|
# Elküldve: 2022. Már. 10. 22:49 - Szerkesztve: charlie
Egy lépésben nem lehet, szerintem, de két lépéses megoldás van:
BFEXTU dX{startbit:8},dY MOVE.B dY,<celcim>
A BFEXTU forrása lehet memória is, de a célja csak másik regiszter lehet. A startbit és a hossz (itt:8) jöhet regiszterből is, nem csak konstans lehet. A BFEXTU mindig a teljes regisztereken dolgozik, tehát a teljes dY-t felülírja.
Ennél lehet hogy lehet gyorsabbat, de ahhoz tudni kéne h. ténylegesen mit akarsz csinálni mert van egy olyan megérzésem, hogy ez csak egy részprobléma, amivel valamit meg akarsz oldani ami lehet hogy fel sem kéne hogy merüljön. :) (Pl. endian konverzió jut így hirtelen eszembe?)
|
siz
Tag
|
# Elküldve: 2022. Már. 11. 08:44 - Szerkesztve: siz
Én arra tippelek, hogy valami bájt alapú adatátvitelt akarna gyorsítani azzal, hogy longokat olvas a memóriából és utána bájtokat ír a perifériára. Elsőre az a nagyon béne tipp jutott eszembe, hogy tárolja le memóriában a longot, aztán bájtonként azt olvas ki belőle, amit akar. Viszont ha tényleg a gyorsítás a szempont, akkor ezzel pont jó sokat lassítana az egészen.
Szerk: egy ACA 1231/42-t tudnék felajánlani tesztelésre, de egyrészt nem annyira szívesen bíznám a magyar postára, másrészt meg (mivel még mindig nem sikerült a költözést befejeznem - most éppen lakásfelújítás van), így bizonytalan ideig nem férek hozzá.
|
kszgd
Tag
|
# Elküldve: 2022. Már. 11. 10:21
Ha ez a probléma, hogy big-endian longokat olvas és byte-onként írná ki őket valahova és pont fordítva van a regiszterben, mint ahogy kiírná, akkor nem léptetni vagy eltolni kell, hanem forgatni, felfele, 8 bitenként, akkor megfordul a kiírás sorrendje:
moveq #8,d1 move.l (a0)+,d0 rol.l d1,d0 move.b d0,(a1) rol.l d1,d0 move.b d0,(a1) rol.l d1,d0 move.b d0,(a1) rol.l d1,d0 move.b d0,(a1)
Arra nincs lehetőség, hogy egy lépésből egy tetszőleges byte-ot mozgasson valahova egy regiszterből.
|
Chain-Q
Divatamigás
|
# Elküldve: 2022. Már. 11. 10:47 - Szerkesztve: charlie
@siz Nem biztos (sőt elég biztos, hogy nem), hogy a LONG beolvasása regiszterbe egy lépésben, és aztán a kiirogatása bájtonként lényegesen gyorsabb, ha egyáltalán. Elképzelhető, hogy egy EC020-on véletlenül igen, de szerintem harmincason már nem, mert ott már van data cache, ezért úgyis egy komplett 16 byteos cache line töltődik be a RAM-ból, amikor behúzol bármekkora adatot, és onnantól már a byte olvasások is csak a cache-ig mennek, az írások meg úgyis cacheletlen területre (I/O) szóval az lesz a lassú, a loop meg úgyis befér az instruction cache-be (ez már huszason is).
És az a tapasztalat, hogy még hatvanason is sokszor gyorsabb a szimpla byte copy, mint ha közben tilitolizni kell a bitekkel, pedig ott még barrel shifter is van. Arról nem is beszélve, hogyha a parallel portra akarod irorgatni a biteket, akkor ott úgyis a parallel port vezérlő és/vagy az alaplap buszsebessége diktál, a kommunikációban meg sokszor a két fél szinkronja többet számít.
De Yellow Dog úgyse hisz nekem, mert ő oldschool assembly programozó, aki tudja h. minden, bármilyen körülmények között ötször gyorsabb lesz, ha két ciklust megspórol valahogy egy copyloopban... :)
|
Yellow Dog
Tag
|
# Elküldve: 2022. Már. 14. 20:05 - Szerkesztve: yellowdog
Köszönöm a hozzászólásokat és tanácsokat, igen még mindig a "parallel - USB" átvitelről van szó. Az első verzió tökéletesen működik, de nem gyors a maga kb. 100kB/s sebességével:
Ezért úgy döntöttem, jöhet az "újratervezés" a cél az adott számítógép hardver (számítási teljesítmény) adta maximumot kihozni az adapterből.
Átnéztem hasonló, parallel portra adaptált projektek forrását és kapcsolását, pl.: Ferix USB pendrive adapter Amiga SDBox illetve Amiga PartoSPI adapter és nem utolsó sorban a Plipbox fejlesztőjének "Amiga Parallel Port: How fast can you go?" leírását. A strobe jel használata kézenfekvő, de ahol használatban van, ott is csak az adás irány preferált, vétel esetén port bit ki-be kapcsolással történik az RD jel előállítása... a max. elérhető sebességet ez esetben a CIA hardver kb. 235kB/s-ban korlátozza: "3E transfer" (by Lallafa)
Az általam használt FT245 modul tulajdonsága, hogy a "TXE" kimeneten jelzi, mikor kész a küldendő adat fogadására, magyarán a strobe jelet követően le kell kérdezni a állapotát (pontosítása később), ha nem "H" akkor várakozó ciklust kell beiktatni, ezzel kb. 7uS-ra adódik az írás ciklus ideje amely kb. 141kB/s elméleti sebességet ad:
ODD CIA - port B írás EVEN CIA - port A olvasás
Nem ismerem a fentebb megnevezett chip felépítését (32bites?), de több próba eredményeként kijelenthető, hogy elegendő minden 4. írást követően lekérdezni a TXE állapotát, így az első három bájt esetében 5 helyett csak 3 db E ciklusra van szükség, így 4 bájt elküldése 28,3 uS helyett 19.75uS ideig tart, tehát kb. 202kB/s az elméleti sebesség érhető el a strobe jel alkalmazásával, adás irányban...
Kézenfekvő volna a késleltetés tst.b (a4) elhagyása, port írás majd btst.b #$02,(a4), ahol a4=$bfd000, ebben az esetben elérhető a max. 235kB/s sebesség, viszont ebben az esetben a teszt az aktuális strobe jel előtt történik, tehát akkor is elküldésre kerül egy további bájt, ha arra az adapter nincs adáskész állapotban...
Fentiekből következik, hogy a strobe jel használata elsőre jó ötletnek tűnik, de megvannak a korlátai.
----------------
A továbblépéshez egy (szoftveres) szinkronjelre van szükségünk, jelen esetben ez a POUT: move.b (a6)+,(a5) move.b #$fd,(a4) ; POUT HIGH -> LOW move.b #$ff,(a4) ; POUT LOW -> HIGH
txe: btst.b #$02,(a4) beq.s txe
Az elméleti sebesség (5 E ciklus/bájt): 142kB/s
A fenti ábrán látszik, hogy a CIA elérés szoftveresen nem ad további számottevő lehetőséget a sebesség növelése végett, így a következő lépés az egy szinkron jel egy írással történő megvalósítása 2db flip-flop segítségével: move.b (a6)+,(a5) move.b #$fd,(a4)
txe1: btst.b #$02,(a4) beq.s txe1
move.b (a6)+,(a5) move.b #$ff,(a4)
txe2: btst.b #$02,(a4) beq.s txe2
Az elméleti sebesség (4 E ciklus/bájt): 177kB/s
Fentebb már említettem, az USB chip TXE jelét elegendő 4 bájtonként ellenőrizni, így 4 bájt küldése 18.33uS, amelyből 218kB/s sebesség adódik. Tehát az aktuális loop az alábbi: move.b (a6)+,(a5) move.b #$fd,(a4)
move.b (a6)+,(a5) move.b #$ff,(a4)
move.b (a6)+,(a5) move.b #$fd,(a4)
move.b (a6)+,(a5) move.b #$ff,(a4)
txe: btst.b #$02,(a4) beq.s txe
A fenti ábrán láthatjuk, hogy minden írási ciklusban van még egy "rés", emiatt kértem a tanácsotok, van-e lehetőség egy alap A1200 (+FAST RAM) esetében elérni az lenti képen látható állapotot, és vele a 284kB/s sebességet? A processzor leírása alapján a move.b (a6)+,(a5) végrehajtásához 12 ciklus szükséges, míg pl. a move.b d0,(a5) esetében elegendő 8, így már belefér az utasítás végrehajtása egy E ciklusba amint az az alábbi képen is látszik. Ez alapján jött az ötletem és a kérdésem, van-e lehetőség és ha igen, segít-e, ha egyben 4 bájtot be tudnék olvastatni és azt követően regiszterből történne a portba írás...?
Quoting: charlie Yellow Dog úgyse hisz nekem, mert ő oldschool assembly programozó, aki tudja h. minden, bármilyen körülmények között ötször gyorsabb lesz, ha két ciklust megspórol valahogy egy copyloopban... :) Nos, itt úgy tűnik, számít(hat) néhány órajel ciklus is, ezért is kértem a ti tanácsotokat illetve segítségeteket, mert bizony hiszek neked/nektek ;-)
Quoting: siz arra tippelek, hogy valami bájt alapú adatátvitelt akarna gyorsítani azzal, hogy longokat olvas a memóriából és utána bájtokat ír a perifériára Igen :-)
Quoting: siz egy ACA 1231/42-t tudnék felajánlani tesztelésre, de egyrészt nem annyira szívesen bíznám a magyar postára, másrészt meg... Azért köszönöm :-) Ahogyan az valószínűsíthető, egy kevés támogatás akár egy 020-as gyorsító, de gondolom egy 030-as kártya már biztosan adna annyi pluszt, hogy elérhető a fentebb említett 284kB/s, ezt szerettem volna élőben letesztelni.
|
Yellow Dog
Tag
|
# Elküldve: 2022. Már. 18. 12:01 - Szerkesztve: yellowdog
Szeretném megkérdezni használj ismeri valaki a VS Code-ot és hozzá az Amiga Assembly for Visual Studio Code bővítményt? Elvagyok a Notepad++ és vasm párossal, de kíváncsiságból feltelepítettem. A fordítás közben az egyébként az exec/exec_lib.i-ben található CALLEXEC makrót ismeretlen mnemonik hibával megugatja, mindenütt ahol használatban van. Volna ötlet, mit kell (még) beállítani? Köszönöm
|
MMG
Tag
|
# Elküldve: 2022. Már. 29. 00:16
Quoting: yellowdog egy hétvégére volna szükségem valamilyen gyorsító kártyára, kölcsönbe, természetesen minden költség állok, volna aki ennyi időre megválna esetleg egyikétől?
Amennyiben SIZ nem találja meg a kártyát, akkor tudok adni egy Blizzard 040-es kártyát. Ha kell akkor az Amiga 1200-as géppel együtt. (Nem egyszerű kivenni a gépből mert van benne egy tartó ami szintben tartja a kártyát, hogy ne a csatlakozót húzza le. Illetve kell a gépnek egy kis emelés, mert a Blizzard kártyán van egy ventilátor.)
Viszont a postázás - bármilyen formában - kizárt! Jössz, elviszed, használod, visszahozod.
Három várost tudok felajánlani átvételre: Halásztelek, Gödöllő, Gyál 4-5 hétig maradhat nálad a gép és a kártya.
(Amúgy január végén már írtam egyszer, hogy tudok adni egy kártyát de azt a hozzászólást nem is látom... ???)
|
Chain-Q
Divatamigás
|
# Elküldve: 2022. Már. 29. 18:44
Quoting: MMG (Amúgy január végén már írtam egyszer, hogy tudok adni egy kártyát de azt a hozzászólást nem is látom... ???) Valamikor volt akkoriban egy szerver-botlas, lehet annak esett pont aldozatul, lehet h. az adatbazis javitast/rebootot 1-2 friss hozzaszolas nem elte tul, szorrika vagyok.
|
Yellow Dog
Tag
|
# Elküldve: 2022. Már. 31. 10:30
Quoting: charlie 1-2 friss hozzaszolas nem elte tul, Igen, biztosan nem olvastam MMG ajánlatát, akkor az valószínűleg tényleg elveszett.
Quoting: MMG tudok adni egy Blizzard 040-es kártyát. Ha kell akkor az Amiga 1200-as géppel együtt Köszönöm szépen a felajánlást! Sajnos elég messze lakunk egymástól, (én úgy általában mindenkitől, Sopron) és nem nagyon járok arra felé, a posta dolgot pedig megértem, még egy kártya csak-csak azért is gondoltam, azt egyszerűbb lehet kérni, de a gép az egyértelműen nem postára való. A beépített kártya meg szintén olyan dolog, hogy ha egyszer jó, akkor az ember nem nagyon szedi ki.
Azt hiszem marad az a verzió, hogy elkészítek a már jó működő verzióból egy "készterméket" gyártatott nyák, doboz, ahogyan kell és inkább én küldöm el tesztre majd valaki(k)nek.
Az adás iránnyal illetve optimalizálásával megvagyok, az alábbi eredményeket kaptam alap A1200 (+4MB Fast RAM) esetén a fentebb már említett "4 bájtonként 1 ellenőrzés" módban: 4 bájt 18,3uS -> 1 bájt 4,57uS amelyből az elméleti sebesség 218kByte/s-ra adódik. 18,3uS=13E, ha feltételezem, hogy gyorsítókártya esetén nincs üres E clock, akkor 4 bájt küldése 9E (12,6uS) alatt megtörténik -> 1 bájt 3,15uS ez esetben 317kByte/s az elérhető sebesség.
Fenti érték természetesen elméleti, mivel pl. a TC plugin protokol esetében kb. 0,73 szorzóval kell számolni, tehát nálam most 160kB/s az Amiga -> PC irányú másolási sebesség, amivel én egyébként meg vagyok elégedve :-)
A vételi irány optimalizálása még hátra van...
-------------------------------------------------------------------
Időközben ránéztem a PCMCIA portra is, ott ugye 16 bit elérhető, ha fenti adapterrel elkészülök, azt hiszem teszek egy próbát ezzel a csatoló felülettel is...
|
Chain-Q
Divatamigás
|
# Elküldve: 2022. Már. 31. 11:14 - Szerkesztve: charlie
A PCMCIA portra nem parallel port-szeru atvitelt kell csinalni, hanem halozatost. Nem TCP/IP-t hanem valami layer 2-re epitot, ami kozvetlenul beszel a SANA-II driverhez. Azzal akkor megvannak a Zorro kartyak is egy fust alatt... Nemtom a TC tud-e valami ilyesmi atviteli protokollt, de en mar gondolkodtam ilyen egyszeru Amigas filesharing szoftveren LAN-ra, ami nem akar titkositast meg hiperszekuritit csinalni mint az SMB protokoll, meg nem is kell hozza TCP/IP, ezert barmin megy ami be bir tolteni egy SANA-II drivert.
Tudom, ott az Envoy, ami eleg faszan mukodik amugy ket Amiga kozott, de ott nem ismerem a reszleteket, mennyire bonyi es up 2 date a protokoll (pl. tud-e egyaltalan 31 karakternel hosszabb fileneveket?) meg ilyesmi, es hat ha pl. "modern" Windowsrol akarsz masolgatni, akkor nem biztos h. egy 30 eves amigas wareval akarsz szivni.
|
Yellow Dog
Tag
|
# Elküldve: 2022. Ápr. 01. 18:30
Quoting: charlie PCMCIA portra nem parallel port-szeru atvitelt kell csinalni, hanem halozatost Értem, de én jelenleg az FT245 chipes adaptert használom, ez egy soros portként jelenik meg PC oldalon, nem csak Windows, de gondolom Linux illetve Mac esetében is, ahhoz, hogy ezen átjöjjön a hálózat, kellene valami a túloldalon...
Quoting: charlie Nemtom a TC tud-e valami ilyesmi atviteli protokollt TC-hez elkészült pluginek, én az itt található "Serial 2.0" módosított verzióját használom az USB adapterhez, soros porton keresztül.
Quoting: charlie "modern" Windowsrol akarsz masolgatni Nem feltétlenül, bár nekem ez adatott meg, de ha lenne rá igény és valaki vetne pár pillantást a plugin forrására, gondolom nem lenne nagy feladat átültetni Linuxra illetve esetleg iOS-re is, akár.
|
Yellow Dog
Tag
|
# Elküldve: 2022. Máj. 01. 21:15
Az alábbi lista egy DIR parancs eredménye, a könyvtárban 8 bejegyzés található:
Patch installed. "NET0" "dir" LOCATE_OBJECT 100194D7,"dir",FFFFFFFE -> 00000000,OBJECT_NOT_FOUND "NET0" "dir" LOCATE_OBJECT 100194D7,"",FFFFFFFE -> 1001DCA5,40063AC4 "NET0" "dir" LOCATE_OBJECT 100194D7,"",FFFFFFFE -> 1001DCED,40063ABC "NET0" "dir" EXAMINE_OBJECT 1001DCED,1001954E -> FFFFFFFF,OK "NET0" "dir" FREE_LOCK 1001DCED -> FFFFFFFF,40000010 "NET0" "dir" LOCATE_OBJECT 100194D7,"",FFFFFFFE -> 1001DD33,40063AB0 "NET0" "dir" EXAMINE_OBJECT 1001DD33,1001DCF0 -> FFFFFFFF,OK "NET0" "dir" EXAMINE_NEXT 1001DD33,1001DCF0 -> FFFFFFFF,OK "NET0" "dir" COPY_DIR 1001DD33 -> 1001DD7B,OK "NET0" "dir" EXAMINE_NEXT 1001DD33,1001DCF0 -> FFFFFFFF,OK "NET0" "dir" EXAMINE_NEXT 1001DD33,1001DCF0 -> FFFFFFFF,OK "NET0" "dir" EXAMINE_NEXT 1001DD33,1001DCF0 -> FFFFFFFF,OK "NET0" "dir" EXAMINE_NEXT 1001DD33,1001DCF0 -> FFFFFFFF,OK "NET0" "dir" EXAMINE_NEXT 1001DD33,1001DCF0 -> FFFFFFFF,OK "NET0" "dir" EXAMINE_NEXT 1001DD33,1001DCF0 -> FFFFFFFF,OK "NET0" "dir" EXAMINE_NEXT 1001DD33,1001DCF0 -> FFFFFFFF,OK "NET0" "dir" EXAMINE_NEXT 1001DD33,1001DCF0 -> 00000000,NO_MORE_ENTRIES "NET0" "dir" FREE_LOCK 1001DD33 -> FFFFFFFF,40000010 "NET0" "dir" FREE_LOCK 1001DD7B -> FFFFFFFF,40000010 "NET0" "dir" FREE_LOCK 1001DCA5 -> FFFFFFFF,40000010 Patch deinstalled.
Amit nem teljesen értek, mi célt szolgál a 2. sor illetve a 3-5-ig mit keres amit nem talál? Esetleg ezekről a dolgokról elérhető leírás? Köszönöm
|
Chain-Q
Divatamigás
|
# Elküldve: 2022. Máj. 02. 00:53
Ennyi infóból csak tippelni tudok, de a 2-3 sorbana LOCATE_OBJECT az saccra az egy dupla CurrentDir() hívás, hogy megkapja az aktuális könyvtárra mutató lockot?
Utána meg gondolom lekéri a könyvtár FileInfoBlock-ját a következő EXAMINE_OBJECT-tel, de csak tippelni tudok, hogy ez minek kell neki (symlink support, talán? vagy megnézni hogy a lock az valóban könyvtár-e?), mielőtt nekiállna listázni a könyvtárat.
Te vagy az assembly programozó szedd szét a dir-t, és tudd meg. :P
|
Yellow Dog
Tag
|
# Elküldve: 2022. Máj. 10. 20:32
Köszönöm a tanácsot, igazából nincs jelentősége, csak érdekelt volna a miértje.
|
dino
Kék troll
|
# Elküldve: 2022. Jún. 18. 19:30
Magyar translator.library letezik valahol? Merthogy milyen jo lenne nekem egy ilyen...:)
|
kszgd
Tag
|
# Elküldve: 2022. Jún. 18. 21:04
A translator.library-nak nincs nyelvfüggő verziója. Rá épülnek a nyelvesítések. Te vagy magyar locale-et keresel, ami itt van: http://aminet.net/package/util/sys/Magyar vagy magyar accent file-okat, amik meg itt vannak: http://aminet.net/package/util/libs/LSHunAccent http://aminet.net/package/util/libs/LSHunAccent211
|
dino
Kék troll
|
# Elküldve: 2022. Jún. 18. 22:28
kszgd Koszi a segitseget, de nem erre gondoltam. A say voice t szeretnem, hogy magyar akcentussal beszeljen. Lehet nem is letezik ilyen magyar translator lib.
|
kszgd
Tag
|
# Elküldve: 2022. Jún. 18. 23:03
De, erre gondoltál.
Még egyszer: a translator.library-ból csak egy van, nem azt nyelvesítik. Neked accent file kell, ha azt akarod, hogy magyar akcentussal beszéljen a Say. Ott van fent a két link, letöltöd azt, amelyik neked kell (a translator.library-d verziójától függően) és becopyzod a "LOCALE:Accents" fiókba, utána a Prefs-ben a Locale-ben beállítod, hogy a "magyar.accent" legyen az akcentus és máris magyar kiejtése lesz az egész rendszernek. Még a "Copy szoveg.txt SPEAK:"-nak is.
|
dino
Kék troll
|
# Elküldve: 2022. Jún. 19. 06:03
kszgd Miket tudsz Te? Nagyon koszi, delutan kiprobalom...:)
|
Yellow Dog
Tag
|
# Elküldve: 2024. Már. 18. 12:31
Ha valaki ránézne ERRE, lefordítaná és leírná mivel és milyen opciókkal sikerült neki, megköszönném előre is :-)
|
Chain-Q
Divatamigás
|
# Elküldve: 2024. Már. 22. 18:02 - Szerkesztve: charlie
@Yellow Dog: Régebbi device kódot nem találtál amivel szopni lehet? :)
De lefordul ez bármivel, főleg ha az ember előbb kijavítja a kódban lévő bugokat. :P
A 850. sor környékén vagy egy bset.b meg egy btst.b, amit bset.l-re meg btst.l-re kell cserélni, mert regiszteren nem lehet ugye byte méretben bitműveletet végezni, csak memórián. De mivel van amelyik - főleg régebbi - assembler ezt leszarja, ezért gondolom benne maradt.
Szerk: Az egyértelműség kedvéért a patchet felraktam ide: http://charlie.amigaspirit.hu/temp/private/8n1.s.patch
Utána kell pl. az NDK Aminetről: https://aminet.net/package/dev/misc/NDK3.2 (Disclaimer: ez most az egyszerűség kedvéért, normál esetben a bottal se lökném odébb a Hyperion NDK-t, de ez most a rókamama esete, és ha már megígértem a gyerekeknek, ugye...)
Ezután kell még egy MOT szintaxisra fordított vasm, meg egy vlink, és azután kb:
./vasmm68k_mot -m68010 -I ndk/include_i 8n1.s -Fhunk -o 8n1.o
Ennek a végeredménye egy 5492 byte-os 8n1.o fáj lesz.
Amit aztán pl. az amiga.lib-bel kell linkelni:
./vlink -s -b amigaos ndk/lib/amiga.lib 8n1.o -o 8n1.device.new
Itt 8n1.device.new néven jön majd létre az új futtatható fájlod.
Hogy megy-e azt nem teszteltem, 64 byte-tal nagyobb mint az eredeti, ami akármi miatt is lehet.
De lefordult. :) Jó szórakozást.
|
Yellow Dog
Tag
|
# Elküldve: 2024. Már. 26. 10:17
Quoting: charlie Régebbi device kódot nem találtál amivel szopni lehet? :) A dolog úgy indult, hogy parallel porton keresztüli fájltranszfer Amiga és PC között FT245-re épülő USB adapterrel, ahol is Amiga a szerver és TotalCommander a kliens. Működik, jó is, de nem az igazi, a PC (Windows) előtt kell ülni... ráadásul mindig is foglalkoztatott egy korrektebb, mountolható device megoldás. A Ferix USB adapter (asm) forrása adta az ötletet illetve lökést, hogy elkezdjek érdemben foglalkozni a dologgal, sikerült A68k-val lefordítani majd módosítani és a RAM-ban szimulálni egy disk-et amely az device-on keresztül elérhető (írható/olvasható). Tudom, nem egy nagy truváj, de az elmélet igazolására jó volt. Gondoltam innen már sínen vagyok, így félre is tettem, az átviteli protokoll következett, a ProNET-et tudtam beüzemelni serial.device segítségével, így virtual porton összekötöttem két WinUAE-t és serial port monitor segítségével elkezdtem visszafejteni (a DOS fylesystem dolgokról itt is értekeztünk pár bejegyzéssel feljebb) majd a szerver oldali WinUAE helyett Windowsból emuláltam azt. Bevallom, elég nyögvenyelősen ment, egyfelől időhiány másfelől nem volt egy érdekfeszítő az egész, felét nem értettem, mit miért, a saját handler írása pedig nem járható út, be kellett látnom (a device-al ellentétben erről szinte semmi elérhető info nincs), így végül félbe lett hagyva és félre lett téve. Később jött egy kis hardver, STM32-vel próbáltam az általánosságban elfogadott (kb. 250kB/s) érték feletti sebességet elérni, hogy ténylegesen legyen motivációm az adapter fejlesztéséhez, az eredmények szerencsére kecsegtetőek (erről is értekeztem már itt) de egyéb dolgok miatt ismét elült a fejlesztés. A TC verzió tűnt egyértelműen a járható útnak, de azért keresgéltem, hátha... így akadtam szintén Amineten a (parallel portos) PC2AMIGA programra, amely elég régi szerzet, így MSDOS-os illetve nincs hozzá forrás, csak a futtatható állományok. Mivel akkor még úgy gondoltam a driver megírása már nem akadály, próbaképpen összeállítottam egy tesztkörnyezetet, DOSBox-X és WinUAE virtuális portokon keresztül összekötve, pc2am-handler valamint serial.device illetve artser.device segítségével is sikerült működésre bírnom. Csak megjegyzem, DOSBox alatt érdekes módon a hosszú fájlnév opció nem működik, konkrétan kifagy... A protokoll lényegesen egyszerűbb, illetve értelmezhetőbb, így belevágtam a visszafejtésébe, úgy látom/remélem nem lesz vele gond. Közben elővettem a már módosított device-t illetve forrását, amely ránézésre az eredeti skeleton ramdisk device alapjain nyugszik. Mivel trackdisk, a pendrive adaptáláshoz megfelelő is, nekem viszont ebből csak a handlerrel való kommunikációra lenne szükségem, az érkezett adatcsomagokat kiteszem a soros portra az onnan érkezőket pedig megkapja a handler (nyilván a végleges verzióban már a parallel port kezelés kerülne be a soros helyett). Addig sikerült eljutnom, hogy az első RdWrt (CMD_WRITE) meghívásakor az IO_DATA tartalmazza a handler felől érkező első csomagot, tehát ezt küldöm egyenesen a soros portra, viszont nem találom a módját, hogyan tudom nyugtázni, hogy átvette azt a driver, így pedig még ötször CMD_WRITE érkezik és természetesen leáll a folyamat. Probálkoztam a ReplyMsg-vel illetve PutMsg-vel is, elvileg a kapott csomagot kell visszaküldeni, de nem jártam sikerrel, bármelyik alkalmazásakor "Software failure" lett az eredmény :-( Mivel serial.device-al működik a dolog, és sem az eredeti serial.device, sem az artser.device, csak a 8n1 forrása elérhető, ezért esett utóbbira a választásom. Röviden ennyi lenne a kérdésedre a válasz... :-)
Quoting: charlie De lefordult. :) Jó szórakozást. Köszönöm szépen! :-)
|
Yellow Dog
Tag
|
# Elküldve: 2024. Már. 26. 12:08 - Szerkesztve: yellowdog
Quoting: charlie Ennek a végeredménye egy 5492 byte-os 8n1.o fáj lesz. 5496 lett :-) illetve kaptam négy warning üzenetet:
warning 62: imported symbol <_LVOAlert> was not referenced warning 62: imported symbol <_LVOSetIntVector> was not referenced warning 62: imported symbol <_LVOAbortIO> was not referenced warning 62: imported symbol <_AbsExecBase> was not referenced
Ezektől függetlenül működik a lefordított 8n1.device, köszönöm a segítséget! :-)
|
Chain-Q
Divatamigás
|
# Elküldve: 2024. Már. 26. 14:59
A warningokat a megfelelő XREF-ek eltávolításával orvosolhatod. Nálam is megvoltak.
|
Yellow Dog
Tag
|
# Elküldve: 2024. Már. 27. 14:25
Igen, mondjuk utána nézettem volna én is, bocs...
|
Yellow Dog
Tag
|
# Elküldve: 2024. Máj. 10. 15:01 - Szerkesztve: yellowdog
ACTION_FINDINPUT funkcióját próbálom értelmezni, de bevallom, nem teljesen világos, google fordító sem annyira a barátom...
http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node005F.html oldalról az érintett rész:
"These actions work based on a FileHandle which is filled in by one of the three forms of opens:
ACTION_FINDINPUT 1005 Open(..., MODE_OLDFILE) ACTION_FINDOUTPUT 1006 Open(..., MODE_NEWFILE) ACTION_FINDUPDATE 1004 Open(..., MODE_READWRITE) ARG1: BPTR FileHandle to fill in ARG2: LOCK Lock on directory that ARG3 is relative to ARG3: BSTR Name of file to be opened (relative to ARG1)
RES1: BOOL Success/Failure (DOSTRUE/DOSFALSE) RES2: CODE Failure code if RES1 is DOSFALSE
All three actions use the lock (ARG2) as a base directory location from which to open the file. If this lock is NULL, then the file name (ARG3) is relative to the root of the current volume. Because of this, file names are not limited to a single file name but instead can include a volume name (followed by a colon) and multiple slashes allowing the file system to fully resolve the name. This eliminates the need for AmigaDOS or the application to parse names before sending them to the file system. Note that the lock in ARG2 must be associated with the file system in question. It is illegal to use a lock from another file system.
The calling program owns the file handle (ARG1). The program must initialize the file handle before trying to open anything (in the case of a call to Open(), AmigaDOS allocates the file handle automatically and then frees it in Close() ). All fields must be zero except the fh_Pos and fh_End fields which should be set to -1. The Open() function fills in the fh_Type field with a pointer to the MsgPort of the handler process. Lastly, the handler must initialize fh_Arg1 with something that allows the handler to uniquely locate the object being opened (normally a file). This value is implementation specific. This field is passed to the READ/WRITE/SEEK/ END/TRUNCATE operations and not the file handle itself.
FINDINPUT and FINDUPDATE are similar in that they only succeed if the file already exists. FINDINPUT will open with a shared lock while FINDUPDATE will open it with a shared lock but if the file doesn't exist, FINDUPDATE will create the file. FINDOUTPUT will always open the file (deleting any existing one) with an exclusive lock."
Általában az ACTION_EXAMINE_OBJECT után érkezik, de nem minden esetben, így nem igazán találom benne a logikát illetve miért van rá szükség, az Examine visszatérő értéke is egyértelműen mutatja, hogy létezik-e a fájl illetve mappa.
Köszönöm a segítséget, ötletet előre is.
|
Chain-Q
Divatamigás
|
# Elküldve: 2024. Máj. 10. 17:40 - Szerkesztve: charlie
Ez a 3 packet nyitja meg a fájlt a filesystem szintjén.
Az ACTION_FINDINPUT olvasásra (MODE_OLDFILE paraméter jelzi az Open() hívásban a DOS szintjén), az ACTION_FINDOUTPUT írásra (MODE_NEWFILE, mint fent), az ACTION_FINDUPDATE pedig írás-olvasásra (MODE_READWRITE, szintén mint fent).
Azért kapod valszeg ACTION_EXAMINE_OBJECT után, mert jónéhány kód az Open() előtt megnézi, hogy egyáltalán van-e ilyen fájl, és mik a paraméterei, típusa, stb...
Lefordítsam a technikai részleteket is? A "find" szó az ACTION-ök nevében elég félrevezető, nem úgy tűnik, mintha a "kereséshez" lenne köze, a leírások alapján amit találok. Maximum annyiban, hogy az FS-ben akkor kell megkeresned - és aztán megnyitnod - a fájlt, amikor ezeket kapod.
|
Yellow Dog
Tag
|
# Elküldve: 2024. Máj. 10. 22:32 - Szerkesztve: yellowdog
Köszönöm, így érthető. Annyi furcsaság van a dologban, hogy a root mappa és a közvetlen alatta lévő listázása esetén nincs FINDINPUT action, az csak a következő szinten jelenik meg és a harmadiktól lefelé lesz állandóan ugyanaz a metódus. Emiatt is nem tudta értelmezni a szerepét. Persze az is lehet, hogy ez a handler sajátossága, nem tudom...
|