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

 - Fórumok - Regisztráció - Keresés - Statisztika - Szabályzat - Pegasos.hu fórum
forum.amigaspirit.hu / Újgenerációs AmigaOS / AmigaOS 4.1
<< 1 ... 36 . 37 . 38 . 39 . 40 . 41 .
Szerző Üzenet
dh1
Mr. DTP

# Elküldve: 2017. Ápr. 11. 01:14


Idezek:
"van fontja, tehat akkor van text modja is ..." MUHAHAAAA OMG

kerdes: ha van fontja (akar tobb is :) akkor a text mod miert csak 80 es 60-as?
"hat le kene merni mekkora egy TTF fontja" ...

itt ereztem, hogy ki kene lepni a csoportbol :D

adsr
Kukabúvár

# Elküldve: 2017. Ápr. 11. 08:15


Quoting: dh1
Idezek:
"van fontja, tehat akkor van text modja is ..." MUHAHAAAA OMG

kerdes: ha van fontja (akar tobb is :) akkor a text mod miert csak 80 es 60-as?
"hat le kene merni mekkora egy TTF fontja" ...

itt ereztem, hogy ki kene lepni a csoportbol :D

Sok szagértő :D.

Yellow Dog
Tag

# Elküldve: 2017. Ápr. 11. 09:31 - Szerkesztve: yellowdog


Quoting: dh1
van fontja, tehat akkor van text modja is ...

Magyar oldalon hangzott el? Te jó ég... bár a logika mibenlétét Hofi is elmagyarázta, ugye: "Van akváriumod, nincs? Akkor buzi vagy" :-)

BSzili
Tag

# Elküldve: 2017. Ápr. 14. 16:34 - Szerkesztve: BSzili


Ki mit gondol arról, hogy a Hyperion és Jens Schönfeld megvette a P96-ot? Elvileg be lett ígérve a driver SDK ingyenessé tétele (új RTG kártyákhoz jól jön majd), meg hogy a Aminet-ről nem lesz leszedve a P96, mint ahogy azt megszokhattuk az ilyen felvásárlások következményeként.

AliveMOon
Tag

# Elküldve: 2017. Ápr. 14. 17:45 - Szerkesztve: alivemoon


Szerintem az az érdekes, hogy eddig miért nem volt nekik fontos? Lett volna rá vagy 20 évük, aztán most jutott eszükbe pont?

Szerintem a Hyp. befosott, hogy Vampir-ból többet adnak el mint OS4-ből, IComp szintén, mert ker.áru CPU-val épít kártyákat, túl nagy kihívásnak érezheti, hogy valaki magát a CPU-t is implementálja.

ratman
Kék troll

# Elküldve: 2017. Ápr. 14. 21:46


@Bszili: WAT?
Egyebkent nem akkora baj, csak legyen free az sdk, meg ugy a minden. :) Az mntmn-es sracok orulnenek neki, szerintem. :D

Chain-Q
Divatamigás

# Elküldve: 2017. Ápr. 14. 22:44 - Szerkesztve: charlie


@BSzili:
Ki mit gondol arról, hogy a Hyperion és Jens Schönfeld megvette a P96-ot?

Nekem van velemenyem. De nem irom ide le, mert ki kellene moderalnom magam.

Szerk: Amugy az en ertelmezesemben, csak Jens Schoenfeld vette meg a P96-t, mivel a Hyperionnak mar eddig is volt joga hogy hasznaljak, az OS4-hez, nem? Raadasul, a legutobbi OS4.1-ben mintha az lett volna h. kidobtak a P96-t, es valami uj API van helyette.

BSzili
Tag

# Elküldve: 2017. Ápr. 14. 23:19


Én úgy tudom a P96 driver API-t belsőleg még mindig használják, legalábbis a régi nem-RadeonHD driverek.

AliveMOon
Tag

# Elküldve: 2017. Ápr. 15. 00:46 - Szerkesztve: alivemoon


Quoting: BSzili
Én úgy tudom a P96 driver API-t belsőleg még mindig használják


P96-nak OS4 elött volt natív PPC-s változata?
BVision-t CybergraphX V3.0 release 70a or higher adták.

OS4-ben ami van azt már Hyp.-nek kellett csinálnia.

Én arra tudok gondolni, hogy eddig Hyp. royalty-t fizetett, eladott OS4-ek után, most meg megvették.

