Enterprise Forever
:HUN => Hardver => Kijelző => Topic started by: Zozosoft on 2009.March.21. 23:15:24
-
Az Iview kapcsán megállapítottuk, hogy olyan csodás dolgokat látunk kedvenc gépünk képernyõjén amire nem is gondoltunk volna, hogy képes rá, és valószínûleg a Nick chip még soha életében nem volt így kihajtva :-)
Sajnos viszont így sok gép rejtett hibája napvilágra került :-( Az elsõ Matusa Pistié volt, de azóta még találtam vagy 5 hibás gépet :-(
A hiba az, hogy a képen nem oda való pixelek tûnnek fel, hol állandóan hol villogva.
Legdurvábban ez az attribútum módú Iview képek esetén jön ki. Amelyik gép itt nagyon hibázik, azoknál már Spectrum átiratokban is fel lehet fedezni a hibát, igaz sokkal kevésbé látványosan, ill. EP-s programokban is. Amelyiknél még csak itt-ott van néhány pötty az Iview képeken, az lehet, hogy teljesen észrevétlen az összes többi programban.
Némelyik gépnél karakteres módban is látszik közelrõl, hogy a karakterekben pixelek tûnnek el vagy jelennek meg.
A tapasztalatok alapján úgy tûnik, hogy minél inkább ugrál össze-vissza a Nick a képmegjelenítés során a videómemóriában, annál látványosabban jelentkezik a probléma. Mintha nem tudná követni a videómemória az ugrásokat... viszont Z80 felõl nézve nem jelentkezik RAM probléma az FC-FF szegmensekben.
Esetleg a Nick más, rövidebb idõzítéssel olvassa az adatokat mint a Z80? És ezt már nem bírják követni az öregedõ RAM IC-k?
Vagy a Nick chip kezd kipurcanni? :-(
Vagy talán pl. kondenzátorok kiszáradása miatt kerülnek zavarjelek a rendszerbe, és ettõl hibázik?
Itt van néhány fotó a hibáról. Az Alien Highway betöltõ képen talán fel se tûnne a hiba, a hold jobb oldalán megy bele egy fehér csík az épületekbe, ill a holdtól balra az elsõ torony tövében szintén, ezek élõben elég feltûnõen vibrálnak. A két képet egymás után lapozva látható még itt-ott pár kevésbé feltûnõ színes pixel is.
Az Iviewes képekhez nem hiszem, hogy kell külön kommentár... (de azért külön Ep128 kolléga kedvéért itt van screenshotok, hogy mit is kéne látni, ha nincs hiba. Most már látod a problémát? :-) )
[attachthumb=6]
[attachthumb=1]
[attachthumb=2]
[attachthumb=7][attachthumb=3]
[attachthumb=9][attachthumb=4]
[attachthumb=8][attachthumb=5]
-
Nagyon is látom, de mivel nekem is "ilyen" pöttyös a kép, így nem tûnt fel, hogy lehetne jobb is... :(
-
Nálam ilyen:
[attachthumb=#]
[attachthumb=#]
[attachthumb=#]
[attachthumb=#]
Ezek jónak tűnnek, csak az utolsó képen furcsa a felhőknél a sötétlila színhiba (amely azonban nem változik véletlenszerűen).
[attachurl=#]
[attachurl=#]
[attachurl=#]
-
utolsó képen furcsa a felhõknél a sötétlila színhiba (amely azonban nem változik véletlenszerûen).
Nem lehet attól, hogy composit videót használsz?
-
Nem lehet attól, hogy composit videót használsz?
De, könnyen lehetséges, hogy ez a video kimenet valamilyen furcsasága, bár nem kompozit, hanem S-video kimenetet készítettem, tehát nincs összekeverve a szín és a világosságjel (így elvileg elkerülhető, hogy a világosság nagy frekvenciájú változásai színként jelenjenek meg). Egyébként hasonló hiba látható itt (http://enterpriseforever.com/enterprise_forum/pc_ep_kepkonverzio-t27.0.html;msg11225#msg11225) is, RF kimenetet használva.
Valószínűleg nem RAM probléma, mert ugyanazok a hibák láthatók .com helyett IVIEW formátumot használva is, annak ellenére, hogy akkor a kép más címre töltődik a video memóriában.
-
Csináltam pár videót is a jelenségrõl. Érdekes, hogy pl az Eat it Up "sakktáblamintás" falkaraktere is nagyon elõ tudja hozni a hibát.
-
Az utolsó videó engem arra emlékeztet, amikor magnóról való töltésnél a töltésjelzõ téglalap, amikor pirosba vált, ott marad egy kis piros függõleges csík a zöld téglalap helyének szélén. Bár az más jelenség lehet, mert antennacsatlakozóval hol volt csík, hol nem, hol meg valami "maszat" volt helyette, erre a maszatra emlékeztetett az Alien Highway videó. Scart csatlakozóval mindig volt éles csík.
-
Az utolsó videó engem arra emlékeztet, amikor magnóról való töltésnél a töltésjelzõ téglalap, amikor pirosba vált, ott marad egy kis piros függõleges csík a zöld téglalap helyének szélén. Bár az más jelenség lehet, mert antennacsatlakozóval hol volt csík, hol nem, hol meg valami "maszat" volt helyette, erre a maszatra emlékeztetett az Alien Highway videó. Scart csatlakozóval mindig volt éles csík.
Hoppá!!! Most egy nagyon érdekeset mondtál!
Mert én ilyet még soha nem láttam! De most megnéztem egy ilyen pixelhibás gépet, és valóban van ez a jelenség! (És lepróbáltam egy jót, ott nincs.)
Ezt neked újkorától csinálta a géped?
-
Még én sem láttam ilyet, pedig egy évet magnóztam.
-
Annyi már kiderült, hogy a Nick chip hûtése jelentõsen befolyásolja a dolgot.
Kísérleteztem leesett hûtésû Nickekkel, ezek alapból igen erõsen produkálják a hibát.
Viszont amint rányomok egy hûtõbordát, jelentõsen javul a helyzet! Amikor leveszem, újra elõjön...
-
Ezt neked újkorától csinálta a géped?
Pontosan erre nem emlékszem, de szerintem igen. Az a kis vonal nekem mindig bizonytalan volt, hogy ott van vagy nincs ott.
Ahogy mondod a chip melegedését, tényleg lehet, hogy összefügg a dolog azzal, hogy mennyi ideje volt a gép bekapcsolva.
Én azért tartottam valószínûtlennek, hogy ez a Nick hibája lenne, mert scart csatlakozóval, ahogy emlékszem, mindig volt éles vonal.
-
Viszont IVIEW képek esetén, ahol maximálisan ki van hajtva a Nick, nem segít hûtõborda se (sõt némelyik alaplapon Eat it UP-ban is megmarad pár kóbor sárga pixel...). Javul a helyzet, de az összes hiba nem tûnik el. Még azt is kipróbáltam, hogy lefagyasztott bordával adtam extrém hûtést a Nicknek, de ez se segített.
-
Pontosan erre nem emlékszem, de szerintem igen.
Ez fontos nyom! Eddig is gyanakodtam, hogy lehet, hogy nem is elromlottak ezek a gépek, hanem eleve ilyenek voltak. De amíg nem voltak Iview képek, addig nagyon nem is tûnt fel a jelenség, az átlag játékokban pár kóbor pixel nem tûnt fel, fõleg ha valaki csak antenna kábelen használta a gépet. Átlag programokban csak akkor jön elõ nagyon súlyosan a hiba, ha leesik a hûtõborda a Nickrõl (Ez egyébként így 25 év után gyakran elõfordul, elenged a ragasztó).
-
Na, ez meg engem az AUTO parancs bug-jára emlékeztet. Tényleg határozottan úgy emlékszem, hogy még eleinte nem volt gond, amikor READ IF MISSING utasítást gépeltem be ilyenkor. Csak késõbb (elég hamar) kezdett a hiba jelentkezni, hogy valami 616-os sor jött az ilyen utasítás után mindig.
A pixelhiba talán mindig megvolt, az autós bug nem mindig.
-
És ami nagyon érdekes: minden hibás gépnél ugyanott vannak a hibák! Tehát pl az Eat it Up falkarakterekben, az Alien Highway 2-ben az a fehér vonal, stb. Nagyon úgy tûnik, hogy ez alapvetõ Nick probléma, már csak az a kérdés, hogy mi hozza elõ?
-
Tesóm valahai gépén (turbósított) volt olyan, hogy alapból soha semmi pixel hiba nem látszott, de ha 7.11Mhz -en járt, akkor kb. háromnegyed óra után elkezdett "maszatos" lenni a kép. Függetlenül attól, mennyire volt kihasználva a NICK. Ha visszakapcsoltuk 4Mhz -re, akkor megszûnt a jelenség. Tehát sebesség függõ is tud lenni.
-
Most fedeztem fel, hogy kétféle Nick chip létezik!
Eddig a 08-47 (http://ep.homeserver.hu/Galery/Alapgep/Picture/NICK.jpg) alkatrész számúról volt fotónk, de most vettem észre, hogy van 08-04 is! Ez jobban is passzol a 08-05-ös Dave-hez. (http://ep.homeserver.hu/Galery/Alapgep/Picture/DAVE.jpg)
Kérdés, hogy vajon mi lehet a különbség? Lehet, hogy a 08-47-es javított kiadás? Vajon van-e összefüggés a Nick verziója és a pixelhiba probléma között?
Ez egyébként egy Flanos EP64-ben van, és olyan full pixelhibás, hogy szinte tiszta sárga a fal az Eat it Up-ban... ehhez valószínûleg erõsen hozzájárulhat, hogy a ragasztófoltból láthatóan igen csálén sikerült a hûtõbordát rögzíteni...
[attachthumb=1]
-
Tesóm valahai gépén (turbósított) volt olyan, hogy alapból soha semmi pixel hiba nem látszott, de ha 7.11Mhz -en járt, akkor kb. háromnegyed óra után elkezdett "maszatos" lenni a kép. Függetlenül attól, mennyire volt kihasználva a NICK. Ha visszakapcsoltuk 4Mhz -re, akkor megszûnt a jelenség. Tehát sebesség függõ is tud lenni.
Én is turboztam csak nem 7.11 hanem 10Mhz-re és a jelenség nálam is elöjött de jégkockával órvosoltam, igaz nem órákig de a jelenség megszünt. Amig a kocka el nem olvadt.
-
Némelyik gépnél karakteres módban is látszik közelrõl, hogy a karakterekben pixelek tûnnek el vagy jelennek meg.
Úgy tûnik több különbözõ problémáról van szó!
Most találtam egy olyan gépet, ami produkálja ezt a karakteres jelenséget, viszont IVIEW képekkel tökéletes! Spectrumos képben sincs hiba.
Az Eat it Up sárga pöttyeit vagy a Spectrumos képernyõn látszódó hibákat, általában eltünteti ha van a Nicken hûtõborda (de van olyan gép amin ez se segít.) Melegedéssel együtt jár az Iview képeken lévõ nagyobb hibafelhõ is.
Az Iview hiba meg lehet, hogy tényleg Nick verzió függõ? Mindenesetre eddig úgy tûnik, az összes ISSUE3,4,5-ös alaplap esetén fennáll! Ami ezek közül leesett bordás volt, az mind 08-04-es Nick. Majd meghámozok pár hibás ISSEU6-os lapon lévõ Nicket, hogy vajon milyen verzió lapul a borda alatt?
-
Érdekes ez a pixelhiba. Ahogy visszaemlékszem, kb. 20 éve szinte természetes volt, hogy bekapcsolás után és bemelegedés után kicsit más a kép, de ez talán nem is igazán tudatosult. De lehet, az is belejátszott, hogy mivel antennacsatlakozót használtunk akkor, a tévé is "elhangolódott".
Amúgy összességében talán mintha bemelegedés után lett volna jobb a kép, nem bekapcsolás után, úgy emlékszem.
-
Mondjuk antennakábelen szerintem a pocsék képminõség el is fedhette a kisebb hibákat.
Iview képekkel próbáltad már a gépedet? A Nick chipeden rajta van a borda?
Bár mint korábbi fotón látható volt a példa, lehet gyárilag is rosszul felragasztva a borda. Azon a gépen újra ragasztottam, utána az átlag programokban jó lett, csak Iview alatt látszik. (Egyébként az is ISSEU4-es lap.)
-
Mondjuk antennakábelen szerintem a pocsék képminõség el is fedhette a kisebb hibákat.
Iview képekkel próbáltad már a gépedet? A Nick chipeden rajta van a borda?
Bár mint korábbi fotón látható volt a példa, lehet gyárilag is rosszul felragasztva a borda. Azon a gépen újra ragasztottam, utána az átlag programokban jó lett, csak Iview alatt látszik. (Egyébként az is ISSEU4-es lap.)
Bocs, hogy ide írom: Zozo az én gépemmel jutottál valamire?
-
Mondjuk antennakábelen szerintem a pocsék képminõség el is fedhette a kisebb hibákat.
Igen, lehet, hogy az antenna viszontagságai voltak azok, amiket érzékeltem...
Iview képekkel próbáltad már a gépedet? A Nick chipeden rajta van a borda?
Az az igazság, hogy bár kint van a szobában az asztalon az igaz EP is, nagyon ritkán kapcsolom be, az emulátort használom helyette, Iview képeket sem néztem még igazi gépen. :oops:
Hogy a Nick-en van-e borda, most nem tudnám megmondani, abban sem vagyok biztos, hol van a Nick a gépben, de majd utánazézek.
UI: Pár éve itt (http://enterpriseforever.com/hardver/milyen_ep_konfigod_van-t31.0.html;msg8029#msg8029l) tettem be képet a konfigomról, a gép belsejérõl is. Nem tudom, ez alapján megállapítható-e, van-e borda. Lehet, hogy még a gyárban lerántották a Nick-rõl a bordát, és így rántottborda lett. :lol:
UI2: Laci oldalán (http://www.ep128.hu/Album/Ep.htm) találtam infót a Nick elhelyezkedésérõl. Mindig tanul az ember, eddig nem tudtam, hogy az a bõvítõpanel azért emelkedik ki az alaplapból, mert azon van a memória egy része. Amennyire aláláttam, valami fényes felület is van alatta, szerintem az lehet az (ezek szerint nem rántott, hanem sült) borda.
-
Kb 15 alaplap megvizsgálása után arra jutottam, hogy tényleg a Nick verzió számít leginkább:
08-47-es Nickek mind hibátlanul tudják az Iview képeket, játékokban sincs hiba. További érdekesség, hogy mindezt hûtõborda nélkül is! Üzemi hõmérséklete amúgy ugyanaz mindkét verziónak.
08-04-es Nickek viszont Iviewben láthatóan hibáznak, és azt, hogy játékokban ne nagyon legyen hiba, csak a hûtõbordával lehet elérni. Persze hosszabb használat után, fõleg nyáron még így is elõjöhet a hiba, lásd Szipucsu magnó szintjelzõje! És van olyan is ami bordával együtt is, rögtön bekapcsolás után is villognak a sárga pöttyök az Eat it Up-ban...
Eddig úgy tûnik, hogy a világoszöld ISSUE6-os alaplapok (amiken E&E gyártási szám van) mind 08-47-es Nickkel vannak szerelve (a NYÁK-on lévõ dátum szerint ezek már 1986-ban készültek), a sötétzöldekben vegyesen fordul elõ ilyen is meg olyan is.
Szalai! Sajnos a tiéd is sötétzöld, 08-04-es Nickkel :-(
Szipucsu! A képen annyi látszik, hogy a te alaplapod is sötétzöld... nem lepne meg ha Iviewvel megnézve hibázna :-(
-
Az SNDPLAY szintjelzõjének a hibája (http://enterpriseforever.com/enterprise_forum/hanglejatszo_fejlesztese-t455.0.html;msg14087#msg14087) függ a Nick verziótól ?
Az csak egyetlen egy gépben fordult elõ, így az valami egyedi hiba lehet. (Lehet, hogy köze van egy ismeretlen elkövetõ által elkövetett 320-as bõvítéshez?) Érdekes módon Iview-ben jó.
-
Csináltam egy primitív "tesztprogramot", a beállított grafikus módnak megfelelõen az összes színnel rajzol egyre vastagabb vonalakat. Majd billentyû nyomásra lehet a palettát állítgatni, mindig egy szín marad fehér, a többi fekete, így meg lehet figyelni, hogy melyik paletta szín az ami szemétként jelentkezik. Ami nagyon érdekes: a páros színek rendetlenkednek! Tehát pl 1-es színû területben felvillannak 0-ás színû pixelek, de 0-ás területen nem villannak fel 1-es színûek. Tulajdonképpen olyan, mintha a video RAM-ból olvasott 1-esek nem jutnának el idõben a Nickhez, és ezért alacsonyabb kódú színt rak ki.
Nagyjából három hibakategória van:
-két különbözõ színû terület határán történõ felvillanás
-karakter határon történõ felvillanás. Ez azért is izgalmas, mert 1 karakter, az 2 bájt hires grafikánál... miért nem minden bájt határon van a hiba?
-karakteren belüli felvillanás
(És van még egy 16 színû módban, amikor az alacsony színekrõl áttérünk magas színekre, ezen a határvonalon is van hiba.)
Melegedés hatására így súlyosbodik a jelenség. De gépenként eltérõ súlyosságú, van amelyik borda nélkül se jut a hármas szintre.
Érdekes kérdés, hogy mi befolyásolja, hogy az egyik gépen súlyosabb a jelenség másikon enyhébb? Egyik Nick így sikerült másik meg úgy? Vagy pl ellenállások, kondenzátorok szórása?
Egyébként egyre inkább az a gyanúm, hogy anno a Enterprise cégnél is szívtak ezzel a problémával, valószínûleg ezért is késett a gép megjelenése.
A ráragasztott hûtõborda erõsen csak tüneti kezelésnek tûnik...
-
Az EP128emu és az EP32 vajon melyik Nickkel rendelkezõ gépet emulálják? Vagy ott a hardware fizikai velejáróinak "emulációja" (pl. melegedés) eleve ki is van zárva?
-
Tekintve, hogy a (túl)melegedés általában ront bármilyen eszköz működésen, így talán érhető, hogy melegedés emulálása (még ha egyébként meg is lenne oldható) nem kívánt feature lenne ;-)
Ezen kívül, egy adott jellemzőt csak akkor lehet pontosan emulálni ha ismert dologról van szó.
Szerintem az EP32 fejlesztésekor még azt sem tudtuk, hogy egyáltalán többféle Nick is létezik. Ha István esetleg tudott is erről, nem hiszem, hogy foglalkozott volna a különböző változatok közötti különbségekkel, mert (joggal) gondolhatta, hogy egyformán működnek.
Szóval ezt a hibát szerintem felesleges lenne emulálni. Ez nem olyan hiba ami szükséges ahhoz, hogy helyesen fussanak a programok.
-
Szerintem az EP32 fejlesztésekor még azt sem tudtuk, hogy egyáltalán többféle Nick is létezik.
Ha jól számolom 8 napja tudjuk :)
-
Ha jól számolom 8 napja tudjuk :)
Igen, tudom, de gondoltam nem zárom ki annak az esélyét (még ha csak matematikai is), hogy esetleg szipucsu kérdése nem teljesen légből kapott :-)
-
Valami olyasmire gondoltam, hogy ha pl. István vagy Egzo pixelhibás alaplapot ismert addig, akkor elméletileg az emulátorban is jelentkeznie kéne a problémának.
De akkor teljesen a melegedésnek tudható be, akkor is, ha rögtön bekapcsolás után tetten érhetõ a probléma?
Légbõl kapott volt amúgy a kérdés. :D
-
De akkor teljesen a melegedésnek tudható be, akkor is, ha rögtön bekapcsolás után tetten érhetõ a probléma?
Nem a melegedés az oka, az csak súlyosbít egy egyébként meglévõ problémát. A problémának van egy gépenként változó alapszintje, amihez képest melegedés hatására romlik a helyzet. Legkorábban az attributúm módú Iview képeken látható, hiszen itt van legjobban kihajtva a Nick, itt kell leginkább össze-vissza olvasnia a memóriát.
Súlyosabb esetben jön az,hogy játékokban is látszik, vagy akár a magnó szintjelzõnél.
Mint a tesztprogramommal kiderült, akár egyszerü Basic grafikánál is, ami azért is rejtve maradhatott, mivel a nullás szín fekete, így kevésbé feltünö ha bevillan.
A tüneti kezelésként felrakott bordával annyit értek el, hogy ez a súlyosabb szint csak hosszú használat után jöjjön elõ (nyáron nyilván hamarabb).
Ha meg van mitõl függ,hogy egyik gép jobban hibázik mint a másik, akkor hátha lehet variálni, hogy csökkenjen a hiba.
Bár nem pont errõl a hibáról van szó, az angol fórumban látható, hogy az ISSEU3-as gépeknél, még jobban szenvedtek, ott a 256 szín és a TEXT 80 (pontosabban a HIRES 2) nem mûködik egyszerre. Egy ellenállás van potméterre cserélve, azzal lehet állítgatni...
Tettem fel videót, igen érdekes hatása lehet ennek az egy ellenállásnak is!
-
Az nem lehet, hogy nem is a Nick a hibás, hanem a lassabb memóriák?
-
... és az nem lehet, hogy ezért nem találtunk (eddig) ISSEU1 meg ISSEU2 alaplapokat? :-) Talán ott olyan katasztrofális szinten volt mind ez, hogy gyártásba sem kerültek...? (Esetleg egy még gagyibb NICK -el szerelve, egyéb gány megoldásokat alkalmazva, stb...)
-
Az nem lehet, hogy nem is a Nick a hibás, hanem a lassabb memóriák?
Szerintem nem, mindenféle variáció elõfordul köztük 300-tól 150 nanosig. Ráadásul itt van ez az alaplap (http://ep.homeserver.hu/Galery/Alapgep/Picture/ISSUE6-5.jpg), ez 300-as RAM-okkal hiba mentes. Amúgy errõl gyárilag hiányzott a Nick borda, de mint kiderült 08-47-es Nickre felesleges is.
Ettõl függetlenül felmerült már bennem, hogy kidobni az egész videó memóriát, a címmultiplexerekkel együtt, és egy 486-os alaplapról kiszedett 64K SRAM IC-vel (ott cache volt) helyettesíteni, amely 15 nanos, vagyis 10x gyorsabb mint az eddig használt leggyorsabb RAM IC :-)
Viszont ezután elég buhera kinézete lesz a lapnak :-)
-
... és az nem lehet, hogy ezért nem találtunk (eddig) ISSEU1 meg ISSEU2 alaplapokat? :-) Talán ott olyan katasztrofális szinten volt mind ez, hogy gyártásba sem kerültek...? (Esetleg egy még gagyibb NICK -el szerelve, egyéb gány megoldásokat alkalmazva, stb...)
Könnyen lehet! Ami hibajegyzék papírokat feltett az angol srác abból az derül ki, hogy az elsõ 100 már "kész" gép ISSUE3-as volt, és ezeket nem eladták, hanem bemutatógépként osztogatták szoftverfejlesztõknek, hogy tudjanak már a megjelenés elõtt fejleszteni. És mellékelték a papírokat, hogy igen ez még nem tökéletes, de a véglegessel nem lesz gond.
(Egyéb érdekességek is kiderültek itt, pl hogy eredetileg a billentyûzet "gumilepedõje" a joystickre is kiterjedt, de rájöttek, hogy nem elég vastag, és elrendelték, hogy a sarkát ki kell vágni, és a már általunk is jól ismert gumikarikát rakni a joy alá.)
-
Az angol srác pont most szórt meg egy rakás újságcikkel :-)
84 januárban már chip problémákról beszélnek:
[attachthumb=1]
Márciusban is:
[attachthumb=2]
Szeptemberben már meg is nevezik, hogy a Nick a problémás:
[attachthumb=3]
-
Könnyen lehet! Ami hibajegyzék papírokat feltett az angol srác abból az derül ki, hogy az elsõ 100 már "kész" gép ISSUE3-as volt, és ezeket nem eladták, hanem bemutatógépként osztogatták szoftverfejlesztõknek, hogy tudjanak már a megjelenés elõtt fejleszteni. És mellékelték a papírokat, hogy igen ez még nem tökéletes, de a véglegessel nem lesz gond.
(Egyéb érdekességek is kiderültek itt, pl hogy eredetileg a billentyûzet "gumilepedõje" a joystickre is kiterjedt, de rájöttek, hogy nem elég vastag, és elrendelték, hogy a sarkát ki kell vágni, és a már általunk is jól ismert gumikarikát rakni a joy alá.)
Azért én ezek után már nagyon megnéznék egy részletes, nagy felbontású képet az ISSEU1 meg ISSEU2 alaplapokról, még akkor is, ha olyanok soha nem gyártódtak le tömegével! :-) Vajon miben különbözhettek a hármastól...?
-
-karakter határon történõ felvillanás. Ez azért is izgalmas, mert 1 karakter, az 2 bájt hires grafikánál... miért nem minden bájt határon van a
Talán a karakteren belül az első és a második byte olvasásának az időzítése más (illetve a második közvetlenül az első után következik, és nincs közben a Z80 számára engedélyezett idő) ?
Légbõl kapott volt amúgy a kérdés. :D
"Csak írható" hozzászólás ? :)
-
"Csak írható" hozzászólás ? :)
Annyiból komolyan gondoltam a kérdést, hogy ha a melegedésen kívül valami más oka is van a jelenségnek, akkor az emulátorban is elõjöhetne a probléma, amennyiben rossz Nickes gép alapján készült (volna) az emulátor.
De nem olyan fontos kérdés ez. :D
-
amennyiben rossz Nickes gép alapján készült (volna) az emulátor.
Az emulátorok szerintem a Nick leírás alapján készültek, ami a tökéletes mûködést írja le.
-
Nem jött be ötlet: címmultiplexerek cseréje HCT-sre...
-
Az emulátorok szerintem a Nick leírás alapján készültek, ami a tökéletes mûködést írja le.
Köszi, így már világos.
-
Légbõl kapott volt amúgy a kérdés. :D
Ettõl függetlenül, igen érdekes programozási feladat lenne emulálni a hibát :-)
-
Azért durva, Zozo mikre derít fényt...
Itt (http://ep128.hu/Album/Ep.htm) mindenesetre kiegészítettem a NICK-hez tartozó dolgokat.
Tényleg, mi van a Nick interjúval? Az lenne még érdekes!
-
Õszintén szólva el nem tudom képzelni, hogy képzelték, hogy ezeket az ISSUE3-as gépeket osztogassák, mint bemutató példányokat...
Valószínûleg nagyon kétségbe voltak esve, hogy valamit mutatni kéne már a népnek, de csak gyári selejtek vannak :(
Annak ellenére, hogy van borda a Nicken, az összes létezõ hibát produkálja egyszerre :-) (pedig a borda mûködik, kb 10 fokkal hidegebb így, mint egy fedetlen Nick! El nem tudom képzelni milyen lehetett borda nélkül... de ezért nem fogom meghámozni :-) )
Itt (http://enterprise.iko.hu/video/OUTPUT_DSCF8200.AVI) egy kis Eat it Up bemutató, miközben a mágikus potmétert csavargatom.
Ami érdekes, hogy amikor kezd el tûnni a Text 80-as szöveg, akkor mintha kevesebb hiba lenne a fal karakterekben. Bár lehet, hogy csak feketére váltanak a pöttyök, és azért nem olyan feltûnõek :-)
Arról most nincs videó, de Text 40-ben is produkálja a hibákat.
-
Azért az igazi hardvert sem árt tesztelni :roll:, mert csak a - sokszor hiányos, félrevezetõ, hibás, stb. - leírás alapján általában nem igazán lehet jó minõségû emulációt készíteni.
Ez kétségtelen! Esetleg emlékszel olyan dologra amit így derítettél ki? Ki lehetne egészíteni, pontosítani a leírásokat.
-
Esetleg emlékszel olyan dologra amit így derítettél ki?
Néhány példa:
- nem dokumentált video módok (pl. milyen a 16 színű ATTR mód + MSBALT, vagy az "érvénytelen" 6-os mód ? :))
- a 83H port felső két bitjének a működése
- időzítés, video memória várakozás, bemeneti órajel pontos értéke (14237536 Hz az alkatrészek szórása nélkül)
- I/O címdekódolás (84H-8FH portokon ismétlődik), port olvasás (a NICK adatbuszról az utolsó értéket adja vissza)
- különböző kisebb hibák, elírások, pontatlanságok a leírásban (ha jól emlékszem, az LSB/MSBALT és/vagy ALTIND0/1-nél valami fel volt cserélve, a megszakítás kimenet az igazi gép tesztelése előtt invertált volt az emulátorban, stb.)
-
Itt (http://enterprise.iko.hu/video/OUTPUT_DSCF8200.AVI) egy kis Eat it Up bemutató, miközben a mágikus potmétert csavargatom.
Az Eat it upban a fal "villódzása" megtévesztésig hasonlít arra, amikor antennacsatlakozónál utánahangolás hiányában elhangolódik kicsit (majd nagyon) a kép. Ezért is mosódott nálam össze a két jelenség.
-
Ettõl függetlenül felmerült már bennem, hogy kidobni az egész videó memóriát, a címmultiplexerekkel együtt, és egy 486-os alaplapról kiszedett 64K SRAM IC-vel (ott cache volt) helyettesíteni, amely 15 nanos, vagyis 10x gyorsabb mint az eddig használt leggyorsabb RAM IC :-)
Viszont ezután elég buhera kinézete lesz a lapnak :-)
Ráment vagy 3 este... és baromira nem változtat semmit a dolgon :smt089 :smt089 :smt089
[attachthumb=1]
Ettõl függetlenül meglepett, hogy bekapcsoltam, és elindult a gép :-)
Azt majd még megnézem, hogy így hány Mhz-ig lehet eljutni tunningban :-) de ez már egy másik téma.
-
Néhány példa:
- nem dokumentált video módok (pl. milyen a 16 színű ATTR mód + MSBALT, vagy az "érvénytelen" 6-os mód ? :))
- a 83H port felső két bitjének a működése
- időzítés, video memória várakozás, bemeneti órajel pontos értéke (14237536 Hz az alkatrészek szórása nélkül)
- I/O címdekódolás (84H-8FH portokon ismétlődik), port olvasás (a NICK adatbuszról az utolsó értéket adja vissza)
- különböző kisebb hibák, elírások, pontatlanságok a leírásban (ha jól emlékszem, az LSB/MSBALT és/vagy ALTIND0/1-nél valami fel volt cserélve, a megszakítás kimenet az igazi gép tesztelése előtt invertált volt az emulátorban, stb.)
A 16 színű ATTR mód érdekelne, emlékszem volt szó róla korábban, de nem találom, segítségedet kérném :) , és mostmár az érvénytelen 6-os mód is piszkálja a fantáziám ;)
-
A 16 színű ATTR mód érdekelne, emlékszem volt szó róla korábban, de nem találom, segítségedet kérném :) ,
Az attribútum mód alapvetően azt jelenti, hogy a paletta szín alsó bitje alapján kicseréli a színt az attribútum byte-ban választott "papír" vagy "tinta" színre, kivéve a 256 színű módot, ahol nincs hatása. Ez a konverzió az LSBALT és hasonló módosítások után történik, tehát azok nem változtatják a színt (mert csak az 1. és 2. bitet állítják, amit az ATTR figyelmen kívül hagy), de azért az LSBALT/MSBALT levágja a pixel byte megfelelő bitjét.
Ez alapján a 16 színű ATTR módban tehát ez történik:
b1,b5,b3,b7 b0,b4,b2,b6
A karakteren belül két négyszeres szélességű pixel lesz, amelyeket a 7. és 6. bit határoz meg, a többi bitnek nincs hatása. Az MSBALT bekapcsolása azt eredményezné, hogy a bal oldali pixel mindig "papír" színű lenne.
Az LSBALT, MSBALT, ALTIND0, és ALTIND1 egyébként minden módban működik, nem csak ott, ahol dokumentálva van:
- az LSBALT/MSBALT nullázza a pixel byte megfelelő bitjét, és a paletta szín 2. vagy 1. bitjét 1-re állítja (OR művelet) a bit eredeti értéke alapján, de a 256 színű módokban a szín nem változik, és attribútum módban sem, mert az attribútum konverzió később történik, és csak az alsó bitet veszi figyelembe
- az ALTIND0/ALTIND1 mindig az LD1 címről olvasott érték alapján működik (függetlenül attól, hogy az éppen pixel adat, karakter kód, vagy attribútum byte), és nem nullázza azt a bitet, amely a színeket vezérli (tehát pl. 256 karakteres módban az ALTIND0-t és az ALTIND1-et is bekapcsolva továbbra is 256 karakter marad, csak 4 64 karakteres csoportra osztva, amelyek különböző színűek); az LSBALT/MSBALT-hoz hasonlóan szintén OR művelet történik a paletta szín megfelelő bitjével, az esetleges attribútum konverzió előtt, és csak 2, 4, vagy 16 színű módban
és mostmár az érvénytelen 6-os mód is piszkálja a fantáziám ;)
Annyira azért nem érdekes, gyakorlatilag olyan karakteres módnak tekinthető, amely a pixel adatot mindig az FFFFh video címről olvassa. :)
Még egy érdekesség: a VSYNC módban a keret is más (ezzel kapcsolatban korábban Zozosoft tévedett :)): itt az aktív (nem keret) részeken szinkron (a feketéhez képest "negatív" világosság), a keret helyén pedig mindig fekete szín (VBLANK) van, és nem generálódik színsegédvivő jel (nincs burst a sor elején).
-
Köszönjük a sok érdekes információt!
ezzel kapcsolatban korábban Zozosoft tévedett
Könnyen lehet, ezek nekem már elég homályos területek :oops:
-
Amirõl még nagyon nincs fogalmam: ezen a rajzon (http://ep.homeserver.hu/Hardware/PCB/Picture/EP64-3.jpg), mi a fenét csinál a lap alsó-közepén található bonyolult ellenállásos tranzisztoros kondenzátoros komplexum???
Annyit tudok tippelni, hogy ebbõl lesz a 14 Mhz-es videó órajel, mivel az U37 10-es lába kimenet. De hogyan lesz itt óra jel? Az egész indul a Nick ismeretlen H/2 és H2REF kimeneteivel...
Annyi biztos, hogy az ISSEU3-as alaplapokon az R81 lett kicserélve egy 470 ohmos potméterre, amivel rendkívül látványosan és érdekesen lehet befolyásolni a Nick mûködését. (Eltûnõ Text 80 karakterek/elmosódó 256 szín)
Azt hiszem ezt a részt Tigrian érthetné, de õt évek óta nem láttuk :cry:
-
Amirõl még nagyon nincs fogalmam: ezen a rajzon (http://ep.homeserver.hu/Hardware/PCB/Picture/EP64-3.jpg), mi a fenét csinál a lap alsó-közepén található bonyolult ellenállásos tranzisztoros kondenzátoros komplexum???
Annyit tudok tippelni, hogy ebbõl lesz a 14 Mhz-es videó órajel, mivel az U37 10-es lába kimenet. De hogyan lesz itt óra jel? Az egész indul a Nick ismeretlen H/2 és H2REF kimeneteivel...
Szerintem ez az áramkör egy PLL (http://en.wikipedia.org/wiki/PLL), amely a 14 MHz-es órajelet állítja elő. A H/2 és a H2REF is kimenet, és a sorfrekvencia fele (innen a név: horizontal / 2) található ezeken. A H/2 valószínűleg a NICK 14 MHz-es bemeneti órajelének az 1824-ed része (2 * 57 * 16, mert egy sorban összesen 57 karakter van, és egy karakter 16 2 színű HIRES pixel, és egy pixel egy ciklus :)), a H2REF pedig a referencia frekvencia, a "PAL" bemeneten érkező 4433618.75 Hz (http://en.wikipedia.org/wiki/PAL#Technical_details)-es órajel 568-al osztva. Az előbb említett frekvenciát a szabvány pontosan meghatározza, az 568-as osztót viszont az itt (http://enterpriseforever.com/emulatorok/idozitesi_problemak_az_emulatorokban-t380.0.html;msg14841#msg14841) végzett tesztekkel sikerült kideríteni. Az U32 XOR kapu a fázisdetektor (amint az a fenti PLL leírásban is olvasható, a legegyszerűbb megoldás erre a célra :)), a TR4, L2, és kapcsolódó alkatrészek pedig a feszültségvezérelt oszcillátor.
A pontos órajel tehát 4433618.75 / 568 * 2 * 57 * 16 = 14237536.2676056338 Hz.
Annyi biztos, hogy az ISSEU3-as alaplapokon az R81 lett kicserélve egy 470 ohmos potméterre, amivel rendkívül látványosan és érdekesen lehet befolyásolni a Nick mûködését. (Eltûnõ Text 80 karakterek/elmosódó 256 szín)
Ez talán az órajel valamilyen tulajdonságát rontja el, pl. stabilitás, élmeredekség, vagy (a legvalószínűbb ?) kitöltési tényező.
-
De hogy lesz a H2 kimeneteken jel bekapcsoláskor, amikor még áll a Nick? És ameddig nincs H2 jelek, addig mibõl csinál a az áramkör órajelet?
Vagy az magában is rezeg, ez a H2 csak a finomításra szolgál?
-
De hogy lesz a H2 kimeneteken jel bekapcsoláskor, amikor még áll a Nick? És ameddig nincs H2 jelek, addig mibõl csinál a az áramkör órajelet?
Vagy az magában is rezeg, ez a H2 csak a finomításra szolgál?
Igen, az oszcillátor frekvenciája valószínűleg csak kis mértékben vezérelhető, tehát ha nem lenne ott az U32 kapu, akkor is lenne órajel, csak nem elég pontos. Az L2 feltehetően éppen azért hangolható, mert egyébként az alkatrészek szórása annyira nagy lehetne, hogy a PLL nem is tudna beállni a pontos frekvenciára.
-
Köszönöm szépen az ismertetőt, egyelőre még 100%-osan nem értem, kúrűnak forralt bort használtam :D, arra gondoltam, hogy esetleg ki lehet csiholni a Nick-ből C64 lo-res üzemmódot is :(
-
Eddig úgy tûnik, hogy a világoszöld ISSUE6-os alaplapok (amiken E&E gyártási szám van) mind 08-47-es Nickkel vannak szerelve
Sajnos ez a feltételezés megdõlt :-( most találtam egy pixelhibás világoszöldet, leszedtem a Nick bordát, és kiderült, hogy 08-04-es :-(
-
Az L2 feltehetõen éppen azért hangolható
Ennek a tekergetésével hullámozni kezd a kép egy idõ után, ha túl sokat tekerünk :-)
Kipróbáltam az ISSUE3-ból ismert dolgot, az R81 potméterre cserélését is: érdekes módon egy újabb alaplapon nem jön elõ az a effekt, hogy eltünik a Text 80 vagy a 256 szín elszínezõdik! A pixelhibára viszont csak minimális hatása van, inkább csak úgy sûrûségében látszik egy pici különbség. Kipróbáltam a "testvérellenálláson" is, az R82-n, hasonló eredménnyel.
-
Regebben volt egy olyan tipped hogy az alaplapon levo osszes elkot ( es tantalt? ) ki kene cserelni, hatha attol megjavulnak a pixelhibak... ez mar teljesen elbukott az uj ismeretek tukreben ?
-
ez mar teljesen elbukott az uj ismeretek tukreben ?
Nagyon úgy tûnik! Amúgy nézegettem kondikat, az ezen az alaplapon (http://ep.homeserver.hu/Galery/Alapgep/Picture/ISSUE5-4.jpg) is látható Philips kondik hajlamosak tönkremenni, ha egyiptomi idõjárásnak voltak kitéve :-)
A legtöbb gépben használt világoskék kondiknak (http://ep.homeserver.hu/Galery/Alapgep/Picture/ISSUE6-5.jpg) nincs baja az arab gépekben se, kíváncsiságból kiszedtem párat a helyérõl, kapacitásmérõvel megmérve semmi bajuk.
-
Kozben megneztem hogy azokat a kepeket amiket neztem IstvanV tette fel, ebben a topikban mas kepek nincsenek is, gemeskut, kekfeher pacak, stb.
Es mintha interlace- esek lennenek, vagy ha nem, akkor nem tom miert rezegnek ugy a kepek az ep128emu -val nezve.
-
Es mintha interlace- esek lennenek, vagy ha nem, akkor nem tom miert rezegnek ugy a kepek az ep128emu -val nezve.
Igen interlacesek. Nekem emu-ban egyébként az vált be, hogy quality 3, és resample to monitor refresh rate.
-
Ja, ez valoban kozelebb allhat egy EP kephez, de az en monitoromon meg ennel es stabilabb mint a te altalad javasolt beallitasok, tehat gyakorlatilag a monitor megallitja teljesen a villodzast, nem lehet rajta megallapitani hogy interlace kep.
csak az emuban vettem eszre, amit a te beallitasaid jol lecsokkentenek egy valoszinuleg standrad RGB monitorra kotott EP szinjere.
-
Kozben megneztem hogy azokat a kepeket amiket neztem IstvanV tette fel, ebben a topikban mas kepek nincsenek is, gemeskut, kekfeher pacak, stb.
Ezek valójában Zozosoft képei, .com formátumra konvertálva :)
Ja, ez valoban kozelebb allhat egy EP kephez, de az en monitoromon meg ennel es stabilabb mint a te altalad javasolt beallitasok, tehat gyakorlatilag a monitor megallitja teljesen a villodzast, nem lehet rajta megallapitani hogy interlace kep.
A monitorban talán valamilyen digitális deinterlace van (ha LCD, akkor szinte biztosan) ? Az emulátor sem villog egyébként szoftveres video módban.
-
U, most nekem beugrott valami ... ( De szoljatok ha ismetlem magam ) ... Meg a regi szep idokben, mikor aktivan hasznaltam az EP- t ( kozepiskolai idoszak, elektronikai szakirany ), igazabol mindig azt lattam az ep- bol, hogy hat az elektronikaja az mar mekkora egy nagy remekseg a 8 bites eraban, es hat jajj, ezt a hardver kivitelt ezt ugy elszurogattak ... hatejnyebejnye ... nade karpotol minket az elektronika ... az igazi lenyeg, a mukodes, a funkcio, ha mar egyszer ra vannak forrasztava azok a drotok, ha mar van hasznalhato klaviatura, ha mar valahogy sikaerult felcsatlakoztatni a joyt vagy a kijelzot, vagy epp betolteni egy programot ( mert valljuk be ezek a dolgok nagyon experimentalisak az ep- nel a kezdetektol ), akkor mar milyen josagokat is tud ez produkalni nekunk ... es akkor kiderul hogy a CPU- ja, memoriaja olyan lassu a mozgatando tarteruletmeretekhez kepest hogy szinte esely sem volt semmit megmozditani rajta, es meg a video hardver sem kepes normalis, szethullasmentes kepet produkalni, csak 50 gepenkent 1- en ? tehat ha valaha osszerak ( vagy osszerakott regen, mert felvitte az isten a dolgat mar akkor ) maganak valaki egy szuper kijelzot az ep- hez, es sikerul neki atomeles kepet varazsolnia, akkor eri a legnagyobb pofon, mert pont ez a kepkielesites az ami megmutatja az EP talan legnagyobb hibajat ! :) Es ez a hiba keremszepen nem mechanikus jellegu. Ez az elektronikaban van ! Benne, a legmelyibe ! Na ez keremszepen verlazito rettenetes es kiabrandito ... :) mikor az emberfia atkuzdi magat a megannyi veszelyen es akadalyon, mikor mar a sarkanyok osszes fejet levagta, mikor mar ott a cel az orra elott... akkor latja meg hogy vege van az utnak, elotte hatalmas szakadek, es benne sarkanyhadsereg kavarog ... ezt szanta nekunk a sors, kedves ep- s sorstarsaim ... :)
-
Sziasztok!
Tudtam én hogy nem csak álmodtam... :ds_icon_cheesygrin:
A kilencvenes években az egyik osztálytársam gépébe tettem joy foglalatot és amikor kipróáltuk, nagyokat lestem hogy miért nincs az egyes játékok alatt neki "csík"! Hát most már tudom!
Az õ gépében is javított nick lehetett.A 04-essel van a 47-essel nincs.
Hétvégén megcserélem õket.
Kíváncsi vagyok...
-
Izgalmas! Ez melyik Dizzy rész? Majd én is kipróbálom pár gépen.
-
A képek a Dizzy 3-ból valók, konkrétan a BabSoft-féle magyar verzióból.
-
ilozikatap: itt van egy program formára alakított iview kép teszteléshez.
-
Ha jól emlékszem van "másfajta" csík is!
Ha kell keresgélek és csinálok képeket.
Zoli
Ui.: köszi a cseri-t Zozoszoft!
Így könnyebb lesz a teszt.
Meg is van!
1: 04-es nick töltés közben a szalagon épp szünet van(kevesebb csík)
2: 04-es nick töltés közben a szalagon van jel (több csík)
3: 04-es nick játék betöltve
4: 04-es nick játék betöltve
5: 47-es nick töltés közben
6: 47-es nick játék betöltve
Az 1 és 2 között nem biztos hogy kimondottan a hang a külömbség lehet hogy olyankor "dolgozik" valami a gépben és akkor csíkosabb...(talán a nálam jobban hozzá értõk megerõsítik ezt a dolgot)
A 3 és 4 között talán az a külömbség hogy ha nincs nagy változás a képen kevesebb a csík de mielött az a kis demó rész váltana több elöjön(vagy valami ilyesmi) :shock:
És a z fehér téglalap a jobb alsó sarokban...
Elég "kézzel foghatónak" tûnik.
Nem úgy mint egy pillanatra felvillanó pixel.
-
Itt is egy!
A jack the nipper felirat mellet balra(lehetne bármelyik ami így tölt)
Igazából úgy vettem észre hogy minden olyan játéknál látszik valami ami ilyen leváltással tölt.(lásd mp3)
A leváltás alatt azt értem hogy az éppen töltõdõ file nevét alulra írja ilyenkor a magnó szintjelzõ is alulra költözik...(nem mindíg jelenik meg alul, de fentrõl eltûnik)
Nem szaporítom tovább, a lényeg már látszik...
-
Ez nem inkább egy döglõdõ gép hibajelensége?
-
Idáig amiket láttam ep-ket mind így viselkedett.
Most is két gépen próbáltam amiben 04-es nick van mindkettõ hozza a hibákat.
A 47-es nem.
Öcsém is így emlékszik hogy az összes gépünk ilyen volt.(10-12 db biztos átment a kezünkön )
Mint említettem egyet láttam régen ami nem hozta a hibákat és nemrég kaptam még egyet az van itt szétszedve 47-es nickkel.
Ha van valakinek kéznél ep küldöm az mp3-makat ha kell...
-
Viszont hogy végképp érdekes legyen a dolog az issue4 es flan-os 04-es nickel szerelve
nem hozza a highwayben és az eat it up-ban...
Vagy ez nem törvényszerû?
-
Általában kell 5-10 perc melegedés is hozzá.
-
Reggel óta mennek. :?: :!:
Akkor ez lehet hogy jó?
Holnap megpróbálom melegíteni...
-
Izgi, nem láttam még olyan 04-est amivel nem jött volna ki ebben a két programban (is).
Cserit nézted?
-
Igen de load errorral leáll.
Pedig mindent úgy csináltam ahogy írtad.
elég halknak tûnt ezért felvettem magnóra és onnan is megpróbáltam de nem akarja az igazságot :(
lacikátol letöltöttem a dash1-et azzal is ez a helyzet.
Az elsõ "fütty" a cím, a második után ki irja a statusban hogy pause és mielõtt a magnó ujjra elindulna load error restarting system.
-
A kilencvenes években az egyik osztálytársam gépébe tettem joy foglalatot és amikor kipróáltuk, nagyokat lestem hogy miért nincs az egyes játékok alatt neki "csík"! Hát most már tudom!
Az õ gépében is javított nick lehetett.A 04-essel van a 47-essel nincs.
De ez a mostani 04-es gép ugye nem az ami régen volt? Ezt úgy emlékszem mostanában szerezted.
A régi géped nincs már meg?
-
Az egyik a régi a másik újj.
2 db 04es van.
És 1 47-es
-
Hogy egész pontos legyek:
1:issue4 flan 04-es nick német
2:issue 6 04-es nick német
3:issue 6 47-es nick angol
és a 2. számút használom folyamatosan 20-on pár éve.
-
A képek a Dizzy 3-ból valók, konkrétan a BabSoft-féle magyar verzióból.
Itt legalább az van, hogy TOJASEMBEREK, nem az, hogy TOJßSEMBEREK. :D Egy fokkal azért jobb az elõbbi.
-
Gyaszjelentes
Nem tudom volt- e meg ketseg zozoban a nick- eket illetoen, eleg hezagosan kovetem csak az esemenyeket, mikor legutobb foglalkoztam a temaval meg csak a gyanu arnya vetult a nick- re, remenykedtunk minden masban, de sajnos az iment bizonyossa valt ( 100% ) hogy a pixelhibat a nick okozza.
Vettem egy ujabb ep- t, es bar kristaly keppel indul par percen belul megjelennek a pixelhibak. Ezen elszontyolodva elhataroztam ( mivel az idofaktor nagyon erosen valami homerseklet problemara, fuggvenyre engedett ugye kovetkeztetni ) hogy megegyszer elvegzem a fagyaszto spray tesztet.
Regen mikor csinaltam ugyanezt meg csak keves ep- m volt, nem mertem ugy szetszedni oket, hogy a nick- et lehetett volna huteni, csak az osszes tobbi alkatreszre fujogattam a fagyaszto spray- t, de mostmar meg szabadon allo alaplapom is van, siman le mertem tepni rola a ram panelt es a hutolemezt a nick- rol, es igy direktben lehetett fujni a hutospray- t a nickre.
Az eredmeny teljesen hatarozott es egyertelmu. Nick- re fujva a hutest azonnal tokeletes rezzenesmentes lesz a kep, nyomtatott papir minosegu. Ha dave- re fujok, vagy mashova korulotte, arra nem reagal.
A tesztet tobbszor elvegeztem ( mindig megvarva, hogy ujra felmelegedjen es a pixelhibak jelentkezzenek ), teljesen egyertelmu volt.
Gyasz es kereszt, pixelbug inside, vegunk van, mehetnek a kukaba az alaplapok.
Azt a kutyamajat.
-
Ez most melyik verziójú Nick és melyik fajta pixelhiba?
-
Hat en eddig meg csak egy fajta pixelhibat vettem eszre mindenhol, engem csak ez zavart meg mindig, minden gepemnel ( kiveve kettot, az egyik amit toled kaptam ),
az pedig az, hogy ilyen szinek hatarainal egy-egy pixeleket villamgyorsan vizszintesen ingadozik a hatar,
na ezt en sem ertettem volna meg,
pld. van egy H karakter aminek mondjuk a bal oldali szaranak pixelei a neha atugranak egy pixellel balra vagy jobbra, de nem az egesz scanline vagy ilyesmi, csak bizonyos pixelek.
A nick szamat erdekes modon nem tudom megmondani, mert kepzeld el nincs rajta. Tisztara toroltem a feher genyatol ami rajta volt, csak valami felatlatszo pillanatragaszto szeru valami maradt rajta ittott, de egyebkent tokfekete az ic teteje. Nincs rajta felirat.
A dave- en tisztan olvashato:
ami 8512GS
dave 01
enter 08-05
austria
feliratok vannak,
az alaplap
S/N 11935
de a nick az jeloletlen ...
lattal mar ilyet ?
-
Probaltam fenykepezni, nem tul nagy eresztes:
[attachthumb=#]
-
lattal mar ilyet ?
Nem, de olyat már igen, hogy a ragasztó leszedtem a feliratot :-)
A "fehér genya" dolog gyanús, hogy már valaki piszkálta, mert ilyen nincs gyárilag, csak a pillanatragasztó.
van egy H karakter aminek mondjuk a bal oldali szaranak pixelei a neha atugranak egy pixellel balra vagy jobbra
Ez az amit "karakteres pixelhibának" hívok, mert jellemzõen a karakteres képernyõn látszik.
A másik fajtáról, amiben a 08-04-es Nick-kek szenvednek a topic elején raktam be képeket, videókat. Ez legdurvábban az attribútum módú IVIEW képeknél jön elõ, de elõfordulhat Spectrum játékokban is.
És a két dolog független, amelyik "karakteres" hibás az IVIEW alatt lehet hibátlan.
-
Akkor nezzem meg hogy ez iview alatt hibazik- e, es ha igen, akkor arra a hibara is kihatassal van- e a hutes ?
-
Igen, nézd meg ezzel a csomag IVIEW képpel (http://ep128.hu/Ep_Demo/Prg/Interlace_Demo_3.rar), ha olyan pixelhiba felhõket látsz, mint az itt betett példákon (http://enterpriseforever.com/hardver/pixelhibas_alaplapok-t471.0.html;msg14091#msg14091), akkor 08-04-es a Nick.
-
arra a hibara is kihatassal van- e a hutes ?
Hatása van, itt próbáltam (http://enterpriseforever.com/hardver/pixelhibas_alaplapok-t471.0.html;msg16376#msg16376), de a mélyhûtött bordával se szûnt meg teljesen a jelenség.
-
Dolargaan írta itt (http://enterpriseforever.com/hardver/hibaelharitas-t166.0.html;msg27942#msg27942), hogy úgy tûnik kismértékû tápfeszültség emelésre megszûnik a gépében a karakteres pixelhiba.
-
Arra nincs lehetoseg hogy a nick ugy kapjon tapot, hogy az mast ne erintsen csak a nicket,
es ugy emelni a feszultseget felfele csak a nicknek ? Legrosszabb esetben besulne egy nick.
Akar levagni a nicket a tapjarol, es kulon adni neki allithatot, es szepen csavarni fel neki ?
Ilyen nem megoldhato elektronikai szempontbol ?
-
Akar levagni a nicket a tapjarol, es kulon adni neki allithatot, es szepen csavarni fel neki ?
Elvileg lehetne ilyet csinálni.
-
Elvileg lehetne ilyet csinálni.
Gyakorlatilag is, ha kicsit gányolva is.
De nem érdemes még ezen agyalni. Most jutottam el odáig, hogy a kapcsoló üzemû táp miatti hullámosodást megszüntettem. A tapasztalatok majd mennek a megfelelõ topikba.
-
Na megcsinaltam a fagyasztos teszteket az iview kepekkel.
Ugyan nem tudtam azokkal a kepekkel csinalni amiket zozosoft javasolt, mert jelenleg egy noteszen kivul nincs mas gepem, igy nem tudtam az ep- re tennni az anyagot,
de a winyomon ott volt az epslides2/epslides3 vagy valami hasonlo nevu konyvtarak a demo alkonyvtarban a hivatalos winyo image- en,
es azokban volt egy csomo iview kep.
Szinte mindegyik hibas, jo nagy szazalekuk marha sok pixelen zizegosen hibas. Pixelhiba tengerek voltak.
Ja azt is majdnem kihagytam hogy nem a reggeli alaplapon probalkoztam, mert azzal nem tudtam osszeloni a winyot,
hanem a tunning gepemen ( mar mindent bevetek, lehet tonkre is tettem a mega ep- met a teszt kedveert, de hat aldozatokat hozni kell ugye :( ), amirol (zozo ugyis tud mindent) most csak azt kell tudni, hogy 08-04 -es nick van benne.
Es hat ra a fagyasztas. Sokkal nehezebben lehet iview kepet pixelhibamentesse tenni fagyasztassal, mint a karakteres kepernyos pixelhibakat. Mondhatni a fagyasztospray- m teljesitmenye a hataran mozog, de ha nem sajnalom (kb. 3/4 fagyasztospray- t fujkodtam el a tesztek alatt) a spray- t, es ugy fujom, hogy az ic feluleten egyenletesen mindenhol, mozgatva, boven locsogjon az anyag,
akkor tobb masodperces hutes aran minden kepet sikerult teljesen pixelhibamentesse tennem (fagyasztanom).
De ez valoban egesz mas aranyu hutest igenyel mint a sima karakteres kepernyon levo pixelhibak.
A karakteres kepernyonel epp csak rafujok egy picit az ic kozepere, es mar hibamentesse is valik ( nehany masodpercre persze, amig ujra fel nem melegszik ), de itt az iview kepeknel hosszu masodpercekig, tizmasodpercekig kell teriteni a spray- t az ic teljes feluleten, ugyelve hogy minden sarka kapjon belole, es akkor lesz csak TELJESEN hibamentes.
Joval kevesebb pixelhibaig viszonylag konnyu huteni az ic- t, de ha a maradek 10%- nyi pixelhibat is el akarom tuntetni, akkor akar fel percen keresztul is huteni kell az ic- t, mire vegre az utolso pixelhiba is eltunik.
Az ic kozben olyan zero fokig hulhet vissza gondolom, mert ha hozzanyulok total hideg, de az ujjam meg nem ragad hozza, viszont ilyen jegesedes jelenik mar meg rajta.
Egyszoval ez a hutes dolog nem mukodo megoldas.
Szerintem 100% hogy a nick a pixel hibajelensegek oka, mindegyik fajta pixelhiba oka, de kompenzalni hutessel nem lehet, hacsak valaki nem akarja folyekony nitrogenben huteni a cuccat.
Remeljuk a tapfeszemelesi manoverek pozitivebb eredmennyel zarodnak. Akar nick pusztulasok aran is. :( :twisted: :twisted:
-
08-04-es Nickkel én is erre jutottam :(
A hûtés csak tüneti kezelés, és nem is teljesen oldja meg a gondot.
Egyéb körülmények változtatásával kellene próbálkozni.
A videó memória szupergyors SRAM-ra való cseréje nem változtatott semmit az IVIEW-es hibán.
-
Az lenne igazabol meg erdekes szamomra, hogy ezek a hibak kezdetektol jelen voltak, csak nem vettuk eszre oket az rf modulatorokon es fekete-feher monitorkivezeteseken keresztul, vagy ez csak egy a nickek oregedesevel elokerulo hiba, es ha 20 evvel ezelott lettek volna ilyen monitoraink mint most, pixelhibamentes kepeket lattunk volna.
Persze ezt mar nem fogjuk megtudni, es ha tudnank se segitene rajtunk most. Itt ez a sok ep, amirol nem is almodhattam volna 20 eve, es zsezseg a kepuk mint 1 hangyaboly.
Ironikus. Mar- mar filozofikus allapotok kerem szepen.
-
Egyéb körülmények változtatásával kellene próbálkozni.
Adjunk neki kakaot! Meglatom micsinalnak majd 5.2 5.5 vagy 6-7 volt kornyeken.
Inkabb meghajtom es visszahutom. De legyen stabil. Ha kozben 2 elpukkan, legalabb tudjuk majd hogy kell megcsinalni.
-
Az biztos, hogy az akkoriban használt megjelenítõkön nem igen tudtunk egyes pixeleket megkülönböztetni, így villogásuk se tûnhetett fel :)
Iview képek se voltak, semmi nem volt ami akár csak félig kihajtotta volna a Nick tudását. Más programokban nem nagyon feltûnõ, csak ha nagyon hibás a gép (pl leesett a Nick borda)
A Szipucsu által említett jelenség (melegedés után a magnó szintjelzõnél látható vonalka) arra utal, hogy a probléma régen is meg volt.
-
Inkabb meghajtom es visszahutom. De legyen stabil. Ha kozben 2 elpukkan, legalabb tudjuk majd hogy kell megcsinalni.
Azért túlzásokba nem kéne esni, manapság nem lehet Nicket kapni, se hibátlant, se hibásat!
A lelkes Nick2 projektrõl se hallani mostanában...
-
Nem akarok beleszólni a hardware szakik dolgába, de szerintem nem kéne elpukkasztani azokat a Nickeket azért. Manapság a Nick ritka, mint mackósajtban a brummogás.
-
Egyeb erdekes jelensegek is vannak:
Ha bekapcsolom a gepet akkor a WP modban a rozsaszin-lila kockak hataran egybol vannak a pixelhibak. Hogy a sima BASIC kepernyon is legyenek pixelhibak arra ugye varni kell par percet, de a WP rozsaszin-lila kockahataron azonnal bekapcsolas utan is vannak.
Ez a WP- ben azonnal jelentkezo pixelhibasodas az IVIEW kepek pixelhibasodasaval rokon, mert az iview pixelhibak is azonnal vannak bekapcsolas utan, es ezeket a WP- s pixelhibakat is ugyanolyan nehez lefagyasztani ( elmulasztani fagyasztassal ) mint az IVIEW- s pixelhibakat.
Tehat mig a BASIC kepernyon csak percekig tarto melegedes utan jelentkezo pixelhibakat egy rovid kis nick kozepere fujt hutospray adaggal le lehet fagyasztani, addig a WP es IVIEW bekapcsolas utan azonnal jelentkezo pixelhibait csak az ic teljes feluletere fujt hosszas, akar tizmasodpercekig tarto fagyasztasaval lehet eltuntetni.
Ebbol en ( is ) arra kovetkeztetnek, hogy ezek a pixelhibak nem is kulonbozo tipusuak, hanem ugyanaz a jelenseg, ami homersekletfuggo, es a kulonbozo szin vagy egyeb parameterkombinaciok kulonbozo homersekleten kulonbozo modon hajlamosak a pixelhibasodasi jelensegre.
Vagyis van a nick, aminek kulonbozo tipusai es peldanyai kulonbozo modon pixelhibasak, ami kb. annyit jelent (persze erdekes lenne ismerni az okokat, de sosem fogjuk megtudni), hogy a kulonbozo megjelenitesi parameter es/vagy szinatmeneteknel ( meg az is lehet ugye, hogy direkt szinvaltasokkal fugg csak ossze a hibajelenseg) HOMERSEKLETTOL nagyon fuggo modon ezt a villogast okozza. Vagyis az egyik tipusu parameter es/vagy szinatmenet kisebb homersekleten is, a masik meg csak nagyobb homersekleten hajlamos a pixelhibasodasra.
Ezert lehet az hogy a WP rozsaszin-lila parameter/szin atmenete es az IVIEW kepek parameter/szin atmenetei azonnal kis homersekleten is hibazhatnak megfelelo(en rossz) nick eseten, mig a BASIC kepernyo feketen zold karakteres atmenetei csak hosszas melegedes utan pixelhibasodnak be.
Es ettol lehet a szukseges hutes mertekenek kulonbozosege is, hisz a BASIC kepernyo pixelhibasodasahoz kell par perc, mire annyira felmelegszik a nick, hogy mar az is behibasodjon, es aztan csak egy rovid kis hutospray adaggal ugy vissza lehet huteni a nicket, hogy azok mar eltunjenek, mig a WP es IVIEW szobahomersekleten is jelentkezo pixelhibasodasat csak hosszas hutessel tudom eltuntetni, hiszen itt a nicket melyen a szobahomerseklet ala kell huteni hogy hibamentesen tudjon dolgozni azoknal a parameter/szinatmeneteknel is.
Tehat egyszeruen arrol van szo hogy a kulonbozo atmenetek kulonbozo mertekben homersekletfuggoek.
Extrem esetben az is lehetne hogy szobahomersekleten is minden egyes szinatmenet csurom pixelhiba, es az is, hogy nyari 50 fokos tuzo napra tett, elotte mar 3 hete folyamatosan uzemelo ep alaplap egyaltalan nem pixelhibasodik be.
De a nickek 90 (vagy megtobb) %- a (sajnos) valahol a ketto kozott van. Lehet hogy azokrol a nickekrol amiket most pixelhibamentesnek gondolunk, azokrol is be tudnank bizonyitani mondjuk egy kis hajszarito fujassal, vagy egyeb melegito technikaval, hogy bizony megfelelo homersekleten azok is pixelhibara hajlamosak.
Az is biztos, hogy 0 fok kornyeken megszunik a pixelhibazas kb. a gyakorlatban. ( Ha a nick belseje is 0 fok kornyeken van ) En legalabbis nem talaltam olyan kepet, kepernyot, barmit, ahol megfeleloen turelmes hutessel egy sima fagyaszto spray- jel ne tudtam volna teljesen pixelhibamentesse tenni a kepet.
Ebbol akkor az is kovetkezik, hogy a legpixelhibasabb gepek is, ha telen minuszfokban kivinnenk oket a szabadba, akor pixelhibamentesen mukodnenek.
Erre akar csinalhatnank is egy tesztet, egy forraltborozassal osszekotott teli osszeroffenes formajaban valahol, ahova ki tudunk huzni egy 220- as kabelt, es nincs tul messze a forraltbor, raadasul nem visz el bennunket a rendorseg sem. :) Persze kihuzhatom a kabelt az erkelyemre is, de akkor kihul a lakas es sose rugok be.
Regebben voltak ilyen elektromos alapu procihutesek, amik ha jol emlekszem 0 fok kornyekere hutottek, lehet az is megoldas lenne. Csak ezekkel a szobahomersekleten 0 fokos cuccokkal az a baj, hogy para csapodik ki es ha az nincs elvezetve, akkor rovidre zar. Itt spray teszteknel is jelentkezik, hogy egy ido utan annyira hideg lesz a nick hogy tok komoly mennyisegu folyadek keletkezik rajta, ami befolyik a labak koze, es elkezd hulyen mukodni a gep. Ezert hittem hogy lehet elromlott, de kiszaradas utan ment tovabb.
Es +1 erdekesseg a vegere:
Olyan szituval is talalkoztam, hogy bekapcsolom a gepet, nem pixelhibas a BASIC ugye, varok valamennyit, bepixelhibasodik a BASIC, aztan megnyomom az auto beallitast a tft- n, ami tud nativ 15 khz- t, es eltunnek a pixelhibak anelkul hogy barmi mashoz nyultam volna !!! Aztan mulik az ido ( tovabb melegszik a nick gondolom ) es megin bepixelhibasodik, ekkor azonban mar nem segit az auto beallitas, csak a hutospray.
-
Olyan szituval is talalkoztam, hogy bekapcsolom a gepet, nem pixelhibas a BASIC ugye, varok valamennyit, bepixelhibasodik a BASIC, aztan megnyomom az auto beallitast a tft- n, ami tud nativ 15 khz- t, es eltunnek a pixelhibak anelkul hogy barmi mashoz nyultam volna !!! Aztan mulik az ido ( tovabb melegszik a nick gondolom ) es megin bepixelhibasodik, ekkor azonban mar nem segit az auto beallitas, csak a hutospray.
No ezt meg kéne nézned CRT-n is!
Mert itt bekavar az, ami miatt azt mondtam, hogy jelenleg soha nem lehet 100%-os képe az EP-nek TFT-n!
Azaz a natív felbontások eltérése, a TFT pixelrácsa nem esik egybe az EP pixelrácsával. A határra kerülõ részpixelekkel meg ki tudja mi lesz, mondhatni véletlenszerûen történik valami. És egy pic változástól, ha odébb csúsznak, akkor más valami fog történni.
Ami majd segíteni fog ezen, hogy jönnek a 4K monitorok, sõt most már 8K-ról is beszélnek, így egyre kisebbek lesznek a határra esõ pixelek.
-
Hat sajna nincs crt montorom keznel, de nem hinnem hogy ilyen tft-ep osszeferhetetlensegrol lenne szo,
hiszen a nick hutesevel teljesen sima lesz a kep ( tehat elmulik a hiba, barmi is az osszefugges ),
es hat barmit is mutat a tft az ep kepebol, osszeferhetetlen- e vagy sem, annak egy allando,
konstans torzulasnak kene lennie egy allando kepnel, itt pedig villogas a jelenseg ugye,
raadasul egyes pixelek villogasa, ami crt monitoron is megfigyelt jelenseg, lattuk mar crt monitoron is.
Vagy nem ? Meg soha senki nem figyelte meg a pixelhibazas jelenseget crt monitoron ?
Arra gondolsz hogy a pixelhibazas jelensege EGYALTALAN nem jelentkezne crt- n, vagy megfeleloen nagy mintavetelu digitalizalasnal ?
Az egesz pixelhibazasi jelenseg tft - ep videojel osszeferhetetlenseg lenne, arrol szol hogy mikronnyit korabban/kesobb jon a pixelhatar az ep jelben,
ami miatt a tft monitor egy egesz pixellel elore vagy hatrarakja a pixelt, ettol lenne a villogas, es ha egy display kepes az ep felbontasanal joval nagyobb pontossaggal reagalni a pixel szinenek valtozasara,
akkor ez a csuszas csak mittomen egy tizedpixel meretu, amit a tft digitalizalo "nagyit" teljes pixel meretu hibava ?
Nem a nick hibazna egy teljes pixelt, hanem csak a tft monitorok novelik a kis hibajat teljes pixel meretuve ?
Es hutes hatasara ez a tizedpixelnyi nick hiba nullazodna le annyira, hogy mar a tft monitorok is hibamentesnek jelzik ki ?
Latta mar valaki a pixelhibakat crt monitoron ?
-
Van pixelhiba CRT-n is.
De a TFT digitalizálós mûködése generálhat még plusz hibákat, vagy a meglévõket jobban kinagyíthatja.
Te írtad, hogy van olyan helyzet amikor a TFT AUTO funkciója eltünteti a hibákat!
A gép melegedésével változhat a jelalak, picit elcsúszik a kép, máshogy esik már a TFT pixelrácsára, stb ezért már másként értelmezheti a digitalizáló.
Ezért lenne jó ezt a konkrét gépet megnézni CRT-vel, hogy úgy mit mutat?
-
Igen, van olyan helyzet hogy az auto funkcio kijavitja oket, de ez inkabb csak erdekesseg, ha aztan meg mar nem kepes,
es ha crt- n is vannak a hibak, akkor ott mar tenyleg biztosan az ep rontja el a teljes egesz pixelt, akkor szerintem az mindegy is,
hogy egy tft monitor auto funkcioja kepes valahogy kompenzalni az ep korai melegedesi szakaszban torteno hibazasat, nem ?
Pedig mar hogy megorultem volna, hogy esetleg nem a nick ront egy teljes pixelt ... :)
-
Sot lehet hogy csak a tuzet szitottam es vissza kell vonjam, lehet hogy az elejen jelentkezo auto funkciotol kijavulos "pixelhibak" valojaban nem is pixelhibak.
Most kiszaradt megint az ep, kozben kihult, es megneztem ezt az elso dolgot, amin eddig csak gyorsan atsiklottam az auto- val,
es valoszinuleg ezek a pixelhibak nem is pixelhibak. Ezek sorelcsuszasok lesznek, amik viszont nem feltetlenul latszanak/jelennek meg minden egyes karakteren,
de az igazi pixelhibazassal ellentetben tul sok zizzenes van szabalyosan a sorban. Tehat mintha nem az igazi jellegzetes fuggetlen egyes pixelek hibazasa lenne,
hanem ilyen egesz sor elcsuszas, ami viszont nem feltetlen latszik meg a sor osszes pixelen ...
De mindegy is mert ha ezen a kezdeti melegedo szakaszon atjutott, akkor jon az "igazi" pixelhibak vilaga, amin ugye semmilyen auto nem segit.
-
Viszont en valamiert azt hiszem (persze nem talalom a leirasaban, hogy milyen felbontasban digitalizal) hogy ez a mar sokat linkelt eszkoz jo nagy felbontasban digitalizal,
mivel direkt erre a celra terveztek, nem pedig csak tesseklassek tettek bele egy monitorba:
http://www.ambery.com/rgbcgatovgac.html
Ha ugy jonnek ossze a dolgok akkor par het mulva mostmar tenylegesen rendelek is egy ilyet, es megtudjuk, hogy mit tud a gyakorlatban.
-
Lehet, hogy abban a sarokban éppen jó, de teljes képet tekintve nem volt olyan, hogy minden jó :oops:
A 9-es feljegyzés (http://enterprise.iko.hu/historical/Concession Note 9.pdf) szól arról, hogy az 50 db ideiglenes Nick-kel szerelt ISSUE4-es alaplapnál is a felét 256 színre, felét Text 80-ra kell beállítani, és ha véletlenül akad olyan amin egyszerre jó mindkét üzemmód, azt 80/256-os jelzéssel kell ellátni.
Amúgy a 08-04 Nick ismert pixelhiba problémája kb 100x mértékben jelentkezik ezeknél, hiába hűtőborda, pl az Eat-it-Up-ban a falak szinte tiszta sárgák...
Amúgy az én EP-men is voltak/vannak hibák, már a betöltőkép alatt, amikor az egyedi státusz sor lekerült a kép alá, ott extra karakterek jelentek meg (Pl Turbo Esprit), vagy ha volt keretszín töltés közben, akkor a kép alján fekete csíkozás is megjelent, most ezek jutottak eszembe, de érdekes, mert a "gyári" porgramoknál ezek nem jelentkeztek, lehet az LPT volt úgy felépítve, hogy ez nem tetszett annyira a Nicknek.
-
Amúgy az én EP-men is voltak/vannak hibák, már a betöltőkép alatt, amikor az egyedi státusz sor lekerült a kép alá, ott extra karakterek jelentek meg (Pl Turbo Esprit), vagy ha volt keretszín töltés közben, akkor a kép alján fekete csíkozás is megjelent, most ezek jutottak eszembe, de érdekes, mert a "gyári" porgramoknál ezek nem jelentkeztek, lehet az LPT volt úgy felépítve, hogy ez nem tetszett annyira a Nicknek.
Ez izgalmas, ilyet én még nem láttam, igaz nekem 08-47-es Nick jutott!
IVIEW-el nézted már, hogy mi produkál a géped?
Az általad leírtakhoz hasonlóról itt (http://enterpriseforever.com/hardver/pixelhibas-alaplapok/msg26574/#msg26574) volt szó.
Na majd kipróbálom pár 08-04-es gépen magnóról töltve ezeket.
-
Ez izgalmas, ilyet én még nem láttam, igaz nekem 08-47-es Nick jutott!
IVIEW-el nézted már, hogy mi produkál a géped?
Az általad leírtakhoz hasonlóról itt (http://enterpriseforever.com/hardver/pixelhibas-alaplapok/msg26574/#msg26574) volt szó.
Na majd kipróbálom pár 08-04-es gépen magnóról töltve ezeket.
Ezt is produkálta :D , és közben ugrált egy picit a kép :D
Nem próbáltam, mert az iview elkészülte előtt kapcsoltam be utoljára a gépem :oops:, azóta csak emulátor, nem is tudom melyik programot teszteltem rajta utoljára, azt tudom, hogy az első pár átiratomat még leteszteltem ott is, csak aztán lusta voltam, vagy meghalt a PC-m, és nem tudtam floppyra másolni.
-
Ki próbáltam több 08-04-es alaplapot (000409 EP64 is köztük volt) az itt emlegettet játékokat (Fast Food, Jack the Nipper, Turbo Esprit) és egyiknél se láttam semmi extra effektet.
Igaz csak lemezről, de az LPT attól még ugyanaz..
-
Én csak kazettáról töltöttem, de nem hinném, hogy befolyásolja, mert játék közben is ott volt a csík, vagy az extra karakterek, vagy épp a keretcsíkozás, és ugrálás :D
Vagy a Nickjeink tartalmaznak még pár extra bugot, vagy ezen játékok LPT-jére allergiás a Nickünk, inkább az előbbire szavazok :D Ja, és volt olyan, ha jól emlékszem, így sok év távlatából, hogy az elején pl a színes keretes játékoknák (úgy rémlik, ilyen volt az Exploding Fist) nem volt csíkozás, aztán idővel szépen gyarapodtak a csíkok :D
-
ISSUE3-as alaplapon az Out of This World (magyar álnéven Magicball) esetén is vannak durva hibák, a pálya jobb szélén mindig látható egy vonal (akkor is amikor üresség van ott), ill. a Level és Road számlálónál a szám mögött egy függőleges csík...
-
ISSUE3-as alaplapon az Out of This World (magyar álnéven Magicball) esetén is vannak durva hibák, a pálya jobb szélén mindig látható egy vonal (akkor is amikor üresség van ott), ill. a Level és Road számlálónál a szám mögött egy függőleges csík...
Azokon milyen Nick van? (típus, származás) Vagy ez itt már lehet nem nick függő, hanem alaplapfüggő dolog?
-
Azokon milyen Nick van? (típus, származás) Vagy ez itt már lehet nem nick függő, hanem alaplapfüggő dolog?
AHogy korábban írtam: "az ISSUE3-as alaplapon Koreában készült DAVE látható (http://enterpriseforever.com/hardver/ep64/?action=dlattach;attach=3870;image), a Nickről nem feszegettem le a bordát (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif) de vélhetően az is ott készülhetett. A végleges gépekben Ausztriában készült chipek vannak."
9-es feljegyzés (http://enterprise.iko.hu/historical/Concession Note 9.pdf) szerint 50 ISSUE4-es alaplapot is összeraktak ilyen Nick-el.
Ebből az újságból (http://enterprise.iko.hu/articles/Personal_Computer_World_1984-11_Page_3.jpg) kéne normális felbontású verzió, ott van lefotózva a még borda nélküli Nick.
Ebből a homályos pixelhalmazból én Koreára és 08-04-re tippelek.
-
A végleges gépekben Ausztriában készült chipek vannak.
Akkor ezért is lett olyan drága az EP! Ausztriából elhurcolták a chipeket UK-ba, ott összerakták, majd chipestül vissza az egész Ausztria mellé Magyarországra. Még ha elhozták volna az EP-t UK-ból Ausztriába, ott belerakják a chipet és onnan Magyarországra, egy picivel olcsóbb lehetett volna. :D
-
Egy kis érdekesség, ezzel a pici programmal BASIC-ben is tesztelhető a Nick:
10 GRAPHICS ATTRIBUTE
20 SET INK RND(16)
30 PLOT RND(1280),RND(720)
40 GOTO 20
Hibás Nick-nél egyes pixelek hunyorognak.
-
Arra vannak -e bizonyítékok, nyomok, hogy a régi időkben is hibáztak -e a nick -ek ?
Tehát ugye régen nem volt még iview, meg régen sokan RF -en működtek, ami majdnem nullázza a nick hiba észrevehetőségét, és ugye azt is tudjuk, hogy 2 féle képpen is megjelenik a nick hiba, van olyan ami csak az iview -s képeknél hibázik, és van olyan is, ami egy sima basic képernyőn is zizeg.
De arra van bármi nyom, hogy ez régen is volt? Konkrétan az a kétféle egymáshoz hasonló jelenség, amit nick hibának hívunk ? Vagy simán lehet, hogy régen ez nem volt, és csak az idők során döglöttek be a nick -ek ?
-
Mennyi hőt adhat le vajon egy nick chip ? Vannak ezek a peltier hűtések:
http://www.frozencpu.com/cat/l2/g30/c105/list/p1/Liquid_Cooling-Peltier_Coolers_TEC_Coldplates.html
Van belőlük 80, 200 wattos is ...
Neten találtam említéseket 400 wattosakról is ... Lehűtheti vajon valami ilyen a nick -et 20 fok alá ? Mert szerintem ott már nem zizegnének ...
-
Konkrétan arra gondolok, hogy a nick most felforrósodik (ezért is biggyesztettek rá hűtést) de ha a hűtőlap helyett (vagy arra rá) egy ilyet tolnánk (mégha esetleg nagyobb teljesítményű tápot is kéne az EP -hez csinálni), akkor az elszívná a nick -ről a hőt, és az ő másik oldala lenne a forró ... Ha meg a nick most nem gyújtja fel a házat, akkor ez sem gyújtaná ... :)
Nekünk csak annyi lenne a lényeg, hogy a nick hideg maradjon, és a forróság erről a hűtőelemről vezetődjön el ... nem ?
Saját hangja meg ennek nincs ... ha működne, akkor ez "javíthatná" a nick hibákat ... bármilyen gépen, bárkinél ... nem ?
-
Peltier coolers, also known as thermoelectric coolers (TEC) consist of the peltier element itself and a powerful heatsink/fan combination to cool the TEC. TEC coolers have two wires which connect to a power source in your pc case, when voltage is applied to those wires, a temperature difference across the two sides of the TEC is achieved. One side is hot and the other side is cool. You place the TEC between the CPU/GPU and the heatsink with an appropriate thermal interface material (thermal grease).
-
Arra vannak -e bizonyítékok, nyomok, hogy a régi időkben is hibáztak -e a nick -ek ?
Érdemes a topic elejét is olvasni :-)
Ott már egyszer kitárgyaltuk pl. szipucsuval, hogy igen régen is. Meg késöbb más játékokban előforduló hiba is lett említve.
Meg azt is írtam, hogy mélyhűtött bordával sem szűnt meg teljesen a jelenség, bár javult.
Amúgy meg a hibás és a jó Nick hőmérséklete egyforma. És a jó remekül el van borda nélkül is.
Amit érdekes lenne tudni, hogy mit terveztek át az ISSUE 3 és 4-es alaplapok között, mivel a 3-ason még hihetetlenül vacak a helyzet.
-
Mert ugye én egy sima fagyasztó spray -vel is meg tudtam szüntetni az iview villódzást (99% -ban mindenképp, és az őrült sokat számít egy hibás nick -nél), de gőzöm nincs hány wattos hűtést fejthettem ki azzal, hogy fújtam rá a fagyasztót, mint az ördög ...
És amint abbahagytam, másodperceken belül visszajöttek a hibák ... de valamiért azt hiszem a nick nem fűthet még 80 wattot sem, mert az EP tápja 9V*1.3A összesen nincs 20 wattos ... nem ?
Magyarul egy 30 dolláros ilyen peltier lehet 0 fokra hütené a nick -et ... nem ?
-
mélyhűtött bordával sem szűnt meg teljesen a jelenség
Ez alatt mit értesz ? Hogy érted el a mélyhűtést ?
Ott már egyszer kitárgyaltuk pl. szipucsuval, hogy igen régen is.
Hát magát a nick-hiba jelenséget csak nemrég "publikáltátok", nem hinném hogy régen (20 évvel ezelőttre gondolok) komolyabb tesztek lettek volna erre ...
Biztosak vagytok benne, hogy jól azonosítottátok be ? Ok, hogy voltak hibás nick -ek régen is, de ez a tömeges mennyiségű nick -et érintő pixelhibázás ez is volt régen is ?
-
Ez alatt mit értesz ? Hogy érted el a mélyhűtést ?
Beraktam egy bazi nagy hűtőbordát a mélyhűtőbe egy napra.
Hát magát a nick-hiba jelenséget csak nemrég "publikáltátok", nem hinném hogy régen (20 évvel ezelőttre gondolok) komolyabb tesztek lettek volna erre ...
Biztosak vagytok benne, hogy jól azonosítottátok be ? Ok, hogy voltak hibás nick -ek régen is, de ez a tömeges mennyiségű nick -et érintő pixelhibázás ez is volt régen is ?
Az a nemrég, az van már vagy 5 éve. Az Iview féle maximális kihajtás hozta elő látványosan.
Késöbb derült ki, hogy máshol is vannak nyomai, amit régen is láttak, csak azt hitték, hogy úgy normális. Mint pl a szintjelzőnél ott maradó pálcika Szipucsu gépén.
Az biztos, hogy régen nem volt Iview féle kihajtás. Legtöbben nem csúcs minőségű monitort használtak.
És ami tényleg súlyosbította az idővel: a borda ragasztása elenged, sok gépben már teljesen le is esett. Így sokkal jobban hibázik a hibás Nick.
-
Á ... ha jól értem nem olyan jó a helyzet ahogy gondoltam, ennek a review -i között:
http://www.frozencpu.com/products/2408/exp-01/245W_Potted_Peltier.html?tl=g30c105s187
találtam ezt:
What people seem to forget is that when you use a peltier, you not only have to cool the heat from the CPU, but the heat the peltier itself generates. This means that if your CPU is generating say 85W, and your peltier is running at 12V/18A, the total amount of heat generated at the hot side of the peltier is 301 Watt! That is an insane amout of heat and you''ll need a good watercooling solution, probably at least double or tripple radiator, if you want your CPU to run cooler with the peltier unit than without it. I wonder why no vendor ever posts the peltier units datasheet, detailing its voltage/current/deltaT/heat_transfer graphs. The other thing is that peltiers heat transfer depends on the temperature difference between its two plates. Maximum heat transfer occurs at deltaT = 0ºC, while heat transfer stops at about deltaT = 67ºC. In short, how good this peltier will work will greatly depend on how cold (= how close to ambient temperature) you can keep the hot side of the peltier.
Amit ha jól értek, akkor arról szól, hogy ez a hűtés akkor működik jól csak, ha sikerül lehűtened a meleg oldalát.
Egyébként pedig vigyázni is kell, mert extrém forróvá válhat hűtés nélkül.
-
Amitől még egy PC házban összeszerelt géphez simán jó lehet továbbra is ...
Sőt a kisebbikkel érdemes lehet eljátszani úgy, hogy szabályzod a max áramfelvételét ...
De lehet hogy ez hülyeség, mert ha a nick elér 60-80 fokot (és annyit szerintem elér) akkor már nem lesz különbség a hideg és a meleg oldal között, és nem vesz el róla többet ...
Mindegy egy próbát megér ...
-
Csak akkor meg mi az értelme egy ilyen hűtésnek, igazából ? :)
Úgy értem, hogy ha egy ilyen hűtőnek a meleg oldalát képes vagyok szobahőmérsékleten tartani (hűtéssel), akkor magát az eszközt is tudom ott tartani, ugyanazzal a hűtéssel, nem ?
Mi ennek az értelme ?
-
Vagy tulajdonképpp ... Ha merünk merészet gondolni ... és most tényleg ne mindenki egy rondán összebarmolt EP -re gondoljon majd, hanem olyanra, mint azok az izomautók, amiknek a motorja kilóg a motorházból ... :)
Tehát hogy ilyen (peltier -rel vagy anélkül) esztétikusan megcsinálva hogy kiall a nick hütése a házból ... :)
Akár úgy hogy nagy darab van kivágva, és abban ül egy nagyobb hűtőtest, akár úgy, hogy csak valami hővezetőcsövek jönnek ki a házból, és felette csatlakoznak be valami nagyobb hűtőtestbe ...
És valami esztétikus és hőálló anyag lenne a kiálló vasak és az EP kivágott részének pereme között ...
-
Az a javulás, amit én a fagyasztóval elértem az iview képeken (99% körülire javulás), ha konstans állapot lenne, az szerintem megérne egy ilyen átalakítast is ...
-
http://www.dansdata.com/peltprac.htm
So you stick a Peltier on your processor, you run it from your computer's Power Supply Unit (PSU), and suddenly the chip's colder than ambient. Possibly much colder than ambient - below freezing, in some circumstances.
Which means you can run it faster than you otherwise could, and boost its supply voltage more than you'd otherwise dare, and still keep the thing at a reasonable temperature.
Szerintem működne ... annyit csak lehetne vele hűteni mint a spray -vel, és az elég. Legalábbis a tesztelt, baromira hibás gépemnél elég volt.
-
Srácok, nekem van egy olyan gyanúm, hogy a spray nem a hűtésével fejti ki a hatását. :-P Mármint nem az előállított hőmérséklettel, hanem azzal, amit a hűtőborda nem tud, mélyhűtve sem, vagyis:
A HIRTELEN (!) hőmérséklet KÜLÖNBSÉGGEL! Már pedig azt semmivel nem produkálod, csak a spray -vel!
Attól "tér észhez" extra mód a NICK, hogy nagyon hirtelen, nagyon nagy kontraszt alakul ki az addigi és a "hirtelen előállt" hőmérséklete KÖZÖTT! De ezt egy folyamatos hűtés Neked sosem fogja produkálni, legyen az bármi is... Épp azért, mert FOLYAMATOS, nem pedig hirtelen erős változást okozó...
(Lehet, hogy hülyeséget beszélek, akkor majd az okosok javítanak... :-) )
-
Ha sokáig fújtam, akkor sokáig maradt jó. Tehát semmiképp nem egy pofonról, vagy változásról beszélünk, hanem egy abszolút értékről: minnél kisebb a hőmérséklet, annál kevesebbet hibázik a hibás nick. Nincs ebben semmi meglepő, mai procik is érzékenyek a melegre, 20 éve nyilván meg rosszabb volt a szitu.
Az már valóban különbség lehet azonban, hogy Zozó a fagyasztott bordájával milyen abszolút értékre tudta hűteni a nick -et, vajon sikerült -e neki oda lehúzni, ahova én a spray -vel. (Majd egy egész dobozt fújtam rá, nem kis cicc -ekről van szó.) Tehát a borda meddig maradt fagyos, miután a hűtőből kivette, és milyen jó volt a hőátadás.
És azt viszont nem tudom elképzelni, hogy a spray nagyobb teljesítményt legyen képes lehűteni mint mondjuk akár csak egy ilyen 80W -os peltier.
Épp most próbálom egyébkén a spray -vel is tesztelt nickről levakarni a ragasztóréteget, ami a hűtés felragasztásához volt használva. Ehhez van már valami bevett módszer vagy tapasztalat ? Hogy jön le az a retek ragasztó a nickről ?
-
1-2 miliméteres pillanatragasztónak tűnő valami réteg van rajta ... :(
-
Az 512k -s belső bővítés azokra a szegmensekre (is) pakolódik be mint az eredeti gyári 64k ? Mert ha igen, akkor egy ilyen beszerelésével a nick frankón szabaddá is válik ... és rá lehetne szerelni egy ilyen hűtést ... :)
-
Mondjuk ha egy ilyen kiállna az EP -ből ott a nick -nél :
http://www.frozencpu.com/products/10061/vid-139/Titan_Iron_Heart_Northbridge_Active_Chipset_Cooler_TTC-CSC31TZRB.html?tl=g40c16#blank
Szerintem marha jó lenne ... :)
Vagy csak egy ilyet kipróbálnánk, ez ahogy méricskélem simán elférne belülre:
http://www.frozencpu.com/products/21966/vid-251/Ultra_Thin_Server_Chipset_Heatsink_-_38mm_x_30mm_x_6mm_-_Silver.html?tl=g40c16
Persze mindkettőt lehetne kombinálni a peltier -rel ...
Marha sokféle van, öröm nézni őket:
http://www.frozencpu.com/cat/l2/g40/c16/list/p1/Air_Cooling-Chipset_HeatsinksCoolers.html?o=rating_desc
-
A Peltier-elemmel megvalósított hűtés nem véletlenül nem terjedt el. Jó ötlet az, hogy az IC-ket a külsejükön akár 0°C alá is hűthetjük, csak nagyon sok vesződséggel jár a hűtésnek a szigetelése (Lásd még: LN2 vagy LHe hűtéses processzor, RAM és VGA tuning). Sajnálatos módon a levegőben mindig van pára, ami szépen kiül a hűtőd hideg oldalára, hogy azután később folyadék formájában elhelyezkedjen a hűtött alkatrész közvetlen közelében. Az álmos-könyvek az elektromosság és víz kombinációjáról nem sok jót írnak. :cry: A másik hibája hogy mivel alacsony a hatásfoka, ezért felesleges nagy a teljesítmény igénye.
-
A Peltier-elemmel megvalósított hűtés nem véletlenül nem terjedt el
Ok, ez a totál negatív oldal, de szerinted nem lehetne mondjuk egy ilyen 80W -os (vagy még kisebb) peltiert úgy beállítani a nick -hez, hogy csak annyit hűtsön, hogy a nick 15 fok körüli legyen ? Az akkor nem negatív, és kisebb plussz teljesítménybe is kerülne, nem ? És ha nem nagyon hideg, tán a pára sem csapódna ... vagy igen ?
-
Nyilván szabályozás kérdése. Mérni kell a páratartalmat és a hűtött oldal hőmérsékletét, azután egy mikrovezérlő már simán megoldja az egészet. Az a kérdés, hogy ilyenkor képes-e biztosítani az igényelt alacsony hőmérsékletet (figyelembe kell venni, hogy a célhőmérsékletnél hidegebbnek kell lenni a hűtőnek, mivel az IC belülről fűt, és a meleget elég gyorsan el kell tudni "szívni"). Így vakon, minden szükséges ismeret nélkül azt mondanám nem. Ha ilyen egyszerű volna, már régen lenne boltban kapható megoldás PC-s igényekre. De hát nincs.
-
Hát ha így van, ez esetben nyilván peltier kuka, de akkor egy olyan kiálló pörgettyűs megoldással, amit linkeltem, elképzelhető hogy szintén megoldható lenne ...
A nick sztm nem fűt iszonyat teljesítményt el ... csak érzékeny a hőmérsékletre ...
Persze lehet hogy egy peltier nélküli, sima vas nem szívna el annyit, amennyit a fagyasztóspray hűtött rajta ... nemtom. :(
-
Az itt ajánlott:
Igen, nézd meg ezzel a csomag IVIEW képpel (http://ep128.hu/Ep_Demo/Prg/Interlace_Demo_3.rar), ha olyan pixelhiba felhõket látsz, mint az itt betett példákon (http://enterpriseforever.com/hardver/pixelhibas_alaplapok-t471.0.html;msg14091#msg14091), akkor 08-04-es a Nick.
iview képekből szeretnék wav -ot gyártani tapir -ral,
milyen sorrendben kell legyenek a file -ok ? :
com
ext
ini
kepek ini -ben rogzitett sorrendben,
vagy valami mas ?
-
milyen sorrendben kell legyenek a file -ok ? :
com
ini
kepek ini -ben rogzitett sorrendben,
-
Hmmm ... mostanra kiprobaltam több verziót is,
megy úgy is simán, hogy:
com
aztan kepek bárhogy
-
Nézek itt egy gépet pixelhibák szempontjából,
töltögetek be iview képeket wav -ból (ez ugye tetemes időket emészt, egy -egy képnek a betöltése),
és ha betöltődött, akkor nem, vagy alig pixelhibásak a képek,
van amelyiknél nem látok mozogni semmit, és van amlyiknél néhol, egy -egy kis területen látok mozgást,
mely mozgások elhalhatnak, vagy beindulhatnak újra azon a területen, mivel egy TFT monitor scart bemenetén nézem, abban sem lehetek biztos, hogy azok egyáltalán pixelhibák, és egy crt monitoron is jelentkeznének mint pixelhiba,
(ha nem pixelhibák, akkor lehet hogy sokadik (kb. 8 körül) ep vásárlásomnál végre sikerült egy pixel hiba menteset kifognom),
de töltés közben van elég nagy mozgás és villódzás.
természetesen nem keverem össze magával a töltődéssel, ami egy függőleges, pixel hibázás sebességéhez képest lassú,
sávos változás a képtartalomban,
egyértelmű, komolyabb területek villódzásáról beszélhetünk a töltés folyamata közben,
és mire betöltődött, addigra eltűnnek a hibák, "megáll" a kép kivéve azt a néhány kis zizit, ami lehet nem is pixelhiba ...
én vagy arra gondolnék, hogy míg töltődik, addig színben nem hasonló árnyalatú pixelek vannak egymás mellett, mikor már betöltődött a kép, akkor ugye hasonló átmeneteket képező pixelek vannak ... és ezzel a pixelhiba összefügghet.
És itt jönne a valódi kérdés:
mikor egy iview kép töltődik befele, az ugye nem lehetséges, hogy a képek lpt -je valami FF szegmensen elhelyezkedő rendszerterületeket jelenít meg, ahol futó kódok változásait látom ?
mert ha nem, hanem egy konstans inicializálatlan területre tölt az iview, akkor az iview képek nem is az igazi megoldások a pixelhibák megjelenítésére,
mert ezen a gépen a képek szinte 100% -osak betöltés után,
hanem valami szintetikus teszt képernyőt kéne megalkotni, ami inkább hajaz az iview képek töltési állapotára, mint a betöltöttre (éles átmenetek kellenek).
-
Most pld. betöltöttem egy olyan iview képet, ahol egy fehér kesztyűs nő egy biliárdasztalon tehénkedik. Mindezt egy sötét háttér előtt ...
És a fehér kesztyűjének a kontúrján erősebb a zizi, mint máshol a képen, teljesen betöltve is ...
Fene tudja, lehet hülyeség a pixelhibatesztelés TFT -n, de ha lesz rendes háttértáram, akkor csinálok egy sokgépes összehasonlítást ... de így wav -val nagyon lassú ...
-
Töltéskor valami szemét lesz ott :-) pl az előző kép maradványa ami nagy valószínűséggel az eltérő képparaméterek miatt nem lesz értelmes. Másrészt interlace képet töltve bőven fogsz olyan részt látni, amikor az egyik félkép még nincs betöltve, helyette szemét van.
Amúgy írtam több mesterséges tesztet is, pl:
10 GRAPHICS ATTRIBUTE
20 SET INK RND(16)
30 PLOT RND(1280),RND(720)
40 GOTO 20
itt az egyre több színes pont között "hunyorgó csillagok" láthatóak hibás Nick-kel. (Olyan mint amikor a csillagos éjjel egyes csillagok a légköri viszonyok miatt hunyorognak.)
-
Itt is raktam be BASIC tesztet. (http://enterpriseforever.com/hardver/pixelhibas-alaplapok/msg16759/#msg16759)
Az első hozzászólásban meg raktam be IVIEW példákat hogy milyen a jó és milyen a hibás.
-
Az első hozzászólásban meg raktam be IVIEW példákat hogy milyen a jó és milyen a hibás.
Igen, hát azon molyolok most. Ezt nézem, amiket betoltál. Később betoltál linket is a képekre egy rar -ban. És ha csak azok számítanak rossz, pixelhibás nick -nek, ami ilyen durván hibázik mint a képpárjaidon, akkor ez az új gépem ez hiba mentes.
De én egyetlen pixel zizegését is nézem, és néha kis zizi itt -ott van ... Ezen a TFT display -en legalábbis ...
Töltéskor pedig még több. De valóban az interlace is beleszólhat ... esetleg ... fene tudja azt mennyire jól kezeli a monitorom ...
-
És ha csak azok számítanak rossz, pixelhibás nick -nek, ami ilyen durván hibázik mint a képpárjaidon
Igen csak azok.
De én egyetlen pixel zizegését is nézem, és néha kis zizi itt -ott van ...
Az szerintem más lesz, vagy interlace, vagy pedig a TFT-nél a konvertálási gond (EP pixel rács nem illeszkedik a TFT pixelrácsára, határon lévő pixelt hol ide, hol oda teszi).
Én jó kis CRT monitoron néztem a hibákat.
-
Szerintem az lesz a végeredmény, hogy a pixel hibázás mint olyan nem egzakt dolog ...
Nem N féle képpen hibás nick létezik, hanem valamilyen mértékben minden nick hibás lesz, és a legtöbb nick (mostanra mindenképp) brutálisan hibás ...
Az egyes tesztek csak rányúlkálnak az általában jelentkező gyenge pontokra, de de mégha azon át is ment egy nick (ráadásul ez ugye sima ránézésre van megítélve) attól a nick még rossz. Legfeljebb olyan kis mértékben, hogy téged nem zavar vagy nem vetted észre. De egy másik szituban meg előjöhet az ő kehessége is.
A legtöbb nick minden sebből vérzik, és van pár amelyik kevésbé kehes. De teljesen jó, amin semilyen teszttel nem lehet kimutatni pixel hibázást ... egyetlen pixeles hibát sem ... olyan talán nincs is egyáltalán ...
-
A legtöbb nick minden sebből vérzik, és van amelyik kevésbé kehes. De teljesen jó, amin semilyen teszttel nem lehet kimutatni pixel hibázást ... egyetlen pixeles sem ... olyan talán nincs is egyáltalán ...
Én már egy csomó olyat láttam, nekem is van egy csomó.
-
Hmmm ... akkor hogy lehet hogy nekem nagyjából 8 -ból ez az első, ami eléggé hajaz a hibamentességre (most leszámítva azt, amit tőled direkt kiválasztva kaptam, meg egy harmadikat, ami ugyan esett szét, de nem igazán pixelhiba jellegűen) ...
Na végülis mindegy ... amíg TFT-n tolom, addig ez a nick pld. jó lesz, mert a kép problémáinak csak kis részéért lehet felelős a pixelhibázás, erősebb a többi faktor ...
Aztán majd ha már CRT -n tolom, akkor pixel hibázás reloaded ... És akkor majd vagy úgy lesz ahogy te gondolod (és eltűnik a maradék bugzás is, mert nem pixelhibákok voltak), vagy úgy ahogy én (és az a pár kis hiba látható lesz, CRT -n is, még sokkal jobban, mert a kép egyébiránt sokkal integráltabb, nyugodtabb, mint TFT -n).
-
Leteszteltem a pöttyözős és a vonalas tesztprogramoddal is az új EP -met, és átment rajtuk, teljesen álló kép lesz rajta.
És most nagyon konkrétan tetten értem azt is, hogy pixelhibásodásszerű jelenséget produkál a tft feldolgozása is, ugyanis megnéztem a legelőször vásárolt nagyon bővített EP -men mindkét basic tesztprogramodat, hogy megnézzem hogy ezen a display -en az milyen (arról tudom, hogy az vadul pixelhibás, már karakteres képen is),
és aztán futattam a csíkozóst az új gépen is, és voálá, a bal oldali legvékonyabb csíknál (szemre) UGYANAZT produkálta, mint a hibás az összes sáv (legvastagabb is) határon,
és gondoltam, háhá, na itt a "kicsit pixelhibázás", de aztán rátoltam egy autohangolást a tft -re, és hopp, kisímult azóta áll mint a cövek ...
tehát a melegedés közben képes elhangolódni időzítésekben valahogy a nick, ami szemre ugyanolyan hibákat okoz tft -n mint az igazi pixelhibák, de ezeket kijavítja ha újra hangolom a tft -t (vagy mi a rákot csinál az auto gomb a tft -n),
de az igazi pixel hibákat azokat nem tudja kijavítani.
A kettő dolog feltehetően egy és ugyanaz. Mikor csak kicsit elhangolódik (gondolom valami idők) ahhoz hozzá tud símulni a tft elektronika, de egy összevissza elhangolódáshoz (amit pixelhibának nevezünk) már nem ... nem ?
-
Ez érdekes!
-
Most lehet hulyseget kerdezek, de a Nickben milyen idozites hangolodhat el? Elvileg orajel alapjan csinal barmit, nem az hangolodik el, amit viszont kivulrol kap?
-
Valami bazi bonyolult áramkör (http://enterprise.iko.hu/schematics/EP64-3~1.jpg) generálja az órajelet, amit még én se értek :oops:
István azt mondta, hogy az egy PLL, amire a Nick maga is hatással van.
Mindenesetre van benne két marék alkatrész, aminek bőven változhat a paramétere melegedés hatására.
Nekem volt olyan gépem ami hidegen azt csinálta, hogy a két félkép külön szinusztáncot járt percekig... végül az L2 tekercs állítgatása szüntette meg a dolgot.
-
Valami bazi bonyolult áramkör (http://enterprise.iko.hu/schematics/EP64-3~1.jpg) generálja az órajelet, amit még én se értek :oops:
István azt mondta, hogy az egy PLL, amire a Nick maga is hatással van.
Valóban, az áramkör lényege, hogy a NICK H/2 (sor frekvencia fele, azaz gyakorlatilag soronként felváltva 0,1,0,1,stb.) és H2REF (PAL frekvencia - 4433618.75 Hz - 568-ad része) kimenetét az U32 XOR kapu összehasonlítja, és az MV2107 típusú diódán (amelynek a kapacitása a feszültségtől függően változik) keresztül vezérli az oszcillátor frekvenciáját. Az áramkör akkor stabil, ha a két frekvencia azonos, és a jelek megfelelő fázisban vannak egymáshoz képest, mert csak ilyenkor lesz megfelelő és fix kitöltési tényezőjű négyszögjel az U32 kimenetén. A kitöltési tényező határozza meg az MV2107-re eső feszültéget, amit az R73/C27 aluláteresztő szűrő simít (-3 dB 159 Hz-en). Ha a feltétel nem teljesül, akkor ez a feszültség "fut", amíg a stabil állapotot megtalálja.
A Wikipedia PLL (http://en.wikipedia.org/wiki/PLL) leírásában megtalálható az egszerű XOR kapus PLL, illetve a PLL áramkörök alapvető elemei:
- fázis detektor (itt az U32 XOR kapu)
- aluláteresztő szűrő (R73/C27)
- feszültségvezérelt oszcillátor (VCO), itt a vezérlést az MV2107 típusú dióda oldja meg
- visszacsatolás, gyakran frekvencia osztóval, ami a NICK-nél a H/2 kimenet (a NICK órajelének 16*57*2 = 1824-ed része), a referencia pedig a H2REF kimenet (a PAL bemenet frekvenciájának 568-ad része). Amikor a H/2 beáll a H2REF-el azonos frekvenciára, akkor a NICK órajelének 4433618.75 / 568 * 1824 = 14237536.27 Hz-nek kell lennie
Mivel az MV2107 kapacitása csak néhány pF tartományban (kb. 20-24 pF között) vezérelhető, ha az oszcillátor frekvenciája nagyon pontatlan, akkor a PLL már nem tud beállni a megfelelő frekvenciára, és ilyenkor "hullámzik" a kép. Ezért állítható az L2 tekercs, mert egyébként az alkatrészek szórása túl nagy lenne. Problémát jelenthet a gépek öregedése is közel 30 év után.
-
Az már mekkora só lenne, ha kiderülne, hogy valójában nem a nick -ek a hibásak, csak a különböző nick -ek különböző módon érzékenyek előbbi alkatrészek elromlására ... :)
És amikor én fagyasztom a nick -et spray -vel, akkor nem a "hibát javítom" a nick -ben, hanem a nick -et teszem érzéketlenebbé előbb említett alkatrészek (mondjuk elöregedésből származó) hibáira ... :)
És bármelyik pixelhibás EP- t meg lehetne javítani előbbi órajel alkatrészek újra cserélésével ...
-
Az igazán pocsék pre-release ISSEU3-as alaplapok pont ebbe az áramkörbe raktak be egy potmétert az R81 helyére amivel lehet állítgatni, hogy HIRES-t tudjon vagy 256 színt...
Meg kéne majd nézni, hogy mennyire egyezik egyébként az áramkör a végleges verzióval.
Az egyébként érdekes kérdés, hogy modern, stabil alkatrészekből összerakva ezt, mi lenne a helyzet.
-
Az egyébként érdekes kérdés, hogy modern, stabil alkatrészekből összerakva ezt, mi lenne a helyzet.
Lehet hogy a jelenlegi és öreg alkatrészek kis zajokat generálnak a jelekbe ... amik a pixelhibák, pixelelcsúszások.
(Amiket én mindíg úgy látom, hogy elcsúszott pixelek csak, mert sosem piros helyett kék jelenik meg, hanem a szomszédos pixelek között rossz a "határ", sőt az is lehet, hogy máshol is rossz, csak ahol a szomszédos pixel is ugyanolyan színű, ott nem lehet észrevenni egy elcsúszást nyilván ... Az persze biztos hogy ez nem egy egesz scanline elcsúszása, scanline- on belül változik, hogy épp hibás vagy jó a pixel átmenet helye a képen ... )
Mi meg itt a szegény nick -et hibáztatjuk ... :)
-
Amiket én mindíg úgy látom, hogy elcsúszott pixelek csak, mert sosem piros helyett kék jelenik meg, hanem a szomszédos pixelek között rossz a "határ", sőt az is lehet, hogy máshol is rossz, csak ahol a szomszédos pixel is ugyanolyan színű, ott nem lehet észrevenni egy elcsúszást nyilván ... Az persze biztos hogy ez nem egy egesz scanline elcsúszása, scanline- on belül változik, hogy épp hibás vagy jó a pixel átmenet helye a képen ...
Ezek alapján úgy tűnik, hogy te nem Nick pixel hibákról beszélsz!!!
A leírásod pont az eltérő felbontású digitális monitorra jelátalakítás hibáira illik.
Viszont amiről mi beszélünk Nick pixel hibaként, ott pont eltérő színek jelennek meg ott ahol nem kéne!
-
Ezek alapján úgy tűnik, hogy te nem Nick pixel hibákról beszélsz!!!
Hát remélem hogy arról ... Lehet hogy nem jól figyeltem meg, de én azt gondolom, hogy pld a te tesztprogramod is miről szól:
vannak fuggőleges egyszínű sávok, melyeknek HATÁRVONALAIN (szemre legalábbis ott látjuk őket csak) jelentkeznek a pixelhibák ... mindegy milyen színűek a sávok, a hibázás a sávhatáron lesz, és vagy a hattérszín nyomul bele a sávba, vagy a sáv a háttérszínbe,
de ha a sávozás plussz háttér X,Y színű, akkor egy pixelhiba sosem lesz Z színű, nem ?
Az megint egy másik dolog, hogy a TFT elhangolódásból is adódik ugyanilyen jelenség, amit a TFT hangolása aztán eltűntet. Az igazi pixelhibákat azonban nem képes eltűntetni (gondolom azért mert nem rendezettek az elcsúszások időben, hanem véletlenszerűek, zaj szerűek.)
Másik segítségem hogy van ugye több gépem, és míg az egyiken ultrabrutális a hibázás jelenség, addig az új gépen eddig csak olyat találtam amit a TFT hangolása eltűntetett, kivéve az iview képeken néha 1-2 pixeles zizegést, amit nem tudtam vele eltűntetni.
De fogok csinálni részletes többgépes scaler -es tesztet is (1080p -nél remélem a legkisebb lesz a TFT "hibagenerálása"), ha lesz SD.
Ha pedig még mindíg kételyeid vannak, hogy egyáltalán pixelhibákról beszélek -e, akkor ezt az egész TFT tesztelést el kell felejteni, és pixelhibás teszteket csak CRT -n érdemes csinálni.
(Mégpedig 15KHz CRT -n, mert scaler -rel már lesz digibe konvertálás. Analóg scaler megoldásról még nem hallottam ...)
-
de ha a sávozás plussz háttér X,Y színű, akkor egy pixelhiba sosem lesz Z színű, nem ?
De, a hibás Nickek esetén pont erről van szó, pl. az Eat-it-Up-ban a lila-fekete falban sárga pixelek jelennek meg.
A te leírásod egyértelműn az EP pixelek nem esnek egybe a digitális monitor pixeleivel hibáról szólnak. Nicknek itt annyi köze van a dologhoz, hogyha nem elég stabil a jel, akkor a határon lévő pixelek hol ide-hol oda esnek.
Szóval szerintem évek óta tök más dologról beszélünk :oops:
-
Szóval szerintem évek óta tök más dologról beszélünk (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)
Bazze ... Áááááááhhhh !!!! :)
Akkor te most azt mondod, hogy bármi amivel itt vergődtem a tft monitoraimon, az valójában nem is pixelhibázás ?
De nem stimmel ez nekem ...
Te írtad azt a 2 basic teszt programodat ... a pöttyözőset és a sávozósat ... nyilván azokat CRT monitoron írtad/használtad ...
Namost nálam a pöttyözős az hunyorog (eltűnedeznek a pixelek), a sávozós pedig a sávhatárokon háttér és sávszín között (nincs harmadik szín) villogtatja a pixeleket,
tehát mindkettő teszt abszolúte pozitív az EGYIK ep -men (szuperbővített),
míg (korábban fejtegetett kis jelenségektől eltekintve) negatív a MASIK (új) ep -men,
mégis azt akarod mondani, hogy amit látok, az valójában (hiába viselkedik a két gép máshogy ugyanazon a TFT monitoron) nem pixelhibázás,
hanem TFT monitor probléma, tehát a 2 basic teszt programod a pozitív gépen false pozitívat ad a TFT monitor miatt ?
Egy másik hibát, nem is EP hibát (nevezzük TFT monitor hibának) mutatnak ki a basic tesztprogramjaid (is) az EGYIK gépemen, nem pedig pixelhibázást ?
-
Újabb "szenzációs" felfedezést tettem pixelhibailag ...
Ugye nálam most az van, hogy a gondosan összerakott álom EP -met félreraktam a mindenféle HID csatoló hardver hekkeléshez,
és egy csupasz alaplapot használok a szereléshez.
Ez a csupasz alaplap persze pixelhibás. Bár Zozo egyre erősködik, hogy ezek nem pixelhibák, de én nem értek vele egyet.
Csak azért mert TFT -n nézem, attól még ezek pixelhibák, és a pixelhibázás a TFT -ken is szépen látszik.
Ezt bizonyítja a mostani felfedezésem is, meg az is, mikor a szuperturbó EP -met fújkodtam fagyasztó spray -vel.
Plussz az is, hogy már "megismerem" ezt a látványt, és analóg monitoron is láttam már a jelenlevő gépeim közül kettőnél minimum.
Azt ugye (már korábbról Zozótól is és) a fagyasztó spray -s tesztek óta tudjuk hogy a pixelhibázás hőmérsékletfüggő.
De Zozó úgy gondolta, hogy a fagyasztott hűtőbordás tesztje után arra következtethetünk, hogy hűtéssel ez nem orvosolható probléma.
Namost a pixelhibáknak arról a fajtájáról beszélek jelenleg, melyek síma BASIC képernyőn is jelentkeznek, és nem kell hozzá semmi ördöngös pixelmód.
Én továbbra is úgy hiszem, hogy vannak gépek melyeknél attól még hogy BASIC -ben nincsenek, ördöngös módokban még lehetnek,
de olyankor mikor BASIC -ben vannak, akkor biztosan van az ördöngös módokban is.
Magyarul ez egy skála, ahogy már régebben is mondtam, minden NICK valamennyire pixelhibás lesz, van ahol ez nem észrevehető sehogy, van aminél csak az IVIEW képeknél okoz problémát, és van ahol már egy síma BASIC képernyőn is.
Namost ez csak a frissítés volt most jön a lényeg:
Régóta azon filózok, hogy meg kéne hűteni a NICK -et, pasztával, hűtőbordával és propellerrel. Ha a hülye spray megoldotta, egy ilyen hűtő szetapnak is meg kell oldania.
Persze ettől megszűnne a némaság, de ez van ... ha rossz a NICK, hát lesz neki hangja ... majd keresek jó halk propellert ...
És miközben most itt nézegettem ezen a raw alaplapon a dolgokat, meg a pixelhibákat, fogdostam a gépet mindenhol, hogy hol mennyire meleg.
Jól összeégettem az ujjam közbe ... A gyári feszstab hűtőborda is marha meleg, NICK is marha meleg, stb ...
Egyszer csak azt nézem, hogy ELTŰNTEK a pixelhibák ... a BASIC képernyőről ... Nem hittem a szememnek ...
De aztán néhány másodperc múlva szép lassan visszajöttek ...
Az ujjam sajgásából szép lassan rájöttem, hogy az UJJAMMAL hűtöm le a NICK -et ... Attól hűl le, hogy megfogom ... :)
Rátappolok, 1-2 másodperc alatt elkezdi égetni az újjam, addigra ELTŰNNEK a pixelhibák ...
Elveszem az ujjam, 3-5 másodperc mire visszajönnek ...
Hát ha az újjam ezt okozza, nehogy már egy KORREKTÜL felrakott, lehetőleg nem miliméteres ragasztórétegre szerelt, pasztázott, borda+venti páros ne hűtse le eléggé ... Nem ?
-
Sőt ez szerintem azt is megmagyarázza, hogy miért kerültek rá a NICK -re a hűtő lemez darabok ...
Azért mert egy nagyon kis hőmérsékletcsökkenés is drámai minőségváltozást tud jelenteni ...
Azóta kikísérleteztem, hogy 2 ujjat felváltva használva lent tudom tartani a NICK hömérsékletét úgy hogy ne legyenek a BASIC képernyőn pixelhibák,
és az ujjaim se égjenek szét ...
Ha nem "hűtöm" a NICK -et az ujjaimmal, akkor valahogy magába akkumulál több meleget,
mikor először rányúlok, akkor jóval melegebb, de aztán 2-3 másodpercenként váltogatva 2 ujjamat,
már nem fájdalmas, és pixelhiba sincs a BASIC képernyőn ... :)
-
Na jó, az mindenképp hülyeség, hogy amelyik NICK -nél van a BASIC képernyőn tapasztalt (általam szintén pixelhibának hívott) jelenség,
az az IVIEW képeken is hibázik.
Végignéztem 5 lemeznyi IVIEW képet, meg még a BLUE.COM, ESZAKIF.COM, GEMESKUT.COM triót is,
és mindegyik áll mint a cövek, pixel sem rezdül.
(Ennek az atomrezdületlenséghez persze nyilván köze van a deinterlace -es scaler -nek is, de a pixelhibázás azon is átjönne ...)
-
Tehát olyan ez, mintha két hasonló, de azért különböző jelenség lenne,
és egy NICK vagy produkálja egyiket vagy másikat, vagy nem ...
Az biztos, hogy múltkor villogó IVIEW képeket "merevítettem" ki a spray -jel (ez volt a szuperturbó gépem, amit Zozó is ismer),
most pedig egy BASIC képernyőn (és Zozó függőleges sávos teszter programjával is jelentkezik ezen a gépen, el ne felejtsem!) jelentkező pixelhibásságot tudok eltüntetni,
simán csak "kézrátétellel" ... :)
Mert a hőmérsékletre mindkét jelenség érzékeny.
-
Mondjuk azt nem értem, miért nem valami frankó hővezető anyaggal applikálták fel a hűtőlemezeket, eredetileg ...
-
Mondjuk azt nem értem, miért nem valami frankó hővezető anyaggal applikálták fel a hűtőlemezeket, eredetileg ...
Szerintem akkor még fel se találták :-) kb az AMD Athlon prociktól kezdve lett ez az egész pasztázás érdekes (azok sültek ropogósra, ha picit is rossz volt a hőelvezetés).
A nagy baj, hogy nincsenek rögzítő lukak rendes bordához, így mindenképpen ragasztani kell...
Amúgy van egy csomó olyan alaplapom, ami a lemez nélkül is remekül el van.
-
Hopp ... így belegondolva viszont akkor az "elméletem" a pixelhibázás "erősségéről", "fokozatairól" lehet mégis helyes, csak épp fordítva van a reláció ...
Ugyanis a szuperturbó gépem, mely valós IVIEW képen pixelhibás dolog, az hibás BASIC képernyőn is ...
Tehát nekem van olyan gépem, ami csak a BASIC képernyőn pixelhibás, és van olyan ami IVIEW+BASIC képen pixelhibás ...
Ebből az következhetne (persze nagyobb minta kéne), hogy a "kevésbé" hibás NICK -ek elkezdenek hibázni a BASIC képernyőn,
a durván pixelhibás NICK -ek meg már az IVIEW képernyőn is tolják ...
Ezt az elméletet az tudja kilőni, ha találunk egy gépet, ami IVIEW képernyőn pixelhibás, de BASIC képen meg nem ... de én most nem tudok ilyenről.
-
Amúgy van egy csomó olyan alaplapom, ami a lemez nélkül is remekül el van.
Ja, a pixelhiba mentes lapjaim között nekem is van olyan. Ezért mondom, hogy ez egy fokozat ... valami gyártástechnológiai és/vagy korból fakadó dolog ...
Mint ahogy különböző frekiken, feszültségeknél és hőmérsékleten hibáznak a mai chip -ek is ... szórásban ... egyik jobban sikerül, másik kevésbé ...
-
Mondjuk jó lenne felvételt látni arról, hogy te mit hívsz BASIC pixelhibának, plusz megnézni ugyanazt a gépet CRT monitoron is.
-
Mondjuk jó lenne felvételt látni arról, hogy te mit hívsz BASIC pixelhibának, plusz megnézni ugyanazt a gépet CRT monitoron is.
Te is láttál már karakteres képernyőn pixelhibázást, jelentkezik BASIC -ban, WP -ben, ASMON -ban, minden karakteres képernyőn ...
Ez MEGEGYEZIK a te függőleges sávozós pixelhiba teszter programod által kimutatott hibával!
Tehát amit te írtál progit, pixelhibák kimutatására, az teljesen pozitív ezen a gépen, amelyik a karakters képernyőn is pixelhibás,
de IVIEW képeken nem,
valamint az ujjammal le tudom hűteni annyira, hogy elmúljon a pixel villódzas a határokon.
(Nem, nem a TFT miatt van. :))
Onnan tudom, hogy láttam ugyanezeket a hibákat CRT monitoron, két lapomnál is. A karamteres képernyős pixelhibákat. Mikor a Karakter és háttér, vagy a te programodnál a sávhatárokon van a pixelek villogása.
-
A nagy baj, hogy nincsenek rögzítő lukak rendes bordához, így mindenképpen ragasztani kell...
Én biztosan nem fogom ragasztani,
elugrok a bővítőimért hozzád a jövő hét utáni héten,
beszerelem az egyiket ebbe a lapba, így felszabadul egy csomó hely mindhárom dimenzióban,
plussz az eredeti panelt tartó fehér műanyag távtartók kiszedése után lesznek furatok is az alaplapon,
amire lehet építkezni ...
Szerintem a legnagyobb ellenség az a különböző vastagságú és kiterjedésű ragasztóréteg ami MÁR sajnos RAJTA VAN a NICK -eken ...
Valszeg azokat roncsolás nélkül leszedni nehéz lenne ...
De remélem valami keményebb paszta kiegyenlíti majd, és ezen a NICK -en pld. csak úgy a felszín 1/3 -án van maradék ragasztó,
és nem akadályozza meg majd a jó hőközlést ... (ha az ujjammal jó volt, csak jó lesz a pasztával is ... :))
-
elugrok a bővítőimért hozzád a jövő hét utáni héten,
Akkor hozzál el egy ilyen gépet, megnézzük CRT-n.
plussz az eredeti panelt tartó fehér műanyag távtartók kiszedése után lesznek furatok is az alaplapon,
amire lehet építkezni ...
Azokkal mondjuk lennének terveim. Z180-dualportsram-megagigaturbo panel :-)
Valszeg azokat roncsolás nélkül leszedni nehéz lenne ...
Simán lepattog, ha elkezded vakargatni. Csak vigyáz a szemedre bazi sz** érzés ha egy ilyen ragasztó szilánk belemegy :oops:
-
Akkor hozzál el egy ilyen gépet, megnézzük CRT-n.
Oké, elviszem a szuperturbót is, amit ismersz,
meg ezt a raw lapot is, amit még nem,
azt sajnos nem tudom megmondani melyik kettő volt már CRT monitoron (karakteres pixelhibázva),
mindet meg nem cipelem el, de 99% hogy az egyik a szuperturbó volt, mert azt vettem CRT monitorral együtt (amiről aztán kiderült hogy csak 3 színt tud, vagy hányat ... :)).
A másik egy commodore RGB monitoron volt, de azt nem fogom tudni kideríteni hogy melyik, ez a raw alaplap is teljesen ugyanazt csinálja, látom rajta.
Azt viszont nem értem a te szívednek ez miért kedves, hisz láttál már karakteres képen pixelhibát ... nekem vagy öt gépem olyan,
te meg még teszter progit is írtál hozzá, ha nem is karakteres képre.
Azokkal mondjuk lennének terveim. Z180-dualportsram-megagigaturbo panel :-)
Hát jó, ha majd én is olyat akarok szerelni, akkor azt majd egy pixelhiba mentes lapomra fogom szerelni, és ott szabad lesz a furat ...
Simán lepattog, ha elkezded vakargatni.
Ja ... gondolom NICK darabkákkal együtt ... :)
-
Azt viszont nem értem a te szívednek ez miért kedves, hisz láttál már karakteres képen pixelhibát ... nekem vagy öt gépem olyan,
te meg még teszter progit is írtál hozzá, ha nem is karakteres képre.
Azért, hogy végre tisztázzuk, hogy ki miről beszél pixelhiba címszóval :-)
Ja ... gondolom NICK darabkákkal együtt ... :)
Dehogy. Én legalább már egy féltucatról levakartam.
-
Azért, hogy végre tisztázzuk, hogy ki miről beszél pixelhiba címszóval :-)
Hány év után ... ? :) !
Dehogy. Én legalább már egy féltucatról levakartam.
Nem nagyon bátorodtam fel ...
-
Z80System, legalább egy képet vagy videót töltenél fel a "Nick pixelhibáról", így megtudnánk, a Nick hibája-e vagy a monitoré, és nem kéne 20 hosszabb-rövidebb hozzászólásból órákon át megpróbálni kihámozni a lényeget!
Egy idő után most kivételesen benéztem a hardver topikba, de lehet, inkább nem kellett volna, emészthetetlenül sok, ami itt van.
-
Z80System, legalább egy képet vagy videót töltenél fel a "Nick pixelhibáról", így megtudnánk, a Nick hibája-e vagy a monitoré, és nem kéne 20 hosszabb-rövidebb hozzászólásból órákon át megpróbálni kihámozni a lényeget!
Egy idő után most kivételesen benéztem a hardver topikba, de lehet, inkább nem kellett volna, emészthetetlenül sok, ami itt van.
éveken és oldalak ezrein keresztül kell elővezetni hogy az EP sz**
:)
-
és nem kéne 20 hosszabb-rövidebb hozzászólásból órákon át megpróbálni kihámozni a lényeget!
Egy idő után most kivételesen benéztem a hardver topikba, de lehet, inkább nem kellett volna, emészthetetlenül sok, ami itt van.
Mélyen átérzem a problémád. Bizony az a jó, mikor nem történik semmi. És az is csak egy sorban. Vagy inkább fél sorban. Röviden. Kontrollálhatóan. Érthetően. A sok betű megárt. A sok részlet meg csak összezavar. Az ember gyanútlanul benéz a hardver topikba, oszt kész a baj ... Szinte orrbavágja az embert a millió betű ... ez szörnyű ... és akkor ott hámozni kell ... ahelyett, hogy valaki három szóban leírná a tényeket ... ehelyett csak az örök polemizálás, meg töprenkedés ... valaki meg nem átallja EP -s élményeit regényes formában tálalni ... ez borzasztó ... az élet szörnyű ... állandóan csak próbálja az embert ...
Z80System, legalább egy képet vagy videót töltenél fel a "Nick pixelhibáról", így megtudnánk, a Nick hibája-e vagy a monitoré,
Eeeegen ... lehet filmet is fogok róla forgatni ... de ha úgy, akkor te úgysem nézed meg, mert 5 órás nagyjátékfilm lesz ... hát ki tud annyit végignézni ... csak ott történnének a dolgok, a mindenféle sok részletek, meg hámozások ... a végén még az is lehet, hogy ki se futna sehova a dolog ... mint egy szutyok francia film ... se kóla, se popcorn, csak a sok hámozások ... oszt vége felirat ...
-
se kóla, se popcorn
Azt a büfében kell kérni :-D
-
Azért, hogy végre tisztázzuk, hogy ki miről beszél pixelhiba címszóval
Most kezd csak leesni,
hogy lehet hogy te arra akarsz itt utalni,
hogy valójában te NEM LÁTTÁL még karakteres képernyőn pixelhibázást ?
Tehát te pixelhibának az IVIEW képeken (és egyéb grafikus játékokról is tettél fel videót még a topik elején)
jelentkező dolgokat nevezed kizárólag,
a tesztprogramjaid is grafikus képernyőkön működnek, függőleges sávos és a pixelezős is,
de síma karakteres képernyőn (pld. BASIC,WP,ASMON) te MÉG NEM LÁTTÁL az előbbi pixelhibázásokhoz hasonló (sztm. ugyanolyan) jelenséget ?
Magyarul én valami teljesen újat fogok neked mutatni ?
-
Na tessék, forgattam filmet.
A karakterek belső éleinél figyelhető meg a pixelhiba jelenség,
mikor a fekete háttérből kéne átmenjen a karakter színbe a jel,
akkor ilyen ide-oda ugrálás alakul ki.
Ez szerintem maga a pixelhiba jelenség, egy ilyen időbeli bizonytalansága bizonyos színátmeneteknek. Vibrálás, villogás.
A valóságban persze a kép sokkal élesebb, a kamera felbontása és fókusza teszi ilyen maszatossá.
Tehát a valóságban rendesen lehet látni, hogy ez nem egyfajta hullámzás, hanem az, hogy a pixelek határa vízszintesen kicsit előre-hátra ugrál ...
És ha hűtöm a NICK -et (a felvett konkrét alaplapnál akár az ujjammal), akkor ez a jelenség megszűnik, és a vibráló élek is ugyanolyan símák lesznek,
mint az összes többi, jelenleg is síma éle (színátmenete) a karaktereknek.
És ez van CRT monitoron is.
És ezen az alaplapon az IVIEW képek teljesen símák, semmi vibrálás nincs rajtuk.
De olyan alaplapon (pld. a szuperturbó gépem) amin az IVIEW képek is így bugzanak (pixelhibásak), azon is kisímul a kép, ha meghűtöm a NICK -et.
-
hm ez érdekes, ismerős ez nekem, de nem tudom honnan. nem vagyok benne biztos, hogy ep-ről
-
Na tessék, forgattam filmet.
No, azért megnéztem a filmedet, ha nem is popcorn és cola mellett, de egy cappuccino mellett.
Szerintem olyan, mintha az EP képernyőt bedobtuk volna egy üstbe a készülő levesbe és ott fortyogna. Néha meg is kéne keverni talán. A végén meg megenni közösen, azt a sok betűt a képernyőről. Az garantáltan olyan lenne, mintha falnánk a betűket! :D Betűleves forever by Z80System
-
lehet hogy hülyeséget mondok, de kezd derengeni egy régi emlék
ilyen zizegést ep-n láttam, de 80 karakteres módban, és csak egy bizonyos monitoron vagy tévén. és/vagy egy bizonyos kimenetnél (a korszak vége felé lett ilyen scart(???) kimenetes izém vagy mi, valakitől rendeltem).
én évekig junoszton használtam az ep-t, aztán lett egy zöld monitorom, később kis színes tévém (katonaság alatti keresetemből vettem haha).
asszem a zöld monitoron volt, amire az a valakitől rendelt kimenettel kötöttem az ep-t
mindezek homályos emlékek, szóval lehet hogy épp hogy hátráltatják a rejtély megoldását :)
-
Annyi biztos, hogy ez a zizi más dolog, mint amiről én beszélek :-)
-
Annyi biztos, hogy ez a zizi más dolog, mint amiről én beszélek :-)
Csak nem értem, hogy miért vagy ebben olyan biztos ...
Nézd meg a te IVIEW (és egyéb játékokról készült) videóidat ... azok is "éppígy" ziziznek ... ennek a topiknak az elején vannak, te raktad fel őket ...
A különbség csak annyi, hogy milyen színátmenetek, mekkora felületen ziziznek ...
És mindkét jelenség NICK hőmérséklet függő ...
-
Annyi biztos, hogy ez a zizi más dolog, mint amiről én beszélek :-)
Valóban, ez véletlenszerű pixel időzítési hibának (jitter) tűnik, ami nekem is van, a "valódi" pixel hiba viszont hibás adatot jelenít meg. Én a "zizit" valamennyire csökkenteni tudtam a tápfeszültség (+5V) szűrésével a video kimenet közelében az egyik IC-re 100 nF-os kondenzátort forrasztva, de így is látható maradt. Egyébként hasonló jelenséget régebben PC-n is láttam a VGA kimenetet használva LCD monitorral, és csak az automata beállítás gyakori használatával lehetett átmenetileg javítani.
Az is problémát okozhat egyes TV-knél, hogy az EP vízszintes frekvenciája nem a szabványos 15625 Hz, hanem 15611.33 Hz. Nálam ez egy CX2388x alapú PC-s TV kártyán a sorok kis mértékű, de zavaró vízszintes remegését eredményezte, és hibás szín dekódolás miatt "havazást" a kép alsó részén; a kártyát a tényleges frekvenciára beállítva megszűntek ezek a hibák, de a pixel jitter nem.
-
Valóban, ez véletlenszerű pixel időzítési hibának (jitter) tűnik, ami nekem is van, a "valódi" pixel hiba viszont hibás adatot jelenít meg.
Jó, lehet hogy ez nem pixel hiba, és lehet hogy ez egy másik hiba, ha annyira mondjátok.
De MINDKETTŐ elmúlik a NICK hűtésével. Ez az általad jitter -nek nevezett dolog már annyi hűtéstől is elmúlik, amit az ujjammal tudok a NICK -en hűteni ...
Nem kell semmilyen kondis mágia ...
-
Egyébként hasonló jelenséget régebben PC-n is láttam a VGA kimenetet használva LCD monitorral, és csak az automata beállítás gyakori használatával lehetett átmenetileg javítani.
Nekem is innen ismerős a dolog.
Én arra tippelek, hogy lehet, hogy analógban is látszik, csak nem túl észrevehető, míg digitálisban, ahol amúgy se esik egybe az EP és a monitor pixelrácsa, a határon lévő pixelek pici eltolódása már azt eredményezi, hogy hol ide - hol oda rakja a digitalizáló áramkör.
-
De MINDKETTŐ elmúlik a NICK hűtésével. Ez az általad jitter -nek nevezett dolog már annyi hűtéstől is elmúlik, amit az ujjammal tudok a NICK -en hűteni ...
Az általam emlegetett, 08-04-es Nickek hibája a kb -10 fokos bordától sem múlt el teljesen.
-
Én a "zizit" valamennyire csökkenteni tudtam
Hát ... amíg ilyen van a képen, addig teljesen élvezhetetlen a kép (szerintem) ... Álló kép az áll, mereven, mint a cövek ...
Ilyen zizivel halál ... ha csak ilyen lenne, utálnék ránézni ...
És 8 alaplapomból 5 ilyet produkál ...
De mint mondtam, NICK HŰTÉSRE TELJESEN MEGSZŰNIK.
-
Én arra tippelek, hogy lehet, hogy analógban is látszik, csak nem túl észrevehető, míg digitálisban, ahol amúgy se esik egybe az EP és a monitor pixelrácsa, a határon lévő pixelek pici eltolódása már azt eredményezi, hogy hol ide - hol oda rakja a digitalizáló áramkör.
Teljesen tisztán látszik ez a zizi egy commodore CRT monitoron. Ugyanolyan tisztán, mint a TFT -n.
Hétvégen ha lesz egy kis vér a pucámban, el is hozom a commodore CRT monitort otthonról ...
-
Nem kell semmilyen kondis mágia ...
Ha kevesebb a zavaró tényező, az mindig csak jó dolog!
-
Az általam emlegetett, 08-04-es Nickek hibája a kb -10 fokos bordától sem múlt el teljesen.
Na én meg ezt nem akarom elhinni, amíg nem látom ...
Esetleg még az lehet, hogy tényleg az van, hogy mikor én a szuperturbó gépemen az IVIEW képek "pixelhibáit javítottam" fagyasztó spray -vel,
akkor is csak egy ilyen "jitter" jelenséget javítottam ...
Persze attól még igaz, hogy van olyan alaplap ami csak karakteres képen jitter -el, míg másik alaplap IVIEW képeken is ...
(Persze csak ha az IVIEW -s jelenségem is jitter, és valójában én még csak nem is találkoztam pixel hibával eddig ... :))
-
Teljesen tisztán látszik ez a zizi egy commodore CRT monitoron. Ugyanolyan tisztán, mint a TFT -n.
Ha a hekkelt színes kompozit kimeneten nézed az már majdnem 100% -ban elfedi egyébként,
ha meg RF -en, az 100% -ban elfedi.
Mindegy milyen monitoron.
De ha RGB -ben nézed, jó monitorral, aminek a fókusza nem tenyérnyi nagyságú, akkor 8 gépből 5 ilyen.
Ezért is vergődtem én annyit, mert évekig nem is volt olyan gépem, ami nem csinálja ezt.
-
És a hűtéses megjavulásra meg csak a minap jöttem rá ... hogy elég a 100% -os megszűnéséhez (karakteres képernyős jitter -ről beszélek, ami a videón van) annyi, hogy rátappolok a NICK -re az ujjammal ...
-
És biztos, hogy hűtöd, nem pedig zavarszűrsz? Gondolj a thereminre, ami az alapján működik, hogy az ember keze megváltoztatja az elektromágneses erőteret.
-
És biztos, hogy hűtöd, nem pedig zavarszűrsz? Gondolj a thereminre, ami az alapján működik, hogy az ember keze megváltoztatja az elektromágneses erőteret.
Gondolok. Sőt szerintem írtam is. Mikor ráteszem az ujjam, másodpercekig hűtögetnem kell (1-3 másodperc) mire eltűnik, és miután levettem róla a kezem, 3-10 másodpercig még jó, és fokozatosan térnek vissza a zizik ... pont mint bekapcsolás után is. Ez melegedéssel összefüggő dolog.
-
na de ha az ujjad ilyen jól lehűti, akkor ki lehetne próbálni egy egyszerű hűtőborda-szerű valamivel is, egy darab fém pl
-
Ezért is vergődtem én annyit, mert évekig nem is volt olyan gépem, ami nem csinálja ezt.
A legelső alaplapom, ami nem csinálta ezt a jitter -t, azt tőled kaptam Zozo ...
Azóta ugyan lett még kettő, ami jó, de az összes többi ilyen jitter -es ...
Én először nem is neveztem pixelhibának, csak neked panaszkodtam erre, hogy így van ez a zizi,
és akkor került elő a pixelhibák témaköre -> ekkor kértem tőled pixelhiba mentes alaplapot,
és mikor adtál egy pixelhiba menteset, akkor az jitter mentes is volt ... :)
Aztán később lett még kettő, melyek szintén jitter mentesek,
most meg észrevettem, hogy ezt a jittert egy egész kis NICK -re rátappolásos hűtés megszűnteti ...
(annál a lapnál, amin szerelek ...)
-
Ha kevesebb a zavaró tényező, az mindig csak jó dolog!
Azt korábban már említette valaki, hogy a tápfeszültség kis mértékű emelése javít a problémán, aminek lehet köze ahhoz, hogy a jobb szűrés (kondenzátor) is eredményes valamennyire.
-
Na, vasárnaptól lesz egy Commodore 1085S D2 monitorom is kéznél ...
Remélem jobb a kép egy 1085S -en mint amire én emlekszem, mert én egy eléggé gyér fókuszú, maszatos valamire emlékszem (ráadásul a jitter hibákkal), de az biztos hogy a scaler és TFT monitor tökéletlenségeiből nem fog birtokolni semmit ...
Ráadásul még pucolnom is kell, mert bár nincs agyonütve, de azért nem is tiszta ... és sztm. fehéríteni sem ártana ...
-
Vicces, hogy az ember mennyire képes kuporogni a vagyon melett ...
Évek óta itt punnyad ez a szerencsétlen monitor a szekrényem tetején, de egyrészt már azt is elfelejtettem hogy pontosan milyen típus is, másrészt valamiért úgy emlékeztem, hogy egy ilyen régi rossz TV minőségét hozta ez a példány ...
Lehet szerintetek egy ilyen monitor fókuszán tvíkelni ? Erősebben fókuszálni az elektronsugarat, vagy ilyesmi ...
-
Na, elcipeltem a Commodore 1085S-D2 -t ... mostantól azt is belepasszírozom ide a használható konfig -ba ... vagy pedig a nyakamba vettem még egy javítandó vackot ... nézőpont kérdése ... kérdés hogy hol találok még olyan szervízt, aki belenéz egy CRT monitorba, neadjisten még javítani is képes rajta ...
Naszó visszatérva a pixelhiba témakörre ... amiről akkor kiderült (amíg mást nem derítünk ki ...) hogy valójában én egy másik hibát is pixelhibának hívtam, sőt leginkább azt hívtam annak, nem az eredeti pixelhibát ...
Amit én hívtam pixelhibának (videó feljebb) azt most akkor IstvanV után szabadon jitter hibának fogom hívni. Vagy jitter -nek.
Ez a jittering jelenség az, ami sok gépet érint, nem a valódi pixelhiba. Ez az ami nekem 8 gépből 5- nél van, nem a pixelhibának nevezett jelenség.
Namost a 1085S -sen is simán látszik a jitter hiba, de valóban sokkal kevésbé zavaró (attól még engem zavar így is, fujj- fujj, le vele, tűnjön el, pusztuljon) az összhatás ... legalábbis EZEN a CRT monitoron. És szerintem az ennek a monitornak a hibája. Vagy ennek a példánynak, vagy ennek a típusnak, még nem tudom. Már úgy értem, hogy az ennek a monitornak a hibája, hogy a jitter bug nem látszik rendesen, hogy jóval kevésbé zavaró, mint a TFT -n.
Ugyanis szerintem azért látszik kevésbé, mert az egész kép SOKKAL ROSSZABB minőségű, mint a TFT monitoron ...
Olyan az egész kép, mintha a monitor felbontása nagyjából összemérhető lenne az EP felbontásával ... vagyis nagyon kicsi, harmat gyönge, ultra gyík ...
Ahogy így nézem, szabadszemmel, közelről, konkrétan meg tudom számolni a világító kis pöttyöket a képen ... azt is látom hogy egy EP pixel, olyan 2X2, 3X3 CRT képpontból állhat össze, attól függően hogy jön ki a dolog. És persze a CRT képpont határok és az EP pixel (videójel) határok abszolút nem esnek egybe, teljesen fínoman lehet kézzel szabályozni hogy X,Y kiterjedésben mekkora helyet fedjen le az EP képe a monitoron, és ennek a beállított méretnek (és pozíciónak is) a függvényében áll be hogy egy- egy EP pixel mely CRT képpontokat fedi le, ráadásul osztva, egy ilyen CRT képpont nem feltétlen teljes egészében tartozik egy EP pixelhez, lehet hogy csak egy része tartozik hozzá, másik része meg már a mellette lévő EP pixelhez.
Namost erre a gyökér felbontásra kombinálódik rá valami olyan jelenség, mintha a betűknek amolyan szellemképe, utógyújtása, árnyéka lenne ...
Ez az utógyújtás olyan durva, hogy ha bekapcsolok egy set border 5 -t (magenta szerű szín), akkor a kép bal oldalán és tetején KÉK, míg jobb oldalán és alján PIROS sáv lesz a border és az aktív kép fekete háttérszínének találkozásakor.
Ráadásul míg az alsó, felső az viszonylag vékony, addig az oldalsóak azok 2-3 CRT képpont szélességűek (kb 1 EP pixel az már!) ...
Namost ilyen eleve homályos, vacak képen egy olyan zizi jelenség, mint a jitter persze hogy kevésbé látszik, legtöbb helyen nem is a fekete háttér és a karakterszín váltakozik, hanem csak hunyorog egy sötétebb színre a jittering -gel zavart színátmenet.
Viszont azt továbbra is tudjuk, hogy bár IstvanV mindenféle egyéb praktikákkal is tudta csillapítani a jittering -et, attól még a NICK hűtése azt meg is szűnteti.
Most ki fogom próbálni a szuperturbó gépen, hogy azon milyen jelenséget orvosoltam én a fagyasztó spray -vel az IVIEW képeken ...
-
Ezt a Commodore monitort milyen bemenettel használod ? Ha nem RGB, hanem RF, kompozit, vagy S-video (http://enterpriseforever.com/hardver/s-video-kimenet/msg34189/#msg34189), akkor normális, ha a színek nem teljesen élesek, amint az az S-video screenshoton is látható. A PAL színsegédvivő sávszélessége ugyanis meglehetősen korlátozott, ami jelentős vízszintes elmosódást eredményez, függőlegesen pedig azért nem éles a kép, mert a színeket az előző sorral átlagolja (így a soronként változó fázis - aminek a PAL a rövidítése - kioltja az esetleges színeltolódást).
Azonban ha az RGB bemenet sem éles, vagy a fekete-fehér kép is életlen, az már probléma. De az is lehet, hogy a monitor az RGB-t is kompozit videóra konvertálja, ha elsősorban C64-hez, vagy hasonló gépekhez készült, amelyeknek nincs RGB kimenete.
-
Hmmm ... megpróbálok utánanézni, de elvben ez egy RGB bemenettel rendelkező monitor (nem tudom hogy belül tönkreteszik -e, de ha kiderül a 1085S -ről, hogy belül elrontják az RGB -t először, mielőtt a katódsugárcsőre kerül a jel, akkor szép nagyot fog szólni amikor talajt fog a sokadik emeletről ... :)), amit RGB kimeneten keresztül használok ...
Mondjuk a kábelt nem én csináltam, és történetesen ezen a gépen pont van hekkelt kompozit videó, de azt én hekkeltem, és aki a kábelt csinálta nem tudhatta, hogy én hova vezetem ki a hekkelt színes kompozitot ... Nem mellesleg talan a D-Sub 9-en (ami van ezen a monitoron RGB bemenetnek) nincs is kompozit jel ...
-
Olyan az egész kép, mintha a monitor felbontása nagyjából összemérhető lenne az EP felbontásával ... vagyis nagyon kicsi, harmat gyönge, ultra gyík ...
"The 1085(S) is a cost-reduced version of the 1084, with lower resolution (.52 mm dot pitch)"
-
"The 1085(S) is a cost-reduced version of the 1084, with lower resolution (.52 mm dot pitch)"
Igen, ezt én is olvastam már sokszor, de a másiknak meg max 10-20% -kal jobb a felbontása, szóval ez nem egy nagyságrendi csökkentés volt ...
-
Na, ki is próbáltam a szuperturbó gépet,
és igen (majdnem) minden az amit vártam,
vagyis hogy ez a lap meg igazából pixelhibás, IVIEW képeken (a blue.com -ot néztem konkrétan) a szép sötétes kékes képben ilyen villogó fényes és összevissza színes pixelek jelennek meg.
A furcsa csak az, hogy ezen az alapon meg nincs jitter (semelyik jelenlegi monitoron nézve), itt inkább (jelenlegi display konfigokkal) mintha ilyen teljes soros elcsúszkálás lenne ritkán, nagyon rövid ideig ...
De azt újra ellenőriztem (CRT monitoron most), hogy biztosan ez is (már a tényleges pixelhibázás) eltüntethető hűtéssel. Csak ehhez komoly hűtés kell, jó sokáig fagyasztom a NICK -et fagyasztó spray -vel, mire eltűnnek az IVIEW képekről a pixelhibák. De eltűnnek, és csak a melegedéssel jönnek vissza.
Kézi (az ujjammal) hűtés semmilyen hatást nem gyakorol rájuk, ott villódzanának attól napestig. Csak a hosszú fagyasztóspray -től tűnnek el.
A jitter -es cucc viszont pikkpakk eltűnik kézzel hűtve is. CRT monitorról is.
Ámen.
-
Ja, egyébként matattam a cuccal még tegnap, és eltűntek két oldalról a vastagabb elszíneződéses sávok ...
Mondjuk tekergettem a monitor potijait, meg széthúztam- összedugtam, meg ilyenek, de mióta eltűntek azóta is sokat matattam ezekkel, és nem jöttek vissza a sávok ...
Úgyhogy az egyetlen magyarazat amit értelmesnek látok, hogy akkor tűntek el, mikor kiforrasztottam a hekkelt színes kompozit kimenet fokozatát ... gondoltam hátha mégis azt használja a kábel (azóta a kábelt is néztem, helyes RGB bekötés az EP oldalon ... a monitort még mindíg nem néztem ... :)), én meg úgysem használok kompozitot sehova, és kiforrasztottam.
Szóval 99%, hogy ettől tűnt el a jelenség, úgyhogy warning, warning, akinek RGB -ben nem tökéletes a képe, és van hekkelt kompozit fokozata, nézze meg nélküle ...
Most mind a négy oldalon ilyen nagyon vékony elszíneződés van csak, ha magentára állítom a keretet. Ez már olyan vékony, hogy körülbelül a CRT képpont méret ... szóval símán lehet az akár, hogy pld. fizikailag egymás mellett vannak a CRT RGB képpont komponensek, és nem pontosan egy RGB határon hanem mondjuk a G -nél vált a border ... ha érthető így ...
-
Újabb érdekesség:
Van ugye a jelenlegi, alaplap formájában létező szerelős "gépem", mely IVIEW képeken nem hibázik, de jitter jelenség van rajta,
mely viszont ujjal hűtögetve a NICK -et teljesen elmúlik.
Legalábbis ami a legtöbb jittering jelenséget illeti ...
Ugyanis a sorcery+ -ban pld. ami egy kék alapra rajzol a jobb alsó sarokba egy alapvetően sárgás könyvet és szintén jittering jelenségeket produkál, az nem múlik el az ujjal hűtésre ... porkodijjó ...
-
Mégiscsak ki kéne próbálni a kondis megoldást :-)
Arra is gondoltam, hogy a 74LS244-est kicserélni HCT-sre, az elvileg kevésbé terheli le a Nick kimenetét.
-
Mégiscsak ki kéne próbálni a kondis megoldást :-)
Arra is gondoltam, hogy a 74LS244-est kicserélni HCT-sre, az elvileg kevésbé terheli le a Nick kimenetét.
Hát ... a hűtés ezzel prioritásban hátrébb szorult most nálam is, mert úgy tűnik (legalábbis ujjal...) nem hűl vissza annyira, hogy minden jitter elillanjon ...
Szóval fogok kísérleteket tenni ilyen kondikkal, tápokkal is ... aztán az eredménytől függően megyek majd tovább a hűtéssel vagy nem ...
De attól még a ramok továbbra is kellenének, SymbOS miatt ... ha nem jön össze a köv 1-2 hétben egy szeánszosabb nap, akkor nem kell feltétlen különösebbet szeánszoljunk,
de a ramokért elugranék vmikor külön is ... láttad az üzeneteket, nem mentek át, vagy még vajúdsz a mikoron ?
-
Mikoron rágodtam :oops:
De végülis a jitter dolog eléggé ki lett tárgyalva, videózva, azt már nem kell külön nézegetni.
A bővítéseket bevittem, azért jöhetsz. Te meg hozol kék joy kupakot :-)
-
Kupak ? Ráadásul kéééék ? Hát nekem olyan nincs is ... hol találok én olyat ... :)
Na majd megnézem valami mosogatószeres flakon kupakját ... hátha kék lesz ... :)
-
Kipróbáltam, semmi mást nem csinálok, csak az eredeti hűtést (fémlemez darabot) visszarakom a NICK -re,
akkor is elmúlnak a jitter jelenségek a BASIC -ről, meg a legtöbb helyről ... :)
(Sorcery könyvéről, vagy az EGI teljes képernyőjéről persze nem tűnnek el ...)
Tehát nem pasztáztam, vagy semmi, csak ráraktam a NICK -re, és nem mozgatom az alaplapot ...
Pedig még kis ragasztó is van a NICK -en, így rendesen fel sem fekszik ...
-
Elég jól meg lehetne oldani télen a fűtést úgy is, ha az összes létező számítógép-alkatrész, köztük a Nick hőjét is összegyűjtenék egy helyre, direkt ilyen célra kijelölt "radiátorra". De hát inkább telerakják a gépeket hűtőbordákkal, ventilátorokkal, ahelyett, hogy azt a sok hőt összegyűjtenék egy helyre és valami hasznosat csinálnának vele.
Télen, amikor egyes szobák amúgy is kissé hidegek, kicsit furcsa, hogy még hűtik is a számítógép-alkatrészeket.
-
Sima cauldron -nak a title/credits/stb. képernyői mennek pár órája, azokon is van jitter jelenség ...
Pedig rajta van a hűtőlemez, és BASIC képernyőn továbbra sincsen ...
-
Korábban gondolkodtunk rajta, hogy a régi Nick (08-04) vajon új korábban is olyan pocsék volt, vagy csak az öregedéstől lett rosszabb?
Egy srác írta a Facebookon:
Én még anno a megjelenésekor vásároltam egy gépet, de rövid idejű kipróbálás után hármat kellett visszavinnem, mire egy "jót" kaptam. Sajnos hosszabb (kb. 2-3 óra) üzemidő után, az is szemetelte a képet, így szervizbe került, de utána sem lett tökéletes.
-
nekem az első gépemen fél óra után futtott a kép a melegedéstől. ha a hűtőbordára tettem valami hideget akkor tovább bírta.
visszavittük, kicserélték
-
Szóval ezek szerint volt egy rakat szemét NICK...