I haven't been posting much to my blog, but what I've been doing is studying the Ellion source and trying to understand the structure.
I have managed to create the traditional "hello world" and have it appear on the TV. That may not seem significant, but for me that's a major step forward since it means I have all of the steps identified for initializing the ScreenPlay. However, most of the steps for painting the rectangle, loading the font and writing the Hello World text on screen still rely on the internal structures of the DvdPlayer program.
In the process, I've had to stop/restart multiple times. Each time that the program stops, whatever was displayed on the TV stays there. If you try to run the program again, it fails to allocate graphical memory because the memory is already allocated. I've been using "stopall" to free up the memory.
What I didn't realize was that stopall was NOT the program responsible for freeing up the memory. It's RootApp, which is called without any command line arguments by the stopall program.
Well, the code for RootApp reinitialize can now be incorporated into my starting Hello World program to auto reinitialize each time :) Like I said, minor discovery, but I felt it was worth sharing anyway.
Hacking devices can/will void your warranty and can turn your expensive consumer electronics into worthless trash if you don't know what you're doing. This blog is for information purposes only, and if you try to hack into your own consumer electronics, you do so at your own risk. The device I'm currently hacking is the Canon SX10 IS camera.
Sunday, November 29, 2009
Friday, November 6, 2009
More about Ellion Firmware on Iomega ScreenPlay Pro HD
Ok, here's the code for the remotes:
RemoteControl.cpp
And then a minor adjustment in RemoteControl.h. I added:
So how did I find out the IOMEGA_CUSTOMER_CODE value? In the ir_control.cpp program, there's a couple of places where IRCodeTranslate(key) is called. All I had to do was put a printf("code: %x\n", key); before it, then run the ./DvdPlayer and press a few remote buttons. It is the last 4 characters (LO WORD) that are returned. At least, for that particular remote protocol it is. That's a fairly common remote protocol, but they did have one other listed (which I left commented in the above code).
So what's so exciting about the Ellion vs the Iomega in terms of functionality? There are several features that the Ellion had implemented that were wish list items on the Iomega.
1) Screensaver
2) USB shows label on NTFS drives
3) Ability to shut off the preview
4) Returns to where you left off. If you exit to the main menu and then reselect the HDD drive, you'll be in the same directory as when you left.
5) Continue movie after stop.
6) Timeshifting (doesn't yet work, may require a dedicated partition on the hard drive)
7) Network browsing / favorites (appears to be able to store username/password, can access root of hard drive).
8) NDAS friendly
9) Favorites folder
10) Auto Chapter during recording
11) Can record to USB
12) Can edit recorded video
13) Good file copy / management
14) Quick display of wifi integrity by pressing display button twice
In addition, there is also DTV tuning and channel scan/set. These are not useful on the Iomega, at least not until somebody figures out what hardware is needed to hook up to the iomega to get it working. There's definitely an area in the bottom of the drive reserved for it, so it's just a matter of determining what tuner module needs to be added.
Now, it's not a pretty interface. Some of the words are very hard to see (for instance, white on yellow) but that kind of thing is easy to change (just edit the Resources in the resource folder). Mapping buttons on the remote to other key commands should be easy. I'm eyeing the instant replay and commercial skip commands.
Also worth mentioning... when I was playing a movie and pressed Home, the menu translucently overlaid the video, which continued to play in the background. That's good, because it means it will be possible to do that in a future replacement media player. So there is a lot we can learn from studying this firmware.
RemoteControl.cpp
#include <Platform_Lib/RemoteControl/RemoteControl.h>
ENUM_REMOTE_PROTOCOL getIRProtocol(void) {
// return IR_PROCOTOL_C03;
return IR_PROCOTOL_NEC;
};
char IRCodeTranslate(int code) {
if((code & 0x0000ffff) != IOMEGA_CUSTOMER_CODE)
return -1;
switch((code & 0x00ff0000)>>16) {
//for the complete list of available commands, see Include/Platform_Lib/Graphics/user_cmd.h
case 18: return CMD_POWER;
case 27: return CMD_DISPLAY;
case 72: return CMD_SETUP;
case 21: return CMD_PSCAN;
case 22: return CMD_MENU;
case 12: return CMD_GUIDE;
case 1: return CMD_UP;
case 9: return CMD_DOWN;
case 25: return CMD_LEFT;
case 17: return CMD_RIGHT;
case 23: return CMD_SELECT;
case 31: return CMD_RETURN;
case 8: return CMD_DELETE;
case 24: return CMD_ZERO;
case 65: return CMD_ONE;
case 77: return CMD_TWO;
case 69: return CMD_THREE;
case 66: return CMD_FOUR;
case 78: return CMD_FIVE;
case 70: return CMD_SIX;
case 67: return CMD_SEVEN;
case 79: return CMD_EIGHT;
case 71: return CMD_NINE;
case 4: return CMD_STOP;
case 14: return CMD_NEXT;
case 15: return CMD_PREV;
case 20: return CMD_FFWD;
case 28: return CMD_FRWD;
case 11: return CMD_SEARCH;
case 3: return CMD_REPEAT;
case 2: return CMD_AB_REPEAT;
case 75: return CMD_STITLE;
case 73: return CMD_AUDIO;
case 74: return CMD_ANGLE;
case 16: return CMD_ZOOM;
case 13: return CMD_VOL_UP;
case 19: return CMD_VOL_DOWN;
case 29: return CMD_FORCE_RECORD;
case 26: return CMD_SOURCE;
// return CMD_EJECT;
// return CMD_GCODE;
// return CMD_SCHEDULE;
// return CMD_DISC_UTILITY;
// return CMD_HDD;
// return CMD_DVD;
// return CMD_USB;
// return CMD_DVCONTROL;
// return CMD_FILE_COPY;
// return CMD_INSTANT_REPLAY;
// return CMD_CMSKIP; // commercial skip
// return CMD_RECORD_PLAY;
// return CMD_PLAY;
// return CMD_PAUSE;
// return CMD_SFWD;
// return CMD_MUTE;
// return CMD_ZOOM_IN;
// return CMD_ZOOM_OUT;
// return CMD_QUALITY;
// return CMD_NET; // ellion specific
default:
return -1;
}
}
And then a minor adjustment in RemoteControl.h. I added:
#define IOMEGA_CUSTOMER_CODE 0x3F40
So how did I find out the IOMEGA_CUSTOMER_CODE value? In the ir_control.cpp program, there's a couple of places where IRCodeTranslate(key) is called. All I had to do was put a printf("code: %x\n", key); before it, then run the ./DvdPlayer and press a few remote buttons. It is the last 4 characters (LO WORD) that are returned. At least, for that particular remote protocol it is. That's a fairly common remote protocol, but they did have one other listed (which I left commented in the above code).
So what's so exciting about the Ellion vs the Iomega in terms of functionality? There are several features that the Ellion had implemented that were wish list items on the Iomega.
1) Screensaver
2) USB shows label on NTFS drives
3) Ability to shut off the preview
4) Returns to where you left off. If you exit to the main menu and then reselect the HDD drive, you'll be in the same directory as when you left.
5) Continue movie after stop.
6) Timeshifting (doesn't yet work, may require a dedicated partition on the hard drive)
7) Network browsing / favorites (appears to be able to store username/password, can access root of hard drive).
8) NDAS friendly
9) Favorites folder
10) Auto Chapter during recording
11) Can record to USB
12) Can edit recorded video
13) Good file copy / management
14) Quick display of wifi integrity by pressing display button twice
In addition, there is also DTV tuning and channel scan/set. These are not useful on the Iomega, at least not until somebody figures out what hardware is needed to hook up to the iomega to get it working. There's definitely an area in the bottom of the drive reserved for it, so it's just a matter of determining what tuner module needs to be added.
Now, it's not a pretty interface. Some of the words are very hard to see (for instance, white on yellow) but that kind of thing is easy to change (just edit the Resources in the resource folder). Mapping buttons on the remote to other key commands should be easy. I'm eyeing the instant replay and commercial skip commands.
Also worth mentioning... when I was playing a movie and pressed Home, the menu translucently overlaid the video, which continued to play in the background. That's good, because it means it will be possible to do that in a future replacement media player. So there is a lot we can learn from studying this firmware.
Wednesday, November 4, 2009
That's not my menu...!
Tonight, I found that in the Ellion Open source, UnitTest/Grandma_DG_StateMachine was the source code for the DvdPlayer. It was everything necessary, but referenced a few things that weren't quite right. For one, it tried to get to the Utility and Platform_Lib as if they were right there. So I put in a symbolic link to put them there. Second was that it was trying to reference the mp3info.h in the mp3info directory when it was really in the mp3info/Include directory. So I copied to to the mp3info directory (yeah, I should have used a hard link instead, doh!)
Last piece was that it was trying to get to a Tools/MConfig, which wasn't there. So I found a Tools/MConfig in the conceptronic sources and put it there. It all compiled (and I mean compiled, not linked a bunch of already compiled .o files :D )
I copied it and the resource directory out on the ScreenPlay. Like in previous attempts, it came up in Pal mode. Unlike in previous attempts, it was now reading the keyboard. So I exited the program and this time brought it up by typing ./DvdPlayer -f NTSC which forced it to NTSC mode.
It worked.
The remote control didn't work, but I could control everything from the keyboard through telnet. I was able to complete the configuration screen, then browse to both the USB and Main hard drives. Naturally, the menu is based on the same principles that the Iomega SPP is, where it just lists filenames and shows a preview. But I was able to browse to specific movies and launch them.
Since there is a file called ir_control.cpp in the directory, I'm positive I'll be able to get the remote control working...
But not tonight. It'll have to wait a couple of nights before I can get back to it.
Update: Too excited to sleep tonight. RemoteControl.cpp and RemoteControl.h in the Platform_Lib were the ones responsible. In RemoteControl.h, it defines the manufacturer's code for the Ellion, which they had two. So I stuck in a printf in the ir_control.cpp to find out what remote code was for the Iomega, and found out mine was 0x3f40. Stuck that in, now it should process the codes...except that the codes are all different. Luckily, prior work has paid off now: http://screenplayprohd.wikia.com/wiki/Remote the bottom half JP1 OBC codes are listed. So it is just a matter of changing the RemoteControl.cpp switch statement to use the Iomega codes intead of the Ellion ones. :)
Last piece was that it was trying to get to a Tools/MConfig, which wasn't there. So I found a Tools/MConfig in the conceptronic sources and put it there. It all compiled (and I mean compiled, not linked a bunch of already compiled .o files :D )
I copied it and the resource directory out on the ScreenPlay. Like in previous attempts, it came up in Pal mode. Unlike in previous attempts, it was now reading the keyboard. So I exited the program and this time brought it up by typing ./DvdPlayer -f NTSC which forced it to NTSC mode.
It worked.
The remote control didn't work, but I could control everything from the keyboard through telnet. I was able to complete the configuration screen, then browse to both the USB and Main hard drives. Naturally, the menu is based on the same principles that the Iomega SPP is, where it just lists filenames and shows a preview. But I was able to browse to specific movies and launch them.
Since there is a file called ir_control.cpp in the directory, I'm positive I'll be able to get the remote control working...
But not tonight. It'll have to wait a couple of nights before I can get back to it.
Update: Too excited to sleep tonight. RemoteControl.cpp and RemoteControl.h in the Platform_Lib were the ones responsible. In RemoteControl.h, it defines the manufacturer's code for the Ellion, which they had two. So I stuck in a printf in the ir_control.cpp to find out what remote code was for the Iomega, and found out mine was 0x3f40. Stuck that in, now it should process the codes...except that the codes are all different. Luckily, prior work has paid off now: http://screenplayprohd.wikia.com/wiki/Remote the bottom half JP1 OBC codes are listed. So it is just a matter of changing the RemoteControl.cpp switch statement to use the Iomega codes intead of the Ellion ones. :)
Tuesday, November 3, 2009
smbpasswd
Inspired from a forum post on the wiki, I decided to try to get smbpasswd going.
The post includes everything needed to set it up. The highlights are:
1) mount -o rw,remount /
2) vi /usr/local/samba/lib/smb.conf
3) Press i. modify the smb.conf.
4) change guest ok = yes to guest ok = no on whichever share you want to restrict. Adding shares is already documented on the wiki.
5) save the smb.conf file (press esc key followed by :wq )
Now you need smbpasswd. I've stuck it out there at: http://www.box.net/shared/l6kbxxb5pn
But the question is how did I make it?
351H_AP_GL ellion source that I blogged about earlier had the samba in system/branch_src_sharedmemory_integration/Utility/samba/Samba-3.0.23C. So I brought up my fedora virtual machine, switched to that directory and ran make. It built all of the samba stuff. mipsel-linux-strip on the smbpasswd file when it was finished, and copied it to my screenplay.
Since my screenplay is currently ext3, I didn't have to do a chmod to make it executable as it was already marked executable. I think the NTFS may do that too, but if it doesn't you'll need to move it onto one of the ext3 drives. Anyway, executed smbpasswd -a root and it added a root user with the password I gave it to the /etc/smbpasswd data file. I did this on my root share that I added, so now when I browse there, it prompts for password (username defaults to guest, grayed out), which I use the root smbpassword I set up and it opens. If I browse to the ScreenPlay share or my USB share, it just opens immediately, does not prompt for password. That's actually an added bonus, since it used to ask for my password and there was none so I just click OK and it would open it.
The post includes everything needed to set it up. The highlights are:
1) mount -o rw,remount /
2) vi /usr/local/samba/lib/smb.conf
3) Press i. modify the smb.conf.
4) change guest ok = yes to guest ok = no on whichever share you want to restrict. Adding shares is already documented on the wiki.
5) save the smb.conf file (press esc key followed by :wq )
Now you need smbpasswd. I've stuck it out there at: http://www.box.net/shared/l6kbxxb5pn
But the question is how did I make it?
351H_AP_GL ellion source that I blogged about earlier had the samba in system/branch_src_sharedmemory_integration/Utility/samba/Samba-3.0.23C. So I brought up my fedora virtual machine, switched to that directory and ran make. It built all of the samba stuff. mipsel-linux-strip on the smbpasswd file when it was finished, and copied it to my screenplay.
Since my screenplay is currently ext3, I didn't have to do a chmod to make it executable as it was already marked executable. I think the NTFS may do that too, but if it doesn't you'll need to move it onto one of the ext3 drives. Anyway, executed smbpasswd -a root and it added a root user with the password I gave it to the /etc/smbpasswd data file. I did this on my root share that I added, so now when I browse there, it prompts for password (username defaults to guest, grayed out), which I use the root smbpassword I set up and it opens. If I browse to the ScreenPlay share or my USB share, it just opens immediately, does not prompt for password. That's actually an added bonus, since it used to ask for my password and there was none so I just click OK and it would open it.
Sunday, November 1, 2009
Temporary diversion -- VSFTP and BFTPD
Super has been waiting for some help from me regarding VSFTP and BFTPD. I thought those were already in IomTools, but apparently the functions were not yet there. So I've helped with what I can and hopefully we'll see the new version soon.
Along the process, I discovered that VSFTP could not use the anonymous upload for the root directory. You have to create a directory on the media partition to do anonymous uploads. I had discovered this when I originally documented it on the wiki, but had forgotten and had to "rediscover" it. So I put it on the wiki this time.
Along the process, I discovered that VSFTP could not use the anonymous upload for the root directory. You have to create a directory on the media partition to do anonymous uploads. I had discovered this when I originally documented it on the wiki, but had forgotten and had to "rediscover" it. So I put it on the wiki this time.
Monday, October 26, 2009
Start of compiling
Really late right now so I'll do a quick synopsis: The source for 1.00.011 APP is missing some pieces. I'm downloading the 2.00.004 sources now to see if the missing pieces are there instead. But then I started playing around with the Ellion sources.
I compiled up most of the libraries, and then compiled the WatchDogApp (also known as RootApp). Tried to run it on my iomega and got a segmentation fault. After a little debugging and searching, I found that in the Include/OSAL/PLI.h file there is a #define that defines the DEF_MEM_SIZE to be 256. Well, the Iomega only has 64. So I switched it over to 64, recompiled the libraries and the RootApp and...
it was able to run.
I stuck in some additional debug statements to tell me, once and for all, what the player thinks it's Realtek chip # is. And without a doubt, I can now safely change my assumption from 1262 to WRONG.
It isn't a 1262. It's a 1282.
Code to find it: I placed this in the resetav function:
reg = (unsigned int *)pli_getIOAddress(0xb801a200);
printf("Chip id is %x\n", *reg);
And 1282 was returned.
I compiled up most of the libraries, and then compiled the WatchDogApp (also known as RootApp). Tried to run it on my iomega and got a segmentation fault. After a little debugging and searching, I found that in the Include/OSAL/PLI.h file there is a #define that defines the DEF_MEM_SIZE to be 256. Well, the Iomega only has 64. So I switched it over to 64, recompiled the libraries and the RootApp and...
it was able to run.
I stuck in some additional debug statements to tell me, once and for all, what the player thinks it's Realtek chip # is. And without a doubt, I can now safely change my assumption from 1262 to WRONG.
It isn't a 1262. It's a 1282.
Code to find it: I placed this in the resetav function:
reg = (unsigned int *)pli_getIOAddress(0xb801a200);
printf("Chip id is %x\n", *reg);
And 1282 was returned.
Saturday, October 24, 2009
Organization, and yet another toolchain (conceptronic / media giant)
Organization. I have two external 1 TB drives with ISOs and I've moved all of my stuff off of the screenplay so I can experiment with it. In the process, I decided to switch back to EXT3 for the screenplay. The screenplayprohd.wikia.com wiki details how to do that in filesystem. Anyway, after reformatting the drive, I then organized all of the videos on the other two drives under one directory called Alphabetical, and then subdirectories from there ABC, DEF, GHI, JKL, and so on with VWXYZ all in the same. So both external drives had that. Underneath each of those directories, I put another directory for each movie / group of movies. For instance, all of the Star Wars ISOs are under Alphabetical/STU/Star Wars.
On the Screenplay, I setup a small, hidden script in the root directory that removes the contents of the Alphabetical directory and recreates the same directory structure as on the USB drives. So it's a mirror image, but empty. Then I use symbolic links to link the contents of each of the USB drives. I do it this way because if you do a symbolic link of an ISO file, the screenplay can't mount and play it.
So here's the script:
I know that's ugly and I could have used a for statement on it. But this follows a script I am making that I'm not ready to divulge yet.
The result of that is that all of my movies appear on the main drive and I don't have to guess as to which USB drive has the movie. I just navigate to the screenplay (now automatically done during bootup, as explained in my last post). It has vastly simplied finding any of the more than 250 movies in my collection. Next, I'm going to try to add some dvd covers in some way so that the kids can browse all of the covers when just looking for a movie to view. I'll probably just put all of them in a single directory, maybe 8 to a JPG and add some background music to the folder...
Media Giant Now that I've finally gotten some time on my hands, I pulled down Fedora 11 virtual machine (from vmware appliances, I used the LinHost one
Then I pulled down the conceptronic GPL sources. 2.00.004 linux one is corrupt, so I used the 1.00.011 sources. Copied them onto the virtual machine (I put them in a windows shared directory and just accessed it from the VM).
Although the instructions are there in the readme for the doing the kernel and the app, the instructions did not work exactly as indicated. First, you need GCC. But not just any GCC. If you do a yum gcc command you'll end up with the latest stable gcc, and that won't compile the OS. Instead, I've found you have to pull down gcc 3.4.6. Do yum install compat-gcc34. Of course, you have to do this under su mode. sudo should work, but I just did su and I'm doing everything under that mode (I know, I know, bad idea).
Now at that point, you're going to have a gcc34 in the /usr/bin, but still no gcc, so you'll still get an error about compiling. I created a symlink to gcc ln -s /usr/bin/gcc34 /usr/bin/gcc and then followed the rest of the directions. When I was finished, I had a full image of everything, app included.
I haven't tried flashing the image in. Instead, I searched for DvdPlayer and then copied that onto my ScreenPlay, along with the Resources and the symlinks of the two font files in the Resources directory. I executed a kill -9 95 (my root app proces from ps was 95) and then stopall. Switched over to the /tmp/hddmedia/mediagiant directory where I had put the other DvdPlayer and executed it.
It came up.
Unfortunately, it is in PAL mode, so I can't see the screen very clearly right now and it is not responding to keystrokes, remote codes,or anything else to allow me to switch it to NTSC. When I get a chance, I'm going to hook it to my HD TV and see if I can see it better. Although, without any way to control it, it's basically worthless to me. But I can see the "Grab 'n Go" interface, so I'm pretty happy that I've gotten this far with it. I ended up having do terminate the process, which left info on the screen even though the process was no longer running. When I ran a stopall, then the info cleared from the screen and I was able to restart the Iomega DvdPlayer version.
The ellion open source code posted at MHDWorld has the source necessary to rebuild and change the DvdPlayer app, so next step will be to get that one compiled with this environment and see if it comes up. If it does, this will probably be the start of a new interface.
On the Screenplay, I setup a small, hidden script in the root directory that removes the contents of the Alphabetical directory and recreates the same directory structure as on the USB drives. So it's a mirror image, but empty. Then I use symbolic links to link the contents of each of the USB drives. I do it this way because if you do a symbolic link of an ISO file, the screenplay can't mount and play it.
So here's the script:
cd Alphabetical
rm -r *
mkdir ABC
mkdir DEF
mkdir GHI
mkdir JKL
mkdir MNO
mkdir PQR
mkdir STU
mkdir VWXYZ
ln -s /tmp/usbmounts/sda1/Alphabetical/ABC/* ABC &
ln -s /tmp/usbmounts/sda1/Alphabetical/DEF/* DEF &
ln -s /tmp/usbmounts/sda1/Alphabetical/GHI/* GHI &
ln -s /tmp/usbmounts/sda1/Alphabetical/JKL/* JKL &
ln -s /tmp/usbmounts/sda1/Alphabetical/MNO/* MNO &
ln -s /tmp/usbmounts/sda1/Alphabetical/PQR/* PQR &
ln -s /tmp/usbmounts/sda1/Alphabetical/STU/* STU &
ln -s /tmp/usbmounts/sda1/Alphabetical/VWXYZ/* VWXYZ &
ln -s /tmp/usbmounts/sdb1/Alphabetical/ABC/* ABC &
ln -s /tmp/usbmounts/sdb1/Alphabetical/DEF/* DEF &
ln -s /tmp/usbmounts/sdb1/Alphabetical/GHI/* GHI &
ln -s /tmp/usbmounts/sdb1/Alphabetical/JKL/* JKL &
ln -s /tmp/usbmounts/sdb1/Alphabetical/MNO/* MNO &
ln -s /tmp/usbmounts/sdb1/Alphabetical/PQR/* PQR &
ln -s /tmp/usbmounts/sdb1/Alphabetical/STU/* STU &
ln -s /tmp/usbmounts/sdb1/Alphabetical/VWXYZ/* VWXYZ &
I know that's ugly and I could have used a for statement on it. But this follows a script I am making that I'm not ready to divulge yet.
The result of that is that all of my movies appear on the main drive and I don't have to guess as to which USB drive has the movie. I just navigate to the screenplay (now automatically done during bootup, as explained in my last post). It has vastly simplied finding any of the more than 250 movies in my collection. Next, I'm going to try to add some dvd covers in some way so that the kids can browse all of the covers when just looking for a movie to view. I'll probably just put all of them in a single directory, maybe 8 to a JPG and add some background music to the folder...
Media Giant Now that I've finally gotten some time on my hands, I pulled down Fedora 11 virtual machine (from vmware appliances, I used the LinHost one
Then I pulled down the conceptronic GPL sources. 2.00.004 linux one is corrupt, so I used the 1.00.011 sources. Copied them onto the virtual machine (I put them in a windows shared directory and just accessed it from the VM).
Although the instructions are there in the readme for the doing the kernel and the app, the instructions did not work exactly as indicated. First, you need GCC. But not just any GCC. If you do a yum gcc command you'll end up with the latest stable gcc, and that won't compile the OS. Instead, I've found you have to pull down gcc 3.4.6. Do yum install compat-gcc34. Of course, you have to do this under su mode. sudo should work, but I just did su and I'm doing everything under that mode (I know, I know, bad idea).
Now at that point, you're going to have a gcc34 in the /usr/bin, but still no gcc, so you'll still get an error about compiling. I created a symlink to gcc ln -s /usr/bin/gcc34 /usr/bin/gcc and then followed the rest of the directions. When I was finished, I had a full image of everything, app included.
I haven't tried flashing the image in. Instead, I searched for DvdPlayer and then copied that onto my ScreenPlay, along with the Resources and the symlinks of the two font files in the Resources directory. I executed a kill -9 95 (my root app proces from ps was 95) and then stopall. Switched over to the /tmp/hddmedia/mediagiant directory where I had put the other DvdPlayer and executed it.
It came up.
Unfortunately, it is in PAL mode, so I can't see the screen very clearly right now and it is not responding to keystrokes, remote codes,or anything else to allow me to switch it to NTSC. When I get a chance, I'm going to hook it to my HD TV and see if I can see it better. Although, without any way to control it, it's basically worthless to me. But I can see the "Grab 'n Go" interface, so I'm pretty happy that I've gotten this far with it. I ended up having do terminate the process, which left info on the screen even though the process was no longer running. When I ran a stopall, then the info cleared from the screen and I was able to restart the Iomega DvdPlayer version.
The ellion open source code posted at MHDWorld has the source necessary to rebuild and change the DvdPlayer app, so next step will be to get that one compiled with this environment and see if it comes up. If it does, this will probably be the start of a new interface.
Subscribe to:
Posts (Atom)