Elkezdtem dolgozni (még csak papíron) egy külsõ NICK chip-en, amely külsõ memóriával rendelkezik.
- Elsõdleges szempont a kompatibiltás, tehát mindent kell tudnia amit a Nick-chip, ami a megjelenítéssel kapcsolatos.
- A szabvány felbontások miatt arra jutottam, hogy egyszerûbb lenne, elhagyni a sorparaméter tábla függõleges szinkroziációhoz tartozó részt, és automatikusan végezné a hardver
Ez nem vili: nem kene ilyet tenni az LPT-be? Az fura lenne, mert akkor hogy lesz kompatibilis? Amugy meg interlaced stb trukkoknel ez nem jelent problemat? Amikor vsync van, de lpt reload nem. Vagy ugy erted, hogy maga a vsync mode az persze ott lenne, csak nem a parameterei alapjan csinalja (ize, ezt hulyen fogalmaztam meg)?
- Elõször 800x600-as felbontást akartam, de ahhoz 50Mhz-es pixel órajel kellne 72Hz-en, nekem csak 25Mhz áll rendelkezésre
- 640x480-as felbontás esetén elégséges 25Mhz pixel órajel, amely kb. 60hz-es függõleges szinkront ad.
Ennek hátránya, hogy csak 80 karakter széles képernyõt képes megjeleníteni, noha az eredeti nick max. 88 karaktet tudott. (Text 80 méretûre gondolok)
Egyelõre a keretszínt hanyagolom, még nem tartok ott.
Imho, amit a nick amugy kepes megjeleniteni, azt jo lenne latni
Az mas kerdes, hogy vannak erdekessegek: amire a nick "fizikailag" kepes pl horizontalis felbontasban, azt nem szokas hasznalni maxra: mivel a tv-knel van ugye az overscan, azaz amit a videojel hordoz informaciot, az nem mind "fer bele" a kepbe (legalabbis klasszikus tv-n, pl lcd-ken vannak ilyen beallitasok, hogy mutassanak mindent). Ez amugy filmeknel is erdekes, allitolag van arra pelda, hogy filmben belog valami oda nem illo, de mivel az overscan tartomanyban volt, senki nem figyelt ra, aztan kesobb tunt fel az embereknek
Ha (ismetlem, ha!) jol szamolom, tudom: 57 slot van egy soron belul, ebbol az elso nyolcban olvassa az lpt-t (ugye minden slot-ra ket byte-ot kepes a nick olvasni), az utolso haromban pedig hsync van. Ez elvileg igy 46 slot, ami max felbontas mellett (mondjuk pixel) 736 pixel. Ugye itt jon az overscan a kepbe, hogy bar a nick ezt mar pl tudja, ezt volt szokas kihasznalni, tekintve, hogy egy resze a legtobb (?) tv-n nem latszott. Most epp nem lelek nick doksit, de emlekeim szerint 42 slot-ot volt szokas kihasznalni, ezt ajanlottak, ez pedig 672 pixel. Szoval az a gond, hogy meg ez is tobb mint az altalad emlitett 640, es akkor meg hol van a keret, ami majd szinten jo, ha latszana a teljes feeling kereteben
Sorry, ha valahol tevedtem volna, emlekezetbol irtam az ertekeket, csak a 16-al valo szorzasnal vettem igenybe a szamitogep segitseget
A fuggoleges felbontassal kapcsolatban most hirtelen passz, de wikipedia szerint a PAL szabvany szerint: 313 sor (felkepenkent marmint), es ebbol 288 latszik (ez talan megint az overscan?), egy kep paros/paratlan sorokbol all ugye, tehat akkor lesz a fuggoleges felbontas az elmeleti 625, illetve a "latszik"-os 576.
Nagyon nehezen boldogulok a Sorparaméter Tábla kiolvasásával, elég bonyolult hardverrutin kell a feldolgozásához. Fõleg a legfontosabb, a karakteres képernyõ jelent gondot a bonyolult címzés miatt.
Ezek azert erdekes dolgok, mert nyilvan anno a Nick tervezesenel is szempont volt, hogy ne legyen tul bonyolult. Ergo biztos van benne vmi trukk, amivel egyszeruen megoldhato, legalabbis kevesbe bonyolultan
Amennyire tudom (de fixme) a Nick is vmi programozhato hw elem (ULA szeruseg, oszinten nem ertek ehhez annyira), tehat nem biztos, hogy filozofiailag annyira mas lenne pl egy FPGA-val megoldani ugyanezt a "mai idokben", ha ezt regebben is megoldottak ugymond "primitivebb" eszkozokkel
Ami igazán problémás az az idõzítés. Azt akarom, hogy ugyanolyan sebességgel tudja írni a külsõ memóriát a Z80 miközben a külsõ Nick is ugyanúgy hozzáfér, de ez utóbbi jóval többször akarja elérni. Bufferelni fogom a Z80 memória írási mûveleteit, és a vízszintes szinkronjel ideje alatt fogom az adatokat elhelyezni a külsõ memóriában. Ehhez viszont átmeneti tároló kellene, de olyan ami az adatokkal együtt a címet is megjegyzi. Ezt próbálom meg fejben összerakni.
Milyen memoria lenne az? Valami DRAM? Oszinten, en mindig SRAM-ban szoktam gondolkodni, nekem a DRAM bonyolult
Bar elvbol hallottam rola, de gyakorlatban ... hmm. Meg SRAM eseten is inkabb vmi dual port tarat hasznalnek, akkor nem gond a konkurens hozzaferes. Vagy, esetleg van olyan memoriavezerlo dram-hoz ami "emulal" dp tarat, bar nyilvan ezt mindenfele "halt"-jellegu signalok "postazasaval" eri el vagy hasonlo, vmi xt alaplapon volt ilyen szornyetegem egyszer az inteltol
Vagy ezt ugy kepzeled, hogy DRAM, es maga a memoriavezerlo minden stb az FPGA-ban van? Mondjuk gondolom a DRAM olcsobb mint az SRAM
Félek nem úszom meg, hogy drágább hardvert kell beszereznem a munkához, amelyben van beépített órajel sokszorozó, de akkor elvesztem az egyszerûség és olcsóság adta elõnyöket.
Imho (ismetlem: imho!) azert van egy-ket dolog ami alapveto, hogy azt tudja amit a nick tudott, felbontas stb. Az mas kerdes h "nick+" cimszoval lehet plusz dolgot is belevinni, de imho ne a kompatibilitas rovasara.
