Początkowo chciałem się podpiąć pod poprzedni topic ale stwierdziłem, że może być mylący...

Nakreślę problem.

Atari zapisuje dane do wyświetlania grafiki w horyzontalnie bajt po bajcie i linia po linii. Upraszcza to odwołanie do pamięci reprezentującej poszczególne bity wyświetlane na ekranie. Z wyświetlaczami jest inaczej...  reprezentacja danych jest pionowa, pierwszy bajt to:
M          x,y
0B:  0,0 do 0,7
1B:  1,0 do 1,7
2B:  2,0 do 2,7
...
161B:  161,0 do 161,7
162B:  161,8 do 161,15
...
1295B: 161,56 do 161,63

Każdy piksel jest reprezentowany 1 bitem, który jest jednocześnie bitem koloru - czyli jak w gr.8 ale z mniejszą rozdziałką.
Chciałbym operować na obszarze pamięci, który po przygotowaniu wyślę w całości do wyświetlacza... i tu zaczynają się schody bo o ile wiedząc gdzie chcę umieścić dane mogę je sobie wcześniej przygotować to dynamiczne przygotowanie ramki wymaga napisania procedur (plot, line) w miarę uniwersalnych, przyjmujących parametry x,y,color. Czy ktoś podpowie jak to zrobić w najprostszy sposób? Mogę oczywiście operować na poszczególnych stronach pamięci wyświetlacza (PAGE0-PAGE7 - każda po 162 bajty) ale to wymaga przewidywania linii w którą wrzuca się dane i kicha z uniwersalności)...

Post's attachments

S1D15705-15160194027.pdf 596.09 kb, liczba pobrań: 12 (od 2019-08-10) 

Tylko zalogowani mogą pobierać załączniki.
https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email

2

Nie znam dokładnie Twojego systemu, ani co tam dokładniej kombinujesz, ale opcje widzę dwie:
1. Dodasz trochę tablic (które przeliczą współrzędne X i Y na Twoj wyświetlacz) i zrobisz plota, który będzie działać na pamięci wyświetlacza. Tablice powinny być dosyć proste. Mając działającego plota linie i inne są już (w miarę) proste.
2. Rysujesz na pamięci jak normalnie dla XE to robisz. Potem konwertujesz tą pamięć i przesyłasz do wyświetlacza. Ale jak już pisałem - nie znam systemu, więc ciężko mi ocenić czy przesyłanie w kółko całości jest racjonalne (chyba, że i tak wysyłasz - w speca się nie wczytywałem dokładniej i nie wiem, czy da się wysłać mniejsze kawałki).

btw: następnym razem zainwestuj w wyświetlacze DSI - tam jest command mode :).

3

Temat jest konsekwencją zastosowanego "przykładowo" kontrolera  GLCD d1s15705 w temacie
VIAtariXE. Jeśli wezmę inny wyświetlacz sterowany bezpośrednio - problem będzie taki sam. DSI to zupełnie inna półka... tu LCD jest podpięty prymitywnie do PIA.

Ja nie jestem programistą - owszem, potrafię oprogramować sterownik/chip ale brakuje mi polotu w adaptacji algorytmów wysokiego poziomu.. I tak: rysować w RAM-ie potrafię jeśli wiem co i gdzie mam narysować. Wysłać ramkę do LCD też :-). Nie potrafię natomiast w prosty sposób odwzorować dynamicznego rysowania w RAM komputera tego co wyślę na LCD.

https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email

4 Ostatnio edytowany przez qbahusak (2019-08-11 23:54:12)

Jeśli chodzi o testowe podejście, to można by to zrobić w pionie w trybie tekstowym na grafice umieszczonej w generatorze znaków. Minus - to brakuje znaków (20*8 = 160, a mamy 128). Ale do testów - zadziała, tylko nie będzie widać ostatnich dwóch linijek. Można to jeszcze ulepszać, ale masz co chciałeś - pamięć gotową do wysłania do wyświetlacza jednocześnie wyświetlaną bezprzerabiania na Atari w gr.0. Można poeksperymentować z wyświetlaniem dwóch półramek 25Hz  z dwoma przełączanymi generatorami znaków o ciągłym obszarze pamięci i dwoma przełączanymi ekranami z poukładanymi znakami w odp. miejscach.

