mailto: blog -at- heyrick -dot- eu

The hammock

I'm on summer holiday. Three weeks of not going to work. Actually, the holiday started Friday before last, at half twelve. The first thing I did was go and buy a nice solid hammock (on clearance offer). It's a very peaceful way to relax. I'm in the hammock as I write this; oh the joys of WiFi!
Relaxing in my hammock
[I'm relaxing, not dead! ☺]

That said, midsummer - sadly - is way past us, the holiday coincides with the bringing in of the wheat harvest, it's coming to the end of the agricultural cycle for another year.
But on the plus side, look at that lovely blue sky!

Empty fields and deep blue evening sky


Speaking of which

...I picked up another Livebox yesterday. It is missing one of its rubber feet, but otherwise it appears to be working okay. The power brick was in a box, so I'm hoping this one is a new unit and not a customer return. It appears to be working, so... third time lucky?

As a small anomaly, the woman at the supermarket checked the Livebox for return and ensured that both it and the power brick were there. She then said "you don't need to give back this stuff" and handed me the ADSL cable, the line filter, the short network cable, and the Livebox-to-phone-socket adaptor. Bizarre, but hey, spare parts are always useful!


Rained out

Was at a vide grenier the other day when the sky turned. Mom suggested we go back, and some people were deciding whether or not to cover the stuff they were selling. Bright flash of lightning and a man said "oh crap, I've not switched off the house!" (well, in French) and he legged it leaving his wife to deal with the stall.
Not the sky you want to see at a vide grenier!

Then it rained. I mean, Epic Rain. It chucked it down. But then, on and off it has chucked it down in style as wave after wave of thunderstorm pass through. Laval and Caen were flooded, several times. We were at a large supermarket during one downpour and mom was concerned about the roof. Nothing happened, but a short way up the road the roof of a supermarket failed. It didn't collapse, thankfully, but there was a ten metre long waterfall in the middle aisle.

People tend to forget that while they might enjoy insufferable heat and relish the opportunity to douse themselves in skin cancer, anomalous weather does not arrive without a penalty. This is why it is preferable to slide into seasons, instead of hopping from 18&dec;C to 32°C...



Of course, when the hot weather turns up, the females of the species dress in ridiculous clothes (if you're embarrassed about being seen in bra&panties, how can you wear that?), while the males have visions of getting in touch with nature by doing the venerable barbeque - a concept that primarily involves taking perfectly good pieces of meat and adding fire, incinerating the outsides while leaving the insides raw.
There are, one might suggest, less troublesome ways to clobber the human immune system...


I don't do BBQs.

I do pasta:

Pasta a la fresco!

Oh, and pancakes:

Okugai no pankęki (outdoor pancakes)


Hey Mona Lisa, who was Leonardo? Was he Andy Warhol? Were you Marilyn Monroe?

[title from "Something Worth Leaving Behind" performed by Lee Ann Womack]

I know that Andy Warhol said, in '68, "In the future, everyone will be world-famous for 15 minutes", and that as a leading figure in the pop-art movement, he might have thought to use Perrier cans instead of Campbell's soup cans; however I wonder if he anticipated having his name scrawled across cans of bottled water forty five years later?
This might be some hipster-trendy-retro French thing, but I'm just not seeing how Mr. Warhol connects to Perrier water at all...unless it is intended to appeal to hipster-trendy-retro Frenchies?

Warhole water?


Share a Coke with...

Speaking of drinks, Coca-Cola (as in Holidays Are Coming, Coke-Is-It, and First time first love, Oh what feeling is this?) has devised a rather clever campaign. Lots of coke bottles with lots of names, and the text "Share a Coca-Cola with <name>".
Mom's is Jennifer (which seems to be the usual French rendering of her name), and mine is Alice for I'm born on the day of Sainte Alice (one of the Catholic saints who appeared to lead a life that didn't end in bloodshed and tragedy; she is known as Adelaide of Italy to the anglophone world).
Share your coke with... (awww, sweet, but wait, can we catch something nasty doing this?)


A welcome surprise

A generous and anonymous benefactor (I know who, but they don't want to be named) has purchased for me the latest version of the Desktop Development Environment.
The ROOL DDE pack

My previous incarnation of the DDE dates from the Castle/Iyonix era, but in terms of the ARM processor, quite a few fundamental things have changed since then. The biggie is the issue of unaligned loads - that is, addresses on the ARM processor are supposed to be "aligned" to a word boundary. A word is a 32 bit value, or four bytes, therefore the address you load word-sized data from should be an address divisible by four. Now, if you load data from an address that is not divisible by four, the older ARM processors would load the data from the next lowest aligned address and rotate it around weirdly (rotated right by eight for each byte off of being a word aligned address); while the newer ARMs will - literally - load the unaligned word (with some caveats). Somewhere in the middle, there is an option on the ARM v5 and v6 families to not load unaligned at all, but instead throw an exception.

It has been said that unaligned loads allow you to quickly read halfword (16 bit) values from arrays of 16 bit data by using the load instruction, then a shift or a mask to get rid of the unwanted 16 bit value.
I struggle to understand the thinking here, as surely a legal word load with a shift or mask is just as simple? The only complicated factor is that you need to know to read words and mask off the desired halfword instead of just incrementing the offset by two, which is the lazy approach. Certainly, I have always - since my days coding ARM on the ARM2 - considered unaligned LDR to be more trouble than it is worth; and it seems my concerns were justified...
...but hey, who listens to some random twat with a self-written blog, anyway?

So back to the DDE. The older (Castle) one crashed on newer hardware. It could be coaxed into working by disabling alignment exceptions, but then the line numbers for compiler errors and warnings would be total gibberish - so I had serious concerns about the quality of code generated by the older compiler. If it tried some fancy optimisation...

Here it is, a ROOL branded USB stick:

ROOL branded USB stick - a piece of RISC OS history!

In response to this, I have done two things: I have updated by "fork" of DeskLib. More on this below. I have also (partially) written a USB compatible clone of Acorn's MIDI module. More on that below, too.

This also, pleasingly, brings me the capability of rolling my own build of RISC OS. I plan to do that soon.

At any rate, it is great to have a compiler that just works on the new hardware. Many thanks to XXXXX for this!


A slice of Pi!

While the Beagle is about a third more powerful than the Pi, and it contains twice as much memory, I anticipate doing my current round of development on the Pi.

The reason for this is the Pi's video is controlled by a GPU that works in a slightly odd way. I tell the Pi, at startup, in a configuration file, what sort of display I want. In my case, 1280×1024 at 60Hz. Then, whatever I choose in RISC OS, it will be scaled to fit that. Essentially I can switch modes all over the place without concern.

The Beagle, on the other hand, has a more traditional approach to video output, so getting a stable video signal means having a good MDF (monitor definition file). Unfortunately, getting some sort of video output on the Beagle with an HDMI-to-VGA adaptor seems to be a fairly hit and miss procedure. It would scale everything to fit into the s-video output, but with the DVI output, it tries to output what it is being told to do - which is rather annoying when you have a stable display and then, after a reboot, the HDMI-to-VGA adaptor just provides a blank screen, even though the machine should be using the same settings as just previous!
I will get this to work, I just don't have time right now.

It is possibly also worth mentioning that it appears as if the Beagle's display capabilities might max out at 1280×1024 at 57Hz. While the ARM core is later and faster, the GPU is only rated for 720p as compared with the Pi that has bolted an older/slower ARM core to a damn fast (apparently HD1080 capable) GPU. This is why the Pi is finding application as a home media device; while for raw grunt, the Beagle xM wins (well, actually the Pandaboard, which is like a Beagle-Maxi (OMAP4, something like 1.5GHz?) wins, but I don't have one of those so it isn't in the comparison).


DeskLib 2.30/RM

This is based upon version 2.30. I note, sadly, that DeskLib is apparently no longer going to support the DDE, but will be GCC/ELF. I can understand supporting GCC in addition to the DDE as it brings an option for those who cannot afford the DDE (although RISC OS Open's forty-some quid or bundled with the NutPi suite is ridiculously cheap compared to what I paid Acorn for C release 4 all those years ago), however the move to ELF is the part that I don't agree with. ELF is a specifically NON native RISC OS filetype and it means future development of DeskLib is likely to exclude those using the DDE.
I had never planned to fork DeskLib. I just rolled my own build a decade or so back because nobody else seemed to see the writing on the wall that a 32 bit version would be a necessity.
However, given this, and because I think the RISC OS DDE is The One True Toolchain, I'm going to nail my colours to the wall and say - it's a fork. It's official. I will continue with DeskLib 2.xx/RM and keep it DDE compatible.

If you have suggestions for features, if there is stuff from the other DeskLib you'd like rolled in to mine, or if you know of a bug or two in need of TLC, you know my email address.

The first build of DeskLib 2.30/RM that should be fully 32 bit safe is here:

Note that the library file is called desklib32 so you can have old and new side by side if you write code for Acorn-era machines. You'll need to link with the ...32 library in order to use this.



Another project on the go is to reimplement the old Acorn MIDI module, only this time talking to USB devices. This was a project I had no necessity to do (I use MuseScore under Windows and both keyboards talk to Windows) but it was something I wanted to do, given the lack of support for musical instruments under RISC OS these days.

Unfortunately, the RISC OS USB stack (all its many variants) each have their own quirks and issues. Sufficient that I'm wondering if it was a good idea to even begin in the first place...

So here is the second alpha release of the (USB)MIDI module, with the following provisos:

  • Tested and works on a RaspberryPi, but hangs a Beagle - though my Beagle firmware is old and it might be that at fault.
  • If your computer hangs, don't panic. There's a 99% chance that the USB system is frozen awaiting data that isn't there. Just unplug the MIDI device, reality should then continue... ;-)
  • Only supports ONE port (MIDI device) at this time. The one chosen will be the first one found.
  • The module detects device removal and will mark the port as disabled. It does not, yet, detect device insertion - so you'll need to *RMReInit MIDI if you reinsert the MIDI device.
  • There is no timestamping. MIDI data is checked for in 10cs intervals (because USB, given MIDI is a "bulk" device for some reason, does not appear to set a flag or cause an interrupt - instead we must specifically ask for data). If you feel 100ms/10cs is too long, get in touch. For what it is worth, a steady allegro clock of 120bpm will tick twice per second. 50cs per crotchet. The MIDI clock ticks at 24 times per beat, or roughly every 2cs at 120bpm. Due to the 10cs polling, it is not possible to tag an absolute time to the received data, however the timing can be reconstituted by looking at its relationship to MIDI ticks.
  • MIDI_RxCommand has not been implemented.
  • No Service Calls or Events.
  • In short, it's an Alpha version. Pre-Beta. Probably won't work, but just might. ;-)

The latest version of the module, with text programs:

And here's a 106K PDF that documents the module, with rough mods for the current status:

The previous version was tested...

  1. Raspberry Pi model B (256Mb) / RISC OS 5.21 (28 Jul 2013)
  2. Yamaha PSR e-333 keyboard, with its own internal USB interface
  3. my "miditestx" software
  4. my "playtest" software
This version was tested...
  1. Raspberry Pi model B (256Mb) / RISC OS 5.21 (28 Jul 2013)
  2. Roland E-16 keyboard, via generic QinHeng USB to MIDI dongle
  3. With, and without, Colin's modified USB driver [see ROOL forums]
  4. my "miditestx" software
  5. my "playtest" software
  6. !Maestro and all of the demo files


Your comments:

Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.

Rick, 4th August 2013, 00:18
Even if I can't get the Beagle video working with the HDMI dodah, I will DEFINITELY use it for RISC OS system builds. It's a no-brainer (to use a horrible expression). I mean, it's pure processing power and data shifting so it's initially a question of ~700MHz ARM vs 1GHz ARM. Plus, I might see if I can knock up a program to copy the entire toolchain and source tree to RAMdisc for the builds, so it can all work without _touching_ external media. The Beagle has more than enough RAM to pull this off, and enough CPU oomph that it would be daft to think of anything else!
Rick, 4th August 2013, 00:20
"_touching_"? ;-) Spot the person used to ROOL's Textile interpreter! 
Textile, being generally horrible and sucky, uses underscores for ITALICS. 
Yup, really.
Rick, 5th August 2013, 15:38
Looks like the Beagle will do 1024x768; but in order to get it to work I need to drop to BASIC and switch to MODE 12 (that's an old-style TV mode!) first. Bizarre.
Zerosquare, 5th August 2013, 16:22
I guess the Orange shops backrooms are overflowing with defective Liveboxes, so they tell people to keep them ;) 
Is there a spare serial port that supports 31250 bps on the Pi? With a bit of extra hardware, you could make a MIDI port out of it, and you wouldn't need to bother with USB. See the official site for low-level details (it's for a 5V power supply, but the same idea can be used for 3.3V supply if you adjust the resistors values):

Add a comment (v0.11) [help?] . . . try the comment feed!
Your name
Your email (optional)
Validation Are you real? Please type 89821 backwards.
Your comment
French flagSpanish flagJapanese flag
«   August 2013   »

(Felicity? Marte? Find out!)

Last 5 entries

List all b.log entries

Return to the site index



Search Rick's b.log!

PS: Don't try to be clever.
It's a simple substring match.


Last read at 14:49 on 2024/05/26.

QR code

Valid HTML 4.01 Transitional
Valid CSS
Valid RSS 2.0


© 2013 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.


Have you noticed the watermarks on pictures?
Next entry - 2013/08/15
Return to top of page