Mikrokomputer COBRA 1

Czy istnieje jakas lista zmian do publikowanych wsadów, co było zmienione w stosunku do poprzedniej wersji?

Wielkich zmian nie ma, jedynie obrazki menu i kombinacje programów w nich zawartych z umieszczaniem nowych jak się pojawiają.
Różnica jest natomiast w stosunku do pierwszych wsadów monochromatycznych.
Obecnie dany wsad można uruchomić z gniazda cartridge jak i z płyty głównej.
Wcześniejsze wersje miały w oznaczeniu wsadu literkę C - gniazdo cartridge lub M - płyta główna.
Opis Dual-Ram oczywiście wykorzystuje tą pamięć w części programów lub w całości.

W załączniku umieściłem wersję 3 gry ELECTROBODY, która przeznaczona jest dla płyt DUAL-RAM i nowej wersji emulatora COBRY.
Jedyną różnicą w stosunku do wersji 2 jest umieszczenie wewnątrz gry tablicy zawierającej zmodyfikowany generator semigrafiki, przepisanie jej do pamięci RAM
od adresu F000hex i przełączenie generatora podstawowego na nowy.
Przed zakończeniem gry przywracam podstawowy generator semigrafiki.
Nie wiem, czy jest to konieczne.
Czy hardware płyty lub emulator nie robi tego samodzielnie przy powrocie do adresu C000hex ?
Adres startowy G:100
Zawartość RAM: od adresu 100 hex do adresu 2280 hex (czyli 8832 bajty)
(przed uruchomieniem nowego emulatora należy skasować plik COBRA.CFG
emulator sam go sobie utworzy)
Załączam podziękowania dla Kol.andrzejlisek za porady na PW.

Pierwsza przymiarka

Witam

Jak dla mnie to wygląda to rewelacyjnie, odrazu widać ze przykładasz dużo uwagi do estetyki urządzenia. Fajnie ze po tylu latach jest jeszcze grono ludzi którzy dalej próbują coś robić z tym komputerem. Wiele osób w tym i ja w tamtych czasach niestety nie miało możliwości zbudowania tego komputera, i teraz te wspomnienia odżywają czytając o nowych ulepszeniach sprzętowych i oprogramowaniu które się ukazuje. Bardzo dobrze prezentuje sie też pcb Cobra 1 które przedstawiłeś kilka postów wcześniej. W ciągu tych kilku lat od założenia tematu, dołączyło kilkanaście bardzo dobrych fachowców, którzy cały czas coś nowego wnoszą do tematu.

Pozdrawiam

Dzisiaj odpaliłem Cobre 1 na przeniesionej do Altium już 4-warstwowej płycie Dual RAM 2023 z zmienionym dekoderem I/O i z wsadem 14 Zdzisława.



Po naprawieniu oscylatora i uzyskaniu 6.5MHz, na wyjściu composite ukazał się taki obraz.



Regulacja P1 pomogła i obraz stał się czytelny, żyleta.


Zero poprawek na PCB. Jutro sprawdzę wyjście RGB. To chyba najszybciej uruchomiony układ od jakiś dwu dekad. W większości użyłem układów serii ALS, zaś wszystkie przerzutniki 7474 w wersji F. Ale mi ulżyło, teraz powinno być z górki. Pozdr, Sławek

Moje szczere gratulacje !
Bardzo się cieszę, że zaprojektowałeś płytę główną PCB bez żadnych błędów.
Dobrą wiadomością jest też bezproblemowe uruchomienie.
Faktycznie to się nie często zdarza.

@zdzis_ek dziękuję
Dzisiaj wyjście RGB odpaliło także z buta.



Klawiatura PS2 również bez problemu.
@atmega8 dzięki za pliki.

@eskwadrat Płyta wygląda imponująco, obudowa i klawiatura robi wrażenie… bardzo ładny projekt!

Zamieszczam do przetestowania oprogramowanie do Atmega88 PS2.
Po wykonaniu adaptera JOYx2 i prostej modyfikacji na płycie komputera, Cobra obsługuje dwa JOYSTICK’i

