custom boot and custom gui?

Hi all, i`m thinking of installing RiscOS on my raspberry pi, before i go for it, i`m wondering if i`ll be able to do what i want..

namely, boot into a non gui os, and launch software.. ie, boot straight into games emulators.

also, how straightforward is programming custom menus etc to run software, basically creating a simple ui to replace the desktop environment..

my thinking is i` like to create a system that boots to my own menu (a list of software available on teh riscOS system) and the menu items will launch the chosen software.

is this a realistic prospect? what kind of programming skills would be involved etc? i have a little basic and scripting knowledge, but never dug into the likes of C.

cheers,

Mark

Just create the menu app say called !menu then you can get it to run on start up.

But what would you gain over just starting RISC OS, and automatically opening a (RISC OS filer) window with a list of software, which when double-clicked on would launch the chosen software? That could be done so easily in a few minutes … your method would need some serious programming. RISC OS is a GUI OS. To run it without the GUI seems rather …. silly.

Or, as Kevin suggests, write a (normal RISC OS GUI) app which is started automatically and displays a list of choices which result in other programs being run.

Do you really have to replace the desktop environment, or just hide it?

Im thinking similar to the raspBMC version of XBMC, as far as i understand it raspBMC runs on debian, but the gui isnt there, ie, it runs on the terminal version. i wasnt sure of you could get riscOS to boot to a terminal/shell and than launch the riscOS based menu program, or not.. i was just thinking boot speed and cpu/memory usage savings on teh pi for running emulators

but something that just runs on startup is fine, as long as it essentially renders the desktop invisible.

cheers,

Mark

What you want to do certainly is possible, but I question the amount of effort you desire to plough into it.

Reading between the lines, you haven’t actually used RISC OS yet, and have only a very shaky grasp of what it’s like, so here are a few pertinent facts:

RISC OS is not Linux. It is not even distantly related to Linux. It is a completely separate OS in its own right, which means that everything, bar nothing, works differently.

The complete bootup time of a newly-installed RISC OS image – from power on to the desktop – is approximately six seconds. This is achieved principally by disabling DHCP requests and all network access until you configure it differently. However, if all you want to do is run an emulator, you may wish to leave the network turned off anyway.

RISC OS itself is literally only a few megabytes in size, and that includes the desktop and a selection of basic built-in applications. You will never, ever, have to worry about running out of memory, even on a Pi. RISC OS hasn’t expanded in size (or the amount of memory it claims while running) significantly since PCs fitted with 4MB of RAM were normal.

RISC OS is not Linux. The amount of CPU speed it uses is barely big enough to measure. Basically, quit fretting about CPU and memory usage and bootup time. Just as long as you don’t attempt to run a completely unsuitable bloated server OS on it, the Pi is actually quite nippy and high-specced.

RISC OS is not thread-safe and does not have pre-emptive multitasking. The upshot, from your perspective, is that it is not possible to do anything with the computer until the boot sequence completes, which means that worries about the desktop flashing up briefly before your emulator launches are meaningless in practice.

Beware of BootFX. This rather pointless piece of eye candy frequently bites people attempting to modify their boot sequences. If you do go the disabling-the-desktop route, you’ll need to unplug the BootFX module.

Once more for luck: RISC. OS. Is. Not. Linux.

ha, thanks, i know its not linux.. i didnt know if the gui ran on top of a non gui OS, like windows used to be on top of dos, and whatever desktop runs on linux etc.. i wasnt suggesting it was the same.. i just wondered about how it worked, hence the speculative question.

that said your list of info is very helpful, thanks indeed.

Technically, it originated in the 1980s as a Wimp system bolted onto a straight port of BBC MOS to ARM, and hasn’t really progressed a whole lot since. If you enter the right runes listed in the thread I linked to (made a bit more complicated since the introduction of BootFX), you end up with something which looks and behaves almost exactly like a Beeb when you switch it on.

