@xxl: Na pytanie odpowiedziałem wielokrotnie, tylko nie po Twojej myśli i drążysz dalej. Jeżeli rozszerzenie wykonuje program, to program działa na rozszerzonym Atari. Rozszerzone Atari != Stock Atari i kwestią osobistej oceny jest jakie rozszerzenia się nam podobają i chcemy mieć z nimi coś do czynienia:
- Tomek przylutowany na stałe byłby rozszerzeniem, które w osobistej ocenie nie za bardzo by mi się podobało.
- VBXE ma fajne praktyczne zastosowania (80-kolumnowa konsola tekstowa itd), ale pokazywanie laikowi 256-cio kolorowych fruwających sprajtów twierdząc, że tak rysuje Atari byłoby pewnym nadużyciem.
- Rapidus ma całą masę fajnych praktycznych zastosowań - szybsze wykonywanie istniejących programów oraz możliwość pisania nowszych programów korzystających z dobrodziejstw 65c816, ale znów wmawianie komuś, że jakieś wyczesane efekty liczone na 65c816 są efektami na Atari też byłoby mijaniem się z prawdą. Byłyby to efekty na rozszerzone Atari.

To są kwestie filozoficzne, a kwestie praktyczne jak np demo compo też są jasne: demo na Rapidusa nie będzie konkurowało w jednej kategorii z demami na 6502.

A poczytaj sobie o Zilog eZ80 i wytłumacz mi, dlaczego można nazwać go 8-bitowcem (i nazywa się go 8-bitowcem nawet w oficjalnym podręczniku), a 65c816 już nie można.
Dziękuję.

A jakie to ma znaczenie? Za pomocą PORTB można zaadresować 4 MB. Dodając teoretycznie drugi rejestr zwiększa się to do 1 GB. Co ma tu do czynienia 8-bitowość czy nie architektury.

Wciąż nie podałeś żadnego niezbitego dowodu, że 65c816 jest procesorem 16-to bitowym. Zadaj sobie trudu i porównaj jego możliwości do 6809 (było już wiele nawiązań do niego w tym wątku), który producenci nazwali 8-bitowym, bo był kontynuacją 8-bitowego 6800. Taką nazwę zapewne zastosowali żeby móc 68000 nazwać 16-bitowym, bo oba procesory pojawiły się mniej więcej w tym samym czasie.
Więcej: 6809 nie jest binarnie kompatybilny ze swoim poprzednikiem 6800 - jest kompatybilny na poziomie kodu źródłowego i kod należy przekompilować aby ruszył na nowym procesorze. Czyż zatem 16-to bitowe rejestry, mnożenie, cała masa trybów adresowania i to takich, że 65c816 może mu jeść z ręki nie pretenduje do nazwania go 16-to bitowym? Najwidoczniej nie, skoro producenci tak nie postanowili.
65c816 został nazwany 16-bitowym marketingowo, bo nie jest bardziej 16-to bitowy niż 6809. A nawet więcej. Jest zamiennikiem 6502 - wyciągasz stary procesor, wkładasz nowy rzekomo 16-bitowy i wszystko śmiga. Jak to możliwe pytam się? skoro jeden jest 8 a drugi 16-bitowy...
Inny przykład z drugiej strony barykady to 8086, który jest kompatybilny na poziomie kodu źródłowego z 8080 (tak jak 6809 kontra 6800). A jednak Intel zadecydował, że nazwie go procesorem 16-to bitowym, ponieważ konkurował z 68000.

Mieszasz w tym poście i pozostałych z trybem emulacji. Tłumaczę i objaśniam. 65c816 został zaprojektowany jako zastępnik 6502 na poziomie wymiany czipu i wszytko miało działać. Żeby to osiągnąć procesor musiał budzić się w trybie zgodnym z 6502 (tzw. "emulacji"). Nie zapala się światełko, że skoro można wyjąć procesor i w tę samą podstawkę wsadzić inny i wszytko będzie działało, to to może i nie oznacza przejścia o rząd wielkości w architekturze i wszystkim co tam sobie wymyślasz? Intel i Motorola wyprodukowały nowe 16-to bitowce i tak je nazwali. WDC chciał przyszpanować i nazwał swojego 65c816 (o funkcjonalności zbliżonej do 6809) 16-to bitowcem i za bardzo wziąłeś sobie to niestety do serca.

Nigdzie niczego takiego nie napisałem. Po prostu gdyby ALU był 8-bitowy, niektóre operacje 16-bitowe trwałyby cykl dłużej, a nie trwają. Trwają tyle samo co odpowiadające operacje 8-bitowe na 6502. Czasy trwania wszystkich legalnych instrukcji 6502 są takie same jak 65c816.

Poczytaj o 8-mio bitowym 6809. 65c816 może mu czyścić berło jeśli chodzi o 16-bitowość, tryby adresowania i rozkazy. 65c816 nie jest taki potężny właśnie dlatego, że jest zamiennikiem 6502 i projektanci mogli wprowadzić tylko takie zmiany, które nie zepsują binarnej kompatybilności, której 8-bitowy 6809 nie ma.

