4,501

(49 odpowiedzi, napisanych Software, Gry - 8bit)

Analiza zwykłego kodu maszynowego i na tej podstawie relokacja nie wydaje mi się najlepszym rozwiązaniem. Daje stosunkowo ubogie możliwości w porównaniu do sytuacji, gdy asembler wie, że ma utworzyć kod relokowalny i sprawdza ew. konflikty oraz dostarcza dodatkowych możliwości programiście.

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.

Poza tym problem relokowalności wydaje mi się tylko jednym z elementów więszej całości jakim byłby pewnie system operacyjny,

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

który mógłby obsługiwać programy relokowalne, np. umożliwiał komunikację pomiędzy nimi. W tej chwili tylko SDX potrafi to zrobić (za pomocą symboli).

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.

Może lepiej więc byłoby się zastanowić PO CO chcemy nowy format i czy napiszemy nowego OSa (oczywiście wielozadaniowego), asemblera a wtedy zastanówmy się jaki format binarki.

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.

4,502

(49 odpowiedzi, napisanych Software, Gry - 8bit)

Nie mówię o pisaniu pod Spartę, tylko użycie formatu tego DOSa (a raczej koncepcji relokowania) także dla innych systemów. Wydaje się, że załatwia on w tej chwili większość problemów.

No ale ja nie mam ochoty używac formatu Sparty dla Sysinfo (bo wymagałoby to zmian w kodzie programu), a jeśli mam go - format Sparty - i tak modyfikować, to wolę coś takiego zdefiniować od nowa.

W końcu stary loader nowego formatu i tak nie będzie rozpoznawał, czy ten format będzie zupełnie nowy, czy będzie modyfikacja któregoś ze starych.

Ładujesz go do pamięci, a przy wyjściu mówisz systemowi, że część zajętą przez procedurę instalacyjną należy zwolnić.

Nie rozumiem, tzn. programista ma o to zadbać?

No pewnie, że programista. A pod SDX flagę INSTALL duch święty ustawia? :D

Zgadza się, tak się w tej chwili najczęściej robi, ale można też użyć obu relokowalnych, np. nie używając flagi INSTALL tylko ustawiając samemu MEMLO. Wtedy odpada problem szóstej strony, o którym piszesz.

Masz rację. Ale rozbudowa loadera tylko w tym celu to jednak overkill.

Laoo: podzielam Twoje wątpliwości.

Jakoś nie widzę, żeby Laoo miał jakieś wątpliwości - przynajmniej ze mną się nimi nie podzielił.

4,503

(49 odpowiedzi, napisanych Software, Gry - 8bit)

Draco, cały czas wydaje mi się, że próbujesz dostosować format do możliwości jakie daje MAE.

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.

4,504

(49 odpowiedzi, napisanych Software, Gry - 8bit)

esli blok TEXT (jeden za drugim) zostanie umieszczony pod $2000, a blok DATA pod $9000, dodatkowo 'vfname' zostanie zmodyfikowane bo jest typu .rw  to czy rozkazy w bloku TEXT odwolujace sie do 'vfname' tez zostana zmodyfikowane, powinny byc bo inaczej ten przyklad nie zadziala.

Akurat z tego punktu widzenia przykład Lizarda nie jest najszczęśliwszy. Co ma robić kompilator: kompilator ma skompilować wszystko tak, jakby było pod adres $0000 (lub ewentualnie $000000). Po czym ma wygenerować listę fixupów, czyli offsetów do słów i długich słów wewnątrz programu, do wartości których nalezy po załadowaniu pliku dodać adres ładowania.

Koniec, kropka.

Napisałem poprzednio, że relokacja ma być transparentna dla programu. Rozwinę to teraz: dla programisty też. Ciebie, jak programisty, nie obchodzi pod jaki adres system operacyjny załaduje program, który piszesz, oraz w jaki to sposób zrobi. Żadnych specjalnych dyrektyw w kodzie źródłowym, dzielących dane na "relokowalne" i "nierelokowalne" ma nie być.

