NefMoto

Trying to make revisions.  New to assembly.  Trying to write ROM 0x817E0A to RAM 0xFA40.

Ive gotten
F3 F9 0A 7E F7 F9 40 FA DB 00

or

movb rh4, 0x817E0A
movb 0xFA40, rh4
rest

Also looking for an idea for a place to look to make insertion point.  Am I on the right track?

ok.  So the issue i keep snagging myself on is in bit referencing.  At 0x8A3AE0, I want to do a simple jb  0xFA40, jump x words.  I cant seem to get the command to move outside of the FDxx Ram Locations.  Right now I have 8A 20 50 00 or jb 0xFD40, jump 5 words.  i have a feeling that this has to do with a ext command, but am not sure how to write the jump from the offset within 0xFDxx to be in 0xFAxx.  Could someone help me figure out which ext command will shift me down?

http://nefariousmotorsports.com/forum/index.php?topic=14265.msg115230#msg115230

You said you would read that. There IIRC you will find all you need about bit-addressable memory ranges, etc. But, to answer your question, the jb* instructions work only with a narrow range of addresses, not ext-s will do anything about that.

I'm reading it and rereading it and trying to understand it.  Im crossreferencing different areas of code.  Its helped with a lot of things.  I get a lot of the architecture and I understand how the directions are working.  Every item I see I reread that page and then tinker.  Jb and jbc seem to be the biggest one in the working with bits, most everything else is words and bytes.

So if I want to use RAM location bits as switches to enable and disable features I just need to keep it all in the 0xFDxx range?

No and the only thing you need to do to understand is to look at the original code.When you ask such questions i can only understand that you did not look at your own binary file enough or you did not define it.

Simple Ram locations that you can work with 0x38xxxx - 0xfdXX

To hook up (hijack) (redirect to your function) your routine you will need to think how fast you need it to run... 1ms 10ms 100ms.

find the tables with the call functions with 1-10-100 ms raster and hijack a function that is not so vital(at least that is my approach) .

Before you do all this things though, sit down and analyze some of the main functions of your sw and you will start to understand more and more.

You can bit address everything, just not everything directly. Typically, you copy the variable to a register and bit address the register. You can also bit mask a register and do jumps based on the contents of the flags in PSW, compilers typically produce code like this, probably not most optimal.

That was exactly what I needed.  Moved the RAM to the register, used jbc to reference register.  Now I can set bits in another register and then write it to the RAM.  Thank you so much.

Right now I'm not working on highjacking any function.  With my limited experience I'm trying to give myself proof of concept.  I'm just doing a ROM to RAM bit transfer.  Then using that RAM as a switch in the routine.  (I think I can just read this from ROM now)  I'm setting my routine to output another RAM value.  I'm going to be able to log that and confirm everything is working as it should and then start hijacking routines.

Been making great progress since seeing that last post.  Can't thank you enough for the help.  Just have one question.

I want to set a bit in a byte and move it back to ram.  What I've done write now is use words instead.

Mov r4, ZEROS
bset r4.1
Mov RAM location, r4

I just don't see a way to do bset rl4.1
Does bset always write to the low byte or the high byte?

If I could do that I could replace a lot of mov with Movb.  Also, am I really gaining anything?  By working in bytes instead of words do I just reduce ram usage or do I speed functionality?

All basic instructions are constant time as far as overall performance is concerned, this does not apply to (long) multiplication / division and such. So, one typically optimises for number of instructions / instruction length (to optimise fetch / space in flash).

I would advise care with byte instructions, one gets into a habit of having uneven addresses (like $FD03), but then missing on b part of the instruction doing "mov r4, mem" and depending on how clever your compiler / assembler is (or your brain when you do things by hand) you will end up in a trap interrupt and likely bricked ECU in effect.

Back to your concrete question, up to r6 you can access the whole word in the register with rX, or single bytes with rlX / rhX, but it is still the same register. So, if your RAM location is a byte, then:

mov r4, ZEROS
bset r4.1
movb RAM, rl4

(sets bit 1 in byte RAM). Equivalently (byte RAM will have bit 1 set):

mov r4, ZEROS
bset r4.9
movb RAM, rh4

And even:

movb rl4, #2
orb RAM, rl4

And while we are at it, "mov r4, ZEROS" is four bytes operation, while "mov r4, #0" is two ;)

I can go on like this forever, I suggest, again, to read the ST10 programming document (again).

Ive been reading it.  I remember reading about the cycles for multiplication and division.  I've been doing everything by looking at how the function works in other areas and redoing it.  Ive been using that information to edit the hex with a thorough reread each time for the instruction and then reload the file in the disassembled.

On further inspection I do have
Mov r5, #0
But got it E6 F5 00 00

