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

 - Fórumok - Keresés - Statisztika - Szabályzat - Pegasos.hu fórum
forum.amigaspirit.hu / Fejlesztés / Free Pascal Compiler (classic és OS4 is)
<< 1 ... 9 . 10 . 11 . 12 . 13 .
Szerző Üzenet
Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 27. 17:08 - Szerkesztve: charlie


Én se, helyesebben tudtam, de nem nagyon érdekelt, egészen pár héttel ezelőttig, amikor valahol valami tök más kapcsán szembejött, hogy a Commodore PC klónok nemhivatalosan tudnak ColorPlus-t, csak ugye nem igazán hirtették sehol, mert annó úgyse volt rá semmi szoftver. Nekem meg persze ennek kapcsán szöget ütött a fejembe, hogy vajon a bridge tudja-e. 1db extra regisztert/IO portot kell átmappolni az Amiga oldalra hozzá, és lám-lám, a standard CGA regisztereken kívül ezt az egyetlen regisztert mappolja a bridge... :) Írtam rá 5 perc alatt teszt kódot, és tényleg megy. Azt meg már korábban is tudtam, h. a bridge-en 32K CGA RAM van mappolva, nem 16K. Szóval mindkét feltétel adott.

És mi értelme ha "nincs ware" ColorPlusra? Ugye azóta volt egy retró-hullám, szóval lett rá pár ware, pl. lett GEM driver (640x200 4 színhez), a Planet X3, meg valaki írt a Sierra kattintós gamékhoz is drivert. Na ez már több volt, mint amennyi ware pl. a 160x100-as textmode hackhoz van, és ugye azt is támogatom.

Már csak meg kellett találni a módját, hogy lehet beletákolni a Viaductba, úgy hogy még (relatív) gyors is legyen. Még van rajta mit bugfixelni (a delta-rendering még valahol szétesik), szóval egyelőre tipikus screenshotware, de lesz ez még így se! :)

kszgd
Tag
# Elküldve: 2022. Jún. 27. 20:14


Úgy látszik a bridge tervezői is úgy gondolták, hogy egy regiszterrel több, vagy kevesebb, meg egy címvezetékkel több, vagy kevesebb már nem számít egy ekkora lehetőségért. Arra persze nem gondolhattak, hogy 30 évet kell várni, mire lesz, ami ki tudja használni, de mondjuk most kíváncsi lennék az arcukra.

A játékok egy dolog, de már a GEM-ért önmagában megérte az egész, hogy el lehessen mondani, hogy Amigán is lehet GEM-ezni.
Erről a képről van szó, ugye?
http://charlie.amigaspirit.hu/screenshots/a2000/A2000-Viaduct-ColorPlus-1st.png

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 27. 22:00


Igen arrol. Amugy a GEM megy sima CGA-n is, de nyilvan csak fekete-feherben, nincs melle a brillians ket tovabbi CGA szin. :)

kszgd
Tag
# Elküldve: 2022. Jún. 27. 22:35


Azt sejtettem, hogy monokrómban megy alap CGA-n is, de en-bloc mondtam, vagy a PCWindow-on is ment a GEM?

Egyébként nem lennék meglepve, ha a Viaduct hatására előbb-utóbb valaki meglátná a fantáziát a bridge kártyákban és előrukkolna egy olyan bridge kártyával, ami egyéb regiszterek mappelését is lehetővé teszi és amivel megoldható lenne az EGA, vagy akár a VGA módok használata is.

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 28. 00:06 - Szerkesztve: charlie


PCWindow-on is ment a GEM, de csak sima CGA mono módban, és csak natív chipset teljes képernyőn. CGA módot WB ablakban vagy RTG képernyőn csak a Viaduct tud.

A GoldenGate-ek tudják az EGA/VGA/stb-t is, de azokhoz nincs programozási doksi, legalább nagy vonalakban, hogy az ember tudja miből indul ki.

Amúgy sajnos az EGA/VGA nagy ugrás a CGA-hoz képest. Az tud osztott képernyőt, miegymást, mindenféle latch és planar trükköket, szóval egy nagyságrenddel komplexebb (és lassabb) lenne támogatni, és-vagy jóval kompromisszumosabb lenne. A Viaduct elég keményen megdolgozik érte, hogy ne egy 640x400-as 16 v. 256 színű bitmapot lapátoljon az RTG kártyába, mert az még ennél is döglassúbb lenne hanem mindenféle bitplane-es trükkökkel, szinenként másolja a bitmapot, ill. a változásokat a bitmapban, és az RTG kártyán blitteli össze.

Persze egy lehetne mindenféle hardware-es trükköket bevetni ennek gyorsítására egy speciálisan erre fejlesztett bridge-en, de amíg a CPU-val kell átlapátolni a bitmapokat az RTG kártyára, addig mindig kompromisszumos lesz. Úgy mondjuk már izgalmasabb lenne, ha maga a Bridge kártya lenne egyben az RTG is, mert akkor a PC mehetne valamiféle hardware-es picture-in-picture megoldással. De az meg nem lenne olcsó. :) Szóval nehéz ügy ez, nem véletlenül nem voltak sokkal gyorsabb PC kártyák, mint az ilyen 486slc kategória. Afelett már mindent brutálisan visszafog az Amiga körülötte, sajnos.

kszgd
Tag
# Elküldve: 2022. Jún. 28. 08:23


Azt hittem a PCWindow-on nem is ment, mondjuk így mindenképp kényelmesebb.

Nekem sose volt RTG-m, így nem tudom: az amigás RTG-k nem tudnak chunky üzemmódot, ugyanúgy planar a videomemóriájuk, mint az Amigáé?
A deltát egyébként hogyan számolod? Arról is küld a kártya notify-t, hogy írtak a VRAM-ba? Gondolom, nem "kézzel" számolsz két frame közt deltát, mert az még lassabb lenne, mint ha mindig az egész framebuffert újrarajzolnád.

Olyan bridge kártyát is el tudnék képzelni, ami maga is el tudja végezni a képkonverziót hardware-esen és be tudja lapátolni az Amiga címtartományán belül bárhova.

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 28. 11:17 - Szerkesztve: charlie


Fú, ez hosszú lesz.

Az RTG kártyák (szinte mindegyike) chunky. Nem is csoda, hiszen sima SVGA chipekre épül (szinte) mindegyik, szóval ugyanazok a funkciók és pixel formátumok léteznek hardveresn mint pl. PC-n.

Bitplane-ek két helyen jönnek a képbe: hogy ugye, van egy 256 színű CLUT (palettás, chunky) RTG képernyőd. Ezen a Viaduct indulásnak lefoglal 16 pent. Viszont semmi garancia nincs rá, hogy ezek a palettában sorfolytonosan helyezkednek el, így a CGA színeket valahogy meg kell feleltetni nekik. Nem tudok olyat csinálni, hogy kezdőszín + CGA szín = végleges szín, szóval a CGA-ból kiolvasott képadatot dinamikusan (és CGA felbontás/üzemmód függően) konvertálom és renderelem az Amiga oldalon szinenként. Ez gyakorlatilag a BltTemplate() OS függvény halálba abuzálását jelenti, szerencsére ezt a függvényt az OS is használja pl. szövegkiíráshoz, így a legtöbb (de sajnos nem mindegyik!) RTG kártya gyorsítja. Egyelőre nem szórakoztam azzal, hogy CPU-s helyettesítőt írjak hozzá, ha a BltTemplate lassú. Magamnak írom a Viaductot, ha lassú nálad vegyél egy PicassoIV-t valami hatvanassal... :D

A másik, ahol bitplane-ek képbe jönnek, hogy a bridge-n 128K "buffer" RAM van, ami az Amiga és a PC közötti kommunikációhoz használható. Viszont ez a RAM 3x van az Amiga memóriájába mappelve, plusz még 128K van mindenféle I/O mappingekre, így a bridge 512K címtartományt használ. A háromszoros - mapping pedig byte, word (endian konverzió hardveresen), ill. graphics . Ez utóbbi arra jó, hogy a CGA color 2 bitplane interleaved bitmapot Amiga bitplane formátumba konvertálja hardveresen, ha ezen keresztül olvasod a CGA grafikus memóriát.

Ez utóbbit én is használom a Viaducttal, a 320x200, 4 színű ill. ugye a 640x200, 4 színű ColorPlus módhoz, de pl. 320x200 16 színben már egyszerűbb egy CPU-s CGA planar-to-per-color-bitplane konverziót csinálni, hogy be tudjam tolni a színeket egyesével a BltTemplate()-be... (Ami aztán egy off-screen bitmapba renderel és egy következő blittel kerül az ablakba, hogy ne villogjon a color-plane-enkénti renderelés...)

Továbbá igen, a kártya küld értesítést, amikor belehánytak a VRAM-ba (vagy a CGA regiszterekbe). Enélkül elég lehetetlen lenne állandó CPU load nélkül konvertálni ami kinyírná az Amiga-oldali multitaskot. Sajnos így is az van, hogy a játékok többsége agy nélkül renderel akkor is ha nem változott semmi, így folyamatosan kapok értesítést, szóval mindent meg kell tenni, hogy minél kevesebb dolgot csinálj per signal, eldöntendő, hogy mi változott, vagy mi sem. (És ha már horror-sztorik - van pár játék, amelyik pl. VBlank-ra sem vár CGA oldalon - ami amúgy valódi CGA kártyán "CGA snow" néven ismert jelenséget okozna -, így folyamatosan fogják a buffer RAM sávszélességét, na azok annyira kinyírják pl. a bridge-t is, hogy másodpercekig(!) tart kiolvasni egy frame-et... És ezzel nem is tudok szoftverből mit csinálni, egyszerűen egy move.l tart szabad szemmel is látható ideig...)

Deltát pedig úgy számolok, hogy CGA RAM előző állapotát elmentem kiolvasáskor egy Fast RAM-ban lévő bufferbe, és a következő körben ahogy olvasom sorban a DWord-öket, összehasonlítom a Fast RAM-ban lévő verzióval és csak azt a DWord-tolom bele a további mindeféle konverzióba, ami változott. Majd eközben trackelem, hogy éppen melyik sorban tartok és csak azokat a sorokat blittelem, amelyikben volt változás. (Helyesebben, 4 soros blokkokat, mert párosítom a CGA odd-even sorokat, plusz még ugye rajta van a vertical 2x-es scaling is.) Ill. most 16 színben, mivel 16 color plane van, ami elég sok, ezért azt is trackelem h. melyik szín plane-ek változtak, és csak azokat frissítem, amik változtak... :)

És igen, ez gyorsabb mint közvetlenül CPU-val blittelni pl. Z2-n. Mert a konverzió nagy része a Fast RAM-ban történik, meg ideális esetben a proci cache-jében. És a Z2-n az RTG kártyába másolandó adat mennyiségét próbálom limitálni, mert az a szűk keresztmetszet, sebesség ügyben, de olyan formában, hogy aztán a kártyán magán könnyen blittelhető legyen.

Amúgy ez az egész mechanizmus az, ami miatt a Viaductra azt mondom h. gyors 030 és gyors RTG kártya a minimum. Tervben van, hogy később pl. AGA-n közvetlenül bitplane-ekbe copyzást is csinálok, és akkor ott nem kell majd az OS függvényen keresztül izélni, meg konvertálgatni, de sok színű high res OCS/ECS-sel nem akarok szopni... Low end gépen nem célom a PCWindow-val versenyezni és nem is akarok, szerintem elég közel van ahhoz, amit régi Kickstarton és alap(-közeli-)gépen ki lehet hozni a témából. A probléma inkább ott volt, hogy high-end gépeken és RTG-n ment szarul, de arra meg ott a Viaduct.

Vagy majd ha mégis, akkor ilyen 5.0-s verzió környékén... :)

Addig is, szerintem ha már ilyen 4 magos RPi alapú vackaink vannak, akkor pl. ott lehetne az egyik magot pl. ilyen DMA-imitátor copper-szerűségre felhasználni, amivel tehermentesíthető lenne a "fő" proci, részben, és azzal a régi kártyák támogatása is jelentősen felgyorsítható lenne. Vagy ugyanez mondjuk PPC-ken is... Ezzel a régi kártyákat is lehetne támogatni, nem csak fantáziálni egy DMA-t tudó bridge kártyáról, ami sose volt, sose lesz. Na majd a Viaduct 7.0-ban... :)

kszgd
Tag
# Elküldve: 2022. Jún. 28. 12:49


Bevallom nem teljesen értem. Tehát van egy RTG palettád 256 színnel, amiben azonban a lefoglalt regiszterek össze vissza vannak.
Hogy van megoldva a konverzió, mit értesz az alatt, hogy színenként konvertálod?
Látatlanban nekem úgy tűnne logikusnak, hogy van egy 256 elemű longword táblád, amit minden képernyőmód beállításkor (hogy a CGA oldalon most mely 4 szín lesz használva a 16-ból) felépítesz, hogy amikor beolvasol 1 byte-ot a CGA memóriából, az abban található 4 db 2-bites CGA pixelt rögtön megfeleltesse 4 db 8-bites regiszterértéknek az RTG palettájából és így 4 pixelenként lehet egyetlen indexeléssel írni.
És ugyanezt a planar konverziónál is, csak ott 8 db 256 elemű byte táblád van, amiben a planar bitek vannak tárolva és persze két lépésben 8 pixelként (első upshift, második or) lehet írni. Ezt így nem lehet? Mert a delta résznél azt írtad, hogy longword-önként nézed és konvertálod.
És akkor a ColorPlusnál is ugyanez, csak ott meg 4 bitet kell mappelni 8-ra.
Vagy rosszul értem az egészet és itt a CGA VRAM nem chunky, tehát nem is lehet így feltáblásítani a konverziót?
(Egyébként nekem nincs bridge kártyám, csak érdekel a technikai rész.)

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 28. 13:11 - Szerkesztve: charlie


A 4 színt lehet(ne) így csinálni, de erre még rájön hogy függőlegesen és vertikálisan is scalezni kell, másként a CGA grafikus mód 320x200 bélyegmoziban jelenne meg. Így egyetlen frame 640*400 azaz 256000 byte átvitelt jelentene. Ha ugyanezt BltTemplate-tel okozom, akkor a driver először átmásolja a plane-eket, ami csak 96K (3 szín-plane, plusz háttér, de azt JAM2 módban az első plane-nel együtt blittelem, szóval 640*400/8*3), és a kártyán belül blittel hardverből, és ez utóbbi lépés úgy két nagyságrenddel gyorsabb mint ugyanez CPU-val a Zorron át. Ezen kívül a color-szinezős módszer nem függ az RTG kártya aktuális módjának színformátumától sem, mert pl. az én módszerem megy high color ill. true color gépeken is (csak példaként írtam a palettás módot), de a tiedhez minden RTG színmélységhez és pixelformátumhoz külön konvertert kéne írni. (És pl. high colorban és true colorban duplázódna ill. triplázódna/négyszereződne a buszon átlapátolandó pixelmennyiség.)

A 16 színű ColorPlus ennél bonyolultabb, mert az csak "félig chunky" - ott ugyanaz van, mint a 4 színű CGA módban, hogy 2 bit per pixel, és az egész képernyő kétszer van egymás után, először a $B8000-tól, utána $BC000-től, és az első másolatból jön a pixelek R G, a másodikból meg a B I értéke. És ezeket először össze kell maszkolni meg miegymás...

És igen, itt pl. felmerül a worst case scenario, hogy ha mind a 16 szín használva van egy sorban, akkor konrétan 16 (15, lásd háttérszín mint fent) szín-plane-et kell átmásolni ami (majdnem) a duplája mintha simán csak konvertálnám 8 bitre aztán heló. De ugye, lásd fent - ez a módszer megy tökmindegy milyen módban van az RTG kártya, pluszban, elég ritkán fordul elő, hogy egy sorban mind a 16 szín használva van (általában csak 3-4-5) így összességében még mindig kevesebb adat, mintha simán csak tolnék egy chunky konverziót, és hopp máris kifizetődött, hogy nyilvántartom, melyik sorokban melyik színeket kell blittelni.

(Amúgy igen, így is van egy rakás táblázat a dologban, pl. ahogy írod is a szín-index-konverzióhoz, sőt az 1 bites plane-ek vízszintessen 2x-esére nyújtásához is, szóval azzal nem mondtál újat.... Nem mondom, hogy nem lehetne jobbat csinálni mint ami a Viaductban most van, de végeredmény és kódkarbantarthatóság/méret szempontjából elég sok előnye van annak, ahogy most van, és sebességre sem utolsó, sőt.)

(Szerk: Ja és bónuszban, az én módszerem megy AGA-n is, mivel a végeredmény kirendereléséhez kizárólag OS függvényeket használ. Nyilván natív chipseten foslassú jelen állapotában, és AGA-n tökre nincs értelme így csinálni, de technikailag megy. Itt megint csak kapcsolódnék a fenti "minden módhoz külön konvertert kell írni" problémához.)

kszgd
Tag
# Elküldve: 2022. Jún. 28. 13:57


Azt nem tudtam, hogy a BltTemplate az belül ügyködik, ha az tényleg annyival gyorsabb, akkor nincs miről beszélni. (Mit értesz amúgy a két nagyságrend alatt? Gondolom nem 100-at.)
Tény, hogy minden bitdepth/format külön konvertert igényelne, de azt ki lehet rakni library-ba és csak azt a libet behúzni, amelyik bitdepth/format aktív. A kérdés inkább az, hogy gyorsabb, vagy lassabb lesz vele. De ha a másik megoldás a belső blit miatt úgyis gyorsabb, akkor megint nincs miről beszélni.
(Egyébként nem volt célom, hogy újat mondjak, csak rákérdeztem arra, amit nem értettem; mint mondtam, a technikai részletek érdekeltek.)

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 28. 14:05 - Szerkesztve: charlie


Persze, értelek, nyugi. Nagyságrendek:

A Zorro II-n, de még a legtöbb ZIII kártyán is, egy számjegyű MB/sec-et tudsz másolni a kártyába, pl. a Picasso IV-mnek valahol 4,5MB/sec körül van vége ZII módban (tehát kb. AGA chip RAM speed), és 9MB/sec ZIII-ban. De a leggyorsabb ZIII kártyáknak is vége (CV64 pl.) kb. 15 körül. De még az elvileg PCI-os BPPC/CVPPC ill. egy Voodoo a GRex PCI-ban is max. 20-25-ig nyújtózkodik ha jó napja van (konfig függően)... Ez a realitás.

A Cirrus Logic GD5446 ami a PicassoIV-n van, a kártya 4MB 45ns-es EDO RAM-jában kb. 180MB/sec-kel tud fillezni a 64bites belső buszon... Nyilván ez utóbbi érték erősen függ attól, hogy mit csinálsz, de a "két nagyságrend" talán nem teljesen légből kapott... :)

Library: a kód maga tökmindegy hol van, az exében vagy kint, attól még meg kell írni és karbantartani. Én már írtam párszor hasonló bitmap-bitdepth konvertert, és húsz éve még fun volt egyesével asm-ban optimalizálgatni minden rutint a demó-motorhoz, de azóta öreg lettem és lusta... :) Szóval ha megy valami egyféleképpen és "elég gyors" akkor jó az úgy.

De amúgy - és ez most tényleg nem ilyen "csináljjobbat" megjegyzés, csak tény - az ilyesmi rendering rutinok megírásához nem kell a bridge, fogsz egy akármilyen RTG-s amigát, meg egy CGA formátumú képet, aztán hajrá, lehet tesztelni a különféle megoldások létjogosultságát. Én is ide jutok majd - még sosem próbáltam a Viaductot a lassabbik A2k-mon, amiben csak egy 25Mhz-s harmincas és PicassoII van... Előre fáj a teszt eredménye... :D

kszgd
Tag
# Elküldve: 2022. Jún. 28. 14:42


Hát így, hogy mondod, hogy 180 MB/s, így már érthető, hogy amit csak lehet, azt belül oldod meg vele; nem tudtam, hogy ez ilyen batár gyors, sose volt RTG-m.

Nem arra gondoltam, hogy assemblyben kéne optimalizálgatni, amúgy sem órajelciklusok spórolásával lehet igazán gyorsítani, hanem jobb algoritmussal, de igazából okafogyott a kérdés; a választ már megkaptam: azzal a 180 MB/s-kel nem lehet CPU felől versenyezni.

Az lehet, hogy az RTG convert/rendering rutinokat tesztelendő nem kell bridge kártya, de RTG továbbra is kell hozzá, ami továbbra sincs. A WinUAE-ben elvégzett ilyen jellegű mérések meg nem biztos, hogy pontosak és hitelesek lennének.

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 28. 14:58


Ja, a WinUAE mérések nem jók, ahogy pl. a PiStorm (vagy Vampire vagy Warp1260) se - legalábbis ha a "tradicionális" cuccokatra is szeretnél optimalizálni -, mert ugye ott minden egy fizikai RAM-ban van ergó az RTG RAM azonos sebességű a Fast RAM-mal...

Amúgy így van, jobb algoritmussal lehetne javítani, de figyelembe véve a limitációkat és lehetőségeket ezt tudtam összehozni. Van azért amin lehetne gyorsítani, de tartok tőle hogy a rutin nagy része az így is a Zorro-felé történő adat-tolásra vagy a bridge kártyából történő adat kinyerésre vár, szóval hogy a pixel konverziók is Pascalban vannak és nem assemblyben, max. ilyen 25Mhz-s 030-on számíthat, a hatvanason majdnem mindegy.

kszgd
Tag
# Elküldve: 2022. Jún. 28. 16:28


A kártya egyébként tud olyat, hogy "suspend"-be, vagy "freeze"-be küldi a PC-s CPU-t? Kb, mintha egy CLI + HLT futott volna le, csak ezt az Amiga felől lehet állítani.
Ha igen, akkor azzal talán megoldható lenne, hogy a folyton renderelő, VBlank-ra se váró cuccokat felfüggeszd időnként, hogy legalább azokat a notify-kat feldolgozhasd, amik beestek.
A notify-kat azonnal feldolgozod amúgy, vagy queue-ba pakolod, hogy ha egy frame alatt ugyanazt a címet ötször írta valamelyik ware, akkor csak egyszer kelljen kiolvasni, mert úgysem látszik?

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 28. 17:28


PC-fék: Nincs ilyesmi rajta, nem. Resetelni lehet csak a gépet az Amiga oldalról. A korabeli PC-s chipek szerintem nem is nagyon tolerálnák, ha valami csak így megállítaná őket... Nem volt az divat akkoriban.

Notify queue: nincs értelme, mert csak a latency-t növeli, a rendering meg úgyis elég lassú hozzá, hogy magától "összevár" több változtatást is... Amúgy a "notify" az egy exec signal és mivel a videó feldolgozás külön szálon megy, de belül single threaded, ezért addig úgysem dolgoz fel további notify-kat, amíg be nem fejezi az előző feldolgozását. De mivel az exec signalhoz tartozó hardware-es interruptot a janus.library kezeli, ezért simán lehet olyan, hogy a háttérben történnek a HW-s interruptok és ez CPU időt zabál, miközben én még bőven az öttel előző signallal vagyok elfoglalva. De erre nekem semmilyen ráhatásom nincs a Viaduct szintjéről.

kszgd
Tag
# Elküldve: 2022. Jún. 28. 17:39


Hát így tényleg nehéz a Viaduct oldaláról megoldani; ehhez már az kéne, hogy a janus.library-ba nyúlj bele, de az meg gondolom zárt forrású.

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 29. 10:28


Ja. Amúgy, akár a janus.library szintjén, nemtom mennyire lehetne ezt pl. megoldani szoftverből, hogy a bridge ne interruptoljon folyton ha írják a ramját, mert az se jó, ha meg "úgy hagyod" az interrupt vonalat egy darabig, mert akkor meg a többi Zorros kártya nem tud interruptolni, lévén Amigán elég rendesen használva van az interrupt sharing.

Ehhez hardware feature kéne, hogy pl. csak akkor interruptoljon a kártya, ha az előző "virtuális" CGA vblank óta írták. Az mondjuk egy jó megoldás lenne. De mivel ilyet nem tud, azzal főzünk ami van.

Más: csináltam 640x400 mono módot is. Sajnos Viaduct specifikus, mert a bridge nem mappel elég regisztert az innenső oldalra, hogy pl. AT&T 6300/Olivetti M24 kompatibilisé lehessen tenni. De a teszt app amit Turbo Pascalban hekkeltem össze öt perc alatt, működik. Kép itt.

Most már csak egy moddolt Windows 3.1 CGA driver kéne... :)

kszgd
Tag
# Elküldve: 2022. Jún. 29. 11:38


A kártyához nincs regisztertérkép, vagy ilyesmi? Mert akkor még egy OpenJanus-t se lenne lehetetlen csinálni. Mondjuk tegnap ránéztem a janus.library-ra, kb. 10kB, talán nem akkora munka visszafejteni, ha az ember tudja, hogy amikor a kártyához szól, akkor mit is csinál.

Ez 640x400 mono ColorPlus?

A win3.1 CGA drivernél nem tudom mit értesz az alatt, hogy moddolt, de itt van egy win3.1 CGA driver: https://archive.org/details/cga_20210607

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 29. 13:30 - Szerkesztve: charlie


Regiszter-map: de van, az A2000/500 Technical Reference manualban van egy elég részletes XT bridge-doksi, de abban nincs benne minden részlet, meg pl. az A1060 sidecar és az A2386sx kicsit eltér ettől egypár részletben, amennyire tudom. De őszintén, nem hiszem h. megéri ezzel szopódni... Főleg mert egy csomó minden a Janus újraírása nélkül is kicserélhető, lásd ugye Viaduct... És DOSServből is van pl. alternatív Amineten, AutoLoadból meg pl. én is írtam egy alternatív hackelt verziót service loading debughoz. Szóval én biztos nem fogok ezzel szórakozni a közeljövőben.

A ColorPlus nem tud 640x400 mono-t, de gyakorlatilag igen, amit a Viaduct csinál, az olyan mintha tudna. :) Mert ugyanabban a regiszterben kell átbillenteni egy másra nem hasznát bitet, mintha a ColorPlus módokat használnád.

A Windows CGA drivert ismerem, már használtam is Viaducttal, de az csak 640x200-ban fog menni anélkül, hogy megtanítsuk neki hogy kell 400-as módba kapcsolni ezzel a kombinációval. De ahhoz ugye moddolni kéne és most nem érzem h. én feltétlenül 16 bites Windows drivereket akarok disassemblálni...

kszgd
Tag
# Elküldve: 2022. Jún. 29. 20:48


Pedig lehet, hogy értelmesebb interrupt handling-et tudnál írni, mint ami a janus.library-ban van és akkor kinyílna pár új lehetőség, persze gondolom van más dolgod is.

Ez vicces, szóval Amigán lassan több képernyőmód elérhető CGA-ból, mint PC-n. A kompozit amúgy a lehetetlen kategória, vagy a nagyon sok szívás kategória lenne?

Így ebből a képből - hogy még a win3.1 is megy vele - elég jól kiviláglik, hogy mennyire szomorú, hogy ezt a potenciált anno nemhogy nem használták ki, de hagyták eltűnni a süllyesztőben.

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 30. 13:19 - Szerkesztve: charlie


mennyire szomorú, hogy ezt a potenciált anno nemhogy nem használták ki, de hagyták eltűnni a süllyesztőben.

Ez kb. az egész Amigára igaz, nem csak a PC kártyákra, szóval nem tudom ez miért meglepő... :)

A kompozit - most már, hogy csináltam 16 színű rendert - nem lehetetlen, de még egy lépés kell hozzá, mégpedig a palettakezelés átdolgozása. A Viaduct jelenleg fix palettával dolgozik, vagyis mindig ugyanaz a 16 CGA szín aktív. Kompoziton teljesen más színek vannak, szóval oda át kell alakítani az egész színkezelést (és akkor még ilyen apróságokról, hogy egyes klóngépeken az is minden bekapcsoláskor(!) változni tud, hogy milyen színek vannak, mert attól függ hogy a colorburst signal pont milyen fázisban van a pixeladathoz, és ezért vannak szoftverek amik más színekre számítanak, stb... :) nem is beszéltünk).

És aztán persze ennek is vannak Amiga-oldali buktatói is, pl. a Viaduct jelenleg shared pen-eket használ a képernyőn, de ha én a 16 színemnek random állítgatni akarom a palettáját, akkor exkluzív pen-eket kell használnom, ami azt okozhatja, hogy pár gépen ahol szép színes a háttér, és palettás módban van a WB, eddig ment a Viaduct ablakban, most meg hirtelen nem menne, mert nem lenne elég lefoglalható pen, szóval nem lehet azt sem csak úgy kivenni, stb ... :)

Szóval talán érthető, hogy mikor a ColorPlus lehetőség kiderült miért voltam egyből motiváltabb 16 színű grafika rendert írni, a kompozit színkezelés helyett. De így most már csak másfél-két lépésre van a kompozit, nem ötre. Szóval meglátjuk mihez lesz kedvem.

kszgd
Tag
# Elküldve: 2022. Jún. 30. 19:42


Nem azt mondtam, hogy meglepő, hanem, hogy szomorú. Hogy ebben is mennyi lehetőség lett volna még.

Mindenképpen egységesíteni akarod a kettőt? Külön kompozit és non-kompozit színkezelés nem játszik?
Mennyire lehet a kompozit színkezelést táblásítani?

Jelen pillanatban mi történik, ha az összes pen foglalt a háttér és az ikonok miatt? Kiválasztja a CGA paletta színeihez legközelebb álló peneket?

Chain-Q
Divatamigás

# Elküldve: 2022. Jún. 30. 22:33 - Szerkesztve: charlie


Mindenképpen egységesíteni akarod a kettőt? Külön kompozit és non-kompozit színkezelés nem játszik?

Long story short, igen, és nem. Nincs értelme, a kompozithoz való színkezelés megfelel a normál CGA színeknek is, fordítva nem, ha meg mindent lefoglalok külön-külön ami kell, akkor meg többszörösére ugrik a szükséges Pen-ek száma, ami szintén nem túl jó, kompatibilitás tekintetében.

Jelen pillanatban mi történik, ha az összes pen foglalt a háttér és az ikonok miatt? Kiválasztja a CGA paletta színeihez legközelebb álló peneket?

graphics.library/ObtainBestPenA() ... :) Amit az a függvény éppen csinál. Sajnos-szerencsére ezt elég sokat variálták - pl. a színválasztó algoritmus tekintetében - a 3.0 (v39) óta eltelt mindenféle OS és RTG rendszer verziókban, de nagy vonalakban igen, ha shared access kérsz, akkor ha nincs elég pen, a legközelebbit adja. Ha meg exclusive accesst kérsz, akkor szimplán kapsz egy -1-et, vagyis hogy nincs pen.

Szerk: link javitva

kszgd
Tag
# Elküldve: 2022. Júl. 01. 07:44


Értem, thx a linket. (A végén van egy felesleges "l" karakter, így 404.)

Awe
Tag

# Elküldve: 2023. Aug. 28. 17:17 - Szerkesztve: awe74


FPCDeluxe segytségével fordítottam egy FPC 3.3.1 + Lazarus 3.99 fejlesztő környezetet.
Target OS : Amiga
Taget CPU : m68k

program Project1;

begin
WriteLn('Hello world!'');
end.


Nem fordul le. :

Fatal: Can't find unit lineinfo used by Project1


Hiba megoldva, de még mindig nem kerek

Chain-Q
Divatamigás

# Elküldve: 2023. Aug. 29. 15:16


Mi nem kerek?

Awe
Tag

# Elküldve: 2023. Aug. 31. 14:41


warning 1007 in line 52 of "/home/awe74/Projects/Amiga/Lazarus3/lib/m68k-amiga/project1.s": scratch at end of line
>.section .data.n_FPC_WIDEINITTABLES,"adrw"

warning 1007 in line 58 of "/home/awe74/Projects/Amiga/Lazarus3/lib/m68k-amiga/project1.s": scratch at end of line
>.section .data.n_FPC_RESSTRINITTABLES,"adrw"

warning 1007 in line 69 of "/home/awe74/Projects/Amiga/Lazarus3/lib/m68k-amiga/project1.s": scratch at end of line
>.section .data.n___stklen,"adrw"

warning 1007 in line 75 of "/home/awe74/Projects/Amiga/Lazarus3/lib/m68k-amiga/project1.s": scratch at end of line
>.section .data.n___heapsize,"adrw"

warning 1007 in line 81 of "/home/awe74/Projects/Amiga/Lazarus3/lib/m68k-amiga/project1.s": scratch at end of line
>.section .data.n___fpc_valgrind,"adrw"

warning 1007 in line 89 of "/home/awe74/Projects/Amiga/Lazarus3/lib/m68k-amiga/project1.s": scratch at end of line
>.section .rodata.n__$PROJECT1$_Ld1,"adr"
Hint: (11030) Start of reading config file /etc/fpc.cfg
Hint: (11031) End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 3.2.2-r0d122c49 [2023/08/29] for m68k
Copyright (c) 1993-2021 by Florian Klaempfl and others
(1002) Target OS: Commodore Amiga
(3104) Compiling project1.lpr
(9009) Assembling project1
(9015) Linking /home/awe74/Projects/Amiga/Lazarus3/project1
(1008) 6 lines compiled, 0.0 sec
(1022) 2 hint(s) issued

Ez van megadva a CompilerOptions/Custom Options -ban:
-Avasm
-XV
-Fu~/fpcupdeluxe/fpc/units/m68k-amiga/*

Chain-Q
Divatamigás

# Elküldve: 2023. Sze. 08. 21:24 - Szerkesztve: charlie


Ez egy vasm bug, amit már kijavítottak, miután reportoltam. Használj 1.8-as, vagy 1.9d vagy újabb vasm-ot! (Jelenleg nincs az 1.9d-nél újabb, csak a jövőre nézve.)

Ezt a Free Pascal wiki Amiga oldala is írja, nagy piros betűkkel:
https://wiki.freepascal.org/Amiga#Assembler

Szerk: és a vasm 1.9d changelogban is benne van:
"std-syntax: Fixed potential problem with "scratch at end of line" warnings after a section attribute string."

<< 1 ... 9 . 10 . 11 . 12 . 13 .
forum.amigaspirit.hu / Fejlesztés / Free Pascal Compiler (classic és OS4 is)
 
 

Powered by simple bulletin board miniBB™ © 2001-2024