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: CommentAuthorxxl
   • CommentTime25 Aug 2019 16:08 zmieniony

    
   bawie sie w implementacje sterownika S: (ekran graficzny)
   
   chce dodac kilka funkcji:
   1. kilka ekranow otwartych na raz (widocznosc konfigurowana)
   2. kontrola wyswietlania (komponuje dzielone ekrany w roznych proporcjach itd)
   3. mapa kolorow (1-bitowa, kontrolowana rejestrem FILFLG, GRAPHICS tryb+16+64), konfigurowana wielkosc mapy kolorow np. na filmiku widac ze jedno kolko ma komorke mapy koloru wsokosci 1 pixela trybu 5
   4. zastanawiam sie nad kontrola wysokosci otwieranego ekranu (nie mylic wyswietlanego)
   5. zarzadzanie pamiecia (ekrany mozna zamkac/otwierac w roznej kolejnosci) - funkcjonalnosc alokacji i zwalniania pamieci udostepniana innym programom
   
   oczywiscie wszystko ma domyslne ustawienia wiec jak ktos uzyje GRAPHICS 7 to nawet nie zauwazy roznicy ... no... bedzie szybciej dzialal tylko.
   
   
   
2. • 2: CommentAuthorgorgh
   • CommentTime25 Aug 2019 18:08

    
   Ciekawe, do czego to może się przydać? Basic?
3. • 3: CommentAuthorxxl
   • CommentTime25 Aug 2019 21:08

    
   tez.
   przewrotnie zapytam, a do czego przydaja sie procedury systemowe ;-)
4. • 4: CommentAuthorgorgh
   • CommentTime25 Aug 2019 21:08

    
   Jako scenowiec powiem: do ćwiartek i jednokilówek!
5. • 5: CommentAuthorxxl
   • CommentTime25 Aug 2019 21:08

    
   albo aby je wylaczyc i odzyskac zajmowane miejsce :D
6. • 6: CommentAuthorpin
   • CommentTime25 Aug 2019 23:08

    
   Jak wiesz XXL, procedury systemowe przydają się przede wszystkim do komunikacji z dowolnym urządzeniem I/O, program nie musi wiedzieć z czym "rozmawia" ;)
7. • 7: CommentAuthorxxl
   • CommentTime26 Aug 2019 14:08 zmieniony

    
   kolejny etap do opracowanie alokacji pamieci (bedzie mozna otwierac i zamykac kilka ekranow niezaleznie - zapobiegamy out of memory)
   
   zarzadzanie pamiecia wstepnie:
   
   -funkcja oddaje adres pierwszej wolnej komorki pamieci wedlug parametrow i id alokacji (parametr przy zwolnieniu pamieci), typ pamieci jest parametrem wejsciowym
   -modfikuje MEMTOP w zaleznosci od typu pamieci oraz czy alokacja jest ponizej MEMTOP
   -nie pozwala wskazac konkretnego adresu alokacji (moze kiedys jak pozwolimy np.loaderom plikow binarych na rezerwacje pamieci gdzie laduja dane)
   -parametry: ilosc pamieci, unikaj grganicy (maska np. 512b,1kb,2,4 itd.), ofset (np. $100 od pasujacego adresu), typ pamieci np.ext (mozna alokowac w MAPRAM :)
   
   jakies pomysly na alokacje? uwagi?
