dokładnie, nie wykorzystujemy pełnej wysokości, najczęściej pole gry ma 24, 25 wierszy
FireNIce korzysta z MCM i jak widać starcza czasu
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Gearlynx 1.2.15 Emulator Atari Lynx doczekał się ważnej aktualizacji z wieloma nowymi funkcjami.
STOS BASIC V5.5 Alpha Popularny język programowania dla Atari ST powraca po ponad 30 latach w nowoczesnej wersji.
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.
atari.area forum » Posty przez tebe
dokładnie, nie wykorzystujemy pełnej wysokości, najczęściej pole gry ma 24, 25 wierszy
FireNIce korzysta z MCM i jak widać starcza czasu
Multi Color Map (MCM)
- ekran znakowy (ANTIC 4) szerokości 40 bajtów (160 pikseli), wysokość 30 wierszy (240 linii)
- sprite/pocisk 2-3 szerokości poczwórnej pokrywają całą szerokość ekranu (160 pikseli), piorytet = 0
- na całej wysokości ekranu CPU jest maksymalnie obciążony (100%)
- występują badlines, wyłączenie ich oznacza utratę kontroli nad COLOR3 (inwers znaków)
- pole mapy (4x8) ma wysokość 8 linii i szerokość znaku (1 bajt)
- sprite/pocisk 0-1 można użyć wg uznania, nie jesy wykorzystywany przez mapę kolorów
- do dyspozycji są 4 palety kolorów po 4 kolory każda
- palety różnią się pomiędzy sobą jednym lub dwoma kolorami
- w polu 4x8 pikseli można użyć tylko jednej z tych 4-ech palet
- możliwe są dodatkowe zmiany rejestrów co wiersz
w załączniku program do edycji MCM dla Windows (mcm_v14.zip)
paleta kolorów ma specyficzny układ i nie jest on przypadkowy
w zakładce Edit Palette widzimy na pierwszym miejscu kolor szary ($04) COLOR 0, następnie kolor czarny ($00) COLBAK
ten układ nie jest przypadkowy, jest zamierzony, pozwala maskować piksle mapy kolorów, które składają się z ducha/pocisku 2..3
chcemy widzieć pojedyńcze piksele mapy a nie cały blok 4x8
rysowanie polega na wybraniu 1 z 4 palet P0, P1, P2, P3, widocznej w zakładce Cell Palette
każdy poziomy wiersz wyznacza paletę z 4 kolorami których możemy użyć w polu 4x8 piksele
w polu 4x8 pikseli nie ma możliwości mieszać palet, może zostać użyty zestaw kolorów tylko z jednej palety P0,P1,P2 lub P3
Tebe: Sz, S1, Nz, N2
Przelew na 110 zł poszedł.
Pz, P2
tylko patroni i wspierający mogą dokonać zakupu ;)
gdyby była możliwość kliknięcia łapki w górę, kliknąłbym :)
użyj CMC które ma to poprawione :)
a to niby co jest?
gdzie widzisz kod dekompresora dla 6502 ?
tam chyba chodzi o nazwę D: ; D1:, była jakaś wersja z patch-em
ten z załącznika wyświetla DIR
https://github.com/tebe6502/Mad-Assembl ... n/packfire
działa tylko z PackFire 1.2
8bitGuy to X16 Commander, najnowsza rewizja jego płyty przechodzi na FPGA, bo te scalaki które można było nabyć to już nie można nabyć
wytłumaczone "bad lines", efekt zoom-x na znakach
może nie wszyscy jeszcze się z tym zapoznali
za długo leżałeś pod kamieniem
ciekawe czy Lotharek podziela Wasz entuzjazm
IrfanView pozwala zapisać w wybranym Bits Per Pixel (Image -> Increase Color Depth...)
ogólnie 8bits Per Pixel jest uniwersalnym wymogiem aby pozyskać obrazek w trybie indeksowym, bitmapa z kodami palety (0..255) i paleta z kolorami RGB
wyniki są zależne od aktywnie wybranej palety (View -> Palette), ten sam obrazek będzie inaczej wyglądał kiedy wybierzemy G2F.ACT, inaczej dla ALTIRRA.ACT, G2F dokonuje mapowania wszystkich kolorów do wybranej palety Atari
pomaga włączenie dither 2x2, inaczej rozłoży kolory (dla 2x2 nie zdoła nic zditherować przy małej liczbie kolorów)
SUN nic nie kombinował przy odczycie bitmap, co najwyżej programy mogą używać innych palet kolorów, a to jest brane pod uwagę przy odczycie BMP, PNG etc.
programy do zamiany BMP, PNG są dostępne też tutaj (pierwszy zapisuje do MCH, drugi tylko do MIC), pliki MCH, MIC można wczytywać do G2F
https://github.com/tebe6502/bmp2mch
https://github.com/tebe6502/bmp2mic
ogólnie operacje z unit PMG sprowadzają sie do manipulacji komórką 106 (RAMTOP), która wskazuje adres pierwszej wolnej strony pamięci
z RAMTOP korzysta też OS, kiedy otwieramy jakiś tryb graficzny czy znakowy
// poke(106,$40);
InitGraph(0);
writeln(hexStr(peek(106),2));
writeln(hexStr(dpeek(560),4));
writeln(hexStr(dpeek(88),4));sprawdź jakie wartości ma RAMTOP domyślnie, jaki adres DisplayList (560..561), jaki adres pamięci obrazu (88..89)
a potem odremuj '// poke(106,$40);' i sprawdź jakie wartości zostaną przyjęte, teraz wiesz co trzeba wpisywać żeby otrzymać przewidywany wynik
unit PMG tez korzysta z RAMTOP i cofa się względem tej wartości, co kończy się "najechaniem" na obszar pamięci obrazu
może lepiej podejrzeć przykłady które nie korzystają z unit PMG, tylko w podobny sposób jak w BASIC-u odwołują się do rejestrów GTIA/ANTIC odpowiedzialnych za grafikę PMG
https://github.com/tebe6502/Mad-Pascal/ ... vaders.pas
https://github.com/tebe6502/Mad-Pascal/ ... aviten.pas
trochę na temat architektury Atari trzeba wiedzieć żeby zmierzyś się z tym tematem
przykłady wykorzystania PMG są dostępne
https://github.com/tebe6502/Mad-Pascal/ ... /graph_pmg
ogólnie sprowadza się to do ustalenia właściwego adresu danych dla PMG, a nie dowolnego
http://atariki.krap.pl/index.php/PMG
brawo ten Pan :)
projekt jakiejkolwiek płyty na pewno przewiduje rozmieszczenie układów tak aby były odpowiednio chłodzone, umieszczanie układów jeden na drugim to proszenie się o kłopoty
potestuj ANTIC na obrazkach Rocky-ego
był na AtariAge wątek na ten temat
atari.area forum » Posty przez tebe
Wygenerowano w 0.103 sekund, wykonano 19 zapytań