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 / Classic hardver / Scanjugglert a népnek!
<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 39 . 40 . >>
Szerző Üzenet
dezz
Tag
# Elküldve: 2009. Jún. 04. 22:20 - Szerkesztve: dezz


Leszimuláltam itt magamnak, hogyan is nézne ki a 4:1:1-es kép a kártyán, AGA-HiRes felbontásból kiindulva. Hát, érdekes. Itt a színfelbontás már csak 90 U + 90 V (overscanben), és ez egyes helyeken okoz is némi elszíneződést, de nem vészes. Szembetűnőbbek a lépcsőmentes színátmenetek (már ha nem túl kis felületen vannak, ahol bejátszik a kisebb színfelbontás). Persze mozgásban dől el majd a dolog. Mindenképpen megpróbálom beletenni a hw-be, opcióként a 4:2:2 mellett. (Itt tehát a 6 bitplénes megoldásról van szó.)

Cobra
Piros troll

# Elküldve: 2009. Jún. 04. 22:39


szerintem csak akkor lenne ertelme a dolognak ha tenyleg kevesebb adatot kene kiirni mert ugye a savszelesseg eleg limitalt. Az U/V 1/6-oda se hangzik jol, az mar nagyon ronda lenne. Azt nem teljesen ertem mit ertessz az alatt hogy 6 bitplane-en rendezni az adatokat ugy hogy 8+8+8-as 411 legyen. Milyen 6 bitplane? Azt hittem hogy csak 2 bitplane-t lehet hasznalni. Vagy az csak a "chunky"-ra vonatkozik?

Egy 030/50 nagyon szepen jatssza a Cinepak codec-et hasznalo videokat (pl. MooVId-el) akar 320x240-ben is. Csak ahhoz fonix-et kene ravenned hogy csinaljon ra supportot a moovidba :) Ami az MPEG-et illeti, amennyire emlekszem egy 030/040 kb. a 160x120 koruli videokat tudta normalisan lejatszani, esetleg egy 040/40MHz tudna tobbet, a 25Mhz-es A3640 ami nekem van biztos nem :) Mindenesetre ha valamennyire letisztul hogy lesznek ezek a mode-ok es lesz egy kis idom osszedobhatok egy verziot a RiVa-bol ami hasznalja. De itt tenyleg az a legfontosabb hogy milyen sebesseggel lehet kiirni a chipramba, illetve mennyi adatot kell kiirni.

dezz
Tag
# Elküldve: 2009. Jún. 05. 01:30


Igen, de már írtam. :) Chunkyból ezek vannak:
SHiRes@2 bitplane -> ExtraLoRes@16bpp RGB565 v. YUV4:2:2, LoRes@8bpp
SHiRes@1 bitplane -> ExtraLoRes@8bpp

Planárok:
x felbontás@8 bitplane -> x/2 felbontás@16bpp RGB565 v. YUV4:2:2
(Persze mehet 7 v. akár 6 bitplénnel is, akkor a színmélység csökken.)

És talán lesz ilyen is (planár):
x felbontás@6 bitplane -> x/2 felbontás@16bpp YUV4:1:1
(Itt tehát nem a színmélység csökkenne, hanem a színfelbontás.)

MPEG: na ez tök jó, pont passzol a fenti chunkyhoz. Ennek örülök. :) Bár ott 4:2:2 van, de a c2p hiánya talán jól kompenzálja ezt. Előre is köszi a supportot!!! :))) Majd szerválok egy kártyát, ha lesz belőle több is.

Cinepak: nocsak, nem gondoltam, hogy egy 030 elvisz bármiből is 320x240-et. De ha minden jól megy, annak meg ott lesz a 4:1:1-es planar. (Később majd term. beszélek vele.)

Cobra
Piros troll

# Elküldve: 2009. Jún. 05. 09:52


Jolvan, mostmar igy kezd osszeallni a kep. Az Chunky ExtraLoRes YUV422 valoban hasznos lehet kisebb felbontasu videoknal, bar egy 160x120-as videot fullscreenben nezni interpolacio nelkul szerintem kicsit perverz dolog :) Kar hogy nem megy 4 bitplane-el, akkor mar lehetne 320-as felbontas, es az videokra untig eleg classicon.

