szkoda, bo brakuje takiego minimalistycznego DOS-a, trzeba ładować wszystko do pamięci
pozatym 'DOS' w nazwie jest mylące, w końcu Disk Operating System to trochę więcej niż załaduj i uruchom
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Command & Conquer na Atari ST Kultowy RTS Command & Conquer zmierza na Atari ST. Zobacz niesamowity port legendarnej strategii.
Altirra 4.50 test 13 Avery Lee udostępnił kolejną wersję testową najdoskonalszego emulatora Atari.
CT60 TOS 1.03e Po blisko 21 latach ukazała się oficjalna aktualizacja CT60 TOS do wersji 1.03e.
Gearlynx 1.2.14 Ukazała się kolejna odsłona zaawansowanego emulatora Gearlynx dla konsoli Atari Lynx.
Premiera magazynu Atari Legacy Już jutro startuje sprzedaż nowego magazynu drukowanego Atari Legacy, składanego na Atari Falconie.
atari.area forum » Posty przez tebe
szkoda, bo brakuje takiego minimalistycznego DOS-a, trzeba ładować wszystko do pamięci
pozatym 'DOS' w nazwie jest mylące, w końcu Disk Operating System to trochę więcej niż załaduj i uruchom
zastanawia mnie możliwość wykorzystania MSDOS-a, czy MSDOS instaluje jakiś handler, czy po wczytaniu głównego programu będzie można doczytywać inne pliki odwołując się w stylu:
d:>path>folder
a zdjęcie tego karta z Atarką jako skalą porównawczą można zobaczyć ?
bo nie można na pierwszej pozycji umieścić wartości absolutnej #, procka realizująca te operacje wyłożyłaby się
może rdzeń do VBXE bez pamięci dodatkowej, z pamięcią dodatkową
u mnie działa (VBXE, rdzeń z pamięcią dodatkową), ale SDX nie mam
eeee, kasowanie ekranu zrobić blitterem VBXE
dlaczego tracimy 5-y kolor? to już wiesz, zależy to od tego czy wystąpił on w pierwszym wierszu czy nie, jeśli tak to w kolumnie w której wystąpił mamy 5-y kolor
a 8 i 4 ostatnie linie to są tracone z powodu synchronizacji, jeśli synchro jest złe występuje ciekawy efekt postrzępienia znaków
ok, nowy G2F pozwala na wyłączenie "badlines" dla trybu GED+
adres ładowania pliku musiał zostać obniżony do $1000 inaczej plik nie mieści się w pamięci, w końcu to 30KB zestawów znaków i obszerny kod zmian rastra oraz pamięć dla PMG
pozatym dla wyłączonych "badlines" tracimy 5-y kolor, pierwszy wiersz obrazu i ostatnie 4 linie obrazu, tak więc graficy nie mają się co podniecać, wyłączenie "badlines" przydać się może bardziej w demie w stylu "Ilusii"
no niech Wam będzie, gratulacje
udało się, z pierwszym wierszem są kłopoty, potem już idzie OK
tak że badlines można usunąć z pomocą VSCROL-a
kod wymaga jeszcze dodatkowych testów na jakiejś sensowniejszej zawartości obrazu
ok, będę starał się pozbyć się tych bad-lines czyli miejsc w których ANTIC zabiera najwięcej czasu CPU, byle potem Fox nie napisał że opanował już to wszystko w końcu lat 80-tych i schował do szuflady
tak na oko sprawa sprowadza się do oszukania ANTIC-a i "wmówieniu" mu że wiersz składający się z 8 linii nigdy się nie kończy, co pewnie oznacza że w każdym wierszu będą te same znaki a to oznacza że co wiersz trzeba zmieniać zestaw znaków, czyli pewnie wiersze będą wysokości 7 linii i będzie trzeba zużyć jakieś 34 zestawy (34 KB) aby pokryć całe 240 linii obrazu
niezłe marnotrawstwo, skoro tylko 32-48 znaków np. z początku każdego zestawu będzie tylko wykorzystanych, reszta do spożytkowania w inny sposób
skoro ANTIC reaguje na zmiany zestawu w linii, może to oznaczać że obliczenia adresu znaku dokonuje na bieżąco, a pierwsza linia każdego wiersza służy mu do np. zbuforowania wiersza, czyli odczytania wiersza bajt po bajcie i zapisaniu w swojej pamięci wewnętrznej
podsumowując, w teorii - pierwsza linia ekranu będzie bad-lines pozwalająca zbuforować ANTIC-owi wiersz, potem zostanie zablokowany VSCROL-em licznik linii wiersza tak aby ANTIC nigdy nie dokonał ponownego buforowania, znaki charsetu będą odpowiednio przycięte - o 1 linię krótsze, co 7 linii zmiana charsetu
zdjęcie OK, oprócz tego że kolory są inne
kiedyś próbowałem zmienić zestaw znaków w linii, widocznych efektów nie udało się zauważyć, przyjąłem więc że ANTIC nie pozwala na tego typu przekręty
okazuje się jednak że można zmienić zestaw znaków w linii, z tym że nie od dowolnego miejsca
w załączniku przykład intensywnego zapisywania do rejestru CHBASE dwóch adresów zestawów znaków (różnią się kolorem, kolor źółty to CHARSET #0, kolor niebieski CHARSET #1), jak widać udaje się dokonać do 8 zmian w linii (na 15 zapisów rejestru CHBASE), podejrzewam że są to miejsca w których plamka jest wyrównana do początku znaku, w pozostałych przypadkach kiedy próbuje się zmienić CHBASE w trakcie rysowania znaku zmiana CHBASE jest ignorowana, lub ma to jakiś związek z czasami w jakich ANTIC pobiera dane
puste linie 0,8,16 itd. to tzw. bad lines, w nich ANTIC dokonuje dekodowania znaków, aktualnie w pamięci obrazu są same zera
do czego można spożytkować zmiany zestawów znakowych w linii? jakieś pomysły?
"bad lines" się nie pozbędziemy, przełączanie zabiera czas CPU, w końcu jest to tryb GED+
p.s.
Atari800Win wyświetla poprawnie, Altirra nie do końca
kiedyś IK+ podejmował podobne próby, doszedł w końcu do wniosku że bez ingerencji we wnętrze GTIA naprawa się nie uda
nie lepiej zebrać te wszystkie informacje dotyczące GTIA w jedno miejsce, aby nie trzeba było odkrywać tego co inni juz odkryli
P.S.
za n-tą liczbę lat będą rozgryzać znaczenie mnemonika LDA
dodaj do tego ruch i jeśli starczy Ci wyobraźni zrozumiesz
przecież asteroidy nie są wypełniane tylko druciane, jak to może brzydko wyglądać, krawędzie będą wyraźniej zaznaczone gdy dwie asteroidy najdą na siebie, dla Hires XOR będzie wyraźniej eksponował wszystkie elementy gry
do mads-a są załączone przykłady także XOR dla trybu kolorowego
każdy duch ma flagę sygnalizującą pierwsze wywołanie ducha
1. jeśli to nie pierwsze wywołanie to XOR starej pozycji X:Y starą klatką ducha, ustaw flagę wywołania ducha
2. XOR na nowej pozycji X:Y nowej klatki ducha (parametry X:Y i numer klatki zapamiętaj)
3. jmp pkt.1
p.s.
przykład wykorzystania będzie można zobaczyć w intrze do Panga, tam w sumie w pierwszej ramce wywoływane są 4 duchy, w drugiej ramce kolejne 4 duchy (razem 8), tylko dzięki zaletom XOR-a udało się to zmieścić w pamięci
przyrosty każdego ducha (kuli) są różne, tak dla X-a jak i dla Y-a, dodatkowo pojawiają się napisy na tych ruchomych obiektach i wszystko jest OK
a dlaczego nie użyć metody XOR dla obiektów, nie trzeba czyścić całego ekranu, samo się czyści, metoda XOR jest idealna gdy tło jest jednolite (Gremlins, Mario Bros korzystają z tej metody i na pewno więcej tytułów z lat 80-tych), nie wspominając o jej małej zasobożerności
http://www.madteam.atari8.info/vbxe/plasma_vbxe.7z
plasma liczona przez CPU 6502, piksle "konopowe", 256 kolorów
dotychczasowe dema dla XE/XL charakteryzują się w większości czarnym (jednolitym) tłem i jakimś efektem na tym tle, taki VBXE daje swobodną możliwość wprowadzenia designu, czyli ozdób, dodatkowej grafiki itp. można sobie wyobrazić demo działające na GTIA, a w przypadku VBXE wzbogacone o dodatkową grafikę, co wpłynęłoby tylko na objętość pliku a nie na obciążenie 6502
nawet prosty efekt typu plasma z odpowiednio skomponowaną grafiką robi większe wrażenie niż taka plasma z czarnym "łysym" tłem
64kb pamięci VBXE czyści się jak i wypełnia blitterem, to dla normalnych, dla mniej normalnych zostaje użycie 6502 w tym celu
nie jestem ekspertem od SDX, ale HDD formatowałem, bodaj partycje 16MB, z tym że dokonuje się tego odpowiednim programem
to może jak już sprawdzisz to napiszesz co faktycznie masz a nie co możesz mieć ale wcale nie musi być to prawda
stuknij się w czoło Jacques
napisałbym czemu tak kiepsko gra, ale Candle mógłby się obrazić ;)
ojej, chłopak nie liczy koloru tła, stąd wychodzą mu tylko 3 kolory
atari.area forum » Posty przez tebe
Wygenerowano w 0.099 sekund, wykonano 18 zapytań