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 jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Altirra 4.50 test 19 Phaeron opublikował nową wersję testową emulatora Altirra z licznymi poprawkami m.in. dla VBXE.
NeoST 0.6.1 Nowa wersja emulatora NeoST z ulepszeniami emulacji układów Atari ST, MIDI oraz obsługą sieci.
Atari na Xenium 2026 Podsumowanie atarowskich produkcji zaprezentowanych podczas tegorocznej edycji imprezy Xenium.
Steem SSE 4.2.1 R1 Ukazała się aktualizacja popularnego emulatora Atari ST/STE z usprawnioną obsługą obrazów STX.
Zelda: Return of the Hylian na Atari ST Krzysztof Jarzyna informuje o pracach nad portem znanej gry z serii Zelda na komputery Atari STE.
atari.area forum » Posty przez drac030
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ć?
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?
BSS akurat jest. W Fast Assemblerze tworzysz go poprzez:
BLK EMPTY długość rodzaj_pamięci
O rozmiarze do 16 MB?
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ż.
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?
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 ;)
> 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?
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 :)
Pomysł mam ten sam co zawsze: karta VGA. Przydałoby się mieć co najmniej pełne 64k "okienka" do pamięci obrazu.
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).
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ć :>
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
rtsProcedurkę 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.
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:
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
Jest jeszcze jedna opcja: lepiej skompresować obrazek. Obecnie zajmuje on niecałe 6,5 KB.
Oprócz wykrywania ROM Simulatora przydałaby się detekcja ROM Changera - szczegóły techniczne u Pasia... :D
Ten program (SI) i tak się z trudem mieści w pamięci. Mogę dołożyc jeszcze niejedno, ale wtedy SI będzie działać tylko ze SpartaDOS X (MEMLO < $2000).
Ok, to dobrze. Chodziło mi o to, czy się jakieś banki nie powtarzają.
A w nieprzetaktowanym co tam jest? Nic, czyli tak jak na stronach $D6-$D7 pamięci podstawowej?
Dobrze. Błąd w Sysinfo przede wszystkim polega na tym, że test pamięci jest robiony przez testem CPU. Czyli flaga oznaczająca że mamy 65c816 jest w chwili testowania RAM-u zawsze wyzerowana. Czyli program w ogóle pomija testowanie RAM-u linearnego. Dawno nie widziałem takiego ładnego baga 8)
Rozumiem. Czyli razem 2 MB. Jeszcze jedno pytanie: jeśli masz 1 MB pamięci liniowej, to co jest potem? Tj. jakie efekty dają odczyty/zapisy w obszarze $100000-$FFFFFF?
Po sciagnieciu SI 2.07 z zapalem zabralem sie do testowanie i... u mnie zonk :cry:
Spróbuj w opcjach włączyć "16-bit mode" i spróbuj jeszcze raz.
PS. Memory usage summary pokazuje wszystko dobrze: to są odczyty ze zmiennych systemowych, a odpowiednie zmienne są zdefiniowane tylko w tym moim niedokończonym ROM-ie.
No cóż, program do poprawki. W System summary jest napisane, że masz 1 MB pamięci w bankach. Masz tyle?
Problem kabelka - mam to na dysku na Atari, i nie mam jak przenieść do netu. Ale wersję 2.07 z całą pewnością ma Lizard ... ;-)
atari.area forum » Posty przez drac030
Wygenerowano w 0.133 sekund, wykonano 14 zapytań