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
Współtwórz atari.area i prześlij newsa! Masz ciekawe znalezisko lub informację ze świata Atari? Możesz samodzielnie dodać newsa!
Gopher2600 v0.54.0 Najnowsza wersja emulatora Atari 2600 przynosi tryb headless oraz poprawki błędów.
Gearlynx 1.2.4 Ukazała się aktualizacja Gearlynx, emulatora konsoli Atari Lynx, z poprawionym debuggerem.
FujiNetChat: Nowy klient IRC dla Atari Pierwsza publiczna wersja alfa FujiNetChat, nowoczesnego klienta IRC wykorzystującego interfejs FujiNet.
Gearlynx 1.2.2 Gearlynx doczekał się aktualizacji. Wprowadzono podgląd SCB, wyszukiwanie w pamięci oraz poprawki.
Opcje wyszukiwania (Strona 57 z 122)
Dane modułu .SID ładowane są w obszar MEMLO+zrelokowany kod programu..$CFFF i $D800..$FFBF. W konfiguracji OSRAM obszar ten pomniejsza się o rozmiar kodu sterownika SDFS i bufory SDX (nie pamiętam teraz ile dokładnie tego jest i gdzie leżą).
Następnie zależnie od obszaru docelowego w którym powinien się znaleźć moduł określane są obszary pamięci do zachowania na później tak, aby zwolnić pamięć z której korzysta moduł .SID.
Są dwie strategie - domyślna i awaryjna.
Domyślna stara się zachować obszary z systemem i odtworzyć je po wyjściu z playera.
Awaryjna stosowana jest wtedy gdy nie da się zachować elementów systemu tak, aby je potem odtworzyć i wrócić bezawaryjnie do DOS-a. Wtedy wyjście z playera kończy się powrotem do SELF-TEST-u.
Tryb awaryjny stosowany jest tylko gdy użytkownik na to pozwoli przez włączenie przełącznika w linii poleceń lub zmiennej środowiskowej.
Kiedy dysponuję odpowiednią ilością XRAM programy systemu zachowywane są w XRAM i tryb awaryjny nie ma zastosowania.
Trudno mi podać konkretne wartości, bo zależą od załadowanych sterowników, ilości XRAM i konfiguracji systemu.
Edit: Ale robi się chyba niepotrzebny offtop. Ciekawiło mnie po prostu gdzie leży problem z wymaganiami SDX odnośnie uruchomienia playera SID, no bo starałem się żeby player potrafił poprawnie zadziałać na standardowym Atari XL/XE.
Konfiguracja może być dowolna. Program rozpoznaje gdzie ma wolne i przepisuje obszary pamięci robiąc miejsce dla modułu .SID, a przed wyjściem je przywraca.
Jeśli jest dotępny XRAM oczywiście go wykorzystuje.
Edit: Gdzie w takim razie tkwi problem?
xxl napisał/a:przypomnij sobie ile potrzeba pamieci dla plajera sidow dla sdx a ile dla xB
Zawsze mi się wydawało, że projektowałem swój player tak, żeby działał na 62KB. Ale może się jednak mylę.
Ale tam są przynajmniej frankfurterki.
Tak. Państwo było właścicielem :)
"Pax, pax między Chrześcijany" :D
Adam Kłobukowski napisał/a:Sam to deszcz pada. Jak masz dobry wynalazek, bez problemu znajdziesz inwestora który wyłoży kasę. Tak, w Polsce.
No tak. Nie zdziw się, że za swój pomysł dostaniesz potem 5% co najwyżej. Resztę weźmie kapitał, który przecież nie ma narodowości. No bo przecież to on dysponuje kapitałem, a ty "tylko" pomysłem, nie masz doświadczenia, nie znasz się na "finansowości" - uzasadnień jest mnóstwo. Tylko, że ten sam kapitał bez narodowości trąbi na okrągło o pomysłach i kreatywności, bo jednak o ironio - sam kapitał jakoś nie bardzo chce się pomnażać :/
A którego znaku nie można stosować?
Ale czy możesz legalnie taką nazwę utworzyć?
Atari DOS-y i kompatybilne pozwalają na użycie parapeta (_), dużych liter i cyfr (na pierwszej pozycji musi być litera).
W Sparta DOS na pierwszej pozycji może być cyfra.
W MyDOS możesz mieć jeszcze '@'.
Loadery nie sprawdzają nazw więc tam może być cokolwiek - directory jest tylko dla usera, bo one i tak bazują na nrze pliku, który wybrałeś do ładowania.
Co do xBIOS-a musi się wypowiedzieć XXL.
Edit: Poprawka.
Nie. GITS nie można oglądać z dubbingiem. Ścieżka dźwiękowa i dialogi mają być oryginalne - melodia tego języka to połowa przyjemności z oglądania.
No zobaczymy co to będzie jesienią.
@skrzyp: Trzeba było przeprowadzić licytację. Towar deficytowy na który jest popyt zyskuje na wartości :)
Do prawie każdego narzędzia w SDX masz instrukcję użytkowania dostępną za pomocą MAN (tzw. manual) w języku angielskim (czasem trzeba sobie go przy instalacji rozpakować z ARC-a i skopiować do katalogu z manualami). Są to zwykłe pliki tekstowe, więc można sobie je przetłumaczyć i wrzucić gdzieś do katalogu, po czym dodać do zmiennej środowiskowej MANPATH tę ścieżkę - wtedy polecenie MAN będzie szukać manuala w ścieżkach zdefiniowanych właśnie tam.
Manuale do poleceń systemowych znajdują się na CAR: (w większych kartridżach).
Poza tym, jak skrzyp napisał, dostępny jest aktualny podręcznik na stronie projektu, w którym masz np. informacje jak używać funkcji systemu z BASIC-a. No i podręcznik programisty (głównie ASM), ponieważ SDX udostępnia szereg mechanizmów nie znanych w innych DOS-ach na Atari (i nie - nie jest to tylko SpartaFS jak by się na pierwszy rzut oka mogło wydawać, przez co często nie da się przenieść programu napisanego dla SDX pod Sparta3.2, BW-DOS, RealDOS czy inne używające SpartaFS). SDX to nie jest tylko inny system plików.
W Atariki jest też kilka stron dotyczących programowania różnych rzeczy pod SDX.
Ja też podtrzymuję chęć zakupu ustrojstwa.
O. Wielkie dzięki. Włączone były wyniki prywatne. Co za świat.
Dzięki Panowie.
@epi: Na szczęście Twoja wyszukiwarka działa widać lepiej, bo moja to mi wstawiała tylko jakieś dema i za cholerę nie chciała się dać przekonać do czegoś sensownego. Dywersanci cholera jasna. Profilowanie kont użytkowników k**** ich mać. Dwóch dowolnych użytkowników nie dostanie takich samych wyników wyszukiwania.
@sachy: Niestety nie wyrwę się, a chciałem mieć blade pojęcie co to :)
sachy napisał/a:K65 - nowy język programowania procesorów 65xx.
Można się o tym coś więcej dowiedzieć?
O to demo jest nawet na Atari 2600: https://www.youtube.com/watch?v=Ko9ZA50X71s :) Szkoda, że nie ma na XL :/
No, a Ty już ich zdążyłeś odsądzić od czci i wiary :)
To pewnie robią zlecenie od Duddiego, zamiast od Yerza :)
Co tam 300 - 1000%. Ostatnio widziałem ZX128 za 2kPLN.
Pytanie nieco na boku:
Co z emulacją/kompilacją kodu samomodyfikującego się?
O ile rozumiem sensowność zastosowania JIT w przypadku Javy, bo tam nie ma opcji, żeby programowo zmienić kod programu, to jak sobie z tym poradzono w przypadku kodu natywnego, który może przecież sam siebie modyfikować? Co z tą kompilacją w locie wtedy? Nie wywali się toto przypadkiem?
PMCNTL/GRACTL ($D01D) jest o tyle niefajny, że steruje włączeniem sprajtów a on nie ma cienia.
Z CONSOL'em faktycznie jest problem wskazany przez XXLa.
HITCLR ($D10E) służy do kasowania kolizji sprajtów.
Może GTIACTL/GPRIOR ($D01B)? Ten ma z kolei cień przepisywany na VBLK więc można by zapisać cień w dowolnej chwili, a i tak uaktualniony byłby na VBLK.
A może wykorzystać jakiś rejestr na $D0xx ale poza standardowym obszarem GTIA (jak to robi np. VBXE)?
Chyba mniej kolizyjny byłby CONSOL. A czy nie można by umieścić obydwu bitów w CONSOL.7?
Ja również reflektowałbym na takie urządzenie montowane do środka komputera. A gdzie jest ten magiczny reyestr?
Znalezione posty [ 1,401 do 1,425 z 3,030 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.098 sekund, wykonano 20 zapytań