The Koala Micro Illustrator

From Atariki

Wersja z dnia 18:25, 1 cze 2006 Dracon (Dyskusja | wkład) (mega-polerowanko... :]) ← Previous diff		Wersja z dnia 22:08, 1 cze 2006 KMK (Dyskusja | wkład) (ogólny edit) Next diff →
Linia 1:		Linia 1:
-	{{SDP}}	+	Jest to łatwy w obsłudze program graficzny, pracujący w [[Graphics 15]] czyli rozdzielczości 160 x 192 piksele i 4 kolorach. Występuje w dwóch odmianach - wersja na [[cartridge]] zatytułowana '''Atari Artist''' i dołączana do Touch Tablet oraz wersja dyskowa pod nazwą '''Koala Microillustrator'''. Swego czasu (I połowa lat 80. i nieco dalej) bardzo popularny program.
-	Jest to łatwy w obsłudze program graficzny, pracujący w [[Graphics 15]] czyli rozdzielczości 160 x 192 piksele i 4 kolorach.	+
-	Występuje w dwóch odmianach - wersja na cartridge (która nazywała się "Atari Artist"), dołączana do Touch Tablet oraz wersja dyskowa. Swego czasu (I połowa lat 80. i nieco dalej) bardzo popularny program. Koala MicroIllustrator wczytuje i zapisuje obrazki w swoim formacie (.PIC), który został opisany poniżej.	+
		+	Koala MicroIllustrator wczytuje i zapisuje obrazki w swoim formacie (.PIC), który został opisany poniżej.
		+	== Format pliku graficznego Koali ==
