RISC OS ON ARM7TDMI

Okay this is in the “insanity” category.

I noted a few weeks ago that someone had made a module loader for the OS installed on the ARM7TDMI coprocessor for the BBC Micro. (The number of users of this system is very small)

This got me thinking… How much of RISC OS 5 could be implemented without the need to do anything that was IOMD, VIDC (or whatever dependent)?

Clearly a WIMP for the BBC Micro would be limited to Mode 0 resolution in Monochrome, but not impossible.

I Somehow doubt adding a co-pro version of Risc OS Open is an immediate priority though… :)

How much of RISC OS 5 could be implemented without the need to do anything that was IOMD

You’d need timers and such. Otherwise, it could be possible to have a version of RISC OS not unlike Pico working via the Tube interface. Not sure how graphics work via Tube. But, I think it’s a really niche thing (which is why nobody has done it).

Clearly a WIMP for the BBC Micro would be limited to Mode 0 resolution in Monochrome, but not impossible.

Not impossible, just quite horrible.
There was a Desktop demo on the Master Compact Welcome Disc.

How much of RISC OS 5 could be implemented without the need to do anything that was IOMD

You’d need timers and such

Timers and an MMU is all that’s really needed. Sprow’s page reveals the ARM7TDMI is in an ML67Q5003 SoC, which certainly has timers, but doesn’t look like it has an MMU. So unless you feel like doing a lot of hacking, it’s probably best to stick with Sprow’s kernel.

Or you could do what all the cool kids are doing these days and use a Raspberry Pi as the coprocessor (which could conceivably have the tube interface software ported to run on RISC OS?): https://stardot.org.uk/forums/viewtopic.php?f=3&t=11325

The module handler for the Kernel on the ARM7TDMI copro – was here – http://mdfs.net/User/JGH/Develop/ARMCoPro/Modules/

The ARM CoPro as such runs a version of ARM BASIC V, presumably the version in RISC OS open could be adpated, assuming it only use OS SWI’s that are supported.

The ARM is 32bit, meaning the 26bit software from the original Evaluation system won’t run. A 32bit version of the C compiler might…

@Rick murray: My understanding was that “graphics” as such were handled either as OSWRCH (for standard VDU operations), or as a block transfer between the host and IO/processor (not sure how this is implemented on the ARM co-pro)

The supported calls are detailed in this document- http://www.sprow.co.uk/bbc/hardware/armcopro/armtubeoscalls.pdf