Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
TONY na małe Atari Nowa gra na małe Atari, w Hiresie, produkcja Rafała Dudka (brat XXL-a), Popmilo i Caruso.
Zaloguj się lub zarejestruj by napisać odpowiedź
pewnie zainteresowani juz wiedza, ale skoro nie ma o tym jeszcze arta ani na glownej, ani u vaskonia - pisze tu
wyszla nowa wersja w ktorej to jest qpe nowosci (choc mi osobiscie nadal brakuje F7 z atari800win+)
wiecej:
http://sourceforge.net/project/shownote … p_id=40606
milej zabawy ;)
Yes, yes, yes! :) ...i do tego działa na moim telefonie :-)
alex co Ty masz za telefon ?
SPV C600 czyli HTC Tornado :)
Dla niewtajemniczonych jest to smartphone z ARM'em 200MHz i Windows Mobile 5.0.
Bardzo sympatyczny telefonik, choć przydało by mu się trochę dodatkowych megahertzów ;)
alex, 200 to malo?
w sumie to megahertzow nigdy zawiele...
No wiesz... Numen chodzi zgrubsza na 100% :-) ale w Bitter Reality kilka części chodzi znacznie wolniej... Jakby się udało zopytmalizować Pocket Atari na 200 MHz'owe ARM'y to pewnie problem by się rozwiązał, ale że to jest muliplatformowy open source project to niestety kod jest zoptymalizowany raczej pod kątem x86 :-(
Alex - jestes pewien ze ten emulator chodzi Ci na 100% szybkosci na tym palmofonie?! Nowa czy stara wersja emulatora? Nie mam teraz mozliwosci sprawdzic nowej, ale stara chodzila na moim ARM 200MHz (Mitac Mio 338) z szybkoscia 50% max na dowolnej grze. Chcialem nawet ufundowac nagrode jak mi to ktos poprawi...
Alex - a tak z ciekawosci, bo palmofony coraz bardziej mnie fascynuja. Ile toto wytrzymuje godzin bez ladowania akumulatorkow przy normalnej pracy z podswietlaniem i wlaczonym normalnie modulem GSM (np. przy czytaniu ebookow)?
muliplatformowy open source project to niestety kod jest zoptymalizowany raczej pod kątem x86 :-(
Dziwny tok rozumowania.
Po prostu tak się składa, że x86 jest little-endian i nie ma problemu z dostępem do niewyrównanych słów - tak jak 6502.
x86 jest little-endian i nie ma problemu z dostępem do niewyrównanych słów - tak jak 6502.
A nie czasem bigger-endian, tak jak 6502? I w czym przeszkadzają niewyrównane słowa i do czego?
Jaki znowu bigger?
Jak emulator chodzi na sprzęcie big-endian lub nie można jedną instrukcją pobrać słowa spod nieparzystego adresu, to np. w przypadku instrukcji LDA $ABCD bajty $CD i $AB muszą być pobrane osobno i złączone w słowo.
Nosty: napisalem, ze numer chodzi z grubsza na 100% :) na moje oko szybkosc emulacji w przypadku tego dema waha sie od 70 do 100 % ale oglada sie przyjemnie, natomaist Bitter Reality chodzi tak wolno, ze nie da sie ogladac niektorych czesci niestety... ale to wina emulatora. Jeśli chodzi o Pocketa to na moim h4150 emulatros smiga na 100% caly czas chyba, ze jest dostep do dodatkowe pamieci - wtedy spada do kilku procent... z winy przepisywania bankow pamieci.
Co do czasu pracy to nigdy nie mierzylem.... ale dziala dosc dlugo ;) ja i tak laduje codziennie na wszelki wypadek, ale jak sluchalem sobie kilka godzin SID playera albo ogladalem 2,5h film w divxe lecac samolotem to zuzylo sie mniej niz 20% baterii o ile pamietam.
Fox: mi chodziło tylko o to, że jeśli kod Atari800 my sie zoptymalizowalo i zmodyfikowalo pod kątem ARM-a (pozwalajac sobie nawet na wstawki w asemblerze) to emulator moglby dzialac szybciej. Nie wiem o ile bo nie jestem specjalista od ARM-ów, ale biorąc pod uwagę, że ARM został opracowany na podstawie 6502 (podobno) mysle, ze mozna by przynajmniej te kilkanascie procent uzyskać. Podkreślam jednak, że to tylko na razie teoria nie poparta żadnymi badaniami.
Lizard: big endian to jest m68k, 6502 jest little endian. Pomerdały ci się procesory, za dużo przy piecu siedzisz :P
Na ARM-ie nie ma dostępu do słów spod nieparzystego adresu?
Ostatnio edytowany przez drac030 (2006-01-04 19:17:16)
alex: przytaczajac powtarzane wielokrotnie przez fox-a slowa (na liscie mailnigowe, gdzies je jeszcze widzialem)
w dzisiejszych czasach poprawnie napisany kod w C + dobry kompilator (w zasadzie za taki, na wiekszosci popularnych architektur, uchodzi powszechnie uzywany gcc) generuje kod, jesli nie szybszy, to conajmniej tak samo dobry, jak recznie optymalizowany w assemblerze.
moze i slowa nieco poprzestawialem, albo i zle cos przetlumaczylem (z pamieci pisze) - ale powie ci to wiekszosc osob grzebiacych przy kompilatorach C.
kod generowany przez kopulator moze byc mniej wydajny w przypadku slabszych kompilatorow (tcc, lub blizszy nam cc65), ale przy np. gcc, jesli platforma na ktora kopulujesz jest w miare popularna (x86, powerpc, rodzina arm-ow, rodzina avr-ow) kod jest naprawde very ok.
W przypadku przeciętnego programu może to i jest prawda. Ale w przypadku emulatora, a konkretnie takiego silnika, który emuluje 6502 na procesorze-hoście, raczej nie ma szans na taki kompilator, który wygeneruje kod optymalny co do szybkości interpretowania opkodów.
Ostatnio edytowany przez drac030 (2006-01-04 22:00:51)
jellonek: znam to twierdzenie :) chodzi mi jednak, że kod w C+ można pisać z myslą o pewnej architekturze i choćbyś miał najlepszy kompilator na świecie to nie zastąpi to optymalizacji pod dany procesor. Najlepsze przykłady można znaleźć na naszym "podwórku". Czy da się na małe Atari zrobić takie efekty jak w Numenie pisząc je w C+ i kompilując na 6502? Czy jednak trzeba podejść indywidualnie do procesora i zastosować pewne sztuczki? ;) Wierzę, że GCC jest dobrym kompilatorem, ale PocketAtari.exe z tego co wiem jest kompilowany na eVC+3.0 Microsoftu. Nataomiast skoro (podobno) Arm bazuje na 6502 to można zaryzykować domniemanie, że mogą istnieć podobne sztuczki pozwalające przyśpieszyć działanie emulatora.
Jednym zdaniem - zgadzam się z Draco w tej kwestii :)
alex - 20% baterii przez 2,5h ogladania DivX? 8-O To masz chyba po kieszeniach upchane dodatkowe akumulatory. Rewelka. Dotad nie widzialem ppc, ktory by potrafil wytrzymac dluzej niz 4-5h odtwarzania divxow.
A co do Atari800 - wyprobowalem. Na moim 200MHz ARM Mitac Mio, przy klatkach 1:1, WYL. filtrowaniu grafiki i WYL. rozszerzonej emulacji Pokeya chodzi max 35%. Zenada. Jak wlacze luksusaowa emulacje Pokeya to spada do 17% na jakiejkolwiek grze czy basicu.
To co podalem to wartosci maksymalne. Gapi 1.2 mam zainstalowane.
Czyli albo jest zle napisany emulator (np. mocno pod pockety hp), albo moj Mitac Mio jest do d... Prawdopodobne sa obie ewentualnosci zwazajac ze emulator C64 smiga mi >100% a Atari ST ~80-90% oryginalu.
Pozdrawiam i ide wybierac nowego pocketa na wiosne...
nosty: nowy pocket ci nie pomoze...
alex: nie ma takiego jezyka jak C+, "+" w zdaniu uzyem jako spojnik :D
co do efektow w numenie, i programowaniu w C - o czym wasc gadasz? co ty porownujesz? w wypadku ataraka pisze sie nie tylko pod procesor, ale pod sprzet (ANTIC, POKEY), a w dodatku nie ma dobrego (dobrze optymalizujacego) kompilatora JAKIEGOKOLWIEK jezyka wyzszego poziomu na rodzine 65xx.
jesli chodzi natomiast o wieksze procesory i o istniejace kopulatory (na liscie atari800 wlasnie byla na ten temat dyskusja) nie moge sie z KMK w calosci zgodzic. dobry kompilator zazwyczaj produkuje lepiej poukladany kod, niz by to zrobil zreczny programista assemblerowy (chodzi tu o kolejnosc rozkazow, oraz ich odpowiednie kombinacje, tak aby jak najlepiej byly wykozystane mozliwosci procesora - hosta)
Jellonek, ty teoretyzujesz, a ja napisałem w asemblerze silnik 6502 sześć razy szybszy od analogicznego kodu generowanego przez gcc. Taka jest różnica między zdaniem moim a twoim.
drac030: czy ten silnik opiera sie o ten sam kod (algorytm) C z ktorego generowalisci (zarowno Ty jak i GCC) kod assemblerowy?
powtarzam: chodzi o poprawny kod w C.
btw. o jaka platforme "host" chodzi? mozna sie przyjrzec twojemu kodowi silnika? i skoro napisales toto, to czemu nie trafilo to do atari800? (mozna na opisana przez ciebie architekture wydzieli sie silnik assemblerowy, podczas gdy na innych bedzie kopulowany z C)
pamietaj ze w wypadku emulacji atari800, nie chodzi tylko o emulacje procesora, ale takze o specjalne traktowanie zapisown/odczytow pewnych adresow (rejestry sprzetowe).
Pierwsze pytanie jest, wybacz wyraz, idiotyczne.
Dalsze pytania:
1) chodzi o Falcona - procesor Motorola 68030.
2) przyjrzeć się nie można, bo nie mam zwyczaju ujawniać źrodeł
3) do Atari 800 nie trafiło, bo jest niekompatybilne z a800, a Petr Stehlik nie zrozumiał kodu w stopniu wystarczającym, by to przystosować.
4) odczyt/zapis rejestrów sprzętowych był uwzględniony, ten silnik jest zaimplementowany w istniejącym - aczkolwiek mocno niedokończonym, bo mi się odechciało - emulatorze, mianowicie EmuXL.
A co do Atari800 - wyprobowalem. Na moim 200MHz ARM Mitac Mio, przy klatkach 1:1, WYL. filtrowaniu grafiki i WYL. rozszerzonej emulacji Pokeya chodzi max 35%. Zenada. Jak wlacze luksusaowa emulacje Pokeya to spada do 17% na jakiejkolwiek grze czy basicu.
To co podalem to wartosci maksymalne. Gapi 1.2 mam zainstalowane.Czyli albo jest zle napisany emulator (np. mocno pod pockety hp), albo moj Mitac Mio jest do d... Prawdopodobne sa obie ewentualnosci zwazajac ze emulator C64 smiga mi >100% a Atari ST ~80-90% oryginalu.
na moim Pentium M 1.8Mhz przy klatce 1:1 Steem zrywa efekty w demach (oczywiscie nie we wszystkich) wiec po 200Mhz nie spodziewal bym sie czegos lepszego...
Pierwsze pytanie jest, wybacz wyraz, idiotyczne.
jak ktos go nie rozumie to moze i idiotyczne.
chodzilo o to ze porownanie predkosci kodu wygenerowanego przez speca (tu Ty), i kopulator (tu GCC) jest bezsensowne, jesli zastosowane byly rozne algorytmy... tak wiec jesli napisane przez Ciebie core emulacji 6502 jest n razy szybsze od kodu opierajacego sie o inne rozwiazania algorytmistyczne - to twoje porownanie mozna tylko wysmiac... jesli natomiast opiera sie o ten sam algorytm (tylko np. recznie poprawiales wygenerowany przez gcc kod, albo pisales go z palca od poczatku, ale opierajac sie o wlasna interpretacje tego co gcc powinna wygenerowac) - swiadczy to o niedoskonalosci gcc na tej architekturze + o Twoim kunszcie ;)
tak, czy siak i tak chyle czola przed praca wykonana przez Ciebie ;)
pamietaj ze C to wlasciwie tylko nieco bardziej przenosny assembler, tak wiec jesli dobrze zaprojektuje sie kod C - wynik w assemblerze, przy dobrym kopulatorze, niewiele sie bedzie roznil od perfekcyjnie napisanego recznie.
btw. gcc -> 68k chyba az tak znowu optymalnym kompilatorem nie jest ;)
ja napisałem w asemblerze silnik 6502 sześć razy szybszy od analogicznego kodu generowanego przez gcc
Głupie pytanie, ale muszę je zadać: czy zastosowałeś opcję "-O2" w gcc? W przypadku nowoczesnych procesorów i kompilatorów, dobrze napisany kod w C jest zwykle max. kilkadziesiąt procent wolniejszy od genialnego kodu w asemblerze. Więc zupełnie nie ma sensu pisanie w asemblerze, tym bardziej, że trzeba by optymalizować pod konkretny model (w C wystarczy zmienić opcję kompilatora). Własnoręcznie wyciąłem ostatnie resztki asma x86 z emulacji GTIA, bo na oko było widać, że gcc 2.95 generuje wydajniejszy kod.
Emulację POKEYa w Atari800 można pewnie przyspieszyć z 50 razy, a resztę emulacji (czyli głównie Antic/GTIA oraz 6502) może dwukrotnie. Oczywiście wszystko cały czas w C. Wszystko jest opisane w pliku TODO ze źródłami Atari800.
Na marginesie: optymalizator cc65 wcale nie jest taki zły. Kiedyś przyglądałem mu się i zgłosiłem trochę poprawek.
emulator C64 smiga mi >100% a Atari ST ~80-90% oryginalu
Jest niemal pewne, że oba te emulatory automatycznie gubią klatki
(czyli zmniejszają refresh). Jest to w TODO Atari800. :)
W przypadku mniej wydajnych urządzeń (szczególnie pocketów) problemem jest woolny dostęp do ekranu i żadne sztuczki z asemblerem nic tu nie pomogą.
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.094 sekund, wykonano 9 zapytań ]