ROM disassembly as raw text file
Jun 18, 2015, 10:27 PM
#226
Evolving Member
Thanks!
I couldn't have done it without looking at your patch and all the info you put in this thread!I have an idea how to do the stationary rev limiter and how to better do the normal rev limiter control.
If all goes well i'll be releasing it to the public and I'll post a binutils objdump with comments so other can learn as I did
Jun 19, 2015, 10:25 PM
#227
Evolving Member
Patch should be good to go, just need some others to test and see how it works.
Here's a quick video Demo of it in action
Here's a quick video Demo of it in action
Last edited by franzcars; Sep 7, 2015 at 02:38 PM.
Jun 19, 2015, 11:05 PM
#229
Evolving Member
I'm using Rom# 59580004. The easiest way to find where I BL to is look at the MUT table for MUT2D, That's the dwell RAM address. If you put that address through your Calculator posted earlier and add 1, then search the number you'll find it where you need to branch just above it.
So in my case MUT2D is 80ab61, which when put in your calculator it gives you the value -5279, so add 1 to it and you get -5280. When you search that value or the hex you find this
So it should be very similar in other roms
So in my case MUT2D is 80ab61, which when put in your calculator it gives you the value -5279, so add 1 to it and you get -5280. When you search that value or the hex you find this
Code:
217d4: e0 05 85 aa ld24 r0,#0x585aa -Loads the Data from the Dwell table 217d8: fe 00 b2 74 bl 0x4e1a8 -Interpolates 217dc: 50 44 f0 00 slli r0,#0x4 || nop -Moves the data 217e0: fe 02 d2 08 bl 0xd6000 //Normally where it'd store the data, branches to my subroutine 217e4: 80 c0 ff ff and3 r0,r0,#0xffff 217e8: 50 04 f0 00 srli r0,#0x4 || nop 217ec: a0 2d eb 60 sth r0,@(-5280,fp)
Last edited by franzcars; Jun 19, 2015 at 11:13 PM.
Jun 20, 2015, 07:33 AM
#230
Evolved Member
Thread Starter
Sorry if this is a dumb question - I'm rusty - but shouldn't those register "pop from stack" ops be in reverse order to the register "push onto stack" ops?
Otherwise, what will go into the patch function in r0 will come back out in r8...? etc.
Rich
Otherwise, what will go into the patch function in r0 will come back out in r8...? etc.
Rich
Jun 20, 2015, 08:05 AM
#231
Evolving Member
Good point, this was my first time ever doing assembly and I had no idea that you had to keep it lined up like that. I will fix it in my patch asap. Thanks!
Jun 20, 2015, 08:39 AM
#232
Evolved Member
Thread Starter
Yeah, if you push registers onto the stack in order 0/1/2/3/4/5/6/7/8, your "pop" off the stack at the other end should be in order 8/7/6/5/4/3/2/1/0.
Your first time doing assembler looks a whole load better than mine, I'll say that!
Rich
Your first time doing assembler looks a whole load better than mine, I'll say that!
Rich
Jun 20, 2015, 07:12 PM
#234
Evolved Member
Thread Starter
Code:
217e8: 50 04 f0 00 srli r0,#0x4 || nop 217ec: a0 2d eb 60 sth r0,@(-5280,fp)
I've found the same bit of code in my ROM, and it looks like the lines above load data into a RAM location that isn't subsequently used by anything else... it's likely there for diagnostic purposes, so it can be watched.
And zooming out, nothing subsequent to the code in question cares about r0-r8 values... so no real-world impact in this particular case.
Jun 20, 2015, 07:44 PM
#235
Evolving Member
Yeah, I got very lucky that it was set up how it was, since my registers were not right, but that has now been fixed. Next question is, should I pop R0 back or leave it be? I think that if I pop it, it will show whatever Dwell would notmally be, not what it is. But If I dont pop it, I think it will show when the cut it enabled besides looking at that one ram address
Last edited by franzcars; Jun 20, 2015 at 11:04 PM.
Jun 21, 2015, 05:50 AM
#236
Evolved Member
Thread Starter
Yeah, I got very lucky that it was set up how it was, since my registers were not right, but that has now been fixed. Next question is, should I pop R0 back or leave it be? I think that if I pop it, it will show whatever Dwell would notmally be, not what it is. But If I dont pop it, I think it will show when the cut it enabled besides looking at that one ram address
Rich
Dec 29, 2016, 09:07 PM
#237
I saw JAMC perform, just a couple of years ago... on the post-Coachella-reunion glory tour. William didn't attack Jim (or us) with his mike stand, the band was tight, and they played out the entire set... but they were brilliant nonetheless. 
That perfect sound just washed over us, and for a little while we were all young, stupid and happy again. All hail the Reid brothers. A-hey-hey-heeeey....
But back to the task at hand! I've got objdump updated with the missing M32R definitions, and I'm happy enough with its assembler output.
I've attached my current build. There's also a readme in there, plus a wee shell script to run the tool a bit more easily.
Yeah, I know Linux isn't normally a "provide-a-binary" kind of world. Everyone normally rolls their own. If requested, I can always bundle up the few source mods I made (required to add support for the M32R "bclr", "bset" and "btst" opcodes). You can then stuff around with a full binutils v2.9.1 package download... if that floats your boat.
The attachment is tar.gz style. As it was 200KB and an EvoM-unspecified file type, I renamed it in a pleasantly dodgy way. Just rename it right back.
If you give it a try, let me know how it goes. Sure looks good on my Ubuntu laptop... and no more "*unknown*" opcodes...
Sweet!
Rich
That perfect sound just washed over us, and for a little while we were all young, stupid and happy again. All hail the Reid brothers. A-hey-hey-heeeey....But back to the task at hand! I've got objdump updated with the missing M32R definitions, and I'm happy enough with its assembler output.
I've attached my current build. There's also a readme in there, plus a wee shell script to run the tool a bit more easily.
Yeah, I know Linux isn't normally a "provide-a-binary" kind of world. Everyone normally rolls their own. If requested, I can always bundle up the few source mods I made (required to add support for the M32R "bclr", "bset" and "btst" opcodes). You can then stuff around with a full binutils v2.9.1 package download... if that floats your boat.
The attachment is tar.gz style. As it was 200KB and an EvoM-unspecified file type, I renamed it in a pleasantly dodgy way. Just rename it right back.
If you give it a try, let me know how it goes. Sure looks good on my Ubuntu laptop... and no more "*unknown*" opcodes...
Code:
b974: a0 bd c5 f0 lduh r0,@(-14864,fp)
b978: 01 f0 7c 04 btst #0x1,r0 -> bc 0xb988
b97c: e4 80 07 00 ld24 r4,#0x800700
b980: a5 74 00 00 bclr #0x5,@(0,r4)
b984: 7f 03 f0 00 bra 0xb990 || nop
b988: e4 80 07 00 ld24 r4,#0x800700
b98c: a5 64 00 00 bset #0x5,@(0,r4)
Rich
Dec 30, 2016, 07:17 PM
#238
Evolved Member
Thread Starter
This was based on the binutils version 2.9.1, which is ancient history these days.
My source edits are commented (look for "RJH"). You can also just download the old 2.9.1 sources and diff these three source files against their originals... and make the same edits in the latest version of binutils objdump.
Have fun with it!
Rich
Dec 30, 2016, 07:25 PM
#239
Evolved Member
Thread Starter
If I'm reading their source correctly, the current version of binutils (v2.27) has those instructions supported now, so there's honestly no need to go messing around with ancient v2.9 patches.
In their m32r-opc.h file, they have...
, M32R_INSN_MULWU1, M32R_INSN_MACLH1, M32R_INSN_SC, M32R_INSN_SNC
, M32R_INSN_CLRPSW, M32R_INSN_SETPSW, M32R_INSN_BSET, M32R_INSN_BCLR
, M32R_INSN_BTST
} CGEN_INSN_TYPE;
Those are the ones I had to add myself, way back in the neolithic age...
, M32R_INSN_TRAP, M32R_INSN_UNLOCK, M32R_INSN_PUSH, M32R_INSN_POP
, M32R_INSN_BTST /* RJH - Added new instruction July 8, 2011 */
, M32R_INSN_BCLR /* RJH - Added new instruction July 8, 2011 */
, M32R_INSN_BSET /* RJH - Added new instruction July 8, 2011 */
, M32R_INSN_MAX
} CGEN_INSN_TYPE;
So just go with the latest stock code. Have a great 2017!
Rich
In their m32r-opc.h file, they have...
, M32R_INSN_MULWU1, M32R_INSN_MACLH1, M32R_INSN_SC, M32R_INSN_SNC
, M32R_INSN_CLRPSW, M32R_INSN_SETPSW, M32R_INSN_BSET, M32R_INSN_BCLR
, M32R_INSN_BTST
} CGEN_INSN_TYPE;
Those are the ones I had to add myself, way back in the neolithic age...
, M32R_INSN_TRAP, M32R_INSN_UNLOCK, M32R_INSN_PUSH, M32R_INSN_POP
, M32R_INSN_BTST /* RJH - Added new instruction July 8, 2011 */
, M32R_INSN_BCLR /* RJH - Added new instruction July 8, 2011 */
, M32R_INSN_BSET /* RJH - Added new instruction July 8, 2011 */
, M32R_INSN_MAX
} CGEN_INSN_TYPE;
So just go with the latest stock code. Have a great 2017!
Rich