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:
      
     CommentAuthorMq
   • CommentTime21 Oct 2020 13:10

    
   W swojej produkcji postanowiłem wyłączyć system żeby zyskać RAM (oczywistość:-)). Używam do tego biblioteki blibs (b_system) i na samym początku programu głównego zaraz po begin robię SystemOff i po sprawie.
   
   Mam jednak w związku z tym kilka dylematów.
   
   Załóżmy, że chciałbym wczytać coś od razu do zwolnionej poprzez wyłączenie systemu pamięci. Z tym że przecież instrukcja SystemOff zostanie odpalona dopiero jak już cały program będzie załadowany i się uruchomi, więc jeżeli dobrze rozumiem, to wcześniej będę miał ROM włączony, a więc nie wczytam nic w te obszary pamięci, tak?
   Chodziło by mi o coś takiego, żeby np. w resources-ach dodać sobie binarkę wczytywaną od razu do pamięci RAM pod ROM-em.
   
   Czyli np. mam plik resources.rc:
   jakisfont rcdata 'font.fnt'
   
   i później chcę osiągnąć coś takiego:
   const
   jakisfont=$C000;
   
   {$r resources.rc}
   
   Da się tak to zrobić? Kompilator jakoś to sobie umie samodzielnie ogarnąć, czy raczej trzeba np. wczytywać dane najpierw w inne obszary dostępnej pamięci, a dopiero później w swoim programie wyłączyć system i dopiero wtedy przerzucać dane (lub doczytywać) w te obszary pamięci pod ROM-em?
   Jak to się robi, jest jakiś przykład na to w MP?
   
   I kolejna sprawa, w sumie powiązana z poprzednią, ale ma też odrębne zastosowania. Jeśli muszę zrobić tak, że wczytuję program, uruchamiam go i później chcę już w swoim programie doczytać kolejne dane po wyłączeniu OS-a, to jak się to robi, żeby z tego samego pliku xex czytać dalsze dane, a w międzyczasie uruchomić już swój program? Chodzi mi o taką sytuację, że np. wczytuję czołówkę gry, odpala się jakaś tam strona tytułowa, i np. trzeba nacisnąć start. I teraz jak to zrobić, żeby uruchomić wtedy doczytanie kolejnych danych z tego samego pliku xex?
   
   Z tego co rozkminiam sobie w głowie, to tak sobie myślę, że pewnie właśnie tak trzeba to zrobić, że najpierw wczytać program i go uruchomić, następnie wyłączyć OS i doczytać wtedy resztę danych.
   Tylko żeby to zrobić, to np. trzeba skorzystać z xbios, albo napisać własną procedurę doczytywania, bo jak wyłączymy OS, to nie doczytamy nic przecież... A czy zwykły DOS(jakikolwiek) umie działać bez OS?
   
   Ewentualnie jeśli do doczytywania trzeba skorzystać z OS, to pewnie trzeba by najpierw wczytać program z danymi w dostępne obszary pamięci, następnie uruchomić program, wyłączyć OS, przerzucić dane w obszar pod ROM-em, włączyć z powrotem OS, doczytać resztę danych w dostępne obszary pamięci i wtedy ostatecznie wyłączyć OS, tak?
2. • 2:
      
     CommentAuthormgr_inz_rafal
   • CommentTime21 Oct 2020 13:10

    
   W ASM jak np. chcę załadować do extramu dane z jednego, długiego .xex to robię wiele sekcji INI.
   
   Czyli z grubsza:
   1. Program zaczyna się ładować
   2. Loader napotyka INI pod jakiś adres
   3. Pod tym adresem jest kod zmiany banku + RTS (powrót do loader)
   4. Loader ładuje dalej, itp.
   5. Na końcu daję RUN
   
   Pierwsze INI wskazuje na funkcję, która robi detekcję banków, itp.
3. • 3: CommentAuthorxxl
   • CommentTime21 Oct 2020 14:10 zmieniony

    
   @Mq, nie musisz, zainteresuj sie jak dzialaja wektor INIT i RUN. po danym bloku umieszczaj zapis do wektora INIT (blok ktory zapisze cos w wektorze INIT), program ladujacy (np. DOS) zawsze tam skacze po zaladowaniu (nie po zaladowaniu calego programu tylko po zaladowniu kazdego bloku) wiec tym mechanizmem mozesz doladowaywac dane z tego samego pliku.
   
   ---
   powrot do ladowania - kontynuacja to wykonanie rozkazu RTS w Twoim kodzie.
4. • 4: CommentAuthorxxl
   • CommentTime21 Oct 2020 14:10

    
   twoj program moze "przesuwac index" ktory wskazuje kolejne/wczesniejsze dane w pliku ale to jest niebezpieczne poniewaz pewien popularny DOS sie na tym wylorzy.
