Jeffrey has tracked down the bug in FPE (versions 4.12-4.31) which clash with the way QTM detects the processor, when running on Arm2/Arm250 machines.
Looks like the bug originated from when Castle updated FPE after taking over Risc OS development (around 2000) - the bug affected the way FPE linked onto the undefined instruction vector. From v4.12-4.31 it looks like FPE switched from using the documented Risc OS method to claim the vector and instead patched it directly. However, along the way it incorrectly read the address of the previous handler...so when it passed on other unknown instructions, they no longer went to the other handlers such as QTM (during the processor test), and this lead to errors. The bug only affected pre-Risc OS 3.5 builds, and wouldn't have appeared for QTM if Arm3 was fitted (as the Arm3-only instruction test would have passed ok).
Anyhow, the new version, 4.32, is on the ROOL site now in the system resources, download here: http://www.riscosopen.org/content/downl ... r-zipfiles.
At my suggestion, Jeffrey has also implemented a neat work-around in the QTM detection code, so it avoids the FPE 4.12-4.31 bug by directly patching the vector during processor detection, on pre-Risc OS 3.5 computers. So you can now use whatever FPE you like, and QTM v1.43 will load perfectly
I've also made some changes in v1.43 of QTM. I've fixed the 32-bit code related bug which I spotted while working on Mus2QTM. The bug was in SWI QTM_Start and under some very specific circumstances (which were achieved in Mus2QTM) - it lead to music playing correctly, but no song being listed as loaded once playing started, because a corrupted register overwrote a key variable.
I've also been playing with Arthur OS - see link here: http://stardot.org.uk/forums/viewtopic.php?f=9&t=6720
And as a result, I've discovered that QTM actually loads and almost works perfectly out of the box on Arthur 0.30 - the oldest Risc operating system! QTM loaded ok and played music, but while playing it produced a constant stream of 'Abort on data transfer' errors. This suggested QTM's sound DMA IRQ was affecting something in Arthur, very differently to RO2 and above... After a lot of bug-hunting and Arthur OS decoding, the solution was found - and it was very very simple.
Arthur OS is like Risc OS 5 !!! - it doesn't expect flags to be preserved on return from IRQs. In particular on entry to the sound DMA IRQ from Arthur - R14 does not contain the return mode or PSR flags. So if you return from the sound DMA IRQ using MOVS PC,R14, you jump out of IRQ mode and back into USR mode, and the stack becomes corrupt... leading to the 'abort' errors...
What made this bug a little difficult to track down in QTM, was the fact I had assumed all the MOVS PC,R14 / LDMFD R13!,{PC}^ instructions had been removed for Risc OS 5 compatibility... However it turns out Jeffrey had left these in for QTM's Arm2-specific code, which included the Arm2/250 DMA handler... dooh! Simply removing the 'S' and '^'s brought Arthur OS compatibility to QTM
I'll be sending round this for testing soon - probably at the weekend.
Steve