Boje sie troche zabierac glos po proznicy, bo zdaje sobie sprawe, ze dokladnie sobie ten format przemyslales i nie wiem, czy moja krytyka moze miec jakakolwiek konstruktywna wartosc, ale uwazam, ze troche mu brakuje do "wymarzonego" formatu. Pierwsza sprawa: relokacja. Mysle, ze pomysl z wyrownaniem do granicy strony to raczej obejscie, a nie rozwiazanie problemu jakim mamy z mnogoscia trybow adresowania. Dodatkowo nie doczytalem (przeoczylem?) jak relokator odroznia argument 2-bajtowy (np. wewnetrzne jsr) od 1-bajtowego (np. wspomniane lda #<costam). Druga sprawa jaka jak narazie zauwazylem, to obecnosc tylko jednego bloku binarnego programu. Jak na XXI wiek to nie jest zbyt rewolucyjne rozwiazanie. Juz od niepametnych czasow na maszynach 16/32 bit obecnosc wielu relokowalnych segmentow jest standardem i wg. mnie wielkim ulatwieniem pracy. Pisze to badzo subiektywnie, gdyz zaczynam uzywac asemblera ca65 z wieloma segmentami i dla mnie to dosc naturalne. Moje spostrzezenia sa zreszta oparte na tym artykule. Jest tam zawartych kilka (nie wszystkie) ciekawych spostrzezen.

Można oczywiście dawać oddzielne fixupy na młodszy i starszy bajt, ale w takim układzie blok fixupów robi się dwakroć dłuższy. Nie wiem, czy gra jest warta świeczki. Traci się w ten sposób do 255 bajtów pamięci, ale zyskuje na długości pliku, czasie ładowania, wielkości loadera (to jest zaniedbywalne dopiero kiedy loader mamy zintegrowany z systemem).

Po fladze APAGE. Kiedy jest wyzerowana, wszystkie adresy muszą mieć postać ciągłą (lo-hi jedno za drugim).

Owszem, ciekawy artykuł. Jednak nie jestem pewien, czy ten format nie jest "za dokładnie" przemyślany. Po co na przykład adresy oryginalnej kompilacji segmentu TEXT i DATA w nagłówku? Albo flaga rodzaju CPU - czy DOS ma odmawiać ładowania pliku z flagą 65c816 jeśli mamy 6502? A co z programami, które chodzą na obydwu?

Część rzeczy z artykułu mój format implementuje, są to: info o autorze (patrz opcjonalny tekst w nagłówku), możliwość rozszerzenia formatu na większą długość słowa (tam 32 bity, u mnie 24 - mogę zmienić, jeśli to ma sens), "split addresses" i to chyba dokładnie tak samo jak u mnie (wyrównanie do strony), możliwość pełnej relokacji (co do bajtu).

Co do segmentów, pisząc o tym miałem na myśli segmenty kodu takie, jakie są w pliku $FFFF. Jeśli idzie o podział na segmenty TEXT/DATA/BSS (jak w ST np.), oraz proponowane w artykule STACK, ZERO i REF, to czemu nie, mogę zaimplementować. Tylko z takim nagłówkiem dość trudno będzie wypuścić w tym formacie demo 256 bajtów  :lol:

Myślę, że zaletą pierwszorzędną - na razie - będzie to, że pliki relokowalne będzie można tworzyć nie rezygnując ze swojego ulubionego asemblera. Jak mówię, stworzyłem program (działający z linii komend) który przetwarza pliki binarne np. MAE na nowy format. Na razie bardzo beta, ale się rozwija ;)

Bo format Sparty X, o ile mi wiadomo, ma ograniczenie odnośnie dzielonych adresów, na przykład. Poza tym jakaż to "część kodu" jest gotowa w tym przypadku?

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ż.

Lizard, kurde felek, znowy masz rację?! Jesteś gorszy ode mnie! (Tkacz potwierdzi).

A o to, że Tkacz się zawsze skarżył, że we wszystkich dyskusjach to ja mam rację. Tylko, bałwan jeden, nigdy mnie nie słucha.

(Tak naprawdę, na manie racji jest bardzo prosty algorytm, ale go nie zdradzę.)

Nie wiem, czy lepszy, bo jeszcze nie było chyba kolizji między Twoim a moim algorytmem. I - jeśli są opracowane na podobnym założeniu - nie będzie.

Nie, w  tej chwili oczywiście max. 64kB, ale przecież można to rozbudować, dodając jeden bit (w tej chwili nieużywany przez Spartę) i podawać większe rozmiary. A swoją drogą na co zamierzasz przeznaczyć te zaalokowane megabajty? 8)

Według mnie segmenty opisane w artykule są trochę na wyrost. Dopóki ktoś nie napisze systemu wielozadaniowego do Atarki to będą używane niezgodnie z przeznaczeniem.
Bo np. segment TEXT ma mieścić kod niemodyfikowany. Tymczasem przecież często wykorzystuje się samomodyfikowację w programach. To oznacza że taki kod trzeba byłoby umieszczać w segmencie DATA ??
Bardziej jednak podoba mi się podejście jakie jest w Sparcie: łączenie kodu relokowalnego i zwykłego, rezerwacja pamięci dają duże możliwości.

Trzeba też pamiętać, że często istnieje konieczność aktualizacji adresów znajdujących się poza kodem relokowalnym. Np. przy definiowaniu nowego urządzenia w tablicy handlerów OSa lub w innych stałych miejscach trzeba umieścić adresy PO relokacji kodu. Sparta załatwia bez problemu tę sprawę.

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?

Przecież jak segmenty będą ładowane jeden po drugim, to tym samym będą ładowane w różne miejsca pamięci, nie wiem o co panu chozi :D

Jak proponujesz te "różne miejsca" zdefiniować?

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.