Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNET firmware v1.5.0 Nowa wersja firmware, która wprowadza szereg ulepszeń i poprawek.
Prima Aprilis Compo 2025 Wystartowała nowa edycja Prima Aprilis Compo, w której obowiązuje jedno wyzwanie - piszemy wyłącznie w Atari BASIC.
maxYMiser FM v1.67 Nowa wersja trackera.
Echa Forevera 23 Wyniki konkursów dla platformy Atari.
Atari Font Maker V1.16.14.4 Narzędzie do projektowania zestawów znaków dla Atari właśnie otrzymało aktualizację
atari.area forum » Posty przez tebe
bedziesz tak zalany, ze monitor Ci sie nie przyda
Fox masz może jeszcze gdzieś swój program wyliczający sinusa z tych zależności trygonometrycznych ?
wzory redukcyjne sa np. tutaj http://www.wsipnet.pl/oip/msl/cz2/u/wt.html
Da sie w ten sposob przedstawic wszystkie stopnie, tyle ze trzeba na końcu znać wartości dla sinusa i cosinusa dla stopni 0..90
chyba mówimy o tym samym zbiorze przykładów wykorzystujących FP, rzeczywiście był tam błąd przy konwersji na ASCII, po poprawce chwyta minusy prawidłowo
dla szeregu potęgowego w/w są pewne odchyły od wartości idealnej, np.
sin(30) = 0.500000001
szereg sin(30) = 0.499674179
sin(37) = 0,6018150231
szereg sin(37) = 0.600888394
szereg wyliczany w krótki sposób sinx = x - x^3/3!
jest to zadowalająca precyzja ?
sinus wg zależności trygonometrycznych, będę musiał poszukać więcej danych na ten temat, może być ciekawiej :)
chyba jednak to wydaje się najprostszym rozwiązaniem
sin x=x - x^3/3! + x^5/5! + x^7/7! + ...
mam takie pytanko, jak wyliczyć sinusa mając do dyspozycji operacje na liczbach zmiennoprzecinkowych typu dodawanie, odejmowanie, mnożenie, dzielenie, ogólnie mając do dyspozycji operacje z pakietu matematycznego Atari
zaglądałem już do źródeł takiej procedury z BASIC'a, może ktoś zna szybszy sposób czy też może przedstawić całą operację wyliczenia sinusa w postaci jakiegoś wzoru, tylko proszę bez szeregów potęgowych czy funkcji różniczkowych
w pakiecie matematycznym Atari znajdują się takie wartości
; POLYNOMIAL FOR SIN/COS FUNCTIONS (11 COEFFICIENTS)
PLYSIN .he 3E 16 05 44 49 00 ; 1.6054449E-03 REF BY BASIC SIN/COS ROUTINES
.he BE 95 68 38 45 00 ; -9.5683845E-03
.he 3F 02 68 79 94 16 ; 0.0268799416
.he BF 04 92 78 90 80 ; -0.049278908
.he 3F 07 03 15 20 00 ; 0.0703152
.he BF 08 92 29 12 44 ; -0.0892291244
.he 3F 11 08 40 09 11 ; 0.1108400911
.he BF 14 28 31 56 04 ; -0.1428315604
.he 3F 19 99 98 77 44 ; 0.1999987744
.he BF 33 33 33 31 13 ; -0.3333333113
NONE .he 3F 99 99 99 99 99 ; 0.9999999999 ALMOST EQUAL TO 1.0 (USED FOR ROUNDOFF PROBLEM)
; SIN OF 45 DEG.
SIN45 .he 3F 78 53 98 16 34 ; 0.7853981634ktoś wie jak to ugryźć, czy to jest potrzebne aby wyliczyć sinus-a, bo Basic używa jakichś swoich predefiniowanych wartości
g2f zlicza sobie kolory ktore wystepuja na obrazku i na podstawie czestotliwosci ich wystepowania przyporzadkowuje je do kolejnych rejestrow koloru, tak wiec kolor ktory najczesciej wystepuje bedzie kolorem tla (712), potem kolejno 708, 709 itd.
dla trybu 9 będę musiał zabronić mu liczyć kolory, wtedy będzie ok
nosty podaj swoj email, poprzedni email odebralem, ale nie mam obecnie dostepu do tamtego kompa
Nosty jeśli dostaniesz potwierdzenie zgonu pana Solo, wyslij swój problem do mnie tbiela[at]poczta.onet.pl
żaden z testowanych programow w C i ASM nic nie wyswietlał, wiec test był uczciwy co do ramki
$f2b0 lubię i będę je używał wtedy kiedy będę miał ochotę i żadna drakońska konserwa nie ma tu nic do gadania, w końcu mniejszość się nie liczy
"makra" w rodzaju while, test, switch mają w założeniu ułatwić życie tym którzy nie czują się pewnie w asm, ostatecznie przyspieszyć proces tworzenie kodu
p.s.
Drac030 mam nadzieję że ten kij w Twojej dupie nie siedzi zbyt głęboko, da się to jeszcze operować ?
atarowcy przybiją gwóźdź do trumny komodorowców ;)
wracając do tematu, program w cc65 po optymalizacji, czyli zamiast "int" jest teraz "unsigned int", rezygnacja z wyrzucania na ekran jakichkolwiek tekstow
cc65 (6502): 2453 fps
Action!: 1015 fps
asm (mads): 1009 fps (automatyczne generowanie kodu dla .WHILE i .TEST, optymalizacja dla skoków warunkowych JNE, JEQ, JCC itd.)
wniosek: CC65 jest wolny, !Action szybki jak assembler
p.s.
następny przyklad programiku w mads z nowymi dyrektywami (i c++) , pytanie, co ten program wyswietli ?:)
;int main() {
; const int WIERSZ = 5;
; const int KOLUMNA = 15;
; int j, i = 1;
org $2000
.var wiersz = 15, kolumna=20, j, i=1 , hlp .byte
; while(i <= WIERSZ)
.while .byte i <= wiersz
; {
; cout << setw(KOLUMNA - i) << '*';
lda kolumna ; setw(KOLUMNA - i)
sub i
sta 82 ; lewy margines
lda #$9b ; cout << setw(KOLUMNA - i)
jsr $f2b0
lda #'*' ; cout << '*'
jsr $f2b0
; j = 1;
mva #1 j
; while( j <= 2*i-2 )
lda i
asl @
sub #2
sta hlp
.while .byte j <= hlp
; {
; cout << '*';
lda #'*'
jsr $f2b0
; j++;
inc j
; }
.endw
; cout << endl;
; i++;
inc i
; }
.endw
; return 0;
;}
mva #$02 82 ; domyslna wartosc komorki 82
mva #$c2 712
jmp *Dely, pewnie jeszcze cos takiego nie powstało, w nastepnej wersji mads bedziesz mial petle while, for i test (odpowiednik if), może Ci to ułatwi pisanie w asm
dla programu w CC65 trzeba dopisać jednak jeszcze po wywołaniu wait()
asm(" lda #0");
asm(" sta $13");
asm(" sta $14");teraz wynik jest lepszy, 2455 FPS
jest OK, okazuje sie że podałem wynik FPS odczytując bajty odwrotnie
przepisuje bajt $13 pod $600, bajt $14 pod $601 i podałem go w kolejnosci $14$13 zamiast $13$14, przez co wynik FPS "podskoczył"
prawidłowo odczytany wynik dla MADS-a to 1036 FPS, czyli ACTION tez jest wiarygodny :) wybaczcie pomyłkę
a na miejscu będzie przewodnik ? :)
ILR a ile masz PRIMES, bo nie mam jak sprawdzic ACTION
pozatym XXL otrzymal podobny wynik dla ASM, tak ze w asm zostało napisane toto podobnie
ja też staram się ułatwiać sobie życie, dlatego wprowadziłem do mads-a (jeszcze nie udostępniony) automatyczne generowanie kodu dla pętli WHILE, kod wynikowy ma długość 375b, fps 1036
/* Eratosthenes Sieve benchmark */
true = 1
false = 0
size = 8190
sizepl = 8191
flags = $8000
org $2000
;void wait(void)
;{
; unsigned char a=PEEK(tick);
; while (PEEK(tick)==a) { ; }
;}
.proc wait
lda:cmp:req 20
rts
.endp
main
;int main()
;{
; unsigned int i, prime, k, count, iter;
.var i, prime, k, count, iter .word
; wait();
wait
mwa #0 $13
; printf("10 iterations\n");
; iter = 1;
mwa #1 iter
; while (iter <= 10) {
p0 .while .word iter <= #10 ;0
; count = 0;
mwa #0 count
; i = 0;
mwa #0 i
; while (i <= size) {
p1 .while .word i <= #size ;1
; flags[i] = true;
lda <flags
clc
adc i
sta adr
lda >flags
adc i+1
sta adr+1
lda #true
sta $ffff
adr: equ *-2
; i++;
inw i
; }
.endw
; i = 0;
mwa #0 i
; while (i <= size) {
p2 .while .word i <= #size ;2
; if (flags[i]) {
lda <flags
clc
adc i
sta adr2
lda >flags
adc i+1
sta adr2+1
lda $ffff
adr2: equ *-2
beq skip
; prime = i + i + 3;
lda i
clc
adc i
sta prime
lda i+1
adc i+1
sta prime+1
lda prime
clc
adc #3
sta prime
scc
inc prime+1
; k = i + prime;
lda i
clc
adc prime
sta k
lda i+1
adc prime+1
sta k+1
; while (k <= size) {
p3 .while .word k <= #size ;3
; flags[k] = false;
lda <flags
clc
adc k
sta adr3
lda >flags
adc k+1
sta adr3+1
lda #false
sta $ffff
adr3: equ *-2
; k = k + prime;
lda k
clc
adc prime
sta k
lda k+1
adc prime+1
sta k+1
; }
.endw
; count++;
inw count
; }
skip:
; i++;
inw i
; }
.endw
; iter++;
inw iter
; }
.endw
; printf("\n%d primes\n", count);
; i=PEEK(tick)+PEEK(tack)*256;
; printf("\n%d fps\n", i);
; return 0;
;}
mwa $13 $600
mwa count $602
mva #$80 712
jmp *
run mainadmini sprawdzają naszą spostrzegawczość, pewnie szykują coś większego ;)
niech zgadne, musisz wejsc do swojego profilu i zmienic jezyk na polski
zacznij składać swoją maszyne czasu mac...
nowa wersja cc65 generuje dłuższy kod i wolniejszy, aktualna długość kodu 3914b (wersja 2.11), poprzednio 3887b (wersja 2.10) , może biblioteki się rozrosły czy coś
w/w benchmark przyspieszy (dla 6502 wyjdzie wynik 2950 fps) jesli zadeklarujemy nasze zmienne jako "unsigned int" w w/w wersji jest bardziej obciążający CPU
Pasiu był tak miły i zapuścił ten benchmark na swojej dopałce, jak pisze ciut powyżej 14Mhz
6502: 554 fps
65816: 533 fps
magicznym zakleciem Laoo ;)
cc65 -O --cpu 65816 -t atari %1 -o %1.s
ca65 --cpu 65816 -t atari %1.s -o %1.o
ld65 -t atari -o %1.xex atari.o %1.o atari.lib
Fox jak zwykle masz racje
oto test który udowadnia że emulator jest szybszy od emulowanej maszyny
/* Eratosthenes Sieve benchmark */
#include <peekpoke.h>
#define true 1
#define false 0
#define size 8190
#define sizepl 8191
#define tick 0x14
#define tack 0x13
char flags[sizepl];
void wait(void)
{
unsigned char a=PEEK(tick);
while (PEEK(tick)==a) { ; }
}
int main()
{
int i, prime, k, count, iter;
wait();
POKE(tick,0x00);
POKE(tack,0x00);
printf("10 iterations\n");
iter = 1;
while (iter <= 10) {
count = 0;
i = 0;
while (i <= size) {
flags[i] = true;
i++;
}
i = 0;
while (i <= size) {
if (flags[i]) {
prime = i + i + 3;
k = i + prime;
while (k <= size) {
flags[k] = false;
k = k + prime;
}
count++;
}
i++;
}
iter++;
}
printf("\n%d primes\n", count);
i=PEEK(tick)+PEEK(tack)*256;
printf("\n%d fps\n", i);
exit(0);
}wyniki w ramkach FPS
atari800win: 4012 fps
prawdziwe Atari z procesorem 65816
tryb 6502: 4015 fps
tryb 65816: 3857 fps
dopałka Pasia F7:
tryb 6502: 554 fps
tryb 65816: 533 fps
p.s.
przeprowadze jeszcze z ciekawości test z programem w asm bez optymalizowania szybkosci kodu z duza iloscia procedur itp. na razie się pisze
atari.area forum » Posty przez tebe
Wygenerowano w 0.091 sekund, wykonano 20 zapytań