Update on next release

[richw]

For what it is worth, I enjoy any sort of update on here, even if I don't follow it all. However it seems unreasonable to sound demanding when someone is dedicating their own time. I am in awe of your commitment, probably more so than the impressive technical achievements.

[JonAbbott]

For what it is worth, I enjoy any sort of update on here, even if I don't follow it all. However it seems unreasonable to sound demanding when someone is dedicating their own time.

Fire away, I'll accommodate requests where I can, be it more detail or requests for additions etc. Additions may not happen immediately, but I do add them all to the wish list and review on a regular basis to see what I can easily include.

I get so little feedback, it's hard to tell if people actually find what I'm doing is of any use - I don't even know if it works beyond my own kit if I'm honest, from memory only two people to date have confirmed any success or issues. That's a royal pain for me as it means I have to spend most of my time testing beta's when the idea of a beta is to let other people test on your behalf. Admittedly, I try not to put out broken betas however, as the supported list of games growing I can no longer test them all.

- - -

I spent a few hours debugging yesterday and believe I've find a source for a lot of the issues. After analysing which games were failing and at what point, I categorized the issues into the following:

1. Games that load files and crash during the loading sequence
2. Games that crash with invalid addresses
3. Games that hang randomly

On investigating (1) further, I realised I'd made a noddy error when coding the paravirtualized** OS_GBPB and forgot to add the final step of cleaning / invalidating the caches. This also got me wondering if I'd missed any other SWI's or CLib functions that need to clean the caches, so I need to double check them over the next few days.

Look into issue (2) I found I wasn't correctly disabling Alignment faults and enabling rotated loads - my Pi ordinarily shouldn't need this as the CPU Configuration is set to ARMv5 by default, however I've updated recently to a Pi2 ROM daily build and wonder if the behaviour has now inadvertently changed. With this fixed a few games got a bit further before crashing on other issues.

(3) I've yet to look into, although its probably not a major issue. I left a few games soak testing during the day, Ballarena and 2067BC ran fine for hours, Conqueror hung within minutes as did Fire & Ice. Zarch is soak testing as I'm typing this. Battle Chess isn't quite working to soak test, its working under emulation so my guess is something isn't cleaning the cache correctly, this is also confirmed by the fact the debug build of ADFFS behaves differently to the non-debug.

Both Fire & Ice and Gribbly's Day out were previously hanging after several cycles of demo mode - but at the same place, implying either an instruction isn't being encoded correctly or something's been missed. I still need to look into this once I've resolved the random hangs.

