Podmiana obrazka startowego w OS 4

W trak­cie startu sys­temu AmigaOS4.1 na ekra­nie poka­zuje się obra­zek sym­bo­li­zu­jący z czym mamy do czy­nie­nia. Po jakimś cza­sie zaczyna on nam się nudzić i naj­chęt­niej chcie­li­by­śmy go zmie­nić na coś swo­jego, indy­wi­du­al­nego.

Jakiś czas po tym jak na swoim SAM440ep zain­sta­lo­wa­łem OS4.1, przy­szedł mi do głowy pomysł żeby pod­mie­nić ory­gi­nalny obra­zek star­towy na jakiś taki który by mi bar­dziej odpo­wia­dał. Nie­stety, choć prze­szu­ka­łem wszyst­kie opcje w pre­fe­ren­cjach Work­ben­cha nie zna­la­złem żad­nej która by to umoż­li­wiała.
Zapy­ta­łem więc na forum eXeca czy jest to w ogóle moż­liwe. W odpo­wie­dzi dowie­dzia­łem się że obra­zek star­towy który poka­zuje się na star­cie sys­temu jest zawarty w jed­nym z pli­ków Kick­Startu.
W związku z tym pod­miana go w spo­sób bez­po­średni nie jest w żaden spo­sób moż­liwa.
Sza­man tak mimo­cho­dem napi­sał: „A może byś spró­bo­wał?”. Jako że za młodu bawi­łem się w ripo­wa­nie modu­łów z gier i pro­gra­mów demon­stra­cyj­nych więc czemu nie. Zabra­łem się za to.

Wszyst­kie opi­sane tu czyn­no­ści wyko­ny­wa­łem na pliku BootI­mage z sys­temu AmigaOS4.1 który był dostar­czany przy zaku­pie kom­pu­tera SAM 440ep. Jest to wer­sja star­sza niż Final Edi­tion. Ponie­waż nie posia­dam tej wer­sji nie jestem w sta­nie stwier­dzić czy ope­ra­cje które tu opi­szę będą w dal­szym ciągu aktu­alne.
Jed­nak do Update 6 wszystko działa bez zarzutu.

Na samym początku trzeba się dowie­dzieć w któ­rym kon­kret­nie ele­men­cie Kick­startu może znaj­do­wać się ten obra­zek. W sys­te­mie 4.x Kick­Start nie jest umiesz­czony w pamięci ROM jak to ma miej­sce star­szych sys­te­mach. Dodat­kowo nie jest też w jed­nym kawałku lecz składa się kil­ku­na­stu poje­dyn­czych pli­ków które w trak­cie startu sys­temu są wczy­ty­wane z twar­dego dysku. Ma to swoje zalety gdyż jaka­kol­wiek aktu­ali­za­cja Kick­Startu polega tylko na pod­mia­nie kon­kret­nego pliku. Taka sytu­acja sprawę pod­miany obrazka bar­dzo uprasz­cza.

Odszu­ka­nie kon­kret­nego pliku było banal­nie pro­ste. Wystar­czyło wejść do kata­logu Sys:Kickstart.
Plik któ­rego szu­ka­łem sam swoją nazwa BootI­mage pod­po­wia­dał że jest tym czego szu­ka­łem.

Nie­stety. Plik ten nie był jakimś zwy­kłym obraz­kiem w jed­nym z popu­lar­nych for­ma­tów ze zmie­nioną nazwą lecz pro­gra­mem który posiada w sobie dane tego obrazka zapi­sane tylko w sobie zna­nym for­ma­cie i wyświe­tla w odpo­wied­nim momen­cie.

Dekom­pi­la­cja tego pro­gramu w ogóle nie wcho­dziła w grę.

Każdy z czy­ta­ją­cych który spo­dzie­wał się pro­fe­sjo­nal­nego podej­ścia do tematu z poka­za­niem jak to można pro­sto zro­bić dostęp­nymi pro­gra­mami
muszę roz­cza­ro­wać. Opi­sane przeze mnie czyn­no­ści można potrak­to­wać jako pry­mi­tywny włam w zawar­tość pliku wyko­rzy­stu­jąc do tego wła­sne opro­gra­mo­wa­nie.

ETAP PIERWSZY - Obrazku pokaż się!

