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:
      
     CommentAuthoramarok
   • CommentTime2 Sep 2020 zmieniony

    
   Założyłem ten wątek, ponieważ chciałbym przedstawić Wam mój pierwszy program napisany w MadPascalu.
   
   gr9Lab, to aplikacja przeznaczona do przetwarzania obrazu z użyciem 8-bitowego Atari.
   Aktualnie program jest w trakcie rozwoju, ale już teraz zawiera zdecydowaną większość funkcjonalności.
   Jak na razie program uruchamiałem jedynie w emulatorze Altirra, tak więc nie ma gwarancji, że będzie działać na rzeczywistym sprzęcie.
   Obecna wersja powinna bez problemu uruchomić się na konfiguracji z 64kB pamięci.
   
   Poniżej znajduje się link do nagrania na YouTube.
   ->link<-
   
   W programie można jednocześnie zarządzać dwoma obrazami w trybie GR9 o rozdzielczości 80x192 piksele.
   Istnieje możliwość przetwarzania obrazów w całości albo w wybranych prostokątnych obszarach (ROI).
   Programem można sterować przy pomocy joysticka oraz klawiatury:
   - klawisze 1 i 2 przełączają widok pomiędzy zapamiętanymi obrazami.
   - klawisz Tab/Shift Tab przechodzi do następnego/poprzedniego elementu menu lub kontrolki GUI.
   - klawisz Return uruchamia podświetlony element menu lub konotrolkę GUI.
   - klawisz Esc przechodzi do menu głównego.
   
   Aktualna lista funkcjonalności obejmuje.
   
   [Menu gr9Lab]
   New - czyści zawartość obrazu.
   Load - ładuje obraz z pliku w formacie GR9 (80x192 piksele).
   Save - zapisuje obraz do pliku w formacie GR9 (80x192 piksele).
   Exit - zamyka aplikację.
   Copy - kopiuje obraz/fragment z drugiego obrazu.
   Show/Hide selection - włącza/wyłącza pracę z ROI obrazu.
   
   [Menu Process]
   Flip horizontal - odbija obraz w poziomie.
   Flip vertical - odbija obraz w pionie.
   Rotate 180 - obraca obraz o 180 stopni.
   Brightness/Contrast - umożliwia korektę janości i kontrastu obrazu.
   Histogram - oblicza i wyświetla histogram jasności obrazu.
   Histogram equalize - wyrównuje histogram jasności obrazu.
   Inverse - wykonuje operację negatywu obrazu.
   Threshold - wykonuje operację progowania, piksele ciemniejsze od parametru są zastępowane jasnością 0 a pozostałe jasnością 15.
   Add noise - wprowadza losowe zmiany jasności pikseli.
   
   [Menu Filter]
   Box filter - nakłada na obraz uśredniający o rozmiarze 3x3 piksele.
   Gaussian blur - nakłada na obraz wygładzający filtr Gaussa o rozmiarze 3x3 piksele.
   Sharpen - wyostrza obraz przy pomocy filtra 3x3 piksele.
   Laplace edges - uwidacznia krawędzi stosując filtr Laplace o rozmiarze 3x3 piksele.
   Emboss - generuje efekt płaskorzeźby obrazu filtrem 3x3 piksele.
   Dilate filter - nakłada morfologiczny filtr dylatacji o rozmiarze 3x3 piksele.
   Erode filter - nakłada morfologiczny filtr erozji o rozmiarze 3x3 piksele.
   Opening filter - nakłada morfologiczny filtr otwarcia o rozmiarze 3x3 piksele.
   Closing filter - nakłada morfologiczny filtr zamknięcia o rozmiarze 3x3 piksele.
   
   [Menu Math]
   Set - ustala stałą jasność pikseli.
   Add - zwiększa jasność pikseli o zadaną wartość.
   Subtract - zmniejsza jasność pikseli o zadaną wartość.
   Difference - oblicza różnicę co do wartości bezwględnej jasności pikseli od zadanej wartości.
   Multiply - mnoży jasności pikseli przez zadaną wartość.
   Divide - dzieli jasności pikseli przez zadaną wartość.
   Log - oblicza logarytm naturalny z jasności pikseli.
   Exp - oblicza wartość funkcji exponencjalnej z jasności pikseli.
   Sqr - oblicza drugą potęgę z jasności pikseli.
   Sqrt - oblicza pierwiastek kwadratowy z jasności pikseli.
   Not - nakłada bitową negację na jasności pikseli.
   Or - oblicza bitową sumę z jasności pikseli i wybranej wartości.
   And - oblicza bitowy iloczyn z jasności pikseli i wybranej wartości.
   Xor - oblicza bitową różnicę symetryczną z jasności pikseli i wybranej wartości.
   Minimum - oblicza minimum z jasności pikseli oraz wybranej wartości.
   Maximum - oblicza maksimum z jasności pikseli oraz wybranej wartości.
   
   [Menu Blender]
   Add - oblicza sumę jasności pikseli z dwóch obrazów.
   Subtract - oblicza różnicę jasności pikseli pomiędzy dwoma obrazami (od bieżącego obrazu odejmuje drugi).
   Difference - oblicza wartość bezwzględną różnicy jasności pomiędzy dwoma obrazami.
   Multiply - oblicza iloczyn jasności pikseli z dwóch obrazów.
   Divide - oblicza iloraz jasności pikseli pomiędzy dwoma obrazami (bieżący obrazu jest dzielony przez drugi).
   Average - oblicza średnią arytmetyczną jasności pikseli z dwóch obrazów.
   Or - oblicza sumę bitową z jasności dwóch obrazów.
   And - oblicza iloczyn bitowy z jasności dwóch obrazów.
   Xor - oblicza bitową różnicę symetryczną z jasności dwóch obrazów.
   Minimum - oblicza minimum z jasności pikseli dwóch obrazów.
   Maximum - oblicza maksimum z jasności pikseli dwóch obrazów.
   
   Program będę chciał dalej rozwijać a aktualna plan obejmuje m.in:
   - dodanie obsługi pamięci rozszerzonej do przechowywanie większej ilości obrazów.
   - dodanie funkcjonalności cofnięcia wykonanej operacji na obrazie.
   - wprowadzenie usprawnień w obsłudze operacji na plikach - lepsze komunikaty o błędach, eksplorator plików.
   - dodanie wyświetlania nazwy widocznego obrazu oraz informacji czy obraz jest zmodyfikowany (niezapisany).
   - dodanie okienka z pomocą oraz ustawieniami (jest parę pomysłów na ustawienia).
   - dodanie obsługi Atari 800 (w tym momencie mam problem z właściwą obsługą klawiatury przez funkcję ReadKey).
   - rozwiązanie problemu crashu systemu podczas zamykania programu.
   
   Dołączam obraz dyskietki oraz plik xex.
   
   Zachęcam Was do zabawy programem oraz będę wdzięczny za wszelkie Wasze komentarze.

   • gr9Lab_WIP1.atr
   • gr9Lab_WIP1.xex