8. • 8: CommentAuthormono
   • CommentTime26 Aug 2019 15:08 zmieniony

    
   Alokacja wg 3 kryteriów:
   - maska dla obszaru którego nie można przekroczyć typowo 0.5, 1, 2, 4K.
   - rozmiar bloku w bajtach
   - offset od którego ma się zaczynać blok (opcjonalny)
   W ten sposób możesz swobodnie alokować pamięć dla PMG/DL/ekranu/generatora i to niekoniecznie dla całości PMG/generatora ale dla części.
   Przykładowo alokacja obszaru P2 w rozdzielczości 1-liniowej:
   - maska: $F800
   - rozmiar: $0100
   - offset: $0600
   lub alokacja znaków $60..$7F generatora dla trybu 3 ANTIC:
   - maska: $FC00
   - rozmiar: $0100
   - offset: $0300
   lub alokacja DL dla trybu GR.0:
   - maska: $FC00
   - rozmiar: $0020
   - offset: brak
   lub alokacja ekranu normalnej szerokości w GR.8+16:
   (górna połówka - 90 linii)
   - maska: $F000
   - rozmiar: $0E10
   - offset: $01F0
   (dolna połówka - 102 linie)
   - maska: $F000
   - rozmiar: $0FF0
   - offset: $0000
   
   Edit: Jeśli uwzględniasz jeszcze rodzaj pamięci (podstawowa/dodatkowa/mapram) to pewnie jeszcze trzeba by wziąć pod uwagę:
   - bank (PORTB) pamięci bo ze względu na oddzielny dostęp ANTIC-a i CPU może być istotne żeby mieć część bloków w tym samym banku
   - i obszar zajmowany przez bank pamięci:
   * $0000..$FFFF - podstawowa
   * $4000..$7FFF - dodatkowa
   * $5000..$57FF - mapram
   To w sumie nic odkrywczego, ale dla pamięci :)
   
   Edit 2: A jakbyś chciał uwzględniać jeszcze pamięć VBXE, AXLON, Weroniki/RAMCART...
   
   Edit 3: Właściwie sterownik mógłby sam alokować i przesuwać pamięć tak, żeby optymalnie ją wykorzystać zależnie od konfiguracji ekranu. Ale wtedy użytkownik musiałby pamiętać, że adresy DL,PMG,generatora, ekranu mogą być w innym miejscu po jego rekonfiguracji.
   Niebezpieczeństwa nie ma kiedy user korzysta ze standardowych trybów, bo wtedy adresy się nie zmieniają.
   Kolejne ryzyko to ciągłość pamięci graficznej. OIDP standardowy S: trzyma pamięć w ciągłym obszarze bo potrzebuje co najwyżej 2 bloków 4K. Ale gdybyś chciał mieć 240 linii trybu graficznego i ekran szeroki (albo scrollowany w poziomie) to tego się już nie da zrobić, bo ekran jest na tyle duży że przekracza 2 4K bloki. Nie ma problemu kiedy user wykonuje wszystkie operacje przez CIO, kłopot powstaje kiedy chce sam malować po pamięci ekranu POKE-ami. Albo zgrać/odtworzyć zawartość ekranu na jakiś nośnik.
9. • 9: CommentAuthorxxl
   • CommentTime26 Aug 2019 16:08 zmieniony

    
   z ofsetem genialne. dodaje.
   rodzaju pamieci w obrebie dodatkowej nie trzeba rozrozniac (w sensie usera - chyba ze bedzie upierdliwy to komenda info dla ID alokacji i dostanie info o banku, rozmiarze i jakie adresy bank zajmuje ;) na poziomie inicjowania bedzie skonfigurowana lista z rejestrami. moze byc nawet tak ze dwa rozne rejestry moga wlaczac pamiec w ten sam obszar w niczym to nie przeszkadza. od inicjalizera bedzie zalezalo jaka ta lista bedzie, moze to bc zupelnie cos fikusneo czeo obecnie nie znamy.
   edit3 nie rozumiem. zarzadzanie pamiecia ma na celu alokacje/zwalnianie i zmiana/kontrola MEMTOP, zadnego przesuwania...
   co do trybow, chce oddzielic DL dla trybu od wyswietlaneo DL... chce miec laczone ekran roznej wysokosci (w uproszczeniu)
10. • 10: CommentAuthormono
    • CommentTime26 Aug 2019 17:08 zmieniony

     
    Chodzi mi o taki scenariusz:
    
    1. Otwieramy w #1 ekran na 10 linii trybu 0.
    2. Otwieramy w #2 ekran na 10 linii trybu 12 zaraz poniżej.
    3. Coś drukujemy w #1 i #2.
    4. Zamykamy #2.
    
    Co się stanie z pamięcią w takiej sytuacji?
    
    Edit: Czy tryby chcesz rozdzielać rozkazem JMP? Czy po prostu zbudujesz odpowiednią displaylistę i będziesz ją modyfikował w razie potrzeby?
11. • 11: CommentAuthorxxl
    • CommentTime26 Aug 2019 18:08 zmieniony

     
    zaprezentowales najprostszy wariant bez kombinacji:
    1. ekran 1, alokacja, modyfikacja memtop
    2. ekran 2, alokacja, modyfikacja memtop
    3. zamkamy 2, zwalnianie pamieci, modyfikacja memtop
    
    chyba chodzilo Ci o zamkniecie ekranu 1, 2 pozostaje otwarty a wtedy:
    
    3. zamykamy 1, zwalnianie pamieci, nie modyfikujemy memtop
    
    teraz gdybysmy chcieli otworzyc ekran 3 to dostaniemy przydzial do pamieci wolnej lezacej za ekran 2 (w tej "dziurze") i tez nie bedzie modyfikacji MEMTOP - tak w uproszczeniu.
    
    mam nadzieje to jest jasne, przeszukujemy pamiec zawsze od "gory" - juz nawet mam preliminary i "prawie" dziala.
    
    dzielony ekran: nie, nie bedzie skokow do DL danego ekranu - na poczatku myslalem zeby tak robic ale mam mocne argumenty przeciw. w DL dla ekranu dzielonego beda wkopiowywane DL skladowych wedlug odpowiednich parametrow...
