1,451

(30 odpowiedzi, napisanych Programowanie - 8 bit)

tylko ja mam problem z takimi eksperymentami, bo mi prościej podpiąć DAC czy Codec do Atari niźli bawić się z haraczącym zakłóceniem :) Wiem że choćby nie wiem jak się starać to nie osiągnie się jakiejś super jakości, a dźwięk takiej jakości bardzo źle działa na moje uszy :D Więc to demotywujące, jednak na chwilę obecną ciekawość zwycięża... ot natura ludzka :P

Pomysł ten od dawna w mojej głowie istniał, bo już dawno temu usłyszałem że się da, a było to w czasach gdy czekało się na produkcje spakowane Cruncher-em 4.64 czy 5.0 de-kompresowały się powodując owe słyszalne zakłócenia w głośniku, gdy produkcja zawierała sample można było je usłyszeć, a właściwie namiastkę tego co z nich zostawało :) Po latach zobaczyłem że ludzie od C64 zrealizowali ten mój szalony pomysł w demie do którego linkowałem, i uznałem że moja teoria była słuszna :D Tyle mi wystarczyło, jednak po latach kolega 'laborant' obudził ponownie moją ciekawość, tylko teraz dzięki cross-dev można wszystko bardzo szybko sprawdzić... gdybym miał czekać aż 128KB wczyta mi się do RAM-u z dyskietki... darowałbym sobie po kilkunastu próbach, albo napisał jakiś "syfer-baro-generator", tudzież pracował z raz wczytanymi samplami to ext. ram.

EDIT:

Pierwszy raz zdałem sobie sprawę że takie akcje są możliwe gdy nawet nie miałem jeszcze swojego komputera, więc biegałem do kolegi który miał Atari 130XE wraz ze stacją dysków LDW2000.... Miał on cało-dyskową wersję gry The Wall, i właśnie podczas wczytywania tej gry z prędkością 19200bps wyraźnie było słychać sampla który potem był odgrywany przez grę na ekranie tytułowym. Nie wiem co to za wersja była, ale ta co jest na AoL ma inny loader (z licznikiem) i dźwięk wczytywania nie jest wyciszony. Pamiętam że tamta wersja wczytywała wszystko przy wygaszonym ekranie i wyciszonym dźwięku SIO... w tle było słychać jednak cichy dźwięk odczytywanych danych... gdy leciał fragment zawierające sample, było to wyraźnie słychać.

1,452

(30 odpowiedzi, napisanych Programowanie - 8 bit)

dlatego napisałem że sprawdzę jeszcze jeden pomysł który mam w głowie, pomysł który ma jakieś podstawy teoretyczne, czy sprawdzi się w praktyce... zobaczymy :)

1,453

(30 odpowiedzi, napisanych Programowanie - 8 bit)

Tak naprawdę to nie wiem co przeszkadza... nawet nie popatrzyłem jeszcze na analizę widma czy oscyloskop, te moje szalone podrygi i eksperymenty miały tylko na celu zobaczenie czy cokolwiek będzie słychać i nawet coś słychać... jakości marnej, być może można by nad tym popracować, ale to wymaga czasu na analizę i eksperymenty... a ja nie miałem czasu na dłuższe eksperymenty. Sprawdzę tylko jeszcze jeden mój pomysł i odpuszczam bo mam wrażenie że "Niewarta skórka wyprawki" :)

1,454

(142 odpowiedzi, napisanych Programowanie - 8 bit)

dzięki za linki TeBe. Tak po ich obejrzeniu, o ile mnie pamięć nie myli to chyba gra "Mercenary - Escape from Targ" całą arytmetykę miała opartą o mnożenie na tablicach log/exp. Wtedy gdy patrzyłem w kod nie bardzo mogłem to zrozumieć bo moja wiedza matematyczna była znikoma.

Mnożenie oparte o właśnie metodę z tablicą kwadratów, tzn:

f(x) = x*x/4 
f(a+b) - f(a-b) = a*b

Wykorzystałem w Invitro do SV2K11 przy początkowej części gdzie smaruje 3d star-field wraz z korekcją perspektywy, i to nawet "wchodzące w ramkę". Gwiazdek mało to na ich tle smaruje się jeszcze slow-motion sprite-scroller :P

1,455

(30 odpowiedzi, napisanych Programowanie - 8 bit)

