Ja (jak już niektórzy wiedzą) od czasu sztabu wyszedłem nieco poza same przemyślenia. Konkretnie napisałem trochę kodu - i rezultat jest niezadowalający. Zresztą chyba pirx doszedł już przedtem do takich samych wniosków.

To co zrobiłem, to emulator "klasyczny" (z pętlą interpretującą kolejne rozkazy). 64k pamięci Z80 to cztery (z pięciu) banków pamięci znajdujących się w 130XE pod adresami $4000-$7FFF. Maszyna emulowana to ZX Spectrum, więc w jednym z banków jest ROM systemu operacyjnego, w pozostałych RAM (łącznie z pamięcią obrazu).

Sekwencja dekodująca opkod ma w "best case" 9 rozkazów 6502 zajmujących 32 cykle (worst case jest dużo gorszy - 15 rozkazów, 54 cykle - ale występuje tylko w 0,94% wszystkich przypadków). Tyle dokładnie czasu wykonuje się NOP. NOP na Z80 zajmuje 4 cykle, a że Spectrum ma zegar 3,5 MHz, więc te 4 cykle trwają tyle, co dwa na Atari. Ergo, taki NOP wykonuje się idealnie z wydajnością 6,25% oryginału, a w rzeczywistości - ze względu na działalność Antica - nieco ponad 4%. Taką też szybkość - 4% oryginału - rozwija ZX OS przy początkowym zerowaniu pamięci. I nie sądzę, żeby tą metodą się dało wycisnąć wiele więcej.

Jak o tym była mowa na sztabie, rozwiązaniem może być JIT.

O tym też była mowa na sztabie - nie wiadomo, czy się to opłaci, bo pytanie brzmi, czy na ZX80/81 istnieje jakiś program, dla którego warto byłoby uruchamiać emulator; że o pisaniu nie wspomnę.

Poza tym spektruś jest naprawdę bardzo prosty: składa się z Z80, 64k pamięci oraz układu ULA, który ma *jeden* rejestr sprzętowy (port 254). W związku z tym emulator zawiera kod emulujący rozkazy Z80 (z czego rozkazy IN i OUT emulują wspomniany rejestr), tablice służące do adresowania RAM-u, Display List i ... nic poza tym.

Hm, wydawało mi się, że nie chcesz pisać po to, żeby używać, tylko żeby pokazać, że się da lub dla "dobra narodu i partii" :)

xxl: 32-54 cykle, jak napisałem, to dekodowanie opkodu, bez wykonania rozkazu (chyba, że to NOP, który nic innego więcej nie robi).

ld r,$xx u mnie to 32 cykle na dekodowanie + 19 na wykonanie, razem 51 - znowu, najszybszy przypadek (best case). Najgorszy: 54 cykle dekodowania + 19 wykonania (73), albo 32 cykle dekodowania + 41 wykonania (też 73).

Przypominam, że u mnie emulowany Z80 ma całe 64k pamięci. :)

No, ale dobrze by było, żeby było też choć trochę używalne przy okazji, nieprawdaż? ;) Poza tym poczytałem o ZX80/81 w wikulcu i nie wiem, czy to nie cięższy przypadek niż ZX Spectrum - w spektrusiu ULA tworzy obraz, więc da się do tego łatwo zatrudnić Antica i sprawa jest z głowy. A w ZX80/81 obraz wytwarza Z80 ... :)

PC aktualizowany jest przy dekodowaniu, a potem przy wykonywaniu też, jeśli to potrzebne.

Co do najdłuższego rozkazu, to trudno orzec. Np. pozornie prosty rozkaz LD I,A zajmuje bardzo dużo czasu, bo ma prefiks, a prefiks dorzuca do czasu wykonywania rozkazu od 34 do 56 cykli. Czyli mamy w najlepszym przypadku 32 dekodowanie + 34 prefiks + 9 wykonanie = 75 cykli. W najgorszym - 22 więcej (97).

