90 MIPS ROS 3 emulation on Panda!

I was reading this thread, https://www.riscosopen.org/forum/forums/8/topics/2395
I think, it’s the good time to introduce you the latest version of Archiemu from Jan de Boer.

The evolution of the software is very fast. There are still a few bugs, and single tasking mode is not faster than Wimp mode (it should be). But it’s definitevely fast, accurate and (almost) stable.

The need for speed

I made some tests with a PandaBoard ES @ 1,5 GHz, with a 6-9 months old ROM and Archiemu from 14/01/2015 (probably not the lastest version). I use mode 32 (800×600×8), 16 MB of RAM and the emulator in a Wimp window. The worst conditions for emulation speed.

Here are the results. ARMSI : 92.19 MIPS.

ROMark
Test Benchmark
Processor – Looped instructions (cache) 21%
Memory – Multiple register transfer 774%
Rectangle Copy – Graphics acceleration test 311%
Icon Plotting – 16 colour sprite with mask 39%
Draw Path – Stroke narrow line 42%
Draw Fill – Plot filled shape 52%

So, it’s not as fast as a StrongARM, but it’s definitevely faster than an ARM 610, and probably faster than an ARM 710. With Archiemu, you can also create ready to run environments for your games and software, and launch them with a simple clic on an icon.

Archiemu is fast enough to compete with the first versions of the RISC PC. And will be probably 40-50% faster on OMAP5 boards (we could probably run it faster on a dedicated core, see my project of bounty :
https://www.riscosopen.org/forum/forums/8/topics/3079 )

Possible tweaks

Some evolutions could come from the community. First, a set of modules and tools to modernize RISC OS 3.11 (I will probably work on this). Hardware tweaks would be cool too.

Could RISC OS 3.11 support a MEMC that can manage lot of memory pages of big size, or more than 4 MEMC? The idea is of course to go up to 64 MB of memory with the same RISC OS ROM (or with a small patch dedicated to the current one).

Would it be possible to emulate a faster VIDC, that could use 1 MB of memory and not 512 KB? That’s necessary for 1920×1080×4 and 1360×768×8 modes.

Would it be possible to make a 26 bits version of ROS 5? If not, would it possible to dump the kernel from ROS 3.11 and make a new ROM with RISC OS 5 components inside?

Nota: My benchmarks was made on a basic configuration. With new and more modern modules, the OS will be probably be faster…

Last point. Should it be interesting to make a special version of the ROS3’s WIMP that would print windows on the host for better integration of old apps? Would need to redirect screen output to a specific ROS3 module.

I hope that peripherals will be added by the community, as Midi support, printers sharing or hotsfs. Then, it would be possible to use old desktop software for serious use, and not only games. And to forget (at least) our old Archimedes, and perhaps later The RISC PC.

How does it run on a Pi? You say it is “probably faster than an ARM 710”, but such hardware never ran RISC OS 3.11. For that, you pretty much need to beat an ARM3 (A5000) to be authentic and it looks like that is well within reach on a Panda. But, on a Pi?

First, a set of modules and tools to modernize RISC OS 3.11

There are a few. See if you can find “NewerLook”. Also Thomas Olsson’s Filer+ will leave you feeling like the RISC OS 5 Filer is kind of braindead in comparison.

NewerLook → ftp://arcade.demon.co.uk/data/080000/081650/081669

I can’t find a link to the older Filer+, but this describes what the RISC OS 3.7 FilerPro could do (and it was fairly similar in behaviour) → http://www.armpit.dk/files/filerpro/

Could RISC OS 3.11 support a MEMC that can manage lot of memory pages of big size,

No. You’d need to reprogram the memory handling logic. Does anybody have the sources to build a working version of 3.11?

or more than 4 MEMC?

I don’t think that is possible. The older ARM memory logic could only work with 64MiB in total and I think that was split up something like 16MiB (max) logical, 16MiB (max) physical, then the ROMs and the I/O and the screen and… I’m not sure how much space is available in the memory map; but you won’t have much to play with compared to modern systems.

The idea is of course to go up to 64 MB of memory with the same RISC OS ROM (or with a small patch dedicated to the current one).

And how would you implement that on a processor that can only address 64MiB? It can be done with some extra capabilities (the RiscPC did it like that to save going the 32 bit route) but an older Archimedes has no 32 bit mode, nor (at this time) can the OS be modified.

Would it be possible to make a 26 bits version of ROS 5?

Given that the RAM image would probably need more memory than most people have installed in their machines, I don’t think this idea would ever have taken off. ;-)
I wonder if RO5 is even capable of being built as a 26 bit version these days; never mind all the old VIDC1/MEMC legacy code is likely lost to time…

Last point. Should it be interesting to make a special version of the ROS3’s WIMP that would print windows on the host for better integration of old apps? Would need to redirect screen output to a specific ROS3 module.