12. • 12: CommentAuthormono
    • CommentTime26 Aug 2019 18:08

     
    DL - dobry pomysł. W takim razie można by przewidzieć nawet maksymalny rozmiar DL i alokować go tylko raz.
    Przewidujesz prezentowanie na ekranie tylko fragmentu pamięci obrazu w danym trybie (czyli podział na ekran logiczny i fizyczny)?
13. • 13: CommentAuthorxxl
    • CommentTime26 Aug 2019 18:08

     
    split bedzie jako komenda specjalna, w standardzie wyswietlana bedzie DL danego ekranu. a wiec split sam zaalokuje sobie pamiec na DL jak trzeba bedzie.
    
    nie, i nie bedzie ekranow wysokosci wiekszej niz standard dla danego trbu np.192, beda mniejsze czyli mozna bedzie stworzyc tryb 7 o wysokosci 16 pixeli. nie chce tworzyc trybow dowolnej szerokosci i wysokosci bo bym sobie z tym nie poradzil...
14. • 14: CommentAuthorxxl
    • CommentTime28 Aug 2019 16:08 zmieniony

     
    zastanawiam sie czy nie przekazywac dodatkowch parametrow dla Screen w ten sposob:
    
    

    10 A$="S3:"
    20 WYSOKOSC = 50
    30 A$(4)=CHR$(WYSOKOSC)
    40 OPEN #5,12+16,7,A$
    

    
    
    to ma spory potencjal rozbudowy a i tak w split potrzebne bada osobne parametry dla kazdego z ekranow
15. • 15: CommentAuthorxxl
    • CommentTime28 Aug 2019 20:08 zmieniony

     
    stanowczo tak.
    
    dodaje parametr:
    ** ICAX1 Auxiliary Byte 1 Equates
    CMAP EQU $40 ;open for colormap (E:, S:)
    UMODE EQU $80 ;open user mode (E: S:)
    
    Wiec jesli zostanie uzyty np. OPEN #5,12+64+128,128,"S8:OPIS TRYBU USERA"
    
    dane jak np. tryb Antica, kolory, szerokosc Narrow, Normal, Wide, wysokosc, adres zestawu znakow itp. tak bedzie takze zestaw znakow dla trybu graficzneggo (tak tez utworzymy systemowo niemozliwy dotychczas do utworzenia tryb ANTIC 3) dane te beda pobierane bezposrednio a nie obliczane jak np. sprawdzanie zakresu wspolrzednch podczas PUT, wiec teoretycznie tryb utworzony w ten sposob bedzie szybszy w obsludze
16. • 16: CommentAuthorxxl
    • CommentTime29 Aug 2019 13:08 zmieniony

     
    UMODE.
    
    dotchczas myslalem, ze najgorzej zaprojektowany element OS to CIO. zmienilem zdanie, wyprzedza go systemowy sterownik S: dochodzi do tego sposob zaprogramowania, nie ma ciaglych 50 bajtow bez bledu.

    • usermode.jpg
      
      
      
      
17. • 17: CommentAuthorxxl
    • CommentTime30 Aug 2019 00:08 zmieniony

     
    na filmiku:
    1. otwieram tryb 2 w kanale #3, rysuje A
    2. otwieram tryb 5 w kanale #4, rysuje punkt w kolorze 2
    3. ustawiam aktywny ekran z kanalu #3
    4. ustawiam split w kanale #3 - polacz wyswietlanie w.parametrow z kanalem #4
    5. ustaw aktywny ekran z kanalu #4
    
    do kazdeo kanlu mozna pisac/czytac niezaleznie wiec do niewidoczneo ekranu caly czas mozna pisac.
    
    
    ===
    oprocz plot, draw i fill przydalo by sie systemowe text - pisanie czcionka na ekranie graficznym...
    
    

    • atarivid.avi
18. • 18: CommentAuthorgorgh
    • CommentTime30 Aug 2019 12:08

     
    Wow
19. • 19: CommentAuthorxxl
    • CommentTime31 Aug 2019 19:08

     
    nowy element... DisplayManager, zaszalejemy, mozna fajnie mieszac lacznie z otwartmi ekranami z romu. a co :-)
    
    
20. • 20: CommentAuthorxxl
    • CommentTime1 Sep 2019 20:09

     
    ostatecze uderzenie ;-)
    
    mozna definiowac wlasne tryby, dowolny tryb GTIA, szerokosc narrow,normal,wide
    
    mozna dodawac wlasny ekran graficzny (np. statyczne obrazy) albo puste DLki
    
    dodatkowo DisplayManager zarzadza DLI, mozna rejestrowac takze wlasne przerwania.