Zainteresuj się Fat Agnusem z Amigi i jego możliwościami. Tam jest tryb tzw. HAM6 i on nie wymaga 40+253 nóżek ani 8 czy 12 bitów. Wymiksuj tą ideę z Anticem i GTIA na Atari na tym co już jest - będziesz miał jakiś Ham4 czyli na  4 bitach jak się nie mylę 256 kolorów w zasięgu ręki.. I nie zabijesz procesora i ramu ilością danych do przemielenia. 4 bity grafy w takim trybie to REALNE rozwiązanie dla 8 bitowej maszyny - no i mniej lutowania  ;)

@laborant:

Dzięki, przejrzę dla świadomości ogólnej rozwiązań proponowanych, ale od razu boję się na wstępie myśląc o "technikach" jakichś, żeby coś uzyskać - podobnie, jak na PC-tach co robiono w latach 90-tych i potem, jakieś dopalacze, coolery, podkręcanie procesorów, etc. - takie wrażenie mi przyszło do głowy - takich rzeczy nie tykam zasadniczo, oczywiste. Coś jak z pakowaniem partycji dysków, sterowanie częstotliwością wyświetlania, czy nawet te dynamiczne sterowanie ANTIC typu "soft-driven", czy jakoś, że pełno kolorów na XL/XE w sposób sztuczny, a na dodatek dynamiczny (podmiana ramek w cyklu 25 na sekundę, czy 50-ciu - i robi się wrażenie kolorów), co aż strach o tym myśleć i strach dotykać, oczywiste.

Skoro XL/XE ma standardowo i "spokojnie " (stabilnie inżyniersko - technicznie) 4 kolory na stabilnych 2 bitach i 2 kolory na 1 bicie, to musi być tak samo dla 4 i 8 bitów. Skoro dla 4 kolorów potrzeba 4 pinów, no to dla 256 kolorów potrzeba 256 pinów - kosmos! Nie dziwne, że firma Atari nie zrobiła NAWET! 16 kolorów, wydaje się to teraz oczywiste nawet chyba, oczywiste.

Czyli zostawiono układy graficzne obsługujące tylko 1 bit i 2 bity danych - wydaje się, że niemożliwością byłoby zrobienie następnego kroku, czyli 4 bity na piksel - utrzymując ten sam standard inżynierskich rozwiązań, jak w dokumentacji do ANTIC i GTIA. 4 bity zmienia układ w 16 pinów, natomiast 8 bitów w 256 pinów. No kosmos zupełny, oczywiste.

Więc na tym etapie są dwie drogi: albo 256 pinów dla ANTIC i byłby to 100% standard architektury original ANTIC Atari Inc, lub... no i teraz by można przynajmniej najlepiej możliwie inżyniersko, zgodnie z oryginałem, chociaż modyfikując, czyli zostawić piny aktualne dla 1 i 2 bits per pixel, żeby zachować 100% kompatybilność w zakresie oryginału, i teraz dopiero dorobić piny w innej obsłudze dla informacji o kolorach, czyli zamiast jeden pin na jeden kolor, to puszczać informację po 6 dodatkowych bitach (pinach), wyjdzie jakaś szyna danych zwyczajna, odpowiedzialna tylko za informację o kolorach uzupełnionych o 252 (4 standard + 252 = 256). Jasność osobno, ale jasność trzeba określić dla wielu dodanych kolorów, więc na GTIA wyjdzie dodatkowa magistrala (powtórzenie takiej samej, jaka już jest) i będzie 256 kolorów w 256 odcieniach, a nawet chyba 256x256 kolorów w 256*256 jasnościach (odcieniach). Bo dla standardu jest 16 kolorów w 16 odcieniach, a nie 4 kolory w 4 odcieniach.

Hmm... trzeba to raz rozpisać i mieć gotowe, etapami... dzięki za info, przejrzę te HAM-y, z ciekawości, jak to porozwiązywano tam na Amidze.

@mono:

Te liczby (zakresy) brzmią genialnie. Jakby przystosowane do dalszej przebudowy ANTIC i GTIA, czyli 640x480 lub 768x512.

Etapami, najpierw tabelki, potem zakresy, osiągając 100% Full, co może XL/XE standard, w zakresie projektu, zobaczymy, czy da się iść dalej, czyli podwojenie rozdzielczości, jak wyżej (640x480, 768x512).

Trzeba iść standardem, nie inaczej, oczywiste.

Dzięki za info, posprawdzam.

Ale naprawdę jestem jedyny, który nie może przebrnąć przez te wpisy @Smaku, bo pod koniec zdania nie wiem jaki był jego początek i jaki sens niesie?

Dokładnie tak, dzięki. Jeszcze wczoraj po zamieszczeniu tej wstępnie przygotowanej tabelki spojrzałem ogólnie i od razu widać, że kolumna z ilością bajtów na linię (bytes per standard line) jest zupełnie na pierwsze spojrzenie nie do zaakceptowania, oczywiste - starałem się liczyć i liczyć, żeby to jakoś wyliczyć, ale wyszło mi, że chyba powinno być 320 bajtów, a nie 40. Hmm...

I teraz od nowa:

8 bits per pixel (8 bitów na jeden piksel, czyli 1 bajt), pikseli jest 40 w linii, czyli 40 bajtów. Hmm... kurde, i teraz znowu nie wiem, wychodzi, że dobrze. I tak w kółko. Jakiś elektronik musi to sprawdzić dokładnie, oczywiste.

Gdyby ktoś wiedział, jak uzupełnić pole Colors per mode dla trybu IR 8. W oryginalnej dokumentacji dla normalnych trybów jest wartość 1.5 (półtora). Jak to przeliczyć na 4 bity na piksel?

I druga rzecz: jak działają te Color clocks per pixel? Jakie wartości tych color clocks powinny być? Z czego to wynika? I czy np. zwiększając w układach możliwy zakres, czy przydział tych Color clocks dla piksela, można osiągnąć nie tylko więcej kolorów, ale i wyższą rozdzielczość? Jak działają te Color clocks? - trzeba to zrozumieć i uzupełnić. Hmm...

Kiedy coś wydaje mi się oczywiste, to tak opowiadam, oczywiste. Jeśli się zgadzam z kimś, to potwierdzam, przykładowo, że "dokładnie tak", nawet mimo, że możliwe, że absolutnie nie, bo patrząc ponownie na te bajty, wychodzi, że jednak chyba jest dobrze, hmm... jednak wczoraj miałem dokładnie to samo wrażenie, że wszystkie liczby z tej kolumny bajtów na linię są źle policzone, dlatego się zgodziłem, że dokładnie tak samo miałem wrażenie, chciałem to dzisiaj poprawić w tej tabelce, ale teraz  znowu liczę i wychodzi, że jest dobrze, hmm... no i kurde, potrzebny jest jakiś elektronik, który by się znał, oczywiste.

@gorgh:

Potwierdzam 100%. Oczywiste.

Jednak wrażenia z reguły mnie nie mylą, oczywiste.

Co do braku pojęcia, o czym mówię, to nie zgadzam się 100%, oczywiste.

Co do mojego przypadku, to nie jestem pewien, hmm... ale prawdą jest o tych głupich, potwierdzam, tak jest, to oczywiste i logiczne w logice rozumnej, oczywiste. W logice nierozumnej byłoby i tak 100% obojętne, oczywiste.

Hmm... moje potwierdzenie 100% zaczyna zniżać swoją wartość procentową ze względu na detale, których nie można potwierdzić, hmm... oczywiste chyba. Ciekawe... muszę wszystko przeanalizować logicznie, zanim udzielę prawdziwej odpowiedzi na informacje uzyskane, oczywiste. Proszę czekać...

Bezrobotny wrócił???

Dla wszystkich zainteresowanych: słowo "oczywiste" padło (tylko w tym wątku) 73 razy.
Czuwaj!

Przepraszam, że trochę pojadę offtopem, ale co do Pascala, to pamiętam, że Smaku napisał kiedyś emulator 6502 w TurboPascalu 5.5. Ciekawe czy skompilowałoby się pod MadPascalem i uruchomiło na Atari.
To byłoby coś: emulator 6502 na 6502.
Smaku, masz źródła?

Aktualny wynik to 83 :)

Polecam zatem to: https://www.youtube.com/watch?v=1KGrciINqeY

@bocianu:

Przejrzałem pobieżnie ten Mad-Pascal, co to jest w ogóle, i wygląda na dość ciekawą rzecz jakąś. Zaciekawiło mnie to, od razu zacząłem myśleć, czy cokolwiek napisane w TP 5.5. na PC, co w miarę spełnia jakieś zakresy możliwe do realizacji na XL/XE, może po skompilowaniu pójść jakimś cudem nieznanym na Atari XL/XE. No coś genialnego to musi być na pierwsze wrażenie, oczywiste. Ciekawe, jaki zakres trybów graficznych XL/XE jest obsługiwany przez ten Mad-Pascal. Coś mi trochę śmierci "C", ale może to tylko wrażenie, musiałbym dokładniej przejrzeć tego Mada...

Tak czy inaczej, jeśli ten Mad-Pascal utrzymuje standard Turbo Pascal 5.5. dla kompilowanych kodów źródłowych, tj. jeśli wszystko z TP5.5. daje się standardowo automatycznie skompilować na tym Mad-Pas, to powinno się dać, oczywiste.

Tylko odpowiedź jest oczywista w kwestii zadziałania kodu wynikowego na Atari XL/XE: na pewno NIE może zadziałać w całym (pełnym) zakresie programu, to oczywiste. Chociażby 64kB RAM Atari XL/XE - tyle jest minimalnie zasadniczo potrzebne w programie jako obszar RAM XL/XE - zarezerwowany dla pracy programu z taką pamięcią XL/XE dostępną, do tego ROM, do tego kod programu, do tego inne zmienne wykorzystywane w programie, etc. - no więc gdzie i jak mógłby się uruchomić emulator XL/XE, jeśli próbować to uruchamiać na XL/XE. Nie jest to oczywiste? Pewnie zawężając zakresy RAM, ustawiając parametry odpowiednio emulatora przed kompilacją do kodu na XL/XE - dałoby się jakoś uzyskać "fragment" XL/XE emulowanego na XL/XE. Myślę, że powinno spokojnie pójść i działać, oczywiste.

Co do udostępnienia kodów źródłowych, to samemu powinno się wiedzieć, oczywiste.

A ja twierdze z uporem maniaka, ze SMAKU to boot. Oczywiste :)