JR NZ,disp:

* niewykonany: 32+19, 32+41 albo 54+19 cykli
* wykonany wstecz na tę samą stronę: 32+36 cykli
* wykonany wstecz na inną stronę: 32+55 cykli
* wykonany w przód na tę samą stronę: 32+37 cykli
* wykonany w przód na inną stronę: 32+56 cykli

LD (HL),$xx:

* niewykonany (adres wskazuje ROM): 32+32, 32+54 albo 54+32 cykle
* wykonany: 32+67, 32+89 albo 54+67 cykli

EDIT: policzyłem od nowa czasy ostatniego rozkazu.

48 cykli na NOP-a = dużo. U mnie, gdyby nie konieczność bankowania pamięci, maximum byłoby 36 cykli. Tak samo przy ld (HL) - sprawdzenie, czy ROM, kosztuje 12 cykli (EDIT: jednak 4 :)); a jak nie ROM, to pamięć trzeba przełączyć dwa razy. No i tak to idzie.

duzo bo procka aktualizujaca pc wyglada tak:

clc
lda pc
adc #1
sta pc
lda pc+1
adc #0
sta pc+1

ale moze wygladac rowniez tak:

inc pc
bne end
inc pc+1
bpl end (32 kb ramu)
asl pc+1
end

a wtedy z 18 cykli robi sie od 8, bardzo rzadko 15 a w szczegolnym przypadku 19 co daje -10 cykli na interpretacji prawie kazdego rozkazu

To jest właśnie JIT (patrz posty wyżej). http://en.wikipedia.org/wiki/Just-in-time_compilation

No, dobrze, ale gdzie tu zalety uproszczonej organizacji RAM-u, skoro oszczędności w porównaniu do wersji 64k (bankowanej) są groszowe albo żadne (istotna różnica jest tylko przy przekraczaniu granicy stron, co występuje bardzo rzadko)? Chyba tylko tyle, że uruchomienie emulca nie wymaga 130XE.

A na dodatek weź pod uwagę, że przy zajęciu 32k na pamięć emulowanego procesora masz spore szanse, że program emulatora nie zmieści ci się w pozostałym obszarze - Z80 ma dobrze ponad 500 rozkazów :)

BTW. zredukowałem dekodowanie do 29 cykli w najczęstszym przypadku (max. 51).

Prawie nic. U mnie dekodowanie wygląda tak:

nop lda (epc),y
    tax
    lda zzlo,x
    sta ?jp+1
    lda zzhi,x
    sta ?jp+2
    iny
    bne ?jp
    inc pc+1
    ldx pc+1
    lda hicon,x
    sta epc+1
    lda mbank0,x
    sta portb
?jp jmp $ffff

sorry, ale LD (HL),$xx nie chce mi się przepisywać ... :) mniej więcej to samo jest u ciebie, tylko w moim jest bankowanie RAM-u. No i lepsze wykorzystanie rejestru Y.

W tej, co ja mam, jest ich 564. Ale podobno są też jakieś nielegalne.

Mylisz się :)

Fakt, można to jeszcze ciut skrócić. Ale urwanie jednego cyklu z dekodowania przyspiesza moją pętlę testową o sześć ramek - z dobrze ponad pięciuset; a zatem przy skróceniu o 4 cykle pętla przyspieszy o 24 ramki, czyli niecałe 5% (w stosunku do emulatora, bo w stosunku do oryginału - o jakieś dwa promile). Oczywiście, to zawsze jest coś, ale jeszcze trochę mało :)

Czemu? Znasz rozkaz, który po pobraniu opkodu nie wymaga zwiększenia PC?

Patrząc globalnie - z punktu widzenia już zrobionego stronicowania - nie wydaje mi się. Prawdopodobnie nie bierzesz paru rzeczy pod uwagę, zwłaszcza w tym całym LD (HL),n. Zaimplementuj, zdebuguj, pogadamy :)