Enterprise Forever

:HUN => Hardver => Karbantartás, javítás => Topic started by: balagesz on 2016.December.27. 23:06:22

Title: Tesztelés
Post by: balagesz on 2016.December.27. 23:06:22
Régen szerettem volna már ezt megnézni, de csak most jutottam el idáig. Viszont mielőtt bármi konkrétumot is írnék; itt egy találós kérdés:

Mi van a képen? :)

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161227_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_001.jpg)
Title: Re: Tesztelés
Post by: IstvanV on 2016.December.27. 23:10:33
A külső színbemenetet (EC0-EC3) használó hardver?
Title: Re: Tesztelés
Post by: endi on 2016.December.27. 23:11:41
A külső színbemenetet (EC0-EC3) használó hardver?

hú ez nagyon érdekes mert sosem volt fogalmam se hogy vajon ez mi lehet
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.27. 23:12:26
Izgalmas! Részletek???
Title: Re: Tesztelés
Post by: balagesz on 2016.December.27. 23:18:33
Itt van egy másik kép is:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161227_002s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_002.jpg)
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.27. 23:23:04
Húúú, ez nem semmi!
Akkor jól tippeltem, hogy bármilyen felbontásban 16 szín lehet 2 színű felbontással?
Title: Re: Tesztelés
Post by: balagesz on 2016.December.27. 23:27:51
Húúú, ez nem semmi!
Akkor jól tippeltem, hogy bármilyen felbontásban 16 szín lehet 2 színű felbontással?

Hát, ez kiderítés tárgya. :) Amúgy az eddigi tippek helyesek természetesen, ez az ECx bemeneteket mozgató cucc. Mindjárt írom a részleteket, mivel az a tervem, hogy hozzám képest villám sebességgel tudnak itt (teszt)programot írni egyesek, így szeretném azt a részt "kiszervezni". :)
Title: Re: Tesztelés
Post by: balagesz on 2016.December.27. 23:37:34
Maga a teszthardver jelenleg a 4-es I/O porton "piszkálható". Ha a B0=1, akkor az első kép (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_001.jpg)en látható dolgot produkálja. A lényeg két számláló. Az egyik egy 10 bites darab, ennek az órajele a gép 14.xxxMHz-es jele, ez a tulajdonképpeni legmagasabb Dot-Clock. Ezt a számlálót a HSYNC jel törli, szóval ez így a vízszintes pozíciót adja a legmagasabb felbontással. Az említett képen ennek a számlálónak a legmagasabb helyiértékű bitje kapcsolja az EXTCOL bitet, amikor a számláló bitje 1, akkor lesz kiválasztva a külső szín. Aztán a másik számláló egy 9 bites darab, ennek a HSYNC adja az órajelet, a VSYNC meg törli. Így ez a rasztersorokat számolja. A képen ennek a számlálónak a 7654 bitjei vannak az EC3210-ra kötve. Az szépen látszik is a képből, hogy a keretet a NICK szépen maszkolja, mivel az ECx bemenetek aktívak a kereten kívül is.
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.27. 23:47:40
Ez idáig tiszta sor :-)
És a második kép? Ott mintha valami videómemóriába írnál.
Title: Re: Tesztelés
Post by: balagesz on 2016.December.27. 23:48:07
Nekünk viszont a második kép (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_002.jpg)en látható jelenség az érdekesebb. Ez a 4-es port B1=1 esetében kapcsol be. A teszthardveren van egy 512 KBYTE-os RAM. Ez egyrészt a gép felől a 0x60..0x7F lapokon keresztül látszik, erről mindjárt. Az előzőleg említett két számláló címzi alapból, mégpedig úgy, hogy a vízszintes számláló jön a RAM A9..A0 címvonalaira. (1 rasztersor 1 KBYTE.) A függőleges számláló jön a RAM A18..A10 címvonalaira, szóval minden rasztersor kerek KB-os határon kezdődik. A RAM-ból minden egyes pixel esetén kiolvasódik egy BYTE, amiből a B3210 kerül az EC3210 vonalakra, a B7 meg megfordítva az EXTCOL-ra. (Tehát ha a B7=1, akkor lesz csak aktív a NICK számára a bejövő EC3210 adat.)

Maga a RAM a Z80 számára csak írható, mivel nem akartam, hogy beleszámolja az EXOS a szabad RAM-ba. Ez a 4-es port B7=1-gyel visszaolvashatóra kapcsolható. Az írás / olvasás jelenleg egy kicsit havazós, ez a karácsonyi ajándék. :) Ezt majd megoldom, bár jelenleg nincs jelentősége.
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.27. 23:56:28
Kapcsolási rajz? :ds_icon_cheesygrin:
Bár ha jól sejtem biztos van benne valami csúnya soklábú :oops:
Title: Re: Tesztelés
Post by: IstvanV on 2016.December.28. 00:01:49
Érdekes lenne kipróbálni 184 karakter szélesre konvertált 16 színű IVIEW képpel. :)
Title: Re: Tesztelés
Post by: balagesz on 2016.December.28. 00:09:58
Kapcsolási rajz? :ds_icon_cheesygrin:
Bár ha jól sejtem biztos van benne valami csúnya soklábú :oops:

Hát, féltem ettől a kérdéstől... :oops: Igen, van benne ilyen soklábú, 0.5mm-es raszterű fekete négyzet. :) De mentségemre szóljon, hogy valójában ez csak tesztre jó, a "minden pixel egy BYTE" típusú adatmennyiség meglehetősen nagy falat egy Z80-nak. De ezek után bármit kipróbálok szívesen! :)

Érdekes lenne kipróbálni 184 karakter szélesre konvertált 16 színű IVIEW képpel. :)

Ez a 184 karakter szélesség hogy jött ki? :) Amúgy ja. A lehetőség adott az ilyen kísérletezésre is.
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.28. 00:24:04
De ezek után bármit kipróbálok szívesen! :)
Mondjuk az egyes variációnál, hogyan néz ki, ha ha jó kis interlace képeket (http://www.ep128.hu/Ep_Demo/Prg/Interlace_Demo_2.rar) tolsz be alá? :-)
Elvileg a paletta színes téglalapoknak változó színe lesz, a bias-osok pedig állandóak.

Ami érdekes próba lenne még, hogy pixel hibás Nick chipeknél a külső színben is meg van-e a hiba? Ha ott nincs, akkor egyértelmű, hogy a Nick korábbi részében (ahol ki találja milyen szín kell az adott pixelre) van a hiba.


Quote
Ez a 184 karakter szélesség hogy jött ki? :)
46x4, azaz a normál 16 szín módhoz képest 4x felbontás, azaz 4x több pixel.
Title: Re: Tesztelés
Post by: balagesz on 2016.December.28. 01:02:06
Mondjuk az egyes variációnál, hogyan néz ki, ha ha jó kis interlace képeket (http://www.ep128.hu/Ep_Demo/Prg/Interlace_Demo_2.rar) tolsz be alá? :-)
Elvileg a paletta színes téglalapoknak változó színe lesz, a bias-osok pedig állandóak.

Most hirtelen ez a "lila-hibás" kép van kéznél:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161227_003s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_003.jpg)

A tipped helyesnek tűnik. :)

Ami érdekes próba lenne még, hogy pixel hibás Nick chipeknél a külső színben is meg van-e a hiba? Ha ott nincs, akkor egyértelmű, hogy a Nick korábbi részében (ahol ki találja milyen szín kell az adott pixelre) van a hiba.

Hát, ehhez kellene egy ilyen alaplap. :oops: Amúgy jelenleg van egy "kis" gondom, amit nem tudok hova tenni: simán (táp)bekapcsolás után a RAM-ban természetesen szemét van. Ha ekkor bekapcsolom a "2-es" módot, akkor ez a RAM-szemét szépen megjelenik a képen:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161227_004s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_004.jpg)

Viszont itt néha villognak bizonyos pixelek... Ez lehet nálam valami időzítési probléma, majd még tologatok pár jelet ide-oda.

46x4, azaz a normál 16 szín módhoz képest 4x felbontás, azaz 4x több pixel.

Uh, ehhez a számoláshoz most már késő van... :roll:
Title: Re: Tesztelés
Post by: Tutus on 2016.December.28. 07:18:56
Régen szerettem volna már ezt megnézni, de csak most jutottam el idáig. Viszont mielőtt bármi konkrétumot is írnék; itt egy találós kérdés:

Mi van a képen? :)

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161227_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_001.jpg)

Ez zseniális! :smt038 És újból lehetne egy szuper hardver fejlesztés EP-re! :)
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.28. 07:27:46
256 szín módban mit csinál?
GRAPHICS HIRES 256 és utána a SET PALETTE és SET BIAS utasításoknak van-e hatása a téglalapokra? Vagyis ezeket használja, vagy fixen az első 16 színt?
Title: Re: Tesztelés
Post by: geco on 2016.December.28. 10:54:45
:smt041 :smt041 :smt041
Kíváncsian várom a végét :) Ha lesz kész hw, egyre beneveznék.
Title: Re: Tesztelés
Post by: endi on 2016.December.28. 12:15:22
de ez most ügye nem az a titokzatos "sprite" dolog?

ez lényegében egy memóriatartalmat rak ki, lyukasztással, az ep videó jelére?
lehet itt is felbontásokat állítani meg ilyesmit? mert ügye egy hires2 felbontású 256 színű mód az kb csak kép megjelenítésre alkalmas, még egy turbós z80-on is :)
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.28. 12:56:31
De, ez a sprite dolog első lépése. Ha már tudunk képet beadni a Nick-nek, az már csak "részlet" kérdés, hogy sprite legyen :-)
Ott nyilván nem az egész képernyő lenne külső, hanem egy-egy kis terület.
Title: Re: Tesztelés
Post by: ergoGnomik on 2016.December.28. 12:58:33
de ez most ügye nem az a titokzatos "sprite" dolog?

ez lényegében egy memóriatartalmat rak ki, lyukasztással, az ep videó jelére?
lehet itt is felbontásokat állítani meg ilyesmit? mert ügye egy hires2 felbontású 256 színű mód az kb csak kép megjelenítésre alkalmas, még egy turbós z80-on is :)
Igen is meg nem is. A "sprite" általában pontosan annyit tud, hogy egy memória tartalmat rak ki lyukasztással a videó jelre. Itt még csak egy kísérleti hardver van összeütve, amin balagesz méricskél és finomhangol. Amikor elkészül akkor majd nagyot fog szólni a dolog.

A felbontás állítás lehetősége attól függ, hogy a nagyérdemű szeretné-e vagy sem. balagesz simán beleprogramozza az ezerlábú vastag fekete bélyegbe amit az úri közönség szeretne. Nincs szó 256 színű módról. Ez csak azt a 16 (8+bias) paletta színt tudja használni, ami az éppen megjelenített LPB-kbe van programozva. Viszont – gondolom én – a Z80-at ez nem fogja lassítani a memóriájához hozzáféréskor a NICK-kel ellentétben. Igazából lehetne egy fullos 16 színű videó kártyát is csinálni ebből, a NICK csak a palettát szolgáltatná, meg kitenne háttérnek valami statikus dolgot.
Title: Re: Tesztelés
Post by: IstvanV on 2016.December.28. 13:08:46
46x4, azaz a normál 16 szín módhoz képest 4x felbontás, azaz 4x több pixel.

Ezzel a programmal meg lehet jeleníteni ilyen képet, de természetesen nem tudtam kipróbálni azon kívül, hogy nem fagy le:
[attachurl=1]
[attachurl=2]

Konvertálás:
Code: [Select]
epimgconv -mode 4 -size 184 276 -quality 1 -scale 4 1 -outfmt 1 file.jpg 736x276.pic
Az egyik paletta szín átlátszóvá is tehető a forráskód elején a TRANSPARENT_COLOR állításával.
Title: Re: Tesztelés
Post by: IstvanV on 2016.December.28. 13:36:54
De, ez a sprite dolog első lépése. Ha már tudunk képet beadni a Nick-nek, az már csak "részlet" kérdés, hogy sprite legyen :-)
Ott nyilván nem az egész képernyő lenne külső, hanem egy-egy kis terület.

Az is egy lehetőség, hogy a háttér legyen külső, a sprite pedig normál NICK grafika (szerk.: ez csak 16 színű módban működne jól, ahol a NICK pixelek átlátszóak lehetnek ha a felső 8 színt használnák). A már meglevő hardvert valószínűleg könnyen lehetne módosítani, hogy a kép scrollozható legyen, ha a számlálókat 0 helyett programozható értékekkel töltené újra.
Title: Re: Tesztelés
Post by: balagesz on 2016.December.28. 17:13:11
Akkor sorban...

256 szín módban mit csinál?
GRAPHICS HIRES 256 és utána a SET PALETTE és SET BIAS utasításoknak van-e hatása a téglalapokra? Vagyis ezeket használja, vagy fixen az első 16 színt?

#0: Itt a tegnapi első kép:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161227_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_001.jpg)

#1: GRAPHICS HIRES 256 (Ez, és a többi kép már FullHD :) (920×576 pixel) felbontású, ekkora a digitalizáló maximális felbontása.)

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161228_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161228_001.jpg)

#2: SET BIAS 55

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161228_002s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161228_002.jpg)

#3: SET PALETTE 11,22,33,44,55,66,77,88

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161228_003s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161228_003.jpg)

Kíváncsian várom a végét :) Ha lesz kész hw, egyre beneveznék.

Hehe... :) Ez egyelőre csak egy teszt. Ha lesz kész HW, annak egyelőre a funkcióit is ki kellene találni. :oops:

Nincs szó 256 színű módról. Ez csak azt a 16 (8+bias) paletta színt tudja használni, ami az éppen megjelenített LPB-kbe van programozva. Viszont – gondolom én – a Z80-at ez nem fogja lassítani a memóriájához hozzáféréskor a NICK-kel ellentétben.

Innen nem lesz 256 színű mód, ez tulajdonképpen várható is volt, viszont ettől függetlenül ez egy picit csalódás a számomra. :oops: Ugyanis a sprite-ok egyik lényege pont az lenne, hogy az alap háttértől teljesen független pixeleket lehet kipakolni, és ez vonatkozik a színekre is... :| Így viszont minden külső pixel színe függ a beállított palettától / biastól. A tökéletes megoldás (szerintem) az lett volna, ha a kívülről bepakolt szín-információ kikerüli a NICK egész palettázós részét, és közvetlenül ki is jut a megfelelő szűrések után a színkimenetre. Ez persze úgy lenne az igazi, ha 8 színbemenet lenne, lehet hogy nincs +4 szabad láb már a NICK-en. De akár a felbontás felezését is el tudnám fogadni, hogy a 4 vezetéken 2 lépésben lehetne betolni a 8 bitet... Sőt, ezt ennél egyszerűbben is el tudom képzelni: a NICK-ből csak egy "csere" vonal jönne ki, és egy egyszerű külső logika cserélné a gépen kívülről jövő színre a NICK színét. Na de ez a hajó elúszott, vagy hogy is fogalmazzak. :)

Amúgy igen, ennek a memóriának a Z80 felőli elérése nem lassítja a CPU-t. Most ronda módon ha a Z80 ír/olvas, akkor a videótól egyszerűen elveszem a RAM-ot arra az időre, így ilyenkor a kép szépen "havazik", ha már a természet nem képes erre Karácsony után, legalább a feeling legyen meg. :-D

Ezzel a programmal meg lehet jeleníteni ilyen képet, de természetesen nem tudtam kipróbálni azon kívül, hogy nem fagy le:
(Attachment Link)
(Attachment Link)

Konvertálás:
Code: [Select]
epimgconv -mode 4 -size 184 276 -quality 1 -scale 4 1 -outfmt 1 file.jpg 736x276.pic
Az egyik paletta szín átlátszóvá is tehető a forráskód elején a TRANSPARENT_COLOR állításával.

Egy gyors teszt, bár lehet (?) hogy nem a legjobb képet választottam alanynak:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161228_004s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161228_004.jpg)

A lila-hibát ezen is mintha látnám... :) Itt is zizeg néhány pixel a képen, nem csak a RAM-szemétnél, de ez is várható volt tulajdonképpen. Viszont a tippelt időket tologatva, továbbra is változatlan a zizegés, amit azért furcsállok. Lehet hogy a géppel is van valami nyűg? (Annak idején nézegettem ezt, mintha Zozo rakott volna fel egy olyan tesztprogramot, ami sima 1 pixeles pöttyöket pakolt volna ki a képre. Mintha ott is "hunyorogtak volna a csillagok", de ezt betudtam a sok D/A-A/D átalakításnak, nem rendes CRT-n néztem.)

Az is egy lehetőség, hogy a háttér legyen külső, a sprite pedig normál NICK grafika (szerk.: ez csak 16 színű módban működne jól, ahol a NICK pixelek átlátszóak lehetnek ha a felső 8 színt használnák). A már meglevő hardvert valószínűleg könnyen lehetne módosítani, hogy a kép scrollozható legyen, ha a számlálókat 0 helyett programozható értékekkel töltené újra.

Ez a "pixel-prioritásos" dolog is tesztelendő amúgy. :) A szkrollozást pofon-egyszerű lenne megcsinálni (mint ahogy a kiírási pozíció visszaolvashatóságát is), csak most csináljak látványos finom-szkrollt egy teszthardverben a többiek idegeinek a borzolására? :evil: :cool:
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.28. 17:38:53
Akkor sorban...
Szóval akkor, logikus módon a külső színek mindig a 16 színű palettán mennek át.


Quote
Hehe... :) Ez egyelőre csak egy teszt. Ha lesz kész HW, annak egyelőre a funkcióit is ki kellene találni. :oops:
Igaz :-) De mik a lehetőségek a fekete ezerlábúak birodalmában? :ds_icon_cheesygrin:
Ez valami "proci" amin program fut? Vagy csak logikai kapuk vannak pakolgatva?
Programként viszonylag egyszerűen el tudja képzelni az ember... de fut az elég gyorsan, hogy pixelről pixelre meg tudja oldani a dolgot?
Kapukból összerakva el nem tudom képzelni a dolgot :oops:


Quote
Innen nem lesz 256 színű mód, ez tulajdonképpen várható is volt, viszont ettől függetlenül ez egy picit csalódás a számomra.
Viszont nekünk a 16 szín értelmes felbontással, az már hatalmas királyság! :ds_icon_cheesygrin:


Quote
A lila-hibát ezen is mintha látnám... :) Itt is zizeg néhány pixel a képen, nem csak a RAM-szemétnél, de ez is várható volt tulajdonképpen. Viszont a tippelt időket tologatva, továbbra is változatlan a zizegés, amit azért furcsállok. Lehet hogy a géppel is van valami nyűg? (Annak idején nézegettem ezt, mintha Zozo rakott volna fel egy olyan tesztprogramot, ami sima 1 pixeles pöttyöket pakolt volna ki a képre. Mintha ott is "hunyorogtak volna a csillagok", de ezt betudtam a sok D/A-A/D átalakításnak, nem rendes CRT-n néztem.)
Az elmesélés alapján egyre gyanúsabb, hogy régi Nick chipes a géped :oops:

Quote
csak most csináljak látványos finom-szkrollt egy teszthardverben a többiek idegeinek a borzolására? :evil: :cool:
Igen! :twisted:
Title: Re: Tesztelés
Post by: endi on 2016.December.28. 18:26:28
A felbontás állítás lehetősége attól függ, hogy a nagyérdemű szeretné-e vagy sem. balagesz simán beleprogramozza az ezerlábú vastag fekete bélyegbe amit az úri közönség szeretne. Nincs szó 256 színű módról. Ez csak azt a 16 (8+bias) paletta színt tudja használni, ami az éppen megjelenített LPB-kbe van programozva. Viszont – gondolom én – a Z80-at ez nem fogja lassítani a memóriájához hozzáféréskor a NICK-kel ellentétben. Igazából lehetne egy fullos 16 színű videó kártyát is csinálni ebből, a NICK csak a palettát szolgáltatná, meg kitenne háttérnek valami statikus dolgot.

hát felbontásnak azért lenne értelme, mert ügye a z80 nem fog tudni hatalmas adatmezőket mozgatni mint spriteok...

de ha jól értem ez a hw bármit tudhat, szóval akár egy geforce videókártya is lehet :)

ami engem érdekel hogy mi az amit itt az EP tud? erről a "színbemenetről" mixel és lyukaszt bármit?
Title: Re: Tesztelés
Post by: IstvanV on 2016.December.28. 18:39:34
Egy gyors teszt, bár lehet (?) hogy nem a legjobb képet választottam alanynak:

Nem jó a program, el van csúszva a kép az LPT-hez képest, azért ennyire csíkos. :oops: De talán az Y_OFFSET állításával javítani lehet, mivel az alsó 1 sorban szemét látható, eggyel növelni kellene.

Quote
A lila-hibát ezen is mintha látnám... :) Itt is zizeg néhány pixel a képen, nem csak a RAM-szemétnél, de ez is várható volt tulajdonképpen. Viszont a tippelt időket tologatva, továbbra is változatlan a zizegés, amit azért furcsállok.

A lila színhiba mindig látható az LM1886-ot használó video kimeneteken. Nem tudom, hogy az LM1886 ilyen rossz minőségű, vagy a NICK digitális kimenetével (annak időzítésével, stb.) van valamilyen probléma. A zizegés is a NICK hibája lehet, ezeken a régebbi képeken (1 (https://enterpriseforever.com/hardver/milyen-ep-konfigod-van/?action=dlattach;attach=6145;image), 2 (https://enterpriseforever.com/hardver/milyen-ep-konfigod-van/?action=dlattach;attach=6147;image), 3 (https://enterpriseforever.com/hardver/milyen-ep-konfigod-van/?action=dlattach;attach=6149;image), 4 (https://enterpriseforever.com/hardver/milyen-ep-konfigod-van/?action=dlattach;attach=6151;image), 5 (https://enterpriseforever.com/hardver/milyen-ep-konfigod-van/?action=dlattach;attach=6153;image), 6 (https://enterpriseforever.com/hardver/milyen-ep-konfigod-van/?action=dlattach;attach=6155;image)) is látható néhány véletlenszerűen hiányzó pixel. Érdekes, hogy az 56-199 színátmenet lila hibát eredményez, a 0-56 viszont nem.
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.28. 18:48:07
ami engem érdekel hogy mi az amit itt az EP tud? erről a "színbemenetről" mixel és lyukaszt bármit?
Az EXTC jel jelzi a NICK-nek, hogy a külső színt használja. Mondhatjuk, hogy ez a lyukasztó :-)
Azonban ezt lehet még szabályozni, erre szolgál az a bizonyos SPRITE EXOS változó, ami Nick 80h port 5-6 bitjét állítja.
-feltétel nélkül a külső szín jelenik meg
-külső szín jelenik meg, ha a belső szín 8-15
-külső szín jelenik meg, ha a belső szín 8-15 vagy ha a külső szín 0-7
-külső szín jelenik meg, ha a belső szín 8-15 vagy ha a külső szín 0-3, 8-11

Így lehet 3 réteg is: BIAS színű háttér előtt látszanak a sprite-ok, de az alap színekkel rajzolt dolgok eltakarják őket.
Title: Re: Tesztelés
Post by: endi on 2016.December.28. 19:07:29
Az EXTC jel jelzi a NICK-nek, hogy a külső színt használja. Mondhatjuk, hogy ez a lyukasztó :-)
Azonban ezt lehet még szabályozni, erre szolgál az a bizonyos SPRITE EXOS változó, ami Nick 80h port 5-6 bitjét állítja.
-feltétel nélkül a külső szín jelenik meg
-külső szín jelenik meg, ha a belső szín 8-15
-külső szín jelenik meg, ha a belső szín 8-15 vagy ha a külső szín 0-7
-külső szín jelenik meg, ha a belső szín 8-15 vagy ha a külső szín 0-3, 8-11

Így lehet 3 réteg is: BIAS színű háttér előtt látszanak a sprite-ok, de az alap színekkel rajzolt dolgok eltakarják őket.

húú ez tök jó! akkor újabb EP-s dolgot értettem meg :)
félő hogy nem lesz több titok...
kár hogy nem lehetett ezt kihasználni hw hiányában... olyat esetleg csinálhattak volna igazán, hogy 2 EP összekötésével valahogy...
Title: Re: Tesztelés
Post by: balagesz on 2016.December.28. 21:04:03
Nem jó a program, el van csúszva a kép az LPT-hez képest, azért ennyire csíkos. :oops: De talán az Y_OFFSET állításával javítani lehet, mivel az alsó 1 sorban szemét látható, eggyel növelni kellene.

Ugyan máshogy csináltam, de sokkal jobb lett:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161228_005s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161228_005.jpg)

Érdekes, hogy az 56-199 színátmenet lila hibát eredményez, a 0-56 viszont nem.

Ez akkor ki is derült? Hogy ezek a színátmenetek okozzák a furcsaságot?

De mik a lehetőségek a fekete ezerlábúak birodalmában? :ds_icon_cheesygrin:
Ez valami "proci" amin program fut? Vagy csak logikai kapuk vannak pakolgatva?

Ez pusztán logikai kapukból, no meg egy adag tárolóból áll. Nincs benne semmi "okosság".

Az elmesélés alapján egyre gyanúsabb, hogy régi Nick chipes a géped :oops:

Itt van róla (http://bsz.amigaspirit.hu/blpcs/20150816/pic0291.jpg) egy közeli kép. Ez szerintem az új, re majd te eldöntöd! ;)

Igen! :twisted:

Csak neked! (http://bsz.amigaspirit.hu/Enterprise/epECtest1.mp4) :cool: (Szerk.: Felért.)
Title: Re: Tesztelés
Post by: endi on 2016.December.28. 22:35:11
ezeket a képeket nem látom jobbnak, mint amit attr+raszterenkénti színezésből ki tudunk hozni.
az a helyzet hogy az attr mód egy okos dolog, hiszen úgy tömöríti a színeket ahogy pl a jpg meg a videó tömörítések, azaz kevesebb bitet ad a színeknek. az emberi szem ugyanis a fényesség változásokra érzékenyebb, mint a szín változásora.

tehát állóképekre szerintem nem lesz sokkal jobb ez a hw cucc
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.28. 23:10:17
Ez szerintem az új, re majd te eldöntöd! ;)
Igen ez a új!

Quote
Csak neked! (http://bsz.amigaspirit.hu/Enterprise/epECtest1.mp4) :cool: (Szerk.: Felért.)
Nem semmi!

Viszont azok a villogó lila pöttyök érdekesek... SCART kábellel nem tudnád megnézni?
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.28. 23:12:59
tehát állóképekre szerintem nem lesz sokkal jobb ez a hw cucc
Attól függ milyen képekre. Ahol finomabb, élesebb részletek is vannak, ott tuti kijönne a különbség.
Title: Re: Tesztelés
Post by: IstvanV on 2016.December.28. 23:13:33
ezeket a képeket nem látom jobbnak, mint amit attr+raszterenkénti színezésből ki tudunk hozni.

Itt azért valószínűleg a TV kimenet is korlátozza a minőséget, RGB-n ennél jobb lehetne. :) És a kép nem interlace módú, tehát csak a vízszintes felbontása nagy.
Title: Re: Tesztelés
Post by: balagesz on 2016.December.28. 23:34:49
Nem semmi!

Ráadásul mintha el is rontottam volna a felvételt... Mennyi IRQ fut le egy frame alatt alapból? :)

Viszont azok a villogó lila pöttyök érdekesek... SCART kábellel nem tudnád megnézni?

Hát, ... nem. :| A tápegység, amit használok, túlzottan be van építve a helyére, egy óra míg kiszedem onnan. Ugyanannyi visszarakni. :) RGB kábelem egyelőre nincs, de azt még megoldanám... Viszont a TV-t ide nem cipelem, az tuti! :razz: Szóval egyszer majd megnézem.

Itt azért valószínűleg a TV kimenet is korlátozza a minőséget, RGB-n ennél jobb lehetne. :) És a kép nem interlace módú, tehát csak a vízszintes felbontása nagy.

Valahonnan szerezni kéne valami olyan digitalizáló cuccot, ami tud RGB-t is. Ilyen "filléres" árban ilyesmi nem jött velem még szembe, sajnos...

A mozgatáshoz lett amúgy két beállítható regiszter, egy 10 bites a vízszintesnek, egy 9 bites meg a függőlegesnek. A 05h I/O címen lehet beállítani a vízszintes kezdőpozíció B7..0 részt, a 06h I/O címen meg a függőleges B7..0 részét. A 07h címre került a maradék, a B10 a vízszintes B98 része, a B7 meg a függőleges B8. Talán érdemes lett volna 16 bites címzést használni, így egy utasítással be lehetne állítani a 10 / 9 bitet, csak azt szerintem BASIC-ből nem lehet kezelni. A beállított értékek a számlálók kezdő pozíciói, tehát ha növelem az értéket, akkor balra / fölfele mozdul a kép.
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.29. 00:05:36
Az is egy megoldás, ha a teszt cuccból csinálsz egyet nekem is :ds_icon_cheesygrin:
Title: Re: Tesztelés
Post by: ergoGnomik on 2016.December.29. 12:40:33
ezeket a képeket nem látom jobbnak, mint amit attr+raszterenkénti színezésből ki tudunk hozni.
az a helyzet hogy az attr mód egy okos dolog, hiszen úgy tömöríti a színeket ahogy pl a jpg meg a videó tömörítések, azaz kevesebb bitet ad a színeknek. az emberi szem ugyanis a fényesség változásokra érzékenyebb, mint a szín változásora.

tehát állóképekre szerintem nem lesz sokkal jobb ez a hw cucc
De "ügye":
A) ez nem állóképekről szól, ennek a többé-kevésbé független mozgó objektumok a lényege;
B) okosan megválasztott palettával és ügyes dithereléssel viszont a több, mint 16 szín illúzióját lehet kelteni a nagy felbontás kihasználásával. (De hogy ezt miért magyarázom pont neked?)
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 12:58:15
na ez az érdekes, hogy hogy lesz ebből mozgó objektumok, sprite-ok?
persze önmagában már az is nagy dolog hogy a háttérrel nem kell foglalkozni a sprite-ok kirakásakor és mozgatásakor. ez esetben ügye ez a hw adná a hátteret, a z80-al meg az eddigi szokásoknak megfelelően rajzolnánk a sprite-okat.
gondolom ezt a legegyszerűbb megoldani.

amúgy ez most c16 felbontásnak megfelelő? vagy c4 (vagy attr) felbontásnak? esetleg a max felbontás?
a felbontás azért számíthat, hiszen a z80 fogja kirajzolni a hátteret, és ügye minél nagyobb a felbontás, annál lassabb lesz ez...
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.29. 13:40:12
na ez az érdekes, hogy hogy lesz ebből mozgó objektumok, sprite-ok?
Ugyanez kell, csak kisebb méretben, mitomén mondjuk pl 32x16-os, és annak meg mondani a bal felső sarkát hova rakja ki. Aztán a Z80-nak már csak ezt a koordinátát kell módosítani. És aztán ilyenből kell x darab.


Quote
persze önmagában már az is nagy dolog hogy a háttérrel nem kell foglalkozni a sprite-ok kirakásakor és mozgatásakor. ez esetben ügye ez a hw adná a hátteret, a z80-al meg az eddigi szokásoknak megfelelően rajzolnánk a sprite-okat.
gondolom ezt a legegyszerűbb megoldani.
Igen.

Quote
amúgy ez most c16 felbontásnak megfelelő? vagy c4 (vagy attr) felbontásnak? esetleg a max felbontás?
Max (2 színűnek megfelelő) felbontás. De ez könnyedén lehet beállítható is, azaz lehet kisebb is.
Title: Re: Tesztelés
Post by: ergoGnomik on 2016.December.29. 13:51:45
na ez az érdekes, hogy hogy lesz ebből mozgó objektumok, sprite-ok?
persze önmagában már az is nagy dolog hogy a háttérrel nem kell foglalkozni a sprite-ok kirakásakor és mozgatásakor. ez esetben ügye ez a hw adná a hátteret, a z80-al meg az eddigi szokásoknak megfelelően rajzolnánk a sprite-okat.
gondolom ezt a legegyszerűbb megoldani.

amúgy ez most c16 felbontásnak megfelelő? vagy c4 (vagy attr) felbontásnak? esetleg a max felbontás?
a felbontás azért számíthat, hiszen a z80 fogja kirajzolni a hátteret, és ügye minél nagyobb a felbontás, annál lassabb lesz ez...
SZVSZ szprájt nagyjából hasonlóan lesz, mint pl. C64-en. Betöltesz ennek a bővítőnek a memóriájába valami támogatott méretű – ami majd egyszer kiforrja magát, vagyis balagesz kifőzi az igényeitek és a lehetőségek alapján – képecskét, megmondod melyik koordinátákon szeretnéd látni, és az ügyeket intéző része majd jól odakeni a képre. Nem a Z80 rajzolgatja, mert a CPU-t értelmes dolgokra kell tartogatni, a kuli munkát végezze a célhardver. Ez sosem a hátteret adta volna, hanem a NICK által rajzolt háttértől függetlenül mozgó alakzatokat. Amik lehetnek a háttér előtt vagy mögött, az üzemmódtól és az alakzat színeitől (pontosabban paletta indexétől) függően. Ezek szerint amikor tegnap este úgy vélted megértetted, akkor lehet hogy igazából mégsem.

Pillanatnyilag ez a maximálisan elérhető felbontás – szerintem – amit két színű és PIXEL mód kiválasztásával lehet elérni. De majd a mesterek kijavítanak.
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 14:47:05
na de ez az, hogyha csináltok egy sprite hardvert, akkor ennyi erővel ráköthetünk bármit... egy mai videókártyát is :)
és hát jön az elvi kérdés, hogy mi legyen ez a hw? a megszokás és a retro miatt x*y és x darab sprite? :) miért nem 3d? :)

zozo, ha max felbontás, akkor az durva! :) akkor tényleg jobbat lehet mint attr módban. de erre mondtam hogy ez csak állóképre jó, hiszen ezen mozgatni sprite-okat azért ahhoz erős hw kell...
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.29. 14:58:08
zozo, ha max felbontás, akkor az durva! :) akkor tényleg jobbat lehet mint attr módban. de erre mondtam hogy ez csak állóképre jó, hiszen ezen mozgatni sprite-okat azért ahhoz erős hw kell...
A külső és belső felbontásnak semmi köze egymáshoz. Vagyis amit a Nick csinálna az teljesen szokásos lenne.
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 15:04:39
A külső és belső felbontásnak semmi köze egymáshoz. Vagyis amit a Nick csinálna az teljesen szokásos lenne.

na jó de ez a célhw mozgatná a sprite-okat akkor erősnek kell lennie, ekkora felbontáshoz
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.29. 15:05:27
Ez sosem a hátteret adta volna, hanem a NICK által rajzolt háttértől függetlenül mozgó alakzatokat.
Ez eredetileg így van. Azonban a mai hardverekkel elérhetővé vált, hogy akár teljes képernyőt is odarakjon a cucc.
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.29. 15:06:59
na jó de ez a célhw mozgatná a sprite-okat akkor erősnek kell lennie, ekkora felbontáshoz
Pont ez a trükk, hogy nem kell mozgatni! Csak koordinátákat kell átírni.
Title: Re: Tesztelés
Post by: ergoGnomik on 2016.December.29. 15:07:04
na de ez az, hogyha csináltok egy sprite hardvert, akkor ennyi erővel ráköthetünk bármit... egy mai videókártyát is :)
és hát jön az elvi kérdés, hogy mi legyen ez a hw? a megszokás és a retro miatt x*y és x darab sprite? :) miért nem 3d? :)

zozo, ha max felbontás, akkor az durva! :) akkor tényleg jobbat lehet mint attr módban. de erre mondtam hogy ez csak állóképre jó, hiszen ezen mozgatni sprite-okat azért ahhoz erős hw kell...
Akkor viszont most el kellene dönteni, hogy legyen hardver bővítés vagy sem? Egyébként meg nem igazán tudsz ide rákötni bármit. Ez a bemenet amit balagesz bizerget pontosan ennyire való. Leginkább n darab x*y méretű sprite belekeverésére a NICK képébe, bár felhasználható abban a módban is amiben a teszt hardver üzemel.

Nem csak állóképre jó. El kell felejteni azt, ahogyan Z80-nal softsprite-ot csinálsz. Ide kicsit erős, de inkább okos hardver kell. Pont mint a C64-ben. A VIC-II sem egy iszonyú lóerőgyár, abból a nem sok tranzisztorból (néhány ezerről van szó), amit akkoriban gazdaságosan bele lehetett gyártani egy IC-be nem lehet sok teljesítményt kihúzni, főleg nem 1 MHz-en. És nem kell aggódnod, balagesz szerintem elég jól képben van mire lesz szükség, elég erős lesz a vas.
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 15:24:21
Pont ez a trükk, hogy nem kell mozgatni! Csak koordinátákat kell átírni.

hát ha megfelelő hw van alatta, megfelelő beégetett sw-vel :P
Title: Re: Tesztelés
Post by: balagesz on 2016.December.29. 16:10:22
Az is egy megoldás, ha a teszt cuccból csinálsz egyet nekem is :ds_icon_cheesygrin:

Ú, ... máris csinálom az RGB kábelt meg cipelem a TV-t... Pillanat... :-D (A fő probléma az, hogy itt is egy régebbi céges kártyát programoztam át ideiglenesen a feladatra. :| )

Viszont lett egy ötletem, csináltam is róla képeket!

#1: Sima kép, de az SVIDEO jelből csak a Luma (világosságjel) van használva, "lila"hiba + pixelzizegéssel együtt:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161229_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161229_001.jpg)

A színhiányon kívül semmi változás, a zizegés is megvan.

#2: Ugyancsak monokróm kép, de ez a gép eredeti fekete-fehér kimenete, aminek az előállításában nem vesz részt semmilyen módon az LM1886+LM1889:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20161229_002s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161229_002.jpg)

Lila-színhibára utaló nyomok: semmi, zizegés: semmi! Az egész problémát az LM1886/LM1889 okozza! Remek... :) Gyorsan (majdnem...) csináltam erről is egy mozgós videót, erre tessék (http://bsz.amigaspirit.hu/Enterprise/epECtest2.webm)!

Nem jó a program, el van csúszva a kép az LPT-hez képest, azért ennyire csíkos. :oops: De talán az Y_OFFSET állításával javítani lehet, mivel az alsó 1 sorban szemét látható, eggyel növelni kellene.

Megcsináltam az Y_OFFSET növelését is, jó is lett egyből. :) Arra azért kíváncsi lennék, hogy az X/Y Offset értéket "hogy találtad ki"? Mintha már láttál volna EP-t... :mrgreen:

Pont ez a trükk, hogy nem kell mozgatni! Csak koordinátákat kell átírni.

No, ez azért még igencsak messze van... :-P

El kell felejteni azt, ahogyan Z80-nal softsprite-ot csinálsz. Ide kicsit erős, de inkább okos hardver kell.

Ez így igaz. Ilyen felbontáson annyi adat van, hogy szerencsétlen Z80 még masszív turbóval se bírná.
Title: Re: Tesztelés
Post by: IstvanV on 2016.December.29. 16:26:15
Arra azért kíváncsi lennék, hogy az X/Y Offset értéket "hogy találtad ki"?

A második kép (https://enterpriseforever.com/hardver/teszteles/msg61136/#msg61136) alapján, ha nem is egészen pontosan. :)
Title: Re: Tesztelés
Post by: balagesz on 2016.December.29. 17:35:37
A második kép (https://enterpriseforever.com/hardver/teszteles/msg61136/#msg61136) alapján, ha nem is egészen pontosan. :)

Na, erre nem gondoltam! Nem semmi! :)
Title: Re: Tesztelés
Post by: geco on 2016.December.29. 18:29:48
Nagyon jó, már a mostani állapotot is lehetne használni, mondjuk egy mega pixelenként oldalra scrollozó program megírására, ahol a hátteret a sprite hw adja, és a sprite-okat meg a normál Nick grafika.
A pixelenkénti scroll bemutató nagyon tetszett :)
Title: Re: Tesztelés
Post by: geco on 2016.December.29. 18:55:58
Collision detection is megoldható, vagy ahhoz már durva hw kéne? És van-e értelme?
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 19:02:43
Collision detection is megoldható, vagy ahhoz már durva hw kéne? És van-e értelme?

szerintem az se egyszerű hogy több sprite van. mert ha csak egy akkor azt könnyű offsetelni ügye (mintha hw scroll lenne), de ha több akkor már nem ilyen egyszerű... főleg ha egymással fedésbe kerülnek ügye...
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 19:11:36
amúgy milyen gyorsan lehet ebbe a memóriába írni? egy pálya kirajzolás azért időbe tellhet...
Title: Re: Tesztelés
Post by: IstvanV on 2016.December.29. 19:41:22
amúgy milyen gyorsan lehet ebbe a memóriába írni? egy pálya kirajzolás azért időbe tellhet...