Rozkazy 65c816 są oczywiście nielegalne na 6502, bo nie potrafi ich wykonać. Zamontowanie 65c816 rozszerza Atari o możliwości nowszego kompatybilnego procesora. 16-to bitowa linia Atari to ST bo została tak zaprojektowana. Atari XL/XE jest 8-bitowe i trochę mocniejszy kompatybilny procesor tego nie zmieni.

Gwoli ścisłości. Ja rozumiem jakie obawy ma Sikor. Tak samo jak Rapidusa w gniazdo CPU można włożyć jakiegokolwiek współczesnego potwora, który będzie naprawdę emulował 6502 a do pamięci Atari widocznej przez ANTIC wrzucał tylko strumień danych tworzących obraz itd... To byłaby emulacja i Atari byłby tu terminalem. Ale Rapidus (przynajmniej ze standardowym rdzeniem) w żaden sposób nie przekracza tej granicy, gdyż jest wyposażony w procesor, który jest oficjalnym i naturalnym następnikiem 6502 zaprojektowanym przez jednego z jego twórców. Żeby się lepiej sprzedawał nazwano go 16-bitowym (do czego przesłanki są w długości ALU, ale z programistycznego punktu widzenia ma to tylko takie znaczenie, że oszczędzamy cykl na niektórych operacjach.), ale jest (ew. powinien być) pod wszelkimi względami kompatybilny z poprzednikiem. Wybrano ten procesor, gdyż jest przystosowany do szybszego taktowania. Potrafi wewnętrznie zaadresować więcej RAM, to czemu mu go nie dać? Ale ten RAM nie wpływa na istniejące programy (modulo brak zapętlania się pamięci przez rozkazy indeksowe, co jest błędem i jest naprawiane przez samego Rapidusa).
Skok o rząd wielkości, o jakim mówi Sikor, miałby miejsce wtedy, gdyby procesor nie potrafił pracować w środowisku 8-bitowym, czyli gdyby naturalne dla niego było połykanie w jednym cyklu 16-bitów danych. Wówczas programy 8-bitowe musiałyby być emulowane. 65c816 pracuje na danych 8-bitowych i nie należy traktować go jako w pełni procesora 16-bitowego.

Oczywiście, że to nie są programy na stockowe 8-bitowe atari. Taka jest definicja rozszerzenia, że modyfikujesz coś w komputerze i program korzystający z modyfikacji nie działa na oryginale. Nie ma zgody tylko co do miejsca postawienia kreski. Dla mnie i wielu zamontowanie 65c816 robi z Atari XL/XE rozszerzone Atari XL/XE, a dla Sikora i popleczników, to już za dużo i żądają kwalifikacji jako 16-bitowa pochodna linii Atari XL/XE co jest absurdem, bo komputer nie jest bardziej 16-bitowy. Nie musi emulować serii XL/XE tylko działa tak samo + trochę więcej. Komputer 16-bitowy adresuje pamięć 16-bitową i nie potrafi w prosty sposób wykonywać tego samego kodu co komputer 8-bitowy i żeby tego dokonać musi stosować emulację. W naszym przypadku to nie występuje.

Sikorze. Ilu bitowy jest wg Ciebie 68000? 32? czy 16? Dlaczego ST jest 16-bitowe a nie 32?
Nie za bardzo rozumiem, dlaczego spośród wszystkich parametrów komputera wybrałeś sobie akurat wewnętrzną architekturę procesora jako czynnik zmieniający wszystko. Obudowa jest ta sama. Jak włączysz, pojawi Ci się ten sam niebieski ekran generowany przez tego samego ANTICa pospołu z tym samym GTIA. Muzyczkę gra ten sam POKEY. Elektrony zapierniczają po tych samych liniach (płyta główna jest ta sama). Architektura wciąż jest 8-bitowa. Procesor (nazwany 16-bitowym) porozumiewa się z resztą Atari tak samo ośmiobitowo jak oryginalny 6502. Co więcej działają te same programy, (chyba, że ktoś napisze je nie tak jak podręczniki uczą), tylko że - jak przystało na kartę turbo - uwaga, uwaga - szybciej! Atarka z Rapidusem zachowuje się całkiem jak zwykła Atarka. Sam procesor nie określa rodziny komputerów. Atari to co innego niż Commodore i co innego niż Apple II, mimo że mają (praktycznie) taki sam procesor. A ta szesnastobitowość, na której się opierasz, jest bardzo przejaskrawiana. Zewnętrznie 65c816 jest 8-bitowy (dlatego można użyć go jako zastępnika 6502) i został użyty w Rapidusie dlatego, że bez problemu działa przy wyższym taktowaniu. To że ma kilka 16-to bitowych rejestrów? Co z tego. 6502 też ma 16-to bitowy licznik rozkazów. Z80 ma całą masę rejestrów 16-bitowych. To nic nie znaczy. Jedyne co potrafi istotnie więcej niż 6502, to adresowanie 24-bitowej pamięci, ale to także z jego rzekomą 16-bitowością nie ma nic wspólnego. Wg Twojej logiki powinno się go w takim razie nazwać procesorem 24-bitowym, bo istnieją w środku logiczne twory, które są 24-bitowe - adres komórki jako para rejestru banku i rejestru adresu. Ale tak jak 16-bitowość PC nie robi z 6502 procesora 16-bitowego, tak samo 24-bity adresu nie robi z 65c816 procesora 24-bitowego. A co do pamięci nic nie stoi na przeszkodzie, żeby w "prawdziwym" Atari napędzanym 6502 zamontować 16 MB, albo i 1 GB RAMu. Odpowiednio dużo rejestrów wybierających bank i masz. 65c816 ułatwia po prostu sprawę w ten sposób, że potrafi adresować tę pamięć sam, bez dodatkowej elektroniki, która będzie pamiętała resztę adresu, tak jak się dzieje w przypadku bankowania.
Reasumując dla mnie 65c816 to procesor 8-bitowy, bo zachowuje się jak procesor 8-bitowy, który wewnętrznie został zoptymalizowany do operacji 16-bitowych i radzi sobie z nimi lepiej (przypominam, że 6502 też wykonuje te operacje, przecież ma 16-bitową przestrzeń adresową, tylko robi to kulawo i wolniej) stąd jego nazwa 65 (rodzina) C (CMOS) 8 (że 8-bitowy) 16 (że dobrze radzi sobie z operacjami 16-bitowymi).

