Three quick Pi questions

Hi.
Goddamn that’s a fast boot! I bet Eben Upton was rather impressed with that (and I’m not using the latest ROM, the one on my SD dates to 1st October I think). I see, also, what the BootFX stuff is about. Looks kinda funny on composite video, but it’s a really nice touch. Not that you have time to, like, notice it much!

I am not going to ask about the long startup delay, I figured out that’d be the DHCP thingy. Gave it a static IP address and it zooms.

My questions:

1. The Pi has a 256MiB chip on top (I looked up the part number), but RISC OS appears to only be using 128MiB. Given the lack of GPU support in RISC OS, I really don’t think I need to reserve half the system memory for graphics functions. How would I knock this back to something more applicable (say, 16 or 32MiB) to give more to RISC OS?
2. There’s an extra header between the big P1 and the LCD edge connector. I don’t see anything written on the board to label this, and the GPIO descriptions I have found don’t mention this 4×2 header. What is it for?
3. Can the composite video output be switched to PAL? It’ll allow a better resolution (576 lines instead of 480). I like how the display is 4:3 pillarboxed; though I wonder how the heck it know my computer was 16:9 (or is this just something it assumes?).

It is slower than the Beagle at playing back my Tôkyô Sky Tree video (AVC, 400×300 at 25fps), and when accessing files there can be momentary pauses for no obvious reason; but benchmarks and such aside, it doesn’t feel any slower or faster than the Beagle. I don’t doubt it would allow me to play ShoutCast streaming radio while knocking together a document in OvationPro; Beagle and Pi side by side would probably fare “about the same”. The display on the Pi is worse, but then we’re comparing composite with s-video, and to the Pi’s credit it doesn’t treat composite as anything other than a scaled-to-fit copy of the main video output (so no colour issues like the Beagle). I do find only having two USB ports to be a restriction (mouse, USB disc, and….) but I plan to play around with a cross-over ethernet cable to see if I can share stuff off the eeePC to save faffing around with the USB key, plus allowing me to use a keyboard.

The most astonishing thing, though, must surely be that I can run the Pi and mouse and keyboard (or memory key) from a USB lead plugged into the eeePC. As the Pi isn’t a real USB device, XP won’t tell me the power consumption, however I believe the USB port would be disabled if too much power was drained.

I’m pretty excited, to be honest, about RISC OS upon both of these devices. It is good to see the platform continue to expand after the demise of Acorn. For all those involved in the more nuts’n’bolts work of getting the ports working – thank you.

1. Change the firmware. On the image there are various choices. Don’t use the 240 version, that leaves too little and you have to fix it on a PC. You just need to copy the relevant file over start/elf. (i.e copy and rename.)
You can access the DOS partition from the loader ‘folder’ in !boot

3. Video section: http://elinux.org/RPi_config.txt

Mine quite happily plays shoutcast with no impact. (But then so does my Iyonix.)

2. Additional GPIOs, according to http://www.raspberrypi.org/archives/1929
3. RISC OS Pi is defaulting to 1920×1080, which the VideoCore scales into whatever mode it selects based on whether an HDMI monitor is present, and what the EDID in that monitor contains.

3. Can the composite video output be switched to PAL? It’ll allow a better resolution (576 lines instead of 480). I like how the display is 4:3 pillarboxed; though I wonder how the heck it know my computer was 16:9 (or is this just something it assumes?).

I’m sure I’d seen reference to this somewhere. After looking for it I came across:-
http://elinux.org/RPi_config.txt
Not too far down is a list of Video options. Hope this may be of some use.

Gave it a static IP address and it zooms.

That’s a good idea.

I just gave mine a static assignment, then manually set it to that IP (so it will get the same whatever, assuming the OS in use gives the same MAC)

I got it into my head that the DHCP stuff was done by the Pi hardware before RISC OS started. The fact that it pauses mid boot should have been a clue. Doh.

Anyway, I gave it a static ip address and the boot was astonishing! I’m glad I saw this thread on the forum.

Anyway, I gave it a static ip address and the boot was astonishing!

One of the big benefits of RO.

