ADFFS 2.64
Pages: 1 2
Jon Abbott (1421) 2641 posts |
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) |
Michael Drake (88) 336 posts |
Great, I loved that one! Can Exodus be 32-bitted / ARMv7ed too? |
Jon Abbott (1421) 2641 posts |
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. |
Michael Drake (88) 336 posts |
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. :)
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. :)
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. |
Jon Abbott (1421) 2641 posts |
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. |
Michael Drake (88) 336 posts |
That was quick! Shame there’s no easy way to handle the DSymphony files. |
Jon Abbott (1421) 2641 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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) |
Steve Pampling (1551) 8155 posts |
There’s probably a reasonable amount of re-use potential, in which case the return on effort is probably more appealing. |
Jon Abbott (1421) 2641 posts |
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.
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. |
Fred Graute (114) 645 posts |
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. |
Jon Abbott (1421) 2641 posts |
Currently using 4.70a11 under RO3.71, but its occurred in all versions up to that build. There’s two crashes, both random:
|
Jeffrey Lee (213) 6048 posts |
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) |
Fred Graute (114) 645 posts |
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.
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. |
Dave Higton (1515) 3497 posts |
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. |
Fred Graute (114) 645 posts |
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. |
André Timmermans (100) 655 posts |
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.
|
Dave Higton (1515) 3497 posts |
Fred: thanks for the response. |
Jon Abbott (1421) 2641 posts |
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. |
André Timmermans (100) 655 posts |
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. |
Jon Abbott (1421) 2641 posts |
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.
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. |
Jeff Doggett (257) 234 posts |
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. |
Dave Higton (1515) 3497 posts |
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. |
Jeff Doggett (257) 234 posts |
You can’t have a negative file size either. |
Krzysztof Klis (2832) 36 posts |
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?
And yet ANSI C ftell() function returns signed integer 8-) And it will most likely propagate into the compiled machine code. |
Pages: 1 2