ZX Spectrum > SOFTWARE

Z80 profiler

<< < (5/7) > >>

ssr86:
Do Enterprise... Gdy jakiś czas temu pytałem autora emulatora jak można to sobie liczyć to otrzymałem poniższą informację:

--- Cytuj ---Wait states generated by DAVE (if enabled on port BFh) are simple, they add 1 cycle to all memory accesses (00h) or only M1 reads (04h). The latter are the first byte of simple instructions with no prefix, or the first two bytes with CB/DD/ED/FDh prefix. Also, according to tests by Zozosoft, it seems that DAVE waits 2 cycles on turbo machines. But in programs where speed is important, wait states are disabled, so all the above does not matter.

Video memory and NICK I/O port timing are more complex: within each 889846 Hz "slot" (1 character), the Z80 is allowed access to one byte at a specific time, and it always needs to wait at least a certain amount of time (a few ns more than 5/16 of a character, and there is also few ns difference depending on the type of access - normal memory, M1 memory, and I/O). This is implemented by the NICK chip halting the Z80's clock, which it can do in 1/2 clock cycles (1/8000000 s on normal non-turbo machines). There is a test run on real machines here that measures the average time between video memory accesses at various intervals in Z80 cycles.

For the calculations in the sprite code, I used a simplified model: add 1.5 cycles to the time between the video memory accesses, and then round up the result to an integer multiple of 4.5 cycles, and that is the real amount of time, with the wait states (stopped Z80 clock) added. In other words, the best case is 1.5 cycles of wait, and the worst case is 5.5 cycles. This is not entirely accurate, but it gives a reasonable estimate.

When calculating video memory timing, it should also be taken into account exactly when the accesses occur within the instruction. This can be found in the Z80 documentation. For example, an LD (HL), A instruction is two memory accesses, an M1 read at 2 cycles, and a normal write at 6.5 cycles.

--- Koniec cytatu ---
Chodziłoby o opóźnienia związane z dostępem do pamięci wideo.

Dr Piotr:

--- Cytat: ssr86 w 2016.01.22, 10:05:30 ---Do Enterprise... Gdy jakiś czas temu pytałem autora emulatora jak można to sobie liczyć to otrzymałem poniższą informację:

--- Cytuj ---Wait states generated by DAVE (if enabled on port BFh) are simple, they add 1 cycle to all memory accesses (00h) or only M1 reads (04h). The latter are the first byte of simple instructions with no prefix, or the first two bytes with CB/DD/ED/FDh prefix. Also, according to tests by Zozosoft, it seems that DAVE waits 2 cycles on turbo machines. But in programs where speed is important, wait states are disabled, so all the above does not matter.

Video memory and NICK I/O port timing are more complex: within each 889846 Hz "slot" (1 character), the Z80 is allowed access to one byte at a specific time, and it always needs to wait at least a certain amount of time (a few ns more than 5/16 of a character, and there is also few ns difference depending on the type of access - normal memory, M1 memory, and I/O). This is implemented by the NICK chip halting the Z80's clock, which it can do in 1/2 clock cycles (1/8000000 s on normal non-turbo machines). There is a test run on real machines here that measures the average time between video memory accesses at various intervals in Z80 cycles.

For the calculations in the sprite code, I used a simplified model: add 1.5 cycles to the time between the video memory accesses, and then round up the result to an integer multiple of 4.5 cycles, and that is the real amount of time, with the wait states (stopped Z80 clock) added. In other words, the best case is 1.5 cycles of wait, and the worst case is 5.5 cycles. This is not entirely accurate, but it gives a reasonable estimate.

When calculating video memory timing, it should also be taken into account exactly when the accesses occur within the instruction. This can be found in the Z80 documentation. For example, an LD (HL), A instruction is two memory accesses, an M1 read at 2 cycles, and a normal write at 6.5 cycles.

--- Koniec cytatu ---
Chodziłoby o opóźnienia związane z dostępem do pamięci wideo.

--- Koniec cytatu ---
Ten opis zawily troche jest, jakbys zorganizowal taka tabelke:
|start address|end address|M1 delay|read delay|write delay|io read delay|io write delay|
To moglbym sprobowac to podlaczyc.

Dr Piotr:
Zrobilem w weekend nowa wersje:
- laduje i wykorzystuje liste zmiennych, generowanych z assemblerow: maxam/winape, pasmo, sjasmplus
- opcja -d - tylko deasemblacja bez profilowania.
- opcja -t - wyswietlanie instrukcji w trakcie ich wykonywania
- opcja -ll - wyswietla liste wszystkich etykiet, zarowno tych wczytanych jak i automatycznie wygenerowanych w trakcie wykonywania

Nastepna wersja bedzie wczytywac pliki .cdb z kompilatora sdcc.
W kolejce czeka UI na windows, pluginy dla roznych procesorow, breakpointy itp :)

Dr Piotr:
Nowa wersja beta, teraz juz jako The Profiler :)

- wersja UI dla windows xp/7/8/10
- ladowanie plikow bin oraz .cdb (sdcc)
- ladowanie plikow z symbolami w formatach

* maxam/winape
* pasmo
* sjasmplus
* noGMB- obsluga wielu procesorow (kazdy procesor jako osobny plugin)

* profiler
* symulator/debugger
* disassembler
* monitor pamieci- wbudowany jezyk skryptowy

* programowalne definiowanie urzadzen (procesor, pamiec ram/rom, porty wejscia) 

* oprogramowanie obslugi np portow wejscia/wyjscia, ekranu, interpretacji pamieci itp.

pear:
Fajny kombajn  8)

Nawigacja

[0] Indeks wiadomości

[#] Następna strona

[*] Poprzednia strona

Idź do wersji pełnej