"cośtam" gra... na początku chciałem bardzo skomplikować sprawę... ale wyszło na to że najlepiej wychodzi czyste miganie kolorem ramki... na początku postanowiłem kombinować z użyciem sprite-ów... (dźwiek był najlepszej jakości, jednak bardzo cichy)... potem próbowałem różnych technik modulacji koloru ramki... wychodzi dość kiepsko... wymaga to dłuższej chwili dla eksperymentów. Oczywiście audio jest bardzo ciche i trzeba wzmacniacz rozkręcić na maksa, no i w wypadku Atari to niestety tor audio jest nieco inaczej filtrowany niż w przypadku C64...

Jak ktoś chce posłuchać tej masakry to proszę bardzo (oczywiście działa tylko na prawdziwym Atari). Kod jest wręcz lamerski, napisany naprędce... wymagane 256KB RAM, ale to tylko dlatego ze postanowiłem do eksperymentów użyć 8-bit sampli. Dzięki tym chorym, wręcz idiotycznym eksperymentom pojawił mi się jednak jeden pomysł w głowie... nie mam już dziś sił ani cierpliwości... nie bardzo widzę co prawda sens ciągnięcia tego eksperymentu, ale spróbuje zrobić jeszcze jedno podejście na dniach...

Dla chcących tego posłuchać link: Antic Audio Test Examples

Program ładuje się od $2000 zajmuje niewiele, ale za to sample ładują się do 8 banków pamięci: $e3,$e7,$eb,$ef,$a3,$a7,$ab,$af. Całość ma ~130KB (99% to "sampel").

Instrukcja obsługi programu... po wczytaniu i uruchomieniu widać najczęściej różne "oczo-dręczące" paski i wzory... należy rozkręcić głośność telewizora/monitora na maksa... może uda się coś komuś usłyszeć, na moim starym TV CRT dźwięk jest dość głośny. Jeżeli ktoś chce posłuchać sampla granego na POKEY-u (4-bit), wystarczy wcisnąć i trzymać SHIFT, puszczenie SHIFT wyłącza odgrywanie na POKEY. (UWAGA!!! przed wciśnięciem SHIFT ścisz TV/Monitor jeżeli nie chcesz doprowadzić do zawału siebie lub domowników, ew. uważać na psa lub kota :P).

Jestem przekonany że jeżeli ktoś się uprze to można to doprowadzić do całkiem zgrabnej formy, jednak głośność tak jak w przypadku C64 będzie naprawdę znikoma a zakłócenia generowane przez tor Video będą i tak dość znaczne.

Zrobię jeszcze parę eksperymentów, tym razem podniosę sample-rate bo chcąc mieć (nie wiedząc czemu) zrobiłem takiego koszmarka 8KHz. No i zrealizuje jeszcze jeden z pomysłów który chodzi mi po głowie. Ale to trochę później. Wcześniej sprawdzę jeszcze inną metodę PWM, pierwsza której próbowałem wyszła wręcz fatalnie :P

EDIT 1:

pierwsza próba PWM: Antic PWM Audio. O dziwo coś słychać i udaje się dosłyszeć poszczególne instrumenty. Na dziś dość... trzeba podnieść sample rate i złapać h-sync z ANTIC... może coś z tego dałoby się więcej wyciągnąć.

EDIT 2:

druga próba PWM, tym razem 5-bit PWM, in sync with H-SYNC: Antic 5-bit PWM audio

EDIT 3:

Jeżeli ktoś ma zacięcie do liczenia cykli i trochę wolnego czasu, właśnie wyszło mi że można spokojnie zrobić czysto software-owy 5-bit PWM na POKEY-u używając jednego kanału, gdy cały player wejdzie w 1-linię to nawet pisku nie będzie słychać :P Przy playerze bez opty (wchodzi w 2-linie) słychać pisk, ale jakość/dynamika jest dość ciekawa :)

ps1) zero jakichkolwiek optymalizacji w kodzie, to wszystko "proof of concept".

ps2) dobranoc, mam dość. czym ja się k******#( zajmuje ;/ jestem zdrowo powalony.

1,456

(30 odpowiedzi, napisanych Programowanie - 8 bit)

jak znajdę chwilę to sprawdzę w domu na CRT czy coś słychać na prostym PWM.

1,457

(30 odpowiedzi, napisanych Programowanie - 8 bit)

