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
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.
Wyniki FujiCup 2025 Poznaliśmy najlepsze gry na 8-bitowe Atari wydane w 2025 roku według jury oraz publiczności.
Wyniki konkursu i gala FujiCup 2025 Poznaj zwycięzców dorocznego turnieju FujiCup 2025 wspierającego twórców gier na Atari XL/XE.
Fujisan 1.1.8 Nowa wersja emulatora Fujisan przynosi wsparcie dla FastBasic oraz poprawki błędów w obsłudze dźwięku.
Opcje wyszukiwania (Strona 158 z 329)
dlatego dobrze jest zadbac o to zeby nasza gra sama przygotowala sobie srodowisko np. wlaczyla lub wylaczyla BASIC.
rozwinieciem tej idei jest sam xB, Twoja gra moze dodatkowo wylaczyc/ustawic przerwania, wylaczyc ROM, wskazac modul komunikacji ktory Ci najbardziej odpowiada, relokowac wektory init/run czy bufor itd. xB jest elastyczny :-)
AtariOS oraz QMEG wlaczaja/wylaczaja BASIC podczas "zimnego startu". xB nie siedzi w ROM, trzeba go zaladowac, sprawdza OPTION po zaladowaniu.
przykladowo:
jesli nie chcesz BASICA i masz AtariOS to wlaczasz komputer z wcisnietym klawiszem OPTION...
Jeśli podczas uruchomienia biblioteki przytrzymamy klawisz OPTION to niezaleznie od tego czy mamy QMEGa ładowanie pliku domyślnego zostanie pominięte.
Plik domyslny standardowo jest zawsze uruchaminy, jesli go nie ma lub jesli trzymamy OPTION przy starcie xB to uruchomione zostanie MENU.
xB po aktualizacji do sciagniecia:
http://xxl.atari.pl/?p=1076
zdefiniuj "dostepne banki"
M'Lady z D!Halt na Atari:
http://atari.pl/mlady.obx
wkrotce bedzie aktualizacja. dwie sprawy:
- jest cos w relokatorze co moze sprawiac klopot zaawansowanym userom, warto to poprawic
- kod zostal skrocony w dwoch obszarach: zezwolenie na uruchamianie xB z urzadzen ktore nie odpowiadaja np. na STATUS oraz xB bedzie wstepnie skonfigurowany juz w momencie uruchomienia.
zaoszczedzonego miejsca bedzie tyle, ze moznaby wbudowac obsluge ramdysku. pytanie: trzymac sie obecnej wielkosci i dodac nowa funkcjonalnosc czy lepiej skrocic plik bo i tak obsluge ramdysku mozna dodac odpowiednim wpisem w naglowku i dodaniem bloku obslugi ramdysku. po co wyreczac progrmiste, jak bedzie chcial ramdysk to sobie doda sam (zrodlo bedzie dostepne).
nie jestes na biezaco:
http://www.atari.org.pl/forum/viewtopic … 54#p188254
chocbys nie wiem jak bardzo chcial to nie zahamujesz rozwoju oprogramowania swoimi upgrejdami czy wymaganiami PIN Ready :-)
zamiast gledzic od dwoch i pol roku o plajerze to sam bys sie juz asemblera nauczyl ;-)
dobrze... lepiej zeby karty trafily do atarowcow
zeby dzialal z urzadzeniami podlaczanymi gniazdem cart i odtwarzal tyle sidow potrzebne by bylo rozszerzenie pamieci atari, po co isc na kompromis?
dzieki takiej budowie plajera i bibliotece xB nie wymaga rozszerzenia i odtwarza sidy nawet takie, ktore laduja sie pod rom lub ponizej $2000.
idea jest taka, zeby xB uruchomic w gotowym srodowisku. programista moze miec kaprys i przykladowo taki Pin bedzie mial wrazenie ze jakas gra dziala mu z jego dosa gdy w rzeczywistosci bedzie to xB ;)
poza tym inny programista zarzyczyl sobie mozliwosc definiowania wielkosci ramdysku lezacego w bankach o wybranych numerach.
porozmawiam z Wiedzacymi, zoptymalizuje i zrodlo zostanie udostepnione podobnie jak zrodlo AOSV.
SID PLAYER? hejtuj w odpowiednim watku.
sprawa dotyczy xBios i jego kolejnych mozliwosci :-) chyba Grzybson chcial miec mozliwosc odpalania produkcji wykorzystujacych xB z ramdysku. przechowuje program w jakims pamieciozernym filesystemie, na czas zabawy przekopiowuje pliki do ramdyku i odpala xBiosa - tak to sobie wykombinowal.
oczywiscie w wersji xB v3 programista zawsze ma mozliwosc zablokowania takich kombinacji :)
co sie stanie jesli interesujace nas programy wykorzystujace xB przekopiujemy do ramdysku i stamtad uruchomimy xB?
a to sie stanie:
http://youtu.be/L2SHG_4PeyI
aktualizacja plajera: http://xxl.atari.pl/?page_id=708
- optymalizacja, bedzie odtwarzal wiecej SIDow,
- wykorzystuje ULTRA SPEED jesli dostepny
jak narazie jedyny plajer na atari, ktory odtwarza SIDy grajace czesciej niz raz na ramke.
sposob w jaki LO potraktowal rozmowce powinien byc powodem do wstydu, tymczasem szanownego kolege duma rozpiera.
malo?
zrobil z tego wydarzenie medialne na forum
chcesz wiecej?
solidaryzuj sie
:D
powinni rypac i o tym trabic, a tak tylko rypali ;-)
ponadczasowo
jakby sie pochwalili, ze umieja odtwarzac SIDy z comodorka dopiero by byli nielubiani :D
byli za dobrzy jak na swoj czas :)
czyli nie lubiani przez Slavesa i jak czytam Dracona...
"Sam mogę dodać tylko tyle, że muzyczki z dem "HARD'u" po wyciągnięciu i zrzuceniu na c64 grają doskonale..."
faktycznie... ale jak to samo zrobil Swiety iles lat pozniej to wszyscy sikali po nogach ze szczescia :)
dlaczego srednio lubiani? bo byli nie do pobicia?
---
2 podstawki - do kazdej mozna wsadzic inna wersje sida?
jednak szkoda gadac. skasowalem posta. jedno slowo.
wstyd.
600xl? czemu nie. poprosze.
sledze Twoj projekt od poczatku roku, calkiem fajne.
chcialbym tylko zwrocic uwage na jedna sprawe - na atari juz istnieje mechanizm rozdzielnego dostepu dla procesora graficznego i cpu. przeprogramowujac mmu w atari mozna tez miec "kilka stron zero i stosow"... moze pracy nie byloby tak duzo jak sie wydaje?
jaki ja widze problem? target. wydaje mi sie jest to rozszerzenie dla ludzi, ktorzy "pracuja" na atari a nie ma juz takich osob. narzedzia na pc sa po prostu wygodniejsze.
wiem, bo ja mysle o atari xl/xe.
Znalezione posty [ 3,926 do 3,950 z 8,203 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.225 sekund, wykonano 17 zapytań