I'd much rather be doing stuff that people regards as useful.


Which would be having a kernel with NTFS write support for instance, or ext?fs for that matter? I wouldn't mind loosing the USB-function if that would get us (large file) write support on the internal hdd :rolleyes:

Are we already running a custom built kernel in the latest firmware? Is it just a matter of building a kernel using the uClinux sources in GPL.zip. Sorry if these questions seem trivial to you guys but I would really like to contribute in some way :)

I think one problem is that all of the **big** changes people would like to see are a bit beyond what we can do with our knowledge of the mg35 at the moment.

Personally my #1 on the wishlist is smb (or at the very least ftp) access to an NTFS hard drive in the unit. The big stumbling block there is probably needing to recompile the kernel to be able to add pure and ntfs_rw drivers - something that is way beyond my limited knowlege of embedded unix. My experience of Kernel compilation is vague memories of running ./configure on SCO systems back in the early 90s!

#1 on a lot of peoples wishlist is adding codecs. I'm not convinced we'll ever be able to do this - but I've been suprised by what's been achieved so far.

Given that I can't contribute to the above I've been trying to build on EmuMannen's excellent work with the graphics by attempting to add the possibility of some user configuration of colours. No two displays are the same, and some schemes that other people have found work well need significantly more contrast on my aging plasma so being able to tweak some of the colours is a definite plus for me.

It's also important to remember that the people who are currently "hacking" the mg35 are doing it as a hobby. I'm actually thinking of buying a cheap PC just to use as a unix box for mg35 development. One part of me does think that if I do that why not just stick it under the TV and use it **instead** of the MG35? But where's the fun in that? :D

Sorry, thought you where playing with httpd in busybox... mathopd might be worth a try if thttpd isn't delivering though...

OK, I have built mathopd, and it seems to be doing everything required to work nicely on uClinux, which is very promising!

I guess it will need running with -
mathopd -n -d -t -f configfile &

I can dump the untested executable on people again, but that didn't work out too well last time!

Ian

In the wishlist / distant future department: wouldn't web based playlist managment and editing be very nice?

OK, I have built mathopd, and it seems to be doing everything required to work nicely on uClinux, which is very promising!

I guess it will need running with -
mathopd -n -d -t -f configfile &

I can dump the untested executable on people again, but that didn't work out too well last time!

Ian

I'm waiting for that

Why is it so important to get a webserver running?I don't quite understand 'the roadmap' :) I've read the entire thread but I don't understand why all this effort goes into trying to run binaries (at least it seems like that tot me) on the box. Or is this all forework needed to understand the workings of dvdplayer.bin so that it can be replaced/altered? NOFI, just trying to understand. I have no experience in this embedded systems stuff :)

I dont have a serial cable yet, so anything I could work on is just a way to do something before my cable arrive.

Sorry, thought you where playing with httpd in busybox... mathopd might be worth a try if thttpd isn't delivering though...

OK, I have built mathopd, and it seems to be doing everything required to work nicely on uClinux, which is very promising.

However, trying to run a CGI script gets -
socketpair: Address family not supported by protocol
on a call to
socketpair(AF_UNIX, SOCK_STREAM, 0, p);
which shouldn't fail.

Ian

Hi guys, great work,

I just wanted to remind you that in my opinion it would be a shame, if at some point the MG-35 would loose it's ability to serve as a totally noiseless media player due to extensions that need an internal harddisk .
I know that you need this for testing and developement, but please keep in mind, that it should run without in the released versions.

Just my 2 Ct. Cheers

Umtauscher

Ok well I will try to figure out how to do the cross compile stuff on my debian box

Hi guys, great work,

I just wanted to remind you that in my opinion it would be a shame, if at some point the MG-35 would loose it's ability to serve as a totally noiseless media player due to extensions that need an internal harddisk .
I know that you need this for testing and developement, but please keep in mind, that it should run without in the released versions.

Just my 2 Ct. Cheers

UmtauscherJust a quick note on that. I have one of my MG-35s in my bedroom, located about 5 feet from the footboard of my bed. It is equipped with a 250 Gig Hitachi 7K250 hard disk.

The Hitachi drive is essentially noiseless. It is spun down by the MG-35 if not being used, even if the unit is left on. This is a great feature. I can hear it spin up (barely) when I first turn the unit on, but I do not hear it otherwise. It is a very quiet drive. It also is very low power, as the case of the MG-35 is barely warm, even after several hours of use playing a movie.

What I'm saying is that an internal HD does not mean the MG-35 will sound like your noisy PC. The MG-35 can be used in a very quiet environment (bedroom) and still be equipped with a hard-disk... as long as you use a modern, quiet, low-power drive.

I would recommend the Hitachi 7K250 drive if something in the 250 Gig range is enough for your needs. It will allow you to have an internal HD and still maintain a silent MG-35. (I got about 45 ISO images of movies, about 20 CD's worth of mp3s, and an entire season of the TV show 24. My ISO images are not compressed at all, but are just the main title extracted using dvdshrink. I even created a 20 gig FAT partition in addition to the main NTFS partition so I can join in the fun once I get equipped to join in the development effort.)

I agree, the development should take into consideration users with internal disks, and those with no internal drive, but installing a drive may not be as big an issue as you might think.

Joe L.

I just wanted to remind you that in my opinion it would be a shame, if at some point the MG-35 would loose it's ability to serve as a totally noiseless media player due to extensions that need an internal harddisk .
I know that you need this for testing and developement, but please keep in mind, that it should run without in the released versions.


I totally agree. My main box has no HD and won't be getting one!

This is probably why I've been looking at NV config more than anyone else.

Ian

...it would be a shame, if at some point the MG-35 would loose it's ability to serve as a totally noiseless media player due to extensions that need an internal harddisk.
Well,
You don't need to use any particular version of reverse-engineered firmware; just go with the Al Tech version.
You can always get a really quiet disk. I bought an ST3250623A which is advertised as the "world's quietest 7200rpm drive with the most advanced fluid-bearing motor." It's quieter than my old buzzy 32" TV!
Ian usually runs diskless, and I seriously doubt he would ignore his own needs when generating new builds. He's the one IIRC who has a TB server in his basement. :cool:

I'm waiting for that

Good job I didn't just dump it on you. It likes multiple users to run. Rather than make new firmware with users www and cgi added to /etc/passwd, I just hacked the source!

socketpair didn't work. Dunno why. I found some source for a replacement on the web and hacked it in. As a result, we need use ifconfig to get a lo network doodaa.

My current config is really rough, and the sample html and cgi are garbage, but I was just after something to let me make sure the code worked.

Zip file attached with instructions. I have served html and cgi from it and it all looks very good. It's a well-written and pretty professional bit of code IMO.

I'll try and remember to add the new users into the next firmware. The loopback can be added to the phase stuff that launches mathopd for now.

Ian

Ian usually runs diskless, and I seriously doubt he would ignore his own needs when generating new builds. He's the one IIRC who has a TB server in his basement. :cool:


It's actually 2 TB before raid. :)

But yes, I think the firmware needs to address the needs of those with HD and those who choose not to use them.

Ian

Before adding codec, we should try to optimize the existing ones. Avi files encoded with xvid and 2 consecutive Bvops (standard AS@L5 profile) give playback problems.

About the GUI: other mediaplayers based on Sigma EM8511 (Zioncom, Mvix, etc.) already use skinnable GUI based on a xml configuration file. Maybe reverse engineering those firmware could help the development for the Mediagate.

mathopd might be worth a try if thttpd isn't delivering though...

Thanks for the recommendation on this one. I have now tried half a dozen web servers for uClinux and this is the first one that's come through. The rest were either a sod to build (fnord as it needs dietlibc, boa as it needs bison and falls over in a yacc'y mess), didn't use vfork correctly and had other issues (BusyBox httpd, thttpd) and various others failed when I just looked at the source and/or read how nommu unfriendly they were.

Other than the socketpair failure (mysterious!) and the rather complex config file,, mathopd was a breeze.

Ian

I'm planning the release new firmware this evening or tomorrow.

Edit: September 1st 2006 - MG32-1.4.4.4-pre0 (new naming system!)
Built by Gadgetmind

As per NewGui-3a-144-eng but with the following changes.
1) Put phase1 and phase2 in Recycled/RECYCLER
2) Added dvddir variable to sashrc so that phase1 can change which dvdplayer.bin is executed.
3) Added www and cgi users (for when we add the mathopd web server)

(1) and (2) should make HD development more pleasant.
(3) will mean I can take the hacks out of mathopd for playing with webby stuff.

If anyone else has anything they want adding (mg35palswap? new palette?) then please let me know. I can easily hold this back until late Sunday.

Ian

Probably not worth bothering with m35palswap - I've just written a new version (with a shorter name!) that takes its input from an ini file. Also, I've confirmed that, on my box at least, when I copy a ramdisc over /bin I can't play mp3s, wmas or divx files. ISOs seem fine though. It appears that fileplayer.bin has problems loading the file - it just gives up with the audio files and sits there trying to load the file forever with video - from HD or network. I'm still assuming it's a memory problem so I'm going to take a look at patching the palette in memory.