myślę że "PWM" na paskach w zupełności wystarczy, na początek wystarczy posłużyć się tylko jasnościami $00,$0F.

1,458

(30 odpowiedzi, napisanych Programowanie - 8 bit)

ludzie od C64 wymyślili pewne zastosowanie tej przypadłości....

https://youtu.be/ZW2XKSWUPLw

Cześć,

Nie jestem kompetentny wypowiadać się w tej sprawie, więc się wypowiem :) Nie wiem czy cokolwiek wniosę do sprawy, ale może się przyda.

#1) czy patrzyłeś sobie np. na ten utwór Jakuba Husaka... http://asma.atari.org/asmadb/search.php?details=244

gdy zajrzysz pod $4695 zobaczysz...

4694: 38                SEC
4695: A9 0D             LDA #$0D
4697: ED AB 3E          SBC $3EAB    [$3EAB] = $07
469A: 8D AB 3E          STA $3EAB    [$3EAB]

w lokalizacji $3EAB znajduje się prędkość wywoływania player-a. A więc powyższy kod co każe wywołanie zmienia prędkość, na przemian występuje prędkość 6,7,6,7,6,7,6,7,6,7,6,7.... genialne w swojej prostocie i nie wykorzystuje żadnych dodatkowych komend zawartych w pattern-ach. Player jest w ACTION! wiec gdy go "disasemblujesz" to może dziwnie miejscami wyglądać, ale jak na kompilator i kod w ACTION! to wynikowy kod wygląda naprawdę całkiem nieźle :)

#2) gdy X-Ray pisał pod MPT i tam nie miał możliwości wykorzystania takiego tricku, po prostu znajdował jeden kanał na którym nie potrzebował używać dodatkowych kodów (np. sterujących głośnością, etc.) i zapełniał go komendami zmiany prędkości co nutę, tak jak to opisałeś wyżej. Z tego co z nim kiedyś rozmawiałem chodziło mu o uzyskanie tempa pośredniego, zamiast pisać z prędkością 1 i wstawiać nuty w odpowiednich miejscach, prościej mu było uzyskać zamierzony efekt właśnie w ten sposób. Dodam tylko że X-Ray często i gęsto pisał na prędkościach 2,3 (podczas gdy tempo wywoływania player-a wynosiło 50Hz).

1,460

(84 odpowiedzi, napisanych Sprzęt - 8bit)

@willy: niestety w takich wypadkach jestem pesymistą :[ kiedyś próbowałem uratować od zapomnienia system Turbo 2600, firmy "Szok" ze Świebodzina, i po pierwszej obiecującej korespondencji kontakt niestety urwał się bezpowrotnie. Oczywiście niczego nie udało się odzyskać. Po pierwszych pozytywnych próbach kontaktu, wszystko się nagle zamarło i nikt więcej nie odpowiedział na żadnego e-maila. Ryszard Mausberg też chyba próbował się z nimi kontaktować, ale z tego co pamiętam sprawa zakończyła się podobnie.

1,461

(84 odpowiedzi, napisanych Sprzęt - 8bit)

To ja się nieco podepnę do tematu, tematyka podobna może ktoś z was będzie w stanie mi pomóc, jednak to wymaga krótkiego wstępu z mojej strony...

Dawno, dawno temu... na warszawskiej giełdzie komputerowej za czasów gdy wszyscy sprzedawali "pirackie" oprogramowanie... A Krzysztof Stec montował Qmeg, Freezer-a oraz rozszerzenia do stacji 1050, LDW2000 czy California Access... widziałem u niego taki program do "kopiowania wszystkiego"... miał on stację 1050, prawdopodobnie z Happy Warp... ponieważ program który ładował aby przekopiować dosłownie wszystko nazywał się "Happy Hacker King III", z tym że tego "III" to nie jestem do końca pewien... czy może ktoś z was potwierdzić istnienie tego softu i odświeżyć mi pamięć? A może ktoś z was ma ten soft w swojej kolekcji?

Wspominałem już o tym kiedyś, w tym wątku... http://www.atari.org.pl/forum/viewtopic ... 06#p105306

Łezka mi się w oku kręci gdy wspominam te czasy... i tak sobie pomyślałem że gdyby ktoś miał ten soft... to u mnie leży jedna biedna goła 1050... to byłaby jakaś motywacja aby zamontować do niej Happy Warp :)

1,462

(35 odpowiedzi, napisanych Fabryka - 8bit)

