Czy mogę zapytać w kwestii "Tajemniczego zamku", jako serii generalnie? Bo ostatnio przeglądałem stare Bajtki i znalazłem grę o tym samym tytule, lub podobnym, w sekcji "Dla Przedszkolaków", była to gra paragafowa, taki niebieski smok chyba tam był na obrazku, chciałbym wiedzieć, przed ewentualnym zakupem, czy to jest ta sama gra?

Postaram się odpowiedzieć wszystkim zainteresowanym niniejszym projektem, po kolei:

@robecc

Z nikogo nie wolno się wyśmiewać, to oczywiste. Szczególnie z ułomnych. Nie wiem, czy jestem ludziem, trudne do określenia, trzeba by ustalić / opisać typy prawidłowo jednoznacznie. Plucie jest zdrowe, tak samo jak rzyganie i inne każde wydalanie, to oczywiste. Zawsze polecam, organizm zawsze wie lepiej, dzięki temu zachowuje naturalne zdrowie i prawidłową funkcjonalność przez długi czas, oczywiste.

@pancio.net:

Zasadniczo jest tak, że co związane z teologią, jest zawsze 100% niepewne i poza zakresem logiki rozumnej, oczywiste, więc takie tematy jedynie dla tych spoza zakresu logiki rozumnej, to oczywiste, każdy wie, oczywiste.

@bocianu:

Warto zebrać 100% wszystkie zdania napisane przeze mnie na tym forum, które kończą się słowem "oczywiste" i określić jednoznacznie oczywistość, czyli 100% prawdę oświadczoną, potwierdzoną słowem "oczywiste" => wtedy będzie widać, że kiedy piszę "oczywiste" - oznacza to prawdę oczywistą, prawdziwą, bez względu na rodzaj logiki lub brak. Oczywiste.

Co do emulatora XL/XE w Turbo Pascal, to prawda, działa 100% perfekcyjnie. Źródła nie pójdą na XL/XE, bo kod korzysta z odwołań systemowych w architekturze PC 386DX 33MHz.

Możliwe, że kod skompilowałby się pod dowolną wersją Turbo Pascala, Borland Pascala, a nawet pod Delphi, ale nie wiem, czy pod zwyczajnym Pascalem. Zwyczajny Pascal nie obsługuje wielu rozwiązań, które są zaimplementowane w Turbo Pascal 5.5.

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.

@Mq:

Zgoda a propos programowania, ale ze zwróceniem uwagi, że sprzęt sprzętowi nierówny, więc programując w obojętne czym (kto co lubi, to sobie używa), nadal wykonuje program na sprzęcie. I w tym miejscu dopiero zaczyna być widać różnice w efektach, oczywiste.

Więcej nie zaśmiecam. Potwierdzam, prawda, true. amen.

@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.

Też o tym myślałem trochę. Nie znając TB XL, ciekawi mnie, czy taki zapis działa w tym języku programowania.

Jeśli działa, to teraz można się zastanowić, jak procesor wykona instrukcję z <> i tę drugą z NOT.

Jeśli <> procesor robi tylko jednym CMP, to wyjdzie szybciej chyba.

Jeśli procesor robi <> na dwóch CMP, to wyjdzie dużo wolniej, niż z NOT, oczywiste.

Instrukcja z NOT to tylko porównanie komórki pamięci z liczbą (=), a potem negacja - dwie proste instrukcje CPU.

Natomiast <> może być być może robione aż na dwóch CMP, bardzo długo wykonujących się. Hmm... ciekawe bardzo dość.

Trzeba by uczciwie zapisać obie instrukcje w asemblerze i będzie widać.

Żeby nikt nie mówił, że nic nie zrobiłem we własnym projekcie, początek tabelki dla trybów graficznych ode mnie:

OS and  Instr.  Colors  Pixel   Bytes   Scan     Colour   Bits
BASIC    reg.    per      per     per      lines     clocks    per
modes   HEX    mode   std.     std.     per       per        pixel
                                line      line     pixel     pixel
3         8            256     40      40     8         ?           8
4         9            16       80      40     4         ?           4
5         A            256     80      80     4         ?           8
6         B            16       160    80     2         ?           4
-         C            16       160    80     1         ?           4
7         D            256     160    160    2         ?           8
-         E            256     160    160    1         ?           8
8         F            ?        320    160    1         ?           4

Color reg select: BAK, PF0, PF1, PF2, PF3-PF253

Teraz pozostaje sprawdzenie przez elektronika, który by się znał na rzeczy.

