Dead lucky you are Hungry Horace. Just after my last post, my PC expired with an impressive display of visual fireworks on screen and lots of worrying BSOD activity from Windows 7. My ageing GTX460 had expired. Shortly after that I totalled my smartphone
. As I still can't drive very far, I was reliant on postal deliveries for both, which went badly wrong on both counts and took ages and many phone calls. So I only got things back to normal (GTX960 and Lumia 640) just after your post. Far too long without any communication abilities!
- Compiling BEXT with barfly throws up hundreds of errors, but devpac only a few... traditionally i'm much more used to using BarFly for compiling.... what would be the cause of this ? (i appreciate this original BW resource needs more work) .... what can i do to fix it ? (i dont relally care what i end up compiling with, as long as it works!)
Resource uses the assembler syntax for either Assem or C.A.P.E.68k or Macro68. The Assem syntax seems to be the most compatible with Devpac (Genam). I don't know Barfly but would suspect it uses something slightly different for some instructions and is why you're getting heaps of errors (or warnings?).
With Devpac I got 7 errors:
One was a line of nonsense code just before an RTE - easily fixed.
One complained about:
SECTION xxxxx,CODE,CHIPDevpac uses:
SECTION xxxxx,CODE_Cso easy fixed.
The others complained about Resource using:
LINK.W #-offsetinstead of plain
LINK #-offsetI took the easy way out and turned off Strict Mnemonics. It would be better to edit the offending lines in the source as the assembler may use its default sizes if the *.B, *.W and *.L size specifiers disappear, thus upsetting the size of code and data blocks.
The only other line needed was:
ORG $0003A4to put the code into the correct memory location (puts GameStart at $000400).
I've attached the files in a zip. (Don't pay any attention to the numbering system, the 40 is arbitrary and the 3 indicates the original plus two attempts.)
- I've identified many many more data blocks (including graphics and soundfx) since this original resource. Would it help to have those to do this again? Can Resource be made to substitute a datablock with a simple INC "filename" instead, or can we only do this when we get to the .asm stage?
Can't be done in Resource without an awful lot of commenting lines out and commenting the INCBIN "filename" lines in.
Better done in the *.asm file.
Note that you can use the Partial Binary Save to save chunks of data. Set the Start on the line where the data block starts. Set the End as ONE LINE AFTER the data block ends. You've probably discovered this already
- Can my updated labels and comments be easily exported from my most recent .rs (attached) and put into a new resource of your original file, to better match what you did with BEXT?
Erm yes. With a bit of work. If you're talking about the same executable, the labels and their offsets can be written to a file with a Resource macro. Then use another macro to import them to the new *.rs file, using the offset to locate the cursor and the label to create the new one. Difficult to describe
. Will only work where the executables used for the *.rs files are identical.
I can redo the original to the same format as the BEXT_CLEAN one if you want. It's mainly a matter of using those macros with a bit of manual correction.
- there are some lines where fixed numbers are used, that should probably be declared (e.g. #ZendikCharacter should be used for #$40 in some locations) ... can we do this in Resource, or again, is this more for the .asm output?
Two ways to do it:
Use the Custom Bases (#1 and #2) under SYM to create them on the fly. But I think you lose them when Resource closes (must check that!).
Create Symbol Libraries. Not as hard as it looks. Just read the docs on Symbol Libraries. There's heaps of examples in the AMOS Extensions Disassembly stuff I did. The rules are that within each library, the symbol values must be unique (which is why you'll probably need more than one library - think of them as separate equates lists) and the values must be in ascending order. That last one is a gotcha if you're defining signed values as Resource treats them unsigned.
As much as I am liking how much i've managed to edit the game thanks to the resource, i must admit, coding patches and relocating code in memory is much much harder than it would be compared to simply re-compiling the game with my changes!
Too true. As far as I can see, you should be able to get a working executable out of the source. I haven't done a byte-for-byte comparison yet. Note that the code for Bloodwych commandeers the Amiga without any safeguards. Like relocating the code to $000400 and allocating a stack at a fixed address ($006000 from memory, may be wrong!). As all this is done outside of AmigaDOS, all hell could break lose if you tried it in any situation other then the WHDLoad one. It takes over the machine, aaargh!
I'll have a look at the original and the *.rs file you supplied and get back to you.
Author
Topic: Bloodwych Amiga Disassembly (Read 53358 times)