Pecus, z tym handlerem chodzi o to aby była możliwość skopiowania obszaru pamięci z jego kodem i przywrócenia działania handlera, czyli taki zunifikowamy loader z możliwością przechowywania jego kodu w buforze

Sparta SDX wydaje mi się zbyt skomplikowana aby można skopiować obszar $700..$2000 i liczyć na to że ruszy

p.s.
nie chodzi o w pełni funkcjonalny Sparta Dos, chodzi o możliwość współpracy z urządzeniami z którymi teraz współpracuje MSDOS

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

a zdjęcie tego karta z Atarką jako skalą porównawczą można zobaczyć ?

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

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

no niech Wam będzie, gratulacje

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

dodaj do tego ruch i jeśli starczy Ci wyobraźni zrozumiesz

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

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