Egy 640x200 méretű kép 128000 byte, az egészet kiírni LDI utasításokkal kb. fél másodperc lenne. De ahhoz még elég gyors a CPU, hogy scrollozáskor a belépő sorokat vagy oszlopokat feltöltse.
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 20:43:00
Egy 640x200 méretű kép 128000 byte, az egészet kiírni LDI utasításokkal kb. fél másodperc lenne. De ahhoz még elég gyors a CPU, hogy scrollozáskor a belépő sorokat vagy oszlopokat feltöltse.

csak mint érdekesség érdekel hogy mennyivel lassabb mint a belső mem?
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.29. 20:51:48
csak mint érdekesség érdekel hogy mennyivel lassabb mint a belső mem?
Jelenleg semmivel.
Title: Re: Tesztelés
Post by: nyuzga on 2016.December.29. 20:57:36
"A kísérlet az kísérlet."

Software és játék kéne erre a gépre. Jók ezek a kísérletek, de akkor már írjatok PC-re. Szart sem ér egy gép, ha nincs rá szoftware.
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 21:14:32
Jelenleg semmivel.

na az tök jó

amúgy emlékszem amikor gameboy advanced-re csináltunk játékot, ott olyan volt a sprite hogy sokat meg tudott jeleníteni, de egy rasztersorban csak valami 8-at (több mindentől függött, de valami ilyesmi).
Title: Re: Tesztelés
Post by: geco on 2016.December.29. 22:17:37
Software és játék kéne erre a gépre. Jók ezek a kísérletek, de akkor már írjatok PC-re. Szart sem ér egy gép, ha nincs rá szoftware.
Nem értem, van több, mint 1000 :ds_icon_cheesygrin:
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 22:20:37
Nem értem, van több, mint 1000 :ds_icon_cheesygrin:

az imádott specy átíratok... :)
Title: Re: Tesztelés
Post by: endi on 2016.December.29. 22:30:41
amúgy ez az external color input ez nem lassítja a rendszert?
ki-be lehet kapcsolni?
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.29. 22:35:47
amúgy ez az external color input ez nem lassítja a rendszert?
Nem.

Quote
ki-be lehet kapcsolni?
Ha úgy van megtervezve :-) Ami célszerű :-)
Title: Re: Tesztelés
Post by: balagesz on 2016.December.29. 22:56:41
Collision detection is megoldható, vagy ahhoz már durva hw kéne? És van-e értelme?

A bővítő porton nincs semmi, ami alapján el lehetne dönteni, hogy a NICK milyen pixeleket pakol ki a kimenetére. Így a háttérrel való ütközésdetektálás szerintem nem oldható meg.

csak mint érdekesség érdekel hogy mennyivel lassabb mint a belső mem?

Ahogy Zozo is írja, semmivel, de ez esetleg cél is kell majd, hogy legyen. De ahogy látom, azért beindult a fantázia rendesen... :-D
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.29. 23:11:56
A bővítő porton nincs semmi, ami alapján el lehetne dönteni, hogy a NICK milyen pixeleket pakol ki a kimenetére. Így a háttérrel való ütközésdetektálás szerintem nem oldható meg.
Na és ha a háttér is kintröl jön?

Quote
De ahogy látom, azért beindult a fantázia rendesen... :-D
És még nem is írtam le mindent :-D

Elmélkedés: "ugyanilyen cucc csak kicsiben" azaz sprite méretben, a koordináta beírható módon. Ez idáig ha jól tippelem nem nagy ügy.
A probléma ott jön, hogy több is kéne ezekből. Egyrészt mi van ha egymáson vannak... adódik a priorítási sorrend. Ez tán úgy lenne legegyszerűbb, ha az EXTC jelével a magasabb priorítású az felülírni az alatta lévőket. Tán még ez se nagy gond.
A nagyobb gond az lenne, hogy a több sprite hogyan olvasná a memóriát egyszerre?
Ha jól sejtem ebből jön a kb az összes sprite rendszernél olvasható x sprite/scanline limit. Talán a keret ideje alatt olvassa be valami pufferbe a sprite adatokat, és aztán a képernyő idő alatt onnan dolgozik.
Esetleg egy rakás kicsi RAM chip mindnek külön-külön? :-)
Title: Re: Tesztelés
Post by: balagesz on 2016.December.29. 23:49:06
Na és ha a háttér is kintröl jön?

Hm... :) Mondjuk ezzel "bukod" az LPT-s sorrendezgetést, de persze lehet keverni a kettőt.

Elmélkedés: "ugyanilyen cucc csak kicsiben" azaz sprite méretben, a koordináta beírható módon. Ez idáig ha jól tippelem nem nagy ügy.

Nem, mert pont eddig van készen. :) (Ha a memóriát kitörlöd, csak egy "kicsi" részbe pakolsz képadatot, akkor oda is értünk. :) De azért ez így elég sovány lenne.)

A probléma ott jön, hogy több is kéne ezekből. Egyrészt mi van ha egymáson vannak... adódik a priorítási sorrend. Ez tán úgy lenne legegyszerűbb, ha az EXTC jelével a magasabb priorítású az felülírni az alatta lévőket. Tán még ez se nagy gond.

Itt csak fel kell állítani egy (célszerűen fix) sorrendet, aztán a "legutolsó" adata fog kikerülni a képre.

A nagyobb gond az lenne, hogy a több sprite hogyan olvasná a memóriát egyszerre?
Ha jól sejtem ebből jön a kb az összes sprite rendszernél olvasható x sprite/scanline limit. Talán a keret ideje alatt olvassa be valami pufferbe a sprite adatokat, és aztán a képernyő idő alatt onnan dolgozik.

Jól gondolod, a VIC-II pl. pontosan ezt csinálja, a keret alatt olvassa be előre a következő scanline adatait; ehhez egy (8...) akkora puffer kell, hogy a sprite-ok 1-1 rasztersora elférjen benne.

Esetleg egy rakás kicsi RAM chip mindnek külön-külön? :-)

Jaaa... :) Röhögni fogsz, nekem is eszembe jutott. Viszont nem túl alkatrészmennyiség-barát a megoldás. Meg nagy fogyasztás, felmelegedés, katasztrófa, mindmeghalunk™. :) Azt hiszem lassan le kellene írnom, hogy én mit tartok elképzelhetőnek. De előtte majd jól összeszedem a gondolataim, azt sem árt figyelembe venni, hogy ezt a valamit esetleg gyártani is lehessen... :razz:
Title: Re: Tesztelés
Post by: geco on 2016.December.30. 09:41:14
A bővítő porton nincs semmi, ami alapján el lehetne dönteni, hogy a NICK milyen pixeleket pakol ki a kimenetére. Így a háttérrel való ütközésdetektálás szerintem nem oldható meg.
jaja, az tiszta, én a sprite-ok utkozesere gondoltam :-)
Ha már álmodozás, állítható méretű sprite-ok, akár pixelenkenként, határ a csillagos ég, a teljes képernyő,esetleg a számláló egyszerűségekét 4 pixelenkenként :-D
ja, és zoom lehetőség a col2 és col16 felbontás között :-)
egyelőre ennyi, és lassan kiveszem a biliből a kezem :-D
Title: Re: Tesztelés
Post by: ergoGnomik on 2016.December.30. 10:51:21
Ebből teljes értékű 16 színű videókártya lesz még a végén. :smt043

Okleveles laikusként úgy érzem a prioritás vizsgálat melléktermékeként nagyjából automatikusan előáll az ütközés információ, ráadásul képpont szinten. Szóval ha csinálunk egy pepita mintát, amit két egymáshoz képest a pepita minta elemi szélességével vízszintesen eltolt sprite jelenít meg, akkor ezek nem generálnának ütközést. De ha csak egyetlen aktív képpontjuk is fedésbe kerül, akkor meg bejelez az ütközés figyelés.

Amit geco és talán endi pedzegetett, hogy kellene nagyítási lehetőség, az sem tűnik – mármint nekem kevéssé hozzáértőnek – bonyolultnak, inkább csak egy számláló kérdése, ami azt szabályozza mikor kezdje az adott sorban a sprite következő képpontját kitenni. Függőlegesen is hasonló lehet a helyzet, itt azt engedélyezi egy számláló lefutása, hogy a sprite adatainak következő sorára lépjen a motor.

Viszont ha a megvalósítás a kereten pufferbe beolvasással történik, akkor jó lesz valamilyen méretkorlátot vagy fix méretet felállítani. Azért is érdemes ezt figyelembe venni, mert abban a formában, amiben jelenleg meg van valósítva, a memória 3/8-a nincs kihasználva, noha így legalább egyszerű az alkalmazása. Ki lehet találni tömörebb formátumot, mint például 1 bájt átlátszósági maszk, amit követ 4 bájt képpont adat 8 darab 4 bites képpontként, illetőleg ennek valamilyen meghosszabbított változata (például a háromszorosa – 3 bájt átlátszóság, 12 bájt pixel – mivel az viszonylag jól illeszkedik egy szép 2n határra). Függőlegesen viszont nem biztos hogy kell limit, lehet az úgy is, mint az Amigánál (ha jól tudom, ott automatikusan nincs korlátozva a magasság, amíg nincs kikapcsolva, átparaméterezve vagy véget nem ér a képernyő, addig folyamatosan rakja ki a memóriából a kiolvasási szabály szerint következő sorokat).

Ezen kívül a pályarajzolás témakörében érdemes megfontolni egy karakteres képernyő jellegű megoldás bevezetését, természetesen nem feltétlenül ragaszkodva a 8 bites karakterkészlethez. És aki itt most felhorkan, hogy nehogy már csak karakteresen lehessen mozgatni a képernyőt, annak figyelmébe ajánlom a balagesz által készített szkrollozós videókat. Biztos vagyok benne, hogy semmi sem akadályozza meg őt abban, hogy ezt átültesse ilyen típusú képernyőszervezésre. Minden csak számlálók kérdése. :smt082
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.31. 10:54:49
Jaaa... :) Röhögni fogsz, nekem is eszembe jutott. Viszont nem túl alkatrészmennyiség-barát a megoldás. Meg nagy fogyasztás, felmelegedés, katasztrófa, mindmeghalunk™. :)
Ha egy marék CMOS SRAM-ot odaszórunk, az nem hinném hogy jelentős fogyasztás lenne.

Quote
Azt hiszem lassan le kellene írnom, hogy én mit tartok elképzelhetőnek.
Ez tényleg célszerű lenne, mielött nagyon elszáll a fantáziánk :-)
Title: Re: Tesztelés
Post by: endi on 2016.December.31. 11:29:58
nem létezik olyan kész hardver ami ezt a feladatot ellátja?
vannak ezek a rapsberry pi és hasonló cuccok, vannak köztük olyanok ha jól tudom (bár tökre nem értek a témához) amik direkt különféle "barkácsolós" kimenetekkel rendelkeznek.
vagy már maga ez a hw is ilyesmikből lesz/van összerakva?
amúgy egy fotó is érdekes lenne :)
Title: Re: Tesztelés
Post by: ergoGnomik on 2016.December.31. 12:03:46
Ha egy marék CMOS SRAM-ot odaszórunk, az nem hinném hogy jelentős fogyasztás lenne.
Ez tényleg célszerű lenne, mielött nagyon elszáll a fantáziánk :-)
A fogyasztás talán a legkisebb baj. Nagyobb probléma, hogy feleslegesen elbonyolítja a NYÁK-ot meg a VHDL/Verilog (nem tudom balagesz melyikben nyomja) kódot. Ez meg a fejlesztési időt nyújthatja feleslegesen hosszúra, főleg mivel úgy nehezebb megkeresni ha valami esetleg félresiklik. Ha sávszélesség kell, akkor szélesebb adatbuszt és/vagy nagyobb órajelet kell használni.

A fantázia elszálláson meg már szerintem most is túl vagyunk. :D

nem létezik olyan kész hardver ami ezt a feladatot ellátja?
vannak ezek a rapsberry pi és hasonló cuccok, vannak köztük olyanok ha jól tudom (bár tökre nem értek a témához) amik direkt különféle "barkácsolós" kimenetekkel rendelkeznek.
vagy már maga ez a hw is ilyesmikből lesz/van összerakva?
amúgy egy fotó is érdekes lenne :)
A RPi és társai pont nem jók ide. Vannak a programozható logikákhoz – gyanúm szerint ezt a tesztet is ilyennel végezte a mester – fejlesztő kártyák, de végleges termékekben a legritkább esetben használnak olyanokat. Oda terveznek és gyártanak külön célhardvert.
Title: Re: Tesztelés
Post by: endi on 2016.December.31. 12:21:14
A RPi és társai pont nem jók ide. Vannak a programozható logikákhoz – gyanúm szerint ezt a tesztet is ilyennel végezte a mester – fejlesztő kártyák,

aha ilyesmire gondoltam én is.
Title: Re: Tesztelés
Post by: balagesz on 2016.December.31. 22:00:11
jaja, az tiszta, én a sprite-ok utkozesere gondoltam :-)

Az mondjuk nem teljesen kizárt, hogy megoldható. Legfeljebb jár egy adag overheaddel. :)

Ebből teljes értékű 16 színű videókártya lesz még a végén. :smt043

Hehe... Mondjuk ezt pont el szerettem volna kerülni. :) Bár... :-D

Okleveles laikusként úgy érzem a prioritás vizsgálat melléktermékeként nagyjából automatikusan előáll az ütközés információ, ráadásul képpont szinten.

Ez megvalósítás kérdése, de szerintem nincs túl sok értelme "dinamikus" módon prioritást kezelni. Kell egy "felépítési sorrend", aztán az lesz a végén látható, amelyik utoljára marad. :)

Viszont ha a megvalósítás a kereten pufferbe beolvasással történik, akkor jó lesz valamilyen méretkorlátot vagy fix méretet felállítani.

Egyelőre itt még nem tartunk, de úgy érzem nem fogok én ragaszkodni a keret alatti felolvasáshoz...

Ki lehet találni tömörebb formátumot, mint például 1 bájt átlátszósági maszk, amit követ 4 bájt képpont adat 8 darab 4 bites képpontként, illetőleg ennek valamilyen meghosszabbított változata (például a háromszorosa – 3 bájt átlátszóság, 12 bájt pixel – mivel az viszonylag jól illeszkedik egy szép 2n határra).

Ez viszont jó ötlet is lehet, elrakom "későbbre".

Ezen kívül a pályarajzolás témakörében érdemes megfontolni egy karakteres képernyő jellegű megoldás bevezetését, természetesen nem feltétlenül ragaszkodva a 8 bites karakterkészlethez.

Toronyóra lánccal? :-D A karakteres képernyő egy meglehetősen bonyolult (az eddigi sima 16 színű grafikushoz képest...), persze hirtelen lett is egy-két ötletem. Ajjaj... :oops:

vagy már maga ez a hw is ilyesmikből lesz/van összerakva?
amúgy egy fotó is érdekes lenne :)

Fotót eddig azért nem csináltam, mert egy halom dróton kívül nincs túl sok látnivaló rajta:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20161231_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20161231_001.jpg)

Nyilván a "hanyatt" levő nyák lenne a lényeges, de azon egy 144 lábú CPLD-n meg egy 44 lábú SRAM-on kívül nincs semmi idevágó dolog.

Ha egy marék CMOS SRAM-ot odaszórunk, az nem hinném hogy jelentős fogyasztás lenne.

Persze, csak nehogy valami ilyesmi (http://tvc.homeserver.hu/html/pic/sprite/TVCsprite1.jpg) legyen a végeredmény! :razz:

Ez tényleg célszerű lenne, mielött nagyon elszáll a fantáziánk :-)

Ahogy nézem fantáziából azért tényleg nincs hiány! Ígérem, jövőre összeírom! ;) Az amúgy normális, hogy ez csak egy tesztnek indult, de szinte folyamatosan azon agyalok, hogy hova milyen alkatrészt kéne betervezni? :mrgreen:
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.31. 22:03:45
Az amúgy normális, hogy ez csak egy tesztnek indult, de szinte folyamatosan azon agyalok, hogy hova milyen alkatrészt kéne betervezni? :mrgreen:
Teljesen! :ds_icon_cheesygrin:
Title: Re: Tesztelés
Post by: endi on 2016.December.31. 22:07:55
talán off, de emlékszem gameboy advanced-en csinált a kóderünk sprite tömörítést, amit realtime tömörített ki, és gyorsabb lett mintha nem lenne tömörítés, ugyanis csökkent az adatátvitel!
(természetesen hw sprite volt itt is, ennek a tömörítés dolognak az animációnál volt értelme, azaz amikor újra és újra fel kellett tölteni az új anim fázist)
Title: Re: Tesztelés
Post by: Zozosoft on 2016.December.31. 22:22:13
Jaj tényleg, animációról még nem is álmodtunk :-)
Mondjuk a memóriában lehetnének egymás után a fázisok, és VSYNC-nél lépteti a mutatót. Beállítható, hogy hány fáziskép (mondjuk 2,4,8,16), az utolsó után visszaugrik az elejére. És az is állítható, hogy hány VSYNC után léptessen.
Elég nagyot álmodtam? :-D
Title: Re: Tesztelés
Post by: endi on 2016.December.31. 22:27:49
ugyan már, legyen már akkor 3d kártya :)
Title: Re: Tesztelés
Post by: balagesz on 2016.December.31. 22:40:55
Teljesen! :ds_icon_cheesygrin:

Akkor már nem csak a hangok mondják ezt? :-D

Jaj tényleg, animációról még nem is álmodtunk :-)
ugyan már, legyen már akkor 3d kártya :)

Á, nem ezeket a szavakat keresitek! Hanem azt, hogy: "kompromisszum"! :razz:
Title: Re: Tesztelés
Post by: endi on 2016.December.31. 22:50:48
mondjuk még az ep-t se használtuk ki teljesen, úgyhogy még nincs is szükség ilyen hw-re :P
Title: Re: Tesztelés
Post by: szipucsu on 2016.December.31. 23:14:34
mondjuk még az ep-t se használtuk ki teljesen
Mi az, amit még semmilyen program nem használt ki?
Title: Re: Tesztelés
Post by: endi on 2016.December.31. 23:40:40
Mi az, amit még semmilyen program nem használt ki?

hát sokmindent...
pl szinte minden grafikus módban lehetne még újszerű dolgokat csinálni
a karakteres módokról nem is beszélve...
Title: Re: Tesztelés
Post by: endi on 2017.January.01. 11:34:45
Amúgy át lehetne nevezni a topikot konkrétabb címre most már. Külső szín bemenet hardver, vagy ilyesmi.
Title: Re: Tesztelés
Post by: endi on 2017.January.02. 16:59:43
most mondok egy jó nagy hülyeséget, de nem lehetséges olyan hogy magából az EP-ből vezetünk ki valahonnan egy jelet amit rákötünk erre a bemenetre? :D
Title: Re: Tesztelés
Post by: ergoGnomik on 2017.January.02. 18:33:48
most mondok egy jó nagy hülyeséget, de nem lehetséges olyan hogy magából az EP-ből vezetünk ki valahonnan egy jelet amit rákötünk erre a bemenetre? :D
Nem biztos, hogy hülyeség, de én nem értem. Ha már bent van a jel, miért vezetnénk ki csak azért, hogy újra beküldjük? Ha már úgy is bent kotorászunk a gép belsejében, akkor direkt rá is lehet kötni a NICK megfelelő bemeneteire. Egyébként meg pont azért vannak azok a bemenetek, hogy ne kelljen a gépbe beleturkálni.
Title: Re: Tesztelés
Post by: endi on 2017.January.02. 18:50:20
Nem biztos, hogy hülyeség, de én nem értem. Ha már bent van a jel, miért vezetnénk ki csak azért, hogy újra beküldjük? Ha már úgy is bent kotorászunk a gép belsejében, akkor direkt rá is lehet kötni a NICK megfelelő bemeneteire. Egyébként meg pont azért vannak azok a bemenetek, hogy ne kelljen a gépbe beleturkálni.

hát pont azért lenne értelme rákötni erre a "sprite input" dologra, hogy megjelenjen a képernyőt, különösebb extra hw nélkül.
mert ügye itt rámixelődik a képre ez az infó.
persze nem hiszem hogy ki lehet nyerni olyan jelet amit érdemes így megjeleníteni :)
Title: Re: Tesztelés
Post by: balagesz on 2017.January.02. 22:09:34
nem lehetséges olyan hogy magából az EP-ből vezetünk ki valahonnan egy jelet amit rákötünk erre a bemenetre? :D

Tulajdonképpen mi van az EP-n belül, amit érdemes lenne kirakni a képernyőre, de amúgy meg nem pont a képernyőre kerül ki alapból? :razz: Persze lehet hogy van valami világmegváltó ötlet, csak eddig ismeretlen volt. :)
Title: Re: Tesztelés
Post by: endi on 2017.January.02. 22:15:23
Tulajdonképpen mi van az EP-n belül, amit érdemes lenne kirakni a képernyőre, de amúgy meg nem pont a képernyőre kerül ki alapból? :razz: Persze lehet hogy van valami világmegváltó ötlet, csak eddig ismeretlen volt. :)

a memória egy másik része :)
itt a lényeg ügye hogy ez a bemenet összemixelődik (lyukasztással) az lpt által megjelenített grafikával. ez hatalmas dolog.
mondjuk odamixelhetne egy másik lpt-t :)
persze bizonyára oka van annak hogy ilyet nem tud. talán a memória elérést lassította volna? meg persze egy másik lpt is feldolgozást igényel.
Title: Re: Tesztelés
Post by: balagesz on 2017.January.02. 23:06:10
a memória egy másik része :)

Aha. És azt "mi címzi"? :) Csak a lényeg hiányzik a történethez. :-D
Title: Re: Tesztelés
Post by: balagesz on 2017.January.02. 23:09:49
Gondolkodtam erről a témáról a hétvégén egy sort (talán túl sokat is... :) ), lehet hogy inkább blogot kellene róla írnom, nem fórumbejegyzést, de most ide próbálom összeszedni a dolgokat mégis. Illetve itt az elején leírnám, hogy egyrészt ez még mindig csak elmélkedés, másrészt ha kézzelfogható dolog lesz is később belőle, most nem ez a legmagasabb prioritású taszkom jelenleg.

Van ugye rögtön az elején az alkatrészek kérdése. Mivel az EP erősen retró cucc, sokan "kiábrándítónak" tartják, ha modern alkatrészekkel készül valami ilyen géphez, mert hogy az úgy már nem autentikus. Engem ez (mármint a modern alkatrészek) nem zavarnak; inkább legyen egy nyák kicsi, mint hogy rápakoljak egy komplett (retró) alkatrésztemetőt... :) (Tehát ha zavarnak a régi gépbe kerülő új alkatrészek, akkor ne is olvass tovább. :) )

Továbbra is az alkatrészeknél maradva; régen (nagyon... :) ) az volt a mérnökök szokása, hogy olyan IC-ket alkalmaztak csak, amiket több gyártótól is be tudtak szerezni, nehogy egy esetleges gyártó-kiesés miatt boruljon minden. (Ezért gyártott abban az időben sok cég Z80-at (meg 6502-t, ...), meg mindenféle perifériákat, a tervező cég termékét csak így voltak hajlandók megvenni. A többi gyártó meg licencelt, szóval mindenki jól járt.) Ez az idő akkor múlt el, amikor megjelentek az első, speciálisan az adott termékbe tervezett IC-k. Ugyan ettől lett maga a késztermék olcsó, de a csak hozzá készült IC-t már nem gyártották sokan, mivel nem az alkatrész eladása volt a cél, hanem a terméké. :) Az EP-ben is ilyen a NICK / DAVE páros, ezeket csak itt lehet használni, sehol máshol. (Talán egy nedvesség-védelmi tanfolyamon lehetett volna még tananyag...) Ez az alkatrészes "több forrásos" verzió nekem is szimpatikus lenne, mert már többször is sikerült később megszűnő gyártású IC-t használni, de kezd a világ úgy kinézni, hogy ilyen már nem lesz... :( Na de hogyan is jön ez ide? :) Talán úgy, hogy nem akarok régi IC-ket sem használni (amik esetleg nehezen de beszerezhetők még ma is), tehát olyan tokokról sem fog szó esni, hogy másik gépben azt használták, esetleg jó lehetne itt is. (Csakis akkor, ha az még ma is élő termék.) Mivel nem lesz (ha lesz) a stuffból 100000+ darabszám, így a spéci ide tervezett alkatrészek nem játszanak, nagy integráltságot meg csak a "nagyobb" programozható logikákkal lehet elérni. Azokból meg sajnos nem lesz több gyártós, egymást helyettesítő verzió, de ezt a részét el kell engednem a témának. :???:

Aztán el kellene dönteni, hogy "mit is szeretnénk megcsinálni"? Az már fix, hogy mivel, de a funkciók mik legyenek? Értve ezen kérdés alatt ismét azt, hogy retró kütyühöz tervezünk. Lehet az a cél, hogy olyan hw készüljön, még ha modern cuccokkal is, ami az akkori időszakban (1984/5/6) reális lehetett volna. Vagy esetleg engedjük el a fantáziánk, aztán mindent bele? Ahogy a hozzászólásokat olvasom, vegyes a kép a "minek csináljunk bármit" verziótól kezdve a másik végletig, de inkább az utóbbiak vannak többen. :razz:

Meg ilyen kérdés is felmerül itt rögtön az elején, hogy mégis mi fér bele árban? Milyen összegekre gondolt a tisztelt társaság, ami szerintük reális egy ilyen kis szériás eszközért? Kicsit furcsa a kérdés így, hogy nem tudni hogy miért is fizetnél valamennyit, de ez most ilyen lesz; ha lesz valami szám, akkor össze lehet számolni, hogy tulajdonképpen abba milyen funkciók férnek bele.

Részemről talán a cél az, hogy legyen egy lehetőleg kicsi, kevés, de ma is gyártott alkatrészt tartalmazó hardver, ami lehetőleg rugalmas is a maga szintjén. Illetve azért legyen benne olyan is, ami engem is érdekel. :) (Értsd: újdonság, amivel lehet tanulni.) Van egy kissé még "ködös" elképzelésem, hogy mi és hogyan lesz majd megvalósítva, erről is írok hamarosan, de kezdésnek most ezt a pár kérdést tartom érdekesnek.
Title: Re: Tesztelés
Post by: Zozosoft on 2017.January.03. 09:29:27
Ha nem megy csődbe a cég, és kiadják a Sprite hardvert, akkor 99.9999% hogy egy a Nick/Dave chiphez hasonló fekete soklábú cucc lett volna a hardver lelke.
Szóval a fekete soklábút nem érzem csalásnak :-) (Csak engem bosszant, hogy nem értek hozzá :oops: )
És ahogy RAM/ROM bővítésből, turbóból, háttértárból is sokkal jobb/nagyobb van manapság, így ha lett volna gyári Sprite, abból is készült volna manapság jobb/nagyobb/okosabb :-) Vagyis egyből ugorhatunk erre a pontra, tehát mindent bele! :ds_icon_cheesygrin:

Nagyságrendileg én olyan 30000-t tippelnék árra.
Title: Re: Tesztelés
Post by: Tutus on 2017.January.03. 11:04:27
Ha nem megy csődbe a cég, és kiadják a Sprite hardvert, akkor 99.9999% hogy egy a Nick/Dave chiphez hasonló fekete soklábú cucc lett volna a hardver lelke.
Szóval a fekete soklábút nem érzem csalásnak :-) (Csak engem bosszant, hogy nem értek hozzá :oops: )
És ahogy RAM/ROM bővítésből, turbóból, háttértárból is sokkal jobb/nagyobb van manapság, így ha lett volna gyári Sprite, abból is készült volna manapság jobb/nagyobb/okosabb :-) Vagyis egyből ugorhatunk erre a pontra, tehát mindent bele! :ds_icon_cheesygrin:

Nagyságrendileg én olyan 30000-t tippelnék árra.

Maximálisan támogatom Zozo hozzászólását! :)
Title: Re: Tesztelés
Post by: szalai56 on 2017.January.03. 11:42:59
Szerintem ma már csak az új cuccokból érdemes építkezni, lásd SD kártya, EnterMice. Az ár egy másik kérdés, erre nem tudok....
Title: Re: Tesztelés
Post by: lgb on 2017.January.03. 12:04:39
Aztán el kellene dönteni, hogy "mit is szeretnénk megcsinálni"? Az már fix, hogy mivel, de a funkciók mik legyenek? Értve ezen kérdés alatt ismét azt, hogy retró kütyühöz

Es mivel? :) Mert pl FPGA viszonylatban eleg szomoru a helyzet. Legtobb mai cucc az BGA tokozasu, meg 3V logikai szint, vagy meg kisebb, stb. Holott egy ebay-en kaphato osi Altera cuccos (van vagy 2-3kHUF, mini board-on pl EP2C5T144C8N, amugy CycloneII  ... oke BRAM az nudli, de egy kis kulso SRAM-mal meg mindig nem draga) siman egy teljes Z80-as gepet elbir, Z80-al egyutt marmint :) csak eppen annak beszerezhetosege mar nem igazan van biztositva :(

Quote
Lehet az a cél, hogy olyan hw készüljön, még ha modern cuccokkal is, ami az akkori időszakban (1984/5/6) reális lehetett volna.

Hat, hogy mi a realis ... Vegulis a Nick/Dave is egy custom ASIC cuccos mai szohasznalattal elve legalabbis, ha ugy nezzuk, nem egy Z80, amit megvehettel "barhol" (illetve ez utobbit meg ma is akar).
Title: Re: Tesztelés
Post by: geco on 2017.January.03. 13:38:26
Engem sem zavar, ha új alkatrészekből készül, de kevésből :D
Támogatom a mindent (lehető legtöbb cuccot) bele verziót :)
Ebben a témában nem vagyok árérzékeny.
Title: Re: Tesztelés
Post by: ergoGnomik on 2017.January.03. 17:05:29
Es mivel? :) Mert pl FPGA viszonylatban eleg szomoru a helyzet. Legtobb mai cucc az BGA tokozasu, meg 3V logikai szint, vagy meg kisebb, stb. Holott egy ebay-en kaphato osi Altera cuccos (van vagy 2-3kHUF, mini board-on pl EP2C5T144C8N, amugy CycloneII  ... oke BRAM az nudli, de egy kis kulso SRAM-mal meg mindig nem draga) siman egy teljes Z80-as gepet elbir, Z80-al egyutt marmint :) csak eppen annak beszerezhetosege mar nem igazan van biztositva :(
Abból kiindulva, hogy többé-kevésbé sorozatban gyártják a Vampire (http://www.kipper2k.com/accel600.html) Amiga (http://www.apollo-accelerators.com/) gyorsító kártyákat (http://www.majsta.com/) sem az FPGA beszerzés, sem a feszültség szint illesztés nem tűnik áthidalhatatlan problémának. Ráadásul balagesz hozzászólása alapján a hardver már eldöntött tény. Gondolom nem tökön szúrni készül saját magát. :ds_icon_cheesygrin:

Hat, hogy mi a realis ... Vegulis a Nick/Dave is egy custom ASIC cuccos mai szohasznalattal elve legalabbis, ha ugy nezzuk, nem egy Z80, amit megvehettel "barhol" (illetve ez utobbit meg ma is akar).
Ha abban az időben képesek voltak NICK-et és DAVE-et tervezni és gyártani, a korban már voltak hardver sprite megoldások és ezen felül még tervbe is vették ilyen bővítő gyártását, akkor nyugodtan feltételezhetjük, hogy a korabeli eszközök képességeivel bezárólag bármi efféle bővítés reális. Nagy különbséget úgy sem lehet majd látni: egyik egy fekete kocka lett volna, a másik meg egy fekete kocka lesz. :ds_icon_cheesygrin:
Title: Re: Tesztelés
Post by: lgb on 2017.January.03. 18:18:04
Abból kiindulva, hogy többé-kevésbé sorozatban gyártják a Vampire (http://www.kipper2k.com/accel600.html) Amiga (http://www.apollo-accelerators.com/) gyorsító kártyákat (http://www.majsta.com/) sem az FPGA beszerzés, sem a feszültség szint illesztés nem tűnik áthidalhatatlan problémának.

Persze, hogy nem tunik annak. Azt probaltam szemlelteni, hogy _en_ a sajat szemszogembol mit latok problemanak :)  Ez persze nem jelenti azt, hogy ez problema masnak is, foleg annak, aki jaratosabb a temaban mint en.

Quote
Ráadásul balagesz hozzászólása alapján a hardver már eldöntött tény.

igen, pont ezert is kerdeztem, hogy mi lett a valasztott :)

Quote
Gondolom nem tökön szúrni készül saját magát. :ds_icon_cheesygrin:

??

Quote
Ha abban az időben képesek voltak NICK-et és DAVE-et tervezni és gyártani, a korban már voltak hardver sprite megoldások és ezen felül még tervbe is vették ilyen bővítő gyártását, akkor nyugodtan feltételezhetjük, hogy a korabeli eszközök képességeivel bezárólag bármi efféle bővítés reális. Nagy különbséget úgy sem lehet majd látni: egyik egy fekete kocka lett volna, a másik meg egy fekete kocka lesz. :ds_icon_cheesygrin:

Aham, ezt probaltam en is kifejezni, hogy egyaltalan nem baj ...
Title: Re: Tesztelés
Post by: ergoGnomik on 2017.January.03. 19:31:13

No, akkor sikerült rosszul megfejteni mit akartál írni. :oops: Bocsesz!
Title: Re: Tesztelés
Post by: lgb on 2017.January.03. 19:33:28
No, akkor sikerült rosszul megfejteni mit akartál írni. :oops: Bocsesz!

Nincs problema, en tisztaban vagyok vele, hogy neha nehezkesen fejezem ki magam :-D
Title: Re: Tesztelés
Post by: balagesz on 2017.January.03. 21:36:41
Szóval a fekete soklábút nem érzem csalásnak :-) (Csak engem bosszant, hogy nem értek hozzá :oops: )

Ennek örülök! :) (Bosszankodni meg fölösleges, tanulni kell aztán kész. :cool: ) Ilyen jellegű "nyavalygást" az EP kapcsán még nem éreztem amúgy, de azért jobb az ilyeneket is tisztázni, még mielőtt valaki csalódik.

És ahogy RAM/ROM bővítésből, turbóból, háttértárból is sokkal jobb/nagyobb van manapság, így ha lett volna gyári Sprite, abból is készült volna manapság jobb/nagyobb/okosabb :-) Vagyis egyből ugorhatunk erre a pontra, tehát mindent bele! :ds_icon_cheesygrin:

Szuper! (Még több munka... :oops:) Szerintem kell akkor majd csinálni egy "eredeti" implementációt, ami talán abban az időben elérhető lett volna, meg egy "kibővítettet", ami belefér. Így aztán mindenki boldog lehet. :) (Nyilván egy verzió lesz... ;) )

Nagyságrendileg én olyan 30000-t tippelnék árra.

Szóval olyan 100 EUR körül. Sok függ a majdani alkatrészek beszerzési lehetőségeitől is, de ez így már abszolút reális lehet. (Mondjuk a 3000 az nem lett volna az.)

Es mivel? :) Mert pl FPGA viszonylatban eleg szomoru a helyzet. Legtobb mai cucc az BGA tokozasu, meg 3V logikai szint, vagy meg kisebb, stb. Holott egy ebay-en kaphato osi Altera cuccos (van vagy 2-3kHUF, mini board-on pl EP2C5T144C8N, amugy CycloneII  ...

A "mivel" az nem véletlenül volt dőlt, az annyira biztos, hogy valami programozható logika lesz, nem korabeli (LS)TTL alkatrészek lesznek felhasználva. Amúgy pont az Altera egy érdekes lehetőség, lenne, ha nem vette volna meg őket az intel. (Mivel "tudjuk", hogy minek kellett neki, az Altera CPLD-i illetve kisebb FPGA-i marhára csak púp a hátukon (IMHO persze), nem tudom hogy hosszabb távon mennyire lehet számítani rájuk.)

Hat, hogy mi a realis ... Vegulis a Nick/Dave is egy custom ASIC cuccos mai szohasznalattal elve legalabbis, ha ugy nezzuk, nem egy Z80, amit megvehettel "barhol" (illetve ez utobbit meg ma is akar).

Persze, de akkor (IMHO továbbra is) nem lett volna reális pl. egy olyan HW, ami "korlátlan" számú sprite-ot ki tudott volna tolni a képre. Tehát lett volna mondjuk 8 db. 24×24 pixeles sprite, esetleg vízszintes / függőleges duplázással, meg beállítható 2/4/16 színű móddal, persze a vízszintes felbontást felezgetve. Ha most ennyit sikerülne megvalósítani, azért akkor szomorú lennék. :-D

Abból kiindulva, hogy többé-kevésbé sorozatban gyártják a Vampire (http://www.kipper2k.com/accel600.html) Amiga (http://www.apollo-accelerators.com/) gyorsító kártyákat (http://www.majsta.com/) sem az FPGA beszerzés, sem a feszültség szint illesztés nem tűnik áthidalhatatlan problémának. Ráadásul balagesz hozzászólása alapján a hardver már eldöntött tény. Gondolom nem tökön szúrni készül saját magát. :ds_icon_cheesygrin:

A jelszintek illesztése nem para, csak plusz alkatrész. :) A hardver csak annyira eldöntött, mint fent írtam: programozható logika lesz diszkrét IC-k helyett. Tulajdonképpen még az sem eldöntött, hogy FPGA lesz, mivel azzal még nem terveztem semmit. :oops: Az első ötleteim még CPLD-vel is megvalósíthatók, viszont közben jött pár újdonság, mint a "sima" képernyős lehetőség. Ezekhez kezd már olyan "méretű" CPLD tartozni, aminek az ára már belelóg az egyszerűbb FPGA-k ársávjába, ahol azért jóval több a lehetőség. Cserébe - számomra, még - ismeretlen terep. (De persze idézem magam: "Bosszankodni meg fölösleges, tanulni kell aztán kész. :cool: ")
Title: Re: Tesztelés
Post by: lgb on 2017.January.03. 23:16:00
Erdekes a tema :) Alterat tenyleg megvette az Intel? Na errol le is maradtam. Bennem az tett mely bemyomast (bar ez MCU fronton ugye inkabb), hogy a Microchip megvette az Atmel-t. Btw, Atmel, nekik vannak kisebb FPGA-ik, ahol meg 5V-ra is gondoltak igy-ugy (tudom, ez az en maniam, hogy sajnalom, hogy logic level shift kell kulon meg ...). Mondjuk, a nagyratoro terv jo :) bar biztos nem egyszeru ... Ha most arrol van szo "csak", hogy az EXTCOL bemeneteket rangatja, es tud "fullscreen"-t adni, az elmeleti max felbontasban is, tudja a fene mennyi igy fejbol, de ugy 736 pixel szer 756 kornyeken (interlaced)? Az baratok kozt is 200Kbyte memoria kornyeken van (16 szinu modot feltetelezve), egyszerubb FPGA-kban nincs is ennyi block RAM, szoval vagy nagyon draga lesz, vagy kulso RAM kell, de akkor meg a kb 14MHz-es pixelclock mellett kell olvasgatni, hogy kozben a Z80 is hozzaferhet :-/ Es a sprite-okrol nem is beszeltunk, ha ez is lehet meg az emlitett fullscreen mode mellett is. Durva :) Mondjuk spec, ha 16 biten eri el a RAM-ot a cucc belsoleg, az nemileg enyhit az idozites szoritasan (ezert jo az FPGA belso bram-ja, ami meg akar adott esetben dual port-oskent is hasznalhato, nomeg joval gyorsabb is). Mondjuk, mega65-nel 192MHz a pixel clock :) es azt elvileg birja 256 szinu modoban is (igaz csak bram-bol, es az eleg draga FPGA azert, Xilinx Artix-7 abban is igy saccra fel mega bram ha van osszesen, vagy hasonlo, de csak igy nagysagrendileg tippelek, pontosan nem neztem utana).

Es akkor mar csak a 3D rendering hianyzik, Z-bufferelt, 4x antialias, 4 millio polygon/sec, izebize atomtuti (ez vicc akart lenni) :-)

A sprite kerdesnel meg anno is inkabb a max megjelenitheto sprite / scanline volt a limit, ez meg C64-nel sw-bol is cselezheto ("sprite multiplexing"), szoval a sprite fuggoleges felbontasa is inkabb mesterseges limit, elvileg semmi sem indokolja kulonoskeppen, foleg egy uj design-ban. A vizszintes felbontas es/vagy a sprite-ok max szama ami egy scanline-ba "belelog" az mar mas kerdes, az idozites miatt (persze, ha nincsenek hatalmas sprite-ok, az FPGA siman beranthatja bram-jaba a vsync alatt pl, es akkor akar az emlitett "fullscreen super 16 colour mode" mellett sem jelentenek a sprite-ok gondot nagyon).