The first task is to search the memory for a pattern of bytes in the pallete. If not copying dvdplayer to ramdisk this should find the palette once, meaning it just uses the copy stored in dvdplayer, or twice, meaning it probably copies it elsewhere in memory. (is it possible there's a memory mapped part of the video controller that points to the palette?)

I've had a look at the memory map stuff on the wiki, but it's left me a bit confused. What memory areas should I be searching? One possibility is to repartition my drive so I've got a FAT partition, mount that rw and dump the whole of memory to that - but I'd rather do it in smaller chunks!

Lastly - one way I can see extended configuration options working for both diskless and HD-enabled MG35s is to store the path of the extended configuration file in NVRAM. That way it can be stored on either an smb share or a folder on the HD and it reduces the amount of NVRAM we need to use for config information.

I'm still assuming it's a memory problem so I'm going to take a look at patching the palette in memory.


That's why I've added the dvddir variable to the new sashrc. If your phase1 copies dvdplayer.bin to /phase2 (and hacks it along the way) then changes dvddir to /hosts, then the only extra memory is what dvdplayer.bin takes in the ramfs. This is about half of what all of /bin takes.


I've had a look at the memory map stuff on the wiki, but it's left me a bit confused. What memory areas should I be searching? One possibility is to repartition my drive so I've got a FAT partition, mount that rw and dump the whole of memory to that - but I'd rather do it in smaller chunks!


Search from 0x1008000 to 0x1F7FFFF - this is all of memory from the base of the kernel to the start of the video area.

Ian

Lastly - one way I can see extended configuration options working for both diskless and HD-enabled MG35s is to store the path of the extended configuration file in NVRAM. That way it can be stored on either an smb share or a folder on the HD and it reduces the amount of NVRAM we need to use for config information.

I guess that depends on what level of configuration we want to provide - full scripting or a selection of settings. My view is that the former is great for development but the latter is better for end users.

So, phase 1/2 off HD for development, and NV parameters for end-user type stuff.

There is also the technical difficulty of mounting an SMB share during phase 1. We'd need to fish all the IP config out on NV and use ifconfig and dchpd to get it all running (and then tear it all down so that setup can do it again!)

Ian

And to follow that up, attached is the source for mgpal - a utility to patch the palette in dvdplayer.bin using information from an ini file.

(I've got to get a cross compiler working - I might see if a friendly geek at work can give me root access to a server to install the arm-elf toolchain then I can vpn/telnet in from home...)

Example Usage: mgpal /cdrom/zz_init/config/mg35.ini /bin/dvdplayer.bin

This is only of any use in a phase1 script where dvdplayer.bin has been copied to ramdisc.

The ini file can be in either DOS or UNIX format and should be like...

[palette]
colour000=808080
colour096=ff0000
colour247=0077b3

It's pretty well error trapped but a bit fussy about the exact format of the colour= lines

The palette index must be 3 decimal digits, with leading zeros if necessary, and no greater than 255.

There must be no white space (or anything else other then the end of the line) after the hex number of the colour.

The colour can be 6 (rrggbb) or 8 (aarrggbb) hex digits - if it's 8 digits the first 2 digits are stored as the alpha value. THIS HAS NOT BEEN TESTED ON AN MG35 YET!

Any line not conforming to the above will be ignored - so you can use the standard ini file convention of "commenting out" a line with a single quote (') at the beginning.

And to follow that up, attached is the source for mgpal - a utility to patch the palette in dvdplayer.bin using information from an ini file.


I have attached a new zip with executable added.

Ian
P.S. I don't understand the warning that gcc gives on line 220. It claims there's a compare between pointer and integer, but everything looks to be a char *

(is it possible there's a memory mapped part of the video controller that points to the palette?)


Did you look at the "top 512k" dump I posted? The first 8 bytes are a mystery, then there might be 256 x 4 byte palette entries (but a different format - YUV?) and then what looks like video memory.

Ian

(I've got to get a cross compiler working - I might see if a friendly geek at work can give me root access to a server to install the arm-elf toolchain then I can vpn/telnet in from home...)


He will need root access to install arm-elf-gcc but you'll just need a user shell to build everything.

The other option is to throw an old PII 100 in a corner as a headless build/play machine. The machine I use doesn't have monitor, keyboard or mouse and has been running happily since our last power cut.

Ian

I have attached a new zip with executable added.

Ian
P.S. I don't understand the warning that gcc gives on line 220. It claims there's a compare between pointer and integer, but everything looks to be a char *

maybe its because you didnt #include <string.h>

IP.S. I don't understand the warning that gcc gives on line 220. It claims there's a compare between pointer and integer, but everything looks to be a char *

Compiles without any warnings in cygwin - but the comment from tohands about string.h makes sense - I did say my C was rusty :(

Anyway, I like web interfaces on embedded gear. :)
And so do I! :D

I'm actually thinking of buying a cheap PC just to use as a unix box for mg35 development. One part of me does think that if I do that why not just stick it under the TV and use it **instead** of the MG35? But where's the fun in that? :D
You don't have to do that to get a true Linux dev. environment. Just download VMware Player (for free) (http://www.vmware.com/products/player/), a pree-built VM of you taste (http://www.vmware.com/vmtn/appliances/directory/community.html) and off you go...

Compiles without any warnings in cygwin - but the comment from tohands about string.h makes sense - I did say my C was rusty :(

My C knowledge is all shiny, new and deeply limited. :)

The additional #include kills the warnings very nicely. But I guess this is ornamental.

Ian

Did you look at the "top 512k" dump I posted? The first 8 bytes are a mystery, then there might be 256 x 4 byte palette entries (but a different format - YUV?) and then what looks like video memory.

Maybe need to put something like this on the wiki?

YUV Colorspace
YUV colorspace is a bit unusual. The Y component determines the brightness of the color (referred to as luminance or luma), while the U and V components determine the color itself (the chroma). Y ranges from 0 to 1 (or 0 to 255 in digital formats), while U and V range from -0.5 to 0.5 (or -128 to 127 in signed digital form, or 0 to 255 in unsigned form). Some standards further limit the ranges so the out-of-bounds values indicate special information like synchronization.

YUV - RGB Conversion
There are many slightly different formulas to convert between YUV and RGB. The only major difference is a few decimal places. The CCIR 601 Standard (now ITU-R 601) specifies the correct coefficients. Since I'm lazy and haven't looked up this spec, I don't know if the following coefficients are correct or not. In any event, I've used them for many conversions with no obvious discoloration.
These formulas assume U and V are unsigned bytes.

R = Y + 1.4075 * (V - 128)
G = Y - 0.3455 * ((U - 128) - (0.7169 * (V - 128))
B = Y + 1.7790 * (U - 128)

Y = R * .299000 + G * .587000 + B * .114000
U = R * -.168736 + G * -.331264 + B * .500000 + 128
V = R * .500000 + G * -.418688 + B * -.081312 + 128

Blending YUV colors
Blending between colors in YUV form is very easy, and shouldn't require any conversions to other colorspaces. In fact, blending in YUV is the same as blending in RGB; Just interpolate between the components.

For example, to mix two colors in equal parts, the result will be:
(Y1+Y2)/2, (U1+U2)/2, (V1+V2)/2

Adding colors in YUV Colorspace
Adding colors in YUV is a bit more tricky. The Y and UV components need to be treated differently, since they represent different things.

Adding the Y channels is easy; You just add them.
Y3 = Y1 + Y2.

It's probably a good idea to saturate the Y value to 255 or 1.0.

Adding the U or V channels is more involved. You have to average the two input values.
U3 = (U1 + U2)/2, V3 = (V1 + V2)/2.

U and V should saturate as well. Otherwise, several additions can cause unusual color distortions when combined with high Y values.

JPEG/JFIF - RGB Conversion
JPEG/JFIF files store compressed images in a YUV-like colorspace that uses slightly different coefficients to convert to RGB. These formulas are:

R = Y + 1.40200 * (U - 128)
G = Y - 0.34414 * (V - 128) - 0.71414 * (U - 128)
B = Y + 1.77200 * (V - 128)

You don't have to do that to get a true Linux dev. environment. Just download VMware Player (for free) (http://www.vmware.com/products/player/), a pree-built VM of you taste (http://www.vmware.com/vmtn/appliances/directory/community.html) and off you go...

I might try this. Can you recommend a distro/VM to install? I don't need all this new-fangled X-Windows/KDE stuff :)

Presumably I'll need a FAT32 or ext2 partition to install to, will some run from NTFS?

Also, if a VM's running on my desktop, does it get its own IP address so I can telnet into it from my laptop?

I might try this. Can you recommend a distro/VM to install? I don't need all this new-fangled X-Windows/KDE stuff :)

Presumably I'll need a FAT32 or ext2 partition to install to, will some run from NTFS?

Also, if a VM's running on my desktop, does it get its own IP address so I can telnet into it from my laptop?You dont have to install it at all (that's the whole point). The VM live in its own files (just copy to any file system) and yes it get's its own networking (trough a virtual network device on the host OS and then NAT, bridget networking or host only).

I would personally recommend Xubuntu 6.06.1 LTS Standard Install with VMware Tools (http://www.vmware.com/vmtn/appliances/directory/497) if you want it all (desktop, apt etc.) or Debian 3.1 (Sarge), minimal install (http://www.vmware.com/vmtn/appliances/directory/13) if you want to keep it compact (but why if you got the disk space for the VM files and some CPU to spare)...

Maybe need to put something like this on the wiki?


I didn't there was enough to go on.

"Here is a big file of an area that might ot might not be video memory in an unknown format". :)

I was kind of hoping that someone would get stuck in and figure out a bit more. If we can just belt a palette straight in there then life gets easier. Ditto if we can get screen grabs - no more colour hunting!

Ian

@EmuMannen

Did you see this post over at the Yahoo group?

http://groups.yahoo.com/group/mg-35_firmware_mods/message/106

Any Ideas??

Any Ideas??
None! :eek: Havent had the chance to tryout YPbPr (component) yet...

None! :eek: Havent had the chance to tryout YPbPr (component) yet...

He he - Well I just tried it and v 3.0 displays perfectly - so presume he must have a setting wrong somewhere , unless Pal displays different to NTSC? , but I doubt that would be the case , ie if it works on NTSC for me , surely it wil be ok in PAL also , as the MG just does a convert?

I use a component connection and it's fine - and component doesn't "know" anything about PAL or NTSC - the only difference would be the frequency (50/60Hz) not the colour encoding.

I didn't there was enough to go on.

"Here is a big file of an area that might ot might not be video memory in an unknown format". :)

I was kind of hoping that someone would get stuck in and figure out a bit more. If we can just belt a palette straight in there then life gets easier. Ditto if we can get screen grabs - no more colour hunting!

Ian

I started looking at it at work, but 5:30 came along. Also I turned my PC off so I can't access my RGB-YUV spreadsheet I started on via the vpn :(

Can we dump the video memory with dd? It would be useful to compare with the latest pallete, which has a bit more variation than the original!

Just had an idea for a quick experiment with memory...

Booted mg35 with no phase1/phase2 scripts

Divx plays ok

cp /bin/dvdplayer.bin /phase2/a

Divx plays ok

cp /bin/dvdplayer.bin/phase2/b

Divx won't play...

So it looks like we do have room for one copy of dvdplayer.bin on a ramdisc.

None! :eek: Havent had the chance to tryout YPbPr (component) yet...
Mine is connected via component and the GUI is fine... Al

I started looking at it at work, but 5:30 came along. Also I turned my PC off so I can't access my RGB-YUV spreadsheet I started on via the vpn :(

Can we dump the video memory with dd? It would be useful to compare with the latest pallete, which has a bit more variation than the original!

dd can't dump video memory as /dev/mem doesn't cover this area.

The attached dumptop utility will write videomem.bin to the current directory (so make sure it's writeable!)

Of course, I might have got the addresses wrong, but it looks promising by eye.

I think I need to write some good peek and poke utilities that can handle ranges, files, etc.

Ian
P.S. Here is the source of dumptop

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include <stdbool.h>

int main ()
{
FILE * outfile;

// ************************************************************ **************
outfile = fopen("videoram.bin", "wt");
if (outfile != NULL) {
fwrite ((char *) 0x1F80000, 1, 0x80000, outfile);
fclose(outfile);
exit(EXIT_SUCCESS);
} else {
printf("Failed to write file");
}

} // end of main

So it looks like we do have room for one copy of dvdplayer.bin on a ramdisc.

Splendid!

However, being a silly sod, I managed to leave the dev MG-35 and serial lead at work. I had 20 minutes to shutdown my notebook, pack bags, cycle 5 miles up a 300ft net climb, and meet my wife (on time!) Sadly, I forgot an important part!

Anyway, I'll grab it Sunday AM and make new firmware with the ability to specify where dvdplayer.bin is.

I may also try running sashrc with hush.

Someone had problems running scripts with hush. More info. please!

Ian

I've tried some searches for compatibility between the MG-25 and the MG-35 in terms of the firmware, and haven't found much...I want the MG-25 because it's smaller, and I want to put it in my wife's car. The car power adapter issue seems easier to solve for the MG-25.

If the firmwares are not compatible, is there a comparable group that is modding the firmware for the MG-25?

I've tried some searches for compatibility between the MG-25 and the MG-35 in terms of the firmware, and haven't found much...I want the MG-25 because it's smaller, and I want to put it in my wife's car. The car power adapter issue seems easier to solve for the MG-25.

If the firmwares are not compatible, is there a comparable group that is modding the firmware for the MG-25?

I own an MG-25 but it's on long-term/permanent loan to my Brother-In-Law in London. It's *very* similar to the MG-35 in many respects.

If it's got a serial port, and the loader works the same, then it's going to be well worth you trying to make some .upgrade files for the MG-25. A lot of what's been done for the MG-25 can just be ripped from the cramFS and used directly, as can most of the utilities.

Ian

I own an MG-25 but it's on long-term/permanent loan to my Brother-In-Law in London. It's *very* similar to the MG-35 in many respects.

Ian

Ref the Mg-25 , this is a interesting link..


http://blade.lansmash.com/?p=123

sadly there is no firmware modding project atm...

Interesting fact is that there is a LG branded version , and the firmware is interchangeable between the two units...

At first I wondered , why LG? , then I realised that LG put alot of the venture capital money into Al Tech a few years ago - hence the "tie in" btween the two products..

Dont think that the LG firmware has been updated in quite a while...

On reading a little about the Tvix M-5000U , I now notice that the latest firmware 1.7.3 now contains a R/W FTP server - might be worhh a quick look at the fimware/Kernal to see if anything can be ported to the MG-35?

#include <stdio.h>

int main ()
{
FILE * outfile;

// ************************************************************ **************
outfile = fopen("videoram.bin", "wt");
if (outfile != NULL) {
fwrite ((char *) 0x1F80000, 1, 0x80000, outfile);
fclose(outfile);
exit(EXIT_SUCCESS);
} else {
printf("Failed to write file");
}

} // end of main

Someone had problems running scripts with hush. More info. please!

1. starting hush in telnet session locks the box. OK, it's not locked, but just echoes the keyoard to the screen.

2. I don't remember exactly, and I cannot test it right now since I'm 600km from home :) Pretty sure I just changed the bangshell for phase1 or phase2 (or some other script called in them) to /bin/hush, and the box didn't boot: the blue power LED was blinking, and blinking, and blinking... Had to get the CF out and revert the bangshell to /bin/lash, and everything was OK. I can try again on Tuesday, when I get back home.

1. starting hush in telnet session locks the box. OK, it's not locked, but just echoes the keyoard to the screen.


Yup, it does that. BusyBox shells are a bit of a mess particularly with terminal stuff.


Pretty sure I just changed the bangshell for phase1 or phase2 (or some other script called in them) to /bin/hush, and the box didn't boot: the blue power LED was blinking, and blinking, and blinking... Had to get the CF out and revert the bangshell to /bin/lash, and everything was OK. I can try again on Tuesday, when I get back home.

I might also get a chance to play on Sunday. I really do want us to use a better shell for sashrc and the phase stuff so that we can have some conditionals.

Ian

On reading a little about the Tvix M-5000U , I now notice that the latest firmware 1.7.3 now contains a R/W FTP server - might be worhh a quick look at the fimware/Kernal to see if anything can be ported to the MG-35?

I'll see what I can track down, but what's wrong with our current FTP server? I've happily read and written to/from my FAT32 partition with it.

Ian

Creating graphics for the MG-35 is a real PITA! I have therefore spent my time automating stuff. Problem is that I hate Photoshop’s built in scripting and not everyone prefer Photoshop. I am therefore creating Python scripts (to keep it free and platform independent) aimed towards automation of the most time consuming actions.

Creating a global palette out of a set of new graphics is not only time consuming it’s boring as well. Below is a small script I made using Python 2.4 and the Python Imaging Library (PIL). It (recursively) scans a directory tree for graphical images (supported by PIL) and then creates a merged image out of any supported graphics found.

The new image is in RGB format so it will contain all colors used if saved as a 24-bit PNG-image (default). That image can then be post processed in Photoshop or any other imaging application to create a new global 8-bit palette.


'''
Script to merge a file tree of images into one RGB image
This script takes two arguments
arg1 (manadatory) path to root of imput files
arg2 (optional) filename of new merged image (defaults to mergedImage.png)

Note file extension of arg2 determens the file format of the new image
This script requires Python Imaging Library (PIL)
http://www.pythonware.com/products/pil/
'''

import os, Image
from sys import argv

def createInfoList(filesPath):
infoList = []
for root, dirs, files in os.walk(filesPath):
for name in files:
try: # Is this a gfx file?
fileName = os.path.join(root, name) # Yes, get info.
gfx = Image.open(fileName) # Note, reads just header
infoList.append((fileName, gfx.size)) # Save name and size
except IOError:
pass # No, do nothing
return infoList

def createNewImage(infoList):
mergedWidth = 0 # Width needed for merged graphics
mergedHeight = 0 # Height needed for merged graphics
for x in infoList:
w = x[1][0] # Get width from tuple for this image
h = x[1][1] # Get height from tuple for this image
mergedWidth = mergedWidth + w
if h > mergedHeight:
mergedHeight = h
return Image.new('RGB', (mergedWidth, mergedHeight))

def drawNewImage(infoList, newImage):
xOffset = 0
for x in infoList:
fileName = x[0] # Get filename from tuple for this image
gfx = Image.open(fileName)
targetRect = (xOffset, 0, gfx.size[0]+xOffset, gfx.size[1])
xOffset = xOffset+gfx.size[0]
newImage.paste(gfx, targetRect)

if __name__ == '__main__':
try:
filesPath = argv[1] # Get root path to input files
try:
mergedFileName = argv[2] # Do we have a output filename?
except:
mergedFileName = 'mergedImage.png' # If not, set default file name

infoList = createInfoList(filesPath) # Get info about input files
newImage = createNewImage(infoList) # Create new image
drawNewImage(infoList, newImage) # Copy input files to new image
newImage.save(mergedFileName) # Save merged image
except:
print 'Usage:', argv[0], '<path to graphical files> [merged file name]'

I might also get a chance to play on Sunday. I really do want us to use a better shell for sashrc and the phase stuff so that we can have some conditionals.


Thinking about it, I'll probably push MG35-1.4.4.4-pre0 out without any more changes. It's got things in to help palette hacking in dvdplayer.bin, and to make life better for people playing with mathopd, so it's a worthy release.

I suggest we got final with MG35-1.4.4.4 once the palette is spot on so the new graphics are thoroughly usable.

We can then be adventurous with the MG35-1.4.4.5 series! I'd like to add the nbtscan/nas stuff, but need to improve my bash scripting and sed skills if I'm to tackle it. It would also be good to get enough web/cgi stuff in for us to be able to change the name of the NAS server via the web interface.

Ian

I think where Teddystacker is heading is that the M-5000A supports ntfs r/w and it also seams to have nfs as well. It is the newer sigma chip EM8621 however. So maybe the ntfs module might work for the kernel in our box, or we might beable to find out which version of the driver it is so we can compile it to work on ours.

I think where Teddystacker is heading is that the M-5000A supports ntfs r/w and it also seams to have nfs as well. It is the newer sigma chip EM8621 however. So maybe the ntfs module might work for the kernel in our box, or we might beable to find out which version of the driver it is so we can compile it to work on ours.

I'd love to find ntfs rw and/or ext2 and/or nfs functionality that we can add without rebuilding our kernel, but all my initial attempts got me no-where very quickly.

I guess the big question is whether we expect Al Tech to release their kernel sources (in which case life becomes run very quickly!) or not. If "not" then we do need to start looking at fall-back solutions. My favourite is to reverse engineer Al Tech's additions. At least that way we get to build new kernels rather than always having to work hard for every extra bit of functionality.

Ian

The new image is in RGB format so it will contain all colors used if saved as a 24-bit PNG-image (default). That image can then be post processed in Photoshop or any other imaging application to create a new global 8-bit palette.


Do you then need to fix some palatte entries because of drawn text/boxes generated by dvdplayer.bin? I guess this is what all the colour hunt is about.

Do you think you're now self-sufficient regards colour hunt?
I can help more this weekend, but really don't think I have a divx/xvid with subtitles. Anything else I can probably do.

But upgrading to the hunt firmware, and then back to something prettier, is dead easy and safe. Someone on the Yahoo list just managed to do it by accident and was still complimentary about the new graphics!

Ian

Do you then need to fix some palatte entries because of drawn text/boxes generated by dvdplayer.bin? I guess this is what all the colour hunt is about.

Do you think you're now self-sufficient regards colour hunt?
I can help more this weekend, but really don't think I have a divx/xvid with subtitles. Anything else I can probably do.

But upgrading to the hunt firmware, and then back to something prettier, is dead easy and safe. Someone on the Yahoo list just managed to do it by accident and was still complimentary about the new graphics!

Ian
I will try to take some time and walk through all 256 indexes with unique values. It should be doable if I can patch the palette in runtime (is it possible now and how) or pach dvdpalyer without having to build a new firmware. I probably patch the whole palette to a grey ramp and then patch a 16-index segment with unique colors. Iterating that 16 times should make it possible to map every color used in the palette (just have to remember to open every dialog, option, etc. there is). Hard work but worth while I guess. Could someone please run me trough how patching dvdpalyer can be carried out today (without having to rebuild a new firmware 16-times)?

It should be doable if I can patch the palette in runtime (is it possible now and how) or pach dvdpalyer without having to build a new firmware.

It can be done now with the phase 1/2 scripts that were posted as a patched dvdplayer.bin can be copied to /bin. Either patch dvdplayer.bin on a PC, or use the new mgpal utility to patch on-the-fly. I'll probably include some sample scripts, mgpal, and bigbox with future releases.

The only problem is that dvdplayer.bin won't play all media with the current arrangement due to what seem to be memory issues.

The other option is to wait until tomorrow when I hope to release the new firmware that let's us run dvdplayer.bin from another directory, and this should give us a run-time patchable dvdplayer.bin with all functionality still working.

I'd release this today but the dev MG-35 is at work as is my serial lead.

I suggest you wait until the job will be easier for you and let's get it all right in one pass.

Ian

I can help more this weekend, but really don't think I have a divx/xvid with subtitles. Anything else I can probably do.

If you save this text as a .srt file in the same folder and with exactly the same name as your .avi it should display some test titles.
1
00:00:01,600 --> 00:00:09,600
Subtitle color test

2
00:00:10,600 --> 00:00:19,600
Subtitle color test Subtitle color test

3
00:00:20,600 --> 00:00:29,600
Subtitle color test

4
00:00:30,600 --> 00:00:19,600
Subtitle color test Subtitle color test

Ian,

I've been going throught the kenerl source from sigma trying to do a make oldconfig (and make config) on their source. It seams to be either missing modules or else they just hacked out the part's they didn't require and manually edited the kernel.

I have found a module in the drivers/char dir called ite_gpio. Any chance this could be similar to the gpio_enable_irq that the kiss kernel was complaining about. The source talks about ite_gpio_irq_handler at the end of the file.

I'm going through looking to see if it contains all the modules for the IR and the buttons,

Nick

I'm uploading MG35-1.4.4.4-pre0 to Yahoo. I have upgraded to this via the GUI and then back to an older version without problems.

This now has sashrc changes to support running dvdplayer.bin from elsewhere. See sample phase1/2 scripts - read them carefully!

I have run dvdplayer.bin from phase2 and played avis and ISOs

Ian

I've been going throught the kenerl source from sigma trying to do a make oldconfig (and make config) on their source. It seams to be either missing modules or else they just hacked out the part's they didn't require and manually edited the kernel.


Have you also looked at the KiSS version and the one that Al Tech released? I have a .config that gets a KiSS kernel building if you want it. However, everything stops when setup tries to insmod the proprietary modules.

You really need a serial lead for this work. You can then download and run new kernels and get all the printk outout.


I have found a module in the drivers/char dir called ite_gpio. Any chance this could be similar to the gpio_enable_irq that the kiss kernel was complaining about. The source talks about ite_gpio_irq_handler at the end of the file.

I'm going through looking to see if it contains all the modules for the IR and the buttons,


I doubt it's related to the missing symbols, but I'm really glad that someone else is looking at this stuff. I really am not too experienced at kernel hacking.

Ian

If you save this text as a .srt file in the same folder and with exactly the same name as your .avi it should display some test titles.


Great, thanks!

Box reflashed with the Newgui-3a-hunt firmware and subtitles working.

Subtitles are a light green.

Subtitle setup dialog has a white background, magenta unselected text an light grey selected text.

Ian

I've been playing with MG35-1.4.4.4-pre0 a bit more.

I edited phase1 to read -
# Take a copy of dvdplayer and tell sashrc the new directory
/bin/cp /bin/dvdplayer.bin /phase2
$phasedir/bin/mgpal $phasedir/config/mg35.ini /phase2/dvdplayer.bin
export dvddir=/phase2

This copied the real dvdplayer.bin from /bin to /phase2, runs mgpal on it (mgpal and .INI on the HD) and then tells sashrc to run the new dvdplayer.bin.

You will need the phase1/2 from the MG35-1.4.4.4-pre0 zip, to make the edits as shown, save these scripts to /cdrom/recycler, put mgpal in /cdrom/recycler/bin and mg35.ini in /cdrom/recycler/config

If you're not using /cdrom/recycler then you also need to edit the export of phasedir in phase1.

So, we should now be able to slap new .INI files on the box, reboot, and immediately see the changes. The .INI files can be sent via ftp as the HD is remounted as r/w.

Of course, you can leave it copying the dvdplayer.bin from the HD and put one patched on a PC directly onto the HD.

Ian

And to follow that up, attached is the source for mgpal - a utility to patch the palette in dvdplayer.bin using information from an ini file.
...

Below is a new Python script that will print out (to stdout) an image files palette in andy666's mgpal expected INI-format...

'''
Script to print out an image files palette in "INI" format to stdout
This script takes one argument
arg1 (manadatory) path to image file containing palette

"INI" format as follows:
[palette]
colour000=RRGGBB
colour001=RRGGBB
colour002=RRGGBB
...

This script requires Python Imaging Library (PIL)
http://www.pythonware.com/products/pil/
'''

import Image
from sys import argv

def splitFloor(seq, m):
# Distribute the seq elements in lists in m groups according to
# quasi equitative distribution (increasing order)
n, b, newseq = len(seq), 0, []
for k in range(m):
a, b = b, b + (n + k) // m
newseq.append(seq[a:b])
return newseq

def printPalette(gfx): # Print palette to stdout in "INI"-format
palette = gfx.getpalette()
entries = len(palette) // 3
colours = splitFloor(palette, entries)
print '[palette]'
for i in range(entries):
print 'colour%03u=%x%x%x' % (i, colours[i][0], colours[i][1], colours[i][2])

if __name__ == '__main__':
try:
fileName = argv[1] # Get file name of input file
gfx = Image.open(fileName) # Try open file
if gfx.palette: # Does it contain a palette?
printPalette(gfx) # Yes, print palette...
else:
print 'No palette in:', fileName
except:
print 'Usage:', argv[0], '<file name>'

Bum.

I just spent 30 minutes learning enough bash shell and sed syntax to write an nbtscan replacement.

It worked a treat on my Linux box.
And totally crashed and burned on the MG-35 - errors from hush about bad syntax and features it didn't support, and then a big fat hang at the end.

I can code this up in C, but I'm not exactly doing back-flips about it. We really need a good shell. :(

Aborted "bash" script below if anyone can see a better way to take this forwards.

Ian

#!/bin/hush

getnameandip ()
{
export nasname=`mgnv "%s" s:252`
# export nasname=mary # For testing!

if [ $? -ne 0 ]
then
return 1
fi

case $nasname in
"" | "loader.bin" )
return 1
;;
* )
# lookup ip address
export nasip=`ping -c 1 $nasname | grep PING | sed -e 's/[^(]*(//' -e 's/)[^)]*//g'`
return $?
;;
esac
}

getnameandip

if [ $? -eq 0 ]
then
mkdir /net/$nasname # create directory in /net - ignore failure
echo -e "${nasip}\t${nasname}" > /hosts/hosts
else
echo /sbin/rbin/nbtscan $*
exit $?
fi

Ian,

Am I correct in thinking MG35-1.4.4.4-pre0 or MG35-1.4.4.4-pre is really only a "developer" release? ie no different for "the user in the Street" than the previous v 3.0 GUI release?

Just want to make sure , as already had a couple of emails on it..

We really need a good shell. :(
Maybe worth trying the Minix shell (enable msh in busybox, should work under uClinux)...

Ps. Both bb-msh and bb-hush seems to be possible alternatives...

Maybe worth trying the Minix shell (enable msh in busybox, should work under uClinux)...

Ps. Both bb-msh and bb-hush seems to be possible alternatives...

hush seems slightly broken and can't handle much of what I wrote.
msh seems to hang the box pretty much immediately.

I'm sure that msh could be made to work, but lots of debug is required. I threw some in and it seems to die almost immediately.

Ian

Ian,

Am I correct in thinking MG35-1.4.4.4-pre0 or MG35-1.4.4.4-pre is really only a "developer" release? ie no different for "the user in the Street" than the previous v 3.0 GUI release?

Just want to make sure , as already had a couple of emails on it..

Yup, just the few changes I listed, most of which is to make development (particularly dvdplayer.bin colour hunting) easier.

But given the generalised nature of the phase 1/2 stuff, and the huge amount that's still to be done, the more people we have trying out different ideas the better.

Ian

By the way, has anyone managed to get the resolver working? I haven't hunted around to see what's missing, but it wasn't working for me on some quick tests.
Ian

Looking through the Kiss kernel there is an option under the davicom network adaptor to "Please specify which GPIO is used as interrupt line". Could this be what the error was about when using the Kiss kernel?

Nick

hush seems slightly broken and can't handle much of what I wrote.
msh seems to hang the box pretty much immediately.
I know it's not a shell but what about Tcl or Lua for scripting?

I know it's not a shell but what about Tcl or Lua for scripting?

There has been a lot of Lua discussion on the busybox list lately. It's about 90kB, so not too big, but is slow. But if anyone wants to try building either/both of these then I'll be very interested to see the results.

If I get time today, I'll see what we can do with lash (very little!) and what actually works in hush. I can probably do a less elegant script with lots of goto. :)

But I also want to get the resolver working. /etc/resolv.conf will need to point to somewhere in hosts we udhcpc can write to it (assuming udhcpc even asks for a DNS server!). But there might be other issues.

If I can get enough scripting, and a working resolver, then I can drop in the nbtscan replacement, which actually gets us additional "man in the street" unfunctionality!

Ian

Looking through the Kiss kernel there is an option under the davicom network adaptor to "Please specify which GPIO is used as interrupt line". Could this be what the error was about when using the Kiss kernel?

Nick

It's maybe the other end of that. The 8511 has loads of pins, and each will have loads of functions. The extra kernel bits will be involved with configuring the exact function of these pins, including interrupt settings.

Ian

But fortunately I don't think rebuilding udhcpc is too difficult and Al Tek have given us this source! So, we can drop the IP and name of the DNS server into /etc/resolv.conf - I must admit I'm wooly regards how the chain of resolving works on Linux. Time to learn. :-)


OK, learning done and new udhcpc created. This fills in the information into /etc/resolv.conf so that we can now ping and nslookup machines by name.

Gotchas -
1) There can be more than one DNS server. My code doesn't handle this.
2) My code doesn't put "domain" and "search" entries into resolv.conf - are they needed?

