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.

Az ilyen jellegű problémák elkerülhetők a NICK tényleges működésének az emulációjával, amire az ep128emu is törekszik (a TV emulációját, függőleges szinkronnal és interlace móddal együtt, külön megoldva), és lényegesen jobb kompatibilitást lehet elérni, mint a "magas szintű" megvalósítással (ami elsősorban akkor előnyös, ha nem lényeges a kompatibilitás, és a továbbfejlesztés az elsődleges cél).
Egyébként nem fontos, hogy egymás után következzenek az interlace módú sorok, ha jobban nem lehet megoldani, elég az is, ha a félképek felváltva jelennek meg, az egyiket fél sorral eltolva (valójában a CRT TV-k és monitorok is így működnek).

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
Így gyakorlatilag csak a BASIC programok fognak futni rajta.

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.

Na ezt most vegkepp nem ertem: a Nick szepsege szamomra abban all, hogy LPT-vel mindent meg lehet neki mondani, I/O port max arra kell hogy hol van az LPT (ok, tudom van meg mar funkcio pl color bias vagy mi is volt - de a lenyeg ez) es minden _mas_ kovetkezik mar az LPT-bol. Pont ez volt az erossege, hogy mas video hw-tol elteroen nem volt egyeb "globalis" regiszter stb, hanem lpt, ami egyreszt szerintem hihetetlenul elegans, masreszt nagyon sok trukkot lehetove tesz. Ha most te extra I/O portot akarsz bedobni, hogy ezt/azt kulon lehesen kozolni vele, akkor egyreszt nem lesz kompatibilis, masreszt ezt a "szepseget" fogja pont elvesziteni a dolog.

Amikor sajat emulator kezdemenyemmel jatszottam ezzel, es csak ugy unalmamban "felturboztam" akkor ott max olyan volt plusz I/O portra, hogy slot/byte sokszorozas: az alap 2 byte/slot memoria olvasast lehetett sokszorozni, igy pl 256 szinu mod lehetett nagyobb felbontasban is (mellekhataskent igy az olvasott lpt is "hosszabb" lett pl lehetne 16 szinu modban a maradek 8 szint is akkor belevenni, vagy egyeb plusz infot bele-encode-olni, stb). Amde ugye ez nem kompatibilis az eredeti hw-vel, mindazonaltal ott ez nem is volt gond: ha ez nem volt beallitva, siman ment mint a "regi", tehat nyilvan kompatbilitasi gondot nem okoz, max persze nyilvan az uj feature csak uj software-rel hasznalhato. Amde az mas kerdes, ha te meglevo, eredeti Nick-el beallithato dolgot akarsz ugy megoldani, hogy az maskepp megy, mint az eredeti Nick-en: ekkor viszont megszunik a mar meglevo nick feature-ok kompatibilitasa is.

Van par dolog, ami az lpt-s szemlelet miatt nagyon tuti szerintem, ilyen peldaul hogy elvileg nem kotott karakteres modban a karakter "magassaga", hanem tetszoleges lehet, mert pl ezt is az lpt irja le. Az lpt-s szemleltbol fakad tovabba az, hogy felbontasok keverhetoek egy kepernyon belul, mivel extrem esetben akar per scanline tudsz mast es mast megadni, stb stb, lehetne folytatni.

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.

Ha tovabb akarsz lepni, akkor azt mondod, hogy az EP/Nick-rol kell tovabblepni, az miert jo? Ez a forum pont arrol szol, hogy az EP szep es jo (es nem csak "volt", hanem jelen idoben is az). Lehet olyat is, amit akarsz, de akkor az mar egy EP 2.0, ami viszzamenolegesen nem (vagy nem teljesen) kompatibilis, megha ezzel sok pluszt is nyujthat mondjuk.

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.

Igen, tullepett, ilyen elven hasznaljunk PC-t, es felejtsuk el az EP-t, hiszen azon mar a technika tullepet. Ez objektiv technikai nezopontbol amugy igaz is.

Nem butítom le a Nicket, még nagyobb felbontást kínálok mint az eredeti.

Szerintem inkabb _SEMMI_ plusz ne legyen (se nagyobb felbontas, se semmi!), de legyen kompatibilis a Nick/EP-vel, ahogy az megteremtetett. A plusz extra feature-ok mar csak bonusz dolgok, az egesznek az lenne az ertelme, hogy a kompatibilitas teljes legyen, es csak _utana_ jojjenek az esetleges extra feature-ok, mint a nagyobb felbontas.

