Raspberry Pi compatibility

General development discussion not covered by a specific forum
Post Reply
Vanfanel
Posts: 373
Joined: Mon Sep 16, 2013 12:01 am

Raspberry Pi compatibility

Post by Vanfanel » Mon Sep 16, 2013 12:12 am

Hi there,

In the first place, I'd like to thank Jon Abbott and everyone nvolved for your work on this initiative: retro-gaming is the best way to attract new users of my own age to Risc OS for me, as I can show them what great games the system has, and it's sad I couldn't show them on the Rpi, natively without a full system emulation involved.
So, for me, running all these classics on the Pi (and Pandaboard) would be a dream come true!

ok. Now, how compatible is this supposed to be with the Raspberry Pi?
In the acornarcade thread, I can read lists of games running "up to Risc OS 3.x" or "up to Risc OS 4.x", but then at the bottom of the page I read "To get games that require VIDC1 translation working on RO5.x IOMD, you'll need to start them from the desktop via an obey script...", and I understand IOMD and the Pi are, more or less, the same if I leave the CPU settings in default mode.
I can even read, on a previous post, "Attached is a beta of just the ADFFS module for Pi/OMAP users...". So it seems ADFFS is intended for use on the Pi as it's now!
I'm very confused. Should I be able to run some ADF-imaged games on the Pi right here, right now?
Wich are supposed to be compatible?
What about OMAP (Panda & Beable) Risc OS systems?

thanks!

JonAbbott
Posts: 1737
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Raspberry Pi compatibility

Post by JonAbbott » Mon Sep 16, 2013 6:21 am

In short, ADFFS won't get game running on a Pi, OMAP or X-Scale processor if they don't already run. Not yet at any rate. All ADFFS can provide on one of these machines is emulation of the 1772 floppy controller.

There's a thread on The Icon Bar, where I've listed Pi compatibility - the working list is currently 11 games.

At the minute full system emulation would be required on the Pi as we've yet to implement fixes for self-modifying code and non-32bit code and need to hypervise the video and aspects of the OS in some cases. You could however use ADFFS on the Pi, under ArcEM to mount/run floppy based games.

RO5.x IOMD refers to the Risc PC build of RO5, which has an IOMD chipset. This latest build of ADFFS contains a VIDC1 (Archimedes video chip) to VIDC20 (Risc PC video chip) converter, so more game will run on it, but again self-modifying code and 32-bit incompatibilities will cause most to fail.

We're about to start work on the compatibility layers to get games running natively on the Pi. Likewise I'm going to start releasing some games we have rights too on here very soon, as the official website isn't ready. If nothing else, you can use ArcEm to play them on the Pi.

Vanfanel
Posts: 373
Joined: Mon Sep 16, 2013 12:01 am

Re: Raspberry Pi compatibility

Post by Vanfanel » Tue Sep 17, 2013 9:10 am

I'll have to wait more, then. Thanks, Jon!
I want to run them natively on the Pi, same as you want :)
ArcEm is NOT an option for me.

regin
Posts: 9
Joined: Wed Oct 30, 2013 10:00 am

Re: Raspberry Pi compatibility

Post by regin » Wed Oct 30, 2013 10:09 am

Hi,

I've found myself at this forum after lots of Googling and am very happy to be here!

To echo earlier posts, thank you to all involved in this project, setting up the site and everything achieved so far.

I'm very excited about the 26-bit games compatibility project you're about to embark on and will be back regularly to see how you're getting on.

Thank you for making my day!

User avatar
DavidS
Posts: 7
Joined: Tue Nov 12, 2013 4:30 pm

Re: Raspberry Pi compatibility

Post by DavidS » Tue Nov 12, 2013 4:43 pm

Hello I am very interested in getting the emulation working starting from a hack that I had thrown togather in order to run some 26Bit software i am currently rewriting this to work with more software and be a bit more effecient.

Also looking into methods of simulating the old HW on the newer boards. Mainly looking at the VIDC at the moment though will look a bit further as more is working.

Thankfully there are not many SWIs that require a wrapper to provide compatability, though I am sure that more will pop up as more software is tested. There is good documentation on what opcodes, and combinations fail, though not so much on what SWIs fail for one reason or another, so if someone has more information on this it would be quite helpfull. Also I would like a recomendation on 4 games that could be used for reasonable testing of the patch using VIDC1/1a/2/20 output and ARMv2/V3 CPU, as not much else will be simulated for some time to come.

JonAbbott
Posts: 1737
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Re: Raspberry Pi compatibility

Post by JonAbbott » Tue Nov 12, 2013 7:29 pm

DavidS wrote:Also I would like a recomendation on 4 games that could be used for reasonable testing of the patch using VIDC1/1a/2/20 output and ARMv2/V3 CPU, as not much else will be simulated for some time to come.
Off the top of my head:

1. Zarch - has self modifying code although is 32bit compatible otherwise, writes directly to the RISCOS 3.1 screen memory and doesn't touch VIDC registers
2. Pacmania - no self modifying code, writes to the current screen memory and uses a 4-bit mode. Doesn't alter VIDC parameters
3. Elite - no self modifying code, 32bit incompatible, doesn't touch VIDC parameters
4. James Pond - the music module has already been shimmed in ADFFS, 32bit incompatible, writes directly to the RO3.1 screen memory and modifies VIDC1 parameters. This is one of the worst case scenarios.

User avatar
DavidS
Posts: 7
Joined: Tue Nov 12, 2013 4:30 pm

Re: Raspberry Pi compatibility

Post by DavidS » Tue Nov 12, 2013 7:34 pm

JonAbbott wrote: Off the top of my head:

1. Zarch - has self modifying code, writes directly to the RISCOS 3.1 screen memory and doesn't touch VIDC registers
2. Pacmania - no self modifying code, writes to the current screen memory and uses a 4-bit mode. Doesn't alter VIDC parameters
3. Elite - no self modifying code, 32bit incompatible, doesn't touch VIDC parameters
4. James Pond - the music module has already been shimmed in ADFFS, 32bit incompatible, writes directly to the RO3.1 screen memory and modifies VIDC1 parameters. This is one of the worst case scenarios.
Ok I am off to track these down (wish me luck). By the sounds of it these will make for a rather complete test. Back when I played Zarch I did not realize that it was that badly behaved (I no longer have a copy).

Post Reply