Masz niestety rację. No ale może zyski będą większe niż straty ... ?

Magistralę ma ośmiobitową, toteż odczyt szesnastobitowy trwa dokładnie dwa razy tyle, co ośmiu bitów. Ale liczy się też zassanie rozkazu i adresu.

Ergo, jedno LDA szesnastobitowe (i z szesnastobitowym adresem) będzie trwało tylko o jeden cykl dłużej niż odpowiednie ośmiobitowe, czyli 5 cykli, w porównaniu do ośmiu, które zjada wciągnięcie analogicznej ilości danych rozkazami ośmiobitowymi.

Wynika z tego, że przesłanie danej z rejestru IDE do pamięci - odczyt w trybie absolutnym, zapis w pośrednim indeksowanym - trwa na 6502 aż 24 cykle:

lda ide_data
sta (bufp),y
iny
lda ide_data+1
sta (bufp),y
iny

natomiast na 65c816 to samo powinno zająć tylko 16:

lda ide_data
sta (bufp),y
iny
iny

no ewentualnie do 18 przy zastosowaniu 24-bitowego adresowania. Czysty zysk.

Khm, że się wtrącę. gcc faktycznie winszuje sobie bardzo dużo pamięci i już na 14 MB mogą być problemy, a co dopiero na 4 MB. Ale to gcc 2.95.2, a kto powiedział, że koniecznie trzeba używać właśnie tej wersji?  Z tego co pamiętam dobrze działające wersje gcc to 2.7.2, 2.6.5 oraz 2.3.3. (było jeszcze 2.8.1 ale to pomyłka). Wszystkie trzy życzą sobie dużo mniej RAM-u niż 2.95.2, są nowsze niż Pure C (tak mi się wydaje - ale może ktoś sprostuje) no i kompilują C++, o ile to komuś robi.

No ja to szczerze mówiąc widzę tak, że w momencie, kiedy dostaniesz x megabajtów pamięci liniowej, adresowalnej wprost, jeszcze w dodatku szybkiej, wtedy rozszerzenia starego typu po prostu przestaną być potrzebne. Może się będzie od biedy wykorzystywać tę pamięć na buforowanie zapisu na twardziel, ale innych zastosowań nie widzę.

Ergo, nie ma sie co gimnastykować i dawać w nowym formacie binarnym jakiegoś szczególnego supportu dla bankowanej pamięci. Jeśli o mnie chodzi - umówmy się, że najwyższą fazą rozwoju systemów operacyjnych zamkniętych w 64 kilobajtach jest SpartaDOS X - która ma dla bankowanej pamięci support prawie perfekcyjny - i ... zostawmy to po prostu tak jak jest.

Mój komputer, odkąd mam twardy dysk, ma 176 kilobajtów niepotrzebnej pamięci. Jest 64k podstawowe plus Sparta X zajmuje jeden bank pamięci, co daje razem 80k. Reszta się leży odłogiem.

Nie jest on taki znowu nowy, pliki $FFFF są ładowane dokładnie tak samo. Ale przyznaję ci rację, że to jest wynalazek wart zachowania.

Tak jest, wiem o tym, jest to załatwione za pomoca symboli. Weź jednak pod uwagę, że symbole są trudne do zachowania - w tej roli - na 65c816, gdzie JSR "krótki" (16-bitowy) i JSR "długi" (24-bitowy) to są dwa oddzielne rozkazy, wymagające w dodatku różnych rozkazów RTS przy powrocie.

Dlatego jedynym sensownym rozwiązaniem dla systemu operacyjnego itp. jest wołanie funkcji przez przerwanie programowe (COP).

Może Bill The Great kupił sobie 800XL. Idea plug&play też się pojawiła dobre 12 lat po tym, jak Atari Inc. wymyśliło "nowe urządzenia".

Tak jest, może się tak okazać. Ja zakładam jednak optymistycznie, że nawet Antic - z jego czterokilowym ograniczeniem - kiedyś wyjdzie z użycia. Dlatego nie uważam, żeby miało sens dostosowywanie formatu binariów do Antica akurat. Ostatecznie można to łatwo rozwiązać programowo. Jak kiedyś na Falconie potrzebowałem bloku pamięci z wyrównaniem do granicy 64 kilobajtów, to obeszło się bez supportu systemowego, wystarczyło że system w ogóle był w stanie zaalokować blok pamięci, dalej poradziłem sobie sam.

Do nagłówka wprowadziłem następujące nowe pola:

- długość segmentu TEXT (to pole było i poprzednio, zmiana nazwy tylko)
- długość segmentu DATA;
- długość segmentu BSS;
- wielkość stosu;
- wielkość segmentu zawierającego symbole zewnętrzne;

Obecnie nagłówek wygląda tak:

- bajty 0-3: REL1
- bajty 4-5: flagi

Flagi obecnie są takie:

$0001 - LWD - 32-bitowe słowa w nagłówku (w przeciwnym razie 16-bitowe); danie 32 bitów zamiast 24 upraszcza loader.
$0002 - TSR - wiadomo;
$0004 - EXE - uruchomić program od offsetu wskazanego w nagłówku (w przeciwnym wypadku: nie uruchamiać; patrz dalej;
$0008 - INI - to samo, tylko że oczekuje się, że program wróci przez RTS oddając przy tym status wykonania (kod błędu albo $01); jeśli oba bity są ustawione, to najpierw wykonuje się INIT, a potem EXEC.
$0010 - STK - zaalokować stos o wielkości wykazanej w nagłówku; teraz mnie naszły wątpliwości, czy ta flaga jest w ogóle potrzebna.
$0020 - ZPG - zaalokować oddzielną stronę zerową dla programu;
$0040 - APG - wyrównać adres ładowania w górę do granicy stron;
$0080 - ABK - wyrównać adres ładowania w górę do granicy banków;

W starszym bajcie trzy bity kodują rodzaj pamięci, do którego należy załadować program. Powinno wystarczyć. Reszta na razie zarezerwowana.

Dalej nagłówek leci tak (słowami 16- albo 32-bitowymi, j/w):

słowo 0: długość segmentu TEXT
słowo 1: długość segmentu DATA
słowo 2: długość segmentu BSS
słowo 3: wielkość stosu
słowo 4: długość segmentu XREF
słowo 5: długość segmentu FIXUP
słowo 6: offset EXEC
słowo 7: offset INIT

bajt: wielkość opcjonalnego tekstu + tekst opcjonalny o tej wielkości.

Segment FIXUP (lista fixupów): pierwsze słowo (16 bitów) koduje format, dalej dane wyglądają w zależności od formatu. Format $0000: szesnastobitowe offsety bezwzględne licząc od początku pliku, i dla 16-bitowych adresów (co wystarcza jeśli program ma <= 64k i używa włącznie 16-bitowego adresowania wewnątrz siebie).

Segment XREF: future definition ;-) wyobrażam sobie to tak, że najpierw idzie typ symbolu, potem wielkość nazwy symbolu, potem onaż, a potem offsety w pliku binarnym, gdzie należy wstawić właściwy adres tudzież wartość. Ale to na razie zostawmy na przyszłość.

Na specjalne życzenie truba, który chce, żeby program składał się nie tylko z oddzielnych segmentów na kod i dane, ale wręcz z oddzielnie ładowanych i uruchamianych porcji kodu, można dać nastepujące zastrzeżenie co do loadera: program ten po załadowaniu pierwszego nagłówka i wszystkich wykazanych w nim segmentów, oraz ewentualnym zainicjowaniu ich, ma powtarzać te czynności w pętli aż do EOF, chyba że program zażąda przerwania tej pętli - tak jak to się obecnie dzieje, przez np. skok jmp (dosvec) z segmentu INIT, zamiast powrotu przez RTS.

Chłop swoje, czort swoje. Trub, czy możesz mi logicznie wytłumaczyć, skąd ci się wzięła uporczywie przez ciebie lansowana koncepcja, że proponowany przez mnie format pliku relokowalnego nie może być, bądź też ma nie być tworzony przez kompilator?

Jeśli mi nie odpowiesz na to pytanie, tak żeby odpowiedź miała ręce i nogi, to kończę dyskutowanie z tobą; bo jak dotąd ja ci mówię A, a ty wyciągasz z tego wniosek, że nie A, tylko B. W ten sposób możemy gadać długo i bezowocnie, szkoda czasu.

Tak jest, ale o systemie może podyskutujemy kiedy indziej, żeby nie rozwadniać.

To chyba mylisz komunikację między programami z obsługą wywołań systemu. W SDX jest to przyznaję rozwiązane bardzo pomysłowo, ale niewiele ma to wspólnego z tematem.

Odpowiedzi na te pytania znajdują się w poprzednich postach wątku. Po co chcemy nowy format:

1) mnie jest potrzebny format relokowalny, żeby uzyskać maksimum wolnej pamięci dla SysInfo;

