ADFFS 2.64

ADFFS 2.64 is now available for download

ADFFS will now run on low vector RISCOS 5 builds, with the caveat that not all supported games will work correctly. There’s also GUI’s to image floppies to ADF and JFD and most games that prompt for manual or wheel/chart based protection have had the protection prompt removed.

The following games are also now available for download:

Botkiller (1995) (Artex Software) (ARMv7 native)
Botkiller2 (1999) (Artex Software)
Omar Sharif's Bridge (1992) (Krisalis Software)
Premier Manager [SA version] (2000) (R-Comp Interactive) (not supported beyond StrongARM)

Botkiller (1995) (ARMv7 native)

Great, I loved that one!

Can Exodus be 32-bitted / ARMv7ed too?

Exodus is next on my list to make ARMv7 compatible, although from memory the Wimp front end is a problem as there’s no source code for it.

The big showstopper however is Digital Symphony Player which I’ve spent a lot of time over the past month trying to make 32bit compatible, I eMailed one of the BASS team who is still active online to get hold of the source code, but haven’t had a reply. Without the source it’s difficult to 32bit due to the sheer amount of self modifying code and high number of long ADR/STR/LDR.

Also looked at TimPlayer as a substitute, but it’s not capable of playing a specific start/end section of a track and doesn’t implement any of the DSym SWI/* commands so would be a lot of work to modify.

Exodus is next on my list to make ARMv7 compatible

That’s great news. I have to thank you for all this work, and Jan Klose for making them in the first place and allowing their release/update like this. :)

although from memory the Wimp front end is a problem as there’s no source code for it.

If I remember correctly, the Exodus WIMP front end was little more than an Iconbar icon with a Quit entry? It’s been a while though. :)

Also looked at TimPlayer as a substitute, but it’s not capable of playing a specific start/end section of a track and doesn’t implement any of the DSym SWI/* commands so would be a lot of work to modify.

Have you asked André Timmermans? Also, Steve Harrison mentioned “converter code … that covers Coconizer and DSymphony” on a Trackers we need to shim or upgrade thread on the JASPP forum.

I’ve now completed the ARMv7 conversion of Exodus, with the exception of DSymphonyPlayer.

Steve and I have had many conversations about shimming DSymphony player to QTM, but it’s not possible. Conversion also isn’t possible as one of the tracks uses delta compression, which the converter doesn’t support. Even if the tracks were to be converted, there’s still the issue of supporting playback of ranges within a track, which no tracker player currently supports.

I think I’ve just got to bite the bullet and manually convert the DSym Module.

I’ve now completed the ARMv7 conversion of Exodus, with the exception of DSymphonyPlayer.

That was quick! Shame there’s no easy way to handle the DSymphony files.

That was quick!

Until you consider I started Exodus four years ago! 🤔

DSymphonyPlayer is quite possibly the worst tracker to update, very few games use it and each game used a different version with differing features. Some games use the same version, but the code is completely different and half the games embed the Module in their code instead of RMLoading it in !Run.

And just to add more salt, from an ARM3 onward perspective the code is poorly implemented as there’s over 32Kb of unrolled loops. These need changing to partial unrolls, so they don’t cause excessive cache misses.

I was seriously contemplating writing a decompiler yesterday, that handles long LDR/STR (ADR followed by LDR/STR with an offset) as its probably going to be quicker than attempting to manually convert them to labeled references.

I was seriously contemplating writing a decompiler yesterday, that handles long LDR/STR (ADR followed by LDR/STR with an offset) as its probably going to be quicker than attempting to manually convert them to labeled references.

You could probably quite easily write a BASIC program (or similar) which you can feed in disassembly and have it do transformations like that for you. Should be a lot quicker than writing your own decompiler from scratch.

Or maybe try approaching druck to see if you can get access to the ARMalyser source code? (or if he’d be willing to open-source it)

I was seriously contemplating writing a decompiler yesterday, that handles long LDR/STR (ADR followed by LDR/STR with an offset) as its probably going to be quicker than attempting to manually convert them to labeled references.

There’s probably a reasonable amount of re-use potential, in which case the return on effort is probably more appealing.

Yes, a BASIC program was my thought. I need to essentially rewrite !Dissi, but with additional support for jump tables and long LDR/STR.

If I’m going to continue to ARMv7 convert games, a utility such as this is going to be essential.

try approaching druck to see if you can get access to the ARMalyser source code

I’ve emailed several times already but had no response, it’s a utility that I rely on quite a lot, but it has several bugs and annoyances that mean it can be painful to use, in some cases I can’t use it at all as it hangs whilst decompiling. I did want to look at fixing those issues several years ago.

!Dissi is the next most used tool, which has many bugs to the point that I try to avoid it unless absolutely necessary.

The third tool is !StrongEd, which crashes a lot with large dissassemblies, but is useful for quickly modifying code.

None do everything required to modify code, so invariably it’s a combination of all three and a lot of reloads due to them crashing.

The third tool is !StrongEd, which crashes a lot with large dissassemblies, but is useful for quickly modifying code.

If you could let me know which version of StrongED are you using, which mode and roughly the size of a large disassembly. It would also be helpful to know if it’s crashing on specific actions. Then I can do some testing to see if this can be fixed.

If you could let me know which version of StrongED are you using, which mode and roughly the size of a large disassembly. It would also be helpful to know if it’s crashing on specific actions. Then I can do some testing to see if this can be fixed.

Currently using 4.70a11 under RO3.71, but its occurred in all versions up to that build. There’s two crashes, both random:

1. Load a large text file (9mb will probably do) and randomly delete chunks of it…eventually it will crash. It’s very hard to repro when you want it to crash though. My guess is it’s going over some memory limit as it only occurs with large files.
2. Type and use the undo function and it will eventually crash, again near impossible to repro but guaranteed to occur when you really need to undo!

I’m assuming that you don’t have Aemulor or anything else loaded that’ll be clamping the max wimp slot size? I think that’s the only time I’ve seen problems when using large files (e.g. trying to save the disassembly of an entire ROM image would crash, due to the disassembly being over 28MB in size)

Load a large text file (9mb will probably do) and randomly delete chunks of it…eventually it will crash.

Thanks, I’ll play around with a file that size and see what happens.

You could check if StrongED is using a wimpslot or a dynamic area. On RO3.71 it would normally use a DA to avoid the limitation of a 28MB wimpslot. However the code still has signed CMPs on memory addresses in it so if the DA is located too high it can cause problems.

Set the variable StrongED$UseDA to 0 in the !Run file to force the use on a wimpslot (assuming the limitation isn’t a problem for you) and see if that fixes this type of crash.

Type and use the undo function and it will eventually crash,

Yes, the undo system has always been a bit temperamental. As you say it’s hard to repro which makes it hard to diagnose what the cause is.

the code still has signed CMPs on memory addresses in it so if the DA is located too high it can cause problems.

A naive question: if you know about them, why are they still there?

I’m not trying to embarrass you; I’m just interested to know what difficulties there are in the way of the solution.

A naive question: if you know about them, why are they still there?

Because removing them is boring stuff and most of the time there are more interesting things to do. Which means they are only removed when I notice them whilst working on a piece of code.

According to my notes I’ve removed them from 15 (out of 34) source files but the remaining files are generally the larger ones. A rough count shows that there are about a 1000 instructions, that use signed condition codes, left to check. I’d like to have this completed before a stable version of StrongED 4.70 is released.

With regard to audio modules shimming with TimPlayer 1.25, I did try to do some here bur there are some limitations which I tried to note down at the beginning of each’s project “c.module” file.

DSym as more than most, though most are probably not important.

• Limitations:
• - Loading from memory doesn’t alter that memory.
• - Loading to memory doesn’t alter that memory, TimPlayer use it’s own RMA/DA space.
• - Stereo info is used by fx, but not transmitted to songs.
• - SWI CutNote always return 0 for offset in sample.
• - SWI PlayInstr(Packed) effects are ignored.
• - Event position cannot be altered by TimPlayer.
• - SWIs Wait, IntState are not implemenet.
• - SWI NoteInfo, effects array is not filled in.
• - VU bar heights differs greatly from original.
• - Sample rate is ignored by Timplayer.
• - SWI TunInfo returns incorrect R1 + undocumented R2 to R5.
• - SWI PlaySingle is not implemented.
• - HardSpeed value is hardcoded and ignored by TimPlayer.
• - LoopType value is ignored by TimPlayer.
• - SWI FillAddress returns a pointer to a dummy function.
  This one though is a limitation I lifted but forgot to remove from the comments:
• - UpCallVector is never called (annoying for !XTreme demo).

Fred: thanks for the response.

With regard to audio modules shimming with TimPlayer 1.25

Does your shim implement *DSym PlaySingle along with the other commands you can pass it? This particular command takes Start and End parameters and plays just that section.

In the shim *DSym commands are passed to the corresponding SWIs just like in the original module but at the moment SWI PlaySingle does nothing due to lack of correspondance in TimPlayer.

As I finally managed to find some time and finished !KinoAmp 0.47 that was stuck in an half-finished state since summer of last year, I may start looking up to add the corresponding command to TimPlayer. Let me know if there are other features used by those games that are not implemented in the shim.

Also, regarding DSym if someone finds our what the undocumented values returned (or corrupted?) into R2-R6 by SWI TuneInfo, let me know.

code still has signed CMPs on memory addresses in it

I’ve been ARMv7 converting Wolfenstein 3D since last year, the amount of signed comparisons and shifts that should be unsigned is driving me nuts. There are thousands and every one ideally needs manually checking, so I feel your pain.

Suffice to say, getting the game to run on ARMv7 is proving a very slow and tedious process. It’s going to be impossible to check every signed test, there’s simply too many and in a lot of cases it’s unclear if the check should or shouldn’t be signed.

regarding DSym if someone finds our what the undocumented values returned (or corrupted?) into R2-R6 by SWI TuneInfo, let me know.

One of the BASS developers is attempting to locate the source code, which if found, will be hosted on JASPP. I’m not going to say I’m hopeful, as source code is exceedingly rare these days.

People using signed branches in ARM code when they should be unsigned is one of my pet peeves. Staggeringly there seem to be some that think that BGT is prettier than BHI so use it instead.
Mind numbing stupidity!

People using signed branches in ARM code when they should be unsigned is one of my pet peeves.

I share your pet peeve. I simply don’t understand why the fact that some things are unsigned isn’t obvious to everyone. No-one ever talks about a negative memory address.

You can’t have a negative file size either.
And yet…

I’ve been ARMv7 converting Wolfenstein 3D since last year, the amount of signed comparisons and shifts that should be unsigned is driving me nuts.

I don’t know much about the RISC OS port, but the MS-DOS original and other conversions I have seen were all written in C. So maybe it’s not entirely the programmer’s fault, but the compiler’s?

You can’t have a negative file size either. And yet…

And yet ANSI C ftell() function returns signed integer 8-) And it will most likely propagate into the compiled machine code.