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 ... 9 . 10 . 11 . 12 . 13 . 14 . 15 . 16 . 17 . 18 . 19 ... 24 . 25 . >>
Szerző Üzenet
ratman
Kék troll

# Elküldve: 2017. Aug. 04. 10:55


@Bszili: No problem, legyen, de ha már ez twice as amazing lesz, akkor talán elférne a többi "észbontóan kurvajó, meg működik, de senkinek sem mutatjuk meg" kompatibilitási izé is benne. :D

Jelen állapotában ez olyan meh. :)

*énkérekelnézést*

Yellow Dog
Tag

# Elküldve: 2017. Aug. 04. 10:59


Quoting: ratman
esetleg valami UN*X-szerű izé is bútoljon rajta

Arra jó egy PC is, nem? Manapság mire jó egy Unix szerű rencccer?

ratman
Kék troll

# Elküldve: 2017. Aug. 04. 16:36


Pontosan, de ha bútol rajta egy unigz, akkor azt jelenti, hogy mindent tud, amit egy "nagy" 68k-nak tudnia kell. :) Leginkább van benne MMU. :) Ééééérted.

Egyébként fél giga rammal már akármire is elég lehet egy ilyen.

Yellow Dog
Tag

# Elküldve: 2017. Aug. 04. 17:01


Aha... :-)

Chain-Q
Divatamigás

# Elküldve: 2017. Aug. 04. 18:00


En mondjuk forditot tesztelek a Lyunigz-zal 68k-n, mert Amigan eleg hendikeppes a debugolas, foleg nagy es komplex szoftvereke. NetBSD-n (vagy Slimuxon) meg A., nem fagy a gep a bugos szoftvertol mert van memoriavedelem B., van GDB es egyeb debug cuccok amivel egy egymillio soros szoftverben mint az FPC is lehet megorules nelkul bugot keresni. Es itt most CPU specifikus dolgokra gondolok, amik aztan kesobb Amigan is hasznosak ill. nem lehet mas platformon debugolni csak 68k-n.

Ilyenek.

Chain-Q
Divatamigás

# Elküldve: 2017. Aug. 05. 07:11


Amugy sem kell az anti-Unix elitizmus, mivel az AmigaOS-t is Sun Unix gepeken fejlesztettek anno, mielott a vas kesz lett volna, es sokaig csak SunOS-en lehetett leforditani, egeszen a C= utani idokig! Eloszor a 90-s evekben pucoltak ki a kodot, hogy leforduljon az AmigaOS Amigan is...

mc68k
Tag

# Elküldve: 2017. Aug. 06. 04:26 - Szerkesztve: mc68k


Itt egy kiváló, programozóknak való kérdés. :)

Hogy lehet megoldani, hogy az interrupt ruting lássa a global data area-t (globális változókat)? Geta4(), __saveds stb? Próbáltam, de nem akar működni. SAS C 6.58.

Chain-Q
Divatamigás

# Elküldve: 2017. Aug. 06. 11:31


Példakód és/vagy disassembly? Nem túl nagy mágia ellenőrizni, hogy mit fordít a fordító ezekből... De én nem szopnék ilyesmivel, hanem az Interrupt struktúrában az is_Data mezőt beállítanám megfelelően egy olyan structra, amiben minden benne van amire az interrupt handlernek szüksége van, és aztán majd az exec garantálja, hogy az is_Data értéke az A1 regiszterben lesz, amikor belép a függvényembe. Amit meg meg kell adni amikor az interrupt rutinod paraméterlistáját deklarálod.

Itt van egy példakód:
http://wiki.amigaos.net/wiki/CIA_Resource

DISCLAIMER: Nem értek az interruptokhoz Amigán.

Yellow Dog
Tag

# Elküldve: 2017. Aug. 06. 12:56


Quoting: charlie
Nem értek az interruptokhoz Amigán.

Én sem, ezért bár félve, de megkérdezem, nem a legegyszerűbb, ha a vektort átírom, majd a saját rutin végén az eredeti, elmentett címre ugrok?
Mint ahogyan pl. C64-nél is, jó, lehet, hogy nem rendszerbarát, de akár még gyorsabb is lehet.

Chain-Q
Divatamigás

# Elküldve: 2017. Aug. 06. 12:58 - Szerkesztve: charlie


Mint ahogyan pl. C64-nél is, jó, lehet, hogy nem rendszerbarát, de akár még gyorsabb is lehet.

Gratulálunk! Ön összefoglalta miért létezik a WHDLoad mint projekt. Mert az ötszázason programozók azt hitték, ez egy Commodore 64, és tudnak okosabb megoldást mint az OS. Aztán szembe jöttek az újabb gépek, és FAIL. És még 25 évvel később is takarítjuk az összehányt mocskot.

Yellow Dog
Tag

# Elküldve: 2017. Aug. 06. 13:13


Ebben teljesen igazad van :-)
De azért látjuk azt is, hogy OS-el illetve anélkül mire képesek ezek a gépek... gondolom nem véletlenül mondtak le annak idején (nem hülye) programozók az OS-ről és vették át a gép felett a teljes irányítást ;-)

Chain-Q
Divatamigás

# Elküldve: 2017. Aug. 06. 13:18 - Szerkesztve: charlie


OS-sel is pont annyira képes, csak ahhoz érteni kéne, nem széttúrni a hardvert aztán majd úgyis rebootol az user, yolo. Eszméletlen mennyiségű kóddal találkozom a mai napig, ami nem azért nem rendszerbarát mert akkor lassabb lenne, hanem mert a hiperokos programozó úgy döntött, hogy "jóazúgy" aztán beletúrt a HW-be inkább. Ez hatványozottan jelentkezik manapság az UAE kóderek korában, amikor az UAE enged valamit amit az igazi HW nem, aztán megy is a beszopás mikor félórával a deadline előtt pánikolnak h. jajigazigépenlefagy, mostmilesz és vegyem fel inkább emuból a demóját. Nembazmeg. Tanulj meg rendesen kódolni inkább.

Amúgy ettől teljesen független, hogy megérzésem szerint Viktor valami drivert hegeszt, C-ben, ergó a fel sem merül hogy ne legyen rendszerbarát a cucc. De majd az illetékes elvtárs kijavít, ha tévedek.

Yellow Dog
Tag

# Elküldve: 2017. Aug. 06. 13:25


Igen, úgy tudom azt hegeszt...

BSzili
Tag

# Elküldve: 2017. Aug. 06. 16:06


Visszatérve az eredeti kérdésre, elég a rutin elejére egy geta4(), és onnantól már hozzá lehet férni a globális változókhoz. Egyébként meg amit az előttem szólók írtak, a user data pointerben is át lehet dobni ha csak egy változó van, vagy valami struktúrába vannak rendezve a dolgok.

mc68k
Tag

# Elküldve: 2017. Aug. 06. 16:11 - Szerkesztve: mc68k


Valamiért a geta4() interrupt-ban nem akar működni. User data pointer-ben lett eddig megoldva, mert csak 1 változó címét kellett átvinni, viszont most már tudni akarom, hogy miért nem megy a geta4()?

Kiegészítés:

__far direktívával működik a dolog.

Globális változó példa:

__far UWORD *col0 = (UWORD *)0xdff180;

thomas^sd
Tag

# Elküldve: 2017. Aug. 07. 08:01


Quoting: charlie
Ez hatványozottan jelentkezik manapság az UAE kóderek korában, amikor az UAE enged valamit amit az igazi HW nem, aztán megy is a beszopás mikor félórával a deadline előtt pánikolnak h. jajigazigépenlefagy, mostmilesz és vegyem fel inkább emuból a demóját.


Valahol sejt-ettem ezt. Latszodik jopar uj demonal ez az effekt.
Gondolom te is partyn lattad, tapasztaltad ezt.

adsr
Kukabúvár

# Elküldve: 2017. Aug. 07. 09:36


Quoting: charlie
. Ez hatványozottan jelentkezik manapság az UAE kóderek korában, amikor az UAE enged valamit amit az igazi HW nem, aztán megy is a beszopás mikor félórával a deadline előtt pánikolnak h. jajigazigépenlefagy, mostmilesz és vegyem fel inkább emuból a demóját. Nembazmeg. Tanulj meg rendesen kódolni inkább.

Hehhe. Én Amosban nyomom, és csakis igazi gépen! :D

BSzili
Tag

# Elküldve: 2017. Aug. 07. 09:39 - Szerkesztve: BSzili


Nézegetem a GCC által generált kódokat, és láttam benne ilyet:

movel #0x3f800000,d0
movel d0,a3@

meg ilyet is:

moveq #1,d0
fsmovel d0,fp0
fmoves fp0,a3@

Ezek ugyanazt eredményezik?

mc68k
Tag

# Elküldve: 2017. Aug. 07. 10:14


Az igazság az, hogy ha nem asm-ben programozok, akkor elolvasom a C fordító manual-ját és úgy csinálom, ahogy ott írja. Nem akarok belemélyedni a generált kódba, tegye a fordító a dolgát, csak úgy működjön, ahogy a doc írja. És nem mindig működik úgy...

BSzili
Tag

# Elküldve: 2017. Aug. 07. 10:59


Én se szoktam nagyon beleturkálni, de nekiálltam kód-generátort írni, ami QuakeC bájtkódból 68k-t gyárt. Végül is annyira nem lényeges, ha azt követem amit a fordító csinált azzal nagyon nem nyúlhatok mellé.

Chain-Q
Divatamigás

# Elküldve: 2017. Aug. 07. 11:25 - Szerkesztve: charlie