Chain-Q
Divatamigás

# Elküldve: 2017. Ápr. 15. 13:36


Nem, csak a Warp3D-bol volt classic PPC nativ valtozat, a P96-bol es a CGFX-bol sosem. (A P96-bol az OS4-ben lett, a CGFX-bol a MorphOS-ben, nyilvan.)

dh1
Mr. DTP

# Elküldve: 2017. Ápr. 15. 20:29 - Szerkesztve: dh1


Quoting: alivemoon
Szerintem a Hyp. befosott, hogy Vampir-ból többet adnak el mint OS4-ből, IComp szintén, mert ker.áru CPU-val épít kártyákat, túl nagy kihívásnak érezheti, hogy valaki magát a CPU-t is implementálja.


szerintem is

Quoting: charlie
Hyperionnak mar eddig is volt joga hogy hasznaljak


igen de esek utan a Hyp mar Vampire utan is kerhet zset, nem veletlen, hogy a Vampire-osok sajat driveren dolgoznak, ha igaz ...

ez megint csak penzbeszedesi kiserlet Hyp reszerol

Lazi
Mr. AmiCon

# Elküldve: 2017. Máj. 21. 19:30 - Szerkesztve: lazi


Hyperion Lemertainment kiadott egy 1.10-es Freespace demot.
Haat nalam nem megy, pedig tonnanyi bugfix van benne.
Valakinek sikerult elinditani?

Nalam igy indul

dh1
Mr. DTP

# Elküldve: 2017. Máj. 21. 22:32


itt megy PEGA2-n

Chain-Q
Divatamigás

# Elküldve: 2017. Okt. 22. 10:46 - Szerkesztve: charlie


Zajlik az AmiWest, mar megvolt Trevor es SSolie beszede az A-Eon es az OS4 reszrol, itt vannak a reszletek, de kb. bejelentettek a nagy semmit, osszefoglalo itt angolul:

http://amiga-news.de/en/news/AN-2017-10-00043-EN.html

Az X5000-rel kapcsolatban kb. annyit, hogy minden optimalizalatlan meg rajta, a SATA driver kulonosen (megj: 2 eve az Amiga30-on pont ez volt az allapot, konkretan miutan Trevor meglatta hogy megy a MorphOS sajat drivere a gepen, odazavarta a ket Friedent kerdezoskodni bigfoothoz, hogy hogy csinalta, de latom azota sem sikerult megoldani a nehezsegeket...) network driver nincs (megj: az X1000-hez sem lett soha, az alaplapi controllerhez), sot meg olyan dolgokat is kell optimalizalni mint a CopyMem rutin.... (Beveszi ezeket a dumakat meg valaki?) Az SMP-rol nem esett szo, sem az OS4.2-rol, bar elvileg a quadcore verzio is jon a gepbol...

A Tabor ott volt, mukodott, kb. annyit lehet rola tudni hogy "az FPU emulatoron meg dolgoznak" (nocsak, tan csak nem kurva lassu, ahogy megjosoltuk?), es hogy a Hyperion majd kiad egy SDK-t amivel direkt a Taborra lehet optimalizalni a cuccokat, es meg mindent optimalizalni kell... Ami rafer, mer' volt nemreg egy video, amin kb. annyi jott at, hogy kurva lassu. Persze az atlatszo kockat forgatja ezerrel a RadeonHD, azzal nincs hiba, csak minden mas olyan, mint a sarba ragadt terepjaro...

Majd kiderul az Amiga32-n hogy megy, mert kiprobalom ha lesz kiallitott gep, az tuti.

OS4 SDK: SSolie mantyogott valamit, hogy akkor lesz SDK update, ha befejezi, es persze sietett kijelenteni, hogy mivel ez mind nyilt forrasu cucc, ezert mas is segithet neki SDK-t kiadni es a munkat befejezni. (Rohogni er-e?)

LibreOffice: Nem esett szo rola egyaltalan. Suru kuss, pedig mar reges reg betaban kene lennie, konkretan mar a tavalyi AmiWest elott...

Chain-Q
Divatamigás

# Elküldve: 2017. Okt. 29. 12:56 - Szerkesztve: charlie


Na.

Volt kiallitva Tabor. Megneztem. Sirtam.

