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: CommentAuthorCharlieChaplin
   • CommentTime14 Feb 2022

    
   Well,
   
   currently AVF is using Gr. 9 + 11 (interleave) with 80x100 pixels and 256 colours. I would like to have other gfx formats for streaming videos, if possible, e.g.:
   
   - Gr. 9 (or Gr. 9+ with black lines) with 80x200 pixels resolution (80x100 pixels resolution) and 16 greys for b/w movies
   
   - HIP (Gr. 10+9) with 160x200 pixels resolution (due to GTIA shifting) and approx. 30 greys for b/w movies - if possible
   
   - MAX (Gr. 15 col + Gr. 15 lum or 4 col x 4 lum for up to 16 colours; standard should be: 4 greys, 4 reds, 4 greens, 4 blues) with 160x200 pixels resolution and up to 16 colours - if possible
   
   - Gr. 10 + 11 (with Gr. 10 GTIA shifting for higher resolution, where Gr. 10 gives 8 lum and Gr. 11 gives 16 col for up to 128 colours) with 160x200 pixels resolution and up to 128 colours - if possible
   
   - CIN (Gr. 15 lum + Gr. 11 col) with 160x200 pixels resolution and up to 64 colours - if possible
   
   - Gr. 10 + Gr. 10 (9 col x 8 lum and GTIA shifting for higher resolution) with 160x200 pixels resolution and up to 72 colours - if possible
   
   - RIP with 160x200 pixels and up to 144 (?) colours - if possible
   - TIP with 160x100 pixels and up to 256 colours - if possible
   
   phaeron said, that some of these formats would be possible for AVF, alas, he did not tell me which ones, so as a non-programmer I really do not know what is possible and what is NOT possible. Maybe you can experiment...?!? I do not know if certain interleave formats (HIP, RIP, TIP, etc.) would flicker like hell or not, nor do I know if they can be used for AVF videos...
2. • 2:
      
     CommentAuthorjhusak
   • CommentTime14 Feb 2022

    
   Thanks for explanation. I think most of them are possible. But MAX for example is not. Only those where there are no color changes in raster. So where one of GTIA mode is used to generate colors or lumas, this is possible. There is no need to make 9+ with empty lines every second line. Bandwidth would be a half as it is (4.5 kB/frame), but who cares, when cards are sooo biig and it is so nice to watch full frame movie.
   
   I focus on
   - graphics 9 grayscale
   - CIN because of resolution
   - graphics "15" grayscale. (doublequote, because all these must be text modes)
   - graphics 8 grayscale (well b&w)
   - maybe gr 8/ gr 11 for full resolution
   
   I thought about special graphics subtitles mode underneath, 12 pixel height and occupying full sector, or two lines of such instead of text. But as the project is modular, this will be decided later.
3. • 3: CommentAuthortebe
   • CommentTime14 Feb 2022

    
   RIP to HIP tylko zamiast kolorów szarości ma ustawione inne kolorowe, ale to wymaga podobnie jak w MAX zapisywania rejestrów kolorów na przemian linie nie/parzyste
4. • 4:
      
     CommentAuthorjhusak
   • CommentTime14 Feb 2022 zmieniony

    
   Jest dokładnie 32 cykle wolnego w każdej linii. To jest 8 rozkazów lda xxxx/sta xxxx. 3(lub 2) lda idą na pobranie dodatkowych bajtów. Życ nie umierać :D
   
   W sumie dało by radę zmienić 2 rejestry:
   lda#
   sta col1
   lda#
   sta col2 i to jest 12 cykli, czyli tyle, co w oryginalnym playerze podmiana trybu gtia, zmiana vscroll i ustawienie znaków "do góry nogami" na przemian.
