RISC OS London Show 2014

Really? Is there a link to where I can download a working version of Firefox?

Yes. Here

Choose your language for default. Load it on a PC.

Or, use the local file version RiscOSM and use NetSurf for browsing – two tasks two applications.

Please read again, I was criticising Google Translate.

Find an interesting looking Japanese page. Give it to Google. Try to comprehend the results. Fun!

That said, I find Google often badly mistranslates negatives in French.

I know. The point I was making was that VRPC only remains in existence as an available product because it runs 26 bit programs. If it was restricted to 32 bit only (RO5) then it is largely useless as genuine hardware exists to outpace the emulator. Diminish the market like that and the product disappears.

Arg. No, I mean, a version of VRPC that runs under RISC OS 5. To provide RISC OS 4 support in RISC OS 5.
Sorry. Was not clear :)

Anyway I would like it ALSO to support RISC OS 5 as a guest OS (but not to limit to RISC OS 5).

It was being used to demonstrate the Open Street Map project

As other folk have said, the software on show was RiscOSM which uses Open Street Map data to render maps as Draw files which you can then export, print, or use however you like. It was being shown on the giant screen because actually viewing a map that big might be a useful thing to do with a giant screen! After all, most of us have far less real estate on our monitors than the Ordnance Survey fit on a traditional fold-out map….

My stand was the next along where I was selling the software.

To clear up one or two misconceptions, RiscOSM uses map data which resides on your hard drive, SD card, or CD ROM, and does not pull the map data direct from the internet on the fly. The data sets have to be reprocessed into a suitable form for rendering the maps, which is pretty time-consuming, so that’s why it’s done this way. The British Isles takes up about 700MB of space.

Open Street Map is more than just the slippy map you can see at http://openstreetmap.org/ — that site just shows a few handy renderings of the data, but there is no end to the possibilities if you have your own renderer and design your own style sheets. It’s also possible (not on RISC OS) to use the vector data behind Open Street Map to produce routing engines. See the cycle journey planner at http://www.cyclestreets.net/ for an example (this site won’t work on NetSurf).

If you just want to view the openstreetmap.org site on a RISC OS machine, then the best option is to use Thomas Milius’s MapView software. It’s on !Store as well as his web site. That downloads the PNG format tiles for a small amount of map and converts to sprites to display on RISC OS. It’s free, and quite nice. I hope he develops it further as it’s much more practical on a global scale: downloading and converting the data for the whole world for use in RiscOSM would be a massive undertaking, but MapView does not have that limitation!

RiscOSM wins if you want to explore the data in the map, design new ways of viewing it, export easily for use in other apps, or print a high-quality vector-based map. It can also give access to hyperlinks for viewing web sites relating to many of the mapped features, and has a bookmarking system too.

..which was very nice, though the mouse pointer disappeared 60% across the the width.

The pointer was disappearing when it passed the 2048 X offset…. I had hoped to poke around in the source to try and resolve the issue before the show but didn’t have the free time to do so.
I’ll probably have a look in the next week or two.

It was connected to a Raspberry Pi.

The refresh rate was only 14Hz.

Actually it was driving the screen at 24Hz, I just didn’t tweak the monitor definition enough to get it to display the correct number.
In practice it didn’t seem too bad using it for general desktop use.

Really? Is there a link to where I can download a working version of Firefox?

Peter Naulls’ 2009 port to RISC OS of a version of Firefox can be found from links here

It takes an age to load on an Iyonix and is then not very stable. When asked at the show about browsers for his new i.MX6-based hardware, Andrew did refer to this version, and it would be great if Peter Naulls could be persuaded back into the fold to continue porting work for the very much faster machine.

The Iyonix port of firefox works also with the new hardware and also with the i.MX6 maschine. For all you need set alignment exceptions off.

My offer to look to trying to bring the ABC compiler more up to date with BBC BASIC changes since, well, at least the last twenty-odd years, is still open, if anybody is interested…

The first step is to bring it up to speed with version 1.05 (April 1992). ABC’s use of LOCAL variables is imaginative as the following example shows:

var%=6
PROCfred
END
DEFPROCfred
LOCAL var%
chunk of BASIC (using var%)
more BASIC (using var%)
identical chunk of BASIC (using var%)
ENDPROC

If you move the ‘chunk’ and ‘identical chunk’ into a procedure or function (to make maintenace easier) then interpreted BASIC will use the correct local variable as it uses the stack to store local variables, restoring them from the stack on exit from the procedure where they were defined as LOCAL, but the ABC compiler uses the global value of var% (in the delegated procedure or fiunction) as it treats local variables as private (i.e. separate and only in scope in the procedure where they are defined, not in any procedures or functions that it might call) rather than local.

How was it connected to the computer?

A single HDMI cable.

The pointer was disappearing when it passed the 2048 X offset…. I had hoped to poke around in the source to try and resolve the issue before the show but didn’t have the free time to do so.
I’ll probably have a look in the next week or two.

I don’t think you’ll find anything in the RISC OS code per se, because I see no such problem on wider screens myself. It’s possibly in the BCM2835-specific graphics driver code, but I wouldn’t be at all surprised if it turns out to be a VideoCore-side limitation, quite possibly within the hardware logic itself. The chip in question was specified to do 720p video and may not cope with such wide screens. I note that 2048 × 32bpp = 65536, ie. a 16-bit product would overflow, and the first thing I’d suggest trying is dropping the bit depth to 16bpp to see whether the problem disappears.

Re pointer disappearing at 2048:
Searching/asking on the Pi Forum would also be a good option, in case it is a hardware limitation.

I don’t think you’ll find anything in the RISC OS code per se, because I see no such problem on wider screens myself.

I was pretty much expecting it to be a Raspberry Pi specific issue.

the first thing I’d suggest trying is dropping the bit depth to 16bpp to see whether the problem disappears.

Reducing the number of colours (or even the resolution) in RISC OS has no effect (The pointer still disappears around the 60% mark). Trying to reduce the framebuffer depth in the config.txt file appeared to have no effect at all (Tried forcing it to be 16 or 8 bit and the RISC OS desktop still looked exactly the same)

Then the VideoCore side will still be operating at 32bpp so, unfortunately, that’s inconclusive. Is it possible to run Linux at this resolution on the Pi? My guess would be that nobody else has tried ;) If it’s found to be okay at this resolution, that still won’t tell us anything; there could be a software workaround in the Linux driver code, or even a soft cursor.

I do remember seeing some threads on the R-Pi forum about issues with large displays – specifically something about an internal buffer that’s used by the scaler/overlay system. Not sure if it was a hard limit or something which could be tweaked in the firmware. Potentially changing hvs_priority as mentioned in this thread will fix it, but I’m not sure that’s the thread I’m thinking of.

Really? Is there a link to where I can download a working version of Firefox? Yes. Here

I tried that but it asked me to choose between Windows, Mac OS, and Linux

I tried that but it asked me to choose between Windows, Mac OS, and Linux

Well, yes. It’s very hard to use RISC OS in isolation these days — unless you’re some kind of masochist.

Peter Naulls’ 2009 port to RISC OS of a version of Firefox can be found from links here. It takes an age to load on an Iyonix and is then not very stable.

Okay, I’ve done that and installed it with !PackMan, but when I click on !Firefox no icon appears on the icon bar.

Which machine do you use. For Beagle, Panda and RPi have the “Alignment Exceptions” set off.
RPi via !Boot or !Configure and CPU-option and for the Beagles and the Pandas use !AlignEx.
I have try your way (install via !PackMan) with my SchlepPi and it works with “AE off” but some time will go…

The machine is a PandaRo Pro running RISC OS 5.19 so I’ve downloaded !AlignEx – which has no Help file, so before I use it, what on Earth are alignment exceptions?

I’ve tried googling for this term, but just get what seem to be arguments on ROOL about the dangers of changing them.

what on Earth are alignment exceptions?

Something to switch off for better compatibility.

I think I could handle a little more detail than that, but in the meanwhile why not switch them off?

The driver hooks the function by patching the system call table, so it’s not safe to unload it unless another thread’s about to jump in there and do its stuff, and you don’t want to end up in the middle of invalid memory.

:D

Unaligned load/store instructions (where the address is not on a word boundary) worked consistently on earlier ARMs but give unpredictable results on later ARMs (where they are not defined) and so you have two choices: generate an exception error OR allow possibly invalid data to be returned or stored. Programmes that contain such instructions MAY be doing something unimportant at the time OR may be using just one byte that happens to be returned correctly. The Pi is an ARM v7 and so can be told to replicate the earlier behaviour. Panda is later and cannot pretend to be an earlier ARM.

This is probably a bit inaccurate but hopefully close enough!

To expand upon that, an aligned load means to load a word (4 bytes) of data from an address divisible by four. This is the natural data size of the ARM processor.
An unaligned load means to load the data from an address that is not divisible by four.

In the olden days, the ARM, when presented with an unaligned address to load data from, would load from the corresponding aligned word (so if you asked for the word at +7 to be loaded, it would load from +4) but (and this is a very big but), the data supplied would be rolled around in a way that was predictable but always seemed a bit peculiar to me. If the address was +1, the data was rotated one byte (to the right). If the address was +2, rotated two bytes. If +3, three bytes.
It was simply not possible to load “normally” from an unaligned address on the original ARM.

Why might this be useful? Between you and me, I’m not sure it is. However, it is possible to synthesise a half-word (16 bit) load with some code such as the following:

   LDR    R0, [R3, #2]
   MOV    R0, R0, LSR #16

A lot of data back then used 16 bit words, it is the native size of the original x86 (which is why in the DOS days we had all that fun with obscure Memory Models and __near and __far pointers, etc).

These days? These days if you ask the ARM to load from an unaligned address, it can. It is, though, classified as an “alignment fault”. As Chris says, sometimes this is intentional, but usually it can have unintended consequences. An example of this is the FYEO2 program which makes a lot of unaligned loads when reading JPEG data. Since the newer processors don’t do that load-and-roll thing, the data that is read will not be what was expected, and as such, JPEG decoding utterly fails. Some programs can tolerate failed loads and you won’t notice anything is amiss, some programs will blow up in your face if the loaded data is wrong.

You get to choose whether the computer shrugs and lets it happen, or if it aborts the program with an alignment exception. I would advise keeping alignment exceptions ON because chances are, what the processor is doing probably isn’t what the programmer thought the processor ought to be doing…

As a rule of thumb – ARMv5 and earlier (most of RISC OS history) will do the load-and-roll. ARMv7 and later (OMAP, etc) will do an unaligned load. ARMv6 (Pi)? You get to pick which behaviour you prefer. For future compatibility, but the best choice is the later (correct, and with exceptions) option.

Addendum: Story is a lot more complicated in reality. It depends upon the memory system, the type of MMU, blah blah. Luckily for us, RISC OS runs on machines with capable hardware. Some ARM devices are more restricted in their abilities. This is in part due to ARM being a licensor of cores rather than a chip maker. The basic ARM is the more or less the same; everything else in the bit of silicon? Not so much. ;-)