Benchmark ZX81

[zipp]

TS1000 po przełączeniu na PAL wykonuje test o 1/3 szybciej w trybie SLOW, czyli w takim samym czasie jak ZX81.
Testowane bez i z pamięcią zewnętrzną (TS1016 i ZXpand).

[PABB]

... tak dla sportu zrobiłem test na ZXMore V2 - w dwóch trybach 3.25MHz i 6.5 MHz. Byłem przekonany, że nie zdążę nawet włączyć stopera, ale ZXMore pokazał mi środkowy palec

Tryb ZX81 (3.25MHz) - 2:24:9
Tryb ZX81 (6.5MHz) - 1:10:49

Różnica wydajności wydaje się wynikać z różnicy w zegarze...

Próba uruchomienia trybu SLOW/FAST kończy się odpowiednio... niczym (SLOW) lub wyłączeniem obrazu (FAST)

[KWF]

W trybie FAST nie ma odświeżania obrazu, aż do końca wykonania programu.

ZX81 więc i ZXmore włączają tryb SLOW jako domyślny, po teście pamięci po starcie/reszcie ZX81. W skrócie ZX81 startuje w trybie FAST, wykonuje test RAMU, przełącza się w tryb SLOW i wyrzuca kursor "K" na ekran. Włączając tryb FAST należy uzbroić się w cierpliwość. Odpalić stoper i czekać Swoją drogą, to zjawisko można wykorzystać jako tester ZX81.

Dla posiadaczy ZX81 i TS1000 jest jeszcze jedna opcja zyskania dodatkowych 10%. Polega ona na eliminacji wstrzymania Z80 (/WAIT) przy każdym wywołaniu /NMI. Potrzebny jest dodatkowy  tranzystor PNP (BC558B/C czy 2N3906) oraz rezystor 10k. Modyfikacja nosi nazwę "no-wait".

Inna możliwością jest tzw. Clock Doubler, automatycznie włączając się (Z80 taktowany x2) kiedy tylko można. Do jego zbudowania potrzeba ok 8 układów TTL. Moim zdaniem gra nie jest warta świeczki.

[romeks]

Po rozbudowie do 16 kB.
SLOW 180 sek.
FAST 45 sek.

[ZbyniuR]

Dopiero teraz do mnie dociera że jest coś takiego jak FAST i SLOW w ZX81, i zastanawia mnie w jakim trybie był robiony test liczb pierwszych w BASICu z tego wątku:

http://www.speccy.pl/forum/index.php?topic=2715.msg37814#msg37814

Można by w linii 70 dopisać średnik na końcu, aby więcej liczb zostało na ekranie.

[KWF]

Dopiero teraz do mnie dociera że jest coś takiego jak FAST i SLOW w ZX81, i zastanawia mnie w jakim trybie był robiony test liczb pierwszych w BASICu z tego wątku:

http://www.speccy.pl/forum/index.php?topic=2715.msg37814#msg37814

Można by w linii 70 dopisać średnik na końcu, aby więcej liczb zostało na ekranie.

W trybie "SLOW", czyli z odświeżaniem ekranu.

[ZbyniuR]

Czyli podsumowując:
FAST na PAL i NTSC są równie szybkie.
SLOW na PAL jest 4 razy wolniejszy niż FAST.
SLOW na NTSC jest 6 razy wolniejszy niż FAST.
z większym RAMem w obu trybach jest o ok 63% wolniej niż z małym. (czyli razy 1.63)

Pierwsze słyszę by komp w NTSC był wolniejszy niż w PAL, albo by dodanie pamięci go spowalniało.
Jak to wytłumaczyć?

[matofesi]

@ZbyniuR Co do pamięci się nie wypowiem, ale różnica między SLOW w PAL i NTSC jest prosta do wytłumaczenia - w NTSC masz większą częstotliwość odświeżania a co za tym idzie procesorowi w ciągu sekundy znacznie więcej czasu zajmuje "narysowanie" ekranu. Tryb SLOW działa w ten sposób, że na wykonanie programu zostaje ten kawałek czasu, kiedy procesor nie "odrysowuje" ekranu, czyli zasadniczo górna i dolna ramka. Można by kombinować i przeliczać dokładnie jaka jest różnica w długościach, ale podejrzewam, że wynik będzie zbliżony do tego co tu zostało zaobserwowane

[KWF]

A to nie tak, że ULA "rysuje" ramki na podstawie danych odczytanych przez procesor, a procesor w nagrodę jest karmiony NOP-ami? W każdym razie, tworzenie obrazu zostawia niewiele czasu na coś uzytecznego.

[matofesi]

ULA rysuje, ale procesor w odpowiednim tempie musi dostarczać dane. Kiedyś przejrzałem sobie dokładnie kod w ROMie i wydawało mi się, że rozumiem całą procedurę, ale to było dawno Istotne jest to, że w trybie SLOW dla programu użytkownika zostaje bardzo mało czasu bo procesor robi co innego

[KWF]

Sposoby przyspieszenia ZX81 zostały opisane na tej stronie: Sinclair ZX Specifications

A różnice pomiędzy NTSC (32 scalelines) i PAL (56 scslelines) wynikają z ilości generowanych linii. W skrócie im ich mniej, tym wolniej działa cały ZX81.

[ZbyniuR]

To ostatnie zdanie jak dla mnie zdaje się nie mieć sensu.

W innych komputerach w NTSC częstotliwość odświeżania się zwiększa, ale też zwykle ilość wyświetlanych linii się zmniejsza, akurat o tyle że w ciągu sekundy komputer i tak wysyła w ekran taką samą ilość danych.

W ZX81 jak rozumiem w obu systemach wysyłanych linii jest tyle samo, ale w NTSC musi je wysyłać z większą częstotliwością aby odbiorniki które "łapią" tylko taką potrafiły wyświetlić obraz. Chociaż ta częstotliwość rośnie o 20% a nie aż o 50% jak wynika z testów. Więc może faktycznie zrobiono to na ostatnią chwilę i ratowano się NOP-ami (jak tu ktoś wspomniał), tak aby takty się zgadzały i dobrze to zsynchronizować.

[zipp]

http://problemkaputt.de/zxdocs.htm#zx80zx81videodisplaytimings

Dla programu w PAL jest dostępnych 54*2 linii, dla NTSC 30*2 lini
i wszystko się zgadza.

[KWF]

Moze to Ci rozjasni:

Resulting User Available CPU Time
  SLOW, 50Hz Effective Speed  0.804600 MHz (54*2*149 cycles, 50 frames) (ori)
  SLOW, 50Hz Effective Speed  0.896400 MHz (54*2*166 cycles, 50 frames) (tuned)
  SLOW, 60Hz Effective Speed  0.536400 MHz (30*2*149 cycles, 60 frames) (ori)
  SLOW, 60Hz Effective Speed  0.597600 MHz (30*2*166 cycles, 60 frames) (tuned)
  FAST, Total CPU Speed       3.250000 MHz (display disabled)

[matofesi]

No właśnie... wiedziałem, że gdzieś gra, ale nie pamiętałem dokładnie gdzie

A tu można przeczytać dokładny opis procesu generowania obrazu: http://eduinf.waw.pl/inf/retro/003_zx81_tv/index.php