Taka wymiana procka jest jak najbardziej możliwa. Robił to bodajże między innymi człowiek od http://hardware.atari.org.
Co do nielegalnych instrukcji, to 68000 i 68010 nie różnią sie chyba aż tak żeby to był problem, a jeśli będzie, to będzie to strasznie wolne.

Na wikipedii piszą, że 68010 ma cache na dwie instrukcje i w rezultacie jest 10% szybsza :)

Oidp, gcc 2.95.2 produkuje dbcc, jeśli się zrobi pętlę do-while, z licznikiem typu short int, zliczającą wstecz do -1 :)

    short int i = 1000;

    do
    {
        printf("%x\n", i);
        i--;
    } while (i != 0xFFFF);

Hmm, kiedyś już zapodałem posta - zazwyczaj procki w ST są 10MHz, a ustawione na 8. Nie chce mi się szukać. Teoretycznie można przyspieszyć wszystko posa grafą - wtedy się monitor ten-teges. To by było chyba lepsze wyjście ;)

Weś ić.

Falcon z fastem kosztuje jakieś 10x tyle co ST :)

O cholera. To aż tak źle? To może i dobrze, że 6502/65816 nie ma mnożenia ani dzielenia, bo odczytanie z tablicy jest o wiele szybsze ;)

Myślę, że kwestią jest korzystniejszy stosunek powierzchni ekranu do wydajności proca. Podejrzewam, że jakby na ST/E robić dema w 64x48, to też dałoby się kilka fajnych rzeczy pokazać, a niestety motorolka nie jest aż tyle razy szybsza od 6502, aby wydolić fajne rzeczy w wysokiej rozdzielczości.

sqward: niemniej, istnieje kompilator, który produkuje pętlę z dbcc. I największy problem, podejrzewam, to nie to, czy on ją produkuje, czy nie, tylko że taka konstrukcja, jak pętla do-while z 16-bitowym licznikiem liczaca wstecz do -1, jest raczej mało prawdopodobna w programie napisanym w C. Gros pętli to przecież for (), potem while(), a do-while daleko w tyle.

Z tym mnożeniem i dzieleniem troche przesadziłem jednak:

1) m68k divs: 158 cykli plus obliczenie adresu efektywnego (np. natychmiastowy 16-bit 4 cykle, czyli razem 162)
- 68010: 122

2) m68k divu: 140 cykli (plus j.w.)
- 68010: 108

3) m68k muls: 70 cykli (j.w.)
- 68010: 42

4) m68k mulu: 70 cykli (j.w.)
- 68010: 40

Wszystko to sa czasy maksymalne, ale: "the divide algorithm used by the MC68000 provides less than 10% difference between the best- and worst-case timings. The multiply algorithm requires 38+2*n clocks, where n is defined as:
- mulu: n = the number of ones in <ea>
- muls: n = concatenate the <ea> with a zero as the LSB; n is the resultant number of 10 or 01 patterns in the 17 bit source, i.e. the wors case happens when the source is $5555".

w 68010 jest duzo zmian-ma wprowadzaona juz prace potokowa w kilku instrukcjach i te 10% to wlasnie z tego powodu. kiedys w gazecie C&A bylo otym naoisane i dodawali na dyskietkach program ktory podnienia instrukcjie nieistejaca z68000 ktora nieistnieje w 68010-byla to instrukcjia dodawania jak dobrze pamietam. w atari tez da sie podmienic ta instrukcjie przy skoku do trap obslugi nielegalnych/nieistniejacych rozkaowa-myslalem ze moze ktos ma taki programik-najlepiej to przydala by sie wersja tos2,06 juz zainstalowanym kodem .
a co do lutowania-to niebardzo bo STe ma podstawke pod motorole i to tylko wymina ukladu by byla. cena prcka jest interesujaca bo 38 zeta a za 030 chac duuuzoo wiecej i cala operacja wymagala by duzo roboty.
sprzedawana wersja to 10 mhz i z takim taktem bym musiala umnie pracowac(prosta przerobka z bramka i osobnym rezonatorem 10mhz)

ja tylko mowie co bylo w gazecie dla amigowcow i twierdzili ze to dodawanie niema swojegoodpowiednika w 68010 dlatego dodali program ktory wykrywa uzycie nieistnijacej dal 68010 instrukcji i podnienia ja na ta z 010.dla przykladu kazali wlaczy jakiki kolwiek program do liczenia i czekac az pojawi sie znana czerwona ramka ;-)

Ja od siebie dodam tyle, że przejrzałem manual od 68000/68010 i żadnych "instrukcji istniejących w 68000 a nieistniejących w 68010" tam nie widzę. :)

rzeczywiście dopałka o 10% (w porywach) to jest zajebista oferta ;) Wzrost prędkości nieodczuwalny, a ryzyko, że coś nie zadziała jest znaczące. Ciekawe czy sam TOS działa na 010 ? :)

Ostatnio edytowany przez sqward (2007-03-27 15:44:22)