2. • 2:
      
     CommentAuthormgr_inz_rafal
   • CommentTime2 Sep 2020

    
   Zacne!
   Aż żałuję, że nie jestem grafikiem...
3. • 3:
      
     CommentAuthorKaz
   • CommentTime2 Sep 2020 zmieniony

    
   Coś pięknego! I to natywnie na A8.
   
   Masa procedur w MP! Będziesz kiedyś publikował źródła? Wrzucał na githuba czy coś takiego?
   
   Linki do filmów YT podajemy w klasycznej wersji (h t t p s : / / w w w ... i tak dalej), wtedy pojawi się od razu podgląd:
   
   
4. • 4:
      
     CommentAuthorbocianu
   • CommentTime2 Sep 2020

    
   Dobra robota! Też chętnie zaglądnął bym w źródła :D
5. • 5: CommentAuthormono
   • CommentTime2 Sep 2020 zmieniony

    
   Ciekawa rzecz.
   Polecam dodanie wyboru funkcji za pomocą pierwszej litery np. Process -> Inverse przez kolejne wciśnięcie P i I - to przyspieszy pracę. Mozolna obsługa joystickiem doprowadza do szału człowieka, który już zna funkcje programu.
   Myszka? Pióro świetlne? Tablet? Trackball?
   Planujesz bardziej rozbudowane selekcje? Przez wycinanie, sumę, selekcja z wolnej ręki?
