• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

[CFW 3.03] Customised Firmware version 3.03 released.

Let me try to explain for the uninitiated, because the general media bandies words about software about as if it's easy.

Writing a computer program isn't very difficult, because for the last many years it has been possible to write instructions that look like reasonably sensible English (although the more advanced programming that goes on these days has diverged away from sensible English again because it makes things easier to express more complex requirements - and programmers understand it). A program written in this way is fairly straight-forward to read and understand, and make changes to, especially if the original author has put in plenty of comments about his intentions.

The problem is that computers cannot understand and execute such programs. Computers only understand very simple instruction codes, conveyed in binary. So one instruction code might be an instruction to add the number stored in one memory location to the number stored in another memory location, and store the result in the first location replacing what was there previously. Programs are made of millions of individual simple steps like this, and computers only seem clever because they are able to process millions or billions of these simple instructions every second and the cumulative effect is a clever program that does something useful.

In order to convert the English description of what you want the computer to do into the simple steps that a computer can understand and execute requires a very clever piece of programming called a compiler. This takes the description (the program) and converts it step by step into a series of instructions for a particular computer processor (and different types of processor understand the binary instruction codes differently, which is why you can't run a Mac program on a Windows machine), so that the processor can then do what it's been told and thus achieve the effect intended by the original description.

So, what you have within the HDR-FOX is a program in binary codes which the processor understands, but is not in a Human-readable form. The Humax programmers have the original source code with all the necessary commentary, but that is commercially sensitive and kept to themselves. It is possible to decode the binary into primitive instructions, but it would then take a huge amount of analysis to work out what all those primitive instructions are meant to achieve. Just comparing two sections of binary instruction code (even if you knew which sections to look at) would yield nothing useful, because the instructions only have to be displaced by a single address for the actual binary to change, even if the instructions themselves are otherwise identical. You would have no idea whether the binary differences were significant or not.

What "we" are able to do is look at and modify the parts of the code that Humax have incorporated from the public domain (rather than expend the effort to recreate for themselves) - which means the Linux operating system stuff. We are also able to observe the effect that the data has on the HDR-FOX code, and how the HDR-FOX code alters the data, so we have been able to deduce that altering the data in particular ways has various desired effects.
 
.
WOW, what a wonderful and detailed explanation!
Thank you to 'Black Hole' for taking the time to explain the finer details of how the Humax works. Even a non-tecky like myself can now understand the complexities of modern programming/coding or whatever it's called these days lol.

I'm from the generation of MS-DOS 5.0, Cobol, Pascal (early 90's) and creating a computer programme back then was easy and extremely interesting. When you'd finished your programme and Run it, the sense of achievement was delirious (i myself created something similar to what Blockbuster used to use - a Video Rental program, with all the sub-menus etc). Obviously the world has moved on since then and the new Binary coding (for want a better word) is WAY beyond my simple brain.

A silly question i keep asking myself is how hard would it be (hypothetically) to write a new program to run on the Humax box to replace the HumaxTV program? No need for answers guys, it's just theoretical :)
.
 
MS-DOS 5.0, Cobol, Pascal etc.
These are languages, not binary processor instructions. When you program in the aforementioned languages you first need to run them through a compiler to make the binary. Some languages are interpreted on the fly. This means that the written code is passed through an interpreter, at run time, which takes the code and converts it to processor instructions and fires them at the processor.
 
I'm from the generation of MS-DOS 5.0, Cobol, Pascal (early 90's) and creating a computer programme back then was easy and extremely interesting.
From the comments you have posted, you're obviously of the "any idiot can program" school. Try throwing away your source code for something you wrote and then recreate it just from decoding the bytes in the executable. Actually, give somebody else the executable and get them to do it.
Don't expect your re-created source any time soon.
 
Even a decompiler can't add comments to say what the code is trying to do, so you still have to guess what it's for.
 
I'm from the generation of MS-DOS 5.0, Cobol, Pascal (early 90's) and creating a computer programme back then was easy and extremely interesting. When you'd finished your programme and Run it, the sense of achievement was delirious (i myself created something similar to what Blockbuster used to use - a Video Rental program, with all the sub-menus etc). Obviously the world has moved on since then and the new Binary coding (for want a better word) is WAY beyond my simple brain.

No, nothing has moved on (not in the way you mean anyway). What you never saw was the translation process from Cobol or Pascal to machine code (MS-DOS is an operating system, not a programming language). The machine won't run on Cobol or Pascal however much you want it to - the program has to be translated to binary machine code first, and that is what a compiler does. As Trev said, sometimes (for very simple languages like BASIC) the code is translated "on the fly" rather than as a preliminary step, and then the compiler is called an interpreter.

