<wpwrak> 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 ?
<wpwrak> maybe i should simulate the thing ...
<kristianpaul> upgrade is good, no?
<wpwrak> i wonder what would look better. in each case, you'd get twice the colors
<wpwrak> 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.
<qi-bot> [commit] Werner Almesberger: ubb-vga.c: removed commented-out code from earlier experiments http://qi-hw.com/p/ben-blinkenlights/8bd7199
<qi-bot> [commit] Werner Almesberger: ubb-vga/README: added title and compatibility list http://qi-hw.com/p/ben-blinkenlights/fb153b2
<qi-bot> [commit] Werner Almesberger: ubb-vga.c: removed unused #defines and rearranged the code a little http://qi-hw.com/p/ben-blinkenlights/554c664
<qi-bot> [commit] Werner Almesberger: ubb-vga.c: a bit more cleanup http://qi-hw.com/p/ben-blinkenlights/dae2169
<qi-bot> [commit] Werner Almesberger: ubb-vga.c: moved line length and timing to variables http://qi-hw.com/p/ben-blinkenlights/dab839a
<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/67107d0
<qi-bot> [commit] Werner Almesberger: ubb-vga: documented single and double mode http://qi-hw.com/p/ben-blinkenlights/5df56a3
<wpwrak> kristianpaul: ah no, the math isn't quite so evil. once i draw the circuit diagram, it became clearer ;-)
<qi-bot> [commit] Werner Almesberger: renamed ubb-vga/res.fig to mapping.fig http://qi-hw.com/p/ben-blinkenlights/e1e473e
<kristianpaul> wpwrak: diagrams and graphs usually are not so evil when coming from nice math
<DocScrutinizer> 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
<qi-bot> [commit] Werner Almesberger: ubb-vga/README: "single/double mode", not "single-double mode" http://qi-hw.com/p/ben-blinkenlights/ce1c6af
<wpwrak> DocScrutinizer: uh, that would require transistors
<DocScrutinizer> really?
<DocScrutinizer> hmm, yes, for batery it would
<wpwrak> 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
<DocScrutinizer> do you need a few hundered?
<wpwrak> 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
<wpwrak> 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
<wpwrak> 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 :)
<DocScrutinizer> WTF is that?
<wpwrak> VGA out for the ben :)
<wpwrak> don't you read the list ? ;-)
<DocScrutinizer> hah
<DocScrutinizer> nah, too many lists
<DocScrutinizer> what are the D?
<DocScrutinizer> clamp?
<DocScrutinizer> I.E. "Zeners"?
<wpwrak> voltage limiters. VGA wants 0.7 V max, so i drop to Vf.
<DocScrutinizer> yeah, Zeners
<DocScrutinizer> use 2 Schottky
<wpwrak> naw, just regular diodes :)
<DocScrutinizer> err 4
<DocScrutinizer> 3 into one
<DocScrutinizer> and short the one to GND with your 4th bit
<wpwrak> i;ll replace them with resistors in the next version. no need for fancy semiconductors :)
<DocScrutinizer> meh
<DocScrutinizer> for your 4th bit for brightness you just need 1 additional diode
<DocScrutinizer> if you got totem pole outputs
<DocScrutinizer> err, plus one R
<wpwrak> hmm, how ? the outputs are GPIOs, so they switch between 0 and 3.3 V
<DocScrutinizer> better you got an open collector output to GND
<wpwrak> OC may get messy. there are pull-ups inside the ben
<wpwrak> besides, i think i'd still need an R for each channel for the brightness bit, no ?
<DocScrutinizer> nope
<DocScrutinizer> your 3 diodes are to GND, no?
<DocScrutinizer> rise that "GND" by 0.2V and your output volage rises from 0.7 to 0.9
<wpwrak> aah, okay. that would be an option. couldn't get rid of the diodes then, though.
<wpwrak> but i could try the same with Rs ...
<DocScrutinizer> or, for schottky, it rises from 0.3 to 0.6V
<DocScrutinizer> nope, with Rs you get crosstalk
<DocScrutinizer> lots of
<wpwrak> crosstalk is okay as long as i can calculate it :)
<DocScrutinizer> lol
<wpwrak> 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 ;-)
<DocScrutinizer> I'd do a weird thing ;-P
<wpwrak> random() ? ;-)
<DocScrutinizer> build an ultrasimple rather slow S&H strobed by the 4th bit, then add the value of the S&H to the 3 bits
<wpwrak> hehe, nice :)
<wpwrak> but that doesn't work. i'm already fighting with pixel timing
<DocScrutinizer> hehe
<DocScrutinizer> well, what was that amiga thing, where 1. pixel defined R, 2nd B, and 3rd G value
<wpwrak> R/G/B so far that would be what i have
<DocScrutinizer> yeah, but then you can have 9bpp and just a smaller resolution, for arbitrary areas of screen
<wpwrak> oh, i see :)
<wpwrak> well, i already kinda mix two pixels into one in "single" mode ..
<wpwrak> may be able to disentangle them a bit, though. we'll see.
<wpwrak> the main problem are the dreadfully slow GPIO updates. a set-clear pair takes 17 PCLK cycles. PCLK is 112 MHz.
<wpwrak> when i try to change PCLK (even make it slower), the system freezes. not sure yet why.
<wpwrak> 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
<wpwrak> and read-as-you-go is too slow
<DocScrutinizer> yay, funny. Sounds like ZX81
<wpwrak> oh yes, very :)
<wpwrak> 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
<DocScrutinizer> you're sure about the hw accel?
<kristianpaul> what is a hw accel for a Z80 btw...
<kristianpaul> ?
<wpwrak> 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
<wpwrak> well, chips more complex than inverters :)
<wpwrak> kristianpaul: probably an 8 bit shift register, possibly plus a FIFO
<DocScrutinizer> hehe
<kristianpaul> shifters do nice job
<kristianpaul> a FIFO??
<kristianpaul> hmm
<wpwrak> at least one FIFO stage would be nice. otherwise, you need to have very precise (and fast) timing for the reloading
<DocScrutinizer> there are shiftregs with a sample stage
<wpwrak> DocScrutinizer: yup. i know i'm not the first to discover the usefulness of that ;-)
<DocScrutinizer> anyway you're right. I thought it had direct video output from a r/2r
<DocScrutinizer> used those a lot, both in and out, to extend 3 IO of an atmel to a chain of inputs/outputs of arbitrary length
<wpwrak> brr. what a waste. just use more mcus. multiprocessors are all the rage anyway ;-)
<wpwrak> you could even do remote code execution: send a function over SPI, the recipient writes it into its own flash, then runs it ;-)
<DocScrutinizer> *cough*
<wpwrak> well, for a few thousand times, until the flash wears out :)
<DocScrutinizer> nah, atmel 89c2051, has iirc 20mA per IO
<DocScrutinizer> sth like 3EUR for a DIL20
<wpwrak> DIL .. *shiver*
<DocScrutinizer> LOL
<DocScrutinizer> really convenient
<wpwrak> too many holes to drill
<DocScrutinizer> meh
<DocScrutinizer> we ordered the boards
<wpwrak> how lame :)
<DocScrutinizer> pretty good quality, doublesided with via, and 8 boards on one eurocard for iirc 30EUR
<wpwrak> good price, yes
<DocScrutinizer> yeah, at a qty of 10
<DocScrutinizer> the 'pusteflipper'
<wpwrak> ;-)
<qi-bot> [commit] David Kühling: Disable (all?) patented codecs.  Disable ffmpeg's (broken) ogg demuxer. http://qi-hw.com/p/openwrt-packages/ffb6f8b
<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/7795ff0
<whitequark> wpwrak: uh-oh, I'm talking with The Creator of pstree!
<wpwrak> whitequark: heh, you found the man page ;-)
<dvdk> whitequark: you mean with the author of the man page :)
<wpwrak> dvdk: naw, the program as well :) i actually don't remember if i also wrote the man page or if this was someone else
<dvdk> apt-get source psmisc
<dvdk> :)
<dvdk> Copyright (C) 1993-2002 Werner Almesberger
<dvdk> wow they had computers back in 1993?
<dvdk> wpwrak: did you see the mail about vga?  wondered why you had to use dats/datc , not just write to dat once per pixel
<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.
<kristianpaul> * pstree.c - display process tree
<kristianpaul> *
<kristianpaul> * Copyright (C) 1993-2002 Werner Almesberger
<kristianpaul> :D
<kristianpaul> * Copyright (C) 2002-2009 Craig Small
<kristianpaul> yes seems they had dvdk ;)
<wpwrak> 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 :)
<kristianpaul> lol
<wpwrak> ironically, back in those days (gcc 1.xx), compiling a kernel was faster than for many years afterwards (gcc 2.xx and beyond)
<kristianpaul> how fast? (i want to wonder)
<wpwrak> 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.
<dvdk> wpwrak: ah, you mean pxdat is read only?  didn't realize that
<wpwrak> 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 :)
<wpwrak> dvdk: yup
<dvdk> wpwrak: but isn't there a 'toggle' register?
<kristianpaul> wpwrak: yeah drivers... always the problem is there..
<kristianpaul> well not always, but is not that the code that grown all days..?..
<dvdk> wpwrak: no toggle register afaics.  uhh :(
<dvdk> wpwrak: btw, creating ntsc/pal timiings would give higher resulution
<wpwrak> dvdk: no toggle either
<dvdk> (looking at the video drivers of the uzebox)
<wpwrak> dvdk: oh, i'm already maxing out the timing. in fact, even in "single" mode, i'm taking about 110% of the "official" time
<kristianpaul> heads to travel
<kristianpaul> read you later
<wpwrak> 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
<dvdk> 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
<dvdk> wpwrak: used to write my own mode-lines for xservers, didn't know there was even a standard (that was on analog monitors, anyways).
<wpwrak> 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
<wpwrak> dvdk: mostof the time
<wpwrak> oops ... ente too early
<wpwrak> 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
<wpwrak> dvdk: i also found that trying to send every line only once was met with disapproval
<Fusin> is reflashing his ben
<Fusin> well, I try and hope it will all function ;)
<dvdk> wpwrak: that's the advantage of pal/ntsc, where sending each line once would work
<dvdk> s/would/might
<dvdk> 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)
<dvdk> wpwrak: only handling vsync via bit-banging
<wpwrak> dvdk: hmm. there's a "busy" handshake in SD. lemme see if i could get rid of that ...
<dvdk> is looking up the datasheet
<Fusin> flashing... flashing...
<Fusin> takes a while coz connection to inet is per 3G
<Fusin> is impatient ;)
<wpwrak> 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.
<dvdk> wpwrak: what about the stream transfer mode, the datasheet talks about?
<dvdk> wpwrak: isn't mmc just a subset of sdio?
<dvdk> so maybe it's ok for sdio?
<dvdk> wow, just encoded an old 4:3 movie for nanonote.
<dvdk> encoded for full-screen 320x240 , plays without problems so far
<wpwrak> not quite sure yet what that stream mode is ...
<dvdk> 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?
<wpwrak> ah yes, taht sounds interesting
<wpwrak> (bad data sheets) yes, thanks to sdcard.org treating their bloody protocol as partially secret
<wpwrak> ah, section 21.5.5.2 has stream mode. nice :)
<dvdk> wpwrak: sure you want to rely on data card manuals?  isn't that a level too hiegh (above sdio)?
<wpwrak> the trick is to combine hints from all possible sources ;-)
<wpwrak> 21.5.7, the table, bit 31: "OUT_OF_RAGE" :)
<viric> Anyone running a 2.6.36 kernel or newer?
<viric> I don't have battery information..
<viric> # CONFIG_BATTERY_JZ4740 is not set
<viric> grr
<viric> I'll try the trunk of xburst-tools
<kyak> do you mean the qi-kernel?
<viric> kyak: I mean the linux kernel
<viric> hm openwrt-trunk still does not have anything for 2.6.38 for xburst.
<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/dfdcbcb
<Fusin> bonjour la france :D
<kyak> viric: linux kernel development for xburst is done here: http://projects.qi-hardware.com/index.php/p/qi-kernel/
<viric> kyak: but larsc uses to update openwrt-trunk setting series of patches and a config file.
<viric> or *used to update* :)
<viric> maybe he does not have 2.6.38 ready
<kyak> i'm not sure about that.. openwrt-xburst is using 2.6.32 for along time now
<viric> openwrt-trunk only has configuration for 2.6.35 and 2.6.36
<viric> sorry
<viric> 2.6.36 and 2.6.37. I'm using that 2.6.36 now
<viric> I imagine that 'openwrt-xburst' works as a super-stable version (in terms of more tested).
<kyak> ah, *that* openwrt-trunk.. i misunderstood :)
<viric> :)
<viric> why is the qi openwrt still using 2.6.32?
<viric> It's simply waiting for someone to require an update to achieve some new feature?
<kyak> i think moving to the latest openwrt-trunk is planned once it's released
<kyak> so far, openwrt-xburst is following openwrt-backfire
<viric> "it's released"? What has to be relased exactly, and by who?
<viric> Aahhh
<viric> an openwrt major release.
<kyak> yea
<viric> kyak: did you try the scaler from David?
<kyak> viric: nope, not yet
<viric> xiangfu: it's me who wrote on xburst-tools... thank you for the answer
<viric> I did not know about git submoduels
<viric> submodules
<xiangfu> viric: oh. thanks for sending patch. we need more :D
<viric> haha. I only prepare patches until it works for me. and it works for me now :)
<qi-bot> [commit] Xiangfu Liu: libtcod: using source code tags: 1.5.0 http://qi-hw.com/p/openwrt-packages/b59a47d
<methril> !last tuxbrain
<methril> ~last tuxbrain
<kyak> that would be:
<methril> thankyou kyak
<kyak> np
<dvdk> wpwrak: any chance sdio-driven vga is going to work?
<methril> uhm... a little bit strange 1 week without tuxbrain news...
<dvdk> wpwrak: btw if you need physical memory for dma in your user-space app, have a look here:
<dvdk> alloc_phys()
<dvdk> :)
<qi-bot> [commit] David Kühling: mplayer_jz47xx: yet another upgrade with minor scaler improvements (accuracy) http://qi-hw.com/p/openwrt-packages/d6e8b1f
<qi-bot> [commit] David Kühling: mplayer: (increase release number) http://qi-hw.com/p/openwrt-packages/5751ee9
<wpwrak> 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.
<rejon> that will never ship
<rejon> man, this UBB-VGA sounds really exciting!
<dvdk> wpwrak: cool.  so can you toggle CMD automatically using just gpio control registers.  or is real hw needed?
<wpwrak> rejon: just too bad VGA is slowly dying ...
<wpwrak> 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.
<rejon> wpwrak I think we have a long time left on vga
<rejon> wpwrak what resolution do you think that VGA can get cranked up too?
<wpwrak> dvdk: i could perhaps still use CMD for VSYNC, with a little low-pass filter
<wpwrak> 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.
<dvdk> wpwrak: if continuous transfers work, don't you have to toggle cmd only once, and then keep streaming forever?
<wpwrak> dvdk: (continuous) ah, maybe. haven't tried that yet.
<rjeffries> somebody needs to alert tuxbrian that Easter holidays are complete. back to work! <grin>
<rjeffries> s/tuxbrian/tuxbrain
<wpwrak> rjeffries: monday may still be a holiday in spain (as it is in most of europe)
<rjeffries> 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)?
<rjeffries> I know tehre are several USB to dsiplay adapters a similar idea I think?
<rjeffries> actually... this takes me back to thoughts of external Propeller board. just a brain excercise is all
<rjeffries> 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
<wpwrak> rjeffries: i don't know HDMI. i would expect it to operate with a faster clock than what we can usefully provide
<wpwrak> ah, minimum clock speed of DVI is ~25 MHz. that would work.
<wpwrak> that is, if that's the link clock, not the pixel clock. looks like pixel clock, though
<dvdk> wpwrak: looks like 25 mhz is the pixel clock :(
<wpwrak> ah yes, data clock = 10 x pixel clock. that would be 251 MHz. no way.
<rjeffries> wpwrak couldn't the clock originate external to Ben? (pardon my massive ignorance)
<rjeffries> if the external widget has memory, copy our framebuffer to it, then all magic happens elsewehere
<kristianpaul> ha, there is movie call *troll*
<kristianpaul> lol
<kristianpaul> a mean for this year
<kristianpaul> (end of OT)
<wpwrak> rjeffries: sure, you could have an external video generator. but that eliminates the simple beauty of the vga solution
<rjeffries> wpwrak understood.
<rjeffries> maybe just maybe Nokia has a hold card vs. a vs. Microfoft and Windows Phone
<rjeffries> s0rry for dupe
<wpwrak> 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.
<wpwrak> 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 ? ;-)
<wpwrak> rjeffries: of course, a drowning man will cling to anything :)
<rjeffries> IMO Nokia will make it, no question.  And they know how to manufacture in VERY high volume
<rjeffries> back in the day when I worked for Ericsson one person explained how crucial software quaity is
<rjeffries> as he put it, they were shipping a 747 worth of phone to China, per day
<rjeffries> Nokia tablet that is NOT Microsoft would be a good idea IMO
<wpwrak> rjeffries: i'm pretty sure those 747 are national flights today :)
<rjeffries> yes indeed. nobody builds anything in quantity oustide of asia. sadly
<wpwrak> rjeffries: nokia is now wed to M$, probably till death do them part
<rjeffries> I am amazed at the uptake of iPhone in China. many rich people I guess
<rjeffries> Intel so far is missing out on tablet wave
<wpwrak> 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.
<kristianpaul> wow 78905 :-)
<wpwrak> rules ! :)
<wpwrak> 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.
<wpwrak> ah, JEDEC JESD84-A441 has some more details.
<wpwrak> grmbl. MMC specify stream mode only for a 1 bit bus and ingenic implement this restriction :-(
<rjeffries> wpwrak when we have 4760 (it just a matter of time...;) will the increased CPU speed help with VGA hack?
<wpwrak> rjeffries: maybe. if things go well, then i'll use mainly the MMC controller, so the CPU speed would be less important
<roh> mmc isnt dead yet?
<wpwrak> roh: they're still making new standards, it seems :)
<roh> m-/
<roh> .s
<roh> hm. can somebody explain to me what i missed?
<roh> why is vga so important for you?
<wpwrak> oh, it fun :)
<wpwrak> s/it/it's/
<wpwrak> besides, it may actually be useful. imagine giving a presentation with a ben :)