@Sim_Piko: zadam głupie pytanie... skąd brałeś źródła Atari800-3.1.0? Bo spróbowałem skompilować źródła z tego co podesłałeś i wychodzi na to że ./configure --target=rpi --host=arm-linux poszło bez najmniejszego problemu. Właśnie poleciał make, również bez problemu.

Ja źródła pobrałem z tej lokalizacji:

http://sourceforge.net/projects/atari80 … 800/3.1.0/

Właśnie sprawdziłem MD5 i wszystko się zgadza:

pi@raspberrypi ~/Downloads $ md5sum atari800-3.1.0.tar.gz 
354f8756a7f33cf5b7a56377d1759e41  atari800-3.1.0.tar.gz

Tyle że 'src' od Ciebie się kompiluje bez problemu, a pliki z sf.net tak jak to widać powyżej ;/

A widzisz... i tu jest "przysłowiowy" pies pogrzebany :)  na początek porównałem pliki "configure", są inne... masz świeższą wersję, ze sporą ilością zmian.

Hej!

Dzięki wielkie za pomoc... małymi krokami do przodu, czyli:

1) pobrałem archiwum (tarball)
2) odpaliłem autoconf (nie było pliku 'configure')
3) autoconf wygenerował sobie cośtam, po czym odpaliłem configure --target --host...
4) miłąchał, miąchał .... i mu nie wyszło...

