Dlaczego C64 jest aż tak wolny?

[hobocti77x_]

Przy okazji naprawy karty w Apple II postanowiłem zrobić mały test porównawczy szybkości C64 i Apple II+ (dokładnie Apple II Europlus, to taka wersja Apple II+ pracująca w systemie PAL, przez co ma nieco niższą częstotliwość CPU).
Oba komputery mają zbliżoną częstotliwość zegara CPU oraz podobny, przynajmniej w budowie wewnętrznej, BASIC Microsoft.
Test jest bardzo prosty:

Kod: Zaznacz cały

10 FOR A=1 TO 1000
20 PRINT a*2
30 NEXT A

A teraz czas na wyniki. Dodam tylko, że testy przeprowadziłem na real Apple II+ i emulatorze VICE, dodatkowo użyłem emulatora Atari z ustawieniami 1.8 MHz:
Applesoft BASIC - 23 sek.
ATARI - 27 sek.
C64 - 48 sek.

W przypadku C64 ustawienie na NTSC w wyniku zmienia niewiele ok.1 sek.
Jaka moze byc tego przyczyna ?

[Steffan]

Sama pęta leci szybko, mnożenie też nie wykonuje się długo. PRINT jest kur...o wolny.
Czemu? Zapytaj the Billa.

pozdro
Steffan

[hobocti77x_]

Ja bym do tego Billa nie mieszal. Zreszta wszystkie 3 BASIC-y sa od niego a apple i comodore nawet z tego samego zrodla skompilowali
W dodatku Bill chyba chcial nawet ratowac sytuacje umieszczajac proc CHRGET na stronie zerowej w c64.
Zreszta zrobilem test tez na IntBASIC (ten z pierwszej wersji AppleII autorstwa Wozniaka) i wynik jest jedynie o jakas 1 sek lepszy 22 sek.

Ja bym tu bardziej wine upatrywal w powolnosci wyswietlania trybu tekstowego ,rozwiazaniu klawiatury , ciaglych przerwaniach oraz w KERNAL.

[hobocti77x_]

Przy okazji zrobilem jeszcze testy pod VICE na PET 1 sek. zabraklo do pelnej minuty , i VIC-20 i tu mile zaskoczenie wyrobil sie w ok. 30 sek. czyli tylko nieco wolniej niz atari z 1.8 MHz.

[thevoid]

A czy to nie jest tak, że tam wchodzi scroll ekranu i to on tak na prawdę jest wolny? C64 ma 2x tyle do przescrollowania, bo jeszcze Color RAM.

[Gordian]

A czy to nie jest tak, że tam wchodzi scroll ekranu i to on tak na prawdę jest wolny? C64 ma 2x tyle do przescrollowania, bo jeszcze Color RAM.

Potwierdzam. Bez scrolla całość wykonuje się w 15 sekund.

Taki kod na szybko:

Kod: Zaznacz cały

10 REM FOR I=40960 TO 49151: POKEI,PEEK(I): NEXT
20 REM FOR I=57344 TO 65535: POKE I,PEEK(I): NEXT
30 REM POKE 1,53
40 REM POKE 59626,96

50 LET T=INT(TIME/60)
60 FOR A=1 TO 1000
70 PRINT A*2
80 NEXT A
90 PRINT "END";INT(TIME/60)-T;

Linie 10-40 kopiują BASIC i KERNAL oraz dopisują RTS w punkcie wejścia procedury przewijania ekranu (więc nie wykonuje się). Aby sprawdzić PRINT bez scrolla należy oczywiście je "odremować".

[hobocti77x_]

Scroll to jednak chyba extremalny przypadek, ale zrobilem cos takiego
dodalem:

Kod: Zaznacz cały

15 PRINT CHR$(145);

20 sek to wychodzi ze linia 15 wykonuje sie przez 5 sek. A wlasciwie to dluzej bo jeszcze odpadl czas scrolla.

[hobocti77x_]

Zrobilem nowy test .
Program rysuje fraktala i w sumie latwo uruchomic go na kazdym 8-bitowcu.
w zalaczniku plik zrodlowy w BASIC

MALDERBROT.zip

(785 Bajtów) Pobrany 150 razy

Na c64 (tak samo appleII) najlepiej zmienic linie na :

Kod: Zaznacz cały

250 W=39

i skasowac linie 480
linie 290 i 510 zmienic dla c64 lub skasowac i zmierzyc czas np. z zegarkiem
Generalnie scrolli jest 64 i nie powinny znaczaco wplynac na szybkosc.
Wyniki
c64 : 15 min.
appleII+: 12min 46 sek.
Wiec hamulcowych jest wiecej

[Gordian]

Scroll to jednak chyba extremalny przypadek [...]

No chyba nie, skoro w Twoim pierwszym przykładzie jest prawie 1000 scrolli.

