Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
atari.area forum » Fabryka - 8bit » Video Board XE - projekt w 90% zakończony
Strony Poprzednia 1 … 21 22 23 24 25 … 29 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
jasne k... z VBXE sa szanse nawet na obsluge myszy, klawiatury, wavetable, wirtualnej maszyny java, OpenGL, DirectX, emulacje Windows i Quake 4. Na kocu ktos wpadnie na pomysl zeby odpiac od VBXE to male szare gowno ze znaczkiem J|L bo tylko przeszkadza w pracy...
EDITED
no sorry, ponioslo mnie.
Ale poszedlem sobie popatrzec na River Raida w folii i juz mi lepiej,
Ta niedyspozycja juz sie nie powtorzy ;P
A co ma vbxe do tego? Jeden gość zrobił coś takiego dla C= (http://tiny.pl/4115) emuluje klawiaturę i mysz 1531.
Ja też kiedyś planowałem XE wsadzić w obudowę PC i co to przeszkadza. Żeby atari istniało trzeba iść z duchem czasu... ;-)
@ nosty - ju orajt? hał ju fil nał? Może zabronić robić dziur w orginalnych obudowach atari po to żeby nie pakować nowych rozszerzeń?
XXL: hmm..., gdzie odniosłeś się do akceleracji?
W przypadku współrzędnych program (jeśli ma być akceleracja) musi od starych współrzędnych odjąć nowe, 'zakcelerować' różnicę i dodać różnicę do starych i mamy wynik.
W przypadku delty, tylko 'akcelerujemy' deltę, dodajemy do nowych współrzędnych i mamy wynik.
Krócej, no nie?
A ws?ółrzędne i tak cały czas są dostępne.
http://atariarea.krap.pl/forum/viewtopic.php?id=4626 ludzie, czytajcie moje linki (plis)
xxl: tez poczatkowo myslalem o współrzędnych w rejestrach, ale drac030 poprosil (i teraz uwazam ze slusznie) o delty. takie rozwiazanie lepiej nadaje sie np. do uzywania myszy jako sterownika w grach, oraz wszedzie tam gdzie nie licza sie wspolzedne, a np. wychylenie/predkosc zmiany w danej osi (cos jak wartosc wychylenia w analogowym joysticku). delty maja wieksze mozliwosci i sa o wieeele latwiejsze w realizacji.
po co odczytywac stan myszy ciagle, jesli np. przez 5 min. jej nie tykasz? po to jest irq (ktore moze tez byc generowane nie koniecznie przy kazdej paczce danych otrzymanej z myszy, ale np. w wiekszych odstepach czasu), aby zglaszac ze cos jest do sprawdzenia.
electron: przez pbi/eci jest to poprostu prosciej zrobic elektronicznie, po czym prosciej oprogramowac, niz transmisja szeregowa po porcie joysticka. ta ostatnia znowu by masakrystycznie obciazala procek, a cala dyskusja w tym temacie rozbija sie wlasnie o jego odciazenie.
nosty: po tym jak przeczytalem o rozluznianiu sie poprzez patrzenie na zafoliowanego riverajda - ciezko mi sie bylo z podlogi pozbierac. fenomenalne poczucie humoru :D
...transmisja szeregowa po porcie joysticka. ta ostatnia znowu by masakrystycznie obciazala procek...
Będzie mały offtopic, ale mi się skojarzyło :D
Na PORTA i PORTB są dostępne przerwania :D Może pamiętacie takie dziwne turbo do magnetofonu (AST?), które przypinało się do portu joya i do seriala? Linie od tych przerwań o ile się nie mylę są dostępne właśnie w gnieździe portu szeregowego. I nawet to jest w systemie chyba obkodowane.
Tak więc wcale transmisja przez PORTA nie musi obciążać proca :)
Poprawcie jeśli się mylę.
Trenowalem transmisje szeregowa po portach joya robiac interface Centronics... rejest przesuwny tam byl i synchronizacja po drugim z bitow. Nie wiem gdzie tu straszne obciazenie procesora, tym bardziej ze w wypadku ukladu posredniczacego odczyt wystarczy robic raz na ramke. Raptem parenascie prostych rozkazow na odczytanie bajtu...
Moznaby to na jakims PICu oprogramowac i zmiescic wszystko we wtyczce, piekna sprawa - w koncu dobrze dzialajaca myszka w maluchu.
Wprawdzie robicie oftop, ale się przyłączę, bo ze znanych względów temat jest dla mnie ważny. ;)
Jeśli już ma to być zrobione na uC, to niech za kryterium wyboru posłużą wymiary i cena oraz łatwość programowania - czyli możliwie najtańszy i najmniejszy układ z ISP, proponuję za Pecusiem jakiś drobniutki PIC.
Proponuję również (1) nie ustalać na sztywno położenia rejestru (rejestrów) w przestrzeni adresowej oraz (2) określić niezmienny format i kolejność danych w rejestrach.
Buduje się coraz więcej dziwnych urządzeń zawierających uC, do których być może łatwo byłoby dodać obsługę myszy i umieścić rejestry w obszarze dostępnym normalnie dla danego urządzenia. Powyższe postulaty zapewniają, że raz napisane oprogramowanie będzie działać ze wszystkimi implementacjami.
Przy okazji fajnie, że maw podlinkował topic sprzed ponad roku. Proponuję przenieść dyskusję tam i zapytać autora, jak mu idzie rozwijanie projektu. :)
dzięki Epi, nareszcie ktoś te moje linki zauważył (a już myślałem, że jakiś tryb 'ignore' cycóś macie na mnie ustawiony:P )
Okiem laika: interfejs musi być przelotowy, przeźroczysty - dlatego mój pierwszy link do atariki - musi być w postaci prawdziwego międzymordzia, czyli z jednej strony dwa wyjścia do joy-a, z drugiej strony dwa wejścia, pomiędzy nimi interfejs PS2. Nie może być tak, że przypinam myszkę i jestem skazany tylko na macany - sorki, makowy - pomysł.
To jedno. Drugie: I delta, i odczyt sparametryzowany generowane przez układ się przydadzą. Delta do symulacji joysticka - prosto na piny, które są obok dostępne. Odczyt sparametryzowany do mojego ulubionego rejestru: PADDLE. Zwłaszcza, że może przyjmować wartości od 0 do 255. Jak już gdzieś zaznaczył XXL, PADDLE jest wolny - przerwanie przydało by się w przypadku rozwiązania z drugiego linku, które może być kłopotliwe z punktu widzenia przeźroczystości interfejsu.
Trzecie: w przypadki symulacji joya odczyt ciągły, sygnał podaje układ na piny - czyli standard. W przypadku PADDLE tak samo. Pytanie: jak zrobić centrowanie pozycji ? Interfejs windowsowy robi to w ten sposób, że w przypadku "wyjścia myszki poza ekran" jako pozycja graniczna przypisywana jest ostatnio otrzymana pozycja poza ekranu (czyli myszka jakby "ciągnie" za sobą obszar widoczny). Tzn. pierw mamy pozycję środka [512,384] (dla 1024x768), która odpowiada pozycji początkowej myszy [0,0] (zakładamy - jaka jest rzeczywista wartość - nie wchodzę). Czyli jeżeli myszka będzie w punkcie [0,0], to wartość jej pozycji będzie [-512,-384]. Wszelkie wyjście poza ten zakres spowoduje zmianę wartości podstawy, a więc mouseX1 (bieżąca pozycja) - mouseX0 (podstawa) == pX (wartość kolumny pozycji X na ekranie).
To chyba przybliżyłem wszystko, co z Waszych odpowiedzi było dla mnie niejasne.
//EDIT: sorki EPI, parę minut przed napisaniem tego posta czytałem inny topik, musiałem tam oko na jakimś poście Pin-a zawiesić...
Przerwania są niezbędne jeśli (wrócę do tematu "systemu okienkowego") kursor myszy ma się ruszać po ekranie w momencie, kiedy kontrola jest oddana aplikacji, a nie application managerowi.
Jak mysz i tak ma być obsługiwana oddzielnym mikroprocesorem, to chyba nic nie stoi na przeszkodzie, żeby można było wybrać, jakiego typu współrzędne się chce od niej otrzymywać. Oraz jaka ma być rozdzielczość. Nic też nie stoi na przeszkodzie, żeby ewentualną akceleracją zajmował się tenże układ - acz wątpię, czy akcelerator przy rozdzielczości ekranu rzędu 320x192 będzie równie niezbędny, jak bywa na innych komputerach przy 1024x768...
@nosty: nikt nie twierdzi, że obsługe myszy trzeba wbudować do VBXE. Tak się przypadkiem offtop zrobił i może lepiej byłoby, gdyby kierownictwo przeniosło go (ten offtop) do nowego wątku.
@mono: na PORTA i PORTB są dostepne przerwania IRQ, ale nie oznacza to, że generują je porty joya. Linie tych przerwań wyprowadzone są na gniazdo SIO.
na PORTA i PORTB są dostepne przerwania IRQ, ale nie oznacza to, że generują je porty joya. Linie tych przerwań wyprowadzone są na gniazdo SIO.
Oczywiście oczywiście. Chodziło mi o ewentualne wykorzystanie ich przy wystawianiu stanów na port joya przez myszkę. Komunikacja nie musiałaby być wtedy szeregowa, ale równoległa (cały porta do dyspozycji, jak ktoś chce z komunikacją w obydwie strony - można przecież ustawić niektóre linie na wyjscia, lub przestrajać kierunki w locie). Ale takie rozwiązanie nie podobałoby mi się ze wzgledu na dwie wtyczki (tak zresztą było właśnie we wspomnianym turbo - uważałem to zawsze za super pokrętne rozwiązanie).
BTW. Czy dostałeś maila ode mnie w związku z sio2bsd (sory za pytanie na forum publicznym, ale nie mam innego kontaktu...)?
Witam.
Ponieważ zostałem wywołany jako autor interfejsu myszki ps/2 dla Atari, pozwolę sobie w tym topicu napisać parę słów na temat tego projektu.
Projekt ukończony jest w 50% procentach. Tzn. działa odczyt współrzędnych, o ile pamiętam ustawianie rozdzielczości i odczyt scrolla myszy ps/2.
Działa emulacja joya. Nie dokończyłem emulacji paddles i emulacji myszek Atari ST/ Amiga. Podłączany jest zgodnie z sugestią z przed roku do jednego portu joya.
Jest kilka różnych liczników do odczytu różniących się zakresami i działaniem. Ale najsensowniej jest odczytywać wartości delta - tak jest w PC'cie czy w Amidze (tu deltę trzeba było sobie policzyć)
i innych kompach z myszą. Teoretycznie soft w pic'u po dodaniu kilku linijek kodu powinien obsłużyć także tablet ze złączem ps/2 w trybie natywnym tzn. odczyt bezwzględnych współrzędnych piórka, odczyt siły nacisku. Niestety nie posiadam takiego urządzenia nie wiem jak by to działało.
W zasadzie do wypuszczenia w świat potrzebuję stworzyć dokumentację, poprawić schemat. Co do softu na Atari to o ile pamiętam przystosowałem lepix (program graficzny) do obsługi myszki i program do testowania poprawności transmisji miedzy Atari a pic' em.
Jeśli jest zainteresowanie to chętnie wszytko opublikuję w następnym tygodniu.
Pozdrawiam.
DarkDK
W zasadzie do wypuszczenia w świat potrzebuję stworzyć dokumentację, poprawić schemat. Co do softu na Atari to o ile pamiętam przystosowałem lepix (program graficzny) do obsługi myszki i program do testowania poprawności transmisji miedzy Atari a pic' em.
Jeśli jest zainteresowanie to chętnie wszytko opublikuję w następnym tygodniu.
Jest zainteresowanie. A czy ten poprawiony Lepix to jest ta ostatnia wersja, ktora wypuscil Eru czy wczesniejsza?
Jest zainteresowanie. A czy ten poprawiony Lepix to jest ta ostatnia wersja, ktora wypuscil Eru czy wczesniejsza?
Ok. Postaram się w przyszłym tygodniu skompletować wszystkie części układanki. Co do Lepixa to poprawiałem źródła dołączone do któreś z wersji MADSa. Nie pamiętam dokładnie.
w pliku README dołączonym do Lepix-a z Mads-a jest informacja o wersji "LePix v.0.1.0 by eru/tqa"
czyli stara wersja, bo najnowsza to 0.2.0
najnowsza wersja ma moduł obsługi myszki, więc wystarczy go podmienić, stara wersja nie miała takiego modułu
Ale takie rozwiązanie nie podobałoby mi się ze wzgledu na dwie wtyczki (tak zresztą było właśnie we wspomnianym turbo - uważałem to zawsze za super pokrętne rozwiązanie).
Obiektywnie wtyczek mogłoby być nawet pięć, rzecz w tym, że te dwie blokowałyby ważne "życiowo" porty, tj. jednocześnie SIO i joya/joye.
BTW. Czy dostałeś maila ode mnie w związku z sio2bsd (sory za pytanie na forum publicznym, ale nie mam innego kontaktu...)?
Tak, sorry za brak odpowiedzi, ale na razie nie miałem czasu się tym zająć. W domu mam jakąś poprawioną wersję sio2bsd, spróbuję zmerdżować twoją wersję z moją, ale do (testów) tego potrzebny mi jest sprawny setup Atari, którego mi chwilowo brakuje ze względu na awarię kompa. :(
@darkdk: rozumiem, że ruch myszą nie wywołuje żadnego przerwania i trzeba do czytać w kółko np. na VBL-u?
podpisz plytki, bedzie wydanie kolekcjonerskie :-)
Śliczne :)
Właśnie testuję pierwszego videoborda
Chodzi z marszu, czy są kłopoty? Ja się nie mogę zabrać za swój, chociaż już dawno leży zmontowany ;)
Są kłopoty z RAM-em niestety, walczę - nie uruchamiam następnych póki nie będę wiedział o co chodzi.
Tzn. Wyjście RGB działa ... Emulacja rozszerzenia ma jakieś problemy.
Co ciekawe maszyna testowa ma walnięte GTIA, a na VBXE wsio jest OK. :)
Automatyczny wewnętrzny test całej pamięci RAM VBXE wypada pomyślnie, brak jakichkolwiek problemów. Sprawa jest więc na styku VBXE -> Atari czyli pozostaje dopracować interfejs szyny w rdzeniu ... no to jestem spokojniejszy.
Na razie zablokowałem emulację rozszerzenia RAM do czasu wyjaśnienia sprawy.
2 uruchomione.
2/2 dotychczas działają, jest RGB, test pamięci OK, działa FLASH ...
tak codziennie 1-2 szt. mogę uruchamiać o ile nie wyjdą jakieś problemy
Trochę to offtopic ale mam pytanie:
Czy teoretycznie na VideoBoard dałoby się tak zaprogramować ten układ (nie pomnę jak się on fachowo nazywa) żeby zamiast robić 50 ramek tak jak do tej pory robił 25 z podwojoną rozdzielczością poziomą?
tzn. chodzi o uzyskanie rozdzielczości 640x200 mono.
Jeżeli dobrze zrozumiałem dokumentację pełni on również między innymi rolę konwertera bitmap->sygnał composite.
Wyobrażam to sobie w ten sposób, że ANTIC byłby programowany do odczytu 2 ekranów naprzemiennie, a VideoBoard sklejałby je w poziomie i z takiej sklejonej bitmapy tworzył sygnał wyjściowy.
Powiem wprost, że opis działania VideoBoard i jego schemat znam bardzo po łebkach, a na programowaniu układów tego typu nie znam się wcale.
Strony Poprzednia 1 … 21 22 23 24 25 … 29 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Fabryka - 8bit » Video Board XE - projekt w 90% zakończony
Wygenerowano w 0.047 sekund, wykonano 65 zapytań