No ja też swoją kompilowałem parę dni temu.

Nb. te same jaja dzieją się przy rozpoczynaniu nowego wątku. Czy możesz jakoś spojrzeć od swojej strony, co się działo przy wysyłaniu przez mnie postu o problemach z Falconem (Forum sprzęt 16/32 bit)?

No nie mam pojęcia, dlaczego się tak kaszani. W każdym razie ze starym skryptem jakoś mi współpracowało.

Dely, a którą wersję Firefoxa masz? Bo ja 1.0 prrrrrr....

Oki, oki. Na razie skasowałem stare cookies, zobaczymy, co sie będzie działo teraz.

Ok, z tym nie na temat, to masz pan rację, tak jakoś wyszło.

A dlaczego do wczoraj/przedwczoraj wszystko działało jak należy?

Zczytujesz PERCOM-y wszystkich napędów i patrzysz na miejsca, które wymienił Caspar ("IDE" w 3 ostatnich bajtach, flagi gęstości itd.). Potem dla wszystkich znalezionych partycji dajesz komendę $EC żeby dowiedzieć się szczegółów.

"Wszystkie napędy" to wartości od 1 do 16 w DUNIT. Niestety, SpartaDOS 3.x (czyli Sparta dyskowa) zawiesza się, kiedy się próbuje gadać z napędami o numerach powyżej 8, oczywiście dotyczy to tylko używania SIO Sparty a nie systemowego. No ale warto to wiedzieć na wszelki wypadek :-)

Myślę, że młodszą najpierw.

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.