#qi-hardware IRC log for Monday, 2011-04-25

wpwrakhmm, 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 ?00:01
wpwrakmaybe i should simulate the thing ...00:02
kristianpaulupgrade is good, no?00:04
wpwraki wonder what would look better. in each case, you'd get twice the colors00:06
wpwrakupgrading 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.00:08
qi-bot[commit] Werner Almesberger: ubb-vga.c: removed commented-out code from earlier experiments http://qi-hw.com/p/ben-blinkenlights/8bd719900:31
qi-bot[commit] Werner Almesberger: ubb-vga/README: added title and compatibility list http://qi-hw.com/p/ben-blinkenlights/fb153b200:31
qi-bot[commit] Werner Almesberger: ubb-vga.c: removed unused #defines and rearranged the code a little http://qi-hw.com/p/ben-blinkenlights/554c66400:31
qi-bot[commit] Werner Almesberger: ubb-vga.c: a bit more cleanup http://qi-hw.com/p/ben-blinkenlights/dae216900:31
qi-bot[commit] Werner Almesberger: ubb-vga.c: moved line length and timing to variables http://qi-hw.com/p/ben-blinkenlights/dab839a00:31
qi-bot[commit] Werner Almesberger: ubb-vga: option -d to double the number of set/clear pairs, improving resolution http://qi-hw.com/p/ben-blinkenlights/67107d000:31
qi-bot[commit] Werner Almesberger: ubb-vga: documented single and double mode http://qi-hw.com/p/ben-blinkenlights/5df56a300:31
wpwrakkristianpaul: ah no, the math isn't quite so evil. once i draw the circuit diagram, it became clearer ;-)00:54
qi-bot[commit] Werner Almesberger: renamed ubb-vga/res.fig to mapping.fig http://qi-hw.com/p/ben-blinkenlights/e1e473e03:07
kristianpaulwpwrak: diagrams and graphs usually are not so evil when coming from nice math03:10
DocScrutinizerwpwrak: (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.5R03:10
qi-bot[commit] Werner Almesberger: ubb-vga/README: "single/double mode", not "single-double mode" http://qi-hw.com/p/ben-blinkenlights/ce1c6af03:11
wpwrakDocScrutinizer: uh, that would require transistors03:12
DocScrutinizerhmm, yes, for batery it would03:13
wpwrakDocScrutinizer: 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" switch03:13
DocScrutinizerdo you need a few hundered?03:14
wpwrakDocScrutinizer: 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.jpg03:14
wpwrakDocScrutinizer: 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 bit03:15
wpwrakalas, 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 :)03:16
DocScrutinizerWTF is that?03:16
wpwrakVGA out for the ben :)03:16
wpwrakdon't you read the list ? ;-)03:16
DocScrutinizernah, too many lists03:16
DocScrutinizerwhat are the D?03:18
DocScrutinizerI.E. "Zeners"?03:19
wpwrakvoltage limiters. VGA wants 0.7 V max, so i drop to Vf.03:19
DocScrutinizeryeah, Zeners03:19
DocScrutinizeruse 2 Schottky03:20
wpwraknaw, just regular diodes :)03:20
DocScrutinizererr 403:20
wpwrakschematics: http://projects.qi-hardware.com/index.php/p/ben-blinkenlights/source/tree/master/ubb-vga/ubb-vga.sch03:20
DocScrutinizer3 into one03:20
DocScrutinizerand short the one to GND with your 4th bit03:20
wpwraki;ll replace them with resistors in the next version. no need for fancy semiconductors :)03:21
DocScrutinizerfor your 4th bit for brightness you just need 1 additional diode03:23
DocScrutinizerif you got totem pole outputs03:23
DocScrutinizererr, plus one R03:24
wpwrakhmm, how ? the outputs are GPIOs, so they switch between 0 and 3.3 V03:24
DocScrutinizerbetter you got an open collector output to GND03:25
wpwrakOC may get messy. there are pull-ups inside the ben03:25
wpwrakbesides, i think i'd still need an R for each channel for the brightness bit, no ?03:26
DocScrutinizeryour 3 diodes are to GND, no?03:27
wpwrakyes. see http://projects.qi-hardware.com/index.php/p/ben-blinkenlights/source/tree/master/ubb-vga/ubb-vga.sch03:27
DocScrutinizerrise that "GND" by 0.2V and your output volage rises from 0.7 to 0.903:27
wpwrakaah, okay. that would be an option. couldn't get rid of the diodes then, though.03:28
wpwrakbut i could try the same with Rs ...03:28
DocScrutinizeror, for schottky, it rises from 0.3 to 0.6V03:28
DocScrutinizernope, with Rs you get crosstalk03:29
DocScrutinizerlots of03:29
wpwrakcrosstalk is okay as long as i can calculate it :)03:29
wpwraki 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 ;-)03:30
DocScrutinizerI'd do a weird thing ;-P03:31
wpwrakrandom() ? ;-)03:31
DocScrutinizerbuild an ultrasimple rather slow S&H strobed by the 4th bit, then add the value of the S&H to the 3 bits03:32
wpwrakhehe, nice :)03:32
wpwrakbut that doesn't work. i'm already fighting with pixel timing03:33
wpwraksee also http://lists.en.qi-hardware.com/pipermail/discussion/2011-April/007835.html03:33
DocScrutinizerwell, what was that amiga thing, where 1. pixel defined R, 2nd B, and 3rd G value03:34
wpwrakand the thread starter: http://lists.en.qi-hardware.com/pipermail/discussion/2011-April/007817.html03:34
wpwrakR/G/B so far that would be what i have03:34
DocScrutinizeryeah, but then you can have 9bpp and just a smaller resolution, for arbitrary areas of screen03:36
wpwrakoh, i see :)03:36
wpwrakwell, i already kinda mix two pixels into one in "single" mode ..03:37
wpwrakmay be able to disentangle them a bit, though. we'll see.03:37
wpwrakthe main problem are the dreadfully slow GPIO updates. a set-clear pair takes 17 PCLK cycles. PCLK is 112 MHz.03:38
wpwrakwhen i try to change PCLK (even make it slower), the system freezes. not sure yet why.03:39
wpwrakanother 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 pixels03:40
wpwrakand read-as-you-go is too slow03:41
DocScrutinizeryay, funny. Sounds like ZX8103:45
wpwrakoh yes, very :)03:45
wpwrakDocScrutinizer: of course, in the ZX80/ZX81, they cheated and had hw video acceleration, while my little ubb-vga does it all with brute gpio force03:51
DocScrutinizeryou're sure about the hw accel?03:51
kristianpaulwhat is a hw accel for a Z80 btw...03:52
wpwrakDocScrutinizer: quite: http://www.mainbyte.com/ts1000/good_schematic_hi.jpg03:52
wpwrakDocScrutinizer: i find the placement of X1 rather intriguing. i think this is the first time i see a crystal that's connected _between_ chips03:53
wpwrakwell, chips more complex than inverters :)03:54
wpwrakkristianpaul: probably an 8 bit shift register, possibly plus a FIFO03:55
kristianpaulshifters do nice job03:55
kristianpaula FIFO??03:55
wpwrakat least one FIFO stage would be nice. otherwise, you need to have very precise (and fast) timing for the reloading04:01
DocScrutinizerthere are shiftregs with a sample stage04:03
wpwrakDocScrutinizer: yup. i know i'm not the first to discover the usefulness of that ;-)04:04
DocScrutinizeranyway you're right. I thought it had direct video output from a r/2r04:04
DocScrutinizerused those a lot, both in and out, to extend 3 IO of an atmel to a chain of inputs/outputs of arbitrary length04:06
wpwrakbrr. what a waste. just use more mcus. multiprocessors are all the rage anyway ;-)04:07
wpwrakyou could even do remote code execution: send a function over SPI, the recipient writes it into its own flash, then runs it ;-)04:08
wpwrakwell, for a few thousand times, until the flash wears out :)04:08
DocScrutinizernah, atmel 89c2051, has iirc 20mA per IO04:10
DocScrutinizersth like 3EUR for a DIL2004:11
wpwrakDIL .. *shiver*04:12
DocScrutinizerreally convenient04:12
wpwraktoo many holes to drill04:13
DocScrutinizerwe ordered the boards04:13
wpwrakhow lame :)04:13
DocScrutinizerpretty good quality, doublesided with via, and 8 boards on one eurocard for iirc 30EUR04:14
wpwrakgood price, yes04:15
DocScrutinizeryeah, at a qty of 1004:15
DocScrutinizerthe 'pusteflipper'04:18
qi-bot[commit] David Kühling: Disable (all?) patented codecs.  Disable ffmpeg's (broken) ogg demuxer. http://qi-hw.com/p/openwrt-packages/ffb6f8b08:02
qi-bot[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/7795ff008:08
whitequarkwpwrak: uh-oh, I'm talking with The Creator of pstree!10:25
wpwrakwhitequark: heh, you found the man page ;-)10:38
dvdkwhitequark: you mean with the author of the man page :)10:38
wpwrakdvdk: naw, the program as well :) i actually don't remember if i also wrote the man page or if this was someone else10:40
dvdkapt-get source psmisc10:43
dvdkCopyright (C) 1993-2002 Werner Almesberger10:43
dvdkwow they had computers back in 1993?10:43
dvdkwpwrak: did you see the mail about vga?  wondered why you had to use dats/datc , not just write to dat once per pixel10:45
wpwrak;-))) 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.10:46
kristianpaul * pstree.c - display process tree10:46
kristianpaul *10:46
kristianpaul * Copyright (C) 1993-2002 Werner Almesberger10:46
kristianpaul* Copyright (C) 2002-2009 Craig Small10:46
kristianpaulyes seems they had dvdk ;)10:47
wpwraki 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 :)10:48
wpwrakironically, back in those days (gcc 1.xx), compiling a kernel was faster than for many years afterwards (gcc 2.xx and beyond)10:48
kristianpaulhow fast? (i want to wonder)10:48
wpwrakdvdk: (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.10:50
dvdkwpwrak: ah, you mean pxdat is read only?  didn't realize that10:50
wpwrakkristianpaul: 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 :)10:50
wpwrakdvdk: yup10:50
dvdkwpwrak: but isn't there a 'toggle' register?10:50
kristianpaulwpwrak: yeah drivers... always the problem is there..10:51
kristianpaulwell not always, but is not that the code that grown all days..?..10:51
dvdkwpwrak: no toggle register afaics.  uhh :(10:51
dvdkwpwrak: btw, creating ntsc/pal timiings would give higher resulution10:52
wpwrakdvdk: no toggle either10:52
dvdk(looking at the video drivers of the uzebox)10:52
wpwrakdvdk: oh, i'm already maxing out the timing. in fact, even in "single" mode, i'm taking about 110% of the "official" time10:53
Action: kristianpaul heads to travel 10:54
kristianpaulread you later10:54
wpwrakdvdk: 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 work10:54
dvdkwprwrak: 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 usable10:54
dvdkwpwrak: used to write my own mode-lines for xservers, didn't know there was even a standard (that was on analog monitors, anyways).10:56
wpwrakdvdk: (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 MHz11:01
wpwrakdvdk: mostof the time11:07
wpwrakoops ... ente too early11:07
wpwrakdvdk: 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 timings11:08
wpwrakdvdk: i also found that trying to send every line only once was met with disapproval11:08
Action: Fusin is reflashing his ben11:11
Fusinwell, I try and hope it will all function ;)11:12
dvdkwpwrak: that's the advantage of pal/ntsc, where sending each line once would work11:12
dvdkwpwrak: 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)11:14
dvdkwpwrak: only handling vsync via bit-banging11:15
wpwrakdvdk: hmm. there's a "busy" handshake in SD. lemme see if i could get rid of that ...11:17
Action: dvdk is looking up the datasheet11:18
Fusinflashing... flashing...11:24
Fusintakes a while coz connection to inet is per 3G11:24
Action: Fusin is impatient ;)11:25
wpwrakdvdk: 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.11:30
dvdkwpwrak: what about the stream transfer mode, the datasheet talks about?11:31
dvdkwpwrak: isn't mmc just a subset of sdio?11:31
dvdkso maybe it's ok for sdio?11:31
dvdkwow, just encoded an old 4:3 movie for nanonote.11:33
dvdkencoded for full-screen 320x240 , plays without problems so far11:33
wpwraknot quite sure yet what that stream mode is ...11:34
dvdkthe 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?11:36
wpwrakah yes, taht sounds interesting11:37
wpwrak(bad data sheets) yes, thanks to sdcard.org treating their bloody protocol as partially secret11:38
wpwrakah, section has stream mode. nice :)11:39
dvdkwpwrak: sure you want to rely on data card manuals?  isn't that a level too hiegh (above sdio)?11:40
wpwrakthe trick is to combine hints from all possible sources ;-)11:41
wpwrak21.5.7, the table, bit 31: "OUT_OF_RAGE" :)11:46
viricAnyone running a 2.6.36 kernel or newer?13:02
viricI don't have battery information..13:02
viric# CONFIG_BATTERY_JZ4740 is not set13:04
viricI'll try the trunk of xburst-tools13:09
kyakdo you mean the qi-kernel?13:19
virickyak: I mean the linux kernel13:28
virichm openwrt-trunk still does not have anything for 2.6.38 for xburst.13:30
qi-bot[commit] David Kühling: nanonote-files: set mplayer config to use fullscreen hw-scaling by default http://qi-hw.com/p/openwrt-packages/dfdcbcb13:32
Fusinbonjour la france :D13:36
kyakviric: linux kernel development for xburst is done here: http://projects.qi-hardware.com/index.php/p/qi-kernel/13:39
virickyak: but larsc uses to update openwrt-trunk setting series of patches and a config file.13:39
viricor *used to update* :)13:39
viricmaybe he does not have 2.6.38 ready13:39
kyaki'm not sure about that.. openwrt-xburst is using 2.6.32 for along time now13:40
viricopenwrt-trunk only has configuration for 2.6.35 and 2.6.3613:40
viric2.6.36 and 2.6.37. I'm using that 2.6.36 now13:41
viricI imagine that 'openwrt-xburst' works as a super-stable version (in terms of more tested).13:41
kyakah, *that* openwrt-trunk.. i misunderstood :)13:41
viricwhy is the qi openwrt still using 2.6.32?13:42
viricIt's simply waiting for someone to require an update to achieve some new feature?13:42
kyaki think moving to the latest openwrt-trunk is planned once it's released13:43
kyakso far, openwrt-xburst is following openwrt-backfire13:43
viric"it's released"? What has to be relased exactly, and by who?13:43
virican openwrt major release.13:43
virickyak: did you try the scaler from David?13:50
kyakviric: nope, not yet13:59
viricxiangfu: it's me who wrote on xburst-tools... thank you for the answer14:29
viricI did not know about git submoduels14:29
xiangfuviric: oh. thanks for sending patch. we need more :D14:37
virichaha. I only prepare patches until it works for me. and it works for me now :)14:38
qi-bot[commit] Xiangfu Liu: libtcod: using source code tags: 1.5.0 http://qi-hw.com/p/openwrt-packages/b59a47d14:53
methril!last tuxbrain16:02
methril~last tuxbrain16:02
kyakthat would be:16:03
methrilthankyou kyak16:03
dvdkwpwrak: any chance sdio-driven vga is going to work?16:03
methriluhm... a little bit strange 1 week without tuxbrain news...16:03
dvdkwpwrak: btw if you need physical memory for dma in your user-space app, have a look here:16:04
qi-bot[commit] David Kühling: mplayer_jz47xx: yet another upgrade with minor scaler improvements (accuracy) http://qi-hw.com/p/openwrt-packages/d6e8b1f16:06
qi-bot[commit] David Kühling: mplayer: (increase release number) http://qi-hw.com/p/openwrt-packages/5751ee916:06
wpwrakdvdk: (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.16:08
rejonhahahah, check this: http://www.rwdubsreviews.com/2011/04/smart-book.html16:09
rejonthat will never ship16:09
rejonman, this UBB-VGA sounds really exciting!16:09
dvdkwpwrak: cool.  so can you toggle CMD automatically using just gpio control registers.  or is real hw needed?16:10
wpwrakrejon: just too bad VGA is slowly dying ...16:10
wpwrakdvdk: just the GPIO, it seems. i hope this are not just some unreliable internal effects. residual charges on tri-stated bus lines or such.16:11
rejonwpwrak I think we have a long time left on vga16:12
rejonwpwrak what resolution do you think that VGA can get cranked up too?16:12
wpwrakdvdk: i could perhaps still use CMD for VSYNC, with a little low-pass filter16:12
wpwrakrejon: (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.16:13
dvdkwpwrak: if continuous transfers work, don't you have to toggle cmd only once, and then keep streaming forever?16:14
wpwrakdvdk: (continuous) ah, maybe. haven't tried that yet.16:15
rjeffriessomebody needs to alert tuxbrian that Easter holidays are complete. back to work! <grin>16:16
wpwrakrjeffries: monday may still be a holiday in spain (as it is in most of europe)16:17
rjeffrieswpwrak 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)?17:05
rjeffriesI know tehre are several USB to dsiplay adapters a similar idea I think?17:05
rjeffriesactually... this takes me back to thoughts of external Propeller board. just a brain excercise is all17:07
rjeffriesby 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 name17:08
wpwrakrjeffries: i don't know HDMI. i would expect it to operate with a faster clock than what we can usefully provide17:11
wpwrakah, minimum clock speed of DVI is ~25 MHz. that would work.17:15
wpwrakthat is, if that's the link clock, not the pixel clock. looks like pixel clock, though17:16
dvdkwpwrak: looks like 25 mhz is the pixel clock :(17:18
wpwrakah yes, data clock = 10 x pixel clock. that would be 251 MHz. no way.17:18
rjeffrieswpwrak couldn't the clock originate external to Ben? (pardon my massive ignorance)17:28
rjeffriesif the external widget has memory, copy our framebuffer to it, then all magic happens elsewehere17:29
kristianpaulha, there is movie call *troll*17:40
kristianpaula mean for this year17:40
kristianpaul(end of OT)17:40
wpwrakrjeffries: sure, you could have an external video generator. but that eliminates the simple beauty of the vga solution18:47
rjeffrieswpwrak understood.18:48
rjeffriesmaybe just maybe Nokia has a hold card vs. a vs. Microfoft and Windows Phone18:48
Last message repeated 1 time(s).18:50
rjeffriess0rry for dupe18:50
wpwraklekernel: what has the world come to ... nowadays a torturer can't even enjoy his easter holidays in peace. the inquisitors sure had it better.18:50
wpwrakrjeffries: 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 ? ;-)18:53
wpwrakrjeffries: of course, a drowning man will cling to anything :)18:54
rjeffriesIMO Nokia will make it, no question.  And they know how to manufacture in VERY high volume18:56
rjeffriesback in the day when I worked for Ericsson one person explained how crucial software quaity is18:56
rjeffriesas he put it, they were shipping a 747 worth of phone to China, per day18:57
rjeffriesNokia tablet that is NOT Microsoft would be a good idea IMO19:00
wpwrakrjeffries: i'm pretty sure those 747 are national flights today :)19:00
rjeffriesyes indeed. nobody builds anything in quantity oustide of asia. sadly19:00
wpwrakrjeffries: nokia is now wed to M$, probably till death do them part19:00
rjeffriesI am amazed at the uptake of iPhone in China. many rich people I guess19:00
rjeffriesIntel so far is missing out on tablet wave19:00
wpwrakrjeffries: 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.19:06
kristianpaulwow 78905 :-)19:06
Action: wpwrak rules ! :)19:06
wpwrakit'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.19:32
wpwrakah, JEDEC JESD84-A441 has some more details.19:43
wpwrakgrmbl. MMC specify stream mode only for a 1 bit bus and ingenic implement this restriction :-(19:47
rjeffrieswpwrak when we have 4760 (it just a matter of time...;) will the increased CPU speed help with VGA hack?21:11
wpwrakrjeffries: maybe. if things go well, then i'll use mainly the MMC controller, so the CPU speed would be less important22:03
rohmmc isnt dead yet?22:35
wpwrakroh: they're still making new standards, it seems :)22:35
rohhm. can somebody explain to me what i missed?22:39
rohwhy is vga so important for you?22:39
wpwrakoh, it fun :)22:41
wpwrakbesides, it may actually be useful. imagine giving a presentation with a ben :)22:42
--- Tue Apr 26 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!