de akkor eszerint ez is jó:

Így van, így kerül pl a Zozotools óra a rögzített helyen lévő status sor fölé.
Vagy a Z&A demóban így tettem a status sort működő magnó szintjelzővel a képernyő közepére.

És ott van még az LPT animáció lehetősége, amikor a végén még nincs újratöltés, hanem folytatódik egy másik kép kocka adataival. Lásd Nasa&Guy demók nagyrésze.

És akkor mitől talál egymásra a videojel és a monitor ?

Az a lényeg, hogy a két megfelelő szinkronszakasz között megfelelő mennyiségű sor legyen. Erre számít a monitor/tv szinkronáramköre, erre próbálja belőni magát.

Szupi ... de hát épp az van, hogy nem vagyunk már szinkronban ... tehát nem vagyunk tűrésen belül ...

Ilyenkor le kell mennie pár normál körnek, hogy beálljon a dolog. Ez az amit úgy látunk, hogy ugrik egyet a kép LPT váltáskor.

Há még vili ... mint ahogy bizonyos gépeken úgy is mennek ...

C64 van ilyen is meg olyan is, és mivel ott minden mindennel összefügg, ezért más lett a CPU órajele is.

Arra nagyon kíváncsi vagyok, hogy ha belépett volna az amerikai piacra az EP (Las Vegasban ugye kiállítottak egy shown), akkor hogyan készült volna az NTSC verzió?

Arra nagyon kíváncsi vagyok, hogy ha belépett volna az amerikai piacra az EP (Las Vegasban ugye kiállítottak egy shown), akkor hogyan készült volna az NTSC verzió?

Hát ez az ... ennek az eszetlen szabadságnak akár ára is lehet ...

Amigán is van copper, ott is vághatsz soronként képet, mégsem kell szinkronizációval tökörésszél ... (remélem jól emlékszem ... ).

Az még egy dolog, hogy az EXOS -t át kellett volna írni olyanra hogy 200 sornál többet ne használjon soha,

de az összes programot is át kellett volna írni, mivel a fene nagy szabadság jegyében mindennek rossz lenne a szinkronja ... nem ?

Jó hogy a szinkront nem az ENTER gombra vezették már ki, hogy a júzer nyomogassa 50 vagy 60 herccel ...

A NICK -en kéne legyen egy PAL/NTSC kapcsoló, vagy freki kapcsoló, lehetne N-M freki range, és az értelmes sorokhoz neki kéne hozzácsapni a szinkront hardverből. Nem ?

Hát ez az ... ennek az eszetlen szabadságnak akár ára is lehet ...

Amigán is van copper, ott is vághatsz soronként képet, mégsem kell szinkronizációval tökörésszél ... (remélem jól emlékszem ... ).

Az még egy dolog, hogy az EXOS -t át kellett volna írni olyanra hogy 200 sornál többet ne használjon soha,

de az összes programot is át kellett volna írni, mivel a fene nagy szabadság jegyében mindennek rossz lenne a szinkronja ... nem ?

Jó hogy a szinkront nem az ENTER gombra vezették már ki, hogy a júzer nyomogassa 50 vagy 60 herccel ...

A NICK -en kéne legyen egy PAL/NTSC kapcsoló, vagy freki kapcsoló, lehetne N-M freki range, és az értelmes sorokhoz neki kéne hozzácsapni a szinkront hardverből. Nem ?

A szabadság árához csak annyit, hogy mindennek van ára. Azon múlik az egész, hogy hajlandó vagy-e megfizetni vagy sem? Senki sem kötelez arra, hogy saját LPT-t használj. Csak lehetőség.

Amigában nem vagyok képben, de ott talán nem tudsz közvetlenül a videoszinkronhoz hozzáférni, ami a te szempontodból legfeljebb kényelmi funkciónak tudható be. EP-n egy kicsit figyelni kell, de ha egyszer elfogadtad a rendszert, hogy ezzel akarsz dolgozni, akkor sajnos implicit módon a szabályokat és korlátokat is elfogadtad.

Egyébként nagyjából pont annyi történt volna az EP NTSC piacra bevezetése után, mint az a Commodore számítógépeknél is. Lett volna belőle PAL és NTSC változat. Képzeld, Latin-amerikába PAL-60-as gépeket gyártott a CBM, mert ott is próbálkoztak. Valószínűleg a hardver különbözősége szoftverben így vagy úgy, de érzékelhető lett volna, és a program a megfelelő időzítéseket és LPT-t használta volna, vagy a két TV szabványú piacra külön változatot készítenek.

