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 )

saulot: Pytasz o jakich dokumentach mówię? Odpowiadam, że chociażby o jedynym normatywnym, czyli "Standard for Programming Language C++" generowanym przez WG21. Zerknij sobie tu. Ostatni working draft sprzed standardu C++11 ma numer N3242. Jeśli do niego zerkniesz, to zauważysz, że na 1300 stron, 400 jest o języku, a 900 o bibliotece. Najbardziej kluczowym aspektem tej biblioteki jest nacisk na programowanie generyczne (stąd np podział na kontenery i algorytmy). Można napisać niezależne biblioteki podążające tym tropem, czego przykładem jest np boost. Qt jednak skrzętnie od wielu lat ignoruje kierunek, w którym rozwija się C++ opierając swój framework na zupełnie innych założeniach bardziej zbliżonych do języków zarządzanych, a nawet dynamicznych, które są sprzeczne z inherentną statycznością C++.

Stąd moje twierdzenie, że Qt nie używa standardowego C++.

Tak całkiem teoretycznie to nie jest takie środowiska wcale potrzebne. Program napisany pod Visual Studio używający np Qt po przekompilowaniu na linuksa powinien po prostu zadziałać, o ile napisało się go oczywiście dostatecznie przenośnie, ale Qt jest frameworkiem, który dostarcza praktycznie wszystko, więc jak ktoś chce, to nie musi poza niego wychodzić.

Używam tych makr. Tutaj akurat chodzi o hint dla asemblera (deklarację) jaka jest spodziewana szerokość rejestrów w danym miejscu, tak, aby asembler mógł wygenerować błąd, jeśli obliczona przez niego szerokość będzie różna, czyli np. (w pseudokodzie):

regA 16  ;rozkaz przełączający akumulator na 16 bitów
.a8 ; deklaracja, że w tym miejscu akumulator ma rozmiar 8 bitów -> ERROR

albo

.proc Prodecura
.a16 ;deklaracja 16-bitowego akumulatora.
...
.endp

...

.a8   ;deklaracja 8-bitowego akumulatora.
jsr Procedura  ;skok do procedury z kontekstu 8-bitowego akumulatora.
                Procedura deklaruje szerokość na 16-btów -> ERROR
...

Ej. A może koledze chodzi po prostu o wgranie programu w BASICu (który ma na PC w postaci pliku tekstowego) do atari, żeby pojawił się w tam jako program (czyli LIST, RUN... te sprawy)?