Branch Prediction, although simple to implement (it's about 20 instructions) is proving very good a highlighting any minor flaws. For it to work correctly, all writes to App space must be mirrored in JIT App space so that any incorrect Branch code is cleaned and recoded if it's overwritten by any file loads, memory writes, self-modifying code etc. It's particularly susceptible to this, one missed instruction and the code in JIT App space won't match the original code in actual App space and result in a crash, hang or odd behaviour.

Games are running as User code*, so any writes done by them are trapped and handled. Anything OS related however needs paravirtualizing so that after RISCOS has done it's thing, ADFFS performs the necessary post actions to ensure the cache's are cleaned of any instructions and that code in JIT App space matches actual App space.

* At the minute this is relying on the main game code not switching into SVC, in a later ADFFS build the CPU mode will be paravirtualized so that all code runs as USR and registers/TLB/L2PT are switched as the code switches virtual CPU modes. Interrupt / vector code that's virualized is all run as User mode, so anything that generates Sound or relies on T1 / VSync IRQ's isn't an issue.

** paravirtualizing - essentially modifying host OS/hardware behaviour to allow code to run at a lower privilage level. In ADFFS's case, this means managing various RISCOS SWI's to allow changes both pre and post of the SWI performing its usual action.

[ringdings]

My RISC skills are at the novice end of the scale, but I'd be happy to help with testing if there's demand...
I can follow instructions and I've been able to get released games working.
I have 3 x Pi B: a rev1, a rev2 and a Pi2

My first exposure to Archimedes was in sixth form in 1990 and I was totally blown away by Lander! Going off to uni a year later all I could afford was a second hand Amiga 500 but that was still very impressive to me.
I'm amazed at all the hours and hard work that has gone into this project.. thanks!

[JonAbbott]

On investigating (1) further, I realised I'd made a noddy error when coding the paravirtualized** OS_GBPB and forgot to add the final step of cleaning / invalidating the caches. This also got me wondering if I'd missed any other SWI's or CLib functions that need to clean the caches, so I need to double check them over the next few days.

Looks like I'd missed _kernel_osgbpb completely so have now added that. Trouble is, that's now caused ExtASM to get into an infinite loop and its now refusing to compile the code, so I've got to fix that first before I can even test

I'm not sure its ever called though, as I've left _kernel_osfile in a state where it's fully coded, but triggers a CLib error when called - I left it that way so I could find a game that used it and double check the code actually worked. I suspect most C code is calling the stdio functions which ADFFS doesn't touch - it relies on CLib running as User and deals with them in the Abort handler. I'm debating changing that behaviour as it's not particularity optimized, where whole pages containing code are being overwritten, it should really be switching them back to data pages that are R/W in User mode. The functions in question are listed as a possible change for Phase 3 of the JIT (see the CLib section.)

The other alternative is to add memory scavenging and get ADFFS to check pages generating Aborts every 10 secs or so to see if they're now all data - switching them back to R/W in User if they are. This is probably a cleaner solution as it will cover cases where STR / STM are being used to copy data around and cover all code, not just CLib. I'd just need to be careful about how many pages it checks as it would potentially need to read the whole page essentially cleaning the D cache in the process. I could mitigate that somewhat by getting the cache handler to kick off a scavenge whenever it needs to clean the whole cache - that happens so infrequently now though, it's probably not worth coding.

[JonAbbott]

@Vanfanel / @ringdings

Latest build is on the FTP site (/development/ADFFS) if you'd like to do some testing to confirm what issues are remaining. I've fixed a few more issues today and done partial testing. I've updated the known issues post in this thread with all known working games - there's still quite a few that are broken.

[JonAbbott]

Updated daily builds in /development/32bit/CPU

In yesterdays build I rolled back the STR code to a previous version to resolve some issues, I've now had a chance to resolve the root problem (STR PC, [PC] wasn't encoded correctly) and reinstate the new code.

[JonAbbott]

@Vanfanel / @ringdings - Don't worry about testing, I've spent the past two days testing on both the Pi and StrongARM and have now finished updating the known working games issues list

[ringdings]

I've just had to rebuild the RISC image on my Pi and I've also updated ADFFS to 2.49g

How do I
"Update the ADFFS module with the daily build (/development/32bit/cpu/adffs500,ffa), and grab the debug module version to assist with locating issues (/development/32bit/cpu/adffs500db,ffa)" ?
I can see in my ADFFS folder there is a adffs500 file...

And a general RISC OS question: how do I get the desktop to remember the position of where I've moved icons to?

[JonAbbott]

How do I
"Update the ADFFS module with the daily build (/development/32bit/cpu/adffs500,ffa), and grab the debug module version to assist with locating issues (/development/32bit/cpu/adffs500db,ffa)" ?
I can see in my ADFFS folder there is a adffs500 file...

Overwrite ADFFS500 with ADFFS500,ffa after renaming it and changing the filetype to FFA. ADFFS500db,ffa - just run as required after you've loaded !ADFFS, you'll only need it if you either want to see what's happening realtime or want to find out where a game hangs/crashes. I tend to use the debug version all the time, as I'm only diagnosing crashes, but the debug info does get in the way if you're doing long play testing.

And a general RISC OS question: how do I get the desktop to remember the position of where I've moved icons to?

Once you've put them where you want them, save the pinboard - middle click/save on the background

[ringdings]

Is there a rule of thumb as to whether I should hold CONTROL to quit desktop when booting floppy or not?
So far I've found that on the games I've tried I get a blank screen if I hold CONTROL.