6. • 6: CommentAuthorxxl
   • CommentTime2 Sep 2020

    
   mozna wykorzstac xMenu (odrazu sa skroty klawiszowe)
   
   ->link<-
   
   przyklad uzycia:
   ->link<-
7. • 7: CommentAuthortebe
   • CommentTime2 Sep 2020

    
   pierwszy program i to tak rozbudowany, robi wrażenie, gratuluję
8. • 8:
      
     CommentAuthorKaz
   • CommentTime2 Sep 2020

    
   A czy będzie możliwe, aby program obsługiwał również inne tryby GTIA - 10,11?
9. • 9: CommentAuthorgorgh
   • CommentTime2 Sep 2020

    
   bardzo fajny programik
10. • 10:
       
      CommentAuthoramarok
    • CommentTime2 Sep 2020

     
    Wielkie dzięki za wszystkie komentarze. Cieszę się z Waszego zainteresowania programem.
    
    @Kaz
    Dzięki za wskazówkę dotyczącą umieszczania linku do YouTube. Spróbuję następnym razem.
    
    Co do kodów źródłowych to oczywiście mam zamiar je udostępnić, trzymam je na gitlabie. Sprawdzę tylko czy jest tam w miarę porządek, żeby wstydu nie było ;)
    
    Jest jeszcze jedna kwestia dotycząca języka programowania. Wspominałem, że jest to aplikacja napisana w MadPascalu i to prawda, ale nie w 100%. O ile część wysokopoziomowa (GUI, logika) jest napisana w MadPascalu to jednak część obliczeniowa jest w assemblerze. Tutaj zależało mi na szybkości działania oraz małej objętości, dlatego zdecydowałem się na ten krok. Mam nadzieję, że nikogo nie rozczarowałem...
    
    @mono
    Rozwiązanie ze skrótami klawiszowymi w postaci pierwszych czy wyróżnionych liter miałem zaimplementowane we wcześniejszej wersji oprogramowania. Jednak nie bardzo odpowiadała forma wizualna menu, dlatego chwilowo porzuciłem ten pomysł. Jednak chcę do tego wrócić, bo faktycznie może to mocno przyspieszyć pracę. Myślałem również o globalnych skrótach klawiszonych np. Ctrl-H wyświetlanie histogramu itp. W tej wersji chciałem bardziej skupić się na ogólnej koncepcji programu a nad użytecznością zamierzałem jeszcze popracować. Wasze głosy są oczywiście bardzo cenne, zawsze to nieco inny punkt widzenia. Po to jest takie forum :)
    
    Co do obsługi myszki czy innych peryferiów niż joystick, to przyznam szczerze, że chodziło mi to po głowie. Jednak podejrzewam, że to chyba programowanie wyższych lotów, na które na razie bym się nie porywał. No i pytanie ile pamięci by to zjadło? Ale na pewno byłby to wspaniały dodatek do tego typu aplikacji.
    
    Jeśli chodzi o bardziej skomplikowane obszary niż prostokąt, to oczywiście jest to bardzo dobry pomysł. Nieregularne maski wymagałyby oczywiście odpowiednio więcej pamięci do przechowywania. Maska mogłaby być pamiętana np. w postaci wektorowej. Żeby operacje na filtrach z maskami były wykonywane relatywnie szybko należałoby maskę uprzednio zrasteryzować np. do osobnego obrazka, co oczywiście przekładałoby się na zużycie pamięci. Ale kto wie, możnaby dorzucić do listy życzeń ;)
    
    @xxl
    Dzięki za propozycję skorzystania z xMenu. Wygląda na bardzo funkcjonalne rozwiązanie. Na pewno się z tym zapoznam.
    
    @Kaz
    Fajnie, że pytasz o możliwość obsługi innych trybów GTIA. Spróbuję odpowiedzieć na to pytanie, ale najpierw przedstawię mój punkt widzenia i motywację do powstania gr9Lab.
    
    Mam zdecydowanie większe doświadczenie w przetwarzaniu obrazów do celów naukowych, a nie artystycznych. Programów dla artystów na małe Atari jest cała masa. Mnie z kolei brakowało oprogramowania bardziej dla naukowca. O ile programy do rysowania mogą być łatwo dostosowane dla dowolnych trybów graficznych, o tyle pod kątem bardziej naukowych zastosowań jak manipulacje histogramem czy filtry konwolucyjne wskazane jest stosować albo grafikę monochromatyczną albo kolorową w postaci np. RGB.
    
    Co do obrazów monochromatycznych, to właśnie tryb 9 jest idealny do tego celu. Tak naprawdę niewiele komputerów 8-bitowych może pochwalić się 16-ma odcieniami szarości czyli "aż" 4-bitową głębią. Dlatego zdecydowałem się na napisanie programu gr9Lab.
    
    Myślałem również o przygotowaniu wersji, która nastawiona byłaby na obrazy kolorowe RGB, jednak pomysł opierałby się również na trybie 9-tym tylko z naprzemiennym podkolorowaniem poszczególnych linii przez DLI. Czyli przykładowo pierwsza linia to odcienie czerwonego, druga zielonego, trzecia niebieskiego, czwarta znowu czerwonego itd. Niestety nie pamiętam jak się taki tryb fachowo nazywa.
    
    Wydaje mi się, że tryb 11-ty byłby trudny do wiernego odwzorowywania zdjęć. Z kolei tryb 10-ty postrzegam raczej jako tryb obrazu, gdzie informacje o pikselach są indeksami z ustalonej palety a nie bezpośrednimi wartościami kolorów. W moim programie wszelkie obliczenia, które zaimplementowałem bazują na bezpośredniej informacji o kolorze (jasności), tak więc niemal całą arytmetykę obrazową należałoby odpowiednio dostować. W tym momencie nie widzę zbyt dużego zysku w wykorzystaniu trybu 10-tego. Ale jestem otwarty na wszelkie sugestie.
    
    Trochę się rozpisałem...