A planar mode-oknal szerintem a YUV422 tul lassu lenne, ott mar egy 320x240-es videohoz 640x240-es screent kene 8bit c2p-zni es mind 8 plane-t kiirni. Ez valoszinuleg lassabb lenne mint a DHAM8 ami csak 6 bites c2p-t csinal, viszont jobb minosegu. Esetleg valamit a byte-ok elrendezesevel lehetne trukkozni, mert a legtobb 32-bit c2p rutin eloszor word-oket swappol, majd byte-okat, utana 4-bit, 2-bit es 1-bit darabokat maszkolassal, elkepzelheto hogy c2p-friendly modon el lehetne rendezni a byteokat es akkor az elso ket c2p lepes kihagyhato lenne.

A Cinepak egy eleg trivialis codec, ezert eleg gyorsra meg lehet csinalni. Egy nagy elonye, hogy altalaban a frame-ek jelentos reszenek a kiirasat ki lehet hagyni, mert ahol nem valtozik semmi, azokat a reszeket ki se irja a celbufferbe. Ez viszont nyilvan csak chunky mode-ban mukodhet hatekonyan, ezert eleg nagy kulonbseget tesz ott egy videokartya ami tud chunky alapu mode-okat (pl. RGB16).

dezz
Tag
# Elküldve: 2009. Jún. 05. 13:24


"bar egy 160x120-as videot fullscreenben nezni interpolacio nelkul szerintem kicsit perverz dolog"
Nem olyan rossz, mint amilyennek hangzik. :)

"Kar hogy nem megy 4 bitplane-el, akkor mar lehetne 320-as felbontas, es az videokra untig eleg classicon."
Végülis még akár ez is megoldható... Eddig abból indultam ki, hogy 4:2:2-es wordök a kiinduló adat, és ezeket nem jó külön byte-okra szedni a 68k-nak, tehát "egészben" vártam őket a 2 bitplénen. De ha amúgy is külön byte-sorokban van az Y, U és V, akkor akár így, byte-onként is fogadhatom őket, 4 bitplénen, pl. a következő rendben:

0. bitplane: Y1, Y3, Y5, Y7, ...
1. bitplane: V0, V1, V2, V3, ...
2. bitplane: Y0, Y2, Y4, Y6, ...
3. bitplane: U0, U1, U2, U3, ...

Mint látható, ebben az esetben az U és V adatokat simán longwordösen lehet másolni, rendezkedés nélkül! Így talán jut elég ideje a procinak az Y-ok lassítás nélküli átrendezésére is.

És talán egy ilyen felállás is lehet (4:1:1):

0. bitplane: Y1, Y3, Y5, Y7, ...
1. bitplane: U0, V0, U1, V1, ...
2. bitplane: Y0, Y2, Y4, Y6, ...

Csak ennél a V-k mindig 2 [SJ] pixelnyi lemaradásban lennének, azaz fél "makropixelnyi", de ez talán nem akkora gond.

Közben arra is kell figyelni, hogy az RGB565 se szenvedjen csorbát. Btw, ugyebár itt is |x, R8, G8, B8| szokott lenni az eredeti adatformátum a memóriában, ebből csinálnak pl. HAM8-at, vagy esetünkben RGB565-öt, utólag. Mármint pl. demókban, már amikor nem palettás eleve az adat.

(Most, hogy nagyjából kész a cucc, mégpedig modulárisan tervezve, nem jelentenek akkora bonyodalmat ezek a változások, már ha beleférnek a rendelkezésre álló kapuszámba, stb.)

Cobra
Piros troll

# Elküldve: 2009. Jún. 05. 14:27 - Szerkesztve: Cobra


Hmmm, azert igy mar jobban nez ki a dolog :) Ha megoldhato 4 bitplane-el, akkor AGA-n c2p es YUV->RGB konverzio nelkul lehetne nyomatni full minosegben szinte barmilyen videot amit egy 68k-s vagy akar PPC kartyas classic elbir. Fincsi :)

