Zawracasz głowę, Magic się wywala z AUTO i bez, z CPX-ami i bez, z akcesoriami i bez, oryginał i lewa wersja, na Falconie i nie na Falconie. Ja w te mity, że "stabilność Magica zależy od wielu czynników" przestałem wierzyć, kiedy zainstalowałem MagiC-a koledze na STE i sypało się dokładnie tak samo, jak u mnie na Falconie.

Z rasizmu zapewne :twisted:

Zależy, co rozumiemy pod "niedopracowany". Jest stabilniejszy niż Magic, czyli moim skronym zdaniem o tyle właśnie jest bardziej dopracowany. A co do toporności, to nie wiem co masz na myśli.

Przecież rozmawialiśmy na SV2k4, mnie ten temat niezbyt interesuje ...

CPU można zrobić na FPGA. Chyba są nawet darmowe tzw. "kory" do zaprogramowania np. Intela 8051 czy takich tam.

Za to masz gorsze rozszerzenie. Coś za coś.

[ Dodano: 14.01.2005 22:33:38 ]

Jasne, łatwość montażu to duża zaleta, wpinasz i po krzyku. Pod warunkiem, że rzecz do wpięcia masz jedną, ale załóżmy. Jednak za tę cenę - i za cenę zachowania stu procent Atari w Atari - taka dopałka będzie miała dużo mniej możliwości, przez co nie jest aż tak atrakcyjna. Ostatecznie, transfer nawet przez najszybszy port na 1,77 MHz, to nie to samo, co bezpośrednie adresowanie na 14 MHz.

Co do wycyklowanych programów: plany Pasia zakładają bardzo dużą, wręcz stuprocentową kompatybilność, bo do uruchamiania takich programów będzie używany stary procesor. A poza tym, na peceta też były cyklowane gierki i demka, i gdzie one teraz są?

[ Dodano: 14.01.2005 22:39:52 ]
PS. Zakładam, że z takimi poglądami masz standardową atarynkę, tj. z 64 albo 128 k pamięci, jak fabryka dała?

Teoretycznie można zrobić układowi DSP power on/off funkcjami Ongibit() i Offgibit(), a potem przeładować bootstrap funkcją DSP_ExecBoot() - o ile dobrze pamiętam nazwę. To są wszystko funkcje XBIOS-u. Ale, z tego co słyszałem, nie zawsze to chce działać, podobno.

A ja owszem, widzę. A to dlatego, że znam praktykę na komputerze, który ma dwa procesory, z tego jeden wyposażony we własną pamięć i podpięty przez porty I/O. Chodzi o Falcona030 i jego DSP. Bywa tak, że po tym, jak jeden program właduje się do pamięci DSP i tam namiesza, to drugi już tego nie może zrobić i DSP jest nieczynne (aż do resetu). Nie jest tak zawsze, ale tak bywa.

Właśnie dla uniknięcia takich sytuacji wolałbym w tej teoretycznej karcie koproca podział na funkcje, które są predefiniowane i zawsze takie same, oraz oddzielną możliwość ładowania i uruchamiania własnych funkcji przez program.

1 MB pamięci powinien starczyć do tego aż nadto.

No o tym właśnie mówię: można przetransferować, ale ogólnie transfery danych będą zachodzić ze starą szybkością, podczas gdy z Pasiową kartą transfer nawet po starej pamięci będzie 3-4 razy szybszy; to moim skromnym zdaniem daje lepsze pole do popisu jeśli chodzi o np. gry niż nawet najszybszy układ mnożący zamontowany na karcie.

Zwłaszcza, że jedno nie wyklucza drugiego.

Nie, to nie jest problem "generalny", tylko taka upierdliwość dnia codziennego.

No usiłuję ci właśnie przetłumaczyć, że też nie... Co ci po mocy obliczenowej Pentium 4 2,5 GHz, który ci rozpakuje divxa, jeśli 6502, nawet nie zajmując się niczym innym jak odbiorem strumienia danych od pentiuma, nie wyrobi się na wyświetlenie nawet 25 klatek animacji na sekundę?

Toteż, jak ktoś tu już cichutko napisał (ale został zignorowany), pasiowa karta wchodzi w podstawkę od procesora.

Byłoby to twierdzenie słuszne, ale następnik jest fałszywy. To znaczy: nie ma co do mej wiedzy możliwości zrobienia "tego" zewnętrznie. To znaczy, karta zewnętrzna nie będzie miała takich możliwości, jak rozszerzenie wewnętrzne. Czyli, jedna rzecz nie może zastąpić drugiej. Ale też z drugiej strony nie wykluczają się wzajemnie.

Wg. mnie zewnętrzna karta z drugim 65c816 taktowanym wysoko (np. 14 MHz) i własną pamięcią mogłaby się przydać jako koprocesor (do karty Pasia albo bez niej). Część funkcji można byoby mu przypisać na stałe (np. obliczenia zmiennoprzecinkowe), a resztę pozostawić do swobodnego wykorzystania przez programy.

