A ten, za pomocą NestedVM nie da się zrobić przypadkiem wersji Java Atari800, którą możesz odpalić na Androidzie?

No ale jak to? Gra muzyka?

niby pozwala stworzyc aplikacje rysujaca po framebufferze, choc powinno sluzyc do robienia jni wywolywanego z poziomu dalvika, ale "da sie" tez calkiem natywne aplikacje zrobic - problem w tym ze nie moga korzystac z bogactwa frameworkow systemowych dostepnych wlasnie z dalvika (obsluga klawiatury ekranowej itd).

aplikacje mieszane (na dalviku "pobranie ekranu gl" + event loop, reszta natywnie po jni) - dzialaja calkiem sensowne jesli chodzi o predkosc

Nie ma paska przewijania. Jest pasek postępu, który teoretycznie ma pokazywać, w którym miejscu gra, ale w praktyce pokazuje postęp buforowania całej muzyki - prawdopodobnie w czasie wyżej wspomnianego "opóźnienia" odbywa się cała emulacja.

Jakiego API używa ten skonwertowany ASAP do odtwarzania dźwięku? Bo w android.media znalazłem tylko MediaPlayer, AsyncPlayer i SoundPool, którym zapodaje się dźwięk przez URLa.

ja na hero mam znacznie dluzsze opoznienie przy starcie, ale nie dziwne - znacznie wolniejszy proc ;)
btw. tak, "progressbar" od razu jest na full, tak wiec cala emulacja na raz leci zanim jakikolwiek dzwiek pojdzie.

co do api - mozna przez AudioTrack bez streamowania po http. jak to robia w tym posredniczacym api do j2me - nie wiem - ciezko mi cos w ich zrodlach wyczytac, ale mam program do deasemblacji apk to moze cos od dupy strony obczaje ;)

added:
ok. widze pliki takie jak (deasemblaty klasy):
AndroidMediaPlayer$InputStreamToServerSocket.smali
AndroidMediaPlayer$MediaListener.smali
AndroidMediaPlayer$PlayerNotifier.smali
AndroidMediaPlayer.smali

to ostanie zawiera m.in.
.implements Ljavax/microedition/media/Player;

tak wiec widac jada "stara metoda" kompatybilna ze starymi frameworkami, tj. implementuja microedition.media.Player streamujac sie po sockecie... wersja z AudioTrack pewnie ma mniejszy narzut - ale pewnie ogranicza zodnosc z api >2.x (wlasciwie standard od kilku miesiecy).

No to trzymam kciuki :-)

A tak wracając do tematu, ktoś jest mi w stanie pomóc z tą amigową dyskietką bootującą z atari800?

Na jakim procku? SAPy z samplami się nie tną?

Nie wiem jak to jest w świecie Amigi ale wydaje mi się że trochę przesadzasz :) . U mnie na Falconie z  CT63 podkręconym na 93MHz, Atari800 dla większości gier pokazuje prędkość oryginału w przedziale 90-103% więc nie jest źle :) Gorzej z demami, taki numen to nawet na jednym efekcie zwalnia do ~40% ale większość efektów i tak jest ~85%. Problem w tym że to Atari800 to wersja 2.1 ale podobno skompilowana bez dzwięku ( bo nic nie słychać :P ), więc dzwięk jeszcze by trochę mocy zjadł. Choć myślę że większość gier byłaby i tak w pełni grywalna, tyle że nie udało mi się Stehlika namówić ( a naprawdę byłem uparty ) na skompilowanie tej wersji z dzwiękiem pod TOSa. A szkoda, bo naprawdę użyteczny kawałek emulatora i to na Atari Falcon :) Do tego jeszcze można trafić na MC68060 która bez większych problemów kręci się na takie 107 MHz i wtedy to już emulacja Atari 8-bit pełną gębą :D

W kwesti dźwięku w emulacji, to ten wbrew pozorom nie musi zjadać "trochę" mocy, czasem zjada jej bardzo dużo. Z doświadczenia wiem że są emulatory (nie mówię tu teraz o małym Atari na Amidze 68k, bo nie mam jak tego zweryfikować), które działają całkiem normalnie bez dzwięku, a po włączeniu emulacji tegoż, stają się całkowicie nieużywalne.
Natomiast co do JITa to taki w UAE jest z pewnością dla procesorów X86 i nie ma na pewno dla procesorów PPC (nie mówię tu o emulatorze Petunia wszytym w AmigaOS 4, bo to inna para kaloszy). Czy jest na platformę Andorida (zapewne pytający posiada procesor ARM), nie mam pojęcia. Jeśli nie ma, to przypuszczam że UAE na procku telefonu komórkowego z przedziału 400MHz - 1GHz (nie mylić wydajności tak taktowanych procków mobilnych z wydajnością procesorów desktopowych) nie osiąga w zastosowaniach pratycznych nawet prędkości gołej A1200. Jesli jest JIT, będzie szybszy od takiej Amigi kilku - kilkunastokrotnie, jednak wątpię aby był szybszy kilkudziesięciokrotnie (060 przyspieszała A1200 ponad 30-krotnie).

ARM to daleki potomek 6502. :) Natomiast siła 68000 leży w adresowaniu i hurtowej ilości 32-bitowych rejestrów - zasymulować na tym 6502... ciężko. Nie ta architektura. Macie: mc68060@100MHz ledwie zipie przy tej robocie :) Z intelem to samo.. a pecetowa architektura też swoje robi. Efekt? Atari800winplus zżera 12% CPU. AMD x64x2@2500 MHz. Czyli do zaemulowania niecałych 2 MHz 6502 plus paru chipów trzeba 600 MHz mocy x86 :(

No, ale 6502, to 6502. 8-bitowe Atari wbrew pozorom ma moc obliczeniową zbliżoną do PC AT i niewiele niższą od Atari ST/Amigi

Podsumowując: jak masz tego androida chodzącego na ARM, to jest szansa na to że natywny emulator a8 będzie wyrabiał. Ale pomysł żeby zaemulować amigę (zmiana architektury #1) po to, żeby ona zaemulowała A8 (zmiana architektury #2) to nie ma w ogóle szans.

Pik33, zupełnie nietrafione argumenty moim zdaniem. Nie wziąłeś pod uwagę, że emulacja całego komputera (z dokładnością do cykla) to nie to samo co emulacja samego procesora 6502.

pik33: emulacja pod emulacją przejdzie. Bez problemu.

Co do emulacji 6502 na 68060@100MHz daje 100% prędkości 6502 na 100% zajętości 060. Jak by 060 podkręcić do 2500GHz to teoretycznie zajętość procesora spadłaby do 4%, więc nie jest tak źle. Jak by do tego jeszcze dołożyć nowoczesny cache, pewnie byłoby w okolicach 2%.