w tym wypadku chodzi o układ który masz w tym CRT... jest zbyt nowy... i jak w przypadku układów z LCD źle interpetuje sygnał z ATARI.... Atari wysyła tylko jeden rodzaj półobrazów, a Twój TV zakłada bezczelnie (nie sprawdzając rodzaju półobrazu - informacja o tym jest w imp. synch pionowej) że lecą na zmianę linie parzyste i nieparzyste, no i wyświetla Ci jedną klatkę w liniach parzystych a drugą w nieparzystych. Jakiej to marki TV? (tak już z ciekawości pytam). Bo ja mam starą banię Thomson, taką multi-systemową (PAL/NTSC/SECAM), dość sporą i wszystko na niej wygląda idealnie, płynnie.

Problem pewnie leży w tym że Twój TV w środku to już bardziej cyfrowy :P

1,463

(35 odpowiedzi, napisanych Fabryka - 8bit)

@tOri: Ale ja nie pisałem że się nie da... tylko 90% tych scalaków nie potrafi poprawnie zinterpretować sygnału video pochodzącego ze starych maszyn (nie tylko Atari). A potem dochodzi jeszcze problem dobrania odpowiedniej matrycy. Niektórzy producenci telewizorów są jednak tego świadomi i potrafią wyprodukować/kupić taki 'scaler' który doskonale radzi sobie z takimi sygnałami. Tylko w telewizorach czy monitora z wejściami TV/CVBS/S-Video/YPbPr/RGB często pojawia się inny problem... nagminną modą jest to że producent implementuje algorytmy usuwania przeplotu, które uśredniają i analizują co się dzieje na ekranie (mają w pamięci kilka poprzednich klatek) ... testowałem to niestety na sobie... często i gęsto nie da się tych systemów wyłączyć ... a one niestety wprowadzają widoczne opóźnienie do sygnału video... efekt jest taki że np. masz ekran z napisem READY, obraz ostry jak żyleta, potraktowany super algorytmami i filtrami '3d comb filter'... ale gdy naciskasz dowolny klawisz... natychmiast słyszysz 'click' z głośników, a obraz zmienia się po widocznym niestety opóźnieniu wynoszącym w zależności od producenta telewizora/monitora od kilkunastu to nawet kilkudziesięciu klatek :(

Już kiedyś pisałem o tym na forum, a było to wtedy kiedy to stałem się jak mi się wydawało "szczęśliwym posiadaczem' monitora LG ze wszystkimi możliwymi wejściami. Niestety stał się on tylko i wyłącznie monitorem ze względu na znaczne opóźnienie które wnosił w torze video przy obróbce sygnałów PAL/NTSC pochodzących z gniazdek CVBS/S-Video czy SCART ;/

1,464

(35 odpowiedzi, napisanych Fabryka - 8bit)

ależ ja jestem spokojny :) i nikomu nie zabraniam snuć hipotez... tylko ja po prostu to wszystko przerabiałem już i dlatego dzielę się moimi spostrzeżeniami i czasami ponieważ dużo pisania zaczyna wychodzić gdy tok myślenia chcę przelać w tekst, to skracam to co chcę powiedzieć dramatycznie i faktycznie może to czasami brzmieć jak jakieś "mądrzenie się", ale zapewniam Cię że tak nie jest... styl gburowatej odpowiedzi wynika z prób skracania wypowiedzi.

Co do pomijania wywołania playera... to być może nie słyszysz tego w tempie... ale to ma spory wpływ na "obwiednię" i czasami słychać, ale to bardzo zależy od zastosowanych brzmień/instrumentów.

A co do zmiany tempa co ramkę... to tutaj musiał by się wypowiedzieć Jakub Husak... i zdradzić swoją "tajemnicę" :) posłuchaj tego...  http://asma.atari.org/asmadb/search.php?play=244 i powiedz co słyszysz :) dodam że "chłyt" który w tym muzaku zastosował qba jest fenomenalny :)

Co do responsywności matryc TFT to można wykład napisać... dodam tylko że nadal nie są one za szybkie a obecne czasy reakcji które podają to marketingowa ściema (chodzi o czas grey-to-grey) lub nieco inteligentniejsze sterowanie (LCD panel overdrive). Taką siatkę komórek TFT możesz traktować jako pamięć DRAM którą trzeba dość często odświeżać bo zgromadzone między elektrodami ładunki szybko odpływają.

