When I was writing games for the Archimedes, I was using ARM-assembly routines to write pixels directly to the double-buffered screen memory. So I think a full blown emulator would be needed, rather than just the same OS. Unless ARM-6 can still execute ARM-1 assembly, and it still has addressable screen memory?

If you used the OS-provided SWIs to get the base address of the screen memory, OS_ReadVduVariables for 148 IIRC, and similarly use SWIs to wait for the VSync and switch buffers then I'd have thought it works just fine.

The Archimedes had ARM 2 BTW, ARM 1 was just in the Tube co-processor for the BBC B. Some instructions are different with the RasPi, mainly to do with the PC register no longer having bits spare for Negative, Carry, etc. http://www.heyrick.co.uk/assembler/32bit.html has more details. There are external programs that detect and trap old 26-bit instructions when on 32-bit RO and allow old games to run but I know little about them; my last Acorn ARM machine was their R140 running RISC iX (a BSD port).

Depending on what the MMU would allow (I know so very little about low level ARM) you could probably map an area of ram to the same address as the old screen memory and make a compatibility layer. This still assumes that ARM-1 is binary compatible otherwise. So you might be able to get some kind of help from the hardware for at least video, but I have no idea about sound and input. I believe that this kind of remapping should be doable in linux so I'd assume that it could be made into a layer in RISC OS also.

ARMv5 dropped support for the 26-bit-addressing mode back-compatibility, so v5 and above definitely can't run ARM1/ARM2 binaries. (Even in v4 the back-compat support was optional.)

RISC OS and most applications are now 32-bit OK.