Eloszor is az OS4 valoban futott rajta. Masreszt viszont ossze-vissza villogott meg glitchelt a Radeon driver, amire aszondtak h. meg "nincs befejezve" de nem ertem, hogy mitol lehet nem befejezve, vagy kiallitasi celra miert nem tettek bele egy regebbit akkor. Vagy osszeglitchelt a driver az FPU emuval, ami ertheto lenne, hiszen egy mai GPU-t szinte kizarolag floating pointban kell es lehet programozni.

A masik, hogy ahogy meg lehetett josolni, az egesz rohadt lassu, amikor barmit a CPU-nak kell(ene) csinalni. Konkretan kikapcsoltak a Solid Window Resize-t a gepen, hogy ne latszodjon h. 2fps az ablak atmeretezese. Egy RadeonHD-n...

Persze kapasbol visszakapcsoltam, es sirtam, mert lassabb volt mint a kiallitott BlizzardPPC + BVision combon a default MorphOS skinnel az ablak atmeretezese, ami azert lassu mert tele van gradiensekkel, amiket Radeonon HW gyorsit a MorphOS, de Permedian nem...

Mindenesetre, allitolag teljesen szoftveres FPU emuval ment most a dolog es a magikus Friedenek dolgoznak valami "TurboFPU" vagy mi, technologian, ami majd mindent megold es sokkal jobb lesz. Nyilvan. (Gondolom olyan FPU emu, ami majd hasznalja az SPE utasitasokat.) Vegulis abban igazuk van hogy ezen csak gyorsitani lehet, mert ez igy ebben a formaban teljesen hasznalhatatlan.

Meg ugye, mar az A-Eon is arrol beszelt, hogy hogyan optimalizalhatjak majd a fejlesztok az alkalmazasaikat Taborra, es hogy majd lesz speci C fordito... Remek lesz, erre vartunk tenyleg miota, hogy megegy verzioban le kelljen forditani mindent. (Szerk: arrol nem is beszelve, hogy az AmiWesten meg pont arrol ment a mantyogas h. nehez SDK-t gyartani. Most sokkal konnyebb lesz, h. ket kulonbozo kell...)

Eh, hagyjuk.

Lazi
Mr. AmiCon

# Elküldve: 2017. Okt. 29. 17:14


Áhh, vetítesz! Mindenhol azt írják, milyen jó kis gép lesz, és hogy fogják szeretni a népek, ha elég ócsó lesz. :-)

Na de miért csak erről írtál? Mint az amigaspirit.hu kiküldött tudósítója lécci beszámolni más élményekről is!

Haynie-vel beszéltél? X5000/MOS volt bemutatva?
???

ratman
Kék troll

# Elküldve: 2017. Nov. 01. 17:39


Quoting: charlie
Eh, hagyjuk.

Ja. :D
Az a szomorú, hogy sokan még mindig hisznek.

Bár, azért van már eladó X5000 az ebay-en, elég masszív összegért, gondolom az eladó igen csalódott lehet. :D

... amin egyáltalán nem vagyok meglepve. :D

HyperionLametainment, nem hittem volna, hogy ma még fel tud dobni valami, de ez a szuperprodukció.... hagyjuk is. :D

BSzili
Tag

# Elküldve: 2018. Jan. 03. 18:38


Érdekes facebók post Daytona675x-től egy olyan Tabor problémáról amit az emulátor nem tud megoldani:
https://www.facebook.com/daniel.mussener/posts/2086799091346527
Dióhéjban a regiszterekben átadott paraméterekkel van a gond SPE és PPC FPU kód keverésekor. Az SPE kód az integer regiszterekben adja őket, a PPC FPU kód meg az (emulált) FPU regiszterekben várná. Ahogy Solie is megmondta, ez teljesen ugyanolyan, mint a '060 vs 68881 FPU régen. Ja mégsem, mert itt két teljesen inkompatibilis FPU-ról van szó.

dino
Kék troll

# Elküldve: 2018. Jan. 03. 20:21


Quoting: BSzili
Ja mégsem, mert itt két teljesen inkompatibilis FPU-ról van szó.

Jaja, de ezt a Csarli jovoltabol itt mar kb tudtuk.
Kb en perpill a guminoben latom jelenleg az olcso Amigaalternativat...ez van.

Lazi
Mr. AmiCon

