atarionline.pl Obrazki z G2F we własnych programach - Forum Atarum

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

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1:
       
      CommentAuthorlarek
    • CommentTime6 Mar 2009 zmieniony
     
    Mam pytanie do Speców od G2F.
    Wygenerowałem sobie obrazek w G2F, który zapisałem w postaci samouruchamialnej XEX. Obrazek bardzo ładnie mi się ładuje i uruchamia pod DOS-em. Chciałbym jednak, aby obrazek ten pojawił się przed załadowaniem programu głównego. Niestety połączenie pliku obrazka z programem głównym (też plik xex) nic nie daje. Obrazek w ogóle się nie pojawia. Plik jest ładowany w całości i uruchamia się od razu mój program główny. Co zrobić, aby uruchomił mi sie najpierw obrazek - tak, jak jest to w wielu grach, np. Kinght Lore, Bomb Jack, Hobgoblin?
    • 2:
       
      CommentAuthorCosi
    • CommentTime6 Mar 2009
     
    Przecież plik XEX ma na początku nagłówek. Zwykłym złączeniem chyba nic nie zdziałasz, wydaje mi się, że masz takie możliwości:
    - reverse engineering pliku XEX z obrazkiem, doklejenie do niego kodu asm programu i ponowna kompilacja
    - dopisanie do pliku z obrazkiem loadera, który by ładował program po naciśnięciu klawisza
    - usunięcie nagłówka z programu, doklejenie kodu do pliku z obrazkiem i zmiana nagłówka; w programie nie mógłbyś używać bezpośrednich adresów skoków (to jest chyba najgłupszy pomysł ;-))
    Nie jestem specem od G2F ani od assemblera, ale może moje podpowiedzi co nieco pomogą.
    • 3: CommentAuthorxxl
    • CommentTime6 Mar 2009
     
    tak sie dzieje bo nie zapisujesz niczego do INIT ($2E2-$2E3) tylko 2x do RUN ($2E0-$2E1), mozna by polaczyc te dwa pliki ale w obrazku z g2f musisz troszke pozmieniac monitorem, oprocz tego adresu jeszcze jmp na rts - zeby nastapil dalszy etap ladowania.
    • 4:
       
      CommentAuthorKaz
    • CommentTime6 Mar 2009
     
    TeBe, czy daloby sie zrobic tak, zeby jakims parametrem z G2F, wygenerowany obrazek XEX uruchamial inny program z dyskietki, o nazwie ustawionej na sztywno np. MAIN.XEX albo MAIN.COM? Ewentualnie, zeby mozna bylo polaczyc dany program z dyskietki z obrazkiem G2F - zeby przekazal tylko start do tego nastepego pliku.

    Wtedy rozwiazany bylby problem takich nie-asemblerowych gosci jak ja czy Larek, ktorzy chcieliby skorzystac z zalet G2F, ale nie potrzebuja sie wglebiac w asembler, zeby zrobic banalne dolaczenie obrazka?

    W ten sposob moglbym dorobic mase obrazkow do starych gier, ktore w wersjach na Atari ich nie maja. Mam przykladowo gotowy podkolowany obrazek do Ninja, ale musze sie prosic koderow, zeby mi to zrobili. A Ci, jak wiadomo, nieskozy sa do robienia czegokolwiek, bo Atari to taka skomplikowana maszyna, nie maja czasu i w ogole ;)
    • 5:
       
      CommentAuthorlarek
    • CommentTime6 Mar 2009 zmieniony
     
    Dzięki za szybki odzew. O tym RUN i INIT coś mi po głowie chodziło. Dobrze, że wspomniałeś XXL o tym RTS na końcu, bo pewnie sam bym tak szybko na to nie wpadł. Spróbuję podmienić.

    A do Twórcy G2F: czy jest sznasa na wprowadzenie do kolejnych wersji programu opcji zapisu pliku z parametrami, jak podał XXL?
    Starzy wyjadacze, którzy mają asembler w małym palcu tego nie potrzebują, ale my młodzi... ;-) Zdecydowanie ułatwi to wykorzystanie obrazków generowanych przez świetny G2F we własnych programach.

    Pozdrawiam


    -----------------
    update:

    Kaz mnie uprzedził z prośbą :-)
    • 6: CommentAuthortebe
    • CommentTime6 Mar 2009
     
    zamiast torturować się monitorem wystarczy zapisać plik ASM i dokonać dwóch zmian

    zastąpić rozkaz

    JMP ($000A)

    rozkazem

    RTS

    zastąpić pseudorozkaz

    RUN MAIN

    pseudorozkazem

    INI MAIN


    po takich poprawkach można "sklejać" dowolną ilość obrazków i będą doczytywać się po kolei

    !!! WARUNKIEM KONIECZNYM !!! jest aby obrazek w pierwszych 8 liniach nie miał żadnych zmian, inaczej nie będzie można wyjść z takiego obrazka

    scalenia plików można dokonać w ten sposób, wymagany assembler do asemblacji

    opt h-
    ins 'plik_1.obx'
    ins 'plik_2.obx'
    ins 'plik_3.obx'
    ins 'plik_4.obx'
    ins 'plik_5.obx'
    ins 'plik_6.obx'


    mogę wprowadzić zmianę że będzie automatycznie zapisywał w/w zmianę rozkazów, mankamentem tego rozwiązania jest crash emulatora albo i Atari po wyjściu z obrazka kiedy nie ma dalszych obrazów do wczytania, aktualnie pokazuje się SELF TEST, albo wraca do DOS-a
    • 7:
       
      CommentAuthorlarek
    • CommentTime6 Mar 2009 zmieniony
     
    No i udało się! XXL, dzięki za podpowiedź. Podmieniłem run na init (w jednym miejscu) i zmieniłem sekwencje jmp(10) na rts,nop,nop i zadziałało!

    Kaz - jak będę miał chwilę czasu ( w tym roku? ), to spróbuję napisać programik w basicu do automatycznej konwersji plików. Wydaje się być to dość proste. Może jednak TeBe pokusiłby się o wprowadzenie takiej opcji w G2F? To byłoby najlepsze rozwiązanie.

    -----------
    Widzę, że TeBe mnie uprzedził.

    Jestem za wprowadzeniem takiej możliwości w G2F. Oczywiście, jako dodatkowej opcji oprócz tej, która teraz istnieje, czyli zapisu samouruchamiającego się obrazka w pliku xex. Myślę, że nikt nie będzie miał za złe, gdy uruchomi taki plik samodzielnie, bez łączenia go z innym i po naciśnięciu klawisza system się posypie. To przecież będzie plik do łaczenia z innym! W taki sposób będzie można łączyć kilka, kilkanaście obrazków i jeśli jako ostatni z nich damy ten "normalny" xex, to na koniec nastapi wyjście do DOS (Self Test). To by było to! :)
    • 8:
       
      CommentAuthorKaz
    • CommentTime6 Mar 2009
     
    Ja tez jestem mocno za, bo moglbym sobie robic wlasne slideshow.
    • 9:
       
      CommentAuthorlarek
    • CommentTime8 Mar 2009
     
    Program do konwersji plików i łączenia ich z innymi programami już jest gotowy :-)
    Jeszcze tylko kilka testów i...
    • 10:
       
      CommentAuthorKaz
    • CommentTime8 Mar 2009
     
    A bedziemy testowac, bedziemy :)
    • 11:
       
      CommentAuthorKaz
    • CommentTime8 Mar 2009
     
    Ja juz testowalem i uwazam, ze rewelacja! Tego mi wlasnie bylo trzeba, zeby sie uniezaleznic od koderow i ich braku wolnego czasu - pyk, pyk i mam gre z czolowka :)

    @sikor: Fajnie, że coś się ruszy... Tylko w takim razie mała prośba: jak się da (bo się nie znam) - to ustawić jakiś czas wyświetlania (docelowo, oczywiście) w G2F, aby to były prawdziwe slide-showy ;)

    Ponoc sie da, ale to jak zwykle - trzeba manipulowac na poziomie assemblera :). Z tym, ze trzeba przydusic TeBego i moze znowu ujawni jakies tajne dotychczas sposoby sterowania tym przez laikow :).

    Z tym, ze mnie mniej interesuje obecnie slideshow, a bardziej nowe wersje gier - z czolowkami. Larek - naliczylem, ze w tej chwili wzbogaciles okolo 20 gier czolowkami! Licze tylko te, ktore maja juz gotowe czolowki, tylko trzeba je podlaczyc. Co zamierzam zrobic.
    • 12:
       
      CommentAuthorlarek
    • CommentTime8 Mar 2009
     
    No, może nie ja... ;-)
    Ja tylko napisałem proste narzędzie dla siebie, które przydać się może jeszcze komuś.
    Niestety dochodzą mnie słuchy (od mojego znajomego), że program nie chce u niego działać, nawet po pełnej instalacji. Coś się dzieje, a ja nie wiem co i nie mogę pomóc... Wygląda na to, że nie dla każdego będzie ten programik :( Taki to już jest ten M$ Visual Basic...
    • 13:
       
      CommentAuthorKaz
    • CommentTime8 Mar 2009
     
    Wersja 1.01 nie chce otwierac mi zadnego okienka :(
    Wiec na razie wracam do 1.00...
    • 14:
       
      CommentAuthorlarek
    • CommentTime8 Mar 2009
     
    już to sprawdzam...
    • 15:
       
      CommentAuthorlarek
    • CommentTime8 Mar 2009
     
    Jest już wersja 2.0
    Jeszcze kilka testów i puszczam :)
    • 16:
       
      CommentAuthorKaz
    • CommentTime8 Mar 2009
     
    Dostalem, potestuje i puszcze w swiat.
    • 17:
       
      CommentAuthorKaz
    • CommentTime9 Mar 2009
     
    Puscilem razem z kilkoma grami, na ktorych testowalem...
    ->link<-
    • 18:
       
      CommentAuthorlarek
    • CommentTime10 Mar 2009
     
    Zgodnie z obietnicą posiedziałem nad kodem G2F, aby spróbować zastąpić procedurę czekającą na wciśnięcie klawisza na prockę czekającą kilka sekund. Asemblerowiec ze mnie żaden, ale dopatrzyłem się takiego fragmentu:

    _lp lda skctl ;wait to press any key; here you can put any own routine
    and #$04
    bne _lp

    Jak wyliczyłem, to w sumie wyszło 7 bajtów, które można podmienić.
    Po kilku godzinach męczenia się spłodziłem coś takiego:

    ldx $14
    dex
    _lp cpx $14
    bne _lp

    Też 7 bajtów! Procedura oczekuje ok. 5 sekund i leci dalej... no właśnie tu jest problem, bo nie leci :(
    Znów nerwy, męczarnie i kilka(naście) innych kombinacji procedur. Nic, nic, nic! Po długich badaniach odkryłem coś, co mną wstrząsnęło! Do tej pory nie chce mi się wierzyć w to, co odkryłem. Aż się boję o tym napisać, bo będziecie się smiać, jak walnę głupotę. Ale trudno. Niech się dzieje, co che. Utknąłem w miejscu i ni jak, nie mogę ruszyć do przodu, więc napiszę, co odkryłem! Wszyscy o słabych nerwach niech przestaną w tym miejscu czytać.

    Odkryłem... no, nie mogę pisać...

    Okryłem, że w czasie wyświetlania grafiki (plik xex z G2F) zegar naszej atarki przestaje bić - CZY TO MOŻLIWE, SIĘ PYTAM?

    Chodzi mi o to, że komórka 20, której zawartość jest normalnie zwiększana przez system w dość regularnych odstępach czasu zamiera! I to jest przyczyną, że mój programik odmierzający czas, a bazujący na wewnętrzym zegarku, czyli na komórce nr 20 nie działa!

    Jeden człowiek może mi na to odpowiedzieć - TeBe, help!
    Jakoś nie chce mi się wierzyć w to, co zobaczyłem i pewnie robię coś źle, ale kto wie...

    Na rozwiązanie tej intrygującej wszystkich zagadki musimy poczekać do następnego postu... jeśli tylko TeBe zechce się wypowiedzieć ;-)
    • 19: CommentAuthortebe
    • CommentTime11 Mar 2009
     
    :) obrazek G2F wyłącza OS, w celu przejęcia maksymalnej mocy CPU dla przerwania DLI, a odpowiedzią na Twoje pytanie Larek jest poniższy fragment deklaracji zmiennych strony zerowej, licznikiem czasu jest komórka CLOC ($0005)

    org $00

    fcnt .ds 2
    fadr .ds 2
    cloc .ds 1
    regA .ds 1
    regX .ds 1
    regY .ds 1
    • 20:
       
      CommentAuthorlarek
    • CommentTime11 Mar 2009
     
    Zbawco!
    Sprytnie to wymyśliłeś! Wyłącza OS i zegarek staje... ;-)
    A ja bym do śmierci dumał, dlaczego serce atarka martwe jest!
    Atari martwym robisz i dajesz mu swoje własne życie... Prawie jak Frankenstein :-)

    Dla ścisłości, to chyba chodzi o $0004.

    No to już szykuję Integratora 2.1 i niech się dzieje wola nieba.

    TeBe - dzięki za zainteresowanie tematem i wsparcie!
    • 21: CommentAuthortebe
    • CommentTime11 Mar 2009
     
    tak, adres $0004
    • 22: CommentAuthorGonzo
    • CommentTime11 Mar 2009
     
    TeBe, czy można w jakiś prosty sposób wczytywać obrazki naciskając konkretne klawisze tak jak to zrobiłeś w ln2 slideshow? Co trzeba by dopisać w asmie?
    • 23:
       
      CommentAuthorlarek
    • CommentTime11 Mar 2009
     
    Integrator 2.1 z dodaną możliwością "wyjścia czasowego" (oraz poprawieniem kilku niedociągnięć) jest już w katalogu użytków AtariOnline: ->link<-
    • 24: CommentAuthortebe
    • CommentTime11 Mar 2009 zmieniony
     
    Gonzo zrobić więcej niż trochę, ogólnie spakować cały plik XEX z obrazkiem, a po naciśnięciu klawisza rozpakować i uruchomić wybrany obrazek, najłatwiejszy wydaje się Exomizer, poniżej przykładowa linia komend tworząca z pliku XEX nowy spakowany samouruchamialny XEX

    załadujesz takie spakowane XEX-y do pamięci a potem po wybraniu klawiszem przepiszesz taki spakowany plik pod adres jaki został przewidziany dla niego (odczytać z nagłówka pliku) i zrobisz JSR pod ten adres, nastąpi automatyczna dekompresja i uruchomienie obrazka (Exomizer wykorzystuje połowę strony 1 [$100..$17F] i wskazaną w parametrze Di_table_addr)

    exomizer sfx sys -t 168 -Di_ram_enter=0xff -Di_ram_exit=0xff -Di_table_addr=0xbc40 input_file -o output_file

    p.s.
    exomizer znajduje się w paczce z mads-em
    • 25: CommentAuthorGonzo
    • CommentTime11 Mar 2009
     
    hmm, trochę to skomplikowane, ale spróbować trzeba... tak sobie po cichu myślałem, że wystarczyło by np. wsadzić pod klawisz nazwę/adres pliku do ładowania
    • 26:
       
      CommentAuthorKaz
    • CommentTime11 Mar 2009
     
    TeBe - ale nie da sie bez pakowania Exomizerem? Jezeli sa dwa obrazki to sie przeciez spokojnie zmieszcza nawet na 64KB Atari.
    • 27: CommentAuthorGonzo
    • CommentTime12 Mar 2009 zmieniony
     
    Kaz, dwa obrazki są ok., ale można więcej :)

    slideshow obrazków ABBUC zrobiony w/g przepisu TeBe



    xex

    ->link<-
    • 28: CommentAuthortebe
    • CommentTime20 Mar 2009
     
    Kaz boisz się Exomizera? szybki, dekompresor zajmuje niecałe 2 strony pamięci, pliki umieszczasz w tym samym obszarze co obszar docelowy rozpakowanych danych (dekompresja od tyłu), bogate możliwości konfiguracji, np. dekompresja pod ROM dzięki czemu nie trzeba pisać dodatkowego kodu, Exomizer sam to zrobi
    • 29:
       
      CommentAuthorKaz
    • CommentTime20 Mar 2009
     
    Po pierwsze sie boje :). Po drugie nie na wszystko potrzebna jest armata, jak wystarczy packa na muchy ;).
    • 30:
       
      CommentAuthorKaz
    • CommentTime3 Jan 2010 zmieniony
     

    Kaz:

    Ja juz testowalem i uwazam, ze rewelacja! Tego mi wlasnie bylo trzeba, zeby sie uniezaleznic od koderow i ich braku wolnego czasu - pyk, pyk i mam gre z czolowka :)


    No wlasnie - na przyklad przerwa polgodzinna skutkuje, niezaleznie od koderow - gra "Whirlinurd", ktora ma teraz taka czolowke jak na C64:

    wersja C64:



    wersja XL/XE:




    Gra w katalogu gier jako wesja (v6).xex:

    ->link<-
    • 31: CommentAuthortebe
    • CommentTime3 Jan 2010
     
    gratuluję, po przejściu pierwszego levelu gra wykłada się
    • 32:
       
      CommentAuthorKaz
    • CommentTime3 Jan 2010
     
    U mnie sie nie wyklada - screenshot jest z drugiego levelu :)