2) format SDX się nie nadaje do tego celu (adresy dzielone);

3) przy okazji format można lepiej zdefiniować i szerzej wykorzystać; dlatego w ogóle poddałem to pod dyskusję.

Relokatora z TA możesz sobie uzywać sam, jeśli cię to satysfakcjonuje.

Nie bardzo widzę, na jakiej podstawie może ci się tak wydawać.

Do możliwości jakie daje MAE (MAC/65, QA, cokolwiek) dostosowany jest program mkrel.com. Nie byłby on potrzebny, gdyby asembler od razu generował kod docelowy.

mkrel.com wymaga jako danych wejściowych dwóch kopii tego samego pliku binarnego skompilowanych pod różne adresy. Jest to jedyna metoda na znalezienie wszystkich wewnętrzych referencji, o ile ich położenie nie jest znane skądinąd. A nie jest :)

To kwestia podłączenia MMU :p

Zresztą, wirtual i MMU na 65c816 dzisiaj jest mniej więcej tak samo prawdopodobny, jak na Motoroli 68k 20 lat temu.

Nie widzę, jak z procedury przerwania można byłoby alokować pamięć bez ryzyka powalenia się wszystkiego - a co jeśli przerwanie wystąpi w środku wykonywania się - hipotetycznego jak dotąd - malloc()?

W systemie z multitaskingiem fragmentacja pamięci i tak będzie występować - bez dobrego MMU się tego nie uniknie. Natomiast w systemie bez multitaskingu mamy do czynienia z jednym programem aplikacyjnym, który po wyjściu z siebie pamięć zwalnia - a więc fragmentacja nie grozi.

Co do TSR-ów, to chyba nie ma aż tak wiele programów TSR, które z poziomu przerwania wołałyby funkcje systemu, CIO dajmy na to.

A ty, jak instalujesz sobie w Atari rozszerzenie RAM-u, to odpowiadasz najpierw na pytania, na co zamierzasz tę pamięć wykorzystać? Co za pytanie w ogóle.

No nie, rozumiesz to chyba zbyt dosłownie. Segment TEXT jest przeznaczony na kod (modyfikowany czy nie), segment DATA na dane preinicjowane, a segment BSS na dane nie preinicjowane. Ale jeśli masz życzenie, możesz dane umieszczać w segmencie TEXT, a kod w segmencie DATA (jedynie w segmencie BSS nie możesz niczego umieszczać oprócz pustego miejsca). Tak więc, jeśli chcesz mieć jeden segment na wszystko (segment TEXT) - to proszę bardzo, nie ma przeciwwskazań. Jednak chodzi o to, żeby, kiedy się to wyda potrzebne, mieć możność podziału programu na te części.

Przecież nikt ci nie zabrania korzystania z binariów Sparty X :)

Słucham? A gdzie tu problem? Przecież PO relokacji adresy są ustalone. Relokacja jest transparentna dla programu, on nic o niej nie wie. A poza tym relokacji podlegają jedynie adresy wewnętrzne programu (bo tylko to ma sens). Mógłbyś mi przybliżyć, gdzie tu widzisz problem?

Można i tak. Nie pamiętam w tej chwili detali formatu relokowalnego SDX, no ale on i tak nie ma tego, co chciałby Laoo: segmentów TEXT/DATA/BSS itd.

Na ładowanie do banków pamięci i tym podobne bajery zarezerwowałem flagi w nagłówku, ale na razie chcę sobie poradzić z normalną pamięcią.

O napisaniu nie Y.COM, ale wręcz nowego X.COM też myślałem i zamierzam to zrobić. Ale na razie dopracowuję program konwertujący binaria. Oczywiście nie widzę większego problemu, żeby był on w stanie wyprodukować również binaria Sparty X: pliki różnią się formatem, ale nie co do zasady.

W ten sposób można byłoby w końcu w miarę wygodnie je pisać, bez konieczności używania FA (salva reverentia auctoris, wolę MAE).

Format fixupów u mnie kompaktowy nie jest, ale za to jest najprostszy możliwy (z punktu widzenia loadera). Ale żeby się do tego nie ograniczać, dodałem na początku bloku fixupów kod ich formatu. W ten sposób - teoretycznie - program będzie mógł mieć taki format fixupów, jaki będzie wygodny.

Adres ładowania programu jest określany przez loader. Program kompilujesz pod adres jaki chcesz, a potem - z zachowaniem pewnej dość nieskomplikowanej procedury - przepuszczasz przez mkrel.com i już.