Nie znam sie na C++, ale moge ufundowac nagrode dla tego kto sprawi, ze na moim PPC2002 z prockiem 200Mhz (Mitac Mio 338) emulator Atari XL/XE bedzie smigal z szybkoscia 100% oryginalu. Pisalem o tym wielokrotnie :(  Wydaje sie niemozliwoscia ale, na te popularna platforme jest 1 (!) emulator i dziala u mnie z szybkoscia 50% oryginalu. Dla przykladu, komercyjny i znacznie wygodniejszy PocketC64 dziala mbosko a emulator ST dziala z szybkoscia 80% oryginalu.
Jaka nagroda zmobilizuje Cie (albo innych) do bardziej wytezonej pracy? ;)

Moja propozycja nagrody: Atari Jaguar + Pad + cart DOOM.

Wbrew pozorom Atari ST i C64 łatwiej zaemulować z racji braku takiego chipa jak Antic ;)

na razie nie powstal emulator ktory Atari ST dobrze emuluje ST.
pierwszy problem to dobra emulacja samego prock 68000 -  prefetch i cykolowanie Div'ow.
nastepne to emulacja hardware - tutaj leza m.in blitter, microwire, emulacja procka klawiatury, dzwiek
no i emulacja bugow - shifter, mmu itp.

wiec nie jestem wcale pewien czy latwiej jest emulaowac ST...
:)

Ostatnio edytowany przez Cyprian_Konador (2005-10-28 16:57:38)

No to rzeczywiście świeża jak piwo otwarte 3 lata temu.
Może jednak lepiej zrobić tak, jak napisałem wyżej.

A poza tym nie wkleiłeś błędów, które się pojawiają, nie napisałeś, której wersji Visuala używasz,
nie wiadomo jakie błędy w GUI masz na myśli - jakiej pomocy więc oczekujesz?

Fox - dzieki ale przebilem sie juz przez wszystkie ustawienia i mimo to nie osiagnalem plynnosci i szybkosci duzo wiekszej niz 50% oryginalu. Co ciekawe w pliku readme pisze ze powienien sie wyrabiac przy procku 200MHz... Moze na innym typie procka.
Cyprian - emulator ST jaki mam na PocketPC calkowicie mi wystarcza - dopalilem kilkadziesiat gier i wsio chodzi. Tylko dzwiek mi sie chrzani ale to nie jest dla mnie priorytet.
Mam w nosie dema! Chce tylko sobie pograc na starych dobrych gierkach ;)

200MHz to chodzi w glownej mierze o x86 (na tej platformie byl najczesciej testowany)
jesli chodzi natomiast o strongarmy (czy ich nastepcow - xscale) to sa prawdziwe riski
tak wiec przy dobrej optymalizacji (a kopulatory ms w tej chwili maja zdaje sie jedne z lepszych
optymalizery) w teori - powinny lepiej sie sprawowac niz x86.

czy czasem nie jest to skrojona wersja (wzgledem platnej)?
czy czasem nie jest pozbawiona np. mfc?
atari800win+ jest zalezne niestety od mfc - tak wiec kopulator dostepny na stronach ms za darmo do pobrania
odpada - bo jest pozbawiony wlasnie tych bibliotek (niezle upraszczajacych pisanie pod winde...)

problemem moze byc brak jakichs plikow naglowkowych (co powinno byc do wyczytania na podstawie bladow kopulatora - mozesz mi je na priv. podeslac?) - ogolnie to mozesz sie do mnie na odezwac przez gg/jabbera/skype/maila - postaram sie pomoc przy rozwiazywaniu problemow z dowolnym kopulatorem...

odpowiednie dane przesylam ci na priv.

no nie pisalem ze emulator nie dziala tylko ze jest okrojony w stosunku do orginalu :P

chodzilo mi tylko o to ze porownywanie wydajnosci niekompletnych emulatorow jest bezsensu

Ostatnio edytowany przez Cyprian_Konador (2005-10-31 11:36:57)

Nie jest.

Jeśli chodzi o trudność w określeniu timingów, to cecha procków superskalarnych i/lub z kieszeniami, więc prawdopodobnie również nowych ARMów.

Offtopic: GCC 4.0 generuje np. "lea eax, [eax+1]", ktoś wie dlaczego nie po prostu "inc eax" ?

Fox: OK, mogę wszystko wrzucić tutaj na forum. Mam nadzieję, że pomożesz :) Co do osoby odpowiedzialnej to podaj mi jakiś kontakt do Kostas Nakos'a, ja się kontaktowałem chyba z jakimś Czechem, którego namiary znalazłem w ostatniej wersji atari800, którą używam.

Jellonek: Pakiet Embedded Visual C++ dla PPC który jest dostęny za darmo na stronach Microsoftu jest pełnym pakietem do produkcji wszelakiego softu na PPC. Nie ma płatnej wersji EVC++. O ile dobrze pamiętam MFC zdaje sie jest ale trzeba pamiętać, że to jest dla PPC. Cieszę się, że jesteś chętny do pomocy. Odezwę się :)

Dla usprawnienia prac przedstawiam krótki harmonogram prac na początek:
1) poprawne skompilowanie najświeższej wersji atari800 WinCE,
2) usunięcie błędów virtualnej klawiatury (shift, ctrl, caps etc.)
3) optymalizacja przełączania banków rozszerzonej pamięci.

Drac030: pewnie tak, ze względu na to, że wykonuje je część procka od generowania adresów, a nie ALU.

Alex: pewnie napisałeś do Stehlika, który czasem bywa zajęty;
http://cvs.sourceforge.net/viewcvs.py/* … TALL.wince

Jeśli chodzi o "3)" to raczej pobożne życzenia (czytaj: jeśli uda się wam to zrobić, to pogratuluję).

jellonek: dłuższy rozkaz na pewno trudniej załadować, w dodatku taki, który ma parametr

Jellonek: Spróbuję pamiętać :-) ale w środowisku pocketowców przyjęło się, że PPC to Pocket PC i mi to juz weszło w krew. O PowerPC to ja juz dawno zapomniałem. Chyba jeszcze tylko fanatycy ogryzków ich używają, ale juz nie długo, bo Apple przechodzi na procki Intela.

Fox: No właśnie - Stehlik :) Nic mi niestety nie odpowiedział... :( Z tą pamięcią to wiem, że to wynik takiego, a nie innego rozwiązania problemu. Trzebaby pewnie przeogranizować zarządzanie pamięcią, żeby nie było przepisywania tylko sprytne indexowanie.... no ale to tak na wyrost :) Może wspólnie uda sie coś wymyśleć :)

Tak głęboko jeszcze nie wnikałem, ale zastanawiałem się czysto teoretycznie nad emulacją banków pamięci w taki sposób:

- tablica memory w emulatorze miałaby długość -> liczba_banków_pamięci*$10000,
- przełączanie banków zamiast przepisywania byłoby relizowane przez dodanie do indexu wartości nr_banku*$10000,
- bank byłyby przełączany tylko wtedy, kiedy licznik adresowy procesora lub adres w którymś z rozkazów pochodziłby z zakresu $4000-$7fff.

Oczywiście w takim przypadku w każdym emulowanym banku mającym $10000 tracimy 48 KB, ale mamy prosty mechanizm przełączania i nie trzeba przepisywać :)

Od razu mówię, że nie analizowałem kodu emulatora i nie wiem jak to w tej chwili działa dokładnie więc mój pomysł może być bez żadnego sensu, ale na razie są to luźne rozmyślania na ten odległy temat ;)