Ale panowie rozumieją, że dotychczasowy "emulator" chodzi z prędkością ok. 4,5% ZX Spectrum, więc np. jeśli w spektrusiu po włączeniu zasilania napis "(c) 1982 Sinclair Research Ltd." się pojawia po 3 sekundach[1], to tu przyjdzie nań poczekać ponad minutę? Więc o jakich demkach tu mowa?

Sikor:

a) ten rejestr nie jest "wykonywany" przez Antica

b) emulację z wyłączonym Antikiem się da zrobić, zysk jest ok. 30% (czyli nie 4,5%, tylko 6,4%), ale nie ma obrazu - a myślę, że slideshow z wyłączoną wizją traci nieco na atrakcyjności.

c) Antic jest procesorem, ale wizyjnym - zasadniczo jest już na niego przerzucone to, co przerzucić było można (czyli tworzenie obrazu i dbanie o to, żeby nie migało mimo przełączania banków pamięci)

[1] nie wiem, ile to trwa, strzelam.

4,5% w tej fazie nie jest wcale takim złym wynikiem. Jak po optymalizacji uda sie zrobic około 30% to nawet będzie mozna coś z tym zrobić... ;)

O.K.

A inne pytanie natury technicznej: jaky Z80 podłączyc przez port Cartridge-a i wtedy emulować tylko ROM maszynki opartej na Z80, jaki wynik - teoretycznie - moznaby uzyskac dla emulacji ZX-Spectrum (w podstawowej wersji 48K). Wtedy - wczytując hipotetyczne romy z poziomu Atari - mielibyśmy dostęp do programów na kompy oparte o Z80.
Inna sprawa - dołączenie emulacji odczytów obrazów programów (czyli na przykład *.tap z ZX-Spectrum)?

A skąd wtedy będziesz wiedział, że emulator działa? Taki emulator ja mogę napisać, nawet Amigi - działa wyłącznie z wyłączonym Antic :)

CIIW ale lista rozkazów Antica zawiera tylko rozkazy tworzenia linii oraz skoki, jak na tym liczyć?

jesli podlaczysz Z80 + nieco ramu + jakies miedzymordzie, coby dobierac sie do tego ramu i udawac konsole - to wlasciwie bedziesz mial modul obslugi CP/M (cos w stylu karty do 1090).
co prawda daje ci to dostep do softu z CP/M ale jakos nie uklada mi sie ten pomysl...

btw. do emulacji ZXa by to niewiele wnioslo - bo nie tyka to ni kapke obslugi grafiki...

jellonek: nie lubisz Turbo Pascala 3.0? ;)

Sikor: trochę mylisz pojęcia. Emulator software'owy może korzystać z właściwości Antica dla ulżenia sobie w ciężkiej, niewdzięcznej i nikomu niepotrzebnej robocie ;) bo pamięć emulowanego Z80 to ta sama pamięć, do której ma tez dostęp Antic.

W przypadku doczepiania rzeczywistego Z80 z zewnątrz rzecz ma się zgoła inaczej - taki procesor musi mieć swoją pamięć (oddzielną od tej, która jest w Atari), a do zewnętrznej pamięci dostępu nie ma z kolei Antic. Więc porażka. Odwrotnie - żeby Antic korzystał z pamięci Atari, a Z80 miał do niej dostęp z zewnątrz - to już prędzej, ale i tak nie obyłoby się bez makowego cuda służącego do translacji adresów w tę i we wtę, i to, oczywiście, w locie.

Jeszcze szybszy będzie taki, który wykona je na PC. :)

Ja mam taki pomysł, żeby najpierw przekompilować, a potem wykonywać.

Żartowałem.

Wlasnie kiedys (i teraz tez) zastanawialismy sie mocno z Pirxem jak to zrobic.
Wymyslilismy zebranie jak najwiekszej biblioteki typowych konstrukcji programistycznych z Z80 (petle, porownania z wykonaniem akcji, itp...) , potem trzeba automatycznie przeanalizowac kod i zastapic odpowiednie konstrukcje ich odpowiednikami w 6502, tam gdzie nie da sie nic dopasowac - tlumaczymy pojedyncze rozkazy, ale staramy sie raczej nawet dwu, trzy-rozkazowe zlepki przetlumaczyc w calosci. Do tego DL dla antica jak w spectrum i troche rekodziela zapewne i moznaby przerabiac gry - i w zasadzie tylko o to chodzi.
W sumie najwazniejsze w takiej analizie jest rozpoznanie i oddzielenie danych od programu.

P.-S. Emulacja ZX81 bylaby mozliwa, bo to straaaasznie powolny komputerek, cale wyswietlanie obrazu robi tam procesor (prawie jak w Atari 2600 :) , ale jeszcze wolniej).

Pamietaj ze w tym o czym pisze, nie ma aktualizacji PC w Z80, operujemy przeliczonymi juz adresami na Atari (dlatego jest to powtorna kompilacja), nie wspomne juz o braku petli interpretujacej kod Z80, bo tego kodu tam nie bedzie, pozostac maja tylko dane, na ktorych operowal bedzie natywnie 6502. Stawiam ze byloby to kilka (a przy duzej bibliotece procedur i dobrej optymalizacji kilkanascie) razy szybsze od emulacji.

Niestety w takim wypadku odpadaja wszelkie tablice skokow, czy tez samomodyfikujacy sie kod.
Z tablicami mozna sobie poradzic interpretujac rozgazy skoku wzglednego jako skok do wielkiej tablicy umieszczonej w calych 64kb pamieci dodatkowej, w ktorej zapisane beda adresy w ktorych znajduja sie przetlumaczone juz na 6502 procedury (tworzona w czasie kompilacji). Drugie rozwiazanie to ostrzeganie swiadomego uzytkownika takiego kompilatora i zmuszenie go do analizy kodu w tym miejscu i recznego przygotowania nowej tablicy skokow (oczywiscie wyliczenie adresow pozostaje w gestii kompilatora.
W sumie jest to wykonalne, ale przy kazdym przerabianym programie bedzie wymagalo niemalych interwencji czlowieka, ktory musi znac i Z80 i 6502. Tyle ze efekt moze byc fajny :)

jest tam taka masa rejestrow ze automodyfikacja raczej nie byla by potrzebna... chociaz...

Sprawdzenie tego w zasadzie nic nie kosztuje, to groszowa oszczędność.

No, wiadomo, że na 65816, przy liniowym RAM-ie i z wykorzystaniem nowych trybów adresowania, to jest zupenie inna bajka: np. dekodowanie rozkazu się na dzień dobry robi 4 cykle szybsze.

To faktycznie musi bardzo przyspieszać emulację :)

A to jeszcze wiele przed tobą :)

Teoretycznie mogę, ale musiałbym za dużo przerabiać. Mogę ci podać wynik w ramkach VBL, ale do tego przydałoby się, żeby pętla wykonywała się większą liczbę razy (np. kilkadziesiąt tysięcy razy) dla lepszej dokładności.

Nie bardzo rozumiem, po co ładujesz 7 do rejestru B.

Ja - jak wiesz zresztą - testuję na czymś takim (przytaczam z pamięci):

    ld HL,$ffff
    ld A,$3f
loop:
    ld (HL),$00
    dec HL
    cp H
    jr NZ,loop

Ta pętla wykonuje się 49152 razy zerując pamięć od $FFFF do $4000. Atarynce wykonanie tego zabiera 496 ramek. Rozkazy ustawiają wszystkie oficjalne flagi Z80, nieoficjalnych przeważnie nie.