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.

Hmm, to 1971 kB/s to jest teoretyczny transfer przy założeniu, że czytamy z rejestrów z pełną szbkością CPU (14,18 MHz) i z takąż zapisujemy do pamięci, a i kod, który nam to robi, w szybkiej pamięci się znajdywa.

Wszelako, pamięć ekranu znajduje się z pierwszych 64k, gdzie zapisy będą szły ze starą szybkością 1,773 MHz.

Policzmy: instrukcja blokowa zużywa 7 cykli na przepisanie bajtu z miejsca na miejsce. Z tego są trzy cykle odczytu rozkazu (to jest pętla), jeden odczyt bajtu źrodłowego, jeden zapis bajtu docelowego i dwa cykle operacji wewnętrznej (zmniejszenie liczników, zwiększenie adresów).

Mamy tu 4 cykle odczytu, jeden zapisu i dwa wewnętrzne. Czyli - przyjąwszy zegar za 14,18 MHz - 6 cykli szybkich i jeden wolny, liczący osiem cykli szybkich. Reasumując, transfer pojedycznego bajtu z dysku do pamięci obrazu zajmie 14 cykli maszynowych szybkich.

512 bajtów pomnożyć przez 14 daje 7168 cykli maszynowych. Dodać ładowanie adresów itd., 7178 cykli maszynowych. Razy dwa, 14356 cykli na kilobajt. 14180000/14356 = 987,74 kilobajta na sekundę ... odjąć 30% na haracz dla Antica => 658,5 kB/s.

Czy użycie tego rozkazu dla całej przestrzeni adresowej będzie korzystne, to się okaże. Na pewno bardzo jest pomocny dla takiego interfejsu, jaki mamy teraz (to znaczy, zapisy i odczyty sektorów w obrębie pierwszego - -czy też jednego - segmentu 64k).

Pasiu, jakie są widoki na to 512k ROM-u? Bo jesli to kwestia paru miesięcy, to moznaby juz powoli startować z pisaniem systemu.

3597 cykli na transfer 512 bajtów przy zegarze 14,18 MHz daje plus minus 1971 kilobajtów na sekundę.

Trochę szybsze będzie: porównaj sobie pod SysInfo odczyt "sequential" i "same block". To pierwsze to jest "best case": przeliczenie numeru sektora na CHS jest robione tylko raz na cały test. To drugie to jest "worst case": obliczenie CHS jest robione za każdym odczytem sektora.