:cool:
brawa dla tego Pana
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNetChat: Nowy klient IRC dla Atari Pierwsza publiczna wersja alfa FujiNetChat, nowoczesnego klienta IRC wykorzystującego interfejs FujiNet.
Gearlynx 1.2.2 Gearlynx doczekał się aktualizacji. Wprowadzono podgląd SCB, wyszukiwanie w pamięci oraz poprawki.
Wyniki FujiCup 2025 Poznaliśmy najlepsze gry na 8-bitowe Atari wydane w 2025 roku według jury oraz publiczności.
Wyniki konkursu i gala FujiCup 2025 Poznaj zwycięzców dorocznego turnieju FujiCup 2025 wspierającego twórców gier na Atari XL/XE.
Fujisan 1.1.8 Nowa wersja emulatora Fujisan przynosi wsparcie dla FastBasic oraz poprawki błędów w obsłudze dźwięku.
atari.area forum » Posty przez tebe
:cool:
brawa dla tego Pana
VBXE1 i 2 nie ma tyle pamięci aby spełniać wszystkie zachcianki, nie po to był projektowany, trzeba wyrzucić wszystkie VBXE1 i VBXE2 do kosza i wypuścić VXBE3 z 1GB na pokładzie za 1000 zł, żeby XXL miał swoje z80, Probe GForca, Draco CPM-a i GEM-a, dodatkowo sprzętowy dekoder MP3, DIVX i H264, player MOD-ów itd.
VBXE miało być rozszerzeniem możliwości GTIA i tak się stało, teraz Candle i Electron muszą zginąć w tragicznym wypadku aby VBXE stało się standardem same w sobie, w obecnej postaci, albo sami bez ingerencji boskiej zakończyć ten projekt
komu będzie chciało się pisać soft na n-tą liczbę rdzeni i wersji, napiszesz coś i za chwilę okaże się że musisz coś zmienić bo już nie działa jak wcześniej
"coś tam zmącić w rdzeniu" ;) czyli poprawić dotychczasowy rdzeń, pozbywając sie części jego dotychczasowych możliwości z powodu braku wystarczającej pamięci, np. zamiast 4-ech palet kolorów będą tylko 2-ie, czyli taki Mr.Proper nie będzie działał na VGA
a może bardziej ekstremalne kompo, kto dłużej wytrzyma na party będąc trzeźwym
disassembly, rewrite code, write binary
nie pociągnie, prawie każdy tytuł z C64 będzie trzeba przepisać pod VBXE + Weronika
tyle to każdy g.... potrafi, ale nie każdy potrafi z malucha zrobić mercedesa :)
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
Pecus, Pirx, jest możliwość udostępnienia źródeł, coby Pajero dopisał co nieco, tak aby był odczyt przez handler D: i parę innych spraw ?
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
atari.area forum » Posty przez tebe
Wygenerowano w 0.098 sekund, wykonano 25 zapytań