9960B01 Extender Status

[unclemiltie]

I don't have a 9960B01 but I'm working on a port of the 6960 extender that I've written. Can someone who has one, fill the thing with FF's, then do a 981 reset and then download the remote and upload the IR file somewhere?

this should help me get things started while I wait for my 9960's to arrive


thanks

[yesok]

Hello,

I have uploaded an ir file in diagnostic area of file section, prepared according to your instructions.

http://www.hifi-remote.com/forums/dload ... le_id=4201

Hope I have done it right.

Good luck,

Yesok Yoon

[unclemiltie]

Hello Robman,

Could you tell me what do we need to know when we are writing an extender for a specific remote from UEI?

Could you tell me what design features of a remote may make the extender developer's life more enjoyable than before?

I am asking this to implement such design faetures on a new remote based on UEI Generic IR Blaster chip(Samsung CPU with flash memory), so that we may create extenders with various capabilities easily and economically.

I'll take a crack at this having just gone through the exercise of writing an extender:

Assuming that you WANT the ability for people to write programs that take over your remote..... There's a whole pile of business-type questions that you have to think about when you open things up. For example, if the customer picks up the phone and calls your support line it costs you money. Even if your support people tell them "you put an extender in it, click" you'll have to account for the distraction value. But making that assumption that you want to enable this.....



In general, DOCUMENT stuff so that we're not guessing!

1: build some common mechanisms to get into the remote. for example, a jump table that's always at the same place in all of the remotes for things that the extender writers need so they're easier to find. (If the "Delay W0" routine was ALWAYS at $010D, I can then not spend time trying to guess where it was) The registers that are used are a common set and the list of registers that are not used is well known.

2: give me more RAM! The extenders are broken into two pieces because there is only 256bytes of RAM, which is a pain in the neck when debugging. IF we had more, this would be less of an issue.

3: think about separate RAM for "program" and "data". The extenders have to run from RAM but there are parts of the remote that read stuff into RAM and thus clobber the extender. To get around this the extender writers have to do strange things to make sure that there is code there when we come back. The extenders would be much simpler (and possibly smaller!) if we didn't have to worry about our code being wiped out

4: put the locations of stuff in EEPROM somewhere that can be changed. We end up re-creating some of the ROM routines with different data points (for example, the Advance Code area) where if this data was in EEPROM we could leverage the ROM more (and thus make the extenders smaller!)

5: put some debugging entry points in the ROM. For example, an entry point that would take a byte and blink it in hex, or another that writes the contents of the register file to a spot in EEPROM. yes, we can re-create this, but then it takes space and then the extender won't fit into RAM (see above)

6: provide some mechanism for the core remote to call-back into user defined code. for example the extenders re-create the main idle/stop/interrupt paths to get control of the remote. If there was a mechanism that this core loop would call out to a routine in the EEPROM if it exists when keys were pressed, when other interrupts happened it would also make it easier to build extenders.

[unclemiltie]

i'm posting this here so that anyone who has a notify me on this topic gets the notification. I've posted a 9960B01 extender beta here

http://www.hifi-remote.com/forums/dload ... le_id=4248

please use the announcement thread to discuss bugs/features/etc