Układ Atmega88 RESET - można pominąć. W mojej Cobrze mam zworkę zamiast diody DR1.

Klawiatura PS2 funkcjonuje jak klawiatura łączona PC i Cobra.

Zestawianie połączeń w matrycy nie jest impulsowe. Połączenie w MT8808 jest aktywne na czas naciśnięcia lub trzymania klawisza, za wyjątkiem kilku klawiszy funkcyjnych np.: Backspace. Naciśnięcie kilku klawiszy zestawia kilka połączeń w matrycy. Podobnie z Joystick’ami. Wychylenie po skosie aktywuje dwa połączenia na czas wychylenia Joystick’a. Można zaprogramować wychylenia Joystkick’a własnymi znakami. Brak problemu kasowania Shift po naciśnięciu znaku, Shift może być stale naciśnięty.
Dokładniejszy opis zamieszczam w pliku tekstowym.
Oczywiście program działa bez adaptera z jednym joystick'iem, ale na PB4 musi być stan wysoki.

Projekt staje się bardzo ładny.

2 dżoje to super sprawa.

marwu napisał:

Dokładniejszy opis zamieszczam w pliku tekstowym.

Co sądzisz o dodaniu myszy PS2 do kompletu? W tym ATMEGA protokół PS2 już jest... tylko 2 linie i można czytać pozycję myszy.

> tylko 2 linie i można czytać pozycję myszy.

No nie do konca. W przeciwieństwie do klawiatury mysz sama nie podaje nic dopóki nie zostanie skonfigurowana.
Nawet jeśli wepniesz mysz do portu PS2 to nie będzie wysyłać żadnych danych, dopóki nie przejdzie procesu inicjalizacji i konfiguracji.

Tutaj jest krótki opis jak to się robi:

https://wiki.osdev.org/PS/2_Mouse

>>21562935 >>21562935

sajmosia napisał:

Nawet jeśli wepniesz mysz do portu PS2 to nie będzie wysyłać żadnych danych, dopóki nie przejdzie procesu inicjalizacji i konfiguracji.

Wobec tego mysz zainicjalizować. Zgodnie z duchem myszy można pykać klawiszami strzałek aby przemieszczać kursor.

> Wobec tego mysz zainicjalizować.

To nie jest takie proste, zwłaszcza ze podczas inicjalizacji po wysłaniu każdej komendy do myszki trzeba czekac na odpowiedz, także albo trzeba to zrobić na przerwaniach i zbudować mały "state machine" w kontrolerze, albo wysyłać komendy powoli i modlić się o pozytywny wynik ignorując odpowiedzi myszki.

Potem gdy mysz już zacznie wysyłać dane, czyli zmiany stanu przycisków i deltę ruchów X i Y, to jak chcesz to interpretować w Cobrze? Sprzętowo, czy programowo ?

Jeśli sprzętowo, to kilka pytan:
- jak chcesz przebudować układ wyświetlania tak, zeby wskaznik myszki przesuwal sie wzgledem tego co wysyla kontroler ?
- Co chcesz zrobić kiedy mysz nie jest potrzebna i wskaźnik ma być niewidoczny ?
- czy wskaznik myszki chcesz tylko przesuwac sprzetowo, czy mieć też możliwość przesuwu programowo ?
- czy jeśli programowo też, to mozna miec wiecej wskaźników i nazwać je duszkami ?
- Jeśli jednak tylko programowo, to w ROMie czy tylko w programach, które piszą użytkownicy ?

Tak na marginesie odnośnie duszków to w Commodore 64 uklad VICII sklada sie w 75% z systemu obsługi duszków i nie jest to prosty układ.

Aczkolwiek jeśli ktoś potrafi taki zaprojektować i wcisnąć do Cobry to jestem za.

Pozdro.

PS: Kiedy przychodzi do mnie dyrektor i zaczyna pytanie od "can we just quickly..."
Reszta to poezja :/

Może to jeszcze nie myszka a jedynie jej kursor.
W roku 2020 poczyniłem próby sterowania kursorem myszki klawiszami W, S, A, D.
Ponieważ nie jestem mocny w pisaniu programów w kodach maszynowych, całość demo napisałem w programie Basic.
Tak to wyglądało :


Znacznie trudniej wydaje się napisanie jakiegoś programu (gry) z takim sterowaniem.
Więc dalsze starania w tym kierunku zaniechałem.

Ale może takie rozwiązanie kogoś zainspiruje do napisania programu z wykorzystaniem kursora.
Później pojawił się kolor i czas poświęciłem na kolorowanie programów monochromatycznych.

zdzis_ek napisał:

Może to jeszcze nie myszka a jedynie jej kursor.

Ale może takie rozwiązanie kogoś zainspiruje do napisania programu z wykorzystaniem kursora.

UUU widzę piękny COBRA OS na CP/M. Te kafelki idealnie sprawdzą się w gęstym trybie graficznym w roli skrótów do programów na dysku...
A może nawet taki player PT3 by zrobić, gdzie kolejne muzyczki to takie kafelki.... widzę moc.

Dodano po 16 [minuty]:

sajmosia napisał:

- jak chcesz przebudować układ wyświetlania tak, zeby wskaznik myszki przesuwal sie wzgledem tego co wysyla kontroler ?
- Co chcesz zrobić kiedy mysz nie jest potrzebna i wskaźnik ma być niewidoczny ?
- czy wskaznik myszki chcesz tylko przesuwac sprzetowo, czy mieć też możliwość przesuwu programowo ?
- czy jeśli programowo też, to mozna miec wiecej wskaźników i nazwać je duszkami ?
- Jeśli jednak tylko programowo, to w ROMie czy tylko w programach, które piszą użytkownicy ?

- kontroler może przetworzyć odpowiedź myszy na kobrowe XY, np. 25x64... następnie takie wartości wystawić na porty ATMEGA, które będzie mieć więcej końcówek, czyli np następne ATMEGA 644 zamiast ATMEGA88... (czyli będzie to lokalny kontroler klawiatury PS2, 2 dżoje i mysz PS2) na portach gdzie są wartości X i Y podłączone komparatory cyfrowe 74LS688. Komparatory miałyby z drugiej stromy podłączony licznik kolumn i wierszy układu graficznego. Czyli zgodzenie się X i Y z licznikami aktywowałoby wyjście komparatorów. Dzięki temu uzyskujemy sygnały za komparatorami "grafika na kursorze".
Te 2 sygnały ORujemy i później ANDujemy z 7 bitem układu 6116 koloru. Wyjście to ORujemy z sygnałem za 74LS165.... tak więc dostajemy kwadrat... albo XORuejmy aby dostać negatyw obrazu pod kursorem. Tak więc zapisanie 1 do bitu 7 do rejestru koloru aktywuje kursor, a 0 deaktywuje kursor dla danego znaku na ekranie. Odczyt pozycji przez program... 2 kolejne scalaki 74LS245 podłączone do szyny danych i dekodera GAL. Z drugiej strony zapięte do wyjść ATMEGA/wejść komparatorów w celu umożliwienia stanu bieżącego. Jakby pokombinować to i się zrobi kursor na więcej znaków, ale o tym można później by nie zaciemniać. Więc mamy w miejscu kursora negatyw/kwadrat i możliwość odczytu myszy IN A....

- pierwsza wersja wizji obejmowała odbiór danych z myszy i przemieszczanie kursora sprzętowego po ekranie. Jeśli kwadrat 8x8 nazwiemy duszkiem to będzie duszek

- kursorów można mieć tyle ile się chce, ale pytanie czy da się kopić tak duże PCB aby pomieścić tyle logiki

- odczyt myszki miał być prostym rozkazem IN A, (adres_myszy_) i IN (adres_myszy_Y). Jak więcej takich wskaźników to więcej tych IN A,()

