Rick's b.log - entry 2013/08/03

The 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!

Speaking of which

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

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...

BBQ

Me?

I don't do BBQs.

I do pasta:

Oh, and pancakes:

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

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?

Share a Coke with...

A welcome surprise

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:

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!

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

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.

USB MIDI

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

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): http://www.midi.org/techspecs/electrispec.php

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 03388 backwards.
		Your comment