Potem uzupełnienie pól tabelki ze znakiem zapytania.

Wychodzi z tabelki, że układ ANTIC musiałby mieć 40+253 nóżki => czyli trzeba tak zrobić, albo pomyśleć o przesyłaniu informacji o kolorze dla 6 bitów z bajta na 6-ciu pinach, zamiast 252.

Początek gotowy. Teraz trzeba iść do przodu z tabelką i opisać resztę. Etapami, oczywiste.

A czy można zapisać tą samą linię w postaci:

150 WHILE NOT (PEEK(53279)=6):WEND

?

Nie znam Turbo BASIC-a XL, więc może coś poznam. Lubię poznawać nowe rzeczy, oczywiste.

Obydwa akapity perfekcyjnie się uzupełniają i obrazują prawidłowo kwestię omawianą:

1. "widząc VGA 320x200 256 kolor - od razu przychodzi do głowy Atari XL/XE, że VGA wygląda, jakby ten sam komputer, jakby XL/XE." - matryca 320x200 - czyli atarowska standardowa, kolorów aż 256, czyli tylko można się popłakać z żalu, że na Atari XL/XE nie ma aż tylu kolorów, oczywiste.

2. "VGA 256 kolor nie da się zrealizować w standardzie 8-bit XL/XE. Architektura układów i systemu nie pozwala. Trzeba by zmienić architekturę zupełnie, żeby coś takiego osiągnąć" - oczywiste, bo można sobie pomyśleć o trybie najwyższej rozdzielczości XL/XE, czyli ok. 320x200, ma tylko jeden kolor w sumie, plus kolor tła, chyba jeszcze ramka osobno, ale realnie w obszarze rysowania można na tle zapalić inny kolor lub zgasić (ten sam kolor piksela, co tła) - z tego wynika jakoś logicznie indukcyjnie, że trzymając się architektury XL/XE, dla 1 i 2 bit danych na piksel, tak, czy inaczej, w trybie 320x200 jest tylko jeden kolor, czyli nawet uzupełniając w standardzie obsługę 4 i 8 bit danych na jeden piksel, nie bardzo może się udać 256 kolorów, co powinno wynikać wprost z 8 bitów danych na piksel, lub 16 kolorów z 4 bitów na piksel, tak samo, jak nie wynika 4 kolory z 2 bitów na piksel, ani 2 kolorów z 1 bita na piksel (jest tylko 1 kolor w 320x200, chociaż można uznać za 2 kolory, biorąc tło jako drugi kolor, oczywiste).

Czyli wniosek: patrząc na VGA 320x200, 256 kolor widać Atari XL/XE, ale aż w 256 kolorach! Cudo jakieś i kosmos raj dla gracza i użytkownika Atari XL/XE, oczywiste.

... jednak nawet chcąc mieć takie efekty na XL/XE - nie da się zasadniczo: architektura nie pozwala. Wynika to pewnie z podziału danych na piksel dla pola gry i duszków, inne informacje, etc. - które dzielą się tak, w obsłudze przez układy, że w trybie 320x200 przykładowo można mieć TYLKO 1 kolor, a nie 4 kolory. Czyli 4 razy mniej, niż logika informatyczna i elektroniczna udostępnia na 2 bitach danych na piksel, oczywiste.

Stąd wniosek, że w trybie 320x200 nie ma szans, bo nie może być szans, zasadniczo (nie psując architektury XL/XE) uzyskać 256 kolorów na 8 bitach danych na piksel. Proste, oczywiste.

Dokładnie tak. Ten przykład z VGA 320x200, 256 kolor jest ogólnym komentarzem, ideowym, do czego zmierza realizacja 'pełnego Atari XL/XE' w jego standardzie opartym na architekturze 8-bit.

Max, w kwestii rozdz. i kolorów, który dałoby się uzyskać standardowo nie zmieniając architektury ani standardów projektowych XL/XE, wynika jakoś automatycznie z tego uzupełnienia omawianego, że nie tylko 1 i 2 bity danych na piksel, ale również 4 i 8.

