Kineskop - jak szybko sprawdzić stan próżni ?

Masz nietypowy problem 'lampowy'? Spróbuj tutaj.

Moderatorzy: gsmok, tszczesn, Romekd

_idu

Re: Kineskop - jak szybko sprawdzić stan próżni ?

Post autor: _idu »

Furman Zenobiusz pisze:Z tym, że A1200 była lepsza od ówczesnych pecetów, raczej się nie do końca się zgodzę.
W pewnym zakresie miała możliwości sporo większe (głównie zastosowania okołotelewizyjne, gry, itp), jednak w kwestii mocy obliczeniowej - no przykro mi, ale tutaj nie było wesoło.
Ale to wina producenta który długo zwlekał z nową konstrukcją. A A4000 wypuszczono za późno podobnie jak A1200, A600 było bezsensem. Natomiast genialny CDTV poległ bo pojawił się za wcześnie.... szkoda bo wyprzedził DVD .... ale kaseta VHS wtedy "rządziła".
W zasadzie jak wypuszczono A400 był już procesor 68060 ostatni z tej rodziny.
Pazerność zgubiła Amigę - gdyby położono nacisk na ilość sprzedanych maszyn byłoby inaczej.
W A1200 jak ją wypuszczano powinien był być 68030 z 68882 oraz już wbudowane choćby 1MB fast memory.
Brakło wyobraźni tym bardziej ze i Commodore jak i Atari nawet polegli ze swoimi PC-tami.
Tym bardziej szkoda Atari Falcon'a - miał on na pokładzie procesor DSP (i procek 68030). Trzeba było być zdolnym aby dobre konstrukcje pogrzebać na samym starcie tym bardziej ze konkurencja (PC i Intel) oferowała przestarzałą architekturę... Transputery dla Atari ST też jakoś nie potrafiły zdobyć miejsca na rynku.
Furman Zenobiusz pisze: Do 486 to nawet nie ma co porównywać, bo byle 386 z 387 na pokładzie będzie szybszy absolutnie we wszystkim, a w operacjach zmiennoprzecinkowych będzie masakrycznie szybszy.
Owszem bo po to zastosowano koprocesor graficzny aby nie męczyć procesora. Idea z czasów końca lat 70-tych jak powstało Atari 400. Atari 8-bitowe - 1.78MHz a w sumie nie było mniej wydajne niż Spectrum z Z80 taktowanym szybciej.
Co do zmiennoprzecinkowych operacji to koprocesory Intela były gorzej niż przeciętne. Jakby było inaczej toby Weitek nie zbijał majątku na swoich koprocesorach. Jak pojawiło się Pentium to było opublikowane porównanie procesora Alpha z Pentium. Podobne zegary (Pentium 266MHz, Alpha 200MHz), kod z Intela emulowany na Alphie był szybszy niż ten sam kod dopalony na Intelu a w przypadku operacji zmiennoprzecinkowych o rząd wielkości szybszy niż na Intelu. Więc ten koprocesor Intela nie był taki super. I nadal nie jest jeśli do obliczeń arytmetycznych coraz częściej wykorzystuje się moc obliczeniowa kart graficznych. Albo kupuje Cray'a jeśli stać.
Furman Zenobiusz pisze: W czystej mocy obliczeniowej AMD 386 + Weitek 387 oba 40MHz jest porównywalny z 68030+68882/40MHz, a wiem to stąd, że posiadam obie maszyny. Zestaw z 386 to mój pierwszy pecet, do dziś sprawny leży i nabiera wartości kolekcjonerskiej. 68030+882 na pokładzie ma moja A600 (Apollo 630).
Zważ że porównujesz Weiteka 387 a nie Intela 387!!!!.
Furman Zenobiusz pisze: Sprawę ratował fakt, że w tamtych czasach sporo potężnego softu było dla PC niedostępne, dlatego nierzadko widziało się Amigi w zastosowaniach profesjonalnych - jeden z moich znajomych gdzieś do 2002 roku używał nieco rozbudowanej Amigi 1200 w telewizji i montażu video, wyparł ją dopiero pecet z dedykowaną kartą (która wtedy miała cenę 4-cyfrową bliską 5-cyfrowej).[/qyuote]
Takowe karty był też i dla Amigi. Np. Video Toaster. Ale był on poza zasięgiem naszych kieszeni.
Furman Zenobiusz pisze: Tak patrząc w przeszłość, to czasy Amigi zaczęły się kończyć właśnie razem z nadejściem 486 i wczesnych Pentium. Wtedy pecety stały się naprawdę mocno rozszerzalne i mimo że kosztowało to niemało, dało się je łatwo rozbudowywać.
Amigę tez można było rozbudowywać - oprócz swojego standardu ZorroII / Zorro III można było korzystać z kart ISA z PC. Niestety błędy decyzyjne doprowadziły do uwalenia konstrukcji - a wystarczyło tylko dać bridge do PCI. Chociaż PC-towe mocno okrojone PCI to była porażka (no po co powstawały dedykowane porty dla kart graficznych m.in. AGP????) - prawdziwe PCI oferowało wysoką wydajność transferu danych. Chunky pixel - można było nie konstruować dedykowanej kości a wykorzystać to co już był ona rynku ( i tak postępowali producenci kart graficznych do Amigi).
Awatar użytkownika
tszczesn
moderator
Posty: 11228
Rejestracja: wt, 12 sierpnia 2003, 09:14
Lokalizacja: Otwock
Kontakt:

Re: Kineskop - jak szybko sprawdzić stan próżni ?

Post autor: tszczesn »

STUDI pisze:
Jest nadal prawdziwe. Wystarczy kilka wredniejszych operacji z USB, Ethernetem i PC-tet (nie tylko pod Windows) przestaje reagować na zdarzenia od klawiatury, myszy itd... Nie wspominam o wsadzeniu pyty CD/DVD problematycznej w odczycie albo podłączeniu dysku z bad-sectorami (SATA oferuje kolejkowanie jak w SCSI czego nie było w IDE). Widać jak stosunkowo proste IO rozkłada system. A USB to już
Tylko pod Windows. Nie zauważyłem takiego zachowania pod Linuksem czy nawet dawno temu pod OS/2. Owszem zdarzają się źle napisane programy które np. muszą poczekać aż wyświetlą listę plików z CDROMu, ale jest to sprawa konkretnego programu a nie systemu. Owszem - USB potrafi zakłócić inne USB jak są na jednej szynie, ale od tego nie uciekniesz, to już cecha USB jako takiego.
STUDI pisze:Owszem procesor nie ma z czego czytać kodu ale - jest cache wewnętrzne czyż nie? są kolejki instrukcji kodu w procesorze, ponadto Intel to CISC a nie RISC i wykonanie instrukcji zajmuje mu sporo cykli maszynowych.
Ano. I tak się dzieje. Zwłaszcza, że współczesne chipsety kolejkują dostęp do pamięci na poziomie sprzętowym, więc transfery DMA nie odcinają zupełnie procesora od szyny.
STUDI pisze:Owszem tak ale 68000 dawało kilka ciekawych mechanizmów ochrony obszarów danych bez MMU - np ramki stosu. Każdy z procesów w trybie user mógł mieć własny prywatny stos. Co to daje - np. obronę przez atakami typu buffer ovefrlow. A w PC mającym MMU?
Owszem, i było to jedyne wsparcie do wielozadaniowości w 68000. A poczytaj sobie dokumentację do choćby 286 (że o 386 nie wspomnę) - dla wielozadaniowych systemów jest to o wiele lepszy procesor, bo dużo rzeczy ułatwia.
STUDI pisze:Ułatwiacze nie były potrzebne - owszem OS < 2.0 (nie wiem ja beta czyli 1.5) miały uproszczony model alokacji pamięci (spadek po BCPL) ale wraz nowym OS (a dokładniej exec.library bo to było jądro systemu Amigi, dos.library to dodatek i to drugorzędny) zniknęły błędy Guru związane np ze zwalnianiem nie przydzielonej pamięci itp. Ale 2.0 to też dwukrotnie większy ROM (kod nie rozrósł się dwuktrotnie kilka bibliotek przesunięto do ROM'u - co ciekawsze można było stosować poprawki do bibliotek w ROM'ie bez kopiowania całości biblioteki do RAM'u - polecenie SetPatch - zaleta nowoczesnej struktury pliku wykonywalnego a nie archaicznej jak EXE w M$).
Ułatwiacze są potrzebne - bez MMU choćbyś pękł nie zrobisz separacji zadań, każdy proces ma wzgląd w pamięć innego procesu i co gorsza systemu. Owszem sensowy system zarządzania pamięcią potrafi zredukować problemy wynikające z błędnego używania zaalokowanej pamięci, ale nijak nie zabezpieczą przed np. nadpisaniem tablicy wektorów przerwań.
STUDI pisze:Wracając do MMU - szybko w PC 640kB było niewystarczające i to bez środowiska graficznego a w Amidze 512kB dawało radę całkiem nieźle.
Nie wiem. Moja A500 miała AFAIR 2MB A 640 wystarczało do wielu zastosowań to bardziej od danych zależy a nie od komputera.
Awatar użytkownika
Furman Zenobiusz
1250...1874 posty
1250...1874 posty
Posty: 1344
Rejestracja: pn, 11 stycznia 2010, 20:44
Lokalizacja: Brzeziny
Kontakt:

Re: Kineskop - jak szybko sprawdzić stan próżni ?

Post autor: Furman Zenobiusz »

Tak wracając do tematu kineskopów i próżni, przeglądałem ostatnio pewną książkę, a dopiero dziś zauważyłem odpowiedni rozdział:
Kineskop - utrata emisji
Kineskop - utrata emisji
Kineskop - wady katod, utrata próżni
Kineskop - wady katod, utrata próżni
Kineskop - wady katod, utrata próżni
Kineskop - wady katod, utrata próżni
Kineskop - uszkodzenia żarzenia
Kineskop - uszkodzenia żarzenia

Ciekawe na ile skuteczny jest sposób z zdejmowaniem podstawki i szybkim pomiarem, muszę kiedyś przetestować na jakimś większym czarno-białym kinolu.
Awatar użytkownika
Furman Zenobiusz
1250...1874 posty
1250...1874 posty
Posty: 1344
Rejestracja: pn, 11 stycznia 2010, 20:44
Lokalizacja: Brzeziny
Kontakt:

Re: Kineskop - jak szybko sprawdzić stan próżni ?

Post autor: Furman Zenobiusz »

Dziś się przekonałem, że jednak jest pewna różnica w montażu tego kineskopu - składałem to do kupy, włożyłem do prowizorycznej obudowy i okazało się, że przekręcony o 180 stopni nie daje się dokładnie wyregulować a ponadto [ekranowane] głośniki wyginają trochę obraz u samego dołu. Dziwne bo wygląda na symetryczny, ale jednak po przekręceniu go w drugą stronę problemy zginęły.
_idu

Re: Kineskop - jak szybko sprawdzić stan próżni ?

Post autor: _idu »

tszczesn pisze: Tylko pod Windows. Nie zauważyłem takiego zachowania pod Linuksem czy nawet dawno temu pod OS/2. Owszem zdarzają się źle napisane programy które np. muszą poczekać aż wyświetlą listę plików z CDROMu, ale jest to sprawa konkretnego programu a nie systemu. Owszem - USB potrafi zakłócić inne USB jak są na jednej szynie, ale od tego nie uciekniesz, to już cecha USB jako takiego.
Nie mówimy o blokowaniu magistrali USB. Niestety PC=ty tak maja niezalażnie od OS'a.
tszczesn pisze: Owszem, i było to jedyne wsparcie do wielozadaniowości w 68000. A poczytaj sobie dokumentację do choćby 286 (że o 386 nie wspomnę) - dla wielozadaniowych systemów jest to o wiele lepszy procesor, bo dużo rzeczy ułatwia.
Był jeszcze 68010, który notabene miał być docelowo montowany w Amigach - mógł pracować z MMU Motoroli a przy okazji miał jedną instrukcję więcej na poziomie supervisora i to taką która już wtedy pozwalała odpalić niejako dwa różne OS'y na raz (w sensie dwa jara pracujące w trybie supervisora - zupełnie niezależnie od siebie). Z tego powodu były nałożone na niego wiesze restrykcje co do handlu zaawansowanymi technologiami (np. COCOM).

Ale tak w zasadzie to 68020 to był procesor z prawdziwego zdarzenie dla wielozadaniowości w rozumieniu ala UNIX.
68000 powstał na długo przed 80286. Nawet przed nieudanym 80186. Po 80286 obiecywano sobie wiele ale jakoś niewiele z tego wyszło i dopiero 80386 otworzył drogę do lepszego świata niż DOS.
Prze rodziną 68k był jeszcze ciekawy procek 6809. Zilog w swoim czasie pozazdrościł Motoroli i wypuścił wzorowany na 68k procesor Z-8000 (był początkowo rozważany przy budowie prototypu Amigi).
tszczesn pisze: Ułatwiacze są potrzebne - bez MMU choćbyś pękł nie zrobisz separacji zadań, każdy proces ma wzgląd w pamięć innego procesu i co gorsza systemu. Owszem sensowy system zarządzania pamięcią potrafi zredukować problemy wynikające z błędnego używania zaalokowanej pamięci, ale nijak nie zabezpieczą przed np. nadpisaniem tablicy wektorów przerwań.
Można było sobie poradzić. Wymagało to specyficznych dekoderów adresu i dodatkowej pracy w kodzie. W czasach gdy wsio pisano w assemblerze to nie było z tym problemu.
MMU zaoferowało wygodniejszą dla programistów platformę wielozadaniową i z pamięcią wirtualną - przy okazji oferującą izolację procesów.
Dodam jeszcze że zarówna architektura 68k, x86 itp. nie nadaje się do pewnych zastosowań gdzie wymagana jest bezwględną separacja pamięci kodu programu i pamięci danych.
I jeszcze jedno obecny typowe procesory maja jedna zła cechę. Brak ochrony danych odłożonych na stosie. A niestety język C wypromował stosowanie stosu. W efekcie jest najczęstszy sposób włamu do programu.
Były produkowane specjalne kompilatory C do mikrokontrolerów gdzie bezwzględnie nie używano stosu do przesyłania danych przy wywoływaniu procedur.
tszczesn pisze: Pierwszy Workbench (graficzny interfejs na AmigoDOS) zadowalał sie 256kB RAM. Kolejne wersje 1.1, 1.2, 1.3 oraz 1.4 zoptymalizowano dla 512kB. Wersja 2.0 i późniejsze można odpalić na 512kB i bez pamięci wirtualnej. Aplikacje z graicznym interfejsem pracowały w takim środowisku.

A Windows 95 które nie oferowało takiej samej wielozadaniowości jak Amiga? Zdecydowanie 4MB pamięci jako minimum a w zasadzie dopiero 8MB dawało jakiś minimalny komfort pracy.
To efekt zwartego kodu (ale nie zamkniętego) zaś Win95 miało tę wadę że nie dało rady rozszerzać niektórych fragmentów API (stąd musiał powstać DirectX bo GDI nie dało się przyśpieszyć....). To właśnie chaotyczny zlepek różnych mało pasujących API wymagał większych zasobów.
Ale po co Windows - gry pod DOS'a a dokładniej korzystające już z DOS4GW. Przed Wolfenstein-em - podobne gry na Amidze zadowalały się 512kB a na PC wymagały 4MB RAM'u. A największa bolączką był obszar poniżej 1MB, którego ciągle było za mało i trzeba było często zamienników HIMEM.SYS.
Awatar użytkownika
tszczesn
moderator
Posty: 11228
Rejestracja: wt, 12 sierpnia 2003, 09:14
Lokalizacja: Otwock
Kontakt:

Re: Kineskop - jak szybko sprawdzić stan próżni ?

Post autor: tszczesn »

STUDI pisze:
tszczesn pisze: Tylko pod Windows. Nie zauważyłem takiego zachowania pod Linuksem czy nawet dawno temu pod OS/2. Owszem zdarzają się źle napisane programy które np. muszą poczekać aż wyświetlą listę plików z CDROMu, ale jest to sprawa konkretnego programu a nie systemu. Owszem - USB potrafi zakłócić inne USB jak są na jednej szynie, ale od tego nie uciekniesz, to już cecha USB jako takiego.
Nie mówimy o blokowaniu magistrali USB. Niestety PC=ty tak maja niezalażnie od OS'a.
Za diabła nie wiem co te PC-ety mają. Blokowanie magistral? (jak tak to nie jest to prawda.
STUDI pisze:
tszczesn pisze: Owszem, i było to jedyne wsparcie do wielozadaniowości w 68000. A poczytaj sobie dokumentację do choćby 286 (że o 386 nie wspomnę) - dla wielozadaniowych systemów jest to o wiele lepszy procesor, bo dużo rzeczy ułatwia.
Był jeszcze 68010, który notabene miał być docelowo montowany w Amigach - mógł pracować z MMU Motoroli a przy okazji miał jedną instrukcję więcej na poziomie supervisora i to taką która już wtedy pozwalała odpalić niejako dwa różne OS'y na raz (w sensie dwa jara pracujące w trybie supervisora - zupełnie niezależnie od siebie). Z tego powodu były nałożone na niego wiesze restrykcje co do handlu zaawansowanymi technologiami (np. COCOM).
Co COCOM ograniczał to nie wiem, jakoś się tego na pamięć nie uczyłem :). rodzina 68k miała sporo członków, jak x86, w końcu rozwijała się chyba za 20 lat :)
STUDI pisze:Ale tak w zasadzie to 68020 to był procesor z prawdziwego zdarzenie dla wielozadaniowości w rozumieniu ala UNIX.
68000 powstał na długo przed 80286. Nawet przed nieudanym 80186. Po 80286 obiecywano sobie wiele ale jakoś niewiele z tego wyszło i dopiero 80386 otworzył drogę do lepszego świata niż DOS.
Prze rodziną 68k był jeszcze ciekawy procek 6809. Zilog w swoim czasie pozazdrościł Motoroli i wypuścił wzorowany na 68k procesor Z-8000 (był początkowo rozważany przy budowie prototypu Amigi).
Wiem. 286 pojawił się w sumie trochę za wcześnie jak na masowy rynek - tak zaawansowane funkcje jądra (wirtualna pamięć, separacja zadań, wsparcie dla multitaskingu) nie były wtedy potrzebne w 'domowych' systemach. 386 miał tylko dwie istotne różnice - stronicowanie pamięci (znakomicie ułatwia obsługę pamięci wirtualnej) i 32-bitowe ALU. 286 też mógł otworzyć 'drogę do lepszego świata niż DOS', ale nie było to jeszcze potrzebne.
STUDI pisze:
tszczesn pisze: Ułatwiacze są potrzebne - bez MMU choćbyś pękł nie zrobisz separacji zadań, każdy proces ma wzgląd w pamięć innego procesu i co gorsza systemu. Owszem sensowy system zarządzania pamięcią potrafi zredukować problemy wynikające z błędnego używania zaalokowanej pamięci, ale nijak nie zabezpieczą przed np. nadpisaniem tablicy wektorów przerwań.
Można było sobie poradzić. Wymagało to specyficznych dekoderów adresu i dodatkowej pracy w kodzie. W czasach gdy wsio pisano w assemblerze to nie było z tym problemu.
No właśnie - specyficznych dekoderów adresu, czyli MMU (w prostej wersji). Żaby było weselej w czasach młodości zaprojektowałem sobie (na bramkach, o VHDLu jeszcze nie słyszałem) MMU do Z80. Teoretycznie (na ile mogłem go ręcznie zanalizować) działał - zapewniał separację zadań, pamięć wirtualną (64kb na proces) i separację danych od kodu.
STUDI pisze:MMU zaoferowało wygodniejszą dla programistów platformę wielozadaniową i z pamięcią wirtualną - przy okazji oferującą izolację procesów.
MMU oferowało w ogóle taką możliwość. Bez MMU nie miałeś jak zabronić procesowi pisać lub czytać pewnych obszarów pamięci.
STUDI pisze:I jeszcze jedno obecny typowe procesory maja jedna zła cechę. Brak ochrony danych odłożonych na stosie. A niestety język C wypromował stosowanie stosu. W efekcie jest najczęstszy sposób włamu do programu.
Były produkowane specjalne kompilatory C do mikrokontrolerów gdzie bezwzględnie nie używano stosu do przesyłania danych przy wywoływaniu procedur.
A to nie sprawa procesorów x86, a struktury systemu operacyjnego. Stos miał własny segment, który nie musiał być wykonywalny i nie musiał być mapowany w innym segmencie.
STUDI pisze:A Windows 95 które nie oferowało takiej samej wielozadaniowości jak Amiga? Zdecydowanie 4MB pamięci jako minimum a w zasadzie dopiero 8MB dawało jakiś minimalny komfort pracy.
To efekt zwartego kodu (ale nie zamkniętego) zaś Win95 miało tę wadę że nie dało rady rozszerzać niektórych fragmentów API (stąd musiał powstać DirectX bo GDI nie dało się przyśpieszyć....). To właśnie chaotyczny zlepek różnych mało pasujących API wymagał większych zasobów.
Ale po co Windows - gry pod DOS'a a dokładniej korzystające już z DOS4GW. Przed Wolfenstein-em - podobne gry na Amidze zadowalały się 512kB a na PC wymagały 4MB RAM'u. A największa bolączką był obszar poniżej 1MB, którego ciągle było za mało i trzeba było często zamienników HIMEM.SYS.
Nie mam bladego pojęcia jaką wielozadaniowość oferował W95. To było naprawdę dawno temu, do tego wtedy ja siedziałem głównie na OS/2. A poza tym Amiga miała sprzętowe wsparcie do grafiki, którego w kartach PC wtedy nie było, co znakomicie ułatwiało obsługę grafiki. I do tego dość porąbane tryby graficzne o wyższej rozdzielczości, które podobno ułatwiały obsługę animacji itp.
ODPOWIEDZ