A szabványváltó kapcsoló önmagában kevés, mert az alap vivőfrekvenciák is mások. Egyébként meg a sorszinkront most is saját maga csapja hozzá hardverből. Sőt, a függőleges szinkront is hardverből csapa hozzá, csak szólni kell neki mikor tegye azt. (Egyébként sizecoding versenyeken a szinkronjelek bizergetésével létrehozott effekteknek azért szokott sikere lenni.)

Egyébként nagyjából pont annyi történt volna az EP NTSC piacra bevezetése után, mint az a Commodore számítógépeknél is. Lett volna belőle PAL és NTSC változat. Képzeld, Latin-amerikába PAL-60-as gépeket gyártott a CBM, mert ott is próbálkoztak. Valószínűleg a hardver különbözősége szoftverben így vagy úgy, de érzékelhető lett volna, és a program a megfelelő időzítéseket és LPT-t használta volna, vagy a két TV szabványú piacra külön változatot készítenek.

Tehát módosítani kellett volna minden addig kiadott játékot (hisz mindenki LPT -t használt) és/vagy az új szabványú gépen a módosításokig nem ment volna egyetlen cucc sem ? Hat ... nekem ez azért elég nagy árnak tűnik, ha jól értem.

A szinkron jelek birizgálása teszi lehetővé az interlace-t is.

Ami szintén lehetne síma flag is a NICK -nek.

Az egy alkalmazói döntés hogy interlace vagy nem interlace, eztán felállítja a döntésének megfelelő LPT értelmes sorainak adatbázisát, kódját,

és a NICK meg az alkalmazás döntésének eredménye képpen megkapott interlace vagy nem interlace adatokat tolja PAL vagy NTSC formában kifele ...

Feltéve hogy a kisebb sorszám (mert ha jól tudom, NTSC -n kisebb sorszám van) nem avatkozik be magába az alkalmazásba is ...

Tényleg, hogy van ez, a világ összes játéka más NTSC -ken mint PAL -on ? Azn NTSC egy képarány változtatás is, vagy csak függőleges felbontás változtatás, vagy csak képfreki változtatás, a színek kezelésének változtatása mellett ?

Ha egy játék kihasznál minden sort amit a PAL enged, akkor ott gamplay változtatásokat kell eszközölni (pld. pálya áttervezése) azért hogy a kisebb NTSC képről ne lógjon ki ? Mert ha így van akkor valóban a szinkron a legkevesebb ...

De mondjuk akkor, ha valaki eleve olyan játékot csinált, ami elférne NTSC -n, akkor se futna egy NTSC gépen, amíg az új szinkront hozzá nem írná ... ami akkor megint rossz.

Nagyon nem vagy kibékülve ezekkel a szinkronjelekkel. Az mindig adottságnak tekinthető, legfeljebb olyan rendszerekben, ahol szabadabban hozzáférhetsz nem volt addig piacra érett a program, amíg hibás szinkront generált. Már ha a programozó volt olyan bátor és babrált vele.

 Az NTSC/PAL kérdést szerintem egy kicsit félreértelmezed. Akkoriban nem nagyon nyűglődtek azzal, hogy minden rendszeren egyazon kódnak kelljen futnia. Ha át kellett írni, akkor átírták. Azt csak a későbbiekben végbement nagyfokú szabványosodás tette lehetővé, hogy már ne kelljen foglalkozni ilyesmivel. Az EP, C64, stb. szintjén ezt nem tudod kikerülni. A legtöbb esetben két dolgot csináltak. Vagy letojták, ha csak az egyik rendszeren megy, akkor csak ott megy és kész. A másik, hogy megfontoltan álltak neki, vették a rendszerek közös nevezőjét, és az ebből fakadó korlátok szerint készítették a dolgot. Pl.: NTSC-ben függőlegesen nyújtott lett a kép, de legalább a zene PAL-ban lassabban vagy egyenetlenül ment. Vagy ha nem fért ki a PAL-nál az alsó meg felső keretre szorított kijelző NTSC-ben, akkor PAL only lett a program és kész. Téged, mint Enterprise fejlesztőt ez szerencsére nem érint egy kicsit sem.

nem értem mit kell már ilyen tök alap dolgokon problémázni, mint az lpt...
én általában valami kész lpt építő kódot használtam, mi a fenének újraírni azt ami már megvan?