176

(198 odpowiedzi, napisanych Sprzęt - 16/32bit)

No to i ja dołączę do koncertu życzeń :) Chętnie przygarnę:
-PAK
-FRAK
-PuSTE

177

(2 odpowiedzi, napisanych Sprzęt - 16/32bit)

PrzemasIII napisał/a:

autor rozszerzeń właśnie bada zapotrzebowanie i chce zlecić produkcje.

A gdzie tam jest ta informacja? Bo nie mogę tego znaleźć.

Edit:
Sam sobie odpowiem. Bo chyba już nie bada zapotrzebowania, tylko ma ileś gotowców, bo jest info, że są dostępne. OK, to jeszcze lepiej :)

178

(25 odpowiedzi, napisanych Programowanie - 16/32bit)

mkm napisał/a:

To jeszcze jedno. Chcesz zrobić init tablicy na starcie a pozniej dla kazego odswiezanego pixela ekranu robic w niej lookup a potem zapisywac znaleziony kolor do chunky buffora, tak?Nie wiem jak duzo odrysowywujesz co ramke, ale jesli wiekszosc ekranu to ten koszt też może się zrobić znaczący (w stosunku do przygotowania 8bit grafik wczesniej).

Na chwilę obecną jest to zrobione tak, że po przeliczeniu danego piksela od razu leci on do karty graficznej, co w naszym przypadku oznacza ST-RAM. Ale generalnie taki właśnie mam plan, że po przeliczeniu koloru najpierw będę go wrzucał do chunky buffora w TT-RAMie, a potem tylko jednym SDLowym blitem przerzucał to do ST-RAMu. To jest następny mój krok optymalizacji tego, ale już wstępnie w pół minuty byle jak na szybko skonstruowałem  sobie taki bufforek i tam przekierowałem przeliczone kolory a potem jeden blit do ST-RAMu i faktycznie różnica w czasie wykonania była ogromna.

mkm napisał/a:

Swoja drogą używasz C2P w pełnym oknie 640x480? Ciekawe jestem jak to się spisuje, pewnie coś koło 3 ramek na to leci na CT60?

No ja akurat jak to mierzyłem to nie w ramkach tylko w milisekundach i wychodzi mi, że w 640x480x256 SDL przerzuca bufor ramki do ST-RAMu w jakieś 60 milisekund, czyli faktycznie jakieś plus/minus 3 ramki.

179

(25 odpowiedzi, napisanych Programowanie - 16/32bit)

Dokładnie, tak zwany target to 060. I przyznam szczerze, że nawet nie rozważałem trybu TC, ba nawet o nim nie pamiętałem. Dla mnie jest to jakiś egzotyczny tryb, nie mówiąc, że kompletnie o nim nic nie wiem, oprócz tego, że raczej jest ciężki. A do tego tego potrzebuję rozdzielczości 640x480, więc czy tryb TC w takiej rozdzielczości nie zabił by ST-RAMu?. Choć kiedyś będę musiał się pobawić tym trybem,.
Ja generalnie mam jedną paletę 8bit, do której potrzebuję się konwertować, więc opcja ze zrobieniem tablicy w inicie to zdecydowanie najbardziej podobające mi się rozwiazanie. W sumie nawet jak bym miał tych palet więcej (a przecież była by to mocno skończona ilość) to i tak bym robił tablice, pewnie wtedy 6cio bitowe, zaufam Fox'owi, że nawet na 6 bitach straty będą niezauważalne.

180

(25 odpowiedzi, napisanych Programowanie - 16/32bit)

Adam Klobukowski napisał/a:

Tu nasuwa się pytanie: czemu chcesz pracować na 24bitach?

Bo tak jest zrobione i specjalnie nie chce mi się wprowadzać dużo zmian. Jest to bardzo prosta gra, tyle, że w pierwszym SDLu i rozdzielczości 640x480, więc bezpośrednio po skompilowaniu tego, chodzi to wszystko jedna klatka na 2-4 sekund. Chcę to doprowadzić do stanu używalności i powoli widać różnice. Na razie "siedzę" jeszcze w menu, i tam jest właśnie kilka efektów, jak np credits'y co kilka sekund zmieniające się, gdzie starye napisy znikają tak jak dym.

181

(25 odpowiedzi, napisanych Programowanie - 16/32bit)

mkm napisał/a:

JNie widzę jakiejś strasznej potrzeby robienia tego w runtime - jury dlaczego? Jak to mówią: najlepsza optymalizacje = nie liczyć;)