You are not really aware of the process when using an interpreted language, because it all happens hidden behind the scenes (except that interpreted languages run more slowly than compiled languages), but the machine instructions still end up as binary. If you want to know how different the binary machine code is from source code, just go onto the Web and look up the instruction set for a simple CPU - say an 8086. Just remember that the instruction set is all there is to command the processor, all there ever was to command the processor, and all the sophistication of high level programming languages such as Cobol and Pascal are the genius of the guys who wrote the compiler - ie the program which can read a series of instructions in Cobol, Pascal, or whatever, and translate them into a series of machine code instructions using the instruction set of the particular CPU in question.

A compiler creates the binary, which is what you see on a PC as a .exe or .com file. Take a .exe file you got from somewhere else, or even one of your own, and try reverse-engineering it. That's easier than taking the Humax binary and working out what that does, because at least the PC architecture is documented in the public domain and there are tools to help you do it. If you do it with one of your own executables you can refer to your source code to try to work it out, and that will help, but it will still be difficult and you will have to remember that you would be trying to decode the Humax binary without the help of source code.

A silly question i keep asking myself is how hard would it be (hypothetically) to write a new program to run on the Humax box to replace the HumaxTV program? No need for answers guys, it's just theoretical :) .
No need to keep asking yourself - I can tell you the answer: very hard to impossible.

The Humax hardware comprises many subsystems for tuning in to broadcast channels, selecting a service stream, decoding the audio and video data, buffering the data to hard drive, and outputting data to the HDMI interface etc etc etc. This is like the systems in a PC which run the USB ports, receive keyboard input, interface to a network or modem, etc etc etc. The software has to tell all the hardware what exactly to do, and in the case of a PC all that is documented and available for people to write programs to do it. The Humax hardware is undocumented (not in the public domain anyway), so trying to write open source alternative software, when you have no idea what codes to send or where to, will be next to impossible.

You can't even open it up and use analysers and scopes to find out how it works, because a lot of it is all contained in one big chip where you can't see what's going on and can't get at it.

(I don't think we had better get into BIOSes and real-time executives, those will really fry your brain)
 
MS-DOS not a language? I'm fairly certain that not many processors understand stuff like DIR and CD etc.
 
Are we starting an argument about semantics? Do you call the instructions in a .bat file "MS-DOS" or something else? I think I could agree on "MS-DOS Shell Script".
 
Last edited:
.
A silly question i keep asking myself is how hard would it be (hypothetically) to write a new program to run on the Humax box to replace the HumaxTV program? No need for answers guys, it's just theoretical :)
.
I'll give you an answer anyway. It would be impossible (definitively) to do this, given that the box itself contains several custom silicon chips which provide the hardware interface which takes input from tuners, processes said input, then outputs to screen via HDMI or SCART. If you knew exactly what chips the box contained and precisely how they were physically connected and had the complete instruction sets from the manufacturers of each chip, even then you would still have a mammoth task. These boxes were designed and built commercially by a team of professionals, not single-handedly by Joe Bloggs in the back garden shed.

Things have come a long way since :
10 CLS
20 PRINT "I really don't have a clue."
30 GOTO 20

and your over simplistic thinking demonstrates a true lack of understanding of current technology. Go back to sleep.
 
Last edited:
These boxes were designed and built commercially by a team of professionals, not single-handedly by Joe Bloggs in the back garden shed

I suppose with all this knowledge now given to me by you guys, it helps me to appreciate better all the hard work done to develop such a product - the HDR-FOX T2!

Thank you to all who've contributed to my learning :)


Your questions don't make a lot of sense.

...lol i did say i was a newbie :)

Thanks for helping me to understand better (although not fully like you guys). Yes i agree that it probably wasn't a deliberate act to slow down the epg but merely a consequence of updating something else within the code. It's just that in this 'modern world' with technology we're all so used to everything being instant, so that when something takes a full second or two, it's too slow! lol.

PS.
Am i allowed to create a new thread/post being a brand new user?

I've got a major issue with certain tv channels on my HDR-Fox T2 (via TV Input#1) not recording (manual or AR), or even appearing on the Time Shift Buffer when NOT actually watching 'directly'.... ie. when i've changed my LG TV to select "TV Input#2" to watch something else on my other HDR-Fox T2 box.

It was fine until i installed CF the other day on Hummy#1 (tv input#1) but now it won't "keep the signal input" on to Hummy#1 as it did before the CF installation? Obviously i'll try re-installing the OF and try to see if it goes back to the way it way before, because it was perfect!

