Yes, yes, yes! :) ...i do tego działa na moim telefonie :-)

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 ;)

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 - 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)?

A nie czasem bigger-endian, tak jak 6502? I w czym przeszkadzają niewyrównane słowa i do czego?

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.

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?

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.

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...

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.

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.

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 ;)