Amugy csak erdekel a tema, melyeben oszinten szolva melyebben nem ertek hozza, szoval mindekitol bocsanat, nem okoskodni szandekozom, csak tenyleg erdekelnek a technikai reszletek, hatha tanulok belole valamit :) Ha nekiallsz, igazan lehetne rola vmi blogod, en szivesen olvasnam :)
Title: Re: Tesztelés
Post by: Ep128 on 2017.January.04. 00:16:50
Maximálisan támogatom Zozo hozzászólását! :)

Én is! :-)
Title: Re: Tesztelés
Post by: balagesz on 2017.January.04. 23:28:25
Bennem az tett mely bemyomast (bar ez MCU fronton ugye inkabb), hogy a Microchip megvette az Atmel-t.

Hát, igen, az "ősi nagy rivális", ugye... :) A jelek ebben az esetben valamennyire biztatóak; ahogy most áll a történet, a Microchipnél kevesebb félnivalója van az Atmel portfóliójának, mint az intelnél az Alterának. :oops:

Btw, Atmel, nekik vannak kisebb FPGA-ik, ahol meg 5V-ra is gondoltak igy-ugy (tudom, ez az en maniam, hogy sajnalom, hogy logic level shift kell kulon meg ...).

A szintillesztést külön én se komálom, de úgy tűnik, hogy ez van. TTL kompatibilis bemenet egyre inkább nem lesz. :( Az Atmel FPGA-kkal "csak" az a gondom első körben, hogy nem találok hozzá fejlesztőkörnyezetet. :oops:

de ugy 736 pixel szer 756 kornyeken (interlaced)? Az baratok kozt is 200Kbyte memoria kornyeken van (16 szinu modot feltetelezve), egyszerubb FPGA-kban nincs is ennyi block RAM, szoval vagy nagyon draga lesz, vagy kulso RAM kell, de akkor meg a kb 14MHz-es pixelclock mellett kell olvasgatni, hogy kozben a Z80 is hozzaferhet :-/

Ennyi memoárt FPGA-val "kialakítani" eléggé pazarlásnak tűnik, mindenképpen kell külső RAM, amivel lehet hozni a kívánt sebességet. Ezt eddig úgy gondoltam, hogy a 14.xxxMHz-es sebesség duplája lenne a RAM buszsebessége, az meg lenne 16 bites, így a sávszélesség a 4×-e lenne. Ebből lehet gazdálkodni.

Amugy csak erdekel a tema, melyeben oszinten szolva melyebben nem ertek hozza, szoval mindekitol bocsanat, nem okoskodni szandekozom, csak tenyleg erdekelnek a technikai reszletek, hatha tanulok belole valamit :) Ha nekiallsz, igazan lehetne rola vmi blogod, en szivesen olvasnam :)

Ó, mondd csak bátran! Az ilyenekből szokott azért ihlet jönni bőséggel. :) A blog az jó kérdés, de ide úgyis írok egyelőre mindent. :)

Amúgy nézegettem alkatrészeket, és egy csöppet le is lettem hangolódva. :( Utoljára talán 2011 környékén nézegettem árakat, hát, eléggé meg lettem most lepődve... Pedig nem is értem hogy miért. Akkor 250 körül volt az euró, 200 alatt meg a dollár. Ma meg 300 körül van mindegyik... Aztán volt egy cég, akitől alkatrészt vettünk, őket megvette kilóra egy másik cég, akik csak "nagyker", magánszemélyként nem lehet vásárolni náluk. Az árak viccesek, leginkább mindenből egész kiszerelést (IC-kből mondjuk komplett tálcát vagy csövet) lehet csak venni, szóval van fejvakargatás rendesen... :evil:
Title: Re: Tesztelés
Post by: Zozosoft on 2017.January.04. 23:34:40
Aztán volt egy cég, akitől alkatrészt vettünk, őket megvette kilóra egy másik cég, akik csak "nagyker", magánszemélyként nem lehet vásárolni náluk. Az árak viccesek, leginkább mindenből egész kiszerelést (IC-kből mondjuk komplett tálcát vagy csövet) lehet csak venni, szóval van fejvakargatás rendesen... :evil:
Nem tudom, hogy ez (https://enterpriseforever.com/hardver/szereles/msg42595/#msg42595) esetleg segítség-e.
Title: Re: Tesztelés
Post by: lgb on 2017.January.05. 08:53:52
Ennyi memoárt FPGA-val "kialakítani" eléggé pazarlásnak tűnik, mindenképpen kell külső RAM, amivel lehet hozni a kívánt sebességet. Ezt eddig úgy gondoltam, hogy a 14.xxxMHz-es sebesség duplája lenne a RAM buszsebessége, az meg lenne 16 bites, így a sávszélesség a 4×-e lenne. Ebből lehet gazdálkodni.

Aham. Csak turbo EP-re is gondolni kell, de amugy oke :) Az is erdekes kerdes, hogy milyen RAM, sima SRAM, vagy esetleg valami SDRAM, akarmi. Ez utobbi erdekessege hogy foleg jellemzoen video RAM szeru felhasznalasnal ki lehet aknazni mindenfele plusz sebesseget, viszont hat frissiteni kell meg minden, de azert nem egy olyan DRAM mint anno volt :D Pl most peldakent a C64DTV-t tudom felhozni, ahol 2Mbyte SDRAM van, amit 32 biten er el, es raadasul folyamatos, linearis olvasasnal joval gyorsabb is. Na persze, nem feltetlen egyszeru egy SDRAM controllert irni VHDL-bol (hogy a DDR-rol ne is beszeljunk, multkor veletlenul megneztem mi az abra Mega65 eseten a Nexys-4 FPGA board DDR felhasznalasaval ... haaaat meg homerseklet kompenzaciot is kell irni bele, hogy ne hibazzon, meg ilyen hulyesegek ... otletem sincs, hogy egy modern PC-ben ezt hogy oldjak meg ...). Bar, spec, szerintem nem kell nekunk tobb mega RAM, ami miatt a sima SRAM felhasznalasa mar "problemas" lenne :D

Quote
Amúgy nézegettem alkatrészeket, és egy csöppet le is lettem hangolódva. :( Utoljára talán 2011 környékén nézegettem árakat, hát, eléggé meg lettem most lepődve... Pedig nem is értem hogy miért. Akkor 250 körül volt az euró, 200 alatt meg a dollár. Ma meg 300 körül van mindegyik... Aztán volt egy cég, akitől alkatrészt vettünk, őket megvette kilóra egy másik cég, akik csak "nagyker", magánszemélyként nem lehet vásárolni náluk. Az árak viccesek, leginkább mindenből egész kiszerelést (IC-kből mondjuk komplett tálcát vagy csövet) lehet csak venni, szóval van fejvakargatás rendesen... :evil:

Hmm, multkor youtube-on pont talaltam egy videot, valami "Decline of hobby electronics?" vagy mi volt a cime, eleg sok ismert arc nyilatkozott benne. Hogy ugye anno, through hole technika, nyomtak iparban is, otthon is, no problem. Manapsag viszont az SMD technika mar olyan szintekre maszik, amit otthon nem igazan lehet egyszeruen muvelni, foleg ha az extrem kis "morzsa" meretu alkatreszekrol van szo, no meg egy BGA tokozasu cuccot forrasszon be egy atlag szerencsetlen mint en ... foleg aki PCB-t sem akar csinalni ugye (jo lesz a proto board is, stb ...), mert ahhoz se technikaja, se penze, hogy allandoan rendelgessen innen-onnan kicad/eagle/stb gerber file-okat kuldozgetve ... Kerdes, hogy meddig tart ki a jelenlegi helyzet, jelenleg meg fut a through hole technika, mert keletebbre meg mindig megeri nehol hogy par szerencsetlennek adjanak 1-2 dollart egy hetre, es forrasszak kezzel, mert igy nem kell venni belulteto gepeket stb (no persze, nem a nagyon nagy volumenu gyartasnal itt sem mar eleve) ... De azert egyre inkabb a "kezzel/otthon szinte lehetetlen" hozzaallas terjed, tehat par evtized mulve nem tudom, lehet kapni egyaltalan barmi alkatreszt majd, amit egy atlag hazi barakacsolo tud hasznalni :-/ Illetve, hat biztos (javitas, miegymas) de ezek szama folyamatosan csokken, jelenleg is belefutottam olyan dolgokba, hogy kineztem par remek kis IC-t datasheet alapjan, es persze mind csak valami elvetelmult tokozasban gyartodik mar eleve ... Az meg nem feltetlen eri meg - hosszu tavon persze - hogy csak hobby celjara mindebol gyarsanak szamukra is kezelheto format :( A masik meg, hogy eleve nyilvan a tomeges vetelre es felhasznalasa optmilizalnak, egy belulteto gepnek (pick&place macine, vagy hogy hijjak a dragat) beadsz egy teljes reel-t (illetve akar egyszerre tobb tucatnyit is, a kulonbozo komponensekhez ...), aztan azzal elvan, nyilvan nem egyesevel akarnak alkatreszeket adogatni, a csomagolasa sem olyan ... No mind1, bocsanat a ram jellemzo szokasos off-topic-ert ...

Node, az eredeti temara visszaterve:

Amugy amikor anno en ilyet kepzeltem el (nem mintha jelenlegi VHDL tudasommal meg tudnak csinalni - ennel joval egyszerubb dolgot sem -, dehat almodozni lehet ... ja es nem is EP fronton, "csak ugy"), akkor arra jutottam, hogy adott egy max memoria fele ertelmezett savszelesseg. Ami ebbe belefer, azt miert ne adnam. Azaz, ha full resolution max szinmelyeseggel (itt ugye "csak" negy bit, ha EXTCOL input-rol van szo) eppen belefer, akkor annyi, de ha pl fele felbontast ker az ember, abbol ket layer-re is futja :D Es akkor pl kulon pozicionalhato egyik a masik fole stb. Sot, ha egy layer alatt (jo, hulye nevet adtam neki ...) azt ertjuk, hogy egy teglalap alaku terulet, ami lehet akkora mint a screen vagy kisebb is (es van/lehet atlatszosagi info is), akkor vegulis a sprite is egy-egy "kicsi" (nem fullscreen) layer. Sot maga a teljes kep is egy "layer" vegulis (igy meg akar scroll-ozni is lehet, ha kicsit arrebb teszed ki, stb, sprite eseten ez a sprite pozicionalasa, de egy teljes screen eseten annak gorgetese pl). No, es persze EP eseten jon a trukk, hogy kozben Nick is kitehet barmit, sot lehet allitani is, hogy az EXTCOL altal kapott infot hogyan ertelmezze, stb. Az mar nagyon messzire vezet, es szerintem "tul bator otlet" is, hogy mi van, ha magat az EP-t modositod "bent", hogy a Nick-bol kijovo 8 bitnyi infot magadra tolod, es esetleg "felulbiralod" adott esetben, majd a vegen ki is adod magadbol (es erre kapcsolodna az, ami az EP-n amugy a Nick 8 bitnyi kimenetere erkezik mint aktualis "szin") igy akar 256 szinu modokkal is lehet szorakozni (itt most ls is allok, mert eszembe jutott, hogy akar tobb mint 8 bitet is kiadhat, es csinalni sajat D/A-t, akkor meg lehetne palatta regiszter EP szinekhez - ami by default az EP palettat adna persze -, de ehhez mar melyen bele kene nyulni sok helyen az EP-be, ami a Nick utan van a videokimenetig bezarolag).
Title: Re: Tesztelés
Post by: endi on 2017.January.05. 11:33:35
érdekes amit írtok az elektronikáról, szerelésről.
én már régóta azt hittem hogy az otthoni szerelést meg lehet úszni akár forrasztás nélkül is, mert azt hittem hogy alap-egységekből építkezik az ember, amik sokat tudnak, programozhatók stb. de ami ez alatt van azt is csak össze lehet kötözgetni. tehát azt hittem hogy ic-k meg ellenállások forrasztgatása az (házilag) rég elavult vagy nem célszerű dolog.

az ep-hw építésnél meg azt is vegyétek szerintem figyelembe hogy lesz-e aki alkot rá valamit, illetve hogy mit... szerintem nem nagyon lesz olyan se aki akár a sprite-okat kihasználná (max valami egyszerű demó)... de ne legyen igazam
Title: Re: Tesztelés
Post by: Zozosoft on 2017.January.05. 11:52:12
az ep-hw építésnél meg azt is vegyétek szerintem figyelembe hogy lesz-e aki alkot rá valamit, illetve hogy mit... szerintem nem nagyon lesz olyan se aki akár a sprite-okat kihasználná (max valami egyszerű demó)... de ne legyen igazam
Itt a kérdés az, hogy tudni fog-e annyi, és olyan sprite-ot a cucc, mint MSX, CPC+, ki tudja még milyen Z80-as sprite-os gép? Ha igen akkor lehetséges lesz ezekről sprite-os játékokat átírni. Tudom fúj átirat, de azért mégiscsak könnyebb, gyorsabb így szaporítani a spriteos programok számot :-)
A másik dolog: mindehhez lehetséges IS-BASIC bővítést írni, így BASIC programból is használni őket. Itt különösen nagy lesz az előny a sima egyik printtel kirakom másik printtel letörlöm, harmadik printtel odébb rakom módszerhez képest.
Title: Re: Tesztelés
Post by: IstvanV on 2017.January.05. 12:00:46
Itt a kérdés az, hogy tudni fog-e annyi, és olyan sprite-ot a cucc, mint MSX, CPC+, ki tudja még milyen Z80-as sprite-os gép? Ha igen akkor lehetséges lesz ezekről sprite-os játékokat átírni.

Az ilyen átiratok viszont nem futnának eredeti EP-n, vagy azt még külön támogatni kellene, ami elég sok munka. Nem véletlen, hogy a hardver bővítések közül elsősorban az EnterMice lett sikeres, egy játékot nem túl nehéz "egeresíteni" úgy, hogy egér nélküli konfiguráción is használható maradjon.
Title: Re: Tesztelés
Post by: endi on 2017.January.05. 12:15:48
hát bármi, ami használja ezt a hw-t, az nem fog futni eredeti gépen :)
de amúgy igen, átiratnak lenne értelme! de akkor ezt már most ki kéne találni hogy melyik gépről lenne lehetséges/érdemes átírni játékokat.

a basic bővítés az jó ötlet!

amúgy engem csak az érdekel hogy az emu is támogassa majd :P
Title: Re: Tesztelés
Post by: lgb on 2017.January.05. 12:45:42
Kicsit visszakanyarodva a sprite boviteshez :) Ha mar mouse: egy erdekes pelda lehet pl gflorez baratunk mouse drivere: mukodik az most is, de _opcionalisan_ hasznalhatna sprite-ot egerkurzorkent, ami hat szebb is, meg talan hatekonyabb is (nem kell szenvedni talan annyit a video modokkal, stb).
Title: Re: Tesztelés
Post by: gflorez on 2017.January.05. 13:15:29
Igen, a legtöbb kód a vezető kapcsolatban van grafikus mód és vezérlési módok. A vezető kizárólag a EnterMice és Sprite lehet nagyon pici.

A másik oldalon, hozzátéve, a Sprite opciót a Universal Mouse Driver, lehet nagyon egyszerű.

Képzeljünk el egy olyan alak változó egérmutató, mint a Windows.

És szövegen módban a mutatót nem korlátozódik karakter határokat.

-----------------------

Yes, most of the code in the driver is related to graphic modes and control modes. A driver made only for EnterMice and Sprites could be very tiny.

On the other side, adding a Sprite option to the Universal Mouse Driver, can be very easy.

Imagine a shape changing pointer, like on Windows.

And on text modes the pointer wouldn't be limited to character boundaries.
Title: Re: Tesztelés
Post by: balagesz on 2017.January.05. 13:24:25
Nem tudom, hogy ez (https://enterpriseforever.com/hardver/szereles/msg42595/#msg42595) esetleg segítség-e.

A linkelt kereskedő "fent van a listán", de jól meg kell nézni, hogy mit vesz az ember, mert elég meredek áraik is vannak. :???:

Csak turbo EP-re is gondolni kell, de amugy oke :) Az is erdekes kerdes, hogy milyen RAM, sima SRAM, vagy esetleg valami SDRAM, akarmi.

A sebességgel IMHO nem lesz gond, de persze majd meglátjuk. (10 MHz-ig biztos jó lesz, de persze oda kell figyelni erre is.) A RAM az tuti valami gyors SRAM lesz, kell ide a gyors Random Read ha nem akarom nagyon elbonyolítani.

Manapsag viszont az SMD technika mar olyan szintekre maszik, amit otthon nem igazan lehet egyszeruen muvelni, foleg ha az extrem kis "morzsa" meretu alkatreszekrol van szo, no meg egy BGA tokozasu cuccot forrasszon be egy atlag szerencsetlen mint en ...

Hát igen, erre halad a világ. Pár év, és ez is a "kiváltságos" multik hatáskörébe kerül, az otthoni faragásnak teljesen lőttek... :( Esetleg még jól "ki is lobbiznak" maguknak valamit (mint pl. az RoHS...), aztán kész is. Használjuk ki a lehetőséget, ameddig még lehet! :) (Vagy inkább :( ?) BGA tokozású alkatrészt azért nem óhajtok használni, mondjuk ha nem túl "sűrű", talán még meg is tudnám szereltetni, de inkább mégse. :)

Kerdes, hogy meddig tart ki a jelenlegi helyzet, jelenleg meg fut a through hole technika,

Azért vannak jelenleg még olyan területek, ahol a "régi" technológiának van bőven létjogosultsága, de elég ha csak visszaszorul, a hozzá kapható alkatrészek ára "elérhetetlen" lesz.

akkor arra jutottam, hogy adott egy max memoria fele ertelmezett savszelesseg. Ami ebbe belefer, azt miert ne adnam. Azaz, ha full resolution max szinmelyeseggel (itt ugye "csak" negy bit, ha EXTCOL input-rol van szo) eppen belefer, akkor annyi, de ha pl fele felbontast ker az ember, abbol ket layer-re is futja :D

:-D Na ja. Ez addig "jó" is, ameddig tervezhető a memória-hozzáférés. Csak itt jön a képbe a CPU, ami nem kiszámítható módon fordul majd a memóriához, neki hagyni kell mindig valami időszeletet, ha kell neki, ha nem. (Mint ahogy a NICK csinálja. :) Mivel ha Z80 ciklus jön, akkor a videótól nem vehetem el a RAM-ot, mert az lesz, ami a teszthardveremnél most van: havazás. :) )

Az mar nagyon messzire vezet, es szerintem "tul bator otlet" is, hogy mi van, ha magat az EP-t modositod "bent", hogy a Nick-bol kijovo 8 bitnyi infot magadra tolod, es esetleg "felulbiralod" adott esetben,

Ezzel csak az a "baj", hogy az alap bővítést is relatíve "kevesen" fogják beszerezni. Ha ehhez a gépen belül még matekolni is kell, akkor ennek a "kevésnek" is a töredékére esik a felhasználói létszám. Gondolkodtam már erről a plus/4 esetén is, ott is van jó pár ötletem, amihez minimálisan módosítani kellene a gépen belül is. De ezt nagyon kevesek csinálnák ám meg! Ne magadból (magamból...) indulj (-unk) ki, akinek nem fáj a forrasztópáka. :-D

Itt a kérdés az, hogy tudni fog-e annyi, és olyan sprite-ot a cucc, mint MSX, CPC+, ki tudja még milyen Z80-as sprite-os gép?

Erről van-e valamerre valami összefoglaló féle? :oops: Nehogy valami banális dolog miatt alul legyen tervezve valami. :)

Az ilyen átiratok viszont nem futnának eredeti EP-n, vagy azt még külön támogatni kellene, ami elég sok munka.