Żeby zrealizować obsługę 4 i 8 bitów informacji o pikselu, żeby GTIA mógł taką informację przerobić na efekt w postaci 16-kolorowego lub 256-kolorowego piksela, na pewno będzie trzeba dolutować kilka nóżek, analogicznie do tych, które odpowiadają za 1 i 2 bity danych. Nie będąc elektronikiem, ale próbując jakoś czasem zastanowić się jak to się "wymnaża" w ilości potrzebnych nóżek na układach, obawiam się, że nie tylko dwie nóżki więcej, ale jakoś w mnożniku dwójkowym by wyszło, więc układ mógłby zacząć przypominać jakieś współczesne 256-pin chipset, albo coś (zamiast ok. 40 nóżek w układzie, wyszłoby 256, albo więcej) - ogólnie bym się bał, gdyby tak miało wyjść, bo nie chodzi o zrobienie współczesnego komputera, czy karty graficznej, oczywiste - trzeba pozostać w architekturze oryginalnego XL/XE 8-bit.

Skoro w oryginale XL/XE można uzyskać tryb GTIA o 16 odcieniach i to jest max dla danych 1 lub 2 bit na piksel, to prawdopodobnie dla danych 4 i 8 bit będzie to max. 256 odcieni jednego koloru w trybie 320 pół na 200 pół.

W 320x200 byłoby pewnie 4 kolory max. To myślenie ogólne, żeby wiedzieć konkretnie trzeba uzupełnić tabelki w opisach inżynierskich do ANTIC i GTIA zgodnie z pomysłem - i będzie gotowe.

Potrzebna pamięć RAM dla "pełnego Atari XL/XE" jest dopiero w 130XE. Całe 64kB akurat idealnie pasuje do obsługi TYLKO grafiki. I to jest perfekcyjne rozwiązanie gotowe, 130XE czeka na swoje pełne parametry, czyli obsługę grafiki w 1,2,4,8 bitach danych dla piksela.

320x200 nawet gdyby było w 256 kolorach (ale nie da się w standardzie aż tyle, najpewniej, oczywiste) powinno pięknie mieścić się na dodatkowych 64kB RAM (130XE).

Nawet na podstawowej pamięci RAM XL/XE bajt danych na piksel w trybach 160x100 (połowa matrycy 320x200) powoduje zajęcie ok. 16kB dla pamięci obrazu, który byłby 256 kolor. Czyli zostaje pełno pamięci na kod i system, etc., niczego nie brakuje, można nawet dwie strony obrazu obsługiwać i chyba dla 32kB zarezerwowanych dla obrazu nadal system powinien działać, a programista mieć obszar dla kodu.

@mono:

1024 kolory to zupełnie nie pasuje do architektury Atari XL/XE. Celem projektu jest uzupełnienie okrojonej wersji XL/XE o połowę, do pełnej wersji XL/XE, jak powinno być w standardzie i zgodnie z architekturą.

Z 8-bit nie da się jakkolwiek zrobić 1024 - taka liczba nie pasuje do architektury zupełnie, tak widzę tę liczbę. To nie jest 8-bit, oczywiste.

@PROTON:

Kwestia ceny RAM, a na dodatek upchania na scalaku pełno elementów, które by się mogło chcieć mieć - właśnie ograniczały projekty producentów i projektantów, dokładnie jak w przykładzie XL/XE - zrobiono pół-wersję komputera, jak widać, i wydaje się to oczywiste, oczywiste. No jak można robić komputer 8-bitowy z układami do grafiki, które obsługują tylko minimalne kilka bitów dla obrazu, jakby miało być "aby tylko cokolwiek z kolorów", czyli 1 i 2 bity danych na piksel, i skoro działa i piękne kolorowe obrazki widać => no to na rynek, gotowe, proste, oczywiste...

... i teraz mając taki kolorowy komputer aż w 16 kolorach (odcieniach) w sumie (jednocześnie na ekranie) można robić piękne gry wideo, akurat jak na lata 80-te, do tego programowalna jest ta konsola (mowa o XL/XE, oczywiście), łatwa w produkcji, nie za dużo nakładów ani elementów elektronicznych, ani pamięci, etc. - i tak zostawiono pół wersję, na 1 i 2 bit danych no i tyle. I działało, ludzie lubili, grali, cieszyli się - zabawka kolorowa, wystarczyła wersja okrojona o połowę.

Potem od razu przeskoczono na 520ST i zapomniano uzupełnić ten pozostawiony, okrojony o połowę, mały komputerek... no i tak zostało, hmm...

W pełnej wersji standard musi być 1,2,4,8 bitów danych na piksel, to pełen XL/XE, oczywiste. 64kB na obraz jest akurat w 130XE. I wtedy to jest komputer, o którym mowa. Inne wersje, to okrojone (ze względu pośpiechu, pędu rynku, kosztów produkcji, etc.), oczywiste.