1,465

(35 odpowiedzi, napisanych Fabryka - 8bit)

eeee... 50.08Hz? Nigdy tego nie liczyłem... i wiem że to nie jest 50Hz dokładnie... ale Altirra mówi że jest to 49.8607Hz i to by się chyba zgadzało, bo...

1,773447MHz / 114 = 15556Hz (H-Sync) / 312 (pal lines) = 49,8607Hz (V-Sync)

1,466

(35 odpowiedzi, napisanych Fabryka - 8bit)

Wieczór... przeczytaj jeszcze raz:

The artifact occurs when the video feed to the device isn't in sync with the display's refresh. This can be due to non-matching refresh rates-in which case the tear line moves as the phase difference changes (with speed proportional to difference of frame rates).

to co próbujesz opisać (double buffering) wygląda równie tragicznie... widać to jak cholera i na szlag człowieka trafia gdy widzi coś takiego, bo myśli że sprzęt mu szwankuje i po chwili próbuje pozbyć się monitora przez okno, albo co gorsza całego sprzętu video :P I nie jest ważne czy zastosujesz double, triple czy n-buffer... bo lada chwila nastąpi moment w którym musisz przetrzymać (konwersja 50->60Hz)  albo zgubić (konwersja 60Hz ->50Hz) klatkę obrazu . I jak tylko na ekranie będzie statyczny obraz to OK, ale jak tylko to będzie jakikolwiek scroll... albo płynna animacja czy efekt wchodzący w ramkę (czytaj "mający 50FPS") to mamy wtedy do czynienia z wizualną katastrofą, powodującą wymioty lub ataki epilepsji :P

Uwierz mi... nie da się dobrze (bez utraty jakości czy płynności) wyświetlić obrazu o frame-rate innym od częstotliwości wyświetlacza. Nie takie mózgi jak my nad tym myślały przez lata i jedyne co im się udało zrobić do dostosować matryce tak aby pracowały 48/50/60Hz lub wielokrotności tychże częstotliwości.

Ja mogę na ten temat długo gadać... ale nie mam siły już pisać, kiedyś pogadamy o tym na żywo... a na chwile obecną aby Ci uzmysłowić problem (bo nie tylko my go mamy) proponuję na początek przeczytać sobie np. to: Telecine*. Problem bardzo podobny... bo frame rate kamery filmowej i TV (czy to PAL czy NTSC) również się mocno różni :P i w dodatku TV była kiedyś "interlaced". Teraz przy wprowadzaniu standardów HD udało im się przemycić tryb progressive oraz różne możliwe frame rate, które musi łykać nowoczesny HD TV :P