11. • 11: CommentAuthorCharlieChaplin
    • CommentTime2 Sep 2020

     
    Well,
    
    the RGB pics on the A8 were first introduced with Colorview (and Apacview) by Jeff Potter. Originally these were three separate pictures *.R, *.G and *.B (62 sectors each, but three Dir. entries and 186 sectors total). Later Clay Halliwell wrote a program named Colorviewsquash, where he used simple RLE to pack the pictures into one file *.RGB which was most of the time shorter than 186 sectors...
    
    I converted dozens, if not hundreds of pics into RGB mode, alas it seems only Gr. 15 RGB produces good results (theoretically 4x4x4 colours = 64 colours, in practice often 16-32 colours). Whenever I used Gr. 8 RGB, I ended up with 3-4 greys (not 2x2x2 colours = up to 8 colours or up to 8 greys). In theory Gr.9 should give the best result and most colours with 16x16x16 = up to 4096 colours, but in practice I reached only 2-4 colours each with 16 luminances (and these were almost always grey and violet, sometimes brown colours in 16 luminances and the results therefore looked ugly).
    
    On the other hand, these R, G, B and RGB converters were written by Americans with NTSC machines and I have only PAL machines, so maybe that was/is the reason for the ugly color results ?!? I guess that the used colour palette simply does not match for PAL machines...
