What software would you like to see on RISC OS?

One obvious piece of software that will be needed before we can move on from Low Vector ROM builds is a 32-bit version of Impression. If we end up with no working Aemulor on ARMX6/Pandaboard/Titanium then we will have to revert to Virtual Risc PC and abandon the latest hardware and RISC OS 5 and move back to RISC OS 4.39/6.

32-bit version of Impression

Who do we canvass to do that?

How is the Imp author getting on – would he like some extra help?
Looking at the Code – it seems to have been written by various people.
(cunning plan) seems to ring a bell :-)

[edit – it’s not written in ‘C’]

Too cryptic again. I was referring to the vagueness of the description “current printers”

So sorry for being vague, I was thinking of when I bought my Pi and plugged in my usb Canon MG7160 and booted up Raspbian, I was able to print from the Pi to that printer. I was unable to do the same with RISC OS. My addition to the wish list would be have the capability to plug a usb HP, Canon, Epson, etc. ink jet printer into a stand alone RISC PC and print directly from RISC OS without needing to go through Windows or buy a laser printer. I am also aware that it is unlikely to happen but that is not the point of a wish list.

How is the Imp author getting on – would he like some extra help?

Richard Keefe has put a lot of work into this project but is a long way from finishing. I spoke to him at the South West Show and he explained that his father-in-law has been involved in a serious road accident (not his fault). As a result, his wife is spending time away from home and Richard is taking up the slack at home.

He hasn’t been able to make any progress recently. I’m sure he’d like some help but I doubt whether or not he’d have the time to get anyone else up to speed.

32-bit version of Impression

Who do we canvass to do that?

Or we just use Ovation Pro, which is already 32bit and very capable. Especially if we have never used Impression before (i.e. me!)

Of course, now that I’ve said that, cue Fred telling me that StrongEd will do all that (either now, or in the next version!).

Not quite, but StrongED is still being developed so it’s always possible to request additional features. I doubt it will ever become a full IDE but extending it to provide some more IDE-like functionality should be possible. Either directly or through add-ons.

An example of such an add-on is the auto-completion add-on I wrote for AppBasic mode. It allows one to quickly insert an AppBasic veneer by typing the first few characters of the Toolbox object/gadget name and then pressing Ctrl-Space. This will produce a menu with all possible veneers for that object/gadget. Highlight the one you want then press Return to insert it.

How much can be provided depends on what features users want and if these can be fit into StrongED’s design. The first step, of course, is for users let me know what new features they’d like to see…

not strictly a cad package but could be used for cad because it has layers Etc and is free http://www.keelhaul.me.uk/acorn/oss/

Ah yes, I was going to mention DrawPlus or Vector for simple CAD!
For circuit design there’s also RiscPCB – http://www.mbelect.co.uk/RISCOS/

No one has mentioned Gutenprint for lots of additional printer support, and more modern machines make printing times more acceptable – http://www.mw-software.com/software/gutenprint/gutenprint.html

“@Richard Windley:” Sourcery brings the Pain like no other. 1056k just for starting it. Any plans for a newer version to sort that?
I only just upgraded to the current version too after seeing the link. I didn’t realise there was an update.

RPCEmu.

I’ve said it a few times before, but in my opinion full-system emulation is the best long-term solution for allowing users to continue to run their old software. With a decent JIT and some good integration with the host OS, the overall user experience shouldn’t be that bad. And the maintenance cost of keeping the emulator working with new host OS/hardware versions should be a lot less than the costs associated with maintaining a compatibility layer/user-space emulator like Aemulor/ADFFS.

allowing users to continue to run their old software

Thats all very well but I’m more interested in the future and in new software (or newer version of the current programs).

I think RISC OS has a brighter future ahead of it and it would be nice to see some more applications ported or written to attract yet more users/developers.

Thats all very well but I’m more interested in the future and in new software (or newer version of the current programs).

In that case…