Nie, nic z tych rzeczy, jeśli z mojej wypowiedzi wynika, że uparcie chcę to robić realtime, to zupełnie niezamierzone. Zdecydowanie należę do tych dla których liczy się wynik końcowy, a jak jest osiągniety, to kompletnie nieistotne ;)
W weekend będę miał chwilkę, to zmontuję tablicę 7 czy nawet i 6 bit jak proponował Fox, i mam nadzieję, że będzie git.

182

(30 odpowiedzi, napisanych Sprzęt - 8bit)

kismet75 napisał/a:

Podepnę się pod temat mam monitor commodore 1084 VDE . Monitor wcześniej trochę piszczał i działał normalnie .W pewnej chwili obraz zaczął się raptownie zwężać i zgasł. Na chwilę obecna pali się jedynie dioda zasilania .Jest sens go naprawiać ? Co mogło zostać uszkodzone .

I co, naprawiałeś? Bo też mam monitor Commodore z tej serii który potrzebuje jakiegoś magika.

183

(25 odpowiedzi, napisanych Programowanie - 16/32bit)

Dzięki Panowie, wygląda na to że tablica będzię najlepszym rozwiązaniem. Szczególnie kusząca jest ta opcja 2MB'owa bez zauważalnej straty.

184

(25 odpowiedzi, napisanych Programowanie - 16/32bit)

Tak, zgadza się, właśnie funkcja SDL_MapRGB tak działa, tyle, że nawet na CT6x tak wolno, że nie da się tego używać w tak zwanym czasie rzeczywistym. Dlatego też myślałem, że w demach czy grach używa się jakichś jeszcze bardziej stratnych algorytmów aby to działało wydajnie.
Jak będziesz miał chwilkę, to podrzuć te linki.

Jak się robi konwersję z palety 24bit do indeksowanej 8bit w grach czy demach na Falcona aby to działało wydajnie w c/c++?
Bo mam sobie taki przypadek, blok 250x70 pikseli (czyli jakieś 18 tysięcy pikseli) i po przeliczeniu mega prostego efektu na tym bloku (które trwa jakieś kilka milisekund pod Hatari 68040@32MHz) dopasowanie składowych R, G, B do palety 8bit za pomocą SDL'owej funkcji SDL_MapRGB dla tych 18 tysięcy pikseli trwa około 3,5 sekundy!
Pod CT63 podkręconym na 95MHz jest oczywiście zauważalnie szybiej, ale i tak jest to dalekie od jakiejkolwiek sensownej prędkości.
Wymyśliłem, że sam sobie stworzę taką funkcję konwertującą, ale wyszło jeszcze z pół sekundy dłużej, a do tego ostateczne odwzorowanie koloru/indeksu palety jaki został wybrany jest zdecydowanie gorsze.
Jak się w takim razie ogarnia jakieś efekty na większej ilości pikseli, tak aby to działało znośnie? No chyba, że efekty robi się jakoś bezpośrednio na docelowej palecie aby uniknąć konwersji, ale to była by chyba jakaś masakra.

uicr0Bee napisał/a:

Wiele gier do odpalenia z HDD musiało być w tym celu spatchowanych i są one dostępne np. na stronach http://d-bug.me/ lub Pery Putnika.

Jeszcze tylko dodam, że Klapauzius też patchował gry na HDD itd (np pod CT6x):
http://www.klapauzius.net/Old_Games.html

187

(2 odpowiedzi, napisanych Programowanie - 16/32bit)

Dzięki za sugestię, ale na razie robię tylko tryb kolorów 8bit, więc endian'y mnie nie dotyczą.
Coś mi przyszło do głowy jeszcze wczoraj, więc będę to dzisiaj jakoś sprawdzał.

Edit: OK, temat nieaktualny. Rozpierdzuchę palety robi funkcja SDL_DisplayFormat wywołana zbyt wcześnie. I to w sumie jest dość zrozumiałe, ale nie rozumiem dlaczego mimo wszystko jak później dostarczymy paletę, to z grafiki robi się mocno psychodeliczny twór. To znaczy, oczywiście odpowiedzialna za to jest zapewne również SDL_DisplayFormat, ale przynajmniej na razie już nie wnikam co i jak bo osiągnąłem to co mi obecnie potrzebne.

188

(2 odpowiedzi, napisanych Programowanie - 16/32bit)

