No akurat ten interfejs nie jest jakoś mocno popularny, dlatego pewnie nie możesz znaleźć informacji w tym temacie. Ale nie jest tak całkiem źle, nawet tutaj jest trochę informacji:

http://www.atari.org.pl/forum/viewtopic.php?id=15726

Sporo informacji o tym interfejsie jest po niemiecku (bo to ichniejszy twór) więc jeśli ten język nie jest problemem to szukaj tam. Natomiast jeśli chciałbyś kupić ten interfejs, to na pewno nie będzie łatwo, nie jest on jakoś specjalnie popularny.

3,5 tysiąca bez metalowych ekranów osłaniających płytę główną?
Pogrzało kogoś!!! Nie warto!
Ale jak co, to możesz mi podać namiar, tak tylko z ciekawości :D

Gwoli wyjaśnienia, dodam, że ten uszkodzony 6128 wczoraj został przeze mnie opłacony.

:( No faktycznie szkoda.

Ale zaraz, przecież płyta Falcona już jakieś dwa czy trzy lata temu była prawie odtworzona przez gościa o ksywie (piszę z pamięci, bez sprawdzania) npatomn (lub jakoś mocno podobnie)
Nie śledzę atari-forum jakoś od tamtego czasu, więc czy to się nie udało ukończyć? Bo z tego co pamiętam, to było prawie na "finiszu", nawet na ostatnim sztabie ten temat był poruszany, ale też chyba nikt go nie dokończył. Czy w takim razie projekt padł, wie ktoś?

W c i dość ciężkawej bibliotece SDL. Taka specyfika SDLowych rzeczy, że nic nie ruszy na gołym Falconie w zadawalającej prędkości.
Edit:
A drugim dość istotnie wpływającym czynnikiem na wydajność tego typu projektów, jest to, że są to projekty tworzone dość współcześnie (ta gra jest z dwa tysiące jedenastego) na platformę która ma mega-giga-herce i nikt z twórców za bardzo się nie przejmuje, że "jedzie" zbędnie po zasobach. Dla przykładu ta gra ma grafikę w plikach bmp o ośmiobitowej głębi kolorów, natomiast sam silnik graficzny jest inicjalizowany w 32bitach.
Z punktu widzenia platformy docelowej dla której ta gra była tworzona, takie coś nie ma najmniejszego znaczenia, natomiast chcąc ją uruchomić na Falconie, to po pierwsze potrzebna by była lepsza grafika (Super Videl czy Radeon) a po drugie "przerzucanie" takiej ilości pustych bitów po magistrali jednak dość mocno obciąża Falcona (nie wspominając, że jest bez sensu)
Wszystkie porty tej gry (a jest ich trochę) nie ruszały zupełnie silnika graficznego i działały właśnie w ten sposób. Natomiast na Falconie to nie miało zupełnie racji bytu, więc musiałem przerobić ten silnik na osiem bitów (co powinno być dość prostą operacją, ale "napsuło" mi dużo krwi, bo wszystko oprócz tła się przełączyło bez problemu a przełączenie tła zajęło mi gdzieś pewnie 80% czasu) co dało niesamowity skok wydajności.
Oczywiście dało by się na pewno zoptymalizować więcej rzeczy przerabiając je mniej lub bardziej.

No brakuje sinf, cosf, acosf, atanf i tak dalej. Wyczytałem wczoraj, że te funkcje "dotarły" do standardu nazwanego C99. Ale ich w "naszym" libm nie ma, są tylko podstawowe sin, cos i tak dalej.
Tyle, że w kodzie właśnie są tylko te podstawowe, to podczas kompilacji coś się dzieje, że są zamieniane na odpowiedniki "f" (których właśnie nie ma) Dlatego szukałem (bezowocnie) jakiejś opcji do dostarczenia kompilatorowi aby nie optymalizował sin na sinf, cos na cosf itp. Ale nic nie znalazłem.

Tego nie znałem, ale właśnie spróbowałem w jednym pliku źródłowym podmienić na math-68881.h (bo math-68882.h nie istnieje, przynajmniej w tym Thorsten'owym toolchain'ie) i po uruchomieniu make, przestał krzyczeć, że w dla pliku obiektowego tej źródłówki ma undefined reference! :)
Na razie nie mam czasu na dalsze działania, ale później spróbuję to zrobić we wszystkich źródłach używających math.h bo wygląda na to, że to da efekt jaki potrzebuję! (czyli zostawi w spokoju oryginalne wywołania, bez zamieniania ich podczas kompilacji na odpowiedniki "f")

Nie znam Elektrody, ale jeśli jest to miejsce gdzie wątki właśnie wyglądają jak ten tutaj przedstawiony, to również popieram protest, głównie w imię tego, aby z AA nie zrobiło się właśnie takie nic nie wnoszące wizualne niewiadomo co.

Dzieki za pomysły. Generalnie już wczoraj wieczorem użyłem na szybko to dd wg parametrów @mono i to co "wypluło" bez problemu otworzyło się w XnView! :)