• Software & drivers for digital TV tuners. Most of this will probably be dependent on having a decent video/media stack, since digital TV tuners tend to just extract the raw MPEG TS stream from the signal and leave the rest up to the CPU/GPU. But you’d also want decent software for performing channel scans, DVR capabilities, etc.
• A better SciCalc. Fix it to display the results at the full internal precision (something I’m currently working on), improve the calculation/answer history (e.g. multi-line display and the ability to select lines to re-enter them), graphics calculator functionality, etc. Possibly there’s already a calculator app which does all this, but my first instinct when I want to calculate something is to open up BASIC in a task window, so I haven’t actually bothered to go looking for other solutions.
• More (up-to-date) compilers. Both for old languages and for new ones. There’s a lot more to the world than just C & C++!
• The long-awaited Wimp version of ArcEm ;-)

RPCEmu

Absolutely.

@Tristan M. I’m not sure I understand ‘Sourcery brings the Pain like no other’?

I don’t actually see 1056K here, I see 824K, but how you would like me to sort it? It is a fairly chunky application – even if it appears on the surface to just put a facade on other apps. I don’t know what spec machine you have, but 1056K isn’t excessive these days. As I look at the applications I have loaded I see Organizer at 224K, Sunfish at 1052K, OvationPro at 2496K and NetSurf a massive 7364K (ignoring the 31M dynamic area).

If you are having genuine problems I’ll be happy to take a look, but this is actually the first comment I’ve ever had about excessive memory usage… or is the capital P in Pain some reference to Zero Pain? I am genuinely confused!

or is the capital P in Pain some reference to Zero Pain?

I suspect so.
Might be worth doing a pass through of the source after reading the page on converting software

Probably a female parent of one’s parent sucking ova situation but sometimes looking at things at a basic low level can remind you of something you missed.

