[RoofusPennymore]

I have some files that are in "Intel Hex Format" that were generated by a PC. If I open them up in a text editor all I get is garbage. I want to write a program (in Real Basic) that can show me the true hex data (and other things) but I cannot figure out how to interpret the garbage to get the hex data out.

[parallax]

What garbage?

If it's something that remotely resembles

:238453984572985A23480BFC8230942E
:23470234DFAC
:2384098230984091834234059023945

then you should be fine -- that's the hex data with some address info.

Look up specs on the Intel Hex Format.

[iJed]

X86 is little endian. This is where the low byte comes before the high byte. Mac OS uses big endian (although I think that PPC is biendian). Here the low byte follows the high byte.

eg.

intel short 0A0B converts to moto short 0B0A
intel long 0A0B0C0D converts to moto long 0D0C0B0A

Easy to do in C, don't have a clue in real basic though.

[Millennium]

I think what he means by "garbage" is that it's getting opened as a text file, and the editor is trying to show the ASCII characters that correspond to the data. This would look like garbage.

It sounds like what he wants to write is something like HexEdit, but taking into account the little-endianness of the Intel architecture. Which HexEdit might be able to do anyway; I'm not certain of that.

[RoofusPennymore]

Originally posted by Millennium:
<STRONG>I think what he means by "garbage" is that it's getting opened as a text file, and the editor is trying to show the ASCII characters that correspond to the data. This would look like garbage.

It sounds like what he wants to write is something like HexEdit, but taking into account the little-endianness of the Intel architecture. Which HexEdit might be able to do anyway; I'm not certain of that.</STRONG>

Your correct. The data is the ASCII form of the data. I have used HexEdit but I need to come up with a custom app for this particular project. Since the equipment that generates this data is PC based I suspect it is little-endian. I'm guessing that I can convert the ASCII text to a number and convert that number to hex? RealBasic has the ability to take in account of the little endianness of it.

[petej]

The first link in Google that came up for "standard intel hex format" was this one:

http://www.8052.com/tutintel.htm

It's what you're looking for.

[RoofusPennymore]

Originally posted by petej:
<STRONG>The first link in Google that came up for "standard intel hex format" was this one:

http://www.8052.com/tutintel.htm

It's what you're looking for.</STRONG>

Thanks for the tip, it helps.

[RoofusPennymore]

Just to update what I have done. Apparently my Intel Hex Format files did not follow the format as I expect. But I was able to convert the ASCII into Hex by loading the entire file into memory and go one by one on each character and converting to hex(asc(chr)). No endian to worry about which is also weird but I got the same results as a PC.

[petej]

Intel Hex format was developed to be sent raw over a serial line to a PROM programmer. The checksums on each line helped make sure that the line was uncorrupted, and the addresses on the front of the lines were there to make sure you got all lines. If you received the file over some reliable transmission medium (like a CD, floppy, or TCP connection), you can safely ignore that stuff, since the transmission medium was designed to take care of all that for you. Endian issues would only affect the address and checksums, and not the byte data on the line, as you found out.

Glad it's working for you.

[benh57]

Originally posted by RoofusPennymore:
<STRONG>Just to update what I have done. Apparently my Intel Hex Format files did not follow the format as I expect. But I was able to convert the ASCII into Hex by loading the entire file into memory and go one by one on each character and converting to hex(asc(chr)). No endian to worry about which is also weird but I got the same results as a PC.</STRONG>

Er, if you open the file in binary mode it's hex already. If you have ascii chars of the file then your file open call has done the conversion from hex to ascii for you, and you are converting it back.

Dunno about realbasic, maybe it can't do that. It is extremely basic C programming.

-B

[absmiths]

Originally posted by benh57:
<STRONG>

Er, if you open the file in binary mode it's hex already. If you have ascii chars of the file then your file open call has done the conversion from hex to ascii for you, and you are converting it back.

Dunno about realbasic, maybe it can't do that. It is extremely basic C programming.

-B</STRONG>

I think what he is calling is a method to format data in HEX, not do some binary-ascii conversion. Especially when you consider that hex is not a data transmission mode, it is a numbering system. In that scenario a byte from a stream is certainly not "in hex format" it is in binary format and must be displayed as hex.

BTW, as has already been mentioned, endianness does NOT reorder the bytes in the file - it only comes into play when you try to convert groups of bytes into higher-order data types like 4-byte int, float, etc. The same file read on both systems will produce the same sequence of bytes, but it is up to you to interpret them.

[ 01-03-2002: Message edited by: absmiths ]

[ 01-03-2002: Message edited by: absmiths ]