W pierw­szej kolej­no­ści nale­żało usta­lić w jakiej wiel­ko­ści i w ilu kolo­rach mógłby to być obra­zek.
Moni­tor do któ­rego mia­łem pod­łą­czony kom­pu­ter wyka­zał że aktu­al­nie wyświe­tlany obraz ma roz­miary 640x480.
To już jest jakaś wska­zówka. Szybka kal­ku­la­cja wyka­zała jed­nak że wiel­kość obrazka znacz­nie prze­kra­cza wiel­kość pliku.
A więc obra­zek musi być jakoś skom­pre­so­wany a to z kolei może utrud­nić sprawę.

Dal­sze czyn­no­ści nad pli­kiem prze­pro­wa­dza­łem na mojej Ami­dze 1200 gdzie mam śro­do­wi­sko pro­gra­mi­styczne.
Wyko­rzy­stu­jąc File Mastera, który posiada opcje hex-edy­tora, posta­no­wi­łem poszu­kać w zawar­to­ści pliku slow klu­czo­wych takich jak: PNG, JPG, JFIF, ILBM i t.p, w nadziei że zapi­sany obra­zek jest tam po pro­stu dokle­jony.

Poszu­ki­wa­nia nie­stety niczego nie przy­nio­sły.

Nale­żało mu się więc bacz­niej przyj­rzeć w poszu­ki­wa­niu cze­go­kol­wiek co mogło by przy­po­mi­nać dane gra­ficzne.

W trak­cie jego prze­glą­da­nia w oczy rzu­cił mi się off­set 0x010058 (65624) w któ­rym dane podej­rza­nie się powta­rzały.
Przy­po­mi­nało to spo­sób zapisu palety barw w sys­te­mie ami­go­wym, gdzie dane koloru jed­nego pisaka w try­bie 8-bito­wym zapi­sane są w trzech dłu­gich sło­wach (3x32 bity). Jed­nak po prze­li­cze­niu ilo­ści tak zapi­sa­nych barw wycho­dziło 3036 baj­tów zamiast ocze­ki­wa­nych 3072 co daje tylko 253 barwy. Na szczę­ście mówił o tym off­set 0x010055 (65621). Po pale­cie barw pod off­se­tami 0x010C38 (68664), 0x010C3A (68666) znaj­do­wały się dane 0x0280, 0x01E0 czyli w prze­li­cze­niu na układ dzie­siętny odpo­wied­nio 640 oraz 480.
To mogła być wiel­kość obrazka a wiec ana­liza pliku szła w dobrym kie­runku.
Za tymi danymi od off­setu 0x010C30 (68668) nastę­po­wały kolejne nic już w sumie nie mówiące dane.
Sko­pio­wa­łem te dane pro­gra­mem który napi­sa­łem bar­dzo dawno temu któ­rego uży­wam do dziś.
Pozwala on na sko­pio­wa­nie dowol­nej dłu­go­ści danych z danego pliku zaczy­na­jąc od dowol­nego miej­sca.
Nazwa­łem go sobie Kopier. Pro­gramy tego typu praw­do­po­dob­nie można zna­leźć na Ami­ne­cie.

Ana­liza wycinka wyka­zała że dane były skom­pre­so­wane metoda RLE (Run-Length Enco­ding). W skró­cie jest to metoda bez­strat­nej kom­pre­sji, która polega na tym że ciągi danych nastę­pu­ją­cych po sobie które się powta­rzają zastę­puje się jed­nym plus infor­ma­cje ile razy taki ele­ment się powtó­rzył. Ele­menty nie­po­wta­rza­jące się prze­pi­suje się.
Dla przy­kładu: „AAAMIGAAA RULEZZZZ” można zapi­sać jako: „3A3MIG3A5 RULE4Z”.
Opis tro­szeczkę upro­ści­łem gdyż w rze­czy­wi­sto­ści trzeba roz­róż­nić które dane się powta­rzają a które nie.
Wyko­rzy­stano tutaj znak liczby infor­ma­cyj­nej: jeśli jest dodatni to ele­menty nie powta­rzają się, jeśli ujemny - powta­rzają. Algo­rytm pry­mi­tywny ale w opi­sy­wa­nym przy­padku wystar­cza­jący.
Oso­bom tro­chę bar­dziej obe­zna­nym z Amigą przy­po­mina to kom­pre­sję sto­so­waną w pli­kach ILBM. I tak w isto­cie jest.
Tyle tylko że w oma­wia­nym przy­padku dane o samym obrazku są ina­czej opi­sane, dane jed­nego pik­sela opi­suje jeden bajt.