*) tak, tak... wiem że w PAL przy 2:2 Pulldown mieli dość łatwo.... ale oszukiwali nas bo przyspieszali wszystko o 4%... (łącznie z fonią, zmieniała się wysokość głosów aktorów (sic!) :P ale w przypadku NTSC musieli już się bardziej napracować... :P

A co do matrycy TFT... to nie wiem czy wiesz... ale bardzo się mylisz.... matryca TFT... nie pamięta obrazu... "świeci" się na niej w danej chwili tylko jedna linia obrazu... aktualnie wysyłana przez kontroler do niej podpięty... ilości danych jakie musisz przesłać do matrycy sam sobie obliczysz... i zdasz sobie sprawę ile mega-bajtów na sekundę śle ten niewielki "chip" na chińskiej płytce do sterowania matrycą TFT. Matryca TFT na ma w sobie pamięci.... jak sam nazwa wskazuje jest to tylko matryca komórek złożona z pojedynczych tranzystorów,które są adresowane przy pomocy "stada" rejestrów przesuwających.... jak nic na niej odpowiednio często nie narysujesz to obraz zniknie za chwilę. Tylko bezwładność matrycy powoduje że widzimy na niej cały obraz :P tak więc sam widzisz że TFT daleko od CRT nie upadło :P To tylko rozwinięcie istniejącego wcześniej pomysłu :P

1,467

(35 odpowiedzi, napisanych Fabryka - 8bit)

eghm... nie bardzo wiem jak sobie wyobrażasz wyświetlanie obrazu o częstotliwości 50Hz na matrycy która ma refresh rate 60Hz? Mówię o wyświetlaniu z pełną jakością bez pomijania ani powielania klatek obrazu, bo to oczywiście ma katastrofalny wpływ na "płynność obrazu".

Taką kichę oczywiście "odwala się" obecnie na wszystkich pecetach przy oglądaniu filmów o innym frame rate niż refresh monitora, i to wygląda tragicznie... ludzie tego nie widzą, ale ja tego nie trawie i to jest jakieś mega nieporozumienie, jak można było dopuścić do czegoś tak durnego :( ale ignorancja to siła... ktoś powiedział że to wystarczy i nie ma co się męczyć, potem ludzie przyjęli że tak jest bo to komputer... i zaakceptowali ten do dziś trwający koszmar.

O ile w przypadku gier da sie temu zaradzić to jeżeli masz video o frame rate 50FPS to nie ma sposobu aby go dobrze wyświetlić na monitorze który ma tylko 60Hz odświeżanie.

Screen Teatring napisał/a:

The artifact occurs when the video feed to the device isn't in sync with the display's refresh. This can be due to non-matching refresh rates-in which case the tear line moves as the phase difference changes (with speed proportional to difference of frame rates).

źródło: Screen Tearing

ps) a monitory które mają wejścia S-Video/PAL mają włożone matryce które potrafią pracować przy 50Hz refresh rate, powiem Ci nawet więcej... niektóre z driverów leżących już na samej matrycy potrafią nawet adresować wiersze tak że w pierwszym przebiegu rysują wiersze parzyste a w następnym w nieparzyste (taka spuścizna po epoce CRT i interlace)... tylko nikt tego nie oprogramował w monitorach komputerowych bo i po co :P Oczywiście teraz się to na nich mści, bo np. jak masz w monitorze gniazdko HDMI to tam może się pojawić tryb 1080i @50Hz... i wtedy trzeba wyświetlić obraz tak jak się to robiło kiedyś na CRT, i lepsze modele monitorów z HDMI mają tryb pracy z 50Hz odświeżaniem i potrafią wyświetlać obraz w interlace.

1,468

(35 odpowiedzi, napisanych Fabryka - 8bit)

@tOri: no to niestety tak samo nadal jest jak było kiedyś :( nie znalazłem rozwiązania które dobrze radziło by sobie z sygnałem z 8-bit Atari czy C64. Teraz to może mało takich produkcji z interlace-em ale kiedyś to była standardowa metoda wyświetlania grafiki narysowanej przez zdolnych grafików... np. rysunek Ripley-a z lat '94-95 w intrze do Barymag #2. Z tego też każdy scaler jaki napotkałem robił siekę totalną, a niektóre przy ruchu wektorów na tle obrazka robiły jeszcze gorszą kaszanę próbując coś interpolować i dodawać od siebie.

@wieczór: nie koniecznie, część matryc TFT ma również narzucony minimalny refresh rate... przy niższych częstotliwościach nie chcą pracować poprawnie, część producentów nawet straszy w specyfikacjach uszkodzeniem matrycy. Ale niektóre mimo ostrzeżeń potrafią sobie poradzić całkiem nieźle z 50Hz.

1,469

(35 odpowiedzi, napisanych Fabryka - 8bit)

@tOri: sprawdź jeżeli możesz i będziesz miał czas tryby interlace oraz płynność scrolla pionowego i poziomego. A na koniec jeszcze ten prawdziwy interlace wymyślony przez Rybags-a (480i) z parzystymi i nieparzystymi pół-obrazami, np. MemoPad 480i

większość tego typu scalaków które przetestowałem poległy już na zwykłych interlace-ach typu CIN lub XL Paint MAX, a nawet HIP, TIP czy RIP.

Część tego typu chipsetów nie radziła sobie nawet z wyświetlaniem najzwyklejszego interlace skłądającego się z dwóch miksowanych obrazów jednego trybu bez zmiany palety kolorów w obrazach (np. początkowe ekrany dema Overmind - tzn. logo "A Year has passed" oraz logo "Overmind")

Wszystko przez to że scaler-y wbudowane w te układy, starały się na siłę "ulepszać" obraz który otrzymywały na wejściu CVBS czy S-Video, wychodziła z tego najczęściej poszarpana masakra, bo scaler spodziewał się drugiego "półobrazu" a Atari uparcie wysyłało mu tylko jeden typ półobrazów. Część skaler-ów przyjmowała że informacja wynikająca z imp. sychronizacji pionowej o tym że leci cały czas ten sam półobraz (linie parzyste) jest fałszywa i traktowała przychodzące półobrazy naprzemieninie jako te zawierające linie parzyste a potem nieparzyste... obraz podskakiwał rytmicznie albo trząsł się losowo... w zależności od chipsetu efekty były różne, ale nigdy takie jak być powinny, nawet jak statyzny obraz wyglądał obiecująco i dobrze, to przy pojawieniu się jakiegokolwiek dynamicznego ruchu, czy nawet scrolla lub trybu interlace, natychmiast wychodziła z tego totalna kaszana.

To co powyżej napisałem, to tylko moje doświadczenia z przed paru lat... być może te nowsze scalaki coś więcej potrafią albo lepiej potrafią poradzić sobie z archanicznym sygnałem video, nota bene nie do końca zgodnym ze standardem PAL... jednak odnoszę wrażenie że im nowszy sprzęt tym gorzej z interpretacją "przedpotopowych" sygnałów wizyjnych.

pozdrawiam
Seban

1,470

(12 odpowiedzi, napisanych Software, Gry - 8bit)

Hej!

Zacznę może od początku... kolor tła i tekstu w trybie Hi-Res w przypadku Atari... no cóż... pewnie zapewne wiesz że w tym trybie kolor tekstu jest zależny w 100% od koloru tła, a wpływać możesz jedynie na jasność tego tekstu...

Jasność tekstu z poziomu linii komend w Sparta DOS X możesz zmienić robiąc zwykłe POKE:

- zmiana jasności tekstu POKE $2C5,$0F (jasność od $00-$0F)
- zmiana koloru i jasności tła POKE $2C6,$XY (X - kolor w zakresie $0-$F, Y jasność tła w przedziale $0-$F), czyli np.

POKE $2C5,$0F
POKE $2C6,$C4

da bardzo jasne litery na średnio zielonym tle, litery oczywiście przyjmą odcień tła ($C) ... taka uroda GTIA, w wygląda to tak:

https://dl.dropboxusercontent.com/u/44199/sdx_col1.png

AS wspomniał Ci o VBXE bo w tym wypadku jest możliwa niezależna zmiana koloru liter, może być niezależna od tła... czyli możesz mieć niebieskie literki na zielonym tle.

A teraz sprawa monitora i trybu mono... to jest totalna ściema... jak zapewne wiesz każdy kineskop kolorowy aby uzyskać dany kolor miesza go używając 3 składowych podstawowych, czyli barw czerwonej, zielonej oraz niebieskiej. Od typu kineskopu zależy jaki są ułożone poszczególne składowe (układ delta, IL czy Trinitron, szczegóły tutaj: http://pl.wikipedia.org/wiki/Maska_kineskopu )

W przypadku Twojego monitora to prawdopodobnie maska typu IL. Przełączenie tego monitora w tryb Green, wyłącza składowe R oraz B... przez co obraz staje się pocięty i widzisz zamiast R,G,B ... ciemno, zielono, ciemno, ciemno zielono, ciemno, ciemno... itd.

Kineskop w tym monitorze jest dość niskiej jakości niestety (mała rozdzielczość maski) więc patrzenie na taką sieczkę bardzo męczy oczy... o wiele sensowniejszym jest włączenie podłączenie do monitora tylko sygnału luminancji lub włączenie trybu "grayscale"... wtedy będą składowe R,G,B będą świeciły jednakowo co da bardziej kojący dla oczu obraz... chociaż nadal będą wycelowane w Ciebie 3 działa elektronowe udające tryb mono :) Dlatego jeżeli chcesz pracować na CRT poważnie zastanów się nad prawdziwym monitorem monochromatycznym gdzie nie ma żadnej maski, a tylko jedno działo i powierzchnia ekranu w całości pokryta luminoforem emitującym światło w danym kolorze (zielonym, bursztynowym czy to po czymś to wszyscy nazywają "czarno-białym", choć tak naprawdę jest to pełna skala szarości).

Mam gdzieś podobny monitor więc zrobię zdjęcie w wolnej chwili o pokażę o co mi chodzi dokładniej.

1,471

(1 odpowiedzi, napisanych Scena - 8bit)

Thanks for the reminder! Nice piece of music!

with greetings
Seban/Slight

1,472

(23 odpowiedzi, napisanych Sprzęt - 8bit)

jak zwykle cenna uwaga :) nie sposób z Tobą nie zgodzić :) sam jestem sobie winny :]