A 4:1:1-es mode-nal akar jo is lehet ha az U/V elcsuszik, lehet hogy csokkenti a kockasodast a szinvaltozasoknal, nem? A forrasban ugyis ket Y pixelre van egy U/V, szoval az U-ra veheti az u[0]-t, a v-re meg a v[1]-et. Vagyis ha azt mutatjuk hogy a source YUV420 adatbol melyik byteokat hova tesszuk akkor lehetne igy:

0. bitplane: Y[1], Y[3], Y[5], Y[7], ...
1. bitplane: U[0], V[1], U[2], V[3], ...
2. bitplane: Y[0], Y[2], Y[4], Y[6], ...

Ennek egyebkent meg az az elonye van, hogy az U es V folyambol is lehetne egyszerre long-okat beolvasni es osszemaszkolni shift muvelet nelkul, mert a byte-ok kapasbol a megfelelo pozicioban vannak :)

dezz
Tag
# Elküldve: 2009. Jún. 05. 15:06


060-on v. PPC-n mehet az planár alapon is, nem? Hiszen ezeknek nem gond a c2p, a chipram írás a szűk keresztmetszet... Vagy azért itt is járna valamilyen előnnyel a c2p megspórolása?

Cobra
Piros troll

# Elküldve: 2009. Jún. 05. 15:46 - Szerkesztve: Cobra


nezd, reklamoztak 040-en meg 060-on copyspeed sebessegu c2p rutinokat, en is probaltam ilyet (cacheline-al trukkoznek meg minden es tenyleg kurvajok), de a valosagban en azt tapasztaltam hogy meg 060-on is van kb. 10% gyorsulas ha nem kell c2p, meg a legmajerebb 8-bit c2p-vel is. Szoval szerintem ha 320-as felbontassal osszehozhatok chunkyban a YUV mode-ok, akkor mindenkepp erdemes azt hasznalni meg 060-on is, annal nagyobb videora ugyse kell max kepmegjelenitesre, de az meg mar nem olyan sebessegkritikus, szoval ott megfelelne a planar mode is (es az ezzel jaro nagyobb felbontas).

Meg ha van is olyan c2p rutin ami tenyleg hozza a copyspeedet, az csak folyamatos adatfolyammal erheti el azt a sebesseget, viszont 3.x alatt a bitplane-ek tipikusan interleaved formaban vannak, igy sorok vegen megszakad a folyam, sot sokszor ha a video szelessege nem egyezik a bitmap modulojaval, akkor extra maszkolgatas/stb. kell. Peldaul ha 16 pixellel kevesebb a video mint a modulo, akkor minden sor vegen feleslegesen csinalja meg a 32-bit c2p felet, mert a felet el kell dobni.

dezz
Tag
# Elküldve: 2009. Jún. 05. 21:23 - Szerkesztve: dezz


Na, még azt mondja meg valaki, hogy ha pl. egy demó RGB adatokkal dolgozik, amit alapesetben pl. HAM8-ban jelenít meg, akkor ezek az RGB adatok milyen formában vannak a fastramban? Szal:
1., Van valamilyen szokás? 3 byte-plénen külön R, G és B, vagy longwordonként (x-R-G-B)?
2., Full 8-bites adatként vannak vagy a byte-ok alsó 6 bitjén? (Mondjuk ez bizonyára változó.)

Az YUV módok átrendezésével az RGB565 rendezése is módosult (mivel term. ugyanazokat az adatutakat használja), pl. ilyen lett a 2-bitplane chunky (1-1 longword, []-ben a bitsorszámok):

0. bitplane: R0[4:0]-G0[5:3], R1[4:0]-G1[5:3], R2[4:0]-G2[5:3], R3[4:0]-G3[5:3], ...
1. bitplane: G0[2:0]-B0[4:0], G1[2:0]-B1[4:0], G2[2:0]-B2[4:0], G3[2:0]-B3[4:0], ...

Ez persze pont jó, ha 3db byte-plane van az RGB-re, mert így longwordökön végzett maszkolás+némi shift kell csak hozzá.

De nem tudom, mennyivel gyorsabb v. lassabb erre átrendezni pl. x8-R8-G8-B8 alakú longwordöket, ami tudtommal szintén használatos, az eddigi helyett (2-2 word):

