A i oto dobry (głupi) przykład na to, iż Epi racji nie ma. Oto program, który może zostać uruchomiony pod
AtariBASIC'em, lecz jeśli zostanie odpalony pod Turbo-BASIC'em zadziała przynajmniej (na oko) 200 razy
szybciej (nawet jeśli się myle o 100 razy). Jest to bardzo extremalny przykład, lecz jest równie głupi, co niektóre tezy postawione przez pewnego tu oto osobnika .. hehe;- ciekawe o kogo chodzi?...
Przyjąłem pewne założenia:
- tzn; iż fakt uruchomienia programu pod T_Basic'em stwierdzam
po sprawdzeniu zawartości komórki $c000 (dec49152) - czy jest to prawda; nie wiem, lecz
akurat w tym domniemanym przypadku nie jest to istotne, a stanowi punkt wyjścia. Cóż - lenistwo RÓLÓ!!!
..... i kawałek szkła... co Jowisz?
- program wykonuje czynność teoretycznie bez sensu, lecz jak widać dobrze ukazuje możliwości
instrukcji MOVE służącej do przemieszczania bloków pamięci (:: mov 65c816?? -> SI??..hmm);
kopiuje $7ff bajtów z adresu adr(a$) do adresu adr(a$)+$800 i odwrotnie.... (czy jakoś tak-
nie chce mi się myśleć...)
i tu zagadka;- jeśli program zostanie wykonany pod AtariBAS. to zostanie wykonany
z kosmiczną prędkością AtariBEJZIKA - czyli do dupy, lecz jeśli będzie to TurboBasic; tu
korzystamy z instr. move- i sytuacja się zupełnie zmienia. Oczywiście łądując wspomniany program
pod kontrolą zwykłego BEJZIKA okaże się, iż w części przeznaczonej dla TB będzie trochę krzaków.
Nie jest to raczej problem, gdyż i tak wspomniana część nie jest uruchamiana.
Epi, wspomniałeś iż twoja wypowiedź dotyczyła użycia 816 od strony kodu zorientowanego w strone
kowoksa .. hehe; - to jeśli w tej sytuacji nie ma korzyści z "nowych" instrukcji "nowego" CPU
to po kiego CH*.* ich używać w tym właśnie momencie? Poza tym wspomniana wypowiedź zabrzmiała
nieco inaczej, niż zapewne chciał jej autor. (jeśli nie rozumiesz przeczytaj raz jeszcze, lub
pomiń ten punkt).
No, to tyle tych smutów, czas na przykładzik. UWAGA! jest po prostu idiotyczny, lecz może ten
fakt komuś coś pomoże.
5 ? CHR$(125)
6 ? :? "A oto i zajebisty przyklad na to,"
7 ? "ze jednak mozna napisac cos co"
8 ? "bedzie dzialac i pod AtariBASIC"
9 ? "jak i pod TurboBAS."
10 ? :? "(c) pin_power_syft, Qurwa 2k3"
12 POSITION 3,10:? "Press START"
15 IF PEEK(53279)<>6 THEN 15
50 DIM A$(4100): IF PEEK(49152)=32:GOTO 90: REM hipoteza na temat wykrycia Turbo_B
65 REM ***************** PROCEDURKA W ATARI BASIC *************************
70 GOSUB 110:POKE 18,0:POKE 19,0:POKE 20,0
72 FOR A=1 TO 100:? A:FOR B=0 TO 2047:POKE AD2+B,PEEK(AD+B):NEXT B
80 FOR B=0 TO 2047:POKE AD+B,PEEK(AD2+B):NEXT B
82 NEXT A:CZAS=PEEK(20)+256*PEEK(19)+65536*PEEK(18):? CZAS:END:REM to na wypadek, gdyby basic okazal sie zbyt powolny..hehe
84 REM ********************************************************************
85 REM ***************** PROCEDURKA W TURBO BASIC XL **********************
90 gosub 110:time$= "000000":for a=%1 to 100:? a:move ad,ad2,$07ff:move ad2,ad,$07ff:next a:czas=time:? time:end
95 rem ********************************************************************
110 ? CHR$(125):AD=ADR(A$):AD2=AD+2048:RETURN
.... nie sprawdzałem części przeznaczonej faktycznie dla ATARIBAS pod nim właśnie - cóż akurat
mam odpalonego kompa do testów - na sztywno 1MB ram, cóż brak bitu od BASICA,.. portb .. bo zjadł go simm.
... i to miało by sens w momencie, gdy w/w proca miała by strategiczny wpływ na szybkość działania całego programu. I tak, jeśli odpalimy to pod AtariBASIC to; wychodzimy na obiad, spacer z psem, czy żoną ... w TB jest inaczej. I właśnie do tego cały czas zmierzam, aby korzystać z nowego CPU tylko tam, gdzie jest to uzasadnione czysta logiką, jednakże jeśli jest to program ogólnie dostępny pewna kultura nakazuje, aby działał też na zwykłej Atarce - i po to właśnie napisałem Ci drogi kolego przykład w bejziku. Nie będę już drążył przykładu SYSINFO, bo jest to jeden z najlepszych przykładów na korzyści wynikające z 816. Napisz Epi w xasm okna, które będą przynajmniej w połowie działać tak jak pod w/w. Testowałem też D2D.com - dma player dla KMK IDE/POKEY/4 bit smp - wynik: 6502 15kHz, 65c816 18kHz - zaznaczam, iż prog odpala sampla z HDD realtime, a każda pojedyncza próbka dźwięku ma 4 bity, więc trzeba jeszcze trochę przy tym liczyć. Jak widać różnica jest znacząca - 3kHz, co szczególnie przy tej częstotliwości dźwięku jest cholernie ważne; czytaj - bardzo poprawia jakość dźwięku. Ze wstępnych obliczeń wynika, iż soft dla kowoksa i 816 powinien mieć "wydajność" na poziomie 20-21kHz - na 6502 nie ma ch*.* wyjść poza 15-16kHz;- oczywiście pamiętaj, że smp jest odpalany w czasie rzeczywistym, więc w tle dzieje się baaardzo wiele rzeczy.
ps. pod 816 TurboBasic też działa .. jak to się stało??? hehehehe;-
Poza tym Epi, jeśli nie chcesz procka, to przecież nie musisz go mieć, może się powtarzam, lecz nie psuj innym dobrej zabawy, I PRZEDEWSZYSTKIM NIE MÓW CHŁOPCZE, ŻE TO DLA MNIE INTERES, BO OD SAMEGO POCZĄTKU WIEDZIAŁEM, IŻ NA TYM POPŁYNĘ .... NIE MÓWIĄC O TYM, ŻE PO 816 JECHALIŚMY 200KM SAMOCHODEM thePINK'A, KTÓRY TEŻ NA TYM WYSZEDŁ W PLERY. No ale dla Ciebie być może nie jest to istotne, więc kup sobie zgrzewkę browca i wypij to z Messiah .,.... może coś z tego będzie ... hehehehehehehehe;- a tak po ćwiartce, to może i ja dołącze i sobie pogadamy o procesorach .. (co Messiah, co o tym sądzisz?)
PS> i tak się na ciebie (k*.*) nie obraziełem, więc wspomnianą fdd i klawisze i tak załatwie. Ale Epi uważaj! FDD przez chwile była odpalona z kompem z 65c816, więc mogła się czymś zarazić .. została naruszona czystość rasy!!! hihihi;-
PS2> IDE PIĆ!!! .. (SCSI??)
kawe, przegryzając dziadem.
... spalonym.
Kontakt: pin@usdk.pl