Using Latest OzTiVo 1.62 image on UK S1 TiVos

[Dave Hatt]

Agreed, on the UK TiVos with UK image there is no palmod.o. However because I am now using the US 3.0 OzTiVo image I figured that it would be using the palmod.o file though.

Not that I have figured out how to update or decompile palmod.o yet. Looks like my next challenge!

Meanwhile thanks to catdog's script I have a definitive list of the relevant register value differences:

UK Image 2.2.5 _________________ US Oztivo 3.0 (1.6.2) Image ____ Comment
Contents of address 02 is: b1 __ Contents of address 02 is: 81 __ Analog Input Control - RGB Mode31
Contents of address 06 is: 97 __ Contents of address 06 is: 65 __ Horizontal sync start
Contents of address 0e is: 01 __ Contents of address 0e is: 81 __ Chrominance Control
Contents of address 0f is: 35 __ Contents of address 0f is: 37 __ Chrominance Gain Control
Contents of address 29 is: c0 __ Contents of address 29 is: 00 __ Component delay/fast switch control
Contents of address 67 is: 20 __ Contents of address 67 is: 00 __ Reserved
Contents of address 9c is: 20 __ Contents of address 9c is: e0 __ Horizontal output window length
Contents of address 9d is: 02 __ Contents of address 9d is: 01 __ Horizontal output window length
Contents of address a8 is: 4b __ Contents of address a8 is: 00 __ Horizontal luminance scaling increment
Contents of address a9 is: 05 __ Contents of address a9 is: 06 __ Horizontal luminance scaling increment
Contents of address ac is: a5 __ Contents of address ac is: 00 __ Horizontal chrominance scaling increment
Contents of address ad is: 02 __ Contents of address ad is: 03 __ Horizontal chrominance scaling increment

And now I can confirm that the following commands set the TiVo into RGB input mode:

/var/hack/iicsetw 0x42h 0x02h 177
/var/hack/iicsetw 0x42h 0x06h 151
/var/hack/iicsetw 0x42h 0x0eh 1
/var/hack/iicsetw 0x42h 0x29h 192
/var/hack/iicsetw 0x42h 0x9ch 32
/var/hack/iicsetw 0x42h 0x9dh 2
/var/hack/iicsetw 0x42h 0xa8h 75
/var/hack/iicsetw 0x42h 0xa9h 5
/var/hack/iicsetw 0x42h 0xach 165
/var/hack/iicsetw 0x42h 0xadh 2

The colour and quality all seem fine with these settings, however the left hand side of the picture seems to get cut off (about 10%). Possibly this is the Horizontal Shift problem mentioned in the Palmod User Guide.

And of course the changes don't survive a channel change on the TiVo. I'm wondering what would be the best approach here: inserting these commands in palmod or patching fpga7114.o.

[Dave Hatt]

Update: I found that just the following are suffient to enable RGB mode:

/var/hack/iicsetw 0x42h 0x02h 177
/var/hack/iicsetw 0x42h 0x29h 192

This doesn't seem to trigger the horizontal shift issue. However I am also now using LJ's fpa7114.o file from here. The picture quality is far better with no artifacts, and so are the colours, but not sure about whether they are optimal just yet.

I tried patching the fpa7114.o file, finding the relevant offset location from this thread, however I haven't quite found registers that survive a channel change as yet. I'm wondering if the fpa7114.0 module only gets read on boot up, and perhaps something else such as palmod is overwriting the values on channel change. More investigative work to do here!

[Dave Hatt]

I think I have finally found the answer! The abovementioned iicsetw commands work when executed, but don't survive channel changes or reboots. Hacking the values into fpa7114.o doesn't have any impact either (in fact from testing I suspect that the values *do* get loaded, but then get overwritten by tivosh).

What did work was to execute the setConn.tcl script:

[TiVo [p0] /var/hack]# /var/hack/setConn.tcl 7 5
Connector changed from 5 to 7
SignalType changed from 5 to 5

Connector type 7 is Scart, and 5 is s-video. Executing this script puts the TiVo into RGB mode on the scart input.

What led me to this discovery was this old post on the mailing list from 2004 by John Graham. Just in case, however, I will list the tcl script again here:

------------------start setConn.tcl---------------
#!/tvbin/tivosh
#
# thanks to Phil Hunt for this script

# source of RetryTransaction function
tvsource $tcl_library/tv/mfslib.tcl

proc FIXUP {db conn st} {
try {
RetryTransaction {
set setup [ db $db open /Setup]
set s1 [ dbobj $setup get Source 0]
set oconn [ dbobj $s1 get Connector ]
set ost [ dbobj $s1 get SignalType ]

dbobj $s1 set Connector $conn
puts "Connector changed from $oconn to $conn"

dbobj $s1 set SignalType $st
puts "SignalType changed from $ost to $st"
}
} catch errCode {
puts "Failed, errCode=($errCode)"
return 0
}
return 1
}

set db [dbopen]
set conn [lindex $argv 0]
set st [lindex $argv 1]
if { $conn == "" || $st == "" } {
puts "Usage: setConnector connectorValue signalTypeValue"
} else {
FIXUP $db $conn $st
dbclose $db
}
------------------end setConn.tcl---------------

Note that I see reference to where UK TiVos and Scart should automatically be detected during initialization, however it either isn't working correctly, or it still needs to be run once manually when the UK TiVo is first set up with the 3.0 image. Maybe another way to detect a UK TiVo during initialisation is needed.


Now that I have RGB working I have moved on to putting the TiVo into Mode 0 (720 lines instead of the default 576 or 480) and the increase in quality with this and RGB is just amazing. Note that I ended up repatching the fpa7114.o module as its a newer version on the 3.0 image so the copy listed with the instructions here is out of date and I wasn't sure if it was adding to my troubles! I am attaching this updated module for those who want to use it themselves. Basically follow the instructions at LJ's website, but use the attached file instead. Note this file simply changes the horizontal shift problem from putting the TiVo into Mode 0. See also the thread on changing resources to set Mode 0 recordings here.

At this point I haven't done any further investigation into setting Component input for the TiVo. The 7118 chip in the UK TiVo is certainly capable of Component input, and I think the following commands will activate it:

/var/hack/iicsetw 0x42h 0x02h 0xa1

However I don't know of any way to make it survive channel changes. Perhaps there is another mode that can be set through a modification of the setConn.tcl to set the correct input, but I suspect it might not be quite that easy! Or if another way can be found to execute the iicsetw command after a channel change then this would likely work well.