5

Taki test już zrobiłem  - jako pierwsze sprawdzenie wysłałem RAW generatora znaków Atari o wyświetlacza. Próba udana niemniej jednak reprezentacja danych w GLCD jest pionowa to i wyświetlane znaki były obrócone o 90 stopni. Zasadniczo żaden problem, można je obrócić.. Ale ja umieściłem w programie generator znaków 5x8, które wydają się bardziej proporcjonalne - no i więcej ich się zmieści (32 zamiast 20). Przygotowanie i wyświetlenie dowolnego stringa nie stanowi problemu, wystarczy wiedzieć gdzie zaczyna się pamięć każdej linii i robi się to podobnie jak w np w AVR i wyświetlaczu HD44780. Natomiast jeśli chodzi o 'produkcyjne' zastosowanie to przydały by się procki do rysowania (w końcu to GLCD) i tu nieliniowość (albo raczej specyficzna liniowość i podział na strony) pamięci wyświetlacza generuje problemy...  Problem jest typowo studencki, algorytmiczny bo przeniesienie kodu wprost z C do asemblera Atari nie jest takie proste.Ten wyświetlacz można potraktować jako 8 struktur 162x8 piksli przy czym każdemu X odpowiada kolejna komórka a Y bity 0-7 w tej komórce. Jak zbudować strukturę, którą będzie łatwo można modyfikować i wysłać jako ramkę do GLCD?

https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email

6

Nie rozumiem problemu. Chyba. Jeśli chodzi o grafikę, masz 2 podejścia: albo mażesz punkt po punkcie algorytmicznie bezpośrednio na wyświetlaczu, co jest wolne ale nie potrzebuje pamięci, albo masz całą ramkę w pamięci, mażesz po niej i wysyłasz raz na jakiś czas. Jak to zrobić, to już jakieś tam przeliczanie współrzędnych i operacje na bitach.
Natomiast jeśli chodzi o tekst i bitmapy, można sprytnie za pomocą struktur danych definiować wygląd, a raz na jakiś czas wysyłać ramkę w locie. Trzeba tylko od drugiej strony działać - wiedzieć, co postawić na konkretnym kolejnym miejscu, czyli jaki bajt wysłać kolejny. Kiedyś tak zrobiłem do jakiegoś sterownika i działało spoko. Było całe gui + bitmapy i to wszystko w locie.

7 Ostatnio edytowany przez xxl (2019-08-12 13:29:37)

ja tez nie rozumiem problemu dlatego napisze kilka linijek kodu.

tak wyglada PLOT?

     ldy px
     ldx py
     lda tabpageH,x
     sta zpadr+1
     lda tabpageL,x
     sta zpadr
     lda tabpix,x
     ora (zpadr),y
     sta (zpadr),y


a zeby bylo wiadomo jak przyotowac tablice to wyjasnienie:

     lda py
     and #%00111111 ; max y=63
     pha
     and #%00111000 ; ktora strona
     tax
     lda tabpage_h,x
     sta zpadr+1
     lda tabpage_l,x
     sta zpadr
     pla
     and #00000111 ; pixel
     tax
     lda tabpix,x
     ldy px  ; max x=161
     ora (zpadr),y
     sta (zpadr),y

?

---
a jak na bufor ekranu zaalokujemy sobie 8 stron to zpadr =0 i PLOT wyglada tak:

     ldy px
     ldx py
     lda tabpageH,x
     sta zpadr+1
     lda tabpix,x
     ora (zpadr),y
     sta (zpadr),y

---
a mozna podac konkretny adres w pamieci wyswietlacza do ktorego chcemy wyslac bajt czy trzeba wysylac cala "strone" czy nawet 8 "stron" ?

http://atari.pl/hsc/ad.php?i=1.

8

Procedura @xxl'a zapala piksel ale nie pozwoli na zgaszenie.

Poniżej może trochę przejrzyściej, choć ciut wolniej:

;C-color (0..1), Y-x coord (0..161), X-y coord (0..63)