A tip: If you are using a DHCP server without the ability to set reserved addresses assigned to specific MACs (this lack is common on home routers) then alter the DHCP IP range to stop at a point before the the normal .254 – say .192 and then assign any manually assigned addresses, like you have on the Pi, as addresses in the .193 – .254 block.

You then guarantee that the dynamically assigned devices in your network do not get an address assigned by DHCP that clashes with your manually assigned devices.
Pretty obvious I know, but then I know people responsible for networks with a couple of 1000 devices that do it wrong and they DO have the ability to set reservations by MAC.

Some answers…

1. The “gpu_mem” and “gpu_mem_256” settings didn’t seem to do anything, so looking around it seems I should have had more than just the one “start.elf” file. Which I didn’t. I did, however, track down arm192_start.elf from here (it’s a binary) which, when renamed “START/ELF” provided 192MiB for RISC OS and… erm… whatever is left for the GPU.
   
   
2. The extra header is P5. Big list of pinout information here (HTML page) – but probe +ve supplies first to verify it all matches up!
   
   
3. It wasn’t hard switching to PAL. In the “CONFIG/TXT” file, I just set sdtv_mode=2 but that came out horribly wrong – PAL but fuzzy and off the left of the screen. I noticed disable_overscan=1 so I tried it with disable_overscan=0 and then it worked correctly.
   It seems, unlike the Beagle, the RPi’s video output is fairly inflexible in that it will output a video picture “so big” and it will scale everything to that size. I have defined a 720×576 mode but it appears on-screen the same size as the 640×480 mode. Hmmm! ;-)

I also grabbed the latest ROM off the ROOL site and installed it. Mmm, new icons! It also seems as if FilerAction is less crashy than the 01/10 build.

Installing software was, actually, fairly easy. Since the Beagle doesn’t (or didn’t when I used it) support a shared partition SD card, the main RISC OS boot drive is a USB key. So I just popped that into the Pi and draggy-droppied everything.

The crawling interference pattern on the green text is kinda cool – very retro, it reminds me of when I used to code on the Beeb! ;-) I’m surprised the Broadcom chip doesn’t support s-video, however… or does it and the Pi people opted for composite in preference?

Piccy:

so looking around it seems I should have had more than just the one “start.elf” file. Which I didn’t

I was thinking that you were using the new RISC OS release, which has several. RISC OS works fine with the version that leaves 32MB for the video.

The latest start.elf should be universal (setting in config.txt) but it doesn’t seem to be distributed by ROOL, so I’m guessing it’s best left for another day.

You know, there was an optimization done in Windows XP, to speed up boot. Windows 2000 (as well as older NT versions) would wait for an IP address during boot, whereas Windows XP will actually kick off the DHCP request, then keep booting.

(Of course, that likely works better on a PMT system.)

And, I do the same thing with having a static and dynamic range. (Although I don’t set my static devices to have a static lease as well.)

As far as the video goes, the trick is that the BCM2835 actually has TWO display modes at once. The first mode is the output mode, and the second mode is the framebuffer mode. The BCM2835 scales the framebuffer to the output as needed. If you use the official RISC OS Pi distribution, it comes up in 1920×1080 framebuffer mode regardless of output mode. (Raspbian, OTOH, checks the BCM2835’s output mode, and sizes its framebuffer accordingly.)

So, to avoid scaling, if it hasn’t detected your display properly, you have to set the mode in TWO places. First, config.txt, second, !Configure’s monitor configuration.

You know, there was an optimization done in Windows XP, to speed up boot. Windows 2000 (as well as older NT versions) would wait for an IP address during boot, whereas Windows XP will actually kick off the DHCP request, then keep booting.

Which in certain circumstances causes problems for users with roaming profiles, plus other issues…

And, I do the same thing with having a static and dynamic range. (Although I don’t set my static devices to have a static lease as well.)

DHCP can do static or dynamic, “manually assigned” describes the ones where you configure the IP on the machine and DHCP reserved describes the ones where you set the IP on the server by entering the MAC. People confuse things by referring to “static or dhcp” instead of “static or dynamic”