Is there any port of Altirra for RPi?
So I will boot RPi into Atari 8bit?
7x130XE + 3xAtari Falcon030 + 1xTT03 + 2xST-ATX
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
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.
atari.area forum » Emulacja - 8bit » Altirra on Raspberry Pi?
Zaloguj się lub zarejestruj by napisać odpowiedź
Is there any port of Altirra for RPi?
So I will boot RPi into Atari 8bit?
no, there isn't
altirra is windows x86 application, so it can't be used on arm based rpi.
with little effort there could be done some little linux distribution with framebuffer based atari800 starting in preconfigured environment but... there is probably no one interested in doing this...
Why not? I'm interested :) Latest Raspbian distro is very promising.
My idea is to have linux core and boot into Altirra (or another emulator that supports 1mb RAM, VBXE and Stereo Pokey) for watching demos or playing VBXE games etc. RPi800 distro or something like that. SDCard image...
Sun: jellonek probably meant "interested" as in someone who's going to do that as opposed to someone who just wants that.
lamiel: gimi rpi and i'll do something like that for you ;)
if not through fbcon, this is doable without big effort through Xorg
jellonek I am for this moment not interested in this, so my RPi will now do what it does, whatever it is ;) .
And if this is a must, there is a http://sourceforge.net/projects/rpiqemuwindows/ so if You want You can.
Atari800 compiles on raspbian "just like that". Another thing is speed. To reach full speed, every second frame must be dropped and pixel size set to 1x1 or 2x2. Forget about fullscreen. Tested with 'enable veryslow' or something on r-pi 512MB at 900 MHz.
This thing is damn slow, slower than G3@400MHz (in processor time, not gfx card).
you might want to use oncpu features, and map framebuffer directly rather than going through drivers and SDL, but it takes time to do it and knowledge
none of them around anymore...
people think they can port any kind of poorly written software straight into embedded system - well, think again
Yes I want -but- I will not due to reasons you mentioned.
It was an 10-minutes test.
Hovever I'd suspect sdl to work with processor on-chip supa-dupa capabilities.
Do you think Raspbian is "poorly written software"? I think maybe so, as linux is written by accidental people.
I do not think that poorly-written = slow. Rather: fast=>poorly written, and: well written->slow.
Maybe some day skilled person with spare time will boost it to use on chip capabilities. But when it will be?
Some reasons found here: https://projects.drogon.net/raspberry-p … i-and-sdl/
sdl does not make any use of any of cpu capabilities, especially these for handling bitmaps, and doing everything in software is always the worst choice, especially if hardware already is there
i've been dealing with linux kernels for embeded systems for quite some time (almost a year now) and i see many inconsistences between modules of what suppose to be unified code for single platform, so i wouldn't expect much of rasbery here
main issue here is that people writing user end applications have no clue of how hardware works, and relay on lower layers of software/os to handle it - not nessesary the case for embedded systems, as they have very little support striaight from manufacturers, and sometimes some drivers are not freely available
all you can assume is that mmu works, memory controller was programmed to match onboard's memory and general use hardware works, so one can actually boot the system
preformacne will be rather average
main issue here is that people writing user end applications have no clue of how hardware works, and relay on lower layers of software/os to handle it - not nessesary the case for embedded systems, as they have very little support striaight from manufacturers, and sometimes some drivers are not freely available
Candle: somewhat true, that would be desirable, but how about time to market?
Nobody plays 'code poet' anymore, since rolling apps for a new hardware is faster with existing codebase, than writing all the stuff yourself.
If you have SDL or fbdev you just use it. Performance and writing code bare-metal is a long gone concept today.
Now there is time to unbury this topic as we have Raspberry Pi 2 which is 4-core ARMv7. The Altirra is written in C and is open source so maybe there is a way to recompile and run it on Pi2
Just looked through Altirra's source files and well...
Some files seems to be written in x86(or even x64?) assembly language.
Altirra's render engine is based on DirectX and OpenGL, while RPi can handle (partially afaik) OpenGL ES 2.0 (via EGL layer?) at best.
Raspbian doesn't have hardware-accelerated X11, so GUI needs a rewrite too.
SDL2 got partial RPi support, so... maybe...
I guess it's not impossible to port Altirra to RPi but it would be sloow program to use.
[offtopic]
I have Rasperry Pi B and I'm using Atari800 on it. There are slowdowns sometimes but at least it works.
(here's link to SDL1.2 library with better RPi HW support)
(gah, sorry for engrish)[/offtopic]
Atari800 compiles on raspbian "just like that". Another thing is speed. To reach full speed, every second frame must be dropped and pixel size set to 1x1 or 2x2. Forget about fullscreen. Tested with 'enable veryslow' or something on r-pi 512MB at 900 MHz.
This thing is damn slow, slower than G3@400MHz (in processor time, not gfx card).
https://youtu.be/i-SnA4wRYWw?t=2m35s
Moim zdaniem szybko chodzi.
nie wiem co wam tam wolno chodzi ale mi na Rpi 1 z 265 ram Demka chodza spoko.
Tymbardziej ze jest dolozony TFT po fbtft by notro ktory tez troche zrzera proca
https://vimeo.com/118503743
Oczywiscie mowa o atari800 ktore imo jest genialne i nie ma jak narazie z tym problemu :)
Raspberry PI 2 niewiele tu chyba pomoze.
Emulator atari800 wspiera SDL w wersji 1.2.
Niestety SDL w tej wersji nie wykorzystuje hardwarowego GPU Raspberry PI (support pojawil sie dopiero dla wersji 2.0).
SDL w wersjach 1.2 i 2.0 to rozne API i konieczne bylyby zmiany w emulatorze.
Moze ktos dorobi do atari800 support dla SDL 2.0?
Atari800 w PiStore nie uzywa SDL, tylko GLES2:
https://www.raspberrypi.org/forums/view … mp;t=30889
Problem sie rozwiazal :)
gwoli ścisłości (z http://www.atari.org.pl/forum/viewtopic … 28#p208228 )
(...)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/GLES2 prosto na hardware'owo akcelerowaną warstwę z procka graficznego RPi, gdzie jest m.in. skalowany na całą możliwą do wyświetlenia rozdzielczość.
SDL jest nadal wykorzystany.
Z tego co się bawiłem z grami w wersjach SDL1 i SDL2, ten drugi przeważnie był wolniejszy o jakieś 5-10 klatek na sekundę, ale to chyba temat na inny wątek.
Dzięki za wyjaśnienie.
To znaczy emulator renderuje obraz na "wirtualnym" display-u np. 320x200, a potem GPU skaluje to na np. 1080p?
Przepraszam, że tu ale chciałem się na szybko podłączyć takimi oto pytaniami w temacie Altirry (bo właśnie przed wyjazdem na zlot próbuje ogarnąć dla dzieciaka emu):
1. włączam dla portu 1 Joy na kursorach. Pytanie: gdzie jest fire i dlaczego naciśnięcie ctrl powoduje, że kierunki przestają działać.
2. czy jest jakiś przyspieszacz do SIO (taki jak np. w Atari800win) by nie czekać godzinami na załadowanie czegokolwiek?
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Emulacja - 8bit » Altirra on Raspberry Pi?
Wygenerowano w 0.034 sekund, wykonano 55 zapytań