Ez viszont teljesen így van. Ezen csak úgy lehet "segíteni", ha a bővítő hardverből "sok" lesz forgalomban, utána már nem gond az igénye. De ha nincs sw, nincs indok a beszerzésre. Mond valakinek az a szám valamit, hogy 22? :-D
Title: Re: Tesztelés
Post by: geco on 2017.January.05. 13:53:17
Erről van-e valamerre valami összefoglaló féle? :oops: Nehogy valami banális dolog miatt alul legyen tervezve valami. :)
Van, de a jelenlegi állapotból kiindulva alultervezéstől nem kell félni :) pl a CPC ugyanígy 1 byte 1 pixel alapon működik, 16 színnel, és ha jól emlékszem az alap felbontás a 4 szín módnak megfelelő, úgy emlékszem 32 sprite lehet max, és fix videómemóriája van a Sprite hardvernek, úgy emlékszem 8Kb sincs.
Title: Re: Tesztelés
Post by: lgb on 2017.January.05. 13:55:05
Amugy pl a SymbOS biztos befuto lehet :) Mar aki akar SymbOS-t, es EP-n. Elonye, hogy a kompatibilitas (eredeti gepen a kerdeses bovites nelkul nem megy esete ...) nem gond, mivel SymbOS aztan nem csak EP-n fut, es jelenleg is fut EP-n :) Viszont sokkal jobb felbontasban, 16 szinu modban is mehetne a bovitessel, de ugyanazon SymbOS app-ok ettol mennek meg "alap" EP-n is. Ezt csak azert irtam, mert ugye szo volt rola, hogy valoban, az problema lehet, hogy adott sw mar nem megy az alap EP-vel. Max, ehhez lehet meg kene tamogatni majd Prodatron baratunkat egy ilyen bovitessel :D
Title: Re: Tesztelés
Post by: geco on 2017.January.05. 13:58:04
Rosszul emlékeztem, 16 sprite van csak, és Col2 módtól indul ott is.

CPC+ sprite (http://www.cpcwiki.eu/index.php/Programming:CPC_Plus_Hardware_Sprites)
MSX Hw (http://bifi.msxnet.org/msxnet/tech/tms9918a.txt)
Title: Re: Tesztelés
Post by: endi on 2017.January.05. 14:27:37
ha jól értem ez egy cpc plus game pl:
https://www.youtube.com/watch?v=CoWHkuI-REQ
Title: Re: Tesztelés
Post by: ergoGnomik on 2017.January.05. 16:44:37
Rosszul emlékeztem, 16 sprite van csak, és Col2 módtól indul ott is.

CPC+ sprite (http://www.cpcwiki.eu/index.php/Programming:CPC_Plus_Hardware_Sprites)
MSX Hw (http://bifi.msxnet.org/msxnet/tech/tms9918a.txt)
Csak szerintem perverz kicsit az MSX megoldása? Ha egy sprite is kívül esik a képernyőn, azonnal befejezi a megjelenítést.

ha jól értem ez egy cpc plus game pl:
https://www.youtube.com/watch?v=CoWHkuI-REQ
Nagyon jó az a parallax. Azonban a játék meglehetősen lassúnak tűnik, ami a látványnak sajnos nem tesz jót. :( Vagy ez valamilyen emulátorból lett felvéve amit gyenge gépen futtattak?
Title: Re: Tesztelés
Post by: endi on 2017.January.05. 16:46:43
Csak szerintem perverz kicsit az MSX megoldása? Ha egy sprite is kívül esik a képernyőn, azonnal befejezi a megjelenítést.
Nagyon jó az a parallax. Azonban a játék meglehetősen lassúnak tűnik, ami a látványnak sajnos nem tesz jót. :( Vagy ez valamilyen emulátorból lett felvéve amit gyenge gépen futtattak?

szerintem ez egy feltuningolt sima cpc game. azaz a pálya meg minden továbbra is cpc, és ráraktak parallax layereket. az fps meg maradt az a lassú ami volt.
de valszeg így nem volt vele annyi munka...
Title: Re: Tesztelés
Post by: IstvanV on 2017.January.05. 19:21:19
szerintem ez egy feltuningolt sima cpc game. azaz a pálya meg minden továbbra is cpc, és ráraktak parallax layereket. az fps meg maradt az a lassú ami volt.
de valszeg így nem volt vele annyi munka...

CPC-re és CPC+-ra is kiadták (http://cpc-power.com/index.php?page=detail&num=1682), ha jól látom, mindkét gépre 1993-ban?
Title: Re: Tesztelés
Post by: geco on 2017.January.05. 19:32:41
Érdekes, hogy a sima CPC verzióban volt CPU idő betenni a 2 rasztercsíkot, a CPC+ verzióban ez nem történt meg, és az is érdekes, hogy ezt csak most vettem észre, pedig mind a kettővel játszottam, ha nem is túl sokat :D
Title: Re: Tesztelés
Post by: balagesz on 2017.January.07. 17:05:20
Rosszul emlékeztem, 16 sprite van csak, és Col2 módtól indul ott is.

CPC+ sprite (http://www.cpcwiki.eu/index.php/Programming:CPC_Plus_Hardware_Sprites)
MSX Hw (http://bifi.msxnet.org/msxnet/tech/tms9918a.txt)

Kösz az "összefoglalót", ezek szerint azért nem akkora varázslat a dolog, illetve ezt most nem érzem egy lehetetlen feladatnak. :)

Viszont menet közben eszembe jutott még egy tesztelési lehetőség, csak ahhoz megint forrasztgatni kellene egy fél napot... :oops:
Title: Re: Tesztelés
Post by: Zozosoft on 2017.January.07. 17:11:34
Egyébként ha jól értem a dolgot, akkor a legnagyobb gond a párhuzamos memória elérések megoldása.
Amúgy meg csak egy nagy rakás számláló, tól/ig beállításokkal :-)
Title: Re: Tesztelés
Post by: balagesz on 2017.January.07. 18:24:02
Arról még nem írtam, hogy nekem milyen ötleteim vannak... :) Első körben én ezt viszonylag egyszerűnek képzeltem el, ezért is készült a jelenlegi teszthardver. Ami "alapjaiban" meghatározza a lehetséges megoldást, az az, hogy direkt "sprite-generátor"-t nem gondolnám, hogy lehet kapni... :)

Az elképzelés annyi volt, hogy van egy szép darab RAM, mint most, annak minden egyes BYTE-ja megfelel 1-1 nagy felbontású pixelnek a képen. Persze a 8 bitből csak 4 + 1 van használva, így 16 lehetséges "szín" van, illetve a "láthatóság" kapcsolható. Ez így tulajdonképpen egy sima "frame buffer". Magának a RAM-nak a buszrendszere úgy lenne felépítve, hogy a NICK Dot-Clock (ami 14.xxx MHz) dupláján futna, és 16 bites lenne, emiatt a sávszélesség a NICK felé szükséges adatmennyiség négyszerese. A fennmaradó RAM időben a Z80 dolgozhat, de ebből a sávszélességből csak néha-néha kell neki egy-egy ciklus, szóval marad szabadidő bőven. Ezt eddig egy nagyobb CPLD-vel meg lehet csinálni.

Na de hogy lesz ebből sprite? Ide lehet "csempészni" egy kis EP-s logikát. :mrgreen: Mivel a sprite pixel-adatait a bővítés memóriájába kell másolni, ebbe a memóriába létre lehetne hozni egy SPT-t. Ami SPB-kből állna. :) Azaz: lenne egy Sprite Parameter Table, amik Sprite Parameter Block-okat tartalmaznak. Ezek a blokkok egy-egy sprite adatait írnák le: hol van a "bitmap" a memóriában, milyen pozícióra kell kirakni a képen, milyen üzemmódban, stb. Ezt a SPT-t meg egy combosabb mikrovezérlő dolgozná fel, a RAM sávszélességének a fennmaradó idejében pakolgathatná az adatokat. Beolvasna egy-egy SPB-t, az alapján felszedné a memóriából a sprite "képét", majd a megfelelő helyre odamásolná a "frame buffer"-be. Ennek a felépítésnek van egy olyan előnye, hogy tulajdonképpen nincs maximálisan megjeleníthető sprite-szám, hanem mozgatható adatmennyiség-korlát van csak. Magyarán kis méretű sprite-okból sokat, nagyobbakból kevesebbet lehet egyszerre kezelni. Illetve a sprite-ok mérete dinamikusan változhat, az egyik lehet ekkora, a másik meg amakkora.

A sprite-ok megjelenítési prioritását én meglehetősen egyszerűnek képzelem el: ha több darab is egymásra kerül, az fog a végén látszani, amelyiket utoljára pakolt ki, azaz később következik az SPT-ben. :)

Természetesen van a megoldásnak "árnyoldala" is. Egyrészt ha meg van jelenítve a kép, a következő frame-et "takarítással" kell kezdeni, illetve a sprite "megjelenítés" maga nem real-time: elindítod az SPT feldolgozását, aztán valamikor kész lesz. De ez tervezhető dolog. Aztán ha kell sprite-sprite ütözést is tudni vizsgálni, akkor az új sprite kipakolása előtt vissza kell olvasni az adott helyen levő adatot a frame-bufferből, ami a RAM sávszélességét fogyasztja.

Nagyjából ennyi volt az elképzelésem, és ekkor jött a teljesen önálló külső kép, mint kívánság... :) Azt nem mondom hogy borít mindent, de - mondjuk úgy - nem egyszerűsíti a helyzetet. :razz: A sprite-háttér ütközést ezzel már lehetne vizsgálni, csak vagy ott is olvasom a "háttér" adatait is, vagy ezt meg a megjelenítéskor tudom csak jelezni, immár real-time. Ami egy kicsit kilóg a logikából. :roll:

Ha ezt a µC-es feldolgozást csinálnánk, annyi előnye mindenképpen lenne, hogy tulajdonképpen csak program kérdése, hogy milyen lehetőségek vannak, lehet egy csomó fajta formátuma a sprite-oknak a 2 színűtől kezdve a nagyításon keresztül tulajdonképpen bármeddig.

Maga a hardver viszont a plusz "háttér" layer-rel kezd kilógni egy CPLD "komfort-zónájából", emiatt szóba jön ide egy valamilyen FPGA, csak azt még egyelőre nem "faragtam". :) De ha már FPGA, ott is van egy csomó lehetőség, akár külső µC felhasználása nélkül is. (Csak még alapabb eszközökkel kell megcsinálni a dolgot.) Jelen pillanatban nem tudom, hogy melyik verzió lenne a célravezető (Kombináltan mindkettő? :) ), van mit mérlegelni.

Egyébként ha jól értem a dolgot, akkor a legnagyobb gond a párhuzamos memória elérések megoldása.
Amúgy meg csak egy nagy rakás számláló, tól/ig beállításokkal :-)

A fenti megoldás "eliminálja" ezt a problémát, nincs szükség a párhuzamos elérésre. Cserébe persze van más... :)
Title: Re: Tesztelés
Post by: geco on 2017.January.08. 09:32:23
Kösz az "összefoglalót", ezek szerint azért nem akkora varázslat a dolog, illetve ezt most nem érzem egy lehetetlen feladatnak. :)
A nagyja már meg is van :), legalábbis nekem úgy tűnik, és nem értek a HW-hez :D
Ami eltér majd a CPC-stől, hogy ott külön palettája van a sprite-oknak, de ez legyen a legkevesebb.
Title: Re: Tesztelés
Post by: geco on 2017.January.08. 09:43:44
Ez az SPB, SPT ötlet nagyon tetszik, az, hogy meg lehet adni a sprite adat kezdetét, meg méretét főleg, sehol se láttam még ilyet, pl CPC-n fix címek vannak, és ha egy nagyobb sprite-ot akarsz, akkor több kisebből kell összepakolni, és gondolom az SPB tartalmazná a sprite x y pozícióját is.
A látható sprite-tal kapcsolatban, ha több sprite van ugyanazon a helyen ,vagy félig takarásban, kirajzolná az összeset, csak az utolsót jól rápakolná a többire, így lenne ami látható lenne a régebbiekből is?
Én úgy gondoltam/nám a sprite-ot, mint full képet, hogy ilyenkor a sprite hw csak a képet adná, esetleg ha van még elég hely a sprite memóriában, akkor lehetne még sprite-okkal is foglalkoznia, és az ütközésvizsgálat ilyenkor a háttér sprite-ban kikapcsolható, ne vizsgálja a háttér és egy sprite ütközését, ha az ütközés vizsgálat sprite pozíció alapján történik majd, ha pedig két sprite aktív pixelének találkozása alapján, akkor maradhat, de gondolom nem ez lesz, mert ehhez egy erőmű kéne.
Title: Re: Tesztelés
Post by: IstvanV on 2017.January.08. 10:28:50
ha pedig két sprite aktív pixelének találkozása alapján, akkor maradhat, de gondolom nem ez lesz, mert ehhez egy erőmű kéne.

A VIC-II (C64) tud ilyet. :) Természetesen a hardver teljesítménye korlátozza a soron belül megjeleníthető sprite számot, a 8 sprite adatának az olvasása a keret időtartama alatt történik.
Title: Re: Tesztelés
Post by: lgb on 2017.January.08. 13:31:41
Azert ne felejtsuk el, hogy itt ez egy hardware :) Mig emulatornal nagy szivas a sprite utkozes vizsgalat (lassu ...), hardware-nel nem lassit, mivel nem egy emulator/software ugye, es megoldhato, hogy minden parhuzamosan menjen, teljesen mas gondolkodast igenyel :) Bar ettol eroforrast nyilvan kovetel, ami jelen esetben a komplexitast jelenti inkabb, talan nem veletlen, hogy C64 VIC-II-nel is a chip felulet jo 3/4-et a sprite kezeles viszi el :)
Title: Re: Tesztelés
Post by: Zozosoft on 2017.January.08. 14:28:22
A priorítás/ütközés vizsgálat az egyszerű szerintem:
Sorba kell kötni őket az 5 bites adatukkal, az EXTC jelnél fogva az újabbik felülírja az eddigieket, ott ahol nem átlátszó. És ahol két EXTC találkozik, az már adja a jelet, hogy az aktuális sprite nekiment valaminek.
Title: Re: Tesztelés
Post by: endi on 2017.January.08. 16:01:01
Azert ne felejtsuk el, hogy itt ez egy hardware :) Mig emulatornal nagy szivas a sprite utkozes vizsgalat (lassu ...), hardware-nel nem lassit

egy mai pc-nek nem hiszem hogy akár több tízezer ilyen sprite ütközés vizsgálata gondot okozna :) (pixel pontosan természetesen)
Title: Re: Tesztelés
Post by: lgb on 2017.January.08. 17:01:42
egy mai pc-nek nem hiszem hogy akár több tízezer ilyen sprite ütközés vizsgálata gondot okozna :) (pixel pontosan természetesen)

Megis, probalj meg nagyon pontos C64 emulatort irni egyszer, es merd le milyen PC kell hozza :) Meglepo lesz az eredmeny :) Pedig az emulalando cucc nem tul 'tapos' egy valami egy modern PC-hez viszonyitva ... Persze ebben nem csak a sprite utkozes van epp benne, de hidd el, sokat elvisz egy gyors CPU-bol is egy olyan muvelet, amit valami megcsinal hw-bol, neked meg egy linearis kodfuttatasra tervezett CPU-n kell emulalni, ami a valodi hw-en tok parhuzamos mukodesu, es hw-bol van megoldva.
Title: Re: Tesztelés
Post by: endi on 2017.January.08. 17:23:41
Megis, probalj meg nagyon pontos C64 emulatort irni egyszer, es merd le milyen PC kell hozza :) Meglepo lesz az eredmeny :) Pedig az emulalando cucc nem tul 'tapos' egy valami egy modern PC-hez viszonyitva ... Persze ebben nem csak a sprite utkozes van epp benne, de hidd el, sokat elvisz egy gyors CPU-bol is egy olyan muvelet, amit valami megcsinal hw-bol, neked meg egy linearis kodfuttatasra tervezett CPU-n kell emulalni, ami a valodi hw-en tok parhuzamos mukodesu, es hw-bol van megoldva.

hát írtam elég sok játékot, pixelpontos ütközésvizsgálattal is... :)
a lineáris kódfuttatás sokat nem számít, hiszen brutálisan gyors egy mai pc egy magon is.
meg hát ügye van sok proci mag, meg gpu mag is :)
c64 emulátorok is régóta vannak, ha jól tudom 100%-osak
Title: Re: Tesztelés
Post by: lgb on 2017.January.08. 17:39:51
hát írtam elég sok játékot, pixelpontos ütközésvizsgálattal is... :)
a lineáris kódfuttatás sokat nem számít, hiszen brutálisan gyors egy mai pc egy magon is.
meg hát ügye van sok proci mag, meg gpu mag is :)
c64 emulátorok is régóta vannak, ha jól tudom 100%-osak

100%-os sosem lesz :) Olyan trukkok is vannak am mar, hogy par a dolog analog jellemzoit is emulalni kell, pl hogy a C64 serial IEC kabelen hiaba megy digitalis jel, a kabel induktiv es kapacitiv jellezoi alapjan a viselkedese elter attol, amit egy idealis digitalis emulacioban varnal. Es hasonlo agymenesek. Valoban, vannak jo C64 emulatorok, csak pont ezt mondom, hogy nezd mar meg mennyivel nagyobb teljesitmenyu gep kell a futtatasukhoz mint a hw amit emulal :) Nem mondom, hogy _csak_ ez (marmint a sprite utkozes vizsgalat) egy mai modern gepen lenne a szuk keresztmetszet, csak ugye azt mondottam, hogy egy FPGA-ban megvalositva ez teljesen mas, mint egy emulatorban.
Title: Re: Tesztelés
Post by: endi on 2017.January.08. 18:23:15
jó de remélem lesz emu támogatás :)
amúgy megint csak azt tudom mondani hogy a konvertálás lehetőségét kéne szem előtt tartani egy ilyen hw készítésekor, mert tuti hogy akkor legalább pár konverzió születne ami használja...
Title: Re: Tesztelés
Post by: gflorez on 2017.January.08. 19:17:41
Ha egy gyors processzor esetén alkalmazható sprite, miért nem hajtják végre néhány egyszerű forma matematika koprocesszor? Persze lebegőpontos BCD ...

----------------

If a fast processor is used for sprites, why not implement some simple form of maths coprocessor?  Of course in floating point BCD...
Title: Re: Tesztelés
Post by: lgb on 2017.January.09. 02:47:04
Kicsit ott-topic, de: https://www.youtube.com/watch?v=h42neZVvoMY

A csavonak vannak erdekessegei, amikor pl egy MCU-val csinalt demot, real-time kodbol eloallitva a videojelet is (annyi RAM sincs, hogy frame buffere legyen), stb. Am itt most nem errol  van szo, hanem: vegulis egy Commodore One-bol kiszedte az egyik panelt (de most mindegy is persze, hogy az honnan van), ami lenyegeben magaban egy Cyclone III FPGA (ami nem is tul modern darab ma mar, mondhatni ...). Aztan abban implementalt maganak egy gepet szepen es irt ra demot :) Nekem tetszik. Persze a latottakbol kikovetkeztetheto, hogy valoszinu egy teljes erosen bovitgetett EP CPU-stul Nick-estul mindenestul is siman beleferne :) Bar ez mar megint egy masik project, nem epp "csak" a sprite/stb generalas kivulrol.
Title: Re: Tesztelés
Post by: Povi on 2017.January.09. 10:15:00
A csavonak vannak erdekessegei, amikor pl egy MCU-val csinalt demot, real-time kodbol eloallitva a videojelet is (annyi RAM sincs, hogy frame buffere legyen), stb.
Beteg egy ember, de pont ezért szeretjük :-)
Régen nézegettem én is az alkotásait, de pár éve nem néztem felé, az MCU-s demo-t (Craft) ismertem, de az újabb cuccait nem láttam még. Ha már off topic-kodunk: :-) ezt a munkáját se ismertem (C64 demo): http://www.linusakesson.net/scene/lunatico/index.php kb. a felénél, miután megfordítod a lemezt, nagyon szép esőcsepp effektek vannak, és a legvégén a harnagjáték-szerű tune nagyon tetszik, hasonlót még nem hallottam SID-ből.
Title: Re: Tesztelés
Post by: balagesz on 2017.January.09. 19:28:33
Ami eltér majd a CPC-stől, hogy ott külön palettája van a sprite-oknak, de ez legyen a legkevesebb.

Itt külön paletta - úgy tűnik - nem lesz sajnos, a NICK ezt nem teszi lehetővé. Ezért is lett volna szerencsés, ha az ECx bemenetek kikerülték volna a palettázó áramköröket, és "direkt" mentek volna ki a színkimenetre.

Ez az SPB, SPT ötlet nagyon tetszik, az, hogy meg lehet adni a sprite adat kezdetét, meg méretét főleg, sehol se láttam még ilyet, pl CPC-n fix címek vannak, és ha egy nagyobb sprite-ot akarsz, akkor több kisebből kell összepakolni, és gondolom az SPB tartalmazná a sprite x y pozícióját is.

Azt az "adat-kezdet" dolgot természetesen úgy kell érteni, hogy a bővítés memóriáján belül. Bár gondolom ez egyértelmű. :) Egy SPB tartalmazna az adott sprite-hoz minden szükséges adatot a képén kívül, az X/Y pozíciót is. Jut eszembe: ebből lehetne akár több is, ha ugyanazt több helyre is ki akarnád rakni. Így elég lenne csak 1× felolvasni, kirakni meg lehetne több helyre. :mrgreen:

A látható sprite-tal kapcsolatban, ha több sprite van ugyanazon a helyen ,vagy félig takarásban, kirajzolná az összeset, csak az utolsót jól rápakolná a többire, így lenne ami látható lenne a régebbiekből is?

Természetesen. Mivel egy-egy pixel egy BYTE-ot használ a "frame-buffer"-ből, így ehhez hardveres segítség is lehet: ha átlátszó a kirakandó pixel, nem történik memóriaírás. De ez már technikai részlet, az meg még odébb van.

ha az ütközés vizsgálat sprite pozíció alapján történik majd, ha pedig két sprite aktív pixelének találkozása alapján, akkor maradhat, de gondolom nem ez lesz, mert ehhez egy erőmű kéne.

Az esetleges ütközésvizsgálat mindenképpen kapcsolható kell hogy legyen, mert ebben a felépítésben rendesen viszi az erőforrást. :) De pixeles találkozás alapon gondolom a vizsgálatot, ahhoz viszonylag egyszerű és jól optimalizálható a matek. (Így, első végiggondolásra legalábbis... ;) )

Azert ne felejtsuk el, hogy itt ez egy hardware :) Mig emulatornal nagy szivas a sprite utkozes vizsgalat (lassu ...), hardware-nel nem lassit,

Ja, de itt pont nem hardver az ütközésvizsgálat. Bár... Most hogy mondod, DE! :) Csinálható ehhez "egyszerű" hardveres segítség, ismét egy megjegyzendő ötlet! :oops:

És ahol két EXTC találkozik, az már adja a jelet, hogy az aktuális sprite nekiment valaminek.

Ez igaz, ha a "világon eddig használt" "real-time" verzió van megvalósítva. Ha a "saját" verziómat nézem, ott nincs több párhuzamos EXTC jel, csak egy van.

If a fast processor is used for sprites, why not implement some simple form of maths coprocessor?  Of course in floating point BCD...

Ha van a külső µC, akkor azt lehet használni koprocesszornak is, persze. Mondjuk én nem biztos, hogy FPU-nak használnám elsősorban, hanem inkább blitter (https://en.wikipedia.org/wiki/Blitter)-nek. Persze a kettő nem zárja ki egymást. ;)

Kicsit ott-topic, de: https://www.youtube.com/watch?v=h42neZVvoMY

Hát igen, eléggé "félőrült" a jóember... (Persze a jó értelemben.)
Title: Re: Tesztelés
Post by: geco on 2017.January.10. 08:40:31
Jut eszembe: ebből lehetne akár több is, ha ugyanazt több helyre is ki akarnád rakni. Így elég lenne csak 1× felolvasni, kirakni meg lehetne több helyre. :mrgreen:
Jó ötlet, viszont ez limitet szabna egy sprite kirakási számának, vagyis nem ,mert ha monsdjuk 8 xy pozíció lenne az SPB-ben, akkor egy újabb SPB-vel ugyanarra a spritre-ra még nyolc pozíció lenne lehetséges.
Title: Re: Tesztelés
Post by: lgb on 2017.January.10. 09:02:32
Ha meg nem volt rola szo (?), az is erdekes, hogy VSYNC ideje alatt mennyi adatot tudna beolvasni. Oke, akkor is osztoznia kell a Z80-al esetleg, de legalabb mas EXTCOL infot kozben nem kell kiadnia. Az FPGA a belso block RAM-jabol meg aztan eleg gyorsan elszorakozhat persze, ha mar ki kell rakni (az megint egy erdekes kerdes, de talan a dolgok tulbonyolitasa, hogy meg lehessen adni, hogy adott sprite mondjuk nem valtozik minden frame-ben, tehat nem kell mindig ujraolvasni feltetlen ...).
Title: Re: Tesztelés
Post by: ergoGnomik on 2017.January.10. 13:19:42
... hogy VSYNC ideje alatt mennyi adatot tudna beolvasni. Oke, akkor is osztoznia kell a Z80-al esetleg, de legalabb mas EXTCOL infot kozben nem kell kiadnia.
A VSYNC összesen 6 rasztersor. Soronként van 57 NICK ciklus. A videó órajel a NICK memória órajel 16-szorosa. balagesz kétszeres órajelet tervez 16 bites adatbusszal. Ebből 6*57*16*2*2=21888 bájt jön ki. Ha mindenre jól emlékszem.

Az azért nem hinném, hogy annyira tragikus lenne a Z80-nal osztozás. Végül is miért akarna olyan sokszor hozzáférni a bővítő memóriájához a processzor? Egyrészt visszaolvasgatni a sprite adatokat nem gyakran van sok értelme. Feltöltöd az adataidat, utána meg csak a pozíciókat meg az adatmutatókat módosítgatod az animációhoz és a mozgatáshoz. Másrészt az írást – szerintem, de majd akik ki tudják rendesen számolni pontosítanak – simán lehet pufferelni, a Z80 azért annyira még 10 MHz-en sem gyors, hogy szaturálni tudná a tervezett memóriabuszt.
Title: Re: Tesztelés
Post by: ergoGnomik on 2017.January.10. 19:58:50
Természetesen van a megoldásnak "árnyoldala" is. Egyrészt ha meg van jelenítve a kép, a következő frame-et "takarítással" kell kezdeni, illetve a sprite "megjelenítés" maga nem real-time: elindítod az SPT feldolgozását, aztán valamikor kész lesz. De ez tervezhető dolog. Aztán ha kell sprite-sprite ütözést is tudni vizsgálni, akkor az új sprite kipakolása előtt vissza kell olvasni az adott helyen levő adatot a frame-bufferből, ami a RAM sávszélességét fogyasztja.
Nem lehetne úgy szervezni a frame megjelenítését, hogy amint felolvasott egy szót, azt azonnal írja felül nullával? Ez megint csökkentené a szabad sávszélességet a megjelenítés ideje alatt, de nem torlódna fel a feladat a kép valamely részére, ráadásul nem kellene külön gondoskodni róla a programozónak (vagy a konstruktőrnek).

Az SPT feldolgozására lehetne olyan stratégiát bevetni, hogy a megjelenítő rész valahány rasztersoronként jelez a mikrokontrollernek, hogy itt már jártam, a megelőző sorokba már szabad rajzolni, a kontroller meg az SPT ismételt feldolgozásai során megjelöli a már feldolgozott SPB-ket például egy folytonosan futó framecounter beírásával, vagy ez feleslegesen elbonyolítaná a működést?
Title: Re: Tesztelés
Post by: balagesz on 2017.January.12. 14:52:41
Jó ötlet, viszont ez limitet szabna egy sprite kirakási számának, vagyis nem ,mert ha monsdjuk 8 xy pozíció lenne az SPB-ben, akkor egy újabb SPB-vel ugyanarra a spritre-ra még nyolc pozíció lenne lehetséges.

Mondjuk senki nem mondta, hogy egy SPB-nek fix hosszúságúnak kell lennie. :-D (Persze logikailag jobban kezelhető az állandó méret.) Na de ez most mindegy, úgyis odébb van. Ami biztos: az FW-t egyszerűen "upgrade"-elhetőre kell csinálni, így az ilyen kiegészítések mehetnek majd később is, amikor már csak a polírozás folyik.

Ha meg nem volt rola szo (?), az is erdekes, hogy VSYNC ideje alatt mennyi adatot tudna beolvasni.

Nem szorítkoznék én csak erre, ráadásul a VSYNC pont "programozható" is EP-n, szóval nem is biztos hogy van. :) (Persze: ha nincs, nincs kép se, szóval ez csak elméleti dolog, de na. :oops:)

Az azért nem hinném, hogy annyira tragikus lenne a Z80-nal osztozás.

A Z80 azért ehhez képest "ritkán" használja a memóriát, még úgy is, ha direkt forszírozva van. :) Ami inkább "gáz", hogy a CPU 8 bites ciklusokat generál a 8 bites mivoltából kifolyólag, :) ha a bővítés busza meg 16 bites, akkor a processzor "dupla" sávszélességet visz el a többi résztől. Meggondolandó, hogy maradjon-e 8 bites a RAM, ezen még lesz mit gondolkodni.

Nem lehetne úgy szervezni a frame megjelenítését, hogy amint felolvasott egy szót, azt azonnal írja felül nullával?

Gondoltam erre is, de ennek valószínűleg több hátránya van mint előnye. Megduplázza a "frame-buffer" sávszélességigényét kapásból, cserébe minden kép kiírásakor újra kell másolni a sprite-okat akkor is, ha amúgy nem változott volna semmi. Illetve azért feltételezhető, hogy a képernyő teljes egészét nem teszik ki a sprite-ok (kivétel persze lehet...), takarításnál meg elég csak azokat a területeket törölni, ahol volt is valami.

Az SPT feldolgozáshoz a későbbiekben bőven lehet mindenféle optimalizációkat bevetni, de ez még a jövő feladata. ;)

(Amúgy eszembe jutott egy ötlet, amihez neki is álltam forrasztgatni, de egyelőre még nem tartok vele sehol. Ha lesz valami "fényképezhető", úgyis mutatom, csak egy kissé elhavaztam. Megint.)
Title: Re: Tesztelés
Post by: Zozosoft on 2017.January.12. 15:00:51
Még egy meggondolandó dolog: maradjon-e ez a 8 bitben 5 bit memóriafelhasználás.
Lehetne esetleg, úgy, hogy a 0-ást színt nevezzük ki átlátszónak, amikor nincs EXTC. Így lehetne félbájtos adatokkal dolgozni, csökkenne a memória igény, ill. CPU igény átvitelnél.
Mondjuk így valamivel bonyolultabb lenne a hardver, a 4 bitnyi adatot OR-olva jönne ki az 5.
Title: Re: Tesztelés
Post by: endi on 2017.January.12. 15:01:50
mondjuk akkor már egy bias szín legyen a lyukasztó
(bocs ha hülyeséget írok és már tök máshol tart az egész :) )
Title: Re: Tesztelés
Post by: Zozosoft on 2017.January.12. 15:05:58
mondjuk akkor már egy bias szín legyen a lyukasztó
Igen ezen én is töprengtem, hogy talán jobb lenne azokból elveszteni egyet.
Title: Re: Tesztelés
Post by: balagesz on 2017.January.12. 15:33:48
Még egy meggondolandó dolog: maradjon-e ez a 8 bitben 5 bit memóriafelhasználás.
Lehetne esetleg, úgy, hogy a 0-ást színt nevezzük ki átlátszónak, amikor nincs EXTC. Így lehetne félbájtos adatokkal dolgozni, csökkenne a memória igény, ill. CPU igény átvitelnél.

A témát itt két fele célszerű szedni:

A sprite "formátuma", hogy hogyan is néz ki a "sprite bitmap", ez az egyik. A jelenlegi elképzelésben ugye ezt a "sprite bitmap"-et felszedi a memóriából egy µC, majd kirakja a "frame-buffer" megfelelő helyére. Viszont a kirakáshoz simán át is lehet alakítani, a "sprite bitmap" emiatt lehet akármilyen formátumban. Lehet akár 2 színű is, ahol 1-1 bit jelenti az átlátszó / valamilyen szín esetet. Magyarán a Z80 által kezelt adat lehet olyan, hogy a lehető legkevesebb feladata legyen vele.

mondjuk akkor már egy bias szín legyen a lyukasztó

A másik rész meg az, ahogyan a hardver a "frame-buffer"-ből adatokat generál az ECx/EXTCOL bemenetekre. Jelen esetben itt gondolkozok az 1 BYTE-ból csak 5 bit használt / pixel verzión. Nekem is eszembe jutott az a verzió, hogy 4 bit legyen egy pixel, és a 16 variációból valamelyik (akár állítható...) kombináció legyen az átlátszó, de ez behoz egy adag problémát. :) Pl. az átlátszóság kezelése, amikor két sprite egymásra másolódik. Külön tesztelni kellene, hogy a BYTE-ban levő két pixel közül 0,1,2 vagy 3 átlátszó, az 1/2 változatban meg a "frame-buffer" tartalmát visszaolvasni+módosítani+beírni kellene egy sima beírás helyett. Aztán ott van a pozíció: ha 1 pixellel akarom vízszintesen eltolni a sprite-ot, akkor az egész sor-adatot fél BYTE-tal kell odébb pakolni, ami megint csak nem hatékony. (Ha lenne gyors és megfelelő méretű, 4 bites szélességű SRAM, az segítene a helyzeten, de szerintem nem van. :) )

Az 1 BYTE 2 pixel verziót viszont az esetleges "háttér", a plusz videolap esetén gondolom jónak, mivel az ismét olyan adathalmaz, amivel a Z80-nak is lehet dolga. Ott a kevesebb mindig jobb elv érvényesül, bár az is kérdés, hogy mi a gyorsabb: két pixelnyi adatot összerakni majd egy BYTE-ot kiírni, vagy két BYTE-ot kiírni. :oops:
Title: Re: Tesztelés
Post by: Zozosoft on 2017.January.12. 15:47:27
az is kérdés, hogy mi a gyorsabb: két pixelnyi adatot összerakni majd egy BYTE-ot kiírni, vagy két BYTE-ot kiírni. :oops:
Igen, ez nekem is eszembe jutott.
Title: Re: Tesztelés
Post by: lgb on 2017.January.13. 15:26:20
Meg azt is vegyuk figyelembe szerintem, hogy 4 bit "elpzarlasa" (vagy 3, ha atlatszosagi bit is benne van) nagyban csokkenti a hw kepessegeit hogy adott idoegyseg alatt mennyi sprite pixel adatot kepes olvasni ... Ha pack-olva van jobb az arany. Plusz, en azon is elgondolkodnek, hogy valoban kell-e atlatszosagi info. Ha van egy I/O port amivel configolni lehet egy "colour key"-t (esetleg sprite-onkent kulon), akkor a 16 szinbol egyet felaldoztunk, hogy az lesz az atlatszo. Cserebe viszont nem kell kulon atlatszosagi bit az FPGA-nak kulon, es ha meg byte-ban ket pixel is van, akkor egyetlen byte ket teljes pixel atlatszosagi infoval egyutt ugymond (bar ezzel egy szin elveszett). Ha 16 biten eri el a RAM-jat az FPGA, akkor egyetlen memoriamuvelettel is ez mar 4db pixel. Ez sokkal rosszabb lenne, ha kulon van minden + atlatszosagi bit is. Ez akkor erdekes foleg, ha kozben ilyen "full screen" jellegu megjelenitest is kerunk tole + sprite-ok is kozben (es mondjuk nem is egy), akkor talan szamit ... Bar lehet en vagyok maximalista, es felesleges?

Ja, a masik meg: VSYNC mellett a HSYNC is kihasznalhato arra hogy 'prefetch-eljen' adatot, amikor nem kell Nick fele az EXTCOL labakon infot adni, nem tudom ez hasznos-e vagy nem.
Title: Re: Tesztelés
Post by: ergoGnomik on 2017.January.13. 15:58:12
Ja, a masik meg: VSYNC mellett a HSYNC is kihasznalhato arra hogy 'prefetch-eljen' adatot, amikor nem kell Nick fele az EXTCOL labakon infot adni, nem tudom ez hasznos-e vagy nem.
Nincs előbetöltés. A hardver előre generált adatfolyamot küld ki a külső szín bemenetekre. Ezt egy mikrovezérlő állítja elő a feltöltött sprite adatok és megjelenítésvezérlés alapján a képmegjelenítési adat-hozzáférések és a Z80 műveletek szüneteiben. Már ha jól értelmeztem az eddigieket.
Title: Re: Tesztelés
Post by: lgb on 2017.January.13. 16:13:11
Nincs előbetöltés. A hardver előre generált adatfolyamot küld ki a külső szín bemenetekre. Ezt egy mikrovezérlő állítja elő a feltöltött sprite adatok és megjelenítésvezérlés alapján a képmegjelenítési adat-hozzáférések és a Z80 műveletek szüneteiben. Már ha jól értelmeztem az eddigieket.

Hat nem tudom, de ennek nincs sok ertelme :) Miert ne lehetne kihasznalni? Ha tudod hogy adott sorban kell a sprite es hol van a memoriaban miert ne lehetne pre-fetch-elni, foleg akkor, ha amugy ott sok sprite van amire nem eleg "just-in-time" memoriasavszelesseg az FPGA szamara (ami aztan a sajat BRAM-jaban persze tarolhatja meg egy darabig). Mikrovezerlorol lemaradtam, vagy lehet nem olvastam el par uzenetet azota, en meg az FPGA-nal tartok :)
Title: Re: Tesztelés
Post by: balagesz on 2017.January.13. 23:38:47
Meg azt is vegyuk figyelembe szerintem, hogy 4 bit "elpzarlasa" (vagy 3, ha atlatszosagi bit is benne van) nagyban csokkenti a hw kepessegeit hogy adott idoegyseg alatt mennyi sprite pixel adatot kepes olvasni ...

Egyelőre még annyira nincs lefixálva semmi, hogy bármi lehet. :) Az elképzelés most az, hogy lesz egy "frame-buffer", ami az egész képernyőhöz tartalmaz bit-információt. Itt lenne a 3 bitnyi pazarlás. :) Ebbe a "frame-buffer"-be meg egy µC "renderelné bele" a sprite-okat, amikor a Z80 mondja neki, hogy most csináld öcsém. Ezt a "frame-buffer"-t tulajdonképpen a Z80-nak nem is kell tudnia közvetlenül elérni! :)

Ha 16 biten eri el a RAM-jat az FPGA, akkor egyetlen memoriamuvelettel is ez mar 4db pixel. Ez sokkal rosszabb lenne, ha kulon van minden + atlatszosagi bit is. Ez akkor erdekes foleg, ha kozben ilyen "full screen" jellegu megjelenitest is kerunk tole + sprite-ok is kozben (es mondjuk nem is egy), akkor talan szamit ... Bar lehet en vagyok maximalista, es felesleges?

A "full screen" jellegű megjelenítés ettől teljesen független (legalábbis az eddigi elképzelések szerint), ott olyan üzemmódot csinálunk, ami éppen jól esik. Valójában a "sprite-frame-buffer" lehet akár külön buszon is, ez ismét egy eldöntendő dolog. (Persze ha külön busz, akkor külön RAM is, meg kell hozzá I/O láb az FPGA részéről, szóval itt is van előny / hátrány egyaránt, mint eddig mindig. :oops:)

Mikrovezerlorol lemaradtam, vagy lehet nem olvastam el par uzenetet azota, en meg az FPGA-nal tartok :)

Az egész ötletelésem onnan indult, de azóta a körítés elbonyolódott a CPLD-vel "kényelmesen" megvalósítható verziótól az FPGA-s megoldás fele. A µC-es lehetőség nekem ettől eltekintve szimpatikus maradt, mert az jó lehet még egy csomó egyéb dologra is.
Title: Re: Tesztelés
Post by: balagesz on 2017.February.17. 00:31:10
(Amúgy eszembe jutott egy ötlet, amihez neki is álltam forrasztgatni, de egyelőre még nem tartok vele sehol. Ha lesz valami "fényképezhető", úgyis mutatom, csak egy kissé elhavaztam. Megint.)

Az elhavazás most is tart, de akadt egy kis "gondom". :) Ugyan nem szeretek úgy írogatni, hogy ne legyen mögötte mutatni való, de most mégis ez lesz. Az említett "ötlet" csak annyi, hogy van valahonnan egy bontott nyákom, amin van egy régi FPGA. Azt akartam csinálni, hogy a jelenlegi CPLD-s tesztet összerakom ezzel. Viszont ez a nyák nem egy fejlesztőpanel, hanem valami termék volt, az FPGA-nak relatív kevés lába van csak kivezetve, amit ugyan megtoldottam némi vezetékezéssel bőven, de még így is hiányos. :| De sebaj, jó lesz úgy is, ha az EP jeleit multiplexelve küldöm most bele, tesztelni lehet úgy is. Nálam ilyen esetben a "hello world" példa az szokott lenni, hogy kialakítok egy egy bites regisztert, amit a CPU tud írni, az állapotát meg kivezetem egy LED-re. Így egy sima OUT utasítással kapcsolgatható; látszik is, hogy jó-e. (Utána persze "ragozom" tovább.) A mostani verzió úgy áll, hogy ha simán "rádrótozom" az EP jeleit az FPGA-ra, akkor a tesztregiszterem simán működik. De ha nekiállok jeleket multiplexelni, akkor felborul az egész. :roll: Valahol valami árulás van, mert viszonylag egyszerű (nek tűnik) a feladat. Ez közel az első ismerkedésem FPGA-val amúgy, szóval simán lehet, hogy valamit benézek. Meg persze a próbált nyák / FPGA is lehet bugos. (Az amúgy is ezer sebből vérzik.) Van egy jó adag ötlet, amit ki fogok tudni próbálni, csak némi idő kell hozzá, remélem a hétvégén majd tudok vele foglalkozni.

Tehát a téma nincs elfelejtve, csak egy kissé elkedvetlenedtem. :| De ez átmeneti állapot csak! :mrgreen:
Title: Re: Tesztelés
Post by: geco on 2017.February.17. 14:43:25
Tehát a téma nincs elfelejtve, csak egy kissé elkedvetlenedtem. :| De ez átmeneti állapot csak! :mrgreen:
Várjuk a fejleményeket :)
Title: Re: Tesztelés
Post by: IstvanV on 2017.February.17. 19:07:14
Várjuk a fejleményeket :)

Addig még elkészülhetne a (Swin)SID kártya (https://enterpriseforever.com/hardver/sid-illesztes-ep-hez/msg48161/#msg48161). :) Annak tulajdonképpen már van kapcsolási rajza is, "csak" gyártani kellene.
Title: Re: Tesztelés
Post by: Zozosoft on 2017.February.17. 19:51:45
Addig még elkészülhetne a (Swin)SID kártya (https://enterpriseforever.com/hardver/sid-illesztes-ep-hez/msg48161/#msg48161). :) Annak tulajdonképpen már van kapcsolási rajza is, "csak" gyártani kellene.
És már szoftver is van hozzá!
Title: Re: Tesztelés
Post by: balagesz on 2017.February.20. 23:55:57
Várjuk a fejleményeket :)

Na, az a fejlemény, hogy valaki most szívat! :| Megcsináltam a hétvégén pár hardveres módosítást, de nem tudom feltölteni az FPGA-ba a belevalót. Pedig eddig ment... Úgy tűnik, megdöglött a nyákon az FPGA, amivel próbálkozok. Ebből a stuffból van még elfekvőben valamerre egy darabom, csak az nincs átalakítva. Azzal még teszek egy próbát, de elkezdtem már "gyári" FPGA fejlesztő paneleket keresgélni.

Addig még elkészülhetne a (Swin)SID kártya (https://enterpriseforever.com/hardver/sid-illesztes-ep-hez/msg48161/#msg48161). :)

Jaaa... :-D Amúgy az eredeti SwinSID-del az egyik "bajom", hogy a használt ATmega88 hivatalosan maximum 20 MHz-es órajellel hajtható, itt meg meg van küldve 32-vel. Enyhe 60%-os overclock, merjek én így terméket csinálni vele? :shock: Viszont menet közben szembejött velem egy kínai ATmega88 klón, ami a "fura érzéseket" leszámítva érdekes lehet. Egyrészt az AVR-nek van pár utasítása / címzésmódja, ami 2 órajelciklus alatt fut, a kínai verzió meg 1-gyel is beéri, emiatt alapból gyorsabb. Ráadásul simán megy 32 MHz-es órajelen... Egy kicsit vicces. Ez az áramkör annyira egyszerű amúgy, hogy "stand-alone" verziót nem is lenne érdemes (szerintem) csinálni belőle, ez simán elfér valami más kártyának a sarkán.
Title: Re: Tesztelés
Post by: geco on 2017.February.21. 08:39:30
Egy kicsit vicces. Ez az áramkör annyira egyszerű amúgy, hogy "stand-alone" verziót nem is lenne érdemes (szerintem) csinálni belőle, ez simán elfér valami más kártyának a sarkán.
Hát akkor mondjuk a Sprite hw sarkán? :ds_icon_cheesygrin:
Türelmes vagyok, kivárom :D
Title: Re: Tesztelés
Post by: ergoGnomik on 2017.February.21. 09:23:01
Egy kicsit vicces. Ez az áramkör annyira egyszerű amúgy, hogy "stand-alone" verziót nem is lenne érdemes (szerintem) csinálni belőle, ez simán elfér valami más kártyának a sarkán.
Vagy inkább licencelni a SwinSID Ultimate-et hozzá. Az viszonylag jelentős javításokat és némi funkció bővítést tartalmaz. Esetleg – Áltimét Hiper G*ci Edísön változatban :D – felhegeszteni foglalatot meg analóg körítést igazi SID-nek.
Title: Re: Tesztelés
Post by: Zozosoft on 2017.February.22. 12:21:01
Ez az áramkör annyira egyszerű amúgy, hogy "stand-alone" verziót nem is lenne érdemes (szerintem) csinálni belőle, ez simán elfér valami más kártyának a sarkán.
Lehetne egy all-in-one hangkártya: SID, AY, 4x8 bit DAC.
Title: Re: Tesztelés
Post by: geco on 2017.February.22. 15:01:58
Lehetne egy all-in-one hangkártya: SID, AY, 4x8 bit DAC.
Ez is szimpi :)
Title: Re: Tesztelés
Post by: balagesz on 2017.February.22. 22:23:47
Hát akkor mondjuk a Sprite hw sarkán? :ds_icon_cheesygrin:

Igen, akár! :)

Vagy inkább licencelni a SwinSID Ultimate-et hozzá.

A plus/4-es verzió kapcsán beszéltem pár szót az egyik alkotóval, nem zárkózott el akkor sem a dologtól, lehet bármi. Mondjuk az Ultimate verzióból az extrák zöme ide nem kell, mivel nem cél a 100%-os SID helyettesítés, elég ha csak a hang ugyanaz. :) A "gyári" SID illesztés is megoldható, csak van-e értelme, ha nemigen szerezhető be az IC maga? :|

Lehetne egy all-in-one hangkártya: SID, AY, 4x8 bit DAC.

Akár... AY emuláció van µC-ben? Mindjárt rá is keresek... :-D (Hát hogy a viharba ne lenne (http://www.avray.ru/)... :cool: )
Title: Re: Tesztelés
Post by: geco on 2017.February.23. 08:36:16
A "gyári" SID illesztés is megoldható, csak van-e értelme, ha nemigen szerezhető be az IC maga? :|
Szerintem nincs, de ez az én magánvéleményem :)
Title: Re: Tesztelés
Post by: balagesz on 2017.March.08. 00:18:56
No, ez nehéz szülés volt, de valami már van... Odáig eljutottam, hogy a csíkos tesztkép (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_001.jpg) a pozícióregiszterekkel már működik egy FPGA-val megvalósítva. Az FPGA feltöltésével valami olyan probléma volt, hogy ha töltés közben a gép irányából jött a multiplexelt jelhalmaz, akkor valahogy megőrült. Utána már nem lehetett újra letölteni, csak akkor, ha volt egy táp ki/bekapcsolás. De ha újra jöttek a muxolt jelek, ismét elhányta magát, mielőtt sikerült volna akár csak egy próba is. :| Szóval MINDENT kapcsolgatnom kell a próbához. :roll:

A memória-kezelés van most soron, utána meg az egyéb kiegészítések. Nem akarom elkiabálni, de már legalább látom azt a bizonyos fényt a hozzá tartozó alagúttal. (Csak miért dudál..?)
Title: Re: Tesztelés
Post by: Zozosoft on 2017.March.08. 10:07:34
Odáig eljutottam, hogy a csíkos tesztkép (http://bsz.amigaspirit.hu/Enterprise/pics/shot20161227_001.jpg) a pozícióregiszterekkel már működik egy FPGA-val megvalósítva.

:smt038

Quote
(Csak miért dudál..?)
:ds_icon_cheesygrin:
Title: Re: Tesztelés
Post by: balagesz on 2017.March.20. 00:36:34
Egy kissé nyögvenyelősen alakulnak a dolgok, de azért pár fejlemény van. Most csinálgatom a memória-alrendszert, de már szinte kezdtem feladni... A tesztkép nem teljesen stabil közben, meg ilyen jellegű problémák jöttek elő. :| Mint említettem, a használt FPGA-s nyák nem valami profi, így eléggé vicces azt kitalálni, hogy én rontok-e el valamit, vagy maga a hardver hülyéskedik. A RAM Z80 felőli elérését faragom, amivel odáig jutottam, hogy a RESET-kori RAM teszt hibát dobált szinte az összes szegmensre... Sima BASIC tesztprogramból viszont jónak tűnt, emiatt a visszaolvasásra tippeltem, mert ott kritikusak az idők. Na de a lényeg: a zavarok miatt bekötöttem a nyákra plusz tápokat vezetékekkel, aminek a végeredménye először nem lett biztató: a tesztkép továbbra is bugzik. :( Viszont a RAM-elérés teljesen megjavult, hibátlannak mutatja mindegyik teszt! :)

Aztán kiderülni látszik a tesztábra ugrálása is, az meg implementációs hiba volt, ami a CPLD-ben működik, az itt, az FPGA-ban nem stabil. De meglett a megoldás, egy kicsit fellelkesedtem... :)

És így estére gondoltam csinálok róla screenshot-ot. Újra bekapcsolva a cuccot, úgy ahogy van, működésképtelen lett az egész. Szerintem itt valami erőteljesen szívat! :evil: Az látszik, hogy ebből még lehet is valami, de mindenképpen kell szereznem valami használható FPGA dev-board-ot, mert ez így csak az idegeimet teszi tönkre.

Title: Re: Tesztelés
Post by: balagesz on 2017.March.20. 17:31:03
Azért csak nem hagyott nyugodni az esti eset; nekiálltam leellenőrizni a hardvert. Végigméricskéltem minden szóba jöhető összeköttetést, de látszólag minden jónak tűnt. Aztán kiszedtem az egyik IC-t a foglalatából, majd visszaraktam. A végeredmény: elindult a cucc:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20170320_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20170320_001.jpg)

A memória mennyiség úgy jön ki, hogy van 128K a gépben, 512K a bővítő kártyán, illetve ehhez hozzá jön még 512K a most berhelt elektronikáról. Ez jelenleg viszonylag jónak tűnik, a RAM-tesztek hibátlannak látják a plusz 512K-t. Az azért hozzátartozik, hogy néha el-el száll... :oops: Bár az is igaz, hogy meglehetősen "kalandosan" jut el a memória-tartalom a gépbe. :) De tulajdonképpen ez most nem annyira lényeges, ezt a memóriát jobb ha az EXOS nem használja el. Az idegeimmel játszó elektronika:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/pic20170320_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/pic20170320_001.jpg)

A megmozgatott IC a bal szélen látható PLCC84-es tokozású darab, kontakthibásnak tűnik a foglalat alatta. Egy kicsit "megfeszegettem" az érintkezőit, azóta látszólag jól csinálja a feladatát. (Jelenleg ez végzi a jelek multiplexelését, ez a végleges elektronikára - ebben a formában biztosan - nem fog kelleni.) Szóval most nyugi van, megyek vissza melózni. :)
Title: Re: Tesztelés
Post by: geco on 2017.March.20. 18:04:24
nem tűnik egyszerűnek a HW, igaz a TVC sprite HW-hez képest édes kis semmiségnek tűnik :D
Nekem ez a direkt 512K memória csak a sprite hardvernek teccik, így nem vesz el semmit a gép elöl.
Egy kérdés, hogyan lehet feltölteni adattal? Külön lapozóregisztere van? Vagy csak az EXOS számára nem látható, amúgy a szokott lapregisztereken keresztül belapozható?
Title: Re: Tesztelés
Post by: balagesz on 2017.March.20. 21:40:56
No igen, a TVC sprite HW-hez képest minden "egyszerű". :-D

A jelenlegi 512K-t most a 0x60..0x7F lapokon keresztül lehet elérni, de egy I/O regiszterbiten keresztül ki lehet tiltani az olvashatóságát. Indulásnál alapból tiltott, így az EXOS "nem látja", de írni lehet bele. Viszont ez a kérdés, hogy külön lapozóregiszter vagy megszokott módon lapozás, ez még nem eldöntött. Én hajlok a külön lapregiszter(ek) felé, némi perverzióval még azt is el tudom képzelni, hogy külön kiválasztható legyen az EP-s lap, ahol látszik a bővítőben kiválasztott lap. :) Viszont a legszebb az egészben az, hogy ezt bőven ráérünk akkor eldönteni, ha már kész a hardver! ;) (Hála a programozható logikának.)
Title: Re: Tesztelés
Post by: Zozosoft on 2017.March.21. 09:13:35
Esetleg egy teszt hardvert lehetne majd kapni? Elég ha csak annyit tud, amennyit az eddigi tesztekben láttunk.
Kipróbálni rakás különféle alaplappal.
Title: Re: Tesztelés
Post by: balagesz on 2017.March.21. 23:34:57
Van egy olyan gond, hogy ez a cucc a saját bővítésemen levő plusz buszcsatlakozóra csatlakozik. :) Ez aktív, buszmeghajtókkal megtámogatott csatlakozó, de elvileg ez nem szükséges, rá lehetne kötni az EP buszra közvetlenül is. Ha csinálsz egy passzív fordítót hozzá, akkor lehet róla éppen szó.
Title: Re: Tesztelés
Post by: Zozosoft on 2017.March.22. 07:21:58
Ha csinálsz egy passzív fordítót hozzá, akkor lehet róla éppen szó.
Ha jól értem egy élcsatlakozót és egy tüskesort kell összefordítani?
Title: Re: Tesztelés
Post by: IstvanV on 2017.March.22. 10:28:15
A jelenlegi 512K-t most a 0x60..0x7F lapokon keresztül lehet elérni, de egy I/O regiszterbiten keresztül ki lehet tiltani az olvashatóságát. Indulásnál alapból tiltott, így az EXOS "nem látja", de írni lehet bele. Viszont ez a kérdés, hogy külön lapozóregiszter vagy megszokott módon lapozás, ez még nem eldöntött. Én hajlok a külön lapregiszter(ek) felé, némi perverzióval még azt is el tudom képzelni, hogy külön kiválasztható legyen az EP-s lap, ahol látszik a bővítőben kiválasztott lap. :) Viszont a legszebb az egészben az, hogy ezt bőven ráérünk akkor eldönteni, ha már kész a hardver! ;) (Hála a programozható logikának.)

Szerintem hasznos lehetne az is, ha az 512K-t normál memóriaként is lehetne használni, így a sprite támogatás nélküli programokban is lenne előnye a hardvernek, a 128K-s gépeket 640K-ra bővíthetné (vagy valamilyen módon választani lehetne, mennyit lásson az EXOS).
Title: Re: Tesztelés
Post by: Zozosoft on 2017.March.22. 11:42:10
Ezt lehetne úgy, hogy bekapcsoláskor nem látszik, és aztán szoftverből lehet konfigolni.
Title: Re: Tesztelés
Post by: balagesz on 2017.March.22. 23:32:08
Ha jól értem egy élcsatlakozót és egy tüskesort kell összefordítani?

Tulajdonképpen igen. Ha jól sakkoztam, akkor ugyanaz a kiosztás, mint az EP buszcsatlakozója, kivéve a tápot! Itt kell a +5V, és ez a +9V helyére van nálam kötve. Ha közvetlenül az EP buszcsatlakozóra menne, akkor emiatt kell még egy +5V-os stab is.

Szerintem hasznos lehetne az is, ha az 512K-t normál memóriaként is lehetne használni, így a sprite támogatás nélküli programokban is lenne előnye a hardvernek, a 128K-s gépeket 640K-ra bővíthetné (vagy valamilyen módon választani lehetne, mennyit lásson az EXOS).

Ebben is van valami... Tulajdonképpen aminek nem kell a támogatás, az elhasználhatja a memóriát. Aminek meg kell, az meg ügyeskedik. :) Mindig elfelejtem, hogy itt nem multitask OS-ről beszélünk. :oops:

Ezt lehetne úgy, hogy bekapcsoláskor nem látszik, és aztán szoftverből lehet konfigolni.

Akár... Ha lesz a cucc mellett valami µC, akkor akár még el is tárolhatom valami pár forintos EEPROM-ba a konfigot. (Vagy egy óra-IC + SRAM kombóba? :-D )
Title: Re: Tesztelés
Post by: geco on 2017.March.23. 08:41:30
Nekem nagyon tetszik Zozó, és István ötlete is :)
Title: Re: Tesztelés
Post by: balagesz on 2017.April.09. 20:43:06
Egy kicsit volt időm foglalkozni a témával, de kezd ezzel a változattal elegem lenni... :-D Módosított teszt-színes kép:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20170409_002s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20170409_002.jpg)

Végre tényleg stabilan működik. Most már biztos, hogy a foglalat kontakthibája okozta a vicces sztori egyik részét. A RAM-ból kép generálás is összejött:

(http://bsz.amigaspirit.hu/Enterprise/pics/s/shot20170409_001s.jpg) (http://bsz.amigaspirit.hu/Enterprise/pics/shot20170409_001.jpg)

(A lila-hiba természetesen meg van maradva, de ebben semmi meglepő sincs.) Viszont úgy tűnik, hogy lassan elérem a jelenlegi hardver határait, legalábbis ami az idegrendszeremet illeti... :) Most éppen az SRAM sávszélessége van elfogyóban, a memória írások alatt már nincs direkt havazás, de néha-néha kicsúszik az időzítésből az olvasás emiatt. (A "háttér-memóriának" kell 14.xx MBYTE/Sec sávszélesség, nekem meg van jelenleg 40. De a Z80-as memóriaelérés a rengeteg multiplex jelkezelés miatt "nem túl rugalmas", emiatt jelenleg annak van prioritása. Ha pont úgy jön össze, akkor a háttér olvasása kicsúszik a szükséges időből, mivel a 40 az kisebb mint 3× 14.xx... Szóval ilyen marhaságok is beesnek. :) ) És a plusz adatmozgatás még nincs sehol... :-|  Mondjuk nem para, csak nem tudom, hogy van-e kedvem ezzel a hardverrel tovább küzdeni.

A küzdés jelenleg abból áll, hogy a használt FPGA egy (ebben az iparban :) ) meglehetősen régi darab, az aktuális fejlesztőkörnyezet már nem támogatja. (Összesen két előnye van: egyrészt itt van kéznél, másrészt meg ez még 5V-toleráns I/O lábakkal rendelkezik.) Emiatt egy régi IDE-t egy virtuális gépbe tudtam csak feltelepíteni, ami nem túl gyors, meg a végeredményt mindig ki kell belőle másolni a host-ra, hogy le tudjam tölteni az FPGA-ba. Mire mindent összelövök egy kis tesztelgetéshez, elmegy a kedvem az egésztől... :evil:
Title: Re: Tesztelés
Post by: geco on 2017.April.09. 21:51:32
Látványos :smt041 , ha ekkora a sz.pás ezzel a hardverrel, miért nem választasz egy könnyebb utat? Na nem a sprite kártya feladására gondoltam :ds_icon_cheesygrin:
Title: Re: Tesztelés
Post by: balagesz on 2017.April.09. 22:29:35
Azért küzdök ezzel, mert ez van. :-D Egy ideje gondolkozok valami egyszerűbb FPGA dev.board beszerzésén, de igazából még nem jutottam el a vendor kiválasztásáig se. :| De az itteni nyűglődés se értelmetlen azért; egy csomó tapasztalat már most összejött a mi működik / mi nem témakörében. Illetve - mivel ez az első FPGA-s próbálkozásom - eddig nagyjából fogalmam se volt, hogy az ilyen feladatok mekkora "kapu-szükséglettel" rendelkeznek. Így legalább lesz sejtésem arról, hogy mekkora "kapacitású" FPGA-t kell megcélozni a tervezésnél. Csak így azért elég nyűgös, mire összepakolom a gépet, elindítom a virtuálisat, abba az IDE-t, ... Egy "gyors ötlet kipróbálása" is sajnos elég hosszú idő, de ez van. :)
Title: Re: Tesztelés
Post by: geco on 2017.April.09. 23:07:34
Már ezzel a hardverrel elért eredményeid is nagyon látványosak, belegondolva, hogy mekkora sprite-jaink lehetnek, és a felbontás rontásával még animálni is lehetne majd simán. Gondolom ez a macera sokszor késlelteti is egy-egy ötlet kipróbálását :)