I-Appliance BBS The Official Source for Internet Appliance Upgrades and Mods BBS Main List | Sign In | Sign Up | Search | Help | Linux-Hacker.net Reply to Thread | Printer |

Home / MISC Areas / Mattel JuiceBox Pixecutor progress report "Read my lips: no nand flashes!"

Pixecutor progress report (modified 1 times) jasonharper Profile Progress report on my PIC-based hack to make specially-formatted programs executable from the picture viewer: IT WORKS!!! Well, on a 2MB Juicebox anyway - I still don't have enough information to do it on an 8MB unit, and supporting both sizes would imply that the programs contain self-relocating code. I've mainly tested this with a modified version of the lcd_2 demo program from the wiki. It's even possible for the programs to cleanly exit back to the picture viewer, if they take care not to stomp on any used memory. Fortunately, there is an easily accessible pointer to a 56K buffer, into which the picture was loaded from the SD card before being memmove()d to the screen. The easiest thing to do is to relocate the screen to that buffer, keeping the executing program and its working RAM in the original screen area. However, there is currently a problem with the use of the buttons - they're still being buffered by the system, so when you exit, all of your program's button presses suddenly get performed in the picture viewer, resulting in some rather bizarre behavior (especially if they result in reselecting the .jbp file containing the program, thus re-executing it!). System calls appear to be fully functional. I've tried printf() (output goes to serial port 0), exec'ing another program, vfork() & exec (so that the program keeps running even after returning to the picture viewer), etc. There is a /bin/sh in the romdisk, so the obvious next step is to run it. Unfortunately, when they say "serial input disabled for production", they really mean it - that kernel option completely omits the actual receive code in the serial port driver, it's not something that can be turned back on with an ioctl or something. So, what I did was write a little program called 'serin', that just reads characters from the serial port hardware and copies them to stdout. I then have my picture-program do a system("serin | sh -i"), and... I'VE GOT A WORKING SHELL!!! It's a horribly inconvenient shell at the moment - there's no echo or editing of typed characters, but that's fixable. Note that 'serin' is a normal uClinux executable, in bFLT format - no assembly startup code, custom linker files, etc. were involved in producing it. ANY uClinux-arm program could be run from the SD card with basically the same technique. The shell environment's root directory is the 1.15 MB romdisk, with about 35 standard Unix commands available in /bin (most of which are links to busybox). There is a /proc filesystem, with all the possibilities for low-level tinkering that implies. There is an empty ramdisk mounted at /ram, also linked from /tmp. I'm not sure how big it is ('df', for some reason, is unable to determine its free space), but I think it's close to a megabyte. The SD card is mounted at /mnt, read-only. I'm not sure if that's an inherent limitation of the driver - I can't try to remount it RW in my current setup, since my 'serin' program is running off of it. Interestingly, the picture viewer appears to also try to mount a nand device or a second romdisk (neither of which is actually possible with the standard hardware), if the SD card isn't mountable. The PIC that's making all this possible, via the JTAG port, is an 18LF1220 - it's not really the appropriate part, it's just what I had handy. The PIC program is only 634 bytes long, with absolutely no attempt at optimization - it could easily be squeezed into the tiniest (and cheapest) of microcontrollers. My goal here is the PIC12F508/SN - it costs about 61 cents (qty=25), and its SOIC-8 package has a pin spacing such that it could be plopped down right on the JTAG pads and soldered in place. Only two actual wires would be needed, to bring power to the PIC. I've got some of these chips on order, I should have more to report once they've arrived and I've ported my code to them. I don't know if any of this will actually be useful to anyone, as there are some major limitations - it's completely incompatible with JTAG debugging, and it cannot automatically start a program when the Juicebox is turned on. But I'm feeling pretty darn proud of myself for having gotten this far! 01-27-2007 01:58:19