Could be doable if you have emulator source to hack, where the emulator can fake the older style environment while passing a lot of the calls on to the host. Perhaps something not unlike coLinux → http://en.wikipedia.org/wiki/Cooperative_Linux

Some people are porting games to run on newer hardware, or providing an environment in which they can run; and there’s Aemulor for desktop applications of importance. However, really, if possible people ought to move forward. The older machines are fun for nostalgia, but clinging too long to the past won’t get us anywhere. We already have more than our fair share of relics and skeletons…

Do you have a link for ArchiEmu? A Google search pointed me to http://home-1.worldonline.nl/jandboer/ but that is giving me a 404.

David

Thanks for the update on Archiemu.

Where is it now hosted as the Home-1.worldonline.nl address I have is no longer valid.

Doug

How does it run on a Pi?

Probably between 15 and 20 Mips. So fast enough. I should make tests.

No. You’d need to reprogram the memory handling logic. Does anybody have the sources to build a working version of 3.11?

Not sure. RISC can manage different size of memory pages, and different total number of pages. See here: https://www.riscosopen.org/wiki/documentation/show/Archimedes%20Hardware

16MiB (max) logical, 16MiB (max) physical, then the ROMs and the I/O and the screen and… I’m not sure how much space is available in the memory map.

Then it’s probably not possible.

Given that the RAM image would probably need more memory than most people have installed in their machines, I don’t think this idea would ever have taken off. ;-)

One solution is to replace most of modules at start-up for newer ones. The other (especially for emulators) would be to be able to make our own ROM, with old kernel and new modules.

Could be doable if you have emulator source to hack, where the emulator can fake the older style environment while passing a lot of the calls on to the host.

There are even tools and a sort of framework to make the guest talking with the host.

The older machines are fun for nostalgia, but clinging too long to the past won’t get us anywhere.

True. That’s why I say: let’s have the perfect emulator, with perfect integration, and with – if possible – new features (better modes, etc.), for the thousand of old applications that will never be available under RISC OS 5 (or will never work with Aemulor or ADFFS). Then move on and forget the old computers.

An ‘XP mode’ for RISC OS :)

And if we can make a link with the retrocomputng market, it’s good too. ACMS (musiiiic) is new, cool, but only available for Archimedes. With a Midi support for Archiemu, it would be possible to use it from a Pi.

Do you have a link for ArchiEmu? A Google search pointed me to http://home-1.worldonline.nl/jandboer/ but that is giving me a 404.

Web hosting expired :) But I’m still in contact with the author, who makes updates almost every day.

Just send me an email (look at the end of this page: http://www.riscos.fr/english.html ), and I will send you the current beta version.

Memory map confirms that there is no place for more memory. But…

This page…
http://www.chiark.greenend.org.uk/~theom/riscos/techdocs.html

… gives a link to Jérôme Mathevet tool needed to make a ROM with new components. 4 MB max on real hardware. 12 MB on emulator. Enough room for a complete set of applications and modules. And so less memory used for modules updates. Seems to be read only, so no way to use this space as extra RAM…

For video memory, I don’t find confirmation, but there is no real limit, except the bandwidth of VIDC. So a virtual VIDC enhancer at 72 MHz, should make the job: to drive 1 MB resolutions.

The objective here is to keep the same resolution as the ROS 5 desktop, when in fullscreen mode. 1920×1080/32 for ROS5, 1920×1080/4 for ROS3.11.

… gives a link to Jérôme Mathevet tool needed to make a ROM with new components.

Ooh, is that the one with my really dodgy translation? I speak French a little better than I did back then…

For video memory, I don’t find confirmation, but there is no real limit, except the bandwidth of VIDC.

I wonder if there are hardware limits/assumptions?

Details / datasheets of the old chips → http://www.home.marutan.net/arcemdocs/

I wonder if there are hardware limits/assumptions?

It should not. But to get 1MB modes you will need a VIDC at 72 MHz (possible on emulator). Jan confirms me today that you can have 1920×1080×2bpp and 960×540×4bpp with the current VIDC enhancer. Not bad for fullscreen use with a full hd screen. The same with 4bpp and 8bpp would be really perfect. And 1024×768×8bpp for windowed use too :)

For memory, there is 6 MB of ROM space free, probably not usable as RAM (but who knows? can we alter the memory map to set this part as RW? 20MB would be cool). Anyway, it open doors for a new 4MB RISC OS ROM, with many new modules. Or even a 8 MB one.

I hope to pack new Sharedclib, new modules and new toolbox inside a RISC OS ROM. For legal issues, I cannot distribute it. But I could distribute a non commercial pack with ROOL components and Jérôme tools. Then you put your ROM in the right directory and let the tool making a new ROM for you :)

Any comment from specialists on memory map? If possible, a patch to change from RO to RW part of the ROM space would be fantastic.

but who knows? can we alter the memory map to set this part as RW?

Not possible, as RISC OS read them at startup (to check of ROM is present)