A függõleges szinkronnal csak a gond van. Minden szempontból.

Ahogy az EP-vel is "csak a gond van", ha megkerdeznel egy modern hw-t programozot, hogy mit szol hozza, hogy 8 bites CPU, meg 64K address bus a CPU szempontjabol legalabbis stb, az o valasza is az lenne: ezzel csak a gond van, a technika ezen tullepett, szep volt, jo volt, de ideje haladni; tessek 32 vagy inkabb 64 bites cpu-kban es gigabyte-nyi memoriakban gondolkodni

- 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.

Az SVGA monitor ne is csinaljon vele semmit, igazad van! Lasd lentebb.

A nick "TV-hez" keszult, ezt ne felejtsuk el Ha ezt el akarod felejteni, akkor ez nem "Nick v2" lesz, hanem valami tok mas.

Amugy nezz meg egy enterprise-128 emulatort (pl ep128emu): a "kimenet" ott sem TV ugye, tekintve, hogy egy ablakban latod. Megis le van emulalva, hogy van szinkronjel, stb. Nem is mondta senki, hogy a szinkronjelet az SVGA monitornak kell ertelmezni. De alapvetoen az egesz Nick az TV signalt allit elo, es ehhez meg jobban is kotodik mint mas 8 bites gepek video hw-je: ha nezed pl a C64 VIC-II-jet, ott van globalis video mod, oszt' csokolom (ok, raster interrupt, miegymas: elvileg ott is modosithatod persze "menet kozben" a dolgokat, de nem olyan egyszeru es elegans mint a Nick-nel), ott pl sokkal egyszerubb azt mondani, hogy epitek egy VIC-II v2.0-at, amde a Nick eseten eleg kemeny fuggosegek vannak a tv szabvany egyes dolgaival, hiszen jovan nagyobb reahatasod van egyszeru LPB-kkel az LPT-n belul, hogy mit csinaljon, mig VIC-II eseten ugye mindent a hw csinal, nem a te dolgod a szinkronjelek eloallitasa. Viszont pont ezert is szep a Nick.

Elvileg egy software emulator is ugy csinalja, es imho egy Nick v2.0-nak is ugy kene, amit Zozo is javasolt: van egy privat memoriaterulet (kulon memoriakent realizalva) amit nevezzunk "frame buffernek". Ebbe "renderel" a Nick kvazi. Ezt meg folyamatosan olvassa egy masik entitas, aminek a feladata a VGA videojel eloallitasa. Igy a ketto tobbe/kevebe fuggetlen, sot, extrakent akar itt is meg lehet oldani a "TV signal"-t a VGA melett, hogy menjen azzal is, ha valakinek ez az alma Ilyenkor ugye a Nick szempontjabol a fuggoleges szinkronjel annyi lesz, hogy mikor kezdi elolrol a framebuffer irasat, es hasonlok, paros/paratlan sor, stb, tehat kvazi minden kezelheto, amit csak el lehet kepzelni. Plusz akkor az sem gaz, hogy egy monitornak mondjuk kotott felbontas es frissitesi frekvencia kell, aminek lehet, SEMMI DE SEMMI koze nincs ahhoz, ahogy a Nick mukodik.

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.

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.

Az a baj, hogy a nem használt üzemmódból csak egy van. Meg kéne nézni, hogy az LPB második byte-jából hogyan lehetne kihozni extra módokat.
PL: A 64 vagy 256 karakter mód esetén a 4, 16 és 256 színû módot szerintem nem nagyon használja semmilyen alkalmazás. Oda betenném mondjuk a TEXT 80-as megoldást TEXT 40 mintára.

Bár a nem használt mód 4 féle színmóddal használható. Ez nagyon izgalmas.

Továbbá arra gondoltam, hogy a kivágás- beillesztés dologhoz (ami nagyon hiányzik nekem az EP-bõl) megcsinálnám úgy, hogy ha a 2. adatmezõ karaktereinek 7.bitje '1' akkor a betû színei invertálva lennének, így könnyebben kijelölhetõvé válna a soron belül a karakter.
 Mivel ezt a NICK automatikusan csinálná, az EP-vel való szövegszerkesztés felgyorsulna. (Nekem legallábbis az Asmon editor nagyon lassúnak hat.)

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.

