Rozumiem wasz problem, i moim zdaniem najlepszym rozwiązaniem jest flash. Ja tak mam zrobione, w jednej połówce zapisanej na stałe mam XL OS, drugą mogę sobie programować czym chcę. Jak coś spieprzę, przełączam pstryczkiem, naprawiam i przełączam z powrotem.

Pecuś: ja mam te procedury, nawet w formie źrodłowej (i binarnej także). Mieszczą się w 2k. Wrzucę przy okazji.

Jellonek: tylko że Numen na ZX81 nie istnieje, a ja na poparcie moich słów mam działający program.

To, że mam rację, możesz łatwo sprawdzić wg mojej sugestii powyżej: wziąć maszynę o analogicznej mocy obliczeniowej (3,8 MIPS) i przy użyciu dowolnego kompilatora C zaimplementować w tym języku engine 6502 - jeśli osiągniesz w tym silniku 50% szybkości mojego, to osobiście Ci pogratuluję i odszczekam.

EDIT: Istnieje też alternatywa, emulec gdzieś tam się wala po sieci w postaci binarnej (o ile pamiętam 150k pliku wykonywalnego), możesz wziąć disasembler i zajrzeć.

Jeśli natomiast nie chce Ci się tego robić, ale za to wolisz twierdzenia o Numenie na ZX81, to - jak to już zresztą zostało dośc dawno temu powiedziane - dalsza dyskusja jest bezprzedmiotowa.

Jeśli niesłusznie, to uznaj aluzję za niebyłą.

Drogi Foxie, chyba niezbyt uważnie czytasz to, co napisałem. W takim wypadku na Twoim miejscu nie ośmielałbym się pisać odpowiedzi, że już nie wspomnę to nadaniu jej tonu nagany, jaki tu wyczuwam.

Osobiście nie uważam, żebym miał jakikolwiek - nawet moralny - obowiązek uczestniczenia w każdym będącym obecnie w toku projekcie na Ziemi. Dlatego też nie przypuszczam, żeby jakąkolwiek niegrzecznością z mojej strony było niepodzielenie się moim kodem z "grupą ludzi tworzących od 10 lat" coś tam. Jeśli jest to grupa ludzi, i pracuje od 10 lat, to spokojnie może się tego samego, co ja, dopracować sama, o ile składa się z ludzi myślących oraz o ile jej na tym zalezy i jej to jest potrzebne (podkreślam trzy warunki). Czy to nie aby Ty jesteś autorem powiedzenia "napisz se"? No.

Co do "sztabu ludzi tworzących gcc", napisałem chyba wyraźnie wyżej, że to ani gcc ani języka C jako takiego nie dotyczy - sprecyzuję może: trzeba byłoby zmienić definicję języka C. Ani mi to na myśl nie przyjdzie.

Żeby wszystko było zupełnie jasne, ja nie mam nic do udowadniania, ja wiem swoje. Co więcej, koncepcję, o której mowa, zrealizowałem w postaci działającego kodu. Mój emulator jest niedokończony, zgadza się, ale akurat silnik 6502 w nim działa dobrze.

Pamiętam. Jednak podtrzymuję, że zachodzi tu wyjątek, mianowicie w postaci programu, który jest silnikiem emulacji innego CPU. Tutaj C niestety polegnie, bo jest JEDNAK językiem stosunkowo wysokiego (za wysokiego) poziomu.

gcc dla m68k to było kolejno 2.7.2, 2.8.1, 2.95.2. Wszystkie wersje generują dość przyzwoity kod wynikowy, zresztą chyba nie może być inaczej, skoro gcc przeprowadza optymalizację jeszcze na etapie niezależnym od maszyny, a dopiero to co mu wychodzi przekłada na mnemoniki. Podejrzewam, że na innych platformach z jakością kodu jest dokładnie tak samo.

Pytanie jest idiotyczne z dwóch względów:

a) masz wyżej napisane, że silnik asemblerowy jest szybszy od ANALOGICZNEGO kodu w C (czyli: algorytm ten sam)

b) asembler to jednak nie jest C, więc wymyślenie programu w C, a potem przełozenie go ręczne na asembler nie może dawać wyników znacząco lepszych niz w przypadku produktu kompilatora; implementacja algorytmu musi być nie tylko w asemblerze napisana, ale tez w asemblerze wymyślona.