Po prostu relokowalne jest wszystko (i tylko to) co jest zdefiniowane jako adresy wewnętrzne programu. Czyli:

fopen kod
    kod
    kod
    rts

...

    jsr fopen

deklaruje etykietę 'fopen' jako adres wewnętrzny, czyli tym samym argument jsr podlega relokacji. Ale:

cio = $e456
...
    jsr cio

deklaruje etykietę 'cio' jako adres absolutny, czyli tym samym argument jsr nie podlega relokacji (a w kodzie wynikowym asembler ma wstawić literalnie $20,$56,$e4 i nie generować fixupa).

Ale programista o tym ma nie myśleć.

Być może są jakieś przeszkody żeby tak zrobić, ale przeszkody są po to, żeby o nich dyskutować (i je usuwać ;-)).

4,505

(49 odpowiedzi, napisanych Software, Gry - 8bit)

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 :)

4,506

(49 odpowiedzi, napisanych Software, Gry - 8bit)

Myślałem że masz jakiś ciekawy pomysł, stąd te 16MB  :rolleyes:

Pomysł polega na tym, że skoro już mamy więcej niż 64k pamięci, oraz życzymy sobie (Laoo np.) żeby był możliwy podział pliku binarnego na segment TEXT, DATA, BSS itp., to żeby rozmiaru tych segmentów sztucznie nie ograniczać.

O ile mi wiadomo, Atari ST na przykład zostało zaprojektowane na 4 MB pamięci. Jednak format pliku binarnego DRI (ten od plików PRG) pozwala teoretycznie na zbudowanie pliku o wielkości do 4 GB. Czy ewentualne pytanie do projektanta tego formatu, na co zamierza wykorzystać te 4 GB, albo czy ma na to jakiś pomysł, uznałbyś za sensowne?

Segment TEXT jest przeznaczony na kod (modyfikowany czy nie)

Ale przecież czytam w artykule: "This doesn't allow self-modifying code in this segment."

Zgadza się, ale ani ten artykuł Biblia, ani gość jest wynalazcą podziału na TEXT/DATA/BSS.

Gościu co wymyślił ten format chciał aby można było współdzielić kod, dlatego zabrania się jego modyfikacji.

No a do tego wystarczy przecież flaga w nagłówku (jak w Atari ST pod MiNT-em: shared text bit). Modyfikacji kodu nie trzeba zabraniać. Poza tym shared text ma sens jedynie w systemie z multitaskingiem, a do tego jeszcze trochę nam zostało.

M.in. dlatego nie bardzo chciałem implementować format pisany w artykule, po tekście widać, że facet jest teoretykiem.

Zgadzam się z Lizardem, że podział na kod/dane/puste miejsce można zastosować na poziomie asemblera. W binarce na razie wystarczyłoby umieszczenie segmentów w oddzielnych blokach.

No ale przecież to właśnie przewiduje przewiduje projekt. Zauważ, że dyskutujemy o formacie pliku binarnego, a nie o tym, w jaki sposób ma go produkować kompilator. Lizard dał ci przykład użycia dyrektyw .text, .data i .bss tak jak to jest robione na innych komputerach, na przykład na Atari ST, żeby daleko nie szukać. Problem w tym, że MAE czy MAC/65 takich dyrektyw nie mają.

Powtarzam, mi chodzi o rozszerzenie rozwiązań ze Sparty, a nie o istnienie dwóch równoległych formatów.

No na SpartaDOS-ie świat się nie kończy.

Program nic o niej nie wie, ale inny program może będzie musiał wiedzieć. Przykład: procedury obsługi urządzenia (rezydentne). Jakiś inny program będzie musiał je zainstalować, np. wpisać adresy do HATABS. On nie musi być rezydentem. Dlatego poprawić należy dwa programy względem siebie. Nie wiem jak to załatwić w Twojej propozycji (chyba że scalić w jeden, ale wtedy niepotrzebnie zajmujemy pamięć).