Jak na moje realizacja to ze 3-4 scalaki więcej (jakieś luźne bramki tam widziałem na schemacie) + przeróbka ATMEGA88 i będzie trykało... czyli kursor będzie przemieszczał się po kafelkach kolegi Zdzisława...

sq2bvn napisał:

Co sądzisz o dodaniu myszy PS2 do kompletu?

… modyfikacja płyty głównej:

Sygnały z myszy zestawiają połączenia w matrycy MT8808, symulując klawiaturę W,A,S,D. Przyciski to ENTER, X, SPACE. Niestety jest tu poważne ograniczenie wynikające z procedury odczytu klawiatury przez Cobrę. Wprowadziłem regulację czasu trwania połączenia w MT8808 w zakresie 5-99ms, w ten sposób można regulować czułość myszki.
Na oscylogramie przesuwanie myszki po skosie: czas trwania impulsu 60ms(może być regulowany) oraz odstęp pomiędzy impulsami 28ms (najmniejszy, wynika z programu w Atmega88, może być większy w zależności od przesuwania myszy).

i 16ms pomiędzy zestawieniem połączeń z różnych kanałów

Czułość myszy po wejściu w tryb programowania klawiszem ScrollLock można regulować klawiszami:

Po wejściu w Basic na ekranie wyświetlane są aktualne wartości czasu trwania impulsu, np.:

Poruszanie się po menu we wsadach do Cobry kolegi zdzis_ek wygląda tak:

Niestety granie w gry przy takim rozwiązaniu myszy jest nie komfortowe, ponieważ w matrycy zestawiane są połączenia impulsowe gryzące się z procedurą odczytu klawiatury w grach. Podobnie będzie z poruszaniem kursorem po ekranie, procedura odczytu klawiatury w Cobrze jest za wolna, widać na filmie wstawianie znaków na ekran, trwa to dość długo w stosunku do ruchu myszki… nie wiem czy da się bez problemowo przyspieszyć procedurę odczytu klawiarury w Cobrze, czy iść w tym kierunku:

sq2bvn napisał:

- odczyt myszki miał być prostym rozkazem IN A, (adres_myszy_) i IN (adres_myszy_Y). Jak więcej takich wskaźników to więcej tych IN A,()

Na filmie poniżej CPU pracuje z zegarem 6,5MHz, czas zestawienia połączenia w MT8808 ustawiłem na 22ms i działa już całkiem akceptowalnie.
Ze względu na ograniczenia czasowe odczytu klawiatury przez Cobrę nie mogłem uzależnić prędkości poruszania myszy do prędkości kursora (znaków) na ekranie. Na filmie znaki na ekran wysyłane są możliwie najszybciej, nie da się tego przyspieszyć. Tu pojawia się pytanie: jeśli da się tą procedurę przyspieszyć do komfortowego posługiwania się myszką, to czy klawiatura mechaniczna będzie jeszcze działała prawidłowo?

marwu napisał:

sq2bvn napisał:

Co sądzisz o dodaniu myszy PS2 do kompletu?

Niestety granie w gry przy takim rozwiązaniu myszy jest nie komfortowe

Aby było bardziej elegancko, pozycja wskaźnika myszy powinna być dostępna dla pętli sterującej grą.
Stąd też dawałem 2 rejestry do odczytu. W przypadku wolnych komputerów, sprzętowy wskaźnik położenia myszy nie jest przesadą. Taki z jednym duszkiem zupełnie by wystarczył. Wówczas ruch wskaźnika myszy na ekranie będzie niezależny od pracy samego CPU, ale mimo to CPU będzie odczytywać gdzie jest wskaźnik i odpowiednio reagować.

Można też zrobić większego duszka jako wskaźnik, ale to powiększy układ, szczególnie jeśli te duszki miały by być modyfikowalne z poziomu CPU.
Najłatwiej byłoby dodać pamięć z odpowiednim wsadem z duszkami i po numerze je aktywować. Danie DUALRAMu na duszki to jednak znaczna przebudowa układu wizji i raczej nie ma kamikadzów co się tego podejmą...