There used to be a Teletext (MODE 7) emulator as well, but I think that was never reimplemented when the video driver had to be rewritten for the port to modern ARM systems.

namely, boot into a non gui os, and launch software.. ie, boot straight into games emulators.

Which emulators? Some of them launch from the Desktop.

If you really want a non-GUI version of RISC OS, you simply patch something into !Boot. Where and how much patching depends upon what resources you will require and how much you want to fiddle with the start-up.

However, as Martin says, boot time in incredibly fast. I’ve not had a six second boot yet (maybe his SD cards are better than mine?) but I have had it boot from power up to functional desktop (not preloading like Windows does it, but completely done) in sixteen seconds.
Don’t just take my word for it: http://www.youtube.com/watch?v=idN0Cph1hh8

Is it really so bad to use the GUI?

also, how straightforward is programming custom menus etc to run software, basically creating a simple ui to replace the desktop environment..

!!! Twice in one week? Wow.

Frankly, that is not a question that can be easily answered. Two questions must be asked. The first one:

• Will the UI be a text-based one? Think of WordPerfect 5.1 or TurboC if you’re old enough. This should not take too much time to write. I might be able to cobble together one in a weekend, but I’d say a week or two for something half-decent.

• Will the UI be a hybrid text/graphics one? Think of DOSShell, if you’re old enough. This shouldn’t take that much longer than the text-based one, as it is largely the same but with more gloss.

• Will the UI be graphical? Think of GEM, if you’re old enough. This will take longer; how much longer depends upon whether your UI is a fixed purpose system or if you will expect it to run apps. If you want it to run apps, it will require extensive knowledge of RISC OS to pull that off, and you’re better off using the UI supplied!