Rozwiązuje się to w ten sposób, że TSR ma tylko segment TEXT, a procedurę instalacyjną na końcu. Ładujesz go do pamięci, a przy wyjściu mówisz systemowi, że część zajętą przez procedurę instalacyjną należy zwolnić.

W SDX natomiast masz dwa segmenty w jednym pliku, z tego jeden relokowalny, a drugi nie. Ten drugi ładujesz na stronę szóstą albo piątą i szóstą i on steruje instalowaniem. Tyle że dwóch stron może zabraknąć na installer, albo mogą być zajęte na coś innego - i co wtedy?

4,507

(49 odpowiedzi, napisanych Software, Gry - 8bit)

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.

4,508

(49 odpowiedzi, napisanych Software, Gry - 8bit)

No tak, rozmieszczenie segmentów jeden za drugim może świadczyc o krótkowzroczności twórców systemu, ale z innego punktu widzenia może świadczyć o dalekowzroczności: w końcu jeśli masz wirtuala i brak fragmentacji, to jest to dokładnie wszystko jedno, gdzie są segmenty. A skoro jest wszystko jedno, to najprościej je umieścić po kolei.

Oczywiście segmenty DATA i BSS można - o ile czegoś nie przeoczam - umieścić w dowolnym miejscu, definicja nagłówka tego nie wyklucza.

4,509

(49 odpowiedzi, napisanych Software, Gry - 8bit)

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.

4,510

(49 odpowiedzi, napisanych Software, Gry - 8bit)

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ć?

4,511

(49 odpowiedzi, napisanych Software, Gry - 8bit)

A swoją drogą na co zamierzasz przeznaczyć te zaalokowane megabajty? 8)

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.

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 ??

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.

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.

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

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

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?

4,512

(49 odpowiedzi, napisanych Software, Gry - 8bit)

BSS akurat jest. W Fast Assemblerze tworzysz go poprzez:

BLK EMPTY długość rodzaj_pamięci

O rozmiarze do 16 MB?

4,513

(49 odpowiedzi, napisanych Software, Gry - 8bit)

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

4,514

(49 odpowiedzi, napisanych Software, Gry - 8bit)

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?

4,515

(49 odpowiedzi, napisanych Software, Gry - 8bit)

Pierwsza sprawa: relokacja. Mysle, ze pomysl z wyrownaniem do granicy strony to raczej obejscie, a nie rozwiazanie problemu jakim mamy z mnogoscia trybow adresowania.

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

Dodatkowo nie doczytalem (przeoczylem?) jak relokator odroznia argument 2-bajtowy (np. wewnetrzne jsr) od 1-bajtowego (np. wspomniane lda #<costam).

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

Moje spostrzezenia sa zreszta oparte na tym artykule. Jest tam zawartych kilka (nie wszystkie) ciekawych spostrzezen.

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 ;)

4,516

(49 odpowiedzi, napisanych Software, Gry - 8bit)

> bit 8 - APAGE

Apage Satanas??? :?

He, he, exactly.

Dalej jedzie segment binarny o długości jak wykazano w słowie 0. Segment jest jeden i ciągły, bo chyba nie ma sensu robić wielu jak program i tak jest relokowalny.

Nie wiem, ale może nie nakładać takich ograniczeń?

No nie bardzo sobie wyobrażam, po co takie oddzielne segmenty kodu (tak samo jak w pliku $FFFF) miałyby być i co z nimi praktycznie robić. Jeśli i tak ładujemy na adres MEMLO i w okolice, to struktura pliku taka, że porcja tu, porcja tam traci sens.

Napisałem dzisiaj loader do tego, który powinien działać pod Spartą oraz DOS II+/D...

Trzebaby jeszcze dorzucić mimimum MyDOS, oraz jakiś loader typu ChaosLoader. Ja bym poprosił jeszcze XDosa. :)

