To może - acz oczywiście, nie musi - zależeć od stylu programowania jednej osoby. Można wsadzić w emulator rozpoznawanie określonych sekwencji, to jest łatwe, problem w tym, żeby wiedzieć, które z nich są typowe dla programowania w Z80, a które przyspieszają tylko jeden program, albo zgoła jeden jego kawałek (natomiast pozostałe zwalniają).

To już nie będzie emulacja, tylko przerabianie.

To załóż nowy topic :) Widać, że xxl-owi chodzi o przenoszenie gierek, a np. draco o napisanie emulatora, na którym będzie działać dowolny program. Ja jestem za tym drugim rozwiązaniem.

Ideę zaproponowaną przez XXLa wcale nie trudno zaimplementować w postaci swoistego JITera (hehe, jestem następny ;P). Mieli byśmy dwie procedury emulujące. Normalną i analizującą. Ta druga obok normalnego wykonywania rozkazów Z80 posiadałaby prosty (i szybki) automat skończony potrafiący rozpoznawać wzorce z biblioteki. Po znalezieniu pasującego wzorca wstawiali byśmy w odpowiednie miejsce patcha (prefix+kod) odpalającego odpowiednik w 6502. Bibliotekę pisałoby się ręcznie, a prosty skrypt mógłby generować na jej podstawie stany wspomnianego automatu, które ładowałoby się do emulatora. Emulując program mieli byśmy opcję przełączania pomiędzy dwiema procedurami emulującymi (bo analizująca jednak byłaby trochę wolniejsza i musiała by być jako opcja, bo nie ma sensu wielokrotnie analizować tego samego kodu).

Musimy tylko dowiedzieć się, które wolne miejsce na pewno są wolne, a nie zajęte przez jakieś używane nielegale.

> Ja nie zauważyłem, żeby na ogólnym tle kodu znajdującego się w ROM-ie Spectrum takie sekwencje występowały jakoś szczególnie często.

oj bardzo czesto i nie koniecznie zwiazane z rysowaniem na ekranie - chociaz w giercach to jest bardzo widoczne i sekwencje sa dluzsze, wracajac do romu trumny pierwszy lepszy wielokrotny przyklad

ld a,r
or r / and r

zerkam teraz na jakies procki z romu ... cale procedurki mozna by bylo zastapic niekiedy.

@laoo no wlasnie nie bardzo automat, a co gdy podmieniany wzor bedzie grafika albo jakimis innymi danymi? po to wlasnie trzeba by bylo robic reczna deasemblacje i tylko kod poddawac patchowaniu.

> Z tego, co mi wiadomo, żadne nie są wolne: "puste" miejsca w tabeli oznaczają rozkazy, które po dodaniu prefiksu działają tak samo, jak odpowiedniki bez prefiksu. Dokumentacja, którą czytałem sugeruje, że bywa to używane do utrudnienia analizy kodu (bo większość disasemblerów się na tym ponoć wykłada).

heh no nie przesadzaj, ile takich programow znajdziesz? 1%? watpie

a co do zajetosci pamieci - nie ma potrzeby implementowania WSZYSTKICH rozkazow, po dekompilacji i wydzieleniu kodu z80 sprawdzamy z czego mozna zrezygnowac a jak jestesmy hardcoreowcami to sprawdzamy na jakich bitach w rej statusu program nie kozysta i zalaczamy wersje rozkazow emulujacych bez ustawiania odpowiednich bitow :D to by bylo cos.

---
@ laoo nie doczytalem Twojej wypowiedzi, teraz ja zrozumialem dopiero. masz racje. nie potrzeba by bylo dekompilacji robic.

XXL: ale analiza będzie on-line podczas wykonywania programu. To samo co przeczyta Z80 przeczyta też analizujący automat więc podmianie będzie ulegał tylko conajmniej raz wykonany kod.
A co do pustych miejsc, to mam nadzieję, że chyba jakieś się znajdzie. Jakiś super nielegal crashujący procesor powinien się nadać, a po nim można zakodować symbol makra.

> To zrób i pochwal się, ile ci to dało :-)

ok. :-)
podaj liczbe cykli wykoania takiego czegos:

ld a,b
or c

a ja pochweale sie ile by to zajelo :-)

> Wystarczy jeden.

masz ambicje zrobic emulator 100%? komus sie to udalo?

> Jak już bystro zauważył dely, ty nie mówisz o emulatorze

tak? to o czym?

@ laoo nie doczytalem Twojej wypowiedzi, teraz ja zrozumialem dopiero. masz racje. nie potrzeba by bylo dekompilacji robic.

> Zob. post #104.

zob. jit ;-)

---

@laoo, co wiecej, mozna by bylo z kodu emulca usunac wszystko nie potrzebne do koncowej emulacji danego programu.

> Zob. post #108 i nie trac watku własnych wypowiedzi.

Tez powinienes przeczytac

> Co do JIT-a, zob. post #3 i #107

obejrzyj tez wiki

idee 'zakumalem' wczesniej, dwa posty temu idea zostala nazwana jit :-)

Trochę wariacki pomysł, ale przedyskutować można w końcu wszystko :) Otóż zamiast pamięć z80 dzielić na 4 banki po 16k można podzielić np. na 16 banków po 4 k, a pozostałe 12k pamięci w banku można przeznaczyć na "dynamicznie ściągane" z repozytorium w innych bankach przekompilowane makra. Wystarczy, że makra będą kodem relokowalnym (teraz o to nie trudno) i automat analizujący kod z80 po napotkaniu fragmentu, który można by zjitować sprawdzałby, czy w aktualnym banku jest obsługujące go makro i jeśli nie, to je ściągał.

Wykorzystując wcześniejszy pomysł można dokonać podziału na rozkazy często i rzadko używane. Obsługa tych często używanych byłaby standardowo w pamięci podstawowej, a te rzadsze byłyby umieszczane w operacyjnej części banku, w którym napotkano dany rozkaz.

Niestety kod byłby niestabilny, bo w najgorszym scenariuszu może zabraknąć pamięci na kod obsługi, ale coś za coś. Można mieć wolną, ale pewniejszą wersję, albo hakerską, ale bez 100% gwarancji, że zadziała :)

Post #104, tym razem ze zrozumieniem (może ty go nie widzisz, ewentualnie nie widzisz w całości?)

Podział jest oczywiście umowny. Zależny jeszcze od tego ile kodu z80 udałoby się zjitować. Jeśli mało, to podział banku pół na pół w zupełności by wystarczył. A może także i to dałoby się skonfigurować podczas działania emulatora? (jak ktoś ma więcej pamięci, to może sobie pozwolić na więcej).

A co do zniknięcia problemu banków, to na dzień dzisiejszy ten problem zniknie tylko dla trzech (?) ludzi, a cała reszta wolałaby jednak wersję na pamięć PORTB (chociaż taki poważny program na pewno przyczyniłby się do produkcji warpów tudzież f7).