MakeHex GUI

[vickyg2003]

Yamaha receivers use the NEC1 protocol, and recently some functions have 16 bits of data. Normally the second byte of data in NEC1 is the complement of the the first byte, but Yamaha now sometimes violates that "rule".

I don't know whether MakeHex would generate such a code or not.

I haven't worked with MakeHex, more than just take a look at this the last few days. I sure wish I had paid more attention as this has been very educational.

With the proper IRP you could create any signal you can define. If I remember correctly, the extended codes that decode as GAP on the Yamaha, just have one bit that doesn't flip, its always one. I think you'd just need a variation of the Nec1 Irp with the Form statement changed.

Nec1
Form=*,D:8,S:8,F:8,~F:8,_;*,_
I belieive you'd just change the form statement
Yamaha Variant
Form=*,D:8,S:8,F:8,~F:7,1:1,_;*._

Or would that be
Form=*,D:8,S:8,F:8,~F:7:1:7,1:1,_;*._

I'm never quite sure what to do in those situations where you need to trim down a field to fewer bits.

[3FG]

The particular signals which prompted you to write the Yamaha helper executor all had the characteristic that the first and second bytes added to 0x7F. But Yamaha documents several other 2 byte function codes which add to other numbers, so I think the straight-foward way to handle this from a Pronto Hex point of view is to treat the data as 16 bits.

However, it isn't clear to me what MakeHex would do if we specified NEC1, and filled in, for example, the function number 153.131.

[garyb.ncc]

I don't think that the two part function number was a feature that was ever completed.

... but I don't remember whether I finished that feature or tested it or ever had any use for it.

From my previous test I couldn't see a difference in the output for a two part function number versus a one part function. For instance for the example 3FG specified, the two part 153.131 function number yields the same output as the one part 153.

[vickyg2003]

The particular signals which prompted you to write the Yamaha helper exIecutor all had the characteristic that the first and second bytes added to 0x7F. But Yamaha documents several other 2 byte function codes which add to other numbers, so I think the straight-foward way to handle this from a Pronto Hex point of view is to treat the data as 16 bits.

If the pattern is more complicated than what we saw before, then we need someone with the decrypting skill (like Robman) to see if there is another pattern at work. I can push the protocols through in etch-a-sketch fashion, but I can't see the patterns.

However, it isn't clear to me what MakeHex would do if we specified NEC1, and filled in, for example, the function number 153.131.

I wouldn't expect it to work, because the "FORM" statement still only handles 8 bits per function. You can always try it and see.

[johnsfine]

However, it isn't clear to me what MakeHex would do if we specified NEC1, and filled in, for example, the function number 153.131.

I wouldn't expect it to work, because the "FORM" statement still only handles 8 bits per function. You can always try it and see.

1) There is no limit to 8 bits in F. So if you wanted F to be a 16 bit value such as 33689 (which is 153+256*131) you could set F to that and use all 16 bits of F in a FORM statement.

The file Denon-K.irp uses a 12 bit F.

2) Function=153.131 does not specify a 16 bit F.

Just as Device=26.98 is specifying an 8 bit D plus an 8 bit S; Function=153.131 specifies an 8 bit F=153 and an 8 bit N=131. D, S, F and N can all be used in FORM.

[vickyg2003]

1) There is no limit to 8 bits in F. So if you wanted F to be a 16 bit value such as 33689 (which is 153+256*131) you could set F to that and use all 16 bits of F in a FORM statement.

Yes, but there is an 8 bit limit to the function value if you chose NEC1 from the dropdown, right? You'd need to create a custom IRP file for the Yamaha.

[mdavej]

It seems like it would be simple enough to open the outfile for append after MakeHex has released it, move the file pointer to the first line, and add the protocol name as the first line in the file.

As far as the name of the outfile I generally like the standard MakeHex way of naming the outfile by protocol better; but it seems reasonable to me that in a GUI interface the user should have control over the name of the outfile.

Well adding the protocol info turned out to be a can of worms. I got it mostly working, but to make it bullet-proof, I have to add a bunch more code to make sure makehex is finished, deal with errors if makehex hangs, or errors out, etc. So I'm tabling that for now.

I can add the ability to change the output file name, but was trying to keep file management as simple as possible and limit it to a single canned file name. Plus I'd have to make sure the name typed in is valid, deal with prompting for overwriting existing files, etc., etc. I'll reconsider if I get some more requests for it.

[mdavej]

Got protocol info working. New version posted with protocol info in the first line, and MakeHex now runs hidden.

[garyb.ncc]

... I'd have to make sure the name typed in is valid, deal with prompting for overwriting existing files, etc., etc. I'll reconsider if I get some more requests for it.

This seem to be pretty straight forwarded and most of this work can be done with a canned save file dialog box. Such as:

Code: Select all

char filter[] = {"Text File (*.txt)|*.txt"};
CFileDialog saveHexFileDialog(FALSE,".txt",NULL,OFN_OVERWRITEPROMPT, filter);
if(saveHexFileDialog.DoModal() == IDOK){	
	if(saveHexFileDialog.GetFileName() != ""){
		//TO DO - add file handling code
		//simply open the file by specifying saveHexFileDialog.GetPathName() 
	}
}

Of course I can live with it the way it is.

[mdavej]

Thanks for the info. I've done that kind of thing before, but I'm just lazy. If I do that, I'll also want to read/write the last path from/to the registry, and so on. Plus I still don't see the point of saving a lot of different files. When I use makehex, I usually run it, paste the results elsewhere and delete my file. I never keep more than one hex file for very long. It would be interesting to see how/why most people use makehex.