Discuss ADFFS development and download test releases
If you look at the game testing status page, you'll see it's now working on StrongARM, so isn't far off working on the Pi*.tlsa1 wrote:Would much additional work be required to run Cannon Fodder on the Pi?
I spent most of Thu/Fri debugging it to see what the problem was, from that I hypervised parts of the sound system to get it covered by the JIT, which got it further. I'll resume debugging on Monday.
* Games running on StrongARM are handled identically to the Pi, if they subsequently fail on the Pi, it's either down to a change in the OS which needs hypervising, or some 26bit code that hasn't been through the JIT. The general rule of thumb is that if it's running on StrongARM, there's probably not a lot of work involved to get it running on the Pi.
Cool, thanks for the update!JonAbbott wrote:I spent most of Thu/Fri debugging it to see what the problem was, from that I hypervised parts of the sound system to get it covered by the JIT, which got it further. I'll resume debugging on Monday.
Correct. A 26bit Module is any Module that doesn't have the 32bit flag set in its header.richw wrote:Out of interest Jon, what do you mean by '26 bit module support'? Some sort of way for legacy modules to run, as presumably many games contain modules for compression/sound/joystick etc.?
The initial problem is that the service for patching Modules which was added by Acorn to patch them for StrongARM, has changed function on RO5 (it's called after the module has been confirmed to be 32bit compliant). As a consequence, Modules are somewhat tricky to patch at runtime, involving a rewrite of the OS Module code.
There's also the issue of the 26bit Branch boundary. Some games Branch to the module SWI decode table directly, instead of issuing SWI's, meaning those modules have to remain within the first 32mb. This is already coded, RMA space within the JIT is located at 8mb. Entry points from the OS and vectors however need to remain in the actual RMA to avoid issues when appspace is paged in/out by the OS.
In short 26bit modules aren't straightforward to support.
Thanks for the info. Since I assume that you are only worrying about supporting 32-bit RISC OS 5 (RISC OS 6 is basically irrelevant), then I guess there might be the option of contributing OS updates to ROOL which might assist ADFFS?
It crashes. The program seems totally stopped while showing a black screen after the LOADING message disappears.It used to do that when it had trouble working out the physical address of the GPU buffer, but that issue was fixed a long time ago. How doesn't it work? Does it crash or does it carry on in the background you just can't see it? What does the debug build do?
Using the debug version, I can see A is stopped at:
When the game runs and shows the map screen, A is at A:1928 while the map is shown, then it goes fine into the game.
I've found out that, even if I press the button very soon, the game DOES work some times. I'd say it works 50% of the times I do that.
I can repro it. Rather oddly, if I copy !ADFFS (2.39) to the RAM drive and run it from there, Magic Pockets seems more reliable as I've not managed to get it to fail in 10 attempts.Vanfanel wrote:It crashes. The program seems totally stopped while showing a black screen after the LOADING message disappears.
There seems to be a new issue in 2.40 though as its causing RISCOS to crash. On 2.39 it hangs at a blank screen when you would normally get the level prompt.