Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
atari.area forum » Posty przez Fox
Rtfm
Eru: tylko dwa bajty krótsze, poza tym to samo. Programik do kompresji jest dołączony, działa identycznie jak Twój.
Zoptymalizowałem procedurę dekompresji inflate. Teraz zajmuje ona niecałe dwie strony pamięci (poprzednio prawie trzy) i wykonuje się nieco szybciej.
Można pobrać ze strony:
http://atariarea.krap.pl/x-asm/inflate.html
Obawiam się, że w Swingu to by była taka kobyła, o której pisał Dely. Są playery natywne, więc wersję javową pisałem pod kątem apletu i midletu, a nie aplikacji. Oczywiście jeśli chcesz sam pisać taką aplikację, to Twoja sprawa, po prostu ja nie widzę sensu.
Optymalizacje, które wymieniłeś, nie mają zastosowania. Pisząc nowy emulator POKEYa i 6502 miałem na uwadze kompilację w Javie, więc nie ma prostych sposobów widocznego przyspieszenia kodu. Ciekawi mnie, jaki zysk można osiągnąć ograniczając zgodność z wersjami Javy?
Źródła są w CVSie. Te same źródła kompiluję jako C i jako Javę.
Midlet dopiero zacząłem kodować.
Wysyła na domyślny (dla Javy) interfejs. Sprawdź inne aplety z dźwiękiem.
To zgodnie z moimi oczekiwaniami: IRQ ustawione co 9 cykli nie daje szansy na wykonanie się "głównemu wątkowi". Takie przerwanie pojawia się w Das_Omen.sap, skutkiem czego w testowym ASAPie po odegraniu sampla nastaje cisza. Tak częste przerwanie ustawia STA $D208 spod $268B. Można sprawdzić na sapemu?
Swoją drogą format SAP jest niedospecyfikowany: np. czy do INIT skakać z ustawionym I czy ze skasowanym? Po jakim czasie zacząć wołać PLAYER? Epi, pewnie też miałeś podobne wątpliwości. Albo np. PLAYER w TYPE S - musi być i to niezerowy, ale poza tym nie jest brany pod uwagę przy odtwarzaniu.
A teraz? (podmieniłem plik)
Bardzo proszę o odpalenie na prawdziwej atarce:
http://asap.sourceforge.net/tirq.xex
i napisanie, czy wyświetla się tęcza na ramce.
Tylko u mnie sie tnie :/ ?
Na to wygląda. Mógłbyś sprawdzić, czy inne aplety z dźwiękiem działają dobrze?
No to tylko wersja alpha. U mnie gra płynnie zżerając ułamek procenta Pentium M 1.6.
Komu się tnie, niech poda procek, OS, wersję Javy i przeglądarki.
Znalazłem taką oto ciekawostkę:
http://6502asm.com/
Nie widzę sensu tworzenia SAP playera javowego, w którym cała robota byłaby odwalana przez kod natywny. Przecież jest to mniej przenośne od playera napisanego w całości w C lub C++.
Aplet byłby tylko ciekawostką. Byłby mniej wygodny w użyciu od normalnych playerów. Co do przenośności to nie wszyscy mają Javę, a na pewno szybciej i łatwiej ściągnąć WASAPa lub SAPa, niż Javę.
Midlet byłby pożyteczny, ale nieprędko powstanie, jeśli w ogóle.
poprawka byla rzeczywiscie jedynie propozycją "jak ugryzc temat"
Jak wiesz projekt Atari800 nie ma nadmiaru developerów, którzy tylko czekają na pomysł, żeby mieć co robić. Ja i Perry jako osoby najlepiej znające emulator od środka napisaliśmy kawał TODO, ale nie zawłaszczamy sobie prawa do zrealizowania wszystkiego własnymi siłami (jakby mało było tego, co dotychczas zrobiliśmy). Chętnie natomiast weźmiemy udział w dyskusji, poradzimy, podpowiemy, itp.
kiedy nastapi przelanie czary goryczy i miast ciagle poprawiac kod, łatając, łatając, łatając - wezmie sie ktos za napisanie go od nowa (ewolucja jest fporzo, ale czasem potrzebna jest rowniez rewolucja) i na podstawie doswiadczen zebranych przy poprawianiu - od nowa napisze wszystko "tak jak trzeba".
Właśnie dotknąłeś istotnej kwestii - łatek vs starannego projektu i napisania od nowa. Przepisałem na nowo znaczną część Atari800 i dlatego jestem krytyczny w stosunku do łatek, które chociaż trochę burzą porządek, bo wiem, że jeśli niskim nakładem pracy wprowadzi się je dzisiaj, to kiedyś nadejdzie czas, żeby je posprzątać (a autor łatki prawdopodobnie będzie już nieosiągalny).
Umieszczając na forum publicznym krytyczne uwagi nt. czyjejś pracy warto wpierw dokładnie zapoznać się z tematem. Inaczej dochodzi do niekończącej się sprzeczki i bezsensownego obrzucania się błotem. Jako osoba od 7 lat związana z projektem Atari800, która poświęciła mu setki jeśli nie tysiące godzin swojego czasu, będę go bronił.
Jakie są dowody, że kod atari++ jest zżynany z atar800? Z tych fragmentów kodu które czytałem, to jest on zupełnie inny.
atari++ jest zaprojektowanym od nowa emulatorem, jednak autor czerpał wiedzę o działaniu układów ze starych wersji Atari800 (sam do tego się przyznaje np. w nagłówku antic.cpp) w związku z czym występują błędy emulacji takie jak w Atari800 0.9.x. Co do żywcem wziętych fragmentów kodu to faktycznie były one niewielkie (np. tablica etykiet systemowych z monitor.c z identycznymi literówkami w nazwach etykiet jak w starych Atari800), ale autor atari++ wypierał się początkowo, że były jakiekolwiek i upierał się przy zastosowaniu swojej, jak sam napisałeś, niezrozumiałej licencji, odrzucając GPL. Dzięki temu, że udało się wywalczyć GPL możesz spokojnie wypuszczać swoje modyfikacje na GPL.
atari800 to czyste C napisany w sposób przypominający wynik działania obfuscatorów (IMHO ma szanse na wysokie miejsce w IOCCC ;) )
"Czyste C" uznaję za komplement, ale do IOCCC daleko. Chyba widziałeś mało skomplikowanych programów - są one skomplikowane, bo realizują skomplikowane funkcje. Tak jest w przypadku Atari800 - zapewnia on po prostu dokładniejszą emulację i większą wieloplatformowość, niż atari++ i dlatego kod jest bardziej skomplikowany.
a atari++ napisany jest bardzo czysto obiektowo i widać, że na początku był projekt, a nie radosne programowanie, dzięki czemu rozszerzanie go o cokolwiek nie sprawia żadnych trudności.
Bardzo podobała mi się konstrukcja pierwszych wersji atari++, jednak z tym bardzo czysto obiektowo to przesada. Co do projektu to niestety ja zauważam "syndrom Javy", tj. nadmiernej rozwlekłości kodu w imię obiektowości. Brakuje natomiast ważniejszej rzeczy: chociażby struktury katalogów w źródłach. W atari++ jest ponad 300 plików źródłowych w jednym katalogu. W tym pliki cart16k.cpp, cart16k.hpp, cart32k.cpp, cart32k.hpp i jeszcze kilkadziesiąt następnych do innych wielkości cartridge-y - czy rozwiązanie z cartridge.c i cartridge.h nie jest rozsądniejsze?
Co do łatwości rozszerzania, to w przypadku atari++ wydaje się, że wszystko trzeba robić na siłę obiektowo - a co w przypadku gdy nowa funkcjonalność niezbyt wpasowuje nam się w istniejący model obiektowy?
Najnowsze dema chodzą i jedyne co zauważyłem, to że dźwięk faktycznie trochę pierdzi (co dowodzi, że przynajmniej POKEY nie był wyrżnięty ;P). A jakie są inne ciężkie winy, że tak jest jechany i skazany na banicję?
Jeśli chodzi o mnie, to życzę projektowi atari++ jak najlepiej. Sam chciałem pomóc w jego rozwoju, jednak szybko zauważyłem, że musiałbym wykonać powtórnie pracę, którą przez lata włożyłem w Atari800, bowiem w atari++ są błędy, które kiedyś były w Atari800. Najnowsze dema nie są najlepszym miernikiem jakości emulacji, znacznie lepsze są stare gry. Ilość portów i ludzi pracujących nad rozwojem emulatora też zdecydowanie przemawia za Atari800. Chociaż obiektowość atari++ może zachwycać na pierwszy rzut oka, na dłuższą metę (np. przy wprowadzaniu istotnych poprawek w emulacji Antica) jest niepotrzebnym balastem.
becny kod jest w/g mnie lepiej rozwijany/bardziej przejrzysty niz atari800. ten ostatni od dluzszego czasu wyglada na zaniedbany...
od prawie roku gotowa byla poprawka do "f7" znanego z atari800win+ i do tej pory nie przejszla...
Dla projektu trwającego ponad 10 lat kilka miesięcy ciszy nie jest problemem - może po prostu jest dobry a użytkownicy zadowoleni? Niedbała jest natomiast poprawka, która w emulatorze wieloplatformowym koncentruje się na jednej platformie (używanej przez autora platformy) i nie uaktualnia dokumentacji. Gdyby poprawka była bez zarzutu, to od razu by przeszła - przecież to żaden wysiłek ją zaaplikować. Zachęcam do poprawienia poprawki tak, aby nie wprowadzała ona większego bałaganu do Atari800, niż jest obecnie.
Zapodaj plik.
1. 10
2. Ruszczyc "Asembler 6502"
3. Używam: C, C#, XSLT, Perl. Znam: Javascript, Java, D, Brainfuck
4. 1
5. SciTE, cl, PSDK, gcc, csc, perl, TortoiseSVN, Trac, nant, make
Nie wiem, ile TB rezerwuje na tablice liczb, ale zakładając optymistycznie, że tylko 6 bajtów na element, potrzebowałbyś 2 tablice * 40 kolumn * 40 rowków * 6 bajtów = dużo. Liczby całkowite 0-255 lepiej trzymać w DIM A$(1600) i I=40*Y+X+1:A$(I,I)=CHR$(LICZBA):LICZBA=ASC(A$(I,I))
No i liczby są w sektorach, a nie wiadomo ile bajtów w sektorze. Można próbować szacować z góry: DPEEK($308)-3 (zaraz po I/O na tym dysku). Jedyna pewna i przenośna metoda to przeczytać plik w całości. :)
OMFG! Połowy tej wiedzy (mnożenie i dzielenie) to nawet bym nie pomyślał, że może istnieć!
Jeśli chodzi o samo zrozumienie idei U2, to wydaje mi się, że zamiast myśleć o b7 jako mającym wagę -128 wygodniej myśleć, że wielokrotności 256 nie występują w obrębie bajtu. W związku z tym bajt $FF to młodszy bajt liczby 255, 511, 767, ale równie dobrze -1 (255-256). Dopóki wykonujesz + i - na bajtach, wielokrotności 256 nie mają znaczenia, np. 3+255=258=256+2 ale też 3+(-1)=2.
W takim razie trzeba zacząć sprzedawać sedesy z logiem Intela. ;)
Alternatywnie proszę o wskazówkę, jak najprościej odpalać .XEXa z emulatora. Kiedyś miałem takiego .ATRa, który odpalał plik PRG.AXE z dysku H: (SidLoad się to nazywało), ale to wciąż niezbyt czysta metoda (szczególnie, jak nowy plik .XEX ma coś doczytywać z dysku, itp.).
Podajesz emulatorowi XEXa z linii poleceń. Ewentualnie -run jeśli masz emulator z serii 1.x. Pliki czytasz z H:.
Autouzupełniania, zwijania (fold, a nie zawijania - wrap) i sesji nigdy nie używałem w SciTE.
Z lexerami rzeczywiście jest problem - od dłuższego czasu są pomysły na "generycznego lexera" w SciTE. Oczywiście taki lexer nie będzie uniwersalny (na pewno Perla dużo nie zrozumie) ani szybki i przede wszystkim jest problem jak wyważyć możliwości i łatwość konfiguracji.
W wolnej chwili możnaby zrobić lexer do kodu 6502. Lexer odpowiada też za zwijanie. Tylko jak zdefiniować co zwijać?
atari.area forum » Posty przez Fox
Wygenerowano w 0.059 sekund, wykonano 20 zapytań