Regards (1) a good C coder could easily add this, but I'm not sure if the list is comma or space delimited. Anyone got a setup where your DHCP returns more than one DNS server who could try my new udhcpc and see? All it needs is running - you don't even need to kill the old one, and the required info. goes to stdout.

Ian

I've been peeking around in the top of memory and it does appear that the pallete is where we (well, gadgetmind) thought it might be.

The first 3 colours in my dvdplayer palette are:

ff cc 00 (00) 58 8b dd (00) fa c0 bc (00)

Applying emumannen's formulae to these gives..

c4 11 aa (--) 85 b2 60 (--) d1 74 9d (--)

and the first 12 bytes of the possible palette in video memory are

(ff) b9 1f a5 (ff )82 ac 64 (ff) c4 76 9a

which seems consistently pretty close to me!

I'll try to get a chance to look see if the alpha values make any difference later...

Of course, what I really need now is a binary to poke values into video memory ;)

Of course, what I really need now is a binary to poke values into video memory ;)

OK, really cheesy peek and poke attached.

Usage -
/hosts/home/armbits # ./peek 0x1F80000
Value at 0x1f80000 = 0x3e
/hosts/home/armbits # ./poke 0x1F80000 45
/hosts/home/armbits # ./peek 0x1F80000
Value at 0x1f80000 = 0x2d
/hosts/home/armbits #

No error checking, should handle decimal or hex.

Ian

I have now officially given up trying to write anything even vaguely complex in script for this box. hush is broken and I can be bothered fixing it. lash is lame, ash won't build on uClinux and msh takes the box out.

busybox is due a totally new shell in a few months and the maintainer also has good plans for regression testing on uClinux.

So, in the mean time, I'm going to reluctantly do everything in C. I've started work on the nbtscan replacement that will allow a machine to be specified as the preferred/nas server so make network browsing faster.

I'll probably start putting this stuff into release 1.4.4.5 as we really need to not change/break stuff in 1.4.4.4

So, my task list is -
New udhcpc to give us a proper resolver.
nbtscan replacement to support faster browsing to a single server.
mount replacement/bodge to always mount our FAT32 HD as rw (removes needs for a lot of phase 2)
make everything in /bin into links to make testing replacement programs easier.
work out exactly what setup does - helps replace dvdplayer.bin later.
Build a new kernel with loads of yummy bits in it.
Get fuse and djmount working so we get UPnP AV compatibility.
Reverse engineer dvdplayer.bin !!!!!

Did I miss anything?

Ian

Some very odd things going on if you poke around in the videoram. The good thing is that the 4 bytes at 0x1F0008 definitely affect palette entry 0. The bad thing is that poking values directly into those bytes doesn't seem to work as expected. If any value is poked into 09-0B they all then seem to then be 00 when "peeked".

I haven't had much time to play yet - I've also been trying to install arm-elf-gcc into a vmware Xubuntu image. The install seems to work, but arm-elf-gcc gives lots of errors even with a trivial file. Are there options I need to use or env variables I need to set up?

Some very odd things going on if you poke around in the videoram. The good thing is that the 4 bytes at 0x1F0008 definitely affect palette entry 0. The bad thing is that poking values directly into those bytes doesn't seem to work as expected. If any value is poked into 09-0B they all then seem to then be 00 when "peeked".


A whole load of things would be going wrong. One of these is that byte writes don't work in this area. Maybe a word peek/poke would be better.


I haven't had much time to play yet - I've also been trying to install arm-elf-gcc into a vmware Xubuntu image. The install seems to work, but arm-elf-gcc gives lots of errors even with a trivial file. Are there options I need to use or env variables I need to set up?

What sort of errors? The main cflags are -Wl,-elf2flt - getting these as part of the build process, and arm-elf- or arm-elf-gcc in as CC, seems to work with most stuff.

To build a simple proggy use -
arm-elf-gcc -Wl,-elf2flt xxx.c -o xxx

Check the file format with "file" or "flthdr"

Ian

Thanks for that - it was the -Wl, bit I needed!

VMWare is still a pain in the butt tho, for 1001 different reasons. I'm beginning to remember why I hung up my sandals and moved away from Unix in the mid 90s now!

Thanks for that - it was the -Wl, bit I needed!


Great, glad you can now build stuff. Without great scripting, the more people that are building C progs and firing stuff around, the better. The -Wl is very important and one day I'll look up what it means!

You should find that you can unpack the Al Tek GPL stuff and build any of it yourself. Strangely, the udhcpc I built is much bigger than their binary and generates more debug. I suspect we don't have the identical sources and they have done more stripping.


VMWare is still a pain in the butt tho, for 1001 different reasons. I'm beginning to remember why I hung up my sandals and moved away from Unix in the mid 90s now!

I don't know much about VMWare. But despite being fairly new to Linux, I find it a breath of fresh air for software development compared to Windows. With Linux all the tools are at hand and it's easy to explore. But there is a learning curve.

Ian

The more I look at what Al Tek have done with this stuff, the more I'm convinced that they program with a fireaxe!

udhcpc invokes an external program for the various events. OK, this can't be a script (they tried! aborted scripts in GPL release!) but it could be a stand-alone bit of C with all the required customisations.

Instead they have badly hacked scripts.c to directly do what's required. I'm tempted to back out all of this and write the stand-alone program. But there's too much other stuff to do. :(

They have done the same with nbtscan. This returns a nice list of IPs and server names, so dvdplayer.bin could invoke it with popen, get all output, and use pclose to check the error code. It can then parse the output and do whatever is required. Instead they just hack nbtscan - I wondered why it had a new command line argument!

So, as I'm writing a wrapper for nbtscan, I guess I can also back-out their hacks to nbtscan and parse the output to do the necessary.

I notice they also have their own version of Samba. I can't bring myself to look at what they've done in there!

I really hope someone rises to the challenge of a dvdplayer.bin replacement - we won't need all these silly wrappers and bodges.

Ian

I really hope someone rises to the challenge of a dvdplayer.bin replacement - we won't need all these silly wrappers and bodges.
I was playing with the idea of finding an EM851x based device with an UPnP AV rendering implementation. It looks like someone compiled upnp lib for uCliunx on Em8511 a board (but every piece of information I find is in Japanese). Most of the GUI stuff is generated from the UPnP server so such an implementation could be a quick win if we only could get it running with full hardware support.

