Raspberry Pi
category: code [glöplog]
Finally plugged mine to a screen and I'm configuring arch linux at the moment.
yay, mine arrived yesterday.. tried raspbmc RC3, and it plays full-HD-Videos (films as well as demo-captures) like a charm! interface is a bit slow but its fine.
-> multimedia-box - check.
let's see the further posibilities
-> multimedia-box - check.
let's see the further posibilities
How can I set an OpenGL window / context under this thing?
v3nom, I'll have to give it another try. RC2 was choppy as hell for me.
xernobyl: See the 'hello_triangle' example at /opt/vc/src/hello_pi/hello_triangle/ (at least, that's where it was for me on Debian).
Also: http://benosteen.wordpress.com/2012/04/27/using-opengl-es-2-0-on-the-raspberry-pi-without-x-windows/
Also: http://benosteen.wordpress.com/2012/04/27/using-opengl-es-2-0-on-the-raspberry-pi-without-x-windows/
Thank you.
The whole distributions thing is still a mess. I wonder if kids like to mess up with library paths, makefiles and what not to learn how to program on this thing.
Being that this thing can be used in a lot of ways, what would be the prefered way do distribute a prod, since you can have different GPU / CPU memory splits, and overclock it. Mine seems to work stably at 900Mhz without voltage changes.
Being that this thing can be used in a lot of ways, what would be the prefered way do distribute a prod, since you can have different GPU / CPU memory splits, and overclock it. Mine seems to work stably at 900Mhz without voltage changes.
It seems RS is taking orders again, for people who signed up for the backorder-list.
gloom: do they give estimates for when they'll ship the orders?
Quote:
what would be the prefered way do distribute a prod
as bootsector intro, with gpu support of course.
i don't understand, why would people start to code demos for linux now on even more limited machines? i mean those who didn't yet. i know, constraint and challenge fuel creativity, relating to the processing power et al, but this seems rather arbitrary. as long as its fun, i suppose.
It's a cheap fixed platform with a lot of expected support. But coding for/on linux is a bitch.
xernobyl: a long, long time away:
Quote:
Delivery Type Desc: Standard Delivery (Despatch expected within 12 week(s))
So, given that you wil have fixed hardware with the RPi...wouldn't it be nice to settle on some kind of standardized software stack as well and provide images that then would be some kind of standard demoplatform?
Any suggestions on how to start such a project?
Any suggestions on how to start such a project?
steam, good idea. I await other people's suggestions :)
Most interesing question would be what OS it would be based on. Seeing that even Linux Graphicla Userinterfaces seem slow I wouldnt even try anything else...if possible at all.
http://www.raspbian.org/ seems to try to fit everything to the rpi hardware. Will give it a try once I get mine. Then try to run some linux demos on it. Or would you guys prefer another OS, or "none" at all?
http://www.raspbian.org/ seems to try to fit everything to the rpi hardware. Will give it a try once I get mine. Then try to run some linux demos on it. Or would you guys prefer another OS, or "none" at all?
http://qt-project.org/wiki/Qt-RaspberryPi or this...
Since the OpenGL drivers are a proprietary blob, it seems to me that aside from reverse-engineering, we're stuck with Linux for any GPU stuff. (Or - more precisely - we're stuck with OSes that support ELF. IIRC there were people hating on Linux for this purpose because it wasn't "realtime enough" - are there any good alternatives on that list?)
My personal wish for RPi-as-a-demoscene-platform would be to distribute releases as self-contained bootable image files - which could be minimal Linux installations (using loopback stuff to embed the filesystem in that image file), some other exotic OS, or 128-byte 'bootsector' intros with no underlying OS at all. That way we don't need to care about OS versions and compatibility, and coders can go as close to the metal as they like.
The way I imagine it, we'd have a FAT boot partition on our SD cards (as we do now), with a /demos directory where we could plonk these images, and a bootloader that presents the contents of that directory in a nice friendly menu.
Disclaimer: I know fuck all about low-level OS internals and boot sequences for anything that isn't a ZX Spectrum, so I have no idea how much of the above is realistic.
My personal wish for RPi-as-a-demoscene-platform would be to distribute releases as self-contained bootable image files - which could be minimal Linux installations (using loopback stuff to embed the filesystem in that image file), some other exotic OS, or 128-byte 'bootsector' intros with no underlying OS at all. That way we don't need to care about OS versions and compatibility, and coders can go as close to the metal as they like.
The way I imagine it, we'd have a FAT boot partition on our SD cards (as we do now), with a /demos directory where we could plonk these images, and a bootloader that presents the contents of that directory in a nice friendly menu.
Disclaimer: I know fuck all about low-level OS internals and boot sequences for anything that isn't a ZX Spectrum, so I have no idea how much of the above is realistic.
I wish Dr Claw wasn't embroiled in his thesis right now as he'd have a lot to say on this topic. : (
maybe some stripped down (ms)dos...
Static compiled binary, run from console (without X11). Done.
I'm using a clean Debian.
I'm using a clean Debian.
What xernobyl said. Accessing the graphics hardware from the Linux console is very easy on the Raspberry Pi, and it doesn't stutter in the least. The standard OS image (Debian) should be the way to go for demos. No need to support those who've done custom memory partitioning etc.
Quote:
My personal wish for RPi-as-a-demoscene-platform would be to distribute releases as self-contained bootable image files - which could be minimal Linux installations (using loopback stuff to embed the filesystem in that image file), some other exotic OS, or 128-byte 'bootsector' intros with no underlying OS at all. That way we don't need to care about OS versions and compatibility, and coders can go as close to the metal as they like.
The way I imagine it, we'd have a FAT boot partition on our SD cards (as we do now), with a /demos directory where we could plonk these images, and a bootloader that presents the contents of that directory in a nice friendly menu.
Good and clever idea, Gasman!
Anyone up for making the loader/menu-viewer?
Did a bit of googling around earlier, and it seems that the furthest anyone's got so far in bare-metal coding (which is what we need for this boot menu, presumably) is this DexOS project, which has a screen display up and running (complete with good old Mandelbrot demo). Unfortunately USB keyboard support seems to be a bit of a roadblock - it sounds like you need to provide your own USB stack.
It looks like the best place to start with low-level RPi hacking is dwelch67's example code, but that doesn't even get as far as a display yet, so there's a certain amount of arsing around with serial consoles before getting to the fun stuff (and the DexOS guy seems a little bit reluctant to share his code).
Given what I've read, it sounds like a loader menu is a bit out of reach for the moment, and we'd be better off focusing our efforts on Making A Demo About It instead.
It looks like the best place to start with low-level RPi hacking is dwelch67's example code, but that doesn't even get as far as a display yet, so there's a certain amount of arsing around with serial consoles before getting to the fun stuff (and the DexOS guy seems a little bit reluctant to share his code).
Given what I've read, it sounds like a loader menu is a bit out of reach for the moment, and we'd be better off focusing our efforts on Making A Demo About It instead.
I'm curious, what do you hope to gain by going closer to the metal than using assembly language on a minimal Linux distro? Apart from for small intros
