Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthortdc
   • CommentTime9 Aug 2013 zmieniony

    
   Tak jak obiecałem podaję filmik prezentujący jeden z problemów, jakie sprawia uruchomienie tego prostego programu bez carta z Action!:
   
   

   
   
   Wcześniej kod działał w miarę dobrze, ale widziałem że kod jest kompletnie niestabilny (pomijając te dziwne linie). Teraz nieco zmieniłem kod programu i niestabilność kodu jest jeszcze bardziej widoczna bo na ułamki sekund wchodzą jakieś śmieci na display listę - swoją drogą bardzo dziwne że powraca to do normy potem.
   
   Wszystkie runtime jakie mam włącznie z tym programem z filmiku, działają źle, w tym każdy się zachowuje inaczej. Np. jedna z bibliotek rysuje poprawnie linie, ale bez koloru.
   
   Użyty w filmiku program to "Action! library" 1988 Iron Soft. Może nie jest to widoczne, ale jednym z efektów jego działania jest spore spowolnienie kodu rysującego linie. Najprawdopodobniej jest to spowodowane tym, że kod skacze w jakieś krzaki zamiast do biblioteki Action!.
   
   Co do intra to zajmę się nim w wolnej chwili bo ostatnio nie miałem na to czasu (czym się zajmowałem to zaraz zobaczycie).
2. • 2: CommentAuthorxxl
   • CommentTime9 Aug 2013

    
   mam takie pytanie, parametr odpowiedzialny za kolor jakie przyjmuje wartosci?
3. • 3:
      
     CommentAuthortdc
   • CommentTime9 Aug 2013

    
   No na Atari zwykle od 0 do 15 i tak też jest w moim programie a ściśle kilku wartości nie używam. Ale jakie to może mieć znaczenie?
4. • 4: CommentAuthorwieczor
   • CommentTime9 Aug 2013 zmieniony

    
   Na mój pierwszy rzut oka procedura rysująca odcinki w bibliotece Iron Soft jest nieodporna na współrzędne spoza ekranu (podczas gdy firmowa, z cartridge'a jest - i po prostu punkty stawiane poza ekranem są pomijane). Tak się przynajmniej wydaje - bo krzaczy się w momencie gdy odcinek wygląda jakby miał być częściowo poza ekranem.
5. • 5:
      
     CommentAuthortdc
   • CommentTime9 Aug 2013

    
   Procedury plot/drawto nie przełykają współrzędnych poza ekranem kończy się to błędem 141 jak w BASICu.
   
   Ten program nie generuje współrzędnych poza ekranem, jednak z jakiegoś powodu tutaj skacze do 0,0 - coś takiego objawia się tylko tutaj, w innych runtimach czegoś takiego nie ma. Jest to po prostu objaw braku stabilności uszkodzonego kodu.
6. • 6:
      
     CommentAuthorwilly
   • CommentTime10 Aug 2013 zmieniony

    
   Po przeanalizowaniu materiału video doszedłem do wniosku że problem leży w "zawijaniu" bądź "niekompatybilności typów" którejś ze zmiennych.
   
   Wygląda to tak, jakby któraś ze zmiennych określających współrzędne na ekranie (chyba Y ale możliwe że obie) podczas rysowania albo była traktowana raz jako ze znakiem innym razem jako bez znaku, albo jakaś inna teoria spiskowa wokół tego tematu - raz jako 8 bitowa raz jako 16.
   
   Efekt jest taki że !NAGLE! procedura rysuje po współrzędnych z poza ekranu nadpisując DL, aż do czasu czyszczenia ekranu i odtworzenia DL.
   Daj programowi podziałać a następnie zrób zrzut pamięci znajdującej się przed DL.
   
   Zakładam że masz ekran gdzieś na końcu pamięci, np. od $A000, wyczyść więc całą pamięć albo jeszcze lepiej wypełnij np $FF przed uruchomieniem programu, i po kilki wysypaniach zrób zrzut pamięci i zobacz co w niej siedzi ;)
7. • 7:
      
     CommentAuthortdc
   • CommentTime11 Aug 2013

    
   Tak masz rację, z grubsza coś niedobrego dzieje się ze współrzędnymi x,y i głównie z nimi bo inne części kodu wydają się działać prawidłowo. Co do 8 i 16 bitowych współrzędnych to na Atari zwykle jest to jasne, że tylko w trybie 8 współrzędne x muszą być 16 bitowe - natomiast w tym wypadku pewnie wszystko jest efektem jakiegoś przypadku, czyli wykonania jakiegoś kodu do którego był skok.
   
   Co do DL to jest to dla mnie kompletnie niezrozumiałe, gdyż DL ustawiam tylko raz i nie zmieniam go potem. Zostaje coś uszkodzone, trudno powiedzieć co, w każdym razie przez pewien czas jest uszkodzony, a potem magicznie powraca jak trzeba - i bądź tu mądry:P
   
   Sprawa jest bardziej skomplikowana bo jak pisałem wcześniej, wcześniejsze wersje, które robiłem w Głuchołazach kompletnie nie uszkadzały DL, teraz wersja nieco zmieniona zaczęła to robić. Podejrzewam że nieco dłuższy kod przesunął coś i CPU wykonuje jeszcze coś dodatkowego czego wcześniej nie robiło.
   
   

   willy:

   Daj programowi podziałać a następnie zrób zrzut pamięci znajdującej się przed DL.

   
   Tak bym robił gdybym chciał to ratować, teoretycznie można prześledzić ten kod po zdeasemblowaniu itp. Jednak ja temu nie wróżę nic dobrego, nie widzę szans na powodzenie ten kod po prostu jest kompletnie niestabilny.
   
   Jedyny wniosek to taki aby po prostu liczyć się z tym że kod który wyszedł z programu "Action! libraty" może być niestabilny jeśli używa systemowych procedur rysujących.
   
   

   willy:

   Zakładam że masz ekran gdzieś na końcu pamięci, np. od $A000

   
   Pamięć obrazu jest tam gdzie zwykle w Action! lub Atari BASICu. Natomiast samo DL przesunąłem w inne miejsce.
   
   

   willy:

   wyczyść więc całą pamięć albo jeszcze lepiej wypełnij np $FF przed uruchomieniem programu

   
   Pomysł dobry, jednak po pierwsze jak pisałem zbyt mało stabilny jest ten kod aby go tak analizować, a po drugie nie tyle mnie interesuje co tam siedzi, co bardziej skąd się to bierze;)
   
   Dzięki za pomoc!
8. • 8: CommentAuthorseban
   • CommentTime11 Aug 2013

    
   @tdc: z tego co pamiętam to w emulatorze np. Altirra masz możliwość ustawienie break-pointa tak aby przerwało wykonywanie programu w momencie gdy nastąpi zapis pod jakiś adres lub jakiś obszar, uruchom to pod Altirra, ustaw break-point tak aby przerwał wykonywanie programu gdy nastąpi zapis w przestrzeni DL. Będziesz wiedział która procedura pisze Ci losowo po pamięci.
9. • 9: CommentAuthorxxl
   • CommentTime11 Aug 2013

    
   ale to wyglada na niekontrolowany zapis do rejestrow sprzetowych a nie do programu antica.