Thanks Ian and Derek,

No need. I figured out what byte 4091 is for. This byte represents the "FROM TABLE" button you press when in the P-PRO mode. The upper four bits, otherwise known as a nibble, represent the device code. The lower nibble is always zero.

What is the current knowledge regarding macro crashes please? Would someone give me a summary or a link. I think I found out what the problem is and how to fix it. I have tried the fix and haven't had any crashes since.

Fixing it involved modifying a file on my PC and then writing it back, after correcting the checksum. I have actually copied macros from one area to another, on the PC, and successfully downloaded them to the MX. Looks pretty good for doing whatever we want. I even figured out that we might be able to add an extra keystroke into the "hidden" 3903-3977 slot. Although there would be no button that would operate it you could operate it from a macro. However this could only by done by editting the file on the PC. In this way you could add the CH+ or PAUSE key to a macro if you really need them. I'll try it later and let you know.

For the device memories there is one byte left to figure out for sure and that is 0002. I think 3903-3977 and 4052-4090 are spare. Derek and I have figured out every byte in the label table except spare ones (about 1650) and of course byte 2. I'll post more on that later.

Mike

Hi Mike,

I found late last night that I had a device I never programmed, but the default didn't match. I was glad to see that you had already figured it out.

As far as byte 2 goes, I think it is an id used by the mx-500 to tell it what device the next 4093 bytes are for. For example, it could be used as an offest in memory or flash. Have you ever seen these values change?

An interesting test would be to change the id in the tv device to 0x70, upload only the tv device to the remote and see if the tv functions are copied to the vcr1 device buttons.

Derek

I just stumbled onto this thread, like most and all I have to say is WOW! Okay, I have a little more to say than just that.

Mike, if you can figure out the format of these files and help me understand I'm pretty sure I could create a web based system for modifying these files and spiting out a new. The way I see it someone uses your hardware and software to generate a "myconfig.all" file. They then upload that file to a web application and through some coding I could, with a little kicking present an Interface that allows them to edit their file. As I understand I might even be able to let people share IR codes etc using this.

I don't have the most free time in the world but I'm sure I could devote some to writing a web application to collect and modify the files that your your work has been able to generate. A database and some PHP and I'm sure I could figure out the back end. I just need a better understanding as to what I am looking at in these files when I see all the hex codes.

Cheers,

Paul

Way cool! Glad I didn't sell my MX-500 yet after getting the MX-700. I don't regret buying the 700...but if we really get to tinker with the 500...all the more fun! If you guys by any chance need another MX-500 for whatever testing, I'd be happy to send you mine as a loaner.

Nice work guys!




This message was edited by Arjen on 07/30/02 22:04.51.

I figured out the final, elusive byte 0002 tonight. It identifies the memory block that the data is destined for. In this regard it must match the code that is used to identify which memory block the MX is receiving to. It must be exactly 80 plus 16 times the memory block. If it is not then the MX responds with FAILD at the end of the cloning process. For example if I use the code A0 then byte 0002 must equal 96. If I use the code A5 then 0002 must be 160. The only difference is if I use the ALL command then byte 0002 must be 80 as that is written to emory block 0. If I change this byte from say 96 (A0) to 112 (A1) and actually change the clone command to A1 from A0 then the cloning process works. I am sorry this is a very clumsy description.

Basically byte 2 must match the memory block you are cloning to else the cloning fails.

I also copied a learned key into the "Hidden Key" location that I mentioned last night and used it in a macro. The results were mixed. The macro did send out the CH+ command for my VCR, as intended, but it also commanded it into high speed rewind which was not expected.

Thanks for all the offers for a second MX-500 but at this stage it isn't required. There was one time when I could have used one but that was solved by a trip to Good Guys to use their demo unit in the store.

Now I must get on with finalizing the hardware and software and getting you guys something you can use.

I'll keep in touch and get you a schedule when I can.

Mike

Wouldn't a standard desktop app be superior for this? I think I'd much prefer a VB app where I can see a representation of the remote and call-outs showing what each button is assigned with, etc. Then I could load in macros and such from files I download from the net or get from another user in e-mail. I can then also take my time and work with a really nice offline interface and not have to worry about my connection going down, etc.

This message was edited by Rich Heimlich on 07/31/02 11:57.36.

Hi All,
I have started writing a app (standard windows app) for programming the MX500 based on Mike's data.

Should have something to post within a week or so depending on my free time.

Hope I'm not duplicating someone else's effort.

Will keep in touch.
-Dave

Dave,

That sounds great, thanks. Derek has agreed to create an "official" memory map and description of what the bytes do. He's already working on it. I have posted a file called ALL-1comp.xls which was a work in prgress type file to help with understanding the memory map and how some of the bytes work. I don't want to take time to explain it so the best thing may be to read and try to understand the Excel formulae, particularly in column P for the macros. One thing to note is that with an ALL file the last 5 bytes of each block are overwritten to 255 or FF. These bytes contain the P-PRO FROM TABLE, device code and punch-throughs. These bytes are therefore duplicated in the label table as shown.

That was a clumsy description for byte 2 on my part
and I may have got it wrong. So I'll give it another
try. There are 11 4096 byte memory blocks. The label
table is in block 0 and byte 2 must be 80 (decimal).
The next block is TV (from memory) and is sent with
code A0. It's byte 2 should be 96, the next is VCR1
and its byte 2 should be 112, and so on. I think that
the formula I gave was correct but the code number
wasn't. The code number is one less than the memory
block number, i.e code A0 belongs with memory block 1.

I hope this is better. If you look at byte 2 in one of
the ALL files you'll see the progression for each of
the 11 memory blocks. If byte 2 doesn't match what's
shown, irrespective of what else you send the download
will fail.

Mike

Mike -- Just found this thread (my MX-500 is coming from Scott Middleton). WOW -- You have really made progress. I doubt that HTM will give much help - they want to sell MX-700's!! This thread is now the first thing I read each day. Thank you!!

Craig

I think both methods are valid. With an online system it tends to be easier to add features etc. However you are right, it depends on your Internet connection. Assuming a small program cab be written to send the IR codes to the MX-500 then a web based system has much more flexability. All codes are kept in the database and you have instand access to the codes for whatever device you want. No need to wait for a friend or anything. Perhaps a combination of the two is in order? A central repository that gets queried for codes etc. Much like CDDB gets checked for CD Songs and albums except for IR codes. :) The Widows application can then use those codes by simply downloading them if you connected to the net.

Paul

Sending the codes to the Windows based app from the web is the way I think it should work.

The app should be the main tool. The website would be the IR code repository.

IMHO!

G.

I agree with the mix though getting updated codes on the desktop would not be a big deal. We develop such apps that interact with online sources every day. Our databases are HUGE Oracle repositories. I can't imagine IR data ever getting all that large.

What I would like is a system (web or app) that will allow me complete control over labels, codes, and their location on the MX-500. My suggestion would be a web repository for all the known codes and then an local application so I could design the exact configuration before I download it to my MX-500.

I have some experience with both web and local application development as well as hardware development and production. I was also just laid off and will unemployed starting this Friday so I have some time to contribute. If you want some help or suggestions, email me.

Uh huh!!! :-)

Oh sorry - I should have said "I agree with Greg" - my bad ;-)

Make the app in Java so it can be cross-platform on Linux, Mac, and Windows - there, that is something new...