12. • 12:
       
      CommentAuthorKaz
    • CommentTime3 Sep 2020

     

    Amarok:

    Trochę się rozpisałem...

    
    
    Ha, a mnie się wydaje, że jeszcze wiele pisania przed nami, bo poruszyłeś wiele ciekawych tematów. I jeszcze raz gratuluję programu, bo nie często się zdarza, że ktoś przychodzi i jako swój pierwszy program prezentuje "fotoszopa" na małym Atari :D
    
    

    Amarok:

    Co do obsługi myszki czy innych peryferiów niż joystick, to przyznam szczerze, że chodziło mi to po głowie. Jednak podejrzewam, że to chyba programowanie wyższych lotów, na które na razie bym się nie porywał. No i pytanie ile pamięci by to zjadło? Ale na pewno byłby to wspaniały dodatek do tego typu aplikacji.

    
    
    Myszka jest podpięta pod port joysticka, więc wielkiej filozofii w tym nie ma. Trochę programów użytkowych, w tym graficznych, a nawet gier na małym Atari, udostępniało myszkę do obsługi:
    
    ->link<-
    
    

    Amrok:

    Wydaje mi się, że tryb 11-ty byłby trudny do wiernego odwzorowywania zdjęć. Z kolei tryb 10-ty postrzegam raczej jako tryb obrazu, gdzie informacje o pikselach są indeksami z ustalonej palety a nie bezpośrednimi wartościami kolorów. W moim programie wszelkie obliczenia, które zaimplementowałem bazują na bezpośredniej informacji o kolorze (jasności), tak więc niemal całą arytmetykę obrazową należałoby odpowiednio dostować. W tym momencie nie widzę zbyt dużego zysku w wykorzystaniu trybu 10-tego. Ale jestem otwarty na wszelkie sugestie.

    
    
    To prawda, że tryb 10 i 11 są nietypowe i rzadko z nich korzystano, ale zapewne też z powodu braku wartościowych narzędzi do ich obsługi (poza RAMbrandtem, ale to wiekowy program). Znaleziono im jednak zastosowanie w trybach interlace'owych (i to kolejne pytanie, które się nasuwa - czy te tryby będą Cię interesować, jak np. HIP ->link<- , RIP, APAC, RGB wspomniany przez Andreasa w poście wyżej) czy 256-kolorowym bez interlace, który możesz zobaczyć tutaj: ->link<- . Tak naprawdę ten ostatni dla mnie osobiście jest najbardziej interesujący.
    
    Zdaję sobie sprawę, że każdy z tych trybów jest na tyle odmienny, że do jego przetwarzania trzeba zupełnie innej artmetyki obrazowej, jak to ująłeś. No i właśnie pytanie, czy to Cię będzie interesować?
    
    

    Amarok:

    Mam zdecydowanie większe doświadczenie w przetwarzaniu obrazów do celów naukowych, a nie artystycznych. Programów dla artystów na małe Atari jest cała masa. Mnie z kolei brakowało oprogramowania bardziej dla naukowca. O ile programy do rysowania mogą być łatwo dostosowane dla dowolnych trybów graficznych, o tyle pod kątem bardziej naukowych zastosowań jak manipulacje histogramem czy filtry konwolucyjne wskazane jest stosować albo grafikę monochromatyczną albo kolorową w postaci np. RGB.

    
    
    Ta strona naukowa brzmi ciekawie. Ale o ile wiem, do tych celów korzysta się współcześnie z pecetów. Skąd pomysł czy potrzeba, by zatrudnić do tego komputer 8bitowy?
    
    

    Amarok:

    Co do obrazów monochromatycznych, to właśnie tryb 9 jest idealny do tego celu. Tak naprawdę niewiele komputerów 8-bitowych może pochwalić się 16-ma odcieniami szarości czyli "aż" 4-bitową głębią. Dlatego zdecydowałem się na napisanie programu gr9Lab.

    
    
    To prawda, na 4 bitach już można robić operacje "ładne wizualnie", "zdjęciowe". Dlatego przez chwilę rozmarzyłem się o programie gr10lab i gr11lab ;)
