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
TURGEN 9.3.1 Najnowsza wersja oprogramowania TURGEN wprowadza kilka istotnych ulepszeń.
FujiCup 2024 - głosowanie Wystartowało głosowanie w tegorocznej edycji konkursu FujiCup.
IX. Basque Tournament of Atari 2600 31 stycznia Euskal Retro Association zorganizowało IX. Baskijski Turniej Atari 2600.
Rogul 1.0f Poprawki i nowe funkcje
a8rawconv GUI Graficzny interfejs użytkownika (GUI) dla narzędzia a8rawconv
Opcje wyszukiwania (Strona 1 z 9)
Strony 1 2 3 … 9 Następna
B. fajny projekt, w stylu pure retro (CART), dzięki czemu każdy może sobie go podłączyć bez babrania się w lutowanie. Fajnie, że wspiera SAA1099. Możecie zaprezentować jakiś track odgrywany na tym ostatnim układzie?
Będzie wersja "po bożemu" (CAR) ?
EDIT: No i jeszcze przydałaby się obsługa Philips SAA1099 (rządzi)...
wieczor napisał/a:@Marek Konopka: Ale sprawdziłeś gdzie prowadzi podany przez Ciebie link? :D
Fajne.
Proponuję doprecyzowanie oraz zmodyfikowanie następującego fragmentu:
Prace wystawione na konkursach będą opublikowane na stronie zlotu w formie zaprezentowanej podczas konkursów. Autorzy mogą oczywiście upublicznić później wersję "final" swoich prac, jeżeli zajdzie taka potrzeba.
do następującej formy:
Wszystkie prace wystawione na konkursach będą opublikowane na stronie zlotu (http://xxx.xxx) w formacie dostarczonym przez autorów, najpóźniej N dni po zakończeniu imprezy.
Gdzie N powinno dążyć do zera...
mazi napisał/a:Przeciez jak sie przyjrzec to sporo elementow jest zmienionych.
Wszystkie są zmienione. Każdy klocek został indywidualnie potraktowany przez grafika.
xxl napisał/a:wydaje mi sie ze to jest 16bit 65816
Zgadza się.
Nie chciało mi się już podpinać ciekawej funkcji modulującej ZOOM'a, ale popracuję jeszcze nad tym tym programem, aby prezentował się atrakcyjniej.
xxl napisał/a:Marek Konopka napisał/a:Zaprezentowana wersja pracuje stabilnie z zegarem 15 MHz, dzięki czemu prezentowane wcześniej demo technologiczne wyświetla animację z płynnością 50 klatek na sekundę.
jakis filmik?
https://www.youtube.com/watch?v=UR7zWrQOFKQ
Klip nakręcony w 25 fps, więc maksymalnej płynności nie dostrzeżemy. Pomiar jednak wskazuje ($01 w pierwszej kolumnie), że mamy do czynienia odtwarzaniem 50 klatek na sekundę. Postaramy się wrzucić jeszcze dla porównania wersję bez akceleracji.
Z wielką przyjemnością chciałbym oznajmić przywrócenie projektu do życia. Dzięki zaangażowaniu oraz dużej wiedzy z zakresu elektroniki, Simiusowi udało się zminiaturyzować projekt do rozmiarów kartridżowych. Od czasu powstania prototypu Zenkowego minęło sporo czasu, jednak najważniejsze, że w końcu udało Nam się przekroczyć granice problemów technicznych z programowaniem układów CPLD. W tym miejscu chciałbym po raz kolejny podziękować Zenkowi za ogrom pracy jaki włożył w projekt kilku stworzonych przez siebie prototypów.
Zaprezentowana wersja pracuje stabilnie z zegarem 15 MHz, dzięki czemu prezentowane wcześniej demo technologiczne wyświetla animację z płynnością 50 klatek na sekundę.
![http://s27.postimg.org/mbdnmrdi7/Veronica_1_0.jpg](http://s27.postimg.org/mbdnmrdi7/Veronica_1_0.jpg)
![http://s10.postimg.org/isbqsy78l/Veronica_1_0_b.jpg](http://s10.postimg.org/isbqsy78l/Veronica_1_0_b.jpg)
xxl napisał/a: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
Sugeruję drugie rozwiązanie. Nie ma sensu płacić za coś, czego się nie wykorzystuje.
Jedyne zastrzeżenie jakie mam to narzut pamięciowy na niewykorzystane urządzenie systemowe, ale tę opinię już znasz od jakiegoś czasu... Przydałoby się, aby przynajmniej w wersji developerskiej była możliwość usunięcia tego modułu dla kogoś, kto nie ma zamiaru z niego korzystać.
xxl napisał/a:ktoras jest jeszcze niejasna/bledna?
Proponuję konsekwentne wyrównanie pozostałych nazw:
xBIOS_BINARY_LOAD -> xBIOS_LOAD_BINARY / xBIOS_LOAD_BINARY_FILE
xBIOS_NOTE -> xBIOS_GET_FILE_OFFSET
xBIOS_POINT ->xBIOS_SET_FILE_OFFSET
xxl napisał/a:odnosnie rename. tak, wolne "sloty" beda mogly byc nazywane (kazdy to osobny plik) przez gracza.
Technicznie rzecz biorąc nadawanie nazw slotom nie wymaga zmiany nazwy pliku. Można zmienić zawartość pliku, jakiś jego fragment odpowiedzialny za "metadane", powiedzmy pierwszych N-bajtów.
xxl napisał/a:co do zmian nazwy kataogow, np. mozliwosc umieszczenia tabeli wynikow jako spisu podkatalogu. podczas przegladania dysku zwyklaym dosem po DIR pojawi sie tabela wynikow ;-)
Czy to jest aż tak istotne, aby łamać pierwotne założenia? Można sobie wyobrazić plugin do filesystemu, który odczyta stosowne metadane z nazw plików/katalogów.
xxl napisał/a:xBIOS_RENAME
Skąd wynikła potrzeba na istnienie takiej funkcji? Do tej pory wydawało się, że intencją biblioteki jest ograniczony zakres zmian, czego wyrazem było udostępnienie f. do zapisu istniejącego już pliku. Teraz okazuje się, że istnieje zapotrzebowanie na zmiany również na poziomie struktury systemu plików. Dlaczego?
xxl napisał/a:xBIOS_DEFAULT_DEVICE
Proponuję konsekwentnie xBIOS_SET_DEFAULT_DEVICE.
xxl napisał/a:xBIOS_HOME_DIR - ta funkcja nie sluzy do ustawiania katalogu domyslnego tylko do powrotu do katalogu domyslnego.
Zatem xBIOS_CHANGE_DIR_TO_DEFAULT.
xxl napisał/a:no wlasnie nazwa + typ moze identyfikowac z czym mamy do czynienia ale dosy chyba tego nie robia :/ nie wiem czy rozszerzac mozliwosci czy zachowac ograniczenia dosow.
Jeśli nie ma takich potrzeb, to nie warto tego realizować. Wygląda to na nadprodukcję, dodatkowo mającą niekorzystny wpływ na interfejs biblioteki.
xxl napisał/a:xBIOS_OPEN_DIR
Czy to jest nowa nazwa dla f. zmieniającej katalog? Jeśli tak, to jest ona nietrafna. W powszechnej konwencji nazywamy taką akcję zmianą bieżącego katalogu, ustawieniem katalogu.
xxl napisał/a:xBIOS_HOME_DIR
Złamana konwencja nazewnicza. Dotychczas wszystkie posiadały takową: xBIOS_[czasownik]_[podmiot]. Proponuję powrót do intuicyjnej formy: xBIOS_SET_HOME_DIR / xBIOS_SET_DEFAULT_DIR.
xxl napisał/a:nie jestem przekonany czy mozliwosc nadawania tych samych nazw dla plikowow i katalogow jest dobra...
Jeśli jakiś DOS udostępnia taką f. to ma to sens. W takiej sytuacji kluczem identyfikującym element systemu plików byłaby para nazwa + typ.
Jeżeli po zmianie jednego z bajtów składowych wektora DLI zostanie zgłoszone kolejne przerwanie DLI, to wtenczas wektor będzie zazwyczaj wskazywał niepoprawną wartość, nastąpi skok w ogórki. Sprawdź, czy przeniesienie ustawiania wektora na sam początek przerwania DLI zmienia sytuację. Wątpię, aby w Twoim konkretnym przypadku to było źródłem problemu, aczkolwiek bezpieczniej jest zmieniać ten wektor na początku przerwania.
Kod Self Testu chyba korzysta z procedur w ROM'ie.
http://atariki.krap.pl/index.php/Rejestry_PIA
Z faktu, że plik będzie się zaczynał od sekwencji $FF FF nie możesz wyciągnąć wniosku, że to plik binarny dosa. Może to również być zwykły plik z danymi.
mono napisał/a:Nic mi natomiat nie wiadomo o tym, że sygnatura ma występować tylko w pierwszym bloku, a w następnym jej nie ma. Nawet w Atariki pisze, że w pierwszym jest obowiązkowa, a w kolejnych opcjonalna.
Jeśli odnosisz się do mojej wypowiedzi, to z niej nie wynikało, że sygnatura ($FF FF) może występować tylko w pierwszym segmencie - wręcz przeciwnie. Pisałem o tym, że istnieją dwa różne sposoby wyrażania segmentu poza pierwszym segmentem. W pierwszym segmencie sygnatura jest obowiązkowa, w pozostałych opcjonalna.
xxl napisał/a:sprawdzilem MADS nie generuje sygnaturki przed blokiem ladowanym pod $ffff
To Mads ma problem.
EDIT: @mono. Skoro odnosisz się do artykułu z Atariki, to w nim nie ma nic napisane o tym, że bloki ładowane od adresu $FFFF muszą być poprzedzone sygnaturą. To jedynie Nasze założenie powodujące, że taki plik zostałby prawidłowo załadowany.
Problem z adresem $FFFF wynika z tego, że segment do załadowania od tej lokalizacji można wyrazić w pliku binarnym na dwa sposoby. Pierwszy posiada nagłówek $FF FF, a za nim adres poczatkowy i końcowy. Drugi nie posiada tego nagłówka. Każdy kolejny (poza pierwszym) segment może być wyrażony na jeden z tych dwóch sposobów. Loader po napotkaniu sekwencji $FF FF musi potraktować ją jako początek nagłówka, a nie adres początkowy. Problem pojawia się w momencie, gdy rzeczywisty segment nie posiada tego nagłówka, czyli zaczyna się od adresu początkowego, którym może być właśnie $FFFF. Nie rozróżnimy tych dwóch sytuacji. Skutkiem tego rozsypie się cały proces ładowania programu - a w konsekwencji może to doprowadzić do nadpisywania pamięci w nieprzewidziany sposób. Rozwiązaniem byłoby przyjęcie założenia, że nie możemy nic załadować od adresu $FFFF, bądź też, że ładowanie od adresu $FFFF zawsze poprzedzone jest nagłówkiem $FF FF. Nic mi nie wiadomo o istnieniu takich założeń.
Znalezione posty [ 1 do 25 z 219 ]
Strony 1 2 3 … 9 Następna
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.014 sekund, wykonano 58 zapytań