Na "wadliwym GTIA" wygląda to tak:

Hej!

Też kiedyś próbowałem takiej zabawy, ale mi wyszło że to nie działa :) Jak widać się myliłem...

Jak zapewne niektórzy wiedzą, VIC który znajduje się w C64 ma pełny 256 znakowy zestaw fontów, zawsze im tego zazdrościłem bo można było sobie ładnie ekran zorganizować do wektorów wypełnianych metodą blitter-ową (XOR,STA), w pamięci obrazu robili sobie coś takiego:

$00,$10,$20,$30,$40,$50,$60,$70,$80,$90,$A0,$B0,$C0,$D0,$E0,$F0
$01,$11,$21,................................................$2F
$02,...
$03,...
$04,...
$05,...
$06,...
$07,...
$08,...
$09,...
$0A,...
$0B,...
$0C,...
$0D,...
$0E,...
$0F,........................................................$FF

Chyba nie muszę mówić jak szybki był na tym blitter-draw ;) potem blitter-fill i mamy piękne duże wektory, ba nawet glenz-wektory jak usuniemy zasłanianie ścian. W przypadku ATARI byliśmy ograniczeni wielkością zestawu znaków do 128.

Kiedyś (okolice po 1995 roku) sobie wymyśliłem sobie iż można by podzielić ekran w połowie szerokości (dwa zestawy) jeden z lewej strony, drugi z prawej strony ekranu... Fonty zorganizowane jak w przypadku C64.... czyli mniej więcej coś takiego:

$00,$10,$20,$30,$40,$50,$60,$70 | $00,$10,$20,$30,$40,$50,$60,$70|
$01,$11.....................$71 | $01,$11.....................$71|
$02,$12.....................$72 | $02,$12.....................$72|
$03,$13.....................$73 | $03,$13.....................$73|
$04,$14.....................$74 | $04,$14.....................$74|
$05,$15.....................$75 | $05,$15.....................$75|
$06,$16.....................$76 | $06,$16.....................$76|
$07,$17.....................$77 | $07,$17.....................$77|
$...........................$78 | $...........................$78|
$...........................$79 | $...........................$79|
$...........................$7a | $...........................$7a|
$...........................$7b | $...........................$7b|
$...........................$7c | $...........................$7c|
$...........................$7d | $...........................$7d|
$...........................$7e | $...........................$7e|
$0f,$1f,....................$7f | $0f,$1f,....................$7f|

jednak wtedy nie udało mi przełączyć zestawu w środku linii... jak widać byłem zbyt mało cierpliwy :) teraz można by to zrealizować, rysowanie linii przy takiej organizacji ekranu  mogło by być równie szybkie... a zmianę zestawu w środku linii można by dokonywać podczas blitter-fill (EOR, STA).

Drugi pomysł to "logoser" bazujący na przełączaniu zestawu w środku linii... ale pomysł chyba nie-efektywny czasowo... chyba łatwiej mieć więcej zestawów nić bawić się w podział poziomy i logos-owanie niezależne dla dwóch odrębnych obszarów tak aby zmieściły się w jednym zestawie znaków ;)

pozdrawiam
Seban

ps) właśnie sobie uświadomiłem że o kant dupy potłuc moje pomysły... BAD-LINES wszystko załatwiają... ja chyba właśnie próbowałem zmienić CharBase w pierwszej linii i dlatego mi nie wychodziło ;)

Ostatnio edytowany przez seban (2010-04-13 13:36:03)

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

Jeżeli będziemy mieć tylko jedną bad line na początku ekranu, to stracimy możliwość manipulacji bitem inwersu (5-ty kolor), co znacznie ograniczy zastosowania takiego trybu.

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

Ostatnio edytowany przez tebe (2010-04-15 20:55:40)

Dlaczego?