Cze ponownie :)

Widzisz drac030 - nawet taki RS to nie jest taka łatwizna Po co zwalać na Atarynkę osługę jakiejś klawiatury ?:)
Po prostu najlepiej uzyć nowoczesnych rozwiązań, czyli mikrokontrolerów - Atarka otrzyma gotowy keycode i tyle A ile przy tym
możliwości się otwiera... No... :D

ale plizzzz - najpierw sama płyta :) Pomysł na karte testową jakiś tam mam. Jakiś wyświetlacz LED albo nawet LCD wraz z obsługą
w ROM jako jakieś tam urządzenie :) i 4 klawiszowa klawiaturka. Tylko po to aby sprawdzić całość. To na razie pomysł ale do realizacji.

Pozdrawiam

tOri

drac030 - no i tu jest leciutka skucha bo klawiatury PC wysyłają owszem kody, i owszem - po swojemu, i owszem czasami jest tego całkiem sporo :( Szkoda by było zajmować atarkę obsługą takich bzdetów jak tłumaczenie kodów z PC na Atari ( szkoda czasu ) Niech procesory zewnętrzne odwalają czarną robotę i tyle. A AKI to niby co jest ? ;-) Obecnie koszty takich rozwiązań są znikome w stosunku do efektów
(popatrz na SIO2IDE - IMHO rewelacja :) Po to są urządzenia zewnętrzne żeby dostarczały porządne dane a nie "półprodukty"

Tak właśnie myślę. W końcu wykorzystanie mocy Atari osiągnie 100% i co wtedy... ? Bez mikrokontrolerów nastąpi to o niebo szybciej
i niejako "na własne życzenie" a tego bym nie chciał. Kiedyś był niejako przymus projektowania "na piechotę" i sam widziałem
FDD 8" zbudowane w oparciu o kilogram (albo więcej) scalaków TTL - a przeciez nie o to chodzi. Ważne aby było jak najbardziej
wydajnie i skutecznie :) Jeśli mam skutecznie rozwalić brzęczącego komara nie zawaham się użyć lasera jeśli to mi da 100% pewności,
że już go nie usłyszę ;-)

Pozdrawiam

tOri

Wiem o tym. Wysyłaja po kilka bajtów. Zapewniam cię, że 6502 sobie z tym świetnie poradzi.

Czy ty aby trochę nie przesadzasz? Translacja tych kodów nie wymaga transformaty Fouriera, to dwie tabelki na krzyż i góra kilkaset bajtów kodu - wykorzystanie ROM-u newdev jak sięgnie przy tym 25%, to będzie dobrze.

AKI to jest emulator firmowej klawiatury Atari przyczepiany do Pokeya  - czyli zupełnie co innego. Zresztą, wyjaśnij mi proszę kwestię, jaką postawiłem w poprzednim poście: jak zewnętrzny procesor ma dokonać translacji funkcji klawiszy na ASCII w oparciu o tablicę definicji klawiatury, KTÓRA JEST W PAMIĘCI ATARI A NIE KARTY?

Wykorzystanie mocy Atari sięgnie 100% przy obróbce skankodów klawiatury? Czy ty aby *lekko* nie przesadzasz? :P Niby co ma atarkę obciążać? Przecież przy urządzeniach I/O takich jak klawiatura, gdzie ilości transmitowanych danych są takie, że poradziłby sobie z tym dalekopis z czasów wojny, wykorzystanie procesora jest w zasadzie żadne. A przy urządzeniach gdzie transfery są intensywne (w rodzaju twardego dysku), 6502 i tak albo odczytuje dane z portu I/O, albo czeka w pętli, niezaleznie od tego, czy wsadzisz między komputer a dysk jeden mikroprocesor więcej czy nie.

Ale komu dzisiaj jest potrzebna ośmiocalowa FDD z kilogramem scalaków? :) Poza tym akurat FDD to jest takie urządzenie, że oddzielny mikroprocesor musi mieć - ale nie dlatego, że to dobre i nowoczesne :P tylko z zupełnie przytomnego powodu: tandem 6502 + Antic nie wyrabia się na odbiór danych szeregowych z kontrolera FDD.

Weź jeszcze przy tym pod uwagę, że karty pewnie niektórzy będa chcieli zmontować sobie w domu. Nie ma więc sensu komplikować ich konstrukcji ponad miarę - oczywiście do konwersji kodu klawiaturowego na ASCII można zatrudnić nawet Pentium 4; tylko po co, skoro ten interfejs można zrobić z kilku prostych scalaków dostępnych za grosze w każdym sklepie, a handler dla 6502 będzie nie dłuższy (albo będzie i krótszy) niż oryginał odczytujący skankody z Pokeya?

PS. SIO2IDE oczywiście znam, ale jakoś nie rzuca mnie na kolana.

