Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Programowanie - 8 bit » Zabawa z Turbo Basic XL
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
Prawie jak Tedec w Action :)
Wydaje mi się, że można przyjąć minimalny czas, jaki udało się uzyskać przy uruchomieniu programów, bo przecież nie synchronizujemy się z początkiem ramki więc start programu może wypaść równie dobrze na końcu i wynik jest wtedy zafałszowany o 1 w górę.
Edit: @seban: Fantastyczny pomysł z CLS!
Edit 2: Chociaż może właściwie uśrednienie jest sensowniejsze.
problem w tym, że Seban się wyrwał jak Konop z Konopii i opublikował kod (więc ja zaraz po nim), a mieliśmy publikować same wyniki :)
przyznaje się bez bicia że bardzo pobieżnie przeczytałem post cobol80, dopiero potem doczytałem że mamy nie publikować kodu ... (no i potem doczytałem że wyniki mają być z TIME a nie TIME$, stąd moje brednio-wywody o zbyt małej precyzyjności TIME$) ... no ale wtedy to mleko się rozlało już... poza tym nie traktuję tego jako rywalizację czy konkurs, ale jako fajną zabawę :)
każda zabawa jest dobra, ale regulaminy to się czyta :)
no czyta, czyta... (tu moja wina jest niezaprzeczalna, chociaż było napisane "nie trzeba przedstawiać", co nie oznacza iż było to zabronione :P) ale praca zespołowa też jest fajna :) skoro kod się zrobił open-source to teraz społeczność ma szansę wycisnąć z niego ostatnie soki :)
no dobra... to mamy stabilne 7:
0 PAUSE %0:DPOKE 19,%0:GRAPHICS 56:POKE 559,%0
2 POKE 48975,255:-MOVE 41297,41296,7679
3 PUT #6;125:? TIMEJa we wszystkich wersjach czyściłem ekran tak:
CLS#6
Ale pomysły macie zarąbiste, trzeba przyznać.
@Seban - bez zerowania 18 mam wyniki kosmiczne,a to pewnie dlatego, że ja nigdy Atari nie wyłączam. Tak, więc zerowanie 18 musi być.
Na marginesie - właśnie zauważyłem, że program TDCa zerował zegar po GRAPHICS 24.
Hej!
Proszę bardzo, bez zerowania 18,19,20... i większości dirty hacków... 7 ramek...
10 PAUSE %0:PRV=TIME
11 GRAPHICS 56:POKE 559,%0:SCR=DPEEK(88)
12 POKE SCR,255
13 MOVE SCR,SCR+1,7679
14 PUT #6;125
15 DLT=TIME-PRV
16 ? DLT;" FRAMES",DLT*(1/50);" SEC."ps) jeżeli PRV=TIME wstawisz po GR.24, to będziesz miał wynik 6 ramek. pokonaliśmy Action! :)
10 GRAPHICS 24:POKE 559,%0:PAUSE %0:PRV=TIME:SCR=DPEEK(88)
11 POKE SCR,255:MOVE SCR,SCR+1,7679
12 CLS #6
13 LN=PEEK(54283):DLT=TIME-PRV
14 ? DLT;" FRAMES",LN*%2;" LINES"dokładniej 6 ramek i ~90 linii rastra.
coś specjalnie dla PIN-a... 6 klatek... 66 linii.... ;-)
10 GRAPHICS 24:POKE 559,%0:PAUSE %0:PRV=TIME
11 POKE 41296,255:MOVE 41296,41297,7679:CLS #6
12 LN=PEEK(54283):DLT=TIME-PRV:? DLT;"FRAMES",LN*%2;" LINES"btw. -MOVE jest wolniejsze.... 6 ramek 100 linii używając -MOVE.
No tak z tym, że TDC nie wylączał ekranu. Nie mam Action! mógłby ktoś rzucić z ciekawości okiem jak by to wyglądało w Action! z wyłączonym obrazem ?
z włączonym ekranem 8 ramek, 134 linie. TBXL zabija to że wszystko właściwie dzieje się na liczbach FP. Ja i tak się dziwię ze z tyloma wywołaniami procedur z pakietu FP wychodzi wolniej tylko o dwie ramki jedną ramkę. (przy włączonym ekranie).
Na marginesie jest jakas wersja Action! plikowa pod Spartę ?
EDIT: wersja v3.7x działa.
Wg testu TDC program wykonuje się jednak 13 jeśli wyzerujemy zegar na starcie.
Turbo BASIC XL wygrywa!!!
Dodajmy - że Action! działa po kompilacji. Trzeba jakiś lepszy test wymyśleć, bo sama zamiana z jednego koloru na drugi jest za łatwa, jak widać. Poniżej wyniku sebana będzie ciężko zejść. Może by tak rysować koła od środka ekranu na zewnątrz i potem wymazywać kolorem tła. O, coś takiego (najmniej optymalnie jak można):
0 PAUSE %0:DPOKE 19,%0:GRAPHICS 24
1 COLOR %1:FOR I=%1 TO 96 STEP %2:CIRC
LE 159,96,I:NEXT I
2 COLOR %0:FOR I=%1 TO 96 STEP %2:CIRC
LE 159,96,I:NEXT I
3 ? TIMEWynik: 1513 przed kompilacją, co ciekawe 1538 po kompilacji i zlinkowaniu ;) Da się sporo zejść z tego, a widać, co się dzieje na ekranie ;) Działajmy na włączonym ekranie. Po wyłączeniu ekranu na wersji niekompilowanej 1413, kompilowanej nie chciało mi się sprawdzać.
tzn. tak... nie wiem jak wygląda kod TDC-a, nawet nie wiem gdzie go szukać... więc napisałem swój... (używałem action v3.6
)
BYTE RTC=$14
BYTE VCOUNT=$D40B
BYTE SDMCTL=$22F
PROC MAIN()
CARD SCR,VCN
BYTE FRM
GRAPHICS(24) RTC=0
SCR=PEEKC(88)
SETBLOCK(SCR,$1E00,$FF)
ZERO(SCR,$1E00)
VCN=VCOUNT FRM=RTC
GRAPHICS(0)
PRINTF("%E %U FRAMES",FRM)
PRINTF("%E %U LINES",VCN*2)i wyszło mi:
jak się wyłączy ekran, wychodzi:
gdy zrobię tak jak piszesz, tzn. zeruję RTCLOCK przez wywołaniem GR.24, czyli:
to wychodzi:
ale gdy zastosuje się sztuczkę PIN-a z GR.56 (nie czyścimy pamięci ekranu) to wynik spada do:
UPDATE: Porównywanie TBXL i Action! jest trochę bez sensu, ponieważ TBXL działa na liczbach FP (zmienno-przecinkowych) a Action! tylko i wyłącznie na całkowitych. W dodatku Action! to kompilator, a TBXL jest właściwie interpreterem, piszę właściwie bo po wpisaniu linii następuje tokenizacja, przekształcenie wyrażeń arytmetycznych, ot taka wstępna kompilacja i optymalizacja w locie. Gdyby nie wbudowane w TBXL funkcje MOVE moglibyśmy jedynie sobie zerować/wypełniać te 8KB pamięci przez ładny kawałek czasu używając np. FOR...NEXT i POKE. Trwałoby to naprawdę jakiś koszmarny kawał czasu.
Jakby ktoś chciał się bawić w dalszą walkę z Action!, to proszę:
BYTE RTC=$14
BYTE VCOUNT=$D40B
BYTE DMA=$22F
PROC VBL()
BYTE V
V=RTC
WHILE(V=RTC) DO OD
RETURN
PROC MAIN()
CARD SCR,VCN
BYTE FRM
GRAPHICS(24) DMA=0 VBL() RTC=0
SCR=PEEKC($58)
SETBLOCK(SCR,$1E00,$FF)
ZERO(SCR,$1E00)
VCN=VCOUNT FRM=RTC
GRAPHICS(0)
PRINTF("%E %U FRAMES %U LINES",FRM,VCN*2)5 ramek, 38 linii rastra. aby było szybciej to już chyba tylko wstawki ASM :) bo te procedury biblioteczne SETBLOCK czy ZERO nie są jakieś super optymalne ;)
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Programowanie - 8 bit » Zabawa z Turbo Basic XL
Wygenerowano w 0.026 sekund, wykonano 67 zapytań