Dla ułatwienia dodam, że ten program chodzi na procesorach od 68020 do 68060 i nie zawiera nieczystych sztuczek w rodzaju samomodyfikującego się kodu (bo to na Motorolach powoduje problemy z cache'em).

Cały program z gcc nie ma nic wspólnego, poza tym, że gcc występuje tu jako wartość porównawcza. Ale twierdzę, że to jest właśnie taki przypadek, gdzie nie tylo gcc, ale dokładnie każdy kompilator zawiedzie. A to z tego powodu, że kompilator jest bezmyślnym automatem. Może optymalizowac znane sobie (czyli swoim twórcom) konstrukcje pod względem formalnym, oraz dokonywac analizy programu na np. częstotliwośc użycia pewnych zmiennych, żeby zdecydować, które zmienne umieścić w rejestrach, które na stosie a które gdzie tam. Oraz dysponuje repertuarem tym podobnych chwytów.

To wszystko jednak nie zmienia faktu, że kompilator nie ma bladego pojęcia, co kompilowany program robi, oraz jak można wykorzystać architekturę danej maszyny do zrobienia tego lepiej. To wie tylko człowiek, bo tylko człowiek jest w stanie zrozumieć algorytm.

Fox: zagadnienie nie ma nic wspólnego z opcjami optymalizacji kompilatora C, a raczej z tym, jak kompilator w ogóle działa, no i jak jest zdefiniowany język C jako taki.

Myślimy, że nie ma przeszkód, żebyś to zrobił.

Jellonek, ty teoretyzujesz, a ja napisałem w asemblerze silnik 6502 sześć razy szybszy od analogicznego kodu generowanego przez gcc. Taka jest różnica między zdaniem moim a twoim.

No to podziel się tym sposobem, bo mi na razie synchronizacja internetu z fi2 wydaje się koncepcją dość egzotyczną.

Moim zdaniem nie ma siły - pudełko może wysłać pakiet z informacją o zdarzeniu do komputera remotnego, poczekać na potwierdzenie przyjęcia i dopiero wtedy przesłać tę samą informację do kompa lokalnego ALE to też niewiele da, bo pakiet z informacją zwrotną nie nadejdzie natychmiast, lecz droga też zabierze mu nieco czasu.

Jeśli więc pomiędzy wysłaniem pakietu z informacją o zdarzeniu a potwierdzeniem przyjęcia upłyną np. 2 sekundy, to nie znaczy, że komputer zdalny dostał informację po dwóch sekundach, tylko że dostał ją gdzieś w czasie od t+0 do t+2, że tak powiem. Kiedy konkretnie - to jest kompletnie nie do ustalenia.

(EDIT: a może i jest - w pakiecie zdarzenia trzeba byłoby zaznaczyć czas nadania, a w zwrotnym czas przyjęcia; a dalej jak poniżej).

Rozwiązaniem jedynym realnym moim zdaniem jest transmisja synchroniczna, to znaczy pudełka generują określoną liczbę pakietów na sekundę niezależnie od tego co robią gracze. Streaming pakietów, innymi słowy, wtedy opóźnienia transmisji dałoby się łatwo przeliczyć w oparciu o podstawę czasu nazwijmy to, co pomogłoby wyeliminować desynch.

Ale obawiam się, że z tym będzie problem, o którym pisano już powyżej, to znaczy gra typu Spy vs. Spy przestanie być grywalna jeśli na na reakcję na ruch joystickiem trzeba będzie poczekać do paru sekund.

Alex, nosty ma rację, przemyśl to jeszcze. Tu nie chodzi o rozjechanie się zegarów, tylko właśnie sytuacji w grze, co będzie spowodowane tym, że "ewenty" joysticka będą docierały do obydwu komputerów nierównomiernie: do jednego - lokalnego - natychmiast, do remotnego natomiast - z opóźnieniem powodowanym przesłaniem pakietu przez internet. I odwrotnie, remotny komp będzie dostawał lokalne wydarzenia natychmiast, ale do twojego będą one docierały z opóźnieniem np. pół sekundy.

Efekt będzie taki, że ty go w ryj, i on na twoim ekranie w ryj dostaje, ale na drugim komputerze on jest już w drugim pokoju a ty nie wiadomo gdzie.

PS. demko to była Pierestroyka.