Cały wieczór dzisiaj spędziłem próbując ustawić paletę przez SDL i *ponownie* nie udało mi się (jakiś kawałek czasu temu po raz pierwszy chciałem to osiągnąć i spędziłem wtedy chyba ze 3 dni, ale w końcu się poddałem)
Może ktoś się dopatrzy czegoś co robię źle.

Generalnie robię to jak poniżej, ładuję bmp SDLową funkcją (choć i czytałem już specyfikację BMP i mam też własną funkcję ładującą BMP) potem buduję sobie paletę i SDLową funkcją ją ustawiam, i wg mojego rozumowania to powinno działać.

    if( SDL_Init( SDL_INIT_EVERYTHING ) == -1 )
    {
        return 1;
    }
    screen = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_SWSURFACE );

    for (x = 0; x <256; x++)    
    {
    strcpy(s1, "screen po setvideomode: ");
    sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, screen->format->palette->colors[x].r, screen->format->palette->colors[x].g, screen->format->palette->colors[x].b);
    strcat(s1, s2);
    loguj(s1);        
    }        
    
    if( screen == NULL )
        return 1;

    background = load_image( "data/images/title.bmp" );
    
    for (x = 0; x < 256; x++)
    {
        paleta[x].r = background->format->palette->colors[x].r;
        paleta[x].g = background->format->palette->colors[x].g;
        paleta[x].b = background->format->palette->colors[x].b;
    }    

    for (x = 0; x <256; x++)    
    {
    strcpy(s1, "background po zaladowa: ");
    sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, paleta[x].r, paleta[x].g, paleta[x].b);
    strcat(s1, s2);
    loguj(s1);        
    }        
    
    if (!SDL_SetPalette(screen, SDL_LOGPAL | SDL_PHYSPAL, paleta, 0, 256))
    {
        loguj("problem z ustawieniem palety1");
    }
    
    SDL_BlitSurface(background, NULL, screen, NULL);
    
    SDL_Flip(screen);
    
    SDL_Delay(1000);

Niemniej kolory są zawsze nie takie jak w pliku. Jeśli z takiego wczytanego BMPka do struktury SDLowej "zbieram" sobie paletę i loguję ją do pliku, to te wartości r, g i b są jakieś zupełnie inne. Co prawda nie wygląda to jak kompletnie losowe wartości:

background po zaladowa: indeks = 0 | r: 0 g: 0 b: 0
background po zaladowa: indeks = 1 | r: 0 g: 0 b: 85
background po zaladowa: indeks = 2 | r: 0 g: 0 b: 170
background po zaladowa: indeks = 3 | r: 0 g: 0 b: 255
background po zaladowa: indeks = 4 | r: 0 g: 36 b: 0
background po zaladowa: indeks = 5 | r: 0 g: 36 b: 85
background po zaladowa: indeks = 6 | r: 0 g: 36 b: 170
background po zaladowa: indeks = 7 | r: 0 g: 36 b: 255
background po zaladowa: indeks = 8 | r: 0 g: 73 b: 0
background po zaladowa: indeks = 9 | r: 0 g: 73 b: 85
background po zaladowa: indeks = 10 | r: 0 g: 73 b: 170
background po zaladowa: indeks = 11 | r: 0 g: 73 b: 255
...
ciach
...
background po zaladowa: indeks = 245 | r: 255 g: 182 b: 85
background po zaladowa: indeks = 246 | r: 255 g: 182 b: 170
background po zaladowa: indeks = 247 | r: 255 g: 182 b: 255
background po zaladowa: indeks = 248 | r: 255 g: 219 b: 0
background po zaladowa: indeks = 249 | r: 255 g: 219 b: 85
background po zaladowa: indeks = 250 | r: 255 g: 219 b: 170
background po zaladowa: indeks = 251 | r: 255 g: 219 b: 255
background po zaladowa: indeks = 252 | r: 255 g: 255 b: 0
background po zaladowa: indeks = 253 | r: 255 g: 255 b: 85
background po zaladowa: indeks = 254 | r: 255 g: 255 b: 170
background po zaladowa: indeks = 255 | r: 255 g: 255 b: 255

tylko faktycznie jak jakaś paleta, ale zupełnie nie ta która była oryginalnie w BMP.

A tu jak co jest calutki kod który w trybie 640x480x8 próbuje wczytać plik BMP i po prostu go wyświetlić:

#include "SDL/SDL.h"