Co do przycisków myszy można zostawić jak jest czyli wduszać klawisze lub na przyciski wykorzystać bity D7-D5 na portach ATMEGA644.
Ale wówczas trzeba będzie wejścia komparatorów XY R7-R5 z ATMEGI podłączyć do 0...

Albo w ogóle dać możliwość ustawienia jak mają działać myszy... w trybie klawiatury, czy w trybie XY.

Po takiej przebudowie kursor myszy będzie biegać po kaflach jak szalony...

W przypadku takiego rozwiązania program PAINT będzie banalny do zrobienia szczególnie w CP/M. Gdzie można stworzyć obraz i zapisać obraz do pliku. W pętli czytasz IN A(addr_mysz_X) oraz IN A(addr_mysz_Y) i ustawiasz znak jako zapalony... Pozostaje pytanie jak rysować w trybie pixel zapixelem?

Można też zrobić jeszcze inaczej. Do liczników w ATMEGA zapodać takt wideo i liczyć pixele w pionie i w poziomie.... wówczas kursor byłby jednym punktem. Wówczas na X będzie 256 pozycji X oraz 200 Y. Wówczas stany klawiszy trzeba dodawać ponad 200... a CPU musiałby odejmować INowaną wartość od 200 aby wiedzieć jakie były klawisze oraz odwrotnie dla pozycji Y

Oto program demonstracyjny działający na każdej wersji COBRY i emulatorze.
Używa wyłącznie standardowy zestaw semigrafiki.
Dżwięk można wybrać:
1- AY-3-8910/12
2- KATARYNKA (porty 00 hex i 08 hex)
3- GENERATOR (port FE hex)
Zajmuje pamięć RAM od adresu 5000 hex do 8BE8 hex (czyli 15 336 bajtów)
Adres startowy G:5000
Większość pamięci zajmują spakowane 16 ekranów oraz dane dla nut dla trzech trybów generowania dźwięku.
Screeny ekranów:



Tytuł BLOODY ANGEL pochodzi od intro utworu muzycznego o takim tytule. Oryginał jednak brzmi o wiele ciekawiej. Ja przeliczałem dane nut z internetu
i dopiero po przeliczeniu wszystkich nut okazało się, że nie jest to wierna kopia.
Animacja była przygotowana już wcześniej i nie ma żadnego związku z muzyką.

Załączam program skompilowany od adresu 5000 hex: BLOODY.hex
oraz skompilowany od adresu 100 hex: BLOODY100.hex

wieswas napisał:

Oto program demonstracyjny działający na każdej wersji COBRY i emulatorze.

2-kanałowy dźwięk brzmi ciekawie. Do zestawu przydałaby się perkusja... ups ups ups

Kurs C na COBRA1 część 1. Przewodnik jak od 0 uruchomić swój pierwszy program w języku C na COBRA1.
Jak widać, tworzenie w C jest banalne i o niebo łatwiejsze od pisania programów w asemblerze. Na dodatek, dzięki C można próbować przenosić programy z Arduino na COBRA1.




Kurs to plik szablonu najprostszego projektu C oraz teoria w PDF.

Ewentualnie proszę o jakieś sugestie, czy robić dalsze części, czy nie tracić czasu.

sq2bvn napisał:

Ewentualnie proszę o jakieś sugestie, czy robić dalsze części, czy nie tracić czasu.

Myślę, że robić, ale bardziej skupić się na "bibliotece API", która zawierałaby wszystkie funkcje potrzebne do Cobra1, jak malowanie na ekranie, granie dźwięku, odczyt klawiszy itp. charakterystyczne dla Cobra1, a także zrobić lub znaleźć bibliotekę, która umozliwia programowanie poprzez API CP/M, czyli wywołania niezależnie od Cobra.

Dodano po 1 [minuty]:

Dodaję wiekową "bibliotekę", którą kiedyś sam pisałem na swoje potrzeby, jak coś próbowałem napisać dla Cobry w SDCC. Może się przyda do budowy bibliteki i tutoriala? Oczywiście nie zawiera katarynki, AY, czy innych wynalazków, które zaistniały później.

sq2bvn napisał:

Co sądzisz o dodaniu myszy PS2 do kompletu? W tym ATMEGA protokół PS2 już jest... tylko 2 linie i można czytać pozycję myszy.

Tak czytam, jak rozwinie się temat myszki, o ile w ogóle. O ile sama obsługa myszki (odbiór przemieszczenia i naciśnięć przycisków) może nie jest jakimś wielkim problemem, o tyle problematyczny może być kursor i ja to "widzi" Z80, jak tego użyć w grach i programach.

Ale z drugiej strony, jak już się ma myszkę PS2, a program może odbierać przemieszczenia, to można pójść dalej: Można poszukać starą myszkę kulową, rozbebeszyć ją i ma się dwa impulsatory, czyli pokrętła emitujace impulsy (inaczej enkodery). Jedynie potrzeba jakoś dorobić przewody do płytki od myszki, bądź też na ATMega zrobić od zera takie coś, co ma 2 przyciski (czy tam tyle, ile przewiduje PS/2) i dwa pokrętła, z których jedno to przemieszczanie myszki w pionie, drugie to przemieszczanie myszki w poziomie.

Takie coś, co udaje myszkę nie wymagałoby osobnych bebechów w przypadku, gdy istnieje interfejs PS/2 do myszki. Zastosowań może być wiele. Regulacja głośności, ustawianie jakiś parametrów liczbowych "od-do", ruch paletki w grze podobnej do Breakout, Pong, prymitywna aplikacja do malowania typu "Etch A Sketch" lub "Magicka Tabulka" (choć rozdzielczość graficzna będzie jedynie 64x72 piksele).

>>21576835

Czy ograniczenie się do mysz kulowych to dobry kierunek?
PS2 można mieć nawet w wersji optycznej, nawet są przejściówki USB->PS2 więc w sumie każdą mysz można zastosować, nawet bezkablową.

@andrzejlisek jesli chodzi o implementacje myszki to mysle, ze najprosciej by bylo stworzyc trzy bajtowy rejestr, w ktorym zapisywane by byly sprzetowo dane przychodzace z myszki i maskowalne IRQ, zeby procesor wiedzial, kiedy te nowe dane od myszki przychodza.

Zeby rozszerzyc to troche, to mozna ustawic kilka takich rejestrow rownolegle tworzac maly bufor, ale to juz troche bardziej komplikuje sprawe.

Co do sprzetowego wyswietlania wskaznika, czy innego duszka sterowanego programowo lub prosto z powyzszego rejestru to mozna sie przyjzec jak zbudowany jest uklad VERA w Commanderze X16. To powinno przyblizyc chocby zarys tego jak sprzetowo wyswietlac obiekty inne niz sam ekran.

Wyswietlanie wskaznika i to i kiedy co robi procesor z danymi przychodzacymi z myszki to sa dwie osobne kwestie i mozna je zaaplikowac niezaleznie od siebie.

Co do ograniczania sie tylko do myszek typu stolokulotoczny manipulator, to kwestia indywidualna. Problem jest tylko taki, ze tych kulkowych myszek praktycznie nie ma skad wziac, a i ogolnie myszki z wtyczka PS2 robia sie coraz rzadsze.
Osobiscie uwazam ze lepiej jest mozliwosci rozwijac niz ograniczac, ale jak kto lubi.

andrzejlisek napisał:

Myślę, że robić, ale bardziej skupić się na "bibliotece API", która zawierałaby wszystkie funkcje potrzebne do Cobra1, jak malowanie na ekranie, granie dźwięku, odczyt klawiszy itp. charakterystyczne dla Cobra1, a także zrobić lub znaleźć bibliotekę, która umozliwia programowanie poprzez API CP/M, czyli wywołania niezależnie od Cobra.

W pliku cobra1.lib właśnie dodawane są kolejne pliki COBRA1 API. Z założenia preferowane są wywołania CP/M BIOS. Akurat za dużo tych wywołań nie ma w CP/M 2.2 ale to co jest będzie wykorzystane, łącznie z obsługą plików. Lib.zip się przyda, można będzie zawartą funkcjonalność do biblioteki CORBA1.h. Obecnie korzystamy z biblioteki z80.lib z SDCC oraz cobra1.lib.

Po 10 częściach kursu można będzie robić fajne programy dla COBRA1 tym bardziej, że jak już ktoś zbudował komputer to zapewne będzie chciał robić na niego również programy. Dodatkowo, język programowania C jest stosowany na nowe komputery, więc nauka przyda się do działania z innymi nowymi komputerami.

Dodano po 20 [minuty]:

andrzejlisek napisał:

Może się przyda do budowy bibliteki i tutoriala?

Te funkcje graficzne są całkiem całkiem...
Obsługa ekranu w trybie XY też można by dodać do kursu. Wtedy można robić program w stylu BASIC.

Procedury core jest już w BIOS CP/M...

sq2bvn napisał:

>>21576835

Czy ograniczenie się do mysz kulowych to dobry kierunek?
PS2 można mieć nawet w wersji optycznej, nawet są przejściówki USB->PS2 więc w sumie każdą mysz można zastosować, nawet bezkablową.

Nie chodzi o ograniczanie do konkretnego typu myszy. W przypadku użytku myszy jako myszy, czyli zgodnie z przeznaczeniem, nie ma znaczenia, jaka ona będzie, byle by miała PS/2. Ja pisałem o tym, że mając rozpracowany interfejs do myszy, można bez dalszych modyfikacji zastosować "manipulator" z jednym czy dwoma enkoderami zrobionymi z części od myszy kulowej lub od podstaw.

andrzejlisek napisał:

manipulator" z jednym czy dwoma enkoderami zrobionymi z części od myszy kulowej

Czy ktoś podejmie się podłączenia manipulatora z jednym czy dwoma enkoderami zrobionymi z części od myszy kulowej do systemu?

Jak to będzie wyglądało w postaci schematu/algorytmu?

Mój układ XY jest realizowalny praktycznie przez każdego (4 dodatkowe układy TTL-LS i tryka). Czy zastosowanie samych enkoderów nie będzie za trudne?

Dodatkowo nie wiadomo, czy źródła pisane w PLM uda się skompilować z procedurami myszy. Programy przejściowe MTA CP/M były robione właśnie w PLM.

sq2bvn napisał:

Czy ktoś podejmie się podłączenia manipulatora z jednym czy dwoma enkoderami zrobionymi z części od myszy kulowej do systemu?

Jak to będzie wyglądało w postaci schematu/algorytmu?

Chyba zaszło małe nieporozumienie. Nie chodzi o budowę jakiegokolwiek urządzenia z części od myszy, tylko o to, że dysponując już gotowym interfejsem zrobionym na użytek myszy PS/2, można ten sam interfejs i protokół wykorzystać do ewentualnego manipulatora z enkoderem, bez robienia kolejnego interfejsu. Protokół PS/2 jest raczej prosty i można go obsłużyć na ATMEGA32 lub ATMEGA328, a urządzenie podłączone do interfejsu myszy PS/2 niekoniecznie musi być myszą, może być czymkolwiek, co emituje takie same sygnały, jak mysz.

O myszy kulowej wspomniałem tylko dlatego, że jak się wyjmie kulkę, to właściwie już jest gotowy manipulator z dwoma enkoderami, tylko, ze jego obsługa nie jest wygodna ze względu na kształt urządzenia, w końcu mysz nie jest przeznaczona do użytkowania w taki sposób.

andrzejlisek napisał:

obsługa nie jest wygodna ze względu na kształt urządzenia

Czyli przerobić mysz na jakiś czujnik położenia i podłączyć do COBRA1? Takie kobruino? Sterowanie jakimiś zabawkami DIY za pomocą COBRA1 jest to ciekawy kierunek rozwoju.

Jakieś tam DIY peryferiały do COBRA1 widziałem... był chyba już CUBE 4x4x4 oraz jakieś sterowniki lampek...