1,473

(23 odpowiedzi, napisanych Sprzęt - 8bit)

@qba: wiedzą, wiedzą... bo te sektory w przypadku gęstości SINGLE leży dokładnie po środku dyskietki, z tego punktu głowica ma tak "samo równo" w obie strony dyskietki :)

Wszystkie Twoje pomysły o których wspomniałeś powyżej są opisane w moim poście na początku tego wątku :)  może nieco żartobliwie i zawoalowane, ale są wymienione bardzo podobne do Twoich moje domysły dotyczące tej sprawy :) Zatem nie pozostaje mi nic innego jak zgodzić się z Tobą w 100% :)

1,474

(23 odpowiedzi, napisanych Sprzęt - 8bit)

to o czym mówiłem, czyli widać doskonale te scieżki nad którymi głowica często lądowała i stacja zatrzymywała silnik (stacja TOMS720), takie efekty mam tylko na dyskietkach które były przeze mnie intensywnie użytkowane i wielokrotnie zapisywane oraz odczytywane:

http://seban.pigwa.net/aa/sys_disk.png

ps) musiałem się posłużyć skanerem oraz pewną obróbką obrazu aby to uwidocznić... gołym okiem widać to doskonale, jednak wykonanie temu zdjęcia jest niemożliwe (odbicia, robi mi się "naturalny" enviroment-mapping ;P) a skaner dopiero przy 1200dpi pokazał te niuanse, efekt należało wzmocnić odpowiednim filtrem wyostrzającym.

