"Integrator" poprawiony by Larek 2009-05-25 12:59:19
Arek "ArSoft" Lubaszka:
Zdaję sobie sprawę z tego, że zapewne temat z "Integratorem" jest już oklepany i nudny, ale nie mogłem pozostać bierny uwagom Tebe'go dotyczącym problemów z wczytywaniem plików XEX przez SIO2PC i program "R5" Electrona. Wszak przecież "Integrator" to program, który istnieje dzięki "Graph2Font" Tebe'go! W załączniku mały opis tego, co zostało zrobione, aby wszyscy korzystający z "R5" byli usatysfakcjonowani.
Każdy dobry krawiec wie, że nie można uszyć dobrego garnituru bez przymiarek i poprawek. W tym, co wydaje nam się dziełem skończonym, zawsze można doszukać się elementów, które możemy poprawić. Tak było również z "Integratorem 3". Napisawszy program testowałem go z różnego rodzaju plikami wejściowymi. To samo robiłem z plikami wygenerowanymi przez ten program. Wszystkie testy wypadały pozytywnie do czasu, gdy... Tebe zechciał wczytać demo "Beep’em All II", w którym dołączono obrazek tytułowy właśnie za pomocą "Integratora". Problem wystąpił podczas wczytywania pliku za pomocą programu "R5" poprzez interfejs SIO2PC. Według "R5" plik XEX wygenerowany przez "Integratora" nie jest plikiem XEX!? Przypuszczalną przyczyną takiego stanu rzeczy było uszkadzanie nagłówków plików przez "Integratora". Postanowiłem się dokładnie przyjrzeć tym plikom XEX.
Jak już wcześniej wspomniałem, pliki XEX wczytywały się i uruchamiały bez problemu, zarówno na emulatorze, jak i na prawdziwym Atari. Na tym drugim wczytywanie pliku było realizowane poprzez interfejs SIO2SD. Fakt ten wskazywał jednak na to, że nagłówki plików są w porządku. Specjalnie do testów ściągnąłem sobie program na PC o nazwie "Check Xex" (CHKXEX.EXE). Testy przeprowadziłem od podstaw. Najpierw zbadałem plik XEX z obrazkiem wygenerowanym przez "Graph2Font". Oto wynik:
Jak widać, wynik jest pozytywny. Teraz kontrola pliku z grą:
Tu również widzimy, że plik „is OK.”. No to łączymy oba pliki "Integratorem" i testujemy:
Niestety program testujący stwierdził, że plik „is too short”. No dobrze, ale gdzie te zepsute nagłówki? Porównajcie sobie wyświetlane dane bloków i nagłówków ze wszystkich powyższych testów. I co? I nic! Wszystko jest dokładnie takie same! Wszystkie liczby przed połączeniem plików i po połączeniu plików są identyczne. Co w takim razie spowodowało, że według programu "R5" i "Check Xex", pliki XEX nie są plikami XEX? Czyżby historia ta nie miała szczęśliwego zakończenia? Nie bardzo mi to odpowiadało, bo zdawałem sobie sprawę z tego, że wiele osób może korzystać z interfejsu SIO2PC i programu "R5" do wczytywania plików. Nie chciałem, żeby byli oni pozbawieni tej możliwości, ale w najgorszym przypadku tak by musiało zostać. Już miałem się poddać, gdy postanowiłem przyjrzeć się jeszcze długości poszczególnych plików... i tu wpadłem na trop! Plik wygenerowany przez "Integratora" był o dwa bajty dłuższy niż to wynikało z długości plików składowych, co jednak wcale nie przeszkadzało w jego poprawnym wczytywaniu w „normalny” sposób ;-) ! Podejrzenie stało się pewnością, gdy wprowadzona drobna zmiana do kodu "Integratora" spowodowała, że test przeprowadzony przy pomocy programu "Check Xex" wygląda tak:
Sukces? Wygląda na to, że tak, ale bez potwierdzenia tego przez „sprawcę zamieszania”, czyli Tebe’go nie ma co świętować. Na szczęście Tebe bardzo szybko sprawdził działanie przesłanych mu do testów plików. Odpowiedź była w pełni satysfakcjonująca! Plik XEX stworzony poprawionym "Integratorem" wczytuje się przez "R5"! I tak powstał Integrator Trzeci w wersji 3.01, który produkuje pliki XEX rozpoznawane prawidłowo przez "R5" i program "Check Xex". W tym miejscu należą się podziękowania dla Tebe’go za wykrycie problemu i pomoc w testach. Dzięki!
Na koniec, wszystkim ciekawym tej drobnej zmiany w "Integratorze" powiem, że wystarczyło dodać średnik w jednym miejscu, aby plik XEX był plikiem XEX!
Nowa wersja (3.01) tutaj.
Zdaję sobie sprawę z tego, że zapewne temat z "Integratorem" jest już oklepany i nudny, ale nie mogłem pozostać bierny uwagom Tebe'go dotyczącym problemów z wczytywaniem plików XEX przez SIO2PC i program "R5" Electrona. Wszak przecież "Integrator" to program, który istnieje dzięki "Graph2Font" Tebe'go! W załączniku mały opis tego, co zostało zrobione, aby wszyscy korzystający z "R5" byli usatysfakcjonowani.
Każdy dobry krawiec wie, że nie można uszyć dobrego garnituru bez przymiarek i poprawek. W tym, co wydaje nam się dziełem skończonym, zawsze można doszukać się elementów, które możemy poprawić. Tak było również z "Integratorem 3". Napisawszy program testowałem go z różnego rodzaju plikami wejściowymi. To samo robiłem z plikami wygenerowanymi przez ten program. Wszystkie testy wypadały pozytywnie do czasu, gdy... Tebe zechciał wczytać demo "Beep’em All II", w którym dołączono obrazek tytułowy właśnie za pomocą "Integratora". Problem wystąpił podczas wczytywania pliku za pomocą programu "R5" poprzez interfejs SIO2PC. Według "R5" plik XEX wygenerowany przez "Integratora" nie jest plikiem XEX!? Przypuszczalną przyczyną takiego stanu rzeczy było uszkadzanie nagłówków plików przez "Integratora". Postanowiłem się dokładnie przyjrzeć tym plikom XEX.
Jak już wcześniej wspomniałem, pliki XEX wczytywały się i uruchamiały bez problemu, zarówno na emulatorze, jak i na prawdziwym Atari. Na tym drugim wczytywanie pliku było realizowane poprzez interfejs SIO2SD. Fakt ten wskazywał jednak na to, że nagłówki plików są w porządku. Specjalnie do testów ściągnąłem sobie program na PC o nazwie "Check Xex" (CHKXEX.EXE). Testy przeprowadziłem od podstaw. Najpierw zbadałem plik XEX z obrazkiem wygenerowanym przez "Graph2Font". Oto wynik:
Jak widać, wynik jest pozytywny. Teraz kontrola pliku z grą:
Tu również widzimy, że plik „is OK.”. No to łączymy oba pliki "Integratorem" i testujemy:
Niestety program testujący stwierdził, że plik „is too short”. No dobrze, ale gdzie te zepsute nagłówki? Porównajcie sobie wyświetlane dane bloków i nagłówków ze wszystkich powyższych testów. I co? I nic! Wszystko jest dokładnie takie same! Wszystkie liczby przed połączeniem plików i po połączeniu plików są identyczne. Co w takim razie spowodowało, że według programu "R5" i "Check Xex", pliki XEX nie są plikami XEX? Czyżby historia ta nie miała szczęśliwego zakończenia? Nie bardzo mi to odpowiadało, bo zdawałem sobie sprawę z tego, że wiele osób może korzystać z interfejsu SIO2PC i programu "R5" do wczytywania plików. Nie chciałem, żeby byli oni pozbawieni tej możliwości, ale w najgorszym przypadku tak by musiało zostać. Już miałem się poddać, gdy postanowiłem przyjrzeć się jeszcze długości poszczególnych plików... i tu wpadłem na trop! Plik wygenerowany przez "Integratora" był o dwa bajty dłuższy niż to wynikało z długości plików składowych, co jednak wcale nie przeszkadzało w jego poprawnym wczytywaniu w „normalny” sposób ;-) ! Podejrzenie stało się pewnością, gdy wprowadzona drobna zmiana do kodu "Integratora" spowodowała, że test przeprowadzony przy pomocy programu "Check Xex" wygląda tak:
Sukces? Wygląda na to, że tak, ale bez potwierdzenia tego przez „sprawcę zamieszania”, czyli Tebe’go nie ma co świętować. Na szczęście Tebe bardzo szybko sprawdził działanie przesłanych mu do testów plików. Odpowiedź była w pełni satysfakcjonująca! Plik XEX stworzony poprawionym "Integratorem" wczytuje się przez "R5"! I tak powstał Integrator Trzeci w wersji 3.01, który produkuje pliki XEX rozpoznawane prawidłowo przez "R5" i program "Check Xex". W tym miejscu należą się podziękowania dla Tebe’go za wykrycie problemu i pomoc w testach. Dzięki!
Na koniec, wszystkim ciekawym tej drobnej zmiany w "Integratorze" powiem, że wystarczyło dodać średnik w jednym miejscu, aby plik XEX był plikiem XEX!
Nowa wersja (3.01) tutaj.
laoo 2009-05-25 14:24:49
lol. Co to za język, w którym brak lub obecność średnika ma takim miejscu zmienia działanie programu?
mono 2009-05-25 14:26:58
BASIC? W Atari BASIC było zdaje się podobnie?
Kaz 2009-05-25 14:51:41
Microsoft Visual Basic jesli dobrze pamietam.
nosty 2009-05-25 15:25:38
Kaz, czy ja dostalem wczoraj do testow na cartridgu plik z juz poprawnego integratora czy jeszcze z tym bledem?
Niby drobiazg, ale przy skomplikowanej metodzie dzialania loadera i zapisu na cartridgu moglo to miec znaczenie i moze stad blad, ktory Ci opisalem...
Kaz 2009-05-25 17:07:37
Plik, ktory otrzymales nie byl potraktowany Integratorem, to byla reczna robota :).
MaPa 2009-05-26 09:06:43
And what about the Check XEX utility, available for download? :)
Kaz 2009-05-27 17:47:34
MaPa - http://madteam.atari8.info/uzytki/chkxex.7z
lol. Co to za język, w którym brak lub obecność średnika ma takim miejscu zmienia działanie programu?
mono 2009-05-25 14:26:58
BASIC? W Atari BASIC było zdaje się podobnie?
Kaz 2009-05-25 14:51:41
Microsoft Visual Basic jesli dobrze pamietam.
nosty 2009-05-25 15:25:38
Kaz, czy ja dostalem wczoraj do testow na cartridgu plik z juz poprawnego integratora czy jeszcze z tym bledem?
Niby drobiazg, ale przy skomplikowanej metodzie dzialania loadera i zapisu na cartridgu moglo to miec znaczenie i moze stad blad, ktory Ci opisalem...
Kaz 2009-05-25 17:07:37
Plik, ktory otrzymales nie byl potraktowany Integratorem, to byla reczna robota :).
MaPa 2009-05-26 09:06:43
And what about the Check XEX utility, available for download? :)
Kaz 2009-05-27 17:47:34
MaPa - http://madteam.atari8.info/uzytki/chkxex.7z