Można w nowszej wersji (0.9.5c). Jutro za dnia ją tu wkleję, bo teraz nie jestem tak do końca w formie.

Dzięki za szczegółowy raport. Problem z PBI.SYS wymaga zbadania, niewątpliwie.

EDIT: problem z zapisanymi ścieżkami jest częściowo ogarnięty, a częściowo nie, faktycznie jest tam taka ślepa uliczka, do której SC może się zagonić. Ale to znowu, jutro zajrzę, bo dzisiaj to już nie :)

Ale co jak? Termin podaj.

Biedna ofiaro lobotomii :)

voy zostaw go, przecież widać, że facet jest upośledzony i właśnie się zapętlił.

Przy VBXE jest 2x węziej.

Jemu się po prostu wydaje, że jego zdanie na ten temat robi na kimkolwiek jakieś wrażenie. Stąd te dziecinne próby podpuszczania.

Przecież widać, że swinkamor12 wymyślił sobie na siłę powód, dla którego PPC jest najlepsze (rzekomy "nakład pracy" przy wymianie "skomplikowanych danych" ze starym kodem 68k), i że żaden argument, że jest inaczej, do niego nie dotrze; tak samo zresztą, jak to było przy jego poprzedniej fazie (kto zainteresowany, niech sobie znajdzie, a niektórzy pewnie nawet pamiętają).

Nie lubię Aranyma i nie poprosiłeś wystarczająco ładnie. A w zasadzie wcale.

Mieszasz pojęcia. Skompilowanie i uruchomienie dowolnego programu na dowolną-obcą platformę, gdy się nie ma gotowego środowiska emulującego jedną platformę na drugiej, nawet gdy obie mają tę samą indiańskość, wymaga dużego nakładu pracy i czasu, którego tu nikt nie zamierza na to poświęcać.

Natomiast wymiana danych pomiędzy pomiędzy x86 a m68k (czy ogólniej pomiędzy procesorem LE a BE) to żaden problem, odbywa się to przypuszczalnie miliard razy w ciągu doby, ilekroć ktoś przełoży kartę CF z peceta do starego maka (albo odwrotnie) w celu odczytania lub zapisania pliku.

Tyle razy wspominany przez Ciebie freemint to robi w sterowniku obsługi FAT. Nawet na m68k ta konwersja to nic specjalnego, dla 16-bit int to będzie 1 rozkaz (rol.w #8,dn - chyba 8 cykli na 68030, nie pamiętam już), a dla 32-bit int - 3 rozkazy: rol/swap/rol.

10 takich konwersji to 20 sekwencji takich rozkazów (bo to działanie jest komplementarne: odczyt - konwersja - obliczenia - konwersja - zapis). Niech sekwencja zajmie 20 cykli. 20x20 = 400 cykli. Dla procesora pracującego z częstotliwością 16 MHz działanie zatytułowane tutaj "obliczeniem" (x10) wydłuży się o 1/40000 (jedną czterdziestotysięczną) sekundy. Nie masz szans tego zauważyć.

EDIT:

A jakimiż to "skomplikowanymi danymi" posługuje się wg Ciebie program ze strony 164 zacytowanego podręcznika? Tam są tylko 32-bitowe wskaźniki oraz 8-, 16- i 32-bitowe integery.

Ten program to trzystronicowy listing w C wydrukowany maczkiem. Niestety, obawiam się, że musisz znaleźć coś, co w sposób prosty i jednoznaczny zilustruje problem, o którym piszesz. Bez "wywołań systemu", po prostu przykład obróbki danych, która się nie uda (da błędne wyniki), jeśli zastosujemy do niej konwersję BE<>LE. Siadasz, piszesz 10-15 linijek w C, i tu wklejasz. Z komentarzem. I to my ocenimy, czy ten przykład jest przekonujący, więc lepiej, żeby był.

I nie, nikt dla Ciebie nie będzie portował całego systemu operacyjnego razem z GEM-em, bibliotekami, kompilatorem C i Bóg wie czym jeszcze na x86 tylko po to, żeby sprawdzić, że się mylisz i istotnie żadnego problemu nie ma (BTW. GEM jest tak w ogóle przeportowany na Atari z PC, indiańskość w parameter arrays, w plikach RSC i w plikach IMG jakoś w tym nie przeszkodziła).

Tak prościej: to Ty twierdzisz, że w suficie jest dziura, a nikt poza Tobą jej nie widzi - a zatem to na Tobie spoczywa tzw. onus probandi, że ona faktycznie tam istnieje. Nikt inny nie jest póki co tym "problemem" zainteresowany, bo nikt nie widzi tu żadnego problemu.

Ja się chętnie zapiszę na takie urządzonko.