15.09.2013 21:57
[#3]
Re: DRAGON - a miało być tak pięknie...
@TUPCOM, post #1
Bez sensu... Po co linkować do jakiegoś marnego tłumaczenia na stronie Vesalii, skoro to samo jest od lat na PPA?
16.09.2013 20:37
[#10]
Re: DRAGON - a miało być tak pięknie...
@_arti, post #9
ZTCP nie weszła do produkcji ze względu na to, że ColdFire nie ma zaimplementowanych wszystkich rozkazów serii m68k i ze względu na to prędkość działania nie powalał, bo rozkazy musiały być emulowane. Przyspieszenie byłoby widoczne dopiero przy programach pisanych specjalnie pod Cold Fire. Byśmy się dziś podniecali czy Q II wyciąga więcej fps na Dragonie, Samancie, czy starym Macui pewnie na tym by się skończyło. Elbox sprzedałby pewnie kilkaset szt tej karty i nie sądze, żeby ktoś bawiłby się w pisanie softu specjalnie pod Cold Fire... choć może się mylę...
17.09.2013 21:09
[#16]
Re: DRAGON - a miało być tak pięknie...
@twardy, post #14
Ciekawą alternatywą były karty AmiJoe z procesorami G3
Można snuć tematy co by było gdyby, szkoda, że nie ma softu do tego wszystkiego, może kiedyś będzie się komuś chciało i coś zrobi :) w co wątpię.
Można snuć tematy co by było gdyby, szkoda, że nie ma softu do tego wszystkiego, może kiedyś będzie się komuś chciało i coś zrobi :) w co wątpię.
19.09.2013 16:38
[#29]
Re: DRAGON - a miało być tak pięknie...
@abcdef, post #28
Nigdy nie czytałem dokumentacji od ColdFire, ale jak nie ma tylko instrukcji dla kodu BCD, to chyba wielkiej tragedii nie będzie przy tym taktowaniu. Podejrzewam że większość gier nawet nie wykorzystuje tych instrukcji (bo tak na szybko nie widzę zastosowania dla nich, no dobra drukowanie wyników, życia itd., ale to jest pojedyncza operacja, może kilka instrukcji BCD). A emulacja tych instrukcji to dodanie kawałka kodu dla pułapki chyba Line_E (procesor wali wyjątek jak nie zna instrukcji, my dodajemy kawałek kodu, który realizuje daną operację przy pomocy dostępnych instrukcji) i po sprawie (wywołanie wyjątku zabiera dość sporo cykli, te parę instrukcji później też parę cykli zjedzą, ale jeżeli nie ma tam w pętli tysięcy wywołań BCD, to powinno to chodzić szybko).
Nawet dostępny soft, dało by się przeassemblować bez źródła, żeby bezpośrednio podstawić w miejsca wywołania instrukcji BCD, kilka instrukcji w zastępstwie, warunek jest jedynie jeden, program musiałby być napisany w bezpieczny sposób (sam nie modyfikuje swojego kodu). Nie mówię że taka przeassemblowaczka jest prosta do napisania, ale jest możliwa.
Ostatnia aktualizacja: 19.09.2013 16:41:54 przez flops
Nawet dostępny soft, dało by się przeassemblować bez źródła, żeby bezpośrednio podstawić w miejsca wywołania instrukcji BCD, kilka instrukcji w zastępstwie, warunek jest jedynie jeden, program musiałby być napisany w bezpieczny sposób (sam nie modyfikuje swojego kodu). Nie mówię że taka przeassemblowaczka jest prosta do napisania, ale jest możliwa.
Ostatnia aktualizacja: 19.09.2013 16:41:54 przez flops
19.09.2013 19:14
[#30]
Re: DRAGON - a miało być tak pięknie...
@flops, post #29
Różnice są mniej więcej ujęte w opisie cf68klib i nie - nie ograniczają się wyłącznie do instrukcji wykorzystujących bcd. Są różnice w działaniu tych samych instrukcji, są braki trybów adresowania. Nic czego obsługa wyjątków nie może załatwić, natomiast trzeba by debuggerem przeanalizować typowy kod amigowy i sprawdzić jak często owe nieobsługiwane bezpośrednio instrukcje się pojawiają. Co do disassemblacji i rekompilacji pod CF - niby można, ale kto zaręczy, że się bez problemu uda? :)