0. bitplane: R0[4:0]-G0[5:0]-B0[4:0], R2[4:0]-G2[5:0]-B2[4:0], ...
1. bitplane: R1[4:0]-G1[5:0]-B1[4:0], R3[4:0]-G3[5:0]-B3[4:0], ...

Erre talán egész jól lehet(ett) a bitfield utasításokkal, vagy azok amúgy is lassúak? (Ha nagyon kellene, talán opcióként ez is meglehetne, de erőforrásigénylő, amiből már kevés van.)

Cobra
Piros troll

# Elküldve: 2009. Jún. 07. 00:10


dezz: En mezei ARGB32-t hasznalnek, mert ott 1 pixel = 1 longword, vagyis baromi egyszeru es hatekony a pixeleket megcimezni. Nem hiszem hogy sok ertelme lenne kulon venni az R/G/B-t. Ami az RGB-t illeti, egy kicsit kaotikusnak tunik ez az uj elrendezes. A bitfield utasitasokat felejtsd el, lassuak. A rivaban kezdetben hasznaltam oket, de aztan minden esetben gyorsabb volt amikor lecsereltem a hagyomanyos and/or/shift muveletekre. Talan holnap beuzemelem az A4k-t es megnezem neked a hicolor rutinokat. Csak az a baj hogy 4k-n nincs se halo, se USB, se semmi, szoval kicsit korulmenyes onnan barmit is atmasolni a kulvilagba :)

Cobra
Piros troll

# Elküldve: 2009. Jún. 08. 13:25 - Szerkesztve: Cobra


dezz: valahogy igy nez ki egy ARGB32->RGB16 konverzio 68k-n:

0. bitplane: R0[4:0]-G0[5:0]-B0[4:0], R2[4:0]-G2[5:0]-B2[4:0], ...
1. bitplane: R1[4:0]-G1[5:0]-B1[4:0], R3[4:0]-G3[5:0]-B3[4:0], ...

move.l (a1), d0 ; d0: xxxxxxxx rrrrrrrr gggggggg bbbbbbbb
move.l 8(a1), d2 ; d2: xxxxxxxx RRRRRRRR GGGGGGGG BBBBBBBB

lsr.l #3,d0 ; d0: 000xxxxx xxxrrrrr rrrggggg gggbbbbb
lsl.w #3,d0 ; d0: 000xxxxx xxxrrrrr gggggggg bbbbb000
lsl.l #6,d0 ; d0: xxxxxrrr rrgggggg ggbbbbb0 00000000
lsl.w #2,d0 ; d0: xxxxxrrr rrgggggg bbbbb000 00000000
lsl.l #5,d0 ; d0: rrrrrggg gggbbbbb 00000000 00000000

lsr.l #3,d2 ; d2: 000xxxxx xxxRRRRR RRRGGGGG GGGBBBBB
lsl.w #1,d2 ; d2: 000xxxxx xxxRRRRR RRGGGGGG GGBBBBB0
lsl.b #2,d2 ; d2: 000xxxxx xxxRRRRR RRGGGGGG BBBBB000
lsl.w #2,d2 ; d2: 000xxxxx xxxRRRRR GGGGGGBB BBB00000
lsr.l #5,d2 ; d2: 00000000 xxxxxxxx RRRRRGGG GGGBBBBB

move.w d2,d0 ; d0: rrrrrggg gggbbbbb RRRRRGGG GGGBBBBB

Nem kell semmifele bitfield muvelet, csak kihasznaljuk hogy lehet word es byte meretben is tologatni. Ez csak a 0. bitplane-t csinalja, a 1. bitplane-t persze ugyanigy kell cask nem 0,2 hanem 1,3 offsetekkel kell betolteni a ket ARGB32 pixelt.

PPC-n ez egyszerubb mert annak eleg komoly bitfield utasitasai vannak (rlwinm/rlwimi) amik egy orajel alatt akarmennyi bitet arrebb tolnak es egy maszk-al beinzertalja egy destination regiszter megfelelo bitjeibe, egyetlen utasitas (es orajel) alatt, igy 5 helyett 3 utasitas (es orajel) lenne osszerakni az R,G,B-t es a move.w se kene a vegen, szoval azzal 5 utasitast lehetne megsporolni PPC-n.

dezz
Tag
# Elküldve: 2009. Jún. 08. 22:08


Cobra: (A 2. move.l után gondolom 4(a1) akart lenni.) Oké, azon leszek, hogy az RGB565 az eredeti alakban maradjon 2-bitplénnél. 4-bitplénnél viszont "kénytelen" a fenti, byte-os formában lenni.

Cobra
Piros troll

# Elküldve: 2009. Jún. 08. 22:19 - Szerkesztve: Cobra


dezz: ja igen, bocs, az 8(a1) akart lenni, mert az elso es harmadik pixelt kell ugye egymas melle tenni, es a source adat long meretu. A masodik plane-hez pedig akkor 4(a1) es 12(a1) kell. Egyebkent szerintem a YUV sokkal hasznosabb, es fontosabb mint az RGB16, kepek megjelenitesere is az ajanlott, video dekodolasra is, igazabol nem is tudom hogy a chunky RGB16-ot mire lenne erdemes hasznalni. Szoval en a YUV-ra koncentralnek leginkabb, aztan a SJ3 ha majd nem szenved ezektol a limitacioktol akkor azzal meg lehetne minden.

dezz
Tag
# Elküldve: 2009. Jún. 09. 22:05


Demo effektekre "szántam". (Pl. magam is szeretném átírni erre 2-3 régebbi kódomat, egyrészt poénból, másrészt... hogy is mondjam... szóval, lelki okokból vagy 15 évig képtelen voltam akár csak egy programsort is leírni gépen, kivéve a mikrokontrollereket. De ez most megváltozott.)

dh1
Mr. DTP

# Elküldve: 2009. Jún. 10. 00:47


CD32 verzio nem lesz?

dezz
Tag
# Elküldve: 2009. Jún. 10. 01:13


dh1: Talán később, mert eléggé át kell tervezni hozzá a panelt.

Cobra
Piros troll

# Elküldve: 2009. Jún. 10. 09:25


dezz: Ha mar igy belejottel az Amiga hardvergyartasba, PPC kartyat nem akarsz tervezni? :P Mondjuk egy MPC8610-alaput? :D

dezz
Tag
# Elküldve: 2009. Jún. 10. 13:31 - Szerkesztve: dezz


Cobra: Hát, azért az egy komolyabb projekt. És még egy prototípust sem könnyű összehozni (spéci nyák + beültetés). De ha jól alakulnak a dolgok, nekem lenne hozzá kedvem. :) (Legalábbis megpróbálni; ha valami nem klappol, többszáz MHz-es, digitális, tárolós szkóp hiányában nem igazán tudnám megtalálni a hibát, ilyenek...)

dezz
Tag
# Elküldve: 2009. Jún. 12. 16:26 - Szerkesztve: dezz


Cobra: Na, úgy néz ki, meglesznek a megbeszélt dolgok. :) (Vagyis már megvannak, de nagyon telítve van már a CPLD, és még 1-2 apróság kell bele. Remélem, minden el fog férni.)

Amúgy most jut az eszembe: a Copperrel megoldható, hogy az Y bitplénje(i) 1:1-es, az U/V-é(i) meg 1:2-es függőleges felbontással menjenek. Azaz így kivitelezhető a 4:2:0 mód, anélkül, hogy az U/V-t 2x kellene átmásolni!

Sőt, mivel az Y(-ok) lehetnek a páros(ok)on, az U/V(-k) meg a páratlan(ok)on, a bitplénpointerekkel sem kell szórakozni, hanem mivel a páros és páratlan bitpléneknek külön moduló-regisztere van, elég a páratlanok modulójával trükközni (soronként váltakozva -x, 0). (Igaz, ez így csak PAL/NTSC/Euro36-ban megy, mert az eleve 31kHz-es módokban máshogy működnek a moduló-regiszterek.)

ps. az interleaved mód screeneknél, stb. választható.

AliveMOon
Tag

# Elküldve: 2009. Jún. 14. 12:20 - Szerkesztve: alivemoon


Szerintetek az hülyeség lenne, hogy ehez a SJ-hez nem PPC kártyát, hanem egy render-egine kártyát kéne tervezni, ha van valami mátrix szorzó meg vector transzformáló, raszterizáló erömű a CPU-nak nem is kell olyan bikának lennie.