Of course if Tristan has a zeropain log for the sourcery error he could mail it to you (unless of course you have a modern machine with a recent OS revision to test under your controlled conditions.

Thanks Steve. I’ll have a look. I have an idea where that many issues may be coming from – Sourcery shifts around a huge amount of files when it starts up, or checks them to see if they need updating. That would be my first port of call, anyway.

Software & drivers for digital TV tuners. Most of this will probably be dependent on having a decent video/media stack, since digital TV tuners tend to just extract the raw MPEG TS stream from the signal and leave the rest up to the CPU/GPU. But you’d also want decent software for performing channel scans, DVR capabilities, etc.

I would be a much happier man. ;-)
I play around with a lot of aviable video stuff (RISC OS and Linux) on my Pandora, IGEPv5, Titanium, ARMX6…
In Linux I have working TV tuners (Pandora) and a detected but not working DVB-S(2) card on Titanium Linux (find not the time to compile the driver… any todo aviable in the net for Debian). The card is also detected in RISC OS with *PCIDevices(?).
MPlayer in Linux play all (DVD, Livestreams from WWW, DVB-Streams from a working device (the needed channel.conf for me(Berlin) is aviable in the www).
FFMPEG in Linux can capture streams, ffplay do this… playing.
RISC OS. MPlayer do the same… play DVDs, Livestreams … FFMPEG/FFPlay also (use the latest alpha from Christopher Martin) but a bit slower an the same maschine.
I can capture DVB-T(2) and DVB-S(2) transport streams via a settop box und use this via network or copy it to Harddisc. MPlayer, FFPlay ans !Kino play this streams if I set the filetype to mpeg but slow (the Pandora in Linux play it faster than the other machines in RISC OS). HD streams are very slow and not usable without recode and this takes a very long time.
If I clean the stream (ffmpeg with copy video/audio-stream without recode) makes any things better but not for HD-streams (needs round about 2GB for 10min).
The normally PAL-streams are usable.
For better use it needs a better video-player support before hardware driver for tv tuners are usable.

I’m not sure I understand ‘Sourcery brings the Pain like no other’?

@Richerd Windley: Yes the 1056k is how much it spits into the ZeroPain log during first initialization. I actually suspect that is what takes most of the time for first run. It’s the only thing that wrote to my ZeroPain log. Let me know where I can send it, and if you want it zipped, as some mail servers may not like it.

nm. I zipped it. Here’s a link to it on DropBox.
https://www.dropbox.com/s/wwgi4cl77nlx303/ZP_Sourcery%2Cddc?dl=0

Yes the 1056k is how much it spits into the ZeroPain log during first initialization.

That’s essentially the maximum size of the log file and if a program repeatedly triggers a zero page access error by looping through a bit of faulty code the log will fill with the repeated report – which looks to be the situation.

Again more of a vague request but support for file types set from magic numbers or even file extensions from external sources like downloads.

I was thinking “NetSurf already sets the filetype for downloads based on the MIME type” but then I realised that maybe you’d have downloaded lots of stuff via another OS and want to set the filetypes based on the extension or content. It would be quite easy to write a little app that sat on the iconbar and to which you could drag files or a whole directory, whereupon it would go through and set the filetypes. Of course, such a thing might already exist!

EXTn FS support module.

See IscaFS. It’s rather old and 26-bit only, so needs replacing. I used to use it on the Risc PC where we had ARMLinux installed. Actually, I mean where we have ARMLinux installed — just haven’t used it in ages.

An SSH server. With all the other available programs, it’d be easy enough to write and build code remotely. The inverse of what I do with Nettle and Sunfish currently.

I would like to have an SSH terminal that worked with up to date encryption. I can no longer log into Linux boxes from RISC OS. Perhaps I’m missing some updates to Nettle?

I hope (given all the talk of IDEs) above that people are aware of Alt-double-click in Zap, which opens the StrongHelp page relating to a SWI or a C library function. Very handy. Not as convenient as an auto-complete thing perhaps, but I find it invaluable.

@Tristan M. Thanks very much – I’ve downloaded it and will try and unpick what is happening.

I would like to have an SSH terminal that worked with up to date encryption. I can no longer log into Linux boxes from RISC OS. Perhaps I’m missing some updates to Nettle?

@Matthew Phillips: I don’t think it’s to do with Nettle. I mean it may be but one day I decided to try it again and it just worked. I don’t know where Nettle gets it’s ssh from. Ie whether it’s internal or provided elsewhere.
I use it along with nfs to do builds on my aarch64 “build server”. So I have access to the files via Sunfish and can build or whatever via Nettle. It works pretty well.

I’ve said it a few times before, but in my opinion full-system emulation is the best long-term solution for allowing users to continue to run their old software. With a decent JIT and some good integration with the host OS, the overall user experience shouldn’t be that bad. And the maintenance cost of keeping the emulator working with new host OS/hardware versions should be a lot less than the costs associated with maintaining a compatibility layer/user-space emulator like Aemulor/ADFFS.

Without a timer API, a means to swap more than just appspace during a task switch and the ability to switch to a specific task, a JIT based VM would be impossible without low level hackery that won’t be forward compatible or platform independent.

For example, for Wimp integration to work, the whole VM memory map needs mapping in when the Wimp returns from the Poll. I have looked at relocating the VM to a DA, but this would mean a substantial slow down in both host and VM performance as all memory access would have to be emulated, or translated into code to offset all memory accesses. That takes your instruction recode count from ~10% to over 50% and limits the advantages of using a JIT.

You’d want to include 0-8000 in the task switch, along with any memory the guest OS maps, its ROM image and any JIT requirements such as the virtual machine state, virtual L1/L2PT, codelet area etc. The VMM essentially needs a way to inform the host taskswitcher of additional pages to swap for the current task.

My goal would be to have a JIT that emulates all the memory accesses. Yes, it would be slower than a virtualisation system where the emulator is able to remap the hosts’ memory to get a direct 1:1 translation between guest address space and host address space, but it would be a lot more portable (and therefore future-proof) since there are fewer requirements/assumptions about the host system.

Fast emulation of memory access is tricky, so the JIT would have to do a lot more rewriting of code, but if the solutions were all obvious/easy then where would the fun be? :-)

My goal would be to have a JIT that emulates all the memory accesses.

Considering the work involved and hit to performance, I wouldn’t waste time going that route, stick with full CPU Emulation. The minute a JIT is added into the equation, things like MMU, VIDC and IOC timer emulation become a major headache, not to mention the complications of managing the JIT and CPU instruction caches.