Szczerze mówiąc wątpię, nie widziałem żadnego CPU opartego o rdzeń 6502 z wbudowanym "serial engine" do obsługi USB. Jeżeli już ktoś tworzy takie "hybrydy" oparte o jakiś 8-bitowy rdzeń, to są to raczej rdzenie zgodne z 8051. Lub takie dla których został opracowany jakiś sprawdzony/komercyjny/porządny kompilator języka C, najlepiej ze wsparciem producenta.

Oczywiście to że ja nie widziałem żadnego rdzenia 65xx ze zintegrowanym USB, nie znaczy że takim wcale nie ma,  bo być może istnieją ale są mało popularne w regionach EU, czy USA. Być może ktoś w Azji wpada na tak szalone pomysły :)

Patrząc na te przejściówki z którymi miałem styczność, to były zwykłe przelotki (zero elektroniki w środku), obsługę USB lub PS/2 realizował MCU który znajdował się w myszce... to właśnie ten MCU orientował się podczas startu do jakiego interface jest podpięty i uruchamiał odpowiedni kawałek softu w zależności od tego do jakiego interface myszka została podłączona. W przypadku PS/2 dwa piny I/O stawały się liniami CLK, DATA w przypadku gdy podłączono mysz do USB, MCU konfigurował piny tak że stawały się liniami D+, D- interfejsu USB.

Ostatnio edytowany przez seban (2021-04-19 16:49:23)

Warunkiem de facto koniecznym do stosowania 6502 w takich nietrywialnych miejscach jest istnienie dobrego kompilatora C, tak jak wspomniał Seban. Ja żadnego nie znam. Wiem o istnieniu komercyjnych kompilatorów C, ale nie mam zielonego pojęcia jakiej one są jakości, bo na oczy żadnego nie widziałem. Nawet WDC ma swój kompilator

O... jak pisałem tego posta, to odkryłem, że narzędzia programistyczne od WDC są dostępne za free: https://wdc65xx.com/WDCTools

Parę minut się pobawiłem i faktycznie, nie dość, że d... nie urywa, to nawet kod wynikowy wygląda na gorszy niż cc65. Ciekawostką jest, że jak przypadkiem zrobiłem błąd w kodzie źródłowym, to zamiast dostać komunikat, to dostałem crash kompilatora :)
6502 w istocie nie jest przyjazdy dla języków wysokiego poziomu z ich tradycyjnymi konstrukcjami (stos, struktury), ale wierzę, że przy odpowiednim wysiłku dałoby się zrobić to dobrze. Tylko nikt, kto potrafi nie ma czasu, a kto ma czas, to nie potrafi :)

Ostatnio edytowany przez laoo/ng (2021-04-20 08:01:27)

Dzięki za odpowiedzi! Autor posta chyba popłynął. W komentarzu ktoś mu wytknął, że nie wszystkie myszki działają z pasywną przejściówką.

Hmmm, nie szukają w tym WDC inżyniera kompilatora? ;)

Z C na 6502 są dwa podstawowe problemy:

• większość kodu operuje na intach, które są co najmniej 16-bitowe

• mocno używany jest stos, a 6502 oferuje tylko dostęp do elementu na wierzchu i ma mały stos

65816 rozwiązuje oba te problemy. Nie widziałem kodu wygenerowanego dla 65816, ale mogę się założyć, że jest znacznie bardziej wydajny, niż dla 6502.

Myślisz zbyt "szablonowo" - język wejściowy to jedno, kod generowany to drugie. Można spokojnie napisać kompilator, który wsiorbie kod w C a wypluje bytecode dla maszyny wirtualnej Javy. Bez żadnego problemu. Kwestia określenia maszyny docelowej. To zadanie dla studenta 3-go roku informatyki (z sensownej uczelni). Można więc wygenerować taki kod, żeby był odpowiednio wydajny.

Inną sprawą jest to, jak faktycznie robią to kompilatory C generujące kod dla Atari, które mamy. Ja bawiłem się chwilę cc65, napisałem sobie w nim jakiś kawałek kodu robiący prosty efekt (paletę 256 kolorów i, osobno, taki "bouncing scroll") ale przyznam, że nie przyglądałem się temu jak wygląda wygenerowany kod maszynowy.

Nie popłynął. Pogóglałem chwilkę i dokopałem się do mikrokontrolera CHESEN CSC0101A.

EDIT: oraz do konwertera Speed-Link SL-6502, ale tu chodzi i o inne PS2, i o inne 6502, mwahaha.

Ostatnio edytowany przez Krótki (2021-04-20 08:51:56)

Też się nie znam, ale się wypowiem ;). A nie można używać TSX/TXS i LDA 256,x do dostępu do innych obiektów na stosie? Zawsze się zastanawiałem czy ktoś w ogóle myślałem o wykorzystywaniu tego do zrobienia kompilatora języka opartego o stos.

To, że kompilatory istnieją, to jedno, a jaki generują kod, to drugie.  Problem jest wielowarstwowy, ale chyba kwintesencją mogłoby być to, że języki programowania ewoluowały razem z procesorami w swoistym sprzężeniu zwrotnym i współczesny kod w C, taki jak się robi go zgodnie ze sztuką nijak ma się do możliwości 6502, za to świetnie współgra z możliwościami współczesnych procesorów. Ja jestem pod wielkim wrażeniem jakie cuda potrafi wygenerować Clang na x64, arm, czy riscv, ale podejrzewam, że backend na 6502 mógłby nie być już taki spektakularny, gdyż 6502 może nie spełniać minimalnych wymagań maszyny na jaką Clang jest w stanie cokolwiek sensownego wygenerować. Jako konkretne problemy można wymienić chociażby kwestie zarządzania pamięcią na tymczasowe zmienne lokalne (naturalny jest stos, który na 6502 trzeba emulować, bo sprzętowy jest mały i trudno dostępny), popularne wzorce adresowania pamięci (które nie mają wsparcia w 6502 przez jego dość specyficzne tryby adresowania), czy rozmiar operandów (dla 6502 nawet 16-bitów jest trudne i pisząc w asemblerze unika się tego sztuczkami, na które niekoniecznie możne sobie pozwolić kompilator nie znający kontekstu i tego co programista miał na myśli).

@mormon
Oczywiście da się zrobić tak jak zaproponowałeś. Tak się nie robi tylko dlatego, że programując w asemblerze nie używa się do tego stosu, a programując w języku wysokiego poziomu nie używa się do tego stosu sprzętowego, bo jest niebezpiecznie mały.

dosc czesto stosowany trik - nawet nie trik ale sa wydajniejsze metody. "emulacja" 16-bit rejestrow indeksowych jest dla 6502 zabojcza.

@Fox: Możesz wyspecyfikować, o co ci chodzi? Czego według ciebie nie zrobiłem lub co zrobiłem a nie powinienem? I przede wszystkim, czemu powinienem byl tak zrobić (lub nie)? Konkrety proszę. Przyglądałem się fragmentom, np. jak robiona jest pętla dla tablicy dłuższej niż jedną strona albo jak jest robione memcpy. Ale całego kodu nie przeglądałem bo nie było to dla mnie interesujące.

jaki on tam sprzętowy :) raczej dywagacyjno-research-o-naukowo-edukacyjny :) no i teraz jeszcze będzie offtopicowo-humorystyczny :)