Trzeba by to może trochę uściślić.

GTIA jak wiadomo potrafi wyświetlać różne kolory zależnie od modelu więc obraz wychodzący z wyjścia monitorowego może wyglądać tak naprawdę inaczej u każdego użytkownika. Tej wady pozbawione jest VBXE, gdzie można ustawić dowolnie paletę kolorów i obraz wychodzący z wyjścia RGB powinien wyglądać u każdego tak samo (pomijam ustawienia temperatury kolorów telewizora/monitora).

Jeśli grafik przygotowuje grafikę np. w G2F i używa konkretnej palety kolorów, to może dołączyć do grafiki paletę w formacie .ACT (Adobe Color Table) lub .PAL (JASC Palette) i zażyczyć sobie zaprezentowania pracy na VBXE z ustawioną takąż paletą kolorów tak, żeby partyzanci mogli podziwiać efekt o jaki mu chodziło. Należy jednak pamiętać, że VBXE (zarówno z rdzeniem FX jak i GTIA) źle emuluje efekt zmiany trybów graficznych w linii więc grafiki wykorzystujące tą właściwość GTIA mogą być wyświetlane niepoprawnie. W takim przypadku lepiej wyświetlić obraz z wyjścia monitorowego, pomimo że kolory z parcianego egzemplarza Atari mogą nie do końca odpowiadać wyobrażeniom autora.
Z każdym innym przypadkiem VBXE z rdzeniem GTIA powinno sobie poradzić.

Edit: Nie chciałbym wam komplikować, ale proponowałbym żeby autor mógł zażądać prezentacji pracy w określonych warunkach:
- GTIA przez wyjście monitorowe,
- VBXE z paletą autora przez wyjście RGB,
- dowolne wyjście video.

Opisany problem dotyczy tylko prac dla GTIA. Prace dla VBXE są prezentowane przy użyciu formatu .BMP, który zawiera informację o barwach.

Edit 2: VBXE domyślnie używa palety LAOO.

Na dwóch, bo wydaje mi się, że z rozpędu Autor użył AUDC2 do zgrubnego ustalania poziomu membrany, a mógł to zrobić  za pomocą AUDC3 (sprawdziłem, ale odsłuch mogę uskutecznić obecnie tylko na emulu). Tak więc na jednym POKEY-u można generować dwa sample 8-bit parami: AUDC1+3 oraz AUDC2+4.
Ech dlaczego sam na to nie wpadłem, żeby pikiem generować podpoziomy na drugim kanale :]

Ja również dziękuję. Odpocząłem wreszcie :) Do następnej razy.

A gdzie ten konwerter?

To prawda. Nie musi bo udostępnia ATR-a do zabootowania z własnym loaderem. Mógłby w ogóle nie mieć żadnego FS-a tylko zapisać pełne sektory sekwencyjnie.
Ale skoro jednak jest wystawiany katalog i VTOC, to miło byłoby żeby poprawnie były tam uzupełniane:
- id FS-a (2, lub 3 zależnie od tego czy jest to DOS 2.0 z gęstością SD/ED, czy MyDOS),
- ilość wszystkich sektorów na dysku.
Obecnie total sectors we VTOC jest identyczne z ilością sektorów pliku zapisanego w directory, a przecież dodatkowo są BOOT sektory, VTOC i directory.

No to naprawdę zajebiście. Gratuluję.

Edit: Przepraszam. Total sectors ma poprawną wartość.

http://atariki.krap.pl/index.php/GTIA
Nie wiem jak od strony elektronicznej działa GTIA i nie wiem którymi liniami ANTIC informuje go o kolorze/trybie pracy (ANx?). Może tu gdzieś w opóźnieniach leży pies pogrzebany?

Edit: Aaaaa nie wchodzisz przecież między ANTIC-a i GTIA.

$400..$6FF oidp to jest obszar w który często ładuje się kod inicjalizacyjny sterowników. Ten obszar jest nieużywany podczas normalnej pracy systemu kiedy wszystko co Ci jest potrzebne już jest załadowane i na 6 stronie raczej nic nie powinno Ci niczego modyfikować.
Jeśli dobrze pamiętam TBXL z jakichś względów sugeruje użycie 6 strony w obszarze od $680..$6FF a nie całej, ale nie pamiętam dlaczego. 5 strona to obszar bufora FP i INPUT-a, 4 strona to obszar buforów IO.

Ładnie! A jak się nazywała oryginalna kompozycja Rastera?

Czyli, jeśli dobrze rozumiem, są dwie konfiguracje:
1. Altirra z podłączonym obrazem hdd ide+/side2 np. na D1: i dyskiem atr na D2:
2. Atari z ide+ hdd na D1: i sio2pc na D2:
W obydwu konfiguracjach atr znajduje się w chmurze i on służy do backupowania danych. Backup/odtwarzanie D1: na/z D2: robisz batem.

A jakbyś miał obraz hdd ide+/side2 ulokowany w chmurce kiedy korzystasz z Altirry? Odpadła by chyba konieczność backupowania batem przynajmniej kiedy pracujesz na Altirrze.
Podczas pracy na Atari trzeba by mieć ten obraz zamapowany przez sio2pc i sektorowym kopierem go aktualizować na hdd.

W ogóle to bardzo mi się spodobał pomysł wykorzystania chmury na Atari :) Teraz trzeba by mieć w Atari sieć, żeby móc aktualizować obraz bez sio2pc :)

Rzeczywiście. Całe poprzednie życie używałem XF-551 i bardzo lubiłem tę stację. Nawet mając szczątkowe informacje że komendy w turbo się wysyła z inwersem zrobiłem sobie SIO które to obsługiwało ale nie miałem pojęcia, że to jest Synchromesh :) Dzięki.
P.S. Odwróć cytowanie.

Warto się przyjrzeć komendom typu DOWNLOAD/EXECUTE bo jeśli chciałbyś mieć synchromesha czy kompatybilność z rozszerzeniami TOMS to chyba trzeba by zapewnić możliwość przesłania i wykonania kodu w środku stacji. A w różnych stacjach są różne procesory. No i taktowanie też pewnie inne. No i adresy procedur w ROM-ie.

Edit: Ktoś mądrzejszy mógłby się wypowiedzieć w kwestii, bo jedyne komendy które ja wysyłałem do stacji to !"NOPRSW :)