But there is something that is possible, and that I suggested to Jan: ST506 disc in host RAM… to be used instead of traditional RamDisc.

Remember that the more you try and push the Archimedes beyond its limits, the more compatibility issues you’ll run into with trying to run old software. In my eye it would be better to stick with a faithful emulation of the hardware rather than try and find ways to hack in more memory, higher resolution screen modes, etc.

The one thing that you might be able to do without breaking too much would be to change the Wimp so that it is able to provide better integration with the host OS. E.g. redirect screen output to a sprite which is held in some fake RAM in a spare part of the address space (spare ROM space?), and have the emulator display that as the screen. Or as you suggested yourself, make the windows appear as individual windows on the host desktop (something that could be useful for other purposes as well – e.g. remote desktop between ordinary RISC OS machines).

I hope to pack new Sharedclib, new modules and new toolbox inside a RISC OS ROM. For legal issues, I cannot distribute it. But I could distribute a non commercial pack with ROOL components and Jérôme tools. Then you put your ROM in the right directory and let the tool making a new ROM for you :)

One problem you’ll run into is that all the C ROM modules are statically linked. If you change the address of a C module then it will break. They’re also statically linked to the SCL, so if you change that then the module will break as well.

The static linking also means that if you want to supply new versions which the user then runs a tool on to produce a new ROM image you either need to (a) provide pre-linked versions of the C modules, with the intent of placing them at a fixed location in the ROM image, or (b) provide the modules in object form and make the ROM linker perform the static linking itself (e.g. using Norcroft’s linker)

Remember that the more you try and push the Archimedes beyond its limits, the more compatibility issues you’ll run into with trying to run old software. In my eye it would be better to stick with a faithful emulation of the hardware rather than try and find ways to hack in more memory, higher resolution screen modes, etc.

Yes, and no. It’s not always true for Wimp applications. And Archiemu also sticks with a faithful emulation of the hardware :) Good point with emulators is that you can simulate different type of solutions. But, anyway, nothing seems to be possible in this area… except better interop tools. A new Wimp is probably too much job (as we have ADFFS and Aemulor). Some 1920×1080 or 960×1040 mode could be added for 16/9 screens. And hard disc could be used as replacement for Ram disc, with a small tweak. Better than nothing.

One problem you’ll run into is that all the C ROM modules are statically linked. If you change the address of a C module then it will break. They’re also statically linked to the SCL, so if you change that then the module will break as well.

True. Jérôme solved the problem by putting SCL always at the same place in the new ROM. No problem with the other modules (Jérôme’s tools adapt parameters to their new location inside ROM), except the toolbox ones, that were compressed (but are not any more). So, it should work (it did with older versions of SCL).

Basically it should be possible to integrate, new SCL, new modules, new toolbox, new Paint, Draw, Edit, new iconset, and probably a few other things (for example RaFS in ROM). A few tweaks could be added (better font at startup, etc.), but will need a specific module.

David – As this emulator doesn’t seem to have a public home, you’re more than welcome to attach it to a thread on the JASPP site.

It will, very soon.

The comments on integrating an emulation of RO3 with a host running RO5 put me in mind of WinRisc from (IIRC) “Armed Forces” (or was it the ARM Club?) – putting Win3 applications running on the PCCard on screen as RO windows, i.e. without the Windows window as a “container” (and, again IIRC, you lost “full screen” DOS/Win mode).

put me in mind of WinRisc from (IIRC) “Armed Forces” (or was it the ARM Club?)

Armed forces, mentioned in the other thread

I guess users of real 3.1 systems would perhaps appreciate a new ROM set with the stuff that is typically soft loaded and hence eats into your 4MB RAM. But is anyone really going to bother? As Jeffrey suggests, stuff like this could screw compatibility.

I seem to recall the 480KB screen limit being an issue, even with CC getting help from Acorn!

But is anyone really going to bother? As Jeffrey suggests, stuff like this could screw compatibility.

For some games, yes. for Wimp applications it should not. And don’t forget: it’s emulation. You can have several machines and ROMS. Jan provide even a way to use one VM for one application (with its own icon).

There are a few. See if you can find “NewerLook”.

NewerLook was by Doggysoft and excellently their web site is still online. http://www.doggysoft.co.uk/prog3.html#nrl

(as an aside, could we maybe make the NewerLook sprites into a RO5 theme?)

as an aside, could we maybe make the NewerLook sprites into a RO5 theme?

Yes. Look in:
ThemeDefs.Themes

copy Raspberry to NewerLook change the content of the sprite files in your Themes.NewerLook copy by replacing them with the newerlook equivalents, tweak to taste.

Select NewerLook theme in the configuration options.

Any screenshots…
Desktop, IronLord, IronLord, MegaDemo, SoC, TechWriter, Wolf3D, Elite, Zool, James Pond

German system… he he ;)

Saved from my A5000. Real German ROMs at that time.