Tak właśnie o to chodzi.
Oczywiście masz rację że w wielu przypadkach procedury w ROMach są słabo zoptymalizowane, co nie raz było poprawiane przez zdolnych koderów. A winę za tą powolność ponoszą programiści ROM-ów a nie konstrukcja sprzętu.
Niemniej jednak właśnie z taką postacią Basiców jaka jest w ROMach ludzie się głównie stykali, a to rzutowało na opinie o danej marce.
Nie napisałem że C64 ma kiepski Basic. Słyszałem nawet że w XE mimo szybszego procka Basic jest wolniejszy niż w C64. Ale nie wiem czy to prawda. Prawdą jest natomiast to że w C64 brak komend PLOT i DRAW, a są to jedne z ulubionych komend początkujących basicowców. Samodzielne napisanie takich procedur w kodzie jest dla nich niemożliwe. Brak też LOCATE, (w ZX to chyba PRINT AT), co instrukcja proponuje zastąpić serią kodów sterujących w CHR$, a jest to raczej mało wygodne.
Takie polecenie jest za to w kartridżu. Teraz nie pamiętam czy to był Final czy BlackBox. Sam kiedyś dzięki niej napisałem na C64 Sokobana w trybie znakowym, a gdybym miał się motać z kodami kontrolnymi albo POKE-ami to pewnie bym sobie odpuścił.
Dodatkowe komendy były 1 lub dwu znakowe, a zaczynały się taką strzałką w lewo. Może ktoś kojarzy w czym to było.
Brakowało też paru innych komend zupełnie tak jakby ten Basic był napisany dla kompa co ma drukarkę zamiast ekranu. Na szczęście każdy komodorowiec miał takie rozszerzenie z którym jego basic stawał się całkiem użyteczny. (...)
A co do nazwy wątku to wymyślił go Tygrys gdy wydzielił tą dyskusję z jeśli dobrze pamiętam:
http://speccy.pl/forum/index.php/topic,1106.0.html czyli "ZX vs C64 vs CPC" chyba z obawy że przemieni się we wojnę, a chciał mieć możliwość zamknięcia tematu. Zresztą może to nie głupi pomysł by to porównanie Basiców przenieść do nowego wątku np. "Olimpiada Basiców" hehe
A teraz moja wstępna niedokończona wersja CPC programu testującego:
10 MODE 1:DEFINT a,x,d:t=TIME:FOR a=16384 TO 20480:POKE a+1,PEEK(a):NEXT:t2=TIME:PRINT"peek-poke"(t2-t)/300:END
20 SAVE"16KB",b,&C000,&4000:t=TIME:LOAD"16KB":t2=TIME:PRINT"load 16KB"(t2-t)/300:END
30 CLS:t=TIME:FOR x=0 TO 510 STEP 30:FOR d=0 TO 510 STEP 30:PLOT x,0:DRAW d,350:NEXT:NEXT:t2=TIME:PRINT"plot-draw"(t2-t)/300:END
40 CLS:t=TIME:FOR x=0 TO 510 STEP 30:FOR d=510 TO 0 STEP-30:PLOT x,0:DRAWR d-x,350:NEXT:NEXT:t2=TIME:PRINT"plot-drawR"(t2-t)/300:END
MODE 1 - zmienia tryb graficzny na 320x200 i czyści ekran
DEFINT - zmienia domyślną postać zapisywanych zmiennych liczbowych z REAL zapisywaną w 5 bajtach na INTEGER zapisywaną w dwóch bajtach, co nieco przyspiesza obliczenia które nie wymagają liczb zmienno-przecinkowych. Bez tej komendy musiałbym do zmiennych a,d,x dopisywać %.
TIME - to w CPC zmienna systemowa która "liczy" ile czasu minęło od ostatniego resetu. 300 takich jednostek to 1 sekunda. Jak widać łącznie ze zmiennymi t i t2 używam jej do mierzenia czasu trwania testowanych operacji.
DRAW - to odpowiednik DRAWTO w XE rysuje linię od ostatniej pozycji "kursora pikselowego" do tych podanych jako parametry względem współrzędnych 0,0 które w CPC są w lewym dolnym rogu.
DRAWR - to odpowiednik komendy DRAW w ZX rysuje linię od ostatniej pozycji "kursora pikselowego" do tych podanych jako parametry względem ostatniej pozycji "kursora pikselowego".
Linia 10 przenosi bajt po bajcie dokładnie 4KB, pod adres o 1 większy niż źródło czyli w praktyce zapełni te 4KB+1bajt wartością z pierwszego bajtu.
Linia 20 - nagrywa plik binarny o długości 16KB a potem mierzy jak długo go wczytuje z powrotem. W przypadku CPC pomiar może nie być precyzyjny. Po 1sze CPC nagrywa plikom binarnym nagłówek 128bajtów co przy zaokrąglaniu objętości pliku na dysku w górę do pełnego KB zajmuje 17KB a przy wczytaniu wymaga by odczytał o jeden sektor więcej niż zajmuje 16KB. Po 2ie sterownik stacji w CPC nie ma osobnego procesora w stacji tylko korzysta z procesora głównego i pauzuje na mikrosekundy przerwania procesora w trakcie odczytu danych z dysku w tym także te z których korzysta funkcja TIME, zaniżając nieco ilość sekund potrzebną na wczytanie pliku. Po 3ie plik testowy nagrany na pustym dysku wymaga przy odczycie mniejszej ilości ruchów głowicy miedzy ścieżkami niż na dysku pełniejszym. Po 4te na czas pomiaru wpływ ma także to czy w chwili wydania komendy LOAD dysk już się obraca czy jeszcze nie oraz pod jakim kątem dysk jest obrócony czyli ile mikrosekund potrzeba nim głowica dotrze do odpowiedniego sektora.
Także odczyt pliku z kasety zależy od reakcji człowieka na wciśnięcie klawisza na klawiaturze, oraz od tego jak daleko od początku pliku jest ustawiona taśma. W praktyce każdy pomiar jest nieco inny, ale graniczne przypadki nie przekraczają kilku procent.
Linie 30 i 40 to dwie wersje testu rysujące identyczny wzór, ta druga jest ciut wolniejsza bo w komendzie DRAWR ma odejmowanie w pierwszym parametrze. Liczby współrzędnych są tak duże bo CPC w takiej rozdzielczości na każdy piksel na ekranie ma 4 piksele teoretyczne np 0,0 - 0,1 - 1,0 oraz 1,1 to ciągle ten sam piksel w lewym dolnym rogu. Dlatego w XE i ZX liczby 510, 350 i 30 muszą być zmniejszone o połowę na 255, 175 i 15 aby narysowały tam identyczny wzór. Z tym że linia 30 jest dla XE a 40 dla ZX.
Testy prędkości wyświetlania tekstów, matematyczne, obróbki zmiennych tekstowych, i sortowania z komendami warunkowymi i skoków - są na razie w chmurze moich myśli. Może ktoś mi coś podpowie?
Mam nadzieję że już macie pomysły jak mierzyć czas na swoich platformach i czekam na wyniki testu oraz pytania, uwagi i komentarze.