I stumbled upon a DSM-320 hacking site while searching. It is not EM851x based (it’s EM8476) but it has some information regarding JTAG, maybe worth following up? (http://dsm320.emediasales.com/dsm320/blog/category/Hardware-Hacking)

I was playing with the idea of finding an EM851x based device with an UPnP AV rendering implementation. It looks like someone compiled upnp lib for uCliunx on Em8511 a board (but every piece of information I find is in Japanese). Most of the GUI stuff is generated from the UPnP server so such an implementation could be a quick win if we only could get it running with full hardware support.


If we don't replace dvdplayer.bin, then UPnP AV will need to be via djmount, which requires libupnp and fuse. If we're doing our own UI, then we just need libupnp and away we go!



I stumbled upon a DSM-320 hacking site while searching. It is not EM851x based (it’s EM8476) but it has some information regarding JTAG, maybe worth following up? (http://dsm320.emediasales.com/dsm320/blog/category/Hardware-Hacking)

Yup, that's what we'd need for a full debrick. But we dont even know where JTAG is.

But I've done all sorts to the dev MG-35 regards flashing with duff firmware and the loader is intact. The combination of serial and not erasing the loader at reflash time make things pleasingly safe.

Ian

I've added a "Who Is Doing What?" page to the wiki.

http://mediagate.pbwiki.com/WhoIsDoingWhat

There we can say what we're up to, what we plan to do, and why.

Ian

A whole load of things would be going wrong. One of these is that byte writes don't work in this area. Maybe a word peek/poke would be better.


Trivial code for poke.


#include <stdlib.h>
#include <stdint.h>

int main (int argc, char *argv[])
{
uint32_t *addr;
uint8_t outb;

addr = (void *) (strtol(argv[1], NULL, 0));
outb = (uint8_t) (strtol(argv[2], NULL, 0));
*addr = outb;
exit(EXIT_SUCCESS);
}


A proper peek/poke with a command line a bit like mgnv and the ability to handle bytes, words and strings, would be great. But I can't see it happening so let's just make the two line change to turn this into pokew.

Ian

If you save this text as a .srt file in the same folder and with exactly the same name as your .avi it should display some test titles.
1
00:00:01,600 --> 00:00:09,600
Subtitle color test

2
00:00:10,600 --> 00:00:19,600
Subtitle color test Subtitle color test


I just tested this srt file with my MG-35 with latest firmware from Yahoo group and it works great. This makes me think that AL Tech may have bought the player Crystal. I don't know of many players that accept srt files. Certainly, my Divx player on the pc does not handle srt files. This may be a hint of the dvdplayer binary... Al

I don't know of many players that accept srt files. Certainly, my Divx player on the pc does not handle srt files. This may be a hint of the dvdplayer binary... Al

O, but there are a lot of players that support .srt. Like BSplayer, VLC, vplayer and of course vobsub. This is not a unique feature!

FYI, I got a bit quiet lately, it is because I run into some unforeseen problems with my hobby car. I therefore have to spend most of my spare time in the garage (until sorted). I just wanted you to know that I am still committed to finalizing the GUI (and maybe more) of our homebrew firmware...

Hey all.

Couple of n00b questions, sorry. 70 pages of posts.....! wow

I'm thinking of getting a MediaGate MG-35.

I will copying my dvd collection onto a 400Gb drive, all vob files. Is there any delay in cataloguing when I turn the MG-35 on? I'm pretty sure I read somewhere that if the HDD is fully utilized there can be horrendous power on times as the MG-35 has to catalogue all the files before providing the menus.

Any thoughts?

Thanks all

FYI, I got a bit quiet lately, it is because I run into some unforeseen problems with my hobby car. I therefore have to spend most of my spare time in the garage (until sorted). I just wanted you to know that I am still committed to finalizing the GUI (and maybe more) of our homebrew firmware...

Great news Rob...

Hey all.

Couple of n00b questions, sorry. 70 pages of posts.....! wow

I'm thinking of getting a MediaGate MG-35.

I will copying my dvd collection onto a 400Gb drive, all vob files. Is there any delay in cataloguing when I turn the MG-35 on? I'm pretty sure I read somewhere that if the HDD is fully utilized there can be horrendous power on times as the MG-35 has to catalogue all the files before providing the menus.

Any thoughts?

Thanks all

I have a 320gb in mine , its 75% full atm , and there is * NO* extended bootup time..

Suggest you rip your dvds to .ISO format using Dvdecrypter , will be much nicer to have just a single file per dvd.Iso's play exactly as a dvd would do , ie menus and all..

Bad news is that even with a 400gb rive , you aint going to get that many dvds on there..

I have a 320gb in mine , its 75% full atm , and there is * NO* extended bootup time....
great news, thanks

Suggest you rip your dvds to .ISO format using Dvdecrypter , will be much nicer to have just a single file per dvd.Iso's play exactly as a dvd would do , ie menus and all..
good idea, thanks again

Bad news is that even with a 400gb rive , you aint going to get that many dvds on there..
approximately 60 :(

is there anyway to mod this thing to accept multiple HDD's or a RAID array?

thanks for the help.

great news, thanks



is there anyway to mod this thing to accept multiple HDD's or a RAID array?[/B]

thanks for the help.

Not yet on the MG-35 - being worked on atm , but not sure if this will ever be possible..

But YES on the MG-350HD , as it accecpts EXTERNAL storage Via its USB Host port....

Not yet on the MG-35 - being worked on atm , but not sure if this will ever be possible..

But YES on the MG-350HD , as it accecpts EXTERNAL storage Via its USB Host port....

maybe I will be getting the 350HD instead then. Any pro's and con's I should consider?

where's the cheapest place to find one that ships to Toronto? Lowest price yet is $249USD on eBay through eWaggle...

once again, thanks for your help.

FYI, I got a bit quiet lately, it is because I run into some unforeseen problems with my hobby car. I therefore have to spend most of my spare time in the garage (until sorted). I just wanted you to know that I am still committed to finalizing the GUI (and maybe more) of our homebrew firmware...

Good news that you're still very much onboard. It's been getting quiet here lately, but I guess a few are on holiday.

Sorry about the car. I know how you feel as our Audi A8 has a dodgy wire to the immobiliser coil and I'm going to have to strip off air-bag, steering wheel and lots of other gubbins to replace it. And my wife wants to sell our Mazda MX-5 (Miata) and the "One careful Lady owner" will only wash if I first remove the supercharger I fitted ...

Ian

and the "One careful Lady owner" will only wash if I first remove the supercharger I fitted ...
:D lol

Great, glad you can now build stuff. Without great scripting, the more people that are building C progs and firing stuff around, the better. The -Wl is very important and one day I'll look up what it means!

-Wl,option
Pass option as an option to the linker. If option contains commas,
it is split into multiple options at the commas.

So -Wl,-elf2flt will pass the -elf2flt to the linker, when it will call ld to generate the executable. On its turn, ld will probably call elf2flt tool to convert the executable from ELF to BFLT.

2) My code doesn't put "domain" and "search" entries into resolv.conf - are they needed?
Ian

They are not necessary. They can be used if you want to be able too use
short names for hosts in one or more domains.

Does anyone know how the box gets a list of smb share names?

nbtscan builds /hosts/hosts with "IP name" pairs and also creates directories with the machine names in /net

smbmount can mount a share.

But how does dvdplayer.bin get the list of shares when you select a server?

Ian

They are not necessary. They can be used if you want to be able too use
short names for hosts in one or more domains.

I added the search entry as it was easy and have also got udhcpc to list all available nameservers.

Now back to hacking the new nbtscan ...

Ian

Yeah I just received my serial cable, but at home, and i'm at work, can't wait to try it once.

I've started writing a VB Program to produce MG35 screen dumps based on the output from gadgetmind's dumptop utility.

Results so far...

Standard Startup Screen - http://www.fatreg.net/pics/mg35/mgscreen1.gif
New Startup Screen - http://www.fatreg.net/pics/mg35/mgscreen2.gif

(Note that these have been reduced in size by 50%)

I'm not reading the palette at the moment, just representing the palette indexes as a greyscale.

Things to do before I "release" this:

Add option to read palette either from dvdplayer.bin or an .act file, or possibly reverse engineering it from the YUV palette in the video dump....

Add facility to display color/palette index under mouse cursor...

Display Background image

Do we have any way of remote executing commands? It would be nice to be able to "grab" a screen from the MG35 on the PC...

Does anyone know how the box gets a list of smb share names?

nbtscan builds /hosts/hosts with "IP name" pairs and also creates directories with the machine names in /net

smbmount can mount a share.

But how does dvdplayer.bin get the list of shares when you select a server?

Ian

On a linux console, to list the shares on a selected server, you have to use smbclient -L <ip>. and that binary is not in our firmware.

But how does dvdplayer.bin get the list of shares when you select a server?

I suspect smbmount has an option for that... My idea is to create a wrapper proggie for nbtscan, smbmount and all the other utils. The tool will record the parameters for the nbtscan/smbmount/etc call, and then call the original program. This way we can see in the log the sequence of programs calls, and their parameters.

I've started writing a VB Program to produce MG35 screen dumps based on the output from gadgetmind's dumptop utility.

Results so far...

Looking good! That should grealy help the colour hunt!

Regards running remote commands, it's fairly easy on Linux but ISTR that the windows telnet client is a bit sniffy about redirecting stdin and stdout.

Is the screen all one bit map? Didn't we expect backgrounds and overlays?

Ian

I suspect smbmount has an option for that... My idea is to create a wrapper proggie for nbtscan, smbmount and all the other utils. The tool will record the parameters for the nbtscan/smbmount/etc call, and then call the original program. This way we can see in the log the sequence of programs calls, and their parameters.

Yup, that's where we need to be. It's pretty easy to do with a script

echo $* >> /hosts/command.log
realprogname $*

I keep planning this, but really need my new firmware that has only soft links in /bin as this will make testing this sort of thing dead easy. This new firmware image is done but I haven't had any time to test it.

I should then be able to use scripts in /bin that have "\sbin\rbin\$0 $*" as the second line (all real executables are now in \sbin\rbin"

Next weekend, maybe.

Ian

I'm quick to biting the bullet and ordering one of these. I'm going to get it with a 320GB drive pre-installed and formatted with FAT-32 (still necessary for write access via ftp, correct?)

It's going to cost $237. In your opinion, is this still one of the better (best?) options in the price range for movie viewing? I don't really care about music or pictures.

I read some earlier posts about issues with divx playing, is that really an issue? Most of my stuff being viewed will be downloaded videos and would it would suck if the majority of them didn't work well.

It will probably be another couple years before I get a HD TV so getting the 350HD without a hard drive for the same price as the 35 with a 320gb hard drive doesn't sound as appealing.

Add option to read palette either from dvdplayer.bin or an .act file, or possibly reverse engineering it from the YUV palette in the video dump....


The best way to reverse engineer might be to patch a single palette entry in dvdplayer.bin and see which entry changes and what to. Removes some of the "hunting and fishing"

BTW, one way to grab a screen remotely is to use a web server, and CGI script. If your code will port to C (what is it now?) and we can work in a JPEG library, then it should be pretty easy!

Ian

I've started writing a VB Program to produce MG35 screen dumps based on the output from gadgetmind's dumptop utility.

Results so far...

Thats really cool, I can write a similar dump2png in Python as soon as you figured out the general layout of the dumped memory. :D


Things to do before I "release" this:

Add option to read palette either from dvdplayer.bin or an .act file, or possibly reverse engineering it from the YUV palette in the video dump....

Add facility to display color/palette index under mouse cursor...

Display Background image

I am writing utility scripts at the moment. I have already finished img2act, img2ini and act2ini. I have almost finished ini2act and I plan for ini2img and act2img. That should cover it I guess...

Code could easily be reused for something like reading a palette from ini, act or any other image and then merge it with data from a memory dump to produce a PNG image.

I will make all my scripts avalable as soon as I have finished them. I will also make a simple GUI and "frozen" binaries on Windows (since Windows users usually can't be trusted with a CLI and advanced scripting) if I get the time...

Do we have any way of remote executing commands? It would be nice to be able to "grab" a screen from the MG35 on the PC...
Not yet but it should be simple, just call a dumping util on MG35 from a cgi-script and make the http-server return the dumped memory (as some x-mg35-dumped-video-memory MIME type) and let your application take it from there...

Did anyone else try the mathopd web server yet? Thoughts?
Ian

It will probably be another couple years before I get a HD TV so getting the 350HD without a hard drive for the same price as the 35 with a 320gb hard drive doesn't sound as appealing.

Mg-35 at Ewaggle = $121.95 Delivered

320 Western Digital Caviar SE 320gb @ Newegg = $96.63 Delivered

Total = $218.58

Saving $18.42 = priceless!

Some Divx/Xvid will play fine , others will not , totally depends on what codec / settings used during the encode..

Is the screen all one bit map? Didn't we expect backgrounds and overlays?

What you got is probably the video-buffer (might explain the YUV palette etc., prepared for output by YPbPr etc.). There is probably an overlay buffer somewhere else that is "blitted" over the video buffer. There might be other buffers too if it is double-bufferering etc.

I read some earlier posts about issues with divx playing, is that really an issue? Most of my stuff being viewed will be downloaded videos and would it would suck if the majority of them didn't work well.


A good 95%+ of the stuff we download works very well. Some older stuff has various issues and a tiny smattering of newer stuff. In these rare cases I run the file through autogk (it takes an hour on an Athlon 64 3200+) and these files always play fine.

The MG-35 is far from perfect but it's great for the money. We really love ours and probably 75% of the TV we watch is ********** downloads!

Ian

gadgetmind, I didnt try the mathopd cause I'm not able to compile it. I wish I had something to help me with my freaking cross compiler, I tried last week to make that work, to compile stuff, but anything I tried (following step from the net) always finish with an error and I'm not able to cross compile anything. So my question is, what you guys use to compile on? what is the linux OS (maybe its just a prob with debian) ? is it cygwin? I tried the .sh coming from the wiki and I'm still stuck at the same exact place (with no cross compiler to work with). Now that I have my serial cable, the only step will be to make a cross compiler work.

gadgetmind, I didnt try the mathopd cause I'm not able to compile it. I wish I had something to help me with my freaking cross compiler, I tried last week to make that work, to compile stuff, but anything I tried (following step from the net) always finish with an error and I'm not able to cross compile anything. So my question is, what you guys use to compile on? what is the linux OS (maybe its just a prob with debian) ? is it cygwin? I tried the .sh coming from the wiki and I'm still stuck at the same exact place (with no cross compiler to work with). Now that I have my serial cable, the only step will be to make a cross compiler work.

A cross compiler won't help you with mathopd as I didn't post the source. The .ZIP is executable, instructions and the test files I used. :)

Regards cross compiler, what command are you using and what error do you get?

Ian

Here is the idea:

mkdir /phase2/hdd
mount /dev/discs/disc0/part1 /phase2/hdd -o rw

Using /phase2/hdd as the mounting point instead of /cdrom could solve the remounting of /cdrom as r/o by dvdplayer. I don't have the MG35 here, so I cannot test this until this evening to see if it survives playing an MP3 via the TV interface (which triggers dvdplayer remount).

The dump at the moment is just the overlay - I'll investigate further, probably displaying a chequerboard jpeg (and possibly an mpeg), when I get a chance - and see if the "underlay" is accessible.

One issue I've got to sort out is that the overlay is 640 x (a few lines less than) 480 whereas the background appears to be 720 x 480. I haven't had a chance to compare my new grabs, with background, to a real mg35 screen yet, so I'm not sure if the overlay is stretched/centred or whether the background (which is an odd ratio) is cropped or whatever. I'll be able to find out more after the wife's watched Eastenders!

Decoding the palette's not a problem, I'm pretty confident of the format/location and I can use the formulae Emumannen posted earlier.

With regard to the remote execution - I was thinking about the web server option on the drive home from work. The easiest option might be to write a straightforward uncompressed bitmap image - we can write that "on the fly" with a cgi program so we won't be cluttering the mg with bitmaps or have the overhead of a graphics library. My code's in VB at the moment but is pretty trivial so will port to C easily.

In these rare cases I run the file through autogk (it takes an hour on an Athlon 64 3200+) and these files always play fine. In my neverending quest to convert my mpeg2 program streams with AC3 sound tracks to something that the Mediagate will play, I tried autogk last night with terrible results. Indeed, the resulting avi file would play with sound, but the video looked terrible anywhere there was motion. All edges were severely jagged. What did I do wrong?

I also have an S-MPEG4 avi file which plays on the Mediagate. But it makes annoying errors on the video in a few places. Block artifacts appear, usually trailing something moving fast.

Here is the idea:

mkdir /phase2/hdd
mount /dev/discs/disc0/part1 /phase2/hdd -o rw

Using /phase2/hdd as the mounting point instead of /cdrom could solve the remounting of /cdrom as r/o by dvdplayer. I don't have the MG35 here, so I cannot test this until this evening to see if it survives playing an MP3 via the TV interface (which triggers dvdplayer remount).

My results were positive but also interesting.

The new mount survived and is still rw.
And so did the one on cdrom that I already had! Has anyone verified whether their rw mounted HD on /cdrom switches to ro when they select it from the GUI?

Ian

In my neverending quest to convert my mpeg2 program streams with AC3 sound tracks to something that the Mediagate will play, I tried autogk last night with terrible results. Indeed, the resulting avi file would play with sound, but the video looked terrible anywhere there was motion. All edges were severely jagged. What did I do wrong?


What output file size did you choose? I can send (via snail mail!) some divx files I made with auto gk with the source being DVB-T divx from my PVR.

Ian

The dump at the moment is just the overlay - I'll investigate further, probably displaying a chequerboard jpeg (and possibly an mpeg), when I get a chance - and see if the "underlay" is accessible.

Decoding the palette's not a problem, I'm pretty confident of the format/location and I can use the formulae Emumannen posted earlier.


How far you go with this depends on your goals. To my mind, in order of difficulty they are -
1) Just enough to aid the colour hunt.
2) Enough to allow remote screen grabs.
3) Enough to allow a full memory map of the video memory area to allow a replacement dvdplayer.bin to be written.


With regard to the remote execution - I was thinking about the web server option on the drive home from work. The easiest option might be to write a straightforward uncompressed bitmap image - we can write that "on the fly" with a cgi program so we won't be cluttering the mg with bitmaps or have the overhead of a graphics library. My code's in VB at the moment but is pretty trivial so will port to C easily.

Well, we now seem to have a CGI-capable web server, so I defer to the more webby/graphics people. But, yes, the less we do on the MG-35, the better. Dunno whether it's faster to ship the lot over the ethernet or compress locally. The former is certainly easier!

Ian

And so did the one on cdrom that I already had! Has anyone verified whether their rw mounted HD on /cdrom switches to ro when they select it from the GUI?

Yes, I checked a million times :-) because it bugs me a lot: at times I cannot upload files via ftp. Digging further, found the /cdrom mounted as r/o, although in my phase2 script I had it unmounted and remounted rw. So the sequence is:

- unmount and remount it rw in phase 2
- connect using telnet, see /cdrom is mounted rw
- play a file using the remote
- check again the mount, now /cdrom it's r/o

I remember that just selecting "Local media" or "Network media" was remounting it... Can you try that? I will check again in the evening, but AFAIR these are the steps.

I remember that just selecting "Local media" or "Network media" was remounting it... Can you try that? I will check again in the evening, but AFAIR these are the steps.

Not for me - no idea why! I selected HD and network and the mount was still rw. I'm currently playing a video via network on my box and mount she say -

Anyway, your work around looks good, and this is all local to your own phase2 script, so you can do what you want. But it's worth understanding what's going on for when we crystalise the rw mount into some firmware.

It's to address the non-development need for rw mounts that I suggested a wrapper for mount. But I might follow Al Tek's lead and just hack the BusyBox mount to always mount fat32 as rw. :)

/ # mount
/dev/root on / type cramfs (ro)
none on /dev type devfs (rw)
ramfs on /phase2 type ramfs (rw)
proc on /proc type proc (rw,nosuid)
ramfs on /hosts type ramfs (rw,nosuid,nodev)
ramfs on /net type ramfs (rw,nosuid,nodev)
ramfs on /usb type ramfs (rw,nosuid,nodev)
/dev/discs/disc0/part1 on /cdrom type vfat (rw)
none on /net/TERA/access type smbfs (ro)

Ian

My access to the TV screen has been VERY limited this evening but I've managed the following:

Modified VB prog to convert the YUV palette in video memory to RGB and use that palette, as well as centering the 640x464 overlay image on top of the default background (assuming palette index 245 is transparent)

http://www.fatreg.net/pics/mg35/screen3.jpg

This uses the 1024 byte palette starting at offset 0x08 in the video ram (0x1F80008). Each colour is represented by 4 bytes - AYUV (Alpha seems to work but needs more testing)

These have been converted to RGB using the following formulae: (as supplied by emumannen)