Tak, jestem pewien, że na Falconach jest ten sam problem.

[ Dodano: 09.01.2005 20:26:19 ]

No właśnie, zszedłem z GG mówiąc, że idę spać, ale zanim to zrobiłem, usiadłem jeszcze do atarynki i jakoś tak mi senność minęła  ;)

Ok, co jest źle; otóż Caviar nie ruszy za chińskiego boga, jeśli się po włączeniu zasilania nie wykona tych dwóch kolejno czynności:

1) odczyta konfiguracji przez IDENTIFY DRIVE (a dotychczasowe wersje interfejsu odczytują geometrię z MBR, którego Caviar nie pozwala odczytać);

2) tejże konfiguracji nie zapoda z powrotem przez INITIALIZE PARAMETERS;

Dodatkowo, zanim się tego nie zrobi, dysku NIE WOLNO resetować softwareo'wo (jaka piękna polszczyzna).

Przerobiłem HDBIOS 1.5 pod tym kątem, wykorzystując iteracyjnie zasadę nieskończoności ("nie ma takiego programu, którego nie dałoby się skrócić o jeszcze jeden bajt"). W rezultacie powstał HDBIOS 1.6, który powinien już inicjować Caviary poprawnie.

[ Dodano: 09.01.2005 20:38:59 ]

Został mi jeden bajt wolnego miejsca i obawiam się, że żadna zasada nieskończoności już tu nie pomoże  ;)

Proszę bardzo. Lepiej, żeby działały dobrze, bo przesłać nową wersję nieprędko będę mógł  ;)

Nowhere yet. I am planning to make it available on the www today (tonight).

No pewnie... ale nie dzisiaj. Zresztą, wiele do dodania nie ma, więc to co napisałem wyżej możesz sam dodać w wolnej chwili ...

LOAD to jest zda się polecenie wewnętrzne command.com, czy się mylę? Ponieważ ładowanie kontentu binarnego pod arbitralny adres  ;) może nadpisać command.com, więc proponowałbym raczej usunięcie LOAD z command.com i zapodanie tego polecenia na urządzenie CAR: jako programu zewnętrznego, oczywiście z tym rozszerzeniem.

[ Dodano: 07.01.2005 02:00:31 ]

Zgadzam się, to jest nieporozumienie. W 4.22 jest też ECHO.COM, czy ma to jakąś przydatność?

Ja proponuję to w ogóle usunąć, to znaczy przenieść na dyskietkę z toolkitem. XEP jest mało popularny i w ogóle jest to urządzenie, które działa, jakby chciało a nie mogło. Szkoda miejsca, które można byłoby wykorzystać na coś bardziej przydatnego.

Można spróbować poprawić błąd, ale chyba nie ma powodu, żeby to rezydowało na karcie.

Ogólnie zgadzam się z Lizardem, lepiej jest zarezerwować CAR: na najniebędniejsze rzeczy.

A może w ogóle docelowo zrezygnować z karta i zaprodukować wersję ładowaną z dysku. To co jest na kartridżu można byłoby wepchnąć do pamięci powyżej adresu $FFFF.

Szczerze wątpię. Motorolka 68030/16 MHz sobie z tym nie radzi. Nieco większe - ale tylko nieco - szanse są przy mp2, ale chyba nawet amigowcom się nie udało osiągnąć zadowalających wyników na 68020/14 MHz - czyli na gołej 1200 - chociaż bardzo się starali.

Z drugiej strony, ja może czegoś nie wiem - bo na Falconie jest DSP, więc nikt się w to nie bawił, TT mało kto ma itd.

[ Dodano: 07.01.2005 01:35:59 ]

Wmontowywać BASIC-a do ROM-u nie ma sensu, skoro go można dużo lepiej załadować z twardego dysku. Taki interpreter BASIC-a, co by miał na program 64k RAM-u - czyli cały segment - spróbuję wykonać. To znaczy on się gdzieś tam w tle stopniowo pisze, ale OS jest ważniejszy.

MVN - move next - transfer bloku, rosnąco. Rozkaz przepisuje w pamięci blok danych o długości do 64k w rosnącej kolejności adresów. Adres źródłowy określa rejestr X, adres docelowy rejestr Y, długość bloku zmniejszona o jeden znajduje się w akumulatorze. Najstarsze bajty adresów źródłowego i docelowego definiowane są przez dwa dodatkowe parametry natychmiastowe. Jest to w gruncie rzeczy jednorozkazowa pętla o następującym działaniu:

Ten tekst jakoś mi wygląda znajomo. Kto go pisał?

[ Dodano: 07.01.2005 01:39:01 ]

No właśnie, 50 złotych mozna dać, zważywszy, że to i tak jest dwuipółkrotne przebicie ceny producenta. Też bym chciał jeden.