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: CommentAuthorilmenit
   • CommentTime27 Feb 2013 zmieniony

    
   Hej,
   
   Gdy potrzebujemy wydajnej obsługi grafiki warto zrobić liniowy dostęp do pamięci ekranu tak, aby każda linia ekranu zaczynała się od nowej strony. Wtedy możemy robić super szybkie STA linia,Y.
   Zależnie od trybu graficznego przy takiej organizacji pamięci pozostaje na każdej stronie sporo miejsca do wykorzystania. O ile nie jest problemem, gdy wrzucamy tam dodatkowe dane, fajnie, gdyby można było tam wrzucić też kod.
   Można to zrobić ręcznie na przykład za pomocą MADSowego .PAGES oraz ORG, ale jest to bardzo uciążliwe dla większego projektu np. gdybyśmy chcieli pracować z liniowym hiresem 320x200.
   
   No i tu pomysł, który mógłby przenieść MADSa na jeszcze wyższy poziom abstrakcji, zbliżony do języków wysokiego poziomu.
   
   MADS umożliwia tworzenie kodu relokowalnego, więc może dałoby radę wrzucać określony kod na strony pamięci za przydzieloną im pamięcią graficzną (lub inną predefiniowaną), wszędzie tam, gdzie jest miejsce?
   
   Wymagałoby to oczywiście auto-korekcji kodu, który nie mieściłby się w granicy strony za pomocą trampolin JMP. Ponieważ kod taki byłby mniej wydajny konieczne byłoby oznaczanie go specjalnym znacznikiem.
   
   BARDZO pomogłoby to również twórcom kompilatorów języków wysokopoziomowych opartych na MADS takich jak Atalan czy Effectus.
   
   Co myślicie?
2. • 2:
      
     CommentAuthorpirx
   • CommentTime27 Feb 2013

    
   pomysł jest super fajny, widzę mnóstwo miejsc, w których mógłby się przydać - resztki po sprajtach, fontach, grafice, etc.
   
   Pytanie inne - w jakim przypadku taki tryb graficzny (z ładowaniem adresu przez antica w każdym wierszu) jest opłacalny, biorąc pod uwagę, że w ten sposób zje się ~1/4(?) czasu procka.
3. • 3: CommentAuthor0xF
   • CommentTime27 Feb 2013

    
   Chybiony pomysł. Szatkowac cały kod żeby oszczędzić pojedyncze cykle na stawianiu pikseli? Pomyśl lepiej o innych optymalizacjach.
4. • 4:
      
     CommentAuthormgr_inz_rafal
   • CommentTime27 Feb 2013 zmieniony

    

   pirx:

   pomysł jest super fajny

   0xF:

   Chybiony pomysł

   W takim razie ja jeste za a nawet przeciw :)
5. • 5: CommentAuthormono
   • CommentTime27 Feb 2013 zmieniony

    
   IMHO fajnie byłoby gdyby w madsie można było definiować sobie sekcje, których umieszczenie w pamięci i rozmiar określałoby się wyrażeniem. Przykładowo:
   

   .sect zpg
   v1 .ds 1
   v2 .ds 2
   .ends
   
   .sect ram
   procedurka:
     ... ;cos robimy
     rts
   .ends
   
   .sect zpg
   v10 .ds 20
   .ends
   

   
   i niech sobie MADS poklei kawałki i ewentualnie pokaże błąd jak przekroczymy rozmiar sekcji. Albo jak nie da się umieścić kawałka kodu w żądanej sekcji.
   A sekcje można by np. definiować:
   

   zpg     .defsect start=$0 size=$100
   stack   .defsect start=$100 size=$100
   ram     .defsect start=$2000 end=$bfff
   scr     .defsect start=(@ & $f000) size=$1000
   dl      .defsect start=(@ & $fc00) size=$400
   xram    .defsect start=$4000 size=$4000
   chr128  .defsect start=(@ & $fc00) size=$400
   chr64   .defsect start=(@ & $fe00) size=$200
   pmg1    .defsect start=(@ & $f800) size=$800
   pmg2    .defsect start=(@ & $fc00) size=$400
   romram  .defsect start=$c000 end=$cfff
   romram  .defsect start=$d800 end=$ffff
   io      .defsect start=$d000 end=$d7ff
   testrom .defsect start=$5000 end=$57ff
   devrom  .defsect start=$d800 end=$dfff
   

   
   Coś w tym stylu.
   @ to symbolicznie adres. Trzeba by pomyśleć nad rozsądną składnią pozwalającą definiować obszary tak, żeby od reguły można było tworzyć wyjątki (romram obszar $c000..$ffff z dziurą na io).
   Taki mechanizm miałem (w postaci wbudowanych sekcji) w asm KEIL Electronics do 51 i pisało mi się w tym bardzo wygodnie.
   A to myślę zaspokoiło by też (przynajmniej częściowo) ilmenita :)
   
   Edit: Oczywiście kwestia do rozstrzygnięcia jak rozmieszczać bloki przy sekcjach nakładających się.
   
   Edit 2: pmg może nawet tak:
   

   pmg1    .defsect start=(@ & $f800 + $300) size=$500
   pmg2    .defsect start=(@ & $fc00 + $180) size=$280
   