Rzecz w tym, że loader jest w postaci programu o oryginalnej nazwie exec.com, który działa tak jak x.com Sparty X - czyli wymaga linii komend. SysInfo będzie miało oddzielny loader dla DOS-ów bez linii komend, ale ten loader będzie po prostu ładował na sztywno SI.REL z bieżącego katalogu ...

A XDosa w życiu nie widziałem na oczy. Wszystko zależy od Lizarda (ukłony) biblioteki getpar.mae, która obsługuje linię komend Sparty i DOS-a II+/D, a innych pewnie nie ...

Ma być nowy wspaniały świat. Atarki z procesorem 65c816, 4/8/16 MHz, 16 MB RAM-u, cuda wianki. Wymyśliłem, że do tego trzeba może trochę odświeżyć format pliku binarnego, bo $FFFF to zawsze była żenada, a teraz tym bardziej. W końcu jest XXI wiek  ;)

Kiedyś już taki format wymyśliłem, nawet wypuściłem w tym SI 2.06 czy coś takiego. Po latach stwierdzam, że to chyba dobry wynalazek, tym bardziej że jeszcze nad tym popracowałem. Założenia:

1) binaria mają być relokowalne;
2) ma nie być ograniczeń dla programisty, tj. taki plik powinien być zdolny do przechowania każdego możliwego rodzaju kodu na 6502;
3) ma pozwalać na ładowanie plików do rozszerzonej pamięci 65c816.

Format pliku:

bajty 0-3: sygnatura formatu, $52, $45, $4c, $31 (tekst: "REL1")
bajty 4-5: flagi

Flagi (znaczenie gdy = 1):

bit 0 - TSR - program ma jest rezydentem
bit 1 - RUN - uruchomić od offsetu RUNAD
bit 2 - INIT - uruchomić od offsetu INITAD
bit 3 - LWORD - wszystkie dalsze słowa nagłówka 24-bit (16-bit w przeciwnym razie)

bity 4-7: MEMFLG - zakodowany rodzaj pamięci, do którego program ma *najchętniej* być załadowany: 0 - podstawowa ($0000-$FFFF), 1 - rozszerzona ($010000-$FFFFFF), reszta wartości zarezerwowana.

bit 8 - APAGE (Align to PAGE ;-)) - adres ładowania wyrównać w górę do najbliższej wolnej granicy stron.
bit 9 - ABANK - adres ładowania wyrównać w górę do najbliższej wolnej granicy banków.
bity 10-15 - zarezerwowane for future extensions.

Dalszy wygląd nagłówka zależy od wartości bitu 3 we flagach, jak napisano wyżej. W każdym razie:

słowo 0 - długość bloku binarnego programu (nie licząc nagłówka i fixupów)
słowo 1 - długość bloku fixupów 16-bitowych (offsety z zakresu 0-65535), zero jeśli takowego bloku nie ma.
słowo 2 - długość bloku fixupów 24-bitowych (offsety większe od 65535), zero jeśli takowego nie ma
słowo 3 - na razie zarezerwowane
słowo 4 - RUNAD - offset (liczony od początku kodu programu), od którego program należy uruchomić; uruchomienie następuje skokiem JMP tylko wtedy, kiedy flaga RUN w nagłówku jest ustawiona. Rejestry CPU osmiobitowe przy tym myślę.
słowo 5 - INITAD - offset (liczony od początku kodu program), od którego program należy uruchomić; uruchomienie następuje skokiem JSR tylko wtedy, kiedy flaga INIT w nagłówku jest ustawiona. Program ma wrócić przez RTS oddając status zwykłą metodą (czyli LDY #$01 na przykład). Rejestry CPU jak wyżej.
bajt - długość następującego stringu (albo zero, kiedy go nie ma)
string - opcjonalna informacja tekstowa o długości do 254 znaków, zakończona zerem (czyli razem do 255 bajtów).

Dalej jedzie segment binarny o długości jak wykazano w słowie 0. Segment jest jeden i ciągły, bo chyba nie ma sensu robić wielu jak program i tak jest relokowalny.

Po nim fixupy. Fixup to są po prostu dwa bajty (albo trzy, patrz wyżej) offsetu wewnątrz pliku (licząc od początku kodu), gdzie jest adres absolutny odnoszący się do wnętrza programu; np. argument wewnętrznego skoku JSR. Do słowa znajdującego się w miejscu wskazanym przez fixupa dodajemy adres ładowania programu (czyli np. wartość MEMLO).

Teraz: wiadomo, że adresy w Atari są w kolejności młodszy/starszy; fixup wskazuje oczywiście bajt młodszy, loader ma po uzupełnieniu go sam zwiększyć offset o 1 i fiksnąć też bajt starszy.

Ale, w takim układzie oczywiście nie przejdzie konstrukcja następująca, chyba wszyscy wiedzą czemu:

    lda #<label+1
    ldx #>label+1
...
label   .by "tu cośtam",0    

Do załatwienia tego służy flaga APAGE w nagłówku: program jest ładowany zawsze od początku granicy stron, co oznacza, że młodsze bajty wszystkich adresów pozostają zawsze niezmienne, i że przy fixupowaniu trzeba zmieniać tylko bajty starsze. W takim układzie fixupy pokazują właśnie na nie i loader po ich uzupełnieniu nie ma już niczego kombinować.

Napisałem dzisiaj loader do tego, który powinien działać pod Spartą oraz DOS II+/D, a poza tym program, który przerabia binaria wypuszczone przez np. MAE na ten nowy format, pozwala na ustawianie wszystkich flag z linii komend itede.

W formacie tym będzie SysInfo 2.08, to jest jedyna metoda, żeby program pozwalał sobie załadować tapetę, kiedy jest wystarczająco dużo pamięci, oraz żeby dalej działał, kiedy nie jest.

Uwagi?

4,518

(75 odpowiedzi, napisanych Software, Gry - 8bit)

Ponadto z bloku PERCOM możńa użyć bajtu nr. 8, który w/g dokumentacji zawsze równy jest $FF i nie jest do niczego używany. Normalnie jest tu trochę informacji używa tego napewno KARIN MAXI. Natomiast po wartości $01 w bajcie $00 bloku PERCOM nie tylko formater SpartaDOS rozpoznaje dyski twarde - ale np. nieśmiertelny SysInfo

Bajt nr 8 coś tam znaczy albo kiedyś znaczył. W każdym razie jak słusznie zauważasz w większości wypadków ma wartość $FF - jeśli przypiszesz mu najstarszy bajt wielkości partycji, to skąd będziesz wiedział, czy to $FF nic nie znaczy?

Bajt 0 z kolei jest to liczba ścieżek dysku, nie? A więc jest to mnożnik liczby sektorów. Teraz przy twardym dysku mamy tam 1 i partycja ma max. 8 GB. Ale jakby dac 2, to by się zrobiło 16 GB i tak dalej. Myślę, że wartości z zakresu od 1 do 34 są do spokojnego wykorzystania (kiedyś były 35-ścieżkowe stacje).

Formatterem SpartaDOS nie ma się co przejmować, i tak nie sformatuje niczego powyżej 16 MB.

A co do nieśmiertelnego SysInfo to to żaden problem: przecież jestem jego autorem  :)

4,519

(123 odpowiedzi, napisanych Software, Gry - 8bit)

Pomysł mam ten sam co zawsze: karta VGA. Przydałoby się mieć co najmniej pełne 64k "okienka" do pamięci obrazu.

4,520

(123 odpowiedzi, napisanych Software, Gry - 8bit)

Twoja procedura zakłada po prostu, że banki się mirrorują (tak jak mogą się mirrorować banki pamięci 16k w normalnych rozszerzeniach). Wtedy zapamiętywanie, zaznaczanie itd. jest konieczne. Procedura bardzo podobna do twojej jest w SI używana do testowania rozmiaru pamięci bankowanej w $4000-$7FFF.

