Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Wyniki 24h Compo: System Error Poznaliśmy zwycięzców 24h Compo: System Error.
Gearlynx 1.2.1 Gearlynx to wieloplatformowy emulator konsoli Atari Lynx, który właśnie doczekał się ważnych poprawek.
II. Baskijski Turniej Atari 8-bit Relacja z drugiej edycji retro zawodów Atari 8-bit zorganizowanych przez Euskal Retro w Bilbao.
Fujisan 1.1.7 Najnowsze wydanie Fujisan przynosi poprawki dla FujiNet oraz nowe funkcje sterowania emulacją.
Charsetter - nowe narzędzie Poznaj Charsetter, wszechstronny edytor fontów i map dla 8-bitowego Atari dostępny w przeglądarce.
Opcje wyszukiwania (Strona 71 z 81)
Z tego twierdzi Drac030, to Piotrek Karkuciński pamięta, gdzie należy udać się w najbliższy poniedziałek. Proponuję Umówić się gdzieś w centrum (najłatwiej tam się będzie każdemu dostać) powiedzmy o 16 i udać się zorganizowaną grupą z w/w osobnikiem na czele.
PureC rządzi najlepszy help system na świecie, ale ten edytor to mnie delikatnie wkurza. (ale tak delikatnie tylko ;) ). Widziałem jakieś alternatywne edytory do PureC (z kolorowaniem składni etc.), ale za bardzo stabilne to one nie są.
Ja używałem qed do pisania programów, potem otwierałem je w edytorze PureC i stamtąd kompilowałem. Jest jeszcze jeden dobry sposób: z linii poleceń odpalić kompilator z odpowiednioustawionymi opcjami.
4MB to akurat starczy na kompilacje printf("hello world"): ;)
ROTFL.
Moje OFMC Atari 65XE :D :D :D
Już nie przesadzaj. Kiedys w 1999 roku kumpel zobaczył to to na Atari i był zachwycony, że ładniej wygląda niż taki Borland C++ pod DOS-a i szybciej komplikuje na ST niż BC++ na 486. I maił chłopak rację. :D
Pure C jest nalepszym na ST kompilator. Zgodnie z jego nazwą jest to C, nie C++. Zgodny z Borland C.
.http://www.reservoir-gods.com/CODE/PURE_C.ZIP
A ja poczekam 10 do 15 lat i na allegro kupię za grosze :D
Albo za cenę niezłej bryki. Zauważ, że sprzętu ośmiobitowego jest coraz mniej, a powoli ludzie zaczynają na niego patrzeć jak na stare samochody. Entuzjaści i kolekcjoneży będą płacić każdą cenę, a to spowoduje jej wzrost.
Mac, to sie da zalatwic. Medycyna plastyczna robi teraz cuda
Fajnie ale ta medycyna za darmo nie jest, a w kasie chorych chyba nie znajdzie zrozumienia. Chyba już taniej jest kase zbierać na sprzęt a nie na plastic operation (play - stick operation).
Poczekaj jeszcze trochę. Aborcja ma być gratis, to operacje plastyczne też niedługo będą. ;)
a ten intel o ktorym kolego mowisz to w ogole byl niezle pojechany.
Oj, był. Dema puszczane z VHS sux.
dzwonic do Ciebie to chcialem z urzedu podatkowego (czy co to tam kolo tej stodoly jest, a wlasciwie to kolo tej kladki ktora schodzisz z pol mokotowskich)
To Urząd Patentowy. A miałeś w ogóle wtedy mój nr telefonu?
"chlopcze ... blokujesz plasik"
r0l0 :D
hehhe ... wtedy to panie dziejku byly imprezy, nie to co teraz ... LOL
Teraz też są fajne, ale Fox wyjechał i sąsiadka jkoś cicho siedzi. ;)
Efekt dealu znajduje się na: .http://www.republika.pl/lzd/panopticum.rar (702kB)
He he, pamięć wirtualna na 65816? Chyba wystąpił ci segmentation fault. ;)
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.
E tam. Czepiasz sie, to był tylko przykład, pierwszy z brzegu pomysł jaki mi przyszedł do głowy. Nie dyskutujemy tu o mallocach na poziomie przerwań, tylko o segmentach programu. Zauważ, że gdy dawno temu narzekałem, że w ST bloki ładują się jetden po drugim zamiast w najbardziej pasujące miejsce, przyznałeś mi rację. To był efekt tego, że twórcom TOS-a nie przyszło do głowy, że na Atari ST może pojawić sie multitasking. Ja dmucham na zimne, stąd moje wywody.
Taka sytuację:
Mamy rezydenta działającego na przerwaniach, który alokuje sobie w pewnym momencie trochę pamięci. My w tym czasie ładujemy program, ale rezydent zwalnia w tym czasie przydzielony obszar powiedzmy w momencie obróbki bloku TEXT (relokacja, aktualizacja adresów, itp.) System przystępuje teraz do ładowania bloku DATA, który jest na tyle mały by mógł zostać załadowany w to miejsce, które przed chwilą zwolnił TSR. Jeśli blok DATA zostanie załadowany właśnie w to miejsce, to układ będzie taki: ˇ TSR
ˇ DATA naszego programu
ˇ ewentualnie nie wykorzystana pamięć (resztaka po malloc by TSR)
ˇ TEXT naszego programu
Jeśli natomiast system załaduje DATA bezpośrednio za TEXT, to otrzymamy: ˇ TSR
ˇ dziura po malloc by TSR
ˇ TEXT naszego programu
ˇ DATA naszego programu
Jeśli w programie wystąpi malloc, to może okazać się, że zabraknie na jego wykonanie kilku bajtów, które mogłyby zostać przydzielone, gdyby DATA siedział w obszarze zwolnionym przez TSR-a.
Czy dobrze rozumiem słowo "uzda"??? :oops:
Sądząc po Twoich wypiekach, to chyba dobrze rozumiesz. ;)
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.
O tymwłaśnie pisałem. Wiem po co wymyślono rozdział na kod, dane pre i dane niepre. ;)
Ale dobrze by było, by segmenty mogły być ładowane w różne miejsca pamięci, nie jeden po drugim. Takie podejście choć częściowo zapobiegałoby fragmentacji pamięci (zwłaszcza, gdybyś dorobili sie jakiejś OSy wielozadaniowej).
No to co nam wciskasz kit o jakiś future wersjach, skoro i tak cała kasę przeznaczasz na OC/AC. ;)
Podział programu na segmenty TEXT i DATA jest dla mnie raczej umowny. Nikt i nic nie może mi zabronić umieszczeniu danych w segmencie kodu ani kodu w segmencie danych (i odwoływać się do niego przez zwykłe JSR lub JMP). Segmenty są raczej pomocne dla asemblera, który mając kilka deklaracji TEXT czy DATA może je scalać w pojedynczy ciągły blok. Przykład:
.text
lda vfname
ldx vfname+1
jsr fopen
.data
vfname .rw fname ; relocatable word ;)
fname .by "D:nazwa.ext"
.text
fopen sta $0314
stx $0315
...
Aembler powyższy przykład powinien obrobić tak, żeby dwa segmenty TEXT następowały po sobie a na końcu DATA.
Co innego BSS. Tu jak powszechnie wiadomo (albo i nie) chodzi o zarezerwowanie pamięci, ale nie zmienianie jej, ani nie ładowanie doń czegokolwiek.
Pewnie Realtime Pacman in Virtual Drinkality ;)
Którzy przez to sami nie jadą, bo nie mają się u kogo zapożyczyć. Koderzy niestety wszystko wydali na Snickersy. ;)
A tak, pamiętam jak kiedyś Tkacz skarżył sie o to. Twój algorytm nie jest mi potrzebny, bo jak widzisz mam własny i skuteczniejszy od Twojego. ;)
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.
BSS akurat jest. W Fast Assemblerze tworzysz go poprzez:
BLK EMPTY długość rodzaj_pamięci
No to skoro jesteś za, to nie marudź. ;)
Gdy zgłosiłem się długo po sciepie na APE 2.x, Vasco nawet się nie zająknął, że był czas na kwestę.
Uderzylismy jeszcze do Maca i wrzucilismy po wiesmaku a potem na chawire:))))
Nie no. 4 wieśniaki to za dużo - tyle z tego zrozumiałem. Ale chciałbym zobaczyć tę w fajnych szmatach, że widać majtki z uzdą. 8)
... rozszerzający oryginalny sprzęt.
Po co ci gwizdek na plaży :?: Ze smoczkiem zawsze do twarzy.
Znalezione posty [ 1,751 do 1,775 z 2,009 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.069 sekund, wykonano 19 zapytań