dezz
Tag
# Elküldve: 2009. Jún. 14. 17:37


Érdekes ötlet. De nem ismerek olyan vektorprocit, ami árban és teljesítményben is megfelelő lenne, és a rendszerbe illesztés sem egyszerű (már ami nem korlátozza túlzottan a sebességet)...

Cobra
Piros troll

# Elküldve: 2009. Jún. 20. 21:12


No, hogy sikerult a SJ2 precentacio a SceneCon-on? Sajnos nem tudtam megvarni. Kar hogy a rivat nem tudtam idon belul osszepofozni ra, ugy latszik oregszem... :/

dezz
Tag
# Elküldve: 2009. Jún. 21. 14:40 - Szerkesztve: dezz


Cobra: Nem probléma! :) Már az is nagyszerű, hogy egyáltalán beteszed a támogatást! (Vagy közösen, ahogy beszéltünk róla.)
Úgy vettem észre, kedvére volt a dolog a népnek. :) (Kellő alapozás után. :) Mármint részemről is.) Persze biztos érdekesebb lett volna valami mozgó dologgal, de nekem sem volt időm ilyesmire az utóbbi napokban. (Még a hétvégére is becsúszott ugye egy firmware frissítés.)

Cobra
Piros troll

# Elküldve: 2009. Jún. 24. 12:30


Sebaj, remeljuk a kovetkezo SJ2 bemutaton mar mozgo dolog is lesz :) Mindenesetre ha idokozben osszedobsz valami algoritmust a YUV mode-okhoz akkor szivesen hozzapattintom a rivahoz (a framework-ot a SceneCon-on mar megcsinaltam hozza :) ha nem akkor majd ha lesz egy kicsit tobb idom megbirkozok vele. Otthon az a baj hogy tul kicsi a hely es eleg maceras az A4k-t uzembehelyezni emiatt (a billentyuzete se fer el a mostani asztalomon).

DeToX^DT
Tag

# Elküldve: 2009. Jún. 24. 13:28


xegény blala (pécéskóder) azt sem tudta exik e vagy ixák ez a témát :)

dezz
Tag
# Elküldve: 2009. Jún. 24. 17:34


Cobra: Persze, örömmel!
DeToX^DT: :)

dezz
Tag
# Elküldve: 2009. Júl. 12. 16:24 - Szerkesztve: dezz


Egy kis helyzetjelentés. Az utóbbi két hétben kicsit betegeskedtem, de lényegében kész van a ScanJuggler 2. A vezérlőkódot csiszolgatom még (majd utólag is lehet frissíteni, csak még bugos az utólagos frissítés :P ). Viszont már hetek óta halogatódik a "sorozatgyártás" beindítása, mert lemondtak egy melót, amiből meglett volna rá a zsozsó. Ha esetleg van még, akinek nincs SJ v. SJ+, és érdekli az SJ2, kedvezményesen elővásárolhatja! (A régebbi kártyákat is le tudom majd cserélni 8k/SJ, 5k/SJ+ ráfizetéssel.)

Cobra
Piros troll

# Elküldve: 2009. Júl. 13. 12:40


dezz: mennyi az a kedvezmenyes ar? :)

dezz
Tag
# Elküldve: 2009. Júl. 13. 13:26


16k. (70 euro lesz a végára, de idehaza valamivel az euroárfolyam alatt fogok számolni.)

Ebben már benne van a floppy alá szerelhető VGA kimeneti modul. Ez egyben váltóként is tud funkcionálni (ha minden be van forrasztva, néhány euro felárral) az SJ2 és az esetlegesen gépben lévő BVision (vagy adapterrel más videokártya) képe között, gombnyomásra v. automatikusan.

edem
Tag

# Elküldve: 2009. Júl. 14. 09:34


dezz
Vevő lennék egy példányra, de ma kb. 10 napra elutazom, légyszives írj fel a listára, nem szeretnék lemaradni. Kösz!

<< . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 ... 39 . 40 . >>
forum.amigaspirit.hu / Classic hardver / Scanjugglert a népnek!
 
 

Powered by open source forum script miniBB™ © 2001-2024