# Elküldve: 2018. Jan. 03. 22:57 - Szerkesztve: lazi


Jól értem, hogy az FPU emulátor azért kell, hogy a G3/G4 ABI FPU kódot megegye a Tabor, tehát nem kell semmit újrafordítani? Azonban így minden FPU művelet lassú lesz.

Hogy a program ne legyen lassú, lehet fordítani SPE-re, ami egy másik ABI, így az FPU emulátor pihen, a program nem behúzott kézifékkel megy.

Ha az OS-t és a clib, newlib, stb. mind megcsinanak SPE-re, akkor emu nelkul minden megy faxan, de ne akarjunk semmi PPC FPU-s cuccot hasznalni az Aminetről.

Ha pedig a rendszer marad normal PPC FPU-s, akkor aki nativ SPE-re fordit az gondoskodjon workaroundrol.

Es mi lesz az SPE emulatorral a tobbi gepen? :)

Az Amiga régóta zsákutca, csak nem hajtunk padlógázzal a falnak, hanem évtizedek óta rángatjuk a kormányt és így már az oldala is sz*rrá van törve. :(

Chain-Q
Divatamigás

# Elküldve: 2018. Jan. 04. 04:53 - Szerkesztve: charlie


@BSzili:
Átgondoltam. Igen, ezt beszopták. De ez a probléma amit feszegetnek, megoldhatatlan? Nem. De hát OS4-en az ABI-k átjárhatósága mindig is remekül ment, lásd a 68k kódhoz szükséges glue-kat annó, meg a .library interface nevű nettó agyhalált (ami ez esetben még hasznos is lehetne, de itt súlyosabb problémák vannak).

A probléma lényegében ugye az, hogy az SPE-s GCC-nek fingja sincs hogy kell normál FPU-s függvényhívásokat fordítani egy normál FPU-t használó libhez, a linker pedig simán összelinkeli a normál és az SPE FPU-s kódot, ami aztán futás közben nyilván megrohad. Breaking news.

Erre kb. az a megoldás, ha az SPE-s compilert megtanítod normál FPU-s hívásokat fordítani (nem tudom ez GCC esetén mekkora szopás, de gondolom nagy) és vica-versa, aztán trackeled valahogy, hogy melyik static lib, .so és .library és azon belül melyik függvény milyen ABI-t használ, így a fordító a megfelelő glue code-ot fordítja minden híváshoz.

A baj az, hogy C-ben ehhez nem nagyon van infrastruktúra, hogy sokféle ABI-t használjunk, ha valami ezoterikus hívás kell, akkor fel van makrózva orrvérzésig, aztán a linker meg belecsap a lecsóba a végén és lesz ami lesz.

Ja és még igen, további probléma, hogy ez így "egyirányú", és valamilyen szinten a nem-SPE-s gépeken is támogatni kéne, hogy rendesen menjen és valóban "átlátszóan". Ehhez meg sok sikert kívánok, a fejlesztés jelenlegi ütemét figyelembe véve. De nyilván egy irányban is nagy segítség lenne, lévén igazából az SPE-s gép az "oddball", ami máshogy működik, más kérdés, hogy ebből akartak nagy példányszámot eladni, ami ha sikerülne akkor totál fejreállítaná a "erőegyensúlyt" és az SPE lenne a mainstream, amit viszont nem lehet fullba támogatni a kompatibilitás miatt... Remek, nem? :)

(És a szükséges Pascal rulez: Röhelyes módon, a probléma megoldása FPC-ben kb. két nap meló lenne, mivel nekünk vannak "unitjaink", ami technikailag egy leírófálj a generált objektekhez, valamint mivel jónéhány CPU-n a belső Pascal ABI tök más mint a külső ABI (pl. C libek meghívásához) így azt is trackeljük h. melyik external függvény milyen ABI-t használ, így simán tudnánk bármelyik ABI-t akár eseti szinten is "imitálni". Szóval ebben az esetben SPE-st vagy simát is, igény szerint keverve, miközben a kód "belső" része a fordítás targetjétől függően a legoptimálisabb ABI-t használhatná. De hát a világ itt még nem tart, persze a C/C++ modules proposal többek között erre is jó lenne, ha nem lenne szokásos módon egyszerre egy overengineerelt és alulspecifikált clusterfuck.)

