| Szerző |
Üzenet |
Chain-Q
Divatamigás
|
# Elküldve: 2017. Júl. 03. 11:45 - Szerkesztve: charlie
Siz, szerintem amit belinkeltel az egy UAE-s felvetel, itt egy igazi HW-s: https://www.youtube.com/watch?v=zEV3xPXVDfM
Azert latszik h. lassabb mint emuban, de nem 0.5 fps kepregeny.
|
ratman
Kék troll
|
# Elküldve: 2017. Júl. 03. 14:25
Öööööö.....
Szóval, a vámpírnak - szerintem - van azért értelme, ha már FPU/MMU nincs, de pl. egyrészt van sok ram, IDE, rtg - amivel az A1000,A500(+) és A2000 tulajok ismét egy "használható" hardverhez jutnak egy "igazi" turbókártya árának töredékéért. Másrészt - és ez számomra fontos - az SD foglalaton keresztül van lehetőség ethernet interfész létrehozására is. :) Végtelen lehetőségek, nem annyira vészesen drágán. Majd kiderül, hogy mi lesz belőle, egyelőre azért _NEM_ annyira rossz, csak korlátozottan használható.
|
siz
Tag
|
# Elküldve: 2017. Júl. 03. 14:33
Nem akartam flamewar-t indítani (dehogyisnem... :D), ezért írtam, hogy NEKEM Amiga=demonézés. Arra a Vampire (nekem, még) nem jó.
@Charlie: mea culpa. benéztem. én mondjuk szemre egyébként 3 sec/frame-et számoltam, ami pont 50%-al lassabb a 0,5FPS-nél :)
|
Yellow Dog
Tag
|
# Elküldve: 2017. Júl. 03. 17:35
Quoting: ratman SD foglalaton keresztül van lehetőség ethernet interfész létrehozására
Ez hogyan?
|
ratman
Kék troll
|
# Elküldve: 2017. Júl. 03. 19:38
SD kártya slot az sima SPI busz, ugye.
Aztán meg ezzel.
... és van már hozzá prebétaalfagamma állapotú sana2-es driver is. :)
Azért ez a közismert hiányosságok ellenére nem szar fícsör. :)
|
Yellow Dog
Tag
|
# Elküldve: 2017. Júl. 03. 22:13 - Szerkesztve: yellowdog
Ja, tényleg SPI, oké így már világos ;-)
Ismerem a kütyüt, használom én is.
|
Yellow Dog
Tag
|
# Elküldve: 2017. Júl. 05. 06:15
Gadtools Listview tud valamilyen módon többszörös kijelölést illetve ha egyre kattintok akkor az is kijelölve marad?
KS 3.0 természetesen ;-)
|
Yellow Dog
Tag
|
# Elküldve: 2017. Júl. 05. 06:16 - Szerkesztve: yellowdog
.
|
Yellow Dog
Tag
|
# Elküldve: 2017. Júl. 05. 22:12
Sajnos a ListView ha minden igaz, nem alkalmas többszörös kijelölésre, így megpróbálkoztam egy másik úttal, TextGadget-eket pakolok egymás alá és frissítem a tartalmakat le és felfele léptetésnek megfelelően. Ami a gond, mindegyik köré Border kerül, ami széttördeli elválasztja a sorokat egymástól, a GTTX_Border pataméter pedig hatástalan.
Mi lehet a probléma?
DOous szerű kétablakos fájl listázást és kijelölést szeretnék a lehető legkisebb OS terheléssel, tehát MUI és társai kizárva.
Köszönöm a tanácsokat előre is
|
Chain-Q
Divatamigás
|
# Elküldve: 2017. Júl. 06. 16:16
De, valszeg tudsz a GadTools listview-vel tobbszoros kijelolest csinalni, csak bonyolultabb. Nem probaltam, de igy az API-t elnezve, csak be kell allitani egy ListView callbackot, es a callbackban magad kezelni a kijelolest amikor az user a listadra klikkelget.
Sacc. Majd a BSzili megmondja ha nem igy van. :P
|
Yellow Dog
Tag
|
# Elküldve: 2017. Júl. 06. 21:21 - Szerkesztve: yellowdog
Igen, van valami callback... megoldottam másként, ami számomra értelmezhetőbb, egyszerűbb, a tömbből mindig az aktuális+10 sor szövegét printelem ki és minden sor mögött van egy button ami újrarajzoltatja más színnel a hozzátartozó sort, valamint létrehoz egy hozzá tartozó "kijelölve" belyegyzést. Most már csak valami CurrentDir függvény kéne.
Hát vindózban könnyebb ez az ablakosdi, itt annyi korlát van, annyi minden lehetőség hiányzik ami manapság tök hétköznapi.
|
Chain-Q
Divatamigás
|
# Elküldve: 2017. Júl. 13. 09:21 - Szerkesztve: charlie
Volt ez a kis javaslat AliveMOon-tol, ahol azt talalta mondani, hogy csak COS/ACOS kell az FPU-ba, en meg nem ertettem egyet, mivel:
Quoting: charlie Raadasul nagyon ritka az olyan modern matematikai algoritmus ahol - a tobbi muvelethez kepest - rengeteg sin/cos-t es egyebet kell szamolni. A legtobb esetben eleg jol "kioptimalizalhato" a sin/cos belole, foleg reszmuveleteire bontva.
Ma talalkoztam ezzel, utility, ami pont ezt csinalja (tobbek kozott). Beadsz neki egy sin/cos/gyokvonas/stb-vel teliszort egyenletet, es alapmuveletekbol allo (osszeadas-kivonas-szorzas) C kodot csinal belole, ami jo kozelitessel ugyanazt a vegeredmenyt adja (nem vagyok matematikus, de talan polinomikus kozelitesnek hivjak amit csinal, magyarul):
https://github.com/samhocevar/lolremez
Pl:
Ja es termeszetesen tobbfele algoritmus letezik erre, van amelyik sebessegre, van amelyik pontossagra torekszik, ez csak egy implementacio, de eleg jopofanak tunik.
|
dekanyz
Tag
|
# Elküldve: 2017. Júl. 13. 10:34
Komoly...
|
AliveMOon
Tag
|
# Elküldve: 2017. Júl. 13. 12:55 - Szerkesztve: alivemoon
Gondolom ezt a polinom optimalizáló, könnyebben implementálható áramkörben, mint a sin/cos :)
Mert ha jól emlékszem ez volt az érv, hogy bonyolult CPU-ba implementálni sin/cos-t :)
Egy fokkal egyszerűbb a fejlesztő élete, ha ilyen alap függvények benne vannak.
Sin/cos-nál eleve egyszerű a táblázatból címzés. Csak hát mégis jobbnak tartom, ha büfög valamit a cpu.
post:
Poénból kicsit csusztatok egyet :)
Tehát szerinted Apollo team-nek mégis igaza van, nem fontos az FPU, hanem egy ilyen utiliti kell, ami kimatekozza a valós számokat, sima egészekben, de rettentően optimalizál mint az állat ezért gyorsabb lesz mint az FPU-val :)
Én egy kompromiszumos megoldást vázoltam fel, hogy ne implementálják az egészet egyenlőre, hanem először rakjanak bele néhány fontos műveletet, gyakorlatilag a soft core-hez valami gyorsítót.
|
Chain-Q
Divatamigás
|
# Elküldve: 2017. Júl. 13. 13:53 - Szerkesztve: charlie
@AliveMOon
Csak hát mégis jobbnak tartom, ha büfög valamit a cpu.
Már leírtam, hogy az egyetlen nagyteljesítményű FPU ami trigonometriai utasításokat implementál, az az x87, de az is polinomikus közelítést használ, és nem javasolt a használata, mert tragikusan pontatlan. Ráadásul lassabb is, mint szoftverből, mert átlag 100 (száz) órajel egy modernebb procin, aminél gyorsabb (és pontosabb) közelítő algoritmust lehet írni szoftverből.
Ez nem vélemény kérdése, hogy mit tart az ember jobbnak, csak a száraz tények... Mindegy...
Amúgy ja, én is ezt mondtam az Apollósoknak, hogy valami emu-gyorsítót basznak bele, jóaz. Pl. valami mechanizmust, hogy ne kelljen végigmenni a normál TRAP-eken meg a register-context save-restore-on, mert az a leglassabb része, amit nem is nagyon lehet szoftverből gyorsítani. De a postommal előbb egyetértettek, hogy pont ilyesmit akarnak, aztán meg kitörölték az egész threadet. Whatever.
|
AliveMOon
Tag
|
# Elküldve: 2017. Júl. 13. 16:06 - Szerkesztve: alivemoon
Fügvény rajzoló!
Ezt kell bemásolni:
sin(x);
(4/pi)*x + (-4/(pi*pi))*x*abs(x);
0.225 * ((4/pi)*x + (-4/(pi*pi))*x*abs(x) * abs((4/pi)*x + (-4/(pi*pi))*x*abs(x)) - (4/pi)*x + (-4/(pi*pi))*x*abs(x)) + (4/pi)*x + (-4/(pi*pi))*x*abs(x);
Méghogy az FPU nem pontos és majd ezek a közelítések igen :)
Mivel Apollo team saját coret fejleszt, senki nem tíltja, hogy az FPU-ban esetleg egy jobb és gyors valamit implementáljanak, csak akarni kell, és akkor nem kell tele szemetelni a kódot minden szarral, amit össze guberálunk a netről, vagy elpöcsölni a debugolásnál egy valag időt, amig rájössz, hogy mégsem elég kerek amit találtál.
Először akkor is a CPU utasítását fogom használni a kódba, aztán ha valami nem tetszik, vagy lassú utána kezdek utána nézni, van funkcióra hatékonyabb megoldás és így a kód nem lesz tele ökörségekkel, ha elégjó akkor meg marad és általában marad.
|
dh1
Mr. DTP
|
# Elküldve: 2017. Júl. 14. 01:17
Ez a SOFTFPU eleg jol muzsikal igy a ma kijott 0.5 verzioban ...
Persze nem vegleges, de csomo FPU-t igenylo progi szepen muzsikal, pl. demok is...
|
Chain-Q
Divatamigás
|
# Elküldve: 2017. Júl. 14. 13:07
Ja, ami nem használja az FPU-t menet közben, csak precalchoz, az szépen megy... :)
|
dh1
Mr. DTP
|
# Elküldve: 2017. Júl. 14. 14:57
jah mint a demod ;)
|
Chain-Q
Divatamigás
|
# Elküldve: 2017. Júl. 14. 15:38
Az szerintem (ki emlekszik mar) hasznalja az FPU-t menet kozben, de annyira minimalisan h. nem oszt nem szoroz. :P Ill. nem emlekszem hogy csak a SIN/COS tablat szamoltam ki FPU-val az elejen, vagy az objekt forgatast is... Az E!- c. 64k introm probalja ki valaki az huzosabb, ott valos ideju objekt generalas van FPU-val, az biztos jobban szaggat. ;)
|
BSzili
Tag
|
# Elküldve: 2017. Júl. 16. 15:16
Ha már FPU olvasgattam a 68060 doksit, és láttam hogy van egy "mode control byte" amivel lehet a kerekítés pontosságát változtatni. A Quake csinál olyat x87-en, hogy renderelés előtt leveszi a pontosságot single-re és utána visszaállítja. Ezt szeretném 060-on reprodukálni, hátha gyorsít valamit.
Hogy tudom ezt a byte-ot állítani?
http://www.intel-assembler.it/portale/5/motorola-fpu-programming/68881-68882-68040-co mmand-reference.asp
|
siz
Tag
|
# Elküldve: 2017. Júl. 16. 22:27
Nem akarlak elkeseríteni, de az én olvasatomban a műveletek mindig extended pontossággal történnek, csak az eredményt kerekíti a beállításnak megfelelően. Akkor lehet értelme, ha utána single pontosságú értékkel akarsz tovább számolni (mert pl. az van deklarálva magas szintű programnyelvben).
Mondom ezt úgy, hogy egyrészt érdemben nem válaszoltam, másrészt meg közöm nincs az m68k assemblyhez (sem).
|
Chain-Q
Divatamigás
|
# Elküldve: 2017. Júl. 18. 13:12 - Szerkesztve: charlie
@BSzili:
Ezt szeretném 060-on reprodukálni, hátha gyorsít valamit.
A., a 040/060-nak vannak alapbol single/double-re kerekito utasitasai, nem kell a mode control regisztert basztatni, ami lassu. (lasd FSADD/FSMUL/FSDIV/FSSUB/etc...)
B., az ilyen muveletek azonos sebesseguek mint a "sima" extended muveletek. A GCC is fordit ilyen utasitasokat 040/060-ra valo optimalizalaskor, de csak azert, mert az IEEE-754 binaris pontossaghoz elvart, maskent mas lehet a vegeredmeny, mert a nem kerekitett "hibak" a 32/64biten felul osszeadodnak.
C., ha nem extendedben van az FPU, akkor 881/882-n lassabb, mivel olyankor tovabb tart a kerekites... (Lasd 881/882 user manual.)
D., a 68060 User Manual leirja hogy milyen gyorsak a kulonbozo FPU utasitasok per orajel, a regiszterekben torteno single/double muveletek azonos szamu orajel alatt futnak mint az extendedek, a mode control regiszter pedig csak a defaultot allitja, mas kulonbseg nincs.
Ha arra vagy kivancsi a GCC mit fordit kulonbozo 68k-s procikon, ajanlom a http://brownbot.hopto.org-ot, ahol egy eleg eleg recent GCC6 parameterezheto 68k-hoz, es nezheto a generalt kod Compiler Explorerben. (Igaz ez Ataris, de az FPU-s kodnal pont nem oszt nem szoroz.)
Persze gondolom a software emunak szamit h. single vagy double vagy extended... :P Mert singleben minden gyorsabb... Ha arra akarsz tesztelni, lehet h. segit. De amugy ne varj csodakat. :) (Spoiler: nem te vagy az elso aki erre gondol. De milyen jo lenne ha pl. valaki irt volna mar FPU kod generatort egy forditohoz, es tesztelt volna ilyesmit... ;)
|
BSzili
Tag
|
# Elküldve: 2017. Júl. 18. 13:31
Értem, szóval nem érdemes ezzel vackolni, mert nem nagyon lehet nyerni vele. Kösz a válaszokat!
Más. A frame pointert érdemes meghagyni ha nem akarok debugolni, vagy többet ér a +1 regiszter amit nyerek nélküle?
|
Chain-Q
Divatamigás
|
# Elküldve: 2017. Júl. 18. 13:49
Kodfuggo. Van kod, ami gyorsabb/kisebb FP nelkul, van ami nagyobb es lassabb. Altalaban kisebb, es hasznos a plusz 1 regiszter amit felszabadit, foleg komplex kodnal, ami sok kulonbozo cimet/pointert hasznal. (Hiszen 68k-n az FP egy cimregiszter (Amigan altalaban A5, mashol A6), ami korlatozasokkal hasznalhato csak masra.) Az FPC jelenleg nem tud FP nelkul kodot forditani, tehat nagyon nem teszteltem ezt...
|
ratman
Kék troll
|
# Elküldve: 2017. Aug. 03. 13:47
Haló,
Szóval, július 27-én a pórnép számára is elérhető lett az femu.
Fél napnyi küszködés után sikerült kiberhelni egy 3.9-es HaageundpartnerOS-ból a math#?.library-kat és felküzdeni a vámpír által megszállt "fekete dögvész" (C)(R)(TM) típusú A500-amra.
Két dologban jelenleg biztos vagyok:
- csinál valamit (legalábbis, aminek FPU kell az "megy", vagy nem :D)
- és... kb. ennyi, teljesítményt nem szabad tőle várni, mert az nem nagyon van (alap A3000, ami ugye 68882@25Mhz, na ahhoz képest a 10-e).
Ja, meg állítólag ma valamit bejelentenek. Vagy nem. Nem lennék meglepve. :)
Én kérek elnézést.
|
Chain-Q
Divatamigás
|
# Elküldve: 2017. Aug. 03. 18:01 - Szerkesztve: charlie
Vampire V4. Nagyobb FPGA-val, 512MB RAM-mal, stb. Tovabbra is az 500/1000/2000 vonalba. Alternativ megoldaskent megy onalloan is (kiterdekel, akkor inkabb egy RPi emuval, de tenyleg), meg lesz 600-asba adapter, elvileg. Allitolag lesz 1200 verzio is, hat kivancsi leszek.
Kivancsi vagyok a nagyobb FPGA mennyit fog rajta tolni sebessegileg.
http://forum.apollo-accelerators.com/viewtopic.php?f=8&t=1804&sid=7ae3f047af5666dfa4b e53091745b5ef
|
ratman
Kék troll
|
# Elküldve: 2017. Aug. 03. 20:44
Szarok a sebességre. Legyen FPU, meg MMU és esetleg valami UN*X-szerű izé is bútoljon rajta. Ennyi ami kell, más nem. :D
|
BSzili
Tag
|
# Elküldve: 2017. Aug. 04. 10:40
Hát *szipp*, AMMX2 meg 4 szálas HyperThreading biztos lesz benne. Most jobb lesz ha fedezékbe vonulok :D
|
dino
Kék troll
|
# Elküldve: 2017. Aug. 04. 10:44
Es ezeket hasznalja is majd valami?
Vagy csak jajdejo ezt is tudja...
|
