A precyzyjniej, śmierć śmieciom z prawej strony ekranu Atari! Jak wiele osób, ja również przez lata obserwowałem, że niektóre obrazki czy programy wywołują jakieś przypadkowe śmieci, daleko z prawej strony ekranu. Ten efekt nie zawsze był widoczny, bo niektóre telewizory w ogóle nie wyświetlają tak szerokiego obszaru, mają nawet problem z wyświetleniem całego, zwykłego obrazu Atari. Stąd zresztą wiele dyskusji w świecie Atari na temat tego, jakie są maksymalne rozmiary ekranu naszego ulubionego komputera i różne obliczenia teoretyczne i praktyczne (jedna z lepszych rozpisek jest dostępna tutaj).
Oczywiście pomijam, pojawiające się w wielu starych źródłach, fałszywe informacje, jakoby maksymalna rozdzielczość Atari wynosiła 320 na 192 pikselach w hiresie, bo każdy średniozaawansowany Atarowiec wie, że Atari ma obraz elastycznie modyfikowany przez Display List, więc ta podana rozdziałka to predefiniowany w systemie tryb GRAPHICS 8 i można bez wielkiego wysiłku komputera czy programisty wyświetlić obraz o innej wysokości, maksymalnie 239 pikseli (przy 240 zrywa synchronizację obrazu, ale kolega Gary "Rybags" Ryan odkrył kilkanaście lat temu jak uzyskać w hires pełne 240 w pionie, podobnie jak we wszystkich pozostałych trybach Atari, uwaga: w popularnym programie graficznym "Graph2Font" nie jest ta poprawka zaimplementowana).
Większa niepewność użytkowników dotyczy szerokości ekranu, mimo, że tutaj możemy sobie w Atari włączyć zaledwie trzy tryby: ekran wąski (256 pikseli hires), normalny (320 pikseli) oraz szeroki... No właśnie, tu się zaczynają schody w obliczeniach, ile pikseli szerokości mamy w tym trybie. W przypadku szerokiego ekranu padają różne wartości, a demoscenowy consesus podaje, że mamy wtedy do czynienia z obrazem większym o jeden znak hiresowy po lewej i po prawej, a więc 320+8+8=336 pikseli. Taką maksymalną szerokość ekranu Atari wyświetlają niektóre emulatory, jak popularny Atari800 i Atari800Win. Dzisiaj zadamy kłam tej teorii, która ma już długą, chyba trzydziestoletnią historię. Udało nam się uzyskać 356 pikseli szerokości, na standardowym Atari, nie modowanym w żaden sposób. Wydaje się niewiele, ale daje to nam, przy pełnej wysokości ekranu, 960 pikseli na rysunku więcej. No i kolejny raz potwierdza, że Atari to niezwykle ciekawy komputer, w którym ciągle można odkryć coś nowego.
Najpierw pokażę przykładowy obrazek, na którym widać rzeczony efekt śmieci po prawej stronie. Jest to wspaniała praca "Inspection" Tomasza "Irwina" Bogdanowicza sprzed kilkunastu lat. Widać na niej doskonale, bo wykorzystuje tryb szerokiego ekranu, że skrajnie z prawej strony pojawia się kolumna z jakimiś śmieciami. Przez lata nikt nie zwracał na nie uwagi, po prostu traktowane były jako zło konieczne, choć zdarzało się, że w celu ich uniknięcia, niektórzy używali duszka, który przykrywał te śmieci (da się to zrobić używając priorytetu 1 lub 2, tylko priorytet 4 nie zadziała). Poniżej zrzuty ekranowe całej pracy Irwina i powiększenie fragmentu z prawej strony ekranu, najpierw z prawdziwego Atari, potem z emulatora Altirra:
rysunek "Inspection" Irwina na prawdziwym Atari - po prawej stronie widać śmieci na dwa piksele szerokości (równoważne w hiresie czterem pikselom, a w trybie GTIA - jednemu pikselowi)
ten sam efekt można sobie obejrzeć w emulatorze Altirra
Również przy okazji tworzenia mojego obrazka tytułowego do powstającej gry "Cyborg Warriors", który z pewnych względów musiałem narysować w szerokim trybie, zauważyłem, że pojawiły się śmieci z prawej strony. Przykryłem te śmieci duszkiem, ale zaintrygowało mnie, dlaczego są one wyłącznie w takim kolorze, jaki użyłem do narysowania kombinezonu kosmonauty... I tu nastąpiło olśnienie. Skoro te śmieci pojawiają się z powodu konkretnych pikseli na ekranie (a więc jakichś danych) to zapytałem kolegę Jerzego "Mono" Kuta czy można wpływać na te dane, które są wyświetlane. Po chwili zastanowienia Mono przeprowadził wywód, z którego wynikało, że teoretycznie jest to możliwe. Przeszliśmy więc do następnego kroku. Najpierw Mono udowodnił, że można te śmieciowe dane okiełznać, uzyskując 4 dodatkowe piksele szerokości w hires (i analogicznie 2 piksele w lowres, 1 dodatkowy piksel w gtiares). Przygotowałem więc pierwszy obrazek o szerokości 356 pikseli, a potem drugi, trzeci... Wszystkie były doskonale widoczne, czym dostaliśmy potwierdzenie, że ekran Atari naprawdę ma taką szerokość. Upewnił nas w tym jeszcze program "Tomoko v2", kolegi AtariFan, który to program jest doskonałym narzędziem do mierzenia szerokości widocznego ekranu (dostępny w naszym archiwum użytków tutaj, w dziale "E. Diagnostyczne", sterowanie klawiszami strzałek i strzałek z Control).
Oczywiście to skrócona wersja całej histori, bo operacja odkrywania błędów w opisach grafiki w różnych źródłach, kodowania, porównywania, testowania, rysowania - jest znacznie dłuższa. Trzeba było sobie poradzić choćby z uzyskiwaniem obrazków o odpowiedniej szerokości. Wykorzystaliśmy do tego "Graph2Font", który radzi sobie z szerokim obrazem bardzo dobrze, ale oczywiście nie pozwala panować nad śmieciami po prawej i w hires nie pozwala na więcej niż 239 pikseli w pionie. To już trzeba było oprogramować ręcznie, co też zrobił Mono, modyfikując pliki ASM, wygenerowane przez "Graph2Font". Warto dodać, że aby uzyskać poprawne zestawy znaków z "Graph2Font" w hires, należało te obrazki przełączyć w lowres i wtedy wygenerować z nich pliki ASM. W przeciwnym wypadku, G2F modyfikuje fonty, co dla naszych potrzeb jest efektem niepożądanym.
Inne programy pecetowe również mają problemy z pokazywaniem pełnego obrazu Atari, choćby emulatory naszego komputerka. Ostatecznie okazało się, że tylko Altirra potrafiła nam poprawnie odwzorować na ekranie śmieci albo uporzadkowane przez nas dane - aby je zobaczyć należy w Altirrze w menu View wybrać opcję Overscan Mode, a tam Extended lub Full (domyślnie emulator jest ustawiony na obcinanie widocznego obrazu jak inne emulatory). Mamy nadzieję, że w kolejnych wersjach takich programów, które nie pokazują pełnego ekranu, ich autorzy uwzględnią, że Atari może wyświetlić obraz znacznie szerszy niż dotychczas sądzono. Aby wspomóc ten rozwój oprogramowania, głos w sprawach technikaliów oddaję Mono, ponieważ nikt tak jak on nie potrafi wyjaśnić zawiłości technicznych całego procesu, ważnych z punktu widzenia kodera, twórcy oprogramowania dla Atari czy peceta:
"Komputery Atari serii 400/800 oraz XL/XE dysponują szerokimi i niespotykanymi na innych im współczesnych platformach ośmiobitowych możliwościami programowania grafiki. Poza różnorakimi trybami graficznymi czy szeroką paletą dostępnych na ekranie barw jest też możliwość łatwej konfiguracji szerokości i wysokości obrazu.
Procesor ANTIC potrafi wyświetlać obraz o trzech szerokościach konfigurowanych ustawieniem rejestru DMACTL ($D400):
32 znaki o szerokości 8 pikseli, co daje 256 pikseli,
40 znaków * 8 pikseli = 320 pikseli,
48 znaków * 8 pikseli = 384 pikseli. O ile pierwsze dwa ustawienia zawsze działają stabilnie i przewidywalnie, o tyle to ostatnie pociąga za sobą kilka niespodzianek.
Pierwszą jest to, że przystępując do wyświetlenia wiersza na ekranie, ANTIC zaczyna prezentować treść dopiero począwszy od czwartego bajtu, a nie od pierwszego, jak by to wynikało z ustalonego adresu i jak ma to miejsce przy pozostałych szerokościach. Mając zdefiniowaną listę wyświetlania (ang. "Display List") jak następuje: .byte $0F | $40 ;MODE F + LMS .word $2000 .byte $0F ;MODE F .byte $0F ;MODE F .byte $0F ;MODE F
czyli chcąc zaprezentować 4 wiersze grafiki wysokiej rozdzielczości w trybie GRAPHICS 8 (tryb graficzny F ANTIC-a) spodziewalibyśmy się, że ich treść znajdzie się w pamięci począwszy od adresów $2000, $2030, $2060 i $2090, a tymczasem na ekranie rzeczywiście prezentowane będą dane począwszy od adresów kolejno: $2003, $2033, $2063 i $2093.
Drugim figlem, jaki płata układ wizyjny, jest mniejsza niż oczekiwana ilość bajtów prezentowanych w linii na ekranie, co oczywiście przekłada się na liczbę wyświetlanych pikseli. Teoretycznie jest to 48 bajtów, a w praktyce ANTIC wyświetla tylko 44 kolejne lokacje pamięci. Nie będą zatem widoczne 3 bajty z początku wiersza i jeden bajt z końca. Wyświetlane więc będą dane zapisane kolejno w obszarach:
$2003-$202E,
$2033-$205E,
$2063-$208E,
$2093-$20BE czyli 44 bajty * 8 pikseli = 352 piksele trybu wysokiej rozdzielczości.
Trzecią niespodzianką jest wąski, czteropunktowy pas zagadkowych śmieci, widocznych na prawej krawędzi ekranu, tuż za wyświetlaną grafiką. Nie występuje on kiedy w rejestrze DMACTL skonfigurowane jest wyświetlanie obrazu wąskiego lub normalnego, tudzież zawartość ekranu nie jest w ogóle prezentowana. To sugeruje że wyjątkowe zachowanie układu wizyjnego może być spowodowane jego błędem, ujawniającym się wyłącznie podczas wyświetlania obrazu szerokiego. Zdawałoby się, że zawartość tych punktów ustalana jest w sposób całkowicie przypadkowy, okazuje się jednak, że zarówno ich źródło jak i treść może zostać zidentyfikowana dość precyzyjnie. Aby to wyjaśnić trzeba przyswoić sobie garść informacji o tym, w jaki sposób ANTIC wyświetla linię obrazu i jak współpracuje z innymi chipami komputera.
Za wyświetlanie obrazu w ośmiobitowych komputerach Atari odpowiedzialne są dwa układy - procesor graficzny ANTIC (ang. "Alpha-Numeric Television Interface Controller") oraz układ GTIA (ang. "Graphic Television Interface Adaptor"). Ten pierwszy zajmuje się pobieraniem z pamięci komputera danych potrzebnych do sformowania punktów obrazu i przesyła je dalej, do drugiego układu zajmującego się nałożeniem kolorów i wygenerowaniem sygnału wizyjnego transmitowanego następnie wprost do monitora lub odbiornika telewizyjnego. Ponieważ w pamięci komputera znajduje się nie tylko grafika, ale również program komputera wykonywany przez główny procesor (ang. "Central Processing Unit") oraz dane przez niego przetwarzane, dlatego obydwa układy - ANTIC oraz CPU - muszą jakoś współpracować i dzielić się dostępem do niej. Jako że prezentacja obrazu jest zadaniem krytycznym czasowo i musi zostać zrealizowana choćby nie wiem co, dlatego układ graficzny ma pierwszeństwo w dostępie do pamięci i potrafi zablokować działanie CPU, na czas tych (szczęśliwie krótkich) chwil, kiedy potrzebuje pobrać potrzebne mu dane.
Pojedyncza linia obrazu podzielona jest na kwanty czasu zwane cyklami, podczas których ANTIC i CPU wykonują powierzone im zadania. Takich cykli jest 114 i w każdym z nich może być realizowane:
odświeżanie pamięci dynamicznej RAM,
pobranie informacji o rodzaju wyświetlanego wiersza (z pamięci Display List),
pobranie kształtu sprajta (z pamięci sprajtów),
pobranie numeru znaku do wyświetlenia w wierszu trybu tekstowego (z pamięci ekranu),
pobranie kształtu wyświetlanego znaku (z zestawu znaków),
pobranie treści prezentowanej na ekranie w trybie graficznym (z pamięci ekranu),
pobranie danych dla CPU. Równocześnie ANTIC na podstawie już pobranych informacji formuje obraz i przesyła go do układu GTIA.
Rys. 1. Diagram rozkładu cykli na rysowanej lini obrazu (za Avery Lee "Altirra Hardware Reference Manual", str. 92, "Event Timing Chart")
Spośród natłoku informacji warto z powyższego diagramu wyłuskać cykle, w których rozpoczyna się i kończy ekran o różnych szerokościach: 8 - początek szerokiego ekranu 16 - początek normalnego ekranu 24 - początek wąskiego ekranu ... 56 - centrum ekranu ... 88 - koniec wąskiego ekranu 96 - koniec normalnego ekranu 103 - deadline WSYNC 104 - koniec szerokiego ekranu + koniec WSYNC
oraz intrygujące, acz istotne w dalszej części artykułu informacje o enigmatycznym WSYNC. Całości dopełnia poniższy diagram, który dodatkowo obrazuje jakie dane pobiera ANTIC w konkretnych cyklach linii trybu F:
Rys. 2. Diagram rozłożenia zadań ANTIC-a w czasie rysowania linii ekranowej (za Avery Lee "Altirra Hardware Reference Manual", str. 91, "ANTIC modes D-F, mode line, wide playfield")
W pierwszych ośmiu cyklach pobierane są dane dla sprajtów (Player/Missile Graphics), oraz rozkaz listy wyświetlania (Display List DMA) i ewentualnie dodatkowe dwa bajty adresu dla rozkazów JMP, JVB i LMS. Następnie zaczynają się cykle pobierania danych graficznych z pamięci ekranu (PlayField DMA) przeplatane gdzieniegdzie cyklami odświeżania pamięci ekranu (Memory Refresh). Wszystkie pozostałe cykle w linii dostępne są dla CPU. To, czy w danym cyklu odbędzie się pobranie specyficznej danej zależy od konfiguracji poszczególnych bitów rejestru DMACTL:
bity 0 i 1 - dane grafiki (i znaki dla trybów tekstowych),
bit 2 - dane pocisków,
bit 3 - dane graczy,
bit 5 - program listy wyświetlania.
Z analizy poprzedniego diagramu wiadomo, że szeroki ekran kończy się w cyklu 104, w którym następuje pobranie ostatniego bajtu danych grafiki - jest to właśnie 47 bajt linii. Poza krawędzią ekranu szerokiego występują dodatkowe cykle (Virtual DMA) w których ANTIC już nie wstrzymuje CPU, ani nie adresuje samodzielnie pamięci, ale za to pobiera bajty znajdujące się w tych momentach na magistrali danych. Potwierdza to Avery Lee w "Altirra Hardware Reference Manual" w sekcji "Virtual DMA Cycles" na str.84:
"Playfield DMA cycles that would occur on cycle 106 or later are blocked by the hardware and do not occupy the bus or stop the 6502. However, ANTIC still reads the data bus and stores or interprets the data on those cycles."
W takim razie, ponieważ te cykle dostępne są dla CPU, oznacza to, że pojawiać się tam będą bajty kodu programu oraz przetwarzanych przez niego danych. Zatem te właśnie dane ANTIC wyświetli zamiast 48-go bajtu linii i powoli staje się jasne dlaczego to, co widać na prawej krawędzi ekranu, przypomina przypadkowy wzór.
Mikroprocesor MOS 6502 wykonuje rozkazy o długości od 1 do 3 bajtów oraz czasie trwania od 2 do 7 cykli, trzeba więc znaleźć sposób zsynchronizowania CPU z ANTIC-iem, tak żeby móc precyzyjnie kontrolować stan magistrali danych w interesującym nas cyklu linii ekranowej. A przyglądając się temu, co dzieje się na krawędzi ekranu:
cykl 104: PlayField DMA
cykl 105: CPU
cykl 106: Virtual DMA widać, że jest to dokładnie cykl 106.
I tu pomocny okazuje się tajemniczy WSYNC, widoczny na pierwszym diagramie. Mianowicie zapis do rejestru WSYNC ($D40A), następujący najpóźniej w cyklu 103 linii ekranowej, powoduje, że ANTIC blokuje działanie CPU aż do zakończenia cyklu 104. A ponieważ pobiera on dane do wyświetlenia dopiero w cyklu 106, to pomiędzy nimi CPU może dostać opkod (ang. opcode - operation code) rozkazu jako argument mającego daną do wyświetlenia na ekranie.
Analizując stan magistrali danych w kolejnych cyklach wykonania rozkazu LDX $8899:
cykl 1: $AE (%10101110) - odczyt opkodu LDX,
cykl 2: $99 (%10011001) - odczyt LSB adresu danej,
cykl 3: $88 (%10001000) - odczyt MSB adresu danej,
cykl 4: $xx (%xxxxxxxx) - odczyt danej z adresu $8899,
Rys. 3. Schemat wykonania rozkazu odczytu w trybie absolutnym (za Henryk Kruszyński, Krzysztof Kulpa "Mikroprocesor 6502 i jego rodzina" str.133 "ABS 2: LDX $8899")
można założyć, że w takim razie sekwencja: STA WSYNC LDA $6060
powinna spowodować wystawienie bajtu %01100000 ($60) w dwóch kolejnych cyklach na magistrali danych:
cykl x: $8D (%10001101) - odczyt opkodu STA cykl x: $0A (%00001010) - odczyt LSB adresu WSYNC cykl x: $D4 (%11010100) - odczyt MSB adresu WSYNC cykl x: $xx (%xxxxxxxx) - zapis do WSYNC ... cykl 104: $xx (%xxxxxxxx) - PlayField DMA bajt 47 linii cykl 105: $AD (%10101101) - odczyt opkodu LDA cykl 106: $60 (%01100000) - Virtual DMA + odczyt LSB adresu $6060 cykl 107: $60 (%01100000) - odczyt MSB adresu $6060 cykl 108: $xx (%xxxxxxxx) - odczyt danej z adresu $6060
otrzymując w ten sposób wzór 0110 do wyświetlenia na ekranie, będący górną połówką bajtu (górny nibble) obecnego na magistrali danych. Dolna połówka (dolny nibble bajtu) jest ignorowana. Zabieg ten można powtarzać w każdej z 240 linii ekranowych tworzonych przez ANTIC.
Dokładnie ten sam mechanizm zadziała poprawnie w przypadku trybu tekstowego, należy jednak mieć na względzie, że wtedy z pamięci ekranu odczytywany jest zawsze komplet 48 bajtów z indeksami znaków do wyświetlenia (a więc łącznie z informacją o inwersji), a tylko 47 bajtów grafiki, tym razem pochodzącej z zestawu znaków. Tak więc wzór podany programowo ANTIC-owi będzie wyświetlony z uwzględnieniem informacji o inwersji 48 bajtu.
Ponadto przetestowaliśmy, że włączenie bitu 4 odpowiadającego za płynny przesuw poziomy w rozkazie trybu Display List i przesuwanie treści grafiki rejestrem HSCROL ($D404) nie ma żadnego wpływu na szerokość ekranu.
Tą oto metodą, opisaną powyżej, uzyskaliśmy ekran o szerokości 44 bajty * 8 + 4 piksele = 356 pikseli."
Aby udokumentować to osiągnięcie, postanowiliśmy zrobić prosty program demonstracyjny, bez żadnej muzyki, pokazujący kilka obrazków o szerokości 356 pikseli i wysokości 240 pikseli. To aktualnie maksymalne rozmiary obrazu, jakie udało nam się uzyskać na Atari. Demo zatytułowaliśmy "Death of the Right Side Garbage", w nawiązaniu do słynnego na Atari ST demka "Death of the Left Border" niemieckiej grupy TNT Crew, które prezentowało nowy wówczas efekt - likwidację ramki po lewej stronie ekranu ST. Nasze demko, likwidujące śmieci po prawej, jest do ściągnięcia stąd, każdy kolejny ekran uzyskujemy po naciśnięciu klawisza spacji. Cztery obrazki w hires zawdzięczamy konwersji, więc chcielibyśmy podziękować panom Jarvisowi, Stuckiemu oraz Floydowi i Steinbergowi za ich wkład w nasze proste demko. Dziekujemy również AtariFanowi za owocne dyskusje i informacje, Miszy za zrealizowanie nagrań działania demka na prawdziwym Atari, zarówno niemodowanym, jak i z VBXE, a Mphobicowi za fajne zdjęcia demka z ekranów jego komputerów.
Gdyby ktoś miał pytania odnośnie efektu 356 pikseli, wymienionych w tym artykule narzędzi, sposobu uzyskiwania obrazków o większej szerokości, albo po prostu chciał w tym temacie podyskutować, zapraszamy do odpowiedniego wątku na Forum Atarum.
Henryk Kruszyński, Krzysztof Kulpa "Mikroprocesor 6502 i jego rodzina" Wydawnictwo Czasopism i Książek Technicznych NOT-SIGMA, Warszawa 1989
2024-01-06 21:23 by Kaz
komentarzy: 30
sim1 @2024-01-06 21:49:22
Wlasnie patrzylem na compo-stream i troche drapalem sie w glowe. Znam leTko Atari, ale przyznam, ze szkoda, ze grafiki nie mialy "oznaczen" odkad zaczynaja sie "myki". Tak, to patrzylem i zastanawialem sie, gdzie grafika sie konczy a zaczyna "myk". Wszytkie grafiki sa swietne, ale ten niebieski kolor jest wrecz.. Och, super ;).
Greetz!
Nikifor @2024-01-06 22:16:35
To nie są śmieci z prawej strony ekranu, tylko płótno malarskie.
Nikifor @2024-01-06 22:17:41
Postrzępione płótno malarskie.
mono @2024-01-07 00:37:04
"czasem jeno szmer cichy posłyszysz, jakoby łagodny podmuch zefiru lubo szept strumyka, gdy ów między kamieniami wartko bieży"
Bca @2024-01-07 02:54:29
Samotny krawiec postrzępione płótno zacerował.
Janusz Biznesu @2024-01-07 10:23:53
Brawo wy, kolejne granice Atari przesunięte! Naprawdę super sprawa, teraz przydałoby się to inkorporować do G2F, chyba że się nie da.
Adam @2024-01-07 10:55:53
Gratulacje.
mono @2024-01-07 13:31:50
@sim1: Na mojej stronie mono.i-demo.pl/356x240.atr (lub .xex) jest wersja gdzie klawiszem OPTION możesz włączać podświetlenie dodatkowych pikseli za pomocą sprajta.
@Janusz Biznesu: Wszystkie te grafiki zostały przygotowane w G2F, bo on pozwala na edycję całego obszaru linii. Kłopot jest potem z generowaniem .xex bo tego G2F już nie umie, ale może uda się napisać jakiś eksporter.
gorgh/Agenda @2024-01-07 16:46:47
Bardzo fajne odkrycie, ciekawi mnie jedna rzecz odnośnie artefaktów.. przy niektórych kombinacjach pikseli w lowres powstają nowe kolory na ekranie bądź artefakty hires w obrębie pikseli low res, ciekawe, czy jest to powtarzalny efekt niezależny od wyświetacza, bo jeśli tak by było to otwiera to pole do nowych możliwości graficznych
Dzięki za artystyczne komentarze i przychylne komentarze! :D
Mono - dorzucam też tę wersję do archiwum naszych użytków. PS. Tryb 356 wzbudził zainteresowanie naszych czołowych koderów demoscenowych, którzy przychodzili na LP podpytać o to, jak to zrobione i mogłem ich wtedy odesłać do szczegółowego opisu powyżej, więc to był dobry pomysł, żeby takie technikalia opisać przy okazji compotów.
Janusz Biznesu, Mono - jest też szansa, że G2F uzyska drugie życie, bo okazało się, że jeden z członków naszego stowarzyszenia jest spcecem od Delphi, więc może uda się ponownie doprowadzić G2F do update'owalności.
Bill Kendrick - thanks a lot! it's great to hear such words from such a famous programmer! :)
Anon @2024-01-07 22:46:24
A g2f było pisane oryginalnie w Delphi?
j_g @2024-01-07 23:29:29
Fajnie opisane.
Dużo dobrego się dziś robi, ale niestety przeważnie brakuje takiego podejścia jak tutaj, wytłumaczenia problematyki tym średnio siedzącym w temacie. Wiadomo, takie opisywanie to pewnie dość niewdzięczna robota, bo najfajniejsze jest implementowanie, ale dla odbiorców najatrakcyjniejsza w tym wszystkim jest właśnie ta zawartość edukacyjna.
Brawo. Byle tak dalej.
Atari XL/XE @2024-01-08 01:43:56
Muszę przyznać, że miałem już dość tych śmieci z prawej strony. Strasznie mnie one męczyły. Dziękuję Panowie, że odśmieciliście mnie. Zawsze mniej śmieci to ulga. Jak to było? Śmieć śmierciom, a nie, sorry ... śmierć śmieciom!
Brush @2024-01-08 09:15:11
I takich hardware'owych tricków mi wiecznie mało na platformach 8bit :) Gratulacje panowie! Przychodząc ze świata c64 od razu wyobrażam sobie jak to praktycznie użyć tak by nie tracić za dużo czasu CPU i nie posiadając narzędzi takich jak sprzętowa synchronizacja (WSYNC) zsynchronizowałbym się raz na początku ekranu a później miał procedurę gdzie bym przeplatał kod robiący coś co będzie efektem z kodem który powoduje wyświetlanie odpowiednich bajtów przez ANTICa i tak przez 240 linii rastra. "over-screen" demo jak najbardziej w zasięgu :)
Tak trzymać @2024-01-08 09:27:46
Światowa premiera!
Cyprian @2024-01-08 10:31:29
Świetna robota Panowie.
Swoją drogą to Atari to jednak dobre było w marketingi. Wiedzieli że szeroka ramka w hiresie ma 352 piksele, ale w dokumentacji dali 384 bo wyglądało ładniej.
Dam sobie paznokieć uciąć, że przy różnych wartościach HSCROL śmieci jest mniej lub więcej.
mono @2024-01-08 14:11:20
Tak, bo pokazywana jest nie tylko górna połówka bajtu, ale i dolna (treść jest w końcu przesuwana w poziomie). Ale szerokość ekranu nadal się nie zmienia.
Yosh @2024-01-08 19:15:44
Zostało to wykorzystane w jednej pracy na wild Silly Venture w 2018r :)
A ja się podniecałem kiedyś (30 lat temu jak nie więcej) artykułem o usuwaniu czarnych marginesów w trybie tekstowym (gr.0) w Basic... Kilka poke i efekt robił wrażenie na zielonym Neptunie... co prawda słabo się pisało na ekranie (edytor Atari Basic się z tym nie lubił, ale to nie był problem w programie). A tu proszę - wyszliśmy znacznie dalej. Quo Vadis, Atari 8-bit?
Brush - dzięki! Nasz artek pobudził kilku koderów co najmniej do rozmowy, więc jesteśmy dobrej myśli. A dotychczas to było tak, że niektóre emulatory i przeglądarki pokazują 336 pikseli szerokości i basta, bo tak ma być :P. We change the world ;)
streak @2024-01-19 10:09:58
Fajna nazwa, przypomina tytul manifestu politycznego partii lewicowej :) buhehe
mono @2024-02-12 12:59:33
@streak: I ten różowy :) Ale to by było right-wing wtedy.
Całość 2934 MB
0-9