5. • 5: CommentAuthorxxl
   • CommentTime21 Oct 2020 14:10

    
   nie laduj bezposrednio w obszar RAM pod ROM tylko buforuj ta operacje i kopij dane mechanizmem INIT. oczywiscie sa rozwiazania ktore takie buforowanie robia automatcznie ale po zmianie programu ladujacego to przestanie dzialac.
6. • 6: CommentAuthorxxl
   • CommentTime21 Oct 2020 14:10

    
   tam jeszcze poruszyles temat otwierania wielu plikow (podczas INITa) w czasie ladowania glownego programu. jesli chcesz korzystac ze "standardowych" rozwiazan to nie rob tego, nie zawsze to bedzie dzialac.
7. • 7: CommentAuthortebe
   • CommentTime21 Oct 2020 15:10 zmieniony

    
   MP 164
   ...
   - dodana możliwość wyłączenia pamięci ROM z zachowaniem działania systemu, {$DEFINE ROMOFF}
   
   spróbuj nie użyć SystemOFF z BLIBS-a tylko wpisz na początku programu {$DEFINE ROMOFF}, BLIBS pewnie wymaga poprawy aby działać z ROMOFF, ale standardowe bilbioteki powinny działać
8. • 8:
      
     CommentAuthorMq
   • CommentTime21 Oct 2020 20:10

    
   Co do {$DEFINE ROMOFF} to spróbowałem, ale tego chyba na szybko nie zrobię, bo z blibs używam też gotowych procedur włączania i wyłączania DLI i VBL, no i te procedury przestają działać w tym momencie. Trzeba by to przepisać/dostosować, ale teraz nie chcę tego robić na tym etapie.
   
   Jeśli chodzi o bloki INIT i RUN, to rozumiem jak to działa i umiał bym to poskładać w assemblerze. Natomiast jak to sobie ogarnąć w Mad Pascalu? Czy da się jakoś takie bloki tutaj tak oprogramować, żebym miał wszystko w jednym projekcie i żeby się kompilowało i wtedy odpalało w Altirra po kolei te bloki?
   
   Jeśli nie jest to takie do końca automatyczne, to czy powinienem zrobić to w taki sposób, że najpierw napisać osobno np. jakiś krótki programik, który będzie pierwszym blokiem INIT, a następnie w tym swoim głównym programie dodać go na początku jako resource? Wtedy on się będzie ładował jako pierwszy i odpalał z INIT-a?
   Czy może w ogóle takie bloki trzeba programować jako odrębne programy dbając tylko o to, żeby adresy były właściwe, a potem na końcu ręcznie to sklejać?
9. • 9:
      
     CommentAuthormgr_inz_rafal
   • CommentTime21 Oct 2020 21:10

    
   Nie znam MadPascala, ale strzelam, że można w nim do woli wstawiać assemblerowe wstawki, więc jakaś tam opcja jest.
   
   Czy są jednak jakieś libki, które to automatyzują/ułatwiają, to już pierun raczy wiedzieć.
10. • 10:
       
      CommentAuthorMq
    • CommentTime21 Oct 2020 21:10 zmieniony

     
    Nie no jasne, że można wstawiać assemblera do woli, a ja w sumie coraz więcej mam tego assemblera w Mad Pascalu, bo ciągle coś przerabiam w grze, przyspieszam, optymalizuję i obecnie to już jest jakoś tak pół na pół pascal z asm:-)
    
    Nie potrzeba mi gotowych libek, bardziej chodzi o to jak to poukładać w madpascalowych strukturach, żeby się stało to co chcę żeby się stało: czyli np. wczytuje mi się jakiś obrazek i czeka na klawisz, po czym wczytuje się właściwy program i uruchamia. Oczywiście chodzi o to, żeby odzyskać w ten sposób pamięć wolną, bo obrazek potrzebny jest tylko na starcie programu, a później już nie, czyli tak jak jest to np. w Rzygoniu. Albo tak jak jest z intrem w Laurze.
    
    Poczytałem tu o adresach 2E0 i 2E2: ->link<-
    
    Następnie poczytałem tu o plikach binarnych dosu: ->link<-
    
    Następnie przeczytałem w instrukcji od MP o resource'ach: ->link<-
    
    Wykoncypowałem, że mogę sobie zrobić np. czołówkę z obrazkiem jako odrębny program, dać mu na końcu zapis do INITAD.
    Ten program następnie powinienem dołączyć do mojego głównego programu w Mad Pascalu jako resource typu DOSFILE.
    
    Pytanie jest takie: czy taki dołączony resource będzie na samym początku, a jeśli niekoniecznie, to jak to zrobić żeby był na samym początku, uruchomił się i dopiero po RTS załadowała się reszta i odpalił się główny program? Czy wystarczy, że po prostu jako pierwszy resource dodam ten dodatkowy programik?
    ******
    Edit: przetestowałem sobie samodzielnie. Pliki dodawane jako resource w Mad Pascalu są umieszczone w wynikowym pliku xex na samym początku i są tam umieszczone w takiej kolejności, w jakiej je umieszczę w resource. Czyli jest dokładnie idealnie tak jak bym tego pragnął:-) Super, a więc da się tak zrobić jak napisałem powyżej:-)
    ******
    
    I jeszcze jedno pytanie: czy ten odrębny programik mniejszy, który ma mieć INIT a nie mieć RUN da się jakoś tak napisać z poziomu Mad Pascala, żeby kompilator wiedział, że ma go przygotować w postaci bloku INIT na końcu z RET i bez RUN?
