Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

How to get your favourite old games running on your newer hardware

By . Published: 22nd Jan 2003, 08:02:51 | Permalink | Printable

Alex Macfarlane Smith guides us through the patchwork

One of the long running concerns about newer versions of the OS/hardware is that a lot of the older games won't run on the new machines. This document attempts to at least give you some information on how to go about updating games to work on newer versions of the OS / CPU (at least as far as RISC OS 4 / StrongARM).

A common problem with older games is that they have been compressed in a way which involves the use of self-modifying code in order to decompress themselves. This was fine up until the StrongARM, but when the StrongARM was released; because the StrongARM has both an instruction and a data cache, modifying the data to create new instructions doesn't update the information in the instruction cache. There are a number of ways round this - one is to simply turn the cache off (using *Cache Off or similar) and then turn it back on (*Cache On) when the self-modifying code has completed, which is fine - but has the disadvantage that it makes it comparatively slow at decompressing. Better ways are to either use the above Cache Off method initially to get the decompressed code, and then save this code out and use this as the code to be executed rather than the original compressed code. Alternatively, you could use the OS_SynchroniseCodeAreas SWI after the self modifying code to flush the instruction cache.

Other things that crop up are assumptions about the behaviour of the processor. An example of this is storing PC on the stack; for example using STMFD R13!,{PC}, as is commonly used in a number of Krisalis games. Up until the StrongARM, this stored PC+12 on the stack, but on the StrongARM it stores PC+8. Thus the relatively common sequence:

B <somewhere>

fails because when the <somewhere> function returns with LDMFD R13!,{PC}, it returns to the branch again, and eventually breaks when it runs out of stack. The solution is to swap the MOVNV and B instructions round, as this works for both the PC+8 and PC+12 cases. Be wary of other instruction sequences that fall foul of this problem though (Swiv has a number of sequences which assume PC+12 is stored, and some of these aren't so easily patched around).

Often games make direct use of the VIDC1 chip, which resided at &03400000 on old machines. But as of the Risc PC this no longer works. The simplest way is often just to no-op these instructions out. In a number of cases this will allow the game to work fine, albeit with some loss of colour (you could always go back later and patch it properly). Or you can update the code to run in a graphics chip independent way (Darren Salt's patches for some games have code for this), or just update it to run on VIDC20 (probably a bad idea these days with new machines coming out, but it's not always easy to make it work cleanly on any graphics chip, you could look at Theo's patch for Swiv for an example of this).

One more thing to watch out for is that as of RISC OS 4, zero page is protected, and there's a number of games which write stuff to zero page (often they modify &100). The best way is to patch this cleanly to stop it using zero page at all (which I unfortunately don't have enough knowledge to be able to do that), or to do a SWI "OS_EnterOS" before the offending zero page accesses so that the game can still behave as it used to. Bear in mind though that zero page values may change over time and this is probably a bad thing to do - Tertis for example made assumptions about certain locations in zero page, and as a result wouldn't work on Risc PCs by default.


Alex's patches Darren's patches

Previous: Facts found on Acorn Cybervillage
Next: How to get your favourite old games running on your newer hardware


Viewing unthreaded comments | View comments threaded by reply | Skip to the end

No comments posted - yet. Post one yourself or come back soon.

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • The RISC OS dispute: 12 months on
    What, if anything, came out of the hype from last summer?
     57 comments, latest by sborrill on 27/07/05 11:10AM. Published: 17 Jun 2005

  • Random article

  • Website update tool has new author
    SiteMatch taken over by Richard Porter, version 2 released
     Discuss this. Published: 20 Feb 2008

  • Useful links

    News and media:

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster


    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign

    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "I made the assumption, though I should have known better in view of previous experience, that the article was factual"
    Page generated in 0.0589 seconds.