...
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for library containing tgetent... no
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: `config.h.in'

pewnie coś nie tak robię z autoconf-em?

EDIT: pomogło 'autoreconf -i', teraz zapuszczam make... zobaczymy :)

Wszystko się skompilowało, trochę faktycznie dziwne scieżki ma domyślnie wpisane (/opt/vc/) dla gcc, ale nie przeszkadza to w kompilacji. Skompilowało się na RaspPI2 i działa :) Dzięki WIELKIE za pomoc! :)

ps) RP2 ma niby 4 jajka, a kompiluje używając jednego :)

najważniejsze, że naprawili, aby configure patrzył na to co system ma, a nie liczył na gotowego kros-kompilatora pod RPI_SDK

następnym razem użyj "tajnej " opcji: "make -j4" gdzie 4 to liczba  rdzeni
Domyślnie gcc kompiluje tylko jednym rdzeniem (chyba taka wsteczna kompatybilność do jedno-rdzeniowców) :v
EDIT: ajj, montezuma mnie wyprzedził :V

Nie polecam się :P i powodzenia w naprawianiu tego buga

EDIT: @montezuma, nie mam zielonego pojęcia, ale oby Ci się nie wykrzaczył SDL. Jak raz próbowałem odpalić emulca na monitorze z 1280x1024, to SDL dał ducha (warstwa GLES w kolorze czarnym + wyłączona klawiatura) i trzeba było zdalnie restartować. 1280x720 i 1680x1050 dzałały bez problemu. eSDeLek z linku w poście 19 o dziwo naprawił sprawę. To chyba mogło być przez audio HDMI, ostatnio miałem problem z Kodi... ale to już inna historia... :v

EDIT @down https://youtu.be/SrdBHYT4q7A?t=29m07s tekst numernabisa

Display wygląda tak:
http://www.abbuc.de/phpBB3/download/file.php?id=1991
a dokładniej tak:
http://www.ebay.de/itm/HDMI-VGA-2AV-Aud … 2a2e1e3550
Jest podpięty przez HDMI.

ATARI 65XE + SIO2BT

hmmm...

1. z repozytoriów Raspbiana pobieramy i instalujemy kompilator i biblioteki wraz z plikami nagłówkowymi, powinno wystarczyć coś w stylu "sudo apt-get install build-essentials libsdl1.2-dev libsdl1.2debian libreadline-dev autoconf", ale nie jestem pewien, które konkretne biblioteki są potrzebne.
2. stąd http://atari800.cvs.sourceforge.net/vie … /?view=tar pobieramy najnowsze źródła atari800 i wypakowujemy je.
3. wchodzimy przez konsolę do folderu wypakowanych źródeł, a potem do podfolderu "src"
4. odpalamy tam "./autogen.sh", który dotworzy parę plików niezbędnych do kompilacji.
5. następnie uruchamiamy "./configure --target=rpi --host=arm-linux"
6. potem "make -j4" (kompiluje emulca do pliku wykonywalnego, wykorzystując wszystkie cztery rdzenie malinki2)
6a. (opcjonalnie) można zainstalować tak przygotowany emulator za pomocą "sudo make install"
7. odplalamy emulator komendą "./atari800" (bądź "atari800" jeżeli wykonaliśmy krok 6a)
7a. (opcjonalnie) jeżeli korzystaliśmy z wersji 3.0.0, możliwe jest, że po uruchomieniu paleta ustawi się na maxymalną jasność. Wtedy wychodzimy z emulca klawiszem F9 i usuwamy/zmieniamy nazwę pliku "/home/pi/.atari800.cfg". (spowodowane jest to dodaniem opcji przestrajania palety(jasność/kontrast) dla palet z pliku).
9. (głosem Pascala B.) et voila, prosta kompilacja gotowa, smacznego grania :P
ps. dla maniaków synchronizacji pionowej, http://atari800.cvs.sourceforge.net/vie … iew=markup info jak ją uzyskać na 720p oraz 1080p

jak gdzieś się pomyliłem/czegoś zapomniałem, to mnie poprawujciepoprawcie

Dzięki @Sim_Piko.

Nareszcie wszystko poszło tak jak trzeba.

nie mam zielonego pojęcia, co złego mogło by się stać.
Ja jakoś gram na tym, co mi system zapodaje, bez żadnego grzebania w config.txt

Prędzej @seban wyjaśniłby (albo właściwie już wyjaśnił w postach 20 i 22) dlaczego VSync jest tak ważny.

gdy mam odświeżanie ustawione na 60Hz i emulator na PAL to w przypadku platformy Windows i emulatora Atari800Win-Plus czy Altirra to efekt jest równie straszny, szarpanie scroll-ami, tryby interlace zamiast wyglądać jakby miały więcej jasności/kolorów z lekkim migotaniem, wyglądają okropnie, drżąc i wyświetlając nierównomiernie dwie klatki obrazu składającego się na cały obrazek w interlace, wygląda to okropnie, w przypadku RaspPI / SDL gdzie nie było Vsync, wyglądało to równie okropnie.

Dziś sprawdzę Ci jak wygląda różnica gdy przestawię RPI2 na 60Hz i odpalę emulację w trybie PAL. Wydaje mi się że będzie ciekawie bowiem emu wydaje sie być zatrzymywany do czasu wystąpienia V-Sync (stwierdzam to po fakcie że nie działa Turbo Mode / F12) gdy go włączę nadal mam 100% wydajności emulatora, tylko dźwięk zostaje wyłączony, a render-pipeline i tak uwiązany jest do V-Synca.

Cześć,

Niestety nie ;/ Turbo działa mniej więcej przez 0,5sek (prędkość ~350%) po czym prędkość spada do 100%, tak jakby "turbo mode" zostało wyłączone, ponowne wciskanie F12 lub włączenie turbo mode w opcjach emulatora nic nie zmienia.

EDIT:

Przełączyłem na tryb 1080p @ 60Hz ... no i niestety przy PAL scroll-e szarpią widocznie, wszystkie efekty które normalnie wykonują się "in one frame" (żargonowo "wchodzą w ramkę") wyglądają paskudnie. Ale za "turbo mode" działa... od ~450% do ponad 800% w zależności od tego co się dzieje na ekranie.

Co ciekawe w trybie 1080p @ 60Hz, po przełączeniu emu na NTSC, Turbo Mode również działa...

dodaj wpisy

# uncomment to force a specific HDMI mode (this will force VGA)
hdmi_group=2

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
hdmi_drive=2

# enables the ignoring od EDID/display data if your display is a crappy
# Chinese one
hdmi_ignore_edid=0xa5000080