13. • 13:
       
      CommentAuthoramarok
    • CommentTime3 Sep 2020

     
    @CharlieChaplin
    Thank you very much for your comments. I am going to explore the the subject of RGB modes in a future. But for now I will rather focus on the current specification - pure Graphics 9 mode.
    
    @Kaz
    Co do obsługi myszki to sprawdziłem, że Altirra wspiera emulację myszki z Atari ST. Tak więc będę chciał to sprawdzić w najbliższym czasie. Myślę, że dodam w aplikacji ustawienia czy obsługa jest przy pomocy joysticka czy myszki.
    
    Jeśli chodzi o inne tryby graficzne, które wymieniłeś, to faktycznie jest w czym wybierać. Na pewno jest to kuszące ale nie wszystko na raz :)
    
    "Skąd pomysł czy potrzeba, by zatrudnić do tego komputer 8bitowy?" Odpowiadając:
    1. Atari 130XE to mój pierwszy komputer.
    2. Zawsze interesowałem się grafiką (również w czasach Atari).
    3. Zawodowo zajmuję się przetwarzaniem obrazu w medycynie.
    4. Chciałem zobaczyć jak to się pisze programy dla małego Atari (do tej pory to były tylko programiki w Basicu).
    5. Nie znalazłem tego typu programu dla Atari XL/XE.
    6. Chciałem zobaczyć czy zadanie jest wykonalne i czy wynik ma jakikolwiek sens :)
    
    Gdyby ktoś był zainteresowany to kody źródłowe znajdują się w poniższej lokalizacji:
    ->link<-
    
    Nie oceniajcie mnie zbyt surowo ;)
14. • 14:
       
      CommentAuthorKaz
    • CommentTime4 Sep 2020

     
    Amarok - dzięki za źródła. Nie sądzę, żeby ktoś się śmiał, raczej wywołałeś mocne, pozytywne zaskoczenie :)
    
    Jeżeli wprowadzisz obsługę myszki ST to równie dobrze można wprowadzić obsługę myszki Amigi, bo zasada ich działania jest identyczne, tylko z innych pinów bierzesz wartości:
    
    mysz ST:
    ->link<-
    mysz Amigi:
    ->link<-
    
    Jeżeli chodzi o różne tryby to faktycznie jest ich sporo, ale jakbym miał głosować to wybrałbym ten tryb 256 kolorów - nie ma interlace, też wykorzystuje tryby GTIA, są jasności punktów.
    
    A przy okazji rozmów o Twoim programie na zoomie (zapraszam w razie czego na następną środę o 20:00) to kolega AtariFan postanowił odczytać używany przez Ciebie format i zrobił to w kilkanaście sekund. Misza wyciął fragment tej naszej rozmowy i zrobił z tego taki filmik:
    
    
15. • 15:
       
      CommentAuthoramarok
    • CommentTime7 Sep 2020 zmieniony

     
    @Kaz, świetny filmik z kodowania przeglądarki do formatu GR9. To była naprawdę szybka akcja!
    
    W międzyczasie przygotowałem drugą wersję aplikacji, w której znalazły się następujące zmiany:
    - Dodałem menu z ustawieniami.
    - Dodałem wsparcie dla myszki z Atari ST i Amigi.
    - Dodałem w menu skróty klawiaturowe oznaczone w inwersie.
    - Dodałem opcję szybszego przetwarzaniu obrazu poprzez wyłączenie obrazu.
    
    Zamieszczam poglądowy filmik z obsługi programu przy pomocy myszki.
    
    

    
    
    Dołączam również obraz dyskietki oraz plik xex.

    • gr9Lab_WIP2.atr
    • gr9Lab_WIP2.xex
16. • 16: CommentAuthorThomas Cherryhomes
    • CommentTime7 Sep 2020

     
    I just booted this over FujiNet (fujinet.pl) and ran it. Amazing :)
17. • 17:
       
      CommentAuthorCOR/ira4
    • CommentTime7 Sep 2020

     
    ... jeszcze z tuzin funkcji i będzie Photoshop na A8 ... ale nie mam pomysłu do czego oprócz zabawy można by go używać .
18. • 18:
       
      CommentAuthoramarok
    • CommentTime9 Sep 2020

     
    @Thomas Cherryhomes, thank you for checking the software on a real hardware. Could you please tell me what Atari model have you used? Do you have an access to Atari ST or Amiga mouse?
    
    @IRATA4, masz 100% racji - od samego początku program miał być formą rozrywki, ale również jest to pewien eksperyment technologiczny.
    
    W najnowszej wersji programu jest możliwość włączenia w ustawieniach opcji szybkiego przetwarzania obrazów poprzez wyłączenie obrazu podczas obliczeń.
    
    Przygotowałem poglądowy filmik, w którym porównuję czas obliczeń dla komputera z systemem PAL i NTSC oraz z włączonym i wyłączonym ekranem. Wiem, że to nic odkrywczego, ale gdyby ktoś był zainteresowany wynikami, to zapraszam do obejrzenia...
    
    
19. • 19:
       
      CommentAuthorsun
    • CommentTime9 Sep 2020

     
    A mnie się podoba. Kolejny kawał kodu do przejrzenia.
20. • 20: CommentAuthorKoval
    • CommentTime9 Sep 2020

     
    Super!
21. • 21:
       
      CommentAuthorKaz
    • CommentTime10 Sep 2020

     
    Nieźle, benchmarki zawsze na propsie :)
22. • 22:
       
      CommentAuthoramarok
    • CommentTime28 Sep 2020 zmieniony

     
    W międzyczasie przygotowałem parę kosmetycznych zmian w aplikacji:
    - dodałem wsparcie Trakballa,
    - dodałem możliwość wyboru portu kontrolera do obsługi joysticka, myszki lub trackballa,
    - dodałem obsługę klawiatury dla komputera Atari 800.
    
    Musiałem dodać tabelę do konwersji kodów klawiatury na ATASCII. Normalnie jest ona dostępna w ROMie jednak Atari 800 jej nie posiada. Tabela konwersji jest używana przez funkcję ReadKey w MadPascalu.
    
    
    Próbuję również namierzyć problem z crashem programu. Może ktoś z Was będzie miał pomysł co może być przyczyną.
    
    Żeby wygenerować błąd wystarczy uruchomić wersję z pliku ATR (tam jest DOS 2.5 z automatycznie bootowalną aplikacją). Następnie należy wyjść z aplikacji do DOS poprzez menu gr9Lab->Exit. W kolejnym kroku należy ponownie uruchomić program z DOS (bez restartu komputera) - program jest dostępny w AUTORUN.SYS. I na koniec ponownie wyłączyć program i przejść do DOS.
    
    Moje przypuszczenia są takie, że obszar pamięci aplikacji oraz DOS'a nakładają się na siebie i to powoduje problemy podczas przechodzenia z aplikacji do systemu operacyjnego.
    
    Jeśli chodzi o gr9Lab, to aktualnie zajmuje obszar pamięci od $2000 do $B8C9.
    
    Wszelkie sugestie z Waszej strony będą bardzo pomocne. Ja niestety mam znikome doświadczenie w tych sprawach.

    • gr9Lab_WIP3.atr
    • gr9Lab_WIP3.xex
23. • 23: CommentAuthorpin
    • CommentTime29 Sep 2020 zmieniony

     
    oo, wreszcie coś na Atari a nie emulator.
    
    EDIT:
    
    Problem ze zwisem jakby nie istnieje pod Sparta DOS X 4.49e. Przynajmniej powtórzenie tej sekwencji 4 razy nie wygenerowało problemu. Dość przyjemnie też śmiga to na Rapidusie.
24. • 24: CommentAuthorpin
    • CommentTime29 Sep 2020

     
    aaa, tylko MemLo to ja mam tu na $12B3