VGA 256 kolor nie da się zrealizować w standardzie 8-bit XL/XE. Architektura układów i systemu nie pozwala. Trzeba by zmienić architekturę zupełnie, żeby coś takiego osiągnąć, czyli nie byłby to już XL/XE, tylko jakiś inny komputer.

Natomiast widząc VGA 320x200 256 kolor - od razu przychodzi do głowy Atari XL/XE, że VGA wygląda, jakby ten sam komputer, jakby XL/XE. Rozdzielczość VGA 320x200, kolory 8-bit - to samo jest w XL/XE. VGA i XL/XE jest jakby tym samym. XL/XE kończy swoje możliwości w tym samym miejscu, w którym VGA zaczyna...

@tebe:

Nie za 100 lat, cały Atari XL/XE już dawno mieści się w "główce szpilki", oczywiste. Czytając taki komentarz, ktoś padnie ze śmiechu i zapyta "a jak podłączyć joystick, przykładowo, albo przynajmniej jedną stację dysków lub jeden monitor? Przez USB, czy HDMI?" :)

@PROTON:

Dzięki, bardzo fajny schemat. To chyba nie jest kwestia magistrali, tylko nóżek odpowiedzialnych za kolor, dwie nóżki (tak próbuję kojarzyć i kombinować), wartości: 1 lub 2 - dwie nóżki określają czy bits per pixel jest 1 lub 2 - z tego wynika, że trzeba by dolutować chyba dwie nóżki dodatkowe, dla bits per pixel: 4 lub 8 - jest to tylko flaga, z ilu danych korzysta ANTIC lub GTIA do realizacji piksela. 8 bit jest max, czyli 256 kolorów, ale żeby GTIA o tym wiedział i rozróżniał 4 różne stany (1,2,4,8 bits per pixel), wystarczą pewnie 4 nóżki, ale pewien nie jestem. Trzeba sprawdzić rozdział kolorów na GTIA - rzeczywiście jest to D0 do D7, więc... trzeba by dolutować D8 do D15 - i wyszłoby na elektronice 256 kolorów lub 16 kolorów - paleta na GTIA musiałaby być łatwo ustawialna w zakresie 256x256 kolorów. To będzie do określenia i sprawdzenia dokładnie.

Dzięki za schemat, genialny rysunek, lubię to, oczywiste.

==

Sprawdziłem trochę te magistrale i do czego one mają służyć niby, wydaje mi się, że gdyby się uprzeć, to dałoby się zrobić co planowane na tej samej, 8-bitowej, tak, jak jest, tylko wykorzystując odpowiednio, hmm... nie znam się za bardzo.

Na pewno trzeba:

- wskazać rodzaj rozdziału danych w bajcie dla pixela obrazu (bits per pixel 1 lub 2 lub 4 lub 8)
- ustawić kolory w zakresie nie tylko 16 różnych w 16 odcieniach, ale 256x256 lub więcej nawet

Magistrala danych dla kolorów w GTIA (dla pola gry i dla graczy i pocisków jest używana jak w tabelce):

http://krap.pl/mirrorz/atari/homepage.n … %20control

I teraz trzeba to dostosować jakoś do obsługi 4 bits per pixel i 8 bits per pixel, czyli rozszerzyć tylko wprost, analogicznie jakoś (żeby nie tylko dla 1 i 2 bits per pixel działały te układy).

Pojedyncze nóżki wskazują wszystko, co potrzeba, a kolory jak widać, magistralą danych, więc nawet na tej samej magistrali być może da się zrealizować 16 i 256 kolorów na ekranie, tylko trzeba o tym poinformować GTIA odpowiednio, czyli wskazać, że dane dla pixela są 4-bitowe lub 8-bitowe, a nie 1 lub 2-bitowe.

Wtedy GTIA robi kolor z 4 bitów lub 8 bitów i gotowe. 256 kolor, oczywiste.

Tylko tyle trzeba dolutować i poustawiać w ANTIC, GTIA i na płycie głównej trochę.

I byłoby gotowe raz na zawsze, w standardzie Atari XL/XE.

Jakoś etapami się uda... musi być zrobione, oczywiste.

Pod moim awatarem "Oczywistych Nimf" jest napisane w polu "Skąd: Planeta Ziemia i okolice".

Bieżące lokalizacje w danej lokalizacji określonej jak wyżej, można pewnie łatwo samemu znaleźć, przeglądając listę IP połączeń przy logowaniu lub przy postach, to chyba oczywiste, czy nie?