const int SCREEN_WIDTH = 640;
const int SCREEN_HEIGHT = 480;
const int SCREEN_BPP = 8;

SDL_Surface *background = NULL;
SDL_Surface *screen = NULL;
SDL_Surface *fafa = NULL;

char s1[100], s2[100];

void loguj (char str[])
{
    FILE *plik;
    plik = fopen("log.txt", "a");
    fprintf(plik, "%s\n", str);
    fclose(plik);
}

SDL_Surface *load_image( char filename[] )
{
    SDL_Surface* loadedImage = NULL;
    SDL_Surface* optimizedImage = NULL;

    loadedImage = SDL_LoadBMP( filename );
    if( loadedImage != NULL )
    {
        optimizedImage = SDL_DisplayFormat( loadedImage );
        SDL_FreeSurface( loadedImage );
    }
    return optimizedImage;
}

int main( int argc, char* args[] )
{    
    SDL_Event event;
    SDLKey key;
    int x, y, indeks_pal;
    int koniec = 0;
    Uint8 *pixel_addr;
    SDL_Color paleta[256];
    
    for (x = 0; x < 256; x++)
    {
        paleta[x].r = x;
        paleta[x].g = x;
        paleta[x].b = x;
    }
    
for (x = 0; x <256; x++)    
{
strcpy(s1, "szara paleta: ");
sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, paleta[x].r, paleta[x].g, paleta[x].b);
strcat(s1, s2);
loguj(s1);        
}    

    if( SDL_Init( SDL_INIT_EVERYTHING ) == -1 )
    {
        return 1;
    }
    screen = SDL_SetVideoMode( SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_BPP, SDL_SWSURFACE );

    for (x = 0; x <256; x++)    
    {
    strcpy(s1, "screen po setvideomode: ");
    sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, screen->format->palette->colors[x].r, screen->format->palette->colors[x].g, screen->format->palette->colors[x].b);
    strcat(s1, s2);
    loguj(s1);        
    }        
    
    if( screen == NULL )
        return 1;

    background = load_image( "data/images/title.bmp" );
    
    for (x = 0; x < 256; x++)
    {
        paleta[x].r = background->format->palette->colors[x].r;
        paleta[x].g = background->format->palette->colors[x].g;
        paleta[x].b = background->format->palette->colors[x].b;
    }    

    for (x = 0; x <256; x++)    
    {
    strcpy(s1, "background po zaladowa: ");
    sprintf(s2, "indeks = %i | r: %i g: %i b: %i", x, paleta[x].r, paleta[x].g, paleta[x].b);
    strcat(s1, s2);
    loguj(s1);        
    }        
    
    if (!SDL_SetPalette(screen, SDL_LOGPAL | SDL_PHYSPAL, paleta, 0, 256))
    {
        loguj("problem z ustawieniem palety1");
    }
    
    SDL_BlitSurface(background, NULL, screen, NULL);
    
    SDL_Flip(screen);
    
    SDL_Delay(1000);
    
    if (!SDL_SetPalette(screen, SDL_LOGPAL | SDL_PHYSPAL, paleta, 0, 256))
    {
        loguj("problem z ustawieniem palety2");
    }    
    
    SDL_Delay(1000);
    
    indeks_pal = 0;

    SDL_FillRect(screen, NULL, SDL_MapRGB(screen->format, 0, 0, 0));
    
    for (x = 0; x < 640; x = x + 5 )
    {
        for (y = 0; y < 200; y++)
        {
            pixel_addr = (Uint8 *)screen->pixels + (screen->pitch * y) + x;
            *pixel_addr = indeks_pal;
            pixel_addr++;
            *pixel_addr = indeks_pal;
            pixel_addr++;
            *pixel_addr = indeks_pal;
            pixel_addr++;
            *pixel_addr = indeks_pal;
            pixel_addr++;
            *pixel_addr = indeks_pal;            
            
        }
        for (y = 200; y < 400; y++)
        {
            pixel_addr = (Uint8 *)screen->pixels + (screen->pitch * y) + x;
            *pixel_addr = indeks_pal + 128;
            pixel_addr++;
            *pixel_addr = indeks_pal + 128;
            pixel_addr++;
            *pixel_addr = indeks_pal + 128;
            pixel_addr++;
            *pixel_addr = indeks_pal + 128;
            pixel_addr++;
            *pixel_addr = indeks_pal + 128;        
            
        }        
        indeks_pal++;
    }
    
    if( SDL_Flip( screen ) == -1 )
        return 1;
    
    while (!koniec)
    {
        while (SDL_PollEvent(&event))
        {
            if (event.type == SDL_KEYDOWN)
            {
                key = event.key.keysym.sym;
                
                if (key == SDLK_ESCAPE)
                    koniec = 1;
            }
        }
    }

    SDL_FreeSurface( background );
    SDL_Quit();
    return 0;
}