5. • 5: CommentAuthorCharlieChaplin
   • CommentTime14 Feb 2022

    
   CIN is Gr. 15 (4 lumas) mixed with Gr. 11 (16 colours) for up to 64 colours in 160x200 pixels resolution.
   
   But I still would like to see Gr. 10 (8 lumas, GTIA shifting to reach higher resolution like in HIP) mixed with Gr. 11 (16 colours) for up to 128 colours in 160x200 pixels resolution.
   
   HIP with approx. 30 greyscales would also be nice for b/w movies and gives more lumas + higher resolution than standard Gr.9 format.
   
   -----
   
   There is a colour JPEG converter (Cpegview) by Raphael Espino which converts *.JPG into e.g. RIP, TIP and Gr.8 (2 lumas) + Gr. 11 (16 colours). Alas, 16 colours with only two lumas looks really bad, tested it with a dozen or so pictures. Thus I think that movies with 16 colours but only two lumas will also look very bad.
   
   16 colours with 4 lumas (CIN) and 16 colours with 8 lumas (Gr. 11 + Gr. 10) looks much much better, I think and we can still reach some 160x200 pixels resolution (for Gr. 15 this is standard, for Gr. 10 one can use GTIA shifting like in HIP/RIP).
6. • 6:
      
     CommentAuthorgienekp
   • CommentTime15 Feb 2022 zmieniony

    
   "Only those where there are no color changes in raster." Why is there a problem with that?
   
   Have you tested "LineConverter"? The base picture is in Gr.9, CPU only changes the chroma. I think when changing the chroma (even only once per line) in the animation, the eye starts to blur the color changes. The luminance for the eye is usually sharp.
   
   For 80x240 picture chroma size is 7x240.
7. • 7:
      
     CommentAuthorjhusak
   • CommentTime16 Feb 2022 zmieniony

    
   post nr 4. Wszystkie linie obrazu to tzw. Bad lines. Nie ma ani jednego wolnego cyklu dla procesora podczas rysowania linii.
8. • 8:
      
     CommentAuthorgienekp
   • CommentTime16 Feb 2022 zmieniony

    
   Hmm, no właśnie tego nie za bardzo czaję, a miałem rozszerzać LC do animacji i żebym się w coś nie wpakował.
   
   ANTIC patrzy na blok 8kB carta to 80x200 w GR9 widzę elegancko, bez żadnych przestojów dla procka.
   W tym czasie dla lini robię:
   
   

   ;jakieś nopy...
   lda #$00
   ldx #$10
   ldy #$20
   sta COLBAK
   stx COLBAK
   sty COLBAK
   lda #$30
   sta COLBAK
   lda #$40
   sta COLBAK
   lda #$50
   sta COLBAK
   lda #$60
   sta COLBAK
   lda #$00
   sta COLBAK
   

   
   i to działa,
   
   mało tego, jakbym miał inteligentnego karta to ten kod by szedł w pętli wirtualnej, gdzie cart podkładał by różne kolory chromy a w ostatniej lini obrazu podłożyłby kod wychodzący z pętli i na kilkudziesięciu bajtach można by zamknąć program cpu. Czyli jedna klatka to jedno 8kb ATARI