my thinking is i` like to create a system that boots to my own menu (a list of software available on teh riscOS system) and the menu items will launch the chosen software.

Easily done. Hell, if you just want a basic “pretty menu”, that’s hardly a UI. That’s an evening’s work. Even using FontManager to make it look nice.
The caveat, however, is what software you intend to run. Multitasking programs don’t take too well to being launched outside of when the Wimp environment is active. You may find peculiar quirks like the system complaining about the amount of free memory being incorrect, and so on.

is this a realistic prospect?

This leads me to my second question: How skilled are you? Writing a menu is dead easy. Writing an actual UI is less so. Not in terms of what languages you know, but little things like “how do you handle something overlaying something else?” and the best algorithm for implementing such a thing.

what kind of programming skills would be involved etc? i have a little basic and scripting knowledge, but never dug into the likes of C.

Depends on what you mean by UI. If you want to boot to a plain ‘80s style menu, you can have it done in under a week using the built-in BASIC. Those of us who are familiar with RISC OS and BASIC can do it in an evening. I’m making some allowances for you not knowing the platform.

If you want a rudimentary fixed-purpose UI using text and/or hybrid, you can do that in BASIC; but you’d be better off doing it in C (for a compiled language will always run a LOT faster than an interpreted one). If you want a graphical UI, you’re looking at C (although kudos to RISC OS, you could probably even pull THAT off in BASIC and make it look good on a Pi).

If you want a UI capable of loading other programs into itself… don’t. Use the Desktop, that’s what it is there for.

i just wondered about how it worked, hence the speculative question.

Inside RISC OS is a kernel. It is not a module, it lies deeper than all of that. The kernel looks after the core hardware – CPU, memory allocation, interrupt and system call dispatch, the usual rubbish. When the kernel is ready to roll, it sets up a module chain and basically works its way through the ROM image looking for modules to load. These modules are, on the surface, a lot like Windows DLLs – but they are so much more than that. They are extensibility of the operating system itself. You don’t load “a RISC OS filing system”, you load “the RISC OS filing system”. You don’t load “a font manager”, you load “the Font Manager”.
That isn’t to say that you can’t replace a lot of this at boot time by newer or alternative modules. Additionally you could make custom ROMs containing only what is required and leave out everything else. It is so simple, yet so powerful, you wonder why more operating systems aren’t designed like this.

RISC OS does not understand the generic process model. You cannot spawn child threads, no matter how hard you poke a fork() into RISC OS. Co-operating processes is something taken care of by the Wimp (which is in itself a number of modules, but primarily “WindowManager”). It does not run on top of the kernel so much as expands the capabilities of what “RISC OS” is. When we speak of “RISC OS”, we are referring to the system as a whole, not the kernel. RISC OS boots as a single-tasking command line, and it becomes a multitasking UI.

Another nice thing about RISC OS on the Pi… You can unplug the SD Card after it has booted, there are a few caveats doing that such as using RAM as a !Scrap. But try doing that on linux, wait..no don’t ;-)
As RISC OS doesn’t have multipath I/O, fiber channel, infiniband and a whole host of other “really useful” desktop features to worry about it is considerably leaner.
A complete loser for server stuff, a complete winner for desktop IMHO.

Oh and even better, there’s no start menu

this is all fantastic, i admit, i didnt fully understand all of it but endeavour to, im now sold on persuing my aim on RiscOS rather than linux.

I suspect what i`m trying to do is similar to what i used to do in AMOS back in the day (bearing in mind ive not programmed anything in a long time) so i suspect possibly BASIC? I`d want to use fonts and some bitmaps in the menus.

maybe my first attempt will be a text based menu though.

based on this info i realise it will be something that runs over the top of the desktop, the idea being that it would launch whatever software from the menu, and then when the emulator/software is closed, drop back to my menu screen raher than the riscOS desktop.

ive installed RPCemu in order to start familiarising myself. :)

cheers again,

Mark

IF you need the services of the desktop, it isn’t quite an in-and-out thing; so your best bet is probably to write a desktop application that opens a window full-screen and displays the menu that way, pushing itself to the background while the desired program runs…

Then you might see how nice the desktop is, and make your menu a little bit smaller than full screen. ;-)

I`m sure its lovely, i just need something my housemates will be able to use without tuition and tamper resistant (its for the living room media centre). i always had a bit of Arcimedes lust when i was younger, and lament the passing of tiny OS`es like workbench, though i`m sure RiscOS is far superior to workbench 3.1.

I suspected that the words “tamper resistant” might figure in your logic somewhere. In that case, since RISC OS has basically no security at all, you’d probably be better off running single-tasking.

The snag is that there are a few hoops to jump through to be able to launch another program from within a single-tasking program and safely return afterwards, but the good news is that it is possible, and disabling the desktop isn’t necessary. Co-operative multitasking means you only hand back control to the desktop when you choose to, so all you have to do to make your program single-task is to choose not to. The only thing to make sure of is that all of the programs available from your menu are also single-tasking – if any of them multitask, there’s nothing you can do to stop it and all your efforts at hiding away the desktop will be in vain.

There’s no such thing as “tamper-proof” under RISC OS… that’s sort of the point. Apart from anything else, whatever you set up the machine to do when you switch it on can be disabled by holding SHIFT and the numeric keypad *, and then one can type *Desktop and hey presto.

I should also remind old RISC OS hands that calling Wimp_Initialise the really old way may well result in exactly what Mark wants… more or less.

I’d write the front end as a Wimp task, enumerate the current tasks and kill them all off, then run secure in the knowledge that the only other tasks that will run will be the ones you start (and it’s then trivial to start them and return to your front end afterwards).

Wouldn’t it be possible to borrow some ideas from the Pace set top boxes? While they ran a cut down version of RISC OS it took quite a bit of digging around to root them. Given their purpose they were designed to be as “tamper proof” as possible.

Over to you Rick ;-)

In that case, since RISC OS has basically no security at all, you’d probably be better off running single-tasking.