11. • 11: CommentAuthortebe
    • CommentTime21 Oct 2020 22:10 zmieniony

     
    Resource to właśnie bloki INI, będą się uruchamiać wg kolejności którą ustalisz
    
    zasób DOSFILE zostanie dołączony bez zmian, jak postanowisz tak będzie, powinien to być blok INI aby można było kontynuować ładowanie pozostałych bloków, na pewno w takim bloku nie powinieneś otwierać kanału do transmisji bo może się wyłożyć dalszy etap ładowania programu
12. • 12:
       
      CommentAuthorMq
    • CommentTime22 Oct 2020 00:10

     
    Ok, dziękuję za wszystkie uwagi, przetestuję sobie to wszystko.
    
    Na ten moment wiem tyle, że dobrą drogą dla mnie będzie przygotowanie kilku małych bloków INI, które zrobią kolejno np. wyświetlenie na początku jakiegoś "loading...", następnie może jakiegoś obrazka. Dalej w ten sam sposób można np. odpalić intro do gry, czy nawet stronę tytułową.
    
    W kwestii pamięci RAM pod ROM-em z kolei myślę, że można dalej pójść tą samą drogą i kolejny blok INI może załadować dane do pamięci ogólnodostępnej, podnieść wtedy ROM, przerzucić te dane do pamięci pod ROM-em, opuścić z powrotem ROM i kontynuować wczytywanie ostatniej części, czyli głównego programu.
    
    Czyli zarys np. może być taki:
    1. Krótki blok INI wyświetlający jakiś napis loading itp., i lecimy dalej z odczytem.
    2. Blok INI wyświetlający np. intro do gry, po naciśnięciu klawisza lecimy dalej z odczytem.
    3. Blok INI z danymi do umieszczenia pod ROM - odczyt do dostępnej RAM, podniesienie ROM, przerzut danych, opuszczenie ROM, lecimy dalej.
    4. Główny program, odczyt całej reszty, uruchomienie, program wyłącza OS i ma dostęp do całego RAM-u.
    
    Czy jest coś o czym nie pomyślałem, albo nie zadziała?
    
    No i jeszcze pytanie: jak skompilować program w Mad Pascalu, żeby mi się z niego zrobił INIT a nie RUN? (chodzi o te pierwsze bloki, które zrobię jako odrębne projekty)
13. • 13: CommentAuthorVidol
    • CommentTime22 Oct 2020 04:10

     
    Zamiast RUN(adres) piszesz INI (adres)
14. • 14:
       
      CommentAuthorMq
    • CommentTime22 Oct 2020 21:10

     
    No yyy... ten teges... ale gdzie piszę zamiast RUN(adres) INI(adres), bo ja tego nigdzie nie piszę, a nie znalazłem nic na ten temat też w instrukcji MP, ani nigdzie indziej...
    
    Mogę poprosić tak bardziej łopatą do głowy?
15. • 15: CommentAuthorxxl
    • CommentTime22 Oct 2020 22:10

     

    TeBe:

    Resource to właśnie bloki INI, będą się uruchamiać wg kolejności którą ustalisz
16. • 16:
       
      CommentAuthorMq
    • CommentTime23 Oct 2020 00:10

     
    @xxl, to nie na temat:-) To ja już wiem, i wiem jak działają resource'y. Wiem też jak zrobić blok INI w assemblerze. Chodzi mi teraz o to jak skompilować osobny programik napisany w Mad Pascalu, żeby on się od razu zrobił jako INI a nie jako RUN. Oczywiście mogę skompilowany programik zgrzebać hex edytorem, ale nie o to mi się rozchodzi, tylko o to, żeby się od razu skompilował jako gotowy blok INI.