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

[Furman Zenobiusz]

Ciężko będzie, o ile magnetowid jeszcze mi został, to kasety VHS nie bardzo.
Dzięki jednak za podsunięcie pomysłu, podłączę magnetowid po RGB do komputera i programikiem Nokia Monitor Test wygeneruję obraz testowy - pozostaje mieć nadzieję, że magnetowid pracuje w zakresie odbieranym przez TV.
Pozostaje jeszcze kwestia overscanu, obraz TV chyba jest nieco większy w pionie od standardowej PALowskiej rozdzielczości, ale to akurat da się ustawić na oko.

[TELEWIZOREK52]

To nie prościej kupić za 4zł nową kasetę? Pozdrawiam.

[_idu]

Dzięki jednak za podsunięcie pomysłu, podłączę magnetowid po RGB do komputera i programikiem Nokia Monitor Test wygeneruję obraz testowy - pozostaje mieć nadzieję, że magnetowid pracuje w zakresie odbieranym przez TV.

Tyle że na TVOUT kart graficznych rozmiar obrazu odbiega od tego co uznano za standard TV.
Szerokość i wysokość jest inna a wynika z przeliczania obrazu 800-600 taktowanego tym samym zegarem co podstawowy obraz SVGA. Ani częstotliwość odchylania poziomego ani pionowego nie zgadza się dokładnie z normą. Gubione są niektóre linie oraz klatki aby się jakoś mocno w przybliżeniu dopasować do standardu PAL.

[Furman Zenobiusz]

Dlatego nie wykorzystałem wyjścia TV-Out, zresztą nie mam takiej karty. Z kolei z wyjściem composite i magnetowidem obraz był kiepskiej jakości.

Znalazłem inne, lepsze rozwiązanie. Porobiłem zrzuty ekranu w programie Ntest2 w najwyższej rozdzielczości, dla regulacji kineskopu mono w zasadzie wystarczył mi standardowy ekran kontrolny + obraz z paskami o różnej szerokości. Przeniosłem je na starą wysłużoną Amigę 600 której standardy TV nie są obce. Modulator antenowy jest na pokładzie, więc wystarczyło otworzyć obrazki i wyświetlić je (przeskalowane) w wybranym trybie graficznym. Testowałem w dwóch trybach: PAL i PAL:Overscan.
Regulacji dokonywałem w ten sposób, że z overscanem ustawiłem krawędzie ekranu na fizycznych krawędziach kineskopu, następnie przełączyłem się w 'goły' PAL, przymierzyłem do kinola ramkę w której siedzi i lekko przesunąłem obraz, żeby mieścił się w widzialnym zakresie. Chyba lepiej nie ma co tego ustawiać, przecież w końcu nie jest to żaden wypasiony telewizor do oglądania na codzień, a jedynie pozbierana do ładu kupka śmieci z której od czasu do czasu może będzie pożytek w plenerze (jak dorwę jakąś obudowę).

[_idu]

Heh, kto by pomyślał że poczciwa Amiga będzie za generator serwisowy robić...

[dark_one]

O ! Amigowcy ! Od razu jakoś raźniej się robi Moją Amisię 1200 też czasem używam jako generator obrazów ... któż nie pamięta Scali

[_idu]

O ! Amigowcy ! Od razu jakoś raźniej się robi Moją Amisię 1200 też czasem używam jako generator obrazów ... któż nie pamięta Scali

Zwłaszcza że potrafi płynnie wyświetlać prezentacje. A PC z M$.....? Krowa o nazwie PowerPoint kontra lekka Scala Multimedia. Była wersja na PC ale to była porażka - skokowo zmieniający się obraz.
Niestety koncepcja bitplane'ów nie sprawdziła się wraz pojawieniem się gry Wolfenstein na PC. Szkoda do to był wydajny wielozadaniowy system (wielozadaniowy także na poziomie hardware'u (MacIntoshow'cy się przechwalali tez multitaskingiem ale wystarczyło im zadać klina sformatuje jednocześnie więcej niż jedną dyskietkę... Amigo potrafiła robić to równolegle na wszystkich 4 dołączonych napędach jednocześnie - można było obejrzeć słynne ich bombki...-> w Amidze odpowiednik Guru Meditation a w PC odpowiednik "niebieskiego ekranu" ) - PC nawet x64 nadal się zacina jak tylko jest używane DMA...).

No i jeszcze to słynne demko wygrywające melodie na mechaniźmie wbudowanej stacji dysków. Dynamika i skala tonalna szersza od piezobrzęczyków w zegarkach z melodyjkami. Nawet basy były.

[dark_one]

W moim mieście jeszcze w zeszłym roku po burzy padła walidacja na dysku kompa lokalnej kablówki i po włączeniu telewizora witał wszystkich ekran startowy Amisi 1200 Teraz mają peceta ... Ale architektura z pamięcią chip i fast żyje choćby w postaci elementów projektu Nvidii CUDA. W poszukiwaniu generatorów obrazów testowych dla Amisi wystarczy przeszukać Aminet o choćby tu:
http://aminet.net/gfx/misc/Vpg.lha

[tszczesn]

Niestety koncepcja bitplane'ów nie sprawdziła się wraz pojawieniem się gry Wolfenstein na PC. Szkoda do to był wydajny wielozadaniowy system (wielozadaniowy także na poziomie hardware'u (MacIntoshow'cy się przechwalali tez multitaskingiem ale wystarczyło im zadać klina sformatuje jednocześnie więcej niż jedną dyskietkę... Amigo potrafiła robić to równolegle na wszystkich 4 dołączonych napędach jednocześnie - można było obejrzeć słynne ich bombki...-> w Amidze odpowiednik Guru Meditation a w PC odpowiednik "niebieskiego ekranu" ) - PC nawet x64 nadal się zacina jak tylko jest używane DMA...).

Nie myl PC-ta z Windows, to to drugie sprawia problemy. A wielozadaniowość sprzętu Amigi była taka sama jak PC, a nawet mniejsza - 68000 ani 68020EC nie miały MMU bez którego wielozadaniowość jest kulawa.

[_idu]

Nie myl PC-ta z Windows, to to drugie sprawia problemy. A wielozadaniowość sprzętu Amigi była taka sama jak PC, a nawet mniejsza - 68000 ani 68020EC nie miały MMU bez którego wielozadaniowość jest kulawa.

Windowsy robią tylko tyle ile pozwala architektura procesora. Co do wielozadaniowości - owszem nie było MMU ale nie byo to wymagane dla wielozadaniowości a jedynie dla realizacji pamięci wirtualnej. 68000 i 68008 a także 68010 nie miały MMU ani nie miały dedykowanego MMU. 68020 miał MMU w postaci zewnętrznej kostki 68851. 68010 móg współpracować z zewnętrznym MMU.

68010 miał jedną instrukcję więcej w trybie supervisor'a co pozwalał na uruchamianie więcej niż jednego systemu operacyjnego jednocześnie na tym samym procesorze. Ponadto 68010 miał krótsze cykle wykonywania rozkazów. To 68010 maił być w Amidze 1000 ale zdecydowano się na tańszy 68000 (oraz łatwiej dostępny).

MMU zintegrowane z procesorem to dopiero 68030. 68040 miał już zintegrowany koprocesor 68882. W czasach 68020 był przewidziany 68881 który można było dołączyć do 68000/68008/68010. Co ciekawe 68000 współpracował też bezproblemowo z koprocesorami Intela - był takowy projekt na Atari ST - jego rozwinięciem był ciekawy emulator PC - płytka z procesorami Intela która korzystała wprost z zasobów sprzętowych Atari ST.

Bolączką PC jest kulawe DMA. W trackie transferu DMA jest wstrzymywana praca rdzeni procesora!!!. Przeczy to idei DMA aby odciążyć procesor - co to odciążenie jeśli procesor musi wstrzymać swoją pracę.

Amiga (oraz małe Atari tak małe Atari bo Amiga jest rozwinięciem idei zastosowanych a Atari) - miała dwa procesory - Agnus (Alice w 1200/4000) mający najwyższy priorytet i 68000 / 680EC20 / 68030 / 68040...
Agnus był procesorem kontrolera obrazu i miał własną listę rozkazów i własny program.

[tszczesn]

Windowsy robią tylko tyle ile pozwala architektura procesora. Co do wielozadaniowości - owszem nie było MMU ale nie byo to wymagane dla wielozadaniowości a jedynie dla realizacji pamięci wirtualnej. 68000 i 68008 a także 68010 nie miały MMU ani nie miały dedykowanego MMU. 68020 miał MMU w postaci zewnętrznej kostki 68851. 68010 móg współpracować z zewnętrznym MMU.

Windowsy robią tyle na ile potrafią go napisać koderzy. Na żadnym innym systemie pod PC (OS/2, Linux) używanie dyskietek czy innego tego typu sprzętu nie blokowało systemu. MMU jest do wielozadaniowości potrzebne, i to nie do pamięci wirtualnej (ta nie jest niezbędna, tylko przydatna), ale do realizacji separacji zadań. Bez tego każde zadanie może i tak w systemie zrobić co chce.

Do realizacji wielozadaniowości jako takiej zasadniczo nie ma potrzeby istnienia wsparcia procesora czy reszty sprzętu, to jest potrzebne do zapewnienia 'usług dodatkowych' - separacji zadań, poziomu przywilejów procesów, pamięci wirtualnej itp. ułatwiaczy.

Bolączką PC jest kulawe DMA. W trackie transferu DMA jest wstrzymywana praca rdzeni procesora!!!. Przeczy to idei DMA aby odciążyć procesor - co to odciążenie jeśli procesor musi wstrzymać swoją pracę.

Nie pamiętam szczegółów architektury PC, ale nawet [1] jeżeli to była prawda, to w czasach ISA i AT, nowsze architektury działają już trochę inaczej.

[1] Mogła być, bo skoro coś innego przejmuje dostęp do pamięci to procesor nie ma z czego czytać kodu, a proste układy kontroli szyny mogą podpinać pod szynę tylko jedno urządzenie. Ale to też była prawda 20 lat temu, teraz kolejkowanie dostępu jest wszędzie.
BTW - to odciąża procesor dość znacznie - transfer bajtu z urządzenia zewnętrznego do pamięci to co najmniej cztery cykle szyny - rozkaz IN, bajt z urządzenia, rozkaz MOV, bajt do pamięci. DMA, nawet najprostsze zrobi to w jednym lub dwóch cyklach.

[Furman Zenobiusz]

W czasach 68020 był przewidziany 68881 który można było dołączyć do 68000/68008/68010.

Z tak napisanego zdania można wywnioskować, że 68881 nie pasuje do wyższych procesorów, co nie jest prawdą 68882 da się zamienić przez 68881.

Bolączką PC jest kulawe DMA. W trackie transferu DMA jest wstrzymywana praca rdzeni procesora!!!. Przeczy to idei DMA aby odciążyć procesor - co to odciążenie jeśli procesor musi wstrzymać swoją pracę.

To od dawna nie jest do końca prawdziwe. Łatwo znaleźć maszyny które przerzucają terabajty danych między różnymi interfejsami lub z/do karty graficznej i czarno na białym widać, że nie zajmuje to zbyt dużo mocy procesora.

[dark_one]

No no - tam gdzie Amisia tam gorąca dyskusja
Zważcie że rozmawiacie o czasie przeszłym - nie ma co porównywać Amigi do obecnego peceta - nie te czasy i nie ta technologia. W czasie kiedy królowała A500 współczesne jej pecety to były cienkie siuśki. Porównanie A1200 i 486 też wypada na korzyść Amisi. Obecny pecet to stosunkowo nowoczesny komputer i raczej wprowadza się nowe rozwiązania a nie wiąże sobie ręce starymi (patrz nieszczęsna ISA). Choć powiem szczerze że pojawienie się wielu rdzeni w procesorach to niewiele zmieniło i prawdziwych programów napisanych tak żeby z tego korzystać jest jak na lekarstwo (wiadomo - trudniej to napisać). Nie piszę tu o stosowaniu wielowątkowości tylko o programie napisanym z choćby śladową intencją optymalizacji wykorzystania mocy obliczeniowej - jak dla np. Cray'a Po co się męczyć skoro moc obliczeniowa jest wystarczająco duża (jest to słuszna droga - zgodna z panującym w przyrodzie trendem)... na Amidze sprawa wyglądała inaczej, albo piszesz maksymalizując wykorzystanie hardware'u i sprzedasz program jako hit albo produkt będzie przeciętny. W takich warunkach (taki hardware czyli brak alternatywy) system wieloprocesorowy ma szansę istnieć. Obecnie inercja zarzyna ciekawe rozwiązania architektury i więcej w tym zakresie dzieje się wśród konsol do gier niż komputerów. Proszę żeby moderatorzy potraktowali pobłażliwie ten offtop, przecież Amisia lubi telewizor, lampowy też

[Furman Zenobiusz]

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.

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

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

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

W kwestii Amiga jako sprzęt serwisowy - moja A600 powróciła do akcji właśnie jako przełączany generator wizji PAL/NTSC. 2003-2010 bezużytecznie na strychu, aż przycisnęła mnie konieczność posiadania sygnałów testowych m.in. do testowania rejestratorów. Od razu przypomniało mi się o sprzęcie, który praktycznie każdy standardowy tryb potrafi wygenerować.

[_idu]

Z tak napisanego zdania można wywnioskować, że 68881 nie pasuje do wyższych procesorów, co nie jest prawdą 68882 da się zamienić przez 68881.

Owszem można było 68881 podłączyć do 68030. Tylko pytanie po co? Chyba aby oszczędzać na kasie (u nas w PRL'u w tamtych czasach istotne). Po prostu wprowadzono na rynek mocniejszy koprocesor (chyba nawet przed wprowadzeniem 68030). Generalnie to można było podłączyć dowolny procesor jako koprocesor i poprzez prosty acz genialny inferfejs na poziomie kodu maszynowego wykorzystać jego rozkazy jakby były wbudowane w listę 68k.

Windowsy robią tyle na ile potrafią go napisać koderzy. Na żadnym innym systemie pod PC (OS/2, Linux) używanie dyskietek czy innego tego typu sprzętu nie blokowało systemu. MMU jest do wielozadaniowości potrzebne, i to nie do pamięci wirtualnej (ta nie jest niezbędna, tylko przydatna), ale do realizacji separacji zadań. Bez tego każde zadanie może i tak w systemie zrobić co chce.

Do realizacji wielozadaniowości jako takiej zasadniczo nie ma potrzeby istnienia wsparcia procesora czy reszty sprzętu, to jest potrzebne do zapewnienia 'usług dodatkowych' - separacji zadań, poziomu przywilejów procesów, pamięci wirtualnej itp. ułatwiaczy.

Nie pamiętam szczegółów architektury PC, ale nawet [1] jeżeli to była prawda, to w czasach ISA i AT, nowsze architektury działają już trochę inaczej.

[1] Mogła być, bo skoro coś innego przejmuje dostęp do pamięci to procesor nie ma z czego czytać kodu, a proste układy kontroli szyny mogą podpinać pod szynę tylko jedno urządzenie. Ale to też była prawda 20 lat temu, teraz kolejkowanie dostępu jest wszędzie.
BTW - to odciąża procesor dość znacznie - transfer bajtu z urządzenia zewnętrznego do pamięci to co najmniej cztery cykle szyny - rozkaz IN, bajt z urządzenia, rozkaz MOV, bajt do pamięci. DMA, nawet najprostsze zrobi to w jednym lub dwóch cyklach.

To od dawna nie jest do końca prawdziwe. Łatwo znaleźć maszyny które przerzucają terabajty danych między różnymi interfejsami lub z/do karty graficznej i czarno na białym widać, że nie zajmuje to zbyt dużo mocy procesora.

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ż nie czasy ISA, Ethernet wetknięty do PCI-X to też nie ISA. Więc coś nie tak.
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.

Chcesz systemu z b. wydajnym IO? Ani Unix, tym bardziej Windows czy QNX. Stare poczciwe main-frame'y. Dlatego nadal pomimo swoje archaiczności (tkwią nadal w latach 60-tych) - pomimo ciągłego od wielu lat przewidywania ich zmierzchu nadal si e mają dobrze. A procesory w nich są przeciętne wydajnościowo i np. aby jako tako chodził np. linux trzeba kupić dodatkowy koprocesor wymagany do pracy takim trybie.

MMU jest do wielozadaniowości potrzebne, i to nie do pamięci wirtualnej (ta nie jest niezbędna, tylko przydatna), ale do realizacji separacji zadań. Bez tego każde zadanie może i tak w systemie zrobić co chce.

Do realizacji wielozadaniowości jako takiej zasadniczo nie ma potrzeby istnienia wsparcia procesora czy reszty sprzętu, to jest potrzebne do zapewnienia 'usług dodatkowych' - separacji zadań, poziomu przywilejów procesów, pamięci wirtualnej itp. ułatwiaczy.

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?

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

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.