RomRaider

Ok im trying to jump back into learning how to disassemble this stuff and I have a couple questions. I have tried googling this stuff and ive looked through the hc16 software manual but I cant find any info on these questions.


1. Figured it out


2. Figured it out


3. How are tables stored and how do I read them? Also how are values retrieved from the table by the code?


4. How do I find the main program loop? Is there a section that is first executed that just starts calling subroutines?

bump

Ok I figured out 1 and 2 after a lot of reading about bitwise stuff. Still wondering about 3 and 4?

There's a bunch of information in the main "getting started" thread about how tables are stored in memory. Probably too much, actually, since I think I can merge a bunch of the 16-bit and 32-bit stuff.

I still don't actually know if there's a main loop or just an interrupt handler that gets fired periodically. Every time I start working my way up the call stack, I get distracted by something shiny. If you want to try to find one, pick a few pieces of code that you know must be getting called frequently (like where load gets calculated, where the rev limiter gets checked, etc) and follow references to those functions, and the references to the functions that call them, and so on, until you bottom out.

I think the 32bit may be a lot different than the 16bit stuff. Or maybe I just didnt understand what you were describing in your thread. Im working with the 16bit stuff right now and it seems a bit less documented


Its probably a good thing nobody responded earlier to this thread, I learned a lot of things in the past couple days by just digging through everything. I found that when a table lookup occurs, index Y is loaded with the address that is 1 byte above the actual table. Then a subroutine(different one for 2D or 3D) is called and the result is stored. It looks like there are two bytes above a table that are important, the first byte is the column(x axis) count minus 1. The second seems to be a table type identifier?


I do have a question on something else though. How does a borrow work? I came across the opcode nege(negate e) and started learning about negative handling and, although im still a bit confused, two's complements. The only way I could think of this is that when you subtract something that is larger then you have to borrow, when you borrow you are borrowing a value of FF? The only way I could get it to work mathematically is consider a borrow a value of 256, then add the borrow to the original value and then subtract.

So 0A - 0C (10 - 12 = -2)
condition requires borrow
10+256 = 266
266 - 12 = 254(FE)
Two's complement of -2 is FE

But I cant %100 grasp why the borrow is 256 and not 255, I have theory's but I would like a definite answer. Or maybe im looking at this completely wrong? And how does the system recognize that this is now a negative number?


I also think I have come to a point where I need to start learning about the different data types and how they are handled. I understand what signed or unsigned means but I have no idea how they are identified or used. Ive also heard the term float which I need to learn about. Any good resources/reading material on this subject?



Also whats up with the bit shift left/right? This seems like it would completely corrupt the data that you are handling? For instance, this is in the speed density rom, it seems like this would completely render the data in ACC E and ACC D useless. It seems like its somehow transferring bits from E to D via the carry bit?

I can't really help with the 16bit stuff as I've never opened a ROM. You'll have to spend time reading the
Board index » RomRaider » ECU Analysis forum. I'd start with the first threads posted an work to the current time to gain some knowledge. Also there's stuff on the openecu forum site too.

Good Luck

Ive read through the ecu analysis forum and openecu, there really isn't a lot of information on 16bit stuff surprisingly. I think im going to go through everything again though, now that I understand things a little better I might be able to find things that I previously overlooked.


I understand the borrowing stuff now, I just had to do a little reading and pound the fact that hex is base16 into my head. Its hard to adjust when ive been thinking in base10 my entire life.

I also understand what is happening in the code I posted. Its basically shifting the data 8bits to the right, which is required because it needs to fit the value into a word. This reduces resolution though, and it took me a bit to understand how the resolution is affected and that shifting 8 bits right is the same data but with less resolution and requires a different multiplier to convert to real data.



I think my next hurdle will be understanding signed unsigned and all the other data types. Then after that, im going to figure out how the stack/stack pointer works.

I should clarify - yesterday I integrated a bunch of 16-bit information, courtesy of elevenpoint7five. There's lot more 16-bit stuff in there right now than there was 24 hours ago.



Yes, and today there's some information in the getting-started thread about what those type bytes mean.



Imagine using decimal notation and being limited to one digit (and no sign) so you can only really represent 0-9. If you wanted to calculate 8 - 9, you'd borrow 10, yielding an intermediate calculation of 18-9, finally yielding 9. Which looks weird, but consider that if you decrement from 0 in this system, you'd end up with 9. So, 9 is how you'd represent -1 in this system. It's just like using 0xFF for -1 (and 0xFE for -2) in 8-bit binary.

Borrowing 10 and borrowing 256 are similar in that each value is 1 greater than you can represent using the number of digits (or bits (binary digits)) in your inputs and outputs. In other words, it's what you get when you add a digit (or bit).

If I remember correctly from classes long ago, you can build CPUs that use 255 for the borrow, and that's ones-complement. It's even less intuitive to work with, though.



It doesn't. This is a common source of bugs. If you're a software developer writing code for a 16-bit processor, you have to be mindful of the fact that signed values can only range between -32,769 and +32,767. For example: 20,000 + 20,000 = 7,233 = surprising behavior from your code. But as long as your values stay within the allowed range, and you check for underflows and overflows, everything works fine.



Think of "signed" and "unsigned" as rules for doing arithmetic. The software developer chooses one or the other depending on the tradeoffs. If negative numbers are expected, signed values are used, and you get the -32,769 and +32,767 range I mentioned earlier. If negative numbers are NOT expected, unsigned values are used, and you a usable range of 0-65,536.

"Float" is shorthand for "floating point" and it refers to the fact that the decimal point can float around in the number. I never realized how silly that sounds until just now. But it's true:

http://en.wikipedia.org/wiki/Floating_point

And of course, in binary it's not called a decimal point...



Bit-shifting often does carry the topmost bit like that (I think it's universal, but it could vary by CPU). Shifting left is equivalent to multiplying by two, and on CPUs without fast math, it's common to fabricate multiplication operations from shifts and adds. For example, shifting left twice and adding the original number is equivalent to multiplying by five.

Ok cool, that helps a lot with the table data types and everything. Do you guys actually understand what the heck goes on in the 2D or 3D table lookup subroutines? I tried going through them to see how the data is acquired and manipulated but they are very complicated.




Ok I think this makes sense now. Does the two's complement system work on the principal that that byte will overflow? So just as -3 + 5 = 2, then FD + 5 = 2 will overflow the byte after adding 3 and then the remainder is 2?




I had read something about the MSB determining the "sign", how does that come into play? And is a "signed" "unsigned" value actually different in the code or is it just the way you look at it?