Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Emulacja - 8bit » atari800-3.0.0 Raspberry PI2
Zaloguj się lub zarejestruj by napisać odpowiedź
Cześć,
Czy ktoś z was spotkał się z takim błędem emulacji w przypadku uruchomienia atari800-3.0.0 na Raspberry Pi2:
zdjęcie (robione tosterem który mialem pod ręką)
oczywiście screen-shoty (F10) wyglądają bezproblemowo:
ps1) Raspberry Pi2 podpięte przed HDMI, tryb 1080p @ 50Hz
ps2) Muszę sprawdzić jeszcze atari800-3.1.0
UPDATE:
Wiem jakiego rodzaju jest błąd, na początek prosty testowy program w Atari BASIC:
10 GRAPHICS 9
20 FOR I=0 TO 15:COLOR I
21 PLOT I,0:DRAWTO I,191
22 PLOT 31-I,0:DRAWTO 31-I,191
25 NEXT I
30 CLOSE #1:OPEN #1,4,0,"K:"
31 FOR I=0 TO 15
32 POKE 712,I*16
33 GET #1,K:IF K=27 THEN 40
34 NEXT I
35 GOTO 31
40 CLOSE #1
99 END poprawny obraz wygląda np. tak:
natomiast problemy zaczynają się gdy manipulujemy kolorem tła, wartość koloru $8x-$Fx wpisane do ColBack, powodują że najwyższy stopień jasności ($0F, czyli COLOR 15 w Atari BASIC) staje się kolorem czarnym, co widać na zdjęciu poniżej: (COLBACK=$80)
ps) nie umiem poprawnie skompilować Atari800-3.1.0 bezpośrednio na Raspberry PI, na cross-compilację zgodnie z informacjami w 'build-rpi' nie miałem jeszcze czasu. Czy ktoś ma może skompilowane Atari800-3.1.0 na Raspberry PI?
Nie ma problemu z kompilacja Atari800-3.1.0 na Pi.
Sciagasz tgz, rpozpakowywujesz, wchodzisz to atari800-3.1.0/src, uruchuamiasz ./configure, a jak wszystko pojdzie ok to make.
Na pi wersji 1, kompilacja trwa jakies 10 minut.
Cześć,
Dokładnie tak próbowałem zrobić ale chyba czegoś brakuje, albo coś źle robię, bo 'make' po configure kończy się u mnie tak:
pi@raspberrypi ~/atari800-3.1.0/src $ make
gcc -c -o afile.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls afile.c
gcc -c -o antic.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls antic.c
gcc -c -o atari.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls atari.c
gcc -c -o binload.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls binload.c
gcc -c -o cartridge.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls cartridge.c
gcc -c -o cassette.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls cassette.c
gcc -c -o compfile.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls compfile.c
gcc -c -o cfg.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls cfg.c
gcc -c -o cpu.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls cpu.c
gcc -c -o crc32.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls crc32.c
gcc -c -o devices.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls devices.c
gcc -c -o emuos.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls emuos.c
gcc -c -o esc.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls esc.c
gcc -c -o gtia.o -DHAVE_CONFIG_H -I. -O2 -Wall -ansi -pedantic -Waggregate-return -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Winline -Wredundant-decls gtia.c
gtia.c: In function ‘GTIA_GetByte’:
gtia.c:532:16: error: ‘INPUT_CONSOL_OPTION’ undeclared (first use in this function)
gtia.c:532:16: note: each undeclared identifier is reported only once for each function it appears in
gtia.c:535:16: error: ‘INPUT_CONSOL_START’ undeclared (first use in this function)
Makefile:82: polecenia dla obiektu 'gtia.o' nie powiodły się
make: *** [gtia.o] Błąd 1chyba nie tylko ja mam problem... http://sourceforge.net/p/atari800/mailm … /30753436/
i dodam że nie chcę budować wersji SDL tylko taką renderującą przez Open GL ES. Wersja 3.0.0 działa prawie doskonale (z wyjątkiem tego co pokazałem wyżej), szybko i bardzo bardzo dobrze radzi sobie z synchronizacją, trybami interlace, płynne scrollingi, etc.
a z tego co widać wyżej również wersja SDL się nie chce kompilować, a ./configure --target=rpi nie działa u mnie również.
To chyba zostaje mi tylko próba z cross-compile ;/ Chociaż patrząc w źródła kod dla OpenGL jest podobny i pewnie efekt będzie ten sam. Spróbuję napisać do autora wersji OpenGL/RPI.
Ale ten błąd wygląda na brak jakiegoś pliku nagłówkowego, tudzież problem ze ścieżkami.
ja nie twierdzę że tak nie jest, tylko nie wiem gdzie mam się zaczepić aby coś więcej się dowiedzieć, nawet jeżeli doszedłbym czego mi brakuje, to według tego co napisali tutaj: http://sourceforge.net/p/atari800/mailm … /30753436/ ... to i tak zbudowałbym wersję SDL, która na Rasppi nie nadaje się do użytku...
Without cross-compiling you can build regular SDL without OpenGL at all (like on other linux'es).
But it's looks ugly on raspberry pi. I dont know how to detect build for raspberry without additional command line options.
Now it's configured for cross build (with --target==rpi).
a próby kompilacji z '--target=rpi' natwynie również nie udają się bo:
Hi)
--target=rpi is configured for cross compiling. You can read build
instructions how to setup it. Building on raspberry is tooooo slow.
22.04.2013 0:01 пользователь "Jan Krupka" <krupkaj@...> написал:
i u mnie kończy się to tak:
pi@raspberrypi ~/atari800-3.1.0/src $ ./configure --target=rpi
checking build system type... armv7l-unknown-linux-gnu
checking host system type... armv7l-unknown-linux-gnu
checking for gcc... /bin/arm-linux-gnueabihf-gcc
checking whether we are cross compiling... yes
checking for suffix of object files... configure: error: in `/home/pi/atari800-3.1.0/src':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more detailsjest jeszcze jeden wątek, i to jest jakaś nadzieja na przyszłość, ale to pewnie potrwa zanim ujrzy światło dzienne:
http://sourceforge.net/p/atari800/mailm … /33673846/
w chwili obecnej build atari800-3.0.0 ze wsparciem Open GLES zawsze się synchronizuje z v-blank, tzn. nie działa Turbo Mode (F12), prędkość jest ograniczona przez v-sync i pomimo włączenia Turbo i tak emulator nie osiągnie prędkości większej niż 100%. Ale to niewielki koszt za ultra płynne scrolle, działający poprawnie interlace i pozostałe wszystkie niuanse, które powodują że całość bardzo zbliża się do oryginału :)
Nie wiem czy dobrze myślę ale nie powinieneś chyba używać target=xxx jeżeli kompilujesz na architekturze docelowej.
no bez "--target=rpi" to masz wcześniejszego log-a, o którym pisałeś że brakuje być może plików.
Do kompletu na forach i w doc-ach piszą że jak budujesz bez target (co zresztą też nie działa), to budujesz wersję SDL, bez Open GLES... które to SDL na Raspberry PI niedomaga ;/ brak wsparcia sprzętowego, brak double-buffer, brak v-sync, software blits only, etc. czyli ogólnie rzecz biorąc "el masakra".
Zależy mi na wersji 3.1.0 ze wsparciem Open GLES, i napisałem post na forum raspberry pi, do autora tego kodu, ale się okazuje że forum jest ultra moderowane, mojego posta nie widać i nie będzie widać do czasu aż jakiś moderator nie zechce zatwierdzić moich wypocin.
odpal skrypt install_dependencies.sh na rpi
potem spakuj i wystaw gdzieś całą zawartość folderu /usr
niestety nie mam rpi dzialajacego zby samemu to zrobic, a jest to niezbedne do kompilacji.
Hej!
Wybacz głupie pytanie, mało zorientowanego człowieka, ale ten skrypt to gdzie powinien być?
szczeże mówiąc to nie mam pojęcia ;P
Zrób bez tego.
Seban,
a czytałeś tutaj?
https://www.raspberrypi.org/forums/view … mp;t=30889
Dla 1080p i emulacji PAL zaleca się specjalne ustawienia w pliku config.txt:
/boot/config.txt
hdmi_group=1
hdmi_mode=31
Jeśli wystarczy Ci działająca wersja binarna, to polecam instalacje atari800 z PI Store-a.
Pozdrawiam
@willy: już się kompresuje, upload pewnie pójdzie szybciej :)
@Montezuma: nawet pisałem o tym że mam tak ustawione w pierwszym poście (1080p @ 50Hz), a co do wątku do którego linkujesz nawet napisałem w tym wątku, (obecnie ostatni post) opisując problem który napotkałem, być może autor poprawi opisany przeze mnie błąd. Atari800-3.0.0 mam zassane z sf.net (tam leży skompilowana i gotowa binarka dla RaspPi) i działa prawie dobrze (z wyjątkiem błędu który dokładnie opisałem wyżej).
Chciałbym skompilować wersję 3.1.0 i jeżeli to się uda to zacznę wnikać w kod renderujący być może uda mi się to poprawić jeżeli wcześniej autor tego nie uczyni wcześniej, chyba wiem gdzie jest problem, ale aby to sprawdzić muszę mieć działającą wersję.
@willy: done... plik znajduje się tutaj.
Dosc spore ... moglem sprawdzic sciezki co jest faktycznie potrzebne
to może nie walcz, bo szkoda Twojego czasu, spróbuję cross-compile uskutecznić, jak się uda to wystawię obraz maszyny wirtualnej (Virtual BOX), może komuś się przyda.
Wlasnie cross compilacje probowalem uskutecznic ... ale nietstey na freebsd jest to chyba niemal niemozliwe. Za duze roznice.
Jednak jestem juz nieco madrzejszy :D Czesc problemow ominalem/rozwiazalem jednak jest to nadal zbyt daleko od ok.
To ja spróbuję z maszyną wirtualną i na tym Debian Linux, ale to wieczorem. FreeBSD mam "produkcyjne" nie będę próbował sobie go psuć, a mam talent do tego :)
Ś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
Ś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
Dzięki Wielkie! Jak dotrę do domu to sprawdzę! :)
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ść.
Jest dokładnie tak jak piszesz, z tym że Open GLES oprócz sprzętowego skalowania i blittowania, idealną synchronizację z V-Sync.
Gdy kompilujesz bez --target=rpi to kompilujesz wersję które również blittuje i skaluje za pomocą SDL, również brak V-Sync, skalowanie wygląda koszmarnie i w dodatku mocno to wszystko obciąża CPU.
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
Patrzyłem trochę na kod renderujący widok dla Open GLES, i mogę się jedynie domyślać gdzie jest problem, chciałem to poprawić... tyle że nie potrafiłem ogarnąć kompilacji na Raspberry PI. Jeszcze raz dzięki za naprowadzenie na właściwą drogę :)
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?
Aby włączyć tryb 1080p z refresh rate na poziomie 50Hz (PAL), a co za tym idzie aby osiągnąć płynność i idealną synchronizację z V-Sync. Wszystko jest idealnie płynne, nic się nie przycina, nie skacze, nie szarpie scrolling-ów. Dopiero to wersja (Open GLES / Rasp-Pi) daje ten efekt. Na domowym PC mam również monitor w trybie 50Hz @ 1080p, i gdy odpalam Altirra z V-Sync + "speed match to broadcast"... to też jest "prawie" dobrze. Sęk w tym że Windows zawsze znajdzie sobie coś ważniejszego do robienia i widać czasami wkurzające przycięcia obrazu i inne artefakty, które to nie występują gdy emu jest uruchomiony na Raspberry Pi.
Ja odpalalem ./configure bez target bo to raczej jest potrzebne do budowania pliku wynikowego dla innej niz obecna platformy.
@moonsoft: już pisałem kilka razy wcześniej... dlaczego upieram się przy --target...
Gdy kompilujesz bez --target=rpi to kompilujesz wersję które również blittuje i skaluje za pomocą SDL, również brak V-Sync, skalowanie wygląda koszmarnie i w dodatku mocno to wszystko obciąża CPU.
użycie --target=rpi włącza renderowanie poprzez Open GLES. W dodatku gdy ustawisz sobie odpowiedni tryb config.txt masz super płynność i idealny V-Sync, taki jak przypadku PAL (jak sobie ustawisz 50Hz mode), lub jak ktoś woli NTSC (60Hz) też nie ma z tym problemu. Dla mnie PAL refresh rate i pełen sync to "konieczna konieczność", inaczej mam mdłości gdy widzę przycinające się srcolle i inne uboczne efekty :)
./configure bez --target=rpi przechodziło, potem jednak umierał przy 'make', a efekt po 'make' we wcześniejszym poście.
@seban, no cóż, jednym synchronizacja pionowa przeszkadza, innym nie. tak czy siak, dzięki za wyjaśnienie :P
@Monsoft, jeśli dobrze pamiętam "src/configure" sam z siebie nie potrafi wykryć, że jest kompilowany na malince, dlatego trzeba ręcznie zaznaczyć "--target=rpi", żeby kompilował wersję z GLES-owym hackiem.
Z OpenGL-i RPi obsługuje sprzętowo (chyba) tylko GLES1 i GLES2, a pod X-ami nie ma żadnego (przynajmniej officjalnego) wsparcia na GLESy.
OpenGL idzie tylko przez software'owt sterownik MESA (z zasady baaardzo powoli, przeważnie w sekundach na klatkę)
coś jeszcze mam nie tak...
pi@raspberrypi ~/atari800-3.1.0/src $ ./configure --target=rpi --host=arm-linux
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
checking build system type... armv7l-unknown-linux-gnu
checking host system type... arm-unknown-linux-gnu
checking for arm-linux-gcc... /bin/arm-linux-gnueabihf-gcc
checking whether we are cross compiling... yes
checking for suffix of object files... configure: error: in `/home/pi/atari800-3.1.0/src':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more detailshmmm... 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 :/
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Emulacja - 8bit » atari800-3.0.0 Raspberry PI2
Wygenerowano w 0.049 sekund, wykonano 80 zapytań