Natomiast w przypadku pamięci liniowej, jeśli w pewnym momencie RAM się kończy i następuje ROM albo pustka, to wystarczy taka procedura, jak moja - która sprawdza, czy pod danym adresem pamięć jest zapisywalna.

Jak już jest 16 MB przestrzeni adresowej, to może by tak, wzorem Motoroli 68k, przeznaczyć jakiś kawałek pod koniec na nowe urządzenia I/O? Np. ostatnie 64k (albo ostatnie 2 MB).

4,521

(123 odpowiedzi, napisanych Software, Gry - 8bit)

To dlatego mam do tego karzełka taki awers, bo to amerykańskie. ;)

Już po nim.

Sądzisz, że nasz orzełek lepiej będzie się kompresował?

Hehe, kto wie. Będziesz mógł sam sprawdzić :>

4,522

(123 odpowiedzi, napisanych Software, Gry - 8bit)

PS. Jak Ci sie chce, mozemy zastanowic sie, co jest nie tak. Moja procka na wykrywanie liniowej pamieci jest taka (kod dla cross-assemblerka ACME):

SysInfo natomiast zawiera taką procedurę (kod MAE):

ngflag = $00

    .or $80

zramsz .ds 3
zmtop  .ds 1

    .or $0600  ; na przykład ;-)

    lda ngflag
    pha
    stz ngflag
    stz zmtop
    stz zramsz
    stz zramsz+1
    stz zramsz+2
loop
    inc zramsz+2
    lda [zramsz]
    eor #$ff
    sta [zramsz]
    cmp [zramsz]
    bne exit
    bit ngflag
    bmi exit
    eor #$ff
    sta [zramsz]
    inc zmtop
    bra loop
exit
    pla
    sta ngflag
    rts

Procedurkę wywołujemy w trybie ośmiobitowym (B = 0, K= 0, D=0). Zmienna 'zmtop' powinna na wyjściu zawierać liczbę dodatkowych banków 64k ponad standard.

Ponieważ nie mogę ci wysłać SysInfo, poprzestanę przeto na prośbie, byś mi przetestował na twoim sprzęcie powyższą procedurkę i podał wyniki. Dzięki.

4,523

(123 odpowiedzi, napisanych Software, Gry - 8bit)

Dely daj mi bana a w życiu nowej wersji SI nie obejrzysz :D . Do waszej wiadomości, pracusie: w przerwach pomiędzy odbieraniem poczty piszę SysInfo 2.08. Poprawiłem błędy, o których tu była mowa, obejrzałem raz "Out of memory" przy próbie załadowania nowej wersji, a potem cyrklowałem tak, żeby się jednak zmieściło. Teraz zaś kombinuję co tu zrobić z tym obrazkiem.

Zdaje się, że pomysł Lizarda (który wcale nie pisze dziś cały dzionek żadnych postów, zamiast pracować :D), coby zastąpić obrazek wzorkiem nie jest najlepszy: wzorek nie skompresuje się (tym algorytmem) dużo lepiej. Może orzełka (który jest skądinąd głową godła USA, o ile się nie mylę) zastąpić godłem państwowym?  :lol:

4,524

(123 odpowiedzi, napisanych Software, Gry - 8bit)

Mógłbyś wywalić obrazek i zastąpić go jakimś powatarzającym się mniejszym wzorkiem. Albo doładować obrazek z pliku, gdy starczy nań pamięci. Wtedy każdy mógłby ustawić swoją ulubioną tapetę. :mrgreen:

Może od razu przerobię SI na desktop  :o

4,525

(123 odpowiedzi, napisanych Software, Gry - 8bit)

Jest jeszcze jedna opcja: lepiej skompresować obrazek. Obecnie zajmuje on niecałe 6,5 KB.