Running Ankh: The Tales of Mystery

[NancySadkov]

Hi! I LP-review RISC OS games, playing each game for about 30min and commenting on it. I managed to get all exclusive RISC OS games running, except Ankh, which fails to read CD properly.

I tried the HDD images coming with RPC Emu and VirtualRPC (which just gave me "unknown directdraw error"). I even tried building my own distro, but I still got the CD-rom issue (apparently it can't read audio tracks). I tried using the CDFaker104 (which as I understand is the daemon tool style CD emulator for RISC OS), but it just says nothing on startup. The low res Archimedes Ankh's version runs fine, but not the CD, which has the true color graphics and CD audio. If somebody have managed to get Ankh running on Windows 11, please let me know how to do it.

Else I will probably have to fire up a debugger and Ghidra, but disabling audio and movies doesn't sound like the right way to review a game.

[sirbod]

I've just tried it with CDFaker 1.04 under RedSquirrel running RISC OS 3.71 and it does work, with CD-Audio...however...depending on which version you have, it might have a bug in the code that constructs the CDFS Control Block.

Use the patcher in the post below.

Obviously make sure you're using a BIN/CUE image of the CD so the CD-Audio metadata is retained.

[NancySadkov]

You need to correct it, which can be done by replacing the following line in !Run:

Many thanks! I will try it.

[NancySadkov]

I've just tried it with CDFaker 1.04 under RedSquirrel running RISC OS 3.71 and it does work, with CD-Audio...however...depending on which version you have, it might have a bug in the code that constructs the CDFS Control Block.

Ok. Tried RedSquirrel. It gave the same DirectDraw errors as VirtualRPC, but I kept clicking OK, and eventually it went through.

This time I grabbed a HDD Arc from this guy: https://www.youtube.com/watch?v=gtpdaonk4iM

It came with SSound under Utilities.Patches

I tried different models, but they all gave the bellow error, which IIRC correctly I also got with the RPCEmu running OS 3.71 coming with it.

!CDPlayer refuses to play the mounted cue+bin either, but CDFS does read it and !Ankh install goes fine.

The only thing I get is a big nice segfault.

[sirbod]

It gave the same DirectDraw errors as VirtualRPC, but I kept clicking OK, and eventually it went through.

You should probably resolve your DirectX issues first as you should not be getting DirectDraw errors. Perhaps start with dxdiag.exe and see if it highlights any issues, then download/install DirectX. Possibly also clear out your graphics drivers and reinstall the latest? ... the usual things you do when you get graphics issues on Windows.

This time I grabbed a HDD Arc from this guy: https://www.youtube.com/watch?v=gtpdaonk4iM

It came with SSound under Utilities.Patches

That's not the usual place it should reside, it should be in !Boot.Resources.!System.310.Modules.

I'd suggest going back to basics and reset your !Boot to UniBoot so its in a known state, then update any Modules as/when required. Rename !Boot to something else, then extract UniBoot...reboot and then try Ankh.

I tried different models, but they all gave the bellow error, which IIRC correctly I also got with the RPCEmu running OS 3.71 coming with it.

RISC OS 3.71 ARM710 or StrongARM should be fine - these are the only two you really need for the later released games Personally I'd probably stick to ARM710 unless a game specifically requires a StrongARM as it avoids the complications of SA compatibility.

!CDPlayer refuses to play the mounted cue+bin either, but CDFS does read it and !Ankh install goes fine.

I can't say I've tried !CDPlayer, but it might require CDFaker to be loaded earlier in the Boot sequence. Try loading !CDFaker in PreDesk (!Boot.Choices.Boot.PreDesk)

The only thing I get is a big nice segfault.

It's not clear at what point during loading that error occurred. It's not !RunImage (or if it is, your version is different to the one I'm looking at), it's possibly !AnkhHigh.misc.Intro? It's certainly not the main game as that's written in BASIC (!AnkhHigh.misc.terdipo - which is obfuscated)

[NancySadkov]

You should probably resolve your DirectX issues first as you should not be getting DirectDraw errors. Perhaps start with dxdiag.exe and see if it highlights any issues, then download/install DirectX. Possibly also clear out your graphics drivers and reinstall the latest? ... the usual things you do when you get graphics issues on Windows.

I have a win11 HP laptop with iRIS Xe, so drivers shouldn't be issue for a winxp app. Guess Microsoft botched their DirectDraw compatibility somewhere around Windows 7 (since VirtualRPC running in Windows 7 gives the same error). And it appears on mode change, so probably related to how windowing system works. I think MS redid GDI completely since XP, but forgot to tell DirectDraw about that.

I can't say I've tried !CDPlayer, but it might require CDFaker to be loaded earlier in the Boot sequence. Try loading !CDFaker in PreDesk (!Boot.Choices.Boot.PreDesk)

Thanks! I will try that.

It's not clear at what point during loading that error occurred. It's not !RunImage (or if it is, your version is different to the one I'm looking at), it's possibly !AnkhHigh.misc.Intro? It's certainly not the main game as that's written in BASIC (!AnkhHigh.misc.terdipo - which is obfuscated)

Haven't yet debugged it, since modding the emulator for that will be a pain. Also looking if there will be any pitfall to worry about. I remember reading MIPS asm was a huge pain, due to branch delay slots.

[NancySadkov]

Ok. I gave up running it as is.

As I understand &ff8 files have no header and are loaded at &8000.
Unsure about the relocatables though, but ankh's RunImage appear to have sensible ARM there.
I read BASIC games can have inline ARM and machine code, which can be a nuisance.

Ghidra only supports ARM4 (I guess Ankh uses ARM3).
And I was unable to get IDA Pro working on win11.
I don't remember if IDA had ARM3 disassembler.

Anyway, now I need to get RPCEmu compiled and modified to do traces and breakpoints on CD access.
This approach is kinda overkill, but I don't feel brave.

Documentation states there should BLNV instructions (00 00 00 FB), if the executable is not compressed or relocatable, but instead there are movs (00 00 A1 E1)
http://www.riscos.com/support/developer ... ormat.html

So apparently RISC OS C compiler produced non-conforming code?

Also, I'm curious why they haven't introduced Thumb initially? Memory was still expensive in 1987, so instruction size is a thing even today today due to cache sizes.

[sirbod]

I have a win11 HP laptop with iRIS Xe, so drivers shouldn't be issue for a winxp app.

The Xe drivers are likely the issue here as Intel dropped support for old API's and handle it via a DirectX12 translation layer. Obviously make sure you've installed the latest Intel drivers as they have been actively improving backward compatibility.

Unfortunately, I do not have anything with Xe to try and replicate your setup.

Haven't yet debugged it, since modding the emulator for that will be a pain.

I think you're overcomplicating the problem as it shouldn't require modifying emulators to diagnose your problem...it will almost certainly be either your !Boot sequence or your copy of Ankh.

As I understand &ff8 files have no header and are loaded at &8000.

Correct in that they are loaded at &8000. They'll have a standard "header" structure if they're compiled to Acorn standards.

Unsure about the relocatables though

As the name implies, they can load at any address - generally somewhere in Application space (&8000+) or the RMA (Relocatable Module Area)

ankh's RunImage appear to have sensible ARM there.

!RunImage is the Wimp front-end and is a standard Absolute. If you disassemble it via !ARMalyser you'll glean more RISC OS specific information.

When you click on it, it runs external apps including the Intro and the the main game code which as previously mentioned is obfuscated BASIC.

I read BASIC games can have inline ARM and machine code, which can be a nuisance.

Possibly not a factor here as I'm not convinced its getting that far. It you want to look at the BASIC code, drop to the Supervisor prompt and run !AnkhHigh.misc.terdipo - it will error, then type BASIC followed by OLD. You can then SAVE the BASIC code to look at in something like StrongEd or Zap.

It's probably possible to run that directly if you want to bypass !RunImage, in which case you'd need to ensure memory is configured correctly (run !AnkhHigh first might be sufficient), then just launch it. You'll need to delete line 0, which checks it its being run unobfuscated.

I've not tried this myself so can't confirm it works when run this way.

Ghidra only supports ARM4 (I guess Ankh uses ARM3).
And I was unable to get IDA Pro working on win11.
I don't remember if IDA had ARM3 disassembler.

You're probably not going to get far with any modern disassemblers. Ghidra will give you a pseudo C output, which is probably not going to be that useful to diagnose your issue.

Documentation states there should BLNV instructions (00 00 00 FB), if the executable is not compressed or relocatable, but instead there are movs (00 00 A1 E1)
http://www.riscos.com/support/developer ... ormat.html

That just means those elements of the Absolute have no code associated with them and perfectly normal.

[NancySadkov]

I think you're overcomplicating the problem as it shouldn't require modifying emulators to diagnose your problem...it will almost certainly be either your !Boot sequence or your copy of Ankh.

Well, I though it would be a nice way to accustom myself with RISC OS, before actually trying to work with the kernel (which requires either ICE or a good software emulator). Back when I extracted sprites from PS1 and DOS games, I modded the PCSX and DOSBox for that. And that worked fine (i did a ton of work converting the classic PCSX to use pure SDL though, since desktop versions were impossible to compile). And then I got two separate bin+cue dumps of Ankh (one has tracks inside a single bin, another has separate bin for each track).

Correct in that they are loaded at &8000. They'll have a standard "header" structure if they're compiled to Acorn standards.

Well it is an interesting header, because it starts with machine code, and has no magic id (I think we are supposed to trust the file type). The machine code jumps over a set of fields, which apparently tell the OS how much memory to allocation for different sections. I need to add them to my map manually, because Ghidra knows nothing about RISC OS. Need to get IDA working to check if it handles that properly &ff8 files properly, and maybe also has out of the box SWI calls dictionary. Or maybe somebody here has premade RISC OS SWI plugin for Ghidra?

So I got to the _start() and instantly got confused. The first thing it does is calling SWIs &20010 and &A0681:
http://www.riscos.com/support/developer ... ilist.html

As I understand &20000 flag means that RISC OS ignores any errors any returns control to the user, with R0 holding the error. R0 would be the syscall return value in C? The &10 is basically OS_GetEnv (classic C thing all _start()s do), but the &80681 (SharedCLibrary_LibInitAPCS_R) is something I see for the first time in my life. C library is a kernel module? Then there is also _32 and _A, which as I understand are newer and is even older versions of the C-library. Is that to allow the userspace to re-use the kernel CLibrary or just to facilitate faster implementation of primitives, like memcpy? Does kernel itself use it? I.e. can we unload the _A and _R versions, if we only run _32 software? Do these SWIs auto-load the library, if some app calls them, or just expect one to be pre-loaded?

Then it also has a separate call to &80682 (SharedCLibrary_LibInitModule), which apparently does what we would call dynamic linking with the modules used by RunImage.

!RunImage is the Wimp front-end and is a standard Absolute. If you disassemble it via !ARMalyser you'll glean more RISC OS specific information.

Thanks! I will see if it has dictionary of SWI and C runtime calls.

Possibly not a factor here as I'm not convinced its getting that far.

How do basic programmers optimize tight loop then?
Is it possible to easily attach a separate C module?
As I understand this old BASIC has no GC;
So interfacing should be easy.

You're probably not going to get far with any modern disassemblers. Ghidra will give you a pseudo C output, which is probably not going to be that useful to diagnose your issue.

Well, it works, just without the function signatures.
But I need a separate debugger with breakpoints and traces.
Ghidra has two windows: one is ARM and another is its attempt at decompile it.
Just like IDA HexRays it is known to mess up the stack and the function calling conventions.
I think one can provide function signatures and data structures to make it more readable.

As a side note, I used GPT3 and GPT4 as both x86 disassembler and decompiler.
You give it byte code, then ask disassembly, then decompile, then ask refactor.
It works since bytecode to C translation is no different from Chinese to English.
Just watch for the LLM to do stupid human-like mistakes.
Though I'm unsure if it had enough ARM and RISC OS examples in its training data.

That just means those elements of the Absolute have no code associated with them and perfectly normal.

Yup. But I was confused since the documentation states AIFs should be using BLNV for the NOP.

[SKS1]

That just means those elements of the Absolute have no code associated with them and perfectly normal.

Yup. But I was confused since the documentation states AIFs should be using BLNV for the NOP.

This was changed in the mid-1990s to MOV r0,r0 when the NV condition was deprecated; see CodeStds/AIF in the DDE.

The SharedCLibrary SWI interface and the C runtime functions that it provides are documented in PRM volume 4.

[NancySadkov]

This was changed in the mid-1990s to MOV r0,r0 when the NV condition was deprecated; see CodeStds/AIF in the DDE.

The SharedCLibrary SWI interface and the C runtime functions that it provides are documented in PRM volume 4.

Thanks! Apparently even Ghidra today doesn't support BLNV, treating it as data, since it never pops up in modern code:
https://github.com/NationalSecurityAgen ... ssues/4871

Regarding SWIs, there is apparently a way to auto-resolve their names, given that somebody have compiled an SWI table.
https://syscall7.com/resolving-arm-syscalls-in-ghidra/

That should also allow marking some of them as no-return, so disassembler wont treat anything after them as code.

Also, tried IDA. It only supports ARMv4 and simply refuses to load RISC OS stuff.
Dunno if there is a plugin for it.
I remember it disassembling Amiga executables perfectly.
And IDA supports all kinds of obscure archs, including CPUs by the Russian government (something NSA apparently doesn't care about).
So unsure why IDA doesn't support the classic ARM. Maybe older IDA versions supported it?

[SKS1]

FWIW my new laptop has Iris Xe graphics. dxdiag is happy; drivers are from March 2023.
Grabbed a RPCEmu Easy Start image with RO 3.71 and it seems to be working fine. Don't have Ankh to test, though.

[NancySadkov]

FWIW my new laptop has Iris Xe graphics. dxdiag is happy; drivers are from March 2023.
Grabbed a RPCEmu Easy Start image with RO 3.71 and it seems to be working fine. Don't have Ankh to test, though.

There is a bin+cue for Ankh at archive.org https://archive.org/details/Nova_AnkhArch_UK
But it doesn't work either on my RO 3.71 install. I think I tried every combination.
Including the Easy Start one.
Just now tried the one at http://www.riscos.com/ftp_space/370/index.htm

What I noticed is that !CDPlayer can see all 8 tracks if cue+bin is mounted through daemon tools, and then captured with RPCEmu. Although !CDPlayer still fails to play it (clicking play produces error). But !CDFaker mounted bin+cue doesn't show in !CDPlayer.

The riscos.com install has SSound under !Boot.Resources.!System.Modules, but it isn't loaded on boot. So I've thrown it into PreDesk folder. I have also thrown the !CDFaker there. Still haven't fixed the !CDPlayer. So I guess there is no way to emulated the game as is. I got accustomed with Ghidra, so next step is compiling RPCEmu and modding it for debug.

Below is the exact error I get each time.

[flibble]

RPCEmu doesn't support bin/cue CDROM images ... yet (only iso)

[sirbod]

There is a bin+cue for Ankh at archive.org https://archive.org/details/Nova_AnkhArch_UK

I'm not sure that CD image is going to work with CDFaker as it's been split out into separate tracks - I don't recall if I added support for multiple BIN files when I added CUE support to CDFaker. I'll check and get back to you.

Once it is working, it should look like this in Partition Manager:

EDIT: Looks like I started to add multi-FILE support, but didn't finish it so that particular CUE/BIN isn't going to work unless the CD is reconstructed into one BIN file.

[NancySadkov]

EDIT: Looks like I started to add multi-FILE support, but didn't finish it so that particular CUE/BIN isn't going to work unless the CD is reconstructed into one BIN file.

I mounted it with daemon tools, but I'm sure it is possible to convert it. I think archive.org also had a monolithic cue+bin, but it doesn't work either.

Edit: some badly written apps fail to run from HostFS. For example, the Last Offence (which works on Arculator ROS 3.11 but crashes after the first screen on RPCEmu ROS3.11) gives cryptic errors if ran from anything other than HDD or floppy (haven't yet tried setting up a network). But that isn't the case with !Ankh

[NancySadkov]

RPCEmu doesn't support bin/cue CDROM images ... yet (only iso)

Yup. So I picked D:\ made by daemon tools.
Dunno how it compares to a real CD-ROM. Windows 11 reports it as "BD-ROM."
The result is: !CDPlayer sees all 8 tracks, but gives error on any attempt to play audio tracks.
Haven't tried pure audio CDs though. So maybe !CDPlayer just dislikes data CDs with audio.
Alternatively it is the RPCEmu problem or both archived bin+cue versions were incorrectly dumped.
Guess CD audio isn't the most requested feature, since Ankh is likely the single app using it.

[danielj]

I just made a bin/cue of it, and did the MD5 of the bin -
e70db85000eb8a038e282c5bc75f6f21

Does that match yours?

[NancySadkov]

I just made a bin/cue of it, and did the MD5 of the bin -
e70db85000eb8a038e282c5bc75f6f21

Does that match yours?

Code: Select all

$ certutil.exe -hashfile ankh.bin MD5
MD5 hash of ankh.bin:
bea485023459cefa12b0cbb7a63686d3
CertUtil: -hashfile command completed successfully.
$

But I think bins could vary between the dumping apps.


Anyway, I have been studying the AIF loading, decompiling the start(), which just calls the C library init and passes control to one of the stubs patched by it. How does Clib locate the main()?

Now there are two drastically different strategies:
1. Ascending approach: patch in a dumper code inside the executable and then do the basic `printf`debugging, as the C library relocates the stuff. Import the dumped memory into Ghidra for analysis.
2. Descending approach: Run an external debugger, preferably ICE level, and set breakpoints. Import the dumped memory into Ghidra for analysis.

Somehow I always used 2 before, because 1 seems like more difficult. 2 is also nicer, since I can easily continue from a saved state (needs modding the emulator though) or just automate input.

Below is the start() routine. More info on how the RISC OS SharedCLibrary operates would be welcome.
Also interesting how GCC uses its own lib (I doubt the RISC OS's one is compatible with GNU).
My own programs currently use the Clang, so unsure what is the best way to compile for RISC OS.

Code: Select all

typdef struct {
  dword error_number;
  char *error_string;
} error_block_t;

typdef struct {
  byte failed; //returned inside cpsr overflow flag
  error_block_t *block; //returned inside r0
} SWI_Error_Return; //apparently the same for all SWIs

typdef struct {
  sdword library_chunkId;    //1 or 2, or -1 (end of stub list)
  dword entry_vector_base;  
  dword entry_vector_limit; //end offset of entry vector
  dword static_data_base;
  dword static_data_limit;  //end offset of static data
} stub_descriptor_t;

error_block_t error_block_c64; //it has text "C64"
                               //C library error 64?

//it is 0 in the file default
//apparently user can redef stack?
int *GStackSize = 0;

stub_descriptor_t stub_descriptors[] = {
  ...,
  {-1,0,0,0,0}
};


void _start() {
  r_OS_GetEnv env = OS_GetEnv();

  int StackSize = GStackSize ? *GStackSize : 0x1000;

  SWI_Error_Return error = SharedCLibrary_LibInitAPCS_R(
     module_descriptors,
     workspace_limit,
     env.ram_limit,
     -1,
     0,
     -1,
     (StackSize >> 10) << 0x10);
  if ((bool)error.failed) OS_GenerateError(error.block);
  if (StackSize * 0x10000 < 0x60000) { // stack is too small?
    OS_GenerateError(&error_block_c64); // exit with error
  }
  (*(codep*)main_stub)(); //gets loaded in main?
  return;
}

//apparently this function gets patched by SharedCLibrary_LibInitAPCS_R
main_stub() {
   mov pc, <value to be patched>
}

[SKS1]

You can grok the RISC OS SharedCLibrary source on the ROOL GitLab:

https://gitlab.riscosopen.org/RiscOS/So ... RISC_OSLib

Confusingly to newcomers, it's globbed together with other RISC OS support routines when built for ROM (these routines being used by the ROM apps such as Edit), hence the RISC_OSLib rather than CLib or something sensible.

As for how main() is located, programs that used the SharedCLibrary are linked with o.Stubs, which imports that symbol.

[NancySadkov]

You can grok the RISC OS SharedCLibrary source on the ROOL GitLab:

https://gitlab.riscosopen.org/RiscOS/So ... RISC_OSLib

Confusingly to newcomers, it's globbed together with other RISC OS support routines when built for ROM (these routines being used by the ROM apps such as Edit), hence the RISC_OSLib rather than CLib or something sensible.

As for how main() is located, programs that used the SharedCLibrary are linked with o.Stubs, which imports that symbol.

That can be helpful, but I think Ankh uses the old version of the library. Modern RISC OS appears to be rewritten to support ELF executables and nobody uses AIF anymore. So I'm digging the leaked source code for the RISC OS 3.71. I have also noticed that there is just a single version of SCLib under !System.310.Modules and on update it gets overwritten with a new one. Haven't that caused the compatibility issues or all versions were backward compatible?

[NancySadkov]

Compiled the RPCEmu stumbling at the obvious part - downloading and getting qt-opensource-windows-x86-5.9.8.exe working. It weights 2.4GB (several times more installed) and takes a minute to start (several times more to compile). Requires user to manually update the PATH variable, like it is some mainframe Unix or a DOS thing. Previously RPCEmu used Allegro, but for some reason switched to Qt, which was a bit scary already during KDE 2.0 times, but with age Qt turned into a post-modern horror comedy. Qt also now forces you to register an account to use. Then again, I was never a big fan of C++, and prefer w64devkit + notepad++ to the Visual Studio IDE

[sirbod]

Looks like I started to add multi-FILE support, but didn't finish it

I'm currently adding support for multi-FILE CUE's and hope to have a beta available soon. It's mostly coded and working with the Ankh CD linked above, I've just got to track down one bug and implement discop's that span across BIN files.

[sirbod]

You can grab the CDFaker beta that supports multi-file CUE's here.

Attached is an Obey file that will correct the High res version of Ankh's CD code, drop it into the !Ankh folder and run it. It will back-up and patch !RunImage and unobfuscate and patch the main BASIC game code.

I've confirmed the Archive dump of the CD does run and play audio correctly...just make sure the RISC OS filenames of the BIN files match the filenames in the CUE file. ie they should all end "/bin"

[NancySadkov]

You can grab the CDFaker beta that supports multi-file CUE's here.

Attached is an Obey file that will correct the High res version of Ankh's CD code, drop it into the !Ankh folder and run it. It will back-up and patch !RunImage and unobfuscate and patch the main BASIC game code.

I've confirmed the Archive dump of the CD does run and play audio correctly...just make sure the RISC OS filenames of the BIN files match the filenames in the CUE file. ie they should all end "/bin"

Thanks! I will try these with Ankh and a few audio cds.
I have also checked the emulator source code.
CD support is basically a stub.
As I understand it was initially developed by Sarah Walker.

RISC OS hacking is a bit harder than PS1 and DOS.
Because of MMU mapping memory arbitrarily.
Another issues is multithreading.
I.e. you can't set a break point on video memory write.
And then expect it to lead back to the place which blitted the graphics.
Same way with disk read - it will only get you inside the kernel.
But I think you can still dump the memory from inside the emulator.
One way is injecting a dumper code which interfaces the emulator.
The dumper will trigger pagefaults and making the OS loading stuff.
Another issue is identifying the process being debugged.
Which is made by just placing a magic number in place of a debugged instruction.

RPCEmu, BTW, uses separate functions to access code and data.
Makes it easier to set data and code breakpoints.

Now I think there is also the third strategy.
Since the kernel source code is available,
Once can compile the kernel with ability to easily trace and dump processes.
Or one can combine all 3 strategies to "speedrun" the debugging.

[NancySadkov]

You can grab the CDFaker beta that supports multi-file CUE's here.

Attached is an Obey file that will correct the High res version of Ankh's CD code, drop it into the !Ankh folder and run it. It will back-up and patch !RunImage and unobfuscate and patch the main BASIC game code.

I've confirmed the Archive dump of the CD does run and play audio correctly...just make sure the RISC OS filenames of the BIN files match the filenames in the CUE file. ie they should all end "/bin"

Ok. Tried running it with the monolithic bin+cue.
1. The RPCEmu RO 3.7 goes into a black screen just like with your previous memory poke patch.
2. Red Squirrel with exactly the same setup does load the first intro movie, which is okay, and the second one is broken, but Red Squirrel does manage to get into main menu, but after the "Cairo" text screen goes black while sound somehow does work. I think it is the directx problem, since Red Squirrel predates Windows XP (though XP era VirtualRPC gave the same error). I don't have any proper vintage hardware, beside a 64-bit PC with windows 7 from 2008, which I think is already too new to run the Arculator. Still funny how emulators regressed from 2000. I think another option would be PCEm. It emulates everything pre-XP near perfectly, but Pentium 2 is too slow for RPC emulation, which had the same performance as the PC.
3. The new !CDFaker now fails to !Boot from the PreDesk for some reason. In fact, even clicking its !App there doesn't register it, yet invoking !Boot manually does run it.

I gave another try to the 32-bit Windows XP emulation of Red Squirrel under VirtualBox but went even worse than the native Windows 11 and crashed on the 2nd movie. Till the RPCEmu and aemulor get improved, we can consider Ankh non-runnable on the contemporary hardware.

[sirbod]

3. The new !CDFaker now fails to !Boot from the PreDesk for some reason. In fact, even clicking its !App there doesn't register it, yet invoking !Boot manually does run it.

That would be my fault - I seem to have merged in old !Boot/!Run to the last beta. Update to today's ZIP and it should hopefully then work.

[jp6741]

Also, I'm curious why they haven't introduced Thumb initially? Memory was still expensive in 1987, so instruction size is a thing even today today due to cache sizes.

At a guess? Thumb was introduced in 1994. Also I don’t think any RiscPC supported Thumb. Hard to use something that isn’t there.