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:
      
     CommentAuthorMaW
   • CommentTime30 Jan 2012 12:01 zmieniony

    
   Witam
   
   Tak dla prostego użytkownika Tibeja ze wstawkami w postaci USR$ - zadałem sobie pytanie: jak często można zmieniać kolory w GR0 z działającym programem w TB i jak najlepiej to zrobić ?
   
   Co jakiś czas próbuję pokombinować trochę z GR8/GR0 - czasami mi się udaje(czasami nie ;-)) umyśliłem sobie coś takiego:
   [linia000] {P0 P1 P2 P3 BL} {C L} 00000000 00000001
   [linia001] {P0 P1 P2 P3 BL} {C L} 00000000 00000001
   ..
   [linia191] {P0 P1 P2 P3 BL} {C L} 00000000 00000001
   
   
   co linię podajamy 5 wartości rejestrów graczy (704 705 706 707 708) oraz informację o bicie priorytetu(623, dodatkowe podświetlanie) /czyli jak można było w moich poprzednich wątkach wyśledzić - mamy ekran przykryty PMG (szerokości 4)/, a na końcu wartość koloru tła (710) i wartość jasności znaków (709).
   
   Wydaje mi się, że w takiej konfiguracji będziemy mieli 256 kolorów na ekranie (128?), w tym 3 na linię + 2 poziomy jasności, przyczym zostanie jeszcze dość czasu na "czkający" TBasic.
   
   Pytanie tylko: jak to "wcisnąć" do wyświetlania ? w końcu to 192 komendy podające wartość do 7 komórek, czyli w najgorszym wypadku 4032 bajty (załadowanie wartości, wstawienie wartości do komórki docelowej *192*7) ?
   
   PS. Jeżeli ktoś byłby chętny do napisania edytora takiego "trybu" (prostszego od G2F - tu konkretnie jest potrzebne wczytanie obrazka znakowego, powiększenie i możliwość ustawienia wartości "z palety" dla 7miu rejestrów danej linii plus wyłączenie podświetlenia/pikseli PMG) - to niech wyśle priva, być może będę w stanie partycypować w kosztach jego wykonania (w końcu tak mało mamy softu dotyczącego a8 na pecetach, że warto wspierać każdą inicjatywę).
2. • 2: CommentAuthor0xF
   • CommentTime30 Jan 2012 17:01

    
   Też mi argument - G2F to obsługuje, ale to tylko jeden program, więc zróbmy drugi bardziej okrojony.
   Kolorów jest max. 128. Jak chciałeś ustawić duszki w poziomie?
   Podobne możliwości daje SHIMC bez użycia duszków, w dodatku udostępnia interlace.
3. • 3:
      
     CommentAuthorjhusak
   • CommentTime30 Jan 2012 18:01 zmieniony

    
   Mało casu kruca bomba, mało casu.
   
   Generalnie:
   w trybach tekstowych masz co 8 linię tzw bad linię, w której właściwie nic nie wciśniesz.
   pozostałe linie też nie zostawiają wiele czasu. Cała linia to bodajże 114 cykli, z czego 40 cykli zabiera dma antica, jeszcze kilka na dma pm, i jeszcze z 10 na refresh memory (piszę z pamięci)
   Zostaje ca 50 cykli, może upchniesz tam 6-7 rozkazów lda sta ale tylko, jeśli są w trybie adresowania natychmiastowym (lda #xx sta)
   Będą się zmieniać po kolei, i będzie to widać. Nie da rady tak, jak chcesz.
   

   (załadowanie wartości, załadowanie komórki docelowej, wstawienie wartości do komórki docelowej *192*7) ?
   

   
   wywal środkową część zdania, to będzie prawda.
4. • 4: CommentAuthornosty
   • CommentTime30 Jan 2012 19:01

    
   Tez to przerabialem w zeszlym roku i bylem bardzo zdziwiony ze trzeba tak cudowac ;) Ale liczby niestety nie klamią. To co napisal Jakub tlumaczy sie nastepująco: przy duzej dyscyplinie w asm w praktyce uda Ci sie zmienic pewnie i "czysto" chyba tylko 5 rejestrow. Resztę zmian moze juz byc brzydko widac.
5. • 5:
      
     CommentAuthorMaW
   • CommentTime30 Jan 2012 20:01

    
   @Fox: mam własną grafikę na fontach, ale jest mono, tym "trybem" chciałbym ją podkolorować - nie dość, że żeby to zrobić w G2F muszę znać program, to jeszcze nagłówkować się, by z zestawów fontów przenieść mapy na postać zjadliwą dla G2F, przyczym wszystkie priorytety i pokrycie duszkami ustawiać ręcznie - zdecydowanie użycie G2F do tego będzie armatą na muchy.
   Kolory - 128 w dwóch jasnościach ?
   SHIMC - ale jak go użyć przy TB ?
   
   @Tebe, @Jakub: z trybu znakowego chcę skorzystać z powodu odciążenia programu rysowaniem elementów (lwią część zadania przerobi ANTIC), no i wykorzystanie pamięci także robi swoje (zestawy znaków powtarzają się, na 16 plansz wystarczy 5 zestawów aż nadto) - czy nie dało by się skorzystać z czasu na ramce ?
   
   Czy ta "bad line" to linia, w której ANTIC zabiera się do "składania" znaków ? "Strata" co ósmej linii to nie strata - to tylko mniejszy o 1/8 zysk kolorów :) - teraz nie ma ani jednej linii kolorowanej w GR.0.
6. • 6:
      
     CommentAuthortdc
   • CommentTime30 Jan 2012 21:01

    

   MaW:

   Czy ta "bad line" to linia, w której ANTIC zabiera się do "składania" znaków ?

   
   W uproszczeniu można założyć, że tak.
7. • 7: CommentAuthortebe
   • CommentTime30 Jan 2012 22:01 zmieniony

    
   MaW "stracisz" czas na naukę G2F a to zaprocentuje w przyszłości
   
   bad lines można wyłączyć, dla trybu kolorowego będzie oznaczać to brak pełnej kontroli nad inwersem znaków (5-y kolor) ale dla GR0 to bez znaczenia
   
   największe znaczenie ma zużycie pamięci, wyłączenie bad lines to 30KB na znaki, każdy wiersz obrazu to kolejny zestaw znaków
   
   najwięcej zmian na linię oferuje ekran wąski, możliwych jest 6 zmian zanim plamka wejdzie w obszar grafiki, pozostałe zmiany to już zmiany właśnie w obszarze grafiki
   
   w przypadku wyłączenie bad lines i ekranu wąskiego to 5 zmian bo jeden zapis tracimy na rejestr scrola pionowego
8. • 8: CommentAuthor0xF
   • CommentTime30 Jan 2012 23:01

    
   W trybie znakowym zapomnij o zmianach 7 rejestrów co linię. Albo nie zmieniasz kolorów, albo GR.8.
   
   SHIMC użyjesz w TB dokładnie tak jak Twojego trybu: piszesz procedurę w asm obsługującą go.
   
   I naucz się G2F - gdyby ktoś Ci napisał nowy program to i tak będziesz się musiał go nauczyć. A jak masz grafikę mono, to chyba można do G2F wrzucić BMP ?
9. • 9:
      
     CommentAuthorMaW
   • CommentTime31 Jan 2012 10:01

    
   Gdyby ktoś pisał "ze mną" nowy program to byłby on na tyle dla mnie intuicyjny, że nie musiałbym już się go uczyć obsługiwać :).
   
   Fox, to nie grafika mono, to mapy :P - przerabianie ich z powrotem na grafikę i import do G2F to trochę krok w tył :) - swego czasu próbowałem swych sił z G2F, nawet Tebe'go molestowałem o parę zmian i zgłaszałem kilka błędów, niestety w wersji, do której wtedy siadłem było kilka problemów (przynajmniej dla mnie) związanych z mapami znakowymi (ogólnie ciężko operować na G2F znakami), w tamtym czasie też Nosty(sorki Nosty )*^v^*( ) podsunął mi nowego Envisiona ->link<- i powiem, że udało mi się w nim nawet stworzyć parę map (w tym do gry Nostego - niestety zadanie mnie przerosło/zaczął się dla mnie ciężki okres :( / ) i zestawów znaków, a nawet miałem nadzieję, że uda się namówić Jakuba na podkolorowywanie map duszkami :).
   Dlatego już prędzej bym wolał skorzystać z tamtego importu map, niż robić wszystko od nowa w G2F.
   
   Wracając do tematu:
   
   1. SHIMC - jakie ma zalety w stosunku do standardowego trybu znakowego, w którym operując blokami pamięci, za pomocą zapętlonego timerem USR-a, jestem w stanie prosto wygenerować sobie animację znaków i jak się uprę, animację software'owego PMG ?
   
   2. Na zasadzie LDA#, STA msb,lsb (6 cykli) dam radę co linię wyłącznie zmienić wartość 1 rejestru koloru, czy się mylę? I zwężenie ekranu mi w tym nie pomoże? Czy jednak da się to jakoś krócej zrobić i wykroić więcej czasu (powiedzmy raz zmieniam kolor tła i znaku, raz kolor pierwszej pary graczy, raz drugiej pary, rezygnuję z piątego gracza i zmiany priorytetów)
   
   3. (@Tebe)

   największe znaczenie ma zużycie pamięci, wyłączenie bad lines to 30KB na znaki, każdy wiersz obrazu to kolejny zestaw znaków

   na jakiej zasadzie to działa?
