no już poprawiłem, angielska jezyk trudna jezyk ;l

zasady właściwie się zmieniły od ostatniej wersji: nadal trzeba układać 'beczki' w linie jednego koloru

ja może, w ramach archiwizacji dla potomnych, podlinkuję wątki z sąsiedniego forum o tym emulcu
Emulacja ANTIC'a na GPU - wątek w którym się wszystko zaczęło
Emulacja POKEY'a w przeglądarce
Fred + Parallax Background - jak na razie najświeższy wątek

U mnie w Edgu działa spoko, Chrome Portable też odpala, a Firefox 56.0.1 (główny browser, nie pytajcie czemu nie aktualizuję) nie ładuje wcale. z innych rzeczy, trochę w uszy kłują odgłosy spadających kamieni w Boulder Dashu (ale to chyba wynika tylko z tego, jak są generowane szumy). Poza tym, zapowiada się fajny emulec, fajnie było pograć w Robbo z 'zepsutym' scrollem jak sprzętowy HSCROLL / VSCROLL nie był jeszcze zaimplementowany :P

"CORE - Dead Feelings"
źródło: z komentarzy do filmiku

https://www.youtube.com/watch?v=iSuFPZ8W3uE

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

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

no powiem tak, 3.1.0 wywala ten sam błąd co tobie
przejrzałem config.log-a, a ten stwierdził, że kompilator nie istnieje

...
configure:2825: checking for C compiler version
configure:2834: /bin/arm-linux-gnueabihf-gcc --version >&5
./configure: line 2836: /bin/arm-linux-gnueabihf-gcc: No such file or directory
configure:2845: $? = 127
configure:2834: /bin/arm-linux-gnueabihf-gcc -v >&5
./configure: line 2836: /bin/arm-linux-gnueabihf-gcc: No such file or directory
configure:2845: $? = 127
configure:2834: /bin/arm-linux-gnueabihf-gcc -V >&5
./configure: line 2836: /bin/arm-linux-gnueabihf-gcc: No such file or directory
configure:2845: $? = 127
configure:2834: /bin/arm-linux-gnueabihf-gcc -qversion >&5
./configure: line 2836: /bin/arm-linux-gnueabihf-gcc: No such file or directory
configure:2845: $? = 127
configure:2865: /bin/arm-linux-gnueabihf-gcc -o conftest -O2 -Wall -I/include -I/include/SDL -I/include/interface/vmcs_host/linux -I/include/interface/vcos/pthreads   -Wl,--unresolved-symbols=ignore-in-shared-libs -L/lib conftest.c  >&5
./configure: line 2867: /bin/arm-linux-gnueabihf-gcc: No such file or directory
configure:2869: $? = 127
configure:3082: checking whether we are cross compiling
configure:3120: result: yes
configure:3124: checking for suffix of object files
configure:3146: /bin/arm-linux-gnueabihf-gcc -c -O2 -Wall -I/include -I/include/SDL -I/include/interface/vmcs_host/linux -I/include/interface/vcos/pthreads  conftest.c >&5
./configure: line 3148: /bin/arm-linux-gnueabihf-gcc: No such file or directory
...
configure:3166: error: cannot compute suffix of object files: cannot compile

główna różnica między "configure" z 3.1.0 a najnowszą wersją z repo, dzięki której jest taka:

---3.1.0---
if [ "$a8_target" = "rpi" ]; then
    CC="${RPI_SDK}/bin/arm-linux-gnueabihf-gcc"

---HEAD---
if [ "$a8_target" = "rpi" ]; then
    [ -z "$RPI_SDK" ] && RPI_SDK="/opt/vc"
    CC="arm-linux-gnueabihf-gcc"

... co by znaczyło, że 3.1.0 jest wręcz nastawiony na cross-compile z peceta (kompilator musi wtedy być podany w zmiennej RPI_SDK), a w najnowszej wersji, jeżeli RPI_SDK nie istnieje/jest puste, to główniejsze pliki związane z RPi bierze z standardowego dla raspbiana miejsca "/opt/vc/", a kompilator jest brany z tego co siedzi pod poleceniem "arm-linux-gnueabihf-gcc", niezależnie od platformy.

...wow, nie wiedziałem, że tyle wiem ._. (albo właśnie odkryłem wodolejstwo)

EDIT: A na tej stronie co Ci podałem jest taki link "Download GNU tarball" który Ci spakuje do pobrania najnowszą wersję kodu :P

hmmm... kompilujesz przez gcc 4.6 czy przez 4.8? albo to, albo (strzelam, że) brakuje Ci jakiś plików nagłówkowych
EDIT: zaraz, kompilujesz na RPi czy na pececie?

checking whether we are cross compiling... -->YES<--

Nie powinien się kroskompajl aktywować, jeśli kompilujesz z malinki :/

Świeża binarka (wraz z źródłem) prosto z najnowszych źródeł, jeszcze ciepła. ...też na niej występuje ten błąd :/
https://www.dropbox.com/s/qtbdhpa0weunf … ar.gz?dl=0
Skompilowane na Raspbianie na RPi 2 z konfigiem "./configure --target=rpi --host=arm-linux" oraz tą wersją SDLa 1.2 z ciut lepszym  hardware'owym renderowaniem na RPi

Nie jestem specem w C/C++, ale z tego, co przejrzałem źródła emulca, na raspberrym SDL jest wykorzystywany do dźwięku, obsługi klawiatury, afaik także dżojstików.
Grafika też jest generowana przez SDL, tyle że wygenerowany obraz zamiast być od razu wyświetlony na ekranie przez SDL-a, idzie przez EGL prosto na hardware'owo akcelerowaną warstwę z procka graficznego RPi, gdzie jest m.in. skalowany na całą możliwą do wyświetlenia rozdzielczość.
Strzelam, że gdzieś przy wyświetlaniu tej warstwy, cuś się chrzani i widać ww. błąd. (pewnie gdzieś w pliku "atari_rpi.c")
Może (nie wiem, nie znam się aż tak) to przez fakt, że rpi nie potrafi obsłużyć więcej niż 16bpp kolorów.
EDIT: Pogrzebałbym coś więcej, ale na razie jestem bez pc-ta, ... a na raspberrym jakoś nie umiem za nic konkretnego się zabrać :V

A, i jedno pytanie - po kiego grzyba(bez urazy) trzeba zmieniać "/boot/config.txt" jak i bez tego mogę wesoło popykiwać sobie w River Raida czy Boulder Dasha?

Edit2: byłbym zapomniał, przed ./configure trza jeszcze odpalić "./autogen.sh", który to plik "configure" tworzy

jak na razie wykrzacza się po wybraniu opcji "Palettes..."

wersja prawie skończona
TODO: - poprawić instrumenty

@xxl: jak tylko znajdę jakiś program, co pozwoli na tak niskie basy -_- (link patrz 0:26)

W załączniku test echa