Sorry that I started a new message thread, but this is not direct with the new program...here's my question:

If a user changes their user interface, then uploads it to Remote Central...will another user downloads it, will the SUI (static user interface) change...or will the og ones still be there. I would guess the later, which means that when we upload to Remote Central, we will also have to upload the .bmp files associated with this new program. Will this be an option when someone uploads their ccf???

I don't know, but I think this is perfect place for the Tonto Project to step in. Handled correctly, a user might not even need to know that he was updating the firmware at all. And the extra bitmaps could be stored in the CCF in some hidden panels with specific names.

If the difference is integral to the design then you most definitely need to send something in. I have not had the time to try it, but is it easy to use, or would it be better for newbies to have a moded firmware with the CCF

and in my opinion you should send the screen shots, so that Daniel does not need to update his emulator every time.

It is a troule to do new designes (.bmp sets) compatible with another device firmware:
The same images are lies at another # and name (see *.txt files, generated when extracting) at different firmwares :(

When replacing, I have no way to predict, to which place I need to place any image of ####.bmp set at another firmware :(

Really the best way is using DB of 2 tables:
{[image ID],[Button name]} and {[Firmware version],[image#],[image ID]} -

01, "Home icon"
02, "Macro icon"
....

RC5000i, 0090, 01
RC5000i, 0094, 02
RU940, 0012, 01
RU940, 0016, 02
....

to use this as image substitutions.

Who can spend own time to carefully comparing image sets of 11 current firmwares in order to develop cross-platform design?

Since Evgueni's tool generates both a Emulator.exe & a Firmware Update.exe, to really load up a "complete" design you would need these in addition to the .ccf.

The actual individual bitmaps by themselves don't make much sense, & they're all contained in either of the .exe's anyway. (Just like a .ccf contains all it's own bitmaps.)

The 9200 changes I did wouldn't be usable on a TSU-6000 or vice-versa. I doubt if they would even look good on a 5200 without the same color-to-grayscale issues as any .bmp.

Incapsulation of static graphics into CCF is a Greate Idea. Also, it is better to update Pronto and emulator (and fonts?) from one environment.

Problems are:
.CCF format is too different from one remote mark to another
.It not so comfortable to browse bitmap lists without image browser
.Same images are placed at emulators and firmwares by different order
.I have no experience to upload firmware segments other then via executing firmware updater

So, the only who can help us is Lord, or Pronto-Developer-Team, or STEWART ALLEN, the author of Tonto project!!! Let's ask him about!

Barry I agree with you but

1) there are many remotes that use a similar interface 1000,2000, 890, 940, RC5000, RC5000i, Rav 2000 and CHAD(I think) also 970,6000. so anyone might want to use the bitmaps but not the firmware

2) what happens when a new firmware comes out, firmware with bitmaps needs to be separated and the bitmaps need to be reloaded into the new firmware

3) isn't downloading uploading firmware a lot more bandwidth intensive instead of a few extra bitmaps?

these are the reasons that I think a discussion on the merits of both sides (icon VS CCF) is worth having

Evgueni: you gave us a great tool even if it might be a bit like Pandora's box :-). I think the proof is in the fact that there is a discussion on it, and that Daniel started a thread to announce it as soon as he published it.

Based on a serial snooper I built and information from Evgueni, I've added code to Tonto to dissect a firmware updater EXE and download the necessary segments to a Pronto. It's not enabled at this time because I haven't done enough testing. But it will allow firmware updating on any platform.

Extending this work to allow Tonto to edit Firmware images should not be terribly difficult. Tonto already has the image handling code. Even more intriguing is the possibility to visually edit animation scripts.

Firmware images contain 5 or 6 segments depending the model: BOOT, PSOS, _SYS, _APP, _CCF and _UDB. During the firmware update, only the segments that are out of date are sent. Since the images are stored sequentially on the firmware, if you update PSOS, for example, you need to re-send everything after it (except _UDB which is stored at the top of memory). This is why the firmware updater grabs your ccf before updating the firmware... it needs to re-download it after the _APP segment is sent.

In short, I can add firmware image editing code to Tonto giving us an all-in-one tool for editing CCF's and doing Firmware hacking.

BTW, I just released Tonto 1.10 into the wild. It is a great leap over previous releases. I've also included the source code for your amusement and edification.

I've asked Daniel on a number of occassions to add Tonto links to the download section, but I haven't heard back. Perhaps he requires more vocal user demand.

Evgueni, please email your new notes on the Firwmare structure so I can start to add image and script editing capabilities.

Anthony-

Yup, all good points... I don't know what will be the best way to pass around the firmware changes. Not quite as portable & universal as .ccf's.

Size does matter(?)... my 37 compressed bitmaps are only 278 kb vs. my 1.17 mb emulator.exe & my 2.03 mb firmware updater.exe. (BTW, I want to know which of my old girlfriends spilled the beans about my small "member"... I get 20 offers daily to "beef up" my beef.)

So yeah, the raw bitmaps are more compact, but then you have to try & figure what bitmaps go where and what the heck they do.

Advantages of trading emulator.exe and/or firmware updater.exe's:

1. You can run it to see the "big picture".
2. You don't have to understand how to run imgrep.
3. If you like it, but want to "fine-tune", you can run imgrep to extract the .bmp's to edit & then reload with your changes.

As far as different platforms:

1. I don't think the RC-9200 & TSU-6000 will share anything useful.

2. The RC-9200 firmware .bmp's could be used fairly easily with the RC-5200, with the same conversion limitations as any graphic... some things just flat don't look good converted.

3. The TSU-6000 hacks won't be useful for any other remotes!?

4. I've only extracted the RC-9200 so I'm clueless how much re-naming & editing will be required for the various grayscale models. I think the RAV & CHAD will be unique animals. Again, some stuff may be usable, but you may have to figure what bitmaps go where and what the heck they do.

Still thinking...

This message was edited by Barry Shaw on 07/03/02 16:07.27.

THAT would be slick!

All will be easier - nearby you will have a possibility to store static icons at CCF like you already can with "home" and "arrows" - with Tonto!

Hm.. 20 requests executed per day - good output!

Barry: I know the Pros for the firmware (actually I think I was the first to mention it on this board

|

as for the different platforms

from a system point of view (but not a firmware)

1) Pronto TS-1000, TSU-2000, RU-890, RU-940, Marantz RC-5000, RC-5000i are the same
(I am not sure if the Yamaha or CHAD use the same type of interface, but I think they do)

2) The ProntoPro TSU-970, TSU-6000 are the same

3) The Marantz RC-5200
4) The Marantz RC-9200

so obviously if someone created a SI for the 9200 it is not an issue. But if someone created an interface for the 5000 it might be, because someone might want to use it on a Pronto.

What I was thinking is that you could post a text file (or table) explaining what icons to replace (FileX.bmp replaces the home button = XYZ.bmp in editor version), or use names for the file (like device_use.bmp)

also like you said, emulator+firmware=3 meg, so can you imagine waiting for all that if all you want is the IR codes for the TV :-)

I know that you know... just thinking out loud for the group...