A cały plik logujący dane z palet załączam do tematu.
O co tutaj chodzi?

189

(11 odpowiedzi, napisanych Software, Gry - 16/32bit)

Nie sprawdzałem z tą myszą, bo mam Eiffel więc musiałbym szukać oryginalnej klawiatury i myszy, ale jako że bardzo dawno grałem na padzie Segi na Falconie, to stwierdziłem, że może źle to pamiętam albo tak naprawdę to w ogóle nigdy nie grałem i tylko chciałem :) więc postanowiłem to zweryfikować na jakiejś grze. Ściągnąłem pierwszą lepszą grę dostosowaną do twardego dysku i Falcona ze strony Klapauzius'a i ... jednak dobrze pamiętałem odnośnie pada Segi. Wszystko działa OK i kierunki i fire. Cuda niewidy ...

190

(11 odpowiedzi, napisanych Software, Gry - 16/32bit)

Dokładnie. Niestety nie rozumiem dlaczego obsługa Fire nie działa dla klasycznego joysticka.
Do tego możesz jeszcze grać na padzie 16bitowej Segi.

Może w takim razie ktoś ma pomysł dlaczego poniższy kod nie działa dla przycisku joysticka (a np. działa dla pada Segi)

Aktywuję joystick tak:

    joystick_atari = SDL_JoystickOpen(0);
    if (joystick_atari != NULL)
    {
        printf("joystick number of buttons: %d\n", SDL_JoystickNumButtons(joystick_atari));   (tu zwraca oczywiście, że jest 1 przycisk)
        printf("joystick number of axes: %d\n", SDL_JoystickNumAxes(joystick_atari));
        printf("joystick number of balls: %d\n", SDL_JoystickNumBalls(joystick_atari));
        printf("joystick number of hats: %d\n", SDL_JoystickNumHats(joystick_atari));
    }

A potem korzystam z niego tak:

    SDL_JoystickUpdate();
    current_hat = SDL_JoystickGetHat(joystick_atari, 0);
    current_button = SDL_JoystickGetButton(joystick_atari, 0);

191

(40 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

tOri napisał/a:

- pośpiechu nie ma, będziesz miał chwilę to sprawdzisz :)

Postaram się jakoś to w najbliższym czasie sprawdzić. Ale w razie jakbym się ociągał z informacją, to się przypomnij, bo pamięć ma tę właściwość, że ulotną jest ;)

192