Szerk: amúgy átgondoltam, nyilván C-ben is fel lehetne makrózni az egészet eseti szinten legrosszabb esetben kézzel bedrótozva a bináris opcode-okat az SPE to Normal glue-ban. Meg lehet csinálni, de ritka ronda és maintainelhetetlen lesz hosszú távon, még akkor is ha generálod. De hát nem mi mondtuk egy SPE-s PPC-re, hogy "jóleszaz, meghekkeljük".

Szerk 2: Ja és hogy ez 68k-n miért nem probléma, és miért lehet FPU emulátort csinálni pl. a Vampire-hoz 1., 68k-n nincs kétféle FPU szabvány 2., a 68k ABI alapból nem ad át értékeket függvényhíváskor az FPU regisztereiben, hanem a stacken vagy integer regiszterben. Szóval ja. Solie értett hozzá megint. (Nem.)

BSzili
Tag

# Elküldve: 2018. Jan. 04. 12:24


charlie
Ha jól értem akkor itt a "tiszta" megoldás az lenne, hogy a GCC SPE fordítóba raknak egy új hívás konvenció attribútumot ami a PPC FPU-val kompatibilis kódot generálna? Azt biztosan élvezetes lenne karbantartani :)
Kíváncsi vagyok ki volt az a lángész, aki megnyugtatta Trevor-t afelől az az inkompatibilis FPU probléma könnyen megoldható.

Lazi
Mr. AmiCon

# Elküldve: 2018. Jan. 04. 18:11


Ha igazatok van, és miért is ne lenne, akkor ez remekül elpazarol pénzt, idot, hangulatot.

Addig sem kell érdemben fejleszteni a rendszert.

Szuper! :(

Chain-Q
Divatamigás

# Elküldve: 2018. Jan. 04. 18:44


@Lázi:
Ez a fő ok, hogy MorphOS nincs amúgy rá. Van Tabor board a teamben, annak ellenére kaptak egyesek, hogy előre megmondták (még azelőtt hogy a board tervei egyáltalán publikusak lettek volna, vagy az effektív hardvertervezés elkezdődött volna) - nem lesz support, pont ezért. Azt a mennyiségű időt, energiát és szívást ami erre megy rá, hogy valahogy nagyjából működésre bírják a meglévő software bázissal, értelmesebben is el lehet tölteni. Főleg egy olyan platformon, amin a fő probléma a full time developerek hiánya.

@BSzili:
Igen. A másik "tiszta" megoldás az lenne, ha teljesen el lenne szeparálva a két ABI, tehát kb. két külön library set, meg minden. Kb. mint mikor x86_64 és i386 binárisokat futtatsz egyszerre mondjuk Linuxon. De ezzel az a fő baj, hogy a Linuxban ehhez van infrastruktúra, és van egy kernel syscall ABI, ahol meg lehet csinálni az átjárást a kettő között, OS4-en (és általában Amigán) meg nincs. De ehhez megintcsak - taggelni kéne a binárisokat hogy melyik "sima" PPC-s és SPE-s, de erre sincs infrastruktúra jelenleg, ezért is linkel össze a linker mindent szívbaj nélkül.

Arról meg, hogy ki volt ez a lángelme - hát olyan sokat nem kell találgatni szerintem, egy jól behatárolható szűk kör tudott arról, hogy milyen procira fog épülni a Tabor. Ők fözték, mind megesszük. Fincsi mi?

Lazi
Mr. AmiCon

# Elküldve: 2018. Jan. 05. 13:10


Egyik "megoldási" lehetőség sem kívánatos.

Túlbonyolított rendszerekből van választék.
Az Amiga egyszerűségében nagyszerű.

dekanyz
Tag

# Elküldve: 2018. Jan. 05. 13:32


En nem vagyok annyira elszant amigas. Szamomra itt az a helyzet, hogy van egy nem eppen olcso lap (mivel kis szerias), ami meg raadasul kompromisszumokkal (huu de finoman fogalmaztam) hasznalhato.

Kizart dolog, hogy en penzt adjak erte!

<< 1 ... 36 . 37 . 38 . 39 . 40 . 41 .
forum.amigaspirit.hu / Újgenerációs AmigaOS / AmigaOS 4.1
 
 

Powered by easy forum software miniBB™ © 2001-2018