@BSzili:
Igen, de a masodik sokkal lassabb, viszont a kornyezo kodtol fuggoen biztonsagosabb lehet, mivel az ertek betoltese a CPU regisztereken keresztul tortenik, ergo a CPU es FPU szinkronizacioja megoldott (az fmove miatt, ami CPU regisztert olvas es FPU regiszterbe ir), ami 030+882 paroson sok esetben problemas, ha az ertekek mozgatasa a memorian keresztul tortenik.

(Ertsd: pl. az FPU mivel parhuzamosan fut, egy move.l d0,(a3); fmove.s (a3),fp0 paros eseten meg az (a3) korabbi erteket olvasna be, nem azt amit a move.l kiirt, ill. vice-versa. Az 68881/68882 ill. a 68040/060 user manual eleg reszletesen leirja mikor kell szinkronizalni a CPU-t az FPU-val.)

Yellow Dog
Tag

# Elküldve: 2017. Aug. 07. 11:31 - Szerkesztve: yellowdog


Quoting: adsr
Én Amosban nyomom, és csakis igazi gépen! :D

Én is tervezem egy játék írását, és azt hiszem az Amos lesz hozzá a befutó, de ezt itt csak halkan... :-)

Lazi
Mr. AmiCon

# Elküldve: 2017. Aug. 20. 09:00 - Szerkesztve: lazi


No errol beszeltem:

Ben Hermans ott segit, ahol tud
(Apollo CPU patent, copyright)

Yellow Dog
Tag

# Elküldve: 2017. Sze. 22. 19:22


A képen látható pakkot keresném, természetesen pdf formátumban. A "libraries" meg van, de a többit egyszerűen nem találom sehol.
Köszönöm

siz
Tag

# Elküldve: 2017. Sze. 22. 20:25


Nem ez az?

Yellow Dog
Tag

# Elküldve: 2017. Sze. 22. 22:08


Tulképp igen, de a komplett könyveket szerettem volna pdf-ben letölteni. Közben mélyebb vizekre eveztem és megtaláltatott... :-)

BSzili
Tag

# Elküldve: 2017. Nov. 26. 22:49 - Szerkesztve: BSzili


Blitter mintermekhez ért valaki? A következő műveletet szeretném elvégezni BltMaskBitMapRastPort-tal:
dest = (dest & mask) | src;
A gond az, hogy a szokásos "ABC|ABNC|ANBC" mintermmel úgy rajzolja ki, mintha a maszk invertálva lenne. Próbáltam "ABC"-vel is, amivel a maszk jó, de maga a forráskép kerül inverzen kirajzolásra. Nézegettem az igazságtáblát a dokumentációban, de a fentiektől eltérő eredményt nem sikerült elérni.

szerk: Mivel a graphics.library az A csatornát fenntartja belső használatra, csak 16 lehetőség van összesen. A nyers erő jegyében kipróbáltam mindet, és a "ABC|ANBC|ANBNC" volt a nyerő a fenti képlethez.

dh1
Mr. DTP

# Elküldve: 2017. Nov. 29. 00:10


hat... ize... igaz! :D

Mash
Tag
# Elküldve: 2017. Dec. 05. 10:25


Sziasztok!

Segítséget kérnék. Éppen az Amigás texture fillerem inner loopját optimalizálom, 68060-on és nem szeretném, hogy valami jó módszer - amit nem ismerek - kimaradjon. ;)
Odáig eljutottam, hogy kigyomláltam a szorzásokat és csak összeadások vannak a loopon belül, illetve próbálom kerülni az instruction cache miss-eket.
Felmerült, hogy ha a scanline 4 chunky pixel, vagy több, akkor longwordöket írok, ha 2 pixel, akkor wordöt, nem byte-okat, mivel mindegyik move 1 clock cycle, de így meg nem hiszem, hogy beférek a cache-be.
A másik, hogy próbálom kihasználni a két ALU-t, és egymás mellé rendezni a pOEP és sOEP párokat, hogy párhuzamosítva fusson a kód, ahol lehetséges.
Egy próbát akarok még tenni azzal, hogy felhasználom az FPU regisztereit is, hogy a lehető legkevesebbet kelljen a stackhez/memóriához nyúlni, hátha ez is gyorsít valamennyit.
Előre is köszönöm a segítségeteket!

Üdv!
Mash

Mash
Tag
# Elküldve: 2017. Dec. 05. 10:27


Ja, szóval a kérdés az, hogy van-e még valami ötletetek, amire érdemes lenne odafigyelni? :)

<< 1 ... 9 . 10 . 11 . 12 . 13 . 14 . 15 . 16 . 17 . 18 . 19 ... 24 . 25 . >>
forum.amigaspirit.hu / Fejlesztés / Általános fejlesztési kérdések
 
 

Powered by chat forum software miniBB™ © 2001-2024