plot    lda rowadl,x
        sta adr
        lda rowadh,x
        sta adr+1

        lda (adr),y
        and masktab,x
        scc
        ora pixeltab,x
        sta (adr),y
        rts

rowadl:
:64     .byte <[screen+162*[#/8]]
rowadh:
:64     .byte >[screen+162*[#/8]]
masktab:
:64     .byte [1 << [~# & %111]] ^ $FF
pixeltab:
:64     .byte [1 << [~# & %111]]

screen  .ds 162*[64/8]

Znacznikiem C podajesz kolor piksela, w Y-x a w X-y. W screen masz bufor ekranu - kolejno 8 "stron" (po 162 bajty) w organizacji takiej, jak potrzebujesz dla wyświetlacza.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

9 Ostatnio edytowany przez pancio.net (2019-08-18 18:49:42)

Dzięki wielkie za prockę... kombinowałem w tę stronę ale programista ze mnie jak z koziej... sprawdzę i zaprezentuję efekt zaraz po powrocie z krótkiego urlopu :-)

Edit.

Dokonałem poprawek i jest prawie dobrze... czyli przy przykładowej sekwencji:

        ;sekwencja [0,0] do [9,9]
        ldx #$0
        ldy #$0         
        jsr plot 
               
        ldx #$1
        ldy #$1         
        jsr plot
        
        ldx #$2
        ldy #$2         
        jsr plot
        
        ldx #$3
        ldy #$3         
        jsr plot
        
        ldx #$4
        ldy #$4         
        jsr plot
        
        ldx #$5
        ldy #$5         
        jsr plot
        
        ldx #$6
        ldy #$6         
        jsr plot
        
        ldx #$7
        ldy #$7         
        jsr plot      
        
        ldx #$8
        ldy #$8         
        jsr plot
        
        ldx #$9
        ldy #$9        
        jsr plot
        
        
        ; [161,0]        
        ldx #$00
        ldy #$a1       
        jsr plot 
        
        ;[161,63]      
        ldx #$3f
        ldy #$a1       
        jsr plot 

wywołuje efekt ja na zdjęciu:

LCD01

czyli z X-sami wszystko gra, natomiast Y-ki  są jakby odwrócone.. i najstarszy jest najmłodszym w bajcie. jak to zmienić?

https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email

10

Jakaś podpowiedź? :-)

https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email

11 Ostatnio edytowany przez mono (2019-08-20 20:31:47)

Zmieńmy trochę tablice:

masktab:
:64     .byte [1 << [# & %111]] ^ $FF
pixeltab:
:64     .byte [1 << [# & %111]]

Przeoczyłem jakoś Twój post.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

12 Ostatnio edytowany przez pancio.net (2019-08-20 21:43:20)

Nooo. o to jest to :-)

Mono jesteś wielki, teraz wyświetlacz działa zgodnie z zamierzeniami:

https://www.youtube.com/watch?v=A8FGVxnLplQ

po "szumie białym" mamy rysowanie punkt po punkcie i wyświetlanie po każdej lini, czyli w cyklu wypełnienia ekranu mamy 64 x przesyłaną pamięć do LCD ( w całości)
W kolejnej części filmu widać wypełnianie punkt po punkcie w całej pamięci obrazu i wysyłanie do LCD raz na cały obraz.

Reasumując, przy obecnych procedurach rysowanie po punkcie nie jest optymalne ale wystarczające :-)

Dzięki Panowie (szczególnie @mono) za pomoc.  Załączam libk-e w asm, może się komuś przyda.

Post's attachments

VIAlib111_cut.zip 17.89 kb, liczba pobrań: 2 (od 2019-08-20) 

Tylko zalogowani mogą pobierać załączniki.
https://systemembedded.eu/ ... https://www.youtube.com/watch?v=GwS7Es1x6mw
""Ja bardzo przepraszam, ale podejrzenia panów są całkowicie bezpodstawne. Ja niczym nie handluję. Ta pani przyszła do mnie w tym Pancake-u i w nim wychodzi.""
ABBUC Member #319. Preferowana forma kontaktu: email