So your saying I could do
Mov r5, #0
Through E0 05

Another entry level question, but just checking.  Do I have to reload data to a register every time I want to use it?  At the beginning of my routine I have a min and max temperature check. 

Extp #0e1h, #1
Movb rl4, tmotlin
Exts #81h, #1
Movb rh4, max_temp
Cmpb rl4, rh4
Jmpr cc_c, cw_reset
Exts #81h, #1
Movb rh4, min_temp
Cmpb rl4, rh4
Jmpr cc_nc, cw_reset

Do I need to reload tmotlin before running another cmpb?

I have what I want put together for my ram locations.  In trying to understand the Multimaps so I can make sense out of map switching routines.  I want to set it up where if 0xFA40 cc_nz I get an alternate map for lamfa, kfzw, and kfzw2.  Can I get any help?

First, $FA40 sounds suspiciously like the register area for one of the interrupts, I'd strongly suggest to verify that it is not used (just disassembly with IDA and direct reference use checking might not be sufficient, as these are typically referenced by pointer not value). In general it is a much better idea to place your things in the external RAM.

Then I suggest to some simpler code modification exercise first. You should get to a point with ST10 assembly and code analysis where solving the problem of multi maps comes to your head naturally. If you need (serious) help, the likely hood of messing this up (even with help) is very high.

I understand.  Illl get that moved.  I put it there when I was struggling with the jb referencing.

I figure this is going the entail a level of trial and error, which is fine as the car is not a daily and I can boot mode flash.

It seems like there's a 16 bit offset constant thats modified.  If I stare at this long enough ill figure it out.

So I took your advise and worked on some things.  For starters I moved my flags to the location 0x383900.  Basically, bit 0 is active during Launch Control, bit 1 is active during No Lift Shift.  Not really necessary to seperate them, but I have some revisions Im hoping to do it lays the groundwork for.  Since I ran into a wall with switching maps based on the status of those bits, i decided to disable knock recognition when those bits were active.  Its bit 0xFD70.14 in my file.  Its set at 0x72DAC and cleared at 0x72DB0.

0x872DAA     jmpr       cc_Z, loc_872DB0
0x872DAC     bset        b_kr.14                                         Replaced with call function
0x872DAE     jmpr       cc_UC, loc_872DB2                        Replaced with call function

0x872DB0     bclr         b_kr.14

0x872DB2      jnb        b_kr.14, loc_872DC8

I inserted a call function to 0x8A4000 replacing the bset and jmpr at 0x872DAC because the call function is a 16 bit and the 2 existing functions were 8 bit.  At 0x8A4000 i have the following:

0x8A4000      extp      #0E0, #1
0x8A4004      movb     rl4, B_alsflags
0x8A4008      cmpb     rl4, #0
0x8A400C      jmpr      cc_NZ, loc_8A4014
0x8A400E      bset       b_kr.14
0x8A4010      jmps      87h, loc _872DB2

0x8A4014      jmps       87h, loc_872DB0

I think I got it.  Call inserted to jump in blank space.  Reference to the flag inserted.  Completion of the function replaced with the call.  Return to program from both sides of the function. 

Now if someone could give me a pointer about pointers I would be eternally grateful.

ok.  Been tracing the disassembly to see what is going on in the map switching.  Following along pretty long til I hit the pointer which weve established I dont really know how it works.

code reads
extp    r5, #1
mov     r7, [r4]

my values for r5 and r4 at this point are r5=207 and r4=2BC
so im concluding that im moving the value located at 0x02BC on page 207 to register 7.  Page 204 is 0x810000 and page 205 is 0x814000.  Im assuming that page 206 is 0x818000 and that page 207 is 0x81A000.  That would mean placing the value im after at 0x81A2BC.  Yet that seems to be blank space in my file.  Do i need to recheck my math to arrive at those values or am I missing something else in this process?

Found my issue.  Was calculating the values using the flag for the new maps and the values for the stock maps.

Ok.  I have kfzw, kfzw2, and lamfa so far as als conditional maps now.  I have them as KFZWALS, KFZW2ALS, and the best one... LAMALS.  I also plan on adding LAMBTS to the mix.  I want to take timing to -30* in areas where im beyond the rpm threshold.  To do that I think I need to add KZFWMN and maybe KFZWMS to the mix.  Ive been able to find KFZWMS, but KFZWMN is more of a problem.  I have 2 variants in my file and nowhere do i see a constant that will point me towards them.  The maps are located at 0x81230C and 0x8123CC.  They output to the RAM variable zwmn.  I dont have a location for zwmn either.  So right now my options are edit KFZWMN over 4000 rpms and assume that I'll never have problems in standard operation, or get a hint on where to find it.  Im going to be posting a M-Box 2.7 and CH-Box 1.8 map here shortly.