Nekem pont erre van szükségem. Köszönöm a dokumentumokat!

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.

Mivel sok mas geppel ellentetben EP/Nick-en a VSYNC-et is a user vezereli az LPT-n at, ezert ha random irkalsz dolgokat, vagy csak nem figyel az ember, sokkal nagyobb valoszinuseggel eri el a fentit, mint stabil kepet Ez azonban nem bug, hanem feature

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.

Tudtommal ilyen lehetőségek nem nagyon vannak a NICK esetében, mert olyan regiszterek nem hozzáférhetőek amik a képsor megalkotására közvetlenül hatnak. Lehet próbálkozni az LPT erőszakos újratöltésével a rasztersor közepén (persze halálpontos időzítéssel), vagy ha van a NICK-nek is valamilyen teszt bitje esetleg annak az izgatásával, de mást én nem tudok elképzelni. Bár a fantáziám azért nem mondható dúsnak.

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.

Szerencsére a NICK ezeket trükkök nélkül is tudja.

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 működne, mert csak a következő sor elején tölti újra.

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

I think that you can find better examples of "small resoltion with cubic pixels" on handhelds: 4-color 160x144 gameboy classic games, 16-color (?) atari lynx, also neogeo pocket and wonderswan graphics I guess... And I think that a lot of gameboy ports would be even feasible on the ep...


Wanted to ask one thing... As the "problem" for abusing nick features is the lack of immediate access to all of it's registers and creating the display via lpt which values are fetched from only at the beggining of meach line. Is it possible to make a hardware hack to map the now-unaccesable registers to some free ports... "Nick Unleashed";P. Asking out of sheer curiosity as I guess this would take too much "meddling" with the computer's motherboard...

egy nagyon vicces dolgot vettem észre!
EP-n nincsenek szürke színek
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

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.