Tekst z datasheeta to papka marketingowa. Zwróćcie uwagę, jaki to 65c816 jest enhanced, extended i advanced. Użycie słowa emulation bardzo ładnie się w to wpisuje - procesor jest taki zajefajny, że jest w stanie emulować 6502!!11

Proszę nie używać liczby mnogiej, bo propozycja jest tylko moja i dziękuję za krytykę :)
Propozycję pseudorozkazu "sys" uzasadniam domniemaną trywialnością implementacji i prostotą użycia, ale po argumencie Foxa uświadomiłem sobie, że w takim rozwiązaniu zewnętrzny program wołany byłby przy każdej asemblacji, podczas gdy rozwiązanie z plikami pośrednimi sterowane make lub odpowiednikiem minimalizuje liczbę wywołań, co jest oczywistym plusem w przypadku skomplikowanych generatorów. Ostatecznie zły pomysł.

A pseudorozkaz "gen"? Ideą jest minimalizowanie liczby zastrzeżonych słów kluczowych będących nośnikami jakichś wartości, które można w przeciwnym razie mnożyć w nieskończoność, a za jego pomocą niejako rezerwujemy na nie osobną niekolidującą przestrzeń nazw.

Wciąż także nie wydaje mi się, aby podstawowe makra (data, itd) nie mogły być realizowane automatycznie np za pomocą takiego generatora. Konieczność instalowania środowiska dlatego, że autor kodu źródłowego napisał sobie linuksowego wsada generującego coś, co może być w samym asemblerze wydaje mi się nadużyciem.

Z tymi 16 bitami z pełnymi konsekwencjami to trochę przesada. Mimo szczerych chęci nie nazwałbym 65c816 w pełni 16 bitowym. To taki 8/16. Nie ma 16 bitowego "feelu". Programując go ma się raczej poczucie takiego Z80 (też ma 16 bitowe rejestry) albo 6809 (który ma bardzo zbliżony "layout"). Porównaj to sobie do takiego 8086, którego 16 bitowość jest już inherentna.
Jasne, że 816-tka ma 24-bity przestrzeni adresowej, ale to jest raczej danie 8-bitowcowi okienka na 16-to bitowy świat, przez które zagląda do większej pamięci...

syscall: Tak się składa, że każdy koder pisze w którymś momencie swojej kariery jakiegoś asemblera. 90% nie kończy, a z tych ukończonych tylko dwa używa ktoś poza autorem.
Wiem, bo sam teraz piszę swojego trzeciego z rzędu asemblera, ale się z tym nie obnoszę, bo pewnie znowu trafi do tych 90% :)
Zalecam więc trochę pokory, bo jaki mads jest każdy widzi, ale jest ukończony i działający na tyle, że używa go większość atarowskiego światka.

21. Rozbijanie płyty, ale na QuST 98. Dwóch od lewej to Solo i Tiger.
58. Rozbijania ciąg dalszy. Tleniony blondynek w środku to Solo. Z prawej jest Tiger i ja chwytający się za głowę :)
90. Po rozbiciu. Od lewej Roland, Tiger, Solo
73. Blondynek w pasiastej koszuli to oczywiście Solo
41. A tu trochę starszy, więc to na pewno jakiś późniejszy zlot.
76. Pet koduje tu Sheola :)

W robocie utrzymuję konfigurację windowsową (visual) i linuksową (gcc makefile) sporego projektu i dorobiłem się kilku automatów, ale w ogólności nie każdy projekt visuala da się trywialnie przerobić na coś strawnego na linuksie. Jeżeli to nic tajnego, to mógłbym na to zerknąć ( laoo ( at ) icomp . pl )