9. • 9:
      
     CommentAuthorjhusak
   • CommentTime16 Feb 2022 zmieniony

    
   Problem jest taki: dane obrazu są przekazywane przez 1 (słownie JEDEN) adres.
   Na szczęście d510.
   
   Spróbuj teraz wymyślić sposób, jak z tego jedynego adresu wyświetlać cały obraz i grać dźwięk:)
   
   I tak. Atari ma kilka kluczowych ficzerów (z pozoru niepotrzebnych), bez których nie da się tego zrobić.
   Też myślałem na początku, zanim się za to zabrałem, że avgcart mapuje 8kB pamięć kartridża na dane, ale tak _nie_ jest.
   
   Nie ma w związku z tym możliwości zrobienia filmu 25fps lub niżej bez wyświetlania czarnych klatek, zmiany rozdzielczości pionowej (jeszcze muszę sprawdzić tryb znakowy 13, ale z tego co wiem, w pierwszej linii antic pobierze dma obrazu i wyświetli charset, a w drugiej linii powtórzy pierwszą linię charsetu, więc d.)
   
   

   mało tego, jakbym miał inteligentnego karta to ten kod by szedł w pętli wirtualnej, gdzie cart podkładał by różne kolory chromy a w ostatniej lini obrazu podłożyłby kod wychodzący z pętli i na kilkudziesięciu bajtach można by zamknąć program cpu. Czyli jedna klatka to jedno 8kb ATARI

   
   
   Ale niestety nie masz :( Jedyny inteligentny kartridż, który kiedyś widziałem i pamiętam to Tomek-8 Nosty'ego.
   
   ->link<-
   
   Tu demo sprzed 10 lat.
   
   ->link<-
10. • 10:
       
      CommentAuthorgienekp
    • CommentTime16 Feb 2022

     
    No to jak cały stream idzie przez "bajta" to szacun.
    
    Myślałem, że tam za jednym zamachem 8kB się podkłada i w zasadzie gotowiec jest. Teoretycznie dla FPGA (a tam chyba Xilinx) to nie problem.
    
    A jest coś przydatnego na tych 8kB wystawiane w trybie "filmu"?
    
    P.S. Mój AVGcart dopiero w drodze...
11. • 11:
       
      CommentAuthorjhusak
    • CommentTime16 Feb 2022

     
    "A jest coś przydatnego na tych 8kB wystawiane w trybie "filmu"?"
    
    Nie rozumiem.
12. • 12:
       
      CommentAuthorjhusak
    • CommentTime16 Feb 2022 zmieniony

     
    Dla zainteresowanych pracami:
    Teraz prace idą w kierunku stworzenia streamu zawierającego zarówno dane STEREO dla covoxa, jaki MONO dla pokeya (stereo niemożliwe),(plus jeśli się uda to odtwarzanie PAL na NTSC i odwrotnie oczywiście z niedogodnościami, ale ma grać jako tako). W sensie stream stworzony i ogarnięty (PAL/NTSC), dane zmieszczone, muxer stworzony. Robi się player.
13. • 13:
       
      CommentAuthorsun
    • CommentTime16 Feb 2022

     
    Czekam na commity :)
14. • 14:
       
      CommentAuthorjhusak
    • CommentTime16 Feb 2022

     
    Teraz będzie trochę niedziałających, jak coś będzie, dam numerek działającego.
15. • 15:
       
      CommentAuthorjhusak
    • CommentTime3 Mar 2022 zmieniony

     
    Załączam AVFPlay dla AVGCart do starego, oryginalnego formatu. Wyrównałem wyzwolenia próbek audio tak, że nie świergoli zarówno w PAL jak i NTSC.

    • AVFPLAY
16. • 16:
       
      CommentAuthorPeri Noid
    • CommentTime3 Mar 2022

     
    To już jutro sprawdzę. Dzięki.
17. • 17: CommentAuthortebe
    • CommentTime3 Mar 2022

     
    to jeszcze link do plików AVF
18. • 18:
       
      CommentAuthorjhusak
    • CommentTime3 Mar 2022 zmieniony

     
    Ale jak to? Mam przesłać stare dobre istniejące linki do starych dobrych od dawna istniejących filmików avf?
    
    UPDATE:
    Nowy format nazywa się JVF (od jakuby file format, bo acid maker zajmuje się przetwarzaniem filmu na potrzeby kartridża, a ja samym formatem i playerem)
    
    Nowy format zawiera strumień stereo dla covoxa (zawsze) i mono dla pokeya (zawsze). Ponadto można sensownie odgrywać filmiki PAL na NTSC (szybciej) i odwrotnie (wolniej) Trochę się dźwięk psuje (ale nie tak strasznie, wszystko zrozumiałe), ale nie poradzisz.
    
    Żródła zostaną upublicznione, jak tylko format się ustali, tzn zobaczę, że działa na SIDE2.
    
    Jak ktoś ma namiary na obsługę tego trybu filmowego w SIDE3 (ogólnie dokumentację programistyczną), to poproszę.
19. • 19: CommentAuthortebe
    • CommentTime3 Mar 2022

     
    może dołącz plik txt-owy z informacją o linkach, stronach gdzie można znaleźć takie filmy, informacje o playerze, dla Ciebie to oczywista oczywistość, jednak dla kogoś nie będącego w temacie to dziwny plik który nic nie robi