thanks
.
 
I do. You don't stand a chance without the source code and the build system.

It's possible, just difficult.

Before I got a Humax PVR I had a Digifusion. The firmware for that was completely a binary blob - everything in one file including the OS (which was OS20). The box was based on an ST20 processor and disassembling the firmware (once I'd written the disassembler) produced over 1 million lines of instructions. I still managed to find the few bytes in there that needed changing to achieve the change that I wanted and several other people also found ways of changing other aspects of the system to our advantage.

Some aspects of the custom firmware on the Humax have required similar effort too. Nowster's patch for the Foxsat is a binary patch against the Humax application, the humidify application was written following a detailed analysis (reverse engineering of the encryption and checksumming algorithms involved) of the HD-Fox T2 bootloader and the ir package required an understanding of the way that the Humax application manipulates heap memory internally, which took months. I find MIPS code very hard to read - far harder than x86 or ST20.

I'll give you an answer anyway. It would be impossible (definitively) to do this, given that the box itself contains several custom silicon chips which provide the hardware interface which takes input from tuners, processes said input, then outputs to screen via HDMI or SCART.
The chipset manufacturer, Broadcom, provides the source for the operating system and a binary blob interface module and associated user space library called libnexus. If the libnexus API documentation was available then there would be a chance of creating a completely custom software package but that's incredibly unlikely.
 
I didn't like the MIPS processor when I had to compile for it more than 20 years ago. It seemed to me to be a fundamentally flawed design, with the compiler needing to know how many cycles each instruction takes and inserting the correct number of NOPs. This means the binary is twice the size of the same code compiled for other cpus, and that either the binary goes at the speed of the slowest cpu or it is recompiled for one that uses fewer cycles per instruction but the binary then either won't work or misbehaves on the slower cpu. Dumb. Register scoreboarding was invented for a reason, MIPS thought their idea was cool but it wasn't. And as for always executing the instruction after a branch regardless of whether the branch is taken, I mean, how often can the compiler put something useful there? Almost never in my experience.
 
And as for always executing the instruction after a branch regardless of whether the branch is taken, I mean, how often can the compiler put something useful there? Almost never in my experience.
I've used compilers that always insert a NOP following a branch to just effectively ignore the branch delay slot. However, in the Humax code there's pretty much always something there IIRC. Something else that makes it hard to follow as it inevitably means that some re-ordering or other optimisation has been done by the compiler.
 
Am i allowed to create a new thread/post being a brand new user?
Yes.

I've got a major issue with certain tv channels on my HDR-Fox T2 (via TV Input#1) not recording (manual or AR), or even appearing on the Time Shift Buffer when NOT actually watching 'directly'.... ie. when i've changed my LG TV to select "TV Input#2" to watch something else on my other HDR-Fox T2 box.

It was fine until i installed CF the other day on Hummy#1 (tv input#1) but now it won't "keep the signal input" on to Hummy#1 as it did before the CF installation? Obviously i'll try re-installing the OF and try to see if it goes back to the way it way before, because it was perfect!

thanks
.
This coincides with a retune event. Your signal problems are probably due to it needing a retune rather than the CF installation.
 
I've used compilers that always insert a NOP following a branch to just effectively ignore the branch delay slot. However, in the Humax code there's pretty much always something there IIRC. Something else that makes it hard to follow as it inevitably means that some re-ordering or other optimisation has been done by the compiler.

Indeed. I can read compiler generated ARM code and make some sense of it even when optimised, but MIPS code has so much work done by the compiler on re-ordering and delays etc. that I find it impenetrable.
 
If the libnexus API documentation was available then there would be a chance of creating a completely custom software package but that's incredibly unlikely.
So the chances of Des In London achieving this goal is not impossible then ? :rolleyes:
 
MS-DOS not a language? I'm fairly certain that not many processors understand stuff like DIR and CD etc.
COMMAND.COM is the command processor that understands stuff like that. A command processor is NOT the operating system.
Stupid people think Windows' command line processor (CMD.EXE) is an "MS-DOS box". It isn't.
 
It's possible, just difficult.

Nowster's patch for the Foxsat is a binary patch against the Humax application
Twiddling 1 byte is possible with a patch. Fixing the EPG isn't.
The chipset manufacturer, Broadcom, provides the source for the operating system and a binary blob interface module and associated user space library called libnexus. If the libnexus API documentation was available then there would be a chance of creating a completely custom software package but that's incredibly unlikely.
Yes, but it isn't and even if it were, it would be under some sort of NDA, and would take many man-years of effort.

In practical terms, it is impossible.
 
Back
Top