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 . 25 .
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...

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

Powered by PHP forum software miniBB™ © 2001-2024