Series2 in PAL

Quote:

---

Originally Posted by inaxeon

Perhaps you should mention how one may contact you anonymously because there may just be someone who has the right information reading this thread as we speak.

---

My website (link is in each and every post I make in my signature) contains my email address. I am sure if one genuinely wanted to help they can find a public terminal, obtain an email address, and email me. From there I am happy to give out better ways of contacting myself. I used to publish my mobile (cell) phone number but although people could read the numbers to dial the correct number they could not read the correct numbers for the times you can and cannot contact me so I withdrew it. I do have a family and a real job so getting calls all hours into the evening is not the done thing.

Failing that one can always send me a private message on this forum.

I'm sure there are other ways people can contact me. I'm not a very private person and just reading my website can give a few more clues if one is genuinely interested in helping the cause.

Quote:

---

Originally Posted by inaxeon

Another thing I've found when working with these chips is that the vendor doesn't always give out the datasheets "Willy Nilly" usually all we get is a precompiled library with an easy to use API for performing the needed tasks on the chip and if there's any issues with that API the vendor will support that rather than giving out a register reference to fix it yourself. (Which does make me wonder, has TiVo been lazy and just used one of these libraries?) So it's not always as straight forward as getting register reference datasheets.

---

True. However I am assuming that there is more than simply a subset of registers or an API in the possession of "example3891" (and others) given the wording "As somebody who has access to the information you need".

However I could be wrong. Like I have said previously I've seen zero evidence of anything so therefore until someone wants to step up to the plate anyone could be telling OzTiVo any old story, including yourself with what you have already divulged about how Broadcom conducts their document control.

Cheers

Quote:

---

Originally Posted by Darren King

However I could be wrong. Like I have said previously I've seen zero evidence of anything so therefore until someone wants to step up to the plate anyone could be telling OzTiVo any old story, including yourself with what you have already divulged about how Broadcom conducts their document control.
Cheers

---

That is true. I could just be making all of this up and there's no point in me trying to back up anything I've said because I don't have any useful information to start with. We'll never know until someone divulges anything useful.

Quote:

---

Originally Posted by Darren King

And at any rate like mentioned by the original poster the BCM7040 and BCM7020 is *not* a TiVo-Broadcom proprietary chipset. It has been used in other devices.

---

Interesting reading.

I wonder if TiVo is not the only product using these devices then what are the other ones and could they provide some sort of insight into the problem.

If you found another product with that same MIPS processor running binaries compiled with a similar compiler, that product runs the chip in PAL mode and also happens to run linux then comparing binaries may provide some insight.

Although if all of the above were found then there are other approaches like trying to hook into the kernel register access stub and see what is written. for example changing the /dev/xxx (or whatever they're called on TiVo) nodes to point to your own kernel module, log them then redirect those to the appropriate Broadcom code (I'm sure all of this has been done by experienced OzTivo members before)

But then you've still got the problem where the TiVo software is quite possibly constantly trying to set the chip back into NTSC mode which totally screws that approach so the TiVo software is what needs to get modified.

Certainly it would be easier if a tv capture card or something similar had used these chips, so we could learn from it's API.

But as far as I'm aware no one has found a product of use to us that had used this chip.

Peter

There are several capture cards based on the BCM7040. Refer to the bottom post here: http://forums.sagetv.com/forums/arch...hp/t-5289.html

Another page I stumbled across suggests the BCM7040 was used at least the "Snazzi-II" and "Snazzi-III" models of capture card: http://qaix.com/software-computer-he...ble-read.shtml

I also had a little time to Google last night and Broadcom make a PVR chip that interfaces to the 7040, the BCM7115: http://www.broadcom.com/collateral/pb/7115-PB06-R.pdf

Added to this, Broadcom did not develop the BCM7040. The original name for the chip, the KFIR-II was the name given to it by a company called VisionTech which Broadcom acquired at some point in time and re-badged the chip with a Broadcom product number: http://archive.tivocommunity.com/tiv...c/57528-1.html and as said by one post in that thread the BCM7040 was not even a new chip at time of TiVo Series 2 development so that adds weight that someone, somewhere would have some information gathering dust on the device.

Therefore it is very clear the BCM7040 was *not* something that Broadcom developed themselves or specifically for use in the Series 2 TiVo and given the age, obsolescence and history of this chip it escapes me why Broadcom would still want to guard it more closely than the Crown Jewels. :confused:

Quote:

---

Originally Posted by Darren King

Added to this, Broadcom did not develop the BCM7040. The original name for the chip, the KFIR-II was the name given to it by a company called VisionTech which Broadcom acquired at some point in time and re-badged the chip with a Broadcom product number

---

That's correct and before that there was the KFIR chip which has pretty much the same register set and parameters as the KFIR-II.

Someone even wrote an open source Linux driver for the KFIR chip which clearly showed the values that needed to be put in the various registers for encoding PAL.

Both Robert Lowery and I came to the conclusion that it's not just the register values that need to be changed.

The chip runs microcode for encoding the video signal and the version of the microcode is specific to the television standard to be encoded i.e. NTSC or PAL. The microcode is loaded into the chip during the driver initialisation.

The BCM7040 driver on the Series2 contains NTSC microcode so no matter what you do to the registers it won't encode a PAL signal correctly.

Overwriting the microcode is quite easy to do but the problem is finding the right version. There are several versions of microcode for the KFIR-II chip available on the net and, of these, I found one that could be used to overwrite the existing code.

When I tried it all I got was a black picture but it wasn't a total failure. When running Robert's S2 palmod.o there were error messages being generated in the tverr log that shouldn't have been there. After replacing the microcode, the error messages stopped.

Maybe it was one step closer to success, maybe not. I really don't know.

If anyone does decide to try and have a go at getting the chip to encode PAL, I hope they succeed. Having spent many, many hours on the project it would be nice to know the answer.

The decoder driver might be an easier place to start. The decoder driver is far more complicated than the encoder driver but it seems to be a Broadcom driver rather than something TiVo wrote. It would also be much easier to determine when you've got it configured for PAL.

I've been silently reading the different posts and I figure that I should post to let you know that I'm still here :-)

Regarding the whole "I have the info but I can not give it to you" issue, I kind of understand the persons that are telling us that if they really say this out of frustration.
On the other hand, despite any "super-duper" system that Broadcome could have to protect the documents, and as much as they could change words and shuffle them around, I really doubt that they will dear touch the sample code (at most the *could* change the name of some variables).
And even a plain sample code would be really helpful ... and if one of us were to get a copy of it, it would not be hard to "rewrite it" so it's not traceable ... but I don't count on that happening anytime soon.

For the rest of the post, I learned that I had not done my homework as good as I believed ...
I knew about the Snazzi capture cards and That's why I was surprised that there is not a lot more info available (I only found a partial code for a driver), still, I was planning to use the little info I got for this cards as my starting point.

On the other hand, I did not knew about the microkernel needing to be changed to start with, nor did I knew that the KFIR and KFIR-II had the same registers ... something interesting to investigate a further.

thanks a lot for the info ...

Quote:

---

Originally Posted by petestrash

Certainly it would be easier if a tv capture card or something similar had used these chips, so we could learn from it's API.

---

Just reading with interest.

I passed on these links to someone a while ago (for BCM7021+BCM7040), not sure if they were/are of interest but just in case.

http://www.fabiao.net/viewthread.php...light=broadcom
http://www.fabiao.net/viewthread.php...light=broadcom

If you translate the rest of the page you can see where to pay (~$20) to get a copy of these papers.

http://translate.google.com/translat...light=broadcom
http://translate.google.com/translat...light=broadcom

If this has already been discounted, then appologies.

Cheers Nick

Seeing that the 7040 pops up again. Was the issue resolved of believing that, given Robert's efforts back in 2004, the only major issue left is that the Tivoapp needed (unknown) modification? In that case the internals of the BCM7040 are not needed, right?

see Robert's mail on 09-10-2004
"Seeing there seems to be a bit more interest in S2 hacking at the moment,
here is some details of the progress I made ages ago. I believe all this
talk of getting Broadcom datasheets etc is a red herring. I have already
managed to hack the mpeg encoder module (kfirm.o) to support PAL and looking
at the disassembly of the mpeg decoder module (brcmdrv-rb.o), it already
supports PAL. I believe the real work remaining is in tivoapp."