RE:Pixecutor progress report (modified 0 times) unix_guy Profile WoW! This is truly clever and makes the 2MB juiceboxes much more useful for linux programming since you don't have to waste the remaining ram with another version of clinux. This hack has real potential. I'd like to try this hack after you have a chance to document it. Since you have dealt with the jbp code I have an slightly off topic question. My currently project loads a picture on to the juice box as a background. The jbp format is 12 bits but I only see an 8 bit framebuffer (3 bits red, 3 bits green, 2 bits blue) so when I load a jbp image from my code I have to strip off the lower order bits to display it. Is this how the clinux code loads a jbp to the framebuffer or is there another undocumented graphics mode that I have missed ? -unix_guy 01-27-2007 07:36:03

RE:Pixecutor progress report (modified 0 times) jasonharper Profile There are actually two different LCD graphics modes that are usable with the hardware. One is the 240x160 3:3:2 mode you've currently using, the other is 4 bit monochrome with dimensions of 720 x 160 - relying on the fact that the LCD's pixels are successively tinted R/G/B. The differences between the two modes are in the high bits of LCDSADDR1, and the value of LCDSADDR3 - when you get it right, a .JBP can be loaded directly into screen memory. See JuiceboxRegsMP3 on the wiki for register values. I don't know why Samsung didn't document the 4:4:4 color mode - as far as I can tell, any LCD panel that physically supports the 3:3:2 mode will work in 4:4:4 as well. Maybe they thought that nobody would want to deal with writing to non-byte-aligned pixels? 01-27-2007 09:56:20

RE:Pixecutor progress report (modified 0 times) unix_guy Profile Thanks for the info. I'd like to use the 4:4:4 mode, could you be a little be more explicit and tell me what the bit settings are for LCDSADDR1 and LCDSADDR3 to set the lcd controller into the undocumented 4:4:4 mode ? Thanks, -unix_guy 01-27-2007 15:51:12

RE:Pixecutor progress report (modified 0 times) jasonharper Profile Like I said, see the wiki - http://elinux.org/wiki/JuiceBoxRegsMp3 captured the LCD registers in 4:4:4 mode. Basically, you want 00010 instead of 00011 in the top 5 bits of LCDSADDR1, and LCDSADDR3 should be 1.5X what it is in 3:3:2 mode (0xB4, assuming that you're not doing virtual screen panning). Also, the low 21 bits of LCDSADDR2 should be 0x7080 higher than the corresponding screen base address bits in LCDSADDR1, to set the proper display height. 01-27-2007 16:19:12

RE:Pixecutor progress report (modified 0 times) jasonharper Profile Update: The Juicebox ramdisk turns out to be dynamically sized, it never has any freespace. Also, it does contain one hidden file, the socket by which applications talk to the Nano-X graphics engine. The 800+K of unaccounted-for memory, that I assumed was the ramdisk, is actually the uClinux kernel - for some bizarre reason, it's being copied to RAM rather than executing directly from ROM. That wipes out much of the advantage I was hoping to get from using the existing kernel. I found out that there's a way to change a mounted disk from read-only to read/write without actually unmounting it. It appears to work when applied to the SD card at /mnt, however any attempt to actually write to it will either do nothing, or generate a filesystem panic message. I therefore assume that the developers left something out, either in the SD driver or the VFAT filesystem. "cat /proc/filesystems" does not show any other installed filesystems that could possibly be used to write to a card. I've tried compiling the Nano-X demo programs. Many of them actually run on the Juicebox, but they are mostly useless due to some combination of (A) assuming a screen size larger than 240x160, (B) lack of input devices, (C) disabled support for most graphics formats, and (D) font limitations. Notice how filenames are always shown in upper case in the picture viewer & MP3 player? Well, that's necessary because the font being used doesn't have any lower case letters! If anybody else ever wants to play with the built-in Nano-X, note that you'll need to get the headers and libraries from version 0.89pre7, to match what's in the romdisk. The current version of Nano-X has had some incompatible changes to the API, so most programs written with it will silently fail on the Juicebox. Just for the heck of it, I compiled the Nano-X version of Doom. The executable is about half a megabyte, even when optimizing for size - there's no way it's ever going to launch on a 2MB unit. I have to say that I'm feeling much less enthusiastic about this hack at this point. 01-31-2007 21:48:50

RE:Pixecutor progress report (modified 0 times) jasonharper Profile Update: I've compiled a couple of TinyGL/nano-X demo programs. Performance isn't great - TinyGL really needs hardware floating point - but it does work as long as you don't try to fill the entire screen (insufficient memory for the Z-buffer) or use any textures (which get resized to 256x256 pixels). I've figured out how to make a Pixecutor program auto-run, sort of - just hold the Play button down (either mechanically or electrically), and make sure that there are no .MP3's on the card, and that the desired program is the first (or only) .JBP. When the picture viewer launches, it will immediately go into "play all" mode and display that first picture. The PIC12F508's I order arrived a few days ago, and I've ported the JTAG code to them. I've installed one of the chips in a newly-opened Juicebox, and it works just fine - although it would have been somewhat easier to close the case back up if I had carved away a bit of the battery compartment plastic right over the PIC. I therefore consider the hardware side of this project complete - I just need to finish illustrating how to install the chip, and package up some demo programs that make use of it. unix_guy, please send me your mailing address (JasonHarper AT pobox DOT com). As the only person who's expressed an interest so far, you've won a FREE Pixecutor chip that you can install in a Juicebox. 02-07-2007 23:47:08

RE:Pixecutor progress report (modified 0 times) WestfW Profile This is really cool... Your "initial" program is limited to the size of a JBP picture, right? Though theoretically it could load more from the flash card? How about managing to bootload a whole new copy of ucLinux from the flash card, or is it too late to set up low-level stuff (recalling that the ARM has some HW protection mechanisms)? So can you use the program to install the missing half of the serial driver? BillW 02-14-2007 00:44:36

RE:Pixecutor progress report (modified 0 times) jasonharper Profile > Your "initial" program is limited to the size of a JBP picture, right? Yes, but this isn't really a problem - it can easily run a normal uClinux executable off of the memory card. I've given up on even trying to have the .JBP program do anything other than a single system() call, there are just too many limitations (in particular, the built-in nano-X graphics engine couldn't be used, since it's tied to the normal screen address - and would destroy the running program if used). I don't know if uClinux supports loading drivers at runtime - 'insmod' and related tools are not present in the romdisk. Anyway, piping input from a program that reads the serial port hardware works adequately for now, and could be made to work completely transparently by using a pseudo-TTY instead of a pipe. The lack of write access to the SD card seems like a much more serious problem to me. Bootloading an entirely new uClinux kernel should certainly be possible. In fact, on an 8MB unit, it would be nearly trivial - load the entire kernel image into a block of allocated RAM (using the standard I/O routines), kill interrupts, copy the image to the bottom of RAM, then jump to it. There is no effective HW protection against doing something like this because there is no memory management unit. Overwriting the interrupt vector, and then causing an interrupt of some sort (perhaps via a timer), would be sufficient to gain control of the CPU in a privileged mode. Bootloading on a 2MB unit would be harder, since there's not enough room to hold both the running and new kernels. It would be necessary to do the boot in two stages, but this isn't any different from what people have already done with combination NAND/SD cartridges. Of course, the question is whether it's even possible to build a kernel that's an overall improvement over the built-in one, and will run in 2MB... 02-14-2007 11:00:28

RE:Pixecutor progress report (modified 0 times) WestfW Profile So a typical program to run via the Pixecutor is like main() { system("/mnt/mybiggerprogram"); } ? What happens if the program you run via the shell uses the display and thus wipes out the pixecute'd code? The obvious major improvement of a still-tiny kernel booted from the card would be a fully functional serial driver, I suspect. Could you record the output of "ls -lr /" or similar? I'm curious as to what is there. It SHOULD be possible to use the rom disk structure even if a new kernel is booted, right? 02-15-2007 00:42:36

RE:Pixecutor progress report (modified 0 times) jasonharper Profile > system("/mnt/mybiggerprogram"); Well, you'd be better off doing something like: system("killall pvplayer; exec mybiggerprogram"); Killing the media player frees up quite a bit of memory, and makes it safe to use the screen - the Pixecuted code is part of pvplayer as far as the OS is concerned, so it will never be returned to. And using 'exec' causes the shell spawned by system() to go away immediately, rather than hanging around in memory until mybiggerprogram exits. Here's a complete dump of the romdisk. 'X' indicates the executable flag (the only permission flag actually stored in the romdisk), decimal numbers are the length of regular files in bytes. I have no idea if this could be used from a new kernel - it has a distinctive header, so it's at least theoretically possible that it could be searched for in ROM. bin X dir bin/busybox X reg 160456 bin/cat -> bin/busybox bin/chmod -> bin/busybox bin/chown -> bin/busybox bin/cp -> bin/busybox bin/date -> bin/busybox bin/dd -> bin/busybox bin/df -> bin/busybox bin/dmesg -> bin/busybox bin/gunzip -> bin/busybox bin/gzip -> bin/busybox bin/hostname -> bin/busybox bin/kill -> bin/busybox bin/ln -> bin/busybox bin/ls -> bin/busybox bin/mkdir -> bin/busybox bin/mknod -> bin/busybox bin/more -> bin/busybox bin/mount -> bin/busybox bin/mv -> bin/busybox bin/ps -> bin/busybox bin/pwd -> bin/busybox bin/rm -> bin/busybox bin/sh X reg 46880 bin/rmdir -> bin/busybox bin/sleep -> bin/busybox bin/sync -> bin/busybox bin/umount -> bin/busybox bin/zcat -> bin/busybox bin/basename -> bin/busybox bin/du -> bin/busybox bin/killall -> bin/busybox bin/md5sum -> bin/busybox bin/init X reg 16624 bin/nano-X X reg 233516 bin/time -> bin/busybox bin/pvplayer X reg 379916 bin/top -> bin/busybox bin/uptime -> bin/busybox bin/which -> bin/busybox bin/chroot -> bin/busybox dev X dir dev/tty char dev 00050000 dev/console char dev 00050001 dev/cua0 char dev 00050040 dev/cua1 char dev 00050041 dev/mem char dev 00010001 dev/kmem char dev 00010002 dev/null char dev 00010003 dev/zero char dev 00010005 dev/random char dev 00010008 dev/urandom char dev 00010009 dev/ram0 blk dev 00010000 dev/ram1 blk dev 00010001 dev/ptyp0 char dev 00020000 dev/ptyp1 char dev 00020001 dev/ptyp2 char dev 00020002 dev/ptyp3 char dev 00020003 dev/ptyp4 char dev 00020004 dev/ptyp5 char dev 00020005 dev/ptyp6 char dev 00020006 dev/ptyp7 char dev 00020007 dev/ptyp8 char dev 00020008 dev/ptyp9 char dev 00020009 dev/ptypa char dev 0002000A dev/ptypb char dev 0002000B dev/ptypc char dev 0002000C dev/ptypd char dev 0002000D dev/ptype char dev 0002000E dev/ptypf char dev 0002000F dev/rom0 blk dev 001F0000 dev/rom1 blk dev 001F0001 dev/rom2 blk dev 001F0002 dev/rom3 blk dev 001F0003 dev/rom4 blk dev 001F0004 dev/rom5 blk dev 001F0005 dev/rom6 blk dev 001F0006 dev/rom7 blk dev 001F0007 dev/rom8 blk dev 001F0008 dev/rom9 blk dev 001F0009 dev/tty0 char dev 00040000 dev/tty1 char dev 00040001 dev/tty2 char dev 00040002 dev/tty3 char dev 00040003 dev/ttyS0 char dev 00040040 dev/ttyS1 char dev 00040041 dev/ttyp0 char dev 00030000 dev/ttyp1 char dev 00030001 dev/ttyp2 char dev 00030002 dev/ttyp3 char dev 00030003 dev/ttyp4 char dev 00030004 dev/ttyp5 char dev 00030005 dev/ttyp6 char dev 00030006 dev/ttyp7 char dev 00030007 dev/ttyp8 char dev 00030008 dev/ttyp9 char dev 00030009 dev/ttypa char dev 0003000A dev/ttypb char dev 0003000B dev/ttypc char dev 0003000C dev/ttypd char dev 0003000D dev/ttype char dev 0003000E dev/ttypf char dev 0003000F dev/nand0 blk dev 00FE0000 dev/nand1 blk dev 00FE0001 dev/fb0 char dev 00650000 dev/audio char dev 00660000 dev/key char dev 00670000 dev/sd blk dev 00FC0000 dev/pm char dev 00680000 etc X dir etc/rc reg 161 etc/inittab reg 47 etc/services reg 8205 etc/motd reg 296 etc/passwd reg 21 etc/version reg 61 home X dir home/juicebox.dat reg 57600 home/wallpapers X dir home/wallpapers/wallpaper_mp3.jpg reg 6045 home/wallpapers/wallpaper_image.rgb reg 57600 home/wallpapers/img_b.jpg reg 5593 home/wallpapers/img_o.jpg reg 5861 home/wallpapers/img_x.jpg reg 5817 home/wallpapers/wallpaper_image.jpg reg 6117 home/wallpapers/wallpaper_mpeg4.jpg reg 5380 home/wallpapers/.xvpics X dir home/wallpapers/.xvpics/wallpaper_image2.jpg reg 4308 home/wallpapers/.xvpics/wallpaper_mp3.jpg reg 4308 home/wallpapers/.xvpics/wallpaper_mpeg4.jpg reg 4308 home/wallpapers/.xvpics/wallpaper_image.bmp reg 4310 home/wallpapers/.xvpics/wallpaper_mp3.bmp reg 4310 home/wallpapers/.xvpics/wallpaper_mpeg4.bmp reg 4310 home/wallpapers/wallpaper_mp3.rgb reg 57600 home/wallpapers/wallpaper_mpeg4.rgb reg 57600 home/wallpapers/warning.jpg reg 2052 home/wallpapers/warning.rgb reg 1872 home/juicebox.mp3 reg 49736 lib X dir mnt X dir proc X dir usr X dir var X dir tmp symlink to /ram sbin symlink to /bin ram X dir 02-15-2007 11:11:32

RE:Pixecutor progress report (modified 0 times) ForkBoy Profile Please forgive me if this is a dumb question, but where does the kernel and romdisk reside in memory? Would it be possible to halt the Juicebox via jtag, upload a new romfs, and restart the kernel? Also, would it be possible to explain how you are able to run new linux programs from a JTAG perspective? I'm a bit confused as to how you execute your code or /bin/sh Also you had mentioned "It would be necessary to do the boot in two stages, but this isn't any different from what people have already done with combination NAND/SD cartridges." Has anyone documented how to do this? -- I've not seen anything on the Wiki or the BBS on how this is actually done. 02-15-2007 18:03:14

RE:Pixecutor progress report (modified 0 times) jasonharper Profile > where does the kernel and romdisk reside in memory? The kernel is originally in ROM somewhere, perhaps in a compressed form. It's moved to the bottom 800K or so of the RAM starting at 0x0C000000 for execution. The romdisk is at 0x006A1000 on my 2MB JuiceBox - I don't know if that's constant across all versions. It extends to about 0x007C6000, somewhat over a megabyte in total. It supports XIP (execute in place), so the programs actually run directly from ROM - their only RAM use is for non-const variables and dynamically allocated memory. (Programs from a SD card have to be entirely copied into RAM to run.) > Would it be possible to halt the Juicebox via jtag, upload a new romfs, and restart the kernel? I don't see the point of this. Your new romfs obviously won't really be in ROM, so you might as well just keep the new files on the SD card (or perhaps copy them to the ramdisk). Also, I'm not sure the kernel is restartable - I think it may overwrite some of its initialization code once it's no longer needed. You'd need to load an entirely new kernel, anyway, to fundamentally change what the kernel is capable of. > Also, would it be possible to explain how you are able to run new linux programs from a JTAG perspective? I've put some details at http://www.elinux.org/wiki/JuiceBoxPixecutor/PixecutorTheory . The JTAG interface is capable of arbitrarily halting and redirecting code execution. It's also capable of reading and writing to memory, but that's a pain to implement, and I don't need it anyway - I let the picture viewer do the work of loading the initial program into memory. Basically, I set a watchpoint that triggers when a specific 8-byte value is written to 0x0C1F1F00 (the start of screen memory), and then force execution to continue at 0x0C1F1F08. The code contained in the picture is now running, although as far as uClinux is concerned, it's still the picture viewer. Arbitrary system calls can now be made, such as launching a normal program. > Also you had mentioned "It would be necessary to do the boot in two stages, but this isn't any different from what people have already done with combination NAND/SD cartridges." > Has anyone documented how to do this? -- I've not seen anything on the Wiki or the BBS on how this is actually done. Nobody has released complete details, because booting from a NAND cartridge necessarily involves duplicating a boot signature that Mattel and/or Emsoft could claim a copyright on. I guess you're supposed to figure out the rest of the details for yourself while rediscovering the signature. 02-15-2007 19:53:02

RE:Pixecutor progress report (modified 0 times) ForkBoy Profile Jasonharper, Thank you for providing additional details, your Pixecutor is quite ingenious! I'm quite disappointed that there haven't been any details released on running uCLinux from the NAND/SD cartridge. "I guess you're supposed to figure out the rest of the details for yourself while rediscovering the signature." Finding the "signature" isn't a big deal if you have a cartridge and JTAG, but I'm not really sure how to go from there to uCLinux. I'm no uCLinux expert and haven't had the time to learn more. I'm not looking for you to answer these questions, but maybe someone else on the BBS would know: Can uCLinux be run from 2MB ram if the bootloader is copied and run the cache/ram area? -- The sample romboot.S file has the kernel, romfs, and bootloader in 2MB... Could the romfs be put in the cartridge flash area? I understand the SD card would need a custom driver, but could the sd card then be mounted as well? Have you messed around with /dev/audio yet? 02-15-2007 21:23:24

RE:Pixecutor progress report (modified 0 times) WestfW Profile Hah! Another reason to work on booting ucLinux from the SD card using the pixecutor. For NAND boot, you need the "signature" so as to fool the rom bootloader. With pixecuter, you ARE the bootstrap, so no signature is required... 02-16-2007 16:48:29

RE:Pixecutor progress report (modified 0 times) WestfW Profile Seriously; booting uclinux from the SD card shouldn't be too hard, should it? And the display memory is probably a good place for a bootstrap to sit, too. At most, the bootstrap would have to re-implement enough of the SD-driver and FAT filesystem code to find the appropriate file on the card and copy it to memory after disabling .. everything, and then jump to the start of the new code. If you're lucky, you might be able to use the existing FAT code to get pointers to absolute addresses in the SD card and only need the driver code... 02-16-2007 17:18:21

RE:Pixecutor progress report (modified 1 times) jasonharper Profile I haven't done anything with /dev/audio yet - my development units have generally had their back cover entirely removed, so there's no speaker connected. Thanks to unix_guy, I've got an 8MB JuiceBox to work with now, and of course I installed a Pixecutor chip in it. I'm afraid the absolute worst-case scenario occurred: it worked perfectly the first try. That shouldn't have been possible, the current code in Pixecutor programs is definitely not position-independent, and the screen surely isn't sitting in the same place as on a 2MB unit, which would be out in the middle of 8MB. I couldn't tell any more without a serial port, so after two botched attempts at adding one to that unit, I finally got shell access. So here's the bad news: a 8MB JuiceBox only uses the first 2MB in uClinux. The amount of available memory is the same, and the screen is at the same address as on a 2MB unit. The remaining 6MB is completely going to waste, as far as I can tell. Yes, this is utterly insane. It should be possible to write a replacement malloc() implementation that allocates memory out of the unused 6MB, however I don't know of any way to get the kernel to use the extra memory. This wouldn't allow you to run a larger program than you currently can, but a small program could allocate a LOT of memory. The only difference I see in the 8MB unit is that there are two extra programs in /bin - lsz and lrz. These are X/Y/ZMODEM file send and receive utilities, respectively. I haven't tried them yet, as they surely won't work with my current 'serin' program (which insists on performing line editing on incoming serial data), but an updated version of serin would presumably allow them to work. 02-16-2007 21:00:36

RE:Pixecutor progress report (modified 0 times) jasonharper Profile Bootloading a new kernel via Pixecutor on an 8MB JuiceBox turned out to be nearly as trivial as I'd expected. I've successfully compiled a basic kernel from the Emsoft source, configured to use the full 8MB, and booted it. It's even possible to reuse the ROMdisk - the kernel configuration includes options for romfs address and size, which are easily determined from the serial output of a normal boot (just under the "Blkmem 1 disk images:" line). However, doing this has a side-effect that I hadn't considered: along with everything else the ROMdisk contains, you get the original startup script - so the new kernel ends up launching the media player! It soon dies with a "NO CARDS FOUND" message, since the Emsoft source doesn't include the SD/MMC driver (perhaps it isn't GPL like the other JuiceBox/Toymaker drivers?). Fortunately, the serial driver is fully functional now, so you've got shell access without any further effort. With no access to the SD card, the only way to run additional software is to download it to the RAMdisk after each boot, using the /bin/lrz utility that the developers thoughtfully forgot to remove from the ROM before release. This works, and I've used it to run a TinyGL demo that wouldn't fit in the memory available from the built-in kernel, but it's horribly inconvenient. 02-20-2007 22:12:32

Reply to Thread | Printer | All times are PST Powered by UltraBoard v1.62

I-Appliance BBS General - NEWS, Breaking NEWS - linux-hacker.net BBS on CD Questions - User Groups in Your Town - E-Bay, Yahoo Auction LINKS ONLY (MODERATED) - Jokes & Humor - usdtv box I-Opener Areas - I-Opener General Posts - I-Opener Technical Stuff - I-Opener Technical Info Reference (MODERATED) WebSurfer Areas - WebSurfer General Posts - WebSurfer Technical Stuff - WebSurfer Technical Info Reference (MODERATED) Other I-Appliances - Virgin Webplayer - WebPal - MailStation - 3Com Audrey - ThinkNIC / Oracle NIC - Gateway/AOL Connected Touch Pad - Philips/AOL-TV - ACER NT-150 STB - MSN Companion - Compaq IA - Emachines IA - IBM NetVista IA - Intel dot.station - MSNTV2 Network Computers - Fujitsu-Siemens Scovery Linux Net Computers - GallantWeb Server Consoles - Dreamcast - xbox hacking Web Pads - Epods One General Post - Panasonic CF-01 - Fujitsu Stylistic 1200 - Cybiko Thin Clients - Thin Clients DigitalVideoRecorders - DTV Recorders, Replay, TiVo, Etc... - Tivo Hacks Linux - Midori Linux General Board - ITX MotherBoards Single Board Computers - Earth Computers mARMalade Elite Member Area MISC Areas - The Swap Meet WE TAKE NO RESPONSIBILITY FOR ANY TRANSACTION HERE AND NO COMMERCIAL POST PERIOD !!! - Wireless Net - Cameras - Robotics - Routers/Gateways - Mattel JuiceBox