10. • 10: CommentAuthor0xF
    • CommentTime31 Jan 2012 10:01

     
    Bardzo powoli dochodzimy do tego, co chcesz osiągnąć. Cały czas nie wiemy, jak chcesz ustawić duszki i czemu mają one służyć.
    
    Przy sporym zacięciu i pomyślnych wiatrach w badliniach normalnej szerokości możesz zmienić maksymalnie 4 rejestry. Zwężenie ekranu jak najbardziej pomoże.
11. • 11: CommentAuthortebe
    • CommentTime31 Jan 2012 12:01

     
    wyłączenie bad lines polega na tym że tylko pierwszy wiersz obrazu jest przetwarzany-dekodowane są znaki, potem w kolejnych wierszach są te znaki powtarzane
    
    stąd brak możliwości zmiany inwersu znaku w kolejnych wierszach (5-y kolor) czy zmiany samych znaków, masz konkretne znaki np. 0..39 na całej wysokości obrazu
    
    p.s.
    trick z wyłączaniem bad lines poprzez scrol pionowy opracował 0xF, ja go tylko zaimplementowałem w G2F
12. • 12:
       
      CommentAuthorMaW
    • CommentTime31 Jan 2012 14:01 zmieniony

     
    Dzięki za podpowiedzi, tak mi gdzieś świtało, że to zasługa Foxa - chyba był wątek w tym temacie na AA (niestety nie umiem go znaleźć w odmęcie nowych :/ )
    
    Z duszkami PMG po rozłożeniu ich na całej szerokości (pix:32+8|32+8|32+8|32+8) ekranu nie chcę nic więcej robić (no może tylko raz na ekran zmienić stan bitów) - chodzi mi o użycie ich do podkolorowania znaków podobnie jak atrybutów w ZX.
    
    Podsumowując - żeby nie za dużo mieszać w obrazie (tzn. mieć 24x40 znaków) i nie marnować 30kB cennej pamięci(zestawy!) trzeba pogodzić się z tym, że co ósmą linię liczba aktualizowanych kolorów spadnie do 4ch (co nie jest zbyt wielką stratą - zakładam, że użytkownik naraz nie będzie chciał zmienić większej ilości kolorów /nie mówcie nic Oozowi i Piesiowi ;)/) - coś mi świta, że te zabezpieczenie chyba jest wmontowane w G2F. I koło się zamyka...
    
    hmm... a kiedy czas na zmianę charsetu? Czy także potraktować ją jak zmianę rejestru kolorów?
    
    Jeśli dobrze liczę, charset należało by zmieniać w linii przed kolejną bad line? I przy korzystaniu z zestawów niezoptymalizowanych by mieć dostęp do 5ciu zestawów, dokonywać zmian co 32 linie wyświetlania (4 wiersze)? I w tym momencie w takiej linii także ograniczyć się do 4ch zmian rejestru?
    
    //EDIT: dobra, wszystko wychodzi wprost jak się z G2F wyeksportuje charsety, DLI i ASM... - troszkę skomplikowany ten plik (spodziewałem się rpostej listy LDA#, STA adrs) - czy jest jakiś edytor wyjaśniający co oprócz procedury ładującej obrazek (main) dzieje się podczas wyświetlania ? typu linia ekranu - zmieniane rejestry ?
13. • 13:
       
      CommentAuthorMaW
    • CommentTime31 Jan 2012 20:01 zmieniony

     
    Czarna magia te pliki... to już wolę linie DATA w basicu...
    
    Czy mogę prosić Was o przykład procedury zmieniającej kolory jednej linii - tymi optymalnymi czterema ?
    
    Czym musi być zainicjowana, jak zsynchronizować ją z przerwaniem obrazu (i którym), jak ustawiać wektor wejścia, aby przy kolejnym wywołaniu przerwania wskaźnik procedury był ustawiony już na następną sekwencję zmiany rejestru ?
    //EDIT:i po lemurze :P
14. • 14:
       
      CommentAuthorjhusak
    • CommentTime1 Feb 2012 03:02 zmieniony

     

    tebe:

    największe znaczenie ma zużycie pamięci, wyłączenie bad lines to 30KB na znaki, każdy wiersz obrazu to kolejny zestaw znaków
    

    
    Ale oczywiście można pozostałe luki zamienić na:
    - miejsce na kod z dziurami na pamięć ekranu
    - animację znaków (3 fazy)
    - dane duszków softsprajtowych.
    
    Ale jazda z tym trybem.
    Czego to Człowiek nie wymyśli (tak, Jeden Człowiek)
    
    A jak widzę tego lemura to mam wrażenie że przecięcie jego oczu jest niepuste :P
15. • 15:
       
      CommentAuthorMaW
    • CommentTime1 Feb 2012 20:02 zmieniony

     
    wracając do tematu - jak zrobiona jest pauza w Chimerze ?
    
    //EDIT: tam chyba nie ma tyle zmian - imho to złudzenie, poruszają się tylko 2 paski z dwoma cyklami kolorów
    
    PS. nadal proszę o przykładzik :P
16. • 16: CommentAuthortebe
    • CommentTime2 Feb 2012 10:02

     
    podejrzewam że poprzez synchronizację z $D40B, licznik linii obrazu
17. • 17:
       
      CommentAuthorMaW
    • CommentTime6 Apr 2012 09:04 zmieniony

     
    wracając do "wątku" - at0mic tutaj: ->link<- (plik ->link<- ) wkleił procedurkę pokazującą "badlines" - moje pytanie jest takie: jak je ominąć, aby tęcza była równomierna i nie traciło się zestawów (jeden w linii) znaków? Czy zacząć zmieniać kolory, gdy ANTIC wkroczy na czarną ramkę? Jeżeli tak, to jak wyznaczyć jej początek, by nie powodowało to tracenia cykli na zliczanie?
    
    //EDIT: metoda z G2F jest dla mnie "za ciężka" (co już pisałem) - całość "ekranu" chciałbym zmieścić w 16kB jednolitego bloku...
18. • 18:
       
      CommentAuthorjhusak
    • CommentTime6 Apr 2012 20:04

     
    jeden kolor lub rejestr scrolla możesz zmienić, ale więcej to już jest problematyczne (jeśli zrobisz lda; sta wsync; sta color;)
19. • 19:
       
      CommentAuthorMaW
    • CommentTime7 Apr 2012 13:04

     
    Kuba, nawet jak zamianę rozpoczniemy "pod ramką" na koniec rysowania widocznej części poprzedniej linii?
20. • 20:
       
      CommentAuthorjhusak
    • CommentTime7 Apr 2012 16:04

     
    Może wtedy ze dwa rejestry, ale to trzeba wycyklować nopami.
    Przerwanie DLI jest wykonywane w ostatniej linii trybu tekstowego, co wraz z rozpoznaniem rodzaju przerwania itepe powoduje, że już jesteśmy prawie na końcu linii ledwo rozpoczynając procedurę przerwania. Naprawdę mało czasu, trzeba próbować i wyczuć zależności czasowe.
21. • 21: CommentAuthorBrix
    • CommentTime8 Apr 2012 00:04

     
    metoda z G2F jest dla mnie "za ciężka"

    
    Czy chodzi Ci o to, że co 2 dwie linie chcesz mieć zmianę zestawu znaków i móc prosto załadować (choć przy tych rozmiarach lepiej rozpakować) grafikę z pliku .fnt z g2f?
    
    Jest to absolutnie możliwe przy użyciu opcji "Options - Standard " oraz odpowiednim użyciu "Special - limitations". Niestety, najnowszy g2f ma chyba jakiegoś dziwnego buga i działa to bardzo źle (albo czegoś nie rozumiem), ale w starszych wersjach g2f jest ok..
22. • 22:
       
      CommentAuthorMaW
    • CommentTime8 Apr 2012 23:04

     
    1/ "za ciężka" do zrealizowania/przeanalizowania (tam naprawdę dużo się dzieje, jak ktoś podglądał plik *.asm)
    2/ "za ciężka" bo tracimy strasznie dużo pamięci, którą praktycznie do niczego już nie da się wykorzystać*(*-przy załóżeniu, że raz przypisaną pamięć używamy wyłącznie jako pamięć do odczytu, która i tak nie może przekroczyć 16kB, bo nie ma czasu na to,żeby ją przepisywać)
    3/ "za ciężka" bo niezbyt nadaje się do obsługi dynamicznych zmian rejestrów kolorów (ok, dobra - zmian zawartości ekranu - podczas wyświetlania pojedyńczego ekranu kod "wspomagający" DL jest statyczny)
23. • 23:
       
      CommentAuthorMaW
    • CommentTime10 Apr 2012 20:04 zmieniony

     
    wracając do tematu, jak "wpaść" na to, że już zaczyna być rysowana ramka ?
    //EDIT: czytam to ->link<- i próbuję zrozumieć "Rysowanie z góry na dół szybsze od wyświetlania" celem zastosowania do zmiany kolorów
24. • 24: CommentAuthorVidol
    • CommentTime10 Apr 2012 20:04

     
    lda 20
    cmp 20
    beq *-2
    
    lub
    
    LOOP lda $d40b
    cmp #$02
    bne LOOP
25. • 25:
       
      CommentAuthorMaW
    • CommentTime10 Apr 2012 20:04 zmieniony

     
    Dzięki Vidol! Czyli włączam timer wraz z rozpoczęciem rysowania linii i albo sprawdzam, co jest w VCOUNT, albo "ręcznie" ustalam czas trwania linii (->Jakub) - właśnie trafiłem przez google tutaj ->link<- zobaczymy, co z tego wyjdzie (najtrudniej napisać kod który by później współgrał z TiBejem, o ile nie wogóle się uruchamiał :P ).
    
    //EDIT: stop, to nie to - VCOUNT-em "znajdę" nie lewy brzeg, ale dolną krawędź - a chodzi mi o to, aby zacząć zmiany kolorów zanim zacznie się rysować kolejna linia, przy czym zakładam wykorzystanie czasu "przeskoku wiązki" (z końca poprzedniej linii na początek następnej) na inne zmiany (sprajty software'owe - da się, da się ?).
26. • 26: CommentAuthorbob_er
    • CommentTime10 Apr 2012 21:04

     
    robisz sta $d40a (WSYNC) - i procesor rusza równo z prawą krawędzią. w trakcie powrotu plamki na lewą stronę pakujesz w rejestry co trzeba. możesz też wywalić sta wsync (masz wtedy trochę więcej czasu, ale nie wiesz dokładnie od którego momentu linii), tylko od razu w rejestry pchać, ale wtedy musisz pokombinować (znaleźć najlepszą kolejność zapisu w rejestrach), byś nie miał mrugania po prawej stronie (dosyć często widziany efekt).
    a jak znaleźć właściwą linię - albo cyklujesz się vcountem, albo dli.
27. • 27:
       
      CommentAuthorMaW
    • CommentTime10 Apr 2012 22:04

     
    DLI wskakuje w trybach znakowych raz na linię znakową, na ostani cykl koloru ostatniej linii ekranu - prawda ?
28. • 28: CommentAuthorBrix
    • CommentTime10 Apr 2012 22:04

     
    Ma się jeszcze trochę czasu do pierwszego użycia "sta wsync" (teraz nie powiem ile, nie chce mi się sprawdzać ), co się poświęca na zachowanie rejestrów i np. załadowanie ich nowymi wartościami. Ale najlepiej to sprawdzić "na żywo". Do następnych linii "graficznych" w trybie znakowym i tak trzeba się dostać tylko przez "sta wsync". Ale tryby znakowe to też tzw. "bad line" (czasem niemal dwa ;), gdzie nie ma co marzyć o zmianie czegoś bezpośrednio na ekranie.
    
    Właściwie to wyobraziłem sobie teraz całą obsługę ekranu opartą na "sta wsync" (bez DLI) - ale to już raczej nie ma sensu - chyba że akurat mieć będzie :)
29. • 29:
       
      CommentAuthorjhusak
    • CommentTime11 Apr 2012 02:04 zmieniony

     
    Polecam Altirra hardware reference manual: ->link<-
    Tam jest wszyściutko opisane dokładnie i bez lania wody.
    
    To trigger a DLI, bit 7 should be set on a display list instruction. This causes ANTIC to fire an NMI at the start of the last scan line for that mode line. Typically the DLI interrupt handler will then issue an STA WSYNC in order to synchronize to the end of the scan line, enabling it to write to hardware registers just prior to the next mode line at a time where the user will not see artifacts from the changes.
30. • 30: CommentAuthorbob_er
    • CommentTime11 Apr 2012 19:04

     
    Brix: na sta wsync to mógłbyś zrobić np. kefren bary :).