(40 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

tOri napisał/a:

Może ktoś ma zalegający taki interfejs

Mam. Edit: ale nie wiem czy działający, od 15 lat leży w pudełku, przedtem działał. Sprawdzenie możliwe, ale nie takie hop, siup, już.

193

(11 odpowiedzi, napisanych Software, Gry - 16/32bit)

>> jakie są minimalne wymagania?

Trudno mi to wycenić. Najmniej wymagająca skórka  (czyli oryginalana) na gołym Falconie jak piszesz, działa wolno, ale na dopalonym przez CT6x za szybko. W takim razie strzelam, że mogła by działać grywalnie na takim AB040, choć może wystarczyło by już CT2. Ale to tylko gdybanie, bo nie mam nic poza CT63 żeby sprawdzić.

194

(11 odpowiedzi, napisanych Software, Gry - 16/32bit)

GNURobbo skompilowany na większe Atarki.

W odróżnieniu do klasycznego Robbo z małego Atari, ma 3 różne skórki graficzne i muzyczne i jest w 8 językach.
Moja ulubiona skórka to Oily, jest to taka niby oryginalna grafika ale dość mocno podrasowana do 24bit. Tyle, że jak uruchamiałem to w 24bitach na PC'cie to nie bardzo przypadła mi do gustu, ale obcięta do 15bitów Videla (edit: oczywiście pomyłka, powinno być: obcięta do 8bit) dla mnie wygląda obłędnie! :) Tak więc nie polecam tej skórki na Super Videlu :) Sam nie sprawdzałem jak to działa na SV, bo moje SV coś latem przestało dawać sygnał i jeszcze nie przysiadłem do niego.

Jeśli dobrze kojarzę, to ta wersja jest praktycznie "czystą" wersją GNURobbo, jedyna większa zmiana dotyczy tylko sterowania. W GNURobbo każdy kontroler należy skonfigurować oddzielnie i tylko danym kontrolerem można sterować. Natomiast w tej wersji nic nie konfigurujemy, wystarczy "złapać" za (prawie*) cokolwiek i można grać, płynnie zmieniając kontroler na inny. Czyli można grać na klawiaturze, Jagpadzie, kontrolerze od 16bit'owej Segi (i pewnie każdym innym zgodnym).Nie działa jedynie klasyczny joystick podłączany do Falcona. To znaczy działają kierunki, ale nie działa strzelanie czego kompletnie nie rozumiem skoro działa taki pad od Segi, który jak mi się wydaje, jest przecież zgodny sygnałowo z joystickami.

Jako, że jest to gra SDL'owa, to wymaga trochę mocy, więc jakaś dopałka raczej wymagana. Skórki Oily i Tronic są bardziej mocożerne, więc CT6x to mus, natomiast skórka oryginalna pewnie działał by płynnnie na jakimś AB040 czy może nawet i czymś lżejszym.

Testy: Kroll i TKSM

https://ufile.io/xu7432z5

195

(3 odpowiedzi, napisanych Software, Gry - 16/32bit)

Niech ma:

(czyżbyś się TDC'a naoglądał? ;) )

lizard1982 napisał/a:

Witam,

Jak skompilować plik .s razem z plikiem .c do binarki *.tos ?

Chcę połączyć plik .s z plikiem .c w jedną binarkę, ale nie wiem jak...

Korzystam z vasm oraz vbcc.

...

vbcc -quiet test.c -o="test.s"
vasm -nocase -devpac -m68000 -Faout -phxass -no-opt -o GEMDOS.o GEMDOS.s
vasm -nocase -devpac -m68000 -Faout -phxass -no-opt -o test.o test.s
vlink -b ataritos -o ppp.tos GEMDOS.o test.o

Nigdy nie kompilowałem w vbcc to się wypowiem :)

Jedyny znany gotowiec jaki kojarzę, to kawałek własnego silnika graficzno-muzycznego Francuza o ksywie Orion_

http://onorisoft.free.fr/retro.htm  (Falcon Demo System v5)

i tam w skrypcie budującym binarkę (również z c i assemblera) robi to tak:

set path="E:\Programmation\Falcon\VBCC\bin"

vc +%path%\..\config\normal.pc -cpu=68030 -O4 -o falcdemo.prg main.c falcsys.c falcsysa.s

pause

OK, dzięki za wszelakie sugestie. Dzisiaj miałem chwilkę to przysiadłem znowu do tematu i najpierw zacząłem z ciekawości przeglądać (uważniej) ten własny endian projektu i znalazłem przyczynę problemu. Potrzebne makra były zaplątane w serię #ifdef'ów i #ifndef'ów które źle zinterpretowałem, więc w rzeczywistości te makra nie były definiowane. Dostosowałem odpowiednio #ifdef'y i projekt się zbudował :)
Z ciekawości sprawdziłem też endian.h cross-toolchain'a (mam zainstalowany Vincent'owy) i trochę się zdziwiłem, bo tam w endian.h nie ma tych makr.
Pobrałem sobie też toolchain Thorsten'a (w wersji 8.coś tam, choć widziałem że już ma 9.cośtam i nawet 10.cośtam) i jak sprawdziłem jego endian.h, to wygląda jak najbardziej "prawidłowo", ma te wszystkie indiańskie marka i takie tam... Nic to, najważniejsze, że projekt się już buduje, a skoro jeszcze pewnie w tym roku będę  zmieniał distro, to zapewne już pójdę w toolchain Thorsten'a, a na razie nic nie ruszam.

Od jakiegoś czasu (strzelam, że ze dwa dni) ani razu mi nie "zamuliło" forum. Dzięki!

U mnie też. Każda taka operacja trwa conajmniej 30 sekund, a czasem i dłużej.

Dodawać tego <endian.h> z ciekawości oczywiście dodawałem, ale nic to nie zmieniało.
A co do mintliba, to zdecydowanie powinienem mieć, regularnie coś tam kross-kompiluję i wszystko działa jak należy, ale może coś mi się tam ostatnio faktycznie rozjechało, zerknę dzisiaj i zweryfikuję czy wszystko jest OK.