-	----	+	Format zapisu stosowany w programie Koala Microillustrator (.PIC) jest, obok formatu [[Micropainter]]a (.MIC), najpopularniejszym standardem zapisu grafiki na 8-bitowych komputerach Atari.
-		+
-		+
-	'''O formacie KOALI'''	+
-		+
-		+
-	Format zapisu KOALI MICROILLUSTRATORA (.PIC) jest obok MICropaintera, najpopularniejszym standardem zapisu grafiki na 8-bitowych komputerach Atari.	+
	Dotychczas ukazało się kilka artykułów na temat tegoż formatu zapisu (m.in. w MEGAZINIE i [[ABBUC Magazine]], jednak w pierwszym przypadku informacje te były niekompletne, zaś w drugim były pewne przekłamania i nieścisłości. Poza tym być może nie wszyscy mają te magazyny...		Dotychczas ukazało się kilka artykułów na temat tegoż formatu zapisu (m.in. w MEGAZINIE i [[ABBUC Magazine]], jednak w pierwszym przypadku informacje te były niekompletne, zaś w drugim były pewne przekłamania i nieścisłości. Poza tym być może nie wszyscy mają te magazyny...
-	W tym artykule opisano POPRAWNĄ budowę pliku KOALI, a w szczególności jego nagłówka (jako że właśnie o nim były podane błędne informacje), opierając się na wiadomościach z m.in. dwóch powyższych źródeł.	+	W tym artykule opisano poprawnie budowę pliku Koali, a w szczególności jego nagłówka (jako że właśnie o nim były podane błędne informacje), opierając się na wiadomościach z m.in. dwóch powyższych źródeł.
-		+
-	Format zapisu KOALI MICROILUSTRATORA powstał w 1983 roku w firmie Koala Ware. W tej lub lekko zmodyfikowanej wersji jest (był) także używany na innych komputerach, np. C64, Apple (!). Format ten rozpoznaje większość trybów graficznych oraz różne wielkości ekranu. Na Atari używa jednak (standardowo) tylko trybu gfx #15 z rozdzielczością ekranu 160x192 piksele.	+
-	Początek pliku w formacie KOALI to specjalny nagłówek, w którym zawarte są najważniejsze informacje o obrazku, tzn. jego szerokość, wysokość, kolory, itd. W tym miejscu zaprezentowano dokładną rozpiskę wszystkich bajtów nagłówka pliku .PIC:	+	Format zapisu Koali powstał w 1983 roku w firmie Koala Ware. W tej lub lekko zmodyfikowanej wersji jest (był) także używany na innych komputerach, np. C64, Apple (!). W formacie tym można przechować grafikę w większości trybów graficznych i przy różnych rozmiarach ekranu. Na Atari używa się jednak (standardowo) tylko trybu [[Graphics 15]].
		+	=== Nagłówek ===
		+	Początek pliku to specjalny nagłówek, w którym zawarte są najważniejsze informacje o obrazku, tzn. jego szerokość, wysokość, kolory itd. W tym tabeli poniżej jest dokładny opis nagłówka pliku .PIC:
	<table BORDER="1" cellpadding="5" WIDTH="100%" cellspacing="0">		<table BORDER="1" cellpadding="5" WIDTH="100%" cellspacing="0">
Linia 48:		Linia 42:
	</td>		</td>
	<td>		<td>
-	Podaje długość nagłówka (tu miejsce jest w dwóch bajtach), ale zwykle jest wartość = 27, tzn. tyle bajtów ma nagłówek (27=$1b)	+	Długość nagłówka. Przeznaczone sa na to dwa bajty, ale zwykle jest tu wartość 27, tzn. tyle bajtów ma nagłówek (27=$1b).
	</td>		</td>
	</tr>		</tr>
Linia 59:		Linia 53:
	</td>		</td>
	<td>		<td>
-	Numer wersji programu względnie formatu obrazka. Normalnie jest to wartość = $01.	+	Numer wersji programu względnie formatu obrazka. Normalnie jest to wartość $01.
	</td>		</td>
	</tr>		</tr>
Linia 94:		Linia 88:
	</td>		</td>
	<td>		<td>
-	Szerokość obrazu w bajtach. Zwykle jest tutaj wartość = 40.	+	Szerokość obrazu w bajtach. Zwykle jest tutaj wartość 40.
	</td>		</td>
	</tr>		</tr>
Linia 105:		Linia 99:
	</td>		</td>
	<td>		<td>
-	Wysokość obrazu w bajtach. Zwykle jest tutaj wartość = 192.	+	Wysokość obrazu w bajtach. Zwykle jest tutaj wartość 192.
	</td>		</td>
	</tr>		</tr>
Linia 143:		Linia 137:
	</table>		</table>
		+	Od '''OFFSET+22''' są 4 pola zarezerwowane na tekst dla tytułu rysunku, autora i pozostałych uwag. Każda taka komórka tekstowa może mieć maksymalnie 40 znaków i musi być zakończona kodem EOL ($9b, 155 dec). Przeważnie znaleźć można tutaj wartość 155 powtórzoną cztery razy. Wpisując w to miejsce jakiś tekst trzeba go zakończyć EOL-em i zwiększyć odpowiednio długość nagłówka w komórce "headln" (tzn. podać nową wartość długości nagłówka, liczonej razem z "komentarzem").
		+	Nagłówek kończy tzw. "spare byte" (zapasowy bajt). Jego wartość wynosi zazwyczaj 162 ($a2), chociaż popularny [[XL-Art]], nagrywając w kompresji Koali wstawia tu wartość $a5.
-	Od adresu '''OFFSET+22''' są 4 komórki zarezerwowane na tekst dla tytułu rysunku, autora i pozostałych uwag. Każda taka komórka tekstowa może mieć maksymalnie 40 znaków i musi być zakończona kodem EOL ($9b, #155 dec). Oczywiście żaden program nie używa tych komórek "tekstowych". Dlatego znaleźć można tutaj normalnie wartość 155 powtórzoną cztery razy. Wpisując w to miejsce jakiś tekst trzeba go zakończyć EOL-em i zwiększyć odpowiednio długość nagłówka w komórce "headln" (tzn. podać nową wartość długości nagłówka, liczonej razem z "komentarzem").	+	=== Okno ===
-	Nagłówek kończy tzw. "spare byte" (zapasowy bajt). Wynosi on zazwyczaj 162 ($a2), chociaż popularny XL-Art, nagrywając w kompresji Koali wstawia tu wartość $a5.	+	Wg [[Bewesoft]]a mogą być ładowane pliki z tylko częścią ekranu - ponoć oryginalny program Koala Microillisutraor potrafi je wczytać. Pozycja i rozmiar tzw. "okna" zdefiniowane są w nagłówku przez pola "scrwidth" i "scrheight". Te 4 bajty określają: początkową pozycję X (w bajtach, a nie w pikselach!), końcową pozycję X obrazu (pierwszą pozycją PO obrazku), początkową pozycję Y obrazu i końcową pozycję Y.
-	<br>	+
		+	=== Kolory ===
-	Sporo jest do skomentowania odnośnie powyższej rozpiski nagłówka Koali. Wg [[Bewesoft]]a mogą być ładowane pliki z tylko częścią ekranu - ponoć oryginalny program KOALA M. potrafi je wczytać. Pozycja i rozmiar tzw. "okna", czyli części "scrwidth" i "scrheight". Te 4 bajty określają: początkową pozycję X (w bajtach, a nie w pikselach !), końcową pozycję X obrazu (pierwszą pozycją PO obrazku), początkową pozycję Y obrazu i końcową pozycję Y.	+	Kolory nagrywane są w kolejności takiej jak w pamięci (708-712), czyli licząc od OFFSET+13 jest nagrywanych pięć bajtów. Wszystkie kolory można dowolnie ustawić w jakimś programie graficznym i ich wartości pojawią się w komórkach "colors" nagłówka. Problem może być jedynie z ustawieniem koloru inwersji ($02c7), który można zmienić tylko w edytorach do [[logosowanie|logosowania]] grafiki. Jednakże to nieistotne, gdyż inwersja ważna jest tylko w grafice znakowej. W każdym razie wartość, jaką można zwykle zastać (dla rejestru $02c7) w nagłówku, to albo $00, albo $46.
-	Kolory nagrywane są w kolejności takiej jak w pamięci (708-712), czyli w kolejne bajty od OFFSET+13 jest nagrywanych pięć wartości. Wszystkie kolory można dowolnie ustawić w jakimś programie graficznym i ich wartości pojawią się w komórkach "colors" nagłówka KOALI. Jedynie może być problem z ustawieniem koloru inwersji ($2c7), który to można zmienić tylko w edytorach do logosowania grafiki. Jednakże to nieistotne, gdyż inwersja ważna jest tylko w grafice znakowej. W każdym razie wartość, jaką można zwykle zastać (dla koloru rejestru $2c7) w nagłówku KOALI, to albo $00, albo $46.	+	=== Kompresja ===
	W użyciu może być jeden z trzech typów kompresji (7. bajt nagłówka):		W użyciu może być jeden z trzech typów kompresji (7. bajt nagłówka):
-	* wartość $00 oznacza brak kompresji w obrazku, czyli, że reszta pliku (po nagłówku) zawiera tylko samą pamięć ekranu.
-	* wartość $01 - najczęściej używana metoda. Oznacza ona spakowane dane, które zostaną umieszczone na ekranie w "pionowym" uporządkowaniu: najpierw bajty w liniach parzystych 0,2,4,6, itd. potem bajty w liniach nieparzystych 1,2,5,7 itd. Po rzędach "idą" w ten sam sposób kolumny ekranu.	+	* wartość $00 oznacza brak kompresji w obrazku, czyli, że reszta pliku (po nagłówku) zawiera tylko same dane zrzucone wprost z pamięci ekranu.
		+
		+	* wartość $01 - najczęściej używana metoda, tzw. kompresja pionowa. Oznacza ona spakowane dane, które zostaną umieszczone na ekranie w "pionowym" uporządkowaniu: najpierw bajty w liniach parzystych 0,2,4,6, itd. potem bajty w liniach nieparzystych 1,2,5,7 itd. Po rzędach "idą" w ten sam sposób kolumny ekranu.
	* metoda $02 również zawiera spakowane dane, ale będą one umieszczone na ekranie tak samo jak w metodzie $00 (poziomo).		* metoda $02 również zawiera spakowane dane, ale będą one umieszczone na ekranie tak samo jak w metodzie $00 (poziomo).
-	Bajt 20. z nagłówka (nazwany "unused") został słusznie przeznaczony przez twórców formatu na przyszłe użycie. Pozwoliło to [[Hermes]]owi (autorowi viewera "ShowPIC v2.0") bardzo pożytecznie wykorzystać pierwszy bajt z pary "unused". Mianowicie został on użyty do przechowywania informacji dla GTIA o jej trzech dodatkowych trybach (tj. gfx #09, ,#10, #11). Pozwala to na wczytywanie skompresowanej grafiki również w w/w trybach graficznych, co oczywiście zaoszczędza miejsce na dysku. Oto jak zostało to zorganizowane:	+	=== Rozszerzenia ===
-	- dwa najmłodsze bity pierwszego nieużywanego bajtu "unused" zawierają informację o powyższych trybach graficznych w następującej kolejności:	+	Bajt 20. z nagłówka ("unused") został przeznaczony przez twórców formatu na przyszłe użycie. Pozwoliło to [[Hermes]]owi (autorowi viewera "ShowPIC v2.0") bardzo pożytecznie wykorzystać pierwszy bajt z pary "unused". Mianowicie został on użyty do przechowywania informacji dla GTIA o jej trzech dodatkowych trybach (tj. [[Graphics 9]], [[Graphics 10]], i [[Graphics 11]]). Pozwala to na wczytywanie skompresowanej grafiki również w tych trybach graficznych, co oczywiście zaoszczędza miejsce na dysku. Oto jak zostało to zorganizowane.
-	* 00 = zwykły tryb Antica (gfx #08)	+	Dwa najmłodsze bity pierwszego nieużywanego bajtu "unused" zawierają informację o trybie graficznym jak następuje:
-	* 01 = 16 jasności tego samego koloru (gfx #09)	+
-	* 10 = 9 dowolnych kolorów z palety 256 (gfx #10)	+
-	* 11 = 16 kolorów o jednakowej jasności (gfx #11)	+
-	Pozostałe bity z tego bajtu oraz drugi wolny bajt są przez viewer "ShowPIC v2.0" nieużywane. Powyższe wykorzystanie bajtu "unused" jest nazwane przez jego pomysłodawcę jako "PIC v2". Idea Hermesa jest świetna, lecz do tej pory spotkać się można z jej zastosowaniem tylko w "ShowPIC v2.0".	+	* 00 = zwykły tryb Antica ([[Graphics 8]])
		+	* 01 = 16 jasności tego samego koloru ([[Graphics 9]])
		+	* 10 = 9 dowolnych kolorów z palety 256 ([[Graphics 10]])
		+	* 11 = 16 kolorów o jednakowej jasności ([[Graphics 11])
-	Dużym problemem jest to, że większość tzw. viewerów, showerów, czy loaderów (programów odtwarzających format KOALI) potrafi ładować pliki .PIC tylko ze standardową długością nagłówka, wynoszącą $1b (27) bajtów. Tymczasem nagłówek może być teoretycznie zmienny, np. gdy doda się jeszcze komentarz do obrazka od komórki OFFSET+22. Co więcej, większość loaderów odczytuje z nagłówka tylko jedną rzecz - dane kolorów. Zauważył to już Bewesoft. Taki sposób działania tych programów można wytłumaczyć tylko jednym: LENISTWEM autorów tychże programików.	+	Pozostałe bity z tego bajtu oraz drugi wolny bajt są przez viewer "ShowPIC v2.0" nieużywane. Powyższe wykorzystanie bajtu "unused" jest nazwane przez jego pomysłodawcę "PIC v2". Pomysł Hermesa jest świetny, lecz do tej pory spotkać się można z jej zastosowaniem tylko w "ShowPIC v2.0".
		+
		+	=== Inne uwagi ===
		+
		+	Dużym problemem jest to, że większość tzw. viewerów, showerów, czy loaderów (programów odtwarzających format Koali) potrafi ładować pliki .PIC tylko ze standardową długością nagłówka, wynoszącą $1b (27) bajtów. Tymczasem nagłówek może mieć zmienną długość, np. gdy doda się jeszcze komentarz do obrazka od komórki OFFSET+22. Co więcej, większość loaderów odczytuje z nagłówka tylko jedną rzecz - dane kolorów. Zauważył to już Bewesoft. Taki sposób działania tych programów można wytłumaczyć tylko jednym: '''lenistwem''' autorów tychże programików.
	Jeśli zechcesz sobie np. dodać komentarz do rysunku, umieszczając go w nagłówku pliku, w odpowiednim miejscu, wiedz, iż na palcach można będzie policzyć programy, które to poprawnie odtworzą. Z testów wynika, że uda Ci się to tylko w:		Jeśli zechcesz sobie np. dodać komentarz do rysunku, umieszczając go w nagłówku pliku, w odpowiednim miejscu, wiedz, iż na palcach można będzie policzyć programy, które to poprawnie odtworzą. Z testów wynika, że uda Ci się to tylko w:
Linia 179:		Linia 180:
	* loaderze BeweSofta z ABBUC Magazine		* loaderze BeweSofta z ABBUC Magazine
	* ShowPIC v2.0 Hermesa		* ShowPIC v2.0 Hermesa
-	* oryginalnym KOALA MICROILUSTRATOR	+	* oryginalnym programie Koala Microillustrator
-	(te trzy powyższe programy można ogólnie spokojnie uznać za najlepsze - dotąd - loadery dla formatu Koali)... Z "eliminacji" odpadły natomiast loadery KOALI w takich programach, jak: GRAPH VIEW z CrisisSoft, GRAPH.COM Souseda, XL-Art, RAMbrandt (!), BIT CONVERTER Bartmana oraz paru innych. Problem "ignorowania" sobie wartości z nagłówka wynika również z innej, bardziej praktycznej (od wstawiania komentarzy do obrazków) rzeczy - przykładowo XL-Art przy zapisie .PIC'a "zapomina" o zapisaniu w nagłówku Koali informacji o długości samego obrazka (nie wstawia nic do bajtów "picln" w nagłówku obrazka). Jako że większość "loaderów" również nie sprawdza bajtu "picln", wszystko jest OK... do czasu, aż napotkasz jakiś program, którego twórca spodziewał się, że są jeszcze dobrze napisane procedury obsługi kompresji KOALI i... w tymże programie nie zapomniał o tym bajcie. Wtedy zaczynają się kłopoty, bo program sprawdzający np. bajt "picln", po prostu (od razu) nie wczyta takiego .PIC-a, który nie ma tam żadnej wartości (czyli "picln" = $00,$00). Po sprawdzeniu braku odpowiedniej wartości w nagłówku po prostu przerwie odczyt... Do tej pory można zauważyć dwa takie przypadki - w niezłym programie graficznym (dla trybu [[Graphics 15]]) "Pixel Artist De Luxe v1.3" (swoją drogą jest on pomocny dla posiadaczy tabliczki graficznej) oraz w basicowym programie do wydruku obrazków "PICPRINT", zamieszczonym w jednym z wydań magazynu "OHAUG"... Obydwa programy "buntowały się" przy próbiw wczytania jakiegoś .PIC-a z XL-Art, ale przyczyna okazała się prozaiczna - brak tego jednego, jedynego bajtu, na który zwracały uwagę... Zatem aby do nich wczytać taki obrazek, należy wpisać do jego nagłówka odpowiednią wartość w bajtach "picln" za pomocą jakiegoś monitora (dyskowego). Można też wczytać obrazek w postaci .MIC do "Pixela..." i tam zgrać go jako .PIC. Zostanie on zapisany w rzadziej spotykanej poziomej kompresji. Na szczęście nie będzie już kłopotów z ładowaniem tak "przerobionego" obrazka w drugą stronę, tzn. w np. XL-Art, bo on bajty "picln", jak już wcześniej wspomniano, ignoruje.	+	Z "eliminacji" odpadły natomiast loadery w takich programach, jak: GRAPH VIEW z CrisisSoft, GRAPH.COM Souseda, [[XL-Art]], [[RAMbrandt]] (!), BIT CONVERTER Bartmana oraz paru innych.
		+
		+	Problem "ignorowania" sobie wartości z nagłówka wynika również z innej, bardziej praktycznej (od wstawiania komentarzy do obrazków) rzeczy - przykładowo XL-Art przy zapisie .PIC-a "zapomina" o zapisaniu w nagłówku Koali informacji o długości samego obrazka (nie wstawia nic do bajtów "picln" w nagłówku obrazka). Jako że większość "loaderów" również nie sprawdza bajtu "picln", wszystko jest OK... do czasu, aż napotkasz jakiś program, którego twórca spodziewał się, że są jeszcze dobrze napisane procedury obsługi kompresji Koali i... w tymże programie nie zapomniał o tym bajcie. Wtedy zaczynają się kłopoty, bo program sprawdzający np. bajt "picln", po prostu nie wczyta takiego .PIC-a, który nie ma tam żadnej wartości (czyli "picln" = $00,$00). Po sprawdzeniu braku odpowiedniej wartości w nagłówku po prostu przerwie odczyt... Do tej pory można zauważyć dwa takie przypadki - w niezłym programie graficznym (dla trybu [[Graphics 15]]) "[[Pixel Artist De Luxe]] v1.3" (swoją drogą jest on pomocny dla posiadaczy tabliczki graficznej) oraz w basicowym programie do wydruku obrazków "PICPRINT", zamieszczonym w jednym z wydań magazynu "OHAUG"... Obydwa programy "buntowały się" przy próbiw wczytania jakiegoś .PIC-a z XL-Art, ale przyczyna okazała się prozaiczna - brak tego jednego, jedynego bajtu, na który zwracały uwagę... Zatem aby do nich wczytać taki obrazek, należy wpisać do nagłówka odpowiednią wartość w bajtach "picln" za pomocą jakiegoś monitora (dyskowego). Można też wczytać obrazek w postaci .MIC do "Pixela..." i tam zgrać go jako .PIC. Zostanie on zapisany w rzadziej spotykanej poziomej kompresji. Na szczęście nie będzie już kłopotów z ładowaniem tak "przerobionego" obrazka w drugą stronę, tzn. w np. XL-Art, bo on bajty "picln", jak już wcześniej wspomniano, ignoruje.
		+
		+	=== Kompresja ===
	Wypadałoby na koniec podać jednak budowę samej kompresji KOALI. Oto, jak to mniej więcej wygląda:		Wypadałoby na koniec podać jednak budowę samej kompresji KOALI. Oto, jak to mniej więcej wygląda:
-	<br>
-	'''Same dane obrazka''' (tzw. mapa bitowa) są skompresowane prostym algorytmem '''RLE''' (redukcja powtarzających się elementów). Kiedy np. pięć razy, jeden za drugim wystąpi w obrazku wartość "0", nagrane zostaną jako "5x0". Obrazek jest umieszczony w poszczególnych blokach. Są dwa typy bloków użytych w kompresji KOALI:
-	<br>
-	'''Dane niespakowane'''. Pierwszy bajt (jako znacznik) ma ustawiony bit 7 (#128 dec), reszta tego samego bajtu stanowi długość bloku danych (maksymalnie 127 bajtów). Jeśli ta długość wynosi zero, to jest wtedy jeszcze o dwa bajty więcej - informują one o aktualnej długości (2-bajtowa wartość, więc będzie DOSYĆ długi niespakowany blok !). Następnymi bajtami są już same niespakowane dane.
-	<br>
-	'''Dane spakowane'''. Pierwszy bajt w takim bloku ma wyzerowany siódmy bit, reszta zaś jest długośćią bloku - tak samo, jak opisana wyżej. Tu jest tylko jeden bajt danych, który wypełni swą wartością wszystkie bajty w bloku. Po prostu informuje on o tym jaka wartość jest skompresowana, a ze znacznika (pierwszego bajtu w bloku, informującego o statusie i długości całego bloku) wynika, ile razy trzeba go powtórzyć. Tu także może wystąpić długi, spakowany (tym razem) blok składający się z 3 bajtów "informujących" i jednego bajtu danych - zasada jest podobna jak w bloku niespakowanym.
-	To na tyle w temacie budowy pliku w formacie KOALI MICROILUSTRATORA. Mimo, że efektywność kompresji w oferowany przez KOALĘ sposób jest raczej kiepska (szczególnie przy dużych skomplikowanych obrazkach), to zapis .PIC jest bardzo popularny, zapewne głównie przez prostotę jego realizacji (format podobny do .PIC stosuje np. edytor [[CIN]], [[Trzmiel]], RGB Shower, czy XL-Paint...). Jakby jednak na to nie patrzeć, (prawie) zawsze obrazek trochę się skróci i raczej w wyjątkowych przypadkach opłaca się trzymać plik .MIC zamiast .PIC-a.	+	* '''Same dane obrazka''' (tzw. mapa bitowa) są skompresowane prostym algorytmem '''RLE''' (redukcja powtarzających się elementów). Kiedy np. pięć razy, jeden za drugim wystąpi w obrazku wartość "0", nagrane zostaną jako "5x0". Obrazek jest umieszczony w poszczególnych blokach. Są dwa typy bloków użytych w kompresji KOALI:
		+
		+	** '''Dane niespakowane'''. Pierwszy bajt (jako znacznik) ma ustawiony bit 7 (128 dec), reszta tego samego bajtu stanowi długość bloku danych (maksymalnie 127 bajtów). Jeśli ta długość wynosi zero, to jest wtedy jeszcze o dwa bajty więcej - informują one o aktualnej długości (2-bajtowa wartość, więc będzie długi, niespakowany blok!). Następnymi bajtami są już same niespakowane dane.
		+	** '''Dane spakowane'''. Pierwszy bajt w takim bloku ma wyzerowany siódmy bit, reszta zaś jest długośćią bloku - tak samo, jak opisana wyżej. Tu jest tylko jeden bajt danych, który wypełni swą wartością wszystkie bajty w bloku. Po prostu informuje on o tym, jaka wartość jest skompresowana, a ze znacznika (pierwszego bajtu w bloku, informującego o statusie i długości całego bloku) wynika, ile razy trzeba go powtórzyć. Tu także może wystąpić długi, spakowany (tym razem) blok składający się z 3 bajtów "informujących" i jednego bajtu danych - zasada jest podobna jak w bloku niespakowanym.
		+	To tyle o budowie pliku w formacie Koali. Mimo, że efektywność kompresji w opisany sposób jest raczej kiepska (szczególnie przy dużych i skomplikowanych obrazkach), to zapis .PIC jest bardzo popularny, zapewne głównie przez prostotę jego realizacji (format podobny do .PIC stosuje np. edytor [[CIN]], [[Trzmiel]], RGB Shower, czy [[XL-Paint]]...). Jakby jednak na to nie patrzeć, (prawie) zawsze obrazek trochę się skróci i raczej w wyjątkowych przypadkach opłaca się trzymać plik .MIC zamiast .PIC-a.
	{{stub}}		{{stub}}
	[[Kategoria:Oprogramowanie Atari 8-bit]]		[[Kategoria:Oprogramowanie Atari 8-bit]]
	[[Kategoria:Programy użytkowe]]		[[Kategoria:Programy użytkowe]]

---

Wersja z dnia 22:08, 1 cze 2006

Jest to łatwy w obsłudze program graficzny, pracujący w Graphics 15 czyli rozdzielczości 160 x 192 piksele i 4 kolorach. Występuje w dwóch odmianach - wersja na cartridge zatytułowana Atari Artist i dołączana do Touch Tablet oraz wersja dyskowa pod nazwą Koala Microillustrator. Swego czasu (I połowa lat 80. i nieco dalej) bardzo popularny program.

Koala MicroIllustrator wczytuje i zapisuje obrazki w swoim formacie (.PIC), który został opisany poniżej.

Spis treści 1 Format pliku graficznego Koali 1.1 Nagłówek 1.2 Okno 1.3 Kolory 1.4 Kompresja 1.5 Rozszerzenia 1.6 Inne uwagi 1.7 Kompresja

Format pliku graficznego Koali

Format zapisu stosowany w programie Koala Microillustrator (.PIC) jest, obok formatu Micropaintera (.MIC), najpopularniejszym standardem zapisu grafiki na 8-bitowych komputerach Atari.

Dotychczas ukazało się kilka artykułów na temat tegoż formatu zapisu (m.in. w MEGAZINIE i ABBUC Magazine, jednak w pierwszym przypadku informacje te były niekompletne, zaś w drugim były pewne przekłamania i nieścisłości. Poza tym być może nie wszyscy mają te magazyny...

W tym artykule opisano poprawnie budowę pliku Koali, a w szczególności jego nagłówka (jako że właśnie o nim były podane błędne informacje), opierając się na wiadomościach z m.in. dwóch powyższych źródeł.

Format zapisu Koali powstał w 1983 roku w firmie Koala Ware. W tej lub lekko zmodyfikowanej wersji jest (był) także używany na innych komputerach, np. C64, Apple (!). W formacie tym można przechować grafikę w większości trybów graficznych i przy różnych rozmiarach ekranu. Na Atari używa się jednak (standardowo) tylko trybu Graphics 15.

Nagłówek

Początek pliku to specjalny nagłówek, w którym zawarte są najważniejsze informacje o obrazku, tzn. jego szerokość, wysokość, kolory itd. W tym tabeli poniżej jest dokładny opis nagłówka pliku .PIC:

Typ	Nazwa	Opis
OFFSET=0 (4 bajty)	identyfikator formatu KOALI	Oznaczenie formatu Koali. Są tu zawsze wartości = 255,128,201,199.
OFFSET=4 (2 bajty)	headln	Długość nagłówka. Przeznaczone sa na to dwa bajty, ale zwykle jest tu wartość 27, tzn. tyle bajtów ma nagłówek (27=$1b).
OFFSET=6 (1 bajt)	revision	Numer wersji programu względnie formatu obrazka. Normalnie jest to wartość $01.
OFFSET=7 (1 bajt)	typcprs	Rodzaj kompresji: 0 = nieskompresowane 1 = kompresja pionowa 2 = kompresja pozioma
OFFSET=8 (1 bajt)	antic-mode	Podaje tryb grafiki obrazka według trybów ANTIC.
OFFSET=9 (2 bajty)	scrwidth	Szerokość obrazu w bajtach. Zwykle jest tutaj wartość 40.
OFFSET=11 (2 bajty)	scrheight	Wysokość obrazu w bajtach. Zwykle jest tutaj wartość 192.
OFFSET=13 (5 bajtów)	scrheight	Kolory obrazka - nagrywane w takiej kolejności jak w pamięci, 708..712.
OFFSET=18 (2 bajty)	picln	Ogólna długość obrazka (samego, bez nagłówka) w bajtach.
OFFSET=20 (2 bajty)	unused	Zawsze wynosi 0.

Od OFFSET+22 są 4 pola zarezerwowane na tekst dla tytułu rysunku, autora i pozostałych uwag. Każda taka komórka tekstowa może mieć maksymalnie 40 znaków i musi być zakończona kodem EOL ($9b, 155 dec). Przeważnie znaleźć można tutaj wartość 155 powtórzoną cztery razy. Wpisując w to miejsce jakiś tekst trzeba go zakończyć EOL-em i zwiększyć odpowiednio długość nagłówka w komórce "headln" (tzn. podać nową wartość długości nagłówka, liczonej razem z "komentarzem").

Nagłówek kończy tzw. "spare byte" (zapasowy bajt). Jego wartość wynosi zazwyczaj 162 ($a2), chociaż popularny XL-Art, nagrywając w kompresji Koali wstawia tu wartość $a5.

Okno

Wg Bewesofta mogą być ładowane pliki z tylko częścią ekranu - ponoć oryginalny program Koala Microillisutraor potrafi je wczytać. Pozycja i rozmiar tzw. "okna" zdefiniowane są w nagłówku przez pola "scrwidth" i "scrheight". Te 4 bajty określają: początkową pozycję X (w bajtach, a nie w pikselach!), końcową pozycję X obrazu (pierwszą pozycją PO obrazku), początkową pozycję Y obrazu i końcową pozycję Y.

Kolory

Kolory nagrywane są w kolejności takiej jak w pamięci (708-712), czyli licząc od OFFSET+13 jest nagrywanych pięć bajtów. Wszystkie kolory można dowolnie ustawić w jakimś programie graficznym i ich wartości pojawią się w komórkach "colors" nagłówka. Problem może być jedynie z ustawieniem koloru inwersji ($02c7), który można zmienić tylko w edytorach do logosowania grafiki. Jednakże to nieistotne, gdyż inwersja ważna jest tylko w grafice znakowej. W każdym razie wartość, jaką można zwykle zastać (dla rejestru $02c7) w nagłówku, to albo $00, albo $46.

Kompresja

W użyciu może być jeden z trzech typów kompresji (7. bajt nagłówka):

• wartość $00 oznacza brak kompresji w obrazku, czyli, że reszta pliku (po nagłówku) zawiera tylko same dane zrzucone wprost z pamięci ekranu.

• wartość $01 - najczęściej używana metoda, tzw. kompresja pionowa. Oznacza ona spakowane dane, które zostaną umieszczone na ekranie w "pionowym" uporządkowaniu: najpierw bajty w liniach parzystych 0,2,4,6, itd. potem bajty w liniach nieparzystych 1,2,5,7 itd. Po rzędach "idą" w ten sam sposób kolumny ekranu.

• metoda $02 również zawiera spakowane dane, ale będą one umieszczone na ekranie tak samo jak w metodzie $00 (poziomo).

Rozszerzenia

Bajt 20. z nagłówka ("unused") został przeznaczony przez twórców formatu na przyszłe użycie. Pozwoliło to Hermesowi (autorowi viewera "ShowPIC v2.0") bardzo pożytecznie wykorzystać pierwszy bajt z pary "unused". Mianowicie został on użyty do przechowywania informacji dla GTIA o jej trzech dodatkowych trybach (tj. Graphics 9, Graphics 10, i Graphics 11). Pozwala to na wczytywanie skompresowanej grafiki również w tych trybach graficznych, co oczywiście zaoszczędza miejsce na dysku. Oto jak zostało to zorganizowane.

Dwa najmłodsze bity pierwszego nieużywanego bajtu "unused" zawierają informację o trybie graficznym jak następuje:

• 00 = zwykły tryb Antica (Graphics 8)
• 01 = 16 jasności tego samego koloru (Graphics 9)
• 10 = 9 dowolnych kolorów z palety 256 (Graphics 10)
• 11 = 16 kolorów o jednakowej jasności ([[Graphics 11])

Pozostałe bity z tego bajtu oraz drugi wolny bajt są przez viewer "ShowPIC v2.0" nieużywane. Powyższe wykorzystanie bajtu "unused" jest nazwane przez jego pomysłodawcę "PIC v2". Pomysł Hermesa jest świetny, lecz do tej pory spotkać się można z jej zastosowaniem tylko w "ShowPIC v2.0".

Inne uwagi

Dużym problemem jest to, że większość tzw. viewerów, showerów, czy loaderów (programów odtwarzających format Koali) potrafi ładować pliki .PIC tylko ze standardową długością nagłówka, wynoszącą $1b (27) bajtów. Tymczasem nagłówek może mieć zmienną długość, np. gdy doda się jeszcze komentarz do obrazka od komórki OFFSET+22. Co więcej, większość loaderów odczytuje z nagłówka tylko jedną rzecz - dane kolorów. Zauważył to już Bewesoft. Taki sposób działania tych programów można wytłumaczyć tylko jednym: lenistwem autorów tychże programików.

Jeśli zechcesz sobie np. dodać komentarz do rysunku, umieszczając go w nagłówku pliku, w odpowiednim miejscu, wiedz, iż na palcach można będzie policzyć programy, które to poprawnie odtworzą. Z testów wynika, że uda Ci się to tylko w:

• loaderze BeweSofta z ABBUC Magazine
• ShowPIC v2.0 Hermesa
• oryginalnym programie Koala Microillustrator

Z "eliminacji" odpadły natomiast loadery w takich programach, jak: GRAPH VIEW z CrisisSoft, GRAPH.COM Souseda, XL-Art, RAMbrandt (!), BIT CONVERTER Bartmana oraz paru innych.

Problem "ignorowania" sobie wartości z nagłówka wynika również z innej, bardziej praktycznej (od wstawiania komentarzy do obrazków) rzeczy - przykładowo XL-Art przy zapisie .PIC-a "zapomina" o zapisaniu w nagłówku Koali informacji o długości samego obrazka (nie wstawia nic do bajtów "picln" w nagłówku obrazka). Jako że większość "loaderów" również nie sprawdza bajtu "picln", wszystko jest OK... do czasu, aż napotkasz jakiś program, którego twórca spodziewał się, że są jeszcze dobrze napisane procedury obsługi kompresji Koali i... w tymże programie nie zapomniał o tym bajcie. Wtedy zaczynają się kłopoty, bo program sprawdzający np. bajt "picln", po prostu nie wczyta takiego .PIC-a, który nie ma tam żadnej wartości (czyli "picln" = $00,$00). Po sprawdzeniu braku odpowiedniej wartości w nagłówku po prostu przerwie odczyt... Do tej pory można zauważyć dwa takie przypadki - w niezłym programie graficznym (dla trybu Graphics 15) "Pixel Artist De Luxe v1.3" (swoją drogą jest on pomocny dla posiadaczy tabliczki graficznej) oraz w basicowym programie do wydruku obrazków "PICPRINT", zamieszczonym w jednym z wydań magazynu "OHAUG"... Obydwa programy "buntowały się" przy próbiw wczytania jakiegoś .PIC-a z XL-Art, ale przyczyna okazała się prozaiczna - brak tego jednego, jedynego bajtu, na który zwracały uwagę... Zatem aby do nich wczytać taki obrazek, należy wpisać do nagłówka odpowiednią wartość w bajtach "picln" za pomocą jakiegoś monitora (dyskowego). Można też wczytać obrazek w postaci .MIC do "Pixela..." i tam zgrać go jako .PIC. Zostanie on zapisany w rzadziej spotykanej poziomej kompresji. Na szczęście nie będzie już kłopotów z ładowaniem tak "przerobionego" obrazka w drugą stronę, tzn. w np. XL-Art, bo on bajty "picln", jak już wcześniej wspomniano, ignoruje.

Kompresja

Wypadałoby na koniec podać jednak budowę samej kompresji KOALI. Oto, jak to mniej więcej wygląda:

• Same dane obrazka (tzw. mapa bitowa) są skompresowane prostym algorytmem RLE (redukcja powtarzających się elementów). Kiedy np. pięć razy, jeden za drugim wystąpi w obrazku wartość "0", nagrane zostaną jako "5x0". Obrazek jest umieszczony w poszczególnych blokach. Są dwa typy bloków użytych w kompresji KOALI:

• • Dane niespakowane. Pierwszy bajt (jako znacznik) ma ustawiony bit 7 (128 dec), reszta tego samego bajtu stanowi długość bloku danych (maksymalnie 127 bajtów). Jeśli ta długość wynosi zero, to jest wtedy jeszcze o dwa bajty więcej - informują one o aktualnej długości (2-bajtowa wartość, więc będzie długi, niespakowany blok!). Następnymi bajtami są już same niespakowane dane.

• • Dane spakowane. Pierwszy bajt w takim bloku ma wyzerowany siódmy bit, reszta zaś jest długośćią bloku - tak samo, jak opisana wyżej. Tu jest tylko jeden bajt danych, który wypełni swą wartością wszystkie bajty w bloku. Po prostu informuje on o tym, jaka wartość jest skompresowana, a ze znacznika (pierwszego bajtu w bloku, informującego o statusie i długości całego bloku) wynika, ile razy trzeba go powtórzyć. Tu także może wystąpić długi, spakowany (tym razem) blok składający się z 3 bajtów "informujących" i jednego bajtu danych - zasada jest podobna jak w bloku niespakowanym.

To tyle o budowie pliku w formacie Koali. Mimo, że efektywność kompresji w opisany sposób jest raczej kiepska (szczególnie przy dużych i skomplikowanych obrazkach), to zapis .PIC jest bardzo popularny, zapewne głównie przez prostotę jego realizacji (format podobny do .PIC stosuje np. edytor CIN, Trzmiel, RGB Shower, czy XL-Paint...). Jakby jednak na to nie patrzeć, (prawie) zawsze obrazek trochę się skróci i raczej w wyjątkowych przypadkach opłaca się trzymać plik .MIC zamiast .PIC-a.

---

Ten artykuł to tylko zalążek. Możesz pomóc rozwojowi Atariki poprzez rozszerzenie go o więcej informacji.