Generalnie scrolli jest 64 i nie powinny znaczaco wplynac na szybkosc.

Jeden scroll to 532 linie ekranowe=33516 cykli=0,034s
64 scrolle to ok. 2,18s
1000 scrolli to ok. 34s

Są na pewno inne procedury spowalniające, np. parsowanie zmiennych czy odczyt klawiatury.

[hobocti77x_]

Jeden scroll to 532 linie ekranowe=33516 cykli=0,034s
64 scrolle to ok. 2,18s
1000 scrolli to ok. 34s

Są na pewno inne procedury spowalniające, np. parsowanie zmiennych czy odczyt klawiatury.

A różnica w czasie wykonania programów na Apple II i C64 wynosi ponad 2 minuty. I dlatego mi to nie pasuje.
Zresztą Apple i C64 w zasadzie przewijają ekran w podobny sposób.
Nakręciłem filmik z wykonania fragmentu programu, który załączyłem. Wykonuje się on pod VICE, w ustawieniu procesora na 1% i widać, że samo przewinięcie ekranu jest szybkie, a dodatkowo że na pewno nie jest użyte przewijanie sprzętowe, tak że do przerzucenia jest jedynie 25 linii tekstu (na apple2 - 24)

Record_2.zip

(1 MiB) Pobrany 146 razy

[Gordian]

A różnica w czasie wykonania programów na Apple II i C64 wynosi ponad 2 minuty. I dlatego mi to nie pasuje.

Wyszedłeś od przykładu z FOR i PRINT gdzie jasno widać, że problemem jest przewijanie ekranu.
W programie rysujący Mandelbrota PRINT stanowi drobną część całości czasu wykonywania - jest sporo mnożeń i pewnie one zajmują jeszcze więcej czasu.

[Cyprian]

Przy okazji naprawy karty w Apple II postanowiłem zrobić mały test porównawczy szybkości C64 i Apple II+ (dokładnie Apple II Europlus, to taka wersja Apple II+ pracująca w systemie PAL, przez co ma nieco niższą częstotliwość CPU).
Oba komputery mają zbliżoną częstotliwość zegara CPU oraz podobny, przynajmniej w budowie wewnętrznej, BASIC Microsoft.
...
Jaka moze byc tego przyczyna ?

myślę że bardziej miarodajny test byłby w ASMie, teraz mierzysz wydajność BASICa

[hobocti77x_]

Moim zdaniem myślę, że jednak mierzę wydajność komputera, a nie tylko BASIC-a.
Jak już pisałem, BASIC Commodore i Applesoft BASIC generalnie są bardzo podobne.
Oba są generowane z tego samego kodu źródłowego.
https://github.com/mist64/msbasic
W Apple są co prawda dodane procedury dla grafiki, ale obliczenia i podstawy BASIC są w zasadzie takie same. Różnice dotyczą raczej systemu operacyjnego obsługującego specyficzne rozwiązania w obu komputerach.
W dodatku Apple ma z zasady szybszy zegar:
Dla C64
PAL: 17734472/18 Hz = 985248 Hz
NTSC: 14318181/14 Hz = 1022272 Hz
W Apple II
NTSC: 14318181/14 Hz = 1022272 Hz
PAL: 14250000/14 Hz = 1017857 Hz
Dodatkowo w C64 VIC w trybie tekstowym wykrada ponad 50,000 cykli. W Apple II układ graficzny nie potrzebuje dodatkowych cykli w zadnym trybie wyswietlania .
Co interesujące, w C64 linia ekranu trwa 65, 64 lub 63 cykle, zależnie od wersji VIC i systemu TV, w Apple linia zawsze jest równa 65 cyklom niezaleznie od systemu TV.
Z tego powodu nie bardzo widzę, jaki sens miałoby porównywanie szybkości ASM.
Choć jeśli kolega zaproponuje jakiś ciekawy test, to chętnie sprawdzę.

[t0m3000]

dla mnie to porownywanie jablek z gruszkami

[mono]

Nie wiem, jak na Apple, choć spodziewam się że podobnie jak na Atari gdzie kod jest stokenizowany - rozkazy, funkcje, zmienne, a liczby przetworzone do FP (6 bajtów). Komodor argumenty ma nieprzeparsowane więc podczas wykonywania kodu PETSCII musi być przetworzone do FP dodatkowo. Jak @Cyprian mówi - mierzysz wydajność BASIC-a a nie komputera.
Przykładowy klasyczny 2024 SYS 2062 wygląda tak:

Kod: Zaznacz cały

        .word 2024
        .byte $9e       ;SYS
        .byte ' 2062',0

[hobocti77x_]

Jak pisalem w AppleII kod BASIC jest stokenizowany tak samo jak w C64.
Ba nawet niektore Tokeny sa takie same
https://www.callapple.org/vintage-apple ... ft-tokens/
https://www.c64-wiki.com/wiki/BASIC_token
Zakodowany przyklad ktory podales wyglada w Apple niemal identycznie:

Kod: Zaznacz cały

;2064 CALL 2064

$E8 07	;2064
8C		;CALL
$32 30 36 32 00 00 00	

[mono]

Ciekawe. Może pakiet matematyczny?

[hobocti77x_]

Wedlug informacji tutaj
https://github.com/mist64/msbasic
i tutaj
https://www.pagetable.com/?p=46
Obie wersje wywodza sie z tej samej wersji MBASIC_2

AppleSoft II (2.0) AppleSoft II to najstarsza wersja Microsoft BASIC 2. Dostępna była na taśmie lub dysku, a także w pamięci ROM w późniejszych modelach Apple II. Jest to pierwszy BASIC od producenta OEM, który rozszerzył BASIC i został ponownie zsynchronizowany z bazą kodu Microsoftu. Innymi słowy: Apple udzielił licencji na ulepszoną i poprawioną wersję BASIC-a i połączył z nią swoje stare zmiany. BASIC 2 zawiera głównie poprawki błędów (w końcu wyeliminowano wszystkie błędy związane z lokalizacją bufora wejściowego), drobne optymalizacje (ponowne użycie dwóch sąsiednich zer wewnątrz stałej zmiennoprzecinkowej 1/2 jako 16-bitowej stałej zera zamiast układać je osobno), naprawiono błąd obsługa DEF FN i obsługa „GO TO” ze spacją pomiędzy nimi jako synonim GOTO. Zmieniono także wzór testu pamięci z $92/$24 na bardziej standardowy $55/$AA. W AppleSoft II firma Apple wyeliminowała także kwestie „rozmiaru pamięci” i „szerokości terminala”.

Commodore BASIC 2 (2.0a) Podobnie jak Apple, Commodore zwrócił się do Microsoftu po zaktualizowaną wersję BASIC-a i zintegrował wprowadzone zmiany w nowej wersji. Wersja, którą otrzymali, była nieco nowsza od wersji Apple.
Microsoft dodał jajko wielkanocne „WAIT 6502”. W tym celu zmienili kodowanie ciągu „MICROSOFT!” który był ukryty w każdym BASIC-u od wersji 1.1 z XORed ASCII do PETSCII z losowo ustawionymi dwoma górnymi bitami - w ten sposób tekst byłby równie zaciemniony, ale dekoder byłby krótszy w systemach PET. Zatem Commodore BASIC 2 jest jedyną wersją Microsoft BASIC, która kiedykolwiek uzyskuje dostęp do tego ukrytego tekstu.

Microsoft dostarczal 2 rozne zestawy funkcji matematycznych tz. MBF single-precision format (32 bits, "6-digit BASIC" lub
MBF extended-precision format (40 bits, "9-digit BASIC")
W obu komputerach zastosowano MBF extended-precision format (40 bits, "9-digit BASIC")

[hobocti77x_]

Przeprowadziłem małe doświadczenie, tym razem na emulacji w VICE.
Zasymulowałem 50 razy przejście przez IRQ w c64 i policzyłem cykle procesora.
Wynik jest zaskakujący. Zakładam, że VICE zlicza tylko cykle użyteczne CPU bez waitów.
W załączniku otrzymane wyniki.

PALlog.zip

(973 Bajtów) Pobrany 135 razy

Jeśli teraz odejmiemy 13342337-12521234, to otrzymamy, że 6510 potrzebował na to 821103 cykle.
(W tym czasie nie byla uzyta klawiatura)
Nie wiem, czy VICE dodaje, czy nie waitstaty spowodowane np. przez BAD lines, w takim razie je dodam, jest 25 bad lines x 43 cykle x 50 Hz, to daje 53750 wait states.
Czyli w sumie mamy 821103 + 53750 = 874853.
Czyli wychodzi, że c64 faktycznie działa z częstotliwością ok. 0,875 MHz
Czyzby po to byl ten wielki trymer przy kwarcu ?
No moze minmalnie wyzsza bo zamiast 50Hz faktycznie jest nieco wiecej.

[hobocti77x_]

Wygląda ze popełniłem błąd w obliczeniach. Zapomniałem, że przerwanie IRQ wykonuje się 60 razy na sek.
W takim razie wychodzi, że w tym czasie procesor wykona 985321-53750=931571 użytecznych cykli.
Z tego spora część idzie jeszcze na przerwania i obsługę klawiatury.

W każdym razie to i tak ok. 80 tys. cykli/sek mniej niż wykona Apple II.

W Apple II odczyt klawiatury sprowadza się do pobrania znaku ASCII bezpośrednio z bufora klawiatury $C000.
Nie trzeba niczego przeliczać.
Dodatkowo OS w apple wogole nie potrzebuje przerwan do dzialania.

logPAL60Hz.zip

(1.05 KiB) Pobrany 151 razy