20. • 20:
       
      CommentAuthorjhusak
    • CommentTime3 Mar 2022 zmieniony

     
    Oj tam oj tam :)
    
    ->link<- do wątku obok z filmami.
21. • 21: CommentAuthorCharlieChaplin
    • CommentTime3 Mar 2022

     
    Tested the AVFplay from post #15 and yes, the sound is better now - during playback there is less of that awful noise (humming/buzzing) than before. But I only tested it with 3 videos, did not have the time to test it with all >200 videos... thanks, Jakub!
22. • 22:
       
      CommentAuthorjhusak
    • CommentTime6 Mar 2022 zmieniony

     
    Tu jest poprawiony player Phaerona współdziałający z SIDE/SIDEII do starych dobrych plików AVF:
    ->link<-
23. • 23:
       
      CommentAuthorjhusak
    • CommentTime10 Mar 2022

     
    Dodana możliwość przewijania w przód i w tył - dla playera SIDE/SIDEII i Incognito. Link jw., katalog bin.
24. • 24:
       
      CommentAuthorjhusak
    • CommentTime12 Mar 2022 zmieniony

     
    Nowa wersja MOVPLAY dla SIDE/SIDEII/Incognito:
    
    - pauza (nie zostawiaj na pauzie - będzie czytane w kółko 17 sektorów, co _może_ uszkodzić kartę, jak zgłaszał @tmp w stosunku do kart micro sd)
    - głośność
    - przyspieszone przewijanie - 1 sekunda = 2 minuty (przewijanie co 120 ramek, czyli 120-krotne przyspieszenie)
    
    Aktualnie wersja na AVF sobie czeka, bo nowy format musi chodzić na ()IDE. A do tego muszę poznać wszelakie niuanse IDE.
    
    ->link<-
25. • 25:
       
      CommentAuthorsun
    • CommentTime12 Mar 2022

     
    Tak sobie myślę...czy w takim razie pauza... ale to by musiało FW wspierać, żeby robić seek, czyli wznowienie od ostatniej pozycji. Wtedy zapewne można by nie pętlić 17 sektorów. Ale to takie wewnętrzne rozważania.
26. • 26:
       
      CommentAuthorjhusak
    • CommentTime12 Mar 2022 zmieniony

     
    Będzie tak, ze klatka po pauzie będzie wczytania przez procek do ramu, co zajmie ca 3 ramki, następnie wyświetlana z ramu, standardowo.
27. • 27:
       
      CommentAuthorPeri Noid
    • CommentTime12 Mar 2022

     
    Jeśli wczytasz tę samą, która była ostatnio (czyli rev o jedną klatkę a potem to co piszesz) to nawet nie będzie tego widać.
28. • 28:
       
      CommentAuthorjhusak
    • CommentTime12 Mar 2022

     
    I tak nie będzie, tylko mryg. Na razie w avg nie ma opcji seek.
29. • 29:
       
      CommentAuthorsun
    • CommentTime12 Mar 2022

     
    Dlatego napisałem, że musi wspierać FW.
    Skoro z ramu, znaczy karty na pauzie padać nie będą ;)
30. • 30:
       
      CommentAuthorjhusak
    • CommentTime13 Mar 2022 zmieniony

     
    Nie jest potrzebne wsparcie firmware do pauzy. Pauzę robimy na następnej klatce, której już nie wyswietlamy ANTICEM, tylko procesor pobiera te dane do ramu, a następnie włącza specjalną display listę do wyświetlania tych danych.
31. • 31:
       
      CommentAuthorsun
    • CommentTime13 Mar 2022

     
    Jasne, ja się tak tylko rozmarzyłem w temacie "odtwórz od ostatniego momentu" czy jak to tam się fachowo nazywa. Do tego seek w fw byłby zbawieniem - chyba.
32. • 32:
       
      CommentAuthorjhusak
    • CommentTime13 Mar 2022

     
    Sprawa z seekiem w fw nie jest beznadziejna, zobaczymy, co tmp zrobi.