Ahogy mar emlitettem, en azt csinalnam, hogy megengednem, hogy a 2 byte / slot nick olvasasi rate-et duplazni (vagy plane sokszornozni) lehessen. Ez persze nem backward compatible, de ez extra feature, x1 szorzoval pontosan a regi helyzet van az meg a default, hacsak valaki nem allitana at. Pl x2 modban 4 byte-ot tudna olvasni a nick 1 slot-ban, ezt pedig a felbontas novelesre tudna forditani, ergo text40-bol lenne - valodi - text 80 (es nem pixel moddal "hamisitott" text80 hehe), illetve kulonbozo pixel-es modokra is rafer nehol a vizszintes felbontas novelese, kulonosen pl 256 szinu modban Raadasul, mivel ekkor 1 slot-ban tobb byte olvashato, ezen beallitas hatasara a beolvasott LPB merete is megno, amiben extra infok lennenek hordozhatoak (pl 16 szinu paletta maradek 8 szine, es egyeb dolgok).

Szerintem ez jar a legkevesebb "filozofia beli" toressel, nem kell uj video mod, semmi. Ez mondjuk tenyleg nem tul LPB-s megoldas, ez imho globalis beallitas lehetne (pl I/O porton at) legyen mondjuk "nick read rate", a default es "original nick compatible" az persze a x1, ami az 1-szeres szorzo a 2 byte/slot eredeti ertekhez. Igy ezzel kb minden videomod mindenfele kulon valtoztatas nelkul novelheto felbontashoz jut, na persze konkretan a 2 szinu pixel modnal sok ertelme nincs, hiszen az a 736 (ha jol irom fejbol) pixel a max De pl 4 szinu uzemmodban (2 bpp) x2 rate-el olvasva maradt a 736 pixel felbontas, igy nem felezodik, ahogy amugy tenne. 16 szinu uzemmodban a max elmeleti felbontashoz mar persze x4 szorzo kene, 256 szinu uzemmodban meg x8. Kerdeses, hogy egy adott hw-ban van-e annyi "power", hogy a x8 elerheto legyen, es a timing megmarad-e, nyilvan emulatorban nem gond ilyet osszeheggeszteni, ahogy anno en tettem

Aztan meg az volt, hogy plusz I/O porttal volt nalam palette, a 256 "vegso" EP szin (amihez szinten egy palregen vezet az ut pl 16 szinu modban ugye) allithato, 2 byte/color megoldassal (azaz 16 bites szinmelyseg). Nalam a nem hasznalt videomod ez a "nativ" mod lenne, amikor egy pixel tetszoleges 16 bites erteket felvehet A felbontas csapnivalo persze! Ilyenkor szinte "must have" a read rate sokszorozas: x8-as rate-el jon elo kb a ~360 pixel, ami mar nem olyan rossz, es hi-color mod

Amennyire en latom, a felbontas novelesere sokkal jobban "nick filozofia" az, hogy mindent hagy az ember pontosan ugy ahogy van, es a read rate-et teszi valtoztathatova, ekkor ez kb olyan elemi parameterre valik mint az lpt kezodcim beallitasa (hiszen ez pl valtoztatja egy lpb meretet is akar!), ezert kerulne ez i/o portra. A globalis paletta szinten egy ilyesmi dolog. Mas imho nem nagyon kene hogy legyen ami custom extra I/O portot kivan, x1 read rate folott egy LPB hossza megno: ez felhasznalhato boven az extra infok tarolasara amire esetleg szukseg van! Anno az is felmerult bennem, hogy pl read rate novelese eseten allithato legyen mire forditodik az extra read-ek "idoszelete", logikus a felbontas novelese (amirol eddig szo volt), de az is eszembe jutott anno, hogy nebezetem az LD3 pointer-t, stb, es siman pl egy belso memoriat tolthet, amit mondjuk igy sprite kijelzesre is hasznalhatna, utana. Elonye: az std nick read timing megmaradna (marmint a sokszorozott teny mellett), nem kell extra "sprite DMA" mint c64 VIC-ii eseten ami aztan felborit ott egy csomo dolgot, es pl azert kellett a floppy serial-IEC-et meg jobban belassitani, mert a vic-ii miatt neha a CPU-tol elkerul a control "hosszabb" idore. Vagy stb, nyilvan szamtalan lehetoseg van