Nobody really had any information on the topic so I figured i'd help some people out by posting a thread about the offseting hex addresses, and in the meantime beating the **** out of a dead horse as you will soon see.

When programming a chip you need to know a little about bits, bytes, and hexidemal numbers. Before we begin let us start with the two of the chips we commonly use: we have the Atmel 29C256 and the 27SF512. First question is, how do we know how much memory space there is on these chips. This usually is the case but not always, we take a look at the last digits. The numbers 256 and 512. Manufacturers use these numbers to tell us the amount of capacity in their chips using kb(kilo bits). Well WTF!?!?!!111 is that you ask. It's be very simple. In the metric system 1 kilo of anything is 1,000. The nearest binary number to 1000 is 2^10 = 1024 which = 1kilo bit. These day we use 'Kibi' instead of 'kilo', for binary prefixes to reduce confusion. I will too so you don't get confused.

Now that we know the 'hidden' meaning of the numbers we can convert our chips into something we commonly relate to...'Bytes' We first take our 256kb or (512kb) and divide them by 8. (because there are 8 bits in a Byte) We get 32kB and (64kB). If convert our capacity into straight Bytes we simply multiply our 32 and 64 by 1024 because remember that that is our binary prefix for kibi we end up with 32768 Bytes and (65536 Bytes). We now have the capacity of our chips(whew!)

Now if we are using a .bin file that doesn't completely use up all of the partitioned space on our chip, we need to offset the addresses that our chip gets written to correctly. First we find out how much space our .bin file takes up. We find out that it's 4k (or 8k or 16k or 32k) but ours for now is 4kB(not the space .bin for uberdata takes up which is 32kBytes or 256kbits). Now we need to convert that number 4kBytes into a hexidecimal number because that's what our burninging program reads and MAINLY that is what the "storage bins" in our chip are labeled with, is an address in hex. We use the calculator method to put our numbers into hex. Take 4kB * 1024 = 4096 Bytes. We convert this number by dividing by 16 and finding the remainer. Right now our number starts at 1, but we need our number to start at 0 because that's where our address starts(if someone can explain this better please do), so we subtract 1 and get 4095(which is still 4096 numers counting the 0 as a number). Hex ---> 4095/16 = 255.9375. Multiply .9375 * 16 to get our remainder = 15. 15 in hex is 'F'. So our first digit is an F. Next take 255/16 = 15.9375. Multiply .9375 * 16 we get 15. So we get an F in the second digit. F(2)F(1) Next we see that 15<16 and all we are left over with is another F so we place it in the third digit F(3)F(2)F(1st). We now set our buffer(file space) as 000FFF

Now we need the offset. Max space on our chips are 256kB and (64kB). We take the max space (converting to hex). = 007FFF which is our 'END'. We now need to figure out where we start. Since the information gets burned starting from the offset address to the final 'END' one. We need to offset the addresses that get burned so that it finished on the Last Address possible. 32kB-4kB= 28 kibi Bytes. This is where our offest will be. 28 * 1024 = 28672 Bytes. We don't need to subtract one because this is our starting point which acts like starting at 0.(can someone explain this better?) 28676 diving by 16's we get remainders of 0, 0 , 0 then we end up with a 7<16 so that's our final digit. 007000 and this is where our offset begins. So we burn from the addresses 007000 - 007FFF.

So. All that ****. I took the long way, but if you can think about it in a simpler way. More power to ya. BTW it's pretty easy if you think about it. I thought i'd put it where everyone could see it. And I like beating the **** out of dead horsies.




Modified by V8MeatHead at 9:53 PM 5/10/2005

 

Also if anyone wants to add anything or correct me or knows better. Please correct me.

 

cool! Sounds good! Nice write up