Stale sa to hybe. Projekt sa vola Framethrower a vyvoj sa da sledovat na Discorde PiStormu.
​​​S chladenim ti bohuzial nepomozem, pouzivam RPi3A.

Jde to uchladit pasivně. Navíc nějaký aktivní chladič tam společně s PiStormem nedostaneš - leží to na sobě a dělí to jen termovodivá podložka. Nechal jsem teď 1/2 hodiny běžet Quake I. na 640×480​ a drželo se to kolem 42 st. Aktivní chladič bude potřeba asi až u Rasberry Pi 5.

Prober (CADA) jo vida, ty mas vlastne Pi4.
1) jak prosimte resis vyvod HDMI z Pi4 ? planoval jsem toto https://retroready.one/collections/a...pistorm32-lite ale Pi4 ma microHDMI a takto kratky kabel s zahnutym microHDMI jsem nenasel, a redukci microHDMI->HDMI se tam nevejde
2) podle fotek mi prijde ze Pi4 trochu vytleza ven z trapdooru, je to pravda ?

Tady ti asi moc neporadím. Já mám Amigu přestavěnou do toweru, takže problém s místem řešit nemusím.

Nevíte někdo, zda a jak se dá nastavit metoda škálování videa přes videocore na Emu68? Konkrétní příklad: Mám výstup z Pi přes HDMI nastavený na 1280x1024 a připojený k LCD monitor se stejným fyzickým rozlišením. Když si ve Workbenchi nastavím RTG obrazovku v rozlišení 1280x1024, vše je "pixel perfect". Když však otevřu obrazovku RTG 640x512 nebo 320x256, je to rozmazané, i když jsou to přesné poměry toho maximálního rozlišení. Jak já tomu (možná špatně) rozumím, tak videocore v Emu68 přeškálovává z těchto nižších rozlišení pořád na to max. nastavené (tedy u mě 1280x1024) a používá k tomu nějaký interpolační algoritmus, který dopočítává přechodové pixely, takže výsledek je pak rozmazaný. Nevíte tedy někdo, zda a jak nastavit, aby se použilo jednoduché násobení pixelů (320x2=640, 640x2=1280, respektive 256x2=512, 512x2=1024) a nedocházelo ke zbytečné interpolaci při škálování? Třeba ve WinUAE to jde, u Indivision AGA Mk3 to taky funguje dobře.

Tu je tabulka kde porovnavaju vysledky render testu Jubimark v Lightvawe:




Z realneho HW je najrychlejsia Motorola 060/105Mhz s casom 51min 52sec (Lightwave 3.5), testovali to aj v Lightwave 5.0, kde im vyslo 41min 42sec na Matze TK060

z FPGA vysiel vitazne Pistorm s casom 5min 51sec (Raspberry 4B, som zvedavy na Raspberry 5)

Z emulacie je to WinUAE Intel i7 6700K 4,2 GHz s casom 1min 24sec (zaujimal by ma vysledok na najnovsom Ryzen 9)

Ja myslim ze to nejde. Jinak to popisujes spravne. Vetsina beznych 4:3 LCD ma prave to rozliseni 1280x1024, ktere nastavis konfiguraci emu68 a to se pouziva stale bez ohledu na nastaveni P96. U me, v jinem rozliseni nez v tom nativnim, mam nahore a dole cerny pruh, neni to moc rusive, ale podle me s tim nelze nic udelat, nevim, asi je to nejaka vlastnost toho P96 ovladace. Sice to nepises, ale nejspis to mas taky a ta chybejici cast prave zpusobuje, ze ty pixely nesedi 2:1 jak by clovek cekal. Kupodivu ja to nepravidelne nasobeni nikde napadne u sebe nevidim.

Chtelo by to napsat autorum, nejspis to ma nejaky duvod a mozna to casem vyresi, ale jen hadam.

Došlo mi, že se ptáš na něco trochu jiného než odpovídám. Člověk by čekal, že při těch rozlišeních, kde to vychází na celočíselné násobky, tedy pro 1280x1024 je to 640x512 a 320x256 bude ten obraz ostrý bez filtrace, ale není, pixely jsou opravdu rozmazané, i když to rozlišení je pěkně přes celou plochu panelu. To asi stojí za prozkoumání, ale nevím jak moc, když jde jen o jedno rozumné rozlišení 640x512 a druhé 320x256 je tak na Dooma. Těžko říct, jestli to vzníká někde v hloubi ovladače P96 nebo až na samotném RPI.

Já bych si spíš vsadil na ten P96 ovladač. Je tady totiž ještě to (podle mě nelogické) chování s černými pruhy při některých rozlišeních. 1280x1024 má totiž poměr bodů 5:4, i když panel je 4:3. Jenže to ten ovladač neví a nějak předpokládá, že ty pixely jsou čtvercové, tak se pro rozlišení například 1024*768 nebo 800x600, které mají poměr bodů 4:3, snaží nesmyslně dodržet poměr stran, aby mu to na těch 5:4 (víc čtverec) vyšlo požadovaných 4:3 (víc obdélník) a doplní nahoru a dolů prázdné pruhy. Jenže ta úvaha je myslím chybná a vznikne nějaká hloupost jako 5:3. Navíc kdo chce mít část panelu prázdnou, že. Podle mě ten mírně jiný poměr stran není ani vidět, případně by to chtělo přepínač, stejně tak ten pro filtraci, pokud někde už není.

Hledal jsem rady i jinde a na DIscord kanálu jsem dostal tip na tooltypes v ikoně ovladače P96, viz obrázek. Není ale prý nikde úplně zdokumentované, co přesně jednotlivé parametry znamenají. Nicméně ten VC4_INTEGER_SCALING vypadá slibně. Zatím jsem neměl čas si s tím hrát. Naprostou většinu času totiž používám na Amize klasickou turbokartu, ne pistorm emulaci. Ale plánuju to někdy zkusit přenastavit. Pokud to někdo vyzkoušíte dřív a budete k tomu mít nějaké postřehy, určitě se podělte

Vypadalo to nadejne, ale nic to nedela.

Bohuzial, ci su nasobky rozlisenia celociselne alebo nie, obraz sa prepocitava vzdy. Akurat niektore monitory a televizory na to maju kvalitnejsiu elektroniku, nez ine.

Tak uz vim, ta filtrace a dalsi parametry se nastavuji pomoci nastroje VC4Tweak

Mám otázku na majitele pistormu - někdy před rokem jsem zaznamenal, že by měl pistorm nějak zvládat zobrazovat pal. Byla to nějaká experimentální fičura. Už je to nějak finalizováno?

peclive sleduji a stale neni: https://eab.abime.net/showthread.php?t=116935&page=4 a https://discord.com/channels/7844284...51373397966900

To bude HW add-on, ktory bude posielat PAL priamo z chipu na video in PiStormu a ten ho bude autoswitchovat do svojho vystupu. Vsetko pojde von cez jeden HDMI kabel. Tiez sledujem vyvoj na Discorde 🙂