6. • 6: CommentAuthorilmenit
   • CommentTime27 Feb 2013

    
   Jest to dosyć zbliżone do tego, co jest w CC65:
   ->link<-
7. • 7: CommentAuthorKonop
   • CommentTime27 Feb 2013

    
   @mono: Mads wspiera już od jakiegoś czasu funkcjonalności segmentów.
   Sprawdź dokumentację pod kątem nastepujących dyrektyw: .SEGDEF, .SEGMENT, .ENDSEG.
8. • 8: CommentAuthormono
   • CommentTime28 Feb 2013

    
   @Konop: Dzięki. Przeoczyłem :/
9. • 9: CommentAuthormono
   • CommentTime4 Mar 2013 zmieniony

    
   Ok. .SEGDEF, .SEGMENT i .ENDSEG działają świetnie przy generowaniu tradycyjnej binarki (dla DOSów zgodnych z 2.x). Deklaruję sobie coś takiego:
   

   .segdef zpg $80 $80
   .segdef ram $2000 $8000
   

   
   i teraz spokojnie mogę się dowolnie przełączać między blokami w kodzie za pomocą .SEGMENT/.ENDSEG. Umożliwia mi to pisanie kodu rozproszonego na wiele plików (np. biblioteki) i wykorzystanie ich w projekcie bez konieczności przypisywania adresów procedurom i rejestrom na zpg. MADS to wszystko ładnie porozmieszcza sam.
   
   A czy da się w MADSie robić coś takiego ale dla binarki SDX (chodzi o bloki typu RELOC, EMPTY i SPARTA)? Chciałbym móc np. zdeklarować coś w tym stylu:
   

   .segdef zpg $80 $80   ;górna połówka zpg
   .segdef main reloc    ;blok relokowalny o nieznanym rozmiarze
   .segdef work empty    ;blok rezerowany na dane o nieznanym rozmiarze
   .segdef data empty $100 ;blok rezerowany na dane o określonym z góry rozmiarze
   .segdef init sparta $600 $100 ;blok stały $100 bajtów od $600
   

   
   i teraz przełączać się między nimi w kodzie np. tak:
   

   .segment init
     sec
     ror
     bit *-1
     rol
     rts
   
     .segment zpg
   adr1 .ds 2
   adr2 .ds 2
   
     .segment main
     ldy #0
   @ lda (adr1),y
     sta (adr2),y
     iny
     bne @-
     rts
   
     .segment work
   cos .ds 1
   
     .segment main
     lda cos
     pha
     ...
     pla
     sta cos
     rts
   

   
   i niechby MADS zrobił z tego 1 blok RELOC, 1 blok SPARTA i 1 blok EMPTY. Blok zpg ma za zadanie jedynie przypisać dynamicznie adresy zmiennym na zpg i nie generować żadnego bloku w pliku dla SDX (empty robi to samo, lecz generuje blok EMPTY w binarce).
   Wiadomo, że SDX ma ograniczenie do 7 bloków relokowalnych dlatego chciałbym właśnie móc deklarować segmenty w takich blokach tak, żeby MADS łączył zawartość segmentów w ramach konkretnych bloków.
   Rozmiar bloku work byłby przez MADSa obliczany i na tej podstawie generowany byłby odpowiedni nagłówek EMPTY w binarce.
   Obecnie mogę chyba tylko używać dyrektywy BLK, która porobi mi oddzielne bloki w pliku :/
   
   Edit: Mocno ułatwiłoby to pisanie kodu bibliotek i używanie ich w projektach dla SDX.
10. • 10: CommentAuthorbrx
    • CommentTime9 Mar 2013

     
    Tak przy okazji... Mam taki problem i nie za bardzo wiem, jak go najlepiej rozwiązać, a "ręcznie" jest to bardzo kłopotliwe. Mam nadzieję, że się wyrażę w miarę jasno.
    
    Czy istnieje jakiś prosty sposób na rezerwację w kodzie bloku na kod lub dane, który będzie miał określoną długość, nie będzie można jej przekroczyć, a wolne miejsce zostanie wypełnione np. zerami?
    
    Kombinowanie z pages wespół z align i org - nie do końca to mi idealnie wychodzi, a te segmenty to albo jakiś wyższy poziom abstrakcji, albo kompletnie nie umiem i nie rozumiem... Miałby ktoś może jakiś pomysł?
11. • 11: CommentAuthortebe
    • CommentTime9 Mar 2013

     
    może .DS liczba_bajtów
12. • 12: CommentAuthorbrx
    • CommentTime9 Mar 2013

     
    DS jest bardzo użyteczny, ale tu mi na nic, bo rezerwuje pustą przestrzeń, ale nie z zawartością w postaci kodu do asembleracji czy danych. No nic, poradziłem sobie org-ami + pages + parę kontrolnych printów sprawdzających długość danych, trzeba będzie jeszcze czyścić tę pamięć przed ini - ale paskudnie to wygląda...
13. • 13: CommentAuthortebe
    • CommentTime9 Mar 2013

     
    można trzymać w pamięci wiele procek, które będą asemblowane pod konkretny adres, np.:
    
    .local prg1, adres_procki
    .endl
    
    .local prg2, adres_procki
    .endl
    
    potem taki LOCAL przekopiować pod ADRES_PROCKI