R = Y + 1.4075 * (V - 128)
G = Y - 0.3455 * ((U - 128) - (0.7169 * (V - 128))
B = Y + 1.7790 * (U - 128)

The screen overlay is a simple 640 x 464 1 byte/pixel bitmap starting at offset 0x0408

The current VB6 program just draws the image on the VB form - I need to modify it to try creating an uncompressed bitmap.

I've also discovered that in order to write to the YUV palette you need to write a 32 bit DWORD - word or byte writes just dword align themselves then pad the remaining 2 or 3 bytes with 0. They also write in reverse order e.g.
/phase2 # ./pokedw 0x1f80008 0x123456ff
/phase2 # ./peek 0x1f80008
Value at 0x1f80008 = 0xff
/phase2 # ./peek 0x1f80009
Value at 0x1f80009 = 0x56
/phase2 # ./peek 0x1f8000a
Value at 0x1f8000a = 0x34
/phase2 # ./peek 0x1f8000b
Value at 0x1f8000b = 0x12


I assumed the compiler would know the target "endian-ness" and compensate?

I haven't confirmed these pokes work on screen yet - our TV is still occupied - but my experiments with byte pokes suggest they will.

Sometime in the next few days I'll modify mgpal to write translated ini file palette setting directly to the YUV palette - that will mean we don't need to copy or modify dvdplayer.bin to change the palette.

My access to the TV screen has been VERY limited this evening but I've managed the following:


What you've managed is absolutely brilliant. It's a great example of a little bit of work by one person kicking off something far more significant by someone else and exactly what I hoped for and what we need.


I've also discovered that in order to write to the YUV palette you need to write a 32 bit DWORD - word or byte writes just dword align themselves then pad the remaining 2 or 3 bytes with 0. They also write in reverse order e.g.
/phase2 # ./pokedw 0x1f80008 0x123456ff
/phase2 # ./peek 0x1f80008
Value at 0x1f80008 = 0xff
/phase2 # ./peek 0x1f80009
Value at 0x1f80009 = 0x56
/phase2 # ./peek 0x1f8000a
Value at 0x1f8000a = 0x34
/phase2 # ./peek 0x1f8000b
Value at 0x1f8000b = 0x12


I assumed the compiler would know the target "endian-ness" and compensate?

I haven't confirmed these pokes work on screen yet - our TV is still occupied - but my experiments with byte pokes suggest they will.

Sometime in the next few days I'll modify mgpal to write translated ini file palette setting directly to the YUV palette - that will mean we don't need to copy or modify dvdplayer.bin to change the palette.

What you're seeing is perfectly normal for a little-endian machine

FF is the least significant byte. It's first in memory.
12 is the most significant. It's last.

That you need to write dwords is unusual but by no means unique. Such limitations are very common as hardware designers rarely consider the convenience of software writers. :)

Ian

Hi!

How can I modify the altek fonts to use Central Europeean encoding (mostly for Romanian subtitles)?

Thanks
A.