Wie­dząc o tym, szybko napi­sa­łem w C pro­gram który zde­kom­pre­so­wał mi te dane. Ilość infor­ma­cji po dekom­pre­sji ilo­ściowo zga­dzała się z zakła­daną jaka powinna być dla obrazka o roz­mia­rach 640 na 480 czyli 327200 baj­tów.
Nale­żało je tylko w jakiś spo­sób zwe­ry­fi­ko­wać. Tutaj z pomocą przy­szedł mi pro­gram Per­so­nal Paint i for­mat gra­ficzny BMP.
For­mat ten zapi­suje dane wprost bez kom­pre­sji z tą róż­nicą że linie obrazu zapi­suje zaczy­na­jąc od ostat­niej.
Jed­nak dla testu nie było to pro­ble­mem. Stwo­rzy­łem w PPa­in­cie pusty obra­zek o wymia­rach 640x480 z paletą jaka była usta­wiona na star­cie pro­gramu i zapi­sa­łem jako BMP.

Wie­dząc że dane gra­ficzne w takim pliku zaczy­nają się od off­setu 0x0436 (1078) aż do końca pliku, pod­mie­ni­łem je poprzez odpo­wied­nie pocię­cie wyżej opi­sa­nym pro­gra­mem i dokle­je­nie swo­ich danych pole­ce­niem Join. Ponowne zała­do­wa­nie takiego
pliku do PPa­inta i… BINGO!
Moim oczom uka­zał się dobrze znany obra­zek tyle że obró­cony do góry nogami z nie­po­prawną paletą.
Teraz wszystko poszło z górki. Nale­żało jesz­cze pod­mie­nić paletę która ory­gi­nal­nie była w 96 bitach na 0RBB (32 bity) gdyż taki zapis obo­wią­zuje w for­ma­cie BMP. Do tego także napi­sa­łem wła­sny pro­gram który mi to prze­kon­wer­to­wał.
Paleta w pliku BMP zapi­sana jest od off­setu 0x0036 (54), wie­dząc to wyko­na­łem pod­mianę danych i osta­tecz­nie dosta­łem to co liczy­łem. Wystar­czyło tylko obró­cić obra­zek wczy­tany do PPa­inta:

Pod­su­muję czego się dowie­dzia­łem:
- obra­zek ma roz­miar 640x480 w 8 bitach
- dane obrazka spa­ko­wane są metodą RLE
- off­set gdzie zaczy­nają się dane obrazka to 0x010C30 (68668)
- cał­ko­wita dłu­gość spa­ko­wa­nych danych ory­gi­nal­nego obrazka to 69741 baj­tów
- paleta obrazka zapi­sana jest w 12 baj­tach na kolor
- off­set palety barw zaczyna się od 0x010058 (65624)
- wyko­rzy­stano tylko 253 barwy (3036 baj­tów).

ETAP DRUGI - Obra­zek wła­sny.

Wie­dząc w jaki spo­sób i gdzie dane są zapi­sane mogę spró­bo­wać pod­mie­nić je na swoje.
Naj­pierw napi­sa­łem algo­rytm który reali­zuje kom­pre­sję RLE. Do testów posłu­żył mi ory­gi­nalny obra­zek który wycią­gną­łem z pliku BootI­mage. Po jego napi­sa­niu i prze­te­sto­wa­niu stwier­dzi­łem że mój algo­rytm oka­zał się wydaj­niej­szy i plik był o kil­ka­na­ście baj­tów krót­szy. Zacie­ka­wiło mnie to. Jed­nak dekom­pre­sor który napi­sa­łem wcze­śniej odtwa­rzał obra­zek bez­błęd­nie. Dodat­kowo upew­ni­łem że wszystko jest w porządku poprzez dokle­je­nie moich danych do pliku BootI­mage gdzie bra­ku­jące bajty zastą­pi­łem war­to­ścią 0x80 (dekom­pre­sor napo­ty­ka­jąc takie dane igno­ruje je). Obra­zek przy star­cie sys­temu OS4.1 poka­zał się bez naj­mniej­szych pro­ble­mów a więc pełny suk­ces. Jed­nak nie do końca. Dłu­gość ta miała zna­cze­nie ale o tym póź­niej.
Gdy stwier­dzi­łem że wszystko działa jak należy, zaczą­łem poszu­ki­wa­nia na sieci jakie­goś obrazka któ­rym mógł­bym zastą­pić ten ory­gi­nalny. Padło na:


Ponie­waż jestem fanem Mangi/Anime ten wła­śnie obra­zek jakoś bar­dzo mi się spodo­bał. Wczy­ta­łem go do PPa­inta. Ten prze­kon­wer­to­wał mi go do 8 bit, dodat­kowo prze­ko­lo­ro­wa­łem do 253 barw, oraz odpo­wied­nio wyka­dro­wa­łem. Zapi­sa­łem jako BMP. Następ­nie taki plik pocią­łem oddzie­la­jąc gra­fikę od palety. Dane obrazka skom­pre­so­wa­łem, paletę prze­kon­wer­to­wa­łem. Następ­nie wszystko wkle­iłem gdzie trzeba do pliku BootI­mage spraw­dza­jąc czy nigdzie się nie pomy­li­łem. Ponie­waż plik po kom­pre­sji był znacz­nie krót­szy dokle­iłem odpo­wied­nią ilość 0x80 jak poprzed­nio. Prze­gra­łem plik gdzie trzeba. Odpa­li­łem Sam440 i moim oczom uka­zał się… No wła­śnie nie wiem, bo w żaden spo­sób nie przed­sta­wiało to tego czego ocze­ki­wa­łem. Jed­nym sło­wem wojna mró­wek bijąca się kaszkę mannę. Co się stało? Co poszło nie tak? Gdzie się pomy­li­łem? Długo się nad tym zasta­na­wia­łem spraw­dza­jąc po trzy­kroć algo­rytmy oraz umiej­sco­wie­nie danych. Nic nie poma­gało. Po pew­nym cza­sie przy­po­mnia­łem sobie o tej róż­nicy dłu­go­ści pliku testu­jąc mój kom­pre­sor i nie dawało mi to spo­koju. Skądś ta róż­nica musiała wyni­kać. Po dłu­gich ana­li­zach dosta­łem olśnie­nia. Mój algo­rytm kom­pre­so­wał dane cało­ściowo. I tu wła­śnie był błąd. Ory­gi­nalny plik każdą linię obrazu miał kom­pre­so­waną oddziel­nie. Aby spraw­dzić moją teo­rię nie prze­ra­bia­łem algo­rytmu kom­pre­sora tylko doda­łem do mojego obrazka szary gra­dient w postaci pio­no­wych pasów.

Był on tak dobrany aby mieć pew­ność że kom­pre­sji zosta­nie pod­dana następna linia. Dla­czego to nie wyszło wcze­śniej? Ory­gi­nalny obra­zek posiada napis nie na jed­no­li­tym tle tylko gra­dien­cie koło­wym. To on spra­wił że dane kom­pre­so­wały się w odpo­wiedni spo­sób. Po doda­niu gra­dientu w końcu mogłem się cie­szyć wła­snym obraz­kiem przy star­cie sys­temu AmigaOS4.1.

Dla dal­szych testów wyko­na­łem kilka testów z róż­nymi obraz­kami z czego dwa umie­ści­łem na OS4 Depot.


Myśla­łem nad tym czy nie napi­sać pro­gramu z popra­wio­nym algo­ryt­mem kom­pre­sji i kon­wer­te­rem palety barw który wyko­ny­wałby plik Booti­mage auto­ma­tycz­nie z dowol­nego obrazka. Jed­nak w trak­cie prac wyszedł jesz­cze jeden pro­blem. Wła­sny obra­zek po kom­pre­sji musi zawie­rać się mak­sy­mal­nie w takiej ilo­ści baj­tów jak obra­zek ory­gi­nalny. Czę­sto przy przy­go­to­wy­wa­niu innych obraz­ków oka­zy­wało się że po kom­pre­sji plik był dłuż­szy od zakła­da­nego limitu. Im był bar­dziej szcze­gó­łowy tym bar­dziej dzia­łało to na nie­ko­rzyść. Nale­żało go więc sztucz­nie mody­fi­ko­wać przez usu­wa­nie pew­nych frag­men­tów lub zmniej­sza­nie ilo­ści barw aż otrzyma się zado­wa­la­jący wynik. Co pra­wie zawsze skut­ko­wało tym, że obra­zek po takich zabie­gach nie wyglą­dał już jak bym chciał.

Myślę że każdy kto zna się choć tro­chę na pro­gra­mo­wa­niu na pod­sta­wie infor­ma­cji które tutaj przed­sta­wi­łem i chciałby taki pro­gram napi­sać zrobi to bez trudu. W razie czego mogę słu­żyć pomocą.

 

 

Phi­brizzo - Amiga NG 1/2017

Bądź pierwszy, który skomentuje ten wpis!

Dodaj komentarz

Twój adres email nie zostanie opublikowany.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.