RC15

its raining cats and dogs

I came across an explanation of this. That some show-off in Elizabethan times, when Greek learning was new and trendy, described the rain as katadoupoi , the standard term for the Cataracts of the Nile (for its thunderous sound). This was misheard by unlearned persons as “cats and dogs”.

The story I heard was that cats and dogs sheltering in thatches sometimes got washed out. It sounds like an anecdotal cat falling from a roof might have combined with the greek word to establish the phrase.

The story I heard was that cats and dogs sheltering in thatches sometimes got washed out.

Extremely unlikely, thatch is pretty dense and holes large enough for such shelter would mean it was well past needing repair to stop leaks. I’d be more inclined to believe something like the cataracts misheard. Such things happen – misheard lyrics and even “Bowl in a china shop” (Dave Gorman)

The French versions are:

Mediæval: Il pleut des hallebardes – a rain of lances.

Rural: Il pleut comme vache qui pisse  – combines visual with sound effect.

Nothing to do with any future RC15.

With the zero page protection-compatible DDE27 now available, a new RC probably isn’t too far behind!

Does anyone have any more news about an RC15 release date?

I bought a Pi3 and RC14 in December with the intention of using RISCOS without being aware of the compatibility issues. I’m not familiar with RISCOS but with help from forum posts here I applied a recent ROM image, firmware, zero pain (I think?!), updated NetSurf and have a working computer.

But I can’t get the software on the NutPi I also bought to work. It copies itself to my boot SD card OK but when I then subsequently try and unzip any of the apps the Pi hangs.

At that point I figured I might as well sit tight and wait for RC15 but if anyone who’s got this far with a Pi 3 has a solution or any suggestions I’d be grateful so I can experiment in the meantime.

I use the October ROM low vector.
NutPi3 just works.

In fact, almost all the software I use works normally.
And it’s very stable too (much more than the RC14 on a Pi1).

http://www.svrsig.org/software/Update.htm

Thanks for the tip, David. Switching to the low vector October ROM solved my problems.

Just the Pi 3-friendly GPIO module to go and I’m up and running…

Just the Pi 3-friendly GPIO module to go and I’m up and running…

I understand that this has been solved (a GPIO module in ROM with necessary HAL changes for the Pi) but not yet checked in. Watch this space.

I understand that this has been solved (a GPIO module in ROM with necessary HAL changes for the Pi) but not yet checked in. Watch this space.

Checked in today, see ‘recent changes in CVS’.

As a new RISC OS user with a Pi 3 I’m super happy to see RC15 arrive. Many thanks to all at ROOL for making it happen!

Just installed RC15. Interestingly it’s low vector, which means ADFFS doesn’t work.

I’m running a recent ROM and have a recent HD4 dumped over my main install. Will RC15 do anything different for me or is that essentially what I’m already using?
Probably a silly question but I’m curious.

Just installed RC15. Interestingly it’s low vector, which means ADFFS doesn’t work.

No announcement and hasn’t triggered a bump in the daily build version to 5.25. It’s either a last death throw for Low Vector before 5.24 is released with High Vectors, or simply to provide support for Pi3, implying 5.24 is seriously delayed.

In light of this, I’ll look at adding Low Vector support back in for the next release of ADFFS.

It’s either a last death throw for Low Vector before 5.24 is released with High Vectors, or simply to provide support for Pi3, implying 5.24 is seriously delayed.

I don’t think it is correct to say that 5.24 (for the Pi) is seriously delayed. The RC15 SD card image includes fixes for all the bundled software so that it runs on the Pi model 3 (which has an ARM version 8 processor). Not a trivial piece of work and, in many cases, not under the direct control of ROOL. In comparison the work on the ROM has been proceeding steadily over the last two years as improvements have been checked in (and a revised ROM image has been available on-line for those who were interested).

Another consideration is that some users have purchased commercial software (e.g. Aemulor) that relies upon a low vector rom.

In comparison to the work of the last two years, the further work to get to a stable ROM build for the Pi (which is now well defined) is not extensive. RC15 is a significant milestone on that timeline. As RC14 lasted for over two years, some platforms would have said that that was a stable build.

+1

The only other comment I’d make is that high vector test ROMs are for just that – testing. It’s therefore sensible for the “mostly stable” RC15 to still be low vector.

As for ADFFS, please don’t go to too much trouble on my account!

In light of this, I’ll look at adding Low Vector support back in for the next release of ADFFS.

Oh thanks!

Another consideration is that some users have purchased commercial software (e.g. Aemulor)

Just need to support RC15 and Pi3, and all will be absolutely perfect.

I want to flag up some problems I have had with automatic recognition of the monitor since installing RC15 when used in conjunction with a KVM. I’m using a Benq G2222HDL (1920 × 1080) and was having persistent problems on booting with (a) the boot sequence stalling before getting to the display (solved by switching off the monitor before booting) followed by (b) the Pi selecting an inappropriate resolution (1920 × 1200) and declaring the monitor ‘out of range’. Connecting the monitor directly to the Pi appears to restore correct operation, hence my conclusion that the KVM is the culprit. Has anyone else had similar problems?

I’ve just installed RC15 (on a different card from the ones I usually use…fortunately).

Boots up straight away, no problem – but in a very odd, low resolution mode. It allows me to change mode to something relatively sensible (1920×1200) but I can’t change the screen configuration in any useful way: it still chooses some low resolution (not necessarily the same one, which seems strange) on reboot.

I tried copying my MDF from the other card, which works very nicely at anything up to 3840×2160×24Hz, which is the native mode for the monitor (at anything from 24Hz to 60Hz), but nothing above 1920×1200 even appears in the mode selection screen or screen configuration screen. Okay, perhaps that’s a CONFIG.TXT issue? So I copied the relevant lines from my old CONFIG.TXT into the RC15 CONFIG.TXT, and now the Pi won’t boot at all (or if it is, it won’t display anything).

Rewrite the image onto the SD card, and have a good root round. Not obvious what to do.

The only thing that’s wrong with my old development build SD card with its 3840×2160 etc. modes is that NetSurf doesn’t work, so I tried copying NetSurf off the RC15 image (where NetSurf works perfectly) onto the older development build card. No joy: NetSurf crashes in just the same way as it did before. (I presume this is the networking infrastructure underneath NetSurf, rather than NetSurf itself.)

I’m a bit at a loss. What I’d really like to do it get all my screen behaviour off that development build card into RC15, or get NetSurf working on the development build card, which would do just as well for the moment, but might be less future proof. I’ve no idea how to do either of those things, given that copying the obvious bits of CONFIG.TXT and the MDF file doesn’t seem to work in the first case, and copying NetSurf doesn’t work in the second.

What should I do?

Adding “disable_mode_changes” to CMDLINE.TXT prevents RISCOS from directly controlling the physical display resolution, which is instead fixed in CONFIG.TXT as has been the case up until recent Pi firmware.
http://forums.jaspp.org.uk:9000/forum/viewtopic.php?f=14&t=344&p=2747&hilit=config.txt#p2747

Then choose the right MDF in !Configure.

Please tell me if it works.

Will try very shortly – thanks!

I can’t even find a CMDLINE.TXT …

I suppose you must create it…