25. • 25: CommentAuthorpin
    • CommentTime29 Sep 2020

     
    Jak czytasz znaki z klawiatury? Na DracOS w czasie wpisywania nazwy pliku program się wiesza.
    
    Dobre by było też, by konfigurację urządzenia "wejściowego" zapisać w jakimś pliku *.cfg, bo używając myszki po każdym uruchomieniu programu trzeba to ustawiać na nowo.
    
    Trochę brakuje DIR.
26. • 26: CommentAuthorpin
    • CommentTime29 Sep 2020 zmieniony

     
    Hehe, filter "sharpen" - 280ms :P
    
    Pozytyw - program wstaje z dowolnego podkatalogu i dowolnego dysku.
27. • 27: CommentAuthorpin
    • CommentTime29 Sep 2020

     
    eeee, przepraszam - poprawka. "sharpen" - 140ms
28. • 28: CommentAuthorpin
    • CommentTime29 Sep 2020

     
    po powrocie do dos zdarza się też, że zamiast pisać z klawiatury normalnie wali kodami wewnętrznymi.
29. • 29:
       
      CommentAuthoramarok
    • CommentTime1 Oct 2020 zmieniony

     
    @pin, dzięki wielkie za to, że podzieliłeś się swoją opinią na temat programu.
    
    Muszę powiedzieć, że czasy na Rapidusie robią wrażenie.
    
    Dzięki za podrzucenie pomysłu z plikiem konfiguracyjnym. Wstęnie zaimplementowałem to rozwiązanie, ale zastanawiam się na ile będzie skutecznie działać.
    
    Najlepiej byłoby, żeby plik konfiguracyjny był umieszczony w tej samej lokalizacji co program. Jednak, przyznam szczerze, nie wiem w jaki sposób mógłbym sprawdzić skąd program jest uruchamiany.
    
    Dlatego na razie na sztywno odczytuje/zapisuję ustawienia w "D:GR9LAB.CFG". Działa to prawidłowo w przypadku uruchomienia z dyskietki, którą przygotowuję z każdym wydaniem (tam jest DOS 2.5). Chciałbym to jednak uzależnić od ścieżki, z której uruchamiany jest program.
    
    Może ktoś ma pomysł jak to sprytniej zrobić?
    
    Jeśli chodzi o obsługę klawiatury, to wykorzystuję funkcję ReadKey w MadPascalu, która zczytuje kod klawiatury i konwertuje go na ATASCII przy pomocy tablicy konwersji.
    
    Adres do tej tablicy jest umieszczony w KEYDEF ($0079) i dla komputerów XL/XE wskazuje na położenie w ROMie. Jednak w przypadku Atari 800 takiej tablicy nie ma, stąd pomysł, żeby dodać ją bezpośrednio w aplikacji w pamieci RAM.
    
    No i tutaj pojawiły się problemy, które mam nadzieję, że już rozwiązałem. Po pierwsze program na starcie ustawiał adres do tablicy konwersji w RAMie ale nie przywracał poprzedniego adresu, który dla XL/XE jest w ROMie. Tak więc po przejściu do DOSa mogło zdarzyć się, że obszar tablicy konwersji mógł być nadpisany i wtedy jako efekt uboczny mogło być to co zauważyłeś, że zamiast ATASCII są kody wewnętrzne.
    
    Druga sprawa jest taka, że podmiana tablicy konwersji jest potrzebna tylko dla Atari 800. Tak więc w pozostałych przypadkach nie ma potrzeby niczego modyfikować. Podejrzewam, że problemy na DracOS, które zaobserwowałeś mogą być spowodowane niepotrzebną redefinicją obsługi klawiatury. To również poprawiłem.
    
    Na razie nie wydaję kolejnej wersji aplikacji, poczekam może na jakieś nowe funkcjonalności. Jednak jakby ktoś chciał się pobawić poprawioną wersją, to jest dostępna u mnie na gitlabie (zarówno atr jak i xex).
    
    ->link<-