…or accepting that there isn’t that much that can be terminally broken under RISC OS. Frankly, the best thing to do is set up a full-screen Wimp application as your menu, and get all the stuff installed the way you like it. Don’t pay too much attention to getting rid of the desktop. Just don’t make it overly obvious (although you may need iconbar etc if you have software that runs within the desktop, like the Beeb emulator).

Then clone the SD card. It’s only 2GB, so you can either copy it to a similar card so you have two, or dump it into a .img file on a larger capacity device.

Then let your family at it.

If things get “damaged”, there are three ways to approach the problem:

1. You broke it, you fix it.
2. You broke it, you do without.
3. Say nothing, rebuild the SD card from the clone image, will take maybe five minutes with WinDiskImager…

Frankly, I would go for option three. Your friends/family may peek around RISC OS if they are so inclined, you aren’t jumping through hoops to hide RISC OS, it’ll be easier to implement, and once you have a “set up as you like it” SD card, it will be pretty much unkillable. If it gets buggered up, temporary data will be lost but you can get going from the saved image in about as long as it takes an average XP box to boot up… Not bad, huh?

While they ran a cut down version of RISC OS it took quite a bit of digging around to root them. Given their purpose they were designed to be as “tamper proof” as possible.
Over to you Rick ;-)

Over to me… Well, I never thought I’d see “RISC OS” and “root” in a sentence that wasn’t talking about “$”!
Tamper proof? Yes, the GUI was extremely rudimentary/dumbed down version of the Desktop in as much as it was the browser more or less running as a single Wimp task by itself. How to get a working desktop on the Bush internet box is discussed at http://www.heyrick.co.uk/assembler/resources/stbgadt.html

“Rooting” it, however, was basically “power it up while holding down Shift”. This would be pretty obvious to anybody who had prior experience with anything Acorn-related. Shift has always, right from the Beeb (maybe the Atom? anyone?) either enabled or disabled auto-booting. Perhaps it toggled the alternative of the configured option. Either way, “hold Shift”. Dead easy. ;-)

But, then, a system where to core OS came in ROMs didn’t need to worry about the user randomly deleting core modules. Sure, you could unplug them, but that can be fixed easily enough…..

I should also remind old RISC OS hands that calling Wimp_Initialise the really old way may well result in exactly what Mark wants… more or less.

I’m not worried about what Mark wants, I’m worried about what Mark wants to run. Where do we go if his menu is going to call a program that normally puts an icon on the icon bar and does nothing else.

Remember also – RISC OS doesn’t have that bloody annoying Windowsy habit of being unable to work unless there’s some sort of window open on the screen.
I mean, can you run Notepad and not have any windows open? RISC OS just doesn’t work that way – so the limits to what Mark can do may derive mostly from what he wants to actually run…

Remember also – RISC OS doesn’t have that bloody annoying Windowsy habit of being unable to work unless there’s some sort of window open on the screen.
I mean, can you run Notepad and not have any windows open?

I never thought I’d see “RISC OS” and “root” in a sentence that wasn’t talking about “$”!

Perhaps “Jailbreak” would’ve been a better way to describe it but Mapple might sue me for that ;-)
Anyways the Bush thingy sounds like what the OP has in mind in that it hides most of the OS from the user. Quoting from your website:

1.The unit is unplugged, right?
2.Open the keypad and hold down the big Shift, on the left. Keep it held down.
3.Plug in the unit, making sure it can detect the Shift keypress (ie, point the remote at the box).
4.Keep on holding shift for a few seconds, then let go.
5.Close the keypad, and press the yellow Internet button to enable the display.
6.Open the keypad and press Enter a few times. You should see a ‘something not found’ error. On my TV and the monitor, the ‘something’ part was off the top left of the screen. Not that it matters, we’re in!
7.Hold Ctrl and tap V, release Ctrl. Hold Ctrl and tap L, release Ctrl. We are now in MODE 12, which is much easier to work with on a 14 inch television / monitor.
8.Type ‘basic’ and press Enter.