In my neverending quest to convert my mpeg2 program streams with AC3 sound tracks to something that the Mediagate will play, I tried autogk last night with terrible results. Indeed, the resulting avi file would play with sound, but the video looked terrible anywhere there was motion. All edges were severely jagged. What did I do wrong?The only thing I found working fast, easy and 100% converting MPEG2 TS (recorded on my Dreambox) to MPEG2 PS (working flawless on my MG35) is VideoReDo (http://www.videoredo.com/)

In my neverending quest to convert my mpeg2 program streams with AC3 sound tracks to something that the Mediagate will play

The latest Dr. Divx:

http://labs.divx.com/DrDivX?nl0806=drdivx

converted my files using Home Theater profile, but customized via the Advanced Tab for AC3 audio creates files that play in the MG-35 with 5 channel dolby perfectly. One of the problems I discovered is for high res videos with AC3; Dr. Divx adjusts such files correctly for the MG-35... Al

My access to the TV screen has been VERY limited this evening but I've managed the following:
...
It is brilliant! I wonder how accurate the color conversion is? What RGB value do you get for the lighter blue in the header and footer of that picture for example? Your attached JPEG image fluctuates around #669AFF (could be because of JPEG compression). It should be solid #6699FF.

Something like this should make it both simple and accurate to hunt down colors used by dvdplayer.bin. Reading the color value under the mouse cursor (outputting to a statusbar or similar) would be really handy too...

Keep up the good work!

PS. Attached some of the Python scripts I am making...

The only thing I found working fast, easy and 100% converting MPEG2 TS (recorded on my Dreambox) to MPEG2 PS (working flawless on my MG35) is VideoReDo (http://www.videoredo.com/) Interesting that you mention VideoReDo, which I also own because it's the only app I have located that doesn't force a resolution change on my satellite DV program streams. I noticed that it can make transport streams too, and I tried that option, but the Mediagate doesn't recognize it as a valid movie file type. VideoReDo can also produce a VOB file; my sample conversion produced the only VOB file whose sound my Mediagate will not play! In particular, other VOB files with AC3 sound tracks play fine. :mad:

Not for me - no idea why! I selected HD and network and the mount was still rw. I'm currently playing a video via network on my box and mount she say -

Anyway, your work around looks good, and this is all local to your own phase2 script, so you can do what you want. But it's worth understanding what's going on for when we crystalise the rw mount into some firmware.


I have this in phase1:
/bin/cp -a /bin /phase2/ # Copy bin folder to convenient ramdisk
/bin/mount -o bind /phase2/bin /bin

And this in phase2:
umount /cdrom >>/phase2/phase2.log
/bin/mount /dev/discs/disc0/part1 /cdrom -o rw,fmask=0000


Here is what I have after the boot:

/dev/root on / type cramfs (ro)
none on /dev type devfs (rw)
ramfs on /phase2 type ramfs (rw)
ramfs on /bin type ramfs (rw)
proc on /proc type proc (rw,nosuid)
ramfs on /hosts type ramfs (rw,nosuid,nodev)
ramfs on /net type ramfs (rw,nosuid,nodev)
ramfs on /usb type ramfs (rw,nosuid,nodev)
/dev/discs/disc0/part1 on /cdrom type vfat (rw)

Then I just go to Local Media (using left arrow) and pres Enter on the remote, and here is what I get:

/dev/root on / type cramfs (ro)
none on /dev type devfs (rw)
ramfs on /phase2 type ramfs (rw)
ramfs on /bin type ramfs (rw)
proc on /proc type proc (rw,nosuid)
ramfs on /hosts type ramfs (rw,nosuid,nodev)
ramfs on /net type ramfs (rw,nosuid,nodev)
ramfs on /usb type ramfs (rw,nosuid,nodev)
/dev/discs/disc0/part1 on /cdrom type vfat (ro,nosuid,nodev)

I suggest replacing the /hdd symlink with an empty directory, to be used as a mounting point by developers.

I did some test with mathopd and it doesnt want stay on. I created the smallest config I could do (I attached my config for those who want to see it). when I run
./mathopd < mathopd.cfg &
(the < is the same thing as the -f)
the command did not do any error

so after I tried to run it with
/hosts/mathopd # ./mathopd -d -t < mathopd.cfg & (-d = debug -t = write to log)
[13] 233

and I list my stuff
-rwxr-x--x 1 0 0 1078 Jan 1 09:48 mathopd.cfg
-rwxr-x--x 1 0 0 122040 Jan 1 09:50 mathopd
-rw-r----- 1 99 99 0 Jan 1 09:54 mathopd.pid (0 byte)
-rw-r----- 1 99 99 0 Jan 1 09:54 mathopd.log.19700101 (0 byte)
-rw-r----- 1 99 99 0 Jan 1 09:54 mathopd.errors.197001 (0 byte)

the pid is there, but the prog doesnt run (doesnt saw it in ps -ef)

I will try to read more about mathopd to see if I could know what's going on (cause the log file doesnt help me at all, its empty)

Will we have the ability to run any Python scripts (or comparable scripting language)? I currently have two modded XBox's running XBMC, with one of them being in my car.

When I start my car, I have the Xbox automatically power-on and on startup, I run a Python script that loads a playlist, shuffles the songs, changes to visualization mode and plays the songs.

I'd like to do the same with the MG-35 I just bought for my wife's car.

So I guess I have some wishlist items to add:

- Python script support
- Persistent playlists (m3u or whatever)
- Music visualizations (i.e., like Milkdrop on XBMC)
- External LCD support for displaying MP3 tags, etc.

Here's an example of the XBMC startup script (autoexec.py) that calls another script to play music:

import xbmc
xbmc.executescript('E:\\Apps\\XBMC\\scripts\\startup_music.p y')

Here's the startup_music.py script that does the heavy lifting:

import xbmc, os, string, random, time
# Change this to your playlist(s).
# Written like this: ['path\\to\\plist1', 'to\\plist2', 'plist\\3']
playlist_files = ['E:\\Apps\\XBMC\\albums\\playlists\Default.m3u']
# Dirs(s) to traverse if playlist does not exist. NB: No trailing slash.
# Written like this: ['path\\to\\dir1', 'to\\dir2', 'dir\\3']
# music_dirs = ['F:\\Music\\Mark\\80s']
music_dirs = ['']
# Shuffle playlist if this var equals 1.
shuffle_files = 1


# ---------------------------------------- #
# Code
# ---------------------------------------- #

# Function for adding files to playlist
def add_files(pl, dirname, names):
for filename in names:
if (os.path.isfile(dirname + "\\" + filename)):
add = 0

# Check extension of file.
if (filename[-4:] == ".mp3"): add = 1
if (filename[-4:] == ".ogg"): add = 1
if (filename[-4:] == ".wav"): add = 1
if (filename[-4:] == ".mpg"): add = 1
if (filename[-4:] == ".avi"): add = 1
if (filename[-4:] == ".wmv"): add = 1
if (filename[-4:] == ".m2v"): add = 1
if (filename[-4:] == ".mov"): add = 1
if (filename[-5:] == ".flac"): add = 1

# If file is to be added, do it.
if (add == 1): pl.add(dirname + "\\" + filename)
elif (os.path.isdir(dirname + "\\" + filename)):
os.path.walk(dirname + "\\" + filename, add_files, pl)

# Get music playlist from XBMC
plist = xbmc.PlayList(0)
plist.clear()

# Load playlist if it exists
for playlist_file in playlist_files:
if (os.path.isfile(playlist_file)):
plist.load(playlist_file)
# Else, find all available music
else:
for music_dir in music_dirs:
os.path.walk(music_dir, add_files, plist)

# Do the shuffle!
if (shuffle_files == 1): plist.shuffle()

time.sleep(4)

xbmc.Player().play(plist)
xbmc.executebuiltin('XBMC.ActivateWindow(Visualisation)')

tohands

not sure if this helps, you probably alread read it. this is from man pages


Mathopd will exit voluntarily (as opposed to crash :) for a few reasons:

-
after reception of a SIGTERM or SIGINT signal

-
when no active connections and no active servers remain; this will be the case some time after delivery of SIGUSR2, or (rather perversely) if Mathopd was started up with a configuration file that did not contain any Server keywords

-
if it cannot open the Log, ErrorLog, or PIDFile; this can only be the case when the server is started up; if Mathopd fails to open a logfile while it is running, it will continue to use the logfile that it already opened (see below)

-
when it can not write to the access or error log; for example, if the disk partition that contains the access or error log gets filled up, Mathopd will die when it tries to write there.

direct link to man pages http://www.penguin-soft.com/penguin/man/8/mathopd.html

http://www.penguin-soft.com/penguin/man/5/mathopd.conf.html




why not use default Umask value of 022 instead of 026 keep things as open as possible then later you can make more restrictions. Maybe even just Stayroot ON

It is brilliant! I wonder how accurate the color conversion is? What RGB value do you get for the lighter blue in the header and footer of that picture for example? Your attached JPEG image fluctuates around #669AFF (could be because of JPEG compression). It should be solid #6699FF.
andy666, please use a lossless image format with a palette (e.g. PNG8 or GIF) if making a bitmap file out of the screen dump. A lossy true color format might affect color representation...

Will we have the ability to run any Python scripts (or comparable scripting language)?
Yes when someone makes it work... ;)

Today we haven't even a proper shell so it is a stretch...

To me any scripting support in MG-35 would be an improvement...

I found a precompiled dist of Tcl/Tk for ARM here, but have no idea if it would work on a MG-35 (slim change I guess)... (http://equi4.com/pub/tk/downloads.html)

Ps. More info and source here... (http://equi4.com/pub/tk/arm/)

... the supercharger I fitted ...
Really Ian, do you have a blower on a Miata?!? :eek:

A friend works in that area (developing blowers for the automotive and boat industry) and he has offered me some help with my Cobra. But I am to old school for that still sticking with a fat 4-barrel carb. Might fit some sort of engine control now when it can be had as open source... (http://www.megasquirt.info/)

Interesting that you mention VideoReDo, which I also own because it's the only app I have located that doesn't force a resolution change on my satellite DV program streams. I noticed that it can make transport streams too, and I tried that option, but the Mediagate doesn't recognize it as a valid movie file type. VideoReDo can also produce a VOB file; my sample conversion produced the only VOB file whose sound my Mediagate will not play! In particular, other VOB files with AC3 sound tracks play fine. :mad:

Hi time to stop lurking,

I use a program called Webscheduler as a digital TV recorder and record to the DVRMS format.

I then run a postprocessing task calling DVRMStoolbox to convert to mpeg2 so I can view on my mediagate through a shared drive:- It's a great setup & has been stable for months - bonus both are freeware

you will have to google for the apps as I can't submit URL's yet

I use a program called Webscheduler as a digital TV recorder and record to the DVRMS format. I then run a postprocessing task calling DVRMStoolbox to convert to mpeg2...Interesting. I don't create DVRMS files, so this route may not be useful in my particular case. Just for grins, what does Media Info (or the equivalent) say about the audio stream? 44.1kHz MPEG-1 layer 2?

The latest Dr. Divx:

http://labs.divx.com/DrDivX?nl0806=drdivx

converted my files using Home Theater profile, but customized via the Advanced Tab for AC3 audio creates files that play in the MG-35 with 5 channel dolby perfectly.Finally something that works! Thanks for this suggestion. Dr Divx produces files of type xvid which are not recognized by the Mediagate, and whose sound will not even play in the xvid player. :rolleyes: Renaming them to mp4 allows them to show up in the file browser, but selecting or playing them starts them up but they immediately exit back to the browser. :mad: Renaming them avi results in a playable file with AC3 soundtrack. :cool:

so after I tried to run it with
/hosts/mathopd # ./mathopd -d -t < mathopd.cfg & (-d = debug -t = write to log)
[13] 233


Did you see my README and also running.txt?

The options you need are -
./mathopd -n -d -t -f test.cfg &

The -n is important. This tells mathopd to run in the foreground rather than trying to daemonise. I have found *nothing* so far that has correct code to daemonise on uClinux. The work around is to tell stuff to run foreground (or hack source to do so!) and then use the &

Ian

Really Ian, do you have a blower on a Miata?!? :eek:


Yup. It's only at 7/8 psi, so only 40% ish hp increase, but it transforms the car. I've also got a lot of home-brew electronics in there. And I also got an air conditioning system for it in a box for £100, and after 6 hours of tinkering had an air conditioned Miata/MX-5.

Socket sets, soldering irons, keyboards, it's all just tools!

Ian

I found a precompiled dist of Tcl/Tk for ARM here, but have no idea if it would work on a MG-35 (slim change I guess)... (http://equi4.com/pub/tk/downloads.html)

Ps. More info and source here... (http://equi4.com/pub/tk/arm/)

The pre-built executables are all for MMU Linux with shared libraries. We don't have an MMU and don't have shared libs. :(

Getting tcl working might be an option. But it's probably easier to fix hush - it's not far off, but it looks like terminal stuff that's wrong, and this is all a mystery to me.

(edit - another thought is that hush fails for any external command, but ls seems to work. Hmmmm)

Ian

Here's an example of the XBMC startup script (autoexec.py) that calls another script to play music:


I actually had a thought regards playlists, and it involves yet another wrapping program that recognises the m3u file format and invokes mp3play for each file. If someone is prepared to lose WAV ability (or OGG or WMA) we might be able to hack dvdplayer.bin to recognise the M3U extension.

But -
1) I'm not sure if dvdplayer.bin reads anything from the file.
2) I'm not sure what output from mp3play it handles - you might not see the title of each track.

Ian

andy666, please use a lossless image format with a palette (e.g. PNG8 or GIF) if making a bitmap file out of the screen dump. A lossy true color format might affect color representation...

The problem with getting "exact" colour representation in a screen dump is that converting the YUV palette back to RGB may not give exactly the original RGB colours. Using the palette in dvdplayer.bin will, but if we end up modifying the palette directly this won't necessarily reflect the current colours.

It is worth noting that we're talking about on-screen representations of colours here - not print - and they'll probably appear different for every user/screen, so do they need to be "exact" ?

One other observation - the menu screens on the mg35 are rendered by displaying a backdrop jpeg then overlaying the 640x480 256 colour image on top. Just like when displaying, for instance, the info box over a playing movie. I'm not certain, but I don't think the background jpegs are subject to any palette restrictions. So if we want a rainbox in the background we can have one!

(PS: What's the ettiquete on this forum regarding posting images in the thread? Do people prefer just to have links or is it useful to include the actual image "inline"?)

It is worth noting that we're talking about on-screen representations of colours here - not print - and they'll probably appear different for every user/screen, so do they need to be "exact" ?
You are right, the only problem is if we got a palette like the default one with a lot of similar colors adjecent to each other (like the first 16, all almost white and one probably used for subs) then it's hard to pick the right one for sure if RGB-values from screen dump isn't spot on...

I'm working on 2 ways to achieve this.

Firstly, my VB Program has a function that shows the palette index of the pixel under the cursor. This really needs a zoom function to be really useful, and as I hate re-inventing wheels...

The second option is an MG35 program that directly creates a greyscale bitmap (just of the overlay - no background) with each palette value represented by a shade of grey - i.e. black (#000000) = palette index 0, mid grey (#1f1f1f) = palette index 127, white (#ffffff) = palette index 255 etc. This should let you load the bitmap into e.g. Photoshop and see the palette values of each pixel. To display it in glorious technicolour just load an appropriate .act palette.

Firstly, my VB Program has a function that shows the palette index of the pixel under the cursor. This really needs a zoom function to be really useful, and as I hate re-inventing wheels...


It might be easier to just have a second display area that shows a larger version of the area around the mouse pointer.

Ian

Interesting. I don't create DVRMS files, so this route may not be useful in my particular case. Just for grins, what does Media Info (or the equivalent) say about the audio stream? 44.1kHz MPEG-1 layer 2?

DVRMStoolbox is producing the following audio
Codec : MPEG-1 Audio layer 2
Bit rate : 256 Kbps
Bit rate mode : CBR
Channel(s) : 2 channels
Sampling rate : 48 KHz
Resolution : 16

Did you see my README and also running.txt?

The options you need are -
./mathopd -n -d -t -f test.cfg &

The -n is important. This tells mathopd to run in the foreground rather than trying to daemonise. I have found *nothing* so far that has correct code to daemonise on uClinux. The work around is to tell stuff to run foreground (or hack source to do so!) and then use the &

Ian

I tried -n alone (well with the -f), and it didnt work, but with -d it work. SO I tried to put the printenv and tried to run it, I have an Internal 500 error, and this is what I see in the mathopd console

Thu Jan 1 00:17:28 1970 [81] process_request: /hosts/www/cgi-bin/printenv.cgi
Thu Jan 1 00:17:28 1970 [81] get_path_info: open("/hosts/www/cgi-bin/printenv.cgi") = 10
Thu Jan 1 00:17:28 1970 [81] get_path_info: curdir = "/hosts/www/cgi-bin"
Thu Jan 1 00:17:28 1970 [81] get_mime: type=CGI, class=2
Thu Jan 1 00:17:28 1970 [81] close_rfd: 10
Thu Jan 1 00:17:28 1970 [81] socketpair: Network is unreachable
Thu Jan 1 00:17:28 1970 [81] process_request finished (s=0)

/hosts/www and /hosts/www/cgi-bin have the permission 755 on it, also printenv.cgi. I'm able to see the index.html (like thttpd) but not the cgi.


#!/bin/sh

echo "Content-type: text/html";
echo "";
echo "Hello World! I love CGI programming with BASH!";


Thats a scripts I tried to run

#include <stdio.h>

int main(void) {
printf("Content-Type: text/html\n\n");
printf("<html><body>Hello World</body></html>\n");
}

Can someone cross compile this, I want to try a C program for the cgi.

/usr/local/lib/gcc-lib/arm-elf/2.95.3/libgcc.a(__main.o): In function `__do_global_ctors':
__main.o(.text+0xc4): undefined reference to `__CTOR_LIST__'
/usr/local/lib/gcc-lib/arm-elf/2.95.3/libgcc.a(__main.o)(.data+0x0): undefined reference to `__DTOR_LIST__'
collect2: ld returned 1 exit status


This is what I got when I tried to cross compile something

/usr/local/lib/gcc-lib/arm-elf/2.95.3/libgcc.a(__main.o): In function `__do_global_ctors':
__main.o(.text+0xc4): undefined reference to `__CTOR_LIST__'
/usr/local/lib/gcc-lib/arm-elf/2.95.3/libgcc.a(__main.o)(.data+0x0): undefined reference to `__DTOR_LIST__'
collect2: ld returned 1 exit status


This is what I got when I tried to cross compile something

That usually means that the elf2flt argument hasn't got through to the linker. Do you definitely have -Wl,elf2flt on your command line and/or in CFLAGS? For simple stuff of your own, this is usually easy to do. For stuff with a simple make file, it's not too much trouble. For stuff using autoconf "it varies" !!!!

Try building (say) nbtstat from the Al Tek GPL release first as the make file for this is all done for you.

Ian

Thu Jan 1 00:17:28 1970 [81] socketpair: Network is unreachable


I had to replace socketpair with a function that uses INET sockets so you need to bring up the local loop back adaptor. It's in my README. :)

Ian

#include <stdio.h>

int main(void) {
printf("Content-Type: text/html\n\n");
printf("<html><body>Hello World</body></html>\n");
}

Can someone cross compile this, I want to try a C program for the cgi.

OK, compiled using -

arm-elf-gcc -Wl,-elf2flt testcgi.c -o testcgi

and attached.

Ian

I tried -n alone (well with the -f), and it didnt work, but with -d it work. SO I tried to put the printenv and tried to run it, I have an Internal 500 error, and this is what I see in the mathopd console


I don't know why -d might also be required. I might not have tried mathopd without it. I guess I'll have to add sorting this out "to the list"

Ian

It's here and people might like to add their own entries. PM me if you need the password.

http://mediagate.pbwiki.com/WhoIsDoingWhat

Ian

hey gadgetmind, I have great news, IT WORK! cgi is working!!! finally

I didnt tried the C compiled to CGI yet.

Finally something that works! Thanks for this suggestion. Dr Divx produces files of type xvid which are not recognized by the Mediagate, and whose sound will not even play in the xvid player. :rolleyes: Renaming them to mp4 allows them to show up in the file browser, but selecting or playing them starts them up but they immediately exit back to the browser. :mad: Renaming them avi results in a playable file with AC3 soundtrack. :cool:

Sorry about forgetting to say the rename to .avi extension before they play... Al

I have wrapped my palette util scripts in a simple "Wizard". It is capable of making .act and .ini files from image files, image files out of .act and .ini files and .ini files out of .act and image files (you get it) ;)

The wrapper application is named mg35palutil and is bundled with all util scripts. It should work on any Linux with Python, wxPython and PIL. I also made a "frozen" standalone version for Windows. This application can be runned under Windows without the need to install Python etc. The Python interpreter is embedded within this application and it is therefor quite big (zip file is 4.5 Mb). I uploaded to Yahoo Groups but I would like to remove it as soon as possible to save space.

So go ahed and grab it while it is avalable... (http://groups.yahoo.com/group/mg-35_firmware_mods/files/MG-35%20Utilities/) :rolleyes:

hey gadgetmind, I have great news, IT WORK! cgi is working!!! finally

I didnt tried the C compiled to CGI yet.

Great stuff!

You have *no* idea how long it took me to realise that I needed a lo interface. <blush> You'd have thought that I might have briefly considered it while writing socket code that uses localhost, but no, not me!

Given our limited scripting, I think that C progs as CGI is probably the best idea. We should be able to have one program that does pretty much everything we need.

Ian

So go ahed and grab it while it is avalable... (http://groups.yahoo.com/group/mg-35_firmware_mods/files/MG-35%20Utilities/) :rolleyes:

Will mirror at rapidshare - I am also going to create a "MG-35" utils area on Rapidshare as a Archive,so none of this stuff gets lost and although many of you dont really like Rapidsahre , at least we wil have a archive that people can access , even if it does take 30 secs or so todo so..

Next firmware release.

I pushed MG35-1.4.4.4-pre0-eng out of the door last weekend. Hopefully this has made development easier for people while hiding the files from normal GUI browsing.

I have another version that I'm making minor changes to and have so far done the following -

MG35-1.4.4.4-pre1-eng
- /sbin/route now correctly links to /bin/busybox
- /etc/resolv.conf now links to /hosts/resolv.conf so we can change it
- www and cgi users added to /etc/passwd

As I'd like MG35-1.4.4.4-eng to be our baseline (new gui for the man on the street, plus some development stuff) I don't intend to do much more on this and it's really just waiting for the final graphics and palette.

I'm also tinkering with MG35-1.4.4.5-alpha0
- Moved all binaries to /sbin/rbin and made everything in / and /bin into links.
- New busybox with nslookup
- New udhcpc that creates /etc/resolv.conf

The 1.4.4.5 series is where we can really experiment with new features including web interface, NAS mode, m3u support, etc.

Feedback required - does this seem sane?

Ian

andy666, what is the layout of the memory dump? Is it an 8-bit header, 256 RGB values (3 * 8-bit YUV) and then video memory (is this a 720*480 matrix with 8-bit palette indexes or is it 720x480 RGB values (3 * 8-bit) etc.)? Is it big or little endian? Any information would be of interest!

Feedback required - does this seem sane?

Ian

Yes very to me - All I ask is that you make it VERY,VERY clear if a release is "Just for Developers" or has any features the "Man in the Street" would want over "MG35-1.4.4.4-eng "

The Yahoo group is doing really,really well and since the New Gui v 3.0 firmware release , and has started to get 50+ new members a week which is amazing,but also 99% of them are "Man in the Street" types.

So How about I redo the Firmware section with a "Developers Only" area and a "General" area - this may avoid the 4-5 emails I am getting daily "Which firmware do I download ,which one is best" etc etc

I would never want to make any of the developer only stuff private,as I am very mindful that we need to get interest to attract new people with the necessary skills to help out..

@Ian and Rob,

Before I archive everything off , could you just have a quick look at the Yahoo group and see if there is anything old (or outdated) that can now be deleted - ie do we really still need MG35-145-KOR-GFX-PRO.zip ? , just send me a pm with the file names and I can delete anything that is no longer of any use..

Another point , the Development fund is now up to $150.45 , so if anyone has any suggestions on how to spend it , please let us know..

@Ian and Rob,

Before I archive everything off , could you just have a quick look at the Yahoo group and see if there is anything old (or outdated) that can now be deleted - ie do we really still need MG35-145-KOR-GFX-PRO.zip ? , just send me a pm with the file names and I can delete anything that is no longer of any use..
MG35-145-KOR-GFX-PRO.zip deleted, I can always provide it on request.

MG35-Palettes.zip could be replaced with one original palette. I can upload the original palette if you remove MG35-Palettes.zip...

andy666, what is the layout of the memory dump? Is it an 8-bit header, 256 RGB values (3 * 8-bit YUV) and then video memory (is this a 720*480 matrix with 8-bit palette indexes or is it 720x480 RGB values (3 * 8-bit) etc.)? Is it big or little endian? Any information would be of interest!

The dumptop util dumps 512k of memory starting at 0x1F80000

0x000000 8 bytes (purpose as yet unknown)
0x000008 Pallete - 256*4 bytes - AYUV (alpha currently always 255)
0x000408 Overlay bitmap - 640 x 465 x 8bit indexed (not sure why 465 lines)
0x048A80 Not sure - could be 720x480 buffer but not enough room unless compressed.
0x07FFFF EOF

MG35-145-KOR-GFX-PRO.zip deleted, I can always provide it on request.

MG35-Palettes.zip could be replaced with one original palette. I can upload the original palette if you remove MG35-Palettes.zip...

ok Done , btw , made both Ian and yourself mods , so you can delete any files , even if you did not upload it..

I say you use the money to buy Ian a beer for all the hard work he has put into this project.

Great stuff!

You have *no* idea how long it took me to realise that I needed a lo interface. <blush> You'd have thought that I might have briefly considered it while writing socket code that uses localhost, but no, not me!

Given our limited scripting, I think that C progs as CGI is probably the best idea. We should be able to have one program that does pretty much everything we need.

Ian

Yeah thats a great idea, I was able to cross compile a cgi script this morning with my debian box, thats great (didnt test it yet, but as soon as I'm done at work, I will try it), finally I have something to work with (the only thing I didnt try, is to flash my mg35 with the serial cable).

I say you use the money to buy Ian a beer for all the hard work he has put into this project.

I think he deserve more than a beer (maybe a 24 pack) ;p

I say you use the money to buy Ian a beer for all the hard work he has put into this project.

Ok , ordered 50 x "Party Sevens" (if you can still get them?) to be delivered to him..

Ok , ordered 50 x "Party Sevens" (if you can still get them?) to be delivered to him..

Doctor's orders might prevent my drinking it all in one sitting. She asked me how much I drunk, wrote it all down, and told me I had to cut back. Fortunately she assumed I was telling her what I drunk per week whereas it was per day!

I don't know, one little attack of gout and they overreact!

Ian

Yeah thats a great idea, I was able to cross compile a cgi script this morning with my debian box, thats great (didnt test it yet, but as soon as I'm done at work, I will try it), finally I have something to work with (the only thing I didnt try, is to flash my mg35 with the serial cable).

Flashing via serial is a doddle. The only bit I need to think about is when typing to commands to change serial speed and then getting hyperterminal to match it.

Ian

I would never want to make any of the developer only stuff private,as I am very mindful that we need to get interest to attract new people with the necessary skills to help out..


We could just say that anything labelled "pre" is probably OK for "man in the street" to try out and comment on. Anything alpha or beta they will probably want to avoid as there could be breakage. (But anyone creating firmware should always upgrade and downgrade a few times via the GUI from both network and HD)

But I'm happy to go with the flow on this one. A lot of the stuff I do is just because no-one has shouted "Stop, fool!" yet. :)


Before I archive everything off , could you just have a quick look at the Yahoo group and see if there is anything old (or outdated) that can now be deleted - ie do we really still need MG35-145-KOR-GFX-PRO.zip ? , just send me a pm with the file names and I can delete anything that is no longer of any use..


Will do but probably not until Friday.


Another point , the Development fund is now up to $150.45 , so if anyone has any suggestions on how to spend it , please let us know..

If it works how I hope, the next firmware version (1.4.4.5) will let us play with pretty much anything without cutting new firmware, so the need for serial leads is greatly reduced. I guess another dev box is an option, but no-one is shouting for one. I find having one useful as it's powered up at home and I can try things on it if I get a spare ten minutes at work and an idea occurs to me.

What's cool is that it's now been powered up for several days, and I've tried all the mathopd, udhcpc and nbtscan stuff on it, and it's still running without a reboot!

Ian

The dumptop util dumps 512k of memory starting at 0x1F80000

0x000000 8 bytes (purpose as yet unknown)
0x000008 Pallete - 256*4 bytes - AYUV (alpha currently always 255)
0x000408 Overlay bitmap - 640 x 465 x 8bit indexed (not sure why 465 lines)
0x048A80 Not sure - could be 720x480 buffer but not enough room unless compressed.
0x07FFFF EOF

Now added to the wiki.

Ian

The Development fund is now up to $150.45 , so if anyone has any suggestions on how to spend it , please let us know.. Bribe an engineer at Al Tech? ;)

Or how about buying the SDK from Sigma? :(

In my neverending quest to convert my mpeg2 program streams with AC3 sound tracks to something that the Mediagate will play, I tried autogk last night with terrible results. Indeed, the resulting avi file would play with sound, but the video looked terrible anywhere there was motion. All edges were severely jagged. What did I do wrong?

I also have an S-MPEG4 avi file which plays on the Mediagate. But it makes annoying errors on the video in a few places. Block artifacts appear, usually trailing something moving fast.

You can also try PVAStrumento (freeware) for converting mpeg-ts to mpeg-ps.
http://www.offeryn.de/dv.htm#pvas

A playlist/M3U hack would be great! any chance of looking at improving video playlists? currently you can't use .iso files in a playlist (or the play all function). I've got a large number of music videos ripped as individual files from DVD causing problems. if i just use the .vob file then the mg35 ignores the aspect ratio (lots are widescreen) if i mux them as normal mpeg i don't get audio as the mg35 wont playback DD from an mpeg file, so as one song per iso i get the right aspect and working sound, but playlists don't work, so you have to select videos one at a time.

Sadly i have no programming skills myself, so can't prove much help. would just like to say thanks to all of you working on improving what will one day be an amazing little box.

The cgi from a C source, work good on the mathopd. Thats great

DVRMStoolbox is producing the following audio
Codec : MPEG-1 Audio layer 2
Bit rate : 256 Kbps
Bit rate mode : CBR
Channel(s) : 2 channels
Sampling rate : 48 KHz
Resolution : 16

forgot to mention that this is the output audio from DVRMStoolbox when converting to mpeg2, it's not AC3, but I think that is because the orignial broadcast DVB data stream is also mpg.

If you are interested I will try to set my tuner to record the AC3 stream as a test.
But as it is at the moment it works for me

/hosts # ./uptime
Uptime: 0 days, 10:59:33.

my first prog for the mg35

This is how the mount is done via the menu

nbtscan -q -b /net -e <mg35ip> /24

ls /net
**list of <computer name>

smbmount -b /net/<computer name> -L <computer name> -U Guest -N -s /hosts/smb.conf C

ls /net/<computer name>
**list of shared on <computer name>

** = output

I also managed to get how the fileplayer is done, but I didnt figure out yet how to hide the menu in front

./fileplayer.bin AVI <avipath> 0

like ./fileplayer.bin AVI /net/TOHANDS1/My\ Movie/Les\ gags\ -\ Juste\ pour\ rire\ 2003\ \(01\ aout\ 2006\).avi 0

I see the movie behind the menu (I was hoping to play a file via web)

I say you use the money to buy Ian a beer for all the hard work he has put into this project.
I think Sylvain a.k.a. "tohands" is making some great strides and may deserve a beer also... Al

i was wondering if my request is possible to implement at the current development state that we are at. Can anyone figure out how to make the movie/music/picture menu in the gui, mapped to certain named folders....example: selecting "Movie" would take you into a folder that you have created on your mg-35 HDD name "Movies" or "Videos". If this is not able to be done now, take a note for future development, this eventually needs to be done in order to make the MG-35 "Family Friendly".

thanx,
neal

Here is a better phase2 script to remount /cdrom as rw
#!/bin/lash
sleep 6 # give dvdplayer some time to mount /proc; 6 sec it's minimum
mount /cdrom -o remount,rw

echo >>/phase2/phase2.log
echo "Final mounts" >>/phase2/phase2.log
mount >>/phase2/phase2.log

Somebody reported that this mount form is crashing MG35, but it worked ok for me...

I'm also tinkering with MG35-1.4.4.5-alpha0
- Moved all binaries to /sbin/rbin and made everything in / and /bin into links.
- New busybox with nslookup
- New udhcpc that creates /etc/resolv.conf

The 1.4.4.5 series is where we can really experiment with new features including web interface, NAS mode, m3u support, etc

If possible, please also try to replace the programs in / (at least fileplayer, mp4play, mpegplayer) with symlinks to /bin or /rbin

This is how the mount is done via the menu

nbtscan -q -b /net -e <mg35ip> /24

ls /net
**list of <computer name>

smbmount -b /net/<computer name> -L <computer name> -U Guest -N -s /hosts/smb.conf C

ls /net/<computer name>
**list of shared on <computer name>

** = output

Great, thanks. I suspect the /net/<computer name> is signs of more hackery but will need to check the smbmount docs and source to be sure.

How did you capture this info.?

Ian

If possible, please also try to replace the programs in / (at least fileplayer, mp4play, mpegplayer) with symlinks to /bin or /rbin

I probably phrased it badly, but this is what I've done. All executables are now in /sbin/rbin Stuff in / symlinks to /bin Everything in /bin (excupt the tiny ll script) then links off to /sbin/rbin.

Ian

The cgi from a C source, work good on the mathopd. Thats great

Great. I'll try and push firmware out with the cgi and www users. I can then unhack mathopd. I'll also try and work out why it might not work without -d

Ian

I also managed to get how the fileplayer is done, but I didnt figure out yet how to hide the menu in front

./fileplayer.bin AVI <avipath> 0

like ./fileplayer.bin AVI /net/TOHANDS1/My\ Movie/Les\ gags\ -\ Juste\ pour\ rire\ 2003\ \(01\ aout\ 2006\).avi 0

I see the movie behind the menu (I was hoping to play a file via web)

Because dvdplayer.bin hasn't launched fileplayer, it hasn't undrawn its screen first. I guess we can just hit video memory to blank out the dvdplayer.bin screen!

I think all of this "how dvdplayer.bin does xyz" should go on the wiki, I can also add a section on setup.

Ian

Here is a better phase2 script to remount /cdrom as rw
#!/bin/lash
sleep 6 # give dvdplayer some time to mount /proc; 6 sec it's minimum
mount /cdrom -o remount,rw

echo >>/phase2/phase2.log
echo "Final mounts" >>/phase2/phase2.log
mount >>/phase2/phase2.log

Somebody reported that this mount form is crashing MG35, but it worked ok for me...

I'll give that a go. I'd also love to know when the MG-35 does the ro remount as I can't catch it in the act!

I guess we could always kick off a background script that checks if the HD is mounted ro, if it is remounts it, and then sleeps and loop.

Ian

i was wondering if my request is possible to implement at the current development state that we are at. Can anyone figure out how to make the movie/music/picture menu in the gui, mapped to certain named folders....example: selecting "Movie" would take you into a folder that you have created on your mg-35 HDD name "Movies" or "Videos". If this is not able to be done now, take a note for future development, this eventually needs to be done in order to make the MG-35 "Family Friendly".


Unless someone has a bright idea, this will have to wait until we get an ext2 filing system (as we can use soft links) or we replace dvdplayer.bin.

The other option would be to hack/wrap nbtstat and smbmount to report parts of the hard drive as if they were network shares and do mount -o bind to get them into place. Neither hack is mega hairy and I'm planning to wrap nbtstat anyway.

Ian

Great, thanks. I suspect the /net/<computer name> is signs of more hackery but will need to check the smbmount docs and source to be sure.

How did you capture this info.?

Ian


with /proc/<process#>/cmdline

I was looking through the system map /proc/ksyms on the MG-35 and found

01018618 gpio_enable_irq
010186b4 gpio_disable_irq
010186fc gpio_irq_enabled
01018738 gpio_irq_pending
01018770 gpio_clear_irq
010187ec gpio_set_data
010187a8 gpio_set_dir

I've about reached the end of my knowledge on Linux Kernel's.

Nick

Great, thanks. I suspect the /net/<computer name> is signs of more hackery but will need to check the smbmount docs and source to be sure.

How did you capture this info.?

Ian

I didnt capture the ls, its just a way to show you after I did the smbmount, everything is mount and with ls (or the file explorer in dvdplayer.bin) you can see the shared. I'm sure dvdplayer.bin is not using ls, cause a file with . prefix, still show in the menu.

the way I capture the smbmount, I connect to telnet, did a ps (without having any ftp or other thing open with my mediagate) so let say the ps pid = 90, next time I do a ps, the pid = 91

so if I select Movies from the Network stuff on mediagate, and I do ps again, the pid is now 93 (so something as been run before my ps)

the way I found what as been run, well its tricky, you have do to a ps, look at the pid, write on the command line (cat /proc/<nextincpid#>/cmdline) and you have to synchronize your ENTER on your PC with the ENTER on your IA remote, if you success that process, you will see what's as been run (something like 'nbtscan-q-b/net-e<mg35ip>/24/proc/<nextincpid#>' without space)

so after that you just guest where the space it (and remove the /proc/<nextincpid>)

Bribe an engineer at Al Tech? ;)

Or how about buying the SDK from Sigma? :(

Golly, do Al Tek have engineers? :)

Ian

I may have missed it somewhere in the 70 + pages. With the webserver and cgi available, couldn't the entire frontend be replaced if we also had some light version of a browser available also? Or, is there no way to get it to load the browser on boot up instead of it's own frontend?

A playlist/M3U hack would be great! any chance of looking at improving video playlists?

This might have to wait for a dvdplayer replacement. Unless someone can think of a neat way to subvert something!

Ian

I was looking through the system map /proc/ksyms on the MG-35 and found

01018618 gpio_enable_irq
010186b4 gpio_disable_irq
010186fc gpio_irq_enabled
01018738 gpio_irq_pending
01018770 gpio_clear_irq
010187ec gpio_set_data
010187a8 gpio_set_dir

I've about reached the end of my knowledge on Linux Kernel's.

Nick

Yes, the problem is that these functions are in the MG-35 kernel but we don't have the source to match.

Ian

udhcpc woes.

I put my new udhcpc in some new firmware, and it brought up the interface properly, and fills in /etc/resolv.conf, but dvdplayer.bin didnt recognise that there was a network.

I then sussed that the udhcpc source is incomplete as the Al Tek supplied binary also generates /hosts/smb.conf.

So, I added that functionality and still dvdplayer.bin isn't happy. I don't know what else it needs but my udhcpc doesn't appear in the process list in square brackets, so I guess it isn't doing something - becoming a child of init?

Anyway, I'll roll back to the Al Tek binary of udhcpc and pop out a 1.4.4.5-alpha without it but with the ability to experiment by dropping new versions into /bin in phase2.

Ian

I'm working on a screen dump utility at the moment and discovered what some might see as a problem with arm-elf-gcc (and gcc)

If you define a structure the elements of that structure are, by default, dword aligned. This causes problems if that structure is a bitmap file header with short int (16 bit) elements!

Luckily there is a workaround - just include -fpack-struct in the arm-elf-gcc command line..

Probably incredibly obvious to seasoned gcc-ers.... :(

udhcpc woes.

I put my new udhcpc in some new firmware, and it brought up the interface properly, and fills in /etc/resolv.conf, but dvdplayer.bin didnt recognise that there was a network.

I then sussed that the udhcpc source is incomplete as the Al Tek supplied binary also generates /hosts/smb.conf.

So, I added that functionality and still dvdplayer.bin isn't happy. I don't know what else it needs but my udhcpc doesn't appear in the process list in square brackets, so I guess it isn't doing something - becoming a child of init?

Anyway, I'll roll back to the Al Tek binary of udhcpc and pop out a 1.4.4.5-alpha without it but with the ability to experiment by dropping new versions into /bin in phase2.

IanIan,
Any possibility of you sharing the source to your potential udhcpc replacement? (Yes, I understand it does not yet work)
I've now gotten Vmware configured on my PC, Xubuntu running, and the arm-elf-gcc cross-compiler installed.

I can't promise anything, but I can at least join in the fun. I've ordered a serial interface and it should be arriving any day now. When it arrives I want to give a try at reverse engineering the gpio_xxxxx routines in the kernel. I don't think they can be too complex (at least their entry point addresses are close to each other, and that might be a clue that they are each fairly simple)

I am hoping I can do the equivalent in assembly without too much work. Odds are good they used in-line assembly to code them to start.

Joe L.

Ian,
Any possibility of you sharing the source to your potential udhcpc replacement? (Yes, I understand it does not yet work)
I've now gotten Vmware configured on my PC, Xubuntu running, and the arm-elf-gcc cross-compiler installed.


Yup, absolutely no problem. I'll tidy up some stuff and zip it up tomorrow. The changes are pretty small and pretty much all in one file.

I'm sure I'm missing something silly. Now knowing how their engineers work, I'm sure dvdplayer.bin must be waiting for something in a file but I don't know what!

If only Al Tek had released the source for the MG-35 rather than something totally different!

Ian

Talking of a screen dump utility - the first version is attached..

It produces an indexed bitmap file called mgscreen.bmp with a greyscale palette. Palette index 0 is #000000 (black), 128 is #808080 (grey), 255 is #ffffff (black)

Note that it will only dump the overlay - NOT any background jpeg...

The main purpose of this is to determine what palette entries are being used where - probably easier than using the "colour hunt" palette!

Probably also worth pointing out this has to run on the mg35 - my windows program will be along soon I hope...

The bitmaps load fine in Windows Image Preview and Paintshop Pro 7 - unfortunately my funds don't extend to Photoshop!

Have Fun

Andy

0x000000 8 bytes (purpose as yet unknown)

Could it be some sort of struct defineing the size of the overlay image, its position over the graphics surface and the clipping to be applied? But I can't make anything out of the values...

0x000008 Pallete - 256*4 bytes - AYUV (alpha currently always 255)

But what YUV? YUV as used in the analog television broadcasting or YCbCr (CCIR 601) as in digital MPEG-2/4? If it is CCIR 601 then this color conversion might be better (YCbCr->RGB):

int Y1, Cb, Cr; /* gamma pre-corrected input [0;255] */
int ER, EG, EB; /* output [0;255] */

double r, g, b; /* temporaries */
double y1, pb, pr;

int
clamp (double x)
{
int r = x; /* round to nearest */

if (r < 0) return 0;
else if (r > 255) return 255;
else return r;
}

y1 = (255 / 219.0) * (Y1 - 16);
pb = (255 / 224.0) * (Cb - 128);
pr = (255 / 224.0) * (Cr - 128);

r = 1.0 * y1 + 0 * pb + 1.402 * pr;
g = 1.0 * y1 - 0.344 * pb - 0.714 * pr;
b = 1.0 * y1 + 1.772 * pb + 0 * pr;

ER = clamp (r * 255); /* [ok? one should prob. limit y1,pb,pr] */
EG = clamp (g * 255);
EB = clamp (b * 255);


and to reverse (RGB->YCbCr):

int ER, EG, EB; /* gamma corrected RGB input [0;255] */
int Y1, Cb, Cr; /* output [0;255] */

double r, g, b; /* temporaries */
double y1, pb, pr;

int
clamp (double x)
{
int r = x; /* round to nearest */

if (r < 0) return 0;
else if (r > 255) return 255;
else return r;
}

r = ER / 255.0;
g = EG / 255.0;
b = EB / 255.0;

y1 = 0.299 * r + 0.587 * g + 0.114 * b;
pb = -0.169 * r - 0.331 * g + 0.5 * b;
pr = 0.5 * r - 0.419 * g - 0.081 * b;

Y1 = clamp (219 * y1 + 16);
Cb = clamp (224 * pb + 128);
Cr = clamp (224 * pr + 128);

/* or shorter */

y1 = 0.299 * ER + 0.587 * EG + 0.114 * EB;

Y1 = clamp ( (219 / 255.0) * y1 + 16);
Cb = clamp (((224 / 255.0) / (2 - 2 * 0.114)) * (EB - y1) + 128);
Cr = clamp (((224 / 255.0) / (2 - 2 * 0.299)) * (ER - y1) + 128);



0x000408 Overlay bitmap - 640 x 465 x 8bit indexed (not sure why 465 lines)

This I don't get at all! The backdrop graphics (e.g. menu_bg.jpg) is 720x480 and overlay graphics map 1:1 to these. But hey, NTSC is 4:3 640x480 and DVD resolution 720x480 is not square pixel ratio (I tend to always assume square pixels when I work on my PC but this is television right)! I still don't get why the overlay would be 465 lines but I do get why the buffer might be 640 wide. What aspect ratio setting was the MG-35 running in when the screen was dumped (4:3, 16:9, Pan&Scan or letter box etc.)?


0x048A80 Not sure - could be 720x480 buffer but not enough room unless compressed.

A planar format would make sense if this is the video buffer. But assume YU12 because it is commonly used for MPEG-2/4.

The three components are separated into three sub- images or planes. The Y plane is first. The Y plane has one byte per pixel. The Cr plane immediately follows the Y plane in memory. The Cr plane is half the width and half the height of the Y plane (and of the image). Each Cr belongs to four pixels, a two-by-two square of the image. For example, Cr0 belongs to Y'00, Y'01, Y'10, and Y'11. Following the Cr plane is the Cb plane, just like the Cr plane.

That would consume less space than an YUV 4:4:4 format with 8 bit samples for each component or AYUV with an 8 bit alpha blend value per pixel (4:4:4:4). But I guess it still would take up to much space...

The screendumps I made from the dumptop memory dumps used the formulae you posted earlier in the thread to convert the YUV values into RGB - I'll try using the formulae above when I get round to modifying mgpal to alter the palette directly.

All of my "screen dumping" so far has been with the MG35 in 16:9 mode - it appears that it just stretches the overlay to map over the background image. I'll try 4:3 mode over the weekend probably...

Oh, and someone wanted a clear screen utility? The attached should do it...

And while I'm on a roll...

The subtitle font has a fill colour of index 1, with a 1 pixel outline in index 253..

And while I'm on a roll...

The subtitle font has a fill colour of index 1, with a 1 pixel outline in index 253..
That would be valuable information but some has reported bright green subs with the new graphics. Index 1 is yellow (I guess it has to be white in the future) and 253 is cyan (would that make bright green)?

Index 1 is pale blue/ cyan in the version I'm using (#588bdd) This could be mistaken for bright green?

(I'm using zero based indexes, 0 is yellow, 1 is cyan .... 254 is the transparent magenta etc...)

Oh, and someone wanted a clear screen utility? The attached should do it...Cool,

If there was a way to know when the image on the screen has paused, or is static, you might have the beginnings of a screen saver.

For a quick and dirty screen saver, how about a simple additive checksum of the video buffer area, sleep for 2 minutes, grab another checksum, sleep for 2 more minutes, grab a third. If all the same checksum, the image has not changed and you could clear it. Of course, not sure how to get it back once cleared.

Are the DVD video images rendered in the same space? Would be nice if they were, as it would catch a paused video.

If DVD and video images are not rendered in the same memory, then this would not work at all... and you can ignore my ramblings.

Joe L.

The screendumps I made from the dumptop memory dumps used the formulae you posted earlier in the thread to convert the YUV values into RGB - I'll try using the formulae above when I get round to modifying mgpal to alter the palette directly.

All of my "screen dumping" so far has been with the MG35 in 16:9 mode - it appears that it just stretches the overlay to map over the background image. I'll try 4:3 mode over the weekend probably...

Oh, and someone wanted a clear screen utility? The attached should do it...

cls works great. So I managed to start a file from telnet with file player, and removed the screen utility with the cls, the IA remote doesnt seem to be activate for the movie, so if I could finish with my spy PID program, maybe I will be able to find how they active it.

(I'm using zero based indexes, 0 is yellow, 1 is cyan .... 254 is the transparent magenta etc...)It sprung to my mind when I went to bed (5 minutes after my post)... :o

The subtitle font has a fill colour of index 1, with a 1 pixel outline in index 253..
Wiki updated... (http://mediagate.pbwiki.com/MoreOnUserInterface)

The subtitle font has a fill colour of index 1, with a 1 pixel outline in index 253..
Any chance finding out the index of the semitransparent green color in these pictures:

http://us.a2.yahoofs.com/groups/g_18279495/b74d/__sr_/3de8.jpg?grwCUAFBrincPgac
http://us.a2.yahoofs.com/groups/g_18279495/b74d/__sr_/f2bb.jpg?grwCUAFBf2CvLfR.

Ps. My qualified guess is index 135, it must also be counted for in the final system palette and should be the background color of OSD overlays (e.g. zoomoff.png etc.).

Pps. Do we have any other unknown colors (colors that show up off in the current GUI)? I think I got enough to motivate a new release (subtitles, dialog background, OSD background color, main menu back glyph etc.).

Oh, and someone wanted a clear screen utility? The attached should do it...

We need to start thinking of a way to bundle up all these useful applications Maybe the wiki is OK to start with as all these bits are pretty small.

I never made peek, poke or dumptop available as they are very crude and unfinished for wide distribution, but maybe if there was a README with clear warnings?

But mgnv is on the wiki and now in any .upgrades I make. However, there is an argument that stuff should just be in people's phase 1/2 until it's actually useful to the Man in the Street.

Ian

Of course, not sure how to get it back once cleared.


Yes, hard to do perfectly.


Are the DVD video images rendered in the same space? Would be nice if they were, as it would catch a paused video.


Look for the pause word/symbol on the screen if one of the videoplayers is running?

However, a lot of this is work designed to work with the existing dvdplayer.bin but the goal of replacing it is looking less daunting with every discovery.

Ian

Pps. Do we have any other unknown colors (colors that show up off in the current GUI)? I think I got enough to motivate a new release (subtitles, dialog background, OSD background color, main menu back glyph etc.).

I can easily make a new 1.4.4.4-pre1 .upgrade once you have these. If it isn't 100% perfect, then we go for pre-2 ...

I could also include the screen dump utility but anyone who can get the data back off the box can easily get a screen dump onto it themselves.

Ian

Anyone done any work towards a portable version of a .upgrade builder?

Dragging stuff on/off a windows box is starting to deeply annoy me and I keep making mistakes, so if anyone has made a start chime up, otherwise I'll probably try and do some work on this at the weekend.

Ian

I have attached my hacked source for udhcpc You'll need to read readme.m35 to see what I've done and what problems I have found.

Happy hacking!

Ian

I managed to recompile and boot a new kernel on Mediagate-35. I have two problems at the time:

1. the ide-jasper.c from the GPL.zip on the mediagate site doesn't work (or there are some changest to be made in hardware.h)

2. there seems to be a patch for blkmem.c as at boot it displays the following:

<4>JASPER use arena[0] for cramfs [0x000e2809]
<4>Blkmem copyright 1998,1999 D. Jeff Dionne
<4>Blkmem copyright 1998 Kenneth Albanowski
<4>Blkmem 1 disk images:
<4>0: E2809-30E2808 [VIRTUAL E2809-30E2808] (RO)

The first line does not show up in my kernel at boot.

Unfortunately, the kernel panics at the end with unable to mount root on 1f:00 (cramfs wrong magic).

How can I join the mediagate wiki (flyduck doesn't work anymore)?

We need to start thinking of a way to bundle up all these useful applications Maybe the wiki is OK to start with as all these bits are pretty small.

I'm probably going to put all of my source and binaries - including WIP stuff - on my own webspace soon. This is mainly so I can access it from anywhere, but I've got no problems with other people downloading it.

When I get round to adding a "who's doing what?" section on the wiki I'll put the URL in there...

1. the ide-jasper.c from the GPL.zip on the mediagate site doesn't work (or there are some changest to be made in hardware.h)


I used the KiSS kernel as a starting point. My IDE didn't give errors but I didn't test with a HD! I have attached my .config for this kernel. I guess I ought to try starting from the MG-35 one at some point, but the missing source discouraged me.


2. there seems to be a patch for blkmem.c as at boot it displays the following:


Go to the top leve menu for Sigma Designs Patches and enable Blkmem Address Probing. This seems to kick off a search for the blkmem start by assuming it contains a cramfs - make sure the start of flash is set right.

Unless you choose to switch to the KiSS sources, you maybe need to read your config and mine side-by-side and decide what to change.


How can I join the mediagate wiki (flyduck doesn't work anymore)?

You have a PM

Ian

I have attached my .config for this kernel.
Don't see it :(


You have a PM

Thanks; I'll post on the wiki my results when I get any.

Don't see it :(


I missed the barf at it being a tar.gz - second try with a .ZIP. Sorry about that!

Ian

Go to the top leve menu for Sigma Designs Patches and enable Blkmem Address Probing. This seems to kick off a search for the blkmem start by assuming it contains a cramfs - make sure the start of flash is set right.


It's worth noting that I couldn't see any attempt to dereference the pointer at 0x40000 to jump to 0xE2809 - I suspect the probing code scans through the whole kernel before finding the cramFS. But I could be wrong - blkmem.c isn't the neatest bit of code!

Ian

However, there is an argument that stuff should just be in people's phase 1/2 until it's actually useful to the Man in the Street.

IanIan,
In my opinion, there are three very broad categories of compiled objects.

Those needed for basic functionality or useful to the "man-in-the-street"
Those that are not needed for basic functionality, but must be in the compressed cramfs filesystem in a distributed .upgrade file.
Those useful to developers.

At this point in time, the telnet daemon and ftp daemon along with your new busybox fall into the first category, the hacked r/w mount of "fat" file systems will too. They allow the man-in-the-street to move mp3 files and smaller video files to their MG-35 without having to resort to NDFS. Once we have a replacement udhcpc, it, along with the utility to read/write the nv ram will belong here too, are this will make the unit far more friendly to family members of the 'man-in-the-street'

The reworked links of all the executables to allow their replacement in "phase1", and phase 1/2 stuff all fall into the second category. (Actually, the phase 1/2 stuff is for developers, but since most developers could not add that feature on their own into the cramfs, and then make their own .upgrade, it needs to be compiled into the .upgrade distributed to man-in-the-street.)

The tools to probe and dump memory, grab screenshots, clear screen, etc can all be downloaded by developers as needed and installed on either a network share or on their own fat32 partition. I don't think these need to be in the cramfs in the general release .upgrade. These all belong in the third category. They might fit in the cramfs, and might leave enough memory for all the media player functions today, but might just take precious ram space and cause something too fail that might work otherwise as a developer experiments on their MG-35 in the future.

Obviously, an object might move from this third category to one of the first two as it is integrated into basic, but expanded functionality. The http-daemon and some cgi scripts are very likely to be part of the basic .upgrade in the near future (as soon as they can do something useful to the 'man-in-the-street')

In my opinion, the wiki is the best place to describe all the available "bits" and "tools" but they don't all automatically belong in the general release .upgrade files.

Joe L.

At this point in time, the telnet daemon and ftp daemon along with your new busybox fall into the first category, the hacked r/w mount of "fat" file systems will too. They allow the man-in-the-street to move mp3 files and smaller video files to their MG-35 without having to resort to NDFS. Once we have a replacement udhcpc, it, along with the utility to read/write the nv ram will belong here too, are this will make the unit far more friendly to family members of the 'man-in-the-street'


The reworked links of all the executables to allow their replacement in "phase1", and phase 1/2 stuff all fall into the second category. (Actually, the phase 1/2 stuff is for developers, but since most developers could not add that feature on their own into the cramfs, and then make their own .upgrade, it needs to be compiled into the .upgrade distributed to man-in-the-street.)


OK, agreed, all makes sense. I'll aim for a new f/w release this weekend that gets these fundamental developer bits into place to hopefully allow all the experimentation we need to allow the next "MITS" release. However, remount of the HD is currently going to require scripts.


In my opinion, the wiki is the best place to describe all the available "bits" and "tools" but they don't all automatically belong in the general release .upgrade files.


OK, that makes sense too. I'll try and put some of the bits I've done on the wiki, either in separate files or one big toolkit.

Ian

sh-chdparm -C /dev/discs/disc0/disc

Thats the first of the 3 command running (Found it with my PID spy) when we create a playlist, but where the h*** is that sh-chdparm prog ?

I couldn't figure out why the Al Tek supplied udhcpc seems to exit after getting the lease when run from the command line but still shows in the process list. Basically, I didn't know how to read the process list.

It shows like this -
45 0 Z [udhcpc]
(others please confirm they see the same)

The brackets mean no command line. The Z means zombie! udhcpc has terminated but setup terminated first! So, the MG-35 will *not* be doing correct dhcp after the initial run.

But the most important question is how dvdplayer.bin decides that udhcpc has done the job - my copy doesn't seem to work. Maybe I should set terminate after lease so it works the same crummy way?!

Ian

sh-chdparm -C /dev/discs/disc0/disc

Thats the first of the 3 command running (Found it with my PID spy) when we create a playlist, but where the h*** is that sh-chdparm prog ?

I guess the sh-c is bogus and it's just hdparm that's being run.

Ian

sh-chdparm -C /dev/discs/disc0/disc

Thats the first of the 3 command running (Found it with my PID spy) when we create a playlist, but where the h*** is that sh-chdparm prog ?

Might it be:

sh -c "hdparm -C /dev/disks/disk0/disc"

sh -c runs the following string (hdparm -C /dev/disks/disk0/disc)as a command.

The hdparm -C option checks the disk status as described here:
(an excerpt from the manual page for hdparm)

hdparm -C
Check the current IDE power mode status, which will always be one of unknown (drive does not support this command), active/idle (normal operation), standby (low power mode, drive has spun down), or sleeping (lowest power mode, drive is completely shut down). The -S, -y, -Y, and -Z flags can be used to manipulate the IDE power modes.

Looks like it might be trying to determine if it needs to "spin up" a drive that has been spun down.

Joe L.

Not incredibly useful, but I now know what 7 of the first 8 bytes of video memory do...

0000: 3E ---- ??
0001: 04 8E 88 ---- Offset to beginning of "unknown" buffer (640x465 + 0x400 + 8) (WxH + palette + 8)
0004: 02 80 ---- Width of Overlay (640)
0006: 01 D1 ---- Height of Overlay (625)

These are uncharacteristically big-endian which is the reason I didn't spot what they were earlier (at least that's my excuse)

I couldn't figure out why the Al Tek supplied udhcpc seems to exit after getting the lease when run from the command line but still shows in the process list. Basically, I didn't know how to read the process list.

It shows like this -
45 0 Z [udhcpc]
(others please confirm they see the same)

The brackets mean no command line. The Z means zombie! udhcpc has terminated but setup terminated first! So, the MG-35 will *not* be doing correct dhcp after the initial run.

But the most important question is how dvdplayer.bin decides that udhcpc has done the job - my copy doesn't seem to work. Maybe I should set terminate after lease so it works the same crummy way?!

IanFrom my UNIX roots...

When processes are forked the parent process has the option to wait for the child process to exit and capture its exit status. It may also elect to not wait, but to continue doing whatever is desired. Either way, when the child process exits, the parent process will be sent an interrupt from the child process containing its exit status. This is the SIGCHLD signal.

Now, if the parent process has already terminated, before the child terminates, there is no process available to receive the SIGCHLD interrupt. As you already said, when this occurs, the child is then known as a "zombie" process. It cannot be killed by a kill -9 since it has already died. It "exit status" exists only as an entry in the process table, but the process itself is gone. (you can see the zombie process table entry using the "ps" command) Only way the zombie entry will go away is if you reboot the box.

So... it appears as if AlTech's setup command kicks off their udhcpc command and exits before it... Also, their "setup" did not correctly set the SIGCHLD interrupt handler. On most systems you could use "signal(SIGCHLD, SIG_IGN);" to cause the parent process to ignore the death of a child and not cause a zombie.

Joe L.

Might it be:

sh -c "hdparm -C /dev/disks/disk0/disc"

sh -c runs the following string (hdparm -C /dev/disks/disk0/disc)as a command.

The hdparm -C option checks the disk status as described here:
(an excerpt from the manual page for hdparm)

hdparm -C
Check the current IDE power mode status, which will always be one of unknown (drive does not support this command), active/idle (normal operation), standby (low power mode, drive has spun down), or sleeping (lowest power mode, drive is completely shut down). The -S, -y, -Y, and -Z flags can be used to manipulate the IDE power modes.

Looks like it might be trying to determine if it needs to "spin up" a drive that has been spun down.

Joe L.

Make sense, cause like I said before, everything from the cmdline, as no space, so I need to guest them

So... it appears as if AlTech's setup command kicks off their udhcpc command and exits before it... Also, their "setup" did not correctly set the SIGCHLD interrupt handler. On most systems you could use "signal(SIGCHLD, SIG_IGN);" to cause the parent process to ignore the death of a child and not cause a zombie.


Yup, I kind of knew most of that in a vague way.

What I don't know is -
1) How dvdplayer.bin decides that udhcpc has done its job.
2) How dvdplayer.bin re-runs udhcpc if you enable dhcp in the GUI.

But I note that dvdplayer.bin does contain "/sbin/ifconfig eth0 down" and two strings containing "/bin/setup" and one containing "/bin/setup f" Could the "f" be for "fixed IP"? Maybe dvdplayer.bin re-runs setup at times?

What's messier is that setup has strings that indicate it reads /proc/nnn/stat so maybe it waits for udhcpc to become a zombie! setup also has strings that indicate that it can generate smb.conf - I guess it has to do this for the fixed IP case.

It's all very messy and far more complicated than it needs to be. Setup could launch udhcpc to run properly in the background, with udhcpc invoking a program when it gets a lease, and setup could call the same program for the fixed IP case. If the dhcp state changes, tell udhcpc to terminate.

I'll try making my version of udhcpc exit after lease and see if that helps.
If it doesn't, I can try running the Al Tek version from the command line and see if the GUI feels happer.

Ian

Make sense, cause like I said before, everything from the cmdline, as no space, so I need to guest them

That's because the separate strings are null terminated. Try this -

/proc/33 # cat cmdline | hexdump -C
00000000 2f 62 69 6e 2f 74 65 6c 6e 65 74 64 00 2d 6c 00 |/bin/telnetd.-l.|
00000010 2f 62 69 6e 2f 73 68 00 |/bin/sh.|
00000018

Note that hexdump wasn't in the original busybox but has been in all those PB/myself have supplied recently.

Ian

That's because the separate strings are null terminated. Try this -

/proc/33 # cat cmdline | hexdump -C
00000000 2f 62 69 6e 2f 74 65 6c 6e 65 74 64 00 2d 6c 00 |/bin/telnetd.-l.|
00000010 2f 62 69 6e 2f 73 68 00 |/bin/sh.|
00000018

Note that hexdump wasn't in the original busybox but has been in all those PB/myself have supplied recently.

Ian


K I will add that to my spy PID

I'll aim for a new f/w release this weekend ...
And I will try to take the time to fix an updated gfx-pack to go with that. I will be off to Paris next week and wont have time for anything but work until next weekend...

That's because the separate strings are null terminated. Try this -

/proc/33 # cat cmdline | hexdump -C
00000000 2f 62 69 6e 2f 74 65 6c 6e 65 74 64 00 2d 6c 00 |/bin/telnetd.-l.|
00000010 2f 62 69 6e 2f 73 68 00 |/bin/sh.|
00000018

Note that hexdump wasn't in the original busybox but has been in all those PB/myself have supplied recently.

Ian


Ah man you just fix my problem with my spy PID, everytime I was reading the file with a fopen (in C) I only had the first command and everything after was gone (I didnt know why, so I change the fopen with a system("cat") but it took more process to run that, and sometime the prog wasnt fast enough to get all the PID) but if you say that it seperate with a null string, thats make sense, cause a string in c end with '\0' or null

Well, the 1.4.4.5 firmware with only links in /bin is looking good. I've got a phase 1/2 that maps a ramfs over bin and copies extra bitsin, and it should play everything (more testing required)

I've now got a good test rig for finding out why my udhcpd doesn't flag to dvdplayer.bin that the network is OK. I can try mine and stock within a few seconds of each other. But stock still seems to have some "secret sauce" way about it.

Ian

Just a thought: maybe it's useful to include in the cramfs a file with our version number. Sometimes I forget which version is now on my MG35. I saw the README in the latest release, it could be a place to keep that info, but I think it just waste of flash space. Anyhow, you generally need the readme file before flashing, not after...

Better have a 0 bytes file like /firmware.1.4.4.5_pre0 or something like this, and keep the readme on the internet.

I have uploaded a new set of graphics to Yahoo Groups (http://tech.groups.yahoo.com/group/mg-35_firmware_mods/files/MG-35%20Graphics/). I hope I got it right (really hard to assign colors that should match a new theme) this time. Subtitles should be white with black outline, had to alter some dialogs backdrops, the old "back" glyph is back in main menu, OSD backdrop should now be dark cyan insted of uggly green etc.

Ps. Started some kind of "revision system" on this theme. I got it now in four flavors, I have named them A, B, C and this latest D. The latest one will always be up on Yahoo Groups, the rest can be provided upon request...

Just a thought: maybe it's useful to include in the cramfs a file with our version number. Sometimes I forget which version is now on my MG35. I saw the README in the latest release, it could be a place to keep that info, but I think it just waste of flash space. Anyhow, you generally need the readme file before flashing, not after...

Better have a 0 bytes file like /firmware.1.4.4.5_pre0 or something like this, and keep the readme on the internet.

Uncanny! In the next two releases I'm planning, I've got a file called VERSION in the root. I can switch this to the zero byte file you suggest if people prefer.

I'd like to keep the README as long as it's not too big. It's actually a good place for me to track what I'm doing with releases, but I guess my build script could remove this as it adds the VERSION file (which I might also have include build date/time)

Ian

I have uploaded a new set of graphics to Yahoo Groups (http://tech.groups.yahoo.com/group/mg-35_firmware_mods/files/MG-35%20Graphics/). I hope I got it right (really hard to assign colors that should match a new theme) this time. Subtitles should be white with black outline, had to alter some dialogs backdrops, the old "back" glyph is back in main menu, OSD backdrop should now be dark cyan insted of uggly green etc.


I guess I might have screwed up, but firmware built with this new palette and graphics looks pretty bad here. On the media screen, the HD and network have pink boxes around them. And when selecting anything, unselected items are dark grey on light black. :)

I've checked files/dates through the build process and it looks like I updated everything.

Where do we go from here? Should I stick the firmware somewhere were you can see if? Or use dumptop or one of the screen dump utilities (haven't played with the latter yet)?

Ian

I am currently uploading MG35-1.4.4.5-alpha1 to Yahoo.

Changes -
Moved all binaries to /sbin/rbin and made everything in / and /bin into links.
New busybox with nslookup

I have put my phase1/2 scripts into the zip so you can see how I'm using this release.

I've tested this with various media off network and have also reflashed to older firmware from both network and HD.

This release allows easy replacement of any binary including dvdplayer.bin (though the approach is slightly different for the latter as it has to be done at phase1)

A change I forgot to mention in the readme is that /etc/resolv.conf is now a link to /hosts/resolv.conf - this is in preparation for a new udhcpc

Ian