Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[copse]

Thanks bruceuncle.

It'd be so much easier if it were possible to enter macros by the function names, doing the hand menu selection with error conditions is clumsy at best.

I need to figure out how to get WinUAE/Workbench31 to be a higher resolution.  As it is, I'm just using the highest native resolution and can only fit so many lines in resource on the screen.

[copse]

Hmm.  Someone over at EAB pointed out that my macro can be replaced by I think it was:

go to base address in file
press shift+ctrl+alt+1
go to a line and hit ctrl+1

And that's it!

[bruceuncle]

Hmm.  Someone over at EAB pointed out that my macro can be replaced by I think it was:

go to base address in file
press shift+ctrl+alt+1
go to a line and hit ctrl+1

And that's it!

That's why it's a good idea to learn a few keyboard shortcuts  .
The main problem I found with Resource is that there's so much to learn! 
I still haven't managed to get to my PC yet (it's school holidays here and I keep getting diverted with visitors, etc).  I gave up with Tapatalk so I'm typing this through a 'keyhole' again  .
Have you found the stuff I put in the AMOS Pro extensions zip yet?  There's a copy-and-paste file of the macro commands there.  I have it open alongside the macro I'm editing. That's why I use 1280 x 1024 workbench for this stuff.  That file has been corrected, so ignore the one in the macros docs.  The 'repeat' instructions have an "x" embedded in them so you don't forget to put the number of repeats in (the assembler will chuck it out).
Read the docs on ShowMacros and ShowKeys (I think they're the right names).  It's a pity that the only way to get the sources out is to do the whole lot in one file.
There's a gotcha where you want to strip the binary from an assembled macro using Resource itself.  Each macro binary MUST end in a single zero word.  But Amiga load files are in multiples of long words.  So 50% of the time you get two words and the macro won't load properly (you'll get a screen 'beep').  When that happens, it corrupts the macros file.  Which is a pain if you just saved it!  The solution is to set the start and end and use a partial binary save.
The smartphone is getting mighty sluggish so I'll leave it a that for now.

[copse]

I haven't found your amos attachment.  Most of what you're saying requires me to learn more.

I'm currently going over the data structures in Resource looking for offsets.  Once that's done I'll try and export the asm and assemble and run it.  If it's stable, then that's a start and the tools can be a next step later on.

[bruceuncle]

I haven't found your amos attachment.  Most of what you're saying requires me to learn more.

Sorry for the delay copse, I had to take some enforced downtime.
I hadn't realised that you didn't have the Resource stuff used for the AMOS Extension libraries.  It's AMOS_Extns.rar and the post is here.  Manuals and docs are in the resource_install folder.  Other docs have a ".asc" extension and are in the root folder.
I keep updating the file of macro codes I use when writing them, so there's the latest copy attached.
I should be able to post more frequently now, although I won't be fully back in action for a few months yet  .  Good luck!

I'm currently going over the data structures in Resource looking for offsets.  Once that's done I'll try and export the asm and assemble and run it.  If it's stable, then that's a start and the tools can be a next step later on.

If you can track down how the help text is printed to screen, then the help files can be fixed.  There appears to be an assumption that any link in the help always has an (assumed) new line at its end.  This seems to be clashing with the embedded new line characters in the text.  The result is the mess you see on screen (try looking at help on macros for an example).  I was hoping that the problem was just a mistake in the help library data.  But the code needs to be tracked down and that's when I stopped any further work.  I'd already got the help text out and produced the Resource_V6_06_Help_Text.pdf manual, so I left it at that for the time being.

[Bit]

If there's anything important bringing both sources together, it would be a thing like the #define in C for constants (and other things)
i.e.
#ifdef XTENDED
  #define NPCVITALITY  10
  #define USEREGA0A4  A4
  #define MOVEBW        move.w
#else
  #define NPCVITALITY  7
  #define USEREGA0A4  A0
  #define MOVEBW        move.b
#endif

In some parts of the code another temporary register is used, in that case A4 for the extended levels, and A0 for the normal game.
By such defines large pieces of the code can be matched and are well readable and compilable.
Another silly difference is adda.w 10, A0 in normal mode, lea 10(a0),a0 in xtended...

[bruceuncle]

Resource uses symbol libraries.  Very easy to put together as they're just lists of symbols and their values.  Let me know what they are for the A4 offsets and I can put one together and apply it to the disassembly.  I used them extensively in the AMOS extensions disassemblies.
Good luck for Wednesday 😉

[Hungry Horace]

Resource uses symbol libraries.  Very easy to put together as they're just lists of symbols and their values.  Let me know what they are for the A4 offsets and I can put one together and apply it to the disassembly.  I used them extensively in the AMOS extensions disassemblies.
Good luck for Wednesday 😉

See thread "Champion Data (BW)" :  http://www.ultimateamiga.co.uk/index.php/topic,9736.msg46373.html#msg46373

... it seems we have cross-over of information being discussed!

There's a few key data-sets i've identied, and i'll try and get the full definitions into the revelant posts in the general Hacking Resource thread.  (You can see a couple of links in that post already)

Certainly the one for "Champion Data" - that defines strength, agility, level etc is commonly used, any time "CharacterStats" is linked to (*usually* in A4)


On a related matter.....

Removing Excess Labels

Did you see my post above about how to define 'offset' address labels? I still don't know how to do this, perhaps via an EQU ?  This would actually remove a number of unwanted labels, and allow us to pack more data blocks up via INCBIN "filename.data" or "filename.graphics" in the final source.


I ask , as this is coming up more and more as i look to put meaningful labels in.


Let me give an example.  There is a label called "PocketContents" - which is a clearly defined datablock for all of the objects held by all 16 champions at any one point. As such it's a 16 * $10 datablock ($100 bytes)

The PocketContents label is therefore referred to in 13 lines of code. Unsurprisingly these are usually something like:    

Code: [Select]

adrJA005170
MOVEQ #0,D0
MOVE.B (adrB_00EE3E).L,D0
ASL.W #4,D0
LEA (PocketContents).L,A0
ADDA.W D0,A0
MOVEQ #0,D0
MOVE.B (A0),D1
CMPI.B #$1B,D1
BCS.B adrCd005192
CMPI.B #$3F,D1
BCS.B adrCd0051A4
adrCd005192
MOVE.B (1,A0),D1
MOVEQ #1,D0
CMPI.B #$1B,D1
BCS.B adrCd0051CE
CMPI.B #$3F,D1
BCC.B adrCd0051CE
This allows the code to skip to the correct Champion's Pockets and start using (A0) and (1,A0) etc to read what is in left hand (A0) and right hand (1,A0)


Now... the currently worn Armour can be checked by looking at (2,A0) .... however, in one instance(!!!) in a routine starting at adrCd00A744, for some reason we jump directly to a label called 'ArmourWorn'

 

Code: [Select]

LEA (ArmourWorn).L,A0
The label itself, is meaningless, because it is effectively (2,PocketContents)... and the routine will also need to add $20 * X to the address, to reach it's 'actual' destination.

Unfortunatley, (2,PocketContents) is not permitted by DevPac, but I guess there must be a way of defining / reaching it, allowing us to change that one instruction. It will also then allow us to take the entire pocket-contents datablock, and replace it with an INCBIN "filename.data".

This technique is used a lot in the graphics sets, which obviously we want to avoid in the final ASM file, in order to include the graphics as individual files!

in my identification spreadsheet for new labels, i am putting yellow highlights on any labels i suspect need removing/replacing for whatever method avoids this.


Any thoughts on how we get to this end-goal??

[Hungry Horace]

Removing Excess Labels

Did you see my post above about how to define 'offset' address labels? I still don't know how to do this, perhaps via an EQU ?  This would actually remove a number of unwanted labels, and allow us to pack more data blocks up via INCBIN "filename.data" or "filename.graphics" in the final source.


I ask , as this is coming up more and more as i look to put meaningful labels in.

....
This technique is used a lot in the graphics sets, which obviously we want to avoid in the final ASM file, in order to include the graphics as individual files!

in my identification spreadsheet for new labels, i am putting yellow highlights on any labels i suspect need removing/replacing for whatever method avoids this.


Any thoughts on how we get to this end-goal??

I think i might have an answer that works in DevPac now

Here is some original code in Playsound routine:

Code: [Select]

asl.w #$02,d0 ;E540
lea AudioSample_1.l,a0 ;41F900054422
add.w adrW_008938(pc,d0.w),a0 ;D0FB005E
move.w adrW_00893A(pc,d0.w),d0 ;303B005C

d0 is used to determine which sample we want to play. To do this is needs two figures, the offset at which the Sample data starts, and the playback speed. These are stored as consective values in a lookup table which starts at adrW_008938.

Because of the way it takes two items of data at once, the code acts as if there are 2 labels. adrW_008938 and adrW_00893A

However. I believe the code should be swapped out for the following, which removes an entire label from our code:

Code: [Select]

add.w adrW_008938(pc,d0.w),a0 ;D0FB005E
move.w adrW_008938+2(pc,d0.w),d0 ;303B005C
This seems to compile up just fine, so i suspect there are quite a few more of these to come.

I guess i'll need to know how to put these into Resource, if that is the case.

In looking at this routine, i've noticed your new code has put in some extra labels in AudioSample_1-5, but i dont think these are right tbh. I suspect you have taken them as offsets relative to AudioSample_1, but that they actual relate to playback speed. I'm going to go verify this now!