No można, ale po co marnować miejsce (w HATABS mieści się tylko 11 wpisów). Zresztą nadpisać istniejący wektor jest łatwiej, niż dodać drugi taki sam, jest do tego procedura w OS-ie.

mikey: no, aż strach pomyśleć, co jeszcze jest zdolny w przyszłości zrealizować :)

tu akurat nie trafiles - karta sieciowa nie potrzebuje uniwersalnego mikroprocka - wystarczy uklad kontrolera, kapke ramu i kilka linii sterujacych (skoro 8051 potrafi tym sterowac, to atarka tym bardziej...)

co do klawiatury - "Atarka otrzyma gotowy keycode": jesli masz na mysli ze program odczyta kod znaku - to nie tylko o to chodzi, bo wazne sa "eventy" czyli: key up, key down. bez tego nie masz mozliwosci obslugi kombinacji klawiszy. atarka spokojnie sobie poradzi z translowaniem kodow ps/2 na strawne dla siebie (ps. jakos nie widze mozliwosci "pelnej kompatybilnosci" klawiatury podpinanej inaczej niz pod pokeja)

correct: Ty sie nimi nie interesujesz, bo jestes spaczony przez 6502 (co widac m.in. po proponowanych przez ciebie mikrokontrolerach - praktycznie u nas nie uzywanych) :P

tak na prawde to roznic jest niewiele miedzy tymi mikroprockami i poza nielicznymi przypadkami (tak, o Ciebie rowniez tu chodzi ;) ), ktos kto zna jednego assemblera, nie powinien miec "odrazy" do innych... kwestia zwiazana z tym ze "nikt sie nie interesuje" jest bardziej zwiazana z tym ze malo kto w ogole sie interesuje assemblerem, bo przeciez turbobasic jest taki szybki :/

co do zgodnosci klawiatury - jesli program uzytkowy: to zazwyczaj bedzie odwolywal sie przez system, jesli giera - to juz zalezy od autora (bo przeciez moze caly system odcinac i sam zarzadzac m.in. klawiatura...)

a co do podzialu - popieram ;) ale domyslam sie ze wiekszosc utilsow by pojszuo bez przerobki (programy ktore dostosowywales do nowej sparty, czy do 816OSa odwoluja sie przez handler K: ?)

Czy w tym temacie są jakieś postępy...?

Cze!

Postępy byłyby gdyby nie shizy dnia powszedniego... Grr... No po prostu czasami zwala z nóg.
Mimo, że w całym projekcie nie ma zbyt wiele filozofii - trzeba dłuższą chwilę mu poświęcić
a mnie czeka kawał solidnej nauki do poważnych egzaminów. Staram się jednak i gdy tylko
cosik wymotam - napewno wrzucę do konsultacji na mój site.

Pozdrawiam

tOri

P.S. Pin - bardzo prawdopodobne, że istniejące rozwiązania musiałyby zostac przerobione albo
odrzucone - niestety ale taka jest zwykle cena za wprowadzanie nowych rozwiązań (czyt. mała zgodność...)

Wkleję się do tego starego wątku.

Ten 32 bit procesor zgodny z 6500 mnie zainteresował.

Dokładniej ciekawi mnie czy dałoby się w nim dodać: "HyperThreading" podobny do tego z P IV i konfigurowalny przydział cykli dla obu pseudordzeni.

tzn. ja to sobie wyobrażam następująco: zdublowane rejestry wszystkie całkowicie od siebie niezależne i dodanya logika do linii clock, która konfigurowalnie oddaje clock raz do jednej puli rejestrów raz do drugiej.

Czyli np. mamy procesor działający z 7x1.8MHz i ustawiamy sobie, że podstawowy pseudordzeń dostaje 1 cykl, a drugi 6 cykli.

Takie rozwiązanie pozwoliłoby zapewnić "hotplug" procesora w już zaprojektowanych płytkach bez znaczących modyfikacji kodu. O ile oczywiście odpowiednio obsługa przerwań do tego byłaby dodana.

ArchieIl - zeby odpoczac przy pisaniu nowego OS w przerwach bedziesz budowal 32-bitowe rozszerzenie procka? ;)

Szczescie, ze ja wogole nie rozumiem tego o czym piszecie i sie tak podniecacie bo jestem zwyklym zbieraczem kardridzy...
Ale kibicuje Ci mocno! Pare lat temu jak tu trafilem tez pisalem takie pomysly na 3 ekrany i oburzalem sie jak ktos mi odpowiadal "napisz se". Moge Ci podac linki nawet ;P Do tej pory nie zostaly jakos zrealizowane - klatwa jakas czy co?
Teraz jak cos zaczynam, to na wszelki wypadek nie pisze nic publicznie, zeby nie zapeszyc. Polecam taki sposob - jest skuteczniejszy.

Myślę, że Drac030 ma w WDC lepsze kontakty ode mnie.