Quite a few steps to “accidently” drop into command line.

Hey all, this is the quickest response forum ive ever seen!! love it.

Ok, so i used the term “resistant” over “proof” for a reason ;) i dont need it to be tamper proof, and dont expect it to be, just something that will reliably keep people out of the desktop, also, there is no mouse attached to the system, which may make things interesting later.. i have no idea how any of these emulators run so it might scupper me there, may have to have a mouse after all.

my menu, ive decided can be as simple as an old 8 bit one, press 1 for C64, 2 for spectrum etc, really basic. but i have no idea whre to start with teh technicalities of launching programs etc, can this be done in basic? or do i have to learn assembler? .. any good tutorials?

cheers,

Mark

but i have no idea whre to start with teh technicalities of launching programs etc, can this be done in basic?

In standard, BBC-style BASIC, no, it can’t. It can’t be done in assembler either. The fundamental problem is that the RISC OS desktop does some clever things with memory mapping which allow every running application to believe it is loaded from a base logical address of &8000. But if your program isn’t running in the desktop, then it can’t do that. The end result is that, when your BASIC menu running at &8000 launches an emulator also running at &8000, the emulator stomps all over the memory that your menu was using, and completely precludes returning to the menu after you quit the emulator.

Now, as I said, thanks to RISC OS’s cooperative nature, it is possible to write a program which runs within the desktop environment – and is therefore capable of launching other programs – while still technically being single-tasking and refusing access to the rest of the desktop. But the problem with this – apart from being slightly trickier than vanilla BASIC – is that you’re not responsible for anything that any of the programs you launch do. Your concept will only work if every single one of the options available on your menu is exactly as single-tasking as your own program, otherwise there’s no way to avoid giving users access to the desktop at all.

Before anyone can give you useful advice, we need a comprehensive list of every program you want to run. And if any of them run in a window, install icons on the icon bar or do anything less than take over the whole computer, you can’t use them.

Your concept will only work if every single one of the options available on your menu is exactly as single-tasking as your own program, otherwise there’s no way to avoid giving users access to the desktop at all.

To put what Martin said into an analogy with a different platform…

…you appear to maybe want to run a Windows application from DOS without having Windows active.

As Martin says, we will need to know exactly what programs you want to launch.

Quoting from your website:

…long list…

Quite a few steps to “accidently” drop into command line.

I am guilty of over-describing so there is no ambiguity for things that seem obvious to me may not be obvious to others. And, no, you don’t “accidentally” drop into the command line any more than you accidentally jailbreak a phone. What I’m saying is it is not difficult, it doesn’t require a special exploit or hack. You just do what you would do to any other RISC OS machine (only complicated slightly by the different style of keyboard and the need to press a button to turn on the display output).

This does not mean that the process is such a lengthy thing.

To turn on a regular RISC OS computer in the same way:

1. Ensure everything is correctly connected.
2. Turn on the monitor/display device.
3. On your keyboard, hold down the Shift key (either one). Keep it held down.
4. Turn on the computer – on Beagles/RPis/etc this means plug in the power lead.
5. You may see colour bars or some sort of fancy colourful effect. This is the system initialising itself. Ignore this, keep on holding Shift.
6. Some stuff may appear on the screen that looks like a complicated list of things. Ignore it, keep on holding Shift.
7. After a short while, you ought to see “RISC OS” and some other stuff (processor type, memory, blah blah) followed by a flashing cursor. You can now let go of the Shift key.
8. Type BASIC and press ENTER.
9. If you are using a non-HD display, or if the text is too tiny, type MODE28 and press ENTER so you can see stuff.

See? It’s just as long to describe the process for a normal system. ;-)

I can’t test this unfortunately for a little screenshot – my keyboard is extremely quirky so the Ctrl and Shift keys work when they feel like it. Some day I’ll get a bod-standard generic UK layout keyboard off eBay…