Top reasons games stop working past RO3

General development discussion not covered by a specific forum
Post Reply
JonAbbott
Posts: 1736
Joined: Thu Apr 11, 2013 12:13 pm
Location: Essex

Top reasons games stop working past RO3

Post by JonAbbott » Sat Jan 24, 2015 6:23 pm

There's a variety of reasons why games stop working past RO3.11 and RO2 come to think of it, here a list the most likely candidates starting with things that break on RO3.1. The higher the number, the higher the OS version before it's an issue:
  1. Badly written !Run Obey file. Common issues are simply not setting the memory requirements via *WimpSlot or forgetting to set the screensize etc
  2. !Boot Obey files that auto-run the game or run protection code (eg. Gribbl'y Day Out)
  3. A dependency on SHIFT-BREAK to boot the floppy. This tends to happen on the really early games as a way to free memory (eg. Arcade 3)
  4. Use of abbreviated * commands (eg *L. instead of *LOAD)
  5. Disk protection that's dependent on a particular Floppy Drive Controller (eg. original Eterna releases talk directly to the 1772 FDC)
  6. Taking over the IRQ hardware vector directly by writing to &18. With RO3.5 the instruction at &18 changed from B &1Fxxxxx to LDR PC, &xxx. Any code which tries to decode this back to an address instantly fails (eg. Nebulus, Lotus Turbo Challenge 2, Gribbly's Day Out)
  7. Taking over IRQ1v directly by writing to &100, instead of claiming IRQv legally. This can cause lockups when the code tries to pass the call on, or prevent IRQ's from being handled back the OS
  8. Bugs in the code. I've seen a few protection routines which work by pure luck, I've also seen code that directly takes over a vector and then presumes R12 equals a certain value. (eg Diggers where most Branches in the main code are out by 1 word!)
  9. Self modifying code. Invariably used in protection methods and some games developed for ARM2 to speed the code up
  10. Claiming vectors instead of passing them on
  11. Reliance on OS_UpdateMEMC returning a legal address. On earlier versions of RISCOS, OS_UpdateMEMC returned the MEMC CR register, with the address included. Some games change this value and then write the value to itself, instead of legally changing CR via OS_UpdateMEMC
  12. Directly writing to the screen memory without first requesting the address via OS_ReadVduVariables
  13. Non 32bit compatible instructions (eg MOVS PC,R14)
  14. Reliance on IOC, VIDC or MEMC registers
  15. Use of 4 bit screen modes
  16. Running the whole game under an interrupt. This can cause re-entrancy issues and parts of the OS to fail because IRQsema is set. Simply swapping from IRQ to SVC and then calling SWI's may have worked on RO2, but invariably fails on later RISCOS versions.
Games are tested on the following systems, under emulation initially to rule out caching issues and then physical for final confirmation:
  1. RISCOS 2 ARM2 physical - only required for really early titles and can be skipped for most if they work on ARM3
  2. RISCOS 3.11 ARM3 emulated
  3. RISCOS 3.50 ARM710 emulated - where they won't run on RO3.71 emulated
  4. RISCOS 3.71 ARM710 emulated
  5. RISCOS 3.71 StrongARM emulated
  6. RISCOS 5.21 ARM11 physical
  7. RISCOS 3.71 StrongARM physical
  8. RISCOS 5.21 StrongARM emulated
  9. RISCOS 3.11 ARM3 physical
  10. RISCOS 3.71 ARM710 physical
  11. RISCOS 4.39 ARM710 physical
  12. RISCOS 5.21 StrongARM physical
  13. RISCOS 5.21 Iyonix physical

Post Reply