na mnozenie przez zero wystarczy kilkanascie cyckow, na pelne 8bit*8bit gdzies w syzygy byla procka 0xFa o ile pamietam ok.60 cyc, to wychodzi trzydziesci kilka ramek, ale moglem sie pomylic bo to na szybkosci.

heh... duzo... tak tez myslalem... chociaz moze daloby sie skrocic bo argument I 4-bitowy a drugi juz 8...

a była taka procedurka do mnozenia z pomoca wyrazenia:
x*y=((x+y)^2+(x-y)^2)/2
nie pamiętam ile to kosztowało cykli, ale chyba mało. trzeba tylko zrobić prekalkulowane tablice kwadratów.

Jeśli możesz poświęcić 8kB, to zrób tablicę wszystkich możliwych wyników, a proca mnożenia wyglądać będzie tak (spisana z kartki, nie zoptymalizowana, nie wiem czy działa, ale chodzi o sama ideę :rolleyes: ):

mul48  lda m4
       and m8
       tax
       beq ?x
       clc
       lda m4
       adc #>tab.lo
       sta t.lo+1
       adc #$10
       sta t.hi+1
       ldy m8
       lda (t.hi),y
       tax
       lda (t.lo),y
?x     rts

Komórki na stronie 0 o adresach t.lo i t.hi zawierają młodsze bajty tablic wyników i nie powinny się zmieniać w czasie wykonywania programu.
Zrobienie samej tablicy nie stanowi problemu. :)

Epi: jak przewidzisz wartości czynników drugiego mnożenia i jaką masz gwarancję, że mnożenie to będzie przez tę samą liczbę 8-bitową?
A nawet jeśli, to jak potem rozdzielisz wartość 16-bitową na dwie 12-bitowe? Tylko tak szybciutko, bo 60 cykli, to nie wiele. :twisted:

Na tym dowcip polega. Nawet jak uda Ci się spreparować taką tablicę, w co wątpię, to zajmie ona tyle pamięci, że lepiej od razu porzucić ten temat.

A wątpię, bo do masz tylko 16 bitów, a dwa wyniki w/w mnożenia, to razem bitów 24. Jednym słowem miałbyś tablicę "sum kontrolnych". A te mają to do siebie, że dla różnych kombinacji na wejściu mogą dać jednakowe wyniki na wyjściu.

Poza tym, nadal nie wiesz co będziesz mnożył następnym razem. A jak wiesz, to po co mnożyć? Lepiej od razu zrobić tabelkę gotowych iloczynów.  :lol: