2011-04-25 00:01 hmm, i have one extra bit for ubb-vga. i could use it to upgrade one channel (R, G, or B) from 1 to 2 bits, or i could use it to resistively mix an offset to all channels. any idea what's better ? 2011-04-25 00:02 maybe i should simulate the thing ... 2011-04-25 00:04 upgrade is good, no? 2011-04-25 00:06 i wonder what would look better. in each case, you'd get twice the colors 2011-04-25 00:08 upgrading one channel is easier ;-) for mixing to all, i'd probably have to get the difference vectors to all possible colors in RGB space and calculate their length. the pick the color that's closest. 2011-04-25 00:31 [commit] Werner Almesberger: ubb-vga.c: removed commented-out code from earlier experiments http://qi-hw.com/p/ben-blinkenlights/8bd7199 2011-04-25 00:31 [commit] Werner Almesberger: ubb-vga/README: added title and compatibility list http://qi-hw.com/p/ben-blinkenlights/fb153b2 2011-04-25 00:31 [commit] Werner Almesberger: ubb-vga.c: removed unused #defines and rearranged the code a little http://qi-hw.com/p/ben-blinkenlights/554c664 2011-04-25 00:31 [commit] Werner Almesberger: ubb-vga.c: a bit more cleanup http://qi-hw.com/p/ben-blinkenlights/dae2169 2011-04-25 00:31 [commit] Werner Almesberger: ubb-vga.c: moved line length and timing to variables http://qi-hw.com/p/ben-blinkenlights/dab839a 2011-04-25 00:31 [commit] Werner Almesberger: ubb-vga: option -d to double the number of set/clear pairs, improving resolution http://qi-hw.com/p/ben-blinkenlights/67107d0 2011-04-25 00:31 [commit] Werner Almesberger: ubb-vga: documented single and double mode http://qi-hw.com/p/ben-blinkenlights/5df56a3 2011-04-25 00:54 kristianpaul: ah no, the math isn't quite so evil. once i draw the circuit diagram, it became clearer ;-) 2011-04-25 03:07 [commit] Werner Almesberger: renamed ubb-vga/res.fig to mapping.fig http://qi-hw.com/p/ben-blinkenlights/e1e473e 2011-04-25 03:10 wpwrak: diagrams and graphs usually are not so evil when coming from nice math 2011-04-25 03:10 wpwrak: (1 bit) use it to switch the matrix from 1:1 r->r, g->g, b->b, to sth like r->R+0.5G, g->G+0.5B, b->B+0.5R 2011-04-25 03:11 [commit] Werner Almesberger: ubb-vga/README: "single/double mode", not "single-double mode" http://qi-hw.com/p/ben-blinkenlights/ce1c6af 2011-04-25 03:12 DocScrutinizer: uh, that would require transistors 2011-04-25 03:12 really? 2011-04-25 03:13 hmm, yes, for batery it would 2011-04-25 03:13 DocScrutinizer: i'd like to keep this very very simple. my idea for the one bit would be to connect it via a resistor to each channel, kinda like a "bright/dim pixel" switch 2011-04-25 03:14 do you need a few hundered? 2011-04-25 03:14 DocScrutinizer: huh ? not sure if we're talking about the same thing :) this is my circuit: http://downloads.qi-hardware.com/people/werner/ubb/vga/ubb-vga-conn.jpg 2011-04-25 03:15 DocScrutinizer: at the moment, 3 x R + 3 x D + UBB. i'll change this to 6 x R + UBB plus whatever i need for making use of the one extra bit 2011-04-25 03:16 alas, VDD has a fat cap on it, so i can't switch it fast enough to do anything useful. well, i could use it for global brightness :) 2011-04-25 03:16 WTF is that? 2011-04-25 03:16 VGA out for the ben :) 2011-04-25 03:16 don't you read the list ? ;-) 2011-04-25 03:16 hah 2011-04-25 03:16 nah, too many lists 2011-04-25 03:18 what are the D? 2011-04-25 03:18 clamp? 2011-04-25 03:19 I.E. "Zeners"? 2011-04-25 03:19 voltage limiters. VGA wants 0.7 V max, so i drop to Vf. 2011-04-25 03:19 yeah, Zeners 2011-04-25 03:20 use 2 Schottky 2011-04-25 03:20 naw, just regular diodes :) 2011-04-25 03:20 err 4 2011-04-25 03:20 schematics: http://projects.qi-hardware.com/index.php/p/ben-blinkenlights/source/tree/master/ubb-vga/ubb-vga.sch 2011-04-25 03:20 3 into one 2011-04-25 03:20 and short the one to GND with your 4th bit 2011-04-25 03:21 i;ll replace them with resistors in the next version. no need for fancy semiconductors :) 2011-04-25 03:21 meh 2011-04-25 03:23 for your 4th bit for brightness you just need 1 additional diode 2011-04-25 03:23 if you got totem pole outputs 2011-04-25 03:24 err, plus one R 2011-04-25 03:24 hmm, how ? the outputs are GPIOs, so they switch between 0 and 3.3 V 2011-04-25 03:25 better you got an open collector output to GND 2011-04-25 03:25 OC may get messy. there are pull-ups inside the ben 2011-04-25 03:26 besides, i think i'd still need an R for each channel for the brightness bit, no ? 2011-04-25 03:26 nope 2011-04-25 03:27 your 3 diodes are to GND, no? 2011-04-25 03:27 yes. see http://projects.qi-hardware.com/index.php/p/ben-blinkenlights/source/tree/master/ubb-vga/ubb-vga.sch 2011-04-25 03:27 rise that "GND" by 0.2V and your output volage rises from 0.7 to 0.9 2011-04-25 03:28 aah, okay. that would be an option. couldn't get rid of the diodes then, though. 2011-04-25 03:28 but i could try the same with Rs ... 2011-04-25 03:28 or, for schottky, it rises from 0.3 to 0.6V 2011-04-25 03:29 nope, with Rs you get crosstalk 2011-04-25 03:29 lots of 2011-04-25 03:29 crosstalk is okay as long as i can calculate it :) 2011-04-25 03:29 lol 2011-04-25 03:30 i would basically get 16 points in 3-dimensional RGB space and then have to try to find the one that's closest to the pixel value. even old pythagoras cuold have done that ;-) 2011-04-25 03:31 I'd do a weird thing ;-P 2011-04-25 03:31 random() ? ;-) 2011-04-25 03:32 build an ultrasimple rather slow S&H strobed by the 4th bit, then add the value of the S&H to the 3 bits 2011-04-25 03:32 hehe, nice :) 2011-04-25 03:33 but that doesn't work. i'm already fighting with pixel timing 2011-04-25 03:33 hehe 2011-04-25 03:33 see also http://lists.en.qi-hardware.com/pipermail/discussion/2011-April/007835.html 2011-04-25 03:34 well, what was that amiga thing, where 1. pixel defined R, 2nd B, and 3rd G value 2011-04-25 03:34 and the thread starter: http://lists.en.qi-hardware.com/pipermail/discussion/2011-April/007817.html 2011-04-25 03:34 R/G/B so far that would be what i have 2011-04-25 03:36 yeah, but then you can have 9bpp and just a smaller resolution, for arbitrary areas of screen 2011-04-25 03:36 oh, i see :) 2011-04-25 03:37 well, i already kinda mix two pixels into one in "single" mode .. 2011-04-25 03:37 may be able to disentangle them a bit, though. we'll see. 2011-04-25 03:38 the main problem are the dreadfully slow GPIO updates. a set-clear pair takes 17 PCLK cycles. PCLK is 112 MHz. 2011-04-25 03:39 when i try to change PCLK (even make it slower), the system freezes. not sure yet why. 2011-04-25 03:40 another problem is memory bandwidth. also there, i'm close to the system's limits. not because i'd move so much data but because i need to squeeze it in the intervals in which i'm not busy pumping out pixels 2011-04-25 03:41 and read-as-you-go is too slow 2011-04-25 03:45 yay, funny. Sounds like ZX81 2011-04-25 03:45 oh yes, very :) 2011-04-25 03:51 DocScrutinizer: of course, in the ZX80/ZX81, they cheated and had hw video acceleration, while my little ubb-vga does it all with brute gpio force 2011-04-25 03:51 you're sure about the hw accel? 2011-04-25 03:52 what is a hw accel for a Z80 btw... 2011-04-25 03:52 ? 2011-04-25 03:52 DocScrutinizer: quite: http://www.mainbyte.com/ts1000/good_schematic_hi.jpg 2011-04-25 03:53 DocScrutinizer: i find the placement of X1 rather intriguing. i think this is the first time i see a crystal that's connected _between_ chips 2011-04-25 03:54 well, chips more complex than inverters :) 2011-04-25 03:55 kristianpaul: probably an 8 bit shift register, possibly plus a FIFO 2011-04-25 03:55 hehe 2011-04-25 03:55 shifters do nice job 2011-04-25 03:55 a FIFO?? 2011-04-25 03:55 hmm 2011-04-25 04:01 at least one FIFO stage would be nice. otherwise, you need to have very precise (and fast) timing for the reloading 2011-04-25 04:03 there are shiftregs with a sample stage 2011-04-25 04:04 DocScrutinizer: yup. i know i'm not the first to discover the usefulness of that ;-) 2011-04-25 04:04 anyway you're right. I thought it had direct video output from a r/2r 2011-04-25 04:06 used those a lot, both in and out, to extend 3 IO of an atmel to a chain of inputs/outputs of arbitrary length 2011-04-25 04:07 brr. what a waste. just use more mcus. multiprocessors are all the rage anyway ;-) 2011-04-25 04:08 you could even do remote code execution: send a function over SPI, the recipient writes it into its own flash, then runs it ;-) 2011-04-25 04:08 *cough* 2011-04-25 04:08 well, for a few thousand times, until the flash wears out :) 2011-04-25 04:10 nah, atmel 89c2051, has iirc 20mA per IO 2011-04-25 04:11 sth like 3EUR for a DIL20 2011-04-25 04:12 DIL .. *shiver* 2011-04-25 04:12 LOL 2011-04-25 04:12 really convenient 2011-04-25 04:13 too many holes to drill 2011-04-25 04:13 meh 2011-04-25 04:13 we ordered the boards 2011-04-25 04:13 how lame :) 2011-04-25 04:14 pretty good quality, doublesided with via, and 8 boards on one eurocard for iirc 30EUR 2011-04-25 04:15 good price, yes 2011-04-25 04:15 yeah, at a qty of 10 2011-04-25 04:18 http://www.mausklick-produktion.de/ 2011-04-25 04:18 the 'pusteflipper' 2011-04-25 04:19 ;-) 2011-04-25 08:02 [commit] David Kühling: Disable (all?) patented codecs.  Disable ffmpeg's (broken) ogg demuxer. http://qi-hw.com/p/openwrt-packages/ffb6f8b 2011-04-25 08:08 [commit] David Kühling: mplayer_jz47xx: upgrade to upstream version 0.1.2 that fixes some severe bugs http://qi-hw.com/p/openwrt-packages/7795ff0 2011-04-25 10:25 wpwrak: uh-oh, I'm talking with The Creator of pstree! 2011-04-25 10:38 whitequark: heh, you found the man page ;-) 2011-04-25 10:38 whitequark: you mean with the author of the man page :) 2011-04-25 10:40 dvdk: naw, the program as well :) i actually don't remember if i also wrote the man page or if this was someone else 2011-04-25 10:43 apt-get source psmisc 2011-04-25 10:43 :) 2011-04-25 10:43 Copyright (C) 1993-2002 Werner Almesberger 2011-04-25 10:43 wow they had computers back in 1993? 2011-04-25 10:45 wpwrak: did you see the mail about vga?  wondered why you had to use dats/datc , not just write to dat once per pixel 2011-04-25 10:46 ;-))) my first linux box was a i386dx with 25 MHz (or was it 20 MHz ?), 4 MB RAM and a "Hercules" video card. the hard disk had a whole 40 MB. that was so big that you had to split it into a 30 MB partition and a 10 MB partition. 2011-04-25 10:46 * pstree.c - display process tree 2011-04-25 10:46 * 2011-04-25 10:46 * Copyright (C) 1993-2002 Werner Almesberger 2011-04-25 10:46 :D 2011-04-25 10:46 * Copyright (C) 2002-2009 Craig Small 2011-04-25 10:47 yes seems they had dvdk ;) 2011-04-25 10:48 i had my DOS on the 30 MB partition and have 10 MB to that new Linux thing (0.12). a bit later, Linux got the 30 MB and DOS had to content itself with 10 MB. again a little later, Linux got a 10 MB swap partition :) 2011-04-25 10:48 lol 2011-04-25 10:48 ironically, back in those days (gcc 1.xx), compiling a kernel was faster than for many years afterwards (gcc 2.xx and beyond) 2011-04-25 10:48 how fast? (i want to wonder) 2011-04-25 10:50 dvdk: (vga) yes, the problem is that you can't write to PxDAT. you can only write to the set/clear registers. it's a nice idea to make sure operations are atomic, but in this case, it's quite inconvenient. 2011-04-25 10:50 wpwrak: ah, you mean pxdat is read only?  didn't realize that 2011-04-25 10:50 kristianpaul: ah, don't remember how long it took. just that it was fast. well, it also helped that linux had hardly any drivers back then :) 2011-04-25 10:50 dvdk: yup 2011-04-25 10:50 wpwrak: but isn't there a 'toggle' register? 2011-04-25 10:51 wpwrak: yeah drivers... always the problem is there.. 2011-04-25 10:51 well not always, but is not that the code that grown all days..?.. 2011-04-25 10:51 wpwrak: no toggle register afaics.  uhh :( 2011-04-25 10:52 wpwrak: btw, creating ntsc/pal timiings would give higher resulution 2011-04-25 10:52 dvdk: no toggle either 2011-04-25 10:52 (looking at the video drivers of the uzebox) 2011-04-25 10:53 dvdk: oh, i'm already maxing out the timing. in fact, even in "single" mode, i'm taking about 110% of the "official" time 2011-04-25 10:54 heads to travel 2011-04-25 10:54 read you later 2011-04-25 10:54 dvdk: the nice thing about digital monitors is that they try to re-interpret the timing on their own, so you can feed them pretty weird stuff and they'll still work 2011-04-25 10:54 wprwrak: i mean vga needs higher line clocks than ntsc/pal.  so going for vga approximately halves available resolutions.  the uzebox people have even slower i/o so they can only do ntsc/pal, as vga would not be usable 2011-04-25 10:56 wpwrak: used to write my own mode-lines for xservers, didn't know there was even a standard (that was on analog monitors, anyways). 2011-04-25 11:01 dvdk: (slower pixel clock) ah, i see. yes, that's basically what i do in "double" mode. there, my effective pixel clock is something like 6 MHz 2011-04-25 11:07 dvdk: mostof the time 2011-04-25 11:07 oops ... ente too early 2011-04-25 11:08 dvdk: most of the time, the monitor doesn't seem to care about the pixel clock (only when trying to figure out the phase), so what's really important are the vsync and hsync timings 2011-04-25 11:08 dvdk: i also found that trying to send every line only once was met with disapproval 2011-04-25 11:11 is reflashing his ben 2011-04-25 11:12 well, I try and hope it will all function ;) 2011-04-25 11:12 wpwrak: that's the advantage of pal/ntsc, where sending each line once would work 2011-04-25 11:12 s/would/might 2011-04-25 11:14 wpwrak: can't one use the 4-bit sdio data lines to directly bit-stream each line at the mmc clock rate? (i.e. one block transfer per line) 2011-04-25 11:15 wpwrak: only handling vsync via bit-banging 2011-04-25 11:17 dvdk: hmm. there's a "busy" handshake in SD. lemme see if i could get rid of that ... 2011-04-25 11:18 is looking up the datasheet 2011-04-25 11:24 flashing... flashing... 2011-04-25 11:24 takes a while coz connection to inet is per 3G 2011-04-25 11:25 is impatient ;) 2011-04-25 11:30 dvdk: hmm. sending a block without first receiving a response isn't something SD/SDIO would do. makes one wonder what would happen if we asked the MMC controller to do it anyway. 2011-04-25 11:31 wpwrak: what about the stream transfer mode, the datasheet talks about? 2011-04-25 11:31 wpwrak: isn't mmc just a subset of sdio? 2011-04-25 11:31 so maybe it's ok for sdio? 2011-04-25 11:33 wow, just encoded an old 4:3 movie for nanonote. 2011-04-25 11:33 encoded for full-screen 320x240 , plays without problems so far 2011-04-25 11:34 not quite sure yet what that stream mode is ... 2011-04-25 11:36 the datasheet is pretty bad.  the freescale imx datasheets have quite a number of details about sdio; maybe it's pretty close to the jz47xx hw? 2011-04-25 11:37 ah yes, taht sounds interesting 2011-04-25 11:37 http://www.sandisk.com/Assets/File/OEM/ApplicationNotes/MultiMediaCard/AppNoteMMCQAv1.0.pdf 2011-04-25 11:38 (bad data sheets) yes, thanks to sdcard.org treating their bloody protocol as partially secret 2011-04-25 11:39 ah, section 21.5.5.2 has stream mode. nice :) 2011-04-25 11:40 wpwrak: sure you want to rely on data card manuals?  isn't that a level too hiegh (above sdio)? 2011-04-25 11:41 the trick is to combine hints from all possible sources ;-) 2011-04-25 11:46 21.5.7, the table, bit 31: "OUT_OF_RAGE" :) 2011-04-25 13:02 Anyone running a 2.6.36 kernel or newer? 2011-04-25 13:02 I don't have battery information.. 2011-04-25 13:04 # CONFIG_BATTERY_JZ4740 is not set 2011-04-25 13:04 grr 2011-04-25 13:09 I'll try the trunk of xburst-tools 2011-04-25 13:19 do you mean the qi-kernel? 2011-04-25 13:28 kyak: I mean the linux kernel 2011-04-25 13:30 hm openwrt-trunk still does not have anything for 2.6.38 for xburst. 2011-04-25 13:32 [commit] David Kühling: nanonote-files: set mplayer config to use fullscreen hw-scaling by default http://qi-hw.com/p/openwrt-packages/dfdcbcb 2011-04-25 13:36 bonjour la france :D 2011-04-25 13:39 viric: linux kernel development for xburst is done here: http://projects.qi-hardware.com/index.php/p/qi-kernel/ 2011-04-25 13:39 kyak: but larsc uses to update openwrt-trunk setting series of patches and a config file. 2011-04-25 13:39 or *used to update* :) 2011-04-25 13:39 maybe he does not have 2.6.38 ready 2011-04-25 13:40 i'm not sure about that.. openwrt-xburst is using 2.6.32 for along time now 2011-04-25 13:40 openwrt-trunk only has configuration for 2.6.35 and 2.6.36 2011-04-25 13:40 sorry 2011-04-25 13:41 2.6.36 and 2.6.37. I'm using that 2.6.36 now 2011-04-25 13:41 I imagine that 'openwrt-xburst' works as a super-stable version (in terms of more tested). 2011-04-25 13:41 ah, *that* openwrt-trunk.. i misunderstood :) 2011-04-25 13:42 :) 2011-04-25 13:42 why is the qi openwrt still using 2.6.32? 2011-04-25 13:42 It's simply waiting for someone to require an update to achieve some new feature? 2011-04-25 13:43 i think moving to the latest openwrt-trunk is planned once it's released 2011-04-25 13:43 so far, openwrt-xburst is following openwrt-backfire 2011-04-25 13:43 "it's released"? What has to be relased exactly, and by who? 2011-04-25 13:43 Aahhh 2011-04-25 13:43 an openwrt major release. 2011-04-25 13:44 yea 2011-04-25 13:50 kyak: did you try the scaler from David? 2011-04-25 13:59 viric: nope, not yet 2011-04-25 14:29 xiangfu: it's me who wrote on xburst-tools... thank you for the answer 2011-04-25 14:29 I did not know about git submoduels 2011-04-25 14:29 submodules 2011-04-25 14:37 viric: oh. thanks for sending patch. we need more :D 2011-04-25 14:38 haha. I only prepare patches until it works for me. and it works for me now :) 2011-04-25 14:53 [commit] Xiangfu Liu: libtcod: using source code tags: 1.5.0 http://qi-hw.com/p/openwrt-packages/b59a47d 2011-04-25 16:02 !last tuxbrain 2011-04-25 16:02 ~last tuxbrain 2011-04-25 16:03 that would be: 2011-04-25 16:03 thankyou kyak 2011-04-25 16:03 np 2011-04-25 16:03 wpwrak: any chance sdio-driven vga is going to work? 2011-04-25 16:03 uhm... a little bit strange 1 week without tuxbrain news... 2011-04-25 16:04 wpwrak: btw if you need physical memory for dma in your user-space app, have a look here: 2011-04-25 16:04 http://mplayer-jz47xx.svn.sourceforge.net/viewvc/mplayer-jz47xx/trunk/jz47xx_vid.c?revision=HEAD&view=markup 2011-04-25 16:04 alloc_phys() 2011-04-25 16:05 :) 2011-04-25 16:06 [commit] David Kühling: mplayer_jz47xx: yet another upgrade with minor scaler improvements (accuracy) http://qi-hw.com/p/openwrt-packages/d6e8b1f 2011-04-25 16:06 [commit] David Kühling: mplayer: (increase release number) http://qi-hw.com/p/openwrt-packages/5751ee9 2011-04-25 16:08 dvdk: (vga) i was able to trick it into pumping out data. one problem is that i need to toggle CMD to fake a response from the MMC device. otherwise, it won't start the transfer. 2011-04-25 16:09 hahahah, check this: http://www.rwdubsreviews.com/2011/04/smart-book.html 2011-04-25 16:09 that will never ship 2011-04-25 16:09 man, this UBB-VGA sounds really exciting! 2011-04-25 16:10 wpwrak: cool.  so can you toggle CMD automatically using just gpio control registers.  or is real hw needed? 2011-04-25 16:10 rejon: just too bad VGA is slowly dying ... 2011-04-25 16:11 dvdk: just the GPIO, it seems. i hope this are not just some unreliable internal effects. residual charges on tri-stated bus lines or such. 2011-04-25 16:12 wpwrak I think we have a long time left on vga 2011-04-25 16:12 wpwrak what resolution do you think that VGA can get cranked up too? 2011-04-25 16:12 dvdk: i could perhaps still use CMD for VSYNC, with a little low-pass filter 2011-04-25 16:13 rejon: (resolution) don't know yet. i think i need at least VGA to get the timing right. there's a lot of "MMC" traffic happening before the pixel data. 2011-04-25 16:14 wpwrak: if continuous transfers work, don't you have to toggle cmd only once, and then keep streaming forever? 2011-04-25 16:15 dvdk: (continuous) ah, maybe. haven't tried that yet. 2011-04-25 16:16 somebody needs to alert tuxbrian that Easter holidays are complete. back to work! 2011-04-25 16:16 s/tuxbrian/tuxbrain 2011-04-25 16:17 rjeffries: monday may still be a holiday in spain (as it is in most of europe) 2011-04-25 17:05 wpwrak VGA is an analog display (I think) what parts would be required so (external to Ben) we have SPI input from Ben, and HDMI out (to display or TV)? 2011-04-25 17:05 I know tehre are several USB to dsiplay adapters a similar idea I think? 2011-04-25 17:07 actually... this takes me back to thoughts of external Propeller board. just a brain excercise is all 2011-04-25 17:08 by the way I contacted a guy who is close to the whole Propeller/Parallax stuff and he says teh follow-on will happen this year, will have new name 2011-04-25 17:11 rjeffries: i don't know HDMI. i would expect it to operate with a faster clock than what we can usefully provide 2011-04-25 17:15 ah, minimum clock speed of DVI is ~25 MHz. that would work. 2011-04-25 17:16 that is, if that's the link clock, not the pixel clock. looks like pixel clock, though 2011-04-25 17:18 wpwrak: looks like 25 mhz is the pixel clock :( 2011-04-25 17:18 ah yes, data clock = 10 x pixel clock. that would be 251 MHz. no way. 2011-04-25 17:28 wpwrak couldn't the clock originate external to Ben? (pardon my massive ignorance) 2011-04-25 17:29 if the external widget has memory, copy our framebuffer to it, then all magic happens elsewehere 2011-04-25 17:40 ha, there is movie call *troll* 2011-04-25 17:40 lol 2011-04-25 17:40 a mean for this year 2011-04-25 17:40 (end of OT) 2011-04-25 18:20 http://twitter.com/#!/PentagonPresSec/status/62531762345091072 2011-04-25 18:47 rjeffries: sure, you could have an external video generator. but that eliminates the simple beauty of the vga solution 2011-04-25 18:48 wpwrak understood. 2011-04-25 18:48 maybe just maybe Nokia has a hold card vs. a vs. Microfoft and Windows Phone 2011-04-25 18:50 s0rry for dupe 2011-04-25 18:50 http://tipstir.the-talk.net/n2946-nokia-tablet-meant-to-compete-with-the-ipad-low-price-huge-number-of-units 2011-04-25 18:50 lekernel: what has the world come to ... nowadays a torturer can't even enjoy his easter holidays in peace. the inquisitors sure had it better. 2011-04-25 18:53 rjeffries: trying to compete on low cost and high volume is a dangerous path for a high-overhead company like nokia. maybe they can beat apple, but they they're up to every single backyard CE fab in china. DVD players anyone ? ;-) 2011-04-25 18:54 rjeffries: of course, a drowning man will cling to anything :) 2011-04-25 18:56 IMO Nokia will make it, no question.  And they know how to manufacture in VERY high volume 2011-04-25 18:56 back in the day when I worked for Ericsson one person explained how crucial software quaity is 2011-04-25 18:57 as he put it, they were shipping a 747 worth of phone to China, per day 2011-04-25 19:00 Nokia tablet that is NOT Microsoft would be a good idea IMO 2011-04-25 19:00 rjeffries: i'm pretty sure those 747 are national flights today :) 2011-04-25 19:00 yes indeed. nobody builds anything in quantity oustide of asia. sadly 2011-04-25 19:00 rjeffries: nokia is now wed to M$, probably till death do them part 2011-04-25 19:00 I am amazed at the uptake of iPhone in China. many rich people I guess 2011-04-25 19:00 Intel so far is missing out on tablet wave 2011-04-25 19:06 rjeffries: maybe they just plan to sit it out. tables have come and gone so many times before, expecting them to disappear after a while wouldn't be the worst conclusion to draw. 2011-04-25 19:06 wow 78905 :-) 2011-04-25 19:06 rules ! :) 2011-04-25 19:32 it's kinda surprising that ingenic implemented stream mode. this thing is as close to vapourware as one can imagine. some specs are full of hints yet nobody actually documents it. 2011-04-25 19:43 ah, JEDEC JESD84-A441 has some more details. 2011-04-25 19:47 grmbl. MMC specify stream mode only for a 1 bit bus and ingenic implement this restriction :-( 2011-04-25 21:11 wpwrak when we have 4760 (it just a matter of time...;) will the increased CPU speed help with VGA hack? 2011-04-25 22:03 rjeffries: maybe. if things go well, then i'll use mainly the MMC controller, so the CPU speed would be less important 2011-04-25 22:35 mmc isnt dead yet? 2011-04-25 22:35 roh: they're still making new standards, it seems :) 2011-04-25 22:39 m-/ 2011-04-25 22:39 .s 2011-04-25 22:39 hm. can somebody explain to me what i missed? 2011-04-25 22:39 why is vga so important for you? 2011-04-25 22:41 oh, it fun :) 2011-04-25 22:41 s/it/it's/ 2011-04-25 22:42 besides, it may actually be useful. imagine giving a presentation with a ben :)