1,475

(23 odpowiedzi, napisanych Sprzęt - 8bit)

TOMS720 też nie cofa głowicy. Natomiast przy każdym włączeniu dojeżdża do końca (79 ścieżka) oraz cofa się do ścieżki 0.

Jaki jest sens przesuwania głowicy na ostatnią ścieżkę po pewnym czasie bezczynności? Prawdę mówiąc nie mam pojęcia, być może podczas normalnej pracy z większością dyskietek głowica rzadko ma okazję dojechać do końca, może takie działanie jest spowodowane chęcią utrzymania prowadnic w jednakowym stanie (tzn. aby ten smar który jest na łożyskach ślizgowych był rozprowadzany równomiernie po całej długości prowadnic?

Być może powód jest bardziej prozaiczny, wyobraź sobie że głowica pozostaje nad jakąś ścieżką np. 18, w tym stacja zatrzymuje silnik i głowica zostaje nad tą ścieżką. Teraz wyobraźmy sobie że Atari nagle chce wykonać jakąś operację I/O... stacja więc rozpędza silnik do odpowiednich obrotów a głowica leży cały czas na nośniku nad ścieżką 18... myślę że to może mieć wpływ po prostu za zużycie nośnika (np. takie rozpędzanie silnika nad daną ścieżką)... nawet jest pewien że ma... jak znajdę moją tzw. dyskietkę systemową ... to dosłownie widać na niej gdzie jest ścieżka zawierająca DIR i VTOC. Jest wytarta tak że zmieniła barwę.

Ewentualnie... wyobraź sobie taką samą sytuację... czarna noc... Henry koduje właśnie swój efekt życia do mega-dema... ostatni zapis na dysk i efekt prawie gotowy... jest godzina 3:51 rano... w tym czasie jego siostra Samatha budzi się i zagląda do pokoju brata... nie chcąc go niepokoić przemyka się cicho za jego plecami, niestety potyka się o przedłużacz do którego podłączony jest cały system Henry-ego... Atari wyłącza się grzebiąc pracę Henry-ego... a do tego stacja konając w agonii i resztkach energii której dopływ został brutalnie odcięty... w ramach chęci podążania tunelem do światłości... postanawia wysłać ostatnie impulsy elektryczne do swoich obwodów... pech chciał za akurat write-gate została otwarta (stan nieustalony jakiejś bramki) i resztka energii napi* w głowicę zapisującą.... stacja ostatnim tchnieniem sił przemagnesowuje kawałek nośnika znajdujący się tuż pod głowicą... pech chciał że to był sektor zawierający najbardziej istotną część kodu w mega efekcie Henry-ego...

ps) dlaczego ten system cenzuruje słowo "n a p i e r n i c z a"? :P to sugeruje że napisałem wyżej coś o wiele bardziej brzydkiego ;/