Ide gondoltam a Nick mûködésével, ill. egyéb kép és HW kapcsolatáról szóló dolgok megbeszélését. Ha kéritek, akkor írok róla összefoglalót is.
Szerintem mindenkinek hasznos volna egy ilyen összefoglaló, hogy tisztán lásson. Viszont gondolom mások sem szeretnék hogy ez a bõvítõkártya készülésének a rovására menjen ;-)
Szerintem mindenkinek hasznos volna egy ilyen összefoglaló, hogy tisztán lásson.
Viszont gondolom mások sem szeretnék hogy ez a bõvítõkártya készülésének a rovására menjen ;-)
Ide gondoltam a Nick mûködésével, ill. egyéb kép és HW kapcsolatáról szóló dolgok megbeszélését. Ha kéritek, akkor írok róla összefoglalót is.
Hát igen, lassan lesz egy új EP alaplap 2000 MHz-es emulált Z80-nal, 1600*1200 felbontásra képes NICK II-vel valamint 192kHz-en 96 biten mintavételezni tudó DAVE II-vel... :) Nameg az elsõ 8bites Linux... :D Meg esetleg MS-Windows... :wink:
Ezt most nem értem, miért írtad. A legutolsó "ötleted" szinte már támadás ellenem. :smt065
Az elõtte levõ értelmetlenség, az az elõttiekrõl pedig legfeljebb egyesek álmodozhattak.
O.K., túlzásokat írtál, tehát nyilvánvalóan poén, de tényleg nem értem, hogy jön ide. :smt017
Jaj, melyik ötletem? :oops:
A Redmond-i cég emlegetése...
Quote from: "tigrian"A Redmond-i cég emlegetése...
:) Már azt hittem, valamelyik értelmesnek szánt ötletemmel támadtalak.... Csak poén akart lenni... :oops: :smt083
Akkor most jöhetnek a kérdések, folyt. köv., ha tetszett.
A szgépek (és a monitorok) nem is használják ezt a módszert. Az EP sem, valójában tehát minden második félkép egyforma.
A színek bekeverését (pontosabban az RGB-bõl a világosság és színjelek elõállítását) az EP-ben másik cél-IC végzi.
Akkor most jöhetnek a kérdések, folyt. köv., ha tetszett.
Quote from: "tigrian"A szgépek (és a monitorok) nem is használják ezt a módszert. Az EP sem, valójában tehát minden második félkép egyforma.
Jól értem?
Minden páros sor megegyezik a páratlan megfelelõjével a számítógépek képmegjelenítése esetén?
A színek bekeverését (pontosabban az RGB-bõl a világosság és színjelek elõállítását) az EP-ben másik cél-IC végzi.Quote from: "geco"Gondolom ezt a TV modulátor végzi, EP esetében nem túl jo hatásfokkal.
Arra gondoltam, hogy digitalizalni kene a videojelet, elrakni egy szeeep nagy puffer RAM-ba, ahonnan viszont egy masik videojel megjelenito aramkor olvasni ki nagyobb sebeseggel, akar tobbszor is, amig egyszer feltolti a Nick-bol erkezett adatokkal. Ekkor persze 'tulfut' a Nick-en, pl 100Hz-es TV-k mukodnek hasonloan az ket puffert hasznal, igy egy frame kesessel lehet latni, az egyik puffer tartalmat latja az ember a kepernyon, a masik meg tellik a video jelbol erkezo adatokkal, aztan utana csere van.
Amugy a Nick eddig "legszebb" tulajdonsaga hogy egy egyszeru digitalis halozat (ULA/PLA ilyesmi lehet talan?), tehat pl analog jel ha jol tudom nem is igazan jon ki rajta, hanem pl 8 "vezetek" jon ki
marmint azt nekunk kell adni, es elvileg lehet igy nyujtani vagy kicsinyiteni azt az idot ami egy frame felepitesre kell (az mas kerdes hogy mit szol hozza egy TV).
Ha eleg gyors a RAM (mert ugye egy un Nick slotban a Nick max 2 byte -ot tud olvasni) akkor lehetne emelni a Nick byte fetch / slot maximumat, es akkor lehetne beallitani olyan modot ahol tobbszorese a vizszintes felbontas emiatt.
Alapvetoen ha jol latom az egesz problema ott vagy hogy ez azert (is) limitalt, mert ugye a memoria sebessege adott
neha a Nick igy is kenytelen megallitani a CPU-t egy kis "cikluslopasert" (ill ha jol tudom ezt a Dave csinalja, marmint a jelet o adja ki).
Tetszik!
A 625 sorból mennyi a hasznos képsor? Valami ötszáz akármennyi?
És mivel a NICK a két félképnek ugyanazt adja, ezért marad kétszáz akárhány soros felbontása?:smt045
... a PC monitorok is használták ezt az interlace technikát, amikor egyre nagyobb felbontást kezdtek kitalálni
Úgy 5-6 éve tünhetett el végleg az Interlace a PC technikából.
Ez minden TV-nél más és más, beállítás kérdése, de úgy nagy átlagban olyan 560 körüli lehet.
lgb és Zozo, jaj, nagyon elõreszaladtatok a RAM olvasásával, ez a következõ rész témája lett (volna). Gondoltam, haladunk tematikusan, de ha már mindenki úgyis tudja...
:) Tanár úr kérem! Azért gondoljon a többi elsõs diákra is :)
Szóval jöhet a következõ rész!
A RAMDAC választása ugyan tetszõleges, a sor hossza viszont szigorúan kötött, a színsegévivõ órajelével szinkronban kell lennie. Elrettentésül: (284-0,25) * 15625 Hz = 4433618,75 Hz, ez a színsegédvivõ.
Gyakorlati okokból a NICK órajele a RAMDAC kétszerese. Mivel a NICK ugyanazt a jelet használja a RAMDAC-nak is és a sorképzésre is, ezért további kötöttségek vannak. Az órajelnek a sorfreki (15625 Hz) többszörösének kell lennie. Feltéve, hogy még 16-tal is osztható az arányuk, így csak bizonyos értékek jöhetnek szóba. A doku szerint 57*16 = 64 usec. Ez alapján a NICK órajele 14.25 MHz. Ha nem annyi, akkor egyéb trükkök is vannak. De nem hinném.
Szerintem el is túlozták kissé, alig akad monitor, ami az ennek megfelelõ felbontást produkálni tudja. TV meg aztán pláne nem. Feltételezem, produkálniuk "kellett" a minél nagyobb felbontást. No meg azért a 8 pixel széles, 80 karakteres képernyõ feltételezi a legalább 12.75 MHz-et. És akkor még nincsen BORDER sem. Szóval alacsonyabb frekivel, 6*8-as karakter olvashatóbb lenne, de az jókora bonyodalmakkal járna...
Vegyük elõ ismét a videojelet!
(http://enterpriseforever.com/userpix/3_di39fig05_1.jpg)
Egy slot 16 RAMDAC órajelet (így 16 pixelt, ill. 32 NICK órajelet) jelent, 1,1228 usec-et. Az elsõ 8 tehát kb. 9 usec.
Az ábra szerint viszont 4.7 + 0.6 + 2.5 + 1.6, összesen 9.4 usec ideig nem lehet képtartalom (a sor a szinkronjel elejétõl kezdõdik, ezért nem számoltam a rajzon szereplõ kezdõ 1.5 usec-et).
Miért érdekes ez?
A NICK a 8-ik slot után, vagyis a 9-ik usec-tõl már kiteszi a videojelbe a BORDER-nek megfelelõ színt. Egy kicsit tehát belelóg abba a tartományba, ahol még fekete szintet kéne produkálnia. Az eltérés nagyon kicsi, általában nem okozhat problémát. Lehetnek azonban TV-k, monitorok, amik meghülyülnek tõle, ha a BORDER nem fekete (ill. alacsony világosságjel-tartalmú).
A soridõ végén is vannak betartandó követelmények, adott ideig ott sem szabad mást, csak fekete szintet kiadni. De ez nekünk már nem fontos, a lényeg, hogy az utolsó 3 slotban már nem lehet aktív képtartalom.
Ez alapján a NICK órajele 14.25 MHz. Ha nem annyi, akkor egyéb trükkök is vannak. De nem hinném.
Tehát ha belegebedsz, akkor sem tudsz kb. 360 pontnál jobb színes felbontást produkálni. Ez nem jelenti azt, hogy minden második pixel egyforma, a fényességük lehet más. A színük nem. Egy sötétkéket pl. követhet világoskék. Piros viszont kizárt. Ez persze csak a kompozit jelre vonatkozik. RGB-ben (legyünk szabatosak: compound jel esetén) bármit lehet.
Quote from: "tigrian"Tehát ha belegebedsz, akkor sem tudsz kb. 360 pontnál jobb színes felbontást produkálni.
Gondolom ez az oka annak, hogy gyárilag csak monochrom kompozit jel van kivezetve.
És hogy is van az az Y-C? Akkor már lehet 2 szomszédos pixel más színû?
Színes meg monocrom composite jelet be lehet vezetni egy TV-be svhs csatlakozón át jó eredménnyel?
Az EP esetében ez rajtunk nem segít, csak az RGB. Ott viszont az alacsony sorfreki a gond. Nemigen találsz hozzávaló monitort. :cry:
Az EP-n alacsony a sorfreki vagy a monitoron? :oops:
Nemigen találsz hozzávaló monitort.
:smt017 Az RGB monitorok nem ugyanúgy váltottsorosak mint a composite monitorok/TV-k?
A megoldást most már az LCD-k jelentik, nemsokára már teljesen leváltják végre ezeket. Azok között már most is találhatsz RGB bemenetût, amit TV-nek árulnak, annál van esély, hogy 15 kHz-en jár (bár nem biztos).
Szóval ha valaki véletlenül (vagy majd ha olcsóak lesznek) vesz egy LCD TV-t EP-jéhez, akkor még az is lehet, hogy pofára esik??? :smt074
Bizony, több oka is lehet rá. A képminõségtõl is történhet vele ilyen, a cipõfûzõje is kioldódhat, meg az is lehet, hogy vásárlás elõtt nem ellenõrizte a paramétereket. :roll:
:smt017 Az RGB monitorok nem ugyanúgy váltottsorosak mint a composite monitorok/TV-k? Valahogy nálam a progresszív megjelenítés a VGA monitorokkal került képbe... :smt090
Nem kell tehát feladni, de jóval egyszerûbb az LCD felé kacsintgatni.
:smt017 Az RGB monitorok nem ugyanúgy váltottsorosak mint a composite monitorok/TV-k?
Van valakinek LCD TV-je? Megnézte már rajta az EP képét? Ha igen, milyen?
Az õsi CGA monitorok valóban majdnem használhatóak lennének.
... Ami valoszinübb lehetne:EGA/VGA monitor.
Ezzel el is érkeztünk az analóg rész végéhez. Ígérem, legközelebb már ismerõsebb terep lesz. :-)
És mikor lesz az a legközelebb? :-)
Addig is itt egy kép neked, példának, hogy mennyire nem lehet a színeket megjeleníteni a videojelben.
Quote from: "tigrian"Addig is itt egy kép neked, példának, hogy mennyire nem lehet a színeket megjeleníteni a videojelben.
Ez valami tévéadásból van?
És mindez ugye a kompozít videójelre vonatkozik, ugye? :-)
Szerintem 75%, hogy nyálcsuri csodálatos képe van az Ep-nek egy olyan kütyün. SCART -lukba dugva az Ep-t persze...
a felbontás nem minden. Kisebb felbontással is lehet élvezhetõ képeket gyártani
Quote from: "Ep128"Szerintem 75%, hogy nyálcsuri csodálatos képe van az Ep-nek egy olyan kütyün. SCART -lukba dugva az Ep-t persze...
Hát ez nem olyan biztos! De majd megkérdezzük Tigriant is, hogy jól gondolom-e :-)
Én a PC-s LCD/TFT monitorokból kiindulva nagy problémákat sejtek...
Visszatérve az elejére: vajon milyen felbontása van egy LCD TV panelnek? és ez mennyire egész számú többszöröse az EP felbontásának?
nagyjából 640*480 körüli (talán egy picit nagyobb) a felbontás, a nagy méretûeknél is. Tehát senki ne akarjon ilyet PC-re kötni, monitornak.
... az ideális olyan 680 lenne, erre kiférne a 42 karakteres sor is, picike borderrel.
Quote from: "Zozosoft"Quote from: "Ep128"Szerintem 75%, hogy nyálcsuri csodálatos képe van az Ep-nek egy olyan kütyün. SCART -lukba dugva az Ep-t persze...
Hát ez nem olyan biztos! De majd megkérdezzük Tigriant is, hogy jól gondolom-e :-)
Én a PC-s LCD/TFT monitorokból kiindulva nagy problémákat sejtek...
Elvileg igen, a képpontoknak a megjelenítés helyére kéne esniük. De ez már az analóg monitoroknál sincs így, sõt, ott meg aztán végképp nem. Ehhez a részéhez nem értek, valamilyen fiziológiás dolog lehet mögötte. A nagyobb felbontásnak is (az adott monitor képességeihez képest) elvileg nincs értelme, mégis nagyobb felbontás érzetét lehet vele elérni. Vagyis mûködik a dolog.Quote
Visszatérve az elejére: vajon milyen felbontása van egy LCD TV panelnek? és ez mennyire egész számú többszöröse az EP felbontásának?
A TV-kbe tudtommal a leggyengébb verziókat teszik. Vagyis úgy nagyjából 640*480 körüli (talán egy picit nagyobb) a felbontás, a nagy méretûeknél is. Tehát senki ne akarjon ilyet PC-re kötni, monitornak.
Ez izgi, mert az LCD Tv-k nagy részét úgy árulják, hogy "számítógéphez is ajánlott" -cetli van rányalva... :-)
Quote from: "Ep128"Ez izgi, mert az LCD Tv-k nagy részét úgy árulják, hogy "számítógéphez is ajánlott" -cetli van rányalva... :-)
Gondolom itt a számítógép = PC. Filmnézésre meg lehet, hogy jó.
Quote from: "lgb"Ha eleg gyors a RAM (mert ugye egy un Nick slotban a Nick max 2 byte -ot tud olvasni) akkor lehetne emelni a Nick byte fetch / slot maximumat, es akkor lehetne beallitani olyan modot ahol tobbszorese a vizszintes felbontas emiatt.
Ilyesmin én is gondolkodom :) Szerencsére van egy nem használt videómód bitkombinációnk, így simán meglehetne csinálni kompatibilisre!
Nana, az teljesen mas! A videomod igazabol azt hatarozza meg, hogy a beolvasott adatokbol milyen modon legyen kepi informacio, azaz peldaul ilyen es olyan videomod, ennyi es annyi szinnel stb. Igazabol az hogy pl 2 byte helyett negyet olvasson be az nem videomod fuggvenye, meg keves is lenne az az egy darab nem hasznalt bitkombinacio, hiszen minden (na jo majdnem minden) videomodnal szukseg lehetne esetleg dupla vizszintes felbontasra, sot van ahol a negyszerezes is jo lenne (pl 256 szinu mod), stb. A nem hasznalt bitkombinaciot inkabb arra kene fenntartani, hogy pl 15 v 16 bites szinmelyesegu mod :)
MB - Mód byte.
* VINT - Ha be van állítva, ennek a MODSOR-nak a kezdetén megszakítás generálódik (lásd késõbb).
* SZÍN MÓD - Azt vezérli, hogyan fordítódnak a képernyõbyte-ok színbyte-okká.
o 00 - Két színû mód
o 01 - Négy színû mód
o 10 - 16 színû mód
o 11 - 256 színû mód
* VRES - Beállítva teljes függõleges felbontást engedélyez, törölve csak korlátozott felbontás van a grafikus módokban.
* VIDEO MÓD - Átfogó video mód. Azt vezérli, hogyan legyenek kiolvasva a képernyõbyte-ok a video RAM-ból.
o 000 - VSYNC mód
o 001 - PIXEL mód
o 010 - ATTRIBUTE mód
o 011 - CH256 mód
o 100 - CH128 mód
o 101 - CH64 mód
o 110 - nincs használva
o 111 - LPIXEL módQuote from: "lgb"Nana, az teljesen mas! A videomod igazabol azt hatarozza meg, hogy a beolvasott adatokbol milyen modon legyen kepi informacio, azaz peldaul ilyen es olyan videomod, ennyi es annyi szinnel stb. Igazabol az hogy pl 2 byte helyett negyet olvasson be az nem videomod fuggvenye, meg keves is lenne az az egy darab nem hasznalt bitkombinacio, hiszen minden (na jo majdnem minden) videomodnal szukseg lehetne esetleg dupla vizszintes felbontasra, sot van ahol a negyszerezes is jo lenne (pl 256 szinu mod), stb. A nem hasznalt bitkombinaciot inkabb arra kene fenntartani, hogy pl 15 v 16 bites szinmelyesegu mod :)
Nem nyert :-)Code: [Select]MB - Mód byte.
* VINT - Ha be van állítva, ennek a MODSOR-nak a kezdetén megszakítás generálódik (lásd késõbb).
* SZÍN MÓD - Azt vezérli, hogyan fordítódnak a képernyõbyte-ok színbyte-okká.
o 00 - Két színû mód
o 01 - Négy színû mód
o 10 - 16 színû mód
o 11 - 256 színû mód
* VRES - Beállítva teljes függõleges felbontást engedélyez, törölve csak korlátozott felbontás van a grafikus módokban.
* VIDEO MÓD - Átfogó video mód. Azt vezérli, hogyan legyenek kiolvasva a képernyõbyte-ok a video RAM-ból.
o 000 - VSYNC mód
o 001 - PIXEL mód
o 010 - ATTRIBUTE mód
o 011 - CH256 mód
o 100 - CH128 mód
o 101 - CH64 mód
o 110 - nincs használva
o 111 - LPIXEL mód
A nem használt 110 videó móddal lehetne jelezni, hogy über brutál hiper szuper nagy felbontású grafika :-) és ehhez még ott van a 2 szín mód bitünk is!
mi van, ha en pl ATTRIBUTE modban szeretnem duplazi a vizszintes felbontast? Vagy a karakterek CH modokban?
En errol beszeltem amikor azt mondtam, hogy szerintem szerencsesebb lenne ha nem azt az 110 kombinaciot hasznalnank erre
Najo, lehet hogy ez a 15/16 bpp kisse tulzas, tenyleg.
Leírom a mostanában megfogalmazodott ötletemet, Tigrian biztos örülni fog neki :-)
Úgy látom nem lenne szükség új alaplapra sem, megoldható lenne egy külsõ Nick2 kártyát csinálni.
Leírom a mostanában megfogalmazodott ötletemet, Tigrian biztos örülni fog neki :-)
... megoldható lenne egy külsõ Nick2 kártyát csinálni.
Ami a programozását illeti, alapvetõen lgb-vel értek egyet, én sem az ún. nem használt videómódot használnám. Inkább új IO portot neki, aztán onnan már bármi lehet. Vagyis nem tolgozgatnám az eredeti LPB-t.
De erre késõbb majd visszatérhetünk.
Most inkább nem ezen járatom az agyam, hanem befejezem a köv. fejezetet. :P
Quote from: "lgb"mi van, ha en pl ATTRIBUTE modban szeretnem duplazi a vizszintes felbontast? Vagy a karakterek CH modokban?
Ezeknek én nem érzem az égetõ szükségességét :)
Quote from: "lgb"En errol beszeltem amikor azt mondtam, hogy szerintem szerencsesebb lenne ha nem azt az 110 kombinaciot hasznalnank erre
És hogyan oldanád meg az eredetivel való 100%-os kompatibilitást?
QuoteNajo, lehet hogy ez a 15/16 bpp kisse tulzas, tenyleg.
Szerintem is! Én a grafikus módokban eggyel nagyobb felbontással már bõven beérném. A kettõvel jobb már überkirály lenne, de ott már jönne a Video RAM méret gond is...
És arra is gondolni kell, hogy ha nem csak állóképeket akarunk nézegetni, hogy a Z80 meg tudjon bírkozni a kép adatok piszkálásával. Ha egy 7-8 Mhz-es Z80-hoz tennénk egy 2x felbontást tudó Nicket, az nyílván úgyanolyan könnyedén mûködne, mint a mostani felállás.
Ha a proci akarja elérni a memóriát, miközben a NICK is, akkor a NICK egész egyszerûen "elveszi" a proci órajelét arra az idõre. Brutális, de hatékony megoldás :-)
Itt egy kicsit nem értem a tervezõket. Az élvezérelt megszakítás miatt csak 2 soronként lehet IT-t generálni. A NICK-ben létezik félsoros jel, amivel törölhetné ezt a bitet. Nem értem, miért nem ezt tették.
A 8-ik, hiányzó módot TPIXEL-nek hívják (tiny resolution pixel talán?), de vagy csak nem dokumentált, vagy nem is létezik.
- LD2 helyén találjuk minden módban a pixel adatot (ami a shift regiszterbe kerül), kivéve a PIXEL módokat. Nem értem, miért ez a distinkció...
- PIXEL módokban LD2 nem használt. A doku szerint függõleges felbontás megadására szánták, egy késõbbi idõpontban. Nem világos, mit érthetnek ezalatt. De talán összefügg az elõzõ megjegyzésemmel.
LPIXEL
Ez ugyanaz, mint a PIXEL, de csak egy byte-ot olvas be (így LD1-et csak 1-gyel növeli), és a RAMDAC csak a fele. Fele annyi display memória kell hozzá, egyébként nem tudom, mi értelme.
A doku szerint függõleges felbontás megadására szánták, egy késõbbi idõpontban.
Tigrian! Kezd izgatni, hogy miféle Nick leirásod van! Mert se az angol se a magyar EXOS könyvbeli leírás nem említi azt a TPIXEL-t... meg más izgalmasat is említesz, pl:QuoteA doku szerint függõleges felbontás megadására szánták, egy késõbbi idõpontban.
Pontosan ez :) Azt irtak rola hogy a Nick egyik elonye hogy olyan rendszerbe is hasznalhato legyen, ahol igencsak keves RAM van
Tigrian! Kezd izgatni, hogy miféle Nick leirásod van! Mert se az angol se a magyar EXOS könyvbeli leírás nem említi azt a TPIXEL-t... meg más izgalmasat is említesz, pl:QuoteA doku szerint függõleges felbontás megadására szánták, egy késõbbi idõpontban.
ET1/1 (tehát a legelsõ az összes doku közül :-) )
Az EXOS leírás nem ebbõl, hanem az ET1/3-ból (egy évvel késõbbi) készült, ha jól látom.
Szkenneltem, majd megbeszéljük, hova küldjem. :wink:
...TPIXEL...
Ez nem Tigrian's Pixel mód? :smt109
Ez nagyon izgalmasan hangzik! Milyen kincseid vannak még? :-)
Quote from: "Zozosoft"Ez nagyon izgalmasan hangzik! Milyen kincseid vannak még? :-)
(http://enterpriseforever.com/userpix/3_et11_1.gif)
Nekem IS dokuk vannak fénymásolva. Az EXOS leírás is ezekbõl készült (ill. u.az).
Ha jól látom, csak két olyan példányom van, ami nem forog közkézen.
És még nincs bescannelve? ;-)
Nekem I.S. dokuk vannak fénymásolva.
Quote from: "MrPrise"És még nincs bescannelve? ;-)
Akkor most én mondom, hogy vissza kéne olvasni... :wink:
Quote from: "tigrian"Nekem I.S. dokuk vannak fénymásolva.
Nagyon izgalmas! Honnan szereztél te ilyeneket? :-)
Kár hogy az EXDOS-ból nem jutott :(
QuoteKár hogy az EXDOS-ból nem jutott :(
Dehogynem! Mondom, ez az EXOS doku.
http://tigrian.fw.hu/nicksamp.zip
Quote from: "tigrian"http://tigrian.fw.hu/nicksamp.zip
hiba 404 :(
párosítd a file-nevet a másik domain-nel, úgy is megtalálod. :wink:
...az EXDOS-t hiányolom :-) amibõl csak a tartalom jegyzék van az angol oldal mirrorján :(
Ez az extended LPB gondolat se rossz, én mondjuk az LD1-be tenném a kérdéses LPB-hez tartozó eLPB címét.
Ha már úgyis új HW, akkor az interface is hozzá lehet új. SW kompat. eleve kizárva,
Átolvastam, amit itt a NICK bõvítésérõl fejtegettetek. Nem igazán értem, mit akartok bonyolítani.
Az odáig rendben, hogy jó lenne egy CH mód, nagyobb felbontással, hogy a 80 karakteres szöveg is gyorsabb legyen. Az is O.K., hogy grafikára is jó lenne egy nagyobb felbontású/színû üzemmód.
Azt viszont nem értem, hogy miért akarjátok ezt az LPB-be belezsúfolni. Ha már úgyis új HW, akkor az interface is hozzá lehet új. SW kompat. eleve kizárva, legalábbis a grafikát illetõen. A karakteres módot is meg lehet oldni, anélkül, hogy az LPB-t tolgozgatnánk.
Quote from: "tigrian"Ha már úgyis új HW, akkor az interface is hozzá lehet új. SW kompat. eleve kizárva,
Na ez az ami nekem nem tetszik! Mert így ha régi programot, vagy akárcsak EXOS-t futatsz, az csak a régi Nicken látszódna, az új kártyán nem.
Ezért nekem az lenne az alapkövetelményem, hogy az új Nick pontosan ugyanazt csinálja mint a régi! Olvassa az LPT-t, stb, így minden jelenlegi program látszodna az új kártyán.
Esetleg lehetne úgy, hogy átkapcsolni egy nem LPT-s módra, de ez nekem nem tetszik, nem EP-s megoldás :)
LPT-t, mint az egyik legEP-sebb dolgot, mindenképpen meg kéne tartani. Így lehetõvé válna a régi és új módok tetszõleges keverése, akár soronként is.
Szerencsére ott a nem használt videómód, így egyszerûen szépen be lehet illeszteni egy nagyobb felbontású grafikai módot.
Én alapvetõen másra nem is vágynék :) Ha karaktermódokat is akarjuk tuningolni, arra is van egy ötletem: a VRES bit-et jelenleg nullázni kell. Ennek 1-es értéke jelenthetné a HW80-as módot. Így akkor nem kéne mindenféle extended LPT-ket kitalálni.
De ez most ugyis csak egy ötlet roham, hogy elüssük az idõt addig, míg jön a Nick elõadás következõ része :) :) :)
a Nick filozofiaban pont az tetszik, hogy igen keves "globalis" dolog van amit pl I/O porton kell beallitani, es minden mast "ugy szed fel" a Nick mukodese kozben, teljsen automatikusan, nulla CPU behatassal
Ezért nekem az lenne az alapkövetelményem, hogy az új Nick pontosan ugyanazt csinálja mint a régi! Olvassa az LPT-t, stb, így minden jelenlegi program látszodna az új kártyán.
LPT-t, mint az egyik legEP-sebb dolgot, mindenképpen meg kéne tartani. Így lehetõvé válna a régi és új módok tetszõleges keverése, akár soronként is.
Szerencsére ott a nem használt videómód, így egyszerûen szépen be lehet illeszteni egy nagyobb felbontású grafikai módot.
Én alapvetõen másra nem is vágynék :) Ha karaktermódokat is akarjuk tuningolni...
De ez most ugyis csak egy ötlet roham, hogy elüssük az idõt addig, míg jön a Nick elõadás következõ része :) :) :)
...Azonban karakteres modnal azert kell nullazni...
Quote from: "Zozosoft"LPT-t, mint az egyik legEP-sebb dolgot, mindenképpen meg kéne tartani. Így lehetõvé válna a régi és új módok tetszõleges keverése, akár soronként is.
Egyetértek, szerintem is a NICK a legjellemzõbb elem a vasban. Azzal már nem feltétlenül, hogy az jó dolog, ami abban van.
Quote from: "Zozosoft"Szerencsére ott a nem használt videómód, így egyszerûen szépen be lehet illeszteni egy nagyobb felbontású grafikai módot.
Na ebben tér el a véleményünk. Minden adott a nagyobb felbontáshoz, minden üzemmódban, egyedül csak a RAMDAC-ot kell felgyorsítani. Ezt pedig szerintem globálisan érdemes, nem pedig soronként. Kár tehát az LPT-be piszkítani. Ugyanazt az LPT-t (ill. majdnem ugyanazt, a pointereket újra kell számolni) egy új vas nagyobb felbontással jeleníthet meg, a NICK pedig annak a felét, negyedét stb (vagyis egy ablakot belõle). Tehát semmiféle új módot nem kell kitalálni.
És ez szépen bele is illik az EXOS-ba. :wink:
Quote from: "lgb"...Azonban karakteres modnal azert kell nullazni...
NEM, minden sor elején 1-gyel nõ az LD2 értéke. Ha azt is újratöltöd, csak a legfelsõ sort ismételgeted.)
Az ET1/1 szkenn kellene nekem
http://tigrian.fw.hu/nicksamp.zip oldal nem létezik!
No, tudjuk tehát, mik a lehetõségek. Az EP-ben ki is választották a maximumot, 7.125 MHz a RAMDAC (elvileg).QuoteA RAMDAC választása ugyan tetszõleges, a sor hossza viszont szigorúan kötött, a színsegévivõ órajelével szinkronban kell lennie. Elrettentésül: (284-0,25) * 15625 Hz = 4433618,75 Hz, ez a színsegédvivõ.
Gyakorlati okokból a NICK órajele a RAMDAC kétszerese. Mivel a NICK ugyanazt a jelet használja a RAMDAC-nak is és a sorképzésre is, ezért további kötöttségek vannak. Az órajelnek a sorfreki (15625 Hz) többszörösének kell lennie. Feltéve, hogy még 16-tal is osztható az arányuk, így csak bizonyos értékek jöhetnek szóba. A doku szerint 57*16 = 64 usec. Ez alapján a NICK órajele 14.25 MHz. Ha nem annyi, akkor egyéb trükkök is vannak. De nem hinném.
ATTR
Attribútum mód, ez egy újabb indirekció segítségével 16 színt engedélyez, de slot-onként csak kettõt.
BUF1 <- (LD1), ide kerül a színinformáció (a paletta indexe. Vagyis a palettája :-) )
BUF2 <- (LD2), ez pedig 2-C adat, ezt kell megjeleníteni, ez kerül a shift regiszterbe.
[row][col] b7 [col] VINT. Az ide írt érték egész egyszerûen kikerül a NICK egyik lábára, ami a DAVE-ben az egyik megszakítás-figyelõ lábra megy. Normál esetben ezt minden félképben (20 msec) egyszer kell 1-esbe tenni, a többi sorban 0-ba. Így áll elõ egy 50 Hz-es megszakítás.
[row][col] b4 [col] VRES. Ha itt 0 van, akkor az LD1-et és az LD2-t is újratölti, minden scanline kezdetén. Szép hosszú függõleges sávokat lehet így egyszerûen elõállítani :-)
QuoteA 8-ik, hiányzó módot TPIXEL-nek hívják (tiny resolution pixel talán?), de vagy csak nem dokumentált, vagy nem is létezik.
LPB+2 LM Left Margin (és egyebek)
b7,b6 MSBALT, LSBALT. Ez két érdekes bit, 2-C PIXEL módban ezekkel 8 szín közül lehet 2-t használni. A HW-ünk tehát így módosul:
LPB+3 RM Right Margin (és egyebek)
b7,b6 ALTIND1, ALTIND0. A szerepük hasonló, mint az xSBALT biteknek, de 2-C karakteres üzemmódban, és nem a karakter képe szerint színez, hanem a kódja szerint.
Az "érvénytelen" mód valójában olyan karakteres módnak tekinthetõ, amely a pixel adatot mindig FFFFh video címrõl olvassa :)Az ilyen elvetemült dolgokat hogyan sikerült ki kísérletezni?
Az ilyen elvetemült dolgokat hogyan sikerült ki kísérletezni?
És akkor az emu mindezen nem dokumentált érdekességeket is tudja?
Vajon aki megírta az emulátort, az a referenciából olvasta, hogy a NICK-nek hogyan kell mûködnie, vagy megszerezte a NICK terveit és onnan írta meg?
Van egy sanda gyanúm, hogy a második.
Ha a NICK legalább két byte-ot olvas be minden kiírás elõtt, és ebben az esetben mindkét byte ugyanonnan származik (FFFFh)
Akkor már támogathatná legalább az OpenGL 1.2-õt is. Szép álom, de jó lenne :)És mindebben mi lenne Enterprise?
Semmi.
De abban a hozzászólásban amire válaszoltam, vajon mi az Enterprise? Mert a videón egy "játékkonzol"-szerûség van házilag... Ha már erre ment el a téma, hogy milyen legyen a Nick II (III, IV, V, ...), akkor ha lúd, legyen kövér :)
Kérdésem az, hogy ez nem-e lehet a NICK hibája miatt, hogy nem engedi hozzáférni a memóriához, vagy bezavar, és emiatt hiba lép fel?Nem, egyszerûen megpimpósodott a RAM IC, van ilyen.
Szerinted mennyiért fogják elvinni? Kelleni fog így valakinek? Elég gány a doboza is. Meg a hátulján is kopottak a feliratok.100-150 fontot tippelek, vitrinbe jó a hibás gép is...
Hogyan módosítsam az lpt végét, hogy NE interlace módban jelenítse meg a képet?
létezhet olyan, hogy a lpt blok nem ~200*16Byte hanem 15-20 * 16Byte ezáltal valamivel kevesebbszer WAIT,HALT -olja a procit ?
Mivel ilyenkor nem kell kiolvasni az LPT blokokat.
Hogyan módosítsam az lpt végét, hogy NE interlace módban jelenítse meg a képet?
Hozz létre egy 68 soros karakteres üzemmódot (ami 68*9=612 pixelsor) és ezt egészítsd ki egy 13 pixelsoros vsync modsorral.
http://www.ep128.hu/Ep_Konyv/Enterpress_Cikkek.htm
Ha kész a kód szólj én is kipróbálom.
>3FB000 F7 08 0B 73 B8 FE E9 01 :w..s8~i.
>3FB008 00 36 00 49 FF 24 2D 36 :.6.I.$-6
>3FB010 E9 02 3F 00 00 00 00 00 :i.?.....
>3FB018 00 00 00 00 00 00 00 00 :........
>3FB020 50 32 0B 33 00 40 00 00 :P2.3.@..
>3FB028 00 FF 58 F8 00 00 00 00 :..Xx....
>3FB030 C5 82 3F 00 00 00 00 00 :E.?.....
>3FB038 00 00 00 00 00 00 00 00 :........
>3FB040 FD 00 3F 00 00 00 00 00 :}.?.....
>3FB048 00 00 00 00 00 00 00 00 :........
>3FB050 FE 00 20 3F 00 00 00 00 :~. ?....
>3FB058 00 00 00 00 00 00 00 00 :........
>3FB060 FF 00 3F 38 00 00 00 00 :..?8....
>3FB068 00 00 00 00 00 00 00 00 :........
>3FB070 FD 00 3F 00 00 00 00 00 :}.?.....
>3FB078 00 00 00 00 00 00 00 00 :........
>3FB080 F2 02 06 3F 00 00 00 00 :r..?....
>3FB088 00 00 00 00 00 00 00 00 :........
>3FB090 E9 02 3F 00 00 00 00 00 :i.?.....
>3FB098 00 00 00 00 00 00 00 00 :........
>3FB0A0 F7 08 0B 73 B8 FE E9 01 :w..s8~i.
>3FB0A8 00 36 00 49 FF 24 2D 36 :.6.I.$-6
>3FB0B0 E9 02 3F 00 00 00 00 00 :i.?.....
>3FB0B8 00 00 00 00 00 00 00 00 :........
>3FB0C0 50 32 0B 33 00 77 00 00 :P2.3.w..
>3FB0C8 00 FF 58 F8 00 00 00 00 :..Xx....
>3FB0D0 C5 82 3F 00 00 00 00 00 :E.?.....
>3FB0D8 00 00 00 00 00 00 00 00 :........
>3FB0E0 FD 00 3F 00 00 00 00 00 :}.?.....
>3FB0E8 00 00 00 00 00 00 00 00 :........
>3FB0F0 FE 00 06 3F 00 00 00 00 :~..?....
>3FB0F8 00 00 00 00 00 00 00 00 :........
>3FB100 FF 00 3F 20 00 00 00 00 :..? ....
>3FB108 00 00 00 00 00 00 00 00 :........
>3FB110 FD 00 3F 00 00 00 00 00 :}.?.....
>3FB118 00 00 00 00 00 00 00 00 :........
>3FB120 F3 02 06 3F 00 00 00 00 :s..?....
>3FB128 00 00 00 00 00 00 00 00 :........
>3FB130 E9 03 3F 00 00 00 00 00 :i.?.....
>3FB138 00 00 00 00 00 00 00 00 :........
Ez gyakori probléma az újabb, "digitális" TV-knél (ilyen lehet az említett 100 Hz-es TV is, amely valószínûleg digitalizálja a video jelet, és minden félképet kétszer jelenít meg); ezek egyszerûen nem támogatják a 8 bites gépek nem szabványos (azaz nem 625 soros interlace, 15625 Hz sor- és 50 Hz félkép frekvencia) video kimenetét. A gyártóknak úgy látszik, nem éri meg ezzel foglalkozni, ha a felhasználók 99%-a csak normál (interlace) TV adást néz a TV-n.Ugyanez lehet a Scart csatlakozós monitorok esetén is, az ott tapasztaltak alapján az LG használ olyan módszert ami számunkra a legjobb eredményt adja. Érdekes módon az interlace EP képbõl (pl IVIEW) is jó minõségû állóképet csinál.
Érdekes módon az interlace EP képbõl (pl IVIEW) is jó minõségû állóképet csinál.
De mi ebben az érdekes? Ez a PAL szabvány, nem?A PAL interlace és az EP interlace az más dolog.
Kezdünk kicsit eltávolodni egymástól, noha próbálok tényleg jól fogalmazni.
Tehát a TV-mnek szerintem az a problémája, hogy nem jól dolgozza fel az interlace módot. Errõl szeretnék megbizonyosodni úgy hogy non-interlace módot állítok elõ az EP-n.
ugye elolvastad a korábbi hozzászólásomat amiben leírtam, hogyan próbáld meg a 625 soros non interlace módot előállítani?
Bizony a Nick hûtõlapja volt. Valahogy levált róla.Ezt írtam már többször is, így 25 év után szokása lepotyogni.
Azon gondolkozom mivel tegyem vissza.Én maradtam a gyári megoldásnál, pillanatragasztó.
a 64Mb-os kiterjesztett memória alól
Ehhez nem kell méregetni, elég elolvasni egy NICK leírást :-)
Mivel 8 bitet elég nehéz egyenlõ arányban három felé osztani, így jött ki, hogy a piros és zöld 3 bites, a kék 2 bites.
Igazság, hogy nem annyira azért kellene, mert valami nálam kinn lenne a képbõl, hanem mert én szeretnék rá programozni :) - hogy mennyire szabad elszaladni a függõleges oszlopok számával, hogy úgy általában feltérjen egy TV képére.
Piros és zöld szintek: 0x00, 0x24, 0x49, 0x6D, 0x92, 0xB6, 0xDB, 0xFF
Kék szintek: 0x00, 0x55, 0xAA, 0xFF
TV gyártótól függ feltünteti vagy sem, használd a tükör trükköt.-- gondolsz arra, hogy belebújok hátulról, aztán tükörben nézem, mi történik elõl? :D (Háát, fiatal vagyok én ehhez, de gyerekként még láttam TV szerelõt)
Én úgy látom, bár ezt több TV-n is ellenõrizni kellene, hogy a normál 11/51, illetve 10/52 margókkal kissé balra van eltolódva a kép.Az én TV-m szerint is! Nálam a két oszlopnyi hely a negyvenhez képest a jobb oldalt van, a normál EP kép éppen súrolja a bal kávát. Akkor gondolom ilyen 336x256 méret elférésére lehet számítani, de ekkor illik a felhasználónak lehetõséget adni a kép kalibrálására (Hová tegye a NICK?), meg a jó régi TV-k miatt a létfontosságú információkat nem a sarkokba rakni.
RF/kompozit/S-Video kimenetet használva valójában nem lineáris a kék szint, hanem a gép 3 bitesre konvertálja, és 0,2,5,7 lesz; ezért a 38h és C7h szín elvileg teljesen szürke, és nem "szines" árnyalatú, mint az emulátoron. Az RGB kimenet külön, (valószínûleg nem túl pontos) ellenállásokkal megvalósított D/A átalakítót használ.Ühüm, szóval akkor a kékre általában a 0x00, 0x49, 0xB6, 0xFF sor illene inkább, ha PC-n akarok hozzá rajzolni. Hát na, az is igaz, hogy a TV-n ennyi eltérés vagy látszik, vagy nem (Ugye felrajzoltam némi palettát, aztán meredtem a TV-re, de nem tûnt fel)... Rajzolásnál persze azért számít.
A program indítása egy kalibrációval egy fehér kerettel kurzorral majd enter-rel fixálni és utána indulna a program néhány 100 bájt az egész.Jaja, és utána, ha szûkös a RAM, el is dobhatod azt a néhány 100 bájtot :D Bár az egy kicsit trükkösebb, ha valami hires módot akarsz pontosan elhelyezni, hiszen 2 byte-os csoportokban fogja csak arrább tenni azt a NICK, tehát ez a kép kiosztásában is igényel némi meggondolást (Amit tervezek, abba viszont ez még éppen hogy belefér).
(Ha van tvtuneres PC a közelben, érdemes összevetni annak a képét a tévével, jól látszik, hogy mennyit levágnak a tévék.)
Itt pontosan mit is csinálnak,és miért is jobb így?
>BCD0 FD 10 3F 00 00 00 00 00 00 00 00 00 00 00 00 00
>BCE0 FC 10 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BCF0 FF 10 3F 20 00 00 00 00 00 00 00 00 00 00 00 00
>BD00 FC 12 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BD10 DE 13 3F 00 00 00 00 00 00 00 00 00 00 00 00 00Utána:>BCD0 FD 10 3F 00 00 00 00 00 00 00 00 00 00 00 00 00
>BCE0 FE 10 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BCF0 FC 10 3F 1C 00 00 00 00 00 00 00 00 00 00 00 00
>BD00 F0 12 06 3F 00 00 00 00 00 00 00 00 00 00 00 00
>BD10 EB 13 3F 00 00 00 00 00 00 00 00 00 00 00 00 00Tehát rövidebb lesz a VSYNC (a szabványos TV adásban 2.5 sor a hossza), utána van még 3.5 sor VBLANK (azaz összesen 9 sor blank/sync, az interlace módú TV adásban ez 2.5+2.5+2.5=7.5 sor, de interlace nélkül szabványosnak mondható a 3+3+3 sor, ezt használják pl. a Commodore gépek is), majd 4 helyett 16 fekete sor. Így 287 sor marad a hasznos kép információ számára, illetve valójában csak 286, mert az első keret sor még fekete marad a margó beállítások miatt. Ezeknek a változtatásoknak általában nincs észrevehető hasznos hatása, de lehet, hogy a régebbi TV-k egy részén az eredeti LPT nem eredményezett stabil képet. A BRD ROM automatikusan elvégzi ezt az LPT módosítást (ha jól emlékszem, megszakításban folyamatosan :)).A BRD ROM automatikusan elvégzi ezt az LPT módosítást (ha jól emlékszem, megszakításban folyamatosan :)).Igen, az szívatott a ZT óra fejlesztésekor :oops:
Az LPT VBLANK részét teszik "szabványosabbá", amint az a dokumentációban olvasható is. A módosítás előtt:
Lenne értelme, hogy az EXOS 2.32 eleve ilyen LPT-t csináljon?
Igazabol en azon gondolkodtam, hogy ossze lehet-e hozni olyan LPT-t, hogy ahol igazi interlaced van, azaz a ket felkep tartalma nem azonos. Azaz nincs vege az LPT-nek a vsync utan, hanem leir meg egy felkepet, us utana van vege. Ez azert erdekes szamomra, mert ugye igy a fuggoleges felbontas a duplajara no.Igen, ezt már gyárilag így tervezték, a különbözõ ismertetõkben így is adták meg a maximális felbontást.
Ha nincs is erre szukseg, pl erdekes lehet arra hasznalni, hogy pl valami "szinkeveres" technikaval egy pixel szine "atlagolodik" az egymas folott levo paros/paratlan felkepbol szarmazo info alapjan.Ilyesmin én is gondolkodtam, itt (http://ep128.hu/Ep_Demo/Leiras/Zozolace.html) egyszerûen a plusz paletta színekkel játszottam, a fekete közös, így összesen 7 szín van 4 színû felbontásban. Az általad leírt keveréses módszerre is gondoltam, gyakorlatban még nem lett megvalósítva.
(Laci! A Utilok közül hiányzik ez!)
Arra a programra gondolsz, ami a Német demokazettán (http://ep128.hu/Ep_Demo/Prg/Ep128_Demonstration_Kassette_DE.rar) volt? Rakjam be az Util programcsokorba is?Igen.
Hamár Interlace: a német újságban karattyolnak valamitA következõt karattyolják, hirtelen, egyszerû fordítással. A "löschen" szó törlést és berakást is jelent, nem tudom, ebben a szövegkörnyezetben mire vonatkozik, a hardveres dolgokhoz nem nagyon értek.
A következõt karattyolják, hirtelen, egyszerû fordítással. A "löschen" szó törlést és berakást is jelent, nem tudom, ebben a szövegkörnyezetben mire vonatkozik, a hardveres dolgokhoz nem nagyon értek.Köszi! Itt a törlés a megfelelõ.
- 640x480-as felbontás esetén elégséges 25Mhz pixel órajel, amely kb. 60hz-es függõleges szinkront ad.Ez egy olyan nagy hátrány, hogy így nem is érdemes belevágni, hiszen már egy EPDOS is használhatatlan lenne vele!
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)
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
- 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.
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.
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.
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.
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,
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.
Már egy 20-25 éves RGB CRT monitoron is be lehetett állítani úgy a képet, hogy minden beleférjen, anno az Iview fejlesztésekor nézegettem a Philipsemen, hogy a 46 karakter x 300 pixel (600 interlace) képbõl szemmel észrevehetõen nem hiányzott semmi. Ezzel a monitorral a TV adásból is többet kapok, lehet látni a teletext bitjeit is, pl az oldalszámláló tök jól látható :-) (ezeket az adatokat az átlag TV-n nem látható sorokban küldik).
Mivel a projekt felvetése onnan indul, hogy VGA monitorral kompatibilis EP legyen, így a legkisebb szóba jöhetõ felbontás a 800x600. Viszont már ez is igen idejétmúlt :-( a CRT monitorokkal együtt lényegében kihalt, a szintén már sok éve eltûnt hagyományos 4:3-as LCD monitorok natív felbontása 1280x1024 vagy 1024x768 volt.
Manapság az idióta szélesvásznú felbontások használatosak: 1280x720,1366x768,1920x1080
Nem értek a modern technikához, de én két IC-vel képzelném el a dolgot: egy ami a NICK dolgát végzi, pontosan úgy mint az eredeti (persze majd plusz tudás lehet), de az eredmény, ahogy az emulátorban is egy VGA puffer memóriába kerül, és van egy VGA megjelenítõ ami ezt a memóriát olvasva állítja elõ a VGA képet, és ezt lehetne programozni a különbözõ felbontásoknak megfelelõen.
Mivel kismillió olyan eszköz létezik, ami VGA monitorra tud képet kiadni, ezért az is lehetséges, hogy ez utóbbi feladatra lehet is kész IC-t kapni.
És ha menni fognak a szélesvásznú felbontások, akkor az új Nickben meg is lehetne oldani, hogy 64 (128 TEXT 80-ban) látható karakter legyen, ez az EXOS minimális módosításával kihasználható lenne.
En se mondom, hogy ismerem a LCD/TFT/stb monitorok lelki vilagat kulonosebben, de amennyire tudom: ezeknek van egy nativ felbontasa, amit hasznalni kell, mert ha nem az megy, az igen csunyan nez ki, par monitor meg idiota modon sikit is, es pl szeeeeeep feliratot biggyeszt a kepernyore h rossz a felbontas ...Igen, ezért írtam, hogy a számunkra ideális 800x600 sajnos kihalt :-(
Igen, ezért írtam, hogy a számunkra ideális 800x600 sajnos kihalt :-(
Azzal nem lennénk sokkal elõrébb, ha a 10 éves CRT TV helyett 10 éves CRT VGA monitort lehetne használni. Az emberek pont az ilyenektõl akarnak szabadulni, és a szép új lapos TV-t, monitort használni.
Az utolsó 3 slot DRAM frissítés. Ha itt nem keret van beállítva, akkor az utolsó video byte ismétlődik (erről valahol a fórumon van is egy régebbi, TV kártyával készült screenshot). Az utolsó slot talán már HBLANK, de ebben nem vagyok biztos. Az első 8 slot viszont (amikor az LPB olvasása történik) valóban HBLANK, és a HSYNC talán egy slottal ez után kezdődik, a kép vízszintes pozíciója alapján.Ahaa, koszi a korrekciot!
Jó lenne megvalósítani a 46-ot, mert pl. TV kártyával, vagy olyan monitorral, amelyen állítható a kép mérete, mind látható, és újabb, emulátorra írt programok is kihasználják.Na varj, en ugy tudtam a 625 az, es az overscan miatt szokas a 576-ot elfogadni. Vagy ezt rosszul tudom es/vagy a sorok egy resze az valojaban a vsync-re kell? Bar olyan remlik h az csak vmi 2 es fel sor vagy mi (marmint idoegysegben). Aztan lehet, rosszul remlik :)
Valóban 576 a "szabványos" felbontás, bár TV-ken az overscan miatt gyakran kevesebb. Mindenesetre az 576-ot érdemes támogatni.
Ahaa, koszi a korrekciot!
Na varj, en ugy tudtam a 625 az, es az overscan miatt szokas a 576-ot elfogadni. Vagy ezt rosszul tudom es/vagy a sorok egy resze az valojaban a vsync-re kell? Bar olyan remlik h az csak vmi 2 es fel sor vagy mi (marmint idoegysegben). Aztan lehet, rosszul remlik :)
Nem értek a modern technikához, de én két IC-vel képzelném el a dolgot: egy ami a NICK dolgát végzi, pontosan úgy mint az eredeti (persze majd plusz tudás lehet), de az eredmény, ahogy az emulátorban is egy VGA puffer memóriába kerül, és van egy VGA megjelenítõ ami ezt a memóriát olvasva állítja elõ a VGA képet, és ezt lehetne programozni a különbözõ felbontásoknak megfelelõen. Mivel kismillió olyan eszköz létezik, ami VGA monitorra tud képet kiadni, ezért az is lehetséges, hogy ez utóbbi feladatra lehet is kész IC-t kapni.Btw, es meg egy erdekesseg: ha van egy belso "frame buffer" amibe a "renderelunk" (es amibol a VGA jel hmm eloallito dolgozik) annak megvan meg az az elonye is, hogy bele lehet modositani a normal LPT-s feldolgozason es kepeloallitason kivul; pl "rarajzolni" ugymond meg mast, kvazi C64 sprite szeruen, vagy hasonlo feature-ok.
És ha menni fognak a szélesvásznú felbontások, akkor az új Nickben meg is lehetne oldani, hogy 64 (128 TEXT 80-ban) látható karakter legyen, ez az EXOS minimális módosításával kihasználható lenne.
Ami azon kívül van, az nem jelenik meg.Szerintem a saját TV-jükbõl indultak ki.
1. Mit szeretnél szemléltetni az ábrákkal?
2. A Gépi Kódú programozás c. könyv szerint bal:9 és jobb:53 lehet a maximum margótávolság. Ami azon kívül van, az nem jelenik meg. Te mégis nagyobb szélességet adtál meg. Ez hogy lehet?
Azt tudom, hogy az IS-BASIC editorja 24 soros+ 1 (statussor), ezen felül még 4-5 további sor jeleníthetõ meg az utolsó sor után.
A nagyobbal számolva 24+1+5=30 sor. Egy sor 9 pixel magas így 30*9=270 pixel a szélesség. Interlace módban kétszerese, így 540 képpont a magasság.
Én mint külsõ Nick készítõ, azt szeretném kérdezni, hogy van-e olyan szoftver EP-re, amely interlace módban 270 képpontnál többet jelenít meg függõlegesen.
Igen látom, az IView egy új szoftver.
Máshogy kérdezem: Az EP-s felhasználói programok 98%-a nem használ interlace technikát, ugye?
A maradék 2% (mint pl. az IView) pedig igen.
2. A Gépi Kódú programozás c. könyv szerint bal:9 és jobb:53 lehet a maximum margótávolság. Ami azon kívül van, az nem jelenik meg. Te mégis nagyobb szélességet adtál meg. Ez hogy lehet?
De jelzem, ez nagyon fontos 2%! :lol:
Szóval kalkulálnod kell a létezésével!
Arrol nem is beszelve, hogy sok ember "ramozdulna", ha lenne ilyesmi, azaz beindulnanak a "maxot kihozo" programok irasa EP-re talan, ha lenne modern megoldas amivel szepen meg is jelenitheto :)Ezt sajnos kizártnak tartom, pár emberen kívül nem nagyon írnak EP-ra programokat. Vagy lehet, hogy ez is változna?
Az a bajom az Interlace sorokkal, hogy nem egymás után következnek, tehát nem tudom egyszerû rutinnal soronként kiolvasni/betölteni.
Ha valaki nagyobb függõleges felbontást akar, jelzi a HW-nek (In/Out utasítással), és nem 27 soros lesz a sorparaméter táblája hanem 54. Esetleg nem 9 pont magas lesz egy sorparaméter-blokk, hanem 18.Akkor ezek szerint már nem teljesül ez a feltétel: kompatibilis a sorparaméter táblával
Ha valamit a Nick tud (meg ha azt ir irjak: nem fog megjelenni bla-bla) azt egy kompatibilis megoldasnak is tudnia kell, imho (azt hogy valami "nem jelenik meg abbol" az a tv korlataibol fakad es nem a nick-ebol, tehat nem nick oldalon kene "lefaragni").Egyetértek, úgy érdemes belevágni, ha mindent tudni fog amit az eredeti.
Ha valaki nagyobb függõleges felbontást akar, jelzi a HW-nek (In/Out utasítással), és nem 27 soros lesz a sorparaméter táblája hanem 54. Esetleg nem 9 pont magas lesz egy sorparaméter-blokk, hanem 18.
Látom Zozo nem vagy hajlandó túllépni azon a problémán, hogy "Szoftver ne vezéreljen függõleges szinkront". Én is szerettem a Nick-kel játszani, jó volt, szép volt, de most ideje tovább lépni.
Nem szabad majmolni a televíziós megjelenítést, volt belõle elég probléma a múltban, a számítástechnika túllépett a váltott soros megjeleníten, jelenleg a számítástechnikai eszközeink elég gyorsak ahhoz, hogy elvégezzék a megjelenítést vibrálás nélkül.
Nem butítom le a Nicket, még nagyobb felbontást kínálok mint az eredeti.
A függõleges szinkronnal csak a gond van. Minden szempontból.
- Különben is, mi a csudát csináljon egy SVGA monitor a televíziós szinkronjelekkel?
- Semmit! Az nem neki szól. Ezért nem veszem figyelembe.
Vagy a Z80 helyezi el grafikus módban?Igen, az két színû grafikus, pluszban játszva a spéci bitekkel, hogy ne csak két szín legyen.
A TEXT 80-as szövegmódot ugyanúgy generálja a NICK mint a TEXT 40-est? Tehát adatcím és hozzá a karakterlap? Vagy a Z80 helyezi el grafikus módban?
Akkor szerintem úgy fogom megcsinálni a külsõ Nick-et, hogy ezt õ fogja kiolvasni és megírni. Az a baj, hogy mivel nincs ilyen mód a paramétertáblában nem tudom mi módon fogja felismerni, hogy az szöveg vagy grafika.Szerintem nem kéne mindenféle kivételeket pakolni belepakolni, abból csak inkompatibilitás lesz. Olvasni kell az LPT-t és végrehajtani ami abban van, úgy ahogy az eredeti is teszi. Új ötleteknek ott van a nem használt üzemmód.
Az a baj, hogy a nem használt üzemmódból csak egy van.
Szerintem nem kéne mindenféle kivételeket pakolni belepakolni, abból csak inkompatibilitás lesz. Olvasni kell az LPT-t és végrehajtani ami abban van, úgy ahogy az eredeti is teszi. Új ötleteknek ott van a nem használt üzemmód.
A "nem használt" módban esetleg a paletta byte-ok felhasználhatók más célra ?
Igen szerintem is ennek 2x üzemmódnak lenne értelme. Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül. És hozzá még hw spriteok varázsolni... (sprite rendszerek terén körbe kéne nézni Z80-as konkurenciánál, mert ha sikerülne valamely létezõ masinát leutánozni, akkor onnan lehetne áthozni játékokat is. Pl ha jól tudom MSX környéken érdemes lenne nézelõdni.)
Hardveres sprite vezérlõvel lehetõség nyílik a grafikus felhasználói felületen a nyílmutató mozgatására különösebb processzorhasználat nélkül.
PC-n úgy oldja meg a Windows GUI, hogy: (mondok példát)
Van egy 600x500-as ablak, amiben ki van feszítve egy azonos méretû bitmap, és ez a háttér. Ebben szeretnénk elhelyezni egy piros teli kört, melynek átmérõje 50 képpont. Mivel a kör egy 50x50-es bitkép a körön kívûl esõ (de még az 50x50-es ablakban lévõ) pontok 0-ra vannak megválasztva.
Amikor ezt kirajzolom, akkor ezek a nullák is rákerülnek a képre, és nem kör jelenik meg, hanem fekete négyzet benne egy körrel. Bármilyen módot választottam a kirajzolásra (bitenkénti OR vagy AND vagy XOR), a négyzet akkor is kirajzolva maradt.
Ezután hosszasan keresgélve találtam egy olyan függvényt, amely a következõket engedte meg:
Ha készítek az 50x50-es bitképhez egy "maszkot", ami ugyanolyan méretû, és ahol azt akarom, hogy kirajzolásra kerüljön ott '1'-ek vannak ahol pedig nem ott nullák. Így akár "lyukas" ábrák is készíthetõk.
Ehhez már egyre bonyolultabb HW kell, vagy egyre erõsebb CPU.
Úgy veszem észre, fõleg nálad Zozo, hogy minden perifériális mûveletet hardveresen akarsz megoldani, hogy a Z80-nak a lehetõ legkevesebb mûveletet kelljen végrehajtania.
Igen szerintem is ennek 2x üzemmódnak lenne értelme. Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül. És hozzá még hw spriteok varázsolni... (sprite rendszerek terén körbe kéne nézni Z80-as konkurenciánál, mert ha sikerülne valamely létezõ masinát leutánozni, akkor onnan lehetne áthozni játékokat is. Pl ha jól tudom MSX környéken érdemes lenne nézelõdni.)
gyors horizontális scroll lehetõségét !
Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyõ mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függõleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi). De kihagyták, elfelejtették.
Ebbe akkor azt is bele lehetne rakni (mivel címbájtokból is több lesz), hogy pixelre lehessen megadni a sor kezdetét. Így lehetne szép vízszintes scroll, CPU terhelés nélkül.
... számomra megfoghatatlan, mire is lenne jó ezt a kedves kis Enterprise-t bővíteni ilyen grafikai és sprite dolgokkal:
1; Először is nem lenne senki, aki írna új játékokat, amelyek kihasználnák.
2; Ha lenne is, akkor se lesz mindenki gépe átalakítva ehhez az újdonsághoz.
3; A régi játékok "tuning"-olásának sincs értelme.
Ilyen ötletek mindig is voltak a régi gépekhez, pl. real-time óra bővítés, de az is minek, mikor egyetlen egy program se kérdezi le.
A témához kapcsolódóan idézet egy korábbi hozzászólásból (talán itt lesz a helye Zozo):
"Idézném a Speccyalista napon elhangzott beszélgetés részletét:
PGyuri: Mire tervezték az EP-t?
Moldani: A világ legjobb számítógépét akarták megcsinálni!"
Nos ez egyértelműen nem sikerült, mert ha azt szerették volna, akkor egyrészt a SPRITE fogalmát nem hagyták volna ki (mondjuk tervez(het)ték hozzá), de a leglényegesebb elemet akkor se felejthették volna el, mégpedig a gyors horizontális scroll lehetőségét !
Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyő mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függőleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi). De kihagyták, elfelejtették. Spectrumon sokat gondolkoztam, hogy ottani hardver mestereinket meggyőzöm egy interface készítésével, amely képes a scroll műveletét elvégezni a processzor helyett, de mindig arra jutottam, hogy úgyse lenne rá program, így felesleges még a gondolatával is foglalkozni.
Ilyen ötletek mindig is voltak a régi gépekhez, pl. real-time óra bõvítés, de az is minek, mikor egyetlen egy program se kérdezi le.Ez EP esetén rossz példa :-) Eleve az EXOS-nak rendes óra+naptára, ami 2079.12.31-ig mûködik, órakártyát több program is kezeli, pl a Zozotools másodpercenként szinkronizálja a szoftveres órát a hardvereshez. Egy rendes lemezes rendszer esetén ez hasznos dolog, hogy lehet tudni melyik fájl mikori.
Ez EP esetén rossz példa :-) Eleve az EXOS-nak rendes óra+naptára, ami 2079.12.31-ig mûködik, órakártyát több program is kezeli, pl a Zozotools másodpercenként szinkronizálja a szoftveres órát a hardvereshez. Egy rendes lemezes rendszer esetén ez hasznos dolog, hogy lehet tudni melyik fájl mikori.
Az lenne a kérdésem, hogy a sorparamétertáblában "64-es karakterkészlet" mód használata esetén a Nick mely karakterkódtól meddig jelenít meg a képernyõn információt?
Az IS-basic ezt használja egyébként?
Már a pénzbedobós játékgépek is bizonyították, hogy a játékok nagyrésze vízszintes, gyors képernyő mozgást kíván, amelyet a C64 elég jól meg is valósított, de a Spectrum, a többi 8 bites gép messze képtelen volt kezelni. A Nick csodálatos LPT képessége a függőleges scroll-hoz nyújtott támogatást, de pont az lett volna a kevésbé fontos, inkább egy cél-hardver-scroll balra-jobbra 1-2-4 pixelenként kellett volna, amellyel tényleg a legjobb gép lehetett volna a maga nemében (és nemcsak a játékhoz kell ilyesmi).
Pgyuri
Használja valamire az 50Hz-es videomegszakítást az IS-BASIC vagy EXOS?Pl abban történik a billentyûzet olvasás. Amúgy kb a programok 99% is ezt a megszakítást használja.
Tehát ha az LPT minden második sorában kiváltok egy videomegszakítást, akkor lesz minimum 600Hz-es a videomegszakítás. Nyilván az EXOS át fogja írni a módokat, de ha mondjuk visszaírom, akkor gyosabban fog villogni a kurzor?
Most tényleg, pontosan milyen feladatokat lát el az 50Hz-es megszakítás? Az 1Hz-es megszakítás ettõl független, mert kipróbáltam, és az óra ugyanúgy járt.
Most tényleg, pontosan milyen feladatokat lát el az 50Hz-es megszakítás?Abban frissitgeti az az LPT-t a videókezelõ, abban megy a billentyûzet lekérdezés.
Az IC egy SRAM IC és kifogástalanul mûködik a transzplantáció után is. Hozzáteszem nem ez az egyetlen munkám, csak most ez volt kéznél.Ezért most õszintén szívbõl irigyellek!
Nincs leragasztva. Nincs olyan HW gyártó aki leragasztana egy IC-t. Tudod milyen drága az ipari ragasztó? De azt sem kell gondolom ecsetelni, hogy a késõbbi szervizelést mennyire megnehezítette volna, ha az alátöltött (ez a hivatalos neve a ragasztásnak) alkatrészt cserélni kell.Szerintem te nagyon mostani technikákban gondolkodsz :oops:
Ezért most õszintén szívbõl irigyellek!
Akkor így 00111111 (bin) ami 3F (hex)Az teljesen világosszürke.
És mivel EP-nél a színek (g2)-(r2)-(b1)-(g1)-(r1)-(b0)-(g0)-(r0) (ahol a 0 a legnagyobb színerősség)Helyesen:
Látom Zozo ma angolos kedvedben vagyNem, csak az angol EXOS leírás szokott használható lenni, mivel a magyar tele van nyomdahibákkal és félrefordításokkal :-(
Nekem úgy tűnik, hogy most az angol EXOS leírás a hibásKiderült nem a leírás a hibás, hanem az angolok által az ősidőkben elkészített html verzióban lett hibás a képlet, valószínűleg úgy gondolta hibás a leírt képlet, mert nem a 0-ás bit szokott nagyobb értékű lenni.
ld hl,4000h
f31 ld (hl),a
jr f31
Szép. :) Legalább a kiforrasztással nem kell duplán nyűglődni, ha ezzel javítasz egy lapot.Pontosan :-)
Pl talan a scroll demo volt ilyen amit epp neztem, a debug ablak azzal van teli, hogy: "Reading undecoded port 0x82". Ez mondjuk erdekes, elvileg - tudtommal - nick registerek nem visszaolvashatoak, tehat a scroll demo nem tudom miert akarja azt a portot olvasni, van otletetek, hogy ezzel mit akar elerni?Na ez egy jó kérdés, eddig én is úgy tudtam felesleges olvasgatni a Nick portjait :oops:
uint8_t Nick::readPort(uint16_t portNum)
{
(void) portNum;
return dataBusState;
} 1189 DB 82 IN A, (82)
*118B E6 07 AND 07
118D 3C INC A
118E 47 LD B, A
118F 10 FE DJNZ 118F
Időzítési célra ennek úgy lehjet értelme, hogy például egy nem látható (a kerettel azonos színű, de nem keret) sorban a video adat egy számsor, amit az aktuális vízszintes pozíció olvasására lehet használni.hm hm... ez érdekes...
Soron belül változó keretszín vagy BIAS pontos időzítéséhez például hasznos lehet.Egyik demómban csináltam ilyet, de persze nem ezzel az időzítéssel, mert nem is tudtam róla akkor. :)
A NICK portjainak (80h-8Fh) az olvasása azt a byte-ot adja vissza, ami az adatbuszon maradt, azaz amit a NICK utoljára olvasott a memóriából (ezt az ep128emu nem emulálja) vagy a NICK I/O portokra utoljára írt értéket.
Időzítési célra ennek úgy lehjet értelme, hogy például egy nem látható (a kerettel azonos színű, de nem keret) sorban a video adat egy számsor, amit az aktuális vízszintes pozíció olvasására lehet használni.
ha jól látom kb 3 karakterenkét lehet váltani, de a scroll kb karakteres?Igen. 3 karakter (~13.49 Z80 ciklus) a legrövidebb lehetséges időtartam két NICK I/O port írás között. Ez is csak "OUT (C), regiszter" utasításokkal lehetséges OUTI helyett, ezért a scroll csak 6 színű, és a "pixeleket" a kód felülírásával lehet módosítani. Az OUTI egyszerűbb lenne, de csak 4 karakteres felbontást tenne lehetővé.
024Ch címre a debuggerben OUT (C), B helyett OUT (C), A-t írva a bal felső sarokban megjeleníthető a kiolvasott vízszintes pozíció változása.Illetve ez nem egészen jó, mert már tartalmazza a vízszintes scrollt is. A scroll azonban megállítható 052Ch címre INC L helyett NOP utasítást írva.
FIXBIAS scroll lebegő adatbusz olvasással időzítve::smt038 :smt038 :smt038
Csak 4 MHz-es valódi gépen működik.Gyorsabb géphez is lehetne időzíteni?
Nem tudom, valódi gépeken az alkatrészek véletlenszerű szóródása miatt előfordulhat-e probléma.A rendszer órajel 3 tizedesig pontos kristállyal van generálva, itt nem is találtam nagy szórást szkóppal, ellentétben a Nick órajellel, aminek a generáló áramköre állítható alkatrészt is tartalmaz, itt van bőven eltérés. (Ezeket igyekszem is az általad kiszámolt elméleti órajelre belőni.) A Nick órajel eltérés befolyásolhatja a programot?
:smt038 :smt038 :smt038Igen, de ahhoz természetesen módosítani kell a kódon (nem hordozható a különböző sebességű gépek között, esetleg a "szabványos" frekvenciákhoz külön meg lehetne írni, és futáskor automatikusan kiválasztani a megfelelő verziót). Viszont 7.12 MHz-es gépen lehetne 2 karakteres felbontás is 3 helyett.
Gyorsabb géphez is lehetne időzíteni?
A rendszer órajel 3 tizedesig pontos kristállyal van generálva, itt nem is találtam nagy szórást szkóppal, ellentétben a Nick órajellel, aminek a generáló áramköre állítható alkatrészt is tartalmaz, itt van bőven eltérés. (Ezeket igyekszem is az általad kiszámolt elméleti órajelre belőni.) A Nick órajel eltérés befolyásolhatja a programot?A NICK és Z80 órajel aránya a lényeges, tehát bármelyiknek a jelentős pontatlansága probléma lehet. Azonban a NICK órajelének elvileg a PAL színsegédvivő kristály az alapja, aminek a szabvány szerint meglehetősen pontosnak kell lennie (talán +/- 50 ppm, de ebben nem vagyok biztos). Az állítható áramkör egy PLL, de ha annyira pontatlan, hogy nem is tud beállni a kristály által meghatározott frekvenciára, akkor lehet hibás a NICK frekvencia (ez képhibát is eredményezhet).
és ha még a 8 palettás színnel lenne "fölé" rajzolva, még lehetne fokozni a hatást :)Az OUT (C), C és az OUT (C), 0 utasításokat nem használja, ezért csak 6 színű a scroll. Az OUT (C), 0 használható lenne a fekete (azaz itt teljesen átlátszó) színhez, de nem működik minden Z80 verzión (ha jól emlékszem, ugyanez az utasítás geco átiratainál is okozott problémákat). Az OUT (C), C is használható lenne fekete színhez, mert a C értéke 80h; ez azonban kikapcsolja a beépített hangszórót, ezért a többi színnél is be kell állítani a 7. bitet (a hangszóró kapcsolgatása zajt eredményez, még akkor is ha egyébként nem lenne hang). A C regiszter valójában lehetne 84h, 88h, vagy 8Ch is, ami további színeket tenne lehetővé.
de nem működik minden Z80 verzión (ha jól emlékszem, ugyanez az utasítás geco átiratainál is okozott problémákat).CMOS procin FFh-t küld ki. (ezt használja az EXOS 2.4 is a proci típus detektálásra.)
Az OUT (C), C és az OUT (C), 0 utasításokat nem használja, ezért csak 6 színű a scroll. Az OUT (C), 0 használható lenne a fekete (azaz itt teljesen átlátszó) színhez, de nem működik minden Z80 verzión (ha jól emlékszem, ugyanez az utasítás geco átiratainál is okozott problémákat). Az OUT (C), C is használható lenne fekete színhez, mert a C értéke 80h; ez azonban kikapcsolja a beépített hangszórót, ezért a többi színnél is be kell állítani a 7. bitet (a hangszóró kapcsolgatása zajt eredményez, még akkor is ha egyébként nem lenne hang). A C regiszter valójában lehetne 84h, 88h, vagy 8Ch is, ami további színeket tenne lehetővé.nem így értem, hanem úgy hogy olyan graf lenne alatta, ami palettaszíneket is tartalmaz, így azokon a bias trükk nem lenne rajta, azaz "felette" lennének, eltakarnák a scrollt (részben, pl fa ágak stb). látványos lenne, főleg ha az is animálna mondjuk (rasztercsíkok, hullámzás, akármi)
Ilyesmin már én is gondolkoztam :-)
Aaaa, pedig mar ugy orultem, hogy milyen okos vagyok (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)Hát lehetsz is, nekem az elmélet első bekezdése után már némi füst kezdett el szállingózni a füleimből... :mrgreen: megyek IC-ket cserélni...
Hát lehetsz is, nekem az elmélet első bekezdése után már némi füst kezdett el szállingózni a füleimből...Pedig egyszerű!
Én ezt nem teljesen értem. Hol jelenne meg ez a több szín?
Hááát, lehetek hervasztó...? :twisted:
em egészen ugyanaz, de egyfajta gyorsítás lenne az is.)
Az a helyzet, hogy vizuális szempontból a 8 fixbias szín nem igazán nagy korlátozás. Jól kitalálták azt. :)
Eddig mindenkinek a sirankozasat lehetett olvasni a forumon, hogy fixbias jajj, most meg hirtelen semmi ertelme, meg jo a fixbias, tok jol kitalaltak :) Furak vagytok azert, nektek sem lehet kedvezni temaval ...Én mindig utáltam a fixbiast!
Eddig mindenkinek a sirankozasat lehetett olvasni a forumon, hogy fixbias jajj, most meg hirtelen semmi ertelme, meg jo a fixbias, tok jol kitalaltak :) Furak vagytok azert, nektek sem lehet kedvezni temaval ...én sose fikáztam. és asszem egyedül én vagyok grafikus itt :)
Latom, neked sebesseg maniad van,< poén> Hja, a Speed mellékhatása... :smt042 </poén>
Eddig mindenkinek a sirankozasat lehetett olvasni a forumon, hogy fixbias jajj, most meg hirtelen semmi ertelme, meg jo a fixbias, tok jol kitalaltak (http://enterpriseforever.com/Smileys/phpbb/smiley.gif) Furak vagytok azert, nektek sem lehet kedvezni temaval ...
Erény már majdnem a lassúság...?
Akkor az EP-t csak video-rammal kellett volna kiadni, a'la Amiga... de annyi eszük azért volt, hogy nem csak olyan lett gyártva, sőt a 128-as terjedt el jobban. Így legalább elmondhatjuk, hogy az EP-nek alapból volt már úgymond FastRam-ja :)
Ehhez képest a Commodore erre sose jött rá...?
Meg akkor minek turbósít itt bárki is Z80-at? :twisted: Minek a nagyobb sebesség, jól elvan mindenki a 4MHz-el...
Amúgy a fixbias... először kissé furcsállottam kissé, nem mondom.
Ott van pl. a Sam Coupe, van neki egy 320*200 16 színű módja, egyenként választható színekkel, hagyományos megoldás, ugye. Igaz, a gép későbbi. Ha azt vesszük, hogy az EP-t mikor kezdték el tervezni, akkor ez a fixbias-os dolog talán nem is annyira kiakasztó, bár erre meg azt mondhatnák, hogy volt akkoriban már ST meg Amiga is, azokhoz képest az EP már lemaradóban volt... ki tud itt igazságot tenni... :oops:
Persze nem akarok semmi jó elrontója lenni, ha ez megoldja a fixbias problémát, akkor végtére is lehet értelme...
Nagyon faj neked ez az Amiga (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)Bocsi, de mintha te is emlegettél volna valami olyat, hogy inkább az Amiga mint a PC lett volna elterjedve... :oops:
IdézetNem hinném hogy pl. azok az orosz fickók is ezt gondolták, akik mindenféle "turbózott" spectrum-klónokat kezdtek csinálni... :twisted: Ott is "húztak" a CPU-poweren, mégsem az volt a céljuk, hogy 4GHz-es 16 magos Z800000000-t csináljanak... nyilván az adott architektúra keretein belül maradtak valahol. Ugyanez vonatkozik a grafikára is. Nyilván nem akarunk 2048*1920-at 16millió colorral, meg effélék, de azért egy "alap" VGA-szerű dolog már hadd ne legyen felfuvalkodott vágyálom, retro ide vagy oda... Ezen az alapon fenéken lehetne rúgni a C64DTV készítőit is, mert ott már elérték ezt a 256-szín dolgot, de hát minek is... mert az alap C64-et véve ez már "őrültségnek" is hathat, ugye... :twisted:QuoteErény már majdnem a lassúság...?Az lehet. Errol szol a "retro computing", ha sebesseget akarsz, modern PC-t kell venni, vagy hasonlo (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)
Bocsi, de mintha te is emlegettél volna valami olyat, hogy inkább az Amiga mint a PC lett volna elterjedve... :oops:
vágyálom, retro ide vagy oda... Ezen az alapon fenéken lehetne rúgni a C64DTV készítőit is, mert ott már elérték ezt a 256-szín dolgot, de hát minek is... mert az alap C64-et véve ez már "őrültségnek" is hathat, ugye... :twisted:
És hát ezen az alapon el lehet felejteni minden további ábrándozásokat az EP 2-ről is... (Zozo nagyon nem örülne... :ds_icon_cheesygrin::twisted: )
Érdekes, normális LPT-je van a DK-nak, úgy emléxem semmi extra nincs benne, viszont a hullám effekted elég érdekes.
Már többször csodálkoztam, hogy a NICK -eken miért nincs olyan szép felfestés, mint a DAVE -eken ...Ezen azért van (http://ep128.hu/Album/Pic/NICK.jpg), mert gyárilag felejtettek el rá hűtést rakni :-)
Aztán most láttam a NICK hűtést ... hát ezért:
Az IS/Enterprise 1983-ban lépet kapcsolatba az AMI-val. Az AMI képviselője mesélte, hogy ezek az emberek bejöttek az irodába, két kézzel drótozott prototípusának "valaminek", és azt mondták ezeknek az egyedi IC-jét szeretnék.
Nem volt semmilyen konkrét terv vagy rajz ezekhez a chipekhez, vagy a végleges prototípusnak. Nyilvánvalóan az IS emberei még soha nem csináltak hasonlót. Nem tudták, hogy nem lehetséges normál alkatrészekből és IC-kből összerakott áramkört 1:1-ben sziliciumra átrakni. Az AMI embereinek kellet modellezni a prototípus normál alkatrészeit nagyszámú alacsony szintű logikai kapu felhasználásával. Ebben az időben még nem voltak olyan konfigurálható áramkörök mint manapság (FPGY, CPLD,...)
A legelső verziója a Dave-nek (amit ESPRIT-nek neveztek ebben az időben, és az AMI a gyártás során végig megtartotta ezt a nevet) 1983 augusztus/szeptember környékén lett kész. Az első (és hibás) Nick (amit ELITE-nek neveztek) 1983 novemberére. Amikor ez első prototípusok megérkeztek Londonba, kiderült, hogy nagyon nem úgy működnek ahogy várták. 1984 novemberéig a Dave 4 revizión ment keresztül, a Nick pedig 5-en, amíg elértek a végleges változatot.
A Nick terveknél nem tudni mikor váltottak version 1-ről (08-04) version 2-re (08-47), de az E revizó az biztosan a 08-47. A rajzokon sajnos nem látszik változtatás nyoma, valószínűleg apró de fontos változások voltak.
Werner Lindnernek köszönhetően:
Nick chip tervrajz 1. oldal
Nick chip tervrajz 2. oldal
Nick chip technikai ismertető
Nick chip belső időzítések
Innen már a CPLD mágusoké a terep :-)
Egy kis érdékesség: a leírásban szó van az NTSC müködésről is!
Ezt most nem vettem le ? Miért érdekes az NTSC mint olyan ? USA miatt, vagy mi ? Hova hiányzott eddig ? Vagy abszolút technikailag érdekesség csak ?érdekesség. Eddig is tudtuk, hogy voltak a CES-en Las Vegasban, tehát gondoltak az amerikai piac meghódítására is.
Igen, elvileg ez az utolsó (08-47) verzió rajza.
Innen már a CPLD mágusoké a terep :-)
Többször hivatkozik az írás a DPC11.doc-ra. Ezt nem lehetne megszerezni?Ott van az is, az a technikai ismertető.
Érdekelne egy pár olyan kód amivel meg lehet hülyíteni a NICk-et.
Gondolok itt olyan kódokra, amelyek a képernyő futását, torzulását, hibaszerű reagálását váltják ki.
Természetesen olyan módon, hogy van visszatérésre, helyreállításra lehetőség.
Érdekelne egy pár olyan kód amivel meg lehet hülyíteni a NICk-et.Endinek volt egy POKE-ja, amivel függőlegesen elmozdul a kép. Kisebb elmozdulásokból képernyőrázást is lehetett.
Endinek volt egy POKE-ja, amivel függőlegesen elmozdul a kép. Kisebb elmozdulásokból képernyőrázást is lehetett.
Szerintem nem ilyesmire gondol sanyike, hanem olyasmire ami komolyan összekeveri a NICK működését. Pfúj, Commodore-os példák: amikor C64-en lebontják az oldalsó keretet, vagy annak ellenére hogy nincs olyan kényelmes technológiájuk mint az LPT, a maximum 7 képpontos finom görgetésnél nagyobb mértékben mozdítják el a képernyőt, vagy valami más, a megjelenítő lelkivilágát jelentősen megzavaró húzás, ami mégis értelmezhető képet ad, mint például plus/4-en csinálta meg valaki (ha jól tudom), hogy megnövelte az egyébként fix vízszintes felbontást a kép egy részén.
Lehet próbálkozni az LPT erőszakos újratöltésével a rasztersor közepén (persze halálpontos időzítéssel)
nem is tudom hova tegyem ezt...
mobilon nagy divat a retró, a pixeles graf. de persze kocka alakú pixelekkel, nem laposakkal :)
na gondoltam kipróbálom hogy nézne ki pár ep játék kocka pixelekkel, íme
persze letöltve, belezoomolva az igaz
nem egy nagy szám az eredmény, úgy értem azt hittem érdekes lesz, (mert szebb biztos nem) de nem :)
amúgy persze ha eleve kocka pixelekkel készül egy játék, akkor az azért szebb, és mobilon elég sok szép példa van erre, akár jóval nagyobb pixelekkel is
egy nagyon vicces dolgot vettem észre!
EP-n nincsenek szürke színek :D
hát ez poén :)
egyszerűen nem lehet olyan színeket találni amik szürkék. kicsit sárgás, kicsit kékes mind :D
Ez talan azert is van (?) mivel az RGB komponensek nem egyenlo szamu bittel vannak abrazolva, a kek csak 2 bit, a piros/zold meg 3 bit. Mashol olyan megoldas is volt, hogy mivel 8 bit van, 2-2-2 bit legyen a maradek bit meg intenzitas.
na igen, de nem lehetett volna besúlyozni úgy hogy épp kijöjjön pár jó szürke?
Ez a használt kimenettől is függ, RF/kompozit/S-video esetén például 3 bites a D/A konverzió kék színnél is, 0,2,5,7 értékekkel. Emulátoron hasonló színeket lehet beállítani a kék kontrasztot 1.286-ra növelve, ez szoftveres módban működik a legpontosabban.
Pont hogy a meglévő Ep-ről beszél IstvanV. Ott van a kapcsolási rajzon is, a harmadik lapon, a C4 szegmensben. U34 17-es, 18-as és 19-es lábak. Ott megyen be az RGB-YCbCr átalakítóba.
tehát átkötjük minden EP-ben? :)
Ez a használt kimenettől is függ, RF/kompozit/S-video esetén például 3 bites a D/A konverzió kék színnél is, 0,2,5,7 értékekkel. Emulátoron hasonló színeket lehet beállítani a kék kontrasztot 1.286-ra növelve, ez szoftveres módban működik a legpontosabban.
| Kék komponens érték (0..3) | Kék 3 bit ekvivalens érték (0..7) |
| 0 | 0 |
| 1 | 2 |
| 2 | 5 |
| 3 | 7 |
Ez a használt kimenettől is függ, RF/kompozit/S-video esetén például 3 bites a D/A konverzió kék színnél is, 0,2,5,7 értékekkel. Emulátoron hasonló színeket lehet beállítani a kék kontrasztot 1.286-ra növelve, ez szoftveres módban működik a legpontosabban.
attól hogy 3 bites a konverzió, a forrás még 2 bites...
emulátorban néztem ezeket a szín tekerőket, de a kéket feljebb tekerve a fekete is kék lett... ez így nem súlyozás...
a fő kérdésem viszont hogy ezek szerint az emu nem azt a képet adja mint az igazi EP??
illetve azt se értem miért függhet a kimenetektől a kék súlyozása...
amúgy mi akadálya lett volna hardveresen pl olyan karakteres módot csinálni hogy a karakter sorszámától függ a szín 1:1-ben?
Szerintem a karakteres mod eredeti celja nem ez, hanem szoveg megjelenitese :) Amirol itt szo van, az mar a karakteres mod kreativ felhasznalasa :)
gameboyNa, azért ne egy játékgéphez hasonlítsuk az EP-t! A C64 még oké.
Na, azért ne egy játékgéphez hasonlítsuk az EP-t! A C64 még oké.
az alap gameboy nem sokkal erősebb hw mint a c64, sőt, talán még gyengébb isDe akkor is, azt játékhoz tervezték, az EP-t meg nem kifejezetten.
De akkor is, azt játékhoz tervezték, az EP-t meg nem kifejezetten.
bár mondjuk a c64-et pont játékra tervezték :)Na igen, és itt felmerül a kérdés, hogy az EP-t mire tervezték. :D Azt hiszem, azt nem sikerült még megfejteni.
Na igen, és itt felmerül a kérdés, hogy az EP-t mire tervezték. :D Azt hiszem, azt nem sikerült még megfejteni.
Korabeliek között nem hinném. Modernek, mint például a V6Z80P+ tudhatják. Kérdés, ezt mennyire érdemes 8bitesnek tekinteni, amikor kb. egy proci, némi RAM meg egy FPGA az egész?
emlékszem az amiga graf processzorát dícsérték, hogy egy 40MHz-s pc-nek felel meg a sebessége, ami abban az időben nagy szó voltAz Amiga esetében ez két dologra vonatkozhatott. Vagy a Blitter kitöltési sebességére, vagy a Copper regiszter írási késleltetésére és sebességére. Mondjuk én inkább az előzőre tippelnék. (Szerinted van bármi ezekkel összemérhető a NICK-ben?)
a z80/nick viszonylatban hogy lehet ez? a bias és border soronkénti megváltoztatásáról jutott eszembe :)
olyasmire gondolok hogy ha a z80 renderelne (állítaná elő a képet), milyen gyorsnak kéne lennie hogy a nick képességét hozza?
persze tudom, ezt így nem lehet teljesen összevetni, de azért érdekes gondolat.
pl a bias vagy border karakterenként megváltoztatható egy sorban, persze biztos a hw korlátozza, kérdés, ha nem korlátozná akkor a z80 milyen sűrűn tudná ezt megtenni?
á hülyeség :)
na pont erre voltam kíváncsiIgazából nem hozta ki a maxot. Az akkor lenne meg, ha megírta volna az összes megjelenítési módra a Z80 kódot, ami értelmezi az LPB-t, és ez alapján generálna egy(-két?) portra kiírt bájt sorozato(ka)t, amit be lehetne adagolni a NICK után lévő elektronikának, és abból előállhatna elvileg a NICK által létrehozottal egyenértékű kép. Ekkor már csak vissza kellene számolni a T-ciklusok alapján a szükséges órajelet, és készen is lenne. Te endi, nem akarnád megcsinálni? :D
szerintem ki hoztad a maxot a témából :)
de most hirtelen még őrültebb ötlet jutott eszembe: a rem1 és rem2. az vajon milyen kép előállítására lenne alkalmas? :D
Viszont lehetne zenéknél plusz két béna hangcsatornaként használni őket. A relék csattogása, mint ritmushangszer. :ds_icon_cheesygrin:
mibe került volna azt megcsinálni hogy a nick egy D/A-ra kiadja mondjuk minden lpt sor első byte-ját?
De ha már NICK: én meg arra lennék kíváncsi, hogy a FIXBIAS 7-es bitje, amivel most a belső hangszórót lehet kapcsolni, azt eredetileg vajon milyen célra szánták? Logikailag abszolút nem illik hozzá a jelenlegi funkció.A külső színbement kikapcsolására. Még a 84-es leírásokban is így van.
ja igen, úgy gondoltam hogy lenne egy byte az lpt-ben ami a digi hang lenne :)Csak bazi hosszú LPT kéne, hogy értelme legyen :-D
15khz az simán jó lehetett volna sokmindenre
A külső színbement kikapcsolására. Még a 84-es leírásokban is így van.
ja igen, úgy gondoltam hogy lenne egy byte az lpt-ben ami a digi hang lenne :)
15khz az simán jó lehetett volna sokmindenre
Csak bazi hosszú LPT kéne, hogy értelme legyen :-D
Csak bazi hosszú LPT kéne, hogy értelme legyen :-D
Hogy igy mennyi sampling rate jonne ki, annak nem szamoltam mondjuk utana :)
igazából engem olyan szempontból érdekelnek ezek a kérdések, hogy annak idején lett volna-e lehetőség ilyesmit csinálni az EP készítőinek, mennyi plusz költség lett volna stb...
Nem is tudom, volt-e olyan (biztos van amugy) 8 bites gep, ahol ilyen "DMA szeruen" tud hangot lejatszani vmi,Én kizárt dolognak tartom, nagyon meglepődnék, ha lenne ilyen.
A sprite kerdes erdekesebb, nekem az a gyanum, hogy gondoltak ok arra is, elvegre az EXTCOL bemenetek is talan pont vmi hasonlo kiegeszito miatt kerulhettek anno szoba.EXOS 2.1-be már be is került a SPRITE változó.
Én kizárt dolognak tartom, nagyon meglepődnék, ha lenne ilyen.CPC +-on van már DMA, de az ugye 90-es évek környékén jött ki, ha jól emlékszem, akkor 1989.
én nem vagyok hardveres, nem értem konkrétan mi az a dma, de a nick képgenerálása az miért nem dma?
CPC +-on van már DMA, de az ugye 90-es évek környékén jött ki, ha jól emlékszem, akkor 1989.De ott meg digi hang nincs ha jól tudom.
Viszont az regen nem volt olyan szokasos, hogy mas is a CPU segitsege nelkul menjen, pl digi hang, meg mas ...Ha jól tippelem ez elsőként az Amiga vivmánya? Később meg PC-n Sound Blaster.
DMA-ról (legjobb tudomásom szerint) akkor beszélünk, ha az operatív tár a forrás vagy cél memória, és a művelet célja adatátvitel. A videójel generálásnak nem célja az adatátvitel, mivel nem kerül át más helyre az olvasott adat másolata, illetve dedikált videómemóriában történik.
Viszont az LPT-s "DMA" hangkeltés megszerintem szinte teljesen hasznavehetetlen lenne, ugyanis a programozási modellje egy katasztrófa. Szerinted jó ötlet, hogy a memóriába szanaszét szórva hevernek a hangminta adatai, ráadásul az LPT előnye, hogy egy LPB-vel több videósort is le lehet írni pont ellentétes a hanglejátszáshoz szükséges egyenletes adatáramlással?
nekem nem kellett volna hogy tökéletes legyen a megoldás, ha lpt-ben van a sample, nekem az is jó lett volna, és hogy ehhez soronkénti lpt kellett volna
játékokban, demókban oké lett volna így is
de azt nem értem miért kéne nagyon nagy lpt neki? hány sor lehet max az lpt, 300?
De az csak 1/50 másodperc hang lenne. :)
Ezért célszerűbb a külön (pl. I/O porton keresztül állítható) olvasási cím használata amikor a soron belül van rá idő, például statikus video RAM esetén az utolsó 3 karakter felszabadulna 6 byte olvasására.
Igy igen erdekes, hogy ket a szam-"csoport" pont meg van cserelve Xep128 es ep128emu kozott, azaz lehet hibasan hasznalom a level szintet a VINT-nel :-P Legalabb meg valami kiderult, hmmm. Alakul ...
Itt lehet hiba a nick.c-ben (570. sor):Code: CAz INT1 bemenet nem invertált, azaz a megszakítás valójában a VINT-es LPB után történik.
Eleve vannak ott komolyabb gondok is, a vsync, interlace miegymas.
En amit osszeemulalgatok _jelenleg_ az viszont nem ebben a filozofiaban irodott, ez igen, hiba is, de ugye az elejen volt, hogy XYZ programnak kellett egy adott videomod, gyorsan beleiram, aztan kiderult kell masik is, stb, igy aztan kialakult, hogy nem globalisan vannak kezelve, ami persze hiba.
Az interlace az nekem mindig kerdes :) Tudom, errol mar volt szo, de tovabbra sem ertem, hogy oszinte legyek :-/ Eleve ez a fel sor hogy jon ki? A PAL signal eseten vmi 312 es fel sor (?) vagy hasonlo felkepenkent, es minden paros v paratlan sor adott half frame-re nezve, tehat 1 sor, miert "fel" akkor? Masik, amirol szerintem mar volt szo, de akkor sem ertettem :)
Nade emulatorban ugye ez latszana azert eleg jol. Mert akkor atlag egy VSYNC blokkos LPT-vel ugy nezne ki, hogy egy sor megjelenites, egy sor ures, egy sor megjelenites egy sor ures stb
Ha jol tippelek, a busz boviton eleg lenne az EXTC-t fixen (?) a foldre kotni (mivel elvileg alacsony aktiv), a biztonsag kedveert pl ellenallason at. Ezek utan a 4 EC szin info-t hol a +5V-ra, haol a GND-re kotogetni mas-mas sorrendben, ezzel kulonbozo szineket "betaplalva"Arra gondoltam, hogy rá kéne rakni egy számlálót a video clockra, és annak a kimenetét bevinni EC-nek.
Arra gondoltam, hogy rá kéne rakni egy számlálót a video clockra, és annak a kimenetét bevinni EC-nek.
Én úgy oldottam meg, hogy a "szabványos" módokhoz külön (optimalizált) renderert írtam, és ezeken kívül van egy általános megvalósítás (NickRenderer_Generic) ami mind az 512 lehetséges szín/mód kombinációt tudja, de lassabb, és ez kezeli a nem dokumentált módokat:
Code: C++
Ezt kulon venni elvileg tenyleg gyorsabb, mar nem tudom mennyi kulonbseget jelent ...
Ezek miert vannak meg "kulon", amikor talan ez se "standard", es inkabb a generic lenne?
Meg egy kerdes, ami nem is kifejezetten emulator fuggo, bar szerintem errol is lehetett szo mar. Eleg csak egy uj LPB elso scanline-janal felolvasni a dolgokat es eltarolni belso valtozokba? Vagy ugyanazon LPB (ha tobb scanline-ra vonatkozik, nyilvan!) eseten is az elso 8 slot-ban mindig ujraolvassa amugy is az LPB-t? Es ha ujraolvassa, mi van ha megvaltozott par parameter a memoriaban kozben?
Az alábbi program teszteli a VINT, LM, RM, és paletta módosítását LPB-n belül:
(Attachment Link)
ep128emu-n így néz ki:
(Attachment Link)
Ez GNU/GPL? Lenyulhatom a tesztjeim koze? Max kene ele vmi copyright/licenc megjegyzes azert.
De ha tok ugyanaz, es nem tolja el egy fel (vagy egy???) sorral, akkor ugye "fesus" lesz a kep, hiszen valahova soha nem jut informacio, ami csak akkor jutna, ha nem interlaced eseten is lenne ket kulon vsync blokk ahhoz hogy mindket "half frame-re" jusson ugyanaz az info.
75Hz-es monitor mennyire jó?
azt lenne még érdemes megnézni, hogy valódi gépen is ilyen-e.[attach=1]
(Attachment Link)
mert ez nem valódi gép? ilyen tévére kötöd az emut? :)???
miért nem használták ki a dave-ben jobban a karakteres módokoat?Biztos gondolták, a gyűrűmodulációk mellett nem kell még az is. :D
mindig a központi procikat szoktuk összehasonlítani teljesítmény szempontból... de pl egy c64 videóchipje hogy aránylik teljesítményben a nickhez?
úgy értem van ügye az nick, ami 1 rasztersor alatt x byte adatot dolgoz fel, persze tudom, ennyi nem elég a teljesítménye meghatározásához, az is számít mit csinál ezekkel az adatokkal közben... de valamennyire össze lehetne pl a c64-el hasonlítani
megint azért jutott ez eszembe, mert elgondolkodtam, hogy miért nem használták ki a dave-ben jobban a karakteres módokoat? pedig pl a c64-ben ezek tök jók... nekünk meg van egy hires 16 felbontású 2*4 színű karakteres módunk ami egyedül használható valami értelmesre, úgy értem grafikai/játék szempontból...
Istvan, abban viszont nem vagyok biztos, hogy csak a keret alatt tud Sprite adatokat olvasni a VIC-II, bar megcafolni sem tudom, konnyen lehet, hogy en tevedek.
Úgy értettem, a soron belül olvassa a keret alatt a sprite adatokat. Egy sor 63 karakter PAL gépen, ebből 40 a képernyő, 5 DRAM frissítés, és marad 18 egyéb célra, a sprite olvasás (legfeljebb 8*4=32 byte) 16 karaktert igényel. Itt (http://www.cebix.net/VIC-Article.txt) a 3.6.3-nál lehet részletesebben olvasni az időzítésről.
FIXBIAS scroll lebegő adatbusz olvasással időzítve:
fbscroll.com (https://enterpriseforever.com/hardver/nick/?action=dlattach;attach=9567)
Csak 4 MHz-es valódi gépen működik. ep128emu-n ez a script javítja az időzítési hibát (így sem egészen pontos, mert igazi gépen nem karakterhatáron változik a szín, hanem egy 16 színű pixellel korábban):
nickread.lua (https://enterpriseforever.com/hardver/nick/?action=dlattach;attach=9568)
Egy másik lebegő adatbusszal kapcsolatos újdonság: ha a jobb margó nagyobb mint 54, akkor az ott található karakter a valódi géphez hasonlóan az utolsó olvasott byte-ot ismétli, bár ennek a gyakorlatban ritkán van jelentősége.Hm, úgy emléxem valamelyik átiratban 56 széles képernyőt használok, remélem az utolsó byte üres, és akkor azt ismétli :D ( A Star Sabr-éból rémlik ilyesmi )
Hm, úgy emléxem valamelyik átiratban 56 széles képernyőt használok, remélem az utolsó byte üres, és akkor azt ismétli :D ( A Star Sabr-éból rémlik ilyesmi )
Érdemes lenne megnézni valódi gépen olyan monitorral, amin beállítható, hogy láthatóak legyenek ezek a karakterek is.
Akkor az eddigi maximális 46-os képeinkből is valójában csak 45,5 látszik.
Elvileg egyébként lehetséges lenne 47 karakter szélességű módot megvalósítani, az utolsó byte-ot minden sorban megfelelő időzítéssel valamelyik NICK portra kiírva. Természetesen ennek a hasznossága korlátozott, mert folyamatosan használja a CPU-t, és az utolsó oszlopban csak egy byte video adat lehetséges (LPIXEL módok).
van ügye a hires 2 mód. ilyenkor 2x olyan magas a pixel mint széles. grafikus szemmel nézve eléggé használhatatlan ez. bár nem tudom a "vízszintes tégla" miért jobb, biztos van valami oka.Felteszem a CGA 640-szer 200-as felbontása is meglehetősen "függőleges tégla" arányú. Commodore földön, ha NTSC masinád volt, mintha ott is magasabb lenne mint széles egy képpont, legalábbis a PAL gépekhez viszonyítva bizonyosan (4:3 képarány mindkét rendszerben, de szabvány szerint csak ~240 látható sor a ~288-cal szemben).
de amiért most ezt írom: van más gép, ami tudott ilyen "függőleges tégla" arányú pixelt? :)
Hát, igen. Ezt mindig elfelejtem. Azonban – érdekes módon – a CRTC alapú rendszerek jellemzően ezt a maximális felbontást produkálták. Biztosan volt ennek valami műszaki oka, vagy csak egy kitalálta, a többi ellopta, mert így volt egyszerűbb.
illetve a soha el nem készült VIC-III-nak is lett volna pl. 1280-szor 200-as vagy 400-as felbontása is.
ez vajon igaz gépen is ilyen?
Valódi gépen ott nincs kép (illetve a TV-k általában le is vágják), tehát valójában annak az oszlopnak mindig feketének kellene lennie. De ez például színes keretnél nem túl jól nézne ki, ezért az emulátor ebben az oszlopban is próbál megjeleníteni valamit: ha nem keretszínű, akkor 00h pixel byte értéket tételez fel. A jobb oldalon viszont az igazi géphez hasonlóan az utolsó olvasott video byte ismétlődik, legalábbis a 2.0.10 verzióban.
az attr módnak vajon miért nincs lores verziója?
VanGondolom, basic-ből nem érhetők el ezek a módok a set video mode stb. utasításokkal, csak gépi kódból, poke-okkal.
Gondolom, basic-ből nem érhetők el ezek a módok a set video mode stb. utasításokkal, csak gépi kódból, poke-okkal.Sztem nem eszi, de ha bespókolod BASICből a megfelelő bájtokat az LPT-be, akkor eszi :D
azon gondolkodtam, lehetséges-e olyan exos bővítőt írni, ami engedélyez ilyen extra módokat, vagy pl lpt soronkénti paletta állítástSimán, VIDEO: néven, és akkor az letiltja a gyárit. Így működik a géphez adott Interlace driver is (demó kazettán volt rajta)
Simán, VIDEO: néven, és akkor az letiltja a gyárit. Így működik a géphez adott Interlace driver is (demó kazettán volt rajta)
attr módban ügye két memcímet lehet megadni az lpt-ben. ez a másik cím karakteres módban is használva van.Na jó, de mire lehetett volna használni? Esetleg a felépítés bonyolításával LORES módban lett volna esély valamit kezdeni ezekkel, mivel ilyenkor van még szabad sávszélesség a memória felé, de az megdrágította volna a NICK-et, és még többet késtek volna a piacra dobással.
a többi grafikus módban miért nem használták ezt valamire a nick tervezői?
Na jó, de mire lehetett volna használni? Esetleg a felépítés bonyolításával LORES módban lett volna esély valamit kezdeni ezekkel, mivel ilyenkor van még szabad sávszélesség a memória felé, de az megdrágította volna a NICK-et, és még többet késtek volna a piacra dobással.
Talán az extra 8 szín definíciós pointerére, de gondolom az már nem fért volna be a Nick olvasási idejébe se. :)
hát nem értek az elektronikához, de vajon ha text80 módban tud két memcímről olvasni hires grafikát akkor miért nincs col2 hires attr mód?Ez nem elektronika, csak a NICK működése. Minden képpontsor a NICK számára fel van osztva 57 időszeletre. Minden időszeletben képes elvégezni két olvasási műveletet a videó memóriából, és biztosítani egy olvasási vagy írási hozzáférést a Z80-nak. Ebből az első nyolc időszeletben olvassa az adott sorhoz tartozó LPB-t, az utolsó háromban pedig végzi a memóriájának frissítését (ezért nem tudsz 46/92/184/368/736 karakternél/képpontnál szélesebb képernyőt létrehozni). Nagy felbontású vagy karakteres módokban kihasználja mindkét olvasási hozzáférést az adatok memóriából elhozására, kis felbontású módban csak az egyiket. Vagy legalább is én így tudom. Amit te kérdezel, annak valószínűleg az az oka, hogy a szükséges mennyiségű adat felolvasása már nem fér bele a rendelkezésre álló sávszélességbe, amit pedig nem lehet megváltoztatni.
hát nem értek az elektronikához, de vajon ha text80 módban tud két memcímről olvasni hires grafikátÉppen ez az, hogy Text 80-ban sem olvas két címről.
Éppen ez az, hogy Text 80-ban sem olvas két címről.
A Text 80 a Nick számára nem karakteres, hanem grafikus (Hires 2). A karakterkészletet a VIDEO eszköz olvassa ki karakter kiírásakor, és teszi oda a megfelelő pixel adatot a grafikus területre. Ezért is van ez szoftveres grafikus módnak nevezve. A Text 40 a hardveres grafikus mód.
na most, hogy lehetett volna ezt úgy kihasználni, hogy maga az ep adjon valami jelet oda, tehát hogy minimális hardverrel (azaz olcsón) valamiféle effektet ki lehessen hozni belőle? :DNem hülye kérdés ez, hanem határozatlan. Azt szeretnéd tudni, hogy milyen módon kell bővítést építeni a kérdéses célból? Vagy azt, hogy mi lenne a lehető legminimálisabb bővítő, ami már működőképes és használja a kérdéses bemeneteket? Vagy esetleg valami mást?
Nem hülye kérdés ez, hanem határozatlan. Azt szeretnéd tudni, hogy milyen módon kell bővítést építeni a kérdéses célból? Vagy azt, hogy mi lenne a lehető legminimálisabb bővítő, ami már működőképes és használja a kérdéses bemeneteket? Vagy esetleg valami mást?
Sok értelme nincs, de egy 74LS138+74LS74 elég arra, hogy két bitet tároljunk, azaz a külső szín jelző bitjét, és egy színbitet. 74LS138+74LS74+74LS273 esetén már mind a 4 színbit eltárolható. Azaz egy Z80-as portra kiírható a színkód, és az, hogy be legyen-e kapcsolva a külső szín.
Sok proci használattal talán valami ábrát is ki lehetne rajzolni... de a CPU lassúsága miatt nem túl jó felbontással.
csíkok jelennének meg a hangmagasság függvényében? :DA mididisp ezt csinálja, csak nem a hangmagasság, hanem a hangerő függvényében jelennek meg a csíkok. Bár az sem lenne rossz, ha egyből nyomná kifele a játszott zenét kotta formájában, vagy láthatatlan kéz játszana a zongorabillentyűkön. Ilyenre régebben gondoltam is, hogy ahogy olvassa a zenét a data sorokból a basic, lejátszás közben minden hangmagassághoz hozzá van rendelve X és Y koordináta egy tömbben, és az adott helyre odapöttyent egy karaktert, ahol persze zongorabillentyűk vannak. De basicben ledarálná a pöttyentéseket bőven, mielőtt a zene befejeződne. Csak hogy jó messze elkanyarodjak az eredeti témától.
ja igen, nyilván sok proci időt se foglaljon. ezért gondoltam a hangra.Kb 50-100 Ft.
amúgy ez amit írtál mennyibe került volna annak idején?
Kb 50-100 Ft.
Ha külön címtartományba tesszük a bekapcsoló bitet, akkor rátehetjük a szín biteket a Dave 0Axh portjaira, és akkor villoghat a hangokra :-) , és külön kapcsolható az effekt.
Sok értelme nincs, de egy 74LS138+74LS74 elég arra, hogy két bitet tároljunk, azaz a külső szín jelző bitjét, és egy színbitet. 74LS138+74LS74+74LS273 esetén már mind a 4 színbit eltárolható. Azaz egy Z80-as portra kiírható a színkód, és az, hogy be legyen-e kapcsolva a külső szín.Lehet, hogy nem ábrát kellene vele próbálni rajzoltatni, hanem a külső bemenet színprioritásának használatával valami áttűnési hatásokat létrehozni. De ez nem egy jól kidolgozott ötlet. :(
Sok proci használattal talán valami ábrát is ki lehetne rajzolni... de a CPU lassúsága miatt nem túl jó felbontással.
Lehet, hogy nem ábrát kellene vele próbálni rajzoltatni, hanem a külső bemenet színprioritásának használatával valami áttűnési hatásokat létrehozni. De ez nem egy jól kidolgozott ötlet. :(
Én úgy gondolom hogy ez inkább karakteres módhoz lett kitalálva, valami kompatibilitási okból. A hiányzó pixel oszlopok miatt szerintem grafikához nem való.Egész pontosan a Text 80-hoz lett kitalálva. Így ott 4 színpár, azaz 8 szín lehetséges.
még nem lesz kép (vajon igazam van???).Nem ilyenkor jön az, hogy rákötöd a logikai analizátort és az oszcilloszkópot a Prisére, írsz